Ковенант

Каждый скрипт в блокчейне отвечает на один вопрос: разрешено ли это расходование? Ковенант позволил бы скрипту задать второй вопрос о транзакции, которая его расходует, и все предложения, которые это разрешают (BIP-119, BIP-118, BIP-345, BIP-347), годами остаются неактивированными. На то, что вы храните сегодня, это не влияет, но продукты для хранилищ и наследства, которые постоянно просят, ждут именно этого.

Как это работает

Статус: ни один опкод ковенанта не активен в основной сети Bitcoin. Каждый описанный ниже проект является предложением, и ни у одного из них нет параметров активации, включенных в Bitcoin Core.

У недостающей возможности есть точное название: интроспекция. Когда узел выполняет скрипт, скрипт может смотреть на подписи, хеши, блокировки по времени и стек, но он не может читать выходы транзакции, которая расходует монету. Именно из-за этого единственного слепого пятна биткоин может выразить «двое из этих трех человек должны договориться» и не может выразить «эти деньги могут уйти только на тот адрес».

Предложения закрывают этот пробел двумя разными способами, и разница между ними составляет суть спора.

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

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

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

Где это встречается

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

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

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

Ковенант vs эскроу-контракт

Ковенант ограничивает место назначения; эскроу-контракт ограничивает подписантов. Они решают разные половины одной и той же задачи, и доступна только одна из них.

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