Ковенанты, OP_CAT и OP_CTV: ключевые аспекты предстоящего обновления Биткоина

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

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

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

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

Для сравнения, Ethereum более масштабируем, чем Биткоин, но размер его блокчейна увеличивается очень быстро, что со временем приводит к централизации его сети. Точно так же сеть Kaspa более масштабируема, чем Биткоин, имеет потенциал стать более децентрализованной, но снижает безопасность из-за использования «обрезанных» узлов.

Чтобы сделать Биткоин быстрее, было придумано множество типов инфраструктуры:

• Сайдчейны – альтернативные цепочки, которые тесно взаимодействуют с Биткойном, но при этом не зависят от него и не получают выгоды от его безопасности, такие как блокчейн Liquid (L-BTC) или Stacks (STX);
• Уровень 2 – инфраструктуры, которые выполняют вычисления вне основной сети, чтобы, в конечном итоге, зарегистрировать только след, такие как BitVM и RGB, которые всё ещё находятся в стадии разработки ;
• Lightning Network – сеть каналов ликвидности, обеспечивающая практически мгновенные и недорогие переводы BTC.

Среди всех рассматриваемых решений есть также модификации самого блокчейна Биткоина, такие как обновления Segwit, проведенные в 2017 году, и Taproot, реализуемые с 2021 года.

В последнее время тема «ковенантов» становится всё более заметной, вызывая многочисленные дебаты вокруг потенциального обновления и нового софт-форка Биткойна.

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

Как работает Script, язык программирования Биткоина

Механизм перевода BTC в Биткоины сильно отличается от того, который используется в блокчейнах с использованием виртуальной машины Ethereum (EVM).

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

Таким образом, единицы BTC, которые мы имеем в нашем биткоин-кошельке, фактически хранятся в форме неизрасходованных выходов, называемых на английском языке «Unspent Transaction Output», часто сокращенно «UTXO».

Эти UTXO работают как купюра или монета, но в цифровом виде. Например, если вы получите 1 биткойн, то у вас будет 1 UTXO стоимостью 1 BTC. После траты ваш UTXO в 1 BTC используется в качестве входа в транзакцию и взамен создаёт новый UTXO в 1 BTC в кошельке, который получает средства.

Прежде чем идти дальше, важно понимать, что для того, чтобы UTXO были потрачены, их необходимо разблокировать, а затем заблокировать с помощью специфичного для Биткоина языка, называемого «Script».

Язык программирования Script – это буквально сценарий, определяющий условия расходования UTXO. И именно эти скрипты выполняются при проверке узлами сети валидности транзакции.

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

Хотя Solidity часто представляют как полный по Тьюрингу, на самом деле это не так. Исполнение смарт-контракта на Ethereum, в первую очередь, зависит от наличия комиссий за газ для оплаты транзакций. Без средств для покрытия этих затрат ни Ethereum, ни Solidity не могут считаться Тьюринг-полными.

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

Хотя он воспринимается как ограниченный по сравнению с другими языками, на самом деле Script очень богат и имеет более сотни кодов операций, таких как OP_RETURN, OP_2DUP, OP_SWAP, OP_ADD и т.д.

Кроме того, коды операций языка Script позволяют создавать множество вещей для Биткоина, например, OP_CHECKMULTISIG, который позволяет адресам управляться несколькими закрытыми ключами, OP_CHECKSEQUENCEVERIFY, который накладывает относительное ограничение по времени, временную блокировку, в частности, позволяющую создавать Lightning Network и фидуциарные депозиты (эскроу).

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

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

Некоторые коды операций даже позволят создавать «ковенанты» – механизмы, которые налагают более конкретные условия расходования UTXO.

Будущее Биткоина в ковенантах

Что такое ковенанты

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

В случае с Биткоином ковенант – это механизм, который накладывает определенные условия на scriptPubKey, используемый для блокировки UTXO в последующей транзакции, причём эти условия конкретно определяются в scriptPubKey исходной транзакции.

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

Существуют различные виды ковенантов:

