Scris de: Chakra Research

Prezentare generală

În comparație cu blockchain-urile complete Turing, cum ar fi Ethereum, scripturile pe Bitcoin sunt considerate a fi foarte limitate și pot efectua doar operațiuni de bază și nici măcar nu acceptă înmulțirea și împărțirea. Mai important, datele blockchain-ului în sine sunt aproape imposibil de citit prin scripturi, ceea ce duce la o lipsă gravă de flexibilitate și o programabilitate scăzută. Prin urmare, oamenii au încercat de multă vreme să găsească modalități de a face Scripturile Bitcoin introspective.

Introspecția se referă la capacitatea de a permite scripturilor Bitcoin să inspecteze și să limiteze datele tranzacțiilor. Acest lucru permite scripturilor să controleze utilizarea fondurilor pe baza detaliilor specifice ale unei tranzacții, permițând funcționalități mai complexe. Majoritatea codurilor actuale de operare Bitcoin (Opcodes) au doar două funcții: împingerea datelor furnizate de utilizator în stivă sau operarea pe datele existente pe stivă. Opcode-ul de introspecție poate împinge datele tranzacției curente (cum ar fi marca temporală, cantitatea, ID-ul tranzacției etc.) în stivă pentru a oferi un control mai precis asupra modului în care este cheltuit UTXO.

În prezent, doar trei coduri operaționale principale din Bitcoin Script acceptă introspecția: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY și CHECKSIG, de asemenea, are variante precum CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG și CHECKMULTISIGVERIFY.

Mai simplu spus, un contract este o restricție asupra modului în care token-urile pot fi transferate. Utilizatorii pot specifica metoda de distribuție a UTXO prin contract. Multe contracte sunt implementate prin coduri operaționale de introspecție, iar introspecția a fost acum discutată în cadrul intrărilor de contract în Bitcoin Optech.

Bitcoin are în prezent două contracte, CSV (CheckSequenceVerify) și CLTV (CheckLockTimeVerify), ambele fiind contracte pe timp, care stau la baza multor planuri de expansiune, cum ar fi Lightning Network. De asemenea, putem vedea din aceasta că planul de expansiune al Bitcoin se bazează în mare măsură pe introspecție și contracte.

Cum să adăugați restricții la transferul de jetoane? În lumea criptării, metoda cea mai des folosită este angajamentul, care este adesea implementat prin hash. Pentru a demonstra că îndeplinim cerințele de transfer, trebuie să o verificăm printr-un mecanism de semnătură. Prin urmare, există multe ajustări ale hashurilor și semnăturilor în contract.

Mai jos descriem propunerea de opcode de contract, larg discutată.

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify) este o actualizare Bitcoin discutată aprig de comunitate și inclusă în BIP-119. CTV permite scriptului de ieșire să specifice șablonul pentru utilizarea fondurilor în tranzacția de cheltuieli, inclusiv nVersion, nLockTime, scriptSig hash, număr de intrare, hash de secvențe, număr de ieșire, hash de ieșiri, index de intrare și alte câmpuri ale tranzacției restricțiile sunt trecute printr-un hash Pentru a realiza acest lucru, scriptul de cheltuieli viitoare va verifica dacă valoarea hash a câmpului specificat în tranzacția de cheltuieli se potrivește cu valoarea hash din scriptul de intrare Aceste șabloane limitează de fapt timpul, metoda, suma și alte detalii a tranzacției de cheltuieli viitoare UTXO.

Este de remarcat faptul că TXID-ul de intrare este exclus din promisiunea hash. Această excludere este necesară, fie în tranzacțiile Legacy sau Segwit, în tipul implicit de semnătură SIGHASH_ALL, TXID-ul trebuie generat pe baza valorii scriptPubKey. Prin urmare, includerea TXID-ului va provoca o buclă în promisiunea hash, care nu poate fi construită cu succes.

Modul în care CTV implementează introspecția este să obțină în mod direct informațiile specificate ale tranzacției printr-un nou opcode, să-l trimită și să o compare cu angajamentul din stivă. Această metodă de introspecție consumă mai puțin spațiu pe lanț, dar îi lipsește o anumită flexibilitate.

