Scris de: Nickqiao, Faust, Shew Wang, geek web3

Consultant: Echipa de cercetare Bitlayer

Rezumat: Delphi Digital a lansat recent un raport de cercetare privind tehnologiile legate de cel de-al doilea strat Bitcoin, intitulat „The Dawn of Bitcoin Programmability: Paving the Way for Rollups”, care a sortat sistematic conceptele de bază legate de Bitcoin Rollups, cum ar fi BitVM Family Bucket, OP_CAT și restricțiile Covenant, stratul DA ecologic, bridge-ul și cele patru straturi secundare majore Bitcoin care utilizează BitVM, inclusiv Bitlayer, Citrea, Yona și Bob.

Deși raportul de cercetare arată în general imaginea generală a tehnologiei de al doilea strat a Bitcoin, este în general relativ general și nu are o descriere detaliată, ceea ce face dificil de înțeles. Geek web3 a efectuat săpături extinse și aprofundate pe baza raportului de cercetare Delphi, încercând să permită mai multor oameni să înțeleagă sistematic BitVM și alte tehnologii.

Vom lansa împreună o serie de rubrici numite „Apropierea BTC” cu echipa de cercetare Bitlayer și comunitatea chineză BitVM pentru a realiza popularizarea științifică pe termen lung în jurul unor subiecte cheie precum BitVM, OP_CAT și punțile încrucișate Bitcoin și ne-am angajat să dezamăgească. Bitcoin pentru mai mulți oameni Tehnologiile legate de nivelul 2 de monedă ajută la deschiderea drumului pentru mai mulți entuziaști.

În urmă cu câteva luni, Robin Linus, șeful ZeroSync, a publicat un articol intitulat „BitVM: Compute Anything on Bitcoin”, propunând în mod oficial conceptul de BitVM și promovând progresul tehnologiei de strat al doilea a Bitcoin. Se poate spune că aceasta este una dintre cele mai revoluționare inovații din ecosistemul Bitcoin A detonat întregul ecosistem Bitcoin de stratul secund, a atras participarea unor proiecte vedete precum Bitlayer, Citrea, BOB etc. și a adus vitalitate. intreaga piata.

După aceea, mai mulți cercetători au participat la îmbunătățirea BitVM și au lansat succesiv diferite versiuni iterative, cum ar fi BitVM1, BitVM2, BitVMX și BitSNARK. Situația generală este următoarea:

  1. Cartea albă de implementare BitVM propusă pentru prima dată de Robin Linus anul trecut este o implementare BitVM bazată pe circuite de porți logice fictive, numite BitVM0;

  2. În mai multe discursuri și interviuri ulterioare, Robin Linus a introdus în mod informal soluția BitVM (numită BitVM1) bazată pe un procesor fictiv, care este similar cu sistemul de protecție împotriva fraudelor de la Optimism, care poate utiliza scripturi Bitcoin pentru a simula efectele CPU off-chain .

  3. Robin Linus a propus, de asemenea, BitVM2, un protocol fără permisiune, cu un singur pas, non-interactiv împotriva fraudei.

  4. Membrii Rootstock Labs și Fairgate Labs au lansat cartea albă BitVMX, care, similar cu BitVM1, speră să emuleze efectele unui CPU de uz general (off-chain) prin intermediul scripturilor Bitcoin.

În prezent, construcția ecosistemului de dezvoltatori legat de BitVM devine din ce în ce mai clară, iar îmbunătățirea iterativă a instrumentelor periferice este vizibilă și cu ochiul liber, în comparație cu anul trecut, ecosistemul BitVM de astăzi a devenit „vag vizibil” din „castelul” inițial în aer", care, de asemenea, a atras din ce în ce mai mulți oameni. Mai mulți dezvoltatori și VC se grăbesc în ecosistemul Bitcoin.

Dar pentru majoritatea oamenilor, nu este ușor de înțeles termenii tehnici legați de BitVM și Bitcoin Layer 2, deoarece trebuie să aveți o înțelegere sistematică a cunoștințelor de bază care îl înconjoară, în special a fundamentelor precum scripturile Bitcoin și Taproot. Materialele de referință disponibile în prezent pe Internet sunt fie prea lungi și pline de prostii, fie explicațiile nu sunt suficient de amănunțite, făcând oamenii să pară că înțeleg, dar nu înțeleg. Ne angajăm să rezolvăm problemele de mai sus și ne străduim să folosim cel mai clar limbaj posibil pentru a ajuta mai mulți oameni să înțeleagă cunoștințele din jur despre cel de-al doilea strat Bitcoin și să stabilim o înțelegere sistematică a sistemului BitVM.

