Автор: Chakra Компилятор: 0xjs@金财经;

Эта статья является третьей частью серии статей о масштабируемости Биткойна, опубликованной Chakra.

Первую часть можно найти в предыдущей статье Golden Finance «Обзор собственного плана расширения Биткойна: SegWit и Taproot».

Вторую часть можно найти в предыдущей статье Golden Finance «Масштабируемость биткойнов: анализ решений уровня 2 и связанных проектов».

Третья часть представляет собой эту статью, а именно:

Обзор

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

Интроспекция относится к способности скриптов Биткойн проверять и ограничивать данные транзакций. Это позволяет сценариям контролировать использование средств на основе конкретных деталей транзакции, обеспечивая более сложную функциональность. В настоящее время большинство кодов операций Биткойна либо помещают в стек предоставленные пользователем данные, либо манипулируют существующими данными в стеке. Однако код операции интроспекции может помещать данные текущей транзакции (например, метку времени, сумму, txid и т. д.) в стек, обеспечивая более детальный контроль над расходами UTXO.

На данный момент только три основных кода операции поддерживают интроспекцию в Bitcoin Script: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY и CHECKSIG, а также их варианты CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG и CHECKMULTISIGVERIFY.

Ковенант (также переводится как «ограничения»), проще говоря, относится к ограничениям на способы перевода валюты, позволяя пользователям указывать метод распределения UTXO. Многие контракты реализуются посредством кодов операций интроспекции, и обсуждение интроспекции теперь перенесено в тему контрактов на биткойн-операции.

В настоящее время у Биткойна есть два контракта: CSV (CheckSequenceVerify) и CLTV (CheckLockTimeVerify). Оба контракта являются контрактами, основанными на времени, и являются основой многих решений по расширению (например, Lightning Network). Это показывает, что решение масштабирования Биткойна в значительной степени опирается на самоанализ и контракты.

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

Ниже мы описываем широко обсуждаемое предложение опкода Covenant.

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify) — это предложение по обновлению Биткойна в BIP-119, которое привлекло широкое внимание сообщества. CTV позволяет сценариям вывода указывать шаблоны для выплат средств в транзакциях, включая nVersion, nLockTime, хэш scriptSig, количество входов, хэш последовательности, количество выходов, выходной хеш, индекс ввода и другие поля. Эти ограничения шаблона реализуются посредством хеш-промисов, и при расходовании средств скрипт проверяет, соответствует ли хеш указанного поля в транзакции расходов хэшу во входном скрипте. Это эффективно ограничивает время, метод и количество будущих транзакций для этого UTXO.

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

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

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

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

CTV может значительно улучшить сети уровня 2. Например, в сети Lightning CTV может создавать деревья тайм-аутов и фабрики каналов, расширяя один UTXO в дерево CTV, позволяя открывать несколько каналов состояния с помощью всего лишь одной транзакции и одного подтверждения. Кроме того, CTV поддерживает атомарные транзакции в протоколе Ark через ATLC.

APO（SIGHASH_ANYPREVOUT）BIP-118

BIP-118 представляет новый подписанный хеш-флаг для Tapscript, предназначенный для обеспечения более гибкой логики расходов, который называется SIGHASH_ANYPREVOUT. APO и CTV имеют много общего. Подход APO к решению проблемы цикла между scriptPubKeys и TXID заключается в исключении соответствующей входной информации и подписании только выходных данных, что позволяет динамически привязывать транзакции к различным UTXO.

Логически операция проверки подписи OP_CHECKSIG (и ее варианты) выполняет три функции:

1. Соберите различные части расходной операции.

2. Хэшируйте их.

3. Убедитесь, что хеш подписан данным ключом.

Конкретные детали подписи отличаются большой гибкостью: флаг SIGHASH определяет, какие поля транзакции подписываются. Согласно определению кодов операций подписи в BIP 342, флаг SIGHASH делится на SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE и SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY управляет входом, а другие — выходом.

