Автор: Chakra Research

Обзор

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

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

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

Проще говоря, контракт — это ограничение на способ передачи токенов. Пользователи могут указать метод распределения UTXO через контракт. Многие контракты реализуются посредством кодов операций интроспекции, и интроспекция теперь обсуждается в разделе «Записи контрактов» в Bitcoin Optech.

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

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

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

CTV (CheckTemplateVerify) BIP-119

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

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

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

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

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

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

АПО (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 предлагает новый тип подписанного хэш-флага для Tapscript, чтобы облегчить написание более гибкой логики расходов, называемый SIGHASH_ANYPREVOUT. APO и CTV во многих аспектах схожи. Столкнувшись с проблемой зацикливания между scriptPubKeys и TXID, решение APO состоит в том, чтобы исключить входную информацию и подписать только выходные данные, чтобы транзакции можно было динамически привязывать к различным 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). Конечно, это все равно требует дополнительного потребления пространства данных свидетеля.

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

Основная критика APO заключается в том, что для него требуется новая версия ключа, чего невозможно добиться за счет чистой обратной совместимости. Кроме того, новые типы хэш-подписей могут привести к потенциальным рискам двойных расходов. После обширного обсуждения в сообществе 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, оставляя остальные листовые узлы без изменений. Дизайн аналогичен TLUV, за исключением того, что OP_VAULT не поддерживает внутренние обновления ключей.

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

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

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

TLUV (TapleafUpdateVerify)

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

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

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

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

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

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

В частности, TLUV получает три входных сигнала:

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

  • Один указывает новый листовой узел для пути Меркла.

  • Один указывает, следует ли удалить текущий листовой узел и/или сколько конечных узлов пути Меркла удалить.

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

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

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

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

Ожидается, что TLUV предоставит решение для децентрализованных пулов фондов второго уровня. Конечно, надежность настроек открытого ключа Taproot еще не подтверждена.

МЭТТ

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

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

Сценарий Меркла: то есть MAST, состоящий из Tapscript. Каждый листовой узел представляет собой возможный путь перехода состояния.

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

Проблемы мошенничества с помощью Merkle

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

  1. Заставить вывод иметь определенные сценарии (и их количество)

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

  3. Чтение данных с текущего входа (или другого входа)

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

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

Учитывая универсальность защиты от мошенничества, некоторые варианты контракта MATT должны включать все типы смарт-контрактов или сборок второго уровня, хотя дополнительные требования (такие как блокировка капитала и задержки периода проверки) должны быть точно оценены, необходимы дальнейшие исследования; чтобы оценить, какое Приложение является приемлемой транзакцией. Например, механизм криптографического подтверждения и проверки мошенничества используется для имитации функции 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, помещается в стек через свидетель, для проверки содержимого как с CSFS, так и с OP_CHECKSIG используются один и тот же открытый ключ и подпись, если оба проходят успешно. , то содержимое любого сообщения, передаваемого в CSFS, совпадает с сериализованной транзакцией расходов (и другими данными), неявно используемой для OP_CHECKSIG. Мы проверили данные транзакции в стеке и можем применить другие коды операций к лимиту транзакции.

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

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

ТХХАШ (OP_TXHASH)

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

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

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

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

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

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

ОП_КАТ

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

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

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

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

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

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

Конкретные принципы криптографии можно найти в статье CAT and Schnorr Tricks, опубликованной Эндрю Поэльстра.

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

Заключение

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

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

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

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

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

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

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

Спасибо Джеффри, Бену, Мутуренду и Линделлу за обзор и предложения по этой статье.