Що таке мова скриптів Bitcoin?

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

Більшість користувачів ніколи безпосередньо не стикаються з мовою скриптів Bitcoin. Їхні гаманці обробляють її непомітно. Але щоразу, коли ви надсилаєте або отримуєте BTC, на тисячах комп’ютерів одночасно виконуються дві невеликі програми, які перевіряють, чи дотримано умови витрачання коштів. Розуміння того, як це працює, значною мірою пояснює, чому Bitcoin побудований саме так, а також що він може і чого не може зробити порівняно з такими платформами, як Ethereum.

У цій статті розглядається принцип роботи Bitcoin Script, детально описуються основні типи транзакцій, які він підтримує, пояснюється оновлення Taproot, яке в 2021 році модернізувало рівень скриптів, а також висвітлюється стан дискусії щодо операційного коду «covenant» станом на червень 2026 року.

Безпечно керуйте своїми біткойнами за допомогою самостійного зберігання Додаток «Гаманець Bitcoin.com».

Основні висновки

• Bitcoin Script — це мова програмування на основі стека, вбудована в протокол Bitcoin, яка визначає умови, за яких можна витратити будь-який вихідний блок біткойна.
• Кожна транзакція в мережі Bitcoin містить два скрипти: скрипт блокування (ScriptPubKey), встановлений одержувачем, та скрипт розблокування (ScriptSig), наданий відправником. Щоб транзакція була дійсною, обидва скрипти мають успішно виконатися.
• Скрипт Bitcoin навмисно не є тюрінгово повним. У ньому немає циклів, немає стійкого стану між виконанням, а також існують жорсткі обмеження на розмір скрипту. Це гарантує, що кожен скрипт обов’язково завершиться, що є елементом безпеки, а не обмеженням.
• Мова сценаріїв пройшла п’ять основних етапів розвитку: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) та Taproot (P2TR), кожен з яких розширював можливості, зберігаючи при цьому зворотну сумісність.
• У версії Taproot (листопад 2021 року) було впроваджено підписи Шнорра, маршрути витрат на основі MAST для забезпечення конфіденційності, а також Tapscript — оновлену мову сценаріїв із вбудованим механізмом, що забезпечує більш плавне оновлення в майбутньому.
• До реальних прикладів використання, реалізованих на базі Bitcoin Script, належать гаманці з багатопідписом, транзакції з часовим блокуванням, контракти з часовим блокуванням на основі хеш-функцій (основа мережі Lightning), ескроу та контракти з дискретним журналом.
• На відміну від смарт-контрактів Ethereum, Bitcoin Script не має стану: кожен скрипт виконується в повній ізоляції, не маючи інформації про будь-які інші транзакції. Це свідомий архітектурний вибір.
• Найактивнішою сферою розробки Bitcoin Script у 2026 році є операційні коди (opcodes) типу «covenant», зокрема OP_CTV (BIP-119) та OP_CAT (BIP-347), які дозволять скриптам визначати, яким саме має бути транзакція витрачання коштів. Жоден із них поки що не активовано в основній мережі.

Що таке Bitcoin Script?

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

Ця мова запозичила свою структуру у Forth — мінімалістичної мови програмування на основі стека, розробленої у 1960-х роках. Як і Forth, Bitcoin Script читається зліва направо, оперує структурою даних, що називається стеком, і використовує зворотну польську нотацію (RPN), в якій оператори йдуть після операндів, а не перед ними. Він виконує по одній інструкції за раз, не має циклів і не зберігає даних у пам’яті між виконаннями.

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

Як працює скрипт Bitcoin: модель стека

Щоб зрозуміти, як працює Bitcoin Script, потрібно зрозуміти, що таке стек. Стек — це структура даних, яка працює за принципом «останнє надійшло — перше вийшло» (LIFO). Уявіть собі стос тарілок: додавати або знімати можна лише те, що лежить зверху. У Bitcoin Script дані заносяться на стек, а операційні коди (opcodes) оперують тим, що знаходиться на вершині.

Коли вузол біткойна перевіряє транзакцію, він послідовно виконує два скрипти:

1. Скрипт розблокування (ScriptSig або свідок) надані особою, яка витрачає монети. Це призводить до додавання даних у стек — зазвичай це цифровий підпис та відкритий ключ.
2. Скрипт блокування (ScriptPubKey) пов'язаний із витрачанням вихідних коштів. Він містить операційні коди, які оперують даними стека та перевіряють, чи виконані умови витрачання.