Baza soluțiilor de al doilea nivel ale Bitcoin, cum ar fi Lightning Network, sunt tranzacțiile presemnate. Pre-semnarea se referă, de obicei, la generarea și semnarea tranzacțiilor în avans, dar nu la difuzarea lor în rețea până când sunt îndeplinite anumite condiții. În esență, CTV implementează o funcție de pre-semnare mai strictă, publicând angajamentul presemnat direct pe lanț, iar tranzacțiile pot fi efectuate numai conform pre-șablonului.

CTV a fost propus inițial pentru a atenua congestia Bitcoin, care poate fi numită și controlul congestiei. Atunci când Bitcoin este relativ aglomerat, CTV poate fi folosit pentru a efectua mai multe tranzacții viitoare printr-o singură tranzacție, fără a fi nevoie să difuzeze mai multe tranzacții în timpul congestiei și apoi să finalizeze tranzacția reală după ce blocarea se reduce. Controlul congestionării poate fi de mare ajutor atunci când un schimb experimentează o alergare. În plus, șabloanele pot fi folosite și pentru a implementa seifuri pentru a preveni atacurile hackerilor. Deoarece destinația fondurilor este determinată, hackerul nu poate trimite UTXO folosind scriptul CTV la propria sa adresă.

CTV poate aduce îmbunătățiri uriașe rețelelor de nivel 2. De exemplu, pentru implementarea Timeout Trees și fabrici de canale în Lightning Network, prin CTV, un singur UTXO poate fi extins într-un arbore CTV și mai multe canale de stat sunt deschise în același timp, în timp ce există o singură tranzacție și o singură confirmare. pe lant. În plus, CTV oferă și suport pentru tranzacțiile atomice ATLC în protocolul Ark.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 propune un nou tip de indicator hash semnat pentru tapscript pentru a facilita scrierea unei logici de cheltuieli mai flexibile, numit SIGHASH_ANYPREVOUT. APO și CTV sunt similare în multe aspecte. Confruntat cu problema buclei dintre scriptPubKeys și TXID, soluția APO este să excludă informațiile legate de intrare și să semneze numai ieșirea, astfel încât tranzacțiile să poată fi legate dinamic la diferite UTXO.

Împărțită logic, operația de verificare a semnăturii OP_CHECKSIG (și codurile operaționale similare ale acesteia) are trei funcții:

1. Asamblarea diferitelor părți ale unei tranzacții de cheltuieli

2. Hash it.

3. Verificați dacă hash-ul a fost semnat de cheia dată.

Conținutul specific al semnăturii are mult spațiu de ajustare. Câmpurile de tranzacție asamblate pentru semnătură sunt determinate de steag SIGHASH. Conform definiției codului operațional de semnătură BIP 342, steagurile SIGHASH sunt împărțite în SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ANYONECANPAY etc., printre care SIGHASH_ANYONECANPAY controlează intrarea și restul controlează ieșirea.

SIGHASH_ALL este indicatorul SIGHASH implicit, care semnează toate ieșirile SIGHASH_NONE nu semnează nicio ieșire; SIGHASH_ANYONECANPAY poate fi setat împreună cu primele trei steaguri SIGHASH Dacă este setat SIGHASH_ANYONECANPAY, doar intrarea specificată va fi semnată, altfel toate intrările trebuie să fie semnate.

Evident, niciunul dintre aceste steaguri SIGHASH nu poate elimina impactul intrării. Chiar și SIGHASH_ANYONECANPAY necesită un angajament pentru o intrare.

Prin urmare, BIP 118 propune SIGHASH_ANYPREVOUT. Semnăturile APO nu necesită cheltuirea UTXO de intrare (numită PREVOUT), ci doar ieșirea, oferind o mai mare flexibilitate pentru controlul Bitcoin. Prin preconstruirea tranzacției și construirea semnăturii de unică folosință și a cheii publice corespunzătoare, activele trimise la adresa cheii publice trebuie cheltuite prin tranzacția preconstruită pentru a implementa contractul. Flexibilitatea APO poate fi folosită și pentru repararea tranzacțiilor. Dacă o tranzacție este blocată în lanț din cauza unor comisioane mici, o altă tranzacție poate fi creată cu ușurință cu taxe mai mari, fără a necesita semnături noi. În plus, pentru portofelele cu semnături multiple, semnăturile nu se bazează pe intrările cheltuite, ceea ce facilitează operarea.

