Traseul de extindere a Bitcoin-ului ≠ BTC L2.
La începutul noului an, am realizat un rezumat al traseului tehnic BTC L2. Acesta se împarte în principal în siguranța și creșterea valorii BTC, precum și în execuția tranzacțiilor L2 și rezultatele descrescătoare. Pe măsură ce timpul a trecut, în mai puțin de trei luni, BTC L2 a atins aproape o sută de unități. Cu toate acestea, există încă câteva probleme fundamentale care trebuie rezolvate, iar problema principală este definirea problemei.
În evoluția Bitcoin-ului, au existat de-a lungul timpului trei modalități de practică pentru extinderea capacității. La baza acestora se află upgrade-urile rețelei principale, cum ar fi SegWit și Taproot. A doua modalitate este extinderea în afara lanțului, cum ar fi validarea clientului, rețeaua Lightning și lanțurile laterale. În cele din urmă, există fork-uri directe, cum ar fi Dogecoin, BSV și BCH.
Din interior spre exterior, există multe opinii despre ce este BTC L2. Referindu-mă la istoria de dezvoltare a Ethereum, propun aici două puncte de evaluare:
1. L2 trebuie să fie în primul rând o rețea proprie, capabilă să finalizeze independent toate etapele de calcul și tranzacție, în cele din urmă să supună Bitcoin pentru decontare;
2. Securitatea L2 este complet garantată de L1, iar valoarea de bază a L2 este susținută de BTC. Token-urile L2 nu trebuie să interfereze cu funcționalitatea BTC.
Conform acestui standard, actualizările și fork-urile rețelei principale nu au legătură cu conceptul L2, iar accentul se pune pe clasificarea rutei de extindere off-chain. De exemplu, rețeaua Lightning este un "canal" special, dificil de considerat ca fiind un blockchain public; iar lanțurile laterale dispun de propriul consens de securitate și mod de operare, iar securitatea nu poate fi strict echivalată cu Bitcoin. Dar L2 ar trebui să fie ascuns în interior. Apoi continuăm să facem distincția.
BTC L2 = rețeaua Lightning + lanțuri laterale.
Referindu-mă la standardele anterioare, BTC L2 ar trebui să fie un produs hibrid al rețelei Lightning și al lanțurilor laterale. Ar trebui să fie complet dependent de rețeaua principală Bitcoin, dar și "independent" în operare față de Bitcoin. Ar trebui să luăm esența din fiecare și să eliminăm impuritățile.
Astfel, soluțiile existente pentru BTC L2 necesită o dezvoltare suplimentară. În special, având în vedere faptul că mecanismul UTXO al BTC și mecanismele inteligente de contracte pe care se bazează Layer 2 nu pot funcționa strict în sinergie. Adică Bitcoin nu poate anula tranzacțiile anterioare, iar L2 trebuie să rezolve singur problema sau să introducă actualizări externe sau mecanisme de indexare.
În al doilea rând, independența L2 prezintă o problemă prea mare. De exemplu, stocarea doar a informațiilor despre blocurile tranzacțiilor Bitcoin ca dovadă de sincronizare de la L2 la L1, sau stocarea doar a informațiilor de decontare în scriptul Bitcoin ca soluție DA, fără a lua în considerare problemele ulterioare de căutare și verificare.
Starea curentă a BTC L2 este ușor de interpretat greșit, ducând la o criză de securitate și încredere. Cred că este necesar să trecem de la un model centrat pe L2 la o nouă etapă centrată pe Rollup. Adică, să utilizăm pe deplin securitatea rețelei principale Bitcoin, în timp ce rezolvăm problema calculului la scară mare.
BTC L2 ≠ Rollup.
BTC construiește un sistem PoS pentru a oferi securitate, folosind un mecanism de acces și distrugere fără permisiune, diferit de sistemele existente, inclusiv activele. Câștigurile din staking BTC folosesc complet BTC ca monedă de calcul, iar token-urile proiectului nu trebuie să interfereze cu BTC. Stratul de calcul al Rollup-ului trebuie să îndeplinească simultan cerințele de amploare și confidențialitate, folosind tehnologia criptografică pentru a contracara tendințele centralizate. Rollup-ul nu poate construi un strat DA suplimentar, folosind strict Bitcoin ca soluție DA.
În concluzie, un Rollup ideal ar trebui să utilizeze BTC ca taxă de gaz nativă și recompensă pentru staking, folosind mecanismul de dublă legare 2WP pentru a permite circulația între lanțuri. Activele mapate xBTC, ancorate 1:1, circulă în BTC L2 și între punțile L2, calculul de confidențialitate + dovezile ZK pot asigura anonimatul complet și confidențialitatea utilizatorilor Bitcoin din sursă și proces, iar token-urile proiectului participă la operarea Rollup-ului, evitând conflictele de rol cu BTC.
Rollup-ul seamănă atât cu un pod, cât și cu un lanț și cu L2.
În primul rând, trebuie să ne eliberăm gândirea. PoW la bază + PoS la vârf este soluția optimă de moment. Câștigurile din staking depind de susținerea valorii de bază. Combinarea ingineriei în loc de inovația tehnologică, nu are prea mult sens să ne concentrăm pe ZK sau OP. Stocarea rezultatelor nu este DA. În plus, nu trebuie să ne agățăm excesiv de designul mecanismelor centralizate și descentralizate. Nici o soluție nu poate fi comparată cu Bitcoin, chiar și ETH OP, dovezile reale de eroare și mecanismele de recuperare sunt de asemenea doar "teoretice". În prezent sau pe termen lung, proiectul va fi în continuare controlat de echipă.
Prin urmare, un design mecanic mai rațional constă în a găsi modalități tehnice de a reduce intervenția umană și de a asigura durabilitatea proiectului.
Stabilitatea este esențială. În ETH L2, se numește proiectare de retragere obligatorie și capsule de salvare. Asigură că, în situații extreme, oprirea proiectului poate garanta securitatea fondurilor utilizatorilor. În cazul BTC Rollup, dificultatea constă în cum să restitui activele mapate pe rețeaua principală Bitcoin în cazul unui defect și cum să asiguri confidențialitatea în timpul procesului de calcul Rollup, în etapele timpurii în care descentralizarea nu este atât de pronunțată.
Mai întâi, discutăm despre primul punct, activele mapate BTC, cum ar fi versiunile descentralizate ale WBTC, trebuie să asigure securitatea în timp ce circulă pe Rollup. Pe de o parte, BTC-ul trebuie să intre pentru a susține valoarea Rollup-ului. Pe de altă parte, BTC-ul Rollup trebuie să fie capabil să se întoarcă pe rețeaua principală în caz de defect.
Soluțiile existente sunt, în esență, variante de poduri între lanțuri. Diferența constă doar în faptul că sunt poduri de comunicare, poduri de active sau poduri centralizate. În prezent, pare foarte greu să existe soluții noi. Podurile de active sunt primul pas în construirea unui sistem PoS.
Cu toate acestea, există încă spațiu pentru inovație în staking și câștigurile din staking. De exemplu, se poate sări peste etapa de dezvoltare a Lido-ului și să folosească tehnologia DVT pentru a construi un sistem complet de staking descentralizat. Sau, bazându-se pe BTC, WBTC sau BounceBit, să emită BTC re-staked derivat din sistemul de schimb, construind un sistem de staking hibrid pentru a reduce impactul asupra securității BTC în perioade de criză.
După poduri de active și DVT/staking mixt, calculul Rollup a fost ignorat pe termen lung. Problema este că Rollup trebuie să fie capabil să suporte cele patru etape sau părți ale throughput-ului de date al blockchain-ului public, actualizarea stării și stocarea rezultatelor, precum și distribuția datelor. Poate fi discutată în două puncte: eficiența și confidențialitatea.
Eficiența este ușor de înțeles. De exemplu, utilizând mecanisme paralele sau concurente. După ce a trecut de emoțiile FOMO din etapele incipiente, Bitcoin Rollup trebuie să concureze cu ETH Rollup în ceea ce privește eficiența operativă. Iar accelerarea a fost demonstrată a fi cu adevărat eficientă de către Solana.
Problema confidențialității a fost ignorată de mult timp. Mecanismul PoW al Bitcoin face ca acesta să fie practic imposibil de cenzurat. Dar Rollup-urile, în etapele lor incipiente, sunt foarte susceptibile la presiunea de cenzură de după PoS-ul ETH. Soluția aici nu poate fi realizată printr-un design mecanic descentralizat. Nici o soluție nu se poate compara cu PoW-ul BTC. Este necesar să căutăm ajutorul calculului confidențial.
În cele din urmă, este problema DA. Aceasta se referă la standardele de evaluare a distincției dintre ETH L2 și Rollup. Cele care nu folosesc rețeaua principală ca soluție DA nu pot fi considerate Rollup. Acest lucru implică o promisiune finală de securitate. Dacă L2/Rollup renunță activ la protecția de securitate a L1, atunci ar trebui să fie eliminate. Datorită mecanismelor independente ale BTC, este necesar un design suplimentar.
Utilizarea mixtă a validării optimiste și a ZK devine o normă. Se referă la tranzacțiile de pe Rollup care sunt confirmate în cele din urmă de rețeaua principală. Dovezile de fraudă folosesc un mecanism optimist, adică confirmare inițială, apoi eliminarea obstacolelor, iar după o anumită perioadă, devin eficiente. La generarea dovezilor, se poate folosi ZK pentru a comprima semnificativ datele. Acest lucru este deosebit de important în BTC Rollup. Motivul este simplu: spațiul Bitcoin este extrem de costisitor.
Mecanismul de inscripție poate juca un rol mai mare în mecanismele de tranzacție. În ETH Rollup, dacă dovezile de fraudă sunt contestate și acceptate de Ethereum, rețeaua principală va confisca activele de staking ale submitentului. Dar în BTC Rollup, această confiscare trebuie efectuată off-chain. Deoarece scriptul Bitcoin, odată scris, nu poate fi modificat din nou. Actualizările pot fi realizate doar prin scrierea informațiilor în noi blocuri, adică se poate doar actualiza, nu se poate suprascrie.
Rețeaua indexer trebuie să își asume în mod real responsabilitatea pentru actualizarea tranzacțiilor. Trebuie să fie descentralizată.
În final, putem finaliza designul mecanismului întregului BTC Rollup. Acesta poate fi împărțit în patru pași, practic urmând xBTC---> staking---> calcul---> DA pentru a construi arhitectura tehnică. Dificultățile principale constau în principiile de design ale sistemului de staking și ale activelor mapate, precum și în problemele de confidențialitate în calculul on-chain și designul final al DA.
În plus, respectăm principiul că token-urile proiectului nu trebuie să intre în conflict cu BTC. Token-urile proiectului ar trebui să își desfășoare activitatea în cadrul Rollup-ului. De exemplu, construirea sistemului DVT, întreținerea descentralizată a indexerilor, precum și circulația în dezvoltarea ecologică și în sistemele de guvernanță.
Imagine de ansamblu: BTC L2 discutat din toate unghiurile.
Dacă folosesc standardul pe care l-am definit pentru Rollup, atunci, evident, multe dintre proiectele propuse nu pot fi incluse în discuție. Prin urmare, extindem domeniul. Orice caracteristici menționate mai sus sunt acceptabile.
A fost evaluat în mod intuitiv.
Conform ordinii celor patru pași, putem compara ușor soluțiile tehnologice principale de acum. Este important de menționat că fiecare pas este interconectat, dar se va presupune că premisa a fost deja stabilită și nu va fi reiterată. De exemplu, următorul pas după punte este staking, așa că în discuția despre staking nu vom mai accentua modalitatea de realizare a punții, ci vom avansa succesiv.
Începând de la activele de punte, ZetaChain și Zeus Network se conformează cel mai bine standardelor. Comunică între Bitcoin și ecosistemul EVM, precum și între ecosistemul Solana. În implementarea concretă, cele două prezintă unele diferențe.
ZetaChain a creat un standard ZRC-20 similar cu ERC-20. BTC poate fi emis ca token zBTC într-o proporție de 1:1. De asemenea, pentru a sublinia conceptul de Omni între toate lanțurile, zBTC are în mod real un mecanism intern de schimb, care nu va fi transferat efectiv pe lanțul țintă, transformând zBTC într-un activ între toate lanțurile. Totuși, acest activ mapat necesită un design mecanic foarte robust. ZetaChain monitorizează tranzacțiile și evenimentele pe lanțul Bitcoin prin utilizarea observatorilor (observers) și semnatarilor (signers), ajungând la un consens pe ZetaChain pentru a interacționa cu blockchain-uri non-smart contract, cum ar fi Bitcoin.
Teoretic, ZetaChain este un pod între toate lanțurile, nu doar capabil să comunice între Bitcoin și ecosistemul EVM. Dar punctul central aici este să explicăm cum lanțurile publice non-smart contract, cum ar fi Bitcoin, pot accesa EVM. Se poate observa că ZetaChain este atât un pod de mesaje, cât și un pod de active.
În timp ce Zeus Network subliniază că este un strat de comunicație și nu un pod între lanțuri. În designul său mecanic, oferă o interfață standardizată care permite diferitelor blockchain-uri să schimbe informații și valori prin această interfață.
De exemplu, BTC poate fi blocat pe o adresă Bitcoin specifică și active echivalente pot fi eliberate pe Solana. Și, în cazul în care BTC trebuie să fie transferat efectiv și să efectueze operațiuni smart contract pe Solana, poate modifica comportamentul pe rețeaua Bitcoin.
Se poate observa că aceasta seamănă mai mult cu un joc de cuvinte. Teoretic, nu este necesar să transferi active între două lanțuri, dar în realitate nu poți transfera cu adevărat BTC pe rețeaua Solana. Podurile de active sau informații necesită în esență introducerea unei terțe părți pentru a se apela și comunica reciproc, diferența constând doar în adâncimea intervenției.
După punerea în funcțiune a podurilor de active, va apărea un sistem de staking. Semnificația staking-ului este de a imita promisiunile de securitate ale rețelei ETH. De exemplu, cele patru tipuri de mecanisme: Stake, LSDFI, Restake și LRTFi, au în esență logica de a asigura securitatea rețelei principale prin staking, emiterea unor titluri echivalente pentru a participa la DeFi și câștigarea de profituri, diferența constând în gradul de complexitate.
În practica Bitcoin, Merlin Chain este un exemplu reprezentativ al sistemului de staking. BounceBit este reprezentantul LRTfi, dar esența rămâne atragerea utilizatorilor de a-și păstra activele în cadrul propriei rețele. Nu este vorba doar de a depozita monede pentru dobândă, ci de a spera să extindă granițele ecologice în timp ce se menține securitatea, era utilizabilității se apropie.
Merlin Chain, pe lângă creșterea violentă, se angajează în dezvoltarea ecologică. Pe baza multisig-ului L1 BTC și a sistemului de contracte inteligente L2, construiește apoi scenarii de utilizare pe L2, cum ar fi Merlin Swap, Merlin Starter și multe altele, fiind cea mai activă rețea Layer 2. Este un produs din aceeași familie cu ETH L2 ZKFair, ambele fiind produse Lumoz. Colaborează cu Cobo pentru a construi un sistem de gestionare a activelor L2, având în prezent un TVL de 3,6 miliarde de dolari, care este practic cel mai mare.
Și BounceBit merge mai departe, sau mai bine zis, mai înapoi.
Progresul constă în faptul că BounceBit produce active re-staked pe baza schimbului, utilizatorii depun BTC direct pe Binance și le schimbă în active ambalate pe BNB Chain, putând participa la activități comerciale CeFi și DeFi. Mai departe, utilizând tehnologia de custodie, BounceBit poate emite active LRTfi în timp ce păstrează Bitcoin, iar sistemul compatibil cu EVM construit poate conecta lumea on-chain.
În cadrul întregului operativ al rețelei, CEX și custodia sunt baza operațiunilor, iar unicitatea BounceBit constă în emiterea de lichiditate pe BTC-ul blocat, integrând logica de valorizare a activelor. În prezent, TVL-ul este de 700 de milioane de dolari și se poate depune BTC sau token-uri proprii în rețeaua de staking, ideea generală fiind utilizarea unor măsuri mai centralizate pentru a reduce riscurile asociate cu operarea BTC.
Mai departe, aceasta este o versiune ușor îmbunătățită a WBTC, chiar și fără o funcționare pe termen lung, securitatea sa nu este neapărat superioară celei oferite de WBTC.
Următorul pas este etapa de calcul on-chain, unde trebuie rezolvate două probleme: descentralizarea ordonatorilor și problematica compatibilității și eficienței calculului.
Centralizarea ordonatorului este o problemă cronică în ETH L2. Esențial, utilizarea ordonatorilor centralizați poate îmbunătăți semnificativ eficiența operativă a L2 și poate preveni în mare măsură atacurile MEV, ajutând în același timp la îmbunătățirea experienței utilizatorului. Pe lângă aceste beneficii, problema serioasă a centralizării poate conduce la faptul că proiectul devine entitatea operativă de facto.
În ceea ce privește compatibilitatea, compatibilitatea EVM sau SVM este ușor de rezolvat, dar interacțiunea între L2-uri va fi mult mai complexă, iar eficiența calculului va necesita o introducere masivă de mecanisme paralele sau concurente; în prezent nu există proiecte de practică foarte evidente.
De asemenea, există problema protecției confidențialității în calculele on-chain. Deși există soluții care utilizează ZK-Rollup, acestea sunt în principal folosite pentru comprimarea datelor și au loc mai mult în publicarea datelor DA. Proiectele dedicate protecției confidențialității în procesul de calcul nu au fost încă foarte vizibile.
În cele din urmă, modalitatea de publicare a datelor DA trebuie discutată în legătură cu mecanismul ZK. Spre deosebire de ETH L2, BTC L2 folosește ZK în principal pentru comprimarea datelor, de exemplu, Bitlayer este un exemplu.
Bitlayer utilizează un mecanism de validare optimist pentru a reduce complexitatea, folosind ZK pentru a comprima datele și scriind informațiile într-o formă similară cu inscripția. În concret, se presupune că loturile de tranzacții sunt valide implicit, cu excepția cazului în care există dovezi care să demonstreze contrariul. Astfel, tranzacțiile pot fi procesate rapid off-chain și trimise în format comprimat către rețeaua Bitcoin, reducând sarcina de date și costurile. Dacă se descoperă comportamente frauduloase, participanții pot iniția provocări, declanșând revenirea la o stare anterioară și pedepsirea actorilor malițioși, asigurând siguranța sistemului.
Dar construirea unui sistem de revenire a stării bazat pe Bitcoin poate să nu fie atât de simplă, necesitând o explorare de lungă durată.
Încheiere
Pornind de la soluțiile de scalare a Bitcoin, încercăm să conturăm cum ar trebui să arate un Rollup centrat pe Bitcoin. Cheia este de a asigura că valoarea și performanța de securitate a BTC se transferă pe Rollup, și de a se distinge de soluțiile existente pentru activele ambalate. În implementarea concretă, soluțiile bazate pe activele de punte și sistemele de staking devin alegeri comune, dar cum să asigurăm descentralizarea și să valorificăm rolul BTC și al token-urilor de rețea rămâne un teritoriu neclar.
Cu toate acestea, ruta centrată pe Rollup este în prezent cea mai completă, fiind mai matură decât soluțiile bazate pe mecanismul UTXO sau pe validarea clientului. În etapele intermediare de pe lanț, calculul confidențial și descentralizarea ordonatorului sunt două puncte cheie, iar în DA-ul final, inscripția oferă deja o abordare destul de matură ca referință, singura dificultate fiind problema costurilor.
