Scris de: Chakra Research

Pe lângă soluția de expansiune nativă menționată în primul volum, o altă cale de expansiune pentru Bitcoin folosește un strat suplimentar de protocol peste Bitcoin, numit Layer 2. Cele mai critice două puncte ale soluției Layer 2 sunt legarea sigură în două sensuri și moștenirea securității consensului Bitcoin.

Sidechain

Originea conceptului sidechain poate fi urmărită până la „Enabling Blockchain Innovations with Pegged Sidechain” trimis de blockStream în 2014. Este un plan de expansiune relativ simplu.

Principiul de funcționare

Lanțul lateral este un blockchain care funcționează complet independent de lanțul principal. Are propriul protocol de consens și poate fi folosit ca domeniu experimental pentru inovarea lanțului principal. Când apare un incident malign în lanțul lateral, deteriorarea este complet limitată la lanțul lateral în sine și nu are impact asupra lanțului principal. Lanțul lateral poate folosi un protocol de consens TPS mai mare pentru a crește capacitățile de programare pe lanț și pentru a obține îmbunătățirea BTC.

Lanțul lateral poate realiza transferul de Bitcoin între diferite blockchain-uri prin bidirecționare sau peg unidirecțional. Desigur, de fapt, BTC poate rămâne doar în rețeaua Bitcoin, așa că avem nevoie de un mecanism de ancorare pentru a face lanțul lateral. BTC din lanț este conectat la BTC din rețeaua Bitcoin.

Peg unidirecțional cere utilizatorilor să trimită BTC pe rețeaua principală la o adresă indisponibilă pentru distrugere, iar apoi numărul corespunzător de BTC va fi obținut în lanțul lateral, dar procesul nu poate fi inversat. Two-way peg este o nouă actualizare la peg one-way, permițând BTC să se deplaseze înainte și înapoi între lanțul principal și lanțurile laterale. În loc să-l trimită la o adresă indisponibilă pentru distrugere, peg-ul bidirecțional va bloca BTC prin scripturi de control, cum ar fi multi-semnătură și menționează noi BTC pe lanțul lateral. Când utilizatorul dorește să se întoarcă la rețeaua principală, BTC-ul de pe lanțul lateral va fi ars și B TC-ul blocat inițial va fi eliberat pe rețeaua principală.

Implementarea peg-ului unidirecțional este mult mai simplă decât cea a peg-ului bidirecțional, deoarece nu este nevoie să gestionați starea relevantă în rețeaua Bitcoin, dar activele lanțului lateral generate prin peg-ul unidirecțional pot fi lipsite de valoare din cauza lipsa mecanismului de ancorare inversă.

Există diferite soluții și diferite niveluri de securitate pentru verificarea tranzacțiilor de blocare pe lanțul principal și a tranzacțiilor de ardere pe lanțul lateral. Cel mai simplu este să utilizați verificarea externă de către participanți cu semnături multiple, dar riscul de centralizare este mare. O opțiune mai bună este să utilizați SPV Proof pentru a realiza verificarea descentralizată. Desigur, deoarece rețeaua principală Bitcoin nu dispune de capabilitățile de programare necesare, verificarea SPV nu poate fi efectuată, iar alte metode pot fi alese doar, de obicei custodia cu mai multe semnături.

Întrebări și idei

Există două probleme principale pentru care lanțurile laterale sunt criticate:

Dependența activelor încrucișate de verificatori: Deoarece rețeaua principală Bitcoin nu este încă capabilă să implementeze contracte inteligente, transferul încrucișat al activelor nu poate fi procesat prin logica contractuală fără încredere Când treceți înapoi de la lanțul lateral la Bitcoin trebuie să se bazeze pe un grup de verificatori Pentru a finaliza operațiunea, există o presupunere de încredere și există riscul de fraudă.

Lanțul lateral nu poate moșteni securitatea lanțului principal: lanțul lateral rulează complet independent de rețeaua principală și nu poate moșteni securitatea rețelei principale Pot apărea evenimente precum reorganizarea blocurilor rău intenționate.

În acest sens, ideile lanțurilor laterale includ dependența de autoritate (tip de alianță), dependența de securitatea economică (PoS), dependența de mineri Bitcoin descentralizați (Merged Mining), dependența de modulele de securitate hardware (HSM), custodia fondului și lanțul lateral. pe Bitcoin Diferite roluri pot fi responsabile pentru producția de blocuri a lanțului, introducând astfel mecanisme de securitate mai complexe.