• Ковенанты хеширования транзакций. Этот тип ковенантов позволяет обуславливать выпуск UTXO на основе действительности конкретного хэша, присутствующего в исходной транзакции. Это означает, что BTC можно потратить только в том случае, если хэш проводящей транзакции соответствует хэшу, установленному в исходной транзакции. Ковенанты хеширования транзакций будут гарантировать, что конкретная транзакция была создана или подписана определенным образом, прежде чем разрешить разблокировку BTC;
• Ковенанты интроспекции транзакции. Этот тип ковенанта позволяет проверять определенные внутренние свойства транзакции, такие как входы, выходы или даже переведенные суммы, прежде чем разрешить расходование UTXO. В отличие от ковенантов хеширования транзакций, они обеспечивают контроль над компонентами самой транзакции. Ковенант о самоанализе транзакций позволят устанавливать более сложные условия расходования средств, которые могут применяться, например, к комиссиям за транзакции или выходам;
• Ковенанты трансформации скриптов. Этот тип ковенантов изменяет или налагает условия на сценарий для разблокировки следующих UTXO. Это позволяет преобразовать сценарий в последующую транзакцию, тем самым определяя не только то, кто может потратить BTC, но и то, как они могут быть потрачены в будущем. Ковенанты трансформации сценария позволят создавать цепочки условий для нескольких транзакций, где каждая транзакция может изменить правила следующей;
• Отложенные ковенанты. Этот тип ковенантов накладывает ограничение, которое не применяется немедленно, но будет применяться в будущей сделке. Они позволяют валидатору просмотреть весь скрипт, а не начинать шаг за шагом с вершины стека. Этот тип ковенантов позволяет отложить применение условия до определенного времени, вероятно, по причинам конфиденциальности или сложности. Отложенные ковенанты позволят обуславливать доступ к BTC на основе будущих событий или критериев, сохраняя условия скрытыми или отложенными до тех пор, пока они не понадобятся.

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

Что ковенанты приносят Биткоину

Ковенанты могут внести множество улучшений в Биткоин и проложить путь для разработки новых приложений, таких как:

• Создание передовых механизмов для защиты BTC;
• Улучшенная производительность Lightning Network благодаря внедрению Eltoo;
• Разработка новых инфраструктур уровня 2, таких как Ark или накопительные пакеты;
• Создание платёжных пулов (структур, похожих на миксеры) для усиления конфиденциальности;
• Прямая интеграция протоколов в основную цепочку, позволяющая использовать приложения, сравнимые с приложениями Ethereum на Биткоине;
• Улучшение контрактов дискретной записи (DLC), в частности, облегчающее создание производных рынков на биткоинах;
• Создание более децентрализованных майнинговых пулов.

Какие риски несут в себе ковенанты

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

Это происходит главным образом из-за рекурсивного характера некоторых ковенантов.

Рекурсивный ковенант – это тип смарт-контракта, который накладывает правила не только на исходный scriptPubKey, но и на все последующие. Если ковенант не применяется ко всем или только к некоторым последующим scriptPubKey, он не считается рекурсивным.

Другими словами, рекурсивный ковенант – это смарт-контракт, который накладывает условия расходования на UTXO, а также на все последующие транзакции, создавая цепочку, в которой каждая транзакция подчиняется правилам, установленным в исходной транзакции.

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

Такие ограничения могут быть установлены различными способами: по ошибке при создании смарт-контракта, путём ограничения, если строгие правила не позволяют расходовать BTC от регулируемых компаний на адреса, занесенные в чёрный список, или путём сознательного выбора пользователя.

Например, запрет расходования биткоинов на адреса, занесенные в чёрный список, как только они, например, покидают обменные платформы, уже возможен посредством строгого регулирования с созданием мультиподписи, где регулируемая платформа будет хранить хотя бы один ключ мультиподписи 2/2, и будет запрещено подтверждать транзакцию по переводу BTC на адрес, который не соответствует правилам.

Подобно тем, кто принял иерархию сатоши из теории ординалов (которой не существует в самой сети Биткоин), эти пользователи могут создать ковенанты «Ординал», делающее невозможным смешивание редких сатоши с другими.

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

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

Среди множества рассмотренных кодов операций два особенно выделяются своей простотой и техническими возможностями: OP_CAT и OP_CHECKTEMPLATEVERIFY.

