Op_Cat: Идеальное решение для ковенантов?

OP_CAT дали зеленый свет? Предложению недавно был присвоен номер BIP 347. Но прежде чем мы углубимся в эту тему, давайте выясним, что такое ковенанты и почему они могут понадобиться биткоинерам.

Является ли Биткоин идеальным вариантом цифровых электронных денег или мы хотим большего от наших монет в цепочке?

Ограничения Биткоин-скриптов

Чтобы понять предложения по ковенантам, такие как OP_CAT, крайне важно понять фундаментальные ограничения Bitcoin Script в его нынешнем виде. Биткоин позволяет создавать базовые смарт-контракты с помощью кодов, определяющих правила блокировки и разблокировки средств. Однако Bitcoin Script, как язык программирования, довольно ограничен базовой логикой, которая вступает в действие только при перемещении монет в новой транзакции.

Сегодня в Биткоине нет возможности предварительно настроить или продиктовать пути транзакций ваших монет или то, как быстро монеты могут перемещаться в момент их блокировки (за исключением хакерских рабочих процессов с использованием PSBT, частично подписанных транзакций, которые не могут должным образом включать комиссию за транзакцию, доказывать удаление, если оно не использовалось, или предотвращать последующую трансляцию).

Эта простота, являющаяся основой модели безопасности Биткоина, накладывает существенные ограничения на способность языка сценариев поддерживать даже базовые смарт-контракты.

Линейная модель исполнения

Одним из ограничений Bitcoin Script является его операционная модель, в которой коды операций выполняются последовательно.

Из этого примера транзакции P2PKH можно увидеть, как сценарий выполняется линейно: дублирование открытого ключа, его хеширование по адресу, проверка хеша по сценарию блокировки и, наконец, проверка подписи по открытому ключу.

Отсутствие циклов означает, что сценарии не являются полными по Тьюрингу и гарантированно завершаются, предотвращая такие проблемы, как бесконечные циклы, которые потенциально могут остановить или значительно замедлить работу сети. Хотя этот дизайн позволяет статически ограничивать использование ресурсов, он также ограничивает возможности Script управлять сложными рабочими процессами.

Отсутствие базовой арифметики

Bitcoin Script имеет чуть менее 100 нетривиальных кодов операций, и, что несколько удивительно, в нем нет возможности умножать, делить или комбинировать объекты в стеке. Как известно многим пользователям, интересующимся OP_CAT, Сатоши отключил несколько кодов операций в Биткоине в 2010 году, в том числе OP_OR, OP_MUL (умножение), OP_DIV (деление) и OP_CAT (объединение). Отключенные коды операций были отключены, поскольку их первоначальные реализации содержали уязвимости, которые могли поставить под угрозу безопасность сети. Но отсутствие этих кодов операций затрудняет выполнение базовых математических вычислений, которые могут быть полезны в простых сценариях, таких как расчет комиссий за транзакции в контракте.

Отсутствие видимости данных транзакций

Большинство людей наверняка предполагают, что смарт-контракты Биткоина способны видеть суммы и другие части данных транзакций, поскольку эта информация уже публично доступна для просмотра в блокчейне. Но вопреки этому предположению, контракты на Биткоине не могут устанавливать условия расходов на основе данных транзакций, потому что Bitcoin Script вообще имеет очень ограниченную способность просматривать данные транзакций.

Если бы скрипт имел возможность интерпретировать больше деталей в данных транзакций, мы могли бы создавать гораздо более надежные контракты, которые могли бы делать более интересные вещи, такие как соблюдение определенных условий расходов, создание многоэтапных транзакций и активация более продвинутых функций безопасности, вроде хранилища.

Что с этим делать?

Мы знаем, что у Биткоина есть эти ограничения, и на протяжении многих лет обсуждалось множество различных предложений по внедрению (или, в некоторых случаях, повторному введению) этой функциональности. Более широкие эксперименты с Bitcoin Script, такие как Simplicity и другие, направлены на предоставление альтернативы ограничениям на основе стека. Такие коды операций, как OP_MULTISHA256, OP_LESS и OP_LE32TOLE64, направлены на улучшение арифметических способностей Биткоина. Предложения, такие как OP_CTV и OP_CAT, которые касаются кодов операций интроспекции, сгруппированы под термином «ковенанты».

Так в чем же разница между смарт-контрактами и ковенантами?

