Это часть 5 серии технических статей Cointelegraph Research о ковенантах в Биткоине. Чтобы прочитать предыдущую статью, нажмите здесь. 

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

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

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

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

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

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

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

<data> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFY

Опкод поддерживает три режима проверки выхода и отдельный режим для входа. В режиме по умолчанию вся сумма BTC входного UTXO направляется в указанный выход; в режиме вычета (deduct) в выход направляется только сумма, равная его номиналу, а остаток остаётся доступным для других выходов; в режиме игнорирования (ignore) проверяются скрипт и обязательство по данным, но сумма не ограничивается. Поскольку режимы по умолчанию и вычета предназначены для сохранения суммы в проверяемых выходах, комиссии транзакции нужно оплачивать отдельными входами. В транзакцию можно добавить специальный вход для оплаты комиссии и выход сдачи, не нарушая ограничений ковенанта. Это предотвращает случайное сжигание средств, возможное при более примитивных реализациях ковенантов, таких как OP_CTV или SIGHASH_ANYPREVOUT. Решается и важное ограничение ковенантов на основе заранее подписанных транзакций: они обычно заранее задают суммы, поэтому не позволяют динамически корректировать комиссии или выполнять частичное раскрытие хранилища (unvault).

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

Сочетание OP_CCV и OP_CAT делает возможности всей системы MATT ещё шире. OP_CAT позволяет объединять байты в Script, благодаря чему можно непосредственно в блокчейне строить и проверять доказательства Меркла. В такой схеме с выходом 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. Каждый из этих опкодов предназначен для решения конкретной проблемы, а не для обеспечения широкой программируемости.

Журнал: владельцы биткоина получили eCash — что с ним можно делать?