MATT și angajament: ideea de bază a BitVM

În primul rând, dorim să subliniem faptul că ideea de bază a BitVM este MATT, ceea ce înseamnă Merkleize All The Things. Se referă în principal la utilizarea unei structuri de stocare a datelor, cum ar fi Merkle Tree, pentru a afișa procesul complex de execuție a programului. încercați să faceți dovada fraudei de verificare a Bitcoin Native.

Deși MATT poate exprima un program complex și urmele sale de prelucrare a datelor, nu va publica direct aceste date pe lanțul BTC, deoarece dimensiunea totală a acestor date este foarte mare. Soluția care utilizează MATT stochează numai date în arborele Merkle în afara lanțului și publică doar rezumatul de sus (rădăcină Merkle) al arborelui Merkle în lanț. Acest arbore Merkle conține în principal trei conținuturi de bază:

  • Cod de script de contract inteligent

  • Date cerute de contract

  • Urme lăsate în timpul executării contractului (înregistrări ale modificărilor aduse memoriei și registrelor CPU atunci când contractele inteligente sunt executate în mașini virtuale, cum ar fi EVM)

(O diagramă Merkle Tree simplă. Rădăcina Merkle este calculată din cele 8 fragmente de date din partea de jos a figurii prin hashing cu mai multe straturi)

În cadrul schemei MATT, doar rădăcina Merkle extrem de mică este stocată în lanț, iar setul complet de date conținut în Arborele Merkle este stocat în afara lanțului. Aceasta folosește o idee numită „angajament”. Iată o explicație a ce este „angajamentul”.

O promisiune este similară cu o declarație concisă, pe care o putem înțelege ca o „amprentă” obținută prin comprimarea unei cantități mari de date. În general, persoana care emite un „angajament” pe lanț va pretinde că anumite date stocate în afara lanțului sunt corecte. Aceste date în afara lanțului ar trebui să corespundă unei declarații concise, iar această declarație este „angajamentul”.

La un moment dat, hash-ul datelor poate fi folosit ca un „angajament” față de datele în sine. Alte scheme de angajament includ angajamentul KZG sau Merkle Tree. În protocolul obișnuit împotriva fraudei al Layer2, editorul de date publică setul de date complet în afara lanțului și se angajează să publice setul de date în lanț. Dacă cineva descoperă date nevalide în setul de date în afara lanțului, angajamentul privind datele în lanț va fi contestat.

Prin Commitment, al doilea strat poate comprima și procesa cantități mari de date și își poate publica „angajamentul” doar pe lanțul Bitcoin. Desigur, este, de asemenea, necesar să ne asigurăm că setul complet de date eliberat în afara lanțului poate fi observat de lumea exterioară.

În prezent, câteva soluții BitVM majore, cum ar fi BitVM0, BitVM1, BitVM2 și BitVMX, adoptă practic structuri abstracte similare:

1. Descompunerea și angajamentul programului: În primul rând, descompuneți programul complex într-un număr mare de coduri de operare de bază (compilare), apoi înregistrați urmele generate de aceste coduri de operare în timpul execuției specifice (pentru a spune clar, un program rulează pe CPU și Când se află în memorie, toate schimbările de stare sunt înregistrate, numite Urmă). După aceea, organizăm toate datele, inclusiv urmele și codurile operaționale, într-un set de date și apoi generăm un angajament pentru acel set de date.

Schemele specifice de angajament pot lua mai multe forme, cum ar fi: arbori Merkle, PIOP-uri (diverși algoritmi ZK), funcții hash

2. Angajarea activelor și presemnarea: editorii de date și verificatorii trebuie să blocheze o anumită cantitate de active pe lanț prin presemnare și vor exista restricții. Aceste condiții vor fi declanșate în mod specific pentru situații care pot apărea în viitor. Dacă editorul de date face rău, verificatorul poate trimite un certificat pentru a elimina bunurile editorului de date.

