Sfântul Graal al rețelei Bitcoin de nivel 2: Introspecție și legăminte

În comparație cu blockchain-urile Turing-complete precum Ethereum, limbajul de scripting al Bitcoin este considerat semnificativ limitat, capabil doar de operațiuni de bază și chiar lipsit de funcții de înmulțire și împărțire. Mai important, propriile date ale blockchain-ului sunt aproape inaccesibile scripturilor, ceea ce duce la limitări severe în ceea ce privește flexibilitatea și programabilitatea. În consecință, oamenii au căutat mult timp modalități de a permite introspecția pentru scripturile Bitcoin.

Introspecție se referă la capacitatea Bitcoin scripturi de a inspecta și constrânge datele tranzacțiilor. Acest lucru permite scripturilor să controleze utilizarea fondurilor pe baza detaliilor specifice ale tranzacției, permițând funcționalități mai complexe. În prezent, majoritatea opcodurilor Bitcoin fie împing pe stivă datele furnizate de utilizator, fie manipulează datele aflate deja pe stivă. Cu toate acestea, opcodurile de introspecție pot introduce în stivă date privind tranzacțiile curente (cum ar fi marcajele temporale, sumele și ID-urile tranzacțiilor), permițând un control mai detaliat asupra cheltuielilor UTXO.

În prezent, există doar trei coduri op principale în scripturile Bitcoin care acceptă introspecția: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY și CHECKSIG. CHECKSIG are mai multe variante, inclusiv CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG și CHECKMULTISIGVERIFY.

Convenții sunt restricții privind modul în care pot fi transferate jetoanele. Utilizatorii pot specifica modul în care UTXO-urile sunt distribuite prin convenții, dintre care multe sunt implementate utilizând opcodes de introspecție. În prezent, Bitcoin Optech clasifică introspecția sub intrările de convenții.

Bitcoin are în prezent două convenții: CSV (CheckSequenceVerify) și CLTV (CheckLockTimeVerify), ambele fiind convenții bazate pe timp și constituind baza multor soluții de scalare, cum ar fi Lightning Network. Acest lucru indică faptul că soluțiile de scalare ale Bitcoin se bazează foarte mult pe introspecție și pe convenții.

Cum să adăugați condiții la transferurile de jetoane

În lumea criptografică, cea mai comună metodă este prin angajamente, adesea implementată cu ajutorul hașurilor. Pentru a dovedi că sunt îndeplinite condițiile de transfer, sunt utilizate mecanisme de semnătură pentru verificare. Prin urmare, convențiile implică numeroase ajustări ale hașurilor și semnăturilor.

Următoarele sunt propuneri de coduri op convenționale discutate pe scară largă:

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify), inclus în BIP-119, este o actualizare Bitcoin foarte dezbătută. CTV permite scripturilor de ieșire să specifice șabloane pentru tranzacțiile de cheltuieli, inclusiv câmpuri precum nVersion, nLockTime, scriptSig hash, număr de intrări, secvențe hash, număr de ieșiri, ieșiri hash și indice de intrare. Aceste restricții ale șabloanelor sunt implementate printr-un angajament hash, iar viitoarele scripturi de cheltuieli vor verifica dacă valorile hash ale câmpurilor specificate în tranzacția de cheltuieli corespund celor din scriptul de intrare. Aceste modele definesc, în esență, ora, metoda și valoarea viitoarelor tranzacții UTXO.

În special, TXID-ul de intrare este exclus din angajamentul hash. Această excludere este necesară deoarece, în tranzacțiile Legacy sau Segwit, TXID depinde de valoarea scriptPubKey atunci când se utilizează tipul implicit de semnătură SIGHASH_ALL. Includerea TXID ar crea o dependență circulară, făcând imposibilă construirea angajamentului hash.

CTV realizează introspecția prin obținerea directă a informațiilor referitoare la tranzacția specificată prin intermediul unui nou cod operațional, prin hashing și prin compararea acestora cu angajamentul de pe stivă. Această metodă consumă mai puțin spațiu pe lanț, dar îi lipsește o anumită flexibilitate.

