Перейти к основному контенту

Возрождение ковенантов Биткоина: как OP_CTV, LNHANCE, OP_CAT и BitVM2 могут наконец внедрить смарт-контракты в Биткоин L1

· 13 мин чтения
Dora Noda
Dora Noda
Software Engineer

На протяжении пятнадцати лет язык сценариев (скриптов) Биткоина был намеренно и агрессивно скучным. Никаких циклов. Никакой рекурсии. Никакого состояния (state). Небольшой стек, горстка операционных кодов (opcodes) и культура, которая относится к любому предложенному расширению как к потенциальной гражданской войне. Этот консерватизм является причиной того, почему Биткоин никогда не подвергался успешным атакам на уровне консенсуса — и причиной того, почему разработчики, которые хотели создать что-то большее, чем просто «отправка монет от А к Б», в конечном итоге сдались и перешли в Ethereum.

Этот расклад меняется в 2026 году. OP_CHECKTEMPLATEVERIFY впервые с момента подготовки BIP-119 получил конкретные параметры активации. OP_CAT получил официальный номер BIP. LNHANCE активно обсуждается как альтернатива, ориентированная на Lightning. А BitVM2, которая вообще не требует софтфорка, уже работает в продакшене, обеспечивая функционирование моста основной сети Citrea, запущенного в январе. После многих лет разговоров о том, что «ковенанты скоро появятся», Биткоин наконец перешел в фазу, когда параллельно разрабатываются несколько заслуживающих доверия предложений, каждое из которых решает свою часть проблемы.

Что такое ковенанты на самом деле (и почему они вызвали столько споров)​

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

Это небольшое расширение открывает удивительное количество функциональных возможностей. Хранилища (Vaults), обеспечивающие обязательную задержку по времени перед тем, как средства смогут покинуть определенный адрес. Обязательства по управлению перегрузками (congestion-control), позволяющие одной ончейн-транзакцией финансировать тысячи офчейн-платежей. Платежные пулы. Неинтерактивные каналы. Мосты ZK-rollup, не полагающиеся на федерации мультисигов. Список новых возможностей настолько велик, что разработчики спорят о ковенантах большую часть десятилетия.

Почему возник спор? Две реальные причины и одна культурная. Технически рекурсивные ковенанты — ковенанты, которые навязывают себя каждой последующей трате навсегда — теоретически могут быть использованы для создания навсегда ограниченных монет, подрывая взаимозаменяемость (fungibility) Биткоина. Культурно же этика разработки Биткоина рассматривает каждый новый операционный код как потенциальную поверхность для атак, и внедрение ковенантов после Taproot для некоторых разработчиков является неприемлемым расширением бюджета сложности протокола. Освещение дебатов по BIP-119 в Bitcoin Magazine прямо зафиксировало эту динамику: «Внедрение ковенантов в Биткоин — это большой шаг при почти полном отсутствии существующих исследований по этой теме, и попыткам протолкнуть это через черный ход так скоро после активации Taproot следует сопротивляться».

Три года дополнительных исследований спустя, критика об «отсутствии» стала гораздо менее убедительной.

OP_CTV (BIP-119): Минималистичное предложение для хранилищ​

OP_CHECKTEMPLATEVERIFY — это предложение по ковенантам, наиболее близкое к фактической активации. Созданный Джереми Рубином, BIP-119 добавляет один операционный код, который привязывает UTXO к трате в рамках конкретного, предопределенного шаблона транзакции — версии, времени блокировки (locktime), количества входов, последовательностей, количества выходов, самих выходов и позиции расходуемого входа. Соответствуете шаблону — можете тратить. Не соответствуете — не можете.

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

Конкретные новости на 2026 год: параметры развертывания CTV теперь указывают время начала 30 марта 2026 года, тайм-аут 30 марта 2027 года, минимальную высоту активации в мае 2027 года, порог сигнализации майнеров 90% и период сигнализации в 2016 блоков. Это не консенсус — это предложение параметров активации. Но это первый случай с 2022 года, когда на столе появился конкретный график, и это представляет собой попытку лагеря CTV поставить вопрос ребром: активировать или официально отклонить.

