MSTR Cat

Блокчейн/Уровень IV · Глубины протокола/4.2 Обновления/Урок 5

Ковенанты и хранилища: CTV, OP_CAT и дебаты 2026 года

Правило, ограничивающее следующую трату, и задержка, которую оно даёт

МатериалыКопия BIP119 (OP_CHECKTEMPLATEVERIFY)Копия BIP347 (повторное включение OP_CAT в Taproot)Исходный код Bitcoin Core с логикой проверки скриптовБлок-эксплорер с возможностью просмотра транзакций

Любопытство

  1. Почему стандартный скрипт биткоина может проверить, кто владеет ключами, но не может определить, куда монеты отправятся дальше?
  2. Какие конкретные ограничения налагает OP_CHECKTEMPLATEVERIFY на будущие транзакции?
  3. Почему повторное включение одного-единственного опкода конкатенации через софтфорк открыло бы дорогу ковенантам?

Исследование

    Часть IПредложения ковенантов: CTV и OP_CAT

  1. Стандартные скрипты биткоина проверяют владение ключом или хешем, но не могут ограничить, куда отправятся монеты после разблокировки. Ковенант меняет это, накладывая условия на `scriptPubKey` последующих выходов. Этот механизм часто сравнивают с талонами на питание: в отличие от наличных, которые можно потратить где угодно, такие средства можно использовать только в определённых ресторанах-партнёрах. Среди предлагаемых применений — хранилища (vaults) с отложенным выводом средств, управление перегрузкой сети и упрощённые конструкции Lightning.
  2. Джереми Рубин предложил OP_CHECKTEMPLATEVERIFY (CTV) в 2019 году. Этот опкод встраивает хеш шаблона будущей транзакции в текущий UTXO. Чтобы его потратить, сама тратящая транзакция должна в точности соответствовать этому шаблону; на этапе проверки подпись не участвует. Следующий ход фиксируется ещё до выполнения текущего. Любое отклонение в суммах, адресатах или структуре скрипта сразу приводит к провалу проверки, гарантируя строгое следование заранее заданному пути.
  3. Ограничение CTV — жёсткость: выходы следующей транзакции фиксируются в момент блокировки монет, поэтому комиссию приходится обеспечивать иначе, например с помощью якорного выхода (anchor output) и механизма CPFP («дочерняя платит за родительскую»). Взамен CTV прост в анализе и дёшев в проверке.
  4. OP_CAT — опкод, объединяющий (конкатенирующий) два элемента стека, — был отключён Сатоши Накамото в 2010 году в качестве меры предосторожности против атак на исчерпание памяти. BIP347 предлагает снова включить его, но только в tapscript. В сочетании с приёмами на основе подписей Шнорра OP_CAT делает возможными ковенанты и другую сложную логику без введения новых правил консенсуса под каждый конкретный сценарий. Он служит примитивным строительным блоком, из которого разработчики могут собирать индивидуальные ограничения для будущих транзакций.
  5. К родственным предложениям относится OP_CHECKSIGFROMSTACK (BIP348), который проверяет подпись под произвольным сообщением, переданным через стек, а не под тратящей транзакцией. Эта гибкость в сочетании с CTV (или, как отдельный вариант, с предлагаемым ANYPREVOUT) позволила бы создавать симметричные каналы Lightning, в которых ни одной из сторон не нужно хранить штрафные данные для каждого прежнего состояния канала.
  6. По состоянию на 2026 год ни одно из этих предложений ковенантов не активировано, хотя попытки добиться активации и споры продолжаются. Дискуссия идёт об их полезности, о рисках, которые они добавляют в правила консенсуса, и о процессе управления, необходимом для активации. Расширение правил консенсуса поднимает вопросы о сложности сети и её долгосрочной поддерживаемости, которые в сообществе пока остаются нерешёнными.

    7. Часть IIКовенанты и хранилища: дебаты 2026 года

  7. Скрипты Биткоина сейчас проверяют условия текущей транзакции, например подписи или таймлоки. Они не могут анализировать выходы тратящей транзакции. Ковенанты расширяют эти возможности: scriptPubKey может накладывать ограничения на scriptPubKey выходов, создаваемых транзакцией, которая его тратит. Это ограничивает, куда монеты могут быть отправлены дальше, и позволяет реализовать такие функции, как белые списки адресов и неинтерактивные платёжные каналы.
  8. BIP-119 предлагает опкод OP_CHECKTEMPLATEVERIFY (CTV). Он позволяет встроить в скрипт хеш шаблона; тратящая транзакция должна соответствовать этому шаблону по выходам, количеству входов, значениям sequence, locktime и версии, но не по тому, какие именно входы тратятся. CTV нерекурсивен: он ограничивает только ближайший следующий шаг. Он заменяет OP_NOP4 и требует софт-форка. На его основе можно строить хранилища (vaults), которые добавляют временную задержку, позволяющую вернуть средства после кражи.
  9. В хранилище вывод средств должен пройти через период ожидания (например, 12 часов), в течение которого отдельный ключ восстановления может перевести средства в безопасное место. Если злоумышленник украдёт повседневный ключ и начнёт вывод, владелец увидит это в блокчейне и вернёт средства до окончания задержки. Так кража ключа превращается из необратимой потери в событие, последствия которого можно исправить, — при условии, что жертва следит за блокчейном.
  10. Несмотря на обсуждения, идущие с 2013 года, ни один софт-форк с ковенантами так и не был активирован. Taproot (ноябрь 2021 г.) остаётся последним крупным обновлением. В феврале 2026 года был опубликован клиент активации BIP-119, созданный без участия Bitcoin Core. Он требует сигнализации 90% майнеров в период с марта 2026 по март 2027 года. По состоянию на май 2026 года сигнализация оставалась почти нулевой, что говорит об отсутствии консенсуса относительно принятия.
  11. OP_CAT (BIP-347) получил полную спецификацию в марте 2026 года, но параметров активации у него нет. Он позволяет конкатенировать элементы скрипта, что даёт более сложную логику, чем один CTV. CTV часто сочетают с CheckSigFromStack (CSFS), который проверяет подпись под произвольными данными из стека, а не только под тратящей транзакцией. Вместе они значительно расширяют выразительные возможности смарт-контрактов и проектирования протоколов.
  12. Дебаты сводятся к компромиссам: ковенанты повышают безопасность и позволяют создавать новые протоколы, такие как хранилища, но добавляют сложности и риски в области управления. Софт-форк меняет правила консенсуса и требует широкого согласия майнеров и операторов нод. Нынешний застой отражает осторожность в отношении ошибок реализации и необратимости изменений состояния блокчейна. Пользователям приходится сопоставлять эти преимущества с риском неудачной или спорной активации.

