Что такое язык скриптов Bitcoin?

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

Большинство пользователей никогда не сталкиваются с языком сценариев Биткойна напрямую. Их кошельки обрабатывают его незаметно. Но каждый раз, когда вы отправляете или получаете BTC, на тысячах компьютеров одновременно запускаются две небольшие программы, проверяющие, выполнены ли условия расходования средств. Понимание того, как это работает, во многом объясняет, почему Биткойн устроен именно так, а также что он может и чего не может делать по сравнению с такими платформами, как Ethereum.

В этой статье рассказывается о том, как работает скрипт Биткойна, подробно описываются основные типы транзакций, которые он поддерживает, объясняется обновление Taproot, которое в 2021 году модернизировало скриптовый уровень, а также освещается текущее состояние дискуссии об опкоде covenant по состоянию на июнь 2026 года.

Безопасно управляйте своими биткойнами с помощью самостоятельного хранения Приложение «Кошелек Bitcoin.com».

Основные выводы

• Bitcoin Script — это язык программирования на основе стека, встроенный в протокол Биткойн, который определяет условия, при которых можно потратить любой биткойн-выход.
• Каждая транзакция в сети Биткойн содержит два скрипта: скрипт блокировки (ScriptPubKey), заданный получателем, и скрипт разблокировки (ScriptSig), предоставленный отправителем. Для того чтобы транзакция была действительной, оба скрипта должны успешно выполниться.
• Скрипт Bitcoin намеренно не является тюринго-полноценным. В нём отсутствуют циклы, нет сохраняемого состояния между выполнениями, а также установлены жесткие ограничения на размер скрипта. Благодаря этому каждый скрипт гарантированно завершается, что является элементом безопасности, а не ограничением.
• Язык сценариев прошел путь развития, пройдя через пять основных форматов: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) и Taproot (P2TR), каждый из которых расширял возможности, сохраняя при этом обратную совместимость.
• В обновлении Taproot (ноябрь 2021 г.) были внедрены подписи Шнорра, траектории расходования средств на основе MAST для обеспечения конфиденциальности, а также Tapscript — обновленный язык сценариев со встроенным механизмом, позволяющим упростить будущие обновления.
• К реальным примерам использования Bitcoin Script относятся кошельки с мультиподписью, транзакции с временной блокировкой, контракты с блокировкой по хешу и времени (основа сети Lightning), эскроу и контракты с дискретным журналом.
• В отличие от смарт-контрактов Ethereum, Bitcoin Script не имеет состояния: каждый скрипт выполняется в полной изоляции и не имеет доступа к данным о других транзакциях. Это сознательный архитектурный выбор.
• Наиболее активным направлением разработки скриптов Bitcoin в 2026 году являются опкоды ковенантов, в частности OP_CTV (BIP-119) и OP_CAT (BIP-347), которые позволят скриптам задавать ограничения на формат транзакций расходования средств. Ни один из них пока не активирован в основной сети.

Что такое скрипт Биткойна?

Bitcoin Script — это стековый язык сценариев без состояния, встроенный в протокол Биткойн. Каждый выход транзакции в сети Биткойн содержит скрипт блокировки (называемый ScriptPubKey), который определяет условия расходования средств. Любой, кто хочет потратить эти средства, должен предоставить скрипт разблокировки (называемый ScriptSig, или, в транзакциях SegWit и Taproot, данные свидетеля), который удовлетворяет этим условиям.

Структура этого языка заимствована у Forth — минималистичного языка программирования на основе стека, разработанного в 1960-х годах. Как и Forth, Bitcoin Script читается слева направо, работает со структурой данных, называемой стеком, и использует обратную польскую нотацию (RPN), в которой операторы следуют за своими операндами, а не предшествуют им. Он выполняет по одной инструкции за раз, не имеет циклов и не сохраняет данные в памяти между выполнениями.