Смарт-контракты и ковенанты

Смарт-контракты – это самоисполняющиеся транзакции, которые передают средства без посредников. Сегодня в Биткоине смарт-контракты ограничиваются блокировкой и разблокировкой биткоина с помощью Bitcoin Script. Целью ковенантов является улучшение функциональности смарт-контрактов Биткоина, позволяя пользователям контролировать, как их средства расходуются в будущих транзакциях.

Разрешая Script интерпретировать данные транзакции, мы создаем эффективный способ использования этих данных в логике контракта.

Это лишь некоторые из наиболее интересных опкодов самоанализа функциональности ковенантов:

1. OP_TXHASH: предоставляет хеш входных (или выходных данных) транзакции и дает скрипту возможность проверять и обеспечивать соблюдение условий на основе данных транзакции.
2. OP_CSFS + OP_CAT: вместе они позволяют скриптам проверять подписи по любым данным, а не только по самой транзакции. Это означает, что скрипт может проверять условия на основе данных транзакций или внешней информации, расширяя возможности проверки в скриптах Биткоина.

Эти два кода операций имеют намеренно широкое применение, что обеспечивает сложные процессы проверки и возможности интроспекции. Другие имеют более узкую сферу применения и представляют собой более ограниченную форму ковенантов.

1. OP_CHECKTEMPLATEVERIFY (CTV): позволяет вставлять в выходные данные транзакции шаблон будущей транзакции расходов, обеспечивая более ограниченное выполнение ковенантов.
2. OP_VAULT: включает особую форму соглашения, используемую для «хранилища», которая позволяет пользователям указывать место назначения транзакции, но не перемещать монеты фактически, кроме как после задержки.

Кроме того, существует отдельный OP_CAT, который не является непосредственно опкодом интроспекции…

1. OP_CAT: позволяет Script объединять два элемента в стеке, что полезно для объединения различных фрагментов информации внутри скрипта.

У OP_CAT, похоже, нет никаких способностей к интроспекции, так что же тогда происходит?

OP_CAT: раскрытие всех возможностей

Интроспекция транзакций

В 2021 году Эндрю Поэльстра написал в своем блоге о приемах интроспекции OP_CAT. Он привел конкретные примеры, но предположил, что читатели уже знакомы с подобными методами. Здесь я постараюсь упростить это объяснение для лучшего понимания.

В Bitcoin Script есть только три основных кода операций, которые позволяют анализировать данные транзакции: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY и CHECKSIG. Кроме того, существуют такие варианты, как CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG и CHECKMULTISIGVERIFY, которые по сути являются второстепенными вариациями CHECKSIG. Первые два позволяют только увидеть, подтверждена ли проверка, обеспечивая довольно узкий функционал. CHECKSIG аналогичен, но разница в том, что он позволяет получить подпись и открытый ключ из стека. Интересно.

Традиционно мы думаем о конкатенации как о функции, которая соединяет два элемента вместе, но мы также можем использовать ее для отделения или разделения элемента, в данном случае – подписи на пару (r, s).

Как же получить функциональность OP_SPLIT в OP_CAT?

«Можно разделить какой-то большой объект, попросив пользователя предоставить две части. Вы объединяете их вместе и проверяете равенство. Таким образом вы всегда можете инвертировать каждую операцию. С помощью CAT вы можете разделять на части подписи». – Эндрю Поэльстра, TABConf 2021

Что это значит? Требуя от пользователя предоставить подпись, открытый ключ и транзакцию, вы можете разделить подпись на составные части, а затем независимо проверять каждую часть на соответствие данным транзакции. Этот метод можно рассматривать как форму разделения или объединения, поскольку он подтверждает, что подпись и открытый ключ действительно являются компонентами действительной транзакции.

Какое отношение это имеет к интроспекции?

«В Taproot, где есть подписи Шнорра с использованием OP_CAT и опкода проверки подписи Шнорра, оказывается можно получить форму нерекурсивного соглашения, где вы буквально получаете хеш транзакции. Это не просто искажённый хеш транзакции, а настоящий SHA2-хеш всех данных транзакции в стеке». – Эндрю Поэльстра, TABConf 2021

Поэльстра демонстрирует, как можно получить хэш SHA2 для входных или выходных транзакций, оставшихся в стеке. Пропустим здесь математику, смысл в том, что с помощью OP_CAT мы можем ограничить части транзакции в соответствии с требованием сценария разблокировки. Мы можем ограничить адрес отправки или значение, отправляемое этой транзакцией, где хеш транзакции служит ключом для ее разблокировки.