Практичной «киллер-фичей» для CTV является хранилище (vault). Сегодня, если пользователь хочет самостоятельно хранить 1 миллион долларов в биткоинах с защитой от компрометации одного ключа, его варианты выглядят не лучшим образом: мультисиг с географическим распределением ключей (операционно сложно), транзакции с временной блокировкой (хрупко) или кастодиальные сервисы (что сводит на нет смысл владения). Хранилище на базе CTV позволяет пользователю установить условие, согласно которому любая трата из его холодного хранилища обязательно должна сначала пройти через промежуточный адрес с временной блокировкой, в течение которой пользователь может обнаружить несанкционированную активность и инициировать возврат средств (clawback). Это тот тип примитива, который существенно меняет профиль риска крупных запасов биткоинов.

OP_CAT (BIP-347): Путь максимализма рекурсивных ковенантов​

OP_CAT — это философски почти противоположное предложение. Если CTV — это один тщательно проработанный операционный код, предназначенный для конкретных сценариев использования, то OP_CAT — это примитив конкатенации строк в стеке, который уже был в оригинальном языке скриптов Биткоина, прежде чем был отключен в 2010 году из-за опасений по поводу DoS-атак, которые более не актуальны при ограничениях на размер скрипта после Taproot.

Повторное включение OP_CAT на первый взгляд не кажется чем-то значительным: оно просто позволяет скриптам соединять две строки байтов. Но конкатенации в сочетании с подписями Шнорра (введенными в Taproot) достаточно для создания интроспекции — способности скрипта проверять транзакцию, которая его расходует. А интроспекции достаточно для создания рекурсивных ковенантов, конечных автоматов (state machines) и, как следствие, практически любого смарт-контракта, который можно написать в сетях типа EVM.

StarkWare опубликовала концепт мостового ковенанта на базе Биткоина с поддержкой OP_CAT, который демонстрирует именно это: минимизирующий доверие мост между Биткоином и L2, работающий полностью на скрипте Биткоина, без необходимости использования федеративного мультисига или отдельной сети моста. Команда sCrypt опубликовала серию статей, показывающих, как OP_CAT позволяет создавать контракты UTXO с состоянием, торговлю ординалами в стиле NFT и рекурсивные хранилища.

Компромисс заключается именно в том, о чем беспокоятся сторонники CTV. Выразительность OP_CAT включает возможность создания навсегда ограниченных монет. На практике это уже существует в более слабых формах (мультисиги с потерянными ключами, временные блокировки с недостижимым сроком), и защитники OP_CAT утверждают, что проблема взаимозаменяемости является скорее теоретической, чем операционной. Но философский разрыв реален: OP_CTV говорит «давайте разрешим ковенанты для этих конкретных случаев»; OP_CAT говорит «давайте разрешим примитив, а разработчики сами придумают сценарии использования».

Получение OP_CAT номера BIP-347 в 2024 году было важно не столько своим техническим содержанием — CAT представляет собой четырехбайтовый операционный код — сколько сигналом о том, что путь максимализма ковенантов обладает достаточным авторитетом среди разработчиков, чтобы пройти процесс BIP.

LNHANCE: компромисс, ориентированный на Lightning​

LNHANCE — это предложение с наиболее четким ответом на вопрос "какую проблему это решает". Вместо того чтобы аргументировать необходимость ковенантов на абстрактных основаниях, LNHANCE объединяет OP_CTV с OP_CHECKSIGFROMSTACK (CSFS) и OP_INTERNALKEY, нацеливаясь именно на улучшение Lightning Network.

К апрелю 2026 года сеть Lightning Network выросла до более чем 65 000 публичных узлов и стала доминирующим платежным каналом Биткоина, но она несет в себе реальный технический долг протокола. Проверка состояния каналов по-прежнему требует использования сервисов-сторожевых башен (watchtowers) или онлайн-кошельков. Фабрики каналов (channel factories) и многосторонние каналы сложны в построении. Неинтерактивное открытие каналов — когда одна сторона может открыть канал другой без присутствия получателя в сети — невозможно в текущей версии Lightning.

