Sveti gral omrežja 2. plasti Bitcoina: Vsiljivost in zaveze

V primerjavi s Turingovimi popolnimi verigami blokov, kot je Ethereum, je skriptni jezik Bitcoina precej omejen, saj omogoča le osnovne operacije, nima pa niti funkcij za množenje in deljenje. Še pomembneje je, da so lastni podatki verige blokov skriptam skoraj nedostopni, kar vodi do resnih omejitev glede prilagodljivosti in programabilnosti. Zato ljudje že dolgo iščejo načine, kako skriptam Bitcoina omogočiti introspekcijo.

Introspekcija se nanaša na sposobnost Bitcoin skripte za pregledovanje in omejevanje podatkov o transakcijah. To skriptam omogoča nadzor uporabe sredstev na podlagi določenih podrobnosti o transakciji, kar omogoča bolj zapletene funkcionalnosti. Trenutno večina opkod Bitcoin bodisi potisne podatke, ki jih zagotovi uporabnik, na kup ali pa manipulira s podatki, ki so že na kupu. Introspekcijske opkodne kode pa lahko na sklad potisnejo trenutne podatke o transakcijah (kot so časovni žigi, zneski in ID-ji transakcij), kar omogoča bolj podroben nadzor nad porabo UTXO.

V skriptih Bitcoin so trenutno le tri glavne opkode, ki podpirajo introspekcijo: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY in CHECKSIG. CHECKSIG ima več različic, med drugim CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG in CHECKMULTISIGVERIFY.

Zaveze obstajajo omejitve glede načina prenosa žetonov. Uporabniki lahko določijo, kako se žetoni UTXO razdelijo, s pomočjo dogovorov, od katerih se mnogi izvajajo z uporabo introspekcijskih opkod. Trenutno Bitcoin Optech kategorizira introspekcijo v okviru vnosov covenantov.

Bitcoin ima trenutno dve pogodbi: CSV (CheckSequenceVerify) in CLTV (CheckLockTimeVerify). To kaže, da so rešitve za skaliranje Bitcoina močno odvisne od introspekcije in dogovorov.

Kako dodati pogoje za prenose žetonov

V svetu kriptovalut je najpogostejša metoda obveznosti, ki se pogosto izvaja z uporabo hashev. Za dokazovanje, da so pogoji prenosa izpolnjeni, se za preverjanje uporabljajo mehanizmi podpisovanja. Zato sporazumi vključujejo številne prilagoditve hešev in podpisov.

O naslednjih predlogih za opcijsko kodo zaveze se je veliko razpravljalo:

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify), vključen v BIP-119, je nadgradnja Bitcoina, o kateri se zelo razpravlja. CTV omogoča izhodnim skriptam, da določijo predloge za transakcije porabe, vključno s polji, kot so nVersion, nLockTime, skriptSig hash, vhodno število, zaporedje hash, izhodno število, izhodni hash in vhodni indeks. Te omejitve predlog se izvajajo z zavezanostjo hash, prihodnje skripte porabe pa bodo preverile, ali se vrednosti hash določenih polj v transakciji porabe ujemajo z vrednostmi v vhodni skripti. Te predloge v bistvu določajo čas, način in znesek prihodnjih transakcij UTXO.

Vhodni TXID je izključen iz zavezanosti k hashu. Ta izključitev je potrebna, ker je v transakcijah Legacy ali Segwit TXID odvisen od vrednosti scriptPubKey pri uporabi privzetega tipa podpisa SIGHASH_ALL. Vključitev TXID bi ustvarila krožno odvisnost, kar bi onemogočilo sestavo zavezanosti k stiskanju.

CTV doseže introspekcijo z neposrednim pridobivanjem določenih informacij o transakciji z novo opkodo, njihovim hashanjem in primerjavo z obveznostjo na kupu. Ta metoda porabi manj prostora na verigi, vendar ji manjka nekaj prilagodljivosti.

Temelj rešitev druge plasti, kot je omrežje Lightning Network, so vnaprej podpisane transakcije. Predpodpisovanje običajno pomeni vnaprejšnje generiranje in podpisovanje transakcij, ki pa se ne oddajajo, dokler niso izpolnjeni določeni pogoji. CTV v bistvu izvaja strožjo funkcijo predhodnega podpisovanja, tako da neposredno v verigi objavlja vnaprej podpisano obveznost in omogoča transakcije samo v skladu z vnaprej določeno predlogo.

