Святой Грааль сети второго уровня Биткойна: Интроспекция и заветы

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

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

В настоящее время в криптовалютах Биткойна существует только три основных опкода, поддерживающих интроспекцию: 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 TXID зависит от значения scriptPubKey при использовании типа подписи SIGHASH_ALL по умолчанию. Включение TXID создало бы круговую зависимость, что сделало бы невозможным построение хэш-обязательства.

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

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

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

CTV может значительно улучшить сети второго уровня. Например, в сети Lightning Network реализация Timeout Trees и Channel Factories с использованием CTV позволяет одному UTXO разрастаться в дерево CTV, открывая множество каналов состояния только с одной транзакцией и подтверждением на цепи. Кроме того, CTV поддерживает атомарные транзакции (ATLC) в протоколе Ark.

APO (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_SINGLE подписывает только указанный выход. SIGHASH_ANYONECANPAY может быть установлен вместе с тремя другими флагами, и если он установлен, то подписывает только указанный вход; в противном случае все входы должны быть подписаны.

Ни один из этих флагов SIGHASH не может устранить влияние входов. Даже SIGHASH_ANYONECANPAY требует обязательства по одному вводу.

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

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

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

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

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

OP_VAULT BIP-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, а шаблон, привносимый опкодом CTV, ограничивает набор выходов, проходящих по данному пути сценария.

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

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

TLUV (TapleafUpdateVerify)

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

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

• Обновление внутреннего открытого ключа
• Обрезать путь Меркла
• Удалить текущий выполняющийся листовой узел
• Добавьте новый листовой узел в конец пути Меркла

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

1. Спецификация того, как обновлять внутренний открытый ключ
2. Новый листовой узел для пути Меркла
3. Указание на то, следует ли удалить текущий листовой узел и/или сколько листовых узлов пути Меркла следует удалить

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

Вдохновением для создания TLUV послужили пулы монет. Сегодня совместные пулы можно создавать с помощью предварительно подписанных транзакций, но если вы хотите добиться безразрешительных выходов, вам нужно создавать экспоненциально растущее число подписей. 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, где каждый листовой узел является возможным путем перехода из одного состояния в другое.
• Выполнение мерклизинга: Достигается с помощью криптографических обязательств и механизмов вызова мошенников. Для любой вычислительной функции участники могут вычислять вне цепи и публиковать обязательства, f(x)=y. Если другие участники находят результат f(x)=z, они могут оспорить его, и арбитраж осуществляется с помощью двоичного поиска, аналогичного принципу оптимистического свертывания.

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

1. Выполнение определенного сценария на выходе (и их количество)
2. Прикрепление данных к выходу
3. Считывание данных с текущего входа (или других входов)

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

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

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

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

CSFS (OP_CHECKSIGFROMSTACK)

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

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

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

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

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

TXHASH (OP_TXHASH)

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

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

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

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

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

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

OP_CAT

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

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

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

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

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

• Версия
• Locktime
• Количество входов
• Количество выходов
• Список входов (каждый из которых включает хэш предыдущей транзакции, индекс, длину сценария, сценарий, последовательность)
• Список выходов (каждый из них включает значение, длину сценария, сценарий)

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

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

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

Заключение

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

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

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

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

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

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

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