La baza soluțiilor de al doilea nivel, precum Lightning Network, stau tranzacțiile presemnate. Pre-semnarea înseamnă, de obicei, generarea și semnarea în avans a tranzacțiilor, dar nu și difuzarea lor până când nu sunt îndeplinite anumite condiții. În esență, CTV implementează o funcție de presemnare mai strictă, publicând angajamentul presemnat direct pe lanț, permițând tranzacții numai în conformitate cu modelul predefinit.

CTV a fost propus inițial pentru a atenua congestia Bitcoin și poate fi denumit și control al congestiei. În timpul perioadelor de congestie ridicată, CTV poate angaja mai multe tranzacții viitoare printr-o singură tranzacție, evitând necesitatea de a difuza mai multe tranzacții în timpul congestiei și de a finaliza tranzacțiile efective după ce congestia scade. Acest lucru ar putea ajuta semnificativ în timpul execuțiilor de schimb. În plus, șabloanele pot fi utilizate pentru a implementa seifuri, prevenind atacurile hackerilor, deoarece destinația fondurilor este predeterminată, ceea ce face imposibilă trimiterea de către hackeri a UTXO folosind scriptul CTV la adresele lor.

CTV poate îmbunătăți semnificativ rețelele din stratul al doilea. De exemplu, în rețeaua Lightning, implementarea arborilor Timeout și a fabricilor de canale utilizând CTV permite unui singur UTXO să se extindă într-un arbore CTV, deschizând mai multe canale de stare cu o singură tranzacție și confirmare pe lanț. În plus, CTV sprijină tranzacțiile atomice (ATLC) în protocolul Ark.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 propune un nou indicator de hash al semnăturii pentru tapscript, denumit SIGHASH_ANYPREVOUT, pentru a facilita scrierea unei logici de cheltuieli mai flexibile. APO și CTV sunt similare în multe privințe. Pentru a aborda dependența circulară dintre scriptPubKeys și TXID-uri, soluția APO este de a exclude informațiile de intrare relevante și de a semna doar ieșirea, permițând tranzacțiilor să se lege dinamic de UTXO-uri diferite.

Din punct de vedere logic, operațiunea de verificare OP_CHECKSIG (și opcodele aferente) are trei funcții:

1. Asamblați părți ale tranzacției de cheltuieli.
2. Hash aceste părți.
3. Verifică dacă hash-ul este semnat de cheia dată.

Conținutul specific al semnăturii poate fi ajustat semnificativ, iar câmpurile tranzacției care sunt semnate sunt determinate de indicatorul SIGHASH. În conformitate cu definiția opcodurilor de semnătură BIP 342, indicatoarele SIGHASH includ, printre altele, SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE și SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY controlează intrarea, în timp ce celelalte controlează ieșirea.

SIGHASH_ALL este steagul SIGHASH implicit, semnând toate ieșirile. SIGHASH_NONE nu semnează nicio ieșire, iar SIGHASH_SINGLE semnează numai o ieșire specificată. SIGHASH_ANYONECANPAY poate fi setat împreună cu celelalte trei indicatori și, dacă este setat, semnează numai intrarea specificată; altfel, toate intrările trebuie semnate.

Niciunul dintre aceste indicatori SIGHASH nu poate elimina impactul intrărilor. Chiar și SIGHASH_ANYONECANPAY necesită un angajament față de o intrare.

Prin urmare, BIP 118 introduce SIGHASH_ANYPREVOUT. Semnăturile APO nu trebuie să se angajeze la UTXO-ul de intrare cheltuit (numit PREVOUT), semnând doar ieșirea, oferind o mai mare flexibilitate în controlul Bitcoin. Prin pre-construirea tranzacțiilor și crearea semnăturilor și a cheilor publice corespunzătoare de unică folosință, activele trimise la adresa acelei chei publice trebuie să fie cheltuite prin tranzacția pre-construită, realizând pactul.

Flexibilitatea APO poate fi utilizată și pentru repararea tranzacțiilor. Dacă o tranzacție rămâne blocată pe lanț din cauza taxelor mici, se poate crea cu ușurință o altă tranzacție pentru a crește taxa fără a fi nevoie de noi semnături. În plus, pentru portofelele cu semnături multiple, semnăturile care nu depind de datele de intrare cheltuite simplifică operațiunile.