SIGHASH_ALL — это флаг SIGHASH по умолчанию, подписывающий весь вывод; SIGHASH_NONE не подписывает какой-либо вывод; SIGHASH_ANYONECANPAY можно установить вместе с первыми тремя флагами SIGHASH. Если установлен SIGHASH_ANYONECANPAY, подписывается только указанный ввод; в противном случае должны быть подписаны все вводимые данные.

Очевидно, что эти флаги SIGHASH не отменяют влияние ввода, даже SIGHASH_ANYONECANPAY, который требует подтверждения ввода.

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

Поскольку цикл между scriptPubKeys и входным TXID устранен, APO может выполнять самоанализ, добавляя выходные данные в Witness, хотя это по-прежнему требует дополнительного использования пространства Witness.

Для автономных протоколов, таких как Lightning Network и Vaults, APO снижает необходимость сохранять промежуточное состояние, что значительно снижает требования к хранилищу и упрощает его. Наиболее непосредственным вариантом использования APO является Eltoo, который повышает производительность сети Lightning во многих отношениях за счет упрощения фабрик каналов, создания легких и дешевых сторожевых вышек и обеспечения возможности одностороннего выхода без выхода из состояний ошибки. APO также можно использовать для эмуляции функций CTV, хотя для этого требуется, чтобы отдельные лица хранили подписанные и предварительно подписанные транзакции, что дороже и менее эффективно, чем CTV.

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

ОП_ВАУЛТ БИП-345

BIP-345 предлагает добавить два новых кода операций, OP_VAULT и OP_VAULT_RECOVER, которые в сочетании с CTV включают специализированные контракты, позволяющие пользователям принудительно отсрочить уплату определенной валюты. Во время этой задержки ранее совершенные транзакции могут быть «отменены» через путь восстановления.

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

OP_VAULT Как реализовать прерываемый вывод средств с блокировкой по времени? OP_VAULT делает это, заменяя используемый сценарий OP_VAULT указанным сценарием, эффективно обновляя один лист MAST, оставляя при этом остальные конечные узлы Taproot неизмененными. Эта конструкция аналогична TLUV, за исключением того, что OP_VAULT не поддерживает обновления внутренних ключей.

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

BIP-345 разработан специально для хранилищ и использует OP_VAULT и OP_VAULT_RECOVER, чтобы предоставить пользователям безопасный метод условного депонирования с использованием высокозащищенных ключей (таких как бумажные кошельки или распределенные мультиподписи) в качестве путей восстановления и одновременной настройки определенных задержек для повторяющихся платежей. Устройство пользователя постоянно отслеживает расходы хранилища, и в случае неожиданного перевода пользователь может инициировать восстановление.

Внедрение Vault через BIP-345 требует затрат, особенно при восстановлении транзакций. Возможные решения включают CPFP (ребенок платит за родителя), временные привязки и новый подписанный хеш-флаг SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

Решение TLUV построено на основе Taproot и направлено на эффективное решение общей проблемы выхода UTXO. Рекомендации заключаются в том, что при использовании выходных данных Taproot внутренние ключи и MAST (tripscript trie) могут быть частично обновлены посредством криптографических преобразований и внутренней структуры адреса Taproot, как описано в сценарии TLUV. Это делает возможной реализацию функционала Covenant.

Концепция схемы TLUV заключается в создании нового адреса Taproot на основе текущих входных данных о расходах путем введения нового кода операции TAPLEAF_UPDATE_VERIFY. Этого можно добиться, выполнив одно или несколько из следующих действий:

  • Обновить внутренний открытый ключ

  • Обрезать пути Меркла

  • Удалить текущий выполняющийся скрипт

  • Добавить новый шаг в конце пути Меркла

В частности, TLUV принимает три входа:

  • Указывает, как обновить внутренний открытый ключ.

  • Способ указать новый шаг для пути Меркла.

  • Указывает, следует ли удалить текущий скрипт и/или сколько шагов пути Меркла нужно обрезать.

Код операции TLUV вычисляет обновленный scriptPubKey и проверяет, расходуются ли выходные данные, соответствующие текущему входному, на этот scriptPubKey.