Introducere caz

Lichid

Prima formă de lanț secundar este lanțul lateral al alianței, în care mai multe entități selectate în prealabil servesc ca verificatori și sunt responsabile pentru custodia fondurilor rețelei principale și producția în bloc a lanțului lateral.

Liquid este reprezentantul lanțului lateral al alianței, cu 15 participanți care servesc ca verificatori. Metoda de gestionare a cheilor private nu este dezvăluită și sunt necesare 11 semnături pentru verificare. Blocurile din lanțul lateral Liquid sunt, de asemenea, întreținute în comun de 15 participanți. Lanțul de alianță cu un număr redus de noduri poate atinge un TPS mai mare și atinge obiectivele de extindere.

Abordarea lanțului lateral al alianței are riscuri de securitate centralizate semnificative.

Portaltoi (RSK)

RSK are, de asemenea, 15 noduri care servesc drept custozi de fonduri principale și sunt necesare doar 8 semnături pentru verificare. Diferența față de Liquid este că cheia cu semnături multiple este gestionată de modulul de securitate hardware HSM, iar instrucțiunea de peg-out este semnată în conformitate cu consensul PoW pentru a împiedica verificatorul care deține cheia să manipuleze direct fondurile escrow.

În ceea ce privește consensul lanțului lateral, RSK utilizează Merged Mining pentru a utiliza puterea de calcul a rețelei principale pentru a asigura securitatea tranzacțiilor pe lanțul lateral lanțul de a fi compromis. RSK a adus îmbunătățiri Merged Mining pentru a asigura securitatea lanțurilor laterale cu rate de hash scăzute. Adoptă o metodă conștientă de furcă pentru a efectua o intervenție de consens în afara lanțului asupra comportamentului de furcă și pentru a reduce probabilitatea de dublare a cheltuielilor.

Cu toate acestea, Merged Mining modifică stimulentele minerilor și intensifică riscurile MEV, ceea ce poate destabiliza în cele din urmă sistemul. Pe termen lung, Merged Mining poate crește centralizarea mineritului.

Stive

Stacks ancorează istoricul lanțului Stacks la Bitcoin prin trimiterea hash-ului de bloc al lanțului lateral la blocul Bitcoin rezista la cheltuieli duble.

sBTC introduce un nou token STX și un model de stimulare, folosind o abordare staking bridge care permite până la 150 de validatori mainnet. În așa-numita punte de miză, validatorii trebuie să mizeze jetoane STX pentru a obține permisiunea de a aproba depunerile și retragerile. Securitatea podului de gaj se bazează în mare măsură pe valoarea activelor gajate Când valoarea activelor gajate fluctuează violent, securitatea cross-chain-ului BTC este ușor deteriorată. Dacă valoarea activelor gajate este mai mică decât valoarea activelor încrucișate, validatorul are un stimulent să facă rău.

Există, de asemenea, câteva propuneri de sidechain care sunt discutate pe larg în comunitate.

Unitatea de lanț

Cea care a atras cea mai mare atenție este Drivechain-ul propus de Paul Sztorc în 2015. Tehnologiilor cheie din plan li s-au atribuit BIP 300 (mecanism peg) și BIP 301 (exploatare blind fuzionată). BIP 300 definește logica adăugării unui nou lanț lateral în detaliu Activarea unui nou lanț lateral este similară cu activarea unei furci moale prin semnalele minerului. BIP 301 permite minerilor Bitcoin să devină producători de blocuri sidechain fără a verifica conținutul specific al tranzacției.

Minerii Bitcoin sunt, de asemenea, responsabili pentru aprobarea tranzacțiilor de retragere poate vota pentru sau împotriva propunerii în orice moment. Odată ce o tranzacție de retragere depășește pragul (13150 de blocuri), tranzacția de retragere este executată și confirmată oficial de lanțul principal Bitcoin.

De fapt, minerii au control complet asupra fondurilor de pe Drivechain Dacă fondurile sunt furate, utilizatorii se pot salva doar prin UASF (furcătură soft activată de utilizator), dar este foarte dificil să se ajungă la un consens. În plus, poziția unică a minerilor în Drivechain exacerba riscurile MEV, așa cum a fost deja demonstrat în Ethereum.

Lanț spațial