Хранилища

Использование тех же методов дает нам интроспекцию транзакций и базовую версию хранилищ. Следуя логике, изложенной в блоге Поэлстры, разработчик под ником Rijndael доказал, что мы можем сделать это только с помощью OP_CAT в своей реализации Purrfect Vaults.

«Восстановление TXID в стеке для анализа предыдущих транзакций оказалось на самом деле проще, чем я ожидал». – Rijndael

При использовании хранилищ пользователи указывают следующий адрес, по которому должны быть отправлены их средства, обеспечивая механизмы восстановления средств в случае компрометации ключа и уменьшая стимулы для кражи закрытого ключа.

Деревья Меркла

Сегодня в Биткоине деревья Меркла – это структура данных, используемая для проверки данных, синхронизации и некоего «связывания» транзакций и блоков блокчейна. Код операции OP_CAT, который позволяет объединить две переменные стека при использовании вместе с хешами открытых ключей SHA256, упрощает процесс проверки дерева Меркла для скриптов. Этот подход, первоначально предложенный Питером Вюйлем в 2015 году, был успешно реализован в сети Liquid.

Представьте себе древовидную структуру, наполненную различными условиями расходов, такими как прообразы хешей, блокировки по времени и открытые ключи, известные как Tree Signatures.

Tree Signatures

OP_CAT позволяет создавать Tree Signatures, которые:

«...Предоставляют скрипт мультиподписи, размер которого может быть логарифмическим по числу открытых ключей и который может кодировать условия расходов, выходящие за пределы n-из-m. Например, транзакция размером менее 1 КБ может поддерживать Tree Signatures с тысячей открытых ключей. Это также обеспечивает обобщенные логические условия расходов». – Автор BIP Итан Хейлман, в списке рассылки bitcoin-dev

Это позволит проверять любой хешированный контент в дереве, обеспечивая целостность и надежность данных без увеличения объема или раздувания блокчейна.

Почему это интересно?

Рекурсивные соглашения (ковенанты)

Если у вас есть возможность проверить транзакцию и применить ограничения к определенным ее частям, вы можете настроить условия, которые будут распространяться на несколько транзакций, эффективно создавая цепочку постоянных ограничений. Эта концепция называется рекурсивным соглашением. OP_CAT – уникальное предложение, поскольку оно дает нам столько возможностей всего в 10 новых строках кода. Он способен устранить все три первоначальных ограничения, о которых мы говорили в начале статьи: видимость данных транзакций, улучшенные математические функции и линейную модель выполнения.

Хотя на первый взгляд OP_CAT может показаться простым, при творческом использовании он раскрывает значительный потенциал. Он служит строительным блоком для еще большей функциональности, выходящей за рамки этой статьи, например, пост-квантовой подписи Лампорта.

Безопасно ли это?

До того, как OP_CAT был первоначально удален, при его сочетании с OP_DUP (дубликат) и повторном использовании для дублирования первоначально 1-байтового значения в стеке использование памяти могло резко возрасти. Это могло быть использовано как атака типа «отказ в обслуживании» (DoS) из-за повышенного потребления памяти. Новое предложение тривиально предотвращает эту атаку, налагая ограничение на элементы стека в 520 байт.

Есть ли опасность того, что контракт будет действовать вечно?

Если под этим имеется в виду, меняет ли OP_CAT модель выполнения Script, означающую, что он больше не ограничивает статически использование ресурсов (как линейную функцию размера сценария) – нет.

Смогут ли ковенанты создать рынок для других монет помимо Биткоина?

Да, если у вас есть рекурсивное соглашение, вы можете технически создавать сложные приложения второго уровня, в том числе NFT, децентрализованные биржи и квантовых котов. Однако сделать это не так просто. Трудно представить, чтобы серьезный рынок сделал это.

Можно ли навсегда «испортить» монеты с помощью CAT?

В случае цветных монет и NFT, выпуская эти активы, пользователь фактически «сжигает» сатоши, маркируя его таким образом, что это означает владение активом «второго уровня». Этот процесс известен как «порча» монет. Но только владелец монеты может пометить свою монету, и биткоин-кошельки больше не будут ее распознавать (если только их авторы явно не добавят код, позволяющий это сделать). Полученные монеты не будут приниматься биткоин-кошельками. Вероятно, их будут принимать кошельки Cryptocat или что-то в этом роде, но для большинства пользователей биткоина это не имеет значения.