Именно с этим последним моментом большинство людей сталкивается в первую очередь, знакомясь с описанием Bitcoin Script на уровне протокола: этот язык намеренно не является тюрингополным. Тюрингополный язык способен выполнять любые вычисления при наличии достаточного количества времени и ресурсов. Bitcoin Script же, по замыслу, не способен на это, и причины такого выбора имеют огромное значение для функционирования сети.

Как работает скрипт Биткойна: модель стека

Чтобы понять, как работает Bitcoin Script, необходимо разобраться в принципе работы стека. Стек — это структура данных, которая работает по принципу «последний вошёл — первый вышел» (LIFO). Представьте себе стопку тарелок: добавлять или снимать можно только с верха. В Bitcoin Script данные помещаются в стек, а операционные коды (opcodes) манипулируют тем, что находится на верху.

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

1. Скрипт разблокировки (ScriptSig или witness) предоставляемые лицом, расходующим монеты. При этом в стек помещаются данные, как правило, цифровую подпись и открытый ключ.
2. Скрипт блокировки (ScriptPubKey) связанный с расходованием вывода. Он содержит операционные коды, которые обрабатывают данные стека и проверяют, выполняются ли условия расходования.

Если скрипт выполняется без ошибок и в конце оставляет в стеке ненулевое значение (TRUE), транзакция считается действительной. Если же он завершается с ошибкой или оставляет значение FALSE, транзакция отклоняется узлом и никогда не попадает в блок.

Это выполнение полностью несохраняющее состояние. Скрипт не имеет никакой информации о предыдущих транзакциях, не знает текущих остатков и не сохраняет никаких данных после завершения своего выполнения. Каждый скрипт запускается с нуля, в изолированном режиме, при каждом запуске.

Пошаговое руководство: стандартная транзакция P2PKH

Pay-to-Public-Key-Hash (P2PKH) — это исходный тип транзакции в сети Биткойн, используемый с 2009 года. Адреса P2PKH начинаются с цифры «1». Вот как на практике выглядят поля ScriptPubKey и ScriptSig:

Скрипт разблокировки (ScriptSig):

<подпись> <открытый ключ>

Скрипт блокировки (ScriptPubKey):

OP_DUP OP_HASH160 <хэш открытого ключа> OP_EQUALVERIFY OP_CHECKSIG

Когда узел объединяет и выполняет их одновременно, операции со стеком происходят пошагово:

• Подпись и открытый ключ из ScriptSig помещаются в стек
• OP_DUP копирует открытый ключ, находящийся в верхней части стека
• OP_HASH160 вычисляет хеш дубликата (сначала SHA-256, а затем RIPEMD-160), получая хеш длиной 20 байт
• Хеш открытого ключа из скрипта блокировки помещается в стек
• OP_EQUALVERIFY проверяет, совпадают ли два хеша. Если нет, выполнение останавливается, и транзакция завершается сбоем.
• OP_CHECKSIG проверяет, действительна ли подпись для данного открытого ключа

Если все этапы проходят успешно, стек завершается значением TRUE, и средства разблокируются. Весь процесс занимает миллисекунды и протекает одинаково на каждом узле сети.

Объяснение операционных кодов Биткойна

Операционные коды Биткойна — это отдельные команды, из которых состоит скрипт. Каждая из них занимает один байт, что дает 256 возможных слотов для операционных кодов. Из них в настоящее время в основной сети активны примерно 80. Остальные либо зарезервированы, либо отключены, либо назначены механизму обеспечения обратной совместимости OP_SUCCESS, введённому вместе с Tapscript.

Операционные коды подразделяются на несколько категорий:

• Операционные коды передачи данных поместить в стек такие значения, как открытые ключи, подписи и хеши
• Операционные коды арифметических операций выполнять операции сложения, вычитания и сравнения. При этом следует отметить, что умножение и деление недоступны.
• Криптографические операционные коды включают OP_SHA256, OP_HASH160, OP_SHA1 для хеширования и OP_CHECKSIG для проверки подписи
• Операционные коды управления потоком включить условную логику: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Операционные коды для работы со стеком в том числе OP_DUP (дублировать верхний элемент), OP_DROP (удалить верхний элемент) и OP_SWAP (поменять местами два верхних элемента)