Prin eliminarea dependenței circulare dintre scriptPubKeys și TXID-urile de intrare, APO poate realiza introspecția prin adăugarea datelor de ieșire în martor, deși acest lucru necesită spațiu suplimentar pentru datele martorului.

Pentru protocoalele în afara lanțului, cum ar fi Lightning Network și seifurile, APO reduce nevoia de stocare a stărilor intermediare, reducând semnificativ cerințele și complexitatea stocării. Cel mai direct caz de utilizare a APO este Eltoo, care simplifică fabricile de canale, construiește turnuri de supraveghere ușoare și necostisitoare și permite ieșiri unilaterale fără a lăsa stări eronate, îmbunătățind performanța rețelei Lightning. APO poate simula funcționalitatea CTV, deși necesită stocarea personală a semnăturilor și a tranzacțiilor pre-semnate, ceea ce îl face mai costisitor și mai puțin eficient decât CTV.

Principala critică a APO este necesitatea unei noi versiuni a cheii, ceea ce o face incompatibilă cu sistemele existente. În plus, noul tip de semnătură hash ar putea introduce riscuri potențiale de dublă cheltuială. După discuții ample cu comunitatea, APO necesită acum o semnătură obișnuită în plus față de cea originală, atenuând problemele de securitate și câștigându-și numărul BIP-118.

OP_VAULT BIP-345

BIP-345 propune două noi opcoduri, OP_VAULT și OP_VAULT_RECOVER, pentru a lucra cu CTV și pentru a implementa o convenție dedicată care impune o perioadă de întârziere pentru cheltuirea jetoanelor specificate, în timpul căreia cheltuirea poate fi „revocată” prin intermediul unei căi de recuperare.

Utilizatorii pot crea un seif prin configurarea unei adrese Taproot specifice, incluzând cel puțin două scripturi în MAST: un script OP_VAULT pentru a facilita procesul de retragere așteptat și un script OP_VAULT_RECOVER pentru a asigura recuperarea monedelor înainte de finalizarea retragerii.

Cum realizează OP_VAULT retrageri întreruptibile blocate în timp?

În termeni simpli, codul operațional OP_VAULT înlocuiește scriptul OP_VAULT utilizat cu un script specificat, actualizând un singur nod de frunze din MAST și păstrând restul neschimbat. Acest lucru este similar cu TLUV, dar fără a suporta actualizarea cheilor interne.

Introducerea unui șablon în timpul actualizărilor scriptului poate restricționa efectele de plată. Parametrul de blocare a timpului este specificat de OP_VAULT, în timp ce șablonul adus de opcode-ul CTV restricționează setul de ieșiri cheltuite prin calea de script respectivă.

BIP-345 este conceput pentru seifuri, permițând utilizatorilor să aibă o cale de recuperare extrem de sigură (portofel de hârtie, semnătură multiplă distribuită), configurând în același timp o întârziere a cheltuielilor pentru plățile de rutină. Dispozitivul utilizatorului monitorizează continuu cheltuielile seifului, permițând recuperarea în cazul unui transfer neautorizat.

Implementarea seifurilor cu BIP-345 necesită luarea în considerare a problemelor legate de taxe, în special pentru tranzacțiile de recuperare. Printre soluțiile posibile se numără CPFP (Child Pays for Parent – Copilul plătește pentru părinte), ancorele temporare și noi indicatori hash de semnătură precum SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

Schema TLUV este construită în jurul Taproot și urmărește să rezolve problema ieșirii eficiente din UTXO-urile partajate. Principiul director este că, atunci când o ieșire Taproot este cheltuită, putem utiliza structura internă a adresei Taproot și transformările criptografice pentru a actualiza parțial cheia internă și MAST în conformitate cu etapele de actualizare descrise de scriptul TLUV, realizând astfel funcționalitatea contractului.

Ideea sistemului TLUV este de a crea o nouă adresă Taproot pe baza datelor actuale privind cheltuielile prin intermediul unui nou cod op TAPLEAF_UPDATE_VERIFY, care poate efectua una sau mai multe dintre următoarele operațiuni:

• Actualizarea cheii publice interne
• Tăiați calea Merkle
• Eliminarea nodului frunză aflat în execuție
• Adăugați un nou nod frunză la sfârșitul traseului Merkle

