Bitcoin Covenants Pjesa 5: MATT dhe OP_CHECKCONTRACTVERIFY — Si mund ta mbajë Bitcoin-i gjendjen ndër transaksione. OP_CCV ngulit gjendjen e kontratës direkt në çelësat e prodhimit Taproot dhe zbaton kalime të vlefshme të gjendjes në rrjet (onchain). Kjo bën të mundur arritjen e kontratave me gjendje dhe provave kompakte të mashtrimit.
Kjo është Pjesa 5 në serinë e artikujve teknikë rreth kovenanteve të Bitcoin nga Cointelegraph Research. Për të lexuar artikullin e mëparshëm klikoni këtu.
MATT (Merkleize All The Things) është një kuadër kontratash inteligjente për Bitcoin që mundëson kontrata me gjendje dhe prova mashtrimi të shkallëzueshme. Një kontratë me gjendje mbart informacionin përpara përgjatë transaksioneve të shumta dhe mund ta përditësojë këtë informacion ndërsa kontrata evoluon. Skriptet standarde të Bitcoin nuk e sigurojnë këtë aftësi, sepse çdo transaksion vlerësohet në mënyrë të pavarur pa pasur kujtesë të ekzekutimeve të mëparshme.
Çdo propozim kovenanti lejon UTXO që mbajnë gjendje deri në një farë mase, siç ilustrohet nga gjuhët e skriptimit si Sapio, e cila ndërtohet mbi OP_CTV. Kjo funksionon duke përdorur adresat për të përfaqësuar një automat me gjendje të fundme, ku transaksionet funksionojnë si kalime gjendjesh. Megjithatë, nuk ka asnjë mënyrë për të zatuar në mënyrë elegante logjikën numerike në këtë paradigmë, një boshllëk i mbushur nga MATT, dhe në veçanti zbatimi i tij i propozuar përmes OP_CCV. Për shkak se MATT lejon që të dhënat e angazhuara të llogariten në kohën e shpenzimit dhe të ringuliten në prodhimin e ardhshëm, çdo shpenzim mund të nxjerrë një gjendje të re në mënyrë dinamike, në vend që të zgjedhë nga një grup i caktuar paraprakisht i gjendjeve.
Si OP_CCV angazhon gjendjen në një çelës Taproot
Për të kuptuar propozimin MATT, është e dobishme të rishikohet fillimisht se si Taproot angazhon të dhënat përmes çelësave publikë. Çdo prodhim Taproot përmban një çelës publik bazë, i quajtur çelësi i brendshëm, i cili mund të modifikohet në mënyrë kriptografike ose "të përshtatet" për të angazhuar informacion shtesë. Formalisht, çelësi publik i përshtatur është Q = P + t·G, ku P është çelësi i brendshëm, G është gjeneratori i kurvës eliptike secp256k1, dhe t është një hash i etiketuar i P dhe të dhënave të angazhuara.
Në një prodhim të rregullt Taproot, ky angazhim zakonisht kodon rrënjën Merkle të një taptree, e cila përmban rrugë të fshehura shpenzimi. MATT ndërtohet mbi këtë mekanizëm për të ngulitur gjithashtu gjendjen e kontratës në çelës. Në vend që të ngulitë logjikë komplekse direkt në gjuhën e skriptimit të Bitcoin, MATT kodon llogaritjen si një sekuencë angazhimesh gjendjeje, dhe zinxhiri verifikon vetëm se çdo kalim gjendjeje është i vlefshëm.
MATT mund të realizohet përmes kombinimeve të ndryshme të opkodeve. Zbatimi më i drejtpërdrejtë dhe i specifikuar mirë mbështetet te OP_CHECKCONTRACTVERIFY (OP_CCV). OP_CCV siguron primitivin që i bën të realizueshme UTXO-të që mbajnë gjendje brenda Taproot. OP_CCV i lejon një skripti të verifikojë se një hyrje ose prodhim çelësi Taproot është përshtatur për të angazhuar një pjesë specifike të të dhënave të gjendjes. Çelësi i brendshëm fillimisht përshtatet me një hash të gjendjes aktuale të kontratës, dhe më pas përshtatja standarde e taptree të Taproot zbatohet sipër. Çelësi i prodhimit që rezulton angazhohet kështu si për tapscript (grupin e kushteve të shpenzimit) ashtu edhe për gjendjen aktuale të kontratës.
OP_CCV mund të zbatojë më pas se çfarë gjendjeje mbartet përpara në prodhimin e ardhshëm. Ai e lejon skriptin të inspektojë të dhënat e gjendjes të siguruara në grumbullin e dëshmitarëve (witness stack), të kryejë llogaritje mbi to dhe të kërkojë që gjendja e përditësuar që rezulton të ringushtohet saktësisht në një prodhim të specifikuar. Kështu zbatohen kalimet e gjendjes në zinxhir. Formati i grumbullit është: OP_CHECKCONTRACTVERIFY
Opkodi mbështet tri mënyra për kontrollin e një prodhimi si dhe një mënyrë të veçantë hyrjeje. Në mënyrën e paracaktuar (default), e gjithë vlera BTC e UTXO hyrëse alokohet në prodhimin e specifikuar; në mënyrën e zbritjes (deduct), vetëm një pjesë e barabartë me shumën e prodhimit caktohet, duke lënë pjesën tjetër të disponueshme për prodhime të mëtejshme; dhe në mënyrën e shpërfilljes (ignore), skripti dhe angazhimi i të dhënave verifikohen pa kufizuar shumën. Për shkak se mënyrat e paracaktuar dhe e zbritjes janë krijuar për të ruajtur vlerën përgjatë prodhimeve të kontrolluara, tarifat e transaksionit duhet të paguhen përmes hyrjeve të veçanta që paguajnë tarifa. Një hyrje e dedikuar tarife dhe një prodhim kusuri mund t'i shtohen transaksionit pa rënë ndesh me kufizimet e kovenantit. Kjo parandalon djegien aksidentale të fondeve që mund të ndodhë në zbatime më primitive të kovenanteve, si OP_CTV ose SIGHASH_ANYPREVOUT. Gjithashtu adreson një kufizim të madh të kovenanteve të stilit të transaksioneve të nënshkruara paraprakisht, të cilat zakonisht përcaktojnë shumat paraprakisht dhe për këtë arsye nuk mund të përshtatin rregullime dinamike tarifash ose shkyçje të pjesshme.
OP_CCV + OP_CAT: Prova Merkle dhe Prova Mashtrimi
Kur OP_CCV kombinohet me OP_CAT, kuadri i plotë MATT bëhet edhe më shprehës. OP_CAT mundëson bashkimin e bajteve në Skript, gjë që bën të mundur ndërtimin dhe verifikimin e provave Merkle direkt në zinxhir. Dy pemë Merkle të dallueshme shoqërohen me një prodhim Taproot në një rregullim të tillë. E para është pema e njohur e skriptit Taproot (taptree), gjethet e së cilës janë skriptet e shpenzimit të kontratës. E dyta është një pemë e veçantë gjendjeje, gjethet e së cilës janë të dhënat e kontratës, si hapat e ndërmjetëm të një llogaritjeje. Skripti OP_CCV + OP_CAT mund të verifikojë një provë Merkle kundër rrënjës aktuale të pemës së gjendjes, të llogarisë rrënjën e përditësuar pas një kalimi, dhe të përdorë OP_CCV për të detyruar prodhimin e ardhshëm të angazhohet ndaj saj.
Ky ndërtim mundëson sisteme të provave të mashtrimit me një kusht ndëshkimi në të cilin një llogaritje e gjatë angazhohet jashtë zinxhirit (off-chain), dhe vetëm hapi specifik i kontestuar (me rrugën e tij në pemën binare) duhet të zbulohet dhe verifikohet në zinxhir. Sisteme të ngjashme ekzistojnë si rollup-e optimiste në sisteme të tjera bllokçaji: llogaritja e plotë ekzekutohet jashtë zinxhirit, dhe kontrata në zinxhir ndërhyn vetëm kur dikush ngre një sfidë. Provat e mashtrimit kërkojnë që llogaritja të përpunohet në një qark binar ose përfaqësim ekuivalent hap pas hapi që mund të angazhohet në një pemë Merkle. OP_CCV + OP_CAT do të shmangte nevojën për nënshkrimet njëpërdorimëshe Lamport dhe grafikët e transaksioneve të nënshkruara paraprakisht në të cilat mbështetet BitVM për të zbatuar konsistencën e gjendjes.
Përtej provave të mashtrimit, kombinimi i OP_CCV dhe OP_CAT ka gjithashtu implikacione për kasafortat (vaults). Vetëm OP_CCV mund të zbatojë kasaforta, por kur kombinohet me OP_CAT, ai lejon kasaforta plotësisht funksionale që janë esencialisht ekuivalente me funksionalitetin e propozuar nga OP_VAULT. Siç ka vënë në dukje James O’Beirne, autori i OP_VAULT, OP_CCV përfaqëson një dizajn më të përgjithshëm dhe më të qëndrueshëm që zëvendëson në mënyrë efektive propozimin e tij të mëparshëm.
Në artikullin e ardhshëm në këtë seri, do të kalojmë nga propozimet e përgjithshme të kovenanteve për të shqyrtuar opkode specifike për aplikacione si OP_VAULT, OP_UNVAULT dhe OP_EVICT. Secili prej opkodeve është krijuar për të zgjidhur një problem specifik në vend që të sigurojë programueshmëri të gjerë.
Revistë: Mbajtësit e Bitcoin kanë marrë eCash — Çfarë mund të bëni me të?
