Обзор MATT и OP_CCV в биткоине для смарт-контрактов

Это пятая часть цикла технических статей о ковенантах биткоина от Cointelegraph Research. Предыдущий материал доступен по ссылке.

MATT (Merkleize All The Things) представляет собой фреймворк смарт-контрактов для биткоина, который поддерживает сохранение состояния и масштабируемые доказательства мошенничества. Контракт с поддержкой состояния передает данные между транзакциями и обновляет их по мере своего выполнения. Стандартные скрипты биткоина не имеют такой возможности, так как каждая транзакция проверяется изолированно и не хранит историю предыдущих вычислений.

Любое предложение по ковенантам в определенной степени допускает использование UTXO с состояниями, что видно на примере таких языков скриптинга, как Sapio на базе OP_CTV. Здесь адреса имитируют конечный автомат, где транзакции выступают в роли переходов между состояниями. Однако в этой модели сложно реализовать полноценную числовую логику. Эту проблему как раз и решает концепция MATT, в частности через предложенный опкод OP_CCV. Поскольку MATT позволяет вычислять зафиксированные данные в момент траты и повторно внедрять их в следующий выход, каждая транзакция расходования может динамически порождать новое состояние вместо выбора из заранее заготовленного набора.

Как OP_CCV фиксирует состояние в ключе Taproot

Для понимания концепции MATT полезно вспомнить, каким образом Taproot привязывает данные к публичным ключам. Каждый выход Taproot содержит базовый публичный ключ (внутренний ключ), который можно криптографически модифицировать или изменять для фиксации дополнительной информации. Формально измененный публичный ключ выглядит как Q = P + t·G, где P — внутренний ключ, G — генератор эллиптической кривой secp256k1, а t — хеш с тегом от P и зафиксированных данных.

В стандартном выходе Taproot эта привязка обычно содержит корень Меркла для дерева скриптов (taptree), скрывающего пути трат. MATT развивает этот механизм, позволяя встраивать в ключ еще и состояние контракта. Вместо того чтобы прописывать сложную логику напрямую в языке скриптов биткоина, MATT кодирует вычисления как цепочку фиксаций состояния, а блокчейн проверяет лишь корректность каждого такого перехода.

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

Затем OP_CCV может контролировать, какое именно состояние переносится в следующий выход. Он дает возможность скрипту считывать данные состояния из стека свидетелей, производить над ними вычисления и требовать, чтобы полученное обновленное состояние было корректно зафиксировано в определенном выходе. Именно так обеспечивается принудительное выполнение смены состояний в блокчейне. Формат стека выглядит следующим образом:

data index pk taptree mode OP_CHECKCONTRACTVERIFY

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

OP_CCV и OP_CAT: доказательства Меркла и доказательства мошенничества

В сочетании с OP_CAT возможности фреймворка MATT становятся еще шире. OP_CAT позволяет объединять байты в скриптах, что дает возможность создавать и проверять доказательства Меркла непосредственно в блокчейне. В такой схеме с выходом Taproot связаны два разных дерева Меркла. Первое — это привычное дерево скриптов Taproot (taptree), листья которого представляют собой условия траты контракта. Второе — отдельное дерево состояний, листья которого содержат данные контракта, например промежуточные шаги вычислений. Связка OP_CCV и OP_CAT способна проверить доказательство Меркла для текущего корня дерева состояний, вычислить обновленный корень после перехода и заставить следующий выход зафиксировать его через OP_CCV.

Подобная архитектура позволяет строить системы доказательств мошенничества с условиями штрафа, когда масштабные вычисления выполняются вне блокчейна, а в сети проверяется и раскрывается лишь конкретный спорный шаг вместе с его путем в бинарном дереве. Похожие решения применяются в виде оптимистичных роллапов в других блокчейнах: основные вычисления идут оффчейн, а смарт-контракт вмешивается только при появлении претензий. Доказательства мошенничества требуют компиляции вычислений в бинарную схему или аналогичное пошаговое представление, которое можно зафиксировать в дереве Меркла. Связка OP_CCV и OP_CAT позволяет обойтись без одноразовых подписей Лампорта и графов заранее подписанных транзакций, на которые опирается BitVM.

Помимо доказательств мошенничества, комбинация OP_CCV и OP_CAT открывает новые возможности для хранилищ (vaults). Сам по себе OP_CCV позволяет создавать хранилища, но в паре с OP_CAT он обеспечивает полноценный функционал, по сути эквивалентный возможностям OP_VAULT. Как отмечал автор OP_VAULT Джеймс О’Берн, OP_CCV предлагает более универсальное и надежное решение, которое фактически превосходит его раннюю разработку.

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