В 2010 году Сатоши Накамото отключил несколько операционных кодов после того, как в их первоначальных реализациях были обнаружены уязвимости. К ним относятся OP_CAT (объединение двух элементов стека), OP_MUL (умножение) и OP_DIV (деление). Их отсутствие оказало долгосрочное влияние на возможности языка Bitcoin Script, и несколько наиболее активно обсуждаемых в 2026 году предложений по модернизации Биткойна касаются вопроса о том, следует ли вновь включить некоторые из них.

Полный справочник по кодам операций, включая шестнадцатеричные значения и описания, можно найти в Страница «Скрипт» в Вики-энциклопедии о биткойне является авторитетным источником.

Почему отсутствие туринговой полноты является преимуществом

Обычно объясняют это тем, что в Bitcoin Script нет циклов, поэтому завершение работы скриптов гарантировано, а сеть защищена от бесконечного выполнения. Это верно, но не в полной мере отражает суть вопроса.

Более глубокий аргумент касается поверхности атаки. Язык, полный по Тьюрингу, способен выражать произвольные вычисления. Эта выразительность одновременно является пространством, в котором обитают ошибки. Язык Solidity в сети Ethereum стал причиной некоторых из самых дорогостоящих уязвимостей программного обеспечения в истории. Взлом DAO в 2016 году был осуществлён за счёт уязвимости реентрантности в смарт-контракте и привёл к убыткам в размере около 60 миллионов долларов по ценам того времени, что в конечном итоге привело к спорному хард-форку сети Ethereum. За несколько лет в экосистеме DeFi в целом в результате атак на смарт-контракты было похищено сотни миллионов долларов.

Скрипт Bitcoin делает этот вид атак структурно невозможным. Невозможно написать скрипт Bitcoin, который вызывал бы другие скрипты, выполнял циклы до изменения условия или сохранял состояние между транзакциями. Каждый скрипт представляет собой ограниченную, завершаемую и поддающуюся проверке программу. Максимальный размер скрипта составляет 10 000 байт. Максимальное количество операционных кодов, не относящихся к операциям push, в одном скрипте — 201. Валидатор всегда может рассчитать затраты на выполнение в худшем случае перед запуском скрипта.

Для сети, стоимость которой исчисляется сотнями миллиардов долларов, такая предсказуемость ценится выше, чем гибкость, от которой приходится отказываться. Ethereum решает проблему неограниченных вычислений с помощью лимитов газа, взимая с пользователей плату за каждый выполненный опкод и останавливая скрипты, у которых заканчивается бюджет. Это работает, но вносит свою собственную сложность и создает новые возможности сбоев. Биткойн же по самой своей архитектуре полностью обходит эту проблему.

Тем не менее, «не является тюринг-полноценным» не означает «не способен к сложной логике». Bitcoin Script поддерживает требования к многосторонним расходованиям, условия, зависящие от времени, раскрытие преобразов хешей, а также комбинации всех этих элементов. Сеть Lightning Network, которая обрабатывает миллионы платежей в день, построена исключительно на примитивах Bitcoin Script.

Типы скриптов: эволюция от P2PKH до Taproot

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

P2PK (Pay-to-Public-Key, 2009)

Исходный формат, использовавшийся в первых транзакциях с биткойнами, в том числе при платеже Сатоши Халлу Финни в блоке № 170. Средства привязывались непосредственно к полному открытому ключу, а не к его хешу. В настоящее время редко используется в новых транзакциях, поскольку при этом открытый ключ становится видимым в цепочке блоков ещё до расходования средств, что считается менее безопасным подходом, чем предварительное хеширование ключа.