Создаст ли это проблему MEV для Биткоина?

Ключевым моментом различия между Биткоином и Ethereum является видимость транзакций. В отличие от Ethereum, не все аспекты контракта обязательно прозрачны, а это означает, что майнеры биткоина не имеют такой же возможности видеть внутреннее состояние контракта и заранее управлять им.

Основная проблема OP_CAT для биткоинеров, мыслящих с экономической точки зрения, – это потенциальная извлекаемая майнерами ценность (MEV). Многие пользователи обеспокоены тем, что если мы сделаем контракты второго уровня технически возможными, MEV станет неизбежным. Но так ли это? В частности, подразумевает ли техническая осуществимость монет второго уровня в Биткоине их неизбежное создание и принятие?

Можно представить себе создание простых своп-контрактов или сравнительно неэффективных NFT, но создание чего-то столь же сложного, как DEX с автоматическими маркет-мейкерами, кажется крайне маловероятным и даже близки не похоже на то, что мы видели на Liquid, несмотря на «техническую возможность» для этого.

Является ли Op_Cat идеальным?

Вряд ли. Некоторые выступают за рекурсивные соглашения, в то время как другие просто не хотят, чтобы Биткоин менялся вообще.

Группа «закоченелых» биткоинеров выступает за сохранение Биткоина в его нынешнем состоянии и относится к любым обновлениям протокола со скептицизмом. Они особенно обеспокоены тем, что значительные изменения, такие как введение соглашений, могут подорвать децентрализацию сети. Их аргументы основаны на убеждении, что лучше всего придерживаться первоначального видения Биткоина. Ирония того, что OP_CAT изначально был частью Биткоина, подпитывает контраргумент. Некоторые полагают, что возвращение OP_CAT может фактически привести Биткоин в соответствие с первоначальным видением Сатоши.

Для внедрения некоторых функций безопасности, которые могут сделать возможными рекурсивные соглашения, OP_CAT был бы хорош, но определенно не так хорош, как полноценный язык сценариев в стиле Lisp. Проблема здесь в том, что это будет масштабное изменение в Биткоине, которое вряд ли найдет поддержку в ближайшее время.

Или, может быть, вы предпочитаете простоту нерекурсивных методов, таких как OP_CTV или OP_VAULT. Нерекурсивные соглашения проще и легче обсуждать без риска создания неконтролируемой цепочки ограничений.

Что, если некая версия рекурсивных соглашений была бы неизбежна?

За прошедшие годы разработчики заметили, что практически любое расширение логики проверки транзакций можно использовать для эмуляции функциональности OP_CAT.

Во вселенной Script есть две области, в зависимости от размера элементов стека. Для элементов стека размером более 4 байтов можно сравнивать их на равенство, интерпретировать как ключ, подпись или хешировать. Элементы стека размером менее 4 байтов или равные им можно рассматривать как объекты для выполнения арифметических операций или ветвления. С процессором RISC-V, работающим на BitVM, вы можете делать буквально все. Все, что позволяет вам эмулировать OP_CAT, разбивать элементы стека или объединять их вместе, объединяет эти две области, так что вы можете «делать что угодно» с помощью Script.

Такие исследователи, как Эндрю Поэльстра, полагают, что мы сможем заключать рекурсивные соглашения практически с любым новым кодом операции. Если это так, это было бы оправданием для работы над тем, чтобы усовершенствовать их.

Является ли OP_CAT вероятным путем для соглашений?

Если ковенанты не просто интересны, но и неизбежны, как мы можем гарантировать, что они будут реализованы таким образом, чтобы больше пользователей Биткоина бездоверительно отправляли средства, как первоначально предполагал Сатоши? В то время как мнения закостенелых биткоинеров по-прежнему разделены, OP_CAT остается горячей темой в дебатах о ковенантах.

OP_CAT – не самое доскональное долото, но оно имеет лучшее соотношение мощности и сложности, что позволит разработчикам создавать некоторые удивительные новые функции.

Это гостевой пост Киары Бикерс. Высказанные мнения являются ее собственными и не обязательно отражают точку зрения BTC Inc. или Bitcoin Magazine.