1. Введение
Модель непотраченных выходов транзакций (UTXO) Биткоина, хотя и элегантна для параллельного перевода средств, имеет значительные ограничения для реализации сложных, сохраняющих состояние смарт-контрактов из-за отсутствия общего изменяемого состояния. Ковенанты появляются как критически важный языковой примитив, предложенный для расширения Биткоин-скрипта, позволяющий транзакции накладывать ограничения на скрипты будущих тратящих транзакций. В данной статье рассматривается пробел в формальных, абстрактных моделях для ковенантов, которые с момента их появления примерно в 2013 году описывались в основном с низкоуровневой, ориентированной на реализацию точки зрения. Предоставляя формальное обоснование, работа направлена на упрощение рассуждений о свойствах контрактов, позволяет специфицировать продвинутые сценарии использования, выходящие за пределы текущих возможностей Биткоина, и способствует разработке абстракций программирования более высокого уровня.
2. Чистая модель Биткоина
В статье адаптируется формализация базовой модели транзакций Биткоина. В модели UTXO состояние блокчейна определяется набором непотраченных выходов транзакций. Каждый выход содержит значение (количество биткоинов) и scriptPubKey (скрипт блокировки), который определяет условия, необходимые для его траты. Тратящая транзакция предоставляет scriptSig (скрипт разблокировки) и ссылается на UTXO, который она хочет потратить. Валидация включает выполнение объединенных скриптов. Ключевым моментом является то, что стандартный Биткоин-скрипт ограничен: он не может интроспектировать или ограничивать структуру тратящей транзакции за пределами проверки подписи и базовой арифметики/логики, что препятствует созданию контрактов, обеспечивающих многошаговые протоколы.
3. Формальная модель ковенантов
Основной вклад — это формальная модель, абстрагирующая предлагаемые опкоды ковенантов (такие как OP_CHECKTEMPLATEVERIFY).
3.1. Примитивы и синтаксис ковенантов
Модель вводит предикаты ковенантов как расширения Биткоин-скрипта. Ковенант по сути является ограничением $C(T_x, T_{next})$, которое оценивается как истина или ложь, где $T_x$ — текущая тратящаяся транзакция, а $T_{next}$ — предлагаемая тратящая транзакция. Предикат может проверять поля $T_{next}$, такие как её выходные скрипты, суммы или временные блокировки.
3.2. Операционная семантика
Правило валидации расширяется: для UTXO с ковенантом валидация тратящей транзакции $T_{next}$ требует не только того, чтобы её scriptSig удовлетворял исходному scriptPubKey, но и того, чтобы предикат ковенанта $C$ выполнялся для пары $(T_x, T_{next})$. Это формально определяется с помощью правил операционной семантики, которые интегрируют проверку ковенанта в существующую логику валидации Биткоина.
3.3. Рекурсивные ковенанты и конечные автоматы
Мощным вариантом является рекурсивный ковенант, где $C$ может требовать, чтобы выход $T_{next}$ сам содержал тот же (или связанный) ковенант $C'$. Это позволяет реализовать конечные автоматы на Биткоине: каждая транзакция представляет переход состояния, а ковенант гарантирует соблюдение правил автомата в цепочке транзакций. В статье это формализуется как последовательность транзакций $T_1, T_2, ..., T_n$, где для каждого $i$ выполняется $C(T_i, T_{i+1})$.
4. Спецификация сложных контрактов в Биткоине
Формальная модель применяется для спецификации контрактов, которые в настоящее время невыразимы или громоздки в чистом Биткоине.
4.1. Хранилища и вывод с временной блокировкой
Ковенанты могут создавать «хранилища», из которых украденные средства могут быть восстановлены. Транзакция может требовать, чтобы любой крупный вывод сначала направлялся в выход с временной блокировкой, позволяя владельцу отменить его, если он был несанкционированным. Это специфицируется ковенантом, который проверяет поле nLockTime и структуру выходов $T_{next}$.
4.2. Платежные каналы и Lightning Network
Хотя Lightning Network существует, ковенанты могут упростить и обезопасить его базовую конструкцию. Они могут требовать, чтобы закрывающая транзакция канала была самым последним состоянием, предотвращая вещание устаревших состояний, ограничивая тратящую транзакцию соответствием предварительно подписанному обновлению.
4.3. Примитивы децентрализованных финансов (DeFi)
Становятся возможными простые конструкции DeFi, такие как обеспеченные долги или некастодиальные свопы. Ковенант может заблокировать средства в транзакции, которая может быть потрачена только транзакцией, представляющей действительное криптографическое доказательство платежа от контрагента или ликвидации.
5. Примитивы языков высокого уровня
В статье обсуждается, как ковенанты могут служить целью компиляции для языков контрактов высокого уровня. Примитивы, такие как «вывести после времени T», «потратить только если контрагент подписал» или «перейти из состояния A в состояние B», могут быть напрямую отображены на конкретные ограничения ковенантов, повышая уровень абстракции для разработчиков контрактов на Биткоине.
6. Ключевая идея и взгляд аналитика
Ключевая идея: Бартолетти и др. не просто предлагают ещё один опкод для ковенантов; они предоставляют недостающую формальную теорию, которая превращает умный хак в легитимную, анализируемую парадигму программирования для Биткоина. Это ключ, открывающий путь к систематическому проектированию сложных, безопасных контрактов на блокчейнах с моделью UTXO, выходя за рамки ад-хок скриптинга.
Логическая последовательность: Аргументация убедительно проста: 1) Модель UTXO Биткоина не имеет состояния, что ограничивает контракты. 2) Ковенанты, предложенные как решение, плохо формально поняты. 3) Следовательно, мы строим формальную модель. 4) Используя эту модель, мы демонстрируем, что она может выражать ценные, сложные сценарии использования (хранилища, каналы, DeFi). 5) Эта формализация затем естественным образом позволяет проектировать языки более высокого уровня. Это классический конвейер «теория позволяет практике», выполненный с точностью.
Сильные стороны и недостатки: Главная сила — в преодолении разрыва между криптографией/теорией языков программирования и инженерией Биткоина — разрыва, который приводил к дорогостоящим ошибкам в модели на основе счетов Ethereum. Формальная семантика позволяет проводить верификацию свойств, что является огромным преимуществом. Недостаток, неявно признанный, — это политическая экономия Биткоина. Как отмечается в статье, «крайне осторожный подход» Биткоина делает развертывание новых опкодов, таких как ковенанты, титанической задачей, независимо от их формальной элегантности. Успех решений второго уровня, таких как Lightning, без нативных ковенантов также ставит вопросы о необходимости против удобства. Более того, безопасность модели основывается на предположении, что ограничиваемые поля (например, хэши скриптов) достаточны; непредвиденные эффекты взаимодействия с другими опкодами могут остаться.
Практические выводы: Для исследователей эта статья — план: используйте формальные методы для снижения рисков и прояснения обновлений блокчейна. Для разработчиков — начинайте проектировать фреймворки для контрактов уже сейчас, предполагая, что ковенанты будут существовать (как видно на Liquid или Stacks). Для разработчиков протокола Биткоина статья предоставляет строгое обоснование, необходимое для аргументации в пользу BIP 119 (OP_CTV) или аналогичных предложений — она превращает запрос на функциональность в инженерную спецификацию. Самый важный вывод: будущее смарт-контрактов на Биткоине заключается не в подражании Ethereum, а в использовании уникальной парадигмы UTXO+ковенанты для создания нового, потенциально более безопасного и масштабируемого класса децентрализованных приложений.
7. Технические детали и формализация
Формальная модель определяет транзакции, скрипты и валидацию контекстуально. Ключевая техническая деталь — представление ограничения ковенанта. Пусть $ exttt{tx}$ представляет транзакцию. Ковенант можно рассматривать как функцию:
$\text{Covenant}_{\text{cond}} : \texttt{tx}_{\text{current}} \times \texttt{tx}_{\text{next}} \times \sigma \rightarrow \{\text{True}, \text{False}\}$
где $\sigma$ представляет контекст валидации (высота блока и т.д.). Предикат $\text{cond}$ может быть конъюнкцией проверок полей $\texttt{tx}_{\text{next}}$:
$\text{cond} \equiv (\texttt{hashOutputs}(\texttt{tx}_{\text{next}}) = H) \land (\texttt{nLockTime}(\texttt{tx}_{\text{next}}) > T) \land ...$
Это согласуется с предложениями вроде OP_CHECKTEMPLATEVERIFY, который помещает хэш указанных частей тратящей транзакции в стек для сравнения. Рекурсивное свойство формализуется путем обеспечения того, что выход $\texttt{tx}_{\text{next}}$ содержит скрипт $S'$, который сам обеспечивает ковенант $\text{Covenant}_{\text{cond}'}$.
8. Фреймворк анализа и пример использования
Пример: Простой контракт хранилища
Цель: Создать UTXO, который можно потратить двумя способами: 1) Мгновенно, но только на конкретный адрес «холодного хранения». 2) На любой адрес, но только после задержки в 30 дней (позволяя отменить кражу).
Применение фреймворка с использованием формальной модели:
1. Начальный скрипт блокировки (scriptPubKey): Содержит условие ковенанта $C_1$.
2. Ковенант $C_1(T_{vault}, T_{spend})$: Должен оцениваться как Истина. Он проверяет:
a) Путь A (Мгновенный): $\texttt{hashOutputs}(T_{spend}) = H_{cold}$ // Хэш выходов должен соответствовать предварительно зафиксированному адресу холодного хранения.
b) Путь B (Отложенный): $\texttt{nLockTime}(T_{spend}) \geq \text{currentBlock} + 4320$ (30 дней в блоках) И $\texttt{hashOutputs}(T_{spend})$ может быть любым.
3. Валидация: При трате UTXO хранилища с помощью $T_{spend}$, нода Биткоина выполняет скрипт. Она требует подпись от владельца хранилища и проверяет, что $C_1$ выполняется для пары транзакций.
Этот пример демонстрирует, как предикат формальной модели $C(T_x, T_{next})$ инстанцируется конкретными проверками полей следующей транзакции, обеспечивая свойство безопасности (восстановление от кражи), невозможное в базовом Биткоине.
9. Будущие приложения и направления
Формализация открывает несколько будущих направлений:
- Верифицированные компиляторы: Создание компиляторов из языков высокого уровня (таких как расширения Simplicity или Miniscript) в Биткоин-скрипт с внедренными ковенантами, с формальными доказательствами корректности.
- Кросс-чейн ковенанты: Исследование ковенантов, которые обусловливают трату событиями из других блокчейнов или оракулов, с использованием криптографических доказательств, таких как SPV, как намекалось в более ранних работах о «мостах» и недавних исследованиях о роллапах.
- Сохраняющие приватность ковенанты: Интеграция проверок ковенантов с доказательствами с нулевым разглашением (например, с использованием подписей Taproot/Schnorr) для сокрытия логики контракта при её обеспечении, направление, исследуемое в таких проектах, как Ark.
- Формальный анализ безопасности: Использование модели для систематического анализа безопасности предлагаемых конструкций ковенантов против экономических и криптографических атак, аналогично работе, проделанной сообществом IEEE Symposium on Security and Privacy по смарт-контрактам Ethereum.
- Упрощение протоколов второго уровня: Перепроектирование протоколов, таких как Lightning Network или сайдчейны (Liquid), для большей эффективности и минимизации доверия за счет использования нативных ковенантов, сокращая необходимость в сложных сторожевым башнях или федерациях.
10. Ссылки
- M. Bartoletti, S. Lande, R. Zunino. Bitcoin covenants unchained. arXiv:2006.03918v2 [cs.PL]. 2020.
- S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
- J. Poon, T. Dryja. The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. 2016.
- M. Moser, I. Eyal, E. G. Sirer. Bitcoin Covenants. Financial Cryptography 2016 Workshops.
- Bitcoin Improvement Proposal 119 (BIP 119). OP_CHECKTEMPLATEVERIFY.
- G. Wood. Ethereum: A Secure Decentralised Generalised Transaction Ledger. Ethereum Yellow Paper. 2014.
- A. Miller, et al. Hashed Timelock Contracts (HTLCs). 2017.
- R. O'Connor. Simplicity: A New Language for Blockchains. Proceedings of the 2017 Workshop on Programming Languages and Analysis for Security.
- Blockstream. Liquid Network. https://blockstream.com/liquid/
- IEEE Symposium on Security and Privacy. Multiple papers on smart contract security analysis. Various years.