OP_CAT — це операційний код біткойна, який об’єднує два елементи даних зі стека в один, і наразі він є предметом однієї з найтриваліших дискусій у сфері розробки біткойна. Він був частиною оригінального коду біткойна, але у 2010 році Сатоші Накамото видалив його через побоювання щодо безпеки; останні кілька років він існував як пропозиція м’якого форку (BIP 347), який міг би відкрити нову категорію можливостей, схожих на смарт-контракти, у біткойні. Станом на липень 2026 року він не активний у основній мережі біткойна, хоча вже працює в кількох мережах, пов’язаних із біткойном, де його непомітно піддають публічним навантажувальним випробуванням.
OP_CAT варто вивчити не лише через сам код. Справа в тому, хто стоїть за ним: розробники Bitcoin Core, які обговорюють, чи є ця зміна безпечною; мем-орієнтований NFT-проект, який зібрав десятки мільйонів доларів, щоб лобіювати її повернення; та швидкозростаючий сайдчейн, який уже почав її використовувати. У цьому посібнику детально роз'яснюється, як працює OP_CAT, чому його було вимкнено, які можливості він може відкрити та яка саме ситуація склалася на сьогодні.
Використовуйте Multichain Додаток «Гаманець Bitcoin.com», якому довіряють мільйони людей, щоб безпечно та легко надсилати, отримувати, купувати, продавати, обмінювати, використовувати та керувати біткойнами та криптовалютами.
Основні висновки
- OP_CAT (скорочення від «operation concatenate») об’єднує два елементи даних зі стека Bitcoin в один. Ось і вся функція.
- Ця функція була активною в найпершому коді біткойна, але потім у 2010 році Сатоші Накамото її вимкнув через ризик відмови в обслуговуванні.
- Пропозиція щодо його відновлення, BIP 347, була розроблена Етаном Гейлманом та Арміном Сабурі, а номер BIP їй було присвоєно у квітні 2024 року.
- OP_CAT сам по собі не є ковенантом, але в поєднанні з іншими опкодами його можна використовувати для створення обмежень на витрачання коштів, подібних до ковенантів, зокрема для створення сховищ.
- Станом на середину 2026 року OP_CAT не було активовано в основній мережі Bitcoin. Наразі фаворитами серед наступних консенсусних м'яких форків Bitcoin є OP_CTV (BIP 119) та OP_CHECKSIGFROMSTACK (BIP 348), а не OP_CAT окремо.
- OP_CAT вже працює в мережі Fractal Bitcoin — сайдчейні, сумісному з Bitcoin, — де він забезпечує функціонування стандарту токенів CAT20, а також вже протягом багатьох років використовується в мережах Liquid Network та Bitcoin Cash без відомих випадків зловживання.
- Проєкт NFT на базі біткойна під назвою Quantum Cats, створений компанією Taproot Wizards, перетворив підтримку OP_CAT на мем-кампанію, яка дозволила зібрати понад 37 мільйонів доларів на розвиток технологій, пов’язаних з OP_CAT.
Як працює OP_CAT
Найпростіший спосіб зрозуміти OP_CAT — уявити собі систему скриптів Біткойна як невеликий стек будівельних блоків. Bitcoin Script — мова програмування, що лежить в основі кожної транзакції в мережі Біткойн, — є стековою мовою. Дані заносяться на стек, операційні коди діють на те, що знаходиться на вершині стека, а результат визначає, чи є транзакція дійсною.
OP_CAT бере два верхні елементи зі стека та об’єднує їх, тобто з’єднує їх кінцями в один комбінований елемент, який потім повертається на вершину стека. Якщо у стеку містяться значення «1» і «2», виконання OP_CAT видаляє обидва і замінює їх на «12». Згідно з офіційною специфікацією в BIP 347, OP_CAT додасть x1 || x2 до стека, де символ у вигляді подвійної вертикальної риски означає конкатенацію.
Є одне важливе обмеження. Операція OP_CAT завершується з помилкою, якщо у стеку міститься менше двох значень або якщо їх об’єднання призведе до утворення комбінованого значення, розмір якого перевищує 520 байтів — це максимальний розмір елемента скрипта в Bitcoin. Це обмеження на розмір у байтах має велике значення для історії цього операційного коду, про що ми поговоримо трохи пізніше.
Сама по собі операція об’єднання двох рядків даних не здається чимось надзвичайним. Однак у скриптовій мові Bitcoin ніколи не було універсального способу об’єднання значень у стеку, і ця прогалина обмежувала можливості розробників щодо вбудовування функціоналу безпосередньо в транзакції Bitcoin. Оскільки Bitcoin Optech пояснює, У Bitcoin Tapscript відсутній універсальний спосіб об’єднання об’єктів у стеку, що обмежує виразність Tapscript і, серед іншого, унеможливлює побудову та обчислення дерев Меркла та інших хеш-структур даних безпосередньо в Tapscript. OP_CAT — це запропоноване рішення для усунення саме цієї прогалини.
Чому у 2010 році було вимкнено OP_CAT?
OP_CAT був частиною найпершої версії Bitcoin. У 2010 році Сатоші Накамото видалив його разом із кількома іншими операційними кодами, такими як OP_MUL, OP_DIV та OP_OR. Офіційним обґрунтуванням стало ризик відмови в обслуговуванні: скрипт, що багаторазово використовує OP_CAT, теоретично міг би генерувати експоненціально зростаючий масив даних, достатньо великий, щоб уповільнити роботу або призвести до збою вузлів, які намагаються його перевірити.
На той час не існувало жорсткого обмеження на розмір окремого елемента в стеку Bitcoin. Це означало, що зловмисний скрипт міг би безперервно об’єднувати значення, доки не утворив би ланцюжок даних, достатньо великий, щоб заблокувати роботу мережі. Видалення OP_CAT, разом з іншими вимкненими операційними кодами, було консервативним кроком, який ставив стабільність мережі вище за функціональність, яка ще не була необхідною для молодої мережі.
Ситуація змінилася в листопаді 2021 року, коли Bitcoin активував оновлення Taproot. Taproot запровадив Tapscript — новий контекст скриптів із власними правилами, одне з яких обмежує розмір будь-якого окремого елемента стека до 520 байтів. Це обмеження в байтах безпосередньо перекриває початковий шлях атаки. Скрипт і надалі може викликати OP_CAT, але він ніколи не зможе генерувати значення, достатньо велике, щоб створити таку проблему вичерпання ресурсів, яка турбувала Сатоші у 2010 році. Саме ця технічна деталь знову відкрила можливість повернення OP_CAT, але лише в межах Tapscript, а не всього Bitcoin Script.
Чи є OP_CAT ковенантом?
Ні, не самостійно, і це один із найпоширеніших випадків неправильного розуміння OP_CAT. У термінології Bitcoin «ковенант» — це обмеження щодо того, як невитрачений вихід транзакції (UTXO) може бути витрачений у майбутньому. Звичайний скрипт Bitcoin може перевіряти лише те, чи авторизовано витрачання коштів саме зараз, зазвичай шляхом перевірки підпису. Ковенант йде далі, перевіряючи не лише те, чи авторизовано витрачання, а й те, чи відповідає отримана транзакція певному набору умов.
OP_CAT не містить жодного вбудованого механізму перевірки даних транзакції. Він надає можливість об’єднувати фрагменти даних у стеку, що стає корисним для ковенантів лише у поєднанні з іншими операційними кодами, які перевіряють підписи на відповідність цим об’єднаним даним. У самому BIP 347 чітко зазначено що OP_CAT, хоча його й було запропоновано для поновлення в Tapscript, не є ковенантом. Точніше буде описати його як будівельний блок, який у поєднанні з операційними кодами перевірки підписів може використовуватися для імітації поведінки, схожої на ковенант.
Це має значення, оскільки саме гнучкість OP_CAT робить його одночасно цікавим і суперечливим. Хоча OP_CAT сам по собі й не є ковенантом, він може імітувати ковенанти завдяки особливості роботи підписів Шнорра. У поєднанні з операційним кодом CheckSigFromStack (CSFS), який перевіряє підпис на відповідність довільним даним, а не лише самій транзакції, OP_CAT можна використовувати для створення таких самих обмежень на витрачання коштів, для чого призначені спеціальні операційні коди ковенантів.
Для чого можна використовувати OP_CAT?
Оскільки OP_CAT є універсальним примітивом, а не функцією з вузькою сферою застосування, розробники запропонували для нього широкий спектр варіантів використання. До найбільш обговорюваних належать:
- Сейфи. «Сейф» — це тип угоди, який передбачає виконання низки кроків, що часто охоплюють окремі транзакції та блоки, перш ніж кошти можуть бути перераховані. Це створює вбудовану затримку, яка дає власнику час помітити та зупинити несанкціоновані витрати, що покращує ефективність систем «холодного» зберігання та спільного зберігання.
- Договори про відсутність двозначності. Вони можуть застосовувати санкції до учасника платіжного каналу, наприклад у мережі Lightning Network, який намагається оприлюднити застарілий або фальшивий стан каналу, тим самим підвищуючи безпеку позаланцюгових платіжних систем.
- Три підписи. OP_CAT дозволяє створювати компактні скрипти з багаторазовим підписом, розмір яких зростає лише логарифмічно від кількості підписувачів, що означає: транзакція розміром менше 1 кілобайта теоретично може підтримувати умови витрачання коштів для мільйонів відкритих ключів.
- Побудова та перевірка дерева Меркла. Оскільки побудова та перевірка дерева Меркла принципово вимагають об’єднання та хешування значень, OP_CAT надає Bitcoin Script відсутній елемент, необхідний для виконання цих операцій на рівні ядра.
- Постквантові ознаки. OP_CAT дозволяє використовувати підписи Лампорта — схему підпису, яка вважається стійкою до атак з боку квантових комп’ютерів, оскільки для підписів Лампорта потрібна лише можливість хешування та об’єднання значень у стеку.
- Токенізовані активи та міжланцюгові мости. Завдяки підтримці більш виразних скриптів OP_CAT зможе забезпечити випуск токенів безпосередньо в ланцюгах, сумісних із Bitcoin, а також створення мостів між Bitcoin та іншими мережами з мінімальним рівнем довіри.
Тут також варто прямо говорити про компроміси. Та сама гнучкість, яка робить OP_CAT корисним для всіх вищезазначених випадків, є причиною обережності деяких розробників Bitcoin щодо нього. Оскільки OP_CAT є універсальним, а не спеціалізованим, він відкриває те, що розробники іноді називають «широким простором для проектування», тобто важче передбачити всі можливі способи його поєднання з іншими операційними кодами. Саме ця невизначеність є сутністю триваючої дискусії, а не другорядним питанням.
OP_CAT проти OP_CTV: порівняння двох провідних пропозицій щодо ковенантів
OP_CAT зазвичай розглядають разом з OP_CTV (OP_CheckTemplateVerify), запропонованим у BIP 119 розробником Джеремі Рубіном. Обидва ці механізми мають на меті надати біткойну певні можливості у сфері укладення угод, але їхні підходи до реалізації є майже протилежними.
Практична відмінність полягає в обсязі. OP_CTV дозволяє виходу транзакції зафіксувати одну конкретну майбутню транзакцію витрачання, охоплюючи такі деталі, як версія, час блокування, виходи та кількість входів. Якщо шаблон збігається — витрачання відбувається. Якщо не відповідає — транзакція не проходить. Така вузькість є навмисною. CTV не є рекурсивним, тобто транзакція, до якої він прив’язується, сама не може прив’язуватися до подальших обмежень, створюючи таким чином постійний ланцюг обмежень. Прихильники вважають це більш безпечною та контрольованою формою угоди.
OP_CAT дотримується протилежної філософії. Замість того, щоб вирішувати одну конкретну проблему, він надає розробникам гнучкий примітив і дозволяє їм будувати на його основі. Якщо CTV — це один операційний код із чітко визначеною сферою застосування, призначений для реалізації конкретного набору сценаріїв використання, то OP_CAT — це примітив, що забезпечує конкатенацію рядків у стеку, який вже був присутній у оригінальній мові скриптів Bitcoin, перш ніж його було вимкнено у 2010 році через побоювання щодо атак типу «відмова в обслуговуванні», які більше не актуальні в умовах обмежень розміру скриптів, встановлених після впровадження Taproot. Саме ця гнучкість дозволяє OP_CAT підтримувати рекурсивні угоди, де одне обмеження може породжувати інше обмеження в подальшому — властивість, якої OP_CTV навмисно уникає.
Чи працює OP_CAT у мережі Bitcoin сьогодні?
Не в основній мережі Біткойна. BIP 347 набув статусу «Complete» як специфікаційний документ, що означає, що сама пропозиція є завершеною та чітко сформульованою. Це не те саме, що її впровадження, яке вимагатиме від широкої спільноти Біткойна та операторів вузлів фактично активувати її шляхом м’якого форку.
Станом на середину 2026 року OP_CAT не є головним кандидатом на наступну зміну механізму консенсусу в мережі Біткойн. Ця позиція наразі належить OP_CTV разом із OP_CHECKSIGFROMSTACK (BIP 348) — пов’язаним операційним кодом, який дозволяє скрипту перевіряти підпис щодо довільних даних, а не лише щодо самої транзакції витрачання. Згідно з останнє довідкове керівництво щодо BIP для біткойна, станом на середину 2026 року провідними кандидатами на наступний консенсусний софт-форк є пропозиції щодо угод BIP 119 (OP_CHECKTEMPLATEVERIFY) та BIP 348 (OP_CHECKSIGFROMSTACK), що відкриє нові можливості скриптингу для сховищ, фабрик каналів та більш ефективних протоколів другого рівня, хоча терміни активації ще не визначені, а консенсус у спільноті ще формується.
OP_CTV просунувся в процесі активації далі, ніж OP_CAT. Розробники опублікували конкретні параметри сигналізації для м’якого форку за типом BIP9: дата початку сигналізації — 30 березня 2026 року, однорічний період очікування, що закінчується 30 березня 2027 року, мінімальна висота активації приблизно в травні 2027 року та поріг сигналізації майнерів у 90 % протягом кожного двотижневого періоду складності. Таким чином, CTV буде реалізовано за тим самим механізмом, що й активація Taproot у 2021 році, хоча досягнення 90-відсоткового порогу далеко не гарантоване, зважаючи на те, наскільки суперечливими залишаються пропозиції щодо ковенантів у спільноті розробників.
Це аж ніяк не означає, що OP_CAT відійшов у минуле. Це означає, що «наступна» дискусія щодо софт-форку в 2026 році наразі зосереджена на іншій парі опкодів, а подальша доля OP_CAT, якщо така взагалі буде, ймовірно, залежатиме від того, як спочатку розвиватиметься дискусія щодо CTV та CSFS.
OP_CAT вже працює в інших місцях
Хоча OP_CAT і чекає на впровадження в основній мережі Біткойна, це не означає, що його не тестують. Вже протягом багатьох років він непомітно працює в робочому середовищі в кількох мережах, пов’язаних із Біткойном.
- Liquid Network. У федеративній сайдчейні Blockstream функція OP_CAT була активована ще з моменту її запуску, що дало широкій екосистемі біткойна можливість реального тестування задовго до того, як з’явився BIP 347.
- Bitcoin Cash та Bitcoin SV. Обидві мережі знову впровадили OP_CAT під час оновлення протоколів, і цей опкод обробляв транзакції в цих ланцюгах без задокументованих випадків зловживання, пов’язаних безпосередньо з самим опкодом.
- Фрактальний біткойн. Це найактивніший на сьогоднішній день проект. Fractal — це сайдчейн, сумісний з Bitcoin, створений на базі власного програмного забезпечення Bitcoin Core та об’єднаний з Bitcoin у рамках злитого майнінгу, який запустив свою основну мережу 9 вересня 2024 року з підтримкою OP_CAT з самого початку.
Fractal заслуговує на більш детальний розгляд, оскільки це найчіткіша відповідь на питання «як це насправді виглядатиме в мережі Bitcoin». З моменту запуску Fractal нові протоколи використовують OP_CAT для створення смарт-контрактів на базі програмного забезпечення Bitcoin, зокрема протокол CAT, який викликав значний інтерес серед користувачів, що працюють безпосередньо з Bitcoin, а також інші нові стандарти, що розширюють функціональність мережі за допомогою OP_CAT.
Найпоказовішим прикладом є CAT20 — стандарт замінних токенів, розроблений спеціально для використання можливостей OP_CAT. Згідно з Власна документація Fractal Bitcoin, CAT20 повністю перевіряється майнерами та функціонує на основі смарт-контрактів, а саме рекурсивних угод, виконання яких повністю забезпечується власною мовою скриптів Bitcoin на базовому рівні, що відрізняє його від стандартів токенів, які покладаються на зовнішню або сторонню перевірку. На практиці це означає, що розгортання, випуск та передача токена CAT20 відбуваються через послідовність операцій OP_CAT, які формують єдиний рядок даних, який потім записується безпосередньо в блокчейн і перевіряється тими самими майнерами, що забезпечують безпеку мережі, а не окремою позаланцюговою службою індексації.
Історія «Quantum Cats»: як мем-кампанія сприяла розвитку OP_CAT
Більшість пропозицій щодо опкодів залишаються лише в межах списків розсилки та обговорень на GitHub. OP_CAT став винятком, головним чином завдяки проєкту Bitcoin Ordinals під назвою Taproot Wizards.
У січні 2024 року компанія Taproot Wizards випустила колекцію з 3 333 предметів у стилі NFT під назвою «Quantum Cats», створену виключно з метою залучення громадської підтримки для поновлення функціонування OP_CAT. Quantum Cats прагнули, щоб OP_CAT створив бездозвільний міст, який би дозволяв переміщувати біткойни та активи на основі біткойна на ланцюги другого рівня (layer 2) мережі Bitcoin, де вони могли б брати участь у більш складних торгових операціях. Щоб навіть отримати право на участь у випуску, учасники мали ознайомитися з фактичною технічною пропозицією та публічно виступити за її повернення, перетворивши досить суху дискусію щодо BIP на кампанію спільноти з реальними ставками.
Сама колекція водночас слугувала наочною ілюстрацією принципу конкатенації в дії. Кожен «Quantum Cat» посилається не на одне статичне зображення, а на кілька окремих файлів, і в міру того, як з часом з’являються нові файли, коти змінюються, точно відтворюючи принцип роботи OP_CAT, який полягає в об’єднанні окремих фрагментів даних.
Кампанія виявилася настільки успішною, що принесла значне фінансування. У 2023 році компанія Taproot Wizards залучила 7,5 млн доларів, а в лютому 2025 року — ще 30 млн доларів; обидва раунди фінансування були прямо призначені для розвитку екосистеми OP_CAT. Співзасновник Уді Вертхаймер описав проект як такий, що зосереджений на OP_CAT як майбутньому біткойна, причому фінансування спрямовується як на внутрішню розробку, так і на підтримку зовнішніх команд, що працюють над цим опкодом. Один-єдиний аукціон Quantum Cat у Sotheby's — «Genesis Cat» — завершився на позначці 254 000 доларів, що підкреслило, наскільки великого культурного значення набула ця кампанія навколо чотирибайтового опкоду.
Це корисне нагадування про те, що технічні дискусії щодо біткойна не завжди залишаються суто технічними. Меми, мистецтво та гроші неодноразово ставали інструментами, що виносили обговорення протоколу на ширший загал, і OP_CAT є одним із найяскравіших останніх прикладів цієї тенденції.
Висновок
OP_CAT виконує одну просту дію: об’єднує два фрагменти даних у стеку Bitcoin в один. Важливість цієї функції полягає в тому, що її впровадження може відкрити безліч можливостей — від більш безпечних сховищ для «холодного» зберігання до постквантових підписів та власних токенів Bitcoin — якщо спільнота Bitcoin колись домовиться про її повернення. Станом на липень 2026 року такої згоди досягнуто не було. BIP 347 — це готова специфікація, яка стоїть у черзі за OP_CTV та OP_CHECKSIGFROMSTACK у рамках наступного консенсусного софт-форку Bitcoin, навіть попри те, що OP_CAT продовжує тихо та без інцидентів працювати на Fractal Bitcoin, Liquid та інших мережах, пов’язаних із Bitcoin. Що б не сталося далі, дискусія навколо OP_CAT уже продемонструвала, як невеликий і простий фрагмент коду може одночасно привернути увагу розробників, митців та інвесторів.