CTV je bil prvotno predlagan za ublažitev zastojev v Bitcoinu in ga lahko imenujemo tudi nadzor zastojev. V obdobjih velike prezasedenosti lahko CTV z eno transakcijo zaveže več prihodnjih transakcij, s čimer se izogne potrebi po oddajanju več transakcij med prezasedenostjo in dokončanju dejanskih transakcij, ko se prezasedenost zmanjša. To bi lahko bistveno pomagalo med izvajanjem izmenjav. Poleg tega je mogoče predloge uporabiti za izvajanje trezorjev, kar preprečuje hekerske napade, saj je cilj sredstev vnaprej določen, kar hekerjem onemogoča pošiljanje UTXO z uporabo scenarija CTV na njihove naslove.

CTV lahko bistveno izboljša omrežja druge plasti. Na primer, v omrežju Lightning Network implementacija dreves časovnega zamika in tovarn kanalov z uporabo CTV omogoča, da se en UTXO razširi v drevo CTV in odpre več državnih kanalov z le eno transakcijo in potrditvijo na verigi. Poleg tega CTV podpira atomske transakcije (ATLC) v protokolu Ark.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 predlaga novo zastavico za stiskanje podpisa za tapscript, imenovano SIGHASH_ANYPREVOUT, ki olajša pisanje bolj prilagodljive logike porabe. APO in CTV sta si v marsičem podobna. Za reševanje krožne odvisnosti med scriptPubKeys in TXID je rešitev APO izključitev ustreznih vhodnih informacij in podpisovanje le izhodnih, kar omogoča transakcijam dinamično vezavo na različne UTXO.

Logično gledano ima operacija preverjanja OP_CHECKSIG (in z njo povezane opkode) tri funkcije:

1. Sestavite dele transakcije porabe.
2. Hash ti deli.
3. Preveri, ali je hash podpisan z danim ključem.

Posebna vsebina podpisa se lahko bistveno prilagodi, katera polja transakcije so podpisana, pa je določeno z zastavico SIGHASH. V skladu z opredelitvijo opkod podpisa BIP 342 oznake SIGHASH med drugim vključujejo SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE in SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY nadzoruje vhod, medtem ko drugi nadzorujejo izhod.

SIGHASH_ALL je privzeta zastavica SIGHASH, ki podpisuje vse izpise. SIGHASH_NONE ne podpisuje nobenih izhodov, SIGHASH_SINGLE pa podpisuje samo določen izhod. SIGHASH_ANYONECANPAY lahko nastavite skupaj z drugimi tremi zastavicami, in če je nastavljena, podpiše samo določen vhod; sicer je treba podpisati vse vhode.

Nobena od teh zastavic SIGHASH ne more odpraviti vpliva vnosov. Tudi SIGHASH_ANYONECANPAY zahteva zavezanost enemu vnosu.

Zato protokol BIP 118 uvaja SIGHASH_ANYPREVOUT. Podpisom APO ni treba potrditi porabljenega vhodnega UTXO (imenovanega PREVOUT), temveč le izhodni podpis, kar zagotavlja večjo prilagodljivost pri nadzoru bitcoinov. S predkonstruiranjem transakcij in ustvarjanjem ustreznih podpisov in javnih ključev za enkratno uporabo je treba sredstva, poslana na ta naslov javnega ključa, porabiti prek predkonstruirane transakcije, s čimer se doseže zaveza.

Prilagodljivost sistema APO se lahko uporablja tudi za popravilo transakcij. Če transakcija zaradi nizkih pristojbin obtiči v verigi, je mogoče preprosto ustvariti drugo transakcijo, s katero se pristojbina poveča, ne da bi bili potrebni novi podpisi. Poleg tega pri denarnicah z več podpisi podpisi, ki niso odvisni od porabljenega vnosa, poenostavijo operacije.

Z odpravo krožne odvisnosti med scriptPubKeys in vhodnimi TXID lahko APO doseže introspekcijo z dodajanjem izhodnih podatkov v pričo, čeprav to še vedno zahteva dodaten prostor za podatke priče.