Ключевые факты

  • Ковенант ограничивает `scriptPubKey` будущих транзакций, а не только текущие условия разблокировки.
  • OP_CHECKTEMPLATEVERIFY (BIP119) привязывает выход к точной форме транзакции, которая его потратит.
  • CTV требует заранее рассчитать параметры будущих транзакций, фиксируя суммы и комиссии в момент создания.
  • OP_CAT был отключён в 2010 году, но BIP347 (2023–2024) предлагает снова включить его в tapscript.
  • BIP348 предлагает OP_CHECKSIGFROMSTACK, который проверяет подпись под сообщением, взятым из стека.
  • По состоянию на 2026 год ни одно предложение ковенантов не было активировано; споры о полезности, рисках и активации продолжались.
  • Ковенанты ограничивают выходы транзакции, которая тратит UTXO.
  • BIP-119 (CTV) требует сигналов от 90% майнеров для активации в период с марта 2026 года по март 2027 года.
  • Уровень сигнализации для BIP-119 по состоянию на май 2026 года был близок к 0%.
  • Taproot (ноябрь 2021 г.) — последний активированный софт-форк; ни один ковенант не работает в сети.
  • OP_CAT получил полную спецификацию в марте 2026 года, но без параметров активации.
  • Хранилища используют ковенанты, чтобы добавить задержку и путь возврата средств на случай кражи ключа.

Упражнение девять, шесть, три, один

9СобратьПеречислите 9 предложенных опкодов или механизмов биткоина, связанных с ковенантами или расширением возможностей скриптов (например, CTV, APO, OP_CAT).
6СгруппироватьСгруппируйте 9 пунктов в 6 категорий по основному типу ограничения: форма транзакции, деривация ключей, логика конкатенации и т. д.
3Выделить главноеСведите 6 групп к 3 ключевым техническим компромиссам между гибкостью и стоимостью проверки.
1КристаллизоватьНапишите одно предложение о том, почему жёсткий ковенант вроде CTV дешевле проверять, чем гибкие скрипты на основе OP_CAT.

Проверка фактов

Даты, цифры и утверждения были проверены по приведенным ниже опубликованным источникам.

Открыть в интерактивной академии →

EN PT ES ZH JA KO DE FR MS