LNHANCE позволяет реализовать LN-Symmetry (более чистый механизм состояния каналов), деревья тайм-аутов (timeout trees для эффективного массового закрытия каналов), упрощенные PTLC-скрипты (point time-locked contracts, заменяющие текущие контракты с хешированием и временной блокировкой HTLC), однонаправленные неинтерактивные каналы, улучшенные хранилища (vaults) и пулы монет без доверия (trustless coin pools). Каждое из этих решений является конкретным улучшением Lightning, а не спекулятивным примитивом смарт-контрактов.

Такой прагматичный подход является политическим преимуществом LNHANCE. Lightning Network добилась реального признания: от региональных платежных процессоров до протокола L402, который Lightning Labs позиционирует как нативный платежный уровень для транзакций ИИ-агентов. Улучшения, поддерживающие конкурентоспособность Lightning, обосновать легче, чем изменения, которые в первую очередь ориентированы на использование BTC в других блокчейнах.

BitVM2: альтернатива без софтфорков, которая уже работает​

Самым важным с прагматической точки зрения событием последних восемнадцати месяцев стало вовсе не предложение о ковенантах — это BitVM2 и тот факт, что она требует нулевых изменений в консенсусе Биткоина.

BitVM2, созданная Робином Линусом, извлекает суть того, что позволяют ковенанты (проверяемые вычисления вне сети, привязанные к Биткоину), не требуя от самого Биткоина выполнения этих вычислений. Протокол работает по модели "вызов-ответ" (challenge-response): прувер делает заявление о некотором вычислении вне сети, вносит залог, и если верификатор считает, что заявление неверно, он может инициировать диспут с использованием бинарного поиска, который изолирует конкретный шаг, на котором прувер схитрил. Этот единственный шаг затем выполняется ончейн в скрипте Биткоина, а залог лжеца конфискуется (слэшинг).

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

BitVM2 уже запущена. Citrea — первый ZK-роллап на Биткоине — запустила свою основную сеть 27 января 2026 года с мостом на базе BitVM2 (кодовое название "Clementine") в качестве производственной модели доверия. GOAT Network выпустила свою тестовую сеть BitVM2 V3 в первом квартале 2026 года, стремясь к созданию полноценного нативного стека zkRollup на Биткоине. Тенденция становится очевидной: команды, которые не хотят ставить сроки своего запуска в зависимость от спорного софтфорка Биткоина, выбирают BitVM2.

Ограничением является экономика, а не криптография. Диспуты оплачиваются местом в блоке Биткоина, и в худшем случае, если комиссии резко возрастут во время окна диспута, инициаторы вызова могут быть вытеснены с рынка из-за цены. Этот риск "экономики диспутов" является открытой проблемой, которую операторы BitVM2 решают с помощью избыточного обеспечения, сервисов watchtowers и тщательного выбора вычислений для защиты. Это реальное ограничение, но риск совсем иного рода, чем "ожидание согласия консенсуса Биткоина по новому коду операции (opcode)".

Вопрос активации: почему технического консенсуса недостаточно​

Неудобная правда о дебатах по ковенантам в Биткоине заключается в том, что технические разногласия — рекурсивные против нерекурсивных, минималистичный opcode против общего примитива — в значительной степени разрешимы. Более сложный вопрос заключается в том, как активировать любой из них.

История софтфорков Биткоина коротка и политически заряжена. SegWit потребовал угрозы UASF (софтфорк, активируемый пользователями), чтобы выйти из тупика с майнерами в 2017 году. Taproot использовал Speedy Trial — трехмесячное окно BIP8 с порогом сигнализации майнеров в 90% — и был чисто активирован в ноябре 2021 года. С тех пор каждое обсуждение методологии активации проходит в тени того, что произошло раньше.

Предложение по параметрам CTV 2026 использует окно сигнализации в стиле Speedy Trial, для чего есть прецедент. Но противники ковенантов четко дали понять, что не считают Speedy Trial подходящим для спорных изменений — он был разработан специально для предложений, которые уже достигли подавляющего консенсуса, а его трехмесячное окно не дает широкой экосистеме времени для выдвижения возражений. Ожидайте, что борьба за методологию активации будет, во всяком случае, более интенсивной, чем техническая борьба.