Deoarece bucla dintre scriptPubKeys și TXID de intrare este eliminată. APO poate implementa introspecția prin adăugarea de date de ieșire în martor (Witness).

Pentru protocoalele în afara lanțului, cum ar fi Lightning Network și Vault, APO reduce starea intermediară care trebuie salvată, reducând considerabil cerințele de stocare și complexitatea. Cel mai direct caz de utilizare al APO este Eltoo, care simplifică fabrica de canale, construiește un turn de veghe ușor și ieftin și permite ieșirea unilaterală fără a lăsa o stare de eroare, îmbunătățind performanța rețelei Lightning în toate aspectele. APO poate fi folosit și pentru a simula funcțiile CTV, dar necesită indivizii să stocheze semnăturile și tranzacțiile presemnate, ceea ce este mai costisitor și nu la fel de eficient ca CTV.

Principala critică la adresa APO este că necesită o nouă versiune a cheii, care nu poate fi realizată prin compatibilitate pură inversă. În plus, noile tipuri de hash de semnătură pot introduce riscuri potențiale de cheltuire dublă. După discuții ample în comunitate, APO a solicitat adăugarea unei semnături comune peste semnătura originală. Problemele de securitate au fost atenuate și, prin urmare, APO a primit numărul BIP-118.

OP_VAULT BIP-345

BIP-345 propune adăugarea a două coduri operaționale noi, OP_VAULT și OP_VAULT_RECOVER, care să fie combinate cu CTV pentru a implementa un contract dedicat care permite utilizatorilor să forțeze o perioadă de întârziere pentru cheltuirea token-urilor specificate În perioada de întârziere, datele anterioare pot fi restaurate prin calea de recuperare Cheltuiește „Anulează”.

Utilizatorii pot construi un seif creând o anumită adresă Taproot. MAST trebuie să conțină cel puțin două scripturi, un script OP_VAULT pentru a facilita procesul de retragere așteptat și un alt script OP_VAULT_RECOVER pentru a se asigura că, în orice moment, înainte de finalizarea retragerii, monedele pot. fi restaurat.

OP_VAULT Cum se implementează retrageri întreruptibile blocate în timp? Pur și simplu, codul operațional OP_VAULT realizează un lucru: înlocuiește scriptul OP_VAULT uzat cu scriptul specificat, completând de fapt actualizarea unui singur nod frunză al MAST, lăsând nodurile frunză rămase neschimbate. Designul este similar cu TLUV, cu excepția faptului că OP_VAULT nu acceptă actualizări interne ale cheilor.

Introducerea șabloanelor în timpul procesului de actualizare a scriptului poate obține efectul de limitare a plăților. Printre acestea, parametrul time lock este specificat de OP_VAULT, iar șablonul adus de opcode-ul CTV limitează setul de ieșiri petrecute prin această cale de script.

BIP-345 s-a născut pentru seifuri Cu OP_VAULT și OP_VAULT_RECOVER, utilizatorii pot avea o metodă de escrow sigură cu o cheie foarte sigură (portofel de hârtie, multi-semnătură distribuită) ca cale de recuperare, iar restul configurației de plată zilnică. întârziat. Dispozitivul utilizatorului monitorizează continuu cheltuielile seifului și, dacă are loc un transfer neașteptat, utilizatorul îl poate restaura.

BIP-345 necesită considerații de cost la implementarea seifurilor, în special restabilirea tranzacțiilor. Soluțiile posibile includ CPFP, ancore temporare și noi semne hash, cum ar fi SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

Soluția TLUV este construită în jurul Taproot și își propune să rezolve problema ieșirii eficiente a UTXO partajat. Ideea călăuzitoare este că atunci când o ieșire Taproot este cheltuită, putem actualiza parțial cheia internă și MAST utilizând structura internă și transformarea criptografică a adresei Taproot conform pașilor de actualizare descriși în scriptul TLUV, realizând astfel funcția contractului. .

Ideea soluției TLUV este că printr-un nou opcode TAPLEAF_UPDATE_VERIFY, puteți crea o nouă adresă Taproot pe baza consumului curent de intrare, efectuând una sau mai multe dintre următoarele operații:

