Идея в одном абзаце. В Биткоине сегодня скрипт может ограничивать *кто* тратит монеты (подпись нужного ключа), *когда* (таймлок) и *при каких условиях* (мультисиг и т. п.). Ковенанты — это следующий класс правил: выход (UTXO) добавляет условия как именно должны выглядеть будущие траты этих монет (на какие скрипты/адреса и в какой форме их можно отправлять). Предлагаемая повторная активация опкода OP_CAT (в Tapscript) — один из путей приблизить такой функционал: он даёт простой «кирпичик» — *склеить* (конкатенировать) кусочки данных на стеке, чтобы затем сравнивать их хэши и проверять соответствие заранее оговорённому «шаблону» будущей транзакции.
Важно: сам по себе OP_CAT не создаёт ковенанты «из воздуха». Он становится полезным в сочетании с другими проверками (подписи, хэши полей транзакции и т. д.), позволяя собрать проверку «будущая трата должна выглядеть вот так». Рядом существуют альтернативные/дополняющие предложения — BIP-119 (CTV), TXHASH/OP_CHECKTXHASHVERIFY, OP_VAULT — они решают схожие задачи разными способами.
Что такое «ковенант» на человеческом языке
В обычном сценарии вы тратите UTXO на *любой* новый скрипт (адрес), если предъявили корректную подпись. Ковенант позволяет UTXO сказать: «меня можно потратить только так-то и так-то». Например:
- «Эти монеты можно вывести только на заранее известный список адресов (или в “корзину” с фиксированными выходами)».
- «Если кто-то попытается потратить эти монеты, у владельца будет 24 часа, чтобы откатить перевод на “адрес возврата” (vault-логика)».
- «Средства биржи выводятся батчем по заранее известному шаблону, без возможности подменить структуру выплат».
Техничесно это достигается через *интроспекцию* транзакции: скрипт UTXO как-то «смотрит» на детали спендящего tx и убеждается, что они соответствуют правилам.
Почему это полезно:
- Безопасность. Холодные сейфы, «чекап до отгрузки», защита от взлома горячих ключей.
- Масштабирование и UX. Шаблоны массовых выплат, пеймэнт-пулы, канальные фабрики для Lightning Network.
- Инфраструктура. Чёткие процессы вывода на биржах, «конгешен-контролируемые» транзакции (снижение давления на мемпул).
Чем тут помогает OP_CAT
OP_CAT — это элементарная операция конкатенации: берёт два элемента со стека и кладёт их «склеенными» обратно. Звучит скромно, но:
- Позволяет конструировать хэшируемые строки из кусочков данных (например, «версия tx» + «locktime» + «определённые выходы»), а затем сравнить их хэш с заранее зафиксированным *коммитментом*.
- В связке с проверками подписи (или с отдельными опкодами проверки хэшей/полей) можно выразить правило: «спендящая транзакция должна соответствовать шаблону X». Это и есть «шаблонный ковенант».
Пример интуитивно: мы заранее сохраняем хэш нужного «макета» будущей траты. В момент расходования склеиваем поля реальной транзакции тем же способом, считаем хэш и сравниваем с прежним. Совпало — значит, трата «по правилам».
Ограничения. Один лишь OP_CAT не даёт доступ ко *всем* полям транзакции; он — вспомогательный кирпичик, который в сочетании с другими Tapscript-возможностями даёт разработчикам больше «выразительности». Из-за гибкости у сообщества есть опасения насчёт «рекурсивных ковенантов» (возможность строить громоздкие цепочки ограничений). В ответ предлагаются «усечённые» варианты (например, OP_PAIRCOMMIT) и строгие гайды использования.
Альтернативы и родственники: CTV, TXHASH, OP_VAULT
| Подход | Что проверяет | Сила/гибкость | Типичные кейсы |
|---|---|---|---|
| BIP-119 CTV | Транзакция должна соответствовать *конкретному шаблону* (кол-во входов/выходов, их скрипты/суммы, locktime и т. п.) | Строго ограничен (не рекурсивен) → проще анализ безопасности | Массовые выплаты, канальные фабрики LN, «конгешен-контролируемые» транзакции |
| TXHASH / OP_CHECKTXHASHVERIFY | Хэш (или поднабор хэшей) текущей транзакции/её частей | Более общий шаблонный ковенант (обобщение идеи CTV) | Широкий спектр ковенантов, гибкие шаблоны для L2-инфраструктуры |
| OP_VAULT (BIP-345) | Специализированная логика «сейфа»: задержка вывода + путь экстренного возврата | Узкоспециализирован (предельно понятен пользователю/аудиту) | Персональные и корпоративные сейфы, регламент бирж |
| OP_CAT (BIP-347) | «Склейка» данных на стеке → удобнее строить коммитменты/сравнения | Базовый кирпичик, даёт выражаемость в связке с другими проверками | Конструктор: от простых шаблонов до продвинутых ковенантов (при дисциплине дизайна) |
Коротко: CTV — минималистичный и безопасный «шаблонизатор»; TXHASH — более общий «просмотр» транзакции; OP_VAULT — готовый «сейф»; OP_CAT — строительный блок, помогающий собирать проверки.
Практические сценарии (зачем бизнесу и пользователям)
Биржи и кастодиальные сервисы. Шаблонные батчи вывода: заранее известный формат «пакета» выплат (кол-во выходов, адреса, лимиты). Попытка подменить структуру обнаружится скриптом. Итог — меньше шансов на несанкционированные переводы, удобное планирование комиссий.
Vault-сейфы для «дальних» сбережений. Монеты «сидят» в UTXO со строгим правилом: при любой попытке вывода есть время на реакцию (например, 24–72 часа) и «адрес восстановления». Это снижает риск кражи горячих ключей: злоумышленник не успеет «моментально вычистить» сейф.
Пеймэнт-пулы и «общие кошельки». Многие плательщики пополняют общий пул, из которого периодически делаются выплаты (зарплатные батчи, массовые рефанды, дистрибуция дивидендов). Ковенант не позволит увести пул «не по регламенту» и упростит аудит.
Канальные фабрики для Lightning. Вместо открытия десятков отдельных каналов участники создают «фабрику» — общий источник ликвидности, из которого «порождаются» каналы. Ковенантные шаблоны помогают надёжно фиксировать «как именно» допустимы дальнейшие перераспределения UTXO.
Инфраструктура L2 и мосты. Шаблонные коммитменты — кирпичик для упорядоченных выходов и аварийных путей в мостах/роллапах, дополняя идеи BitVM2 и решения вроде Ark (для них важны предсказуемые графы транзакций и «безопасные выходы»).
Риски, споры и почему консенсус не быстр
- Сложность анализа. Чем гибче механизм (OP_CAT + набор проверок), тем выше риск «незамеченных» углов. Поэтому часть сообщества предпочитает CTV/VAULT: меньше возможностей — легче формально обосновать безопасность.
- Рекурсия и “навсегда запертые” монеты. Теоретически можно сконструировать упрямые цепочки ограничений. Это требует дисциплины дизайна и, возможно, «ограниченных» вариантов опкодов.
- Процесс софтфорка. Любые консенсусные изменения проходят долгую фазу исследований, тестов на signet, обсуждений в рассылке разработчиков и только потом — дискуссию об активации. Это годы, не месяцы.
Как это выглядит «под капотом» (упрощённая логика)
1) На этапе депозита мы создаём выход (UTXO), чей скрипт содержит:
- коммитмент (хэш) «разрешённой формы» будущей траты;
- логику проверки: *склеить* (через OP_CAT) нужные поля реальной траты, посчитать хэш и сравнить;
- дополнительные условия (подписи, таймлоки и т. д.).
2) При трате:
- формируется транзакция строго по шаблону (или из «разрешённого семейства» шаблонов, если используем TXHASH-подход);
- скрипт проверяет совпадение хэшей и подписи. Если всё ок — монеты уходят на выходы «как задумано».
3) При попытке «схитрить»:
- несоответствие вскрывается локально (узел не валидирует транзакцию), «унести» средства нельзя.
Это всего лишь паттерн. Реальные реализации по-разному кодируют поля, используют различные «соли», комбинируют с таймлоками и мультисигами, чтобы исключить неоднозначности.
Простые аналогии для понимания
- Пломба на посылке. Вы заранее договариваетесь, как должна выглядеть отправка: габариты, получатели, сумма. Любая расхожая с оговорённым макетом попытка будет обнаружена пломбой.
- Чек по шаблону. Банк принимает только чеки «из этой книжки» и только с теми полями, что вы указали. Любая «левизна» — отклоняется.
- Сейф с отложенным открытием. Даже если ключи украли, сейф сперва «пищит» сутки — у вас время нажать «Стоп».
Когда это может появиться в сети
Статус на сегодня: исследования и тестирование.
- OP_CAT оформлен как BIP-347 и активно исследуется на тестовых сетях/Signet; ведутся обсуждения «усечённых» вариантов и рисков «рекурсивности».
- BIP-119 (CTV) давно обсуждается, имеет понятную модель угроз и набор «железных» кейсов, но консенсус на активацию не достигнут.
- OP_VAULT (BIP-345) — сфокусированная «сейфовая» схема; вокруг неё идёт активная проработка дизайна и сравнение с альтернативами.
- TXHASH — эволюционный шаг в сторону общего «шаблонного» ковенанта (обобщение CTV), в сообществе обсуждается как возможный компромисс между силой и анализируемостью.
Иными словами: технология «дозревает». Прежде чем что-то попадёт в мейннет, сообщество должно пройти полный цикл «исследования → прототипы → тестовые сети → согласование активации».
Вопросы и ответы (FAQ)
<details><summary>Это «смарт-контракты на Биткоине»?</summary>Скорее это контракты-ограничители. Они не «исполняют программы», а навязывают форму будущей траты. Этого достаточно для сейфов, шаблонов выплат, канальных фабрик — и это хорошо вписывается в философию минимализма Биткоина.
</details><details><summary>OP_CAT сам по себе включает ковенанты?</summary>Нет. Он лишь помогает собирать коммитменты и сравнения. Нужны ещё проверки подписи/хэшей полей транзакции. Поэтому обсуждение часто ведётся в пакете с CTV/TXHASH/другими примитивами.
</details><details><summary>Чем CTV лучше/хуже OP_CAT-подхода?</summary>CTV строже и предсказуемее (меньше «магии», проще аудит), зато менее гибок. OP_CAT-подход (с доп. проверками) гибче, но требует очень дисциплинированного дизайна, чтобы исключить неожиданные сценарии.
</details><details><summary>Опасно ли «запереть» монеты навсегда?</summary>Риск «неотзывных» ограничений существует для слишком агрессивных схем. Хорошая практика — проектировать аварийные пути (возврат по таймлокам, «ключ-хозяин») и использовать проверенные шаблоны.
</details><details><summary>Когда ждать активации?</summary>Пока рано говорить. Нужны дополнительные исследования, прототипы и согласование способа активации. У Биткоина цикл изменений намеренно медленный.
</details>Лучшие практики проектирования (для команд)
- Начинайте с узких кейсов (vault, батч-выплаты), где легко формализовать корректность.
- Предпочитайте минимальные примитивы (CTV/VAULT), если гибкость не критична: проще аудит → выше вероятность комьюнити-поддержки.
- Если используете «сборные» шаблоны (с OP_CAT), чётко прописывайте границы: какие поля учитываются, где таймлоки/мультисиг, каков «путь отмены».
- Закладывайте мониторинг и «человеческий» UX: предупреждения, окна отмены, «dry-run» проверок перед отправкой.
- Документируйте угрозы рекурсии и способы её исключения (ограничение глубины, статические наборы шаблонов и т. п.).