Pri protokolih zunaj verige, kot so omrežje Lightning in trezorji, APO zmanjšuje potrebo po shranjevanju vmesnih stanj, kar znatno zmanjšuje zahteve po shranjevanju in zapletenost. Najbolj neposreden primer uporabe APO je Eltoo, ki poenostavlja tovarne kanalov, gradi lahke in poceni stražnice ter omogoča enostranske izhode brez zapuščanja napačnih stanj, kar povečuje zmogljivost omrežja Lightning Network. APO lahko simulira funkcionalnost CTV, čeprav zahteva osebno shranjevanje podpisov in vnaprej podpisanih transakcij, zaradi česar je dražji in manj učinkovit kot CTV.

Glavni očitek APO je potreba po novi različici ključa, zaradi česar je nezdružljiv z obstoječimi sistemi. Poleg tega bi lahko nova vrsta podpisnega hasha prinesla potencialna tveganja dvojne porabe. Po obsežnih razpravah v skupnosti APO zdaj poleg originalnega podpisa zahteva tudi navaden podpis, s čimer je ublažil varnostne pomisleke in si prislužil številko BIP-118.

OP_VAULT BIP-345

BIP-345 predlaga dve novi opkodi, OP_VAULT in OP_VAULT_RECOVER, ki delujeta s CTV in izvajata namensko zavezo, ki uveljavlja obdobje zamude pri porabi določenih žetonov, med katerim je porabo mogoče “preklicati” prek poti za obnovitev.

Uporabniki lahko ustvarijo trezor tako, da nastavijo določen naslov Taproot in v MAST vključijo vsaj dve skripti: skripto OP_VAULT, ki olajša pričakovani postopek izplačila, in skripto OP_VAULT_RECOVER, ki zagotovi povrnitev kovancev pred dokončanjem izplačila.

Kako OP_VAULT doseže prekinljivo časovno zaklenjeno izplačilo?

Preprosto povedano, opkoda OP_VAULT nadomesti porabljeno skripto OP_VAULT z določeno skripto, pri čemer posodobi eno vozlišče v MAST, ostalo pa ostane nespremenjeno. To je podobno kot TLUV, vendar brez podpore za posodobitve notranjih ključev.

Uvedba predloge med posodobitvami skript lahko omeji učinke plačila. Parameter časovne blokade je določen z OP_VAULT, medtem ko predloga, ki jo prinese opcijska koda CTV, omeji nabor izhodov, porabljenih prek te skriptne poti.

BIP-345 je zasnovan za trezorje, ki uporabnikom omogočajo zelo varno pot izterjave (papirnata denarnica, porazdeljeni večpodpis), hkrati pa konfigurirajo zamik porabe za rutinska plačila. Uporabnikova naprava neprekinjeno spremlja porabo v trezorju in omogoča izterjavo, če pride do nepooblaščenega prenosa.

Pri izvajanju trezorjev z BIP-345 je treba razmisliti o vprašanjih pristojbin, zlasti pri transakcijah izterjave. Možne rešitve vključujejo CPFP (Child Pays for Parent), začasna sidra in nove oznake za stiskanje podpisov, kot je SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

Shema TLUV temelji na sistemu Taproot in je namenjena reševanju problema učinkovitega izhoda iz skupnih UTXO. Glavno načelo je, da lahko ob porabi izhoda Taproot uporabimo notranjo strukturo naslova Taproot in kriptografske transformacije za delno posodobitev notranjega ključa in MAST v skladu s koraki posodobitve, opisanimi v scenariju TLUV, s čimer dosežemo funkcionalnost pogodbe.

Ideja sheme TLUV je, da se na podlagi trenutnega vnosa porabe ustvari nov naslov Taproot z novo opkodo TAPLEAF_UPDATE_VERIFY, ki lahko izvede eno ali več naslednjih operacij:

• Posodobitev notranjega javnega ključa
• Obrezovanje poti Merkle
• Odstranitev trenutno izvajanega listnega vozlišča
• dodaj novo listno vozlišče na konec poti Merkle

TLUV ima tri vhodne podatke:

1. Specifikacija o tem, kako posodobiti notranji javni ključ.
2. Novo listno vozlišče za pot Merkle
3. Navedba, ali naj se odstrani trenutno listno vozlišče in/ali koliko listnih vozlišč Merklove poti naj se odstrani.