TLUV вдохновлен концепцией CoinPool. Сегодня федеративные пулы можно создавать с помощью только предварительно подписанных транзакций, но для достижения несанкционированного выхода необходимо создать экспоненциально большее количество подписей. TLUV, с другой стороны, позволяет выйти без разрешения и без какой-либо предварительной подписи. Например, группа партнеров может объединить свои средства с помощью Taproot для создания общих UTXO. Они могут использовать ключи Taproot для внутреннего перемещения средств или совместного подписания для инициирования платежей извне. Отдельные лица могут выйти из пула общих фондов в любое время, удалив свой путь оплаты, в то время как другие по-прежнему могут совершать платежи по исходному пути, а вывод отдельного лица не раскрывает другую информацию о других внутри. Эта модель более эффективна и конфиденциальна, чем транзакции без пула.

Код операции TLUV реализует частичные ограничения расходов путем обновления исходного дерева Taproot Trie, но не осуществляет самоанализ выходных сумм. Поэтому также требуется новый код операции IN_OUT_AMOUNT. Этот код операции помещает в стек два элемента: сумму UTXO этого ввода и сумму соответствующего вывода, а затем человеку, использующему TLUV, необходимо использовать математические операторы, чтобы убедиться, что средства правильно сохраняются в обновленном scriptPubKey.

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

TLUV потенциально может стать решением для децентрализованных пулов уровня 2, но его надежность при адаптации Taproot Trie все еще требует подтверждения.

МЭТТ

MATT (Merkleize All The Things) стремится достичь трех целей: мерклеизация состояния, мерклеизация сценария и мерклеизация исполнения, тем самым реализуя универсальные смарт-контракты.

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

  • Мерклейзинг сценария: это относится к использованию Tapscript для формирования MAST, где каждый листовой узел представляет собой возможный путь перехода состояния.

  • Мерклеизация производительности: Мерклеизация производительности посредством криптографических обязательств и механизмов борьбы с мошенничеством. Для любой вычислительной функции участники могут вычислить ее вне цепочки, а затем выдать обязательство f(x)=y. Если другие участники обнаружат неверный результат f(x)=z, они могут инициировать вызов. Арбитраж осуществляется посредством бинарного поиска, аналогично принципу оптимистического агрегирования.

Реализация Меркель

Для реализации MATT язык сценариев Биткойн должен обладать следующими возможностями:

  • Принудительный вывод для определенных сценариев (и их количества)

  • Добавить часть данных к выводу

  • Считать данные с текущего входа (или другого входа)

Второй момент имеет решающее значение: динамические данные означают, что состояние может быть рассчитано на основе входных данных, предоставленных потребителем, поскольку это позволяет моделировать конечный автомат, способный определять следующее состояние и дополнительные данные. Схема MATT достигает этого с помощью опкода OP_CHECKCONTRACTVERIFY (OP_CCV), который представляет собой объединение ранее предложенных опкодов OP_CHECKOUTPUTCONTRACTVERIFY и OP_CHECKINPUTCONTRACTVERIFY, используя дополнительный параметр-флаг для указания цели операции.

Управление выходной суммой. Самый простой метод — это непосредственный анализ, однако выходная сумма представляет собой 64-битное число и требует 64-битной арифметики, что усложняет сценарии Биткойна. OP_CCV использует метод отложенной проверки, такой как OP_VAULT, где входные суммы всех входов для одного и того же выхода в CCV складываются вместе в качестве нижней границы количества этого выхода. Задержка связана с тем, что эта проверка происходит во время транзакции, а не во время оценки входных данных сценарием.

Учитывая повсеместное распространение доказательств мошенничества, некоторые варианты контракта MATT должны иметь возможность реализовывать все типы смарт-контрактов или конструкций уровня 2, хотя дополнительные требования (такие как блокировка средств и задержки периода проверки) требуют точной оценки; необходимы дальнейшие исследования; необходимо оценить, какие приложения программа может принимать транзакции. Например, используйте механизмы криптографического подтверждения и борьбы с мошенничеством для эмуляции функции OP_ZK_VERIFY для реализации не требующих доверия накопительных пакетов в биткойнах.