• Actualizați cheia publică internă

• tăierea merkle cale

• Eliminați nodul frunză care se execută în prezent

• Adăugați un nou nod frunză la sfârșitul căii Merkle

Mai exact, TLUV primește trei intrări:

• Unul specifică cum se actualizează cheia publică internă

• Unul specifică un nou nod frunză pentru calea Merkle

• Unul specifică dacă să eliminați nodul frunză curent și/sau câte noduri frunză cale Merkle să eliminați

Codul operațional TLUV calculează scriptPubKey actualizat și verifică dacă ieșirea corespunzătoare intrării curente consumă acel scriptPubKey.

Scenariul inspirator al TLUV este CoinPool. Astăzi este posibil să creați un pool federat folosind doar tranzacții presemnate, dar dacă doriți să obțineți o ieșire fără permisiune, trebuie să creați un număr exponențial mai mare de semnături, în timp ce TLUV permite o ieșire fără permisiune fără nicio pre-semnare. De exemplu, un grup de parteneri a folosit Taproot pentru a construi un UTXO comun care a pus în comun fondurile reciproce. Ei pot folosi tastele Taproot pentru a muta fonduri în interior și pot, de asemenea, să co-semneze pentru a iniția plăți în exterior. Persoanele fizice se pot retrage din fondul comun în orice moment și își pot șterge propria cale de plată. Alții pot în continuare să efectueze plăți prin calea inițială. În comparație cu tranzacțiile negrupate, această metodă este mai eficientă și mai privată.

Codul operațional TLUV implementează restricții parțiale de cheltuieli prin actualizarea MAST-ului original, dar nu implementează introspecția sumei de ieșire. Deci, trebuie să includeți și un nou cod operațional IN_OUT_AMOUNT, care împinge două date în stivă: cantitatea acestei intrări UTXO și cantitatea ieșirii corespunzătoare, apoi se așteaptă ca persoana care utilizează TLUV să folosească operatori matematici pentru a verifica dacă fondurile sunt rezervate corespunzător în scriptPubKey actualizat.

Introspecția cantității de ieșire adaugă un alt strat de complexitate, deoarece cantitatea de Bitcoin necesită până la 51 de biți pentru a fi reprezentată în satoshis, dar scriptul permite numai operații matematice pe 32 de biți și trebuie să fie actualizat în script prin redefinirea operatorului de comportament opcode sau folosiți SIGHASH_GROUP în loc de IN_OUT_AMOUNT.

Se așteaptă ca TLUV să ofere o soluție pentru fondurile descentralizate de nivel 2. Desigur, fiabilitatea modificărilor cheii publice Taproot nu a fost încă confirmată.

MATT

MATT (Merkleize All The Things) încearcă să atingă trei obiective: stare bazată pe Merkle, scripturi bazate pe Merkle și execuție bazată pe Merkle, iar apoi să realizeze contracte inteligente universale.

Stare Merkle: Construiți un Merkle Trie, în care fiecare nod frunză este valoarea hash a statului, iar rădăcina Merkle reprezintă starea întregului contract.

Script Merkle: adică MAST compus din Tapscript Fiecare nod frunză este o posibilă cale de tranziție.

Execuție bazată pe Merkle: Execuția bazată pe Merkle este realizată prin mecanisme criptate de angajament și de provocare a fraudei. Pentru orice funcție de calcul, participanții pot calcula în afara lanțului și apoi pot elibera un angajament, f(x)=y, iar alți participanți constată că calculul. rezultatul este greșit f(x)= z, puteți contesta și arbitra prin metoda dihotomiei, care este același principiu ca Optimistic Rollup.

Provocări de fraudă activate de Merkle

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

1. Forțați o ieșire să aibă scripturi specifice (și sumele acestora)

2. Adăugați o parte de date la o ieșire

3. Citiți date de la intrarea curentă (sau altă intrare)

Al doilea punct este foarte important, datele dinamice înseamnă că starea poate fi calculată din datele de intrare furnizate de consumator, deoarece aceasta oferă o simulare a mașinii de stări și poate determina următoarea stare cu date suplimentare. Soluția MATT este implementată prin propunerea codului operațional OP_CHECKCONTRACTVERIFY (OP_CCV), care este o fuziune a codurilor operaționale OP_CHECKOUTPUTCONTRACTVERIFY și OP_CHECKINPUTCONTRACTVERIFY propuse inițial și folosește un parametru de semnalizare suplimentar pentru a specifica obiectul operației.