Spacechain a adoptat o abordare diferită, folosind Perpetual 1 Way Peg (P1WP) Utilizatorii arde BTC pentru a obține jetoane pe Spacechain, sărind direct problema securității fondului. Acest token poate fi folosit doar pentru a bloca spațiul pe lanțul spațial la licitație și nu are nicio funcție de stocare a valorii.

Pentru a asigura securitatea lanțului lateral, Spacechain adoptă minarea de îmbinare oarbă. Alți utilizatori folosesc ANYPREVOUT (APO) pentru a licita public pentru a concura pentru dreptul de a construi blocuri bloc lateral. Cu toate acestea, lansarea Spacechain necesită sprijinul Covanent, iar comunitatea Bitcoin încă discută despre necesitatea unui soft furk pentru a adăuga opcode-ul Covanent.

În general, Spacechain poate realiza un lanț lateral cu aceleași proprietăți rezistente la descentralizare și cenzură ca și Bitcoin și mai multă programabilitate prin funcția de licitare pentru blocuri pe Bitcoin.

Softchain

Softchain este o propunere de lanț lateral 2wp propusă de autorul Spacechain Ruben Somsen. Utilizează mecanismul de consens PoW FP pentru a asigura securitatea lanțului lateral. În circumstanțe normale, nodul complet al Bitcoin trebuie doar să descarce antetul de bloc al softchain-ului și să verifice dovada lucrului. Când apare o furcătură, descărcați blocul orfan și angajamentul setat UTXO corespunzător pentru a verifica validitatea blocului.

Pentru mecanismul 2wp, în timpul peg-in-ului, se creează o tranzacție de depunere pe lanțul principal, iar tranzacția din lanțul principal este referită pe softchain pentru a obține fonduri în timpul peg-out-ului, se creează o tranzacție de retragere pe softchain; tranzacția este menționată în lanțul principal pentru a recupera fonduri, iar procesul de retragere trebuie să aștepte o perioadă lungă de provocare înainte de a putea fi finalizat. Mecanismele specifice de peg-in și peg-out necesită suport moale pentru furcă, așa că soluția se numește Softchain.

Soluția Softchain impune costuri suplimentare de verificare asupra nodurilor complete ale rețelei principale Bitcoin. Divizarea consensului Softchain poate afecta realizarea consensului rețelei principale și poate deveni un posibil mijloc de atac asupra rețelei principale Bitcoin.

Rețeaua fulgerului

Rețeaua Lightning a lansat o carte albă în 2015 și a fost lansată oficial în 2018. Ca protocol de plată Layer 2 p2p pe Bitcoin, își propune să transfere un număr mare de tranzacții cu cantități mici, de înaltă frecvență, către procesarea în afara lanțului mult timp, a fost considerată cea mai avansată tehnologie din rețeaua Bitcoin.

modul de bază

Implementarea Lightning Network este inseparabilă de mai multe module importante din Bitcoin, care împreună asigură securitatea tranzacțiilor Lightning Network.

Prima este tranzacția presemnată. Tranzacțiile presemnate au devenit sigure și disponibile numai după upgrade-ul SegWit. SegWit separă semnăturile de restul datelor privind tranzacțiile, rezolvând probleme precum potențialele dependențe circulare, manipularea tranzacțiilor de la terți și manipularea tranzacțiilor de la a doua parte. Securitatea calculului din cadrul lanțului Lightning Network este garantată de angajamentul irevocabil dat de cealaltă parte, iar acest angajament se realizează prin tranzacții presemnate. După ce a primit tranzacția presemnată dată de cealaltă parte, utilizatorul poate transmite tranzacția către lanț în orice moment pentru a finaliza îndeplinirea promisiunii.

Al doilea este multi-semnătura. Transferurile frecvente de fonduri în afara lanțului între două părți necesită un transportator. Acest operator de transport solicită ambelor părți să mențină anumite drepturi de control, deci sunt necesare semnături multiple, în general, se utilizează 2/2 semnături multiple, ceea ce asigură transferul de fonduri trebuie să fie efectuată cu acordul reciproc al ambelor părți.

Cu toate acestea, 2/2 multi-semnătură va cauza probleme de viață, adică dacă cealaltă parte nu cooperează, utilizatorul nu poate transfera niciun bun de la adresa cu mai multe semnături, ducând la pierderea fondurilor inițiale. Blocările de timp pot rezolva problema vieții Prin pre-semnarea unui contract cu o blocare de timp pentru a returna fondurile, se poate asigura că, chiar dacă o parte devine inactivă, cealaltă parte poate recupera fondurile inițiale.