На практике это уже произошло. Йохан Торос Халсет реализовал elftrace с использованием кода операции OP_CHECKCONTRACTVERIFY в предложении софт-форка MATT, который позволяет проверять любую программу, скомпилированную с поддержкой RISC-V, в блокчейне Биткойн, позволяя одной стороне контрактного соглашения пройти проверку контракта для доступа к средствам. объединение встроенной проверки Биткойна.

CSFS（OP_CHECKSIGFROMSTACK）

Из знакомства с кодом операции APO мы узнали, что OP_CHECKSIG (и связанные с ним операции) отвечают за сборку транзакций, хеш-вычисления и проверку подписей. Однако сообщения, проверенные этими операциями, сериализуются посредством транзакции кода операции и не позволяют указывать какие-либо другие сообщения. Проще говоря, роль OP_CHECKSIG (и связанных с ним операций) заключается в использовании механизма подписи для проверки того, разрешено ли использование UTXO, потраченного в качестве ввода транзакции, владельцем подписи, тем самым защищая безопасность Биткойна.

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

Гибкость CSFS позволяет реализовать такие механизмы, как платежные подписи, делегирование, контракты оракулов, гарантии защиты от двойных расходов и, что более важно, самоанализ транзакций. Принцип самоанализа транзакций с использованием CSFS очень прост: если содержимое транзакции, используемое OP_CHECKSIG, помещается в стек через свидетель, и OP_CSFS и OP_CHECKSIG проверяются с использованием одного и того же открытого ключа и подписи, и если обе проверки проходят успешно, то Содержимое любого сообщения для OP_CSFS такое же, как и сериализованная расходная транзакция (и другие данные), неявно используемые OP_CHECKSIG. Затем мы получаем проверенные данные транзакций в стеке, которые можно использовать для установления ограничений на расходные транзакции с использованием других кодов операций.

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

CSFS может реализовывать такие коды операций, как CLTV, CSV, CTV, APO и т. д., что делает его универсальным кодом операции самоанализа. Таким образом, он также способствует решениям масштабируемости второго уровня Биткойна. Недостатком является то, что требуется добавление полной копии подписанной транзакции в стек, что может значительно увеличить размер транзакций с помощью самоанализа CSFS. Специализированные коды операций интроспекции, такие как CLTV и CSV, по сравнению с ними имеют небольшие накладные расходы, но добавление каждого нового специального кода операции интроспекции требует согласованных изменений.

ТХХАШ (OP_TXHASH)

OP_TXHASH — это простой код операции самоанализа, который позволяет оператору выбрать хэш определенного поля и поместить его в стек. В частности, OP_TXHASH извлекает флаг txhash из стека, вычисляет (помеченный) txhash на основе этого флага, а затем помещает полученный хеш обратно в стек.

Из-за сходства между TXHASH и CTV в сообществе было много дискуссий по поводу этих двух типов.

TXHASH можно рассматривать как общее обновление CTV, которое предоставляет более продвинутые шаблоны транзакций и позволяет пользователям явно указывать различные части транзакции расходов, решая многие проблемы, связанные с комиссией за транзакцию. В отличие от других кодов операций Covenant, TXHASH не требует копирования необходимых данных в свидетеле, что еще больше снижает требования к хранилищу, в отличие от CTV, TXHASH не совместим с NOP и может быть реализован только в комбинации TXHASH и CSFS; в качестве альтернативы CTV и APO.

С точки зрения построения контрактов, TXHASH более удобен для создания «дополнительных контрактов», в которых все части данных транзакции, которые вы хотите исправить, помещаются в стек, хешируются вместе и проверяются, что полученный хэш соответствует фиксированному значению. Match;CTV лучше подходит для создания «вычитающих контрактов», где все части данных транзакции, которые вы хотите сохранить свободными, помещаются в стек. Затем, используя повторяющиеся коды операций SHA256, обработка хеширования начинается с фиксированного промежуточного состояния, которое фиксируется в префиксе хэш-данных транзакции. Свободная часть хешируется до этого промежуточного состояния.

Ожидается, что поле TxFieldSelector, определенное в спецификации TXHASH, будет расширено на другие коды операций, такие как OP_TX.