Operacijska koda TLUV izračuna posodobljeni scriptPubKey in preveri, ali je izhod, ki ustreza trenutnemu vhodu, porabljen za ta scriptPubKey.

Navdih za TLUV so bili skladi za kovance. Danes je skupne poole mogoče ustvariti s predhodno podpisanimi transakcijami, če pa želite doseči izhode brez dovoljenja, morate ustvariti eksponentno naraščajoče število podpisov. TLUV omogoča izhode brez dovoljenja brez vnaprej podpisanih transakcij. Na primer, skupina partnerjev uporablja Taproot za oblikovanje skupnega UTXO, pri čemer združuje svoja sredstva. Sredstva lahko premikajo znotraj podjetja z uporabo ključa Taproot ali pa jih skupaj podpišejo za izvedbo zunanjih plačil. Posamezniki lahko kadar koli izstopijo iz skupnega sklada in s tem odstranijo svojo plačilno pot, medtem ko lahko drugi še naprej izvajajo plačila po prvotni poti, ne da bi izpostavili dodatne informacije o preostalih članih. Ta metoda je učinkovitejša in zasebnejša v primerjavi s transakcijami, ki niso združene v skupek.

Z opcijsko kodo TLUV se delne omejitve porabe dosežejo s posodobitvijo izvirnega MAST. Vendar pa ne omogoča introspekcije izhodnih zneskov. Zato je potrebna nova opkoda IN_OUT_AMOUNT, ki na sklad potisne dva podatka: znesek UTXO tega vhoda in ustrezni izhodni znesek. Od osebe, ki uporablja TLUV, se nato pričakuje, da z matematičnimi operatorji preveri, ali so sredstva ustrezno ohranjena v posodobljenem skriptoKljuču.

Introspekcija izhodnih zneskov je še dodatno zapletena, saj so zneski bitcoinov predstavljeni v satoših in zahtevajo do 51 bitov, skripte pa omogočajo le 32-bitne matematične operacije. To zahteva nadgradnjo operatorjev v skripti s ponovno opredelitvijo obnašanja opkode ali uporabo SIGHASH_GROUP, ki nadomesti IN_OUT_AMOUNT.

TLUV naj bi zagotovil rešitve za decentralizirane zbiralnike kovancev 2. plasti, čeprav je treba zanesljivost v smislu prilagajanja javnih ključev Taproot še dodatno potrditi.

MATT

MATT (Merkleize All The Things) želi doseči tri cilje: Merkleizirati stanje, merkleizirati skripte in merkleizirati izvajanje ter tako doseči splošne pametne pogodbe.

• Država Merkleizing: Sestavite triado Merkle, kjer je vsako listno vozlišče hash stanja, koren Merkle pa predstavlja celotno stanje pogodbe.
• Skripte za merkleiziranje: MAST, zgrajen iz Tapscripta, kjer je vsako listno vozlišče možna pot prehoda stanja.
• Merkleiziranje izvedbe: doseženo s kriptografskimi zavezami in mehanizmi za izpodbijanje goljufij. Za katero koli računsko funkcijo lahko udeleženci izračunajo zunaj verige in objavijo zaveze, f(x)=y. Če drugi udeleženci najdejo rezultat f(x)=z, ga lahko izpodbijajo, arbitraža pa se izvede z binarnim iskanjem, podobno kot pri načelu optimističnega valjanja.

Da bi dosegli MATT, morajo imeti programske skripte Bitcoin naslednje funkcionalnosti:

1. uveljavljanje določenega scenarija na izhodu (in njihovih količin)
2. Priključitev podatkov na izhod
3. Preberite podatke iz trenutnega vhoda (ali drugih vhodov)

Druga točka je ključnega pomena, saj dinamični podatki omogočajo izračun stanja z vhodnimi podatki, ki jih zagotovi porabnik, simulacijo stroja stanja ter odločanje o naslednjem stanju in priloženih podatkih. MATT predlaga opcijsko kodo OP_CHECKCONTRACTVERIFY (OP_CCV), ki je kombinacija prej predlaganih opcijskih kod OP_CHECKOUTPUTCONTRACTVERIFY in OP_CHECKINPUTCONTRACTVERIFY, z dodatnim parametrom flags za določitev cilja operacije.

