Web3. Смарт-контракты в модели UTXO: краткий обзор
Историческое развитие смарт-контрактов в Bitcoin
Bitcoin Script (2009)
С момента запуска Биткоина в 2009 году в сеть была встроена базовая возможность примитивных смарт-контрактов через язык сценариев Bitcoin Script.
Это простой стековый язык, намеренно не являющийся Тьюринг-полным – в нём отсутствуют циклы и рекурсия.
Такой дизайн выбран Сатоши Накамото ради безопасности и предсказуемости выполнения: контракт может только проверить несколько условий (подписи, хеши, таймлоки и т.д.) и либо разрешить трату средств, либо отклонить её.
Ранние сценарии позволяли реализовать мультисиг-транзакции, блокировки по времени и т.н. "хеш-замки" для простых контрактов вроде условного депозитария, атомарных свопов или платёжных каналов.
(Но de facto этого хватало для большинства операций, которые тогда вообще предполагалось).
Однако функциональность Script была сильно ограничена: многие потенциально опасные опкоды были отключены, а сложные программы не поддерживались.
P2SH и мультиподписи (2012)
В апреле 2012 года был активирован софтфорк BIP-16 (Pay-to-Script-Hash), который позволил оплачивать не напрямую открытым ключам, а хешам произвольного скрипта.
P2SH расширил гибкость контрактов: отправитель мог отправить средства на адрес-хеш, а получатель при трате раскрывал сценарий и удовлетворял его условия (например, предоставлял M-of-N подписи в случае мультиSig).
Благодаря P2SH мультисиг-кошельки получили широкое распространение – скрипт с несколькими ключами прятался за адресом, что упростило использование мультиSig.
Также P2SH снизил нагрузку на отправителей транзакций, переместив хранение сложного скрипта на сторону получателя.
Таймлоки CLTV/CSV (2015–2016)
В дальнейшем возможности Bitcoin Script расширялись новыми опкодами. В 2015 году обновление BIP-65 ввело оператор OP_CHECKLOCKTIMEVERIFY (CLTV) – абсолютный таймлок, запрещающий тратить выход до наступления заданного времени или номера блока.
(Это, кстати, было одним из первых, что подтолкнуло меня к темпографии).
В 2016 году BIP-112 добавил OP_CHECKSEQUENCEVERIFY (CSV) – относительный таймлок, позволяющий блокировать выход на определённое количество блоков со времени предыдущей транзакции.
Эти улучшения открыли путь к более сложным схемам: появились контракты с отложенной выплатой (например, выпуск средств только по истечении срока) и стали возможны более безопасные платежные каналы и диспуты (благодаря CSV, использующемуся в Lightning Network).
Также со временем были разблокированы некоторые ранее отключенные опкоды (например, OP_NOP2 переопределён под CLTV), что постепенно повышало выразительность Script.
SegWit и развитие Script (2017)
Софтфорк Segregated Witness (SegWit) в 2017 году (BIP-141) значительно изменил формат транзакций, убрав malleability (коротко: transaction malleability — уязвимость, при которой идентификатор транзакции (txid, хэш) можно было изменить без изменения самой сути транзакции: например, меняя подписи или незначительные данные в скрипте) и введя понятие версий скриптов (Script Versioning).
[Примечание: понятие "маллеабильность" пока не прижилось, поэтому оставляю его EN-вариант].
SegWit позволил добавлять новые опкоды и менять семантику скриптов без хардфорка. Он же увеличил допустимый размер сценариев, переместив данные "свидетеля" (подписи и скрипты) вне основного блока.
На практике SegWit проложил дорогу для будущих обновлений вроде Taproot, дав более гибкую основу для эволюции языка Script.
Lightning Network и DLC (2018–2020)
В этот период стали развиваться решения второго уровня, использующие скрипты Биткоина как базис.
Конечно же, отдельно выделю Lightning Network (2018) – сеть платёжных каналов – основана на смарт-контрактах типа HTLC (Hash Time-Locked Contracts), которые комбинируют хеш-замок и таймлок.
(Ещё раз: хеш-замок (hashlock) - криптографический примитив, который позволяет заблокировать средства на адресе до тех пор, пока не будет предоставлен соответствующий хеш).
Каналы Lightning позволяют пользователям мгновенно обмениваться средствами off-chain, прибегая к блокчейну только для открытия и закрытия каналов.
Это стало первым массовым применением сложных биткоин-контрактов, обеспечив масштабирование микро-платежей.
Discreet Log Contracts (DLC, ~2020)
Ещё один важный пример: контракты для ставок и деривативов с использованием оракулов, где условие выплаты зависит от подписи оракула. И это... DLC! Реализуются они через адаптированные подписи и скрипты, сохраняя нужный уровень конфиденциальности.
Lightning и DLC продемонстрировали, что даже с ограниченным Script можно выстраивать многокомпонентные финансовые приложения, однако их реализация требует нескольких транзакций и оффчейн-взаимодействий.
Taproot и Schnorr (2021)
Кульминацией эволюции смарт-контрактов на базе UTXO стало масштабное обновление Taproot, активированное в ноябре 2021 года.
Taproot объединяет серию BIP (340-341-342), предложенных Грегори Максвеллом и др., и принёс в три ключевых новшества:
- Подписи Шнорра (Schnorr signatures): новый алгоритм цифровой подписи, более компактный и поддерживающий агрегацию ключей. Несколько подписей могут быть объединены в одну – это уменьшает размер сложных транзакций и делает многоподписи неотличимыми от обычных.
- MAST (Merkelized Abstract Syntax Tree): древо Меркла, позволяющее коммитить множество условий контракта и раскрывать только исполненный путь. Вместо включения всех условных скриптов в блокчейн открывается лишь ветка, соответствующая выполненному условию. Это резко повышает конфиденциальность и эффективность сложных контрактов – неиспользованные условия остаются скрытыми.
- Tapscript: обновлённая версия Bitcoin Script (версия 1), снявшая некоторые ограничения и добавившая новые возможности. Tapscript поддерживает более длинные скрипты, облегчает введение новых опкодов и повышает гибкость в написании контрактов.
Taproot стал самым значимым улучшением функциональности Bitcoin со времён SegWit.
Благодаря ему сложные смарт-контракты стали дешевле, компактнее и приватнее. Например, до Taproot мультисиг-транзакция росла в размере линейно от числа подписей, а сложный скрипт сразу выдавал наблюдателям все свои условия.
После Taproot – имеем: одна объединённая подпись и скрытые в хеше альтернативные условия.
Список ниже сравнивает до и после Taproot:
Конфиденциальность сложных контрактов:
Комиссии для сложных сценариев:
Максимальная сложность условий:
Различимость типов транзакций:
Принцип MAST. Условия сложного смарт-контракта хранятся в виде древа Меркла. В корень (Hash(script)) закоммичен хеш от двух ветвей условий; каждое условие (A, B, C, D) также захешировано и включено в древо.
При исполнении раскрывается только соответствующая ветвь, а не все сценарии сразу. Это-то как раз и экономит место и улучшает приватность.
Налог на сложность. Taproot значительно снизил “налог на сложность” для разработчиков: сложные сценарии больше не облагаются непропорционально высокими комиссиями.
Кроме того, Taproot сделал возможным, чтобы разные типы транзакций стали неразличимы на блокчейне – простой перевод, открытие Lightning-канала или исполнение контракта выглядят одинаково.
Это повысило базовую анонимность пользователей и устранило стигматизацию сложных контрактов.
Современные расширения (2022–2025)
После Taproot в комьюнити "возрос интерес к дальнейшему расширению программируемости без ущерба безопасности". Появились новые протоколы и языки. Всё перечислять не буду, но ряд - отмечу:
- Miniscript (2019) – вспомогательный язык от Pieter Wuille и др. для упрощения создания Bitcoin Script. Он ввёл шаблонные фрагменты и стандартизованные композиции условий, позволяя безопасно генерировать скрипты сложных политик (например, мультиподпись с таймлоком) из понятного описания. Miniscript не требует изменений в протоколе – это уровень абстракции для разработчиков.
- Taproot Assets / Taro (2022) – протокол от Lightning Labs для выпуска пользовательских активов (токенов) на базе биткоина. Анонсированный как Taro в 2022, он к 2023 году переименован в Taproot Assets. Протокол использует возможности Taproot для встраивания данных об активах в выходы транзакций, сохраняя приватность и эффективность сети. Посредством техники taptweak данные токена коммитятся в публичный ключ Taproot, не раскрываясь напрямую в блокчейне. Это позволяет создавать и перемещать токены по UTXO, а также открывать для них каналы Lightning. Таким образом, Taproot Assets "превратил Битокин-сеть в мульти-активную платформу, сохраняя доверенность и децентрализацию базового уровня".
- Simplicity (2023) – долгожданный высоковыразительный язык смарт-контрактов от Blockstream. Идея Simplicity была предложена еще исследователем Расселом О’Коннором около 2012 года, а первая реализация запущена на сайдчейне Liquid в 2023 году. Simplicity рассчитан на формальную верификацию и безопасность, избегая опасностей полного по Тьюрингу языка (в частности, исключены бесконечные циклы). При этом он гораздо более гибок, чем Bitcoin Script, и позволяет строить сложную логику. Важно, что Simplicity следует UTXO-модели – контракты оперируют выходами, а не аккаунтами. Запуск Simplicity на Liquid "показал возможность реализации продвинутых децентрализованных приложений с сохранением безопасности и проверяемости Биткоина". Ожидается, что в будущем Simplicity может быть предложен и для основной сети Bitcoin (через софтфорк), если докажет надёжность.
Помимо вышеперечисленных проектов, ведутся исследования и других подходов к расширению функциональности смарт-контрактов в биткоине.
Скажем, в 2023 году был представлен концепт BitVM, предлагающий реализовать Тьюринг-полные вычисления путём сочетания оффчейн-вычислений и ончейн-проверок.
Также существуют сайдчейны вроде RSK (Rootstock), где биткоин используется как залог, а параллельная сеть поддерживает виртуальную машину совместимую с Ethereum (EVM) для запуска Solidity-контрактов.
Эти решения дополняют экосистему, оставаясь внешними по отношению к основной сети Bitcoin, поэтому их касаюсь лишь вскользь.
Модель UTXO vs модель аккаунтов: возможности, удобство, безопасность, гибкость
Биткоин использует UTXO-модель (Unspent Transaction Output), тогда как, например, Ethereum – модель аккаунтов и балансов. Различия этих моделей определяют возможности и ограничения смарт-контрактов.
Представление состояния
В UTXO-модели состояние - это набор непотраченных выходов транзакций.
Каждый выход несет определённое количество BTC и условие траты (скрипт). Контракт в биткоине существует имплицитно как условие в UTXO и не хранит собственного состояния между транзакциями.
В аккаунтной модели состояние хранится напрямую на аккаунте: контракт – это аккаунт с собственным хранилищем данных (storage), который может менять переменные в себе при выполнении, а платформа отслеживает глобальное состояние всех аккаунтов.
Тьюринг-полнота и выразительность
Биткоин-скрипт заведомо не является Тьюринг-полным – он ограничен по наборам команд и не может выполнять произвольные вычисления или циклы.
Ethereum же спроектирован Тьюринг-полным: смарт-контракт на EVM может выполнять любой алгоритм, ограниченный только затратой газа. Это делает Ethereum намного более гибким (можно реализовать любые DeFi-протоколы, DAO, сложные взаимодействия и т.д.), тогда как Биткоин-функциональность сосредоточена на базовых финансовых сценариях (мультиподписи, хеш-замки, таймлоки и их комбинации).
Взаимодействие контрактов
В Ethereum контракты могут свободно вызвать друг друга, передавать сообщения и данные – это единое исполнение в рамках глобального состояния.
В Биткоине контракты не имеют механизма прямого взаимодействия: каждый UTXO изолирован, и сценарий выполняется только при попытке потратить данный выход. Невозможно, чтобы один скрипт инициировал выполнение другого на блокчейне без отдельной транзакции. Это ограничение делает невозможными сложные взаимозависимые DAPPs на самом блокчейне.
Языки и инструменты разработки
Для Биткоин-скриптов практически нет высокоуровневых языков. Прямое программирование ведётся на Script (ассемблероподобном языке), либо используются библиотеки шаблонов (те же Miniscript).
Напротив, экосистема Ethereum предоставляет разработчикам удобные языки вроде Solidity, Vyper, инструментальные средства, фреймворки для тестирования и развертывания.
Соответственно - порог входа в разработку Биткоин-контрактов выше, требуются глубокие знания криптографии и особенностей UTXO, тогда как в Ethereum понятие аккаунта ближе к привычной модели баз данных, и инструментарий потому богаче. Несравненно!
Детерминизм и выполнение
Скрипты в Биткоине полностью детерминированы и исполняются очень быстро, по сути проверяя несколько условий.
В Ethereum же выполнение контракта может зависеть от потребления газа: сложный контракт может не завершиться, если исчерпан лимит газа, что добавляет неопределённость. Кроме того, изменение цены газа или порядка транзакций (mempool) влияет на исполняемость.
В Биткоине таких понятий нет – либо скрипт проходит, либо нет, и это однозначно определяется входными данными. Таким образом, Биткоин-контракты более предсказуемы по выполнению, а в EVM бывают нюансы с хронометрацией, reentrancy и пр.
Безопасность и риски
Консерватизм Биткоина означает меньшую поверхность для атак. Упрощённый сценарный язык сводит к минимуму возможные баги: в сети Bitcoin не было эквивалентов печально известных уязвимостей вроде The DAO (взлом смарт-контракта в Ethereum в 2016 г., повлекший потери ~$50 млн)... но зато была проблема 2010 (хотя и на совсем другом уровне)!
Ограниченная функциональность предотвращает целый класс ошибок, например рекурсивные вызовы контрактов или переполнение вычислений.
В Ethereum же богатство возможностей "идёт рука об руку с рисками – истории о багах в смарт-контрактах, хакерских эксплойтах и провалившихся ICO широко известны". Но напомню свою точку зрения: всё это крайне не критично для экосистемы в целом.
Собственно, поэтому Ethereum-разработчики со временем внедрили лучшие практики и даже формальную верификацию контрактов, чтобы повысить надёжность.
Но принципиально тут вот что: Bitcoin выбирает безопасность и простоту ценой гибкости, а Ethereum – гибкость ценой усложнения безопасности.
Ниже представлено краткое сравнение моделей смарт-контрактов Bitcoin vs Ethereum:
Важно отметить, что ограничения Биткоина намерены и философски обоснованы. (По крайне мере - так думают BTC-максималисты)).
Биткоин был задуман прежде всего как устойчивая и доверенно минимальная система передачи ценности, поэтому любой потенциал для уязвимости воспринимается как недопустимый компромисс.
Ethereum же с самого начала позиционировался как платформа для децентрализованных приложений, то есть целью была максимальная функциональность.
В результате две экосистемы не столько конкурируют, сколько дополняют друг друга: Биткоин отлично справляется с задачами, требующими абсолютной надёжности и простоты (цифровое золото, безопасные сделки, хранение стоимости и т.п.), а Ethereum – с задачами, где нужна комплексная логика и быстрые инновации (DeFi, игровые dApp, токенизация).
И я вижу в этом плюс внешней децентрализации. А вы?
Краткое описание решения для смарт-контрактов в Биткоине
Несмотря на ограничения, в экосистеме Биткоина, как я уже рассказал, существует ряд технологий и инструментов, которые расширяют возможности смарт-контрактов.
Рассмотрим теперь их, но с другого ракурса?..
Bitcoin Script
Базовый язык смарт-контрактов. Представляет собой набор опкодов для проверки подписи (OP_CHECKSIG), хешей (OP_HASH160 и др.), сравнения, логических операций и т.д.
Script работает по принципу условного расходования: "если выполнены условия, заложенные в выходе, то средства могут быть потрачены".
Примеры сценариев: требование подписи определённого приватного ключа (стандартный P2PKH), M-of-N мультиподпись (OP_CHECKMULTISIG), таймлоки (OP_CLTV/CSV) для отложенных платежей, хеш-замки для атомарных свопов.
Повторюсь! Bitcoin Script не Turing-полный и ограничен намеренно ради безопасности, поэтому любые сложные контракты должны разбиваться на комбинации этих простых примитивов.
Тем не менее, Script проверен временем – за более чем 15 лет (!) не было критических ошибок в его работе на блокчейне, а простота значительно облегчает аудирование контрактов.
Большинство биткоин-транзакций (например, P2PKH, P2SH) – на самом деле короткие скрипты, встроенные в стандартные шаблоны, поэтому Script используется повсеместно, хотя и незаметно для обычных пользователей.
Miniscript
Это уже высокоуровневый каркас для написания скриптов, предложенный исследователями из Blockstream (Питер Вюлле, Эндрю Поэлстра и др.).
Miniscript задаёт структурированный язык для построения сложных условий из базовых логических блоков (AND, OR, переменные условия и пр.).
Вместо написания Script вручную, разработчик описывает логику контрактов в виде древа или выражения Miniscript, а затем инструмент автоматически компилирует его в корректный Bitcoin Script.
Важное преимущество Miniscript – проверка корректности и исчерпывающее перечисление всех возможных путей исполнения.
Это помогает убедиться, что не останется непредусмотренных способов потратить средства. Miniscript особенно полезен для создания сложных политик доступа: например, "средства можно потратить либо 2 из 3 ключей сразу, либо одним ключом через 1 год ожидания" – такие условия легко выразимы и анализируемы.
К 2025 году Miniscript я бы обозначил как зрелый проект, который используется в ряде кошельков и приложений, что снижает порог входа для разработчиков смарт-контрактов.
MAST
Ещё раз - Taproot как обновление протокола, уже подробно описанное выше. Но!
Taproot (BIP-340–342) ведь внедрил подписи Шнорра, MAST и Tapscript, существенно повысив возможности смарт-контрактов на первом уровне.
То есть для нас важно, что Taproot объединяет сложные условия в один выход, делая контракт невидимым до момента исполнения нужной ветви.
Концепция MAST (Merkelized Abstract Syntax Tree) позволяет хранить варианты сценария в свёрнутом виде: условия хешируются и объединяются в древо Меркла, корень которого включается в выход.
При трате нужно раскрыть только задействованный скрипт и путь по древу, что экономит блокчейн-пространство и не раскрывает неиспользованные условия.
Приведу банальный пример: контракт на наследование может предусматривать несколько альтернатив (потратить по ключу владельца; либо, в случае его неактивности 1 год, по ключу наследника + нотариуса).
В модели до Taproot пришлось бы публиковать сразу все эти условия на блокчейне (через P2SH), что дорого и главное - чересчур заметно.
С Taproot же условия скрыты до реализации: если владельцем потрачено вовремя, вообще никто не узнает о существовании альтернативного сценария. (И опять же - это всё про... темпографию!).
Таким образом, Taproot/MAST расширяет сложность логики, допустимой в одном выходе, без ущерба для конфиденциальности и с меньшими комиссиями. Кроме того, Taproot открыл дорогу новым видам приложений (см. ниже и выше: Lightning, DLC, токены) и "снизил стимулирующие затраты для внедрения смарт-контрактов в бизнес-практики".
Taproot Assets (Taro)
Решение для выпуска и управления активами, используя возможности Taproot.
Как я и обозначил: Taproot Assets позволяет создавать токены (в т.ч. стейблкоины, NFT) непосредственно на блокчейне биткоина. Технически, это реализовано через особые Taproot-выходы с дополнительными данными.
Главный приём aka фича - taptweak: путём модификации публичного ключа Taproot в него вплетается хеш данных актива, при этом со стороны блокчейна выход выглядит как обычный P2TR-адрес.
Информация об активах хранится оффчейн (у эмитента и держателей) в виде доказательств (путей по Merkle-древу), а в блокчейн передаются лишь минимальные сведения для проверки целостности.
Такой гибридный подход (называемый клиентской валидацией) позволяет масштабировать выпуск токенов без перегрузки узлов сети. Важной особенностью Taproot Assets является совместимость с Lightning Network – выпущенные токены могут депонироваться в Lightning-каналы, что обеспечивает мгновенные оффчейн-расчеты с токенизированными активами.
Таким образом, Bitcoin "превратился не только в сеть для BTC, но и в мульти-активную систему, сохраняя при этом безопасность PoW и ликвидность основной сети".
Taproot Assets к 2025 году ещё находится на стадии активной разработки и тестирования, но считается одним из самых перспективных направлений, чтобы “научить” Биткоин работать с активами и сложными контрактами без изменения консенсуса.
Simplicity
Тоже про него выше уже чуть сказал: это новый язык смарт-контрактов, разработанный Blockstream для безопасного расширения возможностей Bitcoin.
Simplicity задуман как прямой преемник Bitcoin Script – низкоуровневый язык, исполняемый в UTXO-модели, но гораздо более выразительный и проверяемый формально.
Он опирается на зрелые, а главное - научные подходы: строгая семантика, возможность математической проверки свойств контракта до его разворачивания (чего трудно достичь с текущим Script или EVM).
При этом Simplicity избегает опасных конструкций (например, отсутствуют бесконечные циклы), что делает его сильно ограниченным по ресурсам, но всё же полноценным языком (функционального стиля).
В 2021–2022 гг. Simplicity прошёл тестирование в Liquid – сайдчейне биткоина. Наконец, в 2023 г. Blockstream официально запустила поддержку Simplicity в Liquid Network, "позволив разработчикам писать смарт-контракты для этого сайдчейна... Это событие называют важным шагом к появлению (полноценных) "умных контрактов на базе Биткоина", поскольку Liquid служит полигоном перед возможной интеграцией Simplicity в основной блокчейн".
Simplicity призван решить многие ограничения Script, сохраняя при этом принципы биткоина – UTXO-модель, детерминированность, отсутствие неожиданных побочных эффектов.
Если эксперименты с Simplicity окажутся успешными, можно ожидать, что в будущем будет предложен софтфорк для его поддержки в мейннете, что откроет новую эру для биткоин-разработки смарт-контрактов... Но это пока всё - желания, хотя и вполне обоснованные.
Другие инициативы
В экосистеме Биткоина существуют и иные решения, расширяющие функциональность контрактов.
Например, RGB Protocol – проект с открытым исходным кодом, разрабатываемый сообществом LNP/BP Standards, использует идеи, схожие с Taproot Assets, для выпуска токенов и запуска смарт-контрактов с проверкой на стороне клиента
Liquid Network – федеративный сайдчейн, запускающий новые функции (конфиденциальные транзакции, выпуск активов, те же смарт-контракты Simplicity) без рисков для основной сети.
Rootstock (RSK) – сайдчейн, объединённый с Биткоином через двухсторонний пег (двухсторонний пег (two-way peg) в нашем контексте и других криптовалют - это механизм, который позволяет переводить активы между основной блокчейн- сетью и сайдчейном в обе стороны) и майнинг слияния, поддерживающий виртуальную машину Ethereum (EVM): это позволяет использовать привычные Solidity-смарт-контракты, залочив BTC - в эквивалент RBTC.
Также, в 2023 году был предложен экспериментальный дизайн BitVM, который в теории позволяет достичь вычислительной полноты: две стороны могут оффчейн вычислить произвольный алгоритм, а в случае спора – доказать на блокчейне, кто прав, через серию шагов (интерактивное доказательство).
Ограничения модели UTXO для смарт-контрактов
Несмотря на прогресс, UTXO-модель накладывает ряд фундаментальных ограничений на смарт-контракты. Рассмотрю в этой статье только основные из них.
Масштабируемость
Биткоин-сеть преднамеренно ограничена по пропускной способности (размер блока, ок. транзакций/с и др.) во имя децентрализации.
В таких условиях масштабировать сложные смарт-контракты на первом уровне затруднительно. Мягко говоря :). Каждый шаг логики зачастую требует отдельной транзакции (например, открытие/закрытие канала Lightning, публикация исхода DLC), что увеличивает нагрузку на блокчейн.
У Ethereum, напротив, контракт может выполнить серию шагов внутри одной транзакции.
С другой стороны, UTXO-модель имеет преимущество параллелизма: независимые транзакции над разными UTXO теоретически могут обрабатываться одновременно, облегчая проверку. Но (!) на практике (!!) ноды Биткоина проверяют всё последовательно, а основное ограничение – размер блока – остаётся. (Если вы подумали, что размер блока - это решение, то... нет: см. на Bitcoin Cash, Bitcoin SV и др. подобные решения: это всё лишь убило безопасность).
В итоге Биткоин делает упор на масштабирование через второй слой (Lightning, сайдчейны), вынося активность смарт-контрактов off-chain. (Ничего не напоминает?)).
Это позволяет достичь огромной пропускной способности (Lightning совершает тысячи транзакций в секунду), но требует дополнительных соглашений и не всем сценариям подходит.
Выразительность и логическая сложность
Bitcoin Script, даже с Taproot, остаётся ограниченным по возможностям: нет циклов, нет произвольных вычислений (например, умножение, хеширование в цикле), строго фиксированы типы данных (числа, байтовые строки).
Хранение состояния между транзакциями отсутствует – контракт не может, например, накапливать данные или счётчики внутри себя по дефолту.
Любая сложная логика должна быть либо разбита на серии транзакций, либо перенесена на внешний уровень (сервер, оракул, пользовательское ПО и т.п.). Это сужает класс возможных приложений.
Например, нельзя написать прямо на Биткоине сложный DeFi-протокол автоматического кредитования – для этого понадобятся централизованные сервисы или переход на Ethereum, или же что-то, что обсуждали выше.
Даже реализуемые на Биткоине вещи (скажем, атомарные свопы или DLC) требуют от участников вручную координировать действия, не говоря уже о поддержке многих пользователей сразу. Или полуавтомат. Или автомат, но сложный...
Модель аккаунтов Ethereum здесь значительно мощнее – контракты могут самостоятельно выполнять действия при вызове, менять свое состояние, вызывать другие контракты, что позволяет создавать сложные dApps.
Ограниченная выразительность – плата за простоту и безопасность: меньше возможностей – меньше поверхностей для атак. Однако это означает, что для сложных dApp БитОк не подходит без вспомогательных протоколов.
Приватность контрактов
Исторически смарт-контракты в Биткоине страдали от низкой приватности.
До Taproot любой нестандартный сценарий был виден в блокчейне: если использована P2SH-мультиподпись или HTLC, то при расходовании выход раскрывал весь скрипт. Наблюдатель мог сразу определить тип сделки (например, Lightning-канал, escrow и т.д.) и участников.
Taproot сильно улучшил ситуацию, сделав контракты неразличимыми от обычных транзакций при кооперативном исполнении.
Например, закрытый по взаимному согласию Lightning-канал теперь выглядит как обычный платёж с одной подписью.
Однако ограничения остаются: если наступает неосновной сценарий (например, форс-погашение канала по тайм-ауту), то соответствующий Taproot-скрипт раскрывается. Значит, в редких случаях контрактную логику всё же можно увидеть? Получается, что да (но тут нужно много уточнений).
Кроме того, сама UTXO-модель, с одной стороны, даёт лучшее базовое псевдо-анонимность, позволяя использовать новые адреса для каждой транзакции.
С другой – она открыта для ончейн-анализа: все UTXO полностью трассируемы, и без специальных мер (coinjoin, микширование) можно связать адреса одного пользователя.
В Ethereum аналогично – аккаунт-модель даже хуже в том, что один адрес-контракт агрегирует все действия, облегчая отслеживание. Однако Ethereum-сообщество активнее разрабатывает L2-решения для приватности (пример: zk-Rollups, Aztec), тогда как в Биткоине фокус на приватности – это именно скрытие условий контрактов (Taproot, конфиденциальные транзакции на Liquid и подобное) и смешивание монет (CoinJoin).
В целом, Биткоин обеспечивает отличную приватность простых платежей, но сложные контракты всё ещё могут выдавать информацию о себе при нестандартных исходах.
Безопасность и аудит
Парадоксально, но консерватизм Биткоина можно назвать... и ограничением :).
Строгие правила Script означают, что некоторые полезные функции не могут быть реализованы без ослабления безопасности.
Например, интеграция данных из внешнего мира требует оракулов – специальных посредников, подписывающих информацию оффчейн (курсы валют, результаты матчей и прочее).
В Ethereum оракулы тоже нужны, но там контракт может напрямую запрашивать их при вызове, а в Биткоине всё приходится проектировать как транзакции с мультиподписью, где одна из сторон – оракул (DLC именно так и работали базово).
Ещё пример – автоматическое исполнение: в Ethereum можно программно инициировать действие (если кто-то вызовет функцию), а в Биткоине контракт никогда не исполнится сам по себе – только когда пользователь решит потратить UTXO.
Нет эквивалента крон-джобов (автоматизированные задачи, которые выполняются по расписанию, часто для поддержания работы блокчейн-сети или сервисов иных) или смарт-контрактов, запускаемых по таймеру.
Это ограничение мешает создавать приложения типа автоплатежей или перманентно работающих протоколов на первом уровне.
С точки зрения аудита, ограниченная функциональность – благо (легче проверить безопасность простого скрипта). Но сложные схемы, распределенные по многим транзакциям и участникам, сложнее анализировать на корректность, чем один автономный смарт-контракт.
То есть безопасность Биткоина базового уровня очень высока, но построение сложных приложений требует огромной тщательности от разработчиков и пользования сторонними библиотеками (что увеличивает доверие к ним). Сколько раз я это уже повторил? А всё дело в том, что с РАЗНЫХ сторон к этому выводу можно прийти и это: база. Поэтому лучше уж я повторю.
Не случайно, появление Miniscript и Simplicity – попытки дать разработчикам безопасные инструменты, чтобы сократить вероятность ошибки при программировании контрактов.
Кроме того, любое изменение в правилах (Б/б)иткоина проходит долгий путь согласования – добавить даже небольшой опкод (как предлагаемое OP_CHECKTEMPLATEVERIFY для ковенантов - bitcoin covenants - это механизм, который позволяет более гибко управлять передачей биткоинов), добавляя новые правила и ограничения на транзакции занимает годы обсуждений.
Это "ограничение на развитие" тоже влияет на смарт-контракты: инновации внедряются медленно, пока сообщество не будет уверено в их безопасности. И будет ли?..
Доводы, но не выводы
Модель UTXO накладывает жёсткие рамки, но они же служат прочным фундаментом Биткоина. Другие подходы я пока даже не рассматривал. Но они есть.
Безопасность, предсказуемость и простота проверки – ключевые приоритеты Биткоина как финансового протокола.
Поэтому многие ограничения являются следствием осознанного выбора. В результате смарт-контракты в Биткоине занимают свою нишу: это, как правило, простые и критичные приложения (хранение, мультиподписи, обмен ценностями), где надёжность важнее функциональности.
Более сложные же децентрализованные приложения нашли приют на платформах вроде Ethereum. Иначе и не скажешь :). Даже шире: в EVM-семействе!
В 2025 году очевидно, что оба подхода сосуществуют: Биткоин и UTXO-модель обеспечивают базовый уровень доверия и сохранности стоимости, тогда как account-платформы дают песочницу для экспериментов и разнообразных сервисов. Разве это плохо?! Нет!
В идеале, экосистема будет использовать сильные стороны каждого: Биткоин - для максимально надёжных смарт-контрактов (например, хранение активов, простейшие условия), а другие сети или надстройки – для богатой логики.
Такой баланс специализаций и взаимодополняемости и станет, надеюсь, основой развития смарт-контрактов в будущем...
Дополнительно
- Поупражняйтесь в де-кодинге: https://live.blockcypher.com/btc/decodetx/
- Изучите материал: https://www.gate.com/ru/learn/articles/op-net-and-arch-exploring-smart-contracts-on-bitcoin/4214
- И большую статью: https://arxiv.org/abs/2406.07700