În mod specific, TLUV are trei intrări:

1. O specificație privind modul de actualizare a cheii publice interne
2. Un nou nod frunză pentru calea Merkle
3. O specificație privind eliminarea nodului frunză curent și/sau a numărului de noduri frunză ale căii Merkle care trebuie eliminate

Opcode-ul TLUV calculează scriptPubKey-ul actualizat și verifică dacă ieșirea corespunzătoare intrării curente este utilizată pentru scriptPubKey-ul respectiv.

Sursele de inspirație pentru TLUV sunt coin pools. În prezent, pool-urile comune pot fi create folosind tranzacții presemnate, dar dacă doriți să obțineți ieșiri fără permisiune, trebuie să creați un număr exponențial de semnături. TLUV permite ieșiri fără permisiune fără nicio tranzacție presemnată. De exemplu, un grup de parteneri utilizează Taproot pentru a construi un UTXO comun, punându-și în comun fondurile. Aceștia pot transfera fonduri intern folosind cheia Taproot sau pot semna împreună pentru a efectua plăți externe. Persoanele pot ieși din fondul comun în orice moment, eliminându-și calea de plată, în timp ce alții pot continua să efectueze plăți prin calea inițială, fără a expune informații suplimentare despre membrii rămași. Această metodă este mai eficientă și mai privată în comparație cu tranzacțiile care nu sunt puse în comun.

Opcode-ul TLUV realizează restricții parțiale de cheltuieli prin actualizarea MAST original. Cu toate acestea, nu realizează introspecția sumelor de ieșire. Prin urmare, este necesar un nou opcode IN_OUT_AMOUNT, care introduce două date pe stivă: valoarea UTXO a acestei intrări și valoarea de ieșire corespunzătoare. Persoana care utilizează TLUV este apoi așteptată să utilizeze operatori matematici pentru a verifica dacă fondurile sunt păstrate în mod corespunzător în scriptPubKey actualizat.

Introspecția sumelor de ieșire adaugă o altă complexitate, deoarece sumele Bitcoin sunt reprezentate în satoshis și necesită până la 51 de biți, însă scripturile permit numai operațiuni matematice pe 32 de biți. Acest lucru necesită actualizarea operatorilor din script prin redefinirea comportamentului opcode sau utilizarea SIGHASH_GROUP pentru a înlocui IN_OUT_AMOUNT.

TLUV este de așteptat să ofere soluții pentru bazinele de monede descentralizate de nivel 2, deși fiabilitatea în ceea ce privește modificarea cheilor publice Taproot necesită confirmare suplimentară.

MATT

MATT (Merkleize All The Things) își propune să atingă trei obiective: Merkleizing state, Merkleizing scripts și Merkleizing execution, realizând astfel contracte inteligente generale.

• Statul Merkleizing: Construiți un Trie Merkle în care fiecare nod frunză este un hash al stării, iar rădăcina Merkle reprezintă întreaga stare a contractului.
• Merkleizing Scripturi: Un MAST construit din Tapscript în care fiecare nod frunză este o posibilă cale de tranziție de stare.
• Execuția Merkleizing: Realizat prin angajamente criptografice și mecanisme de contestare a fraudelor. Pentru orice funcție de calcul, participanții pot calcula în afara lanțului și pot publica angajamente, f(x)=y. Dacă alți participanți găsesc rezultatul f(x)=z, îl pot contesta, iar arbitrajul se realizează printr-o căutare binară, similar cu principiul Optimistic Rollup.

Pentru a realiza MATT, scripturile de programare Bitcoin trebuie să aibă următoarele funcționalități:

1. Aplicați un anumit script pe o ieșire (și cantitățile acestora)
2. Atașați date la o ieșire
3. Citiți datele de la intrarea curentă (sau de la alte intrări)

Al doilea punct este esențial, deoarece datele dinamice permit calcularea stării prin intermediul datelor de intrare furnizate de spender, simulând o mașină de stare și hotărând următoarea stare și datele atașate. MATT propune opcode-ul OP_CHECKCONTRACTVERIFY (OP_CCV), o combinație a opcode-urilor OP_CHECKOUTPUTCONTRACTVERIFY și OP_CHECKINPUTCONTRACTVERIFY propuse anterior, cu un parametru flags suplimentar pentru a specifica ținta operațiunii.

