Autor: Chakra Traducere: 0xjs@金财经

Există multe căi către scalarea Bitcoin Prima parte a seriei noastre de articole a descris deja una dintre căile „Bitcoin native scaling soluții”. Cel mai important aspect al soluției cu două straturi este puntea bidirecțională sigură și moștenirea securității consensului Bitcoin.

lanț lateral

Conceptul de sidechain datează din 2014, când Blockstream a prezentat „Enabling Blockchain Innovation with Pegged Sidechains”. Reprezintă o metodă de scalare relativ simplă.

Cum funcționează lanțul lateral?

Un lanț lateral este un blockchain care funcționează independent de lanțul principal, are propriul protocol de consens și poate servi drept teren de testare pentru inovarea lanțului principal. Când apare un eveniment advers pe lanțul lateral, deteriorarea este limitată complet la lanțul lateral în sine, fără nici un impact asupra lanțului principal. Sidechains-urile pot adopta protocoale de consens cu TPS (tranzacții pe secundă) mai ridicate, pot îmbunătăți programabilitatea în lanț și pot facilita funcționalitatea îmbunătățită a BTC.

Sidechain-urile pot realiza transferul de Bitcoin între diferite blockchain-uri prin cheie bidirecționale sau peg unidirecționale. Dar, în realitate, BTC poate locui numai pe rețeaua principală Bitcoin, așa că este necesar un mecanism de ancorare pentru a lega BTC pe lanțul lateral cu BTC pe rețeaua principală Bitcoin.

Peg-urile unidirecționale necesită utilizatorilor să trimită BTC de pe rețeaua principală la o adresă indisponibilă pentru distrugere și apoi să bată o cantitate echivalentă de BTC pe sidechain, dar acest proces este ireversibil. Șuruburile cu două direcții reprezintă o îmbunătățire a șuruburilor unidirecționale, permițând BTC să se deplaseze înainte și înapoi între lanțul principal și lanțurile laterale. În loc să fie distrus prin trimiterea la o adresă indisponibilă, un peg bidirecțional blochează BTC prin multi-semnături sau alte scripturi de control, batând noi BTC pe sidechain. Când utilizatorul dorește să se întoarcă la rețeaua principală, BTC-ul de pe lanțul lateral va fi distrus, iar BTC-ul blocat inițial va fi eliberat pe rețeaua principală.

Implementarea unui peg unidirecțional este mult mai simplă decât a unui peg bidirecțional, deoarece nu necesită gestionarea stării relevante pe rețeaua principală Bitcoin. Cu toate acestea, activele sidechain create prin cheie unidirecționale pot fi lipsite de valoare, deoarece le lipsește un mecanism de fixare inversă.

Există diferite scheme și niveluri de securitate pentru verificarea tranzacțiilor de blocare pe lanțul principal și tranzacții de ardere pe lanțul lateral. Cea mai simplă metodă este verificarea externă prin participanți cu semnături multiple, dar aceasta implică riscuri mari de centralizare. O opțiune mai bună este să utilizați dovezile SPV pentru verificarea descentralizată. Cu toate acestea, deoarece rețeaua principală Bitcoin nu dispune de capabilitățile de programare necesare pentru a efectua verificarea SPV, trebuie utilizate alte metode, de obicei escrow cu mai multe semnături.

Probleme și metode

Principalele critici la adresa sidechain-urilor includ:

1. Activele încrucișate se bazează pe verificatori: deoarece rețeaua principală Bitcoin încă nu poate implementa contracte inteligente, transferurile de active încrucișate nu pot fi gestionate prin logica contractuală fără încredere. Returnarea activelor dintr-un sidechain la Bitcoin se bazează pe un set de validatori, introducând ipoteze de încredere și riscuri de fraudă.

2. Lanțurile laterale nu pot moșteni securitatea lanțului principal: deoarece lanțurile laterale rulează complet independent de rețeaua principală, ele nu pot moșteni securitatea rețelei principale, ceea ce poate duce la reorganizarea blocurilor rău intenționate.

Pentru a rezolva aceste probleme, sidechain-urile au adoptat metode, inclusiv bazarea pe instituții autorizate (federație), securitate economică (PoS), mineri Bitcoin descentralizați (mining combinat) și module de securitate hardware (HSM). Custodia fondurilor pe Bitcoin și producția de blocuri pe sidechains pot fi gestionate de diferite roluri, introducând mecanisme de securitate mai complexe.

