Il nuovo articolo di Vitalik: Il possibile futuro di Ethereum, The Surge

Autore: Vitalik Buterin

Compilato da: Karen, Foresight News

Un ringraziamento speciale a Justin Drake, Francesco, Hsiao-wei Wang, @antonttc e Georgios Konstantopoulos.

Inizialmente, c’erano due strategie di scalabilità nella roadmap di Ethereum. Uno (vedi un documento precedente del 2015) è lo "sharding": ciascun nodo deve verificare e archiviare solo una piccola parte delle transazioni, anziché verificare e archiviare tutte le transazioni nella catena. Anche qualsiasi altra rete peer-to-peer (come BitTorrent) funziona in questo modo, quindi possiamo sicuramente far funzionare una blockchain allo stesso modo. L’altro sono i protocolli Layer2: queste reti si posizioneranno sopra Ethereum, consentendo loro di beneficiare appieno della sua sicurezza mantenendo la maggior parte dei dati e dei calcoli al di fuori della catena principale. I protocolli Layer2 si riferiscono ai canali statali nel 2015, Plasma nel 2017 e poi Rollup nel 2019. I rollup sono più potenti dei canali statali o di Plasma, ma richiedono molta larghezza di banda dati sulla catena. Fortunatamente, entro il 2019, la ricerca sullo sharding ha risolto il problema della verifica della “disponibilità dei dati” su larga scala. Di conseguenza, i due percorsi sono confluiti e abbiamo ottenuto una roadmap incentrata sul Rollup che rimane la strategia di scalabilità di Ethereum oggi.

The Surge, edizione della tabella di marcia 2023

La roadmap incentrata sul Rollup propone una semplice divisione del lavoro: Ethereum L1 si concentra sull'essere uno strato di base potente e decentralizzato, mentre L2 ha il compito di aiutare la scalabilità dell'ecosistema. Questo modello è onnipresente nella società: il sistema giudiziario (L1) esiste non per perseguire la super velocità e l’efficienza, ma per proteggere i contratti e i diritti di proprietà, e gli imprenditori (L2) costruiscono su questo solido strato di base per costruire e guidare l’umanità verso (letteralmente e figurato) Marte.

Quest’anno, la roadmap incentrata sui rollup ha ottenuto risultati importanti: con il lancio dei blob EIP-4844, la larghezza di banda dei dati di Ethereum L1 è aumentata in modo significativo e molteplici rollup di Ethereum Virtual Machine (EVM) sono entrati nella prima fase. Ogni L2 esiste come un "frammento" con le proprie regole e logiche interne. La diversità e la diversificazione dei metodi di implementazione dello sharding sono ormai diventate una realtà. Ma come abbiamo visto, percorrere questa strada comporta anche alcune sfide uniche. Pertanto, il nostro compito ora è completare la roadmap incentrata sul rollup e affrontare questi problemi mantenendo la robustezza e la decentralizzazione che caratterizzano Ethereum L1.

The Surge: obiettivi chiave

1. In futuro, Ethereum potrà raggiungere più di 100.000 TPS tramite L2;

2. Mantenere il decentramento e la robustezza di L1;

3. Almeno alcuni L2 ereditano completamente gli attributi principali di Ethereum (trustless, aperto, resistente alla censura);

4. Ethereum dovrebbe sembrare un ecosistema unificato piuttosto che 34 blockchain diverse.

Contenuto di questo capitolo

1. Il triangolo della scalabilità

2. Ulteriori progressi nel campionamento della disponibilità dei dati

3. Compressione dei dati

4. Plasma generalizzato

5. Sistema di prova L2 maturo

6. Miglioramenti all'interoperabilità tra L2

7. Estendi l'esecuzione su L1

Il triangolo della scalabilità

Il triangolo della scalabilità è un'idea proposta nel 2017 che sostiene che esiste una contraddizione tra tre proprietà della blockchain: decentralizzazione (più specificamente: basso costo di esecuzione dei nodi), scalabilità (elaborazione di un numero elevato di transazioni) e sicurezza (un utente malintenzionato dovrebbe compromettere gran parte dei nodi della rete fino a far fallire una singola transazione).

Vale la pena notare che il paradosso del triangolo non è un teorema e il post che introduce il paradosso del triangolo non include una dimostrazione matematica. Fornisce un argomento matematico euristico: se un nodo favorevole alla decentralizzazione (ad esempio un laptop consumer) può verificare N transazioni al secondo e si dispone di una catena che elabora k*N transazioni al secondo, allora (i) ogni transazione può essere solo visto da 1/k nodi, il che significa che un utente malintenzionato deve compromettere solo alcuni nodi per passare una transazione dannosa, oppure (ii) il tuo nodo diventerà potente e la catena non sarà decentralizzata. Lo scopo di questo articolo non è mai stato quello di dimostrare che rompere il paradosso del triangolo è impossibile, ma piuttosto mostrare che rompere il trilemma è difficile e che richiede un certo grado di pensiero al di fuori del quadro dell'argomentazione.

Nel corso degli anni, alcune catene ad alte prestazioni hanno spesso affermato di aver risolto il trilemma senza modificare radicalmente la propria architettura, spesso applicando tecniche di ingegneria del software per ottimizzare i nodi. Questo è sempre fuorviante, gestire un nodo su queste catene è molto più difficile che gestire un nodo su Ethereum. Questo articolo esplorerà il motivo per cui questo è il caso e perché l'ingegneria del software client L1 da sola non può scalare Ethereum?