P2PKH (Pay-to-Public-Key-Hash, 2009)

Стандартный формат, используемый уже более десяти лет. В схеме P2PKH средства привязываются к хешу открытого ключа, а не к самому ключу, что позволяет сохранять открытый ключ в тайне до момента расходования средств, формирует более короткий 20-байтовый адрес и лежит в основе всех адресов, начинающихся с цифры «1». Согласно данным Unchained (апрель 2026 года), на адресах P2PKH в настоящее время хранится примерно 43 % добытых биткойнов.

P2SH (Pay-to-Script-Hash, 2012, BIP 16)

Внедренный посредством мягкого форка 1 апреля 2012 года, протокол P2SH переложил бремя сложных скриптов расходования средств с отправителя на получателя. Вместо встраивания полного скрипта блокировки в выходной транзакции, P2SH выводит коммит к 20-байтовому хешу «скрипта погашения». Полный скрипт раскрывается только при трате монет. Это сделало мультиподпись практичной для обычных пользователей: для схемы мультиподписи «2 из 3» больше не требовалось, чтобы все три открытых ключа были видны отправителю на момент оплаты. Адреса P2SH начинаются с цифры «3».

Чтобы ознакомиться с подробным описанием того, как работает проверка P2SH на уровне протокола, Руководство по транзакциям на сайте developer.bitcoin.org пошагово рассказывает о механизме работы скриптов redeem.

P2WPKH и P2WSH (встроенный SegWit, 2017 г., BIP 141)

Функция Segregated Witness, активированная в августе 2017 года на блоке № 481 824, перенесла данные подписи за пределы основного тела транзакции в отдельную структуру «witness». Данные «witness» получают скидку в размере 75 % на вес, что делает транзакции с SegWit значительно дешевле. Стандартная транзакция P2WPKH с одним входом и двумя выходами весит примерно 141 виртуальный байт, в то время как вес аналогичной транзакции P2PKH составляет 226 виртуальных байтов, согласно Анализ типов адресов Биткойна, проведенный Spark с марта 2026 года. SegWit также устранил проблему изменчивости транзакций, что стало необходимым условием для создания сети Lightning Network. Нативные адреса SegWit начинаются с «bc1q.».

P2TR (Pay-to-Taproot, 2021, BIP 340/341/342)

Taproot был активирован в ноябре 2021 года на блоке № 709 632 и является самым значительным обновлением скриптового уровня Биткойна со времён SegWit. В рамках этого обновления были внедрены подписи Шнорра, новый тип вывода с поддержкой MAST, а также Tapscript — обновлённый язык сценариев. Адреса Taproot начинаются с «bc1p.».

Taproot и Tapscript: как изменился язык сценариев Биткойна в 2021 году

Taproot — это не одно изменение. Это три предложения по улучшению Биткойна (BIP), разработанные в комплексе и активированные одновременно.

BIP 340: Подписи Шнорра

Изначально в биткоине использовался алгоритм ECDSA (алгоритм цифровой подписи на основе эллиптической кривой). Сатоши выбрал его отчасти потому, что в то время подписи Шнорра были защищены патентом. Срок действия этого патента истек в 2008 году, и благодаря Taproot алгоритм Шнорра наконец-то был внедрен в протокол.

Подписи Шнорра занимают меньше места — 64 байта по сравнению с 71–73 байтами у ECDSA. Что ещё важнее, они поддерживают агрегацию ключей с помощью схемы под названием MuSig2. Агрегация ключей позволяет нескольким подписантам объединять свои индивидуальные ключи и подписи в один совокупный ключ и подпись, которые в цепочке блоков неотличимы от обычного платежа с одной подписью. Транзакция из кошелька с мультиподписью «2 из 3», осуществляемая через кооперативный путь ключей Taproot, выглядит в блокчейне точно так же, как и стандартный платеж. Это реальное улучшение конфиденциальности для любого, кто хранит биткоины в рамках сложной схемы хранения.