studiu de caz

Lichid

Una dintre cele mai timpurii forme de sidechain a fost sidechain-urile federate, care s-au bazat pe un grup preselectat de entități pentru a servi drept validatori responsabili de custodia activelor din rețeaua principală și de generarea de blocuri pe sidechain.

Liquid este un exemplu clasic de sidechain federat, cu 15 părți acționând ca validatori. Gestionarea cheii private nu este publică, iar verificarea necesită 11 din 15 semnături. Producția de blocuri pe lanțul lateral Liquid este, de asemenea, întreținută de acești 15 participanți. Numărul mai mic de noduri din această federație are ca rezultat tranzacții pe secundă (TPS) mai mari, atingând astfel obiectivele de scalabilitate, iar principala sa zonă de aplicare este DeFi.

Cu toate acestea, modelul sidechain federat are riscuri semnificative de securitate de centralizare.

Portaltoi (RSK)

RSK este, de asemenea, gestionat de 15 noduri care sunt responsabile pentru găzduirea fondurilor principale ale rețelei, iar verificarea necesită doar 8 semnături. Spre deosebire de Liquid, cheile cu semnături multiple ale RSK sunt gestionate de un Modul de securitate hardware (HSM), iar instrucțiunile de cârlig sunt semnate pe baza consensului Proof-of-Work (PoW), împiedicând validatorii cu acces cheie să manipuleze direct fondurile escrow.

În ceea ce privește consensul în lanțul lateral, RSK adoptă minerit fuzionat și utilizează puterea de calcul a rețelei principale pentru a asigura securitatea tranzacțiilor în lanțul lateral. atacuri asupra lanțului lateral. RSK s-a îmbunătățit pe baza extragerii combinate. Prin conștientizarea furcii, efectuează o intervenție de consens în afara lanțului asupra comportamentului furcii, asigurând astfel securitatea lanțurilor laterale în condiții de putere de calcul scăzută și reducând posibilitatea atacurilor de dublu-cheltuire.

Cu toate acestea, mineritul fuzionat modifică stimulentele minerilor, crește riscul valorii extractibile de către mineri (MEV) și are potențialul de a destabiliza sistemul. În timp, mineritul fuzionat poate crește centralizarea mineritului.

Stive

Stacks atinge aceeași finalitate ca și Bitcoin, ancorând istoria lanțului său la Bitcoin, trimițând hash-uri ale blocurilor sale sidechain în blocuri Bitcoin. Furcăturile în stive pot apărea numai atunci când Bitcoin însuși se furcă, făcându-l mai rezistent la atacurile duble.

sBTC introduce un nou model de token și stimulent care utilizează o punte de staking care permite până la 150 de validatori mainnet. Validatorii trebuie să mizeze jetoane STX pentru a avea acces la depozitele și retragerile aprobate. Securitatea unui pod de staking depinde în mare măsură de valoarea activelor gajate, ceea ce prezintă un risc pentru securitatea inter-lanțului BTC în perioadele de fluctuații semnificative ale prețului activelor gajate.

Alte propuneri de sidechain sunt în prezent discutate pe larg în comunitate.

Unitatea de lanț

Cea mai notabilă dintre acestea este propunerea Drivechain a lui Paul Sztorc din 2015, care a împărțit tehnologiile cheie în BIP 300 (Mecanism Peg) și BIP 301 (Blind Merge Mining). BIP 300 definește logica pentru adăugarea de noi sidechain-uri, similar cu activarea noilor sidechain-uri prin semnale miner (cum ar fi soft forks). BIP 301 permite minerilor Bitcoin să devină producători de blocuri pe sidechain fără a verifica detaliile specifice ale tranzacțiilor.

Minerii Bitcoin sunt, de asemenea, responsabili pentru aprobarea tranzacțiilor de retragere. Ei inițiază o propunere de retragere prin crearea unei ieșiri OP_RETURN în tranzacția coinbase a blocului pe care l-au extras. Alți mineri pot vota apoi propunerea susținând sau opunându-i în fiecare bloc pe care îl minează. Odată ce o tranzacție de retragere depășește pragul (13.150 de blocuri), aceasta este executată și confirmată pe lanțul principal de Bitcoin.

De fapt, minerii au control complet asupra fondurilor de pe Drivechain. Dacă fondurile sunt furate, utilizatorii se pot salva numai prin intermediul soft forks activate de utilizator (UASF), despre care este dificil să se ajungă la un consens. În plus, poziția unică a minerilor în Drivechain crește riscul MEV, așa cum a fost demonstrat în Ethereum.

