Ce este limbajul de script Bitcoin?

Bitcoin Script este limbajul de programare care controlează fiecare tranzacție din rețeaua Bitcoin. Este un limbaj simplu, bazat pe stivă, care definește condițiile exacte în care pot fi cheltuiți bitcoinii, iar fiecare nod complet din rețea îl execută de fiecare dată când o tranzacție este validată. Fără el, Bitcoin ar fi un registru de numere, fără niciun mecanism care să stabilească cui îi aparține ce.

Majoritatea utilizatorilor nu intră niciodată în contact direct cu limbajul de scriptare Bitcoin. Portofelele lor se ocupă de acest aspect în mod invizibil. Însă de fiecare dată când trimiți sau primești BTC, două programe mici se execută simultan pe mii de computere, verificând dacă au fost îndeplinite condițiile de cheltuire. Înțelegerea modului în care funcționează acest lucru explică în mare măsură de ce Bitcoin este structurat așa cum este și ce poate și ce nu poate face în comparație cu platforme precum Ethereum.

Acest articol prezintă modul de funcționare al Bitcoin Script, descrie principalele tipuri de tranzacții pe care le permite, explică actualizarea Taproot care a modernizat stratul de scriptare în 2021 și prezintă stadiul actual al dezbaterii privind opcodul „covenant” la data de iunie 2026.

Gestionează-ți Bitcoin-ul în siguranță cu soluția de auto-custodie Aplicația Bitcoin.com Wallet.

Concluzii cheie

• Bitcoin Script este un limbaj de programare bazat pe stivă, integrat în protocolul Bitcoin, care definește condițiile în care poate fi cheltuită orice ieșire Bitcoin.
• Fiecare tranzacție Bitcoin include două scripturi: un script de blocare (ScriptPubKey) stabilit de destinatar și un script de deblocare (ScriptSig) furnizat de expeditor. Ambele trebuie să se execute cu succes pentru ca tranzacția să fie validă.
• Scriptul Bitcoin nu este, în mod intenționat, Turing-complet. Nu conține bucle, nu păstrează starea între execuții și are limite stricte privind dimensiunea scriptului. Astfel, se garantează că fiecare script se va încheia, ceea ce reprezintă o caracteristică de securitate, nu o limitare.
• Limbajul de scriptare a evoluat prin cinci formate principale: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) și Taproot (P2TR), fiecare dintre acestea extinzând posibilitățile existente, menținând în același timp compatibilitatea cu versiunile anterioare.
• Taproot (noiembrie 2021) a introdus semnăturile Schnorr, traseele de cheltuieli bazate pe MAST pentru protejarea confidențialității și Tapscript, un limbaj de scriptare actualizat, dotat cu un mecanism integrat care permite actualizări viitoare mai ușoare.
• Printre cazurile de utilizare din lumea reală bazate pe Bitcoin Script se numără portofelele cu semnături multiple, tranzacțiile cu blocare temporară, contractele cu blocare temporară bazate pe hash (fundamentul rețelei Lightning), serviciile de escrow și contractele cu jurnal discret.
• Spre deosebire de contractele inteligente Ethereum, Bitcoin Script nu ține evidența stării: fiecare script rulează în izolare completă, fără a avea cunoștință despre nicio altă tranzacție. Aceasta este o alegere arhitecturală deliberată.
• Domeniul cel mai activ al dezvoltării scripturilor Bitcoin în 2026 îl reprezintă codurile de operație (opcode) de tip „covenant”, în special OP_CTV (BIP-119) și OP_CAT (BIP-347), care ar permite scripturilor să impună anumite condiții privind forma pe care trebuie să o aibă o tranzacție de cheltuire. Niciunul dintre acestea nu a fost încă activat pe rețeaua principală.

Ce este Bitcoin Script?