Якщо скрипт виконується без помилок і в кінці залишає на стеку значення, відмінне від нуля (TRUE), транзакція вважається дійсною. Якщо ж він завершується з помилкою або залишає значення FALSE, транзакція відхиляється вузлом і ніколи не потрапляє до блоку.

Це виконання є повністю безстатевим. Скрипт не має інформації про попередні транзакції, не знає поточних залишків на рахунках і не зберігає даних, які б переносилися після завершення його виконання. Кожен скрипт щоразу виконується з нуля, в ізольованому режимі.

Покрокова інструкція: стандартна транзакція P2PKH

Pay-to-Public-Key-Hash (P2PKH) — це оригінальний тип транзакції в мережі Bitcoin, який використовується з 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 Wiki» є авторитетним джерелом.

Чому відсутність повного набору Тюрінга є перевагою

Загальноприйняте пояснення полягає в тому, що в Bitcoin Script немає циклів, тому завершення виконання скриптів гарантоване, а отже, мережа захищена від нескінченного виконання. Це вірно, але таке пояснення не повністю розкриває суть питання.

Більш глибока проблема полягає в площі атаки. Мова, що є Тюрінговою повною, може описувати довільні обчислення. Ця виразність є також простором, де існують помилки. Мова Solidity в мережі Ethereum стала причиною деяких із найдорожчих програмних вразливостей в історії. Злом DAO у 2016 році скористався вразливістю реентрантності у смарт-контракті та спричинив збитки на суму близько 60 мільйонів доларів за тодішніми цінами, що зрештою призвело до суперечливого хард-форку мережі Ethereum. Протягом кількох років у ширшій екосистемі DeFi через експлойти смарт-контрактів було викрадено сотні мільйонів доларів.

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

Для мережі, вартість якої сягає сотень мільярдів доларів, така передбачуваність цінується вище, ніж гнучкість, від якої доводиться відмовлятися. Ethereum вирішує проблему необмежених обчислень за допомогою лімітів газу, стягуючи з користувачів плату за кожен виконаний опкод і зупиняючи скрипти, у яких вичерпано бюджет. Це працює, але створює власні складнощі та можливості збою. Bitcoin повністю обходить цю проблему завдяки своїй архітектурі.

Проте «не є тюринго-повним» не означає «не здатний до складної логіки». 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 віртуальний байт, у порівнянні з 226 віртуальними байтами для еквівалентної транзакції P2PKH, згідно з Аналіз типів біткойн-адрес, проведений Spark з березня 2026 року. SegWit також усунув проблему підданості транзакцій маніпуляціям, що було необхідною умовою для створення мережі Lightning Network. Вбудовані адреси SegWit починаються з «bc1q.».

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

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

Taproot і Tapscript: як змінилася мова скриптів Bitcoin у 2021 році

Taproot — це не одна зміна. Це три пропозиції щодо вдосконалення біткойна (BIP), розроблені разом і введені в дію одночасно.

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

Спочатку у біткойні використовувався алгоритм ECDSA (алгоритм цифрового підпису на основі еліптичних кривих). Сатоші обрав його частково тому, що на той час підписи Шнорра були захищені патентом. Термін дії цього патенту закінчився у 2008 році, і завдяки Taproot підписи Шнорра нарешті були впроваджені в протокол.

Підписи Шнорра мають менший розмір — 64 байти, на відміну від 71–73 байтів у підписів ECDSA. Що ще важливіше, вони підтримують агрегацію ключів за допомогою схеми під назвою MuSig2. Агрегація ключів дозволяє кільком підписувачам об’єднати свої індивідуальні ключі та підписи в єдиний агрегований ключ і підпис, який у ланцюжку не відрізняється від звичайного платежу з одним підписом. Витрачання коштів із гаманця з мультипідписом «2 з 3» через кооперативний шлях ключів Taproot виглядає ідентично до стандартного платежу в блокчейні. Це реальне підвищення рівня конфіденційності для будь-кого, хто зберігає біткойни в рамках складної схеми зберігання.

BIP 341: Pay-to-Taproot та MAST

P2TR запроваджує новий тип виходу з двома шляхами витрачання:

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

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

Станом на 2024 рік частка транзакцій Bitcoin, здійснених за допомогою 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 забезпечують безумовне виконання скрипта. Майбутні м'які форки зможуть надати цим операційним кодам реальну поведінку, додавши обмеження щодо умов їх успішного виконання, без необхідності випуску нової версії скрипту або повного циклу повторного розгортання в екосистемі. Нові можливості можна додавати до скриптового шару Bitcoin більш чітко, ніж будь-коли раніше в історії протоколу.