În cele din urmă, există blocarea hash, care poate conecta mai multe canale de stare și poate construi o rețea. Imaginea originală a hash-ului va fi folosită ca mediu de comunicare pentru a coordona funcționarea corectă a mai multor entități.

Rulați procesul

canal cu două sensuri

Ambele părți care utilizează Lightning Network pentru a efectua tranzacții trebuie să deschidă mai întâi un canal de plată bidirecțional pe Bitcoin Ambele părți pot efectua orice număr de tranzacții în afara lanțului pentru a finaliza decontarea și a închide culoarul de plată.

Mai exact, implementarea canalelor de plată presupune următorii pași cheie:

1. Creați o adresă cu semnături multiple. Ambele părți ale canalului trebuie mai întâi să creeze o adresă cu semnături multiple 2 din 2 ca adresă de blocare a fondului canalului. Fiecare parte deține o cheie privată de semnătură și oferă propria sa cheie publică.

2. Inițializați canalul. Ambele părți difuzează o tranzacție pe lanț și blochează o anumită cantitate de Bitcoin în adresa cu mai multe semnături ca fonduri inițiale ale canalului. Această tranzacție se numește tranzacția „ancoră” a canalului.

3. Actualizați starea canalului. La efectuarea unei plăți în cadrul canalului, ambele părți actualizează starea canalului prin schimbul de tranzacții presemnate. Fiecare actualizare va genera o nouă „tranzacție de angajament”, reprezentând starea actuală a alocării fondului. Tranzacția de angajament are două rezultate, corespunzătoare cotelor de fond ale ambelor părți.

4. Difuzați cea mai recentă stare. Oricare dintre părțile canalului poate transmite în orice moment cea mai recentă tranzacție de angajament către blockchain pentru a-și retrage partea din fonduri. Pentru a împiedica cealaltă parte să difuzeze vechiul statut, fiecare tranzacție de angajament are o „tranzacție de pedeapsă” corespunzătoare. Dacă cealaltă parte trișează, puteți obține toate fondurile celeilalte părți.

5. Închide canalul. Când două părți decid să închidă un canal, ele pot coopera pentru a genera o „tranzacție de decontare” care transmite starea finală a distribuției fondului către blockchain. În acest fel, fondurile blocate în adresa cu mai multe semnături sunt eliberate înapoi la adresele personale ale ambelor părți.

6. Arbitraj în lanț. Dacă cele două părți nu pot ajunge la un acord la închiderea canalului, oricare dintre părți poate difuza unilateral cea mai recentă tranzacție de angajament și poate începe procesul de arbitraj în lanț. Dacă nu există obiecții într-o anumită perioadă de timp (cum ar fi 1 zi), fondurile vor fi trimise ambelor părți în funcție de alocarea tranzacției angajate.

rețeaua de plată

Canalele de plată pot fi conectate între ele pentru a forma o rețea, care acceptă rutarea multi-hop, implementată prin HTLC. HTLC folosește blocarea hash ca condiție directă și plata semnăturii cu blocarea temporală ca condiție de rezervă. Utilizatorii pot interacționa în jurul imaginii originale a hashului înainte de expirarea blocării timpului.

Atunci când nu există un canal direct între doi utilizatori, plata poate fi finalizată cu ajutorul HTLC între routere. Preimaginea hash R joacă un rol cheie în întregul proces, asigurând atomicitatea plății. În același timp, blocarea de timp a HTLC este setată să scadă pe parcurs, asigurându-se că fiecare hop are suficient timp pentru a procesa și a trimite plata.

Probleme

În esență, Lightning Network eludează ipoteza de încredere externă a punerii în punte a activelor prin canalele de stare p2p, folosind în același timp scripturi de blocare a timpului pentru a oferi garanția finală a activelor și pentru a oferi protecție împotriva erorilor. Atunci când cealaltă parte își pierde activitatea și nu cooperează, retragerea unilaterală poate fi finalizată. Prin urmare, Lightning Network are o valoare mare în scenariile de plată, dar are și multe limitări, inclusiv:

• Limită de capacitate a canalului. Capacitatea canalului de plată din rețeaua Lightning este limitată de fondurile inițiale blocate și nu poate suporta plăți mari care depășesc capacitatea canalului. Acest lucru poate limita anumite scenarii de aplicare, cum ar fi tranzacționarea cu mărfuri.