Bitcoin Script este un limbaj de scriptare bazat pe stivă și fără stare, integrat în protocolul Bitcoin. Fiecare ieșire a unei tranzacții din rețeaua Bitcoin conține un script de blocare (numit ScriptPubKey) care specifică condițiile de cheltuire a fondurilor. Oricine dorește să cheltuiască aceste fonduri trebuie să furnizeze un script de deblocare (numit ScriptSig sau, în cazul tranzacțiilor SegWit și Taproot, datele martor) care să îndeplinească aceste condiții.

Limbajul își are structura inspirată din Forth, un limbaj de programare minimalist bazat pe stivă, dezvoltat în anii 1960. La fel ca Forth, Bitcoin Script se citește de la stânga la dreapta, operează pe o structură de date numită stivă și utilizează notația poloneză inversă (RPN), în care operatorii urmează operanzii, în loc să îi precede. Acesta execută câte o instrucțiune pe rând, nu are bucle și nu păstrează memoria între execuții.

Acest ultim aspect este cel cu care se confruntă majoritatea oamenilor atunci când încep să învețe despre Bitcoin Script la nivel de protocol: limbajul nu este, în mod intenționat, Turing-complet. Un limbaj Turing-complet poate efectua orice calcul, cu condiția să dispună de timp și resurse suficiente. Bitcoin Script nu poate face acest lucru, prin însăși concepția sa, iar motivele care stau la baza acestei alegeri au o importanță deosebită pentru modul în care funcționează rețeaua.

Cum funcționează scriptul Bitcoin: modelul stivei

Pentru a înțelege cum funcționează Bitcoin Script, trebuie să înțelegi conceptul de stivă. O stivă este o structură de date care funcționează pe principiul „ultimul intrat, primul ieșit” (LIFO). Imaginați-vă o stivă de farfurii: puteți adăuga sau scoate doar de la vârf. În Bitcoin Script, datele sunt introduse în stivă, iar codurile de operație (opcode) manipulează ceea ce se află la vârf.

Atunci când un nod Bitcoin validează o tranzacție, acesta execută două scripturi în ordine:

1. Scriptul de deblocare (ScriptSig sau martor) furnizate de persoana care cheltuiește monedele. Aceasta plasează datele pe stivă, de obicei o semnătură digitală și o cheie publică.
2. Scriptul de blocare (ScriptPubKey) asociată cu cheltuirea ieșirii. Aceasta conține coduri operaționale care acționează asupra datelor din stivă și verifică dacă sunt îndeplinite condițiile de cheltuire.

Dacă scriptul se execută fără erori și lasă la final o valoare diferită de zero (TRUE) în stivă, tranzacția este validă. Dacă eșuează sau lasă valoarea FALSE, tranzacția este respinsă de nod și nu ajunge niciodată într-un bloc.

Această execuție se desfășoară fără a păstra starea. Scriptul nu are cunoștință despre nicio tranzacție anterioară, nu are informații despre soldurile curente și nu păstrează nicio memorie după ce execuția sa se încheie. Fiecare script se execută de la zero, în mod izolat, de fiecare dată.

Pas cu pas: o tranzacție standard P2PKH

Pay-to-Public-Key-Hash (P2PKH) este tipul original de tranzacție Bitcoin, utilizat încă din 2009. Adresele P2PKH încep cu „1”. Iată cum arată ScriptPubKey și ScriptSig în practică:

Script de deblocare (ScriptSig):

<semnătură> <cheie publică>

Script de blocare (ScriptPubKey):

OP_DUP OP_HASH160 <hash-ul cheii publice> OP_EQUALVERIFY OP_CHECKSIG

Atunci când nodul concatenează și execută ambele operații simultan, operațiile din stivă se desfășoară pas cu pas:

