Короткий ответ: covenant в Bitcoin – идея ограничить не только то, кто может потратить UTXO, но и то, каким должно быть последующее расходование. Это может быть шаблон транзакции, назначение выходов, задержка или сохранение состояния в новых UTXO. Под одним термином объединяют разные конструкции и предложения. На 2 октября 2026 года BIP-119 для OP_CHECKTEMPLATEVERIFY и BIP-443 для OP_CHECKCONTRACTVERIFY имеют статус Draft. Черновик не означает, что эти правила уже активны в консенсусе Bitcoin.
Важно отличать covenant от обычного Bitcoin Script. Текущие скрипты проверяют условия расходования существующего выхода, но ограниченно читают детали транзакции и управляют произвольными будущими выходами. Covenants обсуждают как расширение выразительности, а не как отдельную монету или функцию любого Taproot-кошелька.
Что именно ограничивает covenant
Bitcoin работает с неизрасходованными выходами транзакций – UTXO. Когда владелец тратит выход, новая транзакция создаёт следующий набор выходов. Простая блокировка может требовать подпись или выполнение скрипта. Covenant добавляет связь между исходным UTXO и будущей транзакцией: например, разрешает трату лишь в транзакцию с заранее определёнными выходами или требует, чтобы часть суммы сохранила заданную политику.
Это не обязательно делает монеты замороженными. Ограничение может допускать несколько путей: владелец выводит средства после задержки, а аварийный ключ раньше переносит их в безопасный выход. Но если конструкция задана неверно, разрешённые действия окажутся слишком узкими или UTXO станет непотратимым. Поэтому covenant усиливает контроль и одновременно усложняет проектирование.
Термин применяют к разным системам: от заранее подписанных цепочек транзакций до новых опкодов Script. Для конкретного предложения важно выяснить, какие поля транзакции фиксируются, что остаётся изменяемым и какие данные доступны скрипту.
OP_CHECKTEMPLATEVERIFY и BIP-119
BIP-119 описывает OP_CHECKTEMPLATEVERIFY, или CTV. Предлагаемый опкод сравнивает хеш шаблона со свойствами транзакции, которая тратит выход. Спецификация перечисляет версию и locktime, число входов, последовательности, число выходов, хеш выходов и индекс текущего входа. Если транзакция не совпадает с зафиксированным шаблоном, выполнение должно завершиться неуспешно.
Схема подходит случаям, где следующий шаг заранее известен. Например, payment tree может описывать ветви распределения средств, а набор массовых выплат – раскладываться на последовательные транзакции. Получатель не должен доверять координатору на слово: допустимость перехода проверяется узлами. Но CTV не даёт произвольно менять все детали следующей транзакции, поскольку фиксация шаблона и есть суть ограничения.
BIP-119 остаётся proposal со статусом Draft. До активации консенсус Bitcoin не меняется, и обычный кошелёк не может считать CTV новым правилом сети. Обсуждение реализации или демонстрация на тестовой среде не равны включению в mainnet.
OP_CHECKCONTRACTVERIFY и перенос состояния
BIP-443 предлагает OP_CHECKCONTRACTVERIFY, или CCV. Черновик описывает проверку характеристик Taproot-выходов и связь с данными, переносимыми между UTXO. Это более общая модель состояния: скрипт проверяет, что будущий выход сохраняет ожидаемые ключи, дерево или commitment либо соответствует допустимому переходу.
Возможные применения включают shared UTXO, схемы типа Ark, vault, timeout trees и некоторые конструкции rollup. Выразительность может поддержать больше сценариев, но анализ должен учитывать суммы, индексы входов, комиссии и альтернативные выходы. BIP-443 также находится в Draft и не должен описываться как доступная всем пользователям возможность действующего mainnet.
Часть таких правил проекты сегодня эмулируют координаторами, комитетом подписантов или заранее подписанными транзакциями. Это добавляет предположения о доверии и доступности. В обзоре Bitcoin staking в Babylon covenant committee рассматривается как отдельный компонент дизайна, а не как универсальный активированный опкод.
Зачем обсуждают такие ограничения
Vault. Пользователь может потребовать, чтобы крупный вывод сначала попадал на адрес с задержкой, оставляя окно для аварийного восстановления. Covenant мог бы зафиксировать последовательность и назначение следующего UTXO. Безопасность зависит от наличия пути отмены, хранения ключей и набора допустимых действий.
Платёжные пулы и деревья выплат. Несколько получателей могут разделять структуру, из которой средства расходуются по заранее заданным ветвям. Ограничение будущей транзакции помогает не менять чужую долю на следующем шаге. При этом участникам нужны совместимые кошельки и способы восстановить данные всей конструкции.
Каналы и масштабирование. Заранее заданные переходы могут пригодиться некоторым каналам, совместным UTXO и финансовым схемам. Однако covenant не превращает Bitcoin в EVM: модель хранения и условия исполнения остаются другими. Нельзя без анализа переносить предположения о смарт-контрактах Ethereum на UTXO.
Отличия от мультиподписи, timelock и Taproot
Мультиподпись определяет, кто должен подписать трату. Timelock запрещает расход до времени или числа блоков. Covenant ограничивает содержание расходующей транзакции. Механизмы могут сочетаться, например порог подписей плюс запрет на немедленный вывод куда угодно, но один не заменяет другой.
Taproot позволяет организовать условия в дереве скриптов и скрыть неиспользованные ветви, но сам по себе не вводит новые covenant-опкоды. Полезно понимать разницу между key path и script path и между multisig и MuSig2. Ключи, дерево условий и пути восстановления нужно хранить вместе с корректным descriptor – см. руководство по Bitcoin descriptors.
Как оценивать предложения и риски
Читайте спецификацию, а не только пример применения. Уточните, какие поля следующей транзакции закреплены, можно ли добавлять сдачу, как оплачиваются комиссии, сколько входов допустимо и какие ветви останутся у владельца. Сложный шаблон может быть уязвим к ошибке кошелька или неверным предположениям о свободных полях транзакции.
Оцените совместимость и приватность: необычная политика может быть узнаваемой, увеличить witness и требовать обновления кошельков, подписантов и обозревателей. Проверьте аварийное восстановление при потере сервиса или ключа. Главное – смотрите текущий статус предложения и механизм активации. Пока правило не включено в консенсус, не отправляйте реальные средства на адрес, безопасность которого зависит от его исполнения.