3. Publicarea datelor și a angajamentului: editorul de date publică angajamentul în lanț, setul complet de date este publicat în afara lanțului, iar verificatorul preia setul de date și verifică dacă există erori. Fiecare parte a setului de date în afara lanțului are o corelație cu un angajament în lanț.

4. Provocări și penalități: odată ce verificatorul descoperă că există o eroare în datele furnizate de editorul de date, va duce această parte a datelor în lanț pentru verificare directă (această parte a datelor trebuie mai întâi tăiată foarte fin). ). Aceasta este logica dovezii de fraudă. Dacă rezultatele verificării arată că editorul de date a furnizat într-adevăr date invalide în afara lanțului, activele acestuia vor fi luate de validatorul care îl contestă.

În concluzie, editorul de date Alice dezvăluie toate urmele generate în timpul execuției tranzacției de nivel al doilea în afara lanțului și publică angajamentele corespunzătoare față de lanț. Dacă doriți să demonstrați că o anumită parte a datelor este greșită, mai întâi dovediți nodului Bitcoin că această parte a datelor este legată de angajamentul pe lanț, adică dovediți că datele sunt dezvăluite de Alice însăși și apoi lăsați nodul Bitcoin să confirme că această parte a datelor este greșită.

Acum înțelegem aproximativ ideea generală a BitVM, iar toate variantele BitVM sunt practic inseparabile de paradigma de mai sus. Deci, în continuare, să începem să învățăm și să înțelegem unele dintre tehnologiile importante utilizate în procesul de mai sus, începând cu cele mai elementare scripturi Bitcoin și Taproot și pre-semnare.

Ce este Bitcoin Script?

Cunoștințele legate de Bitcoin sunt mai greu de înțeles decât Ethereum Chiar și cel mai elementar comportament de transfer implică o serie de concepte, inclusiv UTXO (ieșire de tranzacție necheltuită), script de blocare (cunoscut și ca ScriptPubKey) și script de deblocare (cunoscut și ca ScriptSig). Să explicăm mai întâi aceste concepte principale.

(Un exemplu de cod de script Bitcoin constând din coduri operaționale de nivel inferior decât un limbaj de nivel înalt)

Modul în care sunt exprimate activele în Ethereum seamănă mai mult cu Alipay sau WeChat. Fiecare transfer doar adaugă și scade soldurile diferitelor conturi, iar soldul activelor este doar un număr sub numele de cont Expresia este mai mult ca aur. Fiecare bucată de aur (UTXO) va fi marcată cu proprietarul său. Transferul distruge de fapt vechiul UTXO și generează un nou UTXO (proprietarul se va schimba).

Bitcoin UTXO conține două câmpuri cheie:

  • Suma, în „satoshi” (o sută de milioane de satoshi este un BTC);

  • Scriptul de blocare, cunoscut și sub numele de „ScriptPubKey”, definește condițiile de deblocare a UTXO.

Trebuie remarcat faptul că proprietatea asupra Bitcoin UTXO este exprimată printr-un script de blocare Dacă doriți să transferați UTXO-ul dvs. către Sam, puteți iniția o tranzacție pentru a distruge unul dintre UTXO-urile dvs. și puteți scrie condițiile de deblocare ale UTXO-ului nou generat ca „. Numai Sam îl poate debloca.”

Ulterior, dacă Sam dorește să folosească acești Bitcoin, trebuie să trimită un script de deblocare (ScriptSig). În acest script de deblocare, Sam trebuie să-și prezinte semnătura digitală pentru a dovedi că este Sam însuși. Dacă scriptul de deblocare se potrivește cu scriptul de blocare menționat mai sus, Sam poate debloca și transfera bitcoinii altora.

(Scriptul de deblocare trebuie să se potrivească cu scriptul de blocare)

Din perspectiva expresiei, fiecare tranzacție din lanțul Bitcoin corespunde mai multor intrări și ieșiri. Fiecare intrare trebuie să declare un anumit UTXO pe care dorește să îl deblocheze și să trimită un script de deblocare pentru a debloca și a distruge informațiile UTXO nou generate va fi afișat și conținutul scriptului de blocare va fi dezvăluit lumii exterioare.