BIP, связанный с TXHASH, в настоящее время находится в статусе черновика на GitHub, и ему еще не присвоен номер.

ОП_КАТ

OP_CAT — это загадочный код операции, который изначально был оставлен Сатоши Накамото по соображениям безопасности, но недавно вызвал бурные дискуссии среди разработчиков Bitcoin Core и даже породил культуру мемов в Интернете. В конечном итоге OP_CAT был одобрен в соответствии с BIP-347 и назван предложением BIP, которое, скорее всего, будет принято в ближайшем будущем.

На самом деле поведение OP_CAT очень простое: он объединяет два элемента из стека. Как он реализует функциональность Ковенанта?

Фактически, способность соединять два элемента соответствует мощной криптографической структуре данных: Три Меркла. Для построения Merkle Trie требуются только конкатенация и хеширование, а функция хеширования предусмотрена в Bitcoin Script. Таким образом, используя OP_CAT, мы теоретически можем проверить доказательства Меркла в сценарии Биткойн, который является одним из наиболее распространенных облегченных методов проверки в технологии блокчейна.

Как упоминалось ранее, CSFS может реализовать общее решение Covenant с помощью OP_CAT. Фактически, сам OP_CAT может обеспечить самоанализ транзакций даже без CSFS, используя структуру подписей Шнорра.

В подписях Шнорра сообщение, которое необходимо подписать, состоит из следующих полей:

Эти поля содержат основные элементы транзакции. Поместив их в scriptPubKey или Witness и используя OP_CAT в сочетании с OP_SHA256, мы можем создать подпись Шнорра и проверить ее с помощью OP_CHECKSIG. Если проверка пройдена, стек сохраняет проверенные данные транзакции, позволяя провести самоанализ транзакции. Это позволяет нам извлекать и «исследовать» различные части транзакции, такие как ее входы, выходы, адрес назначения или количество задействованных биткойнов.

Конкретные принципы криптографии можно найти в статье Эндрю Поэльстры «CAT и трюки Шнорра».

В целом, универсальность OP_CAT позволяет ему моделировать практически любой код операции Covenant. Многие коды операций Covenant полагаются на функциональность OP_CAT, что значительно повышает его позицию в списке слияния. Теоретически, полагаясь исключительно на OP_CAT и существующие коды операций Биткойна, мы могли бы надеяться создать накопительный пакет BTC ZK с минимальным доверием. Starknet, Chakra и другие партнеры по экосистеме активно продвигают эту цель.

в заключение

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

Без гибкого базового слоя невозможно построить более гибкий второй слой.

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

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

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

APO, OP_VAULT и TLUV предпочитают прямое применение. Выбор этих трех методов позволяет реализовать конкретные приложения дешевле и эффективнее. Энтузиасты Lightning Network выберут APO для реализации LN-Symmetry; пользователям, желающим внедрить Vault, лучше всего использовать OP_VAULT, а для создания CoinPool TLUV может обеспечить лучшую конфиденциальность и эффективность; OP_CAT и TXHASH более многофункциональны, с меньшей вероятностью имеют уязвимости безопасности и могут быть объединены с другими кодами операций для достижения большего количества вариантов использования, но ценой может стать увеличение сложности сценария. CTV и CSFS настраивают метод обработки блокчейна, CTV реализует отложенный вывод, а CSFS реализует отложенную подпись. MATT выделяется своим оптимистичным исполнением и стратегиями защиты от мошенничества, используя структуру Меркла Три для реализации смарт-контрактов общего назначения, но функция самоанализа по-прежнему требует новых кодов операций.

Мы видим, что биткойн-сообщество активно обсуждает возможность приобретения ковенантов посредством софт-форка. Starknet официально объявил, что присоединится к экосистеме Биткойн и планирует реализовать расчеты в сети Биткойн в течение шести месяцев после слияния OP_CAT. Chakra продолжит обращать внимание на последние события в экосистеме Биткойн, продвигать слияние софт-форка OP_CAT и использовать возможности программирования, предоставляемые Ковенантами, для создания более безопасного и эффективного уровня расчетов Биткойн.