Политические условия на самом деле могут благоприятствовать активации. Ончейн-активность Биткоина значительно снизилась по сравнению с пиком инскрипций 2024 года, спрос на пространство в блоках невелик, и майнеры Биткоина — которые должны одобрять любой софтфорк через сигнализацию — ищут новые нарративы, стимулирующие спрос на место в блоках. Хранилища (vaults), улучшения Lightning и L2-решения, защищенные Биткоином, — всё это генерирует спрос на транзакции в сети. Совпадение экономических интересов сейчас более очевидно, чем когда-либо за последние годы.

Что это значит для разработчиков инфраструктуры Биткоина​

Для команд, строящих на Биткоине, ренессанс ковенантов создает реальный стратегический выбор. У команд, которым функциональность, подобная смарт-контрактам, нужна прямо сейчас, есть три надежных пути:

Путь 1 — Ожидание CTV / CAT / LNHANCE. Более низкая сложность, требуется софтфорк для активации, неопределенные сроки. Лучше всего подходит для команд, чьи варианты использования принципиально невозможны без изменений на уровне консенсуса (например, масштабируемые нефедеративные хранилища — vaults).

Путь 2 — Разработка на BitVM2. Доступно уже сегодня, более высокая сложность реализации, зависимость от экономической безопасности. Лучше всего подходит для команд, создающих L2-решения, мосты или роллапы на Биткоине, которым нужно запуститься в 2026 году, не дожидаясь консенсуса.

Путь 3 — Гибридный подход. Запуск на BitVM2 с проектированием протокола таким образом, чтобы активация ковенантов обеспечила более чистый путь обновления. Именно такую позицию занимают GOAT Network и несколько других команд разработчиков Bitcoin L2.

Для провайдеров инфраструктуры общий вывод один: скрипт Биткоина становится более выразительным независимо от того, какой из этих путей победит. Кошельки, RPC-провайдеры, индексаторы и инфраструктура узлов — все должны быть готовы к обработке более сложных типов транзакций в основной сети: UTXO с поддержкой ковенантов, транзакции оспаривания BitVM2, новые структуры каналов Lightning.

BlockEden.xyz предоставляет RPC-инфраструктуру корпоративного уровня для Биткоина и смежных сетей, включая развивающиеся L2-решения на базе BitVM2 и примитивов с поддержкой ковенантов. Изучите наш маркетплейс API, чтобы строить на фундаменте, спроектированном для следующей главы в истории Биткоина.

Облик следующего десятилетия Биткоина​

Самое интересное в 2026 году — это не то, что одно из этих предложений обязательно будет активировано (любое из них все еще может затянуться еще на год или три). Дело в том, что культура разработки Биткоина решительно вышла за рамки бинарных дебатов «ковенанты — да или нет», которые определяли период 2022–2024 годов.

Сейчас дискуссия идет о том, какая комбинация примитивов ковенантов, протоколов внечейновой (off-chain) проверки и архитектур второго уровня обеспечит наиболее полезную программируемость при минимальных изменениях консенсуса. CTV — для хранилищ и контроля перегрузок. CAT — для выразительности и мостов. LNHANCE — для Lightning. BitVM2 — для всего, что может работать в рамках модели разрешения споров. Это не конкурирующие видения, а взаимодополняющие инструменты в расширенном наборе средств разработки скриптов Биткоина.

Биткоин намеренно оставался «скучным» в течение пятнадцати лет. Это стратегическое терпение позволило создать самый безопасный расчетный уровень (settlement layer) в истории. Вопрос следующего десятилетия заключается в том, сможет ли эта же дисциплина безопасности сохраниться при расширении до полноценного программируемого слоя. Если дебаты об активации 2026 года закончатся внедрением хотя бы одного из этих предложений, ответ будет положительным — и роль Биткоина в более широкой криптоэкосистеме сместится с «цифрового золота, которое ничего не делает» на «расчетный уровень, которому доверяют все остальные».

Источники:

Share on Twitter