Nadzor izhodnih količin: Najbolj neposreden način je neposredna introspekcija. Vendar so izhodni zneski 64-bitna števila, ki zahtevajo 64-bitne operacije, kar poveča zapletenost izvajanja skripte Bitcoin. CCV sprejme zapoznelo preverjanje, podobno kot OP_VAULT, ki sešteje vhodne zneske za vse vhode v isti izhod, pri čemer je CCV spodnja meja tega izhodnega zneska. Preverjanje je odloženo na proces transakcije namesto med ocenjevanjem vhodne skripte.

Glede na splošnost dokazov goljufij bi morale nekatere različice pogodb MATT doseči vse vrste pametnih pogodb ali konstrukcij plasti 2, čeprav je treba natančno oceniti dodatne zahteve (kot so zaklepanje kapitala in zamude v obdobju preizkušanja). Potrebne so nadaljnje raziskave za oceno, katere aplikacije so sprejemljive transakcije. Na primer, uporaba kriptografskih zavez in mehanizmov za izzivanje goljufij za simulacijo funkcij OP_ZK_VERIFY, s čimer se doseže nezaupljiv Rollup na Bitcoinu.

V praksi se to že dogaja. Johan Torås Halseth je izvedel elftrace z uporabo opkode OP_CHECKCONTRACTVERIFY iz predloga mehke vilice MATT, ki omogoča preverjanje vseh programov, ki jih podpira kompilacija RISC-V, v verigi Bitcoin, s čimer so omogočeni avtohtoni mostovi za preverjanje Bitcoin za pogodbene protokole.

CSFS (OP_CHECKSIGFROMSTACK)

Iz predstavitve opkode APO vemo, da je OP_CHECKSIG (in povezane operacije) odgovoren za sestavljanje transakcij, hashanje in preverjanje podpisa. Vendar je sporočilo, ki ga preverja, izpeljano iz serializacije transakcije z uporabo te opkode, kar ne omogoča določitve drugih sporočil. Preprosto povedano, OP_CHECKSIG (in z njim povezane operacije) služi za preverjanje, ali je UTXO kot vhod transakcije pooblaščen za porabo s strani imetnika podpisa, s čimer se zaščiti varnost Bitcoina.

CSFS, kot pove že ime, preverja podpise iz sklada. Operacijska koda CSFS iz sklada vzame tri parametre: podpis, sporočilo in javni ključ ter preveri veljavnost podpisa. To pomeni, da je mogoče v sklad prek podatkov prič posredovati katero koli sporočilo, ki ga CSFS preveri, kar omogoča nekatere novosti v Bitcoinu.

Prilagodljivost sistema CSFS mu omogoča izvajanje različnih mehanizmov, kot so podpisi plačil, delegiranje pooblastil, pogodbe oracle in obveznice za zaščito pred dvojno porabo ter, kar je še pomembneje, introspekcija transakcij. Načelo introspekcije transakcij s sistemom CSFS je zelo preprosto. Če se vsebina transakcije, ki jo uporablja OP_CHECKSIG, potisne na kup prek priče in se za preverjanje s CSFS in OP_CHECKSIG uporabita isti javni ključ in podpis, če sta oba uspešna, potem je vsebina katerega koli sporočila, posredovanega CSFS, enaka serializirani transakciji porabe (in drugim podatkom), ki jo implicitno uporablja OP_CHECKSIG. Nato dobimo preverjene podatke o transakciji na kupu, ki jih lahko uporabimo za uporabo omejitev za transakcijo porabe z drugimi opkodami.

CSFS se pogosto pojavlja z OP_CAT, ker lahko OP_CAT združuje različna polja transakcije za dokončanje serializacije, kar omogoča natančnejši izbor polj transakcije za introspekcijo. Brez OP_CAT skripta ne more ponovno izračunati hashev iz posamezno preverljivih podatkov, zato lahko preveri le, ali se hash ujema z določeno vrednostjo, kar pomeni, da je kovance mogoče porabiti le prek ene določene transakcije.

CSFS lahko doseže opkode, kot so CLTV, CSV, CTV, APO, in je splošna introspekcijska opkoda, s čimer pomaga tudi pri rešitvah za skaliranje plasti 2 za Bitcoin. Njegova pomanjkljivost je, da zahteva dodajanje celotne kopije podpisane transakcije v sklad, kar lahko znatno poveča velikost transakcij, ki želijo uporabiti CSFS za introspekcijo. V nasprotju s tem imajo najmanj režijskih stroškov enonamenske opkode za introspekcijo, kot sta CLTV in CSV, vendar dodajanje vsake nove posebne opkode za introspekcijo zahteva spremembe konsenza.