• Online și sincronizat. Pentru a primi și a transmite plăți în timp util, nodurile Lightning Network trebuie să rămână online. Dacă un nod este offline pentru o perioadă lungă de timp, poate pierde unele actualizări ale stării canalului, ceea ce face ca starea să nu fie sincronizată. Aceasta poate fi o provocare pentru utilizatorii individuali și dispozitivele mobile și, de asemenea, crește costul operațiunilor nodurilor.

• Managementul lichiditatii. Eficiența de rutare a rețelei Lightning se bazează pe distribuția de lichiditate a canalelor. Dacă fondurile sunt distribuite inegal, unele căi de plată pot eșua, afectând experiența utilizatorului. Gestionarea soldului de lichiditate al canalului necesită anumite costuri tehnice și de capital.

• Încălcarea confidențialității. Pentru a găsi căile de plată disponibile, algoritmul de rutare al Lightning Network necesită un anumit nivel de cunoaștere a capacității canalului și a informațiilor de conectivitate. Acest lucru poate dezvălui confidențialitatea unor utilizatori, cum ar fi distribuția de fonduri, contrapărțile etc. Deschiderea și închiderea canalelor de plată poate expune, de asemenea, informații despre participanții relevanți.

RGB

Ideea originală a protocolului RGB a fost inspirată de conceptele de verificare și etanșare unică pe partea clientului propuse de Peter Todd. Acesta a fost propus de Giacomo Zucco în 2016. Este un protocol de al doilea strat Bitcoin scalabil și care păstrează confidențialitatea. .

Ideea principală

Verificarea clientului

Procesul de verificare a blockchain-ului este de a difuza blocurile compuse din tranzacții către toți, permițând fiecărui nod să calculeze tranzacțiile din bloc și să finalizeze verificarea. Acest lucru creează de fapt un bun public, adică nodurile din rețea ajută fiecare persoană care trimite o verificare completă a tranzacției, iar utilizatorii oferă BTC ca taxă de gestionare ca stimulent pentru a ajuta la verificare. Verificarea la nivel de client este mai centrată pe persoană. Verificarea de stat nu este efectuată la nivel global, ci este verificată de persoanele care participă la anumite tranziții de stat sarcina asupra nodurilor și îmbunătățește scalabilitatea.

Sigiliu de unica folosinta

Există un pericol ascuns în tranziția de la un punct la altul. Sigilarea de unică folosință este propusă pentru a rezolva această problemă. Folosește un obiect special care poate fi folosit o singură dată pentru a se asigura că nu se produce dublarea cheltuielilor și pentru a îmbunătăți securitatea. UTXO al Bitcoin este cel mai potrivit obiect sigilat unic, garantat de mecanismul de consens al Bitcoin și puterea de calcul a întregii rețele, astfel încât activele RGB pot moșteni securitatea Bitcoin.

Crypto Promise

Sigiliul unic trebuie combinat cu angajamentul de criptare pentru a se asigura că utilizatorul cunoaște starea de tranziție și pentru a evita apariția atacurilor cu cheltuieli duble. Așa-zisul angajament este de a informa pe ceilalți că ceva s-a întâmplat și nu poate fi modificat ulterior, dar nu este nevoie să expunem evenimente specifice până în momentul în care este necesară verificarea. Putem folosi o funcție hash pentru a face un angajament. În RGB, conținutul angajamentului este tranziția de stat. Prin cheltuielile UTXO, destinatarul activului RGB va primi semnalul de transfer de stat și apoi va verifica angajamentul față de datele specifice transmise în afara lanțului de către cheltuitor. activ.

procesul de lucru

RGB folosește consensul Bitcoin pentru a asigura securitatea dublei cheltuieli și rezistența la cenzură, iar toate verificările transferurilor de stat sunt transferate în afara lanțului și sunt verificate doar de clientul care acceptă plata.

Pentru emitentul de active RGB, un contract RGB trebuie creat prin inițierea unei tranzacții, în care angajamentul de informații specific va fi stocat în scriptul OP_RETURN al unei anumite condiții de cheltuieli în tranzacția Taproot.

