OP_CAT este un cod de operație (opcode) Bitcoin care combină două elemente de date de pe stivă într-unul singur și reprezintă în prezent subiectul uneia dintre cele mai îndelungate dezbateri din domeniul dezvoltării Bitcoin. Acesta a făcut parte din codul original al Bitcoin, fiind eliminat de Satoshi Nakamoto în 2010 din motive de securitate, iar în ultimii ani a fost propus ca soft fork (BIP 347) care ar putea deschide calea către o nouă categorie de comportamente similare contractelor inteligente în cadrul Bitcoin. În iulie 2026, acesta nu este activ pe rețeaua principală Bitcoin, deși funcționează deja pe câteva rețele adiacente Bitcoin, unde este supus în mod discret unor teste de stres în public.
Ceea ce face ca OP_CAT să merite să fie înțeles nu este doar codul. Ci și personajele din jurul său: dezvoltatorii Bitcoin Core care dezbat dacă această modificare este sigură, un proiect NFT inspirat de meme care a strâns zeci de milioane de dolari pentru a face lobby în favoarea reintroducerii sale și un sidechain în plină expansiune care l-a pus deja în practică. Acest ghid explică în detaliu ce face OP_CAT, de ce a fost dezactivat, ce ar putea permite și care este exact situația actuală.
Folosiți tehnologia multichain Aplicația Bitcoin.com Wallet, o platformă în care milioane de oameni au încredere pentru a trimite, primi, cumpăra, vinde, tranzacționa, utiliza și gestiona Bitcoin și criptomonede în mod sigur și ușor.
Concluzii cheie
- OP_CAT (prescurtarea de la „operația de concatenare”) combină două elemente de date din stiva Bitcoin într-un singur element. Aceasta este întreaga funcție.
- Această funcție era activă în codul inițial al Bitcoin, dar a fost dezactivată de Satoshi Nakamoto în 2010 din cauza riscului de atac de tip „denial-of-service”.
- Propunerea de reintroducere a acesteia, BIP 347, a fost elaborată de Ethan Heilman și Armin Sabouri, iar numărul BIP i-a fost atribuit în aprilie 2024.
- OP_CAT nu este în sine un angajament, dar, combinat cu alte coduri operaționale, poate fi utilizat pentru a crea restricții de cheltuieli similare angajamentelor, inclusiv seifuri.
- Până la jumătatea anului 2026, OP_CAT nu a fost activat pe rețeaua principală Bitcoin. Principalele opțiuni pentru următorul soft fork de consens al Bitcoin sunt OP_CTV (BIP 119) și OP_CHECKSIGFROMSTACK (BIP 348), nu OP_CAT în sine.
- OP_CAT este deja operațional pe Fractal Bitcoin, un sidechain aliniat la Bitcoin, unde stă la baza standardului de token CAT20, și funcționează de ani de zile pe Liquid Network și Bitcoin Cash fără să se fi înregistrat vreo vulnerabilitate cunoscută.
- Un proiect NFT bazat pe Bitcoin, numit Quantum Cats, creat de Taproot Wizards, a transformat susținerea pentru OP_CAT într-o campanie de tip meme care a strâns peste 37 de milioane de dolari pentru dezvoltarea legată de OP_CAT.
Cum funcționează OP_CAT
Cea mai clară modalitate de a înțelege OP_CAT este să ne imaginăm sistemul de scripturi al Bitcoin ca pe un mic teanc de blocuri de construcție. Bitcoin Script, limbajul de programare care stă la baza fiecărei tranzacții Bitcoin, este un limbaj bazat pe stivă. Datele sunt introduse în stivă, codurile operaționale acționează asupra elementului aflat în vârful stivei, iar rezultatul determină dacă o tranzacție este validă.
OP_CAT preia primele două elemente din stivă și le concatenează, adică le unește cap la cap într-un singur element combinat, care este apoi plasat din nou în vârful stivei. Dacă stiva conține valorile „1” și „2”, executarea OP_CAT le elimină pe amândouă și le înlocuiește cu „12”. Conform specificației oficiale din BIP 347, OP_CAT ar introduce x1 || x2 pe stivă, simbolul cu două bare orizontale indicând concatenarea.
Există o limită importantă. OP_CAT eșuează dacă pe stivă se află mai puțin de două valori sau dacă combinarea acestora ar genera o valoare totală mai mare de 520 de octeți, aceasta fiind dimensiunea maximă a unui element de script în Bitcoin. Această limită de octeți are o importanță deosebită pentru istoria acestui cod operațional, la care vom reveni în scurt timp.
La prima vedere, îmbinarea a două șiruri de date nu pare a fi o funcționalitate deosebit de puternică. Însă limbajul de scriptare al Bitcoin nu a dispus niciodată de o metodă universală de combinare a valorilor din stivă, iar această lacună a limitat posibilitățile dezvoltatorilor de a integra direct funcționalități în tranzacțiile Bitcoin. Așa cum Bitcoin Optech explică, Tapscript-ul Bitcoin nu dispune de o metodă generală de combinare a obiectelor din stivă, ceea ce limitează capacitatea de expresie a limbajului Tapscript și împiedică, printre altele, posibilitatea de a construi și evalua arbori Merkle și alte structuri de date hash direct în Tapscript. OP_CAT este soluția propusă pentru a remedia această lacună specifică.
De ce a fost dezactivată funcția OP_CAT în 2010?
OP_CAT a făcut parte din prima versiune a Bitcoin. Satoshi Nakamoto l-a eliminat, împreună cu alte câteva coduri operaționale, precum OP_MUL, OP_DIV și OP_OR, în 2010. Motivul oficial invocat a fost riscul de atac de tip „denial-of-service”: un script care utilizează OP_CAT în mod repetat ar putea, în teorie, să genereze o cantitate de date care crește exponențial, suficient de mare încât să încetinească sau să blocheze nodurile care încearcă să o valideze.
La acea vreme, nu exista o limită strictă privind dimensiunea maximă a unui singur element din stiva Bitcoin. Aceasta însemna că un script rău intenționat putea continua să concateneze valori până când genera un șir de date suficient de voluminos încât să blocheze rețeaua. Eliminarea OP_CAT, alături de celelalte coduri operaționale dezactivate, a fost o măsură conservatoare care a acordat prioritate stabilității rețelei în detrimentul unor funcționalități de care rețeaua, aflată încă la început, nu avea încă nevoie.
Situația s-a schimbat în noiembrie 2021, când Bitcoin a activat actualizarea Taproot. Taproot a introdus Tapscript, un nou context de scriptare cu propriile reguli, una dintre acestea limitând orice element individual din stivă la 520 de octeți. Această limită de octeți blochează direct calea de atac inițială. Un script poate apela în continuare OP_CAT, dar nu poate produce niciodată o valoare suficient de mare pentru a crea genul de problemă de epuizare a resurselor care îl îngrijora pe Satoshi în 2010. Acesta este detaliul tehnic care a redeschis ușa pentru readucerea OP_CAT, limitată însă la Tapscript, și nu la întregul Bitcoin Script.
OP_CAT este un „Covenant”?
Nu, nu în sine, iar acesta este unul dintre aspectele cel mai des înțelese greșit în legătură cu OP_CAT. Un „covenant”, în terminologia Bitcoin, reprezintă o restricție privind modul în care o ieșire de tranzacție necheltuită (UTXO) poate fi cheltuită în viitor. Scriptul Bitcoin obișnuit poate verifica doar dacă o cheltuire este autorizată în momentul respectiv, de obicei prin verificarea unei semnături. Un „covenant” merge mai departe, verificând nu doar dacă o cheltuire este autorizată, ci și dacă tranzacția rezultată corespunde unui set specific de condiții.
OP_CAT nu include niciun mecanism încorporat pentru verificarea datelor tranzacției. Ceea ce oferă este o modalitate de a combina fragmente de date din stivă, care devine utilă pentru clauzele contractuale numai atunci când este combinată cu alte coduri operaționale care verifică semnăturile în raport cu datele combinate respective. Chiar BIP 347 precizează în mod clar că OP_CAT, deși a fost propus pentru reactivare în Tapscript, nu este un „covenant”. Este mai corect să-l descriem ca pe un element constitutiv care, combinat cu coduri operaționale de verificare a semnăturilor, poate fi utilizat pentru a emula un comportament similar celui al unui „covenant”.
Acest aspect este important deoarece flexibilitatea OP_CAT este exact ceea ce îl face atât interesant, cât și controversat. Deși OP_CAT nu este neapărat un „covenant” în sine, acesta poate emula „covenants” datorită unei particularități a modului în care funcționează semnăturile Schnorr. În combinație cu un cod operațional numit CheckSigFromStack (CSFS), care verifică o semnătură în raport cu date arbitrare, nu doar cu tranzacția în sine, OP_CAT poate fi folosit pentru a crea același tip de restricții de cheltuieli pe care sunt concepute să le creeze codurile operaționale dedicate clauzelor.
La ce ar putea fi folosit OP_CAT?
Deoarece OP_CAT este o primitivă cu utilizare generală, și nu o funcționalitate cu domeniu de aplicare restrâns, dezvoltatorii au propus o gamă largă de aplicații pentru aceasta. Printre cele mai des discutate se numără:
- Cripte. Un „vault” este un tip de acord care necesită mai mulți pași, adesea desfășurați în cadrul unor tranzacții și blocuri distincte, înainte ca fondurile să poată fi transferate. Acest lucru introduce o întârziere încorporată care îi oferă proprietarului timp să observe și să oprească cheltuielile neautorizate, îmbunătățind astfel configurațiile de stocare la rece și de custodie partajată.
- Contracte fără ambiguitate. Acestea pot sancționa o parte dintr-un canal de plată, cum ar fi Lightning Network, care încearcă să difuzeze o stare a canalului învechită sau frauduloasă, consolidând astfel securitatea sistemelor de plată off-chain.
- Trei semnături. OP_CAT permite crearea de scripturi compacte cu semnături multiple, a căror dimensiune crește doar logaritmic odată cu numărul de semnatari, ceea ce înseamnă că o tranzacție cu o dimensiune sub 1 kilobyte ar putea, teoretic, să suporte condiții de cheltuire pentru milioane de chei publice.
- Construirea și verificarea arborelui Merkle. Întrucât construirea și verificarea unui arbore Merkle implică, în esență, concatenarea și hash-ul valorilor, OP_CAT oferă Bitcoin Script elementul care lipsea pentru a realiza acest lucru în mod nativ.
- Semnături post-cuantice. OP_CAT poate activa semnăturile Lamport, un sistem de semnături considerat rezistent la atacurile computerelor cuantice, întrucât semnăturile Lamport nu necesită altceva decât capacitatea de a genera hash-uri și de a concatena valori pe stivă.
- Active tokenizate și punți inter-lanțuri. Prin permiterea unor scripturi mai expresive, OP_CAT ar putea sprijini emiterea de tokenuri direct pe lanțuri compatibile cu Bitcoin și crearea unor punți cu un nivel minim de încredere între Bitcoin și alte rețele.
Merită să fim clari și în privința compromisurilor din acest context. Aceeași flexibilitate care face ca OP_CAT să fie util pentru toate situațiile menționate mai sus este tocmai ceea ce îi determină pe unii dezvoltatori Bitcoin să fie precauți în privința sa. Deoarece OP_CAT este o funcție de uz general, mai degrabă decât una specializată, aceasta deschide ceea ce dezvoltatorii numesc uneori un „spațiu de proiectare” extins, ceea ce înseamnă că este mai dificil de prevăzut toate modurile în care ar putea fi combinată în cele din urmă cu alte coduri operaționale. Această incertitudine se află în centrul dezbaterii actuale, nu este o chestiune secundară.
OP_CAT vs. OP_CTV: O comparație între cele două propuneri principale privind pactul
OP_CAT este de obicei discutat împreună cu OP_CTV (OP_CheckTemplateVerify), propus în BIP 119 de către dezvoltatorul Jeremy Rubin. Ambele au ca scop dotarea Bitcoin cu o anumită formă de capacitate de angajament contractual, dar adoptă abordări de proiectare aproape opuse.
Diferența practică se reduce la domeniul de aplicare. OP_CTV permite ca o ieșire a tranzacției să se angajeze față de o singură tranzacție de cheltuire viitoare, specifică, acoperind detalii precum versiunea, locktime, ieșirile și numărul de intrări. Dacă se respectă șablonul, tranzacția de cheltuire se efectuează. Dacă nu se potrivește, tranzacția nu se efectuează. Această limitare este intenționată. CTV este nerecursiv, ceea ce înseamnă că o tranzacție la care se angajează nu se poate angaja la rândul ei la restricții suplimentare, într-un mod care să creeze un lanț permanent de constrângeri. Susținătorii consideră că aceasta este forma mai sigură și mai controlată de angajament.
OP_CAT adoptă o filosofie opusă. În loc să rezolve o problemă specifică, le oferă dezvoltatorilor o primitivă flexibilă și le permite să construiască pe baza acesteia. În timp ce CTV este un cod de operație cu domeniu de aplicare bine definit, conceput pentru a permite un set specific de cazuri de utilizare, OP_CAT este o primitivă – concatenarea de șiruri de caractere pe stivă – care exista deja în limbajul de scriptare original al Bitcoin înainte de a fi dezactivată în 2010 din cauza preocupărilor legate de atacurile de tip „denial-of-service”, preocupări care nu mai sunt valabile în contextul limitelor de dimensiune a scripturilor post-Taproot. Aceeași flexibilitate este cea care permite OP_CAT să suporte clauze recursive, în care o restricție poate genera o altă restricție în lanț, o proprietate pe care OP_CTV o evită în mod deliberat.
OP_CAT este activ astăzi în rețeaua Bitcoin?
Nu pe rețeaua principală Bitcoin. BIP 347 a atins statutul de „Complet” ca document de specificație, ceea ce înseamnă că propunerea în sine este finalizată și bine definită. Acest lucru este diferit de implementarea efectivă, care ar necesita ca comunitatea Bitcoin în ansamblu și operatorii de noduri să o activeze efectiv printr-un soft fork.
La jumătatea anului 2026, OP_CAT nu este principalul candidat pentru următoarea modificare a mecanismului de consens al Bitcoin. Această poziție îi revine în prezent lui OP_CTV, alături de OP_CHECKSIGFROMSTACK (BIP 348), un cod operațional înrudit care permite unui script să verifice o semnătură în raport cu date arbitrare, nu doar cu tranzacția de cheltuire în sine. Conform unui Ghidul de referință recent privind BIP-urile Bitcoin, începând cu jumătatea anului 2026, principalii candidați pentru următorul soft fork de consens sunt propunerile de convenție BIP 119 (OP_CHECKTEMPLATEVERIFY) și BIP 348 (OP_CHECKSIGFROMSTACK), care ar permite noi capacități de scripting pentru seifuri, fabrici de canale și protocoale de nivel 2 mai eficiente, deși nu a fost stabilit încă un calendar de activare, iar consensul comunității este încă în curs de formare.
OP_CTV a avansat mai mult în procesul de activare decât OP_CAT. Dezvoltatorii au publicat parametri concreți de semnalizare pentru un soft fork de tip BIP9: o dată de începere a semnalării stabilită pentru 30 martie 2026, o perioadă de așteptare de un an care se încheie la 30 martie 2027, o înălțime minimă de activare în jurul lunii mai 2027 și un prag de semnalare de 90% din partea minerilor pe parcursul fiecărei perioade de dificultate de două săptămâni. Astfel, CTV va urma același tip de mecanism care a activat Taproot în 2021, deși atingerea pragului de 90% este departe de a fi garantată, având în vedere cât de controversate rămân propunerile de convenții în cadrul comunității de dezvoltatori.
Nimic din toate acestea nu înseamnă că OP_CAT a dispărut. Înseamnă că „următoarea” discuție privind soft fork-ul din 2026 se concentrează în prezent pe o altă pereche de coduri operaționale, iar viitorul OP_CAT, dacă acesta există, va depinde probabil de modul în care se va desfășura mai întâi dezbaterea privind CTV și CSFS.
OP_CAT funcționează deja în altă parte
Deși OP_CAT este încă în așteptare pe rețeaua principală Bitcoin, nu rămâne netestat. De ani de zile, acesta funcționează discret în mediul de producție pe câteva rețele legate de Bitcoin.
- Rețeaua Liquid. Sidechain-ul federat al Blockstream a avut funcția OP_CAT activată încă de la lansare, oferind ecosistemului Bitcoin în ansamblu un mediu de testare în condiții reale cu ani înainte ca BIP 347 să existe măcar.
- Bitcoin Cash și Bitcoin SV. Ambele rețele au reintrodus OP_CAT în cadrul actualizărilor de protocol, iar acesta a procesat tranzacții pe aceste lanțuri fără ca să se fi înregistrat vreo vulnerabilitate legată de codul de operație în sine.
- Bitcoin fractal. Aceasta este cea mai activă implementare din prezent. Fractal este un sidechain aliniat la Bitcoin, construit folosind propriul software al Bitcoin Core și minat în paralel cu Bitcoin, care și-a lansat rețeaua principală pe 9 septembrie 2024, cu OP_CAT activat încă din prima zi.
Fractal merită o analiză mai atentă, deoarece reprezintă răspunsul cel mai clar la întrebarea „cum ar arăta acest lucru, de fapt, pe Bitcoin”. De la lansarea Fractal, noi protocoale au folosit OP_CAT pentru a crea contracte inteligente bazate pe software-ul Bitcoin, inclusiv Protocolul CAT, care a stârnit un interes semnificativ în rândul utilizatorilor nativi ai Bitcoin, alături de alte standarde emergente care extind funcționalitatea rețelei folosind OP_CAT.
Exemplul cel mai reprezentativ este CAT20, un standard de token fungibil creat special pentru a valorifica OP_CAT. Conform Documentația proprie a Fractal Bitcoin, CAT20 este validat integral de către mineri și funcționează pe baza contractelor inteligente, mai precis a clauzelor recursive, aplicate în întregime prin limbajul de scriptare propriu al Bitcoin la nivelul stratului de bază, ceea ce îl deosebește de standardele de tokenuri care se bazează pe validarea externă sau de către terți. În practică, aceasta înseamnă că implementarea, emiterea și transferul unui token CAT20 se realizează printr-o secvență de operațiuni OP_CAT care construiesc un singur șir de date, care este apoi înscris direct pe blockchain și verificat de aceiași mineri care asigură securitatea rețelei, și nu de un serviciu separat de indexare off-chain.
Povestea Quantum Cats: Cum o campanie bazată pe meme a impulsionat proiectul OP_CAT
Majoritatea propunerilor de coduri operaționale rămân limitate la listele de discuții și la thread-urile de pe GitHub. OP_CAT nu a fost cazul, în mare parte datorită unui proiect Bitcoin Ordinals numit Taproot Wizards.
În ianuarie 2024, Taproot Wizards a lansat o colecție în stil NFT formată din 3.333 de piese, numită „Quantum Cats”, concepută în întregime cu scopul de a genera sprijin public pentru reactivarea OP_CAT. Quantum Cats dorea ca OP_CAT să creeze o punte fără permisiuni care să poată transfera bitcoin și activele bazate pe bitcoin pe lanțurile de nivel 2 ale Bitcoin, unde acestea ar putea participa la tranzacții mai complexe. Pentru a se califica măcar pentru emisiune, participanții trebuiau să se familiarizeze cu propunerea tehnică propriu-zisă și să pledeze public pentru revenirea acesteia, transformând o discuție destul de aridă despre BIP într-o campanie comunitară cu mize reale.
Colecția în sine a servit și ca demonstrație a concatenării în acțiune. Fiecare „Quantum Cat” face referire la mai multe fișiere separate, nu la o singură imagine statică, iar pe măsură ce noi fișiere sunt dezvăluite în timp, pisicile se schimbă, reflectând exact modul în care funcționează OP_CAT prin asamblarea unor fragmente separate de date.
Campania a avut un succes suficient de mare încât să se concretizeze într-o finanțare substanțială. Taproot Wizards a strâns 7,5 milioane de dolari în 2023, urmată de o rundă de finanțare de 30 de milioane de dolari în februarie 2025, ambele sume fiind alocate în mod explicit dezvoltării ecosistemului OP_CAT. Cofondatorul Udi Wertheimer a descris proiectul ca fiind axat pe OP_CAT ca viitor al Bitcoin, fondurile fiind direcționate atât către dezvoltarea internă, cât și către sprijinirea echipelor externe care construiesc pe baza acestui opcode. O singură vânzare a unui „Quantum Cat” la Sotheby’s, denumită „Genesis Cat”, s-a încheiat la 254.000 de dolari, subliniind cât de mare a devenit impactul cultural al campaniei în jurul unui opcode de patru octeți.
Este un memento util că dezbaterile tehnice legate de Bitcoin nu rămân întotdeauna la nivel tehnic. Memele, arta și banii au devenit în repetate rânduri instrumente pentru a aduce discuțiile despre protocol în atenția unui public mai larg, iar OP_CAT este unul dintre cele mai clare exemple recente ale acestui fenomen.
Concluzie
OP_CAT face un singur lucru simplu: unește două elemente de date din stiva Bitcoin într-unul singur. Ceea ce îl face semnificativ este tot ceea ce această singură funcție ar putea face posibil, de la seifuri de stocare la rece mai sigure la semnături post-cuantice și până la tokenuri native Bitcoin, dacă comunitatea Bitcoin ar fi vreodată de acord să o reintroducă. Până în iulie 2026, acest acord nu s-a concretizat. BIP 347 este o specificație finalizată, situată în spatele OP_CTV și OP_CHECKSIGFROMSTACK în lista de așteptare pentru următorul soft fork de consens al Bitcoin, chiar dacă OP_CAT continuă să funcționeze în liniște și fără incidente pe Fractal Bitcoin, Liquid și alte rețele legate de Bitcoin. Indiferent ce se va întâmpla în continuare, dezbaterea din jurul OP_CAT a demonstrat deja cum o bucată mică și simplă de cod poate atrage simultan dezvoltatori, artiști și investitori.