OP_CAT: универсальный опкод

OP_CAT – это код операции, который может позволить Script, языку программирования Биткоин, стать намного более гибким и открыть путь для многих новых вариантов использования.

Технически OP_CAT предназначен для объединения 2-х элементов, расположенных вверху стека скриптов. Конкатенация заключается в сборке 2 фрагментов данных путем их соединения встык, образуя таким образом единую последовательность данных вместо 2 отдельных, что снижает сложность скрипта.

Хотя эта операция кажется простой, она значительно увеличивает выразительность языка сценариев, позволяя создавать более сложные структуры данных непосредственно в транзакциях Биткоин.

Например, он позволил бы выполнять такие операции, как умножение (3×4), которые, в противном случае, потребовали бы серии последовательных сложений (3+3+3+3) без OP_CAT.

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

Например, это может позволить:

• создание Хранилищ: систем, повышающих безопасность BTC;
• создание смарт-контрактов: полных по Тьюрингу, как на Ethereum;
• внедрение Eltoo для улучшения сети Lightning;
• создание Ark: второго уровня Биткоина, предназначенного для передачи BTC;
• оптимизация BitVM: вычислительная парадигма, позволяющая создавать накопительные пакеты;
• или даже создание многочисленных слоев 2, действительно извлекающих выгоду из безопасности Биткоина.

OP_CAT изначально был частью сценария Биткоина при его создании, но был быстро деактивирован в 2010 году самим Сатоши Накамото . Основной причиной удаления был риск распространения спама в сети, который мог поставить под угрозу её безопасность.

Это связано с тем, что OP_CAT не имел ограничения на размер, что потенциально могло перегрузить узлы из-за перегрузки мемпула и экспоненциального увеличения размера блокчейна. Ethereum пытался решить аналогичную проблему с помощью своего языка Solidity, но без особого успеха. Внедрение Ethereum теперь зависит от его уровня 2.

Так зачем же снова вводить OP_CAT в язык Script, если это рискует перегрузить узлы Биткойна и снизить его децентрализацию в долгосрочной перспективе?

Всё просто потому, что появление Tapscript в 2021 году во время обновления Taproot помогло смягчить этот риск, наложив ограничение в 520 байт на размер элементов стека. Таким образом, OP_CAT можно реинтегрировать в язык Script без ущерба для децентрализации Биткоина.

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

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

Хотя этот код операции потенциально может изменить способ написания и использования скриптов, он представляет значительные риски для Биткоина, которые необходимо тщательно оценить. Тем не менее, некоторые разработчики биткоина считают, что эти риски переоценены.

Если OP_CAT будет повторно введен, это можно будет сделать в течение 1-5 лет после обширных обсуждений, тщательного тестирования и голосования сообщества.

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

OP_CHECKTEMPLATEVERIFY (OP_CTV): простой, но ограниченный код операции

OP_CHECKTEMPLATEVERIFY, также называемый «OP_CTV», – это код операции, предложенный Джереми Рубином в 2019 году как часть BIP 119. Этот код операции позволяет создавать ковенанты на основе хэша транзакции, вводя в Биткоин нерекурсивные ковенанты, способные заранее определить точный способ, которым должна быть построена следующая транзакция.

Идея OP_CTV родилась из необходимости создания более безопасных и эффективных транзакций для Биткоин, включая такие приложения, как хранилища, платёжные каналы Lightning Network, контроль перегрузки транзакций, а также улучшение DLC и создание уровня 2 Ark.

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

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

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

Код OP_CHECKTEMPLATEVERIFY прост по сравнению с OP_CAT и готов уже несколько лет.

Вот основные различия между OP_CTV и OP_CAT:

• Гибкость: OP_CTV менее гибок, но более предсказуем, чем OP_CAT, что снижает риск ошибок при его использовании;
• Потенциальные приложения: OP_CTV идеально подходит для разработки нескольких приложений, но OP_CAT позволяет создавать более сложные приложения, в частности, путём создания сложных сценариев и сценариев уровня 2, таких как накопительные пакеты;
• Риски перегрузки: OP_CTV был разработан для минимизации воздействия на сеть Биткоин, оставаясь ограниченным в её функциях, в то время как OP_CAT требует дополнительных мер предосторожности, чтобы избежать перегрузки сети;
• Принятие и реализация: OP_CTV пользуется значительной поддержкой со стороны биткоин-сообщества, что позволяет потенциально ускорить внедрение благодаря его простоте;
• Будущая эволюция: OP_CTV может удовлетворить большинство текущих потребностей разработчиков биткоинов без чрезмерного усложнения системы, тогда как OP_CAT предложит больший потенциал для эволюции.

OP_CTV по-прежнему имеет существенное ограничение, отмеченное Питером Тоддом несколько месяцев назад. Он отмечает, что реализация CheckTemplateVerify (CTV) не решает проблемы масштабируемости Биткоина, поскольку требует от каждого пользователя иметь UTXO для оплаты комиссий, что сводит на нет преимущества совместного использования UTXO.

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

С другой стороны, тот факт, что OP_CHECKTEMPLATEVERIFY не является рекурсивным, даёт ему значительный потенциал внедрения по сравнению с OP_CAT. Как объяснялось ранее, рекурсия позволит вредоносным объектам или ошибкам разработки влиять на взаимозаменяемость BTC, потенциально даже выступая в качестве цензуры.

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

Гибкость и меньшее влияние на блокчейн Биткоина даёт OP_CTV значительное преимущество в дебатах внутри сообщества. Однако помните, что эти два кода операции можно добавить в Script одновременно.

Другие коды операций, позволяющие заключать соглашения с Биткоином

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

Вот краткое описание предложений, которым больше всего внимания уделяет биткоин-сообщество.

Опкод ANYPREVOUT (APO)

SIGHASH_ANYPREVOUT (APO), предложенный в BIP-118, представляет собой обновление концепции SIGHASH_NOINPUT, которое позволяет подписывать транзакцию без ссылки на конкретный UTXO в качестве входных данных. Такая гибкость позволяет впоследствии финансировать заранее подписанную транзакцию с помощью различных UTXO, при условии, что сценарии совместимы.

APO особенно полезен для таких приложений, как Eltoo, который улучшает управление каналами Lightning Network, а также может использоваться для таких механизмов, как Statechains и Spacechains. Однако, APO создаёт проблемы безопасности и сложности, требующие тщательного управления во время его реализации.

Опкод OP_VAULT

OP_VAULT – это предложение, которое вводит два новых кода операции в Tapscript: OP_VAULT и OP_VAULT_RECOVER, указанные в BIP-345.

Эти коды операций в сочетании с OP_CHECKTEMPLATEVERIFY (CTV) позволяют установить задержку, прежде чем BTC можно будет потратить в произвольное место назначения, если только они не отправлены по заранее указанному пути восстановления.

До окончательного расходования BTC всё ещё можно направить по этому пути восстановления. OP_VAULT направлен на усиление безопасности BTC, обеспечивая дополнительную защиту от кражи, позволяя пользователю вмешаться в случае попытки кражи.

Опкоды TXHASH и CHECKSIGFROMSTACKVERIFY

Опкоды TXHASH и CHECKSIGFROMSTACKVERIFY предложены для декомпозиции и воспроизведения функциональности CTV и ANYPREVOUT более гибким и модульным способом, короче говоря, вместе они могут заменить все остальные предложения ковенантов.

Точнее, TXHASH позволяет генерировать хэши транзакций на основе определенных параметров, а CHECKSIGFROMSTACKVERIFY проверяет подписи на основе этих хэшей.

Хотя ANYPREVOUT может имитировать CTV, это требует более высоких затрат. TXHASH и CHECKSIGFROMSTACKVERIFY предоставляют альтернативу для создания ковенантов и других приложений с более простым и адаптируемым набором кодов операций, хотя они и занимают больше места.

Когда ковенанты появятся в Биткоине

Разработчики и биткоин-сообщество известны тем, что на внедрение обновлений уходит несколько лет. За свою историю Биткоин претерпел только два крупных обновления: SegWit и Taproot, в отличие от других блокчейнов, которые разрабатывают правила консенсуса более регулярно.

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

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