Când deținătorul unui activ RGB dorește să cheltuiască, trebuie să obțină informații relevante de la destinatarul activului, să creeze o tranzacție RGB, să angajeze detaliile tranzacției RGB și să plaseze valoarea angajamentului în UTXO specificat de destinatarul activului. . și emiteți o tranzacție care cheltuiește UTXO inițial și creează UTXO specificat de destinatar. Când destinatarul activului observă că UTXO-ul care a stocat inițial activul RGB este cheltuit, el poate verifica validitatea tranzacției RGB prin angajamentul din tranzacția Bitcoin Odată ce verificarea este valabilă, el crede că a primit într-adevăr Activ RGB.

Pentru destinatarul activelor RGB, plătitorul trebuie să furnizeze regulile de tranziție inițiale și de stat ale contractului, tranzacțiile Bitcoin utilizate pentru fiecare transfer, tranzacțiile RGB efectuate de fiecare schimb Bitcoin și validitatea fiecărei tranzacții Bitcoin. verificat de clientul destinatarului pe baza acestor date, verifică valabilitatea tranzacției RGB. Printre acestea, UTXO al Bitcoin este folosit ca un container pentru a salva starea contractului RGB Istoricul de transfer al fiecărui contract RGB poate fi exprimat ca un grafic aciclic direcționat Destinatarul activului RGB poate obține doar informațiile legate de RGB bun pe care îl deține și nu poate accesa alte sucursale.

Avantaje și dezavantaje

Verificare ușoară

În comparație cu verificarea completă a blockchain-ului, protocolul RGB reduce foarte mult costul verificării. Utilizatorii nu trebuie să parcurgă toate blocurile istorice pentru a obține cel mai recent statut, ci trebuie doar să sincronizeze înregistrările istorice legate de activele pe care le primesc pentru a le verifica. eficacitatea tranzacţiei.

Această verificare ușoară face tranzacțiile peer-to-peer mai ușoare, eliminând și mai mult nevoia de furnizori de servicii centralizați și crescând nivelul de descentralizare.

Scalabilitate

Protocolul RGB moștenește securitatea Bitcoin doar prin angajamentul unui hash. Prin scripturile Taproot, nu există aproape niciun consum de spațiu suplimentar pe lanțul Bitcoin, ceea ce face posibilă programarea complexă a activelor. Datorită utilizării UTXO ca container, protocolul RGB are concurență naturală a activelor RGB pe diferite ramuri de transfer nu se vor bloca reciproc și pot fi cheltuite în același timp.

Confidențialitate

Spre deosebire de protocoalele generale, doar destinatarul activelor RGB poate obține statutul istoric de transfer al activelor RGB Odată ce cheltuielile sunt finalizate, nu se poate obține statutul viitor de transfer, ceea ce garantează în mod semnificativ confidențialitatea utilizatorului. Nu există nicio corelație între tranzacția de active RGB și transferul Bitcoin UTXO, iar alții nu pot obține urme ale tranzacțiilor RGB pe lanțul Bitcoin.

În plus, RGB acceptă și cheltuieli oarbe, iar plătitorul nu poate ști în ce UTXO vor fi plătite activele RGB, îmbunătățind și mai mult confidențialitatea și sporind rezistența la cenzură.

insuficient

Când activele RGB își schimbă mâinile de mai multe ori, noii utilizatori care primesc active vor fi forțați să verifice un istoric de transfer lung, ceea ce duce la o sarcină de verificare mai mare, timpul de verificare poate fi mai lung și capacitatea de a confirma rapid se pierde. Pentru nodurile care rămân în rulare în blockchain, deoarece cea mai recentă stare este întotdeauna sincronizată, timpul de primire a transferului rapid al stării de verificare a noii zone este limitat de fiecare dată.

Comunitatea discută despre posibilitatea reutilizarii calculelor istorice, iar recursiv ZK Proof are posibilitatea de a realiza o verificare constantă a stării de timp și dimensiune.

Rulează

Prezentare generală

Rollup este cea mai bună soluție de expansiune la care a ajuns ecosistemul Ethereum după ani de explorare, de la canalele de stat la Plasma și în sfârșit la Rollup.

Rollup este un blockchain independent care colectează tranzacții în afara lanțului Bitcoin, împachetează tranzacții multiple într-un lot și îl execută și transmite datele și angajamentele de stare ale acestui lot lanțului principal, realizând tranzacții în afara lanțului și actualizări de stare. Pentru a obține o expansiune maximă, Rollup utilizează de obicei un secvențior centralizat în această etapă pentru a îmbunătăți eficiența execuției fără a pierde securitatea, deoarece securitatea este garantată prin verificarea tranzițiilor de stare Rollup pe lanțul principal.

Pe măsură ce soluția Rollup a ecosistemului Ethereum se maturizează, ecosistemul Bitcoin a început și el să experimenteze cu Rollup. Cu toate acestea, cea mai critică diferență dintre Bitcoin și Ethereum este lipsa capacităților de programare și incapacitatea de a efectua calculele necesare pentru a construi Rollup pe lanț.

Clasificare

În funcție de diferitele metode de verificare a transferului de stat, Rollup poate fi împărțit în două categorii majore, Optimistic Rollup și Validity Rollup (ZK Rollup).

Optimistic Rollup adoptă o metodă de verificare optimistă În timpul perioadei de dispută după trimiterea fiecărui lot de tranzacții, oricine poate verifica datele din afara lanțului, poate ridica obiecții la loturile de tranzacții problematice, poate trimite dovada de fraudă la lanțul principal și poate pierde Sequencerul. Dacă nu există o dovadă validă a fraudei după perioada de dispută, lotul de tranzacții este considerat valabil și actualizarea stării este confirmată pe lanțul principal.

Validity Rollup folosește Validity Proof pentru a finaliza verificarea, iar Sequencer folosește un algoritm de verificare a cunoștințelor zero pentru a genera o dovadă concisă a validității pentru fiecare lot de tranzacții, care demonstrează că transferul de stare al lotului este corect pentru fiecare actualizare lanțul principal dovada de valabilitate, lanțul principal verifică dovada și apoi înțelege și confirmă actualizarea stării.

Avantajul Optimistic Rollup este că este relativ simplu de implementat și necesită mai puține modificări ale lanțului principal. Dar este nevoie de mai mult pentru a confirma tranzacțiile (în funcție de perioada de obiecție) și necesită o disponibilitate mai mare a datelor. Validitatea Tranzacțiile cumulate sunt confirmate rapid, nu se bazează pe perioade de obiecție, iar datele tranzacțiilor pot rămâne private, dar generarea și verificarea dovezilor fără cunoștințe necesită o suprafață de calcul mare.

Celestia a propus, de asemenea, conceptul unui rollup suveran. Datele de tranzacție ale pachetului sunt publicate într-un blockchain de nivel DA dedicat, care este responsabil pentru disponibilitatea datelor, iar pachetul suveran în sine este responsabil de execuție și decontare.

Explorează și discută

Rollup pe Bitcoin este încă în fazele sale incipiente Din cauza diferențelor dintre modelul de contabilitate și limbajul de programare și Ethereum, este dificil să copiați în mod direct experiența practică a Ethereum.

Suveranitate Rollup

Pe 5 martie 2023, Rollkit a fost anunțat ca fiind primul cadru care acceptă pachetele suverane Bitcoin Constructorii de pachete suverane pot publica date despre disponibilitate pe Bitcoin prin Rollkit.

Rollkit este inspirat de Ordinals și publică date prin tranzacții Taproot. O tranzacție standard Taproot prin mempool-ul public poate conține până la 390 KB de date, iar o tranzacție Taproot non-standard emisă direct de un miner poate conține aproape 4 MB de date arbitrare.

Sarcina reală a Rollkit este de a oferi o interfață pentru Rollup suveran pentru a citi și scrie date pe Bitcoin, pentru a oferi servicii middleware clienților și pentru a transforma Bitcoin într-un strat DA.

Ideea unui rollup suveran a fost întâmpinată cu mult scepticism, mulți oponenți susținând că un rollup suveran pe Bitcoin nu este altceva decât utilizarea Bitcoin ca buletin și complet incapabil să moștenească securitatea Bitcoin. De fapt, dacă trimiteți doar date de tranzacție către Bitcoin, puteți doar îmbunătăți vii, adică toți utilizatorii pot obține datele corespunzătoare pentru verificare prin Bitcoin, dar securitatea poate fi definită doar de Rollup-ul suveran și nu poate fi moștenită. În plus, spațiul de blocare este foarte important pentru Bitcoin, iar trimiterea datelor complete asupra tranzacțiilor poate să nu fie o decizie bună.

OP Rollup și Validity Rollup