De exemplu, în introducerea unei tranzacții, dovediți că sunteți Sam, deblocați mai multe UTXO oferite de alții, le distrugeți uniform, generați mai multe UTXO noi și declari că xxx va fi deblocat în viitor.

Mai exact, în datele de intrare ale tranzacției, trebuie să declarați ce UTXO doriți să deblocați și să indicați „locația de stocare” a acestor date UTXO. Trebuie remarcat aici că Bitcoin și Ethereum sunt complet diferite, conturi contractuale și conturi EOA, pentru a stoca datele într-o bază de date unificată a „World State”, la transferul de bani, anumite conturi pot fi modificate direct din „World State” pentru a facilita localizarea locației de stocare a datelor;

Bitcoin nu are un design de stat mondial, iar datele activelor sunt împrăștiate și stocate în blocurile anterioare (adică datele UTXO deblocate sunt stocate separat în OutPut-ul fiecărei tranzacții).

Dacă doriți să deblocați un UTXO, trebuie să indicați ce ieșire a tranzacției informațiile UTXO există în trecut, să afișați ID-ul tranzacției (care este hash-ul său) și să lăsați nodul Bitcoin să o caute în înregistrările istorice. Dacă doriți să interogați soldul Bitcoin al unei anumite adrese, trebuie să traversați toate blocurile de la început și să găsiți UTXO-ul deblocat asociat cu adresa xx.

Când utilizați de obicei un portofel Bitcoin, puteți verifica rapid soldul Bitcoin deținut de o anumită adresă. Acest lucru se datorează adesea faptului că serviciul de portofel însuși indexează toate adresele prin scanarea blocurilor, ceea ce ne face mai ușor să interogăm rapid.

(Când generați o declarație de tranzacție pentru a oferi UTXO-ul dvs. altora, trebuie să marcați poziția UTXO-ului în istoricul Bitcoin pe baza hash-ului/ID-ului tranzacției căruia îi aparțin aceste UTXO)

Interesant este că rezultatele tranzacțiilor Bitcoin sunt calculate în afara lanțului. Când utilizatorii generează tranzacții pe dispozitivele lor locale, trebuie să creeze direct atât Input, cât și Output, ceea ce este echivalent cu calcularea rezultatelor tranzacției. Tranzacțiile sunt difuzate în rețeaua Bitcoin și verificate de noduri înainte de a fi puse în lanț. Acest model de „verificare de calcul în afara lanțului” este complet diferit de Ethereum. Pe Ethereum, trebuie doar să furnizați parametrii de intrare a tranzacției, iar rezultatele tranzacției sunt calculate și scoase la evidență de nodul Ethereum.

În plus, scriptul de blocare UTXO (Locking Script) este personalizabil. Puteți seta UTXO să fie „deblocat de către proprietarul unei anumite adrese Bitcoin”. . În tipul de tranzacție Pay-to-Script-Hash (P2SH), puteți adăuga un Script Hash în scriptul de blocare UTXO Cine poate trimite imaginea originală a scriptului corespunzătoare acestui Hash și să îndeplinească condițiile prestabilite din imaginea originală a scriptului? poți debloca UTXO. Scriptul Taproot pe care se bazează BitVM utilizează caracteristici similare cu P2SH.

Cum se declanșează scriptul Bitcoin

Aici folosim mai întâi P2PKH ca exemplu pentru a introduce metoda de declanșare a scriptului Bitcoin Numai prin înțelegerea metodei sale de declanșare putem înțelege Taproot și BitVM mai complexe. Numele complet al P2PKH este „Pay to Public Key Hash”. la fel ca ideea convențională de transfer Bitcoin.

În acest moment, nodul Bitcoin trebuie să confirme că cheia publică din scriptul de deblocare se potrivește cu hash-ul cheii publice specificate în scriptul de blocare prin UTXO se potrivesc reciproc.

În plus, în cadrul schemei P2PKH, după primirea tranzacției, nodul Bitcoin va îmbina scriptul de deblocare ScriptSig dat de utilizator cu scriptul de blocare ScriptPubkey al UTXO care urmează să fie deblocat și le va executa în mediul de execuție al script-ului BTC. Următoarea figură arată rezultatele îmbinării înainte de execuție:

Poate că cititorii nu cunosc mediul de execuție a scripturilor BTC, așa că aici îl vom prezenta pe scurt. În primul rând, scriptul BTC conține două elemente:

date și coduri operaționale. Aceste date și coduri de operare vor fi împinse în stivă în ordine de la stânga la dreapta și executate conform logicii specificate pentru a obține rezultatul final (detaliile despre ce este o stivă nu vor fi elaborate aici, cititorii pot conversa singuri).

Luând ca exemplu imaginea de mai sus, partea stângă este scriptul de deblocare ScriptSig încărcat de cineva, inclusiv semnătura sa digitală și cheia publică, în timp ce scriptul de blocare ScriptPubkey din partea dreaptă conține un cod operațional și un set de date de către creatorul UTXO atunci când generează UTXO (Nu trebuie să înțelegem semnificația fiecărui opcode aici, doar o înțelegere aproximativă).

Codurile DUP, HASH160, EQUALVERIFY și alte operațiuni din scriptul de blocare din dreapta din figura de mai sus sunt responsabile pentru hashing cheia publică transportată în scriptul de deblocare din stânga și pentru compararea acesteia cu hash-ul presetat al cheii publice în scriptul de blocare. Dacă cele două Dacă sunt egale, înseamnă că cheia publică încărcată în scriptul de deblocare se potrivește cu hash-ul presetat al cheii publice din scriptul de blocare, iar prima verificare este trecută.

Cu toate acestea, există o problemă. Conținutul script-ului de blocare UTXO este de fapt public pe lanț. numit de împărat". ” persoană. Prin urmare, după verificarea cheii publice și hash-ul cheii publice, este de asemenea necesar să se verifice dacă inițiatorul tranzacției este într-adevăr controlorul real al cheii publice, ceea ce necesită verificarea semnăturii digitale. Codul operațional CHECKSIG din scriptul de blocare este responsabil pentru verificarea semnăturii digitale.

Pentru a rezuma, în cadrul schemei P2PKH, scriptul de deblocare trimis de inițiatorul tranzacției conține cheia publică și semnătura digitală atunci când aceste condiții sunt îndeplinite, poate debloca UTXO fără probleme.