BIP 341: Pay-to-Taproot и MAST

P2TR вводит новый тип вывода с двумя путями расходования:

• A ключевой путь осуществлять расходы с использованием подписи Шнорра, которая применяется в тех случаях, когда все стороны согласны и стремятся выбрать самый простой и дешевый вариант
• A путь к скрипту осуществлять расходы с использованием MAST (Merkelized Abstract Syntax Tree — «меркелизованное абстрактное синтаксическое дерево», представляющее собой реализацию этой концепции в Taproot)

MAST позволяет одному выходу фиксироваться в дереве из нескольких сценариев расходования средств посредством корня Меркла. При расходовании средств в цепочке блоков раскрывается только конкретное условие, которое фактически используется. Все остальные возможные пути расходования в дереве остаются навсегда скрытыми. Для пользователя, настроившего сложную политику расходования средств, например: «Я могу тратить средства в обычном режиме, либо два из трёх доверенных лиц могут тратить средства через шесть месяцев, либо ключ восстановления может тратить средства через два года», в блокчейне отображается только тот путь, который фактически реализуется.

По состоянию на 2024 год доля транзакций Taproot в сети Биткойна выросла примерно до 42 %, что, согласно данным Glassnode, на которые сослался Spark в марте 2026 года, в значительной степени было обусловлено активностью по созданию Ordinals и BRC-20. С тех пор эта доля колебалась в зависимости от рыночной конъюнктуры, но в настоящее время эта инфраструктура стала стандартом для всех крупных кошельков и бирж. Тематическая страница Bitcoin Optech, посвящённая Taproot отслеживает текущую работу по разработке протокола Taproot.

BIP 342: Tapscript

Tapscript — это обновлённый язык сценариев, используемый для операций со скрипт-путями в системе Taproot. Он имеет большинство опкодов, общих с устаревшим Bitcoin Script, но в него внесены несколько существенных изменений:

• OP_CHECKMULTISIG и OP_CHECKMULTISIGVERIFY устарели. В старом опкоде мультиподписи была особенность, из-за которой в качестве обходного пути требовалось помещать в стек фиктивный элемент. Tapscript устраняет эту особенность и заменяет её на OP_CHECKSIGADD, которая проверяет подписи Шнорра по одной и накапливает счетчик. Схемы мультиподписей с пороговым значением становятся более лаконичными и дешевыми в реализации.
• Ограничения на размер скриптов для каждого листа MAST сняты. Размер отдельных скриптов в ветке Taproot может быть произвольно большим.
• Операционные коды OP_SUCCESS являются наиболее перспективным изменением. В старом скрипте обнаружение неопределённого опкода приводит к сбою скрипта. В Tapscript опкоды из диапазона OP_SUCCESS обеспечивают безусловное выполнение скрипта. Будущие мягкие форки смогут назначать этим кодам операций реальное поведение, добавляя ограничения на условия их успешного выполнения, без необходимости выпуска новой версии скрипта или полного цикла повторного развертывания по всей экосистеме. Новые возможности могут быть добавлены в скриптовый уровень Биткойна более чистым способом, чем когда-либо ранее в истории протокола.

Минискрипт

Наряду с Tapscript для разработчиков всё большую актуальность приобретает связанный с ним проект под названием Miniscript. Miniscript представляет собой структурированный подход к написанию подмножества языка Bitcoin Script, которое поддаётся анализу, компоновке и универсальной подписи. В то время как исходный Script требует ручного построения и затрудняет аудит, скрипты Miniscript можно автоматически проверять на правильность и объединять в более крупные политики. Это не расширяет возможности Script, но делает то, что он уже умеет, значительно более доступным для разработчиков, создающих кошельки и инструменты хранения.

Возможности скриптов Bitcoin: реальные примеры применения