Controlul cantității de ieșire: Cel mai direct mod este prin introspecție directă. Cu toate acestea, cantitatea de ieșire este un număr de 64 de biți și necesită operații pe 64 de biți, ceea ce este foarte complex în implementarea scripturilor Bitcoin. CCV adoptă o metodă de verificare întârziată, similară cu OP_VAULT. Întârzierea se datorează faptului că verificarea se face în timpul tranzacției și nu în timpul evaluării scriptului introdus.

Având în vedere caracterul general al protecției împotriva fraudei, o anumită variantă a contractului MATT ar trebui să permită toate tipurile de contracte inteligente sau construirea de al doilea strat, deși cerințe suplimentare (cum ar fi blocarea capitalului și întârzierile perioadei de provocare) trebuie evaluate cu precizie; pentru a evalua care aplicație este o tranzacție acceptabilă. De exemplu, mecanismul de provocare a angajamentului criptografic și a fraudei este utilizat pentru a simula funcția OP_ZK_VERIFY pentru a implementa Rollup fără încredere pe Bitcoin.

De fapt, deja se întâmplă. Johan Torås Halseth a implementat elftrace folosind codul de operare OP_CHECKCONTRACTVERIFY în propunerea de furcătură soft MATT, care poate verifica toate programele care acceptă compilarea RISC-V pe lanțul Bitcoin, permițând unei părți din acordul contractual să primească fonduri prin contract, realizând o punte A. la verificarea nativă a Bitcoin.

CSFS (OP_CHECKSIGFROMSTACK)

De la introducerea codului operațional APO, am aflat că OP_CHECKSIG (și operațiunile aferente acestuia) este responsabil pentru asamblarea tranzacțiilor, hashing și verificarea semnăturilor. Cu toate acestea, mesajul pe care îl verifică este obținut prin serializarea tranzacției folosind acest opcode și nu este permis să fie specificate alte mesaje. Mai simplu spus, OP_CHECKSIG (și operațiunile sale aferente) funcționează prin mecanismul de semnătură pentru a verifica dacă UTXO utilizat ca intrare de tranzacție este autorizat să fie cheltuit de către deținătorul semnăturii, protejând astfel securitatea Bitcoin.

CSFS, după cum sugerează și numele, verifică semnăturile din stivă. Opcode-ul CSFS primește trei parametri din stivă: o semnătură, un mesaj și o cheie publică și verifică validitatea semnăturii. Aceasta înseamnă că se pot transmite mesaje arbitrare stivei prin datele martor și le poate verifica de către CSFS. ceea ce face bitul Unele inovații asupra monedei sunt posibile.

Caracteristicile flexibile ale CSFS îi permit să implementeze mai multe mecanisme, cum ar fi semnăturile de plată, delegarea autorității, contractele oracle, obligațiunile de protecție cu cheltuieli duble etc. și, mai important, poate realiza introspecția tranzacției. Principiul utilizării CSFS pentru introspecția tranzacției este foarte simplu Dacă conținutul tranzacției utilizat de OP_CHECKSIG este împins în stivă prin martor, aceeași cheie publică și semnătură sunt utilizate pentru a verifica conținutul atât cu CSFS, cât și cu OP_CHECKSIG , atunci conținutul oricărui mesaj transmis către CSFS este același cu tranzacția de cheltuială serializată (și alte date) utilizate implicit pentru OP_CHECKSIG. Avem datele de tranzacție verificate în stivă și putem aplica alte coduri operaționale pentru tranzacția.

CSFS apare de obicei împreună cu OP_CAT, deoarece OP_CAT poate conecta diferite câmpuri ale tranzacției pentru a finaliza serializarea și poate selecta cu mai multă acuratețe câmpurile tranzacției care trebuie să fie introspectate. Fără OP_CAT, scriptul nu poate recalcula hash-ul din datele care pot fi verificate individual, așa că tot ce poate face este să verifice dacă hash-ul este egal cu o anumită valoare, ceea ce înseamnă că moneda poate fi cheltuită doar printr-o singură tranzacție specifică.