(Această imagine este dinamică: diagramă schematică a scriptului de deblocare a Bitcoin sub schema P2PKH

Sursa: https://learnmeabitcoin.com/technical/script)

Desigur, rețeaua Bitcoin acceptă mai multe tipuri de tranzacții, nu doar hash Pay to public key/public key, ci și P2SH (Pay to Script hash), etc. Totul depinde de modul în care este setat scriptul de blocare personalizat atunci când este creat UTXO. .

Trebuie remarcat aici că, în cadrul schemei P2SH, un Script Hash poate fi presetat în scriptul de blocare, iar scriptul de deblocare trebuie să trimită conținutul scriptului complet corespunzător Script Hash-ului. Nodurile Bitcoin pot executa acest script Dacă logica verificării cu semnături multiple este definită în acest script, efectul unui portofel cu semnături multiple poate fi obținut asupra lanțului Bitcoin.

Desigur, în cadrul schemei P2SH, creatorul UTXO trebuie să informeze persoana care deblochează UTXO în viitor conținutul scriptului corespunzător Script Hash-ului în prealabil, atâta timp cât ambele părți cunosc conținutul acestui Script, atunci putem implementa logică de afaceri mai complexă decât semnarea multiplă.

Trebuie remarcat aici că lanțul Bitcoin (blocul) nu înregistrează direct ce UTXO sunt asociate cu ce adrese, înregistrează doar ce hash de cheie publică/ce hash de script UTXO poate fi deblocat, dar folosim hash-ul/script-ul cheii publice. pentru a-l debloca, Hash poate calcula rapid adresa corespunzătoare (secțiunea afișată pe interfața portofelului arată ca niște caractere eronate).

Motivul pentru care putem vedea xx cantitate de Bitcoin sub adresa xx în exploratorul de blocuri și interfața portofel este pentru că exploratorul de blocuri și proiectul portofel vă ajută să analizați datele, să scanați toate blocurile și să blocați scriptul în funcție de hash-ul/script-ul cheii publice declarat în, calculează „adresa” corespunzătoare și apoi afișează câți Bitcoin sunt sub numele adresei xx.

Martor și Martor segregați

După ce înțelegem ideea de P2SH, suntem cu un pas mai aproape de Taproot, de care depinde BitVM. Dar înainte de asta, trebuie să înțelegem un concept important: Martor și Martor Segregat.

Revizuind scriptul de deblocare și scriptul de blocare menționate mai devreme, precum și procesul de deblocare UTXO, veți găsi o problemă: semnătura digitală a tranzacției este inclusă în scriptul de deblocare, iar scriptul de deblocare nu poate fi suprascris la generarea semnăturii ( parametrii utilizați pentru a genera semnătura nu pot fi incluși semnătura în sine), astfel încât semnătura digitală poate acoperi doar părți, altele decât scriptul de deblocare, adică poate fi asociată doar cu partea principală a datelor tranzacției și nu poate acoperi complet tranzacția date.

În acest fel, chiar dacă scriptul de deblocare a tranzacției este ușor manipulat de către intermediar, nu va afecta rezultatul verificării semnăturii. De exemplu, nodurile Bitcoin sau pool-urile de minerit pot introduce alte date în scriptul de deblocare al tranzacției, provocând modificări subtile în datele tranzacției fără a afecta verificarea semnăturii și rezultatele tranzacției. Aceasta este cunoscută sub numele de problema maleabilității tranzacției.

Dezavantajul acestui lucru este că, dacă intenționați să inițiați mai multe tranzacții succesive și există dependențe secvențiale (de exemplu, tranzacția 3 se referă la ieșirea tranzacției 2, iar tranzacția 2 se referă la rezultatul tranzacției 1), atunci tranzacții Este necesar să citați ID-ul (hash) al tranzacției anterioare. Orice intermediar, cum ar fi un pool de minerit sau un nod Bitcoin, poate regla fin conținutul scriptului de deblocare, astfel încât hash-ul după ce tranzacția este încărcat să fie inconsecvent cu ceea ce. Atunci, tranzacțiile multiple pe care le-ați creat în prealabil au Tranzacții legate secvențial vor deveni invalide.

De fapt, în soluțiile DLC bridge și BitVM2, tranzacțiile cu corelație secvențială vor fi construite în loturi, așa că scenariul menționat mai sus nu este neobișnuit.

Mai simplu spus, problema scalabilității tranzacției este că ID-ul tranzacției/hash-ul va include datele scriptului de deblocare atunci când îl calculează, iar intermediarii, cum ar fi nodurile Bitcoin, pot regla fin conținutul script-ului de deblocare, determinând ca ID-ul tranzacției să fie diferit de ceea ce se aștepta utilizatorul. De fapt, acesta este bagajul istoric lăsat de slaba considerație a Bitcoin în designul său timpuriu.

Ulterior, upgrade-ul Segregated Witness/SegWit decuplează complet ID-ul tranzacției și scriptul de deblocare. Scriptul de blocare UTXO care urmează upgrade-ului SegWit va seta un cod operațional numit „OP_0” în mod implicit, care servește ca marcaj, iar scriptul de deblocare corespunzător a fost redenumit din SigScript în Witness;

După respectarea regulilor SegWit, problema de scalabilitate a tranzacției va fi rezolvată în mod corespunzător și nu trebuie să vă faceți griji că datele tranzacției trimise către nodul Bitcoin sunt reglate fin. Desigur, nu trebuie să ne gândim prea complicat. Funcțiile P2WSH nu sunt în mod esențial diferite de P2SH menționate mai devreme. conținutul scriptului corespunzător hash-ului în lanț și executat.

Dar dacă conținutul scriptului pe care doriți să îl implementați este deosebit de mare și conține mult cod, scriptul complet nu poate fi transmis lanțului Bitcoin prin metode convenționale (fiecare bloc are o limită de dimensiune). Ce să fac? Acest lucru necesită utilizarea Taproot pentru a eficientiza conținutul scriptului din lanț, iar BitVM este o soluție complexă construită pe baza Taproot.

În următorul articol din „Apropierea BTC”, vom realiza o popularizare detaliată a Taproot, pre-semnare și alte tehnologii mai complexe legate de BitVM, așa că rămâneți pe fază!