Controlul cantităților de ieșire: Cea mai directă modalitate este prin introspecție directă. Cu toate acestea, sumele de ieșire sunt numere pe 64 de biți care necesită operațiuni pe 64 de biți, ceea ce adaugă complexitate implementării scriptului Bitcoin. CCV adoptă o verificare întârziată similară cu OP_VAULT, însumând sumele de intrare pentru toate intrările la aceeași ieșire cu CCV ca limită inferioară a acelei sume de ieșire. Verificarea este amânată până la procesul de tranzacționare și nu în timpul evaluării scriptului de intrare.

Având în vedere generalitatea dovezilor de fraudă, unele variante ale contractelor MATT ar trebui să realizeze toate tipurile de contracte inteligente sau construcții de nivel 2, deși cerințele suplimentare (cum ar fi blocarea capitalului și întârzierile perioadei de provocare) necesită o evaluare precisă. Sunt necesare cercetări suplimentare pentru a evalua care aplicații sunt tranzacții acceptabile. De exemplu, utilizarea angajamentelor criptografice și a mecanismelor de provocare a fraudelor pentru a simula funcțiile OP_ZK_VERIFY, realizând Rollups fără încredere pe Bitcoin.

În practică, lucrurile se întâmplă deja. Johan Torås Halseth a implementat elftrace folosind opcode-ul OP_CHECKCONTRACTVERIFY din propunerea de soft fork MATT, permițând tuturor programelor acceptate de compilarea RISC-V să fie verificate pe lanțul Bitcoin, permițând punți de verificare Bitcoin native pentru protocoalele contractuale.

CSFS (OP_CHECKSIGFROMSTACK)

Din introducerea codului op APO, știm că OP_CHECKSIG (și operațiunile conexe) este responsabil pentru asamblarea tranzacțiilor, hashing și verificarea semnăturii. Cu toate acestea, mesajul pe care îl verifică este derivat din serializarea tranzacției utilizând acest opcode, nepermițând specificarea altor mesaje. În termeni simpli, OP_CHECKSIG (și operațiunile conexe) servește la verificarea faptului că UTXO ca intrare în tranzacție este autorizat să fie cheltuit de titularul semnăturii, protejând astfel securitatea Bitcoin.

CSFS, după cum sugerează și numele său, verifică semnăturile din stivă. Opcode-ul CSFS preia trei parametri din stivă: o semnătură, un mesaj și o cheie publică și verifică validitatea semnăturii. Aceasta înseamnă că orice mesaj poate fi transmis stivei prin intermediul datelor martorilor și verificat de CSFS, permițând unele inovații pe Bitcoin.

Flexibilitatea CSFS îi permite să pună în aplicare diverse mecanisme, cum ar fi semnăturile de plată, delegarea autorității, contractele oracol și obligațiunile de protecție împotriva cheltuielilor duble și, mai important, introspecția tranzacțiilor. Principiul introspecției tranzacțiilor utilizând CSFS este foarte simplu. Dacă conținutul tranzacției utilizate de OP_CHECKSIG este introdus pe stivă prin intermediul martorului și dacă aceeași cheie publică și aceeași semnătură sunt utilizate pentru a verifica atât cu CSFS, cât și cu OP_CHECKSIG, dacă ambele trec, atunci conținutul oricărui mesaj transmis către CSFS este același cu cel al tranzacției de cheltuieli serializate (și alte date) utilizate implicit de OP_CHECKSIG. Obținem apoi date de tranzacție verificate pe stivă, care pot fi utilizate pentru a aplica restricții tranzacției de cheltuieli cu alte opcode.

CSFS apare adesea cu OP_CAT deoarece OP_CAT poate concatena diferite câmpuri ale tranzacției pentru a finaliza serializarea, permițând o selecție mai precisă a câmpurilor tranzacției pentru introspecție. Fără OP_CAT, scriptul nu poate recompune hash-uri din date care pot fi verificate individual, astfel încât poate verifica doar dacă un hash corespunde unei anumite valori, ceea ce înseamnă că monedele pot fi cheltuite doar printr-o singură tranzacție specifică.

