Scritto da: Chakra Research
Oltre alla soluzione di espansione nativa menzionata nel primo volume, un altro percorso di espansione per Bitcoin utilizza un ulteriore livello di protocollo sopra Bitcoin, chiamato Layer 2. I due punti più critici della soluzione Layer 2 sono il bridging sicuro a due vie e l’ereditarietà della sicurezza del consenso di Bitcoin.
Catena laterale
L'origine del concetto di sidechain può essere fatta risalire a "Enabling Blockchain Innovations with Pegged Sidechain" presentato da blockStream nel 2014. Si tratta di un piano di espansione relativamente semplice.
principio di funzionamento
La catena laterale è una blockchain che opera in modo completamente indipendente dalla catena principale, ha un proprio protocollo di consenso e può essere utilizzata come campo sperimentale per l’innovazione della catena principale. Quando si verifica un evento maligno nella catena laterale, il danno è completamente limitato alla catena laterale stessa e non ha alcun impatto sulla catena principale. La catena laterale può utilizzare un protocollo di consenso TPS più elevato per aumentare le capacità di programmazione sulla catena e ottenere il miglioramento di BTC.
La catena laterale può realizzare il trasferimento di Bitcoin tra diverse blockchain tramite peg bidirezionale o peg unidirezionale. Ovviamente, infatti, BTC può rimanere solo sulla rete Bitcoin, quindi abbiamo bisogno di un meccanismo di ancoraggio per rendere la catena laterale The. BTC nella catena è collegato al BTC nella rete Bitcoin.
Il peg unidirezionale richiede agli utenti di inviare BTC sulla rete principale a un indirizzo non disponibile per la distruzione, quindi il numero corrispondente di BTC verrà ottenuto sulla catena laterale, ma il processo non può essere invertito. Il peg a due vie è un ulteriore aggiornamento del peg unidirezionale, che consente a BTC di spostarsi avanti e indietro tra la catena principale e le catene laterali. Invece di inviarlo a un indirizzo non disponibile per la distruzione, il peg bidirezionale bloccherà BTC attraverso script di controllo come multi-firma e conierà nuovi BTC sulla catena laterale. Quando l'utente desidera tornare alla rete principale, i BTC sulla catena laterale verranno bruciati e i BTC originariamente bloccati verranno rilasciati sulla rete principale.
L'implementazione del peg unidirezionale è molto più semplice di quella del peg bidirezionale, poiché non è necessario gestire lo stato rilevante sulla rete Bitcoin, ma gli asset della catena laterale generati tramite il peg unidirezionale potrebbero essere inutili a causa del peg unidirezionale. mancanza di meccanismo di ancoraggio inverso.
Esistono diverse soluzioni e diversi livelli di sicurezza per la verifica delle transazioni di blocco sulla catena principale e di transazioni di masterizzazione sulla catena laterale. La soluzione più semplice è utilizzare la verifica esterna da parte di partecipanti con firme multiple, ma il rischio di centralizzazione è elevato. Un’opzione migliore è utilizzare SPV Proof per ottenere una verifica decentralizzata. Naturalmente, poiché la rete principale di Bitcoin non dispone delle capacità di programmazione necessarie, la verifica SPV non può essere eseguita e si possono solo scegliere altri metodi, solitamente la custodia multi-firma.
Domande e idee
Ci sono due problemi principali per cui le catene laterali vengono criticate:
La dipendenza degli asset cross-chain dai verificatori: poiché la rete principale di Bitcoin non è ancora in grado di implementare contratti intelligenti, il trasferimento cross-chain di asset non può essere elaborato attraverso la logica del contratto trustless quando si passa dalla catena laterale a Bitcoin è necessario affidarsi ad un gruppo di verificatori. Per portare a termine l'operazione c'è un presupposto di fiducia e c'è il rischio di frode.
La catena laterale non può ereditare la sicurezza della catena principale: la catena laterale funziona in modo completamente indipendente dalla rete principale e non può ereditare la sicurezza della rete principale Possono verificarsi eventi come la riorganizzazione dannosa dei blocchi.
A questo proposito, le idee delle catene laterali includono la dipendenza dall’autorità (tipo di alleanza), la dipendenza dalla sicurezza economica (PoS), la dipendenza dai minatori Bitcoin decentralizzati (Merged Mining), la dipendenza dai moduli di sicurezza hardware (HSM), la custodia dei fondi e la catena laterale su Bitcoin Ruoli diversi possono essere responsabili della produzione di blocchi della catena, introducendo così meccanismi di sicurezza più complessi.
Introduzione al caso
Liquido
La prima forma di catena laterale è la catena laterale dell’alleanza, in cui più entità selezionate in anticipo fungono da verificatori e sono responsabili della custodia dei principali fondi della rete e della produzione in blocchi della catena laterale.
Liquid è il rappresentante della catena laterale dell'alleanza, con 15 partecipanti che fungono da verificatori. Il metodo di gestione della chiave privata non è divulgato e per la verifica sono necessarie 11 firme. Anche i blocchi sulla catena laterale Liquid sono gestiti congiuntamente da 15 partecipanti. La catena di alleanze con un numero basso di nodi può raggiungere un TPS più elevato e raggiungere obiettivi di espansione. L'ambito di applicazione principale è la DeFi.
L’approccio della catena laterale dell’alleanza presenta significativi rischi per la sicurezza centralizzata.
Portinnesto (RSK)
RSK ha anche 15 nodi che fungono da custodi dei fondi della rete principale e sono necessarie solo 8 firme per la verifica. La differenza rispetto a Liquid è che la chiave multi-firma è gestita dal modulo di sicurezza hardware HSM e l'istruzione di peg-out è firmata secondo il consenso PoW per impedire al verificatore che detiene la chiave di manipolare direttamente i fondi di deposito a garanzia.
In termini di consenso della catena laterale, RSK utilizza il Merged Mining per utilizzare la potenza di calcolo della rete principale per garantire la sicurezza delle transazioni sulla catena laterale. Quando la proporzione della potenza di calcolo del mining unito nella rete principale è elevata, può prevenire meglio il lato catena da essere compromessa. Attacco a doppio fiore. RSK ha apportato miglioramenti al Merged Mining per garantire la sicurezza delle catene laterali con hash rate bassi. Adotta un metodo sensibile al fork per eseguire un intervento di consenso fuori catena sul comportamento del fork e ridurre la probabilità di doppia spesa.
Tuttavia, il Merged Mining modifica gli incentivi dei minatori e intensifica i rischi del MEV, che alla fine potrebbe destabilizzare il sistema. A lungo termine, il Merged Mining potrebbe aumentare la centralizzazione del mining.
Pile
Stacks ancora la storia della catena Stacks a Bitcoin inviando l'hash del blocco della catena laterale al blocco Bitcoin. Ha la stessa finalità di Bitcoin. Il fork di Stacks può essere causato solo dal fork di Bitcoin resistere alla doppia spesa.
sBTC introduce un nuovo token STX e un modello di incentivi, utilizzando un approccio di staking bridge che consente fino a 150 validatori mainnet. Nel cosiddetto staking bridge, i validatori devono mettere in staking i token STX per ottenere il permesso di approvare depositi e prelievi. La sicurezza del ponte dei pegni dipende in larga misura dal valore degli asset impegnati. Quando il valore degli asset impegnati oscilla violentemente, la sicurezza della catena incrociata BTC viene facilmente danneggiata. Se il valore degli asset impegnati è inferiore al valore degli asset cross-chain, il validatore ha un incentivo a fare del male.
Ci sono anche alcune proposte di sidechain che vengono ampiamente discusse nella comunità.
Catena di trasmissione
Quella che ha attirato maggiormente l’attenzione è Drivechain proposta da Paul Sztorc nel 2015. Alle tecnologie chiave del piano sono stati assegnati BIP 300 (meccanismo di peg) e BIP 301 (blind merged mining). BIP 300 definisce in dettaglio la logica di aggiunta di una nuova catena laterale. L'attivazione di una nuova catena laterale è simile all'attivazione di un soft fork tramite i segnali del minatore. BIP 301 consente ai minatori Bitcoin di diventare produttori di blocchi sidechain senza verificare il contenuto specifico della transazione.
I minatori Bitcoin sono anche responsabili dell'approvazione delle transazioni di prelievo. I minatori devono prima creare un output OP_RETURN nella transazione coinbase del blocco che hanno estratto per proporre una transazione di prelievo. Successivamente, ogni minatore può votare sulla proposta può votare a favore o contro la proposta in qualsiasi momento. Una volta che una transazione di prelievo supera la soglia (13150 blocchi), la transazione di prelievo viene ufficialmente eseguita e confermata dalla catena principale di Bitcoin.
In effetti, i minatori hanno il controllo completo sui fondi sulla Drivechain. Se i fondi vengono rubati, gli utenti possono salvarsi solo tramite UASF (soft fork attivato dall'utente), ma su questo è molto difficile raggiungere il consenso. Inoltre, la posizione unica dei miner in Drivechain aggrava i rischi MEV, come già dimostrato nel caso Ethereum.
Catena spaziale
Spacechain ha adottato un approccio diverso, utilizzando il Perpetual 1 way peg (P1WP). Gli utenti bruciano BTC per ottenere token su Spacechain, saltando direttamente la questione della sicurezza del fondo. Questo token può essere utilizzato solo per mettere all'asta lo spazio di blocco sulla spacechain e non ha alcuna funzione di memorizzazione del valore.
Per garantire la sicurezza della catena laterale, Spacechain utilizza il blind merge mining e altri utenti utilizzano ANYPREVOUT (APO) per fare offerte pubbliche per competere per il diritto di creare blocchi. I minatori Bitcoin devono solo impegnare l'intestazione del blocco Spacechain nel blocco senza verificare la catena laterale. Tuttavia, il lancio di Spacechain richiede il supporto di Covanent e la comunità Bitcoin sta ancora discutendo sulla necessità di un soft fork per aggiungere il codice operativo Covanent.
In generale, Spacechain può realizzare una catena laterale con le stesse proprietà di decentralizzazione e resistenza alla censura di Bitcoin e maggiore programmabilità attraverso la funzione di offerta per blocchi su Bitcoin.
Softchain
Softchain è una proposta di catena laterale 2wp proposta dall'autore di Spacechain Ruben Somsen. Utilizza il meccanismo di consenso PoW FP per garantire la sicurezza della catena laterale. In circostanze normali, il nodo completo di Bitcoin deve solo scaricare l'intestazione del blocco della softchain e verificare la prova di lavoro. Quando si verifica un fork, scarica il blocco orfano e il corrispondente impegno del set UTXO per verificare la validità del blocco.
Per il meccanismo 2wp, durante il peg-in, viene creata una transazione di deposito sulla catena principale e si fa riferimento alla transazione della catena principale sulla softchain per ottenere fondi durante il peg-out, viene creata una transazione di prelievo sulla softchain e il la transazione viene referenziata sulla catena principale per recuperare i fondi e il processo di prelievo deve attendere un lungo periodo di sfida prima di poter essere completato. I meccanismi specifici di peg-in e peg-out richiedono il supporto soft fork, quindi la soluzione si chiama Softchain.
La soluzione Softchain impone costi di verifica aggiuntivi su tutti i nodi della rete principale Bitcoin. La divisione del consenso di Softchain può influenzare il raggiungimento del consenso della rete principale e diventare un possibile mezzo di attacco alla rete principale Bitcoin.
Rete fulminea
Lightning Network ha pubblicato un white paper nel 2015 ed è stato lanciato ufficialmente nel 2018. Essendo un protocollo di pagamento p2p Layer 2 su Bitcoin, mira a trasferire un gran numero di transazioni di piccolo importo e ad alta frequenza all'elaborazione off-chain da molto tempo è considerata la tecnologia più avanzata della rete Bitcoin, un piano di espansione promettente.
modulo principale
L'implementazione di Lightning Network è inseparabile da diversi moduli importanti in Bitcoin, che insieme garantiscono la sicurezza delle transazioni di Lightning Network.
La prima è la transazione pre-firmata. Le transazioni prefirmate sono diventate sicure e disponibili solo dopo l'aggiornamento di SegWit. SegWit separa le firme dal resto dei dati della transazione, risolvendo problemi come potenziali dipendenze circolari, manomissione delle transazioni di terze parti e manomissione delle transazioni di seconde parti. La sicurezza informatica nella catena Lightning Network è garantita dall'impegno irrevocabile assunto dalla controparte, e questo impegno si realizza attraverso transazioni prefirmate. Dopo aver ricevuto la transazione prefirmata fornita dall'altra parte, l'utente può trasmettere la transazione alla catena in qualsiasi momento per completare l'adempimento della promessa.
Il secondo è la multifirma. I frequenti trasferimenti di fondi fuori catena tra due parti richiedono un vettore. Questo vettore richiede che entrambe le parti mantengano determinati diritti di controllo, quindi sono necessarie firme multiple. Generalmente viene utilizzata la firma multipla 2/2, che garantisce il trasferimento di fondi deve avvenire con il consenso reciproco di entrambe le parti.
Tuttavia, la firma multipla 2/2 causerà problemi di attività, ovvero se l'altra parte non collabora, l'utente non potrà trasferire alcuna risorsa dall'indirizzo con firma multipla, con conseguente perdita dei fondi originali. I blocchi temporali possono risolvere il problema della vitalità. Firmando preventivamente un contratto con un blocco temporale per la restituzione dei fondi, è possibile garantire che anche se una parte diventa inattiva, l'altra parte può recuperare i fondi iniziali.
Infine, c'è l'hash lock, che può connettere più canali di stato e costruire una rete. L'immagine originale dell'hash verrà utilizzata come mezzo di comunicazione per coordinare il corretto funzionamento di più entità.
Esegui il processo
canale bidirezionale
Entrambe le parti che utilizzano la rete Lightning per condurre transazioni devono prima aprire un canale di pagamento bidirezionale su Bitcoin. Entrambe le parti possono eseguire un numero qualsiasi di transazioni fuori dalla catena. Dopo che tutte le transazioni sono state completate, lo stato più recente verrà inviato alla catena Bitcoin per completare la liquidazione e chiudere il corridoio.
Nello specifico, l’implementazione dei canali di pagamento prevede i seguenti passaggi chiave:
Crea un indirizzo con firma multipla. Entrambe le parti del canale devono prima creare un indirizzo con firma multipla 2 su 2 come indirizzo di blocco dei fondi del canale. Ciascuna parte detiene una chiave privata di firma e fornisce la propria chiave pubblica.
Inizializza il canale. Entrambe le parti trasmettono una transazione sulla catena e bloccano una certa quantità di Bitcoin nell'indirizzo multi-firma come fondi iniziali del canale. Questa transazione è chiamata transazione "di ancoraggio" del canale.
Aggiorna lo stato del canale. Quando si effettua un pagamento all'interno del canale, entrambe le parti aggiornano lo stato del canale scambiando transazioni prefirmate. Ogni aggiornamento genererà una nuova "transazione di impegno", che rappresenta lo stato attuale dell'allocazione dei fondi. La transazione di impegno ha due output, corrispondenti alle quote del fondo di entrambe le parti.
Trasmetti lo stato più recente. Ciascuna delle parti del canale può trasmettere l’ultima transazione di impegno alla blockchain in qualsiasi momento per ritirare la propria quota di fondi. Per evitare che l'altra parte trasmetta il vecchio stato, ogni transazione di impegno ha una corrispondente "transazione di punizione". Se l'altra parte imbroglia, puoi ottenere tutti i fondi dell'altra parte.
Chiudi il canale. Quando due parti decidono di chiudere un canale, possono cooperare per generare una "transazione di regolamento" che trasmette lo stato finale della distribuzione dei fondi alla blockchain. In questo modo, i fondi bloccati nell’indirizzo multifirma vengono restituiti agli indirizzi personali di entrambe le parti.
Arbitrato on-chain. Se le due parti non riescono a raggiungere un accordo al momento della chiusura del canale, ciascuna delle parti può trasmettere unilateralmente l'ultima transazione di impegno e avviare il processo di arbitrato on-chain. Se non ci sono obiezioni entro un certo periodo di tempo (ad esempio 1 giorno), i fondi verranno inviati ad entrambe le parti in base all'allocazione della transazione impegnata.
rete di pagamento
I canali di pagamento possono essere collegati tra loro per formare una rete, che supporta il routing multi-hop, implementato tramite HTLC. HTLC utilizza il blocco dell'hash come condizione diretta e il pagamento della firma con blocco temporale come condizione di backup. Gli utenti possono interagire sull'immagine originale con hash prima della scadenza del blocco temporale.
Quando non esiste un canale diretto tra due utenti, il pagamento può essere completato con l'aiuto di HTLC tra router. L’hash preimage R gioca un ruolo chiave nell’intero processo, garantendo l’atomicità del pagamento. Allo stesso tempo, il blocco temporale di HTLC è destinato a diminuire lungo il percorso, garantendo che ogni hop abbia tempo sufficiente per elaborare e inoltrare il pagamento.
I problemi
In sostanza, Lightning Network elude il presupposto di fiducia esterna del bridging delle risorse attraverso canali statali p2p, utilizzando script di blocco temporale per fornire la massima garanzia delle risorse e fornire protezione dai guasti. Quando l’altra parte perde l’attività e non collabora, è possibile completare il ritiro unilaterale. Pertanto, Lightning Network ha un valore elevato negli scenari di pagamento, ma presenta anche molte limitazioni, tra cui:
Limite di capacità del canale. La capacità del canale di pagamento nella Lightning Network è limitata dai fondi iniziali bloccati e non può supportare pagamenti di grandi dimensioni che superano la capacità del canale. Ciò potrebbe limitare alcuni scenari applicativi, come il commercio di materie prime.
Online e sincronizzato. Per ricevere e inoltrare i pagamenti in modo tempestivo, i nodi Lightning Network devono rimanere online. Se un nodo è offline per un lungo periodo, potrebbe perdere alcuni aggiornamenti sullo stato del canale, causando la non sincronizzazione dello stato. Ciò può rappresentare una sfida per i singoli utenti e i dispositivi mobili e aumenta anche il costo delle operazioni dei nodi.
Gestione della liquidità. L'efficienza del routing del Lightning Network si basa sulla distribuzione della liquidità dei canali. Se i fondi vengono distribuiti in modo non uniforme, alcuni percorsi di pagamento potrebbero fallire, influenzando l'esperienza dell'utente. La gestione del saldo di liquidità del canale richiede alcuni costi tecnici e di capitale.
Violazione della privacy. Per trovare i percorsi di pagamento disponibili, l’algoritmo di routing di Lightning Network richiede un certo livello di conoscenza della capacità del canale e delle informazioni sulla connettività. Ciò potrebbe rivelare la privacy di alcuni utenti, come la distribuzione dei fondi, le controparti, ecc. L'apertura e la chiusura dei canali di pagamento possono anche esporre informazioni sui partecipanti rilevanti.
RGB
L'idea originale del protocollo RGB è stata ispirata dai concetti di verifica lato client e di sigillatura una tantum proposti da Peter Todd. È stato proposto da Giacomo Zucco nel 2016. Si tratta di un protocollo Bitcoin di secondo livello scalabile e che preserva la privacy. .
idea principale
Verifica del cliente
Il processo di verifica della blockchain consiste nel trasmettere a tutti i blocchi composti da transazioni, consentendo a ciascun nodo di calcolare le transazioni nel blocco e completare la verifica. Ciò crea in realtà un bene pubblico, ovvero i nodi della rete aiutano ogni individuo che invia una transazione a completare la verifica e gli utenti forniscono BTC come commissione di gestione come incentivo per aiutare con la verifica. La verifica lato client è più centrata sull'individuo. La verifica dello stato non viene eseguita a livello globale, ma viene verificata da individui che partecipano a transizioni di stato specifiche. Solo le parti che generano la transazione verificano la validità della transizione di stato. Ciò migliora significativamente la privacy e la riduce il carico sui nodi e migliora la scalabilità.
Sigillo usa e getta
Esiste un pericolo nascosto nella transizione di stato punto a punto Se gli utenti non riescono a raccogliere la cronologia completa delle transizioni di stato, potrebbero essere truffati e spendere due volte. Per risolvere questo problema viene proposta la sigillatura usa e getta. Utilizza un oggetto speciale che può essere utilizzato solo una volta per garantire che non si verifichi una doppia spesa e migliorare la sicurezza. L'UTXO di Bitcoin è l'oggetto sigillato una tantum più adatto, garantito dal meccanismo di consenso di Bitcoin e dalla potenza di calcolo dell'intera rete, in modo che le risorse RGB possano ereditare la sicurezza di Bitcoin.
Promessa crittografica
Il sigillo una tantum deve essere combinato con l’impegno di crittografia per garantire che l’utente conosca la transizione di stato ed evitare il verificarsi di attacchi a doppia spesa. Il cosiddetto impegno consiste nell'informare gli altri che qualcosa è successo e non può essere modificato in seguito, ma non è necessario esporre eventi specifici fino al momento in cui è richiesta la verifica. Possiamo utilizzare una funzione hash per prendere un impegno. In RGB, il contenuto dell'impegno è la transizione di stato. Attraverso la spesa di UTXO, il destinatario dell'asset RGB riceverà il segnale di trasferimento dello stato, quindi verificherà l'impegno rispetto ai dati specifici trasmessi off-chain da chi spende l'impegno. risorsa.
processo di lavoro
RGB utilizza il consenso di Bitcoin per garantire la sicurezza della doppia spesa e la resistenza alla censura, e tutta la verifica dei trasferimenti statali viene trasferita fuori catena e verificata solo dal cliente che accetta il pagamento.
Per l'emittente di asset RGB, è necessario creare un contratto RGB avviando una transazione e l'impegno delle informazioni specifiche verrà archiviato nello script OP_RETURN di una determinata condizione di spesa nella transazione Taproot.
Quando il detentore di un bene RGB vuole spendere, deve ottenere le informazioni rilevanti dal destinatario del bene, creare una transazione RGB, impegnare i dettagli della transazione RGB e inserire il valore dell'impegno nell'UTXO specificato dal destinatario del bene . ed emette una transazione che spende l'UTXO originale e crea l'UTXO specificato dal destinatario. Quando il destinatario dell'asset osserva che l'UTXO che originariamente memorizzava l'asset RGB è esaurito, può verificare la validità della transazione RGB attraverso l'impegno nella transazione Bitcoin. Una volta che la verifica è valida, crede di aver effettivamente ricevuto l'asset Risorsa RGB.
Per il destinatario delle risorse RGB, il pagatore deve fornire lo stato iniziale e le regole di transizione statale del contratto, le transazioni Bitcoin utilizzate per ciascun trasferimento, le transazioni RGB impegnate da ciascun scambio Bitcoin e la validità di ciascuna transazione Bitcoin. verificato dal client del destinatario sulla base di questi dati, verifica la validità della transazione RGB. Tra questi, l'UTXO di Bitcoin viene utilizzato come contenitore per salvare lo stato del contratto RGB. La cronologia dei trasferimenti di ciascun contratto RGB può essere espressa come un grafico aciclico diretto. Il destinatario dell'asset RGB può ottenere solo le informazioni relative all'RBG patrimonio che detiene, e non può accedere ad altre filiali.
Vantaggi e svantaggi
Verifica leggera
Rispetto alla verifica completa della blockchain, il protocollo RGB riduce notevolmente il costo della verifica. Gli utenti non devono attraversare tutti i blocchi storici per ottenere lo stato più recente, ma devono solo sincronizzare i record storici relativi agli asset che ricevono da verificare. l'efficacia della transazione.
Questa verifica leggera semplifica le transazioni peer-to-peer, eliminando ulteriormente la necessità di fornitori di servizi centralizzati e aumentando il livello di decentralizzazione.
Scalabilità
Il protocollo RGB eredita la sicurezza di Bitcoin solo attraverso l'impegno di un hash. Attraverso gli script Taproot, non c'è quasi alcun consumo di spazio aggiuntivo sulla catena Bitcoin, il che rende possibile una complessa programmabilità delle risorse. Grazie all'utilizzo di UTXO come contenitore, il protocollo RGB ha una concorrenza naturale. Le risorse RGB su diversi rami di trasferimento non si bloccheranno a vicenda e potranno essere spese contemporaneamente.
Privacy
A differenza dei protocolli generali, solo il destinatario dei beni RGB può ottenere lo stato di trasferimento storico dei beni RGB. Una volta completata la spesa, non è possibile ottenere lo stato di trasferimento futuro, il che garantisce in modo significativo la privacy dell'utente. Non esiste alcuna correlazione tra la transazione di asset RGB e il trasferimento di Bitcoin UTXO, e altri non possono ottenere tracce di transazioni RGB sulla catena Bitcoin.
Inoltre, RGB supporta anche le spese cieche e il pagatore non può sapere in quale UTXO verranno versate le risorse RGB, migliorando ulteriormente la privacy e rafforzando la resistenza alla censura.
insufficiente
Quando le risorse RGB cambiano di mano molte volte, i nuovi utenti che ricevono risorse saranno costretti a verificare una lunga cronologia di trasferimento, con conseguente onere di verifica più pesante, il tempo di verifica potrebbe essere più lungo e la capacità di confermare rapidamente viene persa. Per i nodi che rimangono in esecuzione nella blockchain, poiché l'ultimo stato è sempre sincronizzato, il tempo per ricevere il trasferimento rapido dello stato di verifica della nuova zona è ogni volta limitato.
La comunità sta discutendo la possibilità di riutilizzare i calcoli storici e ZK Proof ricorsivo ha l'opportunità di ottenere una verifica costante dello stato temporale e dimensionale.
Rollup
Panoramica
Rollup è la migliore soluzione di espansione a cui è arrivato l'ecosistema Ethereum dopo anni di esplorazione, dai canali statali a Plasma e infine a Rollup.
Rollup è una blockchain indipendente che raccoglie transazioni al di fuori della catena Bitcoin, impacchetta più transazioni in un batch e le esegue, quindi invia i dati e gli impegni sullo stato di questo batch alla catena principale, realizzando transazioni fuori catena e aggiornamenti di stato. Per ottenere la massima espansione, Rollup utilizza solitamente in questa fase un sequenziatore centralizzato per migliorare l'efficienza di esecuzione senza perdere la sicurezza, perché la sicurezza è garantita dalla verifica delle transizioni di stato di Rollup sulla catena principale.
Man mano che la soluzione Rollup dell’ecosistema Ethereum matura, anche l’ecosistema Bitcoin ha iniziato a sperimentare Rollup. Tuttavia, la differenza più critica tra Bitcoin ed Ethereum è la mancanza di capacità di programmazione e l’incapacità di eseguire i calcoli richiesti per costruire Rollup sulla catena. Ciò fa sì che le persone attualmente cerchino solo di implementare Rollup sovrano e OP Rollup.
Classificazione
In base ai diversi metodi di verifica del trasferimento di stato, il Rollup può essere suddiviso in due categorie principali, Rollup Ottimistico e Rollup di Validità (ZK Rollup).
Optimistic Rollup adotta un metodo di verifica ottimistico. Durante il periodo di controversia dopo l'invio di ciascun batch di transazioni, chiunque può controllare i dati fuori catena, sollevare obiezioni a batch di transazioni problematici, inviare prove di frode alla catena principale e rinunciare al Sequencer. Se non esiste alcuna prova di frode valida dopo il periodo di controversia, 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 completare la verifica e Sequencer utilizza un algoritmo di prova a conoscenza zero per generare una prova di validità concisa per ogni batch di transazioni, dimostrando che il trasferimento dello stato del batch è corretto a cui ogni aggiornamento deve inviare il batch di transazioni la catena principale prova di validità, la catena principale verifica la prova e quindi comprende e conferma l'aggiornamento dello stato.
Il vantaggio di Optimistic Rollup è che è relativamente semplice da implementare e richiede meno modifiche alla catena principale. Ma ha tempi di conferma della transazione più lunghi (a seconda del periodo di opposizione) e richiede una maggiore disponibilità dei dati. Le transazioni di rollup di validità vengono confermate rapidamente, non si basano su periodi di obiezione e i dati delle transazioni possono rimanere privati, ma generare e verificare prove a conoscenza zero richiede un elevato sovraccarico computazionale.
Celestia ha anche proposto il concetto di rollup sovrano. I dati delle transazioni del rollup vengono pubblicati su una blockchain di livello DA dedicata, che è responsabile della disponibilità dei dati, e il rollup sovrano stesso è responsabile dell'esecuzione e del regolamento.
Esplora e discuti
Il rollup su Bitcoin è ancora nelle sue fasi iniziali. A causa delle differenze tra il modello contabile e il linguaggio di programmazione e Ethereum, è difficile copiare direttamente l'esperienza pratica di 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 i rollup sovrani Bitcoin. I creatori di rollup sovrani possono pubblicare dati sulla disponibilità su Bitcoin tramite Rollkit.
Rollkit si ispira agli Ordinali e pubblica i dati tramite transazioni Taproot. Una transazione Taproot standard tramite il mempool pubblico può contenere fino a 390 KB di dati e una transazione Taproot non standard emessa direttamente da un miner può contenere quasi 4 MB di dati arbitrari.
Il vero compito di Rollkit è fornire un'interfaccia affinché Rollup sovrano possa leggere e scrivere dati su Bitcoin, fornire servizi middleware ai clienti e trasformare Bitcoin in un livello DA.
L’idea di un rollup sovrano è stata accolta con molto scetticismo, con molti oppositori che sostengono che un rollup sovrano su Bitcoin non sia altro che usare Bitcoin come bacheca e completamente incapace di ereditare la sicurezza di Bitcoin. Infatti, se invii a Bitcoin solo i dati delle transazioni, puoi solo migliorare la liveness, cioè tutti gli utenti possono ottenere i dati corrispondenti per la verifica tramite Bitcoin, ma la sicurezza può essere definita solo dal Rollup sovrano stesso e non può essere ereditata. Inoltre, lo spazio dei blocchi è prezioso su Bitcoin e l’invio di dati completi sulle transazioni potrebbe non essere una buona decisione.
Rollup OP e rollup validità
Sebbene molti progetti Bitcoin di secondo livello si definiscano ZK Rollup, che è essenzialmente più vicino a un OP Rollup, ma coinvolge la tecnologia Validity Proof nel processo, le capacità di programmazione di Bitcoin non sono ancora sufficienti per supportare la verifica diretta della Validity Proof.
Attualmente, l'insieme di codici operativi di Bitcoin è molto limitato e non può nemmeno calcolare direttamente la moltiplicazione. La verifica della prova di validità richiede l'espansione dei codici operativi e fa molto affidamento anche sull'implementazione di contratti ricorsivi. Quelli attualmente discussi nella comunità includono OP_CAT, OP_CHECKSIG. OP_TXHASH ecc. Naturalmente, se potessimo aggiungere direttamente un OP_VERIFY_ZKP, forse non avremmo bisogno di altre modifiche, ma questo è ovviamente improbabile. Inoltre, le limitazioni sulla dimensione dello stack ostacolano anche gli sforzi per verificare la prova di validità negli script Bitcoin e molti tentativi vengono esplorati.
Allora come funziona la prova di validità? La maggior parte dei progetti pubblica lo statediff e la prova di validità dei batch di transazioni su Bitcoin sotto forma di iscrizioni e utilizza BitVM per la verifica ottimistica. BitVM Bridge sostituisce qui la tradizionale soluzione multi-firma. The Bridge Operator formerà un'alleanza di N persone per programmare i depositi degli utenti. Prima che gli utenti effettuino un deposito, l'alleanza dovrà prefirmare l'UTXO da generare per garantire che il deposito possa essere legalmente riscosso solo dall'Operatore. Dopo aver ottenuto la pre-firma, BTC verrà bloccato su un indirizzo Taproot multi-firma N/N.
Quando un utente emette una richiesta di prelievo, Rollup invierà la prova di validità con Root di ritiro alla catena Bitcoin. L'Operatore soddisferà prima le esigenze di prelievo dell'utente di tasca propria, quindi ne verificherà la validità tramite il contratto BitVM. Se ciascun Operatore ritiene che il certificato sia valido, l'Operatore verrà rimborsato tramite multifirma, purché qualcuno ritenga che ci sia una frode, verrà avviato un processo di contestazione e la parte sbagliata verrà detronizzata;
Questo processo è in realtà lo stesso di OP Rollup. Il presupposto di attendibilità è 1/N Finché un verificatore è onesto, il protocollo è sicuro.
Tuttavia, potrebbero esserci difficoltà nell'implementazione tecnica di questa soluzione. Nel progetto OP Rollup di Ethereum, Arbitrum è stato sviluppato per molti anni e l'attuale Fraud Proof è ancora presentato da nodi autorizzati. Optimism ha annunciato solo di recente che supporta Fraud Proof, il che dimostra quanto sia difficile da implementare;
Per quanto riguarda l'operazione pre-firmata nel bridge BitVM, con il supporto di Bitcoin Covanent, può essere implementata in modo più efficiente, che è ancora in attesa del consenso della comunità.
In termini di attributi di sicurezza, inviando l'hash del blocco Rollup a Bitcoin, si ottiene la resistenza alla riorganizzazione e alla doppia spesa, e l'uso dell'Optimistic Bridge porta un presupposto di sicurezza 1/N. Tuttavia, la resistenza alla censura del bridge può ancora attendere ulteriori sviluppi.
Conclusione: il livello 2 non è una panacea
Osservando così tante soluzioni di livello 2, possiamo facilmente scoprire che ciascuna soluzione è limitata nelle attività che può svolgere. Sotto determinati presupposti di fiducia, gli effetti che il Livello 2 può ottenere dipendono in gran parte dal Livello 1, ovvero dalle capacità native di Bitcoin.
Senza aggiornamenti SegWit e blocchi temporali, la rete Lightning non può essere costruita con successo; senza aggiornamenti Taproot, gli impegni RGB non possono essere inviati con successo senza OP_CAT e altri Covanent, il Validity Rollup su Bitcoin non può essere costruito con successo...
Molti Bitcoin Maxi credono che Bitcoin non dovrebbe mai essere modificato e che non dovrebbero essere aggiunte nuove funzionalità. Tutti i difetti dovrebbero essere risolti dal Livello 2. Questo è impossibile. Il Livello 2 non è una panacea. Abbiamo bisogno di un Layer 1 più potente per costruire un Layer 2 più sicuro, efficiente e scalabile.
Nel prossimo articolo presenteremo i tentativi di migliorare la programmabilità su Bitcoin, quindi rimanete sintonizzati.