Lanț spațial

Spacechain adoptă o abordare diferită, folosind o cheie permanentă unidirecțională (P1WP), în care utilizatorii distrug BTC pentru a obține jetoane pe Spacechain, ocolind complet problema securității fondului. Aceste jetoane sunt folosite doar pentru a licita pentru spațiu de bloc pe Spacechain și le lipsește orice funcționalitate de stocare a valorii.

Pentru a asigura securitatea sidechain-ului, Spacechain folosește oarbă merge mining, în care utilizatorii licitează public pentru dreptul de a construi blocuri folosind ANYPREVOUT (APO). Minerii Bitcoin trebuie să trimită doar anteturile blocurilor Spacechain în propriile blocuri fără a valida blocurile sidechain. Cu toate acestea, lansarea Spacechain necesită suport Bitcoin pentru Covenants, iar comunitatea Bitcoin încă dezbate dacă este necesară un soft fork pentru a adăuga opcode Covenant.

În general, Spacechain își propune să realizeze un sidechain care este la fel de descentralizat și rezistent la cenzură ca Bitcoin, sporind în același timp programabilitatea prin funcția sa de licitație bloc.

Softchain

Softchain este o altă propunere de lanț lateral bidirecțional (2wp) de către Ruben Somsen care utilizează mecanismul de consens PoW FP pentru a securiza lanțul lateral. În circumstanțe normale, nodurile complete Bitcoin trebuie doar să descarce antetul blocului Softchain pentru a verifica dovada lucrului. Dacă apare o furcă, ei descarcă blocul orfan și setul de angajamente UTXO corespunzător pentru a verifica validitatea blocului.

Pentru mecanismul 2wp, atunci când peg-ul este transferat, va fi creată o tranzacție de depozit pe lanțul principal, iar Softchain-ul se va referi la această tranzacție în lanț principal pentru a obține fonduri când peg-ul este transferat, va fi creată o tranzacție de retragere pe Softchain, iar lanțul principal va cita această tranzacție pentru a retrage BTC după o perioadă mai lungă de provocare. Mecanismele specifice de agățare de transfer în și transfer în afara necesită suport moale pentru furcă, așa că propunerea se numește Softchain.

Propunerea Softchain adaugă costuri suplimentare de verificare la nodurile complete ale rețelei principale Bitcoin, iar împărțirea consensului în cadrul Softchain poate afecta consensul rețelei principale și poate constitui un posibil vector de atac pentru Bitcoin.

Rețeaua fulgerului

Cartea albă Lightning Network a fost lansată în 2015 și lansată oficial în 2018. Ca protocol de plată punct-la-punct de nivel al doilea pe rețeaua Bitcoin, își propune să transfere un număr mare de tranzacții de înaltă frecvență cu cantități mici către off- procesarea în lanț a fost întotdeauna considerată cea mai promițătoare expansiune a rețelei Bitcoin.

modul de bază

Implementarea rețelei Lightning se bazează pe mai multe module importante din cadrul Bitcoin, care împreună asigură securitatea tranzacțiilor în rețea.

În primul rând, există tranzacții presemnate. Aceste tranzacții au devenit sigure de utilizat după upgrade-ul SegWit. SegWit separă semnăturile de restul datelor privind tranzacțiile, rezolvând probleme potențiale, cum ar fi maleabilitatea tranzacțiilor, manipularea tranzacțiilor de la terți și de la a doua parte. Securitatea calculelor off-chain în Rețeaua Lightning este garantată de angajamente irevocabile furnizate de contrapărți, care sunt executate prin tranzacții presemnate. Odată ce utilizatorii primesc o tranzacție presemnată de la o contraparte, o pot difuza în blockchain în orice moment pentru a-și îndeplini angajamentul.

Urmează semnătura multiplă. Transferurile frecvente de fonduri în afara lanțului între două părți necesită un mediu care este controlat în comun de ambele părți, necesitând astfel semnături multiple, utilizând de obicei o schemă 2 din 2. Acest lucru asigură că transferurile de fonduri pot avea loc numai prin consimțământ reciproc.