CSFS poate realiza opcoduri precum CLTV, CSV, CTV, APO și este un opcod general de introspecție, ajutând astfel și soluțiile de scalare de nivel 2 pentru Bitcoin. Dezavantajul său este că necesită adăugarea în stivă a unei copii complete a tranzacției semnate, ceea ce poate crește semnificativ dimensiunea tranzacțiilor care doresc să utilizeze CSFS pentru introspecție. În schimb, opcodurile de introspecție cu scop unic, precum CLTV și CSV, au cel mai mic cost, dar adăugarea fiecărui nou opcod special de introspecție necesită modificări ale consensului.

TXHASH (OP_TXHASH)

OP_TXHASH este un cod op de introspecție foarte simplu care permite operatorului să selecteze hash-ul unui câmp și să îl împingă pe stivă. Mai exact, OP_TXHASH scoate un indicator txhash din stivă, calculează un txhash (marcat) pe baza indicatorului și introduce hash-ul rezultat pe stivă.

Datorită similitudinii dintre TXHASH și CTV, au existat discuții ample în comunitate cu privire la cele două.

TXHASH poate fi văzut ca o îmbunătățire generală a CTV, oferind un model de tranzacție mai avansat care permite utilizatorilor să specifice părți ale tranzacției de cheltuieli, rezolvând multe probleme legate de taxele de tranzacție. Spre deosebire de alte opcode de contract, TXHASH nu necesită furnizarea unei copii a datelor necesare în martor, reducând și mai mult nevoile de stocare. Spre deosebire de CTV, TXHASH nu este compatibil cu NOP și poate fi implementat numai în tapscript. Combinația de TXHASH și CSFS poate fi considerată o alternativă la CTV și APO.

În ceea ce privește construirea contractelor, TXHASH este mai ușor de realizat „contracte aditive” prin împingerea tuturor părților din datele tranzacției pe care doriți să le fixați în stivă, hashing-ul lor împreună și verificarea dacă rezultatul corespunde unei valori fixe. CTV este mai ușor de realizat „contracte substractive” prin introducerea în stivă a tuturor părților din datele tranzacției pe care doriți să le păstrați libere. Apoi, folosind rolling OP_SHA256, pornind de la o stare intermediară fixă, acea stare intermediară comite prefixul datelor hash ale tranzacției. Părțile libere sunt hașurate în starea intermediară respectivă.

Se așteaptă ca câmpul TxFieldSelector definit în specificația TXHASH să se extindă la alte coduri op, cum ar fi OP_TX.

BIP referitor la TXHASH este în prezent în stare de proiect pe Github și nu i s-a atribuit încă un număr.

OP_CAT

OP_CAT este un opcode oarecum misterios care a fost depreciat de Satoshi Nakamoto din cauza problemelor de securitate. Cu toate acestea, a stârnit recent discuții ample în rândul dezvoltatorilor Bitcoin core, devenind chiar un meme în comunitatea online. În cele din urmă, OP_CAT a fost aprobat ca BIP-347, mulți numind-o cea mai probabilă propunere BIP care va trece în viitorul apropiat.

În realitate, comportamentul OP_CAT este foarte simplu: concatenează două elemente de pe stivă într-unul singur. Dar cum permite acest lucru funcționalitatea contractului?

Funcția de concatenare a două elemente corespunde unei puternice structuri de date criptografice cunoscută sub numele de Merkle Trie. Construcția unui Merkle Trie necesită doar operații de concatenare și hashing, ambele fiind disponibile în scripturile Bitcoin. Prin urmare, cu OP_CAT, putem verifica teoretic Merkle Proofs în scripturi Bitcoin, care este cea mai comună metodă de verificare ușoară în blockchains.

După cum s-a menționat anterior, CSFS poate utiliza OP_CAT pentru a realiza o schemă generală de contracte. De fapt, chiar și fără CSFS, structura semnăturilor Schnorr permite OP_CAT să realizeze introspecția tranzacțiilor.

Într-o semnătură Schnorr, mesajul care urmează să fie semnat este compus din următoarele câmpuri:

• Versiune
• Timp de blocare
• Număr de intrări
• Număr de ieșiri
• Listă de intrări (fiecare incluzând hash-ul tranzacției anterioare, indexul, lungimea scriptului, scriptul, secvența)
• Lista de ieșiri (fiecare incluzând valoarea, lungimea scriptului, scriptul)