Tuttavia, la combinazione del campionamento della disponibilità dei dati e degli SNARK risolve il paradosso del triangolo: consente al cliente di verificare che una certa quantità di dati sia disponibile e che un certo numero di passaggi computazionali sia disponibile, scaricando solo una piccola quantità di dati ed eseguendo una quantità molto piccola di calcoli eseguiti correttamente. Gli SNARK sono senza fiducia. Il campionamento della disponibilità dei dati ha un modello di fiducia sottile di pochi N, ma mantiene la proprietà di base delle catene non scalabili, ovvero anche un attacco del 51% non può forzare l'accettazione dei blocchi danneggiati dalla rete.

Un’altra soluzione al trilemma è l’architettura Plasma, che utilizza tecniche intelligenti per affidare all’utente la responsabilità di monitorare la disponibilità dei dati in modo compatibile con gli incentivi. Già nel 2017-2019, quando disponevamo solo di prove di frode come mezzo per espandere la potenza di calcolo, Plasma era molto limitato in termini di esecuzione della sicurezza, ma con la popolarità degli SNARK (argomenti succinti non interattivi a conoscenza zero), il Plasma l'architettura è più Una gamma più ampia di casi d'uso è diventata più fattibile.

Ulteriori progressi nel campionamento della disponibilità dei dati

Quale problema stiamo risolvendo?

Quando l'aggiornamento di Dencun sarà attivo il 13 marzo 2024, la blockchain di Ethereum avrà tre blob di circa 125 kB per slot di 12 secondi, o circa 375 kB di larghezza di banda dati disponibile per slot. Supponendo che i dati della transazione siano pubblicati direttamente sulla catena, un trasferimento ERC20 è di circa 180 byte, quindi il TPS massimo di Rollup su Ethereum è: 375000 / 12 / 180 = 173,6 TPS

Se aggiungiamo i calldata di Ethereum (massimo teorico: 30 milioni di Gas per slot / 16 gas per byte = 1.875.000 byte per slot), questo diventa 607 TPS. Con PeerDAS, il numero di BLOB può essere aumentato a 8-16, il che fornirebbe 463-926 TPS per i dati delle chiamate.

Si tratta di un miglioramento significativo rispetto a Ethereum L1, ma non sufficiente. Vogliamo più scalabilità. Il nostro obiettivo a medio termine è 16 MB per slot, che se combinato con i miglioramenti della compressione dei dati di rollup si tradurrà in circa 58.000 TPS.

che cos'è? Come funziona?

PeerDAS è un'implementazione relativamente semplice del "campionamento 1D". In Ethereum, ogni blob è un polinomio di grado 4096 su un campo primo di 253 bit. Trasmettiamo quote polinomiali, dove ciascuna quota contiene 16 valutazioni in 16 coordinate adiacenti da un totale di 8192 coordinate. Di questi 8192 valori valutati, 4096 qualsiasi (secondo i parametri attualmente proposti: 64 qualsiasi su 128 possibili campioni) possono recuperare il blob.

PeerDAS funziona facendo in modo che ogni client ascolti un piccolo numero di sottoreti, dove l'i-esima sottorete trasmette l'i-esimo campione di qualsiasi blob e chiedendo ai peer nella rete p2p globale che ascolteranno su diverse sottoreti) di richiedere blob su altre sottoreti di cui ha bisogno. Una versione più conservativa, SubnetDAS, utilizza solo il meccanismo della sottorete senza ulteriori interrogazioni del livello di peering. La proposta attuale è che i nodi che partecipano alla Proof of Stake utilizzino SubnetDAS, mentre altri nodi (ovvero i client) utilizzino PeerDAS.

In teoria, possiamo ridimensionare un po' un "campionamento 1D": se aumentiamo il numero massimo di blob a 256 (targeting 128), allora possiamo raggiungere il target di 16 MB e ciascuno dei campioni di disponibilità dei dati campiona 16 campioni per nodo * 128 BLOB * 512 byte per campione per BLOB = 1 MB di larghezza di banda dati per slot. Questo rientra appena nel nostro intervallo di tolleranza: è fattibile, ma significa che i client con vincoli di larghezza di banda non possono campionare. Possiamo ottimizzarlo in qualche modo riducendo il numero di BLOB e aumentando la dimensione del BLOB, ma ciò renderà la ricostruzione più costosa.

Quindi alla fine vogliamo fare un ulteriore passo avanti ed eseguire il campionamento 2D, che è un campionamento casuale non solo all'interno dei blob, ma anche tra i blob. Sfruttando le proprietà di linearità degli impegni KZG, l'insieme di blob in un blocco viene ampliato da un nuovo insieme di blob virtuali che codificano in modo ridondante le stesse informazioni.

Quindi alla fine vogliamo fare un ulteriore passo avanti ed eseguire il campionamento 2D, che è un campionamento casuale non solo all'interno dei blob, ma anche tra i blob. La proprietà lineare degli impegni KZG viene utilizzata per espandere l'insieme di BLOB in un blocco con un elenco di nuovi BLOB virtuali che codificano in modo ridondante le stesse informazioni.

Campionamento 2D. Fonte: criptovaluta a16z

Fondamentalmente, il calcolo del ridimensionamento degli impegni non richiede blob, quindi lo schema è fondamentalmente favorevole alla costruzione di blocchi distribuiti. I nodi che effettivamente costruiscono i blocchi devono solo avere l'impegno KZG del blob e possono fare affidamento sul campionamento della disponibilità dei dati (DAS) per verificare la disponibilità del blocco di dati. Anche il campionamento unidimensionale della disponibilità dei dati (DAS 1D) è intrinsecamente favorevole alla creazione di blocchi distribuiti.