CSFS poate implementa coduri de operare CLTV, CSV, CTV, APO și alte operațiuni. Dezavantajul este că trebuie adăugată la stivă o copie completă a tranzacției semnate, ceea ce poate crește semnificativ dimensiunea tranzacțiilor pe care doriți să le introspectați cu CSFS. În comparație, codurile operaționale de introspecție cu un singur scop, cum ar fi CLTV și CSV, folosesc un cost minim, dar adăugarea fiecărui nou cod operațional de introspecție special necesită o schimbare de consens.

TXHASH (OP_TXHASH)

OP_TXHASH este un opcode de introspecție foarte simplu, care permite operatorului să selecteze un hash al unui câmp pentru a-l împinge pe stivă. Mai exact, OP_TXHASH va scoate un flag txhash din stivă, va calcula un txhash (etichetat) pe baza acelui indicator și va împinge hash-ul rezultat în stivă.

Datorită asemănării dintre TXHASH și CTV, au existat multe discuții despre cei doi în comunitate.

TXHASH poate fi văzut ca o actualizare generală la CTV, oferind un șablon de tranzacție mai avansat, care permite utilizatorilor să cheltuiască în mod explicit o parte dintr-o tranzacție, ceea ce rezolvă multe probleme legate de comisioanele de tranzacție. În comparație cu alte coduri de operare contractuale, TXHASH nu trebuie să furnizeze o copie a datelor necesare în martor, reducând și mai mult nevoia de stocare, spre deosebire de CTV, TXHASH nu este compatibil cu NOP și poate fi implementat doar în combinația TXHASH și; CSFS poate fi considerat o alternativă la CTV și APO.

Din perspectiva modului în care este construit contractul, TXHASH face mai ușoară implementarea unui „contract aditiv”, împingând toate părțile datelor tranzacției pe care doriți să le remediați în stivă, combinându-le pe toate împreună și verificând dacă hash-ul rezultat se potrivește cu valoarea fixă ​​CTV Este mai ușor să implementați „contracte scădere”, împingând toate părțile datelor de tranzacție pe care doriți să le păstrați libere în stivă. Apoi utilizați rularea OP_SHA256 pentru a începe de la o stare intermediară fixă ​​care comite prefixul datelor hash ale tranzacției. Partea liberă este hashed în această stare intermediară.

Câmpul TxFieldSelector definit în specificația TXHASH este de așteptat să fie extins la alte opcodes, cum ar fi OP_TX.

BIP-ul legat de TXHASH este în prezent în stare de schiță pe Github și nu a fost încă numerotat.

OP_CAT

OP_CAT este un cod de operare destul de misterios. A fost abandonat de Satoshi Nakamoto din cauza problemelor de securitate. A provocat recent un număr mare de discuții între dezvoltatorii de bază Bitcoin și chiar a declanșat o cultură Meme pe Internet BIP-347 și a fost Mulți oameni o numesc propunerea BIP cel mai probabil să fie adoptată în viitorul apropiat.

De fapt, OP_CAT se comportă foarte simplu, concatenând două elemente din stivă într-unul singur. Cum se implementează funcția de contract?

De fapt, funcția de îmbinare a două elemente corespunde unei puternice structuri de date criptografice, Merkle Trie. Procesul de construcție al lui Merkle Trie necesită doar două operațiuni: splicing și hashing, iar în scripturile Bitcoin sunt disponibile funcții hash. Prin urmare, cu OP_CAT, putem verifica teoretic Merkle Proof în scriptul Bitcoin, care este cea mai frecventă metodă de verificare ușoară în blockchain.

După cum sa menționat anterior, CSFS, cu ajutorul OP_CAT, este capabil să implementeze o schemă de contract comună. De fapt, OP_CAT însuși poate implementa introspecția tranzacției fără CSFS, valorificând structura semnăturilor Schnorr.

În semnătura Schnorr, mesajul care trebuie semnat este compus din următoarele câmpuri:

Aceste câmpuri conțin elementele principale ale tranzacției, plasându-le într-un scriptPubKey sau martor, folosind OP_CAT și OP_SHA256, putem construi o semnătură Schnorr și o putem verifica folosind OP_CHECKSIG. Dacă verificarea trece, datele tranzacției verificate sunt păstrate în stivă, permițând introspecția tranzacției, cu capacitatea de a extrage și „examina” diferite părți ale tranzacției, cum ar fi intrările, ieșirile, adresa de destinație sau cantitatea de Bitcoin. implicat.

