Scritto da: Hakeen
1. Roadmap di aggiornamento di Ethereum M2SVPS
La fusione
Nella fase di fusione, il meccanismo di consenso POW passerà al POS e le catene di beacon verranno unite insieme. Per facilità di comprensione, semplifichiamo la struttura di Ethereum nella figura seguente:
Definiamo innanzitutto cos'è lo sharding: una semplice comprensione è il processo di divisione orizzontale del database per distribuire il carico.
Dopo il passaggio al POS: i proponenti dei blocchi e i validatori dei blocchi sono separati, e il flusso di lavoro POS è il seguente (inteso in base alla figura sopra):
Le transazioni vengono impegnate sui validatori rollup aggiungono transazioni ai blocchi di shard La catena beacon seleziona i validatori per proporre nuovi blocchi I validatori rimanenti formano comitati casuali e convalidano le proposte sugli shard
Sia la proposta di un blocco che la dimostrazione della proposta devono essere completate entro uno slot, che solitamente è di 12 secondi. Ogni 32 slot costituiscono un ciclo di epoca e ogni epoca interromperà l'ordine dei validatori e rieleggerà il comitato.
Dopo la fusione, Ethereum implementerà la separazione proponente-costruttore (PBS) per il livello di consenso. Vitalik ritiene che l'obiettivo finale di tutte le blockchain sarà quello di avere una produzione centralizzata dei blocchi e una verifica decentralizzata dei blocchi. Poiché i blocchi di Ethereum richiedono un elevato utilizzo di dati dopo lo sharding, è necessaria la centralizzazione della produzione dei blocchi a causa degli elevati requisiti di disponibilità dei dati. Allo stesso tempo, deve esserci una soluzione in grado di gestire un set decentralizzato di validatori in grado di convalidare i blocchi ed eseguire il campionamento della disponibilità dei dati.
Separazione dei minatori e verifica dei blocchi. I minatori costruiscono i blocchi e poi li inviano ai validatori. Si fa un'offerta al validatore per selezionare il proprio blocco, dopodiché il validatore vota per decidere se il blocco è valido.
Lo sharding è un metodo di partizionamento che consente di distribuire attività di elaborazione e carichi di lavoro di archiviazione in una rete P2P. Con questo metodo di elaborazione, ciascun nodo non è responsabile della gestione del carico di transazioni dell'intera rete, ma deve solo gestire le informazioni relative alla propria partizione (o frammento). Ogni frammento ha la propria rete di validatori o nodi.
Problemi di sicurezza dello sharding: ad esempio, se l'intera rete ha 10 catene di shard e per distruggere l'intera rete è necessario il 51% della potenza di calcolo, per distruggere un singolo shard basterà il 5,1% della potenza di calcolo. Per questo motivo, i miglioramenti successivi includono un algoritmo SSF, in grado di prevenire efficacemente gli attacchi che limitano la potenza di calcolo del 51%. Secondo Vitalik, il passaggio a SSF è un percorso che richiederà diversi anni e, nonostante il lavoro svolto, sarà uno dei principali cambiamenti che Ethereum implementerà in seguito, molto tempo dopo che il meccanismo di prova PoS, lo sharding e il Verkle Tree di Ethereum saranno completamente lanciati.
La beacon chain è responsabile della generazione di numeri casuali, dell'assegnazione di nodi ai frammenti, dell'acquisizione di istantanee di singoli frammenti e di varie altre funzioni. È responsabile del completamento della comunicazione tra i frammenti e del coordinamento della sincronizzazione della rete.
Le fasi di esecuzione della catena di beacon sono le seguenti:
I produttori di blocchi si impegnano a fornire l'intestazione del blocco insieme all'offerta. Il creatore di blocchi (validatore) sulla catena di beacon seleziona l'intestazione del blocco vincente e fa un'offerta, e riceverà incondizionatamente la commissione per l'offerta vincente indipendentemente dal fatto che il confezionatore di blocchi generi o meno il corpo del blocco. Il comitato (scelto casualmente tra i validatori) vota per confermare l'intestazione del blocco ottenuta. Il confezionatore di blocchi rivela il corpo del blocco.
L'ondata
L'obiettivo principale di questo percorso è promuovere l'espansione incentrata su Rollup. Surge si riferisce all'aggiunta dello sharding di Ethereum, una soluzione di scalabilità che, secondo la Ethereum Foundation, consentirà di realizzare blockchain di secondo livello con commissioni del gas ridotte, ridurrà il costo dei rollup o delle transazioni in bundle e renderà più semplice per gli utenti gestire i nodi che proteggono la rete Ethereum.
Il diagramma può essere ancora compreso attraverso il seguente schema semplificato:
Prendiamo come esempio il principio di funzionamento di zkrollup: zkrollup è suddiviso in un sequenziatore e un aggregatore. Il sequenziatore è responsabile dell'ordinamento delle transazioni degli utenti, del loro confezionamento in batch e del loro invio all'aggregatore. L'aggregatore esegue la transazione, genera la radice dello stato successivo dalla radice dello stato precedente e quindi genera la prova. L'aggregatore invia infine la radice dello stato precedente, la radice dello stato successivo, i dati della transazione e la prova al contratto su L1. Il contratto è responsabile della verifica della validità della prova. I dati della transazione vengono memorizzati in calldata. La disponibilità dei dati di Zkrollup consente a chiunque di ripristinare lo stato globale di un account in base ai dati delle transazioni archiviati sulla catena.
Tuttavia, il costo dell'utilizzo di calldata è molto elevato, quindi l'intero protocollo EIP-4844 (che potrebbe cambiare in qualsiasi momento) propone di modificare la dimensione dei blocchi di transazione a 1-2 MB, gettando solide basi per futuri rollup e sharding dei dati. Attualmente, la dimensione del blocco di Ethereum è di circa 60 KB ~100 KB. Prendendo come esempio EIP-4844, il limite della dimensione del blocco può essere aumentato di circa 10~34 volte. Questo formato di blocco è chiamato blob (chiamato anche frammento di dati).
Il flagello
In questa fase, Scourge è un'integrazione alla roadmap e viene utilizzato principalmente per risolvere i problemi MEV. Cos'è quindi il MEV?
MEV è l'acronimo di Miner Extractable Value / Maximal Extractable Value. Questo concetto è stato applicato per la prima volta nel contesto della prova di lavoro e originariamente era chiamato "Miner Extractable Value". Questo perché nella proof of work i miner hanno capacità di ruolo quali l'inclusione, l'esclusione e l'ordinamento delle transazioni. Tuttavia, dopo la transizione a Proof of Stake tramite fusione, i validatori saranno responsabili di questi ruoli e il mining non sarà più applicabile (il metodo di estrazione del valore descritto qui rimarrà anche dopo questa transizione, da qui il cambio di nome). Per continuare a utilizzare lo stesso acronimo e garantire continuità mantenendone allo stesso tempo il significato di base, ora si utilizza "Maximal Extractable Value" come alternativa più inclusiva.
Le opportunità di arbitraggio includono:
Comprimendo lo spazio di archiviazione si ottiene la differenza di prezzo delle tariffe del gas; Prelazione dell'arbitro: effettuando una ricerca approfondita delle transazioni sul mempool, la macchina esegue calcoli localmente per vedere se sarà redditizia. In tal caso, avvia la stessa transazione con il proprio indirizzo e utilizza una commissione del gas più elevata; Alla ricerca di obiettivi di liquidazione: i robot competono per analizzare i dati della blockchain il più rapidamente possibile per determinare quali mutuatari possono essere liquidati, per poi diventare i primi a inviare una transazione di liquidazione e riscuotere autonomamente la commissione di liquidazione. Transazioni sandwich: i ricercatori monitorano le transazioni di grandi dimensioni sui DEX all'interno del pool di memoria. Ad esempio, qualcuno vuole acquistare 10.000 UNI utilizzando DAI su Uniswap. Transazioni così grandi avrebbero un impatto significativo sulla coppia UNI/DAI, aumentando potenzialmente in modo significativo il prezzo di UNI rispetto a DAI. Un ricercatore può calcolare l'impatto approssimativo sul prezzo di una grande operazione sulla coppia UNI/DAI ed eseguire il miglior ordine di acquisto immediatamente prima della grande operazione, acquistando UNI a un prezzo basso, e quindi eseguire un ordine di vendita immediatamente dopo la grande operazione, vendendo al prezzo più alto causato dall'ordine di grandi dimensioni.
Svantaggi del MEV:
Alcune forme di MEV, come il sandwich trading, possono comportare un'esperienza utente notevolmente peggiore. Gli utenti che si trovano in una posizione intermedia devono far fronte a uno slittamento maggiore e a una peggiore esecuzione delle negoziazioni. A livello di rete, i front-runner comuni e le aste del gas a cui spesso partecipano (quando due o più pionieri competono per includere le proprie transazioni nel blocco successivo aumentando gradualmente le commissioni del gas delle proprie transazioni) portano alla congestione della rete e a commissioni del gas elevate per gli altri che cercano di eseguire transazioni legittime. Oltre a ciò che avviene all'interno di un blocco, il MEV può avere effetti dannosi anche tra blocchi diversi. Se il MEV disponibile in un blocco supera significativamente la ricompensa standard del blocco, i miner potrebbero essere incentivati a riesaminare i blocchi e ad accaparrarsi il MEV, con conseguente riorganizzazione della blockchain e instabilità nel consenso.
La maggior parte dei MEV viene estratta da partecipanti indipendenti alla rete chiamati "cercatori". I ricercatori eseguono algoritmi complessi sui dati della blockchain per individuare opportunità MEV redditizie e ci sono bot che inviano automaticamente queste transazioni redditizie alla rete. Il problema MEV su Ethereum riguarda l'uso di bot per sfruttare le transazioni sulla rete, causando congestione e commissioni elevate.
Il limite
Verge implementerà "Verkle tree" (una dimostrazione matematica) e "stateless client". Questi aggiornamenti tecnici consentiranno agli utenti di diventare validatori di rete senza dover memorizzare grandi quantità di dati sui propri computer. Questo è anche uno dei passaggi dell'espansione del rollup. Il semplice principio di funzionamento dello zk rollup è stato menzionato in precedenza. L'aggregatore ha inviato la prova e il contratto di verifica sul livello 1 deve solo verificare l'impegno KZG e la prova generata nel blob. Ecco una breve introduzione all'impegno di KZG, che consiste nel garantire l'inclusione di tutte le transazioni. Poiché rollup può inviare transazioni parziali e generare prove, se si utilizza KZG, si avrà la certezza che tutte le transazioni saranno incluse nella prova generata.
The Verge assicura che la verifica sia molto semplice. È sufficiente scaricare N byte di dati ed eseguire calcoli di base per verificare la prova inviata dal rollup.
Vale la pena ricordare che esistono numerose soluzioni per lo ZK rollup, come stark, snark o bulletproof. Ogni schema affronta la dimostrazione e la verifica in modo diverso, per cui emergono dei compromessi. SNARKs è attualmente più facile da usare e tecnologicamente più avanzato di STARKs, motivo per cui molti progetti inizialmente utilizzano SNARKs. Tuttavia, con l'evoluzione della tecnologia STARK, alla fine si ricorrerà a STARK resistenti agli attacchi quantistici. Sebbene uno dei principali miglioramenti di Ethereum EIP-4844 sia il formato di transazione blob per adattarsi al rollup, che espande la capacità del blocco, il principale collo di bottiglia di tutte le attuali dimostrazioni a conoscenza zero risiede ancora nei loro algoritmi di dimostrazione. Da un lato, il problema della dimostrazione viene risolto migliorando l'algoritmo, dall'altro, l'efficienza della dimostrazione viene migliorata impilando l'hardware, il che ha anche portato all'emergere del percorso di mining ZK. Chi fosse interessato può leggere questo articolo.
La Purga
Purge ridurrà la quantità di spazio necessario per archiviare ETH su un disco rigido, tentando di semplificare il protocollo Ethereum e di non richiedere ai nodi di archiviare la cronologia. Ciò può migliorare notevolmente la larghezza di banda della rete.
EIP-4444:
I client DEVONO smettere di fornire intestazioni, corpi e destinatari storici più vecchi di un anno tramite il livello P2P. I clienti possono eliminare localmente questi dati storici. Preservare la storia di Ethereum è fondamentale e credo che ci siano vari modi fuori banda per raggiungere questo obiettivo. I dati storici possono essere impacchettati e condivisi tramite collegamenti magnetici torrent o reti come IPFS. Inoltre, sistemi come Portal Network o The Graph possono essere utilizzati per ottenere dati storici. Il client dovrebbe consentire l'importazione e l'esportazione di dati storici. I clienti possono fornire script che recuperano/convalidano i dati e li importano automaticamente.
Lo sfizio
Questo percorso include principalmente alcune correzioni di ottimizzazione frammentarie, come l'astrazione dell'account, l'ottimizzazione EVM e lo schema di numeri casuali VDF.
L'astrazione degli account (AA) qui menzionata è sempre stata il primo obiettivo che il Layer 2 basato su ZK vuole raggiungere. Cos'è dunque l'astrazione dell'account? Dopo aver implementato l'astrazione dell'account, un account con contratto intelligente può anche avviare attivamente transazioni senza basarsi sul meccanismo di "meta transazione" (proposto in EIP-4844).
In Ethereum, gli account sono suddivisi in account contrattuali e account esterni. Attualmente, esiste un solo tipo di transazione in Ethereum, che deve essere avviata da un indirizzo esterno. L'indirizzo del contratto non può avviare attivamente una transazione. Pertanto, qualsiasi modifica nello stato del contratto stesso deve basarsi su una transazione avviata da un indirizzo esterno. Che si tratti di un account multi-firma, di un mixer o di qualsiasi modifica alla configurazione di uno smart contract, è necessario che venga attivato almeno da un account esterno.
Indipendentemente dall'applicazione utilizzata su Ethereum, gli utenti devono possedere Ethereum (e assumersi il rischio delle fluttuazioni del prezzo di Ethereum). In secondo luogo, gli utenti devono confrontarsi con logiche complesse relative a commissioni, prezzo del gas, limiti del gas, blocchi delle transazioni, concetti troppo complicati per gli utenti. Molti portafogli o applicazioni blockchain tentano di migliorare l'esperienza utente tramite l'ottimizzazione del prodotto, ma con scarsi risultati.
L'obiettivo della soluzione incentrata sull'account è creare un account per l'utente gestito sulla base di uno smart contract. I vantaggi dell'implementazione dell'astrazione dell'account sono:
I contratti odierni possono contenere ETH e inviare direttamente transazioni con tutte le firme. Gli utenti non devono necessariamente pagare commissioni sul gas per le transazioni. Tutto dipende dal progetto. Poiché è stata implementata la crittografia personalizzata, in futuro non sarà obbligatorio utilizzare la curva ellittica ESCDA per la firma. In futuro, il riconoscimento delle impronte digitali, il riconoscimento facciale, la biometria e altre tecnologie dei telefoni cellulari potranno essere utilizzate come metodi di firma. Ciò migliora significativamente l'esperienza di interazione dell'utente con Ethereum.
2. Modularità di Ethereum
L'intero Ethereum ha ormai mostrato una tendenza verso la modularizzazione e il livello di esecuzione è responsabilità del Livello 2 (come arbitrum, zksync, starknet, polygon zkevm, ecc.). Sono responsabili dell'esecuzione delle transazioni degli utenti su L2 e dell'invio delle prove. Il livello 2 utilizza generalmente la tecnologia OP/tecnologia ZK. In teoria, il TPS della tecnologia ZK è molto più elevato di quello della tecnologia OP. Attualmente, un gran numero di ecosistemi si trova nel sistema OP, ma in futuro, con il miglioramento della tecnologia ZK, sempre più applicazioni migreranno verso il sistema ZK. Questa sezione fornisce una descrizione dettagliata della tabella di marcia e integra il perché e il come.
Attualmente, Ethereum separa solo il livello di esecuzione e, di fatto, gli altri livelli sono ancora mescolati tra loro. Nella visione di Celestia, il livello di esecuzione fa solo due cose: per una singola transazione, esegue la transazione e ne modifica lo stato; per le transazioni nello stesso batch, calcola la radice dello stato del batch. Attualmente, parte del lavoro del livello di esecuzione di Ethereum è assegnato a Rollup, con cui abbiamo familiarità con StarkNet, zkSync, Arbitrum e Optimism.
Ora, che si tratti di Optimism, Polygon, Starknet, Zksync, ecc., stanno tutti esplorando la strada della modularizzazione.
L'ottimismo ha proposto lo stack bedrock/op, Polygon sta anche sviluppando Polygon Avail come livello di disponibilità dei dati e le supernet vengono utilizzate per semplificare la creazione di catene e set di validatori condivisi.
Livello di regolamento: può essere inteso come il processo mediante il quale il contratto Rollup sulla catena principale verifica la validità della radice dello stato precedente, della radice post-stato, della prova (zkRollup) o della prova di frode (Optimistic Rollup) sopra menzionate. Livello di consenso: indipendentemente dal fatto che vengano utilizzati PoW, PoS o altri algoritmi di consenso, il livello di consenso ha lo scopo di raggiungere un consenso su qualcosa in un sistema distribuito, ovvero di raggiungere un consenso sulla validità della transizione di stato (la radice dello stato precedente viene convertita nella radice dello stato successivo tramite calcolo). Nel contesto della modularizzazione, i significati del livello di insediamento e del livello di consenso sono in qualche modo simili, per cui alcuni ricercatori hanno unificato i due livelli. Livello di disponibilità dei dati: assicurarsi che i dati delle transazioni siano caricati completamente sul livello di disponibilità dei dati e che il nodo di verifica possa riprodurre tutte le modifiche di stato tramite i dati in questo livello.
Ciò che è necessario distinguere qui è la differenza tra disponibilità dei dati e archiviazione dei dati:
La disponibilità dei dati è diversa dall'archiviazione dei dati, in quanto la prima riguarda la disponibilità dei dati pubblicati nell'ultimo blocco, mentre la seconda implica l'archiviazione sicura dei dati e la garanzia che siano accessibili quando necessario.
1. Vari rollup sullo strato di liquidazione
Dal punto di vista del livello di insediamento, si ritiene attualmente che il focus del rollup sia sul sistema ZK. Se le dimensioni, il consumo di gas e il costo del sistema di prova ZK possono essere migliorati tramite il rollup ZK e poi combinati con la ricorsione e l'elaborazione parallela, il suo TPS può essere notevolmente ampliato. Quindi iniziamo con il rollup ZK.
Con l'avanzare dell'espansione di Ethereum, Vitalik ritiene che la tecnologia Zero Knowledge Proof (ZKP) possa rappresentare la soluzione definitiva nella battaglia per l'espansione.
L'essenza di una ZKP è quella di consentire a qualcuno di dimostrare di sapere o di avere qualcosa. Ad esempio, posso dimostrare di avere la chiave per aprire una porta senza doverla estrarre. Dimostrare di conoscere la password di un account senza doverla digitare e rischiare di essere scoperti ha implicazioni per la privacy personale, la crittografia, le aziende e persino il disarmo nucleare. Approfondisci la tua comprensione con una versione modificata del problema del milionario di Yao: questo problema riguarda due milionari, Alice e Bob, che vogliono sapere chi di loro è più ricco senza rivelare la loro effettiva ricchezza.
Supponendo che l'appartamento venga affittato a 1.000 dollari al mese, per qualificarsi come candidato all'affitto, dovresti pagare almeno 40 volte quella cifra di affitto. Quindi noi (inquilini) dobbiamo dimostrare che il nostro reddito annuo è superiore a $ 40.000. Ma il proprietario non vuole che troviamo scappatoie, quindi sceglie di non rivelare l'importo specifico dell'affitto. Il suo scopo è verificare se rispettiamo gli standard e la risposta è semplicemente sì o no; lui non è responsabile dell'importo specifico.
Ci sono ora dieci caselle, contrassegnate da $ 10.000 a $ 100.000 con incrementi di $ 10.000. Ognuno ha una chiave e uno slot. Il proprietario di casa è entrato nella stanza con la scatola e ha distrutto le 9 chiavi, prendendo quella della scatola con la scritta $40k.
Lo stipendio annuo dell'inquilino raggiunge i 75.000 dollari. L'agente bancario supervisiona l'emissione di un documento comprovante la presenza di beni, che non specifica i fondi specifici. L'essenza di questo documento è la dichiarazione patrimoniale della banca per verificare il documento di richiesta. Quindi mettiamo il file nel contenitore 10k-70k. Quindi, quando il proprietario usa la chiave da 40k per aprire la cassetta e vede i documenti di richiesta verificabili all'interno, determinerà che l'inquilino soddisfa i criteri.
I punti coinvolti qui includono il rilascio da parte del dichiarante (banca) di un certificato di conformità patrimoniale e il controllo da parte del verificatore (locatore) della verifica se l'inquilino è qualificato tramite la chiave. Ancora una volta, ci sono solo due opzioni per i risultati della verifica: qualificato e non idoneo. Non ci saranno e non potranno esserci requisiti relativi all'ammontare specifico dei beni dell'inquilino.
Possiamo ancora utilizzare il seguente diagramma per comprendere che le transazioni vengono eseguite sul livello 2 e inviate allo shard. Il livello 2 adotta generalmente la forma di rollup, ovvero più transazioni vengono impacchettate in un batch sul livello 2 per elaborare le transazioni e poi inviate allo smart contract rollup del livello 1. Ciò include le vecchie e le nuove radici di stato. Il contratto sul livello 1 verificherà se le due radici di stato corrispondono. Se corrispondono, la vecchia radice di stato sulla catena principale verrà sostituita con la nuova radice di stato. Come possiamo verificare che la radice dello stato ottenuta dopo l'elaborazione batch sia corretta? È qui che entrano in gioco l'optimistic rollup e lo zk rollup. La tecnologia Fraud proof e zk vengono utilizzate rispettivamente per confermare le transazioni e verificare le radici di stato.
In questo caso, il livello 2 (rollup) equivale al dichiarante (banca) nell'esempio precedente. La sua operazione di confezionamento è questa operazione di dichiarazione. Non dichiara l'importo specifico, ma conferma se lo standard è stato rispettato. Questo documento di dichiarazione rivendicabile viene confezionato e inviato al livello 1. La chiave per verificare lo stato nuovo e vecchio è che il locatore utilizzi la chiave per verificare se la solidità finanziaria dell'inquilino che si aspetta soddisfi i requisiti. Il problema della verifica della radice dello stato è come rendere credibile la dichiarazione presentata dalla banca.
Per i rollup ottimistici o a prova di frode, il contratto Rollup della catena principale registra un record completo delle modifiche alla radice dello stato interno del Rollup, nonché il valore hash di ogni elaborazione batch (che attiva le modifiche alla radice dello stato). Se qualcuno scopre che la nuova radice di stato corrispondente a un'elaborazione batch è errata, può pubblicare una prova sulla catena principale per dimostrare che la nuova radice di stato generata dall'elaborazione batch è errata. Il contratto verifica la prova e, se la verifica ha esito positivo, tutte le transazioni elaborate in batch successive a questo batch vengono annullate.
In questo caso, il metodo di verifica equivale alla presentazione da parte del dichiarante (banca) di un documento di dichiarazione patrimoniale verificabile, per poi rendere pubblici tutti i documenti patrimoniali sulla catena e rendere pubblici anche i dati sulla catena. Altri contendenti effettuano i calcoli in base ai dati originali per verificare se vi siano errori o falsificazioni nei documenti verificabili relativi alle attività. In caso di problemi, viene presentato un ricorso e, se il ricorso ha successo, vengono inoltrati reclami alla banca. La questione più importante in questo caso è dare il tempo al contestatore di raccogliere i dati e verificare l'autenticità del documento.
Per i Rollup che utilizzano la tecnologia Zero Knowledge Proof (ZKP), ogni elaborazione batch contiene una prova crittografica denominata ZK-SNARK. La banca utilizza la tecnologia di crittografia per generare documenti di dichiarazione patrimoniale. In questo modo non è necessario riservare tempo agli sfidanti e quindi non esiste il ruolo dello sfidante.
2. Motivi per cui il Rollup basato su ZK non è così buono come previsto
Attualmente è stato rilasciato Hermez della serie Polygon e sono state lanciate anche le reti principali di sviluppo zksync e starknet. Tuttavia, la velocità delle loro transazioni sembra essere ben lontana da quella che teoricamente immaginiamo. In particolare, gli utenti di starknet possono chiaramente percepire che la velocità della sua rete principale è sorprendentemente lenta. Il motivo è che è ancora molto difficile generare prove utilizzando la tecnologia di prova a conoscenza zero, il costo è ancora molto elevato e c'è anche la necessità di bilanciare la compatibilità di Ethereum e le prestazioni di zkevm. Il team di Polygon ha anche ammesso: "La versione testnet di Polygon zkEVM ha anche capacità di throughput limitate, il che significa che è lontana dalla sua forma finale come macchina di espansione ottimizzata".
3. Livello di disponibilità dei dati
I passaggi astratti di esecuzione di Ethereum sono i seguenti:
Nel processo di decentralizzazione di Ethereum, possiamo osservarlo anche nella roadmap di The Merge: validatori decentralizzati. La cosa più importante è diversificare la clientela, abbassare la soglia di ingresso della macchina e aumentare il numero di validatori. Pertanto, se alcuni validatori le cui macchine non soddisfano gli standard desiderano partecipare alla rete, possono utilizzare dei light client. Il principio di funzionamento dei nodi leggeri è quello di richiedere le intestazioni dei blocchi tramite i nodi completi vicini. I nodi leggeri devono solo scaricare e verificare le intestazioni dei blocchi. Se i nodi leggeri non partecipano, tutte le transazioni dovranno essere verificate dai nodi completi. Pertanto, i nodi completi devono scaricare e verificare ogni transazione nel blocco. Allo stesso tempo, con l'aumento del volume delle transazioni, aumenta anche la pressione sui nodi completi. Pertanto la rete di nodi tende gradualmente ad aumentare le prestazioni e la centralizzazione.
Il problema in questo caso è che un nodo completo dannoso può fornire un'intestazione di blocco mancante/non valida, mentre il nodo leggero non può falsificarla. Esistono due modi per risolvere questo problema. Inizialmente si utilizza la prova di frode. Per monitorare la validità del blocco è necessario un nodo completo attendibile. Dopo aver trovato un blocco non valido, viene creata una prova di frode. Se entro un determinato periodo di tempo non viene ricevuta alcuna prova di frode, l'intestazione del blocco viene considerata valida. Ma qui è ovviamente necessario un nodo completo attendibile, il che presuppone una configurazione attendibile o un presupposto di onestà. Tuttavia, se il produttore del blocco riesce a nascondere alcune transazioni, la prova della frode sarà ovviamente invalida, perché anche i nodi onesti si affidano ai dati del produttore del blocco. Se i dati stessi vengono nascosti, i nodi attendibili crederanno che i dati inviati siano tutti i dati e, naturalmente, non verrà generata alcuna prova di frode.
Mustarfa AI-Bassam e Vitalik hanno proposto una nuova soluzione: il codice di cancellazione in un articolo scritto a quattro mani. I codici di cancellazione vengono utilizzati per risolvere il problema della disponibilità dei dati. Ad esempio, Celestia e Polygon Avail utilizzano entrambi i codici di cancellazione Reed-Solomon. Ma come garantire che i dati trasmessi siano completi? Possiamo combinare l'impegno KZG con la prova di frode.
Grazie alla prova di impegno/frode del KZG è possibile garantire che i produttori di blocchi pubblichino dati completi e non nascondano le transazioni. I dati vengono quindi codificati tramite codici di cancellazione e quindi campionati per renderli disponibili, in modo che i nodi luminosi possano verificarli correttamente.
I dati inviati dall'aggregatore nel Rollup vengono memorizzati sulla catena sotto forma di calldata. Questo perché calldata è più economico di altre aree di archiviazione.
Costo chiamata dati in gas = Dimensione transazione × 16 gas per byte
La spesa principale di ogni transazione è il costo dei dati di chiamata, poiché l'archiviazione on-chain è estremamente costosa e rappresenta dall'80% al 95% del costo di rollup.
A causa di questo problema, abbiamo proposto il nuovo formato di transazione blob EIP-4844 per espandere la capacità del blocco e ridurre la commissione del gas richiesta per l'invio alla catena.
4. Livelli di disponibilità dei dati on-chain e off-chain
Come risolvere quindi il problema dei costosi dati on-chain? Esistono diversi modi:
Il primo è quello di comprimere la dimensione dei dati calldata caricati su L1 e a questo proposito sono state apportate numerose ottimizzazioni. Il secondo è ridurre i costi di archiviazione dei dati sulla catena, fornire "grandi blocchi" per i rollup tramite il proto-danksharding e il danksharding di Ethereum, fornire uno spazio di disponibilità dei dati più ampio e utilizzare codici di cancellazione e impegni KZG per risolvere il problema dei nodi leggeri. Come EIP-4844. La terza è quella di rendere i dati disponibili off-chain. Le soluzioni più comuni a questo problema includono Celestia/Polygon Avail, ecc.
In base alla posizione in cui sono archiviati i dati disponibili, li suddividiamo nella seguente figura:
La soluzione di Validium: rendere i dati disponibili off-chain, in modo che i dati delle transazioni siano gestiti da operatori centralizzati e gli utenti abbiano bisogno di impostazioni affidabili, ma il costo sarà molto basso e, allo stesso tempo, non ci sarà quasi nessuna sicurezza. Successivamente, sia Starkex che Arbitrum Nova hanno proposto di istituire DAC come responsabile dell'archiviazione dei dati sulle transazioni. I membri del DAC sono individui o organizzazioni ben noti all'interno di giurisdizioni legali e si presume che non colluderanno e non faranno del male.
Zkporter propone ai tutori (titolari di token zksync) di impegnarsi a mantenere la disponibilità dei dati. In caso di mancata disponibilità dei dati, i fondi promessi verranno confiscati. Con Volition, gli utenti possono scegliere la disponibilità dei dati on-chain/off-chain e scegliere tra sicurezza e costo in base alle proprie esigenze.
In questo momento, appaiono celestia e polygon avail. Se Validium ha bisogno di disponibilità di dati off-chain ma teme che il basso livello di decentralizzazione possa portare ad attacchi alle chiavi private simili ai bridge cross-chain, allora una soluzione DA universale decentralizzata può risolvere questo problema. Celestia e Polygon Avail forniscono soluzioni DA off-chain per Validium diventando una catena separata. Tuttavia, nonostante la sicurezza venga migliorata tramite una catena separata, il costo aumenterà di conseguenza.
L'espansione di Rollup in realtà si compone di due parti. Uno è la velocità di esecuzione dell'aggregatore, l'altro richiede la cooperazione del livello di disponibilità dei dati. Attualmente l'aggregatore è gestito da un server centralizzato. Supponendo che la velocità di esecuzione delle transazioni possa raggiungere un livello infinito, la principale difficoltà di espansione risiede nel fatto che essa è influenzata dalla capacità di elaborazione dei dati della soluzione di disponibilità dei dati sottostante. Massimizzare la produttività dello spazio dati della soluzione di disponibilità dei dati è fondamentale affinché il rollup possa massimizzare la produttività delle transazioni.
Tornando all'inizio, utilizzare gli impegni KZG o le prove di frode per garantire l'integrità dei dati e utilizzare codici di cancellazione per espandere i dati delle transazioni e aiutare i nodi leggeri a eseguire il campionamento della disponibilità dei dati, garantendo ulteriormente che i nodi leggeri possano verificare correttamente i dati.
Forse vorrai anche chiedere: in che modo KZG promette di lavorare per garantire l'integrità dei suoi dati? Forse posso spiegarlo un po':
Impegno KZG: dimostrare che il valore di un polinomio in una posizione specifica è coerente con il valore specificato. Un impegno KZG non è altro che un tipo di impegno polinomiale in grado di verificare un messaggio senza fornire un messaggio specifico. Il processo generale è il seguente:
Convertire i dati in un polinomio tramite la codifica di cancellazione ed espanderli. L'utilizzo di KZG Commitment garantisce l'efficacia delle nostre estensioni e la validità dei dati originali. L'estensione può quindi essere utilizzata per ricostruire i dati e infine eseguire il campionamento della disponibilità dei dati.
Il committer genera un impegno, vincolandolo al messaggio. Il messaggio vincolato viene inviato al verificatore. In questo caso lo schema di comunicazione è correlato alla dimensione della prova. Il verificatore importa più valori del campo finito per verificare se sono ancora uguali ad a (questo è il processo di campionamento di disponibilità). Il principio di base è che più verifiche vengono effettuate, maggiore è la probabilità che la risposta sia corretta.
Celestia richiede ai validatori di scaricare l'intero blocco, mentre danksharding ora utilizza la tecnologia di campionamento della disponibilità dei dati.
Poiché i blocchi sono parzialmente disponibili, dobbiamo garantire la sincronizzazione ogni volta che ricostruiamo i blocchi. Quando un blocco è effettivamente parzialmente disponibile, i nodi comunicano tra loro per ricomporre il blocco.
Confronto tra l'impegno di KZG e la prova di frode dei dati:
Come si può notare, KZG promette di garantire che l'estensione e i dati siano corretti, mentre la prova di frode introduce una terza parte per l'osservazione. La differenza più evidente è che le prove di frode richiedono un intervallo di tempo affinché gli osservatori reagiscano e poi segnalino la frode, il che richiede una sincronizzazione diretta dei nodi affinché l'intera rete possa ricevere tempestivamente la prova di frode. KZG è significativamente più veloce delle prove di frode, poiché utilizza metodi matematici per garantire la correttezza dei dati senza richiedere tempi di attesa.
Può dimostrare che i dati e le loro estensioni sono corretti. Tuttavia, poiché l'impegno KZG unidimensionale richiede più risorse, Ethereum sceglie l'impegno KZG bidimensionale.
Ad esempio, 100 righe × 100 colonne equivalgono a 100.000 condivisioni. Ma ogni volta che si preleva un campione, non c'è garanzia che sia accurato. Quindi, espandendo di quattro volte, almeno 1/4 dell'intera quota deve essere non disponibile prima di poter estrarre una quota non disponibile, il che significa che è realmente non disponibile perché non può essere recuperata. Solo quando 1/4 di essi non sono disponibili l'errore può essere scoperto in modo efficace, quindi la probabilità di un'unica estrazione è di circa 1/4. Pompando più di dieci o quindici volte si può raggiungere una garanzia di affidabilità del 99%. Ora scegli un intervallo compreso tra 15 e 20 volte.
5、EIP-4844（Proto-Danksharding）
Nell'implementazione proto-danksharding, tutti i validatori e gli utenti devono comunque verificare direttamente la disponibilità dei dati completi.
La caratteristica principale introdotta da Proto-danksharding è un nuovo tipo di transazione, che chiamiamo transazioni blob-carrying. Una transazione che trasporta un blob è simile a una transazione normale, con la differenza che trasporta anche un dato extra chiamato blob. I BLOB sono molto grandi (~125 kB) e sono molto più economici di una quantità simile di dati di chiamata. Tuttavia, questi blob non sono accessibili dall'EVM (solo l'impegno verso il blob). I blob vengono memorizzati dal livello di consenso (beacon chain) anziché dal livello di esecuzione. Questo è in realtà l'inizio della graduale formazione del concetto di data sharding.
Poiché i validatori e i client devono comunque scaricare l'intero contenuto del blob, l'obiettivo di larghezza di banda dei dati nel proto-danksharding è di 1 MB per slot, anziché i 16 MB completi. Tuttavia, poiché questi dati non competono con il consumo di gas delle transazioni Ethereum esistenti, si ottengono comunque grandi guadagni in termini di scalabilità.
Sebbene il raggiungimento dello sharding completo (con campionamento della disponibilità dei dati, ecc.) sia un compito complesso e rimarrà tale anche dopo il proto-danksharding, questa complessità è contenuta nel livello di consenso. Una volta avviato il proto-danksharding, non è richiesto ulteriore lavoro da parte dei team client del livello di esecuzione, degli sviluppatori di rollup e degli utenti per completare la transizione allo sharding completo. Il proto-danksharding separa anche i dati blob dai dati delle chiamate, consentendo ai client di archiviare i dati blob in tempi più rapidi.
In particolare, tutto il lavoro è stato svolto tramite modifiche consensuali del livello e non è stato richiesto alcun lavoro aggiuntivo da parte dei team dei clienti, degli utenti o degli sviluppatori di Rollup.
Sia EIP-4488 che proto-danksharding determinano un utilizzo massimo a lungo termine di circa 1 MB per slot (12 secondi). Ciò equivale a circa 2,5 TB all'anno, ovvero molto più alto del tasso di crescita di cui Ethereum ha bisogno oggi.
Nel caso di EIP-4488, la soluzione di questo problema richiede la proposta di scadenza della cronologia EIP-4444 (menzionata nella sezione roadmap), in base alla quale i client non sono più tenuti a memorizzare la cronologia oltre un certo periodo di tempo.
6. Frammentazione dei dati
Qui cercherò di spiegare quanti più problemi possibili di cui tutti stanno discutendo durante il processo di espansione di Ethereum, dal punto di vista di un principiante. Torniamo quindi allo sharding e sottolineiamo ancora una volta il concetto unilaterale di sharding: in parole povere, è il processo di suddivisione orizzontale del database per distribuire il carico.
Qui c'è un problema molto importante con il nostro data sharding. In PBS (separazione di proponenti e costruttori di blocchi, menzionata nella roadmap The Merge), in uno shard, ogni gruppo di nodi elabora solo le transazioni all'interno dello shard e le transazioni tra gli shard sono relativamente indipendenti. Quindi, se gli utenti AB si trovano su shard diversi, come dovrebbero trasferirsi denaro a vicenda? Ciò richiede buone capacità di comunicazione tra chip.
Il vecchio approccio consisteva nel frammentare il livello di disponibilità dei dati, assegnando a ogni frammento proponenti e comitati indipendenti. Nel set di validatori, ogni validatore verifica a turno i dati dello shard e scarica tutti i dati per la verifica.
Gli svantaggi sono:
Per garantire che i validatori possano essere sincronizzati all'interno di uno slot è necessaria una tecnologia di sincronizzazione rigorosa. Il validatore deve raccogliere i voti di tutti i comitati e anche in questo caso si verificheranno dei ritardi. Inoltre, per il verificatore è molto stressante scaricare tutti i dati.
Il secondo approccio consiste nel rinunciare alla convalida completa dei dati e adottare invece un approccio di campionamento della disponibilità dei dati (un approccio implementato più avanti in The Surge). Esistono due tipi di metodi di campionamento casuale: 1) Campionamento casuale a blocchi, ovvero campionamento di alcuni frammenti di dati. Se la verifica viene superata, il verificatore firma. Ma il problema in questo caso è che potrebbero verificarsi casi in cui le transazioni non vengono registrate. 2) I codici di cancellazione vengono utilizzati per reinterpretare i dati come polinomi e la capacità dei polinomi di recuperare i dati in determinate condizioni viene sfruttata per garantire la completa disponibilità dei dati.
La chiave dello "sharding" è che il validatore non è responsabile dello scaricamento di tutti i dati, ed è per questo che Proto-danksharding non è considerato "sharding" (anche se ha "sharding" nel nome). Il proto-danksharding richiede che ogni validatore scarichi completamente tutti gli shard blob per verificarne la disponibilità; Danksharding introdurrà quindi il campionamento, in base al quale un singolo validatore dovrà scaricare solo frammenti di un blob di frammenti.
3. Il futuro di Ethereum: Layer 3
Layer 2 basato su ZK, che è visto come il futuro dell'espansione di Ethereum, come zksync e starknet, ha proposto il concetto di Layer 3. In parole povere, è Layer 2 di Layer 2.
Gli elevati costi di transazione su Ethereum stanno spingendo L3 a diventare il livello di regolamento per L2. Credo che nel prossimo futuro, grazie alla significativa riduzione dei costi di transazione, al crescente supporto per gli strumenti DeFi e alla maggiore liquidità fornita da L2, gli utenti finali svolgeranno la maggior parte delle loro attività su L2, con Ethereum che diventerà gradualmente il livello di regolamento.
L2 migliora la scalabilità riducendo il costo del gas per transazione e aumentando le tariffe delle transazioni. Allo stesso tempo, le L2 mantengono i vantaggi della decentralizzazione, della logica comune e della componibilità. Tuttavia, alcune applicazioni richiedono personalizzazioni specifiche che potrebbero essere meglio gestite da un nuovo livello indipendente: L3!
L3 è correlata a L2 proprio come L2 è correlata a L1. Finché L2 può supportare gli smart contract Verifier, L3 può essere implementato utilizzando prove di validità. Quando L2 utilizza anche prove di validità inviate a L1, come fa StarkNet, si ottiene una struttura ricorsiva molto elegante in cui il vantaggio di compressione delle prove L2 viene moltiplicato per il vantaggio di compressione delle prove L3. In teoria, se ogni livello realizzasse, ad esempio, una riduzione dei costi di 1.000 volte, allora L3 potrebbe essere 1.000.000 di volte più economico di L1, mantenendo comunque la sicurezza di L1. Questo è anche un caso d'uso reale della dimostrazione ricorsiva di cui starknet va fiera.
In questo caso è necessaria una certa conoscenza (livello di disponibilità dei dati on-chain e off-chain). L'intero Livello 3 include:
Rollup (disponibilità dei dati on-chain), validium (disponibilità dei dati off-chain). Le due tipologie corrispondono a requisiti applicativi diversi. Le aziende Web2 sensibili ai prezzi e ai dati possono utilizzare Validium per posizionare i dati off-chain, il che riduce notevolmente le tariffe del gas on-chain e garantisce la privacy non divulgando i dati degli utenti, consentendo alle aziende di controllare i propri dati e di utilizzare formati di dati personalizzati. Il precedente modello aziendale basato sui dati può ancora funzionare senza problemi.
L2 è per il ridimensionamento, mentre L3 è per le funzionalità personalizzate, come la privacy.
In questa visione non c'è alcun tentativo di fornire una "scalabilità quadratica"; al contrario, nello stack è presente un livello che aiuta le applicazioni a scalare e poi separa i livelli in base ai requisiti di funzionalità personalizzati dei diversi casi d'uso.
L2 è per le estensioni generali, mentre L3 è per le estensioni personalizzate.
Le estensioni personalizzate possono presentarsi in diverse forme: applicazioni specializzate che utilizzano qualcosa di diverso dall'EVM per i calcoli, rollup la cui compressione dei dati è ottimizzata per il formato dei dati di un'applicazione specifica (inclusa la separazione dei "dati" dalle "prove" e la sostituzione completa delle prove con un singolo SNARK per blocco), ecc.
L2 viene utilizzato per l'espansione senza fiducia (rollup), mentre L3 viene utilizzato per l'espansione con fiducia debole (validium).
Validium è un sistema che utilizza SNARK per verificare i calcoli, ma lascia la disponibilità dei dati a una terza parte o a un comitato di fiducia. A mio parere, Validium è gravemente sottovalutato: in particolare, molte applicazioni "blockchain aziendale" potrebbero in realtà essere meglio servite da un server centralizzato che esegua un dimostratore di Validium e invii periodicamente hash alla catena. Validium ha un livello di sicurezza inferiore rispetto ai rollup, ma può essere molto più economico.
Per gli sviluppatori dApp, ci sono diverse opzioni per l'infrastruttura:
Sviluppa il tuo Rollup (ZK Rollup o Optimistic Rollup)
Il vantaggio è che puoi ereditare l'ecosistema di Ethereum (utenti) e la sua sicurezza, ma per un team di dApp, il costo di sviluppo di Rollup è ovviamente troppo alto.
Scegli Cosmos, Polkadot o Avalanche
I costi di sviluppo saranno inferiori (ad esempio, dydx ha scelto Cosmos), ma si perderà l'ecosistema Ethereum (utenti) e la sicurezza.
Sviluppa tu stesso una blockchain di Livello 1
I costi di sviluppo e la difficoltà sono elevati, ma ti danno il massimo controllo.
Confrontiamo tre situazioni:
Difficoltà/Costa: Alt-layer 1 > Rollup > Cosmos Sicurezza: Rollup > Cosmos > Alt-layer 1 Ecosistema/Utenti: Rollup > Cosmos > Alt-layer 1 Controllo: Alt-layer 1 > Cosmos > Rollup
Come sviluppatore dApp, se vuoi ereditare la sicurezza e il traffico su Ethereum, non puoi sviluppare una nuova catena, quindi puoi scegliere solo il rollup. Tuttavia, sviluppare autonomamente un rollup di livello 2 è molto costoso, quindi la soluzione più appropriata diventa quella di utilizzare l'SDK di livello 3 per sviluppare il proprio rollup specifico per l'applicazione (application-specific rollup), ovvero il Livello 3.
4. Sviluppo futuro del livello 2
Poiché Ethereum è progettato in base a un modello di account, tutti gli utenti si trovano nello stesso albero di stato e non possono essere eseguiti in parallelo. Pertanto, i vincoli di Ethereum stesso impongono di eliminare le operazioni di esecuzione e di combinare più transazioni rollup in un'unica transazione come livello di regolamento. Ora tutti i problemi sono focalizzati sul miglioramento della produttività del livello 2. Non solo il livello 3 può migliorare la produttività delle transazioni, ma l'elaborazione parallela sul livello 2 può anche migliorare notevolmente la produttività dell'intera rete.
Anche Starknet sta esplorando attivamente il problema della parallelizzazione. Sebbene l'algoritmo rappresenti ancora un ostacolo al momento, non si prevede che lo diventerà in futuro. I potenziali colli di bottiglia includono:
Elaborazione tx del sequencer: alcune operazioni del sequencer sembrano essere intrinsecamente seriali. Larghezza di banda: l'interconnessione tra più sequencer sarà limitata. Dimensione dello stato L2
Nella comunità starknet, i membri hanno anche proposto che il metodo di elaborazione parallela di aptos sia molto buono. Per quanto riguarda Starknet, viene promossa anche la capacità di parallelizzare le trasmissioni all'interno del sorter.
V. Conclusion
Ethereum sta eliminando il livello di esecuzione, tutto nella direzione della sua visione di un livello di regolamento "globale". Sebbene il progresso dell'intero Ethereum sia attualmente lento, ciò è dovuto al fatto che è troppo grande nel suo complesso e ogni aggiornamento comporta molti interessi e compromessi. Ma è innegabile che Ethereum stia subendo grandi cambiamenti. L'enorme quantità di attività on-chain di Ethereum, i miglioramenti dei meccanismi economici e la scalabilità di Ethereum 2.0, così come le innovative ICO, Defi, NFT e molte altre cose che ha introdotto, sono degni dell'entusiasmo e delle aspettative della comunità di Ethereum. Credo che, man mano che sempre più Paesi implementeranno i nodi Ethereum, come il governo della capitale argentina che prevede di implementare i nodi di verifica Ethereum nel 2023, Ethereum sarà davvero in grado di realizzare la sua grande visione nel prossimo futuro.