MSTR Cat

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

Рубежи криптографии: witness encryption и PIPEs

Как запереть ключ внутри доказательства, если опкод так и не появится

МатериалыТексты BIP-119 и BIP-347Доступ к блок-эксплореру с функциями отладки скриптовБлокнот для отслеживания статуса предложенийЭкземпляр IACR ePrint 2026/186

Любопытство

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

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

    Часть IКриптографический фронтир: ковенанты и шифрование со свидетелем

  1. Bitcoin Script намеренно ограничен. Он может проверить, что подпись соответствует публичному ключу, но не может проверить, куда отправляются монеты после траты. Это ограничение делает Script простым и предсказуемым. Однако оно же блокирует некоторые конструкции, в которых условия траты зависят от структуры будущих транзакций.
  2. Предложение Джереми Рубина OP_CHECKTEMPLATEVERIFY (BIP-119) закрывает этот пробел. Этот опкод позволил бы скрипту требовать, чтобы тратящая транзакция соответствовала заранее зафиксированному шаблону, задающему её выходы и некоторые другие поля. Это делает возможными нерекурсивные ковенанты — правила о том, куда монеты могут пойти дальше, например блокировка средств в хранилищах (vaults) или ограничение путей погашения. Предложение по-прежнему не активировано и остаётся предметом дискуссий в сообществе Биткоина.
  3. Отдельное предложение, OP_CAT (BIP-347), касается конкатенации данных на стеке, а не прямого наложения ограничений на назначение монет, хотя в сочетании с подписями Шнорра оно тоже позволяет реализовать ковенанты. Эта простая операция открывает путь к сложным криптографическим конструкциям, включая древовидные подписи, компактно выражающие очень большие политики мультиподписи. Она также облегчает использование постквантово-устойчивых подписей Лэмпорта, позволяя манипулировать хешами и значениями прямо в движке скриптов.
  4. Помимо новых опкодов, исследователи рассматривают шифрование со свидетелем как альтернативный путь к программируемости. Шифрование со свидетелем позволяет отправителю зашифровать данные так, что расшифровать их сможет только тот, кто докажет обладание определённым секретом (свидетелем, witness). Теоретически это позволило бы раскрывать ключи от биткоинов только при доказательстве некоторого утверждения, не требуя от сети напрямую проверять вычисления.
  5. Ранние конструкции шифрования со свидетелем описаны в академической литературе, но для использования в Биткоине пока непрактичны. Практической конструкции для утверждений общего вида пока не существует: известные схемы огромны и опираются на криптографические допущения, которым пока широко не доверяют. Хотя теоретические основы прочны, инженерный разрыв между proof-of-concept и протоколом, готовым к продакшену, остаётся значительным.
  6. Компромисс очевиден: ковенанты добавляют выразительности, но вводят новые правила консенсуса, требующие тщательной проверки; шифрование со свидетелем добавляет приватности и гибкости, но влечёт высокие затраты на хранение и вычисления. Оба подхода стремятся расширить возможности Биткоина, не отказываясь от его базовой модели безопасности — фиксированной, предсказуемой эмиссии и ограниченных возможностей скриптов.

    7. Часть IIВвод и вывод биткоинов: PIPEs и шифрование по свидетелю

  7. Shielded Bitcoin, подробно разобранный в предыдущем уроке, обеспечивает приватные переводы внутри собственной системы нот. Peg-in и peg-out он оставляет за рамками: то есть то, как перевести стоимость из обычного, прозрачного Bitcoin в защищённый слой и обратно. План построения этих мостов опирается на механизм под названием шифрование по свидетелю, а именно на Bitcoin PIPEs v2 (IACR ePrint 2026/186, февраль 2026 г.).
  8. Шифрование по свидетелю запирает данные за математическим утверждением. В данном случае приватный ключ Bitcoin шифруется так, что расшифровать его можно, только предъявив действительный свидетель (witness) — доказательство того, что утверждение истинно. Шифротекст публикуется офчейн, а ключ внутри остаётся недоступным для всех, кто не может предъявить соответствующий свидетель.
  9. Механизм переносит программируемость из консенсуса в криптографию. Вместо новых опкодов или софт-форков для обеспечения сложных условий траты вся логика целиком находится внутри схемы шифрования. Тот, кто предъявит действительный свидетель, например SNARK-доказательство, восстанавливает приватный ключ и тратит монеты обычной подписью Шнорра. Для правил консенсуса Bitcoin это просто стандартная транзакция; вся сложность остаётся невидимой.
  10. Этот подход позволяет эмулировать ограничения в стиле ковенантов, например CheckTemplateVerify или механизмы хранилищ (vaults), без изменения протокола. Условия обеспечиваются тем, что ключ невозможно расшифровать, если свидетель не удовлетворяет определённым критериям. Это открывает путь к продвинутым условиям траты, которые остаются совместимыми с существующими правилами валидации Bitcoin, — при условии, что лежащая в основе криптография надёжна.
  11. Главное препятствие — масштаб. В статье февраля 2026 года размер каждого шифротекста оценивался примерно в 338 терабайт; в более поздней работе авторы говорят примерно о 10 терабайтах, что по-прежнему непрактично для хранения и распространения. Реализации не существует, поэтому это лишь оценки, и вопрос о том, можно ли вообще развернуть PIPEs, остаётся открытым исследовательским вопросом.
  12. Это по-прежнему стадия исследований, а не реализованная функция. Сроки развёртывания не определены, а противоречивые данные о размерах подчёркивают неопределённость в этой области. Пока шифротексты не уменьшатся достаточно, шифрование по свидетелю остаётся теоретическим мостом между прозрачным реестром Bitcoin и сложными криптографическими обязательствами, а не рабочим инструментом для пользователей.

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

  • OP_CHECKTEMPLATEVERIFY (BIP-119) предлагает механизм ковенантов, ограничивающий, куда монеты могут быть отправлены в будущем.
  • OP_CAT (BIP-347) позволяет выполнять конкатенацию на стеке, поддерживая древовидные подписи и подписи на основе хешей (Лэмпорта).
  • Шифрование со свидетелем запирает данные за доказательством знания секретного свидетеля, не раскрывая сам секрет.
  • Практической конструкции шифрования со свидетелем для утверждений общего вида пока не существует.
  • Ковенанты остаются неактивированными предложениями, вокруг которых идут споры о консенсусе.
  • Ограничения Bitcoin Script по замыслу исключают многие классы атак.
  • Bitcoin PIPEs v2 использует шифрование по свидетелю, чтобы запирать приватные ключи за математическими утверждениями.
  • Чтобы восстановить ключ, нужно предъявить действительный свидетель, например SNARK-доказательство.
  • После восстановления ключа трата выполняется обычной подписью Шнорра.
  • Механизм эмулирует ковенанты, не требуя новых опкодов или софт-форков.
  • Оценки размера шифротекста снизились примерно с 338 ТБ (в статье) до примерно 10 ТБ (в более поздних заявлениях), что по-прежнему непрактично.
  • Планы peg-in и peg-out для Shielded Bitcoin опираются на эту инфраструктуру шифрования по свидетелю.

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

9СобратьПеречислите 9 технических ограничений или особенностей Bitcoin Script, которые определяют его нынешние возможности и пределы.
6СгруппироватьСгруппируйте эти 9 пунктов в 6 групп по тому, что каждый из них позволяет или чему препятствует.
3Выделить главноеСведите 6 групп к 3 основным причинам, по которым расширять Bitcoin Script трудно, несмотря на очевидные теоретические преимущества.
1КристаллизоватьНапишите 1 предложение о фундаментальном противоречии между добавлением программируемости и сохранением стабильности консенсуса в децентрализованной системе.

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

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

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

EN PT ES ZH JA KO DE FR MS