Pentru principii specifice de criptare, vă rugăm să consultați articolul CAT și Schnorr Tricks publicat de Andrew Poelstra.

În rezumat, flexibilitatea lui OP_CAT îi permite să emuleze aproape orice cod operațional de contract, iar un număr mare de coduri operaționale contractuale se bazează pe funcționalitatea OP_CAT, ceea ce îl plasează semnificativ în fruntea listei de îmbinare. În teorie, bazându-ne doar pe OP_CAT și pe codurile operaționale Bitcoin existente, putem spera să construim un BTC ZK Rollup cu încredere minimizată, iar Starknet, Chakra și alți parteneri ecologici promovează în mod activ acest lucru.

Concluzie

Pe măsură ce explorăm mai multe strategii pentru scalarea Bitcoin și creșterea programabilității acestuia, este clar că calea de urmat implică o combinație de îmbunătățiri native, calcul în afara lanțului și capabilități sofisticate de scripting.

Fără un strat de bază flexibil, nu puteți construi un al doilea strat mai flexibil.

Expansiunea de calcul în afara lanțului este viitorul, dar trebuie să existe un progres în programabilitatea Bitcoin pentru a sprijini mai bine expansiunea și a deveni o monedă reală.

Cu toate acestea, calculele Bitcoin și Ethereum sunt de fapt fundamental diferite Bitcoin acceptă doar „verificarea” ca formă de calcul și nu poate efectua calcule generale, în timp ce Ethereum este de natură computațională, iar verificarea este un produs secundar al calculului. Această diferență poate fi văzută dintr-un punct: Ethereum percepe o taxă sub formă de gaz pentru tranzacțiile eșuate, în timp ce Bitcoin nu.

Contractul implementează o formă de contract inteligent bazat mai degrabă pe verificare decât pe calcul. În ceea ce privește contractele, toată lumea, cu excepția unui număr mic de fundamentaliști Satoshi, pare să creadă că contractele sunt o opțiune bună pentru îmbunătățirea Bitcoin. Cu toate acestea, comunitatea continuă să dezbate ce metodă ar trebui utilizată pentru implementarea contractului.

APO, OP_VAULT și TLUV sunt mai părtinitoare către aplicațiile directe, iar alegerea acestora poate implementa aplicații specifice într-un mod mai ieftin și mai eficient. Pasionații de Lightning Network vor prefera APO, deoarece poate implementa LN-Symmetry dacă doriți să implementați un seif, cel mai bine este să utilizați OP_VAULT pentru a construi CoinPool, pentru mai multă confidențialitate și eficiență; OP_CAT și TXHASH sunt mai versatile și mai puțin probabil să aibă vulnerabilități de securitate Prin combinarea cu alte opcode, pot fi realizate mai multe cazuri de utilizare, desigur, în detrimentul complexității scriptului. CTV și CSFS au făcut ajustări în procesul de procesare blockchain CTV a implementat ieșire întârziată, iar CSFS a implementat semnături întârziate. MATT este relativ unic, folosind ideile de execuție optimistă și de dovadă a fraudei și folosind structura Merkle Trie pentru a implementa contracte inteligente universale, dar încă are nevoie de coduri operaționale noi pentru a aduce funcții de introspecție.

Am văzut că comunitatea Bitcoin discută deja intens despre posibilitatea de a permite Bitcoin să obțină contracte prin soft forks. Starknet și-a anunțat oficial intrarea în ecosistemul Bitcoin și intenționează să implementeze decontarea în rețeaua Bitcoin în termen de șase luni de la fuziunea OP_CAT. Chakra va continua să acorde atenție celor mai recente tendințe din ecosistemul Bitcoin, să promoveze fuziunea OP_CAT soft forks și să folosească programabilitatea adusă de introspecție și contracte pentru a construi un strat de decontare Bitcoin mai sigur și mai eficient.

Mulțumim lui Jeffrey, Ben, Mutourend și Lynndell pentru recenzia și sugestiile lor cu privire la acest articol