Мініскрипт

Поряд із Tapscript для розробників дедалі більшого значення набуває пов’язаний із ним проєкт під назвою Miniscript. Miniscript — це структурований підхід до написання підмножини Bitcoin Script, яка піддається аналізу, комбінуванню та підписанню у загальному вигляді. На відміну від «сирого» Script, який вимагає ручного створення та є складним для аудиту, скрипти Miniscript можна автоматично перевіряти на правильність та об’єднувати в більш масштабні політики. Це не розширює можливості Script, але робить те, що він уже вміє, значно доступнішим для розробників, які створюють гаманці та інструменти зберігання.

Можливості Bitcoin Script: приклади застосування в реальному житті

На сьогодні в основній мережі Bitcoin діють такі типи транзакцій, усі з яких побудовані на основі примітивів Bitcoin Script:

Гаманці з багатопідписом (multisig) вимагають 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 вже працюють у основній мережі Bitcoin і використовуються для опціонів та ф’ючерсів, розрахунки за якими здійснюються в біткойнах.

Скрипти Bitcoin проти смарт-контрактів Ethereum

Як скрипт Bitcoin, так і Solidity від Ethereum визначають умови, за яких може відбуватися переміщення коштів, але вони відображають принципово різні архітектурні рішення. Це порівняння варто провести безпосередньо, оскільки ці відмінності багато що пояснюють щодо компромісів, на які пішла кожна з мереж.

Основною відмінністю є наявність стану. Контракти Ethereum зберігають і змінюють дані, які зберігаються між транзакціями, що робить можливими протоколи кредитування, децентралізовані біржі, управління в ланцюжку та стандарти токенів. У Bitcoin Script немає аналогів. Кожен скрипт виконується ізольовано, не маючи інформації про будь-які інші транзакції.

Це свідомий архітектурний вибір, а не прогалина, яку потрібно заповнити. Скриптовий рівень біткойна був розроблений для виконання одного конкретного завдання: забезпечення дотримання умов витрачання біткойнів — передбачувано, безпечно та в великих масштабах. Для виконання цього завдання відсутність стану є перевагою. Поверхня атаки менша, виконання є детермінованим серед мільйонів незалежних валідаторів, а на рівні протоколу не існує жодної категорії вразливостей смарт-контрактів, оскільки на цьому рівні немає контрактів зі станом.

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

Дебати щодо «Covenant»: що може змінитися в скрипті Bitcoin

Еволюція скрипту 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 року жодна з них не була активована в основній мережі Bitcoin. Технічні розбіжності між ними здебільшого можна вирішити. Складнішою проблемою є механізм активації. Процес «м'якого форку» Біткойна вимагає широкого консенсусу, а дискусія щодо угоди супроводжується залишковою напругою від попередніх суперечливих оновлень. З цієї дискусії стає зрозуміло, що скриптовий рівень Біткойна має значний потенціал для розвитку в межах своєї консервативної структури. Питання, над яким зараз працюють, стосується послідовності дій та згоди спільноти, а не того, чи має скриптова мова майбутнє.

Висновок

Скрипт Bitcoin — це невидима інфраструктура, на якій базується кожна транзакція в мережі. Більшість користувачів ніколи не стикаються з нею безпосередньо. Гаманці створюють дійсні скрипти, підписують їх і передають у мережу, не розкриваючи при цьому механізмів їхньої роботи. Але кожна оплата, кожен канал Lightning, кожен план із часовим блокуванням, кожне сховище з мультипідписом працює на базі тієї самої стекової мови скриптів Bitcoin, яка була впроваджена разом із протоколом у 2009 році.

З того часу рівень скриптів значно розширився: технологія P2SH зробила можливими складні операції з витрачанням коштів, SegWit знизив комісії та забезпечив роботу мережі Lightning, а Taproot запровадив підписи Шнорра, захист приватності на основі MAST та сумісну з майбутніми версіями архітектуру операційних кодів Tapscript. Пропозиції щодо ковенантів, які зараз активно обговорюються, представляють собою наступний потенційний етап розвитку. Чи будуть вони реалізовані, і в які терміни — станом на середину 2026 року це питання залишається справді відкритим.

Щоб зрозуміти Script, не обов’язково бути розробником. Однак потрібно усвідомити, що консервативність Біткойна, його навмисні обмеження, повільний темп оновлень та відсутність турингової повноти — це не недоліки. Ті самі властивості, які роблять Bitcoin Script передбачуваним, протягом шістнадцяти років забезпечували чистоту рівня консенсусу.