Deși multe proiecte Bitcoin din al doilea strat se numesc ZK Rollup, care este în esență mai aproape de un Rollup OP, dar implică tehnologia Validity Proof în proces, capacitățile de programare ale Bitcoin nu sunt încă suficiente pentru a susține verificarea directă Validity Proof.

În prezent, setul de coduri operaționale Bitcoin este foarte limitat și nici măcar nu poate calcula în mod direct multiplicarea. Verificarea Validity Proof necesită extinderea codurilor operaționale și se bazează în mare măsură pe implementarea contractelor recursive. Cele discutate în prezent în comunitate includ OP_CAT, OP_CHECKSIG. OP_TXHASH etc. Desigur, dacă am putea adăuga direct un OP_VERIFY_ZKP, poate nu am avea nevoie de alte modificări, dar acest lucru este, evident, puțin probabil. În plus, limitările privind dimensiunea stivei împiedică, de asemenea, eforturile de a verifica Validity Proof în scripturile Bitcoin și sunt explorate multe încercări.

Deci, cum funcționează Validity Proof? Majoritatea proiectelor publică loturile statediff și Validity Proof ale tranzacțiilor pe Bitcoin sub formă de inscripții și folosesc BitVM pentru o verificare optimistă. BitVM Bridge înlocuiește soluția tradițională cu semnături multiple The Bridge Operator va forma o alianță de N persoane pentru a programa depunerile utilizatorilor. Înainte ca utilizatorii să efectueze o depunere, alianța va trebui să presemneze UTXO-ul care urmează să fie generat pentru a se asigura că depozitul poate fi colectat doar de către Operator. După obținerea pre-semnăturii, BTC va fi blocat la o adresă Taproot cu semnături multiple N/N.

Atunci când un utilizator emite o solicitare de retragere, Rollup va trimite Dovada de valabilitate cu retragere Root către lanțul Bitcoin. Operatorul va satisface mai întâi nevoile utilizatorului de retragere din propriul buzunar, apoi va verifica validitatea prin contractul BitVM. Dacă fiecare Operator consideră că certificatul este valabil, Operatorul va fi rambursat prin semnătură multiplă, atâta timp cât cineva consideră că există fraudă, se va desfășura un proces de contestare, iar partea greșită va fi tăiată.

Acest proces este de fapt același cu OP Rollup Ipoteza de încredere este 1/N Atâta timp cât un verificator este sincer, protocolul este sigur.

Cu toate acestea, pot exista dificultăți în implementarea tehnică a acestei soluții. În proiectul OP Rollup al Ethereum, Arbitrum a fost dezvoltat de mulți ani, iar actualul Fraud Proof este încă trimis de noduri autorizate, Optimism a anunțat abia recent că acceptă Fraud Proof, ceea ce arată cât de dificil este de implementat.

În ceea ce privește operațiunea presemnată în podul BitVM, cu sprijinul Bitcoin Covanent, aceasta poate fi implementată mai eficient, care încă așteaptă consensul comunității.

În ceea ce privește atributele de securitate, prin transmiterea hash-ului de bloc Rollup la Bitcoin, se obține rezistența la reorganizare și dublarea cheltuielilor, iar utilizarea Optimistic Bridge aduce o presupunere de securitate 1/N Cu toate acestea, rezistența la cenzură a podului poate încă așteptați dezvoltarea ulterioară.

Concluzie: Stratul 2 nu este un panaceu

Privind atât de multe soluții de Strat 2, putem descoperi cu ușurință că fiecare soluție este limitată în sarcinile pe care le poate îndeplini. În anumite ipoteze de încredere, efectele pe care le poate obține stratul 2 depind în mare măsură de stratul 1, adică capacitățile native ale Bitcoin.

Fără upgrade-uri SegWit și time locks, Lightning Network nu poate fi construită cu succes fără upgrade-uri Taproot, angajamentele RGB nu pot fi trimise cu succes fără OP_CAT și alte Covanent, Validity Rollup pe Bitcoin nu poate fi construit cu succes;

Mulți Bitcoin Maxi cred că Bitcoin nu ar trebui să fie schimbat și că nu ar trebui adăugate funcții noi Toate defectele ar trebui rezolvate prin Stratul 2. Acest lucru nu este un panaceu. Avem nevoie de un Layer 1 mai puternic pentru a construi un Layer 2 mai sigur, eficient și scalabil.

În articolul următor, vom introduce încercări de a îmbunătăți programabilitatea pe Bitcoin, așa că rămâneți pe fază.