Происходит ли OP_CAT? Предложению о ковенантах только что был присвоен номер BIP № 347. Но прежде чем мы углубимся, давайте выясним, что такое ковенанты и почему они могут понадобиться биткойнерам.
Является ли Биткойн идеальным вариантом цифровых электронных денег или мы хотим большего от наших монет в цепочке?
Поцарапав поверхность: ограничения биткойн-скриптов
Чтобы понять предложения по заветам, такие как OP_CAT, крайне важно понять фундаментальные ограничения биткойн-скрипта в его нынешнем виде. Под капотом Биткойн позволяет создавать базовые смарт-контракты с помощью кодов, определяющих правила блокировки и разблокировки средств. Однако Bitcoin Script, как язык программирования, довольно ограничен базовой логикой, которая вступает в действие только при перемещении монет в новой транзакции.
Сегодня в Биткойне нет возможности предварительно настроить или продиктовать пути транзакций ваших монет или то, как быстро монеты могут перемещаться в момент их блокировки (кроме хакерских рабочих процессов с использованием PSBT, частично подписанных транзакций биткойнов, которые не могут должным образом включать комиссию за транзакцию, доказывать удаление, если оно не использовалось, или предотвращать последующую трансляцию).
Эта простота, являющаяся основой модели безопасности Биткойна, накладывает существенные ограничения на способность языка сценариев поддерживать даже базовые смарт-контракты.
Линейная модель исполнения
Одним из ограничений Bitcoin Script является его операционная модель, в которой коды операций выполняются последовательно, без циклов.
Из этого примера транзакции P2PKH вы можете увидеть, как сценарий выполняется линейно: дублирование открытого ключа, его хеширование по адресу, проверка хеша по сценарию блокировки и, наконец, проверка подписи по открытому ключу.
Отсутствие циклов означает, что сценарии не являются полными по Тьюрингу и гарантированно завершаются, предотвращая такие проблемы, как бесконечные циклы, которые потенциально могут остановить или значительно замедлить работу сети. Хотя этот выбор дизайна позволяет статически ограничивать использование ресурсов, он также ограничивает возможности Script управлять сложными рабочими процессами.
Отсутствие базовой арифметики
Bitcoin Script имеет чуть менее 100 нетривиальных кодов операций, и, что несколько удивительно, в нем нет возможности умножать, делить или комбинировать объекты в стеке. Как известно многим пользователям, интересующимся OP_CAT, Сатоши отключил несколько кодов операций в Биткойне в 2010 году, включая OP_OR, OP_MUL (умножение), OP_DIV (деление) и OP_CAT (объединение) среди других. Отключенные коды операций были удалены, поскольку их первоначальные реализации содержали уязвимости, которые могли поставить под угрозу безопасность сети. Но отсутствие этих кодов операций затрудняет выполнение базовых математических вычислений, которые могут быть полезны в простых сценариях, таких как расчет комиссий за транзакции в контракте.
Отсутствие прозрачности данных транзакций
На первый взгляд, я думаю, что большинство людей предполагают, что смарт-контракты Биткойна способны видеть суммы стоимости и любые другие части данных транзакций, поскольку эта информация уже публично доступна для просмотра в блокчейне. Но вопреки этому предположению, контракты на Биткойн не могут устанавливать условия расходов на основе данных транзакций, потому что Биткойн-скрипт вообще имеет очень ограниченную способность просматривать данные транзакций.
Если бы скрипт имел возможность интерпретировать больше деталей в данных транзакций, мы могли бы создавать гораздо более надежные контракты, которые могли бы делать все интересные вещи, такие как соблюдение определенных условий расходов, создание многоэтапных транзакций и активацию более продвинутых функций безопасности, таких как хранилища.
Что нам с этим делать?
Мы знаем, что у Биткойна есть эти ограничения, и на протяжении многих лет обсуждалось множество различных предложений по внедрению (или, в некоторых случаях, повторному введению) этой функциональности. Более широкие эксперименты с биткойн-скриптами, такие как Simplicity и другие, направлены на предоставление альтернативы ограничениям на основе стека. Такие коды операций, как OP_MULTISHA256, OP_LESS и OP_LE32TOLE64, направлены на улучшение арифметических способностей Биткойна. Такие предложения, как OP_CTV и OP_CAT, которые касаются кодов операций самоанализа, сгруппированы под термином «заветы».
Так в чем же именно разница между смарт-контрактами и новыми срочными соглашениями?
Смарт-контракты против ковенантов
Смарт-контракты — это самоисполняющиеся транзакции, которые передают средства без посредников. Сегодня в Биткойне смарт-контракты ограничиваются блокировкой и разблокировкой биткойнов с помощью биткойн-скрипта. Заветы направлены на улучшение функциональности смарт-контрактов Биткойна, позволяя пользователям контролировать, как их средства расходуются в будущих транзакциях.
Разрешая Script интерпретировать данные транзакции, мы эффективно создаем способ использования этих данных в логике контракта.
Это лишь некоторые из наиболее интересных опкодов самоанализа функциональности ковенантов:
OP_TXHASH: предоставляет хэш входных (или выходных) транзакций и дает скрипту возможность проверять и обеспечивать соблюдение условий на основе данных транзакции.
OP_CSFS + OP_CAT: вместе они позволяют сценариям проверять подписи по любым данным, а не только по самой транзакции. Это означает, что скрипт может проверять условия на основе данных транзакции или внешней информации, расширяя возможности проверки в скриптах Биткойн.
Эти два кода операций намеренно широкие, что обеспечивает сложные процессы проверки и возможности самоанализа. Другие имеют более узкую сферу применения и представляют собой более ограниченную форму заветов.
OP_CHECKTEMPLATEVERIFY (CTV): позволяет вставлять в выходные данные транзакции шаблон будущей транзакции расходов, обеспечивая более ограниченное выполнение ковенантов.
OP_VAULT: включает особую форму соглашения, используемую для «хранилища», которая позволяет пользователям указывать место назначения транзакции, но не перемещать монеты фактически, кроме как после задержки.
Кроме того, существует отдельный OP_CAT, который не является непосредственно опкодом самоанализа…
OP_CAT: позволяет сценарию объединять два элемента в стеке, что полезно для объединения различных фрагментов информации в сценарии.
У 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 в стеке для анализа предыдущих транзакций оказалось на самом деле проще, чем я ожидал». — Рейндал
При использовании хранилищ пользователи указывают следующий адрес, на который должны быть отправлены их средства, обеспечивая механизмы восстановления средств в случае компрометации ключа и уменьшая стимулы для кражи закрытого ключа.
Деревья Меркла для скрипта
Сегодня в Биткойне деревья Меркла — это структура данных, используемая для проверки данных, синхронизации и более или менее «связывания» транзакций и блоков блокчейна вместе. Код операции OP_CAT, который позволяет объединить две переменные стека при использовании вместе с хэшами открытых ключей SHA256, упрощает простой процесс проверки дерева Меркла для сценариев. Этот подход, первоначально предложенный Питером Вюйлем в 2015 году, был успешно реализован в сети Liquid.
Представьте себе древовидную структуру, наполненную различными условиями расходов, такими как прообразы хэшей, временные блокировки и открытые ключи, известные как древовидные подписи.
Подписи деревьев
OP_CAT позволяет создавать сигнатуры дерева, которые:
«…Предоставить сценарий мультиподписи, размер которого может быть логарифмическим по числу открытых ключей и который может кодировать условия расходов, выходящие за пределы n-из m. Например, транзакция размером менее 1 КБ может поддерживать древовидные подписи с тысячей открытых ключей. Это также обеспечивает обобщенные логические условия расходов». — Автор BIP Итан Хейлман, в списке рассылки bitcoin-dev
Это позволит проверять любой хешированный контент в дереве, обеспечивая целостность и надежность данных без увеличения объема или раздувания блокчейна.
Что во всем этом интересного?
Рекурсивные соглашения
Если у вас есть возможность проверять транзакцию и применять ограничения к определенным ее частям, вы можете настроить условия, которые будут распространяться на несколько транзакций, эффективно создавая цепочку постоянных ограничений. Эта концепция называется рекурсивным заветом. OP_CAT — уникальное предложение, поскольку оно дает нам столько возможностей всего за 10 новых строк кода. Он способен устранить все три первоначальных ограничения, о которых мы говорили в начале статьи: видимость данных транзакций, улучшенные математические функции и линейную модель выполнения.
Хотя на первый взгляд OP_CAT может показаться простым, при творческом использовании он раскрывает значительный потенциал. Он служит строительным блоком для еще большей функциональности, выходящей за рамки этого обсуждения, например, пост-квантовые подписи Лампорта.
Это безопасно?
До того, как OP_CAT был первоначально удален, при его сочетании с OP_DUP (дубликат) и повторном использовании для дублирования первоначально 1-байтового значения в стеке использование памяти могло резко возрасти. Это могло быть использовано как атака типа «отказ в обслуживании» (DoS) из-за повышенного потребления памяти. Новое предложение тривиально предотвращает эту атаку, налагая ограничение на элементы стека в 520 байт.
Есть ли опасность, что контракт будет действовать вечно?
Если под этим мы имеем в виду, меняет ли OP_CAT модель выполнения скрипта, означая, что он больше не ограничивает статически использование ресурсов (как линейную функцию размера скрипта)? Нет.
Смогут ли ковенанты создать рынок для других монет помимо Биткойна?
Да, если у вас есть рекурсивный завет, вы можете технически создавать сложные приложения уровня 2, включая NFT, децентрализованные биржи и квантовые коты. Однако сделать это не так просто. Трудно представить, чтобы какой-либо серьезный рынок сделал это.
Можно ли навсегда «испортить» монеты с помощью CAT?
В случае цветных монет и NFT, выпуская эти активы, пользователь фактически «сжигает» сатоши, отмечая его таким образом, что это означает владение активом «уровня 2». Этот процесс известен как «порча» монет. Но только владелец монеты может пометить свою монету, и биткойн-кошельки больше не будут ее распознавать (если только их авторы явно не добавят код, позволяющий это сделать). Полученные монеты не будут приниматься биткойн-кошельками. Вероятно, их будут принимать кошельки Cryptocat или что-то в этом роде, но для большинства пользователей биткойнов это не имеет значения.
Создаст ли это проблему MEV для Биткойна?
Ключевым моментом различия между Биткойном и Эфириумом является видимость транзакций. В отличие от 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.
Источник: Журнал Биткойн.
Пост OP_CAT: Идеальное решение для ковенантов? впервые появился в Crypto Breaking News.