Quali sono i collegamenti con la ricerca esistente?

1. Post originale sulla disponibilità dei dati (2018): https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding

2. Articolo di follow-up: https://arxiv.org/abs/1809.09044

3. Articolo esplicativo su DAS, paradigma: https://www.paradigm.xyz/2022/08/das

4. Disponibilità 2D con impegni KZG: https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081

5. PeerDAS su ethresear.ch: https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541 e articolo: https://eprint.iacr.org / 2024/1362

6. EIP-7594: https://eips.ethereum.org/EIPS/eip-7594

7. ethresear.ch Il SubnetDAS di casa: https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169

8. Sfumature del recupero dei dati nel campionamento 2D: https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256

Cos'altro è necessario fare? Quali sono i compromessi?

Il prossimo passo sarà il completamento dell'implementazione e del lancio di PeerDAS. Da lì, è stato un processo graduale volto ad aumentare il numero di blob su PeerDAS osservando attentamente la rete e migliorando il software per garantire la sicurezza. Nel frattempo, speriamo di vedere più lavoro accademico sulla standardizzazione di PeerDAS e altre versioni di DAS e sulla loro interazione con questioni come la sicurezza delle regole di scelta della fork.

In futuro, dovremo lavorare di più per identificare la versione ideale di 2D DAS e dimostrarne le proprietà di sicurezza. Speriamo anche di passare alla fine da KZG a un'alternativa che sia quantistica sicura e non richieda una configurazione affidabile. Al momento, non sappiamo quali candidati siano favorevoli alla costruzione di blocchi distribuiti. Anche l'uso di costose tecniche di "forza bruta", anche l'uso di STARK ricorsivi per generare prove di validità per ricostruire righe e colonne, non è sufficiente perché, sebbene tecnicamente uno STARK sia O(log(n) * log(log(n)) valore hash (usando STIR), ma in realtà lo STARK è grande quasi quanto l'intero blob.

Il mio percorso realistico a lungo termine è:

1. Implementare il DAS 2D ideale;

2. Attenersi al DAS 1D, sacrificare l'efficienza della larghezza di banda di campionamento e accettare limiti di dati inferiori per semplicità e robustezza

3. Abbandona DA e abbraccia completamente Plasma come architettura Layer2 primaria su cui ci concentriamo.

Tieni presente che questa opzione esiste anche se decidiamo di ridimensionare l'esecuzione direttamente al livello L1. Questo perché se il livello L1 deve gestire un numero elevato di TPS, i blocchi L1 diventeranno molto grandi e il client vorrà un modo efficiente per verificarne la correttezza, quindi dovremo utilizzare Rollup al livello L1 (come ad esempio ZK -EVM e DAS) stessa tecnologia.

Come interagisco con le altre parti della roadmap?

La necessità di DAS 2D sarà ridotta, o almeno ritardata, se verrà implementata la compressione dei dati, e ulteriormente ridotta se il plasma verrà ampiamente utilizzato. DAS pone anche sfide ai protocolli e ai meccanismi di costruzione di blocchi distribuiti: mentre DAS è teoricamente favorevole alla ricostruzione distribuita, in pratica questa deve essere combinata con la proposta dell'elenco di inclusione e il meccanismo di scelta del fork che lo circonda.

Compressione dei dati

Quale problema stiamo risolvendo?

Ogni transazione in Rollup occupa molto spazio dati sulla catena: un trasferimento ERC20 richiede circa 180 byte. Anche con il campionamento ideale della disponibilità dei dati, ciò limita la scalabilità del protocollo Layer. Con 16 MB per slot, otteniamo:

16000000 / 12 / 180 = 7407 TPS

E se potessimo risolvere non solo il problema del numeratore, ma anche quello del denominatore, in modo che ogni transazione in un rollup occupi meno byte sulla catena?

Cos'è e come funziona?

Secondo me la spiegazione migliore è questa foto di due anni fa:

Nella compressione a byte zero, ogni lunga sequenza di byte zero viene sostituita con due byte, che indicano quanti byte zero ci sono. Facendo un ulteriore passo avanti, sfruttiamo le proprietà specifiche della transazione:

Aggregazione delle firme: passiamo dalle firme ECDSA alle firme BLS La caratteristica delle firme BLS è che più firme possono essere combinate in un'unica firma in grado di dimostrare la validità di tutte le firme originali. Nello strato L1 le firme BLS non vengono considerate a causa dell'elevato costo computazionale della verifica anche con l'aggregazione. Ma in un ambiente scarso di dati come L2, ha senso utilizzare le firme BLS. La natura di aggregazione di ERC-4337 fornisce un modo per ottenere questa funzionalità.

Sostituzione di indirizzi con puntatori: se un indirizzo è stato utilizzato in precedenza, possiamo sostituire l'indirizzo di 20 byte con un puntatore di 4 byte che punta a una posizione nella cronologia.

Serializzazione personalizzata dei valori delle transazioni: la maggior parte dei valori delle transazioni ha pochissime cifre, ad esempio 0,25 ETH è rappresentato come 250.000.000.000.000.000 wei. Anche la commissione di gestione base massima e la commissione di gestione prioritaria sono simili. Pertanto, possiamo utilizzare un formato a virgola mobile decimale personalizzato per rappresentare la maggior parte dei valori monetari.