TXHASH (OP_TXHASH)

OP_TXHASH je zelo preprosta opkoda za introspekcijo, ki operaterju omogoča, da izbere hash polja in ga potisne na zalogo. Natančneje, OP_TXHASH z odlagalne plošče odstrani zastavico txhash, izračuna (označen) txhash na podlagi zastavice in potisne dobljeni hash na odlagalno ploščo.

Zaradi podobnosti med TXHASH in CTV je v skupnosti potekala obsežna razprava o njiju.

TXHASH lahko obravnavamo kot splošno nadgradnjo CTV, saj zagotavlja naprednejšo predlogo transakcije, ki uporabnikom omogoča, da določijo dele transakcije porabe, kar rešuje številna vprašanja, povezana s pristojbinami za transakcije. Za razliko od drugih pogodbenih operacijskih kod TXHASH ne zahteva zagotavljanja kopije potrebnih podatkov v priči, kar še dodatno zmanjša potrebe po shranjevanju. Za razliko od CTV TXHASH ni združljiv z NOP in se lahko izvaja samo v tapscriptu. Kombinacija TXHASH in CSFS se lahko šteje kot alternativa CTV in APO.

Pri sestavljanju pogodb je s TXHASH lažje doseči “aditivne pogodbe”, tako da vse dele podatkov transakcije, ki jih želite popraviti, potisnete na kup, jih skupaj hashate in preverite, ali se rezultat ujema s fiksno vrednostjo. S CTV je lažje doseči “subtraktivne pogodbe”, tako da vse dele podatkov o transakciji, ki jih želite ohraniti proste, potisnete na kup. Nato z uporabo drseče OP_SHA256, začenši s fiksnim vmesnim stanjem, to vmesno stanje izroči predpono podatkov hash transakcije. Prosti deli so hashirani v to vmesno stanje.

Polje TxFieldSelector, opredeljeno v specifikaciji TXHASH, se bo predvidoma razširilo na druge opkode, kot je OP_TX.

BIP, povezan s TXHASH, je trenutno v statusu osnutka na Githubu in mu še ni bila dodeljena številka.

OP_CAT

OP_CAT je nekoliko skrivnostna opkoda, ki jo je Satoshi Nakamoto iz varnostnih razlogov ukinil. Vendar je nedavno sprožila obsežno razpravo med razvijalci jedra Bitcoina in v spletni skupnosti postala celo meme. Na koncu je bil OP_CAT odobren kot BIP-347, mnogi pa so ga označili za najverjetnejši predlog BIP, ki bo sprejet v bližnji prihodnosti.

V resnici je obnašanje OP_CAT zelo preprosto: dva elementa na kupu združi v enega. Toda kako to omogoča funkcionalnost pogodbe?

Funkcija združevanja dveh elementov ustreza močni kriptografski podatkovni strukturi, znani kot Merkle Trie. Konstrukcija tria Merkle zahteva le operaciji konkatenacije in hashanja, ki sta na voljo v skriptih Bitcoin. Zato lahko z OP_CAT teoretično preverjamo Merklejeve dokaze v skriptih Bitcoin, kar je najpogostejša lahka metoda preverjanja v verigah blokov.

Kot je bilo že omenjeno, lahko CSFS uporablja OP_CAT za doseganje splošne pogodbene sheme. Pravzaprav lahko OP_CAT tudi brez CSFS zaradi strukture Schnorrovih podpisov sam doseže introspekcijo transakcij.

Pri Schnorrovem podpisu je sporočilo, ki ga je treba podpisati, sestavljeno iz naslednjih polj:

• Različica
• Locktime
• Število vnosov
• Število izhodov
• Seznam vhodnih podatkov (vsak vključuje hash prejšnje transakcije, indeks, dolžino scenarija, scenarij, zaporedje)
• Seznam izhodov (vsak vključuje vrednost, dolžino scenarija, scenarij)