На сегодняшний день в основной сети Биткойна активны следующие типы транзакций, все из которых построены на основе примитивов Bitcoin Script:

Кошельки с многократной подписью (мультисиг) требуется M из N частных ключей для авторизации транзакции. Финансовый отдел компании может требовать 3 из 5 одобрений для любого снятия средств. Супружеская пара может использовать схему «2 из 2» для совместных сбережений. Благодаря Taproot и агрегации ключей Шнорра совместные транзакции с мультиподписью теперь в цепочке неотличимы от стандартных транзакций с одной подписью.

Транзакции с фиксированным временем Используйте OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify, или CLTV) и OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify, или CSV) для предотвращения перемещения средств до достижения определенной высоты блока или истечения заданного времени. Среди областей применения — планирование наследования, графики вступления в силу прав на токены для сотрудников, механизмы принудительного накопления средств и транзакции с штрафными санкциями, используемые внутри каналов Lightning Network.

Контракты с фиксированным временем хеширования (HTLC) сочетают требование о наличии обратного образа хеша с временной блокировкой. Условие расходования средств работает следующим образом: необходимо раскрыть обратный образ данного хеша до достижения указанной высоты блока, иначе средства возвращаются отправителю. HTLC являются основным примитивом сети Lightning Network, обеспечивающим бездоверительную маршрутизацию платежей по цепочкам каналов между участниками, не имеющими прямых взаимоотношений.

Эскроу В рамках таких механизмов средства блокируются в скрипте P2SH или Taproot, и для их разблокировки требуется согласие нескольких сторон; как правило, решающий голос принадлежит стороннему арбитру, владеющему ключом, дающим право на принятие окончательного решения в случае равенства голосов.

Контракты с конфиденциальным журналом (DLC) использовать подписи адаптера Шнорра на основе оракула, чтобы обеспечить возможность заключения финансовых контрактов, расчеты по которым производятся на основе реальных данных, таких как ценовые фиды или результаты событий, без необходимости передачи средств на хранение оракулу. DLC уже запущены в основной сети Биткойна и используются для опционов и фьючерсов с расчетами в биткойнах.

Скрипты Биткойна против смарт-контрактов Ethereum

И скрипт Bitcoin, и Solidity в Ethereum определяют условия, при которых может происходить перемещение средств, однако они представляют собой принципиально разные архитектурные решения. Это сравнение стоит провести напрямую, поскольку эти различия во многом объясняют компромиссы, на которые пошла каждая из сетей.

Основным отличием является наличие состояния. Контракты Ethereum хранят и изменяют данные, которые сохраняются между транзакциями, что делает возможным существование протоколов кредитования, децентрализованных бирж, управления в цепочке и стандартов токенов. В Bitcoin Script нет ничего подобного. Каждый скрипт выполняется в изолированной среде, не имея представления о каких-либо других транзакциях.

Это осознанный архитектурный выбор, а не пробел, который нужно восполнить. Скриптовый уровень Биткойна был разработан для одной конкретной задачи: обеспечения соблюдения условий расходования биткойнов — предсказуемо, безопасно и в больших масштабах. Для этой задачи отсутствие состояния является преимуществом. Поверхность атаки меньше, выполнение детерминировано на миллионах независимых валидаторов, и на уровне протокола не существует категории уязвимостей смарт-контрактов, поскольку на этом уровне нет контрактов с состоянием.

Проекты, стремящиеся расширить возможности программирования на базе Bitcoin, реализуют их послойно. Сеть Lightning Network обрабатывает платежи. Протоколы DLC обеспечивают работу финансовых контрактов, привязанных к внешним данным. Системы второго уровня, такие как Ark и Liquid Network, ориентированы на различные сценарии масштабируемости. Ничто из этого не требует изменения модели скриптинга базового уровня.

Дебаты вокруг «Ковенанта»: что может измениться в скрипте Биткойна