Quali sono i collegamenti con la ricerca esistente?

1. Esplora sequenza.xyz: https://sequence.xyz/blog/compressing-calldata

2. Contratto di ottimizzazione L2 Calldata: https://github.com/ScopeLift/l2-optimizooooors

3. I rollup basati su prove di validità (noti anche come rollup ZK) pubblicano differenze di stato anziché transazioni: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2 -data -impronta-su-l1/9975

4. Portafoglio BLS - Aggregazione BLS tramite ERC-4337: https://github.com/getwax/bls-wallet

Cos’altro è necessario fare e quali sono i compromessi?

La cosa principale da fare dopo è implementare effettivamente la soluzione di cui sopra. I principali compromessi includono:

1. Il passaggio alle firme BLS richiede molto impegno e riduce la compatibilità con chip hardware affidabili che migliorano la sicurezza. È possibile utilizzare invece i wrapper ZK-SNARK di altri schemi di firma.

2. La compressione dinamica (ad esempio, la sostituzione degli indirizzi con puntatori) complicherà il codice client.

3. La pubblicazione delle differenze di stato nella catena anziché nelle transazioni ridurrà la verificabilità e renderà molti software (come i block explorer) incapaci di funzionare.

Come interagisco con le altre parti della roadmap?

L’adozione di ERC-4337 e l’eventuale incorporazione di parti di esso nell’EVM L2 potrebbero accelerare significativamente l’implementazione delle tecnologie convergenti. Posizionare parti di ERC-4337 su L1 può accelerarne l'implementazione su L2.

Plasma generalizzato

Quale problema stiamo risolvendo?

Anche con BLOB da 16 MB e compressione dei dati, 58.000 TPS potrebbero non essere sufficienti per soddisfare pienamente le esigenze dei pagamenti dei consumatori, dei social decentralizzati o di altre aree a larghezza di banda elevata, soprattutto se iniziamo a considerare considerazioni sulla privacy, che potrebbero compromettere la scalabilità 3-8 volte. Per un volume di transazioni elevato e scenari applicativi di basso valore, un’opzione attuale è quella di utilizzare Validium, che mantiene i dati fuori catena e adotta un modello di sicurezza interessante: gli operatori non possono rubare i fondi degli utenti, ma possono congelare temporaneamente o permanentemente tutti i fondi degli utenti. Ma possiamo fare di meglio.

Cos'è e come funziona?

Plasma è una soluzione di ridimensionamento che prevede che un operatore pubblichi blocchi off-chain e metta le radici Merkle di tali blocchi on-chain (a differenza di Rollup, che mette blocchi completi on-chain). Per ogni blocco, l’operatore invia a ciascun utente un ramo Merkle per dimostrare cosa è cambiato, o non è cambiato, nel patrimonio di quell’utente. Gli utenti possono ritirare i propri asset fornendo un fork Merkle. È importante sottolineare che questo ramo non deve essere rootato nell'ultimo stato. Pertanto, anche se si verifica un problema con la disponibilità dei dati, gli utenti possono comunque recuperare le proprie risorse estraendo lo stato più recente a loro disposizione. Se un utente commette un branch non valido (ad esempio, ritira un asset che ha già inviato a qualcun altro, o l'operatore stesso crea un asset dal nulla), la proprietà legale dell'asset può essere determinata attraverso una sfida on-chain meccanismo.

Diagramma della catena di Plasma Cash. Una transazione che costa la moneta i viene collocata nella i-esima posizione nell'albero. In questo esempio, presupponendo che tutti gli alberi precedenti siano validi, sappiamo che Eva attualmente possiede il token 1, David possiede il token 4 e George possiede il token 6.

Le prime versioni di Plasma erano in grado di gestire solo casi di utilizzo a pagamento e non potevano essere ulteriormente promosse in modo efficace. Tuttavia, Plasma diventa molto più potente se richiediamo che ogni radice venga verificata con SNARK. Ogni gioco di sfida può essere notevolmente semplificato perché eliminiamo la maggior parte dei percorsi possibili per imbrogliare gli operatori. Allo stesso tempo, si aprono nuove strade per consentire alla tecnologia al plasma di espandersi a una gamma più ampia di classi di attività. Infine, a condizione che l’operatore non imbrogli, gli utenti possono prelevare fondi immediatamente senza dover attendere un periodo di sfida di una settimana.

Un modo (non l'unico modo) per creare una catena di plasma EVM: utilizzare ZK-SNARK per costruire un albero UTXO parallelo che rifletta le modifiche di equilibrio apportate da EVM e definisca lo "stesso token" in diversi punti della storia "L'unica mappatura . Sopra di esso possono poi essere costruite strutture al plasma.

Un aspetto fondamentale è che i sistemi al plasma non devono essere perfetti. Anche se puoi proteggere solo un sottoinsieme di risorse (ad esempio, solo token che non si sono spostati nell'ultima settimana), hai notevolmente migliorato lo stato attuale dell'EVM iperscalabile (ovvero Validium).

Un altro tipo di struttura è un ibrido Plasma/Rollup, come Intmax. Questi costrutti inseriscono una quantità molto piccola di dati per utente sulla catena (ad esempio, 5 byte) e così facendo ottengono alcune proprietà tra Plasma e Rollup: nel caso di Intmax, puoi ottenere scalabilità e privacy molto elevate, sebbene anche con una capacità di 16 MB è teoricamente limitata a circa 16.000.000 / 12 / 5 = 266.667 TPS.

Quali sono i collegamenti con la ricerca esistente?

1. Articolo originale su Plasma: https://plasma.io/plasma-deprecated.pdf

2. Plasma Cash: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298

3. Flusso di cassa del plasma: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#?-Esci

4. Intmax (2023): https://eprint.iacr.org/2023/1082

Cos'altro è necessario fare? Quali sono i compromessi?

Il compito principale che rimane è quello di mettere il sistema al plasma in applicazioni pratiche di produzione. Come accennato in precedenza, Plasma vs Validium non è una scelta alternativa: qualsiasi Validium può migliorare le sue proprietà di sicurezza almeno in una certa misura incorporando le funzionalità di Plasma nel suo meccanismo di uscita. L'obiettivo della ricerca è ottenere il meglio per le proprietà EVM (considerato in termini di requisiti di fiducia, costo del gas L1 nel caso peggiore e capacità di resistere agli attacchi DoS), nonché strutture alternative specifiche dell'applicazione. Inoltre, Plasma è concettualmente più complesso di Rollup, che richiede essere affrontato direttamente dalla ricerca e costruire quadri generali migliori.

Il principale compromesso con l'utilizzo dei progetti Plasma è che sono più dipendenti dall'operatore e più difficili da basare, sebbene i progetti ibridi Plasma/Rollup spesso evitino questa debolezza.

Come interagisco con le altre parti della roadmap?

Quanto più efficiente è la soluzione Plasma, tanto minore è la pressione su L1 per avere capacità di disponibilità dei dati ad alte prestazioni. Spostare le attività su L2 riduce anche la pressione MEV su L1.

Sistema di prova L2 maturo

Quale problema stiamo risolvendo?

Attualmente, la maggior parte dei rollup non sono effettivamente trustless. Esiste un comitato di sicurezza che ha la capacità di ignorare (ottimista o validità) il comportamento del sistema. In alcuni casi il sistema di attestazione non funziona nemmeno del tutto o, se funziona, ha solo una funzione “consultiva”. I rollup all'avanguardia includono: (i) alcuni rollup trustless specifici per l'applicazione, come Fuel (ii) al momento della stesura di questo documento, Optimism e Arbitrum sono due che hanno raggiunto un traguardo trustless parziale noto come "Fase 1"; Rollup EVM completo. Il motivo per cui Rollup non è riuscito a compiere ulteriori progressi era dovuto a preoccupazioni relative ai bug nel codice. Abbiamo bisogno di Rollup trustless, quindi dobbiamo affrontare questo problema a testa alta e risolverlo.

Cos'è e come funziona?

Per prima cosa, esaminiamo il sistema “stage” originariamente introdotto in questo articolo.

Fase 0: gli utenti devono essere in grado di eseguire il nodo e sincronizzare la catena. Se la verifica è completamente attendibile/centralizzata, va bene lo stesso.

Fase 1: deve esistere un sistema di prova (senza fiducia) che garantisca che verranno accettate solo transazioni valide. È consentito un comitato di sicurezza che possa prevalere sul sistema di certificazione, ma deve esserci una soglia di voto del 75%. Inoltre, la parte del comitato che blocca il quorum (ovvero il 26%+) deve essere esterna alla società principale che costruisce il Rollup. È consentito un meccanismo di aggiornamento più debole (come DAO), ma deve avere un ritardo sufficientemente lungo affinché, se approva un aggiornamento dannoso, gli utenti possano ritirare i propri fondi prima che i fondi vengano attivati.

Fase 2: deve esserci un sistema di prova (senza fiducia) che garantisca che verranno accettate solo transazioni valide. Il comitato per la sicurezza può intervenire solo se, ad esempio, sono presenti bug dimostrabili nel codice. Se due sistemi di prova ridondanti sono incoerenti tra loro, o se un sistema di prova accetta due diverse radici post-stato per lo stesso blocco (o non accetta nulla per un periodo di tempo sufficientemente lungo, ad esempio una settimana). Il meccanismo di aggiornamento è consentito, ma deve avere un lungo ritardo.

Il nostro obiettivo è arrivare alla Fase 2. La sfida principale nel raggiungere la fase 2 è acquisire sufficiente fiducia nel fatto che il sistema sia effettivamente sufficientemente affidabile. Esistono due modi principali per farlo:

1. Verifica formale: possiamo utilizzare le moderne tecniche matematiche e informatiche per dimostrare (ottimista e valido) che il sistema accetta solo blocchi che superano la specifica EVM. Queste tecnologie esistono da decenni, ma i recenti progressi (come Lean 4) le hanno rese più pratiche, e i progressi nelle dimostrazioni assistite dall’intelligenza artificiale potrebbero accelerare ulteriormente questa tendenza.

2. Multi-prover: crea più sistemi di prova e investi denaro in questi sistemi di prova con comitati di sicurezza (o altri gadget con presupposti di fiducia, come i TEE). Se il sistema di prova concorda, il comitato per la sicurezza non ha alcun potere; in caso contrario, il comitato per la sicurezza può scegliere solo tra uno dei due e non può imporre unilateralmente la propria risposta.

Grafico stilizzato di più dimostratori, che combina un sistema di prova ottimistico, un sistema di prova di validità e un comitato di sicurezza.

Quali sono i collegamenti con la ricerca esistente?

1. EVM K Semantics (lavoro di verifica formale del 2017): https://github.com/runtimeverification/evm-semantics

2. Conferenza sull'idea di dimostrazioni multiple (2022): https://www.youtube.com/watch?v=6hfVzCWT6YI

3. Taiko prevede di utilizzare multi-prove: https://docs.taiko.xyz/core-concepts/multi-proofs/

Cos'altro è necessario fare? Quali sono i compromessi?

Per la verifica formale, il carico di lavoro è enorme. Dobbiamo creare una versione formalmente verificata dell'intero prover SNARK per EVM. Si tratta di un progetto estremamente complesso, anche se abbiamo già iniziato a lavorarci. C'è un trucco che semplifica notevolmente questo compito: possiamo creare un prover SNARK formalmente verificato per una macchina virtuale minima (come RISC-V o Cairo), e quindi implementare l'EVM in questa macchina virtuale minima (e prova formale della sua equivalenza ad altre specifiche della macchina virtuale Ethereum).

Ci sono due parti principali della prova multipla che devono ancora essere completate. In primo luogo, dobbiamo avere sufficiente fiducia in almeno due diversi sistemi di prova, sia per garantire che siano ciascuno ragionevolmente sicuro, sia per garantire che, se hanno problemi, i problemi dovrebbero essere diversi e non correlati (quindi non si verificano simultaneamente A si verifica il problema). In secondo luogo, dobbiamo avere un altissimo grado di fiducia nella logica sottostante al sistema di prova della fusione. Questa parte del codice è molto meno. Esistono modi per renderlo molto piccolo, semplicemente archiviando i fondi in un contratto multisig sicuro con contratti che rappresentano ciascun sistema di prova come firmatari, ma ciò aumenterà il costo del gas sulla catena. Dobbiamo trovare un equilibrio tra efficienza e sicurezza.

Come posso interagire con le altre parti della roadmap?

Lo spostamento dell'attività su L2 riduce la pressione MEV su L1.

Miglioramenti all'interoperabilità tra L2

Quale problema stiamo risolvendo?

Una delle principali sfide che l'ecosistema L2 di oggi deve affrontare è la difficoltà per gli utenti di navigare al suo interno. Inoltre, gli approcci più semplici spesso reintroducono presupposti di fiducia: catene incrociate centralizzate, client RPC, ecc. Dobbiamo far sì che l’utilizzo dell’ecosistema L2 sembri come l’utilizzo di un ecosistema Ethereum unificato.

Cos'è? Come funziona?

Esistono molte categorie di miglioramenti dell'interoperabilità tra L2. In teoria, Ethereum incentrato sul rollup è la stessa cosa dell'esecuzione dello shard L1. L'attuale ecosistema Ethereum L2 presenta ancora queste carenze rispetto allo stato ideale nella pratica:

1. Indirizzo di una catena specifica: l'indirizzo dovrebbe contenere informazioni sulla catena (L1, Ottimismo, Arbitrum...). Una volta ottenuto ciò, il processo di invio cross-L2 può essere implementato semplicemente inserendo l'indirizzo nel campo "invia", a quel punto il portafoglio può gestire l'invio da solo in background (incluso l'utilizzo di protocolli cross-chain) .

2. Richieste di pagamento specifiche della catena: dovrebbe essere semplice e standardizzato creare messaggi del tipo "Inviami X token di tipo Y sulla catena Z." Questo ha principalmente due scenari applicativi: (i) Che si tratti di pagamento tra persone o pagamento tra persone e servizi commerciali (ii) DApp che richiede fondi;

3. Scambio cross-chain e pagamento del gas: dovrebbe esserci un protocollo aperto standardizzato per esprimere operazioni cross-chain, come "Invierò 1 Ethereum alla persona che mi ha inviato 0,9999 Ethereum su Arbitrum (su Ottimismo)" e " Invierò 0,0001 ether (su Optimism) alla persona che ha incluso questa transazione su Arbitrum." ERC-7683 è un tentativo del primo, mentre RIP-7755 è un tentativo del secondo, sebbene entrambi abbiano applicazioni più ampie rispetto a questi casi d'uso specifici.

4. Light client: gli utenti dovrebbero essere in grado di verificare effettivamente la catena con cui interagiscono, anziché fidarsi semplicemente del provider RPC. Helios della crittografia a16z può farlo (per Ethereum stesso), ma dobbiamo estendere questa assenza di fiducia a L2. ERC-3668 (lettura CCIP) è una strategia per raggiungere questo obiettivo.

Una vista di come i light client aggiornano la catena di intestazioni di Ethereum. Una volta ottenuta la catena di intestazioni, puoi utilizzare le prove Merkle per verificare qualsiasi oggetto di stato. Una volta ottenuto l'oggetto stato L1 corretto, puoi utilizzare le prove Merkle (e le firme se desideri verificare la preconferma) per verificare qualsiasi oggetto stato su L2. Helios ha fatto il primo. Passare a quest’ultima è una sfida di standardizzazione.

1. Portafoglio Keystore: oggi, se desideri aggiornare la chiave che controlla il tuo portafoglio smart contract, devi aggiornarla su tutte le N catene in cui esiste il portafoglio. I portafogli Keystore sono una tecnologia che consente alle chiavi di esistere in un solo posto (su L1 o eventualmente successivamente su L2) e quindi qualsiasi L2 che ha una copia del portafoglio può leggere le chiavi da esso. Ciò significa che l'aggiornamento deve essere eseguito solo una volta. Per migliorare l'efficienza, il portafoglio Keystore richiede che L2 abbia un modo standardizzato per leggere le informazioni su L1 a costo zero, ci sono due proposte per questo, ovvero L1SLOAD e REMOTESTATICCALL;

Come funziona il portafoglio Keystore

2. Un concetto più radicale di "ponte di token condiviso": immagina un mondo in cui tutto L2 è un rollup di prova di validità e ogni slot viene inviato a Ethereum. Anche in un mondo del genere, il trasferimento di asset da una L2 a un’altra L2 nel suo stato nativo richiede ancora prelievi e depositi, che richiedono il pagamento di commissioni significative sul gas L1. Un modo per risolvere questo problema è creare un rollup minimalista condiviso la cui unica funzione è mantenere quale L2 possiede ciascun tipo di token e quanto saldo ha ciascuno, e consentire a questi saldi di passare attraverso una serie di transazioni avviate da qualsiasi operazione di invio L2 su L2 per gli aggiornamenti batch. Ciò consentirà di effettuare trasferimenti tra L2 senza dover pagare le commissioni sul gas L1 per ogni trasferimento e senza utilizzare tecnologie basate su fornitori di liquidità come ERC-7683.

3. Composizionalità sincrona: consente che avvengano chiamate sincrone tra una specifica L2 e L1 o tra più L2. Ciò aiuta a migliorare l’efficienza finanziaria dei protocolli DeFi. Il primo può essere implementato senza alcun coordinamento tra L2; il secondo richiede un ordinamento condiviso. Le tecniche basate sul rollup funzionano automaticamente con tutte.

Quali sono i collegamenti con la ricerca esistente?

Indirizzo specifico della catena: ERC-3770: https://eips.ethereum.org/EIPS/eip-3770

ERC-7683: https://eips.ethereum.org/EIPS/eip-7683

Italiano: RIP-7755: https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md

Scorri il design del portafoglio keystore: https://hackmd.io/@haichen/keystore

Elio: https://github.com/a16z/helios

ERC-3668 (a volte chiamato lettura CCIP): https://eips.ethereum.org/EIPS/eip-3668

Proposta di "preconfirmazioni basate (condivise)" proposta da Justin Drake: https://ethresear.ch/t/based-preconfirmations/17353

Scaricamento di L1SLOAD (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388

REMOTESTATICCALL in Ottimismo: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76

AggLayer, che include l'idea di un token bridge condiviso: https://github.com/AggLayer

Cos'altro è necessario fare? Quali sono i compromessi?

Molti degli esempi sopra riportati affrontano il dilemma degli standard su quando standardizzare e quali livelli standardizzare. Se standardizziamo troppo presto, rischiamo di consolidare una soluzione inadeguata. Se standardizzi troppo tardi, potresti creare una frammentazione non necessaria. In alcuni casi, esiste una soluzione a breve termine che ha proprietà più deboli ma è più facile da implementare, e una soluzione a lungo termine che è "alla fine corretta" ma richiede anni per essere implementata.

Questi compiti non sono solo problemi tecnici, sono anche (forse soprattutto) problemi sociali che richiedono la cooperazione tra la L2 e il portafoglio, nonché tra la L1.

Come posso interagire con le altre parti della roadmap?

La maggior parte di queste proposte sono strutture di "livello superiore" e quindi hanno un impatto minimo sulle considerazioni di livello L1. Un'eccezione è l'ordinamento condiviso, che ha un impatto significativo sul valore massimo estraibile (MEV).

Estendi l'esecuzione su L1

Quale problema stiamo risolvendo?

Se L2 diventa molto scalabile e di successo, ma L1 è ancora in grado di gestire solo volumi di transazioni molto piccoli, potrebbero sorgere una serie di rischi per Ethereum:

1. Lo stato economico degli asset ETH diventerà più instabile, il che a sua volta influirà sulla sicurezza a lungo termine della rete.

2. Molte L2 beneficiano di forti legami con l’ecosistema finanziario altamente sviluppato della L1, e se questo ecosistema viene significativamente indebolito, gli incentivi a diventare una L2 (invece di diventare una L1 indipendente) si indeboliranno.

3. Ci vorrà molto tempo prima che L2 raggiunga la stessa garanzia di sicurezza di L1.

4. Se L2 fallisce (ad esempio, a causa di un comportamento dannoso da parte dell'operatore o scompare), gli utenti dovranno comunque recuperare le proprie risorse tramite L1. Pertanto, L1 deve essere abbastanza potente da gestire, almeno occasionalmente, i tocchi finali altamente complessi e disordinati di L2.

Per questi motivi, è estremamente prezioso continuare ad espandere la stessa L1 e garantire che possa continuare a soddisfare un numero crescente di casi d’uso.

che cos'è? Come funziona?

Il modo più semplice per aumentare la portata è aumentare direttamente il limite del gas. Tuttavia, ciò potrebbe centralizzare L1, minando così un’altra importante caratteristica che rende Ethereum L1 così potente: la sua credibilità come robusto strato di base. C’è ancora un dibattito sulla misura in cui il semplice aumento del limite del gas sia sostenibile, e questo sarà influenzato anche da quali altre tecnologie saranno implementate per rendere più semplice la verifica di blocchi più grandi (ad esempio, scadenza della cronologia, apolidia, L1 EVM Validity Proof). Un’altra cosa importante che deve continuare a migliorare è l’efficienza del software client Ethereum, che è molto più efficiente oggi rispetto a cinque anni fa. Un’efficace strategia di limitazione del gas L1 comporterà l’accelerazione dello sviluppo di queste tecnologie di verifica.

1. EOF: un nuovo formato bytecode EVM più adatto all'analisi statica e che consente implementazioni più rapide. Considerati questi miglioramenti in termini di efficienza, il bytecode EOF può ottenere costi del gas inferiori.

2. Prezzi multidimensionali del gas: l’impostazione di tariffe base e limiti diversi per calcolo, dati e archiviazione può aumentare la capacità media di Ethereum L1 senza aumentare la capacità massima (evitando così la creazione di nuovi rischi per la sicurezza).

3. Riduzione dei costi del gas per specifici codici operativi e precompilazioni - Storicamente, abbiamo aumentato in diverse occasioni il costo del gas di alcune operazioni a basso prezzo per evitare attacchi di negazione del servizio. Una cosa che potrebbe essere fatta di più è ridurre i costi del gas per codici operativi troppo costosi. Ad esempio, l'addizione è molto più economica della moltiplicazione, ma attualmente i codici operativi ADD e MUL costano lo stesso. Possiamo rendere ADD più economico e codici operativi ancora più semplici come PUSH più economici. EOF è nel complesso più ottimizzato a questo riguardo.

4. EVM-MAX e SIMD: EVM-MAX è una proposta per consentire una matematica analogica nativa di grandi numeri più efficiente come modulo separato dell'EVM. A meno che non siano esportati intenzionalmente, i valori calcolati dai calcoli EVM-MAX sono accessibili solo da altri codici operativi EVM-MAX. Ciò consente più spazio per memorizzare questi valori in un formato ottimizzato. SIMD (single instructions multiple data) è una proposta che consente l'esecuzione efficiente della stessa istruzione su un array di valori. Insieme, i due creano un potente coprocessore insieme all'EVM che può essere utilizzato per implementare operazioni crittografiche in modo più efficiente. Ciò è particolarmente utile per i protocolli di privacy e i sistemi di protezione L2, quindi aiuterà con il ridimensionamento L1 e L2.

Questi miglioramenti verranno discussi più dettagliatamente nei futuri articoli su Splurge.

Infine, la terza strategia sono i rollup nativi (o rollup incorporati): essenzialmente, creare molte copie dell'EVM che vengono eseguite in parallelo, risultando in un modello equivalente a ciò che Rollup può fornire, ma più integrato in modo nativo nel protocollo.

Quali sono i collegamenti con la ricerca esistente?

1. Roadmap di ridimensionamento di Ethereum L1 di Polynya: https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ

2. Prezzi multidimensionali del gas: https://vitalik.eth.limo/general/2024/05/09/multidim.html

3. EIP-7706: https://eips.ethereum.org/EIPS/eip-7706

4. Fine della sessione: https://evmobjectformat.org/

5. EVM-MAX: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168

6. SIMD: https://eips.ethereum.org/EIPS/eip-616

7. Rollup nativi: https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE

8. Intervista a Max Resnick sul valore dello scaling di L1: https://x.com/BanklessHQ/status/1831319419739361321

9. Justin Drake parla della scalabilità con SNARK e rollup nativi: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

Cos’altro è necessario fare e quali sono i compromessi?

Esistono tre strategie per l'espansione L1, che possono essere eseguite individualmente o in parallelo:

1. Migliorare le tecniche (ad esempio codice cliente, clienti apolidi, scadenza della cronologia) per rendere L1 più facile da verificare, quindi aumentare i limiti del gas.

2. Ridurre i costi per operazioni specifiche e aumentare la capacità media senza aumentare il rischio nel caso peggiore;

3. Rollup nativi (ovvero, creazione di N copie parallele dell'EVM).

Comprendendo queste diverse tecnologie, scopriremo che esistono diversi compromessi. Ad esempio, i Rollup nativi soffrono di molti degli stessi punti deboli in componibilità dei Rollup semplici: non è possibile inviare una singola transazione per eseguire operazioni in modo sincrono su più Rollup, come si può fare all'interno di un contratto sulla stessa L1 (o L2) che modo. L’aumento del limite massimo comprometterebbe altri vantaggi che possono essere ottenuti semplificando la verifica L1, come l’aumento della percentuale di utenti che eseguono nodi di convalida e l’aumento del numero di staker solisti. A seconda dell'implementazione, rendere più economiche operazioni specifiche nell'EVM (Ethereum Virtual Machine) può aumentare la complessità complessiva dell'EVM.

Una grande domanda a cui deve rispondere qualsiasi roadmap di ridimensionamento L1 è: qual è la visione definitiva per L1 e L2? Ovviamente, mettere tutto su L1 è ridicolo: i potenziali casi d'uso potrebbero coinvolgere centinaia di migliaia di transazioni al secondo, il che renderebbe L1 completamente inverificabile (a meno che non si segua il percorso Rollup nativo). Ma abbiamo bisogno di alcune linee guida per assicurarci di non entrare in una situazione in cui un aumento di 10 volte del limite massimo danneggerebbe gravemente la decentralizzazione di Ethereum L1.

Una visione della divisione del lavoro tra L1 e L2

Come interagisco con le altre parti della roadmap?

Portare più utenti in L1 significa non solo migliorare la scalabilità, ma anche migliorare altri aspetti di L1. Ciò significa che più MEV rimarrà su L1 (invece di diventare semplicemente un problema di L2), quindi la necessità di gestire esplicitamente MEV diventerà più urgente. Ciò aumenterà notevolmente il valore degli slot time veloci su L1. Allo stesso tempo, ciò dipende fortemente anche dal regolare svolgimento della verifica L1 (The Verge).

Lettura consigliata: (Il nuovo articolo di Vitalik: Il possibile futuro di Ethereum, la fusione)