Aceste câmpuri conțin elementele principale ale unei tranzacții. Plasându-le în scriptPubKey sau în martor și utilizând OP_CAT și OP_SHA256, putem construi o semnătură Schnorr și o putem verifica cu OP_CHECKSIG. Dacă verificarea trece, stiva reține datele tranzacției verificate, permițând introspecția tranzacției. Acest lucru ne permite să extragem și să „inspectăm” diverse părți ale tranzacției, cum ar fi intrările, ieșirile, adresele de destinație sau sumele Bitcoin implicate.

Pentru principii criptografice mai detaliate, consultați articolul lui Andrew Poelstra „CAT and Schnorr Tricks”.

Pe scurt, flexibilitatea OP_CAT îl face capabil să imite aproape orice opcod contractual, iar multe opcode contractuale depind de funcționalitatea sa. Acest lucru avansează semnificativ poziția sa pe lista de fuzionare. Teoretic, doar cu OP_CAT și opcodurile Bitcoin existente, am putea construi un BTC ZK Rollup cu încredere minimizată. Starknet, Chakra și alți parteneri din ecosistem lucrează activ pentru a face acest lucru posibil.

Concluzie

Pe măsură ce explorăm diverse strategii de extindere a Bitcoin și de îmbunătățire a programabilității sale, devine evident că calea de urmat implică o combinație de îmbunătățiri native, calcul în afara lanțului și funcționalități complexe de script.

Fără un strat de bază flexibil, este imposibil să se construiască un al doilea strat mai flexibil.

Scalabilitatea calculelor în afara lanțului este viitorul, dar programabilitatea Bitcoin trebuie să se impună pentru a susține mai bine scalarea și a deveni o monedă mondială adevărată.

Cu toate acestea, calculul Bitcoin diferă fundamental de calculul Ethereum. Bitcoin acceptă doar „verificarea” ca formă de calcul, în timp ce Ethereum este fundamental computațional, verificarea fiind un produs secundar. Această diferență este evidentă în faptul că Ethereum percepe taxe de gaz pentru tranzacțiile eșuate, în timp ce Bitcoin nu o face.

Contractele realizează o formă de contracte inteligente bazate mai degrabă pe verificare decât pe calcul. În ceea ce privește contractele, în afară de câțiva fundamentaliști Satoshi stricți, majoritatea oamenilor cred că contractele sunt o alegere bună pentru îmbunătățirea Bitcoin. Cu toate acestea, comunitatea dezbate în mod constant ce schemă să utilizeze pentru a implementa contractele.

APO, OP_VAULT și TLUV sunt orientate către aplicații directe. Alegerea acestora poate implementa aplicații specifice mai ieftin și mai eficient. Pasionații de Lightning Network preferă APO deoarece realizează simetria LN; dacă doriți să creați un seif, cel mai bine este să utilizați OP_VAULT; pentru a construi un CoinPool, TLUV este mai privat și mai eficient. OP_CAT și TXHASH sunt mai generale, cu mai puține vulnerabilități de securitate, și pot realiza mai multe cazuri de utilizare prin combinații cu alte coduri op, deși potențial cu prețul complexității scriptului. CTV și CSFS au ajustat abordarea procesării blockchain: CTV implementează ieșiri întârziate, iar CSFS implementează semnături întârziate. MATT este relativ unic, utilizând execuția optimistă și dovezile de fraudă și se bazează pe structura Merkle Trie pentru a realiza contracte inteligente generale, deși necesită în continuare noi opcodes pentru a oferi capacități de introspecție.

Vedem că comunitatea Bitcoin discută deja intens posibilitatea introducerii contractelor printr-o bifurcație soft. Starknet și-a anunțat oficial intrarea în ecosistemul Bitcoin, plănuind să implementeze decontarea pe rețeaua Bitcoin în termen de șase luni de la fuziunea OP_CAT. Chakra va continua să monitorizeze ultimele evoluții din ecosistemul Bitcoin, să promoveze fuziunea soft fork OP_CAT și să utilizeze programabilitatea adusă de introspecție și contracte pentru a construi un strat de decontare Bitcoin mai sigur și mai eficient.