Ta polja vsebujejo glavne elemente transakcije. Če jih vstavimo v scriptPubKey ali witness ter uporabimo OP_CAT in OP_SHA256, lahko sestavimo Schnorrov podpis in ga preverimo z OP_CHECKSIG. Če je preverjanje uspešno, sklad ohrani preverjene podatke o transakciji, kar omogoča introspekcijo transakcije. Tako lahko izluščimo in “pregledamo” različne dele transakcije, kot so njeni vhodi, izhodi, ciljni naslovi ali vključeni zneski Bitcoin.

Za podrobnejša kriptografska načela si oglejte članek Andrewa Poelstre “CAT in Schnorrovi triki”.

Če povzamemo, lahko OP_CAT zaradi svoje prilagodljivosti posnema skoraj vsako pogodbeno opkodo, od njegove funkcionalnosti pa so odvisne številne pogodbene opkode. Zaradi tega je njegov položaj na seznamu za združevanje bistveno boljši. Teoretično bi lahko samo z OP_CAT in obstoječimi bitcoinskimi opkodami sestavili z zaupanjem zmanjšani BTC ZK Rollup. Starknet, Chakra in drugi partnerji iz ekosistema si aktivno prizadevajo, da bi se to zgodilo.

Zaključek

Ko raziskujemo različne strategije za razširitev Bitcoina in izboljšanje njegove programabilnosti, postane jasno, da pot naprej vključuje kombinacijo izvirnih izboljšav, računanja zunaj verige in zapletenih funkcij skript.

Brez prožnega osnovnega sloja je nemogoče ustvariti prožnejši drugi sloj.

Skalabilnost izračuna zunaj verige je prihodnost, vendar se mora programirljivost Bitcoina prebiti, da bi bolje podpirala skaliranje in postala prava svetovna valuta.

Vendar se izračunavanje v Bitcoinu bistveno razlikuje od izračunavanja v Ethereumu. Bitcoin podpira le “preverjanje” kot obliko računanja, medtem ko je Ethereum v osnovi računski, preverjanje pa je njegov stranski produkt. Ta razlika se kaže v dejstvu, da Ethereum zaračunava pristojbine za plin za neuspešne transakcije, medtem ko Bitcoin tega ne počne.

Pogodbe so oblika pametnih pogodb, ki temeljijo na preverjanju in ne na računanju. Kar zadeva pogodbe, večina ljudi, razen nekaj strogih fundamentalistov Satoshija, meni, da so pogodbe dobra izbira za izboljšanje Bitcoina. Vendar skupnost nenehno razpravlja o tem, katero shemo uporabiti za izvajanje pogodb.

APO, OP_VAULT in TLUV se nagibajo k neposredni uporabi. Z njihovo izbiro lahko določene aplikacije izvajate ceneje in učinkoviteje. Navdušenci nad omrežjem strele imajo raje APO, ker doseže LN-simetrijo; če želite ustvariti trezor, je najbolje uporabiti OP_VAULT; za izgradnjo CoinPool je TLUV zasebnejši in učinkovitejši. OP_CAT in TXHASH sta bolj splošna, z manj varnostnimi ranljivostmi, z njima pa lahko s kombinacijami z drugimi opkodami dosežemo več primerov uporabe, čeprav potencialno na račun zapletenosti skript. CTV in CSFS sta prilagodila pristop k obdelavi verige blokov: CTV implementira zakasnjene izhode, CSFS pa zakasnjene podpise. MATT je razmeroma edinstven, saj uporablja optimistično izvajanje in dokaze o prevarah ter se zanaša na strukturo Merkle Trie za doseganje splošnih pametnih pogodb, čeprav še vedno zahteva nove opkode za zagotavljanje zmožnosti introspekcije.

Vidimo, da skupnost Bitcoin že intenzivno razpravlja o možnosti uvedbe pogodb z mehkim viličenjem. Družba Starknet je uradno napovedala svoj vstop v ekosistem Bitcoin in načrtuje, da bo v šestih mesecih po združitvi OP_CAT uvedla poravnavo v omrežju Bitcoin. Chakra bo še naprej spremljala najnovejši razvoj dogodkov v ekosistemu Bitcoin, spodbujala združitev OP_CAT z mehko vilico ter uporabila programabilnost, ki jo prinašata introspekcija in pogodbe, za vzpostavitev varnejše in učinkovitejše plasti za poravnavo Bitcoin.