Autore: Chakra Traduzione: 0xjs@金财经
Esistono molti percorsi per il ridimensionamento di Bitcoin. La prima parte della nostra serie di articoli ha già descritto uno dei percorsi "Soluzioni di ridimensionamento nativo di Bitcoin". l’aspetto più critico della soluzione a 2 livelli è il ponte sicuro a due vie e l’ereditarietà della sicurezza del consenso di Bitcoin.
catena laterale
Il concetto di sidechain risale al 2014, quando Blockstream ha presentato “Enabling Blockchain Innovation with Pegged Sidechains”. Rappresenta un metodo di ridimensionamento relativamente semplice.
Come funziona la catena laterale?
Una catena laterale è una blockchain che opera indipendentemente dalla catena principale, ha un proprio protocollo di consenso e può fungere da banco di prova per l’innovazione della catena principale. Quando si verifica un evento avverso sulla catena laterale, il danno è completamente limitato alla catena laterale stessa senza alcun impatto sulla catena principale. Le sidechain possono adottare protocolli di consenso con TPS (transazioni al secondo) più elevati, migliorare la programmabilità sulla catena e facilitare una funzionalità avanzata di BTC.
Le sidechain possono realizzare il trasferimento di Bitcoin tra diverse blockchain tramite peg a due vie o unidirezionali. Ma in realtà, BTC può risiedere solo sulla rete principale Bitcoin, quindi è necessario un meccanismo di ancoraggio per collegare BTC sulla catena laterale con BTC sulla rete principale Bitcoin.
I peg unidirezionali richiedono agli utenti di inviare BTC dalla rete principale a un indirizzo non disponibile per la distruzione, quindi coniare una quantità equivalente di BTC sulla sidechain, ma questo processo è irreversibile. I picchetti a due vie rappresentano un miglioramento dei picchetti unidirezionali, consentendo a BTC di spostarsi avanti e indietro tra la catena principale e le catene laterali. Invece di essere distrutto inviando a un indirizzo non disponibile, un peg bidirezionale blocca BTC tramite firme multiple o altri script di controllo, coniando nuovi BTC sulla sidechain. Quando l'utente desidera tornare alla rete principale, i BTC sulla catena laterale verranno distrutti e i BTC originariamente bloccati verranno rilasciati sulla rete principale.
L'implementazione di un ancoraggio unidirezionale è molto più semplice di un ancoraggio bidirezionale perché non richiede la gestione dello stato rilevante sulla rete principale Bitcoin. Tuttavia, le risorse della sidechain create tramite peg unidirezionali potrebbero essere inutili perché prive di un meccanismo di peg inverso.
Esistono diversi schemi e livelli di sicurezza per verificare le transazioni di blocco sulla catena principale e masterizzare le transazioni sulla catena laterale. Il metodo più semplice è la verifica esterna tramite partecipanti multifirma, ma ciò comporta elevati rischi di centralizzazione. Un’opzione migliore è utilizzare le prove SPV per la verifica decentralizzata. Tuttavia, poiché la rete principale di Bitcoin non dispone delle capacità di programmazione necessarie per eseguire la verifica SPV, è necessario utilizzare altri metodi, solitamente l'impegno multi-firma.
Problemi e metodi
Le principali critiche alle sidechain includono:
1. Gli asset cross-chain si basano su verificatori: poiché la rete principale Bitcoin non è ancora in grado di implementare contratti intelligenti, i trasferimenti di asset cross-chain non possono essere gestiti attraverso una logica contrattuale trustless. La restituzione degli asset da una sidechain a Bitcoin si basa su una serie di validatori, introducendo presupposti di fiducia e rischi di frode.
2. Le catene laterali non possono ereditare la sicurezza della catena principale: poiché le catene laterali funzionano in modo completamente indipendente dalla rete principale, non possono ereditare la sicurezza della rete principale, il che potrebbe portare a una riorganizzazione dannosa dei blocchi.
Per risolvere questi problemi, le sidechain hanno adottato metodi che includono l’affidamento a istituzioni autorevoli (federazione), sicurezza economica (PoS), minatori Bitcoin decentralizzati (mining unito) e moduli di sicurezza hardware (HSM). La custodia dei fondi su Bitcoin e la produzione di blocchi sulle sidechain possono essere gestite da ruoli diversi, introducendo meccanismi di sicurezza più complessi.
argomento di studio
Liquido
Una delle prime forme di sidechain erano le sidechain federate, che si basavano su un gruppo preselezionato di entità che fungevano da validatori responsabili della custodia delle risorse sulla rete principale e della generazione di blocchi sulla sidechain.
Liquid è un classico esempio di sidechain federata, con 15 parti che fungono da validatori. La gestione della chiave privata non è pubblica e la verifica richiede 11 firme su 15. Anche la produzione a blocchi sulla sidechain Liquid è gestita da questi 15 partecipanti. Il minor numero di nodi in questa federazione si traduce in transazioni al secondo (TPS) più elevate, raggiungendo così obiettivi di scalabilità, e la sua principale area di applicazione è la DeFi.
Tuttavia, il modello di sidechain federato presenta notevoli rischi per la sicurezza della centralizzazione.
Portinnesto (RSK)
RSK è inoltre gestito da 15 nodi responsabili dell'hosting dei principali fondi della rete e la verifica richiede solo 8 firme. A differenza di Liquid, le chiavi multi-firma di RSK sono gestite da un modulo di sicurezza hardware (HSM) e le istruzioni di hook sono firmate in base al consenso Proof-of-Work (PoW), impedendo ai validatori con accesso alla chiave di manipolare direttamente i fondi di deposito a garanzia.
In termini di consenso della catena laterale, RSK adotta il merged mining e utilizza la potenza di calcolo della rete principale per garantire la sicurezza delle transazioni della catena laterale. Quando gran parte della potenza di calcolo della rete principale viene utilizzata per il mining combinato, può prevenire efficacemente la doppia spesa attacchi sulla catena laterale. RSK è migliorato sulla base del merged mining. Attraverso la consapevolezza del fork, esegue un intervento di consenso off-chain sul comportamento del fork, garantendo così la sicurezza delle catene laterali con bassa potenza di calcolo e riducendo la possibilità di attacchi double-spending.
Tuttavia, il merged mining modifica gli incentivi dei minatori, aumenta il rischio di valore estraibile dai minatori (MEV) e ha il potenziale per destabilizzare il sistema. Nel corso del tempo, il mining unito può aumentare la centralizzazione del mining.
Pile
Stacks raggiunge la stessa finalità di Bitcoin ancorando la cronologia della sua catena a Bitcoin inviando gli hash dei suoi blocchi sidechain nei blocchi Bitcoin. I fork negli stack possono verificarsi solo quando Bitcoin stesso si biforca, rendendolo più resistente agli attacchi di doppia spesa.
sBTC introduce un nuovo modello di token e incentivi che utilizza uno staking bridge che consente fino a 150 validatori mainnet. I validatori devono mettere in staking i token STX per avere accesso ai depositi e ai prelievi approvati. La sicurezza di uno staking bridge dipende in gran parte dal valore degli asset impegnati, il che rappresenta un rischio per la sicurezza cross-chain di BTC durante i periodi di significative fluttuazioni dei prezzi degli asset impegnati.
Altre proposte di sidechain sono attualmente ampiamente discusse nella comunità.
Catena di trasmissione
La più notevole di queste è la proposta Drivechain di Paul Sztorc nel 2015, che divideva le tecnologie chiave in BIP 300 (Peg Mechanism) e BIP 301 (Blind Merged Mining). BIP 300 definisce la logica per l'aggiunta di nuove sidechain, in modo simile all'attivazione di nuove sidechain tramite segnali del minatore (come i soft fork). BIP 301 consente ai minatori Bitcoin di diventare produttori di blocchi su sidechain senza verificare i dettagli specifici delle transazioni.
I minatori Bitcoin sono anche responsabili dell’approvazione delle transazioni di prelievo. Avviano una proposta di prelievo creando un output OP_RETURN nella transazione coinbase del blocco che hanno estratto. Gli altri minatori possono quindi votare la proposta sostenendola o opponendosi ad ogni blocco che estraggono. Una volta che una transazione di prelievo supera la soglia (13.150 blocchi), viene eseguita e confermata sulla catena principale di Bitcoin.
In effetti, i minatori hanno il controllo completo sui fondi su Drivechain. Se i fondi vengono rubati, gli utenti possono salvarsi solo attraverso soft fork attivati dall’utente (UASF), su cui è difficile raggiungere un consenso. Inoltre, la posizione unica dei minatori in Drivechain aumenta il rischio MEV, come è stato dimostrato in Ethereum.
Catena spaziale
Spacechain adotta un approccio diverso, utilizzando un peg unidirezionale permanente (P1WP), in cui gli utenti distruggono BTC per ottenere token su Spacechain, aggirando completamente il problema della sicurezza dei fondi. Questi token vengono utilizzati solo per fare offerte per blocchi di spazio su Spacechain e non hanno alcuna funzionalità di riserva di valore.
Per garantire la sicurezza della sidechain, Spacechain utilizza il blind merge mining, in cui gli utenti fanno offerte pubbliche per il diritto di creare blocchi utilizzando ANYPREVOUT (APO). I minatori Bitcoin devono solo inviare intestazioni di blocco Spacechain nei propri blocchi senza convalidare i blocchi sidechain. Tuttavia, il lancio di Spacechain richiede il supporto di Bitcoin per Covenant e la comunità Bitcoin sta ancora discutendo se sia necessario un soft fork per aggiungere il codice operativo Covenant.
Nel complesso, Spacechain mira a realizzare una sidechain decentralizzata e resistente alla censura come Bitcoin, aumentando al tempo stesso la programmabilità attraverso la sua funzione di asta a blocchi.
Softchain
Softchain è un'altra proposta di sidechain a due vie (2wp) di Ruben Somsen che utilizza il meccanismo di consenso PoW FP per proteggere la sidechain. In circostanze normali, i nodi completi Bitcoin devono solo scaricare l'intestazione del blocco Softchain per verificare la prova di lavoro. Se si verifica un fork, scaricano il blocco orfano e il corrispondente set di impegni UTXO per verificare la validità del blocco.
Per il meccanismo 2wp, quando il peg viene trasferito, verrà creata una transazione di deposito sulla catena principale e la Softchain farà riferimento a questa transazione della catena principale per ottenere fondi; quando il peg verrà trasferito, verrà creata una transazione di prelievo sulla Softchain e la catena principale quoterà questa transazione per ritirare BTC dopo un periodo di sfida più lungo. Gli specifici meccanismi di aggancio di trasferimento in entrata e in uscita richiedono il supporto del soft fork, quindi la proposta si chiama Softchain.
La proposta di Softchain aggiunge ulteriori costi di verifica per tutti i nodi della rete principale Bitcoin, e la divisione del consenso all'interno di Softchain potrebbe influenzare il consenso della rete principale e costituire un possibile vettore di attacco per Bitcoin.
Rete fulminea
Il white paper di Lightning Network è stato pubblicato nel 2015 e lanciato ufficialmente nel 2018. Essendo un protocollo di pagamento punto a punto di secondo livello sulla rete Bitcoin, mira a trasferire un gran numero di transazioni ad alta frequenza di piccolo importo su servizi off-line. elaborazione a catena È sempre stata considerata l'espansione più promettente del piano della rete Bitcoin.
modulo principale
L'implementazione del Lightning Network si basa su diversi moduli importanti all'interno di Bitcoin, che insieme garantiscono la sicurezza delle transazioni di rete.
Innanzitutto, ci sono transazioni prefirmate. Queste transazioni sono diventate sicure da utilizzare dopo l'aggiornamento di SegWit. SegWit separa le firme dal resto dei dati della transazione, risolvendo potenziali problemi come la malleabilità delle transazioni e la manomissione delle transazioni di terze e seconde parti. La sicurezza dei calcoli fuori catena nel Lightning Network è garantita da impegni irrevocabili forniti dalle controparti, che vengono eseguiti tramite transazioni prefirmate. Una volta che gli utenti ricevono una transazione prefirmata da una controparte, possono trasmetterla alla blockchain in qualsiasi momento per adempiere al proprio impegno.
Il prossimo è la firma multipla. I frequenti trasferimenti di fondi fuori catena tra due parti richiedono un mezzo controllato congiuntamente da entrambe le parti, richiedendo quindi firme multiple, in genere utilizzando uno schema 2 su 2. Ciò garantisce che i trasferimenti di fondi possano avvenire solo previo consenso reciproco.
Tuttavia, il multisig 2 su 2 può portare a problemi di attività in cui se una parte non collabora, l'altra parte non è in grado di trasferire fondi dall'indirizzo multisig, con conseguente perdita dei fondi originali. I blocchi temporali possono risolvere il problema delle attività; prefirmando un contratto con un blocco temporale per la restituzione dei fondi, puoi garantire che anche se una parte è inattiva, l'altra parte può comunque recuperare i fondi iniziali.
Infine, gli hash lock vengono utilizzati per connettere più canali statali, creando un effetto di rete. La preimmagine con hash funge da mezzo di comunicazione, coordinando le operazioni corrette tra più entità.
flusso operativo
canale bidirezionale
Per condurre transazioni utilizzando Lightning Network, entrambe le parti devono prima aprire un canale di pagamento bidirezionale su Bitcoin. Possono condurre un numero illimitato di transazioni fuori catena e, dopo aver completato tutte le transazioni, inviare lo stato più recente alla blockchain di Bitcoin per regolare e chiudere il canale di pagamento.
Nello specifico, l’implementazione dei canali di pagamento prevede i seguenti passaggi chiave:
1. Crea un indirizzo con firma multipla. Entrambe le parti devono prima creare un indirizzo con firma multipla 2 su 2 come blocco dei fondi del canale. Ciascuna parte detiene la chiave privata utilizzata per la firma e fornisce la propria chiave pubblica.
2. Inizializzare il canale. Entrambe le parti trasmettono una transazione sulla catena, bloccando una certa quantità di Bitcoin nell'indirizzo multi-firma come fondi iniziali del canale. Questa transazione è nota come transazione "di ancoraggio" del canale.
3. Aggiorna lo stato del canale. Quando si effettua un pagamento all'interno di un canale, entrambe le parti si scambiano transazioni prefirmate per aggiornare lo stato del canale. Ogni aggiornamento genera una nuova "transazione di impegno" che rappresenta l'attuale allocazione dei fondi. La transazione di impegno ha due output, corrispondenti alle quote di fondi di entrambe le parti.
4. Trasmetti lo stato più recente. Qualsiasi parte può ritirare la propria quota di fondi in qualsiasi momento trasmettendo l’ultima transazione di impegno alla blockchain. Per evitare che l'altra parte trasmetta informazioni stantie, ogni transazione di impegno è accompagnata da una corrispondente "transazione di penalità" che consente a una parte di reclamare tutti i fondi dell'altra parte se imbroglia.
5. Chiudere il canale. Quando due parti decidono di chiudere un canale, possono collaborare per generare una "transazione di regolamento" e trasmettere la distribuzione finale dei fondi alla blockchain. Ciò rilascerà i fondi bloccati nell'indirizzo con firma multipla agli indirizzi personali di entrambe le parti.
6. Arbitrato a catena. Se entrambe le parti non riescono a mettersi d'accordo sulla chiusura del canale, ciascuna delle parti può trasmettere unilateralmente l'ultima transazione di impegno per avviare un procedimento arbitrale sulla catena. Se non vi è alcuna controversia entro un certo periodo di tempo (ad esempio un giorno), i fondi verranno distribuiti ad entrambe le parti in base all'allocazione nella transazione di impegno.
rete di pagamento
Utilizzando HTLC (Hash Time Lock Contract), i canali di pagamento possono essere interconnessi per formare una rete che supporta il routing multi-hop. HTLC utilizza il blocco dell'hash come condizione diretta e il pagamento della firma con un limite temporale come condizione di backup, consentendo agli utenti di interagire in base alle preimmagini con hash prima della scadenza del blocco temporale.
Quando non esiste un canale diretto tra due utenti, i pagamenti possono essere completati utilizzando HTLC attraverso i percorsi di instradamento. In questo processo, la preimmagine con hash R gioca un ruolo cruciale nel garantire l’atomicità del pagamento. Inoltre, i blocchi temporali in HTLC diminuiranno lungo il percorso, garantendo che ogni hop abbia tempo sufficiente per elaborare e inoltrare i pagamenti.
I problemi
Fondamentalmente, Lightning Network elude i presupposti di fiducia esterna dell’asset bridging tramite canali statali peer-to-peer, sfruttando script bloccati nel tempo per fornire la massima protezione degli asset contro i guasti. Ciò consente uscite unilaterali nel caso in cui una controparte perda l’attività e diventi non collaborativa. Pertanto, Lightning Network è molto pratico negli scenari di pagamento, ma presenta anche diverse limitazioni, tra cui:
1. Limite di capacità del canale: la capacità del canale di pagamento nel Lightning Network è limitata dai fondi iniziali bloccati e non può supportare pagamenti che superano la capacità del canale. Ciò potrebbe limitare alcuni casi d'uso, come il commercio di materie prime.
2. Requisiti online e di sincronizzazione: per ricevere e inoltrare i pagamenti in modo tempestivo, i nodi del Lightning Network devono rimanere online. Se un nodo è offline per un lungo periodo di tempo, potrebbe perdere alcuni aggiornamenti sullo stato del canale, con conseguente desincronizzazione. Ciò può rappresentare una sfida per i singoli utenti e i dispositivi mobili e può anche aumentare i costi operativi dei nodi.
3. Gestione della liquidità: l'efficienza del routing del Lightning Network dipende dalla distribuzione della liquidità tra i canali. Se i fondi non vengono distribuiti in modo uniforme, alcuni percorsi di pagamento potrebbero non essere più validi, incidendo negativamente sull'esperienza dell'utente. La gestione del saldo di liquidità di un canale richiede determinate risorse tecniche e finanziarie.
4. Problemi di privacy: per trovare percorsi di pagamento fattibili, l'algoritmo di instradamento di Lightning Network deve conoscere un certo grado di capacità del canale e informazioni di connessione, che potrebbero far trapelare la privacy dell'utente, come l'allocazione dei fondi e le controparti. L'apertura e la chiusura dei canali di pagamento possono anche esporre informazioni sui partecipanti.
RGB
Il concetto originale del protocollo RGB è stato ispirato dalle idee di Peter Todd di convalida lato client e sigillatura una tantum. È stato proposto da Giacomo Zucco nel 2016 come protocollo di secondo livello scalabile e che preserva la privacy per Bitcoin.
Idea fondamentale
Convalida del cliente
Il processo di verifica in una blockchain prevede la trasmissione di blocchi costituiti da transazioni all'intera rete, consentendo a ciascun nodo di calcolare e verificare le transazioni all'interno di questi blocchi. Ciò crea effettivamente un bene pubblico, con i nodi della rete che assistono ogni individuo che invia una transazione con verifica, con gli utenti che forniscono BTC come commissione di transazione come ricompensa per la verifica. La convalida lato client è più incentrata sull'individuo e la convalida dello stato non viene eseguita a livello globale ma da individui coinvolti in transizioni di stato specifiche. Solo le parti che generano la transazione possono verificare la legittimità di queste transizioni di stato, migliorando significativamente la privacy, riducendo il carico sui nodi e migliorando la scalabilità.
Sigillo usa e getta
Le transizioni di stato peer-to-peer sono rischiose e, senza l’accesso alla cronologia completa delle transizioni di stato, gli utenti potrebbero essere vulnerabili alle frodi, con conseguenti doppie spese. Per risolvere questo problema è stato proposto il sigillo monouso. Utilizzando oggetti speciali che possono essere utilizzati una sola volta, garantiscono che non si verifichi una doppia spesa, aumentando così la sicurezza. Il modello UTXO (Unspent Transaction Output) di Bitcoin è la forma più adatta di sigillo una tantum, protetto dal meccanismo di consenso di Bitcoin e dal potere di hashing della rete, consentendo alle risorse RGB di ereditare le caratteristiche di sicurezza di Bitcoin.
Promessa crittografica
I sigilli una tantum devono essere combinati con impegni crittografici per garantire che gli utenti comprendano chiaramente le transizioni di stato e prevengano attacchi a doppia spesa. Una promessa di informare gli altri che qualcosa è successo e che non può essere cambiato in seguito, senza rivelare dettagli specifici fino a quando non sarà richiesta la verifica. Ciò può essere ottenuto utilizzando le funzioni hash. In RGB, il contenuto di un impegno è una transizione di stato che viene segnalata al destinatario dell'asset RGB attraverso la spesa di un UTXO. Il destinatario dell'asset verifica quindi l'impegno sulla base di dati specifici trasmessi off-chain da chi spende l'asset.
Flusso di lavoro
RGB sfrutta il consenso di Bitcoin per garantire la sicurezza della doppia spesa e la resistenza alla censura, mentre tutte le attività di verifica della transizione statale sono delegate off-chain ed eseguite solo dal cliente che riceve il pagamento.
Per gli emittenti di asset RGB, la creazione di un contratto RGB implica l'avvio di una transazione in cui un impegno per informazioni specifiche viene archiviato in uno script OP_RETURN all'interno delle condizioni della transazione Taproot.
Quando il detentore di un bene RGB desidera spenderlo, deve ottenere le informazioni pertinenti dal destinatario del bene, creare una transazione RGB e inviare i dettagli di questa transazione. L'impegno viene quindi inserito in un UTXO specificato dal destinatario dell'asset e viene emessa una transazione per spendere l'UTXO originale e creare un nuovo UTXO specificato dal destinatario. Quando il destinatario dell'asset nota che l'UTXO che conserva l'asset RGB è stato speso, può verificare la validità della transazione RGB attraverso l'impegno nella transazione Bitcoin. Una volta che la verifica è valida, possono confermare con sicurezza la ricezione della risorsa RGB.
Per i destinatari di asset RGB, il pagatore deve fornire lo stato iniziale del contratto e le regole di transizione statale, ciascuna transazione Bitcoin utilizzata nel trasferimento, la transazione RGB inviata per ciascuna transazione Bitcoin e la prova della validità di ciascuna transazione Bitcoin. Il client del destinatario utilizza questi dati per verificare la validità della transazione RGB. In questa configurazione, l’UTXO di Bitcoin funge da contenitore che contiene lo stato del contratto RGB. Lo storico dei trasferimenti di ciascun contratto RGB può essere rappresentato come un grafico aciclico diretto (DAG), e il destinatario di un asset RGB può accedere solo allo storico relativo all'asset che detiene e non ad altri rami.
pro e contro
Verifica leggera
Rispetto alla verifica completa richiesta dalla blockchain, il protocollo RGB riduce notevolmente i costi di verifica. Gli utenti non devono attraversare tutti i blocchi storici per ottenere lo stato più recente. Devono solo sincronizzare la cronologia relativa alle risorse ricevute per verificarne la validità della transazione.
Questa verifica leggera semplifica le transazioni peer-to-peer e riduce ulteriormente la dipendenza da fornitori di servizi centralizzati, migliorando la decentralizzazione.
Scalabilità
Il protocollo RGB richiede solo un impegno di hash, eredita la sicurezza di Bitcoin e praticamente non consuma ulteriore spazio di blocco Bitcoin utilizzando gli script Taproot. Ciò consente una programmazione complessa delle risorse. Utilizzando UTXO come contenitore, il protocollo RGB supporta naturalmente la concorrenza; le risorse RGB su diversi rami di trasferimento non si bloccheranno a vicenda e potranno essere utilizzate contemporaneamente.
privacy
A differenza dei protocolli tipici, solo il destinatario della risorsa RGB ha accesso alla cronologia del trasferimento della risorsa. Una volta utilizzati, non hanno accesso alla cronologia dei trasferimenti futuri, garantendo notevolmente la privacy dell'utente. Le transazioni di asset RGB non sono associate ai trasferimenti di Bitcoin UTXO, quindi gli estranei non possono tracciare le transazioni RGB sulla blockchain di Bitcoin.
Inoltre, RGB supporta l'output cieco, il che significa che i pagatori non possono determinare a quale UTXO verrà pagata una risorsa RGB, migliorando ulteriormente la privacy e la resistenza alla censura.
discordanza
Quando una risorsa RGB passa di mano più volte, il nuovo destinatario della risorsa potrebbe dover affrontare un notevole onere di verifica per verificare la lunga cronologia dei trasferimenti, il che potrebbe comportare tempi di verifica più lunghi e la perdita della capacità di confermare rapidamente le transazioni. Per i nodi in esecuzione in una blockchain, il tempo necessario per verificare una transizione di stato dopo aver ricevuto un nuovo blocco è in realtà limitato poiché sono sempre sincronizzati con lo stato più recente.
La comunità sta discutendo la possibilità di riutilizzare i calcoli storici e le prove ZK ricorsive potrebbero consentire tempi e dimensioni costanti della verifica dello stato.
Rollup
Panoramica
Rollup è la migliore soluzione di espansione nell'ecosistema Ethereum, derivata da anni di esplorazione dai canali statali a Plasma e infine evoluta in Rollup.
Rollup è una blockchain indipendente che raccoglie transazioni esterne alla catena Bitcoin, raggruppa più transazioni, esegue queste transazioni e invia batch di dati e impegni statali alla catena principale. Ciò consente l'elaborazione delle transazioni fuori catena e gli aggiornamenti di stato. Per massimizzare la scalabilità, Rollup utilizza in genere un sequenziatore centralizzato in questa fase per migliorare l'efficienza di esecuzione senza compromettere la sicurezza, poiché la sicurezza è garantita dalla verifica delle transizioni dello stato di Rollup da parte della catena principale.
Man mano che la soluzione Rollup dell’ecosistema Ethereum diventa sempre più matura, anche l’ecosistema Bitcoin inizia ad esplorare i Rollup. Tuttavia, una differenza fondamentale tra Bitcoin ed Ethereum è la mancanza di capacità di programmazione per eseguire i calcoli necessari per creare rollup on-chain. Attualmente stiamo lavorando principalmente sull'implementazione dei rollup sovrani e OP rollup.
Classificazione
I rollup possono essere suddivisi in due categorie principali: rollup ottimistici (rollup ottimistici) e rollup di validità (rollup ZK). La differenza principale risiede nel metodo di verifica della transizione di stato.
Optimistic Rollup adotta un metodo di verifica ottimistico. Durante il periodo di controversia dopo l'invio di ogni batch di transazioni, chiunque può visualizzare i dati fuori catena, sollevare obiezioni ai batch problematici e inviare prove di errore alla catena principale, penalizzando così il Sequencer. Se entro il periodo di contestazione non viene presentata alcuna prova valida dell'errore, il batch di transazioni viene considerato valido e l'aggiornamento dello stato viene confermato sulla catena principale.
Validity Rollup utilizza la prova di validità per la verifica. Sequencer utilizza un algoritmo di prova a conoscenza zero per generare una prova di validità concisa per ciascun batch di transazioni, dimostrando che la transizione di stato del batch è corretta. Ogni aggiornamento richiede l'invio di una prova di validità del batch di transazioni alla catena principale, che verificherà la prova e confermerà immediatamente l'aggiornamento dello stato.
Il vantaggio di Optimistic Rollup è che è relativamente semplice e richiede poche modifiche sulla catena principale, ma lo svantaggio è che il tempo di conferma della transazione è più lungo (a seconda del periodo della controversia) e i requisiti per la disponibilità dei dati sono più elevati. Il vantaggio di Validity Rollup è che la conferma della transazione è rapida, non è influenzata dal periodo della controversia e può garantire la privacy dei dati della transazione, ma generare e verificare prove a conoscenza zero richiede molto sovraccarico computazionale.
Celestia ha anche proposto il concetto di rollup sovrano, in cui i dati delle transazioni del rollup vengono pubblicati su una blockchain dedicata al livello di disponibilità dei dati (DA), che è responsabile della disponibilità dei dati, mentre il rollup sovrano stesso è responsabile dell'esecuzione e del regolamento.
Esplora e discuti
I rollup basati su Bitcoin sono ancora nelle fasi iniziali. A causa delle differenze nel modello contabile e nel linguaggio di programmazione di Ethereum, è difficile copiare direttamente Ethereum. La comunità Bitcoin sta esplorando attivamente soluzioni innovative.
Rollup della sovranità
Il 5 marzo 2023, Rollkit è stato annunciato come il primo framework a supportare Bitcoin Sovereign Rollups. I costruttori di Rollup sovrani possono utilizzare Rollkit per pubblicare dati sulla disponibilità su Bitcoin.
Rollkit si ispira agli Ordinali e utilizza le transazioni Taproot per pubblicare i dati. Le transazioni Taproot conformi agli standard mempool pubblici possono contenere fino a 390 KB di dati, mentre le transazioni Taproot non standard pubblicate direttamente dai minatori possono contenere quasi 4 MB di dati arbitrari.
Rollkit fornisce essenzialmente un'interfaccia per leggere e scrivere dati su Bitcoin e fornisce un servizio middleware per convertire Bitcoin in un livello DA.
L’idea di un roll-up sovrano è stata accolta con notevole scetticismo. Molti critici sostengono che Rollup sovrano basato su Bitcoin utilizzi Bitcoin semplicemente come bacheca e non riesca ad ereditare la sicurezza di Bitcoin. In effetti, se a Bitcoin venissero inviati solo i dati delle transazioni, l’attività non farebbe altro che aumentare, garantendo che tutti gli utenti possano accedere e verificare i dati rilevanti tramite Bitcoin. Tuttavia, la sicurezza può essere definita solo dallo stesso Rollup sovrano e non può essere ereditata. Inoltre, lo spazio dei blocchi è estremamente prezioso su Bitcoin e l’invio di dati completi sulle transazioni potrebbe non essere una buona decisione.
Rollup OP e rollup di validità
Sebbene molti progetti Bitcoin Layer2 affermino di essere ZK Rollup, sono essenzialmente più vicini agli OP Rollup e coinvolgono la tecnologia Validity Proof. Ma le attuali capacità di programmazione di Bitcoin non sono sufficienti per supportare la verifica diretta della prova di validità.
L'attuale insieme di codici operativi di Bitcoin è così limitato che non può nemmeno calcolare direttamente le moltiplicazioni, e la verifica delle prove di validità richiede l'estensione dei codici operativi, che dipende in gran parte dall'implementazione di contratti ricorsivi. La comunità sta discutendo attivamente opzioni tra cui OP_CAT, OP_CHECKSIG, OP_TXHASH, ecc. Idealmente, l'aggiunta di OP_VERIFY_ZKP potrebbe risolvere il problema senza altre modifiche, ma ciò è improbabile. Inoltre, le limitazioni relative alle dimensioni dello stack hanno anche ostacolato gli sforzi per verificare le prove di validità negli script Bitcoin e molte esplorazioni sono in corso.
Allora come funziona la prova di validità? La maggior parte dei progetti pubblica discrepanze nelle dichiarazioni e prove di validità delle transazioni batch su Bitcoin in formato di iscrizione e utilizza BitVM per la verifica ottimistica. In questo schema, l’operatore del ponte agisce come una federazione, gestendo i depositi degli utenti. Prima che un utente effettui un deposito, la federazione prefirma l'UTXO per garantire che il deposito possa essere legalmente richiesto solo dall'operatore. Una volta prefirmato, BTC viene bloccato in un indirizzo Taproot multifirma N/N.
Quando un utente richiede un prelievo, Rollup invia la root del prelievo con prova di validità alla catena Bitcoin. L’operatore inizialmente paga di tasca propria per soddisfare le esigenze di prelievo degli utenti, quindi il contratto BitVM ne verifica la validità. Se ciascun operatore ritiene che la prova sia valida, ripagherà l'operatore tramite multifirma; se qualcuno ritiene che ci sia una frode, verrà avviato un processo di contestazione e la parte sbagliata verrà punita;
Questo processo è essenzialmente lo stesso di OP Rollup, dove il presupposto di attendibilità è 1/N: finché un validatore è onesto, il protocollo è sicuro. Per quanto riguarda la prova di validità, lo scopo non è quello di facilitare la verifica sulla rete Bitcoin, ma di facilitare la verifica per i singoli nodi.
Tuttavia, l'implementazione tecnica di questa soluzione potrebbe incontrare delle sfide. Nel progetto OP Rollup di Ethereum, Arbitrum è in fase di sviluppo da molti anni, ma la sua prova di frode è ancora presentata dai nodi autorizzati. Ottimismo non supporta ancora la prova di frode, il che mostra la difficoltà di implementazione.
Con il supporto di Bitcoin Covenant, le operazioni di pre-firma nel bridge BitVM possono essere eseguite in modo più efficiente, cosa che deve ancora essere raggiunta dalla comunità.
Dal punto di vista degli attributi di sicurezza, inviando l’hash del blocco Rollup a Bitcoin, Bitcoin acquisisce la capacità di resistere alla riorganizzazione e alla doppia spesa, mentre l’Optimistic Bridge porta un presupposto di sicurezza 1/N. Si prevede che anche la resistenza alla censura di Optimistic Bridge sarà ulteriormente migliorata.
Conclusione: il livello 2 non è una panacea
Osservando le varie soluzioni a due livelli, è diventato chiaro che ciascuna soluzione presentava i suoi limiti. L’efficacia del Livello 2 dipende fortemente dalle capacità del Livello 1 (ovvero Bitcoin) sotto determinati presupposti di fiducia.
La creazione di successo della rete Lightning non sarebbe possibile senza gli aggiornamenti SegWit e i commit efficienti in RGB non sarebbero possibili senza gli aggiornamenti Taproot. I rollup di validità su Bitcoin non sarebbero possibili senza OP_CAT e altri Covenants...
Molti massimalisti di Bitcoin credono che Bitcoin non dovrebbe mai cambiare, che non dovrebbero essere aggiunte nuove funzionalità e che tutti i difetti dovrebbero essere risolti con una soluzione di livello 2. Tuttavia, ciò non è realizzabile; lo strato 2 non è una panacea. Abbiamo bisogno di un livello 1 più forte per costruire un livello 2 più sicuro, efficiente e scalabile.
Nel nostro prossimo articolo, esploreremo i tentativi di migliorare la programmabilità di Bitcoin.