Развитие скрипта Bitcoin всегда происходило медленно и осторожно. Наиболее активной областью разработки в настоящее время являются опкоды «covenant» — это предложения, которые позволят скрипту ограничивать не только круг лиц, имеющих право тратить выходной билет, но и то, как должна выглядеть итоговая транзакция. Это значительное расширение выразительных возможностей скрипта.

Наиболее перспективные предложения по состоянию на июнь 2026 года:

• OP_CTV (BIP-119, CheckTemplateVerify), автором которого является Джереми Рубин, добавляет один операционный код, который фиксирует UTXO в конкретном, заранее определённом шаблоне расходования, включающем версию транзакции, время блокировки, количество входов, последовательности, количество выходов и сами выходы. По замыслу он не является рекурсивным, считается самым консервативным из крупных предложений и в первую очередь нацелен на хранилища, управление перегрузками и определенные улучшения Lightning. По состоянию на апрель 2026 года для OP_CTV обсуждаются конкретные параметры внедрения, определяющие окно сигнализации Speedy Trial, однако, согласно Анализ ковенантов BlockEden за апрель 2026 года.
• OP_CAT (BIP-347), предложенный Итаном Хейлманом и Армином Сабури, позволит вновь активировать опкод, который Сатоши отключил в 2010 году. OP_CAT объединяет два элемента стека — это просто в описании, но имеет широкие последствия. В сочетании с подписями Шнорра он обеспечивает возможность анализа транзакций по типу «ковенантов». Согласно анализу цепочки блоков, проведённому sCrypt в конце 2024 года, в тестовой сети Bitcoin Signet OP_CAT сгенерировал значительно больше транзакций разработчиков, чем APO или CTV. OP_CAT уже активен в сетях Liquid Network и Fractal Bitcoin, и с его использованием не было зафиксировано ни одного злоупотребления. BIP-347 имеет официальный номер предложения и подкреплён активными исследованиями, однако для активации в основной сети требуется консенсус сообщества, которого пока нет.
• LNHANCE объединяет OP_CTV с OP_CHECKSIGFROMSTACK (CSFS) и OP_INTERNALKEY, направленные на конкретные усовершенствования в построении каналов сети Lightning Network, включая неинтерактивное открытие каналов и более эффективное управление многосторонними каналами.

По состоянию на июнь 2026 года ни одна из них не была активирована в основной сети Биткойна. Технические разногласия между ними в основном поддаются урегулированию. Более сложной проблемой является механика активации. Процесс «мягкого форка» Биткойна требует широкого консенсуса, а дискуссия по поводу соглашения сопровождается остаточной напряжённостью, унаследованной от предыдущих спорных обновлений. Из этой дискуссии ясно, что у скриптового уровня Биткойна есть значительный потенциал для развития в рамках его консервативной архитектуры. В настоящее время обсуждаются вопросы последовательности действий и достижения согласия в сообществе, а не то, есть ли будущее у языка скриптов.

Заключение

Скрипт Биткойна — это невидимая инфраструктура, лежащая в основе каждой транзакции в сети. Большинство пользователей никогда не сталкиваются с ним напрямую. Кошельки создают допустимые скрипты, подписывают их и транслируют, не раскрывая внутренних механизмов. Но каждый платеж, каждый канал Lightning, каждый план с временной блокировкой, каждое хранилище с мультиподписью работает на основе того же стекового языка скриптов Bitcoin, который был включён в протокол в 2009 году.

С тех пор уровень сценариев значительно расширился: технология P2SH сделала возможным осуществление сложных транзакций, SegWit снизила комиссии и обеспечила работу сети Lightning, а Taproot привнесла подписи Шнорра, конфиденциальность на основе MAST и перспективную архитектуру операционных кодов Tapscript. Предложения по ковенантам, которые сейчас активно обсуждаются, представляют собой следующий потенциальный этап развития. Будут ли они реализованы и в какие сроки — на середину 2026 года этот вопрос по-прежнему остается открытым.

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