Cu toate acestea, 2-of-2 multisig poate duce la probleme de viață în care, dacă una dintre părți nu cooperează, cealaltă parte nu poate transfera niciun fond de la adresa multisig, ceea ce duce la pierderea fondurilor inițiale. Blocările de timp pot rezolva problema activității prin pre-semnarea unui contract cu o blocare de timp pentru returnarea fondurilor, vă puteți asigura că, chiar dacă una dintre părți este inactivă, cealaltă parte poate recupera fondurile inițiale.

În cele din urmă, blocările hash sunt folosite pentru a conecta mai multe canale de stat, creând un efect de rețea. Preimaginea hashed servește ca mijloc de comunicare, coordonând operațiunile corecte între mai multe entități.

fluxul de operare

canal cu două sensuri

Pentru a efectua tranzacții folosind Lightning Network, ambele părți trebuie mai întâi să deschidă un canal de plată bidirecțional pe Bitcoin. Aceștia pot efectua un număr nelimitat de tranzacții în afara lanțului și, după finalizarea tuturor tranzacțiilor, pot transmite cel mai recent statut blockchain-ului Bitcoin pentru a deconta și închide canalul 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 trebuie să creeze mai întâi o adresă cu semnături multiple 2 din 2 ca blocare a fondului canalului. Fiecare parte deține cheia privată utilizată pentru semnare și oferă propria sa cheie publică.

2. Inițializați canalul. Ambele părți au difuzat o tranzacție pe lanț, blocând o anumită cantitate de Bitcoin în adresa cu mai multe semnături ca fonduri inițiale ale canalului. Această tranzacție este cunoscută drept tranzacția „ancoră” a canalului.

3. Actualizați starea canalului. La efectuarea unei plăți în cadrul unui canal, ambele părți fac schimb de tranzacții presemnate pentru a actualiza starea canalului. Fiecare actualizare generează o nouă „tranzacție de angajament” care reprezintă alocarea curentă a fondurilor. Tranzacția de angajament are două rezultate, corespunzătoare cotelor de fond ale ambelor părți.

4. Difuzați cea mai recentă stare. Orice parte își poate retrage partea din fonduri în orice moment, difuzând cea mai recentă tranzacție de angajament către blockchain. Pentru a împiedica cealaltă parte să transmită o stare de învechire, fiecare tranzacție de angajament este însoțită de o „tranzacție cu penalizare” corespunzătoare, care permite uneia dintre părți să pretindă toate fondurile celeilalte părți dacă înșală.

5. Închideți canalul. Când două părți decid să închidă un canal, pot colabora pentru a genera o „tranzacție de decontare” și a difuza distribuția finală a fondurilor către blockchain. Acest lucru va elibera fondurile blocate în adresa cu semnături multiple înapoi la adresele personale ale ambelor părți.

6. Arbitraj în lanț. Dacă ambele părți nu se pot pune de acord asupra închiderii canalului, oricare dintre părți poate difuza unilateral cea mai recentă tranzacție de angajament pentru a iniția procedurile de arbitraj în lanț. Dacă nu există nicio dispută într-o anumită perioadă de timp (de exemplu, o zi), fondurile vor fi distribuite ambelor părți conform alocarii în tranzacția de angajament.

rețeaua de plată

Prin utilizarea HTLC (Hash Time Lock Contract), canalele de plată pot fi interconectate pentru a forma o rețea care acceptă rutarea multi-hop. HTLC folosește blocarea hash ca o condiție directă și plata semnăturii blocate în timp ca o condiție de rezervă, permițând utilizatorilor să interacționeze pe baza preimaginilor hash înainte de expirarea timpului de blocare.

Când nu există un canal direct între doi utilizatori, plățile pot fi finalizate folosind HTLC pe căile de rutare. În acest proces, preimaginea hashed R joacă un rol crucial în asigurarea atomicității plății. În plus, blocările de timp în HTLC sunt setate să scadă de-a lungul rutei, asigurându-se că fiecare hop are suficient timp pentru procesarea și redirecționarea plăților.

Probleme

În mod fundamental, Lightning Network eludează ipotezele de încredere externă ale punerii în punte a activelor prin intermediul canalelor de stat peer-to-peer, valorificând în același timp scripturile blocate în timp pentru a oferi protecție finală pentru active împotriva defecțiunilor. Acest lucru permite ieșiri unilaterale în cazul în care o contraparte își pierde activitatea și devine necooperantă. Prin urmare, Lightning Network este extrem de practică în scenariile de plată, dar are și câteva limitări, inclusiv:

1. 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 care depășesc capacitatea canalului. Acest lucru poate limita anumite cazuri de utilizare, cum ar fi tranzacționarea cu mărfuri.

2. Cerințe online și de sincronizare: pentru a primi și redirecționa plăți în timp util, nodurile din rețeaua Lightning trebuie să rămână online. Dacă un nod este offline pentru o perioadă lungă de timp, este posibil să rateze unele actualizări ale stării canalului, ceea ce duce la desincronizare. Aceasta poate fi o provocare pentru utilizatorii individuali și dispozitivele mobile și poate crește, de asemenea, costurile de operare ale nodurilor.

3. Managementul lichidității: Eficiența de rutare a rețelei Lightning depinde de distribuția lichidității între canale. Dacă fondurile sunt distribuite inegal, anumite căi de plată pot deveni invalide, afectând experiența utilizatorului. Gestionarea soldului de lichiditate al unui canal necesită anumite resurse tehnice și financiare.

4. Probleme de confidențialitate: Pentru a găsi căi de plată fezabile, algoritmul de rutare al rețelei Lightning trebuie să cunoască un anumit grad de capacitate a canalului și informații despre conexiune, care pot pierde confidențialitatea utilizatorilor, cum ar fi alocarea fondurilor și contrapărțile. Deschiderea și închiderea canalelor de plată poate, de asemenea, expune informații despre participanți.

RGB

Conceptul original al protocolului RGB a fost inspirat de ideile lui Peter Todd privind validarea clientului și sigilarea unică. A fost propus de Giacomo Zucco în 2016 ca un protocol scalabil și care păstrează confidențialitatea pentru Bitcoin.

Idee de bază

Verificarea clientului

Procesul de verificare într-un blockchain implică difuzarea blocurilor constând din tranzacții către întreaga rețea, permițând fiecărui nod să calculeze și să verifice tranzacțiile din aceste blocuri. Acest lucru creează efectiv un bun public, cu noduri din rețea care asistă fiecare persoană care trimite o tranzacție cu verificare, utilizatorii furnizând BTC ca taxă de tranzacție ca recompensă pentru verificare. Validarea la nivelul clientului este mai centrată pe individ, iar validarea stării nu este efectuată la nivel global, ci de către indivizi implicați în anumite tranziții de stare. Numai părțile care generează tranzacția pot verifica legitimitatea acestor tranziții de stat, sporind semnificativ confidențialitatea, reducând sarcina nodului și îmbunătățind scalabilitatea.

Sigiliu de unica folosinta

Tranzițiile de stat peer-to-peer sunt riscante și, fără acces la istoricul complet al tranziției de stat, utilizatorii pot fi vulnerabili la fraudă, ceea ce duce la cheltuieli duble. Sigiliul de unică folosință a fost propus pentru a rezolva această problemă. Folosind obiecte speciale care pot fi folosite o singură dată, acestea asigură că nu se produce dublarea cheltuielilor, sporind astfel securitatea. Modelul UTXO (Unspent Transaction Output) al Bitcoin este cea mai potrivită formă de sigilare unică, protejată de mecanismul de consens Bitcoin și puterea de hashing a rețelei, permițând activelor RGB să moștenească caracteristicile de securitate ale Bitcoin.

Crypto Promise

Sigiliile unice trebuie combinate cu angajamente criptografice pentru a se asigura că utilizatorii înțeleg clar tranzițiile de stare și pentru a preveni atacurile cu cheltuieli duble. O promisiune de a informa pe alții că ceva s-a întâmplat și nu poate fi schimbat mai târziu, fără a dezvălui detalii specifice până când este necesară verificarea. Acest lucru poate fi realizat folosind funcții hash. În RGB, conținutul unui angajament este o tranziție de stare care este semnalată destinatarului activului RGB prin cheltuirea unui UTXO. Destinatarul activelor verifică apoi angajamentul pe baza datelor specifice transmise în afara lanțului de către cheltuitor de active.

Fluxul de lucru

RGB profită de consensul Bitcoin pentru a asigura securitatea dublei cheltuieli și rezistența la cenzură, în timp ce toate sarcinile de verificare a tranziției de stat sunt delegate în afara lanțului și efectuate numai de clientul care primește plata.

Pentru emitenții de active RGB, crearea unui contract RGB implică inițierea unei tranzacții în care un angajament față de anumite informații este stocat într-un script OP_RETURN în condiția tranzacției Taproot.

Când deținătorul unui activ RGB dorește să-l cheltuiască, trebuie să obțină informațiile relevante de la destinatarul bunului, să creeze o tranzacție RGB și să trimită detaliile acestei tranzacții. Angajamentul este apoi plasat într-un UTXO specificat de destinatarul activului și este emisă o tranzacție pentru a cheltui UTXO inițial și pentru a crea un nou UTXO specificat de destinatar. Atunci când destinatarul activului observă că UTXO care stochează activul RGB a fost cheltuit, poate verifica validitatea tranzacției RGB prin angajamentul din tranzacția Bitcoin. Odată ce verificarea este valabilă, aceștia pot confirma cu încredere primirea activului RGB.

Pentru beneficiarii de active RGB, plătitorul trebuie să furnizeze starea inițială și regulile de tranziție ale statului, fiecare tranzacție Bitcoin utilizată în transfer, tranzacția RGB transmisă pentru fiecare tranzacție Bitcoin și dovezi ale validității fiecărei tranzacții Bitcoin. Clientul destinatarului folosește aceste date pentru a verifica validitatea tranzacției RGB. În această configurație, UTXO al Bitcoin acționează ca un container care deține starea contractului RGB. Istoricul de transfer al fiecărui contract RGB poate fi reprezentat ca un grafic aciclic direcționat (DAG), iar destinatarul unui activ RGB poate accesa doar istoricul aferent activului pe care îl deține și nu orice alte ramuri.

argumente pro şi contra

Verificare ușoară

În comparație cu verificarea completă cerută de blockchain, protocolul RGB reduce foarte mult costul de verificare. Utilizatorii nu trebuie să parcurgă toate blocurile istorice pentru a obține cel mai recent statut. Trebuie doar să sincronizeze istoricul aferent activelor primite a tranzacției.

Această verificare ușoară face tranzacțiile peer-to-peer mai ușoare și reduce și mai mult dependența de furnizorii de servicii centralizați, sporind descentralizarea.

Scalabilitate

Protocolul RGB necesită doar un angajament hash, moștenește securitatea Bitcoin și nu consumă practic niciun spațiu suplimentar de bloc Bitcoin folosind scripturile Taproot. Acest lucru permite programarea complexă a activelor. Folosind UTXO ca container, protocolul RGB acceptă în mod natural concurența activelor RGB pe diferite ramuri de transfer nu se vor bloca reciproc și pot fi utilizate în același timp.

intimitate

Spre deosebire de protocoalele tipice, doar destinatarul activului RGB are acces la istoricul transferului de active. Odată utilizate, acestea nu au acces la istoricul transferurilor viitoare, asigurând în mare măsură confidențialitatea utilizatorului. Tranzacțiile cu active RGB nu sunt asociate cu transferurile de Bitcoin UTXO, astfel încât persoanele din afara nu pot urmări tranzacțiile RGB pe blockchain-ul Bitcoin.

În plus, RGB acceptă ieșire oarbă, ceea ce înseamnă că plătitorii nu pot determina la care UTXO va fi plătit un activ RGB, sporind și mai mult confidențialitatea și rezistența la cenzură.

neajuns

Atunci când un activ RGB își schimbă mâinile de mai multe ori, noul destinatar al activului se poate confrunta cu o sarcină considerabilă de verificare pentru a verifica istoricul lung de transfer, ceea ce poate duce la timpi de verificare mai lungi și la pierderea capacității de a confirma rapid tranzacțiile. Pentru nodurile care rulează într-un blockchain, timpul necesar pentru verificarea unei tranziții de stare după primirea unui nou bloc este de fapt limitat, deoarece acestea sunt întotdeauna sincronizate cu cea mai recentă stare.

Comunitatea discută despre posibilitatea reutilizarii calculelor istorice, iar dovezile recursive ZK pot permite un timp și dimensiune constantă a verificării stării.

Rulează

Prezentare generală

Rollup este cea mai bună soluție de expansiune din ecosistemul Ethereum, derivată din ani de explorare de la canalele de stat la Plasma și, în cele din urmă, a evoluat la Rollup.

Rollup este un blockchain independent care colectează tranzacții din afara lanțului Bitcoin, grupează mai multe tranzacții, execută aceste tranzacții și trimite loturi de date și angajamente ale statului către lanțul principal. Acest lucru permite procesarea tranzacțiilor în afara lanțului și actualizările de stare. Pentru a maximiza scalabilitatea, Rollup utilizează în mod obișnuit un secvențior centralizat în această etapă pentru a îmbunătăți eficiența execuției fără a compromite securitatea, deoarece securitatea este asigurată de verificarea lanțului principal a tranzițiilor stării Rollup.

Pe măsură ce soluția Rollup a ecosistemului Ethereum devine din ce în ce mai matură, ecosistemul Bitcoin începe și el să exploreze Rollups. Cu toate acestea, o diferență cheie între Bitcoin și Ethereum este lipsa capacității de programare pentru a efectua calculele necesare pentru a construi Rollup-uri în lanț. În prezent, lucrăm în principal la implementarea pachetelor Suverane și a pachetelor OP.

Clasificare

Rollup-urile pot fi împărțite în două categorii principale: Rollup-uri Optimistic (Optimistic Rollups) și Validity Rollups (ZK Rollups). Principala diferență constă în metoda de verificare a tranziției.

Optimistic Rollup adoptă o metodă de verificare optimistă în timpul perioadei de dispută după trimiterea fiecărui lot de tranzacții, oricine poate să vizualizeze datele din afara lanțului, să ridice obiecții la loturile problematice și să trimită dovezi de eroare către lanțul principal, penalizând astfel Sequencerul. Dacă nu este prezentată nicio dovadă validă de eroare în perioada de dispută, lotul de tranzacții este considerat valabil și actualizarea stării este confirmată pe lanțul principal.

Validity Rollup utilizează Validity Proof pentru verificare. Sequencer utilizează un algoritm de demonstrare a cunoștințelor zero pentru a genera o dovadă concisă a validității pentru fiecare lot de tranzacții, demonstrând că tranziția de stare a lotului este corectă. Fiecare actualizare necesită trimiterea unei dovezi de valabilitate a lotului de tranzacții către lanțul principal, care va verifica dovada și va confirma imediat actualizarea stării.

Avantajul Optimistic Rollup este că este relativ simplu și necesită puține modificări pe lanțul principal, dar dezavantajul este că timpul de confirmare a tranzacției este mai lung (în funcție de perioada de dispută) și cerințele de disponibilitate a datelor sunt mai mari. Avantajul Validity Rollup este că confirmarea tranzacției este rapidă, nu este afectată de perioada de dispută și poate asigura confidențialitatea datelor despre tranzacție, dar generarea și verificarea dovezilor fără cunoștințe necesită o mulțime de cheltuieli de calcul.

Celestia a propus, de asemenea, conceptul de rollup-uri suverane, în care datele de tranzacție ale pachetului sunt publicate într-un blockchain de nivel dedicat disponibilității datelor (DA), care este responsabil pentru disponibilitatea datelor, în timp ce pachetul suveran în sine este responsabil de execuție și decontare.

Explorează și discută

Rollup-urile bazate pe Bitcoin sunt încă în stadii incipiente Din cauza diferențelor în modelul de contabilitate și limbajul de programare al lui Ethereum, este o provocare să copiați direct Ethereum.

Suveranitate Rollup

Pe 5 martie 2023, Rollkit a fost anunțat ca fiind primul cadru care sprijină Bitcoin Sovereign Rollups. Constructorii de Rollup-uri suverane pot folosi Rollkit pentru a publica date de disponibilitate pe Bitcoin.

Rollkit este inspirat din Ordinals și utilizează tranzacțiile Taproot pentru a publica date. Tranzacțiile Taproot care respectă standardele publice mempool pot conține până la 390KB de date, în timp ce tranzacțiile Taproot non-standard postate direct de mineri pot conține aproape 4MB de date arbitrare.

Rollkit oferă în esență o interfață pentru citirea și scrierea datelor pe Bitcoin și oferă un serviciu middleware pentru conversia Bitcoin într-un strat DA.

Ideea unui pachet suveran a fost întâmpinată cu un scepticism considerabil. Mulți critici susțin că Rollup-ul suveran bazat pe Bitcoin folosește doar Bitcoin ca panou de buletin și nu reușește să moștenească securitatea Bitcoin. De fapt, dacă s-ar transmite către Bitcoin doar date privind tranzacțiile, ar crește doar activitatea - asigurându-se că toți utilizatorii pot accesa și verifica datele relevante prin Bitcoin. Cu toate acestea, securitatea poate fi definită doar de Rollup-ul suveran și nu poate fi moștenită. În plus, spațiul bloc este extrem de valoros pe 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 Layer2 pretind a fi ZK Rollups, ele sunt în esență mai aproape de OP Rollups și implică tehnologia Validity Proof. Dar capacitățile actuale de programare ale Bitcoin nu sunt suficiente pentru a sprijini verificarea directă a dovezii de valabilitate.

Setul actual de coduri operaționale Bitcoin este atât de limitat încât nici măcar nu poate calcula direct înmulțirile, iar verificarea dovezilor de valabilitate necesită extinderea codurilor operaționale, care depinde în mare măsură de implementarea contractelor recursive. Comunitatea discută activ despre opțiuni, inclusiv OP_CAT, OP_CHECKSIG, OP_TXHASH etc. În mod ideal, adăugarea OP_VERIFY_ZKP ar putea rezolva problema fără alte modificări, dar acest lucru este puțin probabil. În plus, limitările de dimensiunea stivei au împiedicat, de asemenea, eforturile de verificare a dovezilor de validitate în scripturile Bitcoin și multe explorări sunt în desfășurare.

Deci, cum funcționează dovada validității? Majoritatea proiectelor publică discrepanțe ale declarațiilor și dovezi de valabilitate ale tranzacțiilor în lot către Bitcoin în format de înscriere și folosesc BitVM pentru o verificare optimistă. În această schemă, operatorul podului acționează ca o federație, gestionând depozitele utilizatorilor. Înainte ca un utilizator să facă o depunere, federația pre-semnează UTXO pentru a se asigura că depozitul poate fi revendicat în mod legal doar de către operator. Odată presemnat, BTC este blocat într-o adresă Taproot cu semnături multiple N/N.

Când un utilizator solicită o retragere, Rollup trimite rădăcina de retragere cu dovada validității lanțului Bitcoin. Operatorul plătește inițial din buzunar pentru a satisface nevoile de retragere ale utilizatorilor, iar apoi contractul BitVM verifică valabilitatea. Dacă fiecare operator consideră că dovada este valabilă, va rambursa operatorul prin multi-semnătură dacă cineva consideră că există fraudă, va fi inițiată un proces de contestare și partea greșită va fi pedepsită.

Acest proces este în esență același cu OP Rollup, unde ipoteza de încredere este 1/N - atâta timp cât un validator este sincer, protocolul este sigur. În ceea ce privește dovada validității, scopul nu este de a ușura verificarea în rețeaua Bitcoin, ci de a face verificarea mai ușoară pentru nodurile individuale.

Cu toate acestea, implementarea tehnică a acestei soluții poate întâmpina provocări În proiectul OP Rollup de la Ethereum, Arbitrum se dezvoltă de mulți ani, dar Proba de fraudă este încă trimisă de noduri autorizate, ceea ce arată dificultatea implementare.

Cu sprijinul Bitcoin Covenant, operațiunile de pre-semnare în podul BitVM pot fi efectuate mai eficient, ceea ce rămâne de atins de către comunitate.

Din perspectiva atributelor de securitate, prin transmiterea hash-ului de bloc Rollup la Bitcoin, Bitcoin dobândește capacitatea de a rezista reorganizării și cheltuielilor duble, în timp ce Optimistic Bridge aduce o ipoteză de securitate 1/N. De asemenea, se așteaptă ca rezistența la cenzură a lui Optimistic Bridge să fie îmbunătățită.

Concluzie: Stratul 2 nu este un panaceu

Pe măsură ce ne-am uitat la diferitele soluții pe 2 niveluri, a devenit clar că fiecare soluție are limitările sale. Eficacitatea stratului 2 depinde în mare măsură de capacitățile stratului 1 (adică Bitcoin) în anumite ipoteze de încredere.

Înființarea cu succes a rețelei Lightning nu ar fi posibilă fără upgrade-uri și timelock-uri SegWit nu ar fi posibile fără upgrade-uri de Validity pentru Bitcoin, fără OP_CAT și alte Convenții;

Mulți maximaliști Bitcoin cred că Bitcoin nu ar trebui să se schimbe niciodată, nu ar trebui adăugate caracteristici noi și toate defectele ar trebui rezolvate cu o soluție de nivel 2. Cu toate acestea, acest lucru nu este realizabil, stratul 2 nu este un panaceu. Avem nevoie de un Layer 1 mai puternic pentru a construi un Layer 2 mai sigur, mai eficient și mai scalabil.

În următorul nostru articol, vom explora încercările de a îmbunătăți programabilitatea Bitcoin.