• Semnătura și cheia publică din ScriptSig sunt plasate pe stivă
• OP_DUP duplică cheia publică aflată în vârful stivei
• OP_HASH160 calculează hash-ul duplicatului (SHA-256 urmat de RIPEMD-160), generând un hash de 20 de octeți
• Hash-ul cheii publice din scriptul de blocare este introdus în stivă
• OP_EQUALVERIFY verifică dacă cele două hash-uri se potrivesc. Dacă nu se potrivesc, execuția se oprește și tranzacția eșuează.
• OP_CHECKSIG verifică dacă semnătura este valabilă pentru cheia publică

Dacă toate etapele sunt parcurse cu succes, stiva se încheie cu valoarea TRUE, iar fondurile sunt eliberate. Întregul proces durează câteva milisecunde și se desfășoară identic pe fiecare nod din rețea.

Explicații privind codurile de operație Bitcoin

Codurile operaționale Bitcoin sunt comenzile individuale care alcătuiesc un script. Fiecare dintre ele are o lungime de un singur octet, ceea ce înseamnă că există 256 de sloturi posibile pentru coduri operaționale. Dintre acestea, aproximativ 80 sunt active în prezent pe rețeaua principală. Restul sunt fie rezervate, fie dezactivate, fie alocate mecanismului de compatibilitate cu versiunile viitoare OP_SUCCESS, introdus odată cu Tapscript.

Codurile de operație se împart în mai multe categorii:

• Coduri operaționale de transmitere a datelor să introducă pe stivă valori precum cheile publice, semnăturile și valorile hash
• Coduri de operație aritmetice efectuează operații de adunare, scădere și comparație. De remarcat că înmulțirea și împărțirea sunt dezactivate.
• Coduri de operație criptografice includ OP_SHA256, OP_HASH160, OP_SHA1 pentru generarea de hash-uri și OP_CHECKSIG pentru verificarea semnăturilor
• Coduri de operație pentru controlul fluxului activarea logicii condiționale: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Coduri de operație pentru manipularea stivei printre care se numără OP_DUP (duplicarea elementului de sus), OP_DROP (eliminarea elementului de sus) și OP_SWAP (schimbarea între primele două elemente)

Mai multe coduri operaționale au fost dezactivate de Satoshi Nakamoto în 2010, după ce au fost descoperite vulnerabilități în implementările lor inițiale. Printre acestea se numără OP_CAT (concatenează două elemente din stivă), OP_MUL (înmulțire) și OP_DIV (împărțire). Absența acestora a avut consecințe de durată asupra capacităților de exprimare ale Bitcoin Script, iar câteva dintre cele mai intens dezbătute propuneri de actualizare a Bitcoin din 2026 vizează reactivarea unora dintre acestea.

Pentru referința completă a codurilor de operație, inclusiv valorile hexazecimale și descrierile, consultați Pagina „Bitcoin Wiki Script” este sursa de referință.

De ce faptul că un sistem nu este complet în sensul lui Turing reprezintă o caracteristică

Explicația standard este că Bitcoin Script nu conține bucle, astfel încât se garantează că scripturile se vor încheia, iar rețeaua este protejată împotriva execuției infinite. Aceasta este o afirmație corectă, dar nu surprinde pe deplin esența problemei.

Argumentul mai profund se referă la suprafața de atac. Un limbaj Turing-complet poate exprima calcule arbitrare. Această expresivitate reprezintă totodată spațiul în care se ascund erorile. Solidity, limbajul de programare al Ethereum, a generat unele dintre cele mai costisitoare vulnerabilități software din istorie. Atacul asupra DAO din 2016 a exploatat o vulnerabilitate de reentrare într-un contract inteligent și a provocat pierderi de aproximativ 60 de milioane de dolari la prețurile de atunci, ducând în cele din urmă la un hard fork controversat al rețelei Ethereum. Ecosistemul DeFi în ansamblu a înregistrat pierderi de sute de milioane de dolari ca urmare a exploatării contractelor inteligente pe parcursul mai multor ani.

Scriptul Bitcoin face ca acest tip de atac să fie imposibil din punct de vedere structural. Nu se poate scrie un script Bitcoin care să apeleze alte scripturi, să execute bucle până la schimbarea unei condiții sau să stocheze starea între tranzacții. Fiecare script este un program delimitat, care se termină și poate fi inspectat. Dimensiunea maximă a unui script este de 10.000 de octeți. Numărul maxim de coduri operaționale (opcode) care nu sunt de tip „push” per script este de 201. Un validator poate calcula întotdeauna costul de execuție în cel mai rău caz înainte de a rula scriptul.

Pentru o rețea cu o valoare de sute de miliarde de dolari, această previzibilitate valorează mai mult decât flexibilitatea la care renunți. Ethereum rezolvă problema calculului nelimitat prin limite de gaz, taxând utilizatorii pentru fiecare cod operațional executat și oprind scripturile care depășesc bugetul alocat. Această abordare funcționează, dar introduce propria complexitate și propriile moduri de eșec. Bitcoin ocolește complet această problemă prin însăși concepția sa.

Cu toate acestea, „nu este Turing-complet” nu înseamnă „nu este capabil de logică complexă”. Bitcoin Script acceptă cerințe de cheltuire cu mai mulți participanți, condiții bazate pe timp, dezvăluirea preimaginii hash-ului și combinații ale tuturor acestor elemente. Rețeaua Lightning, care procesează milioane de plăți pe zi, este construită în întregime pe elementele primitive ale Bitcoin Script.

Tipuri de scripturi: Evoluția de la P2PKH la Taproot

Stratul de scripturi al Bitcoin a evoluat semnificativ începând din 2009, fiecare actualizare introducând un nou format de tranzacție, menținând în același timp compatibilitatea cu toate versiunile anterioare.

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

Formatul original, utilizat în primele tranzacții Bitcoin, inclusiv în plata efectuată de Satoshi către Hal Finney în blocul 170. Fondurile erau blocate direct pe o cheie publică completă, și nu pe hash-ul acesteia. În prezent, acest format este rar utilizat în tranzacțiile noi, deoarece expune cheia publică pe lanț înainte de efectuarea plății, ceea ce este considerat o măsură de securitate mai slabă decât hash-area prealabilă a cheii.

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

Formatul standard de mai bine de un deceniu. P2PKH blochează fondurile pe un hash al cheii publice, nu pe cheia însăși, păstrând cheia publică confidențială până în momentul cheltuirii, generând o adresă mai scurtă, de 20 de octeți, și constituind baza tuturor adreselor care încep cu „1”. Conform datelor on-chain furnizate de Unchained (aprilie 2026), adresele P2PKH dețin în prezent aproximativ 43% din oferta de bitcoin minată.

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

Introdus printr-un soft fork la 1 aprilie 2012, P2SH a transferat sarcina scripturilor complexe de cheltuire de la expeditor la destinatar. În loc să încorporeze un script complet de blocare în ieșire, ieșirile P2SH se bazează pe un hash de 20 de octeți al unui „script de răscumpărare”. Scriptul complet este dezvăluit doar atunci când monedele sunt cheltuite. Acest lucru a făcut ca multisig-ul să devină practic pentru utilizatorii obișnuiți: o configurație multisig de tip 2 din 3 nu mai necesita ca toate cele trei chei publice să fie vizibile pentru expeditor în momentul plății. Adresele P2SH încep cu „3”.

Pentru o prezentare detaliată a modului în care funcționează validarea P2SH la nivel de protocol, Ghidul tranzacțiilor de pe developer.bitcoin.org prezintă pas cu pas mecanismul scriptului „redeem”.

P2WPKH și P2WSH (SegWit nativ, 2017, BIP 141)

Segregated Witness, activat în august 2017 la blocul 481.824, a mutat datele de semnătură din corpul principal al tranzacției într-o structură separată de tip „witness”. Datele „witness” beneficiază de o reducere a greutății de 75%, ceea ce face ca tranzacțiile SegWit să fie semnificativ mai ieftine. O tranzacție standard P2WPKH cu o singură intrare și două ieșiri are o greutate de aproximativ 141 de octeți virtuali, comparativ cu 226 de octeți virtuali pentru o tranzacție P2PKH echivalentă, conform Analiza tipurilor de adrese Bitcoin realizată de Spark începând cu martie 2026. SegWit a rezolvat, de asemenea, problema maleabilității tranzacțiilor, ceea ce a constituit o condiție prealabilă pentru rețeaua Lightning. Adresele native SegWit încep cu „bc1q.”

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

Taproot a fost activat în noiembrie 2021 la blocul 709.632 și reprezintă cea mai importantă actualizare a stratului de scriptare al Bitcoin de la SegWit încoace. Acesta a introdus semnăturile Schnorr, un nou tip de ieșire cu suport MAST și Tapscript ca limbaj de scriptare actualizat. Adresele Taproot încep cu „bc1p.”

Taproot și Tapscript: Cum s-a schimbat limbajul de scriptare Bitcoin în 2021

Taproot nu reprezintă o singură modificare. Este vorba de trei propuneri de îmbunătățire a Bitcoin (BIP) concepute împreună și activate simultan.

BIP 340: Semnăturile Schnorr

Bitcoin a folosit inițial algoritmul ECDSA (Elliptic Curve Digital Signature Algorithm). Satoshi l-a ales, în parte, deoarece semnăturile Schnorr erau protejate de un brevet la acea vreme. Brevetul respectiv a expirat în 2008, iar Taproot a integrat în cele din urmă semnăturile Schnorr în protocol.

Semnăturile Schnorr au o dimensiune mai mică, de 64 de octeți, față de 71-73 de octeți în cazul ECDSA. Mai important, acestea acceptă agregarea cheilor printr-un sistem numit MuSig2. Agregarea cheilor permite mai multor semnatari să-și combine cheile și semnăturile individuale într-o singură cheie și semnătură agregată, care este indistinctibilă pe lanț de o plată obișnuită cu o singură semnătură. O cheltuială efectuată dintr-un portofel multisig de tip 2 din 3 prin intermediul căii de chei cooperative a Taproot arată identic cu o plată standard pe blockchain. Acesta reprezintă un real câștig în materie de confidențialitate pentru oricine deține bitcoin într-un aranjament complex de custodie.

BIP 341: Pay-to-Taproot și MAST

P2TR introduce un nou tip de ieșire cu două căi de cheltuire:

• A calea cheie se efectuează folosind o semnătură Schnorr, utilizată atunci când toate părțile sunt de acord și doresc cea mai simplă și mai ieftină soluție
• A calea către script utilizarea MAST (Merkelized Abstract Syntax Tree, care reprezintă implementarea conceptului în Taproot)

MAST permite ca o singură ieșire să se raporteze la o structură arborescentă formată din mai multe scripturi de cheltuire prin intermediul unei rădăcini Merkle. La efectuarea cheltuielii, pe lanț este dezvăluită doar condiția specifică utilizată efectiv. Toate celelalte căi posibile de cheltuire din structura arborescentă rămân ascunse definitiv. Pentru un utilizator care a configurat o politică complexă de cheltuire, de exemplu „Pot cheltui în mod normal, sau doi dintre cei trei administratori pot cheltui după șase luni, sau o cheie de recuperare poate cheltui după doi ani”, pe blockchain apare întotdeauna doar calea care este efectiv executată.

Conform datelor Glassnode citate de Spark în martie 2026, până în 2024, ponderea Taproot în tranzacțiile cu Bitcoin a crescut la aproximativ 42%, în mare parte datorită activității de inscripționare a Ordinalelor și a BRC-20. De atunci, această pondere a fluctuat în funcție de condițiile pieței, dar infrastructura este acum standardizată în principalele portofele și platforme de tranzacționare. Pagina tematică dedicată Taproot de la Bitcoin Optech urmărește evoluția continuă a protocolului Taproot.

BIP 342: Transcrierea dialogului

Tapscript este limbajul de scriptare actualizat utilizat pentru tranzacțiile de tip „script-path” din cadrul Taproot. Acesta are în comun majoritatea codurilor de operație cu limbajul Bitcoin Script tradițional, dar introduce câteva modificări semnificative:

• OP_CHECKMULTISIG și OP_CHECKMULTISIGVERIFY sunt învechite. Vechiul cod de operație multisig avea o particularitate care impunea adăugarea unui element fictiv în stivă ca soluție de compromis. Tapscript îl elimină și îl înlocuiește cu OP_CHECKSIGADD, care verifică semnăturile Schnorr pe rând și ține evidența numărului acestora. Schemele multisig cu prag devin mai simple și mai ieftine de pus în practică.
• Limitele de dimensiune ale scripturilor pentru fiecare frunză MAST au fost eliminate. Scripturile individuale dintr-o ramură Taproot pot avea o dimensiune arbitrară.
• Coduri de operație OP_SUCCESS reprezintă cea mai inovatoare schimbare. În Script-ul tradițional, întâlnirea unui cod de operație nedefinit duce la eșuarea scriptului. În Tapscript, codurile de operație din intervalul OP_SUCCESS determină executarea cu succes a scriptului, în mod necondiționat. Viitoarele soft fork-uri pot atribui un comportament real acestor coduri operaționale prin adăugarea de constrângeri privind condițiile în care acestea au succes, fără a necesita o nouă versiune de script sau un ciclu complet de redeployare în întregul ecosistem. Noi capabilități pot fi adăugate la stratul de scriptare al Bitcoin într-un mod mai curat decât în orice moment anterior din istoria protocolului.

Miniscript

Alături de Tapscript, un proiect conex numit Miniscript a devenit din ce în ce mai relevant pentru dezvoltatori. Miniscript reprezintă o modalitate structurată de a scrie un subset al limbajului Bitcoin Script care poate fi analizat, combinat și semnat în mod generic. În timp ce Script-ul brut necesită construire manuală și este dificil de auditat, scripturile Miniscript pot fi verificate automat din punct de vedere al corectitudinii și combinate în politici mai ample. Acesta nu extinde capacitățile Script-ului, dar face ca funcționalitățile existente să fie semnificativ mai accesibile pentru dezvoltatorii care creează portofele și instrumente de custodie.

Ce permite Bitcoin Script: cazuri de utilizare din viața reală

În prezent, pe rețeaua principală Bitcoin sunt active următoarele tipuri de tranzacții, toate bazate pe elementele de bază ale limbajului Bitcoin Script:

Portofele cu semnături multiple (multisig) necesită M din N chei private pentru a autoriza o cheltuială. Trezoreria unei companii ar putea necesita 3 din 5 aprobări pentru orice retragere. Un cuplu căsătorit ar putea folosi 2 din 2 pentru economiile comune. Cu Taproot și agregarea cheilor Schnorr, cheltuielile multisig cooperative sunt acum, pe lanț, imposibil de distins de tranzacțiile standard cu o singură semnătură.

Tranzacții cu blocare temporară utilizați OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify sau CLTV) și OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify sau CSV) pentru a împiedica transferul fondurilor înainte de atingerea unei anumite înălțimi a blocului sau a expirării unui anumit interval de timp. Printre aplicații se numără planificarea succesiunii, programele de acordare a token-urilor angajaților, mecanismele de economisire forțată și tranzacțiile cu penalități utilizate în cadrul canalelor Lightning Network.

Contracte cu blocare temporală bazate pe hash (HTLC) combină o cerință privind preimaginea unui hash cu un timelock. Condiția de cheltuire funcționează astfel: dezvăluie preimaginea acestui hash înainte de atingerea acestei înălțimi a blocului, altfel fondurile se întorc la expeditor. HTLC-urile reprezintă elementul fundamental al rețelei Lightning, permițând rutarea plăților fără încredere prin lanțuri de canale între părți care nu au nicio relație directă.

Cont de garanție Aceste mecanisme blochează fondurile într-un script P2SH sau Taproot, care necesită acordul mai multor părți înainte de eliberarea acestora, de obicei cu un arbitru terț care deține o cheie de departajare.

Contracte de jurnal discret (DLC) utilizează semnături de tip adaptor Schnorr bazate pe oracol pentru a permite derularea contractelor financiare pe baza datelor din lumea reală, cum ar fi fluxurile de prețuri sau rezultatele evenimentelor, fără ca oracolul să fie nevoit să dețină în custodie vreun fond. DLC-urile sunt active pe rețeaua principală Bitcoin și sunt utilizate pentru opțiuni și contracte futures decontate în Bitcoin.

Scriptul Bitcoin vs. contractele inteligente Ethereum

Atât Bitcoin Script, cât și Solidity de la Ethereum definesc condițiile în care pot fi transferate fondurile, dar reprezintă alegeri arhitecturale fundamental diferite. Merită să se facă această comparație directă, deoarece diferențele explică în mare măsură compromisurile pe care fiecare rețea le-a acceptat.

Linia de demarcație fundamentală este caracterul statal. Contractele Ethereum stochează și modifică date care persistă de la o tranzacție la alta, făcând posibile protocoalele de împrumut, bursele descentralizate, guvernanța în lanț și standardele de tokenuri. Scriptul Bitcoin nu are un echivalent. Fiecare script rulează izolat, fără a avea cunoștință de nicio altă tranzacție.

Aceasta este o alegere arhitecturală deliberată, nu o lacună care așteaptă să fie completată. Stratul de scripturi al Bitcoin a fost conceput pentru o singură sarcină specifică: asigurarea respectării condițiilor de cheltuire a bitcoin-urilor, în mod previzibil și sigur, la scară largă. Pentru această sarcină, lipsa stării reprezintă un avantaj. Suprafața de atac este mai mică, execuția este deterministă la nivelul a milioane de validatori independenți, iar la nivelul protocolului nu există nicio categorie de exploatare a contractelor inteligente, deoarece nu există contracte cu stare la nivelul protocolului.

Proiectele care doresc un nivel mai ridicat de programabilitate pe lângă Bitcoin o implementează pe straturi. Rețeaua Lightning se ocupă de plăți. Protocoalele DLC gestionează contractele financiare care fac referire la date externe. Sistemele de nivel 2, precum Ark și Liquid Network, răspund unor profiluri diferite de scalabilitate. Niciuna dintre aceste soluții nu necesită modificarea modelului de scripting al stratului de bază.

Dezbaterea privind „Covenant”: Ce s-ar putea schimba în scriptul Bitcoin

Evoluția limbajului de script Bitcoin a fost întotdeauna lentă și conservatoare. Cel mai activ domeniu de dezvoltare în acest moment îl reprezintă opcodurile de tip „covenant”, care sunt propuneri ce ar permite unui script să impună restricții nu doar asupra persoanelor care pot cheltui o ieșire, ci și asupra modului în care trebuie să arate tranzacția rezultată. Aceasta reprezintă o extindere semnificativă a puterii de expresie a limbajului de script.

Propunerile principale, la data de iunie 2026, sunt următoarele:

• OP_CTV (BIP-119, CheckTemplateVerify), elaborată de Jeremy Rubin, adaugă un singur cod de operație care alocă un UTXO unui șablon de cheltuire specific și prestabilit, incluzând versiunea tranzacției, timpul de blocare, numărul de intrări, secvențele, numărul de ieșiri și ieșirile. Este concepută ca fiind nerecursivă, fiind considerată cea mai conservatoare propunere majoră, și vizează în principal seifurile, controlul congestiei și anumite îmbunătățiri ale rețelei Lightning. Începând cu aprilie 2026, OP_CTV are pe masă parametri concreți de implementare care specifică o fereastră de semnalizare „Speedy Trial”, dar nu a obținut consensul larg al comunității necesar pentru activare, conform Analiza clauzelor contractuale ale BlockEden pentru aprilie 2026.
• OP_CAT (BIP-347), propus de Ethan Heilman și Armin Sabouri, ar reactiva un cod operațional pe care Satoshi l-a dezactivat în 2010. OP_CAT concatenează două elemente din stivă, ceea ce este simplu în descriere, dar are implicații ample. Atunci când este combinat cu semnăturile Schnorr, acesta permite o introspecție a tranzacțiilor de tip „covenant”. Pe rețeaua de testare Bitcoin Signet, OP_CAT a generat un număr semnificativ mai mare de tranzacții ale dezvoltatorilor decât APO sau CTV, conform analizei on-chain realizate de sCrypt la sfârșitul anului 2024. OP_CAT este deja activ pe rețeaua Liquid și pe Fractal Bitcoin, fără ca vreun exploit să-i fie atribuit. BIP-347 are un număr oficial de propunere și cercetări active în spate, dar activarea pe rețeaua principală necesită un consens al comunității care încă nu există.
• LNHANCE combinează OP_CTV cu OP_CHECKSIGFROMSTACK (CSFS) și OP_INTERNALKEY, având ca obiectiv îmbunătățiri specifice în ceea ce privește construirea canalelor din rețeaua Lightning, inclusiv deschiderea canalelor neinteractive și gestionarea mai eficientă a canalelor cu mai mulți participanți.

Niciuna dintre acestea nu a fost activată pe rețeaua principală Bitcoin până în iunie 2026. Disensiunile tehnice dintre ele pot fi, în mare parte, rezolvate. Problema mai dificilă o reprezintă mecanismele de activare. Procesul de soft fork al Bitcoin necesită un consens larg, iar dezbaterea privind convenția este marcată de tensiuni reziduale din actualizările controversate anterioare. Ceea ce reiese clar din dezbatere este că stratul de scriptare al Bitcoin are un potențial semnificativ de dezvoltare în cadrul său conservator. Problema care se încearcă a fi rezolvată este ordinea de implementare și acordul comunității, nu dacă limbajul de scriptare are sau nu un viitor.

Concluzie

Bitcoin Script reprezintă infrastructura invizibilă care stă la baza fiecărei tranzacții din rețea. Majoritatea utilizatorilor nu intră niciodată în contact direct cu acesta. Portofelele creează scripturi valide, le semnează și le transmit fără a dezvălui vreodată mecanismele din spate. Însă fiecare plată, fiecare canal Lightning, fiecare plan cu blocare temporală și fiecare seif multisig funcționează prin același limbaj de scriptare Bitcoin bazat pe stivă, care a fost lansat odată cu protocolul în 2009.

De atunci, stratul de scripting s-a dezvoltat considerabil: P2SH a făcut posibile tranzacțiile complexe, SegWit a redus comisioanele și a permis implementarea rețelei Lightning, iar Taproot a introdus semnăturile Schnorr, confidențialitatea bazată pe MAST și designul opcode-urilor Tapscript, compatibil cu versiunile viitoare. Propunerile de acorduri aflate acum în discuție reprezintă următorul capitol potențial. Dacă vreuna dintre ele va fi activată și în ce interval de timp rămâne o chestiune cu adevărat deschisă la jumătatea anului 2026.

Pentru a înțelege Script nu este necesar să fii programator. Este însă necesar să recunoști că conservatorismul Bitcoin, limitările deliberate, ritmul lent de actualizare și lipsa completitudinii Turing nu reprezintă o deficiență. Proprietățile care fac ca Bitcoin Script să fie previzibil sunt aceleași care au menținut stratul de consens curat timp de șaisprezece ani.