Nuovo articolo di Vitalik: Il possibile futuro del protocollo Ethereum The Verge

In realtà, ci vorranno anni prima di ottenere una prova di validità del consenso di Ethereum.

Titolo originale: 《Possible futures of the Ethereum protocol, part 4: The Verge》

Autore: Vitalik Buterin

Traduzione: Mensh, ChainCatcher

 

Un ringraziamento speciale a Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy, Ryan Sean Adams e Uma Roy per i loro feedback e la revisione.

Una delle funzionalità più potenti della blockchain è che chiunque può eseguire un nodo sul proprio computer e verificare la correttezza della blockchain. Anche se 9596 nodi che eseguono il consenso della catena (PoW, PoS) concordassero immediatamente nel cambiare le regole e iniziassero a produrre blocchi secondo le nuove regole, ogni persona che esegue un nodo di piena validazione rifiuterebbe di accettare la catena. I minatori che non fanno parte di questa cospirazione si raggrupperanno automaticamente su una catena che continua a seguire le vecchie regole e continueranno a costruire su quella catena, mentre gli utenti che eseguono la piena validazione seguiranno quella catena.

Questa è la differenza chiave tra blockchain e sistemi centralizzati. Tuttavia, affinché questa caratteristica sia valida, eseguire un nodo di piena validazione deve essere effettivamente fattibile per un numero sufficiente di persone. Questo vale sia per i produttori di blocchi (perché se non validano la catena, non contribuiscono all'esecuzione delle regole del protocollo), sia per gli utenti comuni. Oggi è possibile eseguire un nodo su un laptop consumer (incluso il laptop che sto usando per scrivere questo articolo), ma è comunque difficile. The Verge mira a cambiare questa situazione, rendendo il costo computazionale della piena validazione della catena molto basso, così che ogni wallet su smartphone, browser wallet e persino smartwatch esegua la validazione di default.

Roadmap di The Verge 2023

Inizialmente, "Verge" si riferiva al trasferimento dell'archiviazione dello stato di Ethereum agli alberi Verkle—una struttura ad albero che consente prove più compatte, abilitando la validazione stateless dei blocchi Ethereum. Un nodo può validare un blocco Ethereum senza dover archiviare alcuno stato di Ethereum (bilanci degli account, codice dei contratti, storage...) sul proprio disco rigido, al costo di alcune centinaia di KB di dati di prova e qualche centinaio di millisecondi di tempo extra per verificare una prova. Oggi, Verge rappresenta una visione più ampia, focalizzata sull'ottenere la massima efficienza delle risorse nella validazione della catena Ethereum, che include non solo la tecnologia di validazione stateless, ma anche l'uso di SNARK per verificare tutta l'esecuzione di Ethereum.

Oltre all'attenzione a lungo termine sulla verifica SNARK dell'intera catena, un'altra questione recente riguarda se gli alberi Verkle siano la tecnologia migliore. Gli alberi Verkle sono vulnerabili agli attacchi dei computer quantistici, quindi se sostituiamo l'attuale Merkle Patricia Tree KECCAK con un albero Verkle, dovremo sostituire nuovamente l'albero in futuro. Il metodo auto-sostitutivo degli alberi Merkle è saltare direttamente all'uso di STARK con rami Merkle, inserendoli in un albero binario. Storicamente, a causa dei costi e della complessità tecnica, questo approccio è stato ritenuto impraticabile. Tuttavia, di recente, abbiamo visto Starkware dimostrare 1,7 milioni di hash Poseidon al secondo su un laptop, e grazie a tecnologie come GKB, anche i tempi di prova per hash più "tradizionali" stanno rapidamente diminuendo. Così, nell'ultimo anno, "Verge" è diventato più aperto, con diverse possibilità.

The Verge: obiettivi chiave

• Client stateless: lo spazio di archiviazione richiesto per client di piena validazione e nodi marcatori non dovrebbe superare pochi GB.
• (A lungo termine) Piena validazione della catena (consenso ed esecuzione) su uno smartwatch. Scarica alcuni dati, verifica uno SNARK, fatto.

In questo capitolo

• Client stateless: Verkle o STARKs
• Prova di validità dell'esecuzione EVM
• Prova di validità del consenso

Validazione stateless: Verkle o STARKs

Qual è il problema da risolvere?

Oggi, i client Ethereum devono archiviare centinaia di gigabyte di dati di stato per validare i blocchi, e questa quantità aumenta ogni anno. I dati di stato grezzi aumentano di circa 30GB all'anno, e ogni client deve archiviare alcuni dati aggiuntivi per aggiornare efficacemente la tripla.

Questo riduce il numero di utenti in grado di eseguire un nodo Ethereum di piena validazione: sebbene siano comuni dischi rigidi abbastanza grandi da archiviare tutto lo stato di Ethereum e persino anni di storia, i computer che le persone acquistano di default spesso hanno solo poche centinaia di GB di spazio. La dimensione dello stato crea anche grande attrito nel processo di bootstrap di un nodo: il nodo deve scaricare l'intero stato, il che può richiedere ore o giorni. Questo genera vari effetti a catena. Ad esempio, rende molto più difficile per i produttori di nodi aggiornare la configurazione del nodo. Tecnicamente, è possibile farlo senza downtime—avviare un nuovo client, attendere che si sincronizzi, poi spegnere il vecchio client e trasferire le chiavi—ma in pratica è molto complesso tecnicamente.

Come funziona?

La validazione stateless è una tecnica che consente ai nodi di validare i blocchi senza possedere l'intero stato. Invece, ogni blocco viene fornito con una "witness" che include: (i) i valori, il codice, i bilanci, lo storage in posizioni specifiche dello stato che il blocco accederà; (ii) prove crittografiche che questi valori sono corretti.

In pratica, implementare la validazione stateless richiede di cambiare la struttura dell'albero di stato di Ethereum. Questo perché l'attuale Merkle Patricia Tree è estremamente poco amichevole per qualsiasi schema di prova crittografica, specialmente nei casi peggiori. Sia che si tratti di rami "raw" Merkle, sia che si tratti di possibilità "incapsulate" in STARK. La difficoltà principale deriva da alcune debolezze dell'MPT:

1. È un albero esadecimale (ogni nodo ha 16 figli). Questo significa che, in un albero di dimensione N, una prova richiede in media 32*(16-1)*log16(N) = 120*log2(N) byte, ovvero circa 3840 byte in un albero di 2^32 elementi. Per un albero binario, servono solo 32*(2-1)*log2(N) = 32*log2(N) byte, ovvero circa 1024 byte.

2. Il codice non è "Merkleizzato". Questo significa che per provare l'accesso al codice di un account, bisogna fornire tutto il codice, fino a 24000 byte.

 

Possiamo calcolare il caso peggiore come segue:

30000000 gas / 2400 (costo lettura account freddo) * (5 * 488 + 24000) = 330000000 byte

Il costo dei rami è leggermente inferiore (usando 5*480 invece di 8*480), perché quando ci sono molti rami, la parte superiore si ripete. Ma anche così, la quantità di dati da scaricare in uno slot è completamente irrealistica. Se proviamo a incapsularlo in uno STARK, incontriamo due problemi: (i) KECCAK è relativamente poco amichevole per STARK; (ii) 330MB di dati significa che dobbiamo provare 5 milioni di chiamate alla funzione round di KECCAK, il che potrebbe essere impossibile da provare per qualsiasi hardware consumer tranne il più potente, anche se riuscissimo a rendere la prova STARK di KECCAK più efficiente.

Se sostituiamo direttamente l'albero esadecimale con un albero binario e "Merkleizziamo" anche il codice, il caso peggiore diventa circa 30000000/2400*32*(32-14+8) = 10400000 byte (14 è la sottrazione per i bit ridondanti di 2^14 rami, 8 è la lunghezza della prova per entrare nella foglia del blocco di codice). Va notato che questo richiede di cambiare il costo del gas, addebitando per ogni blocco di codice separato; EIP-4762 fa proprio questo. 10,4 MB è molto meglio, ma per molti nodi è ancora troppi dati da scaricare in uno slot. Quindi, abbiamo bisogno di tecniche più potenti. In questo senso, ci sono due soluzioni principali: alberi Verkle e alberi hash binari STARKed.

Alberi Verkle

Gli alberi Verkle usano impegni vettoriali basati su curve ellittiche per prove più brevi. La chiave è che, indipendentemente dalla larghezza dell'albero, ogni parte della prova tra padre e figlio è solo di 32 byte. L'unico limite alla larghezza dell'albero è che, se troppo largo, l'efficienza computazionale della prova diminuisce. La proposta per Ethereum prevede una larghezza di 256.

Quindi, la dimensione di un singolo ramo nella prova diventa 32 - log256(N) = 4*log2(N) byte. Quindi, la dimensione massima teorica della prova è circa 30000000 / 2400 * 32 * (32 -14 + 8) / 8 = 130000 byte (a causa della distribuzione non uniforme dei blocchi di stato, il risultato reale varia leggermente, ma come prima approssimazione va bene).

Va anche notato che, in tutti gli esempi sopra, questo "caso peggiore" non è il peggiore: un caso peggiore è che un attaccante "scavi" due indirizzi con un prefisso comune più lungo nell'albero e legga dati da uno di essi, il che può raddoppiare la lunghezza del ramo nel caso peggiore. Ma anche così, la lunghezza massima della prova di un albero Verkle è 2,6MB, in linea con i dati di verifica nel caso peggiore attuale.

Abbiamo anche sfruttato questa osservazione per un'altra cosa: rendiamo molto economico l'accesso a spazi di storage "adiacenti": molti blocchi di codice dello stesso contratto o slot di storage adiacenti. EIP-4762 fornisce una definizione di adiacenza e addebita solo 200 gas per accessi adiacenti. In questo caso, la dimensione massima della prova diventa 30000000 / 200*32 - 4800800 byte, ancora entro limiti accettabili. Se per sicurezza vogliamo ridurre questo valore, possiamo aumentare leggermente il costo degli accessi adiacenti.

Alberi hash binari STARKed

Questa tecnica è autoesplicativa: basta creare un albero binario, ottenere una prova massima di 10,4 MB, provare i valori nel blocco, poi sostituire la prova con una STARK. Così, la prova stessa contiene solo i dati provati, più un overhead fisso di 100-300kB dalla STARK reale.

La sfida principale qui è il tempo di verifica. Possiamo fare lo stesso calcolo di prima, ma invece di byte, contiamo gli hash. Un blocco da 10,4 MB significa 330000 hash. Se aggiungiamo la possibilità che un attaccante "scavi" indirizzi con prefissi comuni più lunghi, il caso peggiore arriva a circa 660000 hash. Quindi, se possiamo provare 200.000 hash al secondo, va bene.

Su un laptop consumer usando la funzione hash Poseidon, questi numeri sono già raggiunti, e Poseidon è progettato appositamente per essere STARK-friendly. Tuttavia, Poseidon è ancora relativamente nuovo, quindi molti non si fidano ancora della sua sicurezza. Quindi, ci sono due strade realistiche:

1. Analizzare rapidamente la sicurezza di Poseidon e acquisire abbastanza familiarità da poterlo implementare su L1
2. Usare funzioni hash più "conservative", come SHA256 o BLAKE

Per provare funzioni hash conservative, il circuito STARK di Starkware, al momento della scrittura, può provare solo 10-30k hash al secondo su un laptop consumer. Tuttavia, la tecnologia STARK sta migliorando rapidamente. Anche oggi, tecniche basate su GKR mostrano che questa velocità può essere aumentata a 100-200k.

Altri casi d'uso delle witness oltre la verifica dei blocchi

Oltre alla verifica dei blocchi, ci sono altri tre casi d'uso chiave che richiedono una validazione stateless più efficiente:

• Mempool: quando una transazione viene trasmessa, i nodi nella rete P2P devono verificare la validità della transazione prima di ritrasmetterla. Oggi la verifica include la firma e il controllo del saldo e del nonce. In futuro (ad esempio, con account abstraction nativa come EIP-7701), questo potrebbe includere l'esecuzione di codice EVM che accede allo stato. Se il nodo è stateless, la transazione deve includere una prova degli oggetti di stato.
• Inclusion list: è una funzione proposta che consente ai validatori PoS (probabilmente piccoli e non complessi) di forzare l'inclusione di una transazione nel prossimo blocco, indipendentemente dalla volontà dei costruttori di blocchi (probabilmente più grandi e complessi). Questo riduce la capacità dei potenti di manipolare la blockchain ritardando le transazioni. Tuttavia, richiede che i validatori possano verificare la validità delle transazioni nell'inclusion list.
• Light client: se vogliamo che gli utenti accedano alla chain tramite wallet (come Metamask, Rainbow, Rabby, ecc.), devono eseguire un light client (come Helios). Il modulo core di Helios fornisce agli utenti la root di stato verificata. Per un'esperienza completamente trustless, l'utente deve fornire una prova per ogni chiamata RPC (ad esempio, per una chiamata eth_call, l'utente deve provare tutti gli stati acceduti durante la chiamata).

Tutti questi casi d'uso hanno in comune la necessità di molte prove, ma ciascuna molto piccola. Quindi, le prove STARK non hanno molto senso qui; la soluzione più realistica è usare direttamente i rami Merkle. Un altro vantaggio dei rami Merkle è che sono aggiornabili: dato una prova di un oggetto di stato radicato nel blocco B, se si riceve un sotto-blocco B2 e la sua witness, si può aggiornare la prova per radicarla in B2. Anche le prove Verkle sono nativamente aggiornabili.

Collegamenti con la ricerca esistente:

• Verkle trees
• Articolo originale di John Kuszmaul sugli alberi Verkle
• Starkware
• Poseidon2 paper
• Ajtai (funzioni hash alternative veloci basate sulla durezza dei reticoli)
• Verkle.info

Cosa resta da fare?

Il lavoro principale che resta è

1. Ulteriori analisi sulle conseguenze di EIP-4762 (variazioni del costo del gas stateless)

2. Ulteriore lavoro per completare e testare il programma di transizione, che è la parte principale della complessità di qualsiasi implementazione stateless

3. Ulteriore analisi della sicurezza di Poseidon, Ajtai e altre funzioni hash "STARK-friendly"

4. Sviluppare ulteriormente protocolli STARK ultra-efficienti per hash "conservativi" (o "tradizionali"), ad esempio con tecniche basate su Binius o GKR.

Inoltre, presto dovremo scegliere tra tre opzioni: (i) alberi Verkle, (ii) funzioni hash STARK-friendly e (iii) funzioni hash conservative. Le loro caratteristiche sono riassunte nella tabella seguente:

Oltre a questi "numeri di copertina", ci sono altre considerazioni importanti:

• Oggi, il codice degli alberi Verkle è già abbastanza maturo. Usare qualsiasi altro codice oltre a Verkle ritarderà la distribuzione, probabilmente ritardando un hard fork. Questo non è un problema, soprattutto se abbiamo bisogno di più tempo per l'analisi delle funzioni hash o l'implementazione dei validatori, o se abbiamo altre funzionalità importanti da includere prima in Ethereum.
• Aggiornare la root di stato usando hash è più veloce che con gli alberi Verkle. Questo significa che i metodi basati su hash possono ridurre il tempo di sincronizzazione dei nodi completi.
• Gli alberi Verkle hanno interessanti proprietà di aggiornamento delle witness—le witness Verkle sono aggiornabili. Questa proprietà è utile per mempool, inclusion list e altri casi d'uso, e può anche aiutare l'efficienza: se un oggetto di stato viene aggiornato, si può aggiornare la witness del penultimo livello senza leggere l'ultimo livello.
• Gli alberi Verkle sono più difficili da provare con SNARK. Se vogliamo ridurre la dimensione della prova a pochi KB, le prove Verkle presentano alcune difficoltà. Questo perché la verifica delle prove Verkle introduce molte operazioni a 256 bit, che richiedono al sistema di prova di avere un grande overhead o una struttura interna personalizzata con una parte di prova Verkle a 256 bit. Questo non è un problema per la statelessness in sé, ma aggiunge difficoltà.

Se vogliamo ottenere l'aggiornabilità delle witness Verkle in modo sicuro contro i quanti e ragionevolmente efficiente, un'altra possibile strada sono gli alberi Merkle basati su reticoli.

Se, nel caso peggiore, l'efficienza del sistema di prova non è sufficiente, possiamo anche usare il multidimensional gas, uno strumento inaspettato, per compensare: impostare limiti separati di gas per (i) calldata; (ii) calcolo; (iii) accesso allo stato e forse altre risorse. Il multidimensional gas aumenta la complessità, ma in cambio limita più rigorosamente il rapporto tra caso medio e caso peggiore. Con il multidimensional gas, il numero massimo teorico di rami da provare può scendere da 12500 a, ad esempio, 3000. Questo renderebbe BLAKE3 (appena) sufficiente anche oggi.

Il multidimensional gas consente limiti alle risorse dei blocchi più vicini ai limiti delle risorse hardware sottostanti

Un altro strumento inaspettato è ritardare il calcolo della root di stato allo slot successivo al blocco. Così, abbiamo 12 secondi interi per calcolare la root di stato, il che significa che anche nel caso più estremo, una velocità di prova di 60000 hash al secondo è sufficiente, il che ancora una volta rende BLAKE3 appena sufficiente.

Lo svantaggio di questo approccio è che aumenta la latenza del light client di uno slot, ma ci sono tecniche più intelligenti per ridurre questa latenza al solo ritardo di generazione della prova. Ad esempio, la prova può essere trasmessa sulla rete non appena viene generata da qualsiasi nodo, senza attendere il blocco successivo.

Come interagisce con le altre parti della roadmap?

Risolvere il problema stateless aumenta notevolmente la difficoltà dello staking singolo. Se ci sono tecnologie che abbassano il saldo minimo per lo staking singolo, come Orbit SSF o strategie a livello di applicazione come lo staking di gruppo, questo diventa più fattibile.

Se viene introdotto EOF contemporaneamente, l'analisi del multidimensional gas diventa più semplice. Questo perché la complessità principale dell'esecuzione del multidimensional gas deriva dalla gestione delle chiamate figlio che non trasmettono tutto il gas del genitore, mentre EOF rende illegali tali chiamate, rendendo il problema banale (e l'account abstraction nativa fornirà un'alternativa interna per l'uso principale attuale del gas parziale).

C'è anche una sinergia importante tra validazione stateless e scadenza della storia. Oggi, i client devono archiviare quasi 1TB di dati storici; questi dati sono molte volte lo stato. Anche se il client è stateless, a meno che non possiamo rimuovere la responsabilità di archiviare i dati storici, il sogno di un client quasi senza storage non sarà realizzato. Il primo passo in questa direzione è EIP-4444, che significa anche archiviare i dati storici su torrents o sulla Portal Network.

Prova di validità dell'esecuzione EVM

Qual è il problema da risolvere?

L'obiettivo a lungo termine della validazione dei blocchi Ethereum è chiaro: dovrebbe essere possibile validare un blocco Ethereum tramite: (i) scaricare il blocco, o anche solo una piccola parte del campionamento della disponibilità dei dati del blocco; (ii) verificare una piccola prova della validità del blocco. Questa sarà un'operazione a bassissimo consumo di risorse, eseguibile su client mobili, wallet browser e persino su un'altra chain (senza la parte della disponibilità dei dati).

Per raggiungere questo obiettivo, è necessario provare con SNARK o STARK sia (i) il livello di consenso (cioè la proof of stake) sia (ii) il livello di esecuzione (cioè EVM). Il primo è una sfida a sé, da affrontare con continui miglioramenti del livello di consenso (ad esempio, per la finalità single-slot). Il secondo richiede la prova dell'esecuzione EVM.

Cos'è e come funziona?

Formalmente, nelle specifiche di Ethereum, l'EVM è definita come una funzione di transizione di stato: hai uno stato precedente S, un blocco B, e calcoli uno stato successivo S' = STF(S, B). Se l'utente usa un light client, non possiede S e S' completi, né E; invece, ha una root di stato precedente R, una root di stato successiva R' e un hash del blocco H.

• Input pubblico: root di stato precedente R, root di stato successiva R', hash del blocco H
• Input privato: corpo del blocco B, oggetti nello stato accessibili dal blocco Q, stessi oggetti dopo l'esecuzione del blocco Q', prove di stato (come rami Merkle) P
• Affermare 1: P è una prova valida che Q contiene alcune parti dello stato rappresentato da R
• Affermare 2: Se si esegue STF su Q, (i) il processo accede solo agli oggetti interni a Q, (ii) il blocco è valido, (iii) il risultato è Q'
• Affermare 3: Se si ricalcola la nuova root di stato usando le informazioni di Q' e P, si ottiene R'

Se tutto ciò esiste, si può avere un light client che verifica completamente l'esecuzione EVM di Ethereum. Questo riduce già molto le risorse richieste dal client. Per avere un client Ethereum completamente verificato, serve lo stesso lavoro anche per il consenso.

Le prove di validità per il calcolo EVM esistono già e sono ampiamente usate su L2. Ma per rendere le prove di validità EVM fattibili su L1, c'è ancora molto lavoro da fare.

Collegamenti con la ricerca esistente?

• EFPSE ZK-EVM (ora deprecato per soluzioni migliori)
• Zeth, che compila l'EVM in RISC-0 ZK-VM
• Progetto di formalizzazione ZK-EVM

Cosa resta da fare?

Oggi, le prove di validità dei sistemi di contabilità elettronica sono carenti su due fronti: sicurezza e tempo di verifica.

Una prova di validità sicura deve garantire che lo SNARK verifichi effettivamente il calcolo EVM e che non ci siano vulnerabilità. Le due principali tecniche per aumentare la sicurezza sono i multi-verificatori e la verifica formale. I multi-verificatori sono implementazioni di prove di validità scritte indipendentemente, come i client multipli; se un blocco è provato da un sottoinsieme sufficientemente grande di queste implementazioni, il client lo accetta. La verifica formale implica l'uso di strumenti normalmente usati per dimostrare teoremi matematici, come Lean4, per dimostrare che la prova di validità accetta solo esecuzioni corrette della specifica EVM sottostante (ad esempio, la semantica K di EVM o la specifica EELS in python).

Un tempo di verifica sufficientemente veloce significa che qualsiasi blocco Ethereum può essere verificato in meno di 4 secondi. Oggi siamo ancora lontani da questo obiettivo, anche se siamo più vicini di quanto si pensasse due anni fa. Per raggiungerlo, servono progressi in tre direzioni:

• Parallelizzazione—il più veloce verificatore EVM attuale può provare un blocco Ethereum in media in 15 secondi. Questo è ottenuto parallelizzando su centinaia di GPU e poi aggregando il lavoro. In teoria, sappiamo come costruire un verificatore EVM che prova il calcolo in tempo O(log(N)): una GPU per ogni step, poi un "albero di aggregazione":

Implementare questo è una sfida. Anche nel caso peggiore, cioè una transazione molto grande che occupa tutto il blocco, la suddivisione del calcolo non può essere fatta per transazione, ma deve essere fatta per opcode (opcode EVM o RISC-V). Garantire che la "memoria" della VM sia coerente tra le diverse parti della prova è una sfida chiave. Tuttavia, se riusciamo a implementare questa prova ricorsiva, sappiamo che almeno il problema della latenza del prover è risolto, anche senza altri miglioramenti.

• Ottimizzazione dei sistemi di prova—nuovi sistemi di prova come Orion, Binius, GRK e altri probabilmente ridurranno ancora il tempo di verifica del calcolo generico.
• Altri cambiamenti al costo del gas EVM—molte cose nell'EVM possono essere ottimizzate per favorire i prover, specialmente nei casi peggiori. Se un attaccante può costruire un blocco che blocca il prover per dieci minuti, non basta poter provare un blocco Ethereum normale in 4 secondi. I cambiamenti necessari all'EVM si dividono in:
• Variazioni del costo del gas—se un'operazione richiede molto tempo per essere provata, anche se è relativamente veloce da calcolare, dovrebbe avere un costo di gas elevato. EIP-7667 è stato proposto per affrontare i problemi più gravi: aumenta molto il costo di gas delle funzioni hash (opcode e precompilati), che sono relativamente economici. Per compensare, possiamo ridurre il costo di gas degli opcode EVM che sono relativamente economici da provare, mantenendo invariata la throughput media.
• Sostituzione delle strutture dati—oltre a sostituire l'albero di stato con uno più STARK-friendly, dobbiamo sostituire la lista delle transazioni, l'albero delle ricevute e altre strutture costose da provare. L'EIP di Etan Kissling che sposta transazioni e ricevute su SSZ è un passo in questa direzione.

Oltre a ciò, anche i due strumenti menzionati nella sezione precedente (multidimensional gas e root di stato ritardata) possono aiutare. Tuttavia, va notato che, a differenza della validazione stateless, l'uso di questi strumenti significa che abbiamo già abbastanza tecnologia per fare ciò che ci serve ora, mentre anche con questi strumenti, la verifica completa ZK-EVM richiede ancora molto lavoro—solo un po' meno.

Un punto non menzionato sopra è l'hardware del prover: usare GPU, FPGA e ASIC per generare prove più velocemente. Fabric Cryptography, Cysic e Accseal sono tre aziende che stanno facendo progressi in questo campo. Questo è molto prezioso per L2, ma probabilmente non sarà un fattore decisivo per L1, perché si desidera fortemente che L1 rimanga altamente decentralizzato, il che significa che la generazione delle prove deve essere alla portata degli utenti Ethereum, senza colli di bottiglia dovuti all'hardware di una singola azienda. L2 può fare scelte più aggressive.

In questi ambiti, resta ancora molto lavoro da fare:

• La parallelizzazione delle prove richiede che le diverse parti del sistema di prova possano "condividere la memoria" (come le lookup table). Sappiamo come farlo, ma va implementato.
• Serve più analisi per trovare il set ideale di variazioni del costo del gas per minimizzare il tempo di verifica nel caso peggiore.
• Serve più lavoro sui sistemi di prova

I possibili trade-off sono:

• Sicurezza vs tempo del prover: scegliere funzioni hash più aggressive, sistemi di prova più complessi o ipotesi di sicurezza più aggressive o altri design può ridurre il tempo del prover.
• Decentralizzazione vs tempo del prover: la comunità deve concordare sulle "specifiche" dell'hardware del prover. È accettabile che i prover siano grandi entità? Vogliamo che un laptop consumer di fascia alta possa provare un blocco Ethereum in 4 secondi? O qualcosa nel mezzo?
• Grado di rottura della retrocompatibilità: altre carenze possono essere compensate con variazioni più aggressive del costo del gas, ma questo potrebbe aumentare in modo sproporzionato il costo di alcune applicazioni, costringendo gli sviluppatori a riscrivere e ridistribuire il codice per mantenere la sostenibilità economica. Anche questi strumenti hanno la loro complessità e svantaggi.

Come interagisce con le altre parti della roadmap?

La tecnologia core necessaria per la prova di validità EVM su L1 è in gran parte condivisa con altri due ambiti:

• Prove di validità L2 (cioè "ZK rollup")
• Metodo stateless "STARK binary hash proof"

Se la prova di validità viene implementata con successo su L1, sarà finalmente possibile lo staking singolo facile: anche i computer più deboli (inclusi smartphone e smartwatch) potranno fare staking. Questo aumenta ulteriormente il valore di risolvere altri limiti dello staking singolo (come il limite minimo di 32ETH).

Inoltre, la prova di validità EVM su L1 può aumentare notevolmente il gas limit di L1.

Prova di validità del consenso

Qual è il problema da risolvere?

Se vogliamo validare completamente un blocco Ethereum con uno SNARK, l'esecuzione EVM non è l'unica parte da provare. Dobbiamo anche provare il consenso, cioè la parte del sistema che gestisce depositi, prelievi, firme, aggiornamenti dei bilanci dei validatori e altri elementi della proof of stake di Ethereum.

Il consenso è molto più semplice dell'EVM, ma la sfida è che non abbiamo rollup EVM L2, quindi comunque la maggior parte del lavoro va fatto. Quindi, qualsiasi implementazione della prova del consenso di Ethereum deve essere fatta "da zero", anche se il sistema di prova può essere costruito su lavoro condiviso.

Cos'è e come funziona?

La beacon chain è definita come una funzione di transizione di stato, proprio come l'EVM. La funzione di transizione di stato è composta principalmente da tre parti:

• ECADD (per verificare le firme BLS)
• Pairing (per verificare le firme BLS)
• Hash SHA256 (per leggere e aggiornare lo stato)

In ogni blocco, dobbiamo provare 1-16 ECADD BLS12-381 per ogni validatore (potrebbero essere più di uno, perché una firma può essere inclusa in più set). Questo può essere mitigato con tecniche di precomputazione dei sottoinsiemi, quindi possiamo dire che ogni validatore deve provare solo un ECADD BLS12-381. Attualmente, ci sono 30000 firme di validatori per slot. In futuro, con la finalità single-slot, questo numero potrebbe cambiare in due direzioni: se scegliamo la strada "brute force", il numero di validatori per slot potrebbe salire a 1 milione. Se invece usiamo Orbit SSF, il numero di validatori resterà a 32768, o addirittura scenderà a 8192.

Come funziona l'aggregazione BLS: la verifica della firma totale richiede solo un ECADD per partecipante, non un ECMUL. Ma 30000 ECADD sono ancora molte prove.

Per quanto riguarda il pairing, attualmente ci sono al massimo 128 prove per slot, quindi bisogna verificare 128 pairing. Con EIP-7549 e ulteriori modifiche, per slot si può scendere a 16. I pairing sono pochi, ma molto costosi: ogni pairing richiede (o prova) migliaia di volte più tempo di un ECADD.

Una delle principali sfide nel provare le operazioni BLS12-381 è che non esiste una curva con ordine uguale alla dimensione del campo di BLS12-381, il che aggiunge molto overhead a qualsiasi sistema di prova. D'altra parte, l'albero Verkle proposto per Ethereum è costruito sulla curva Bandersnatch, il che rende BLS12-381 la curva nativa nel sistema SNARK per provare i rami Verkle. Un'implementazione semplice può provare 100 addizioni G1 al secondo; per velocità sufficienti, serviranno tecniche intelligenti come GKR.

Per gli hash SHA256, il caso peggiore attuale è il blocco di transizione dell'epoca, dove l'intero short balance tree dei validatori e molti bilanci vengono aggiornati. Ogni short balance tree di validatore è solo un byte, quindi 1 MB di dati viene ri-hashato. Questo equivale a 32768 chiamate SHA256. Se il bilancio di mille validatori supera o scende sotto una soglia, bisogna aggiornare i record dei validatori, il che equivale a mille rami Merkle, quindi forse 10000 hash. Il meccanismo di shuffling richiede 90 bit per validatore (quindi 11 MB di dati), ma può essere calcolato in qualsiasi momento dell'epoca. Con la finalità single-slot, questi numeri possono variare. Lo shuffling diventa inutile, anche se Orbit potrebbe ripristinare parzialmente questa necessità.

Un'altra sfida è che bisogna recuperare di nuovo lo stato di tutti i validatori, incluse le chiavi pubbliche, per verificare un blocco. Per 1 milione di validatori, solo leggere le chiavi pubbliche richiede 48 milioni di byte, più i rami Merkle. Questo richiede milioni di hash per epoca. Se dobbiamo provare la validità del PoS, una soluzione realistica è una qualche forma di calcolo incrementale verificabile: memorizzare nel sistema di prova una struttura dati separata, ottimizzata per ricerche efficienti e per provare gli aggiornamenti.

In sintesi, le sfide sono molte. Per affrontarle al meglio, probabilmente servirà una profonda riprogettazione della beacon chain, che potrebbe avvenire insieme al passaggio alla finalità single-slot. Questa riprogettazione potrebbe includere:

• Cambio della funzione hash: ora si usa SHA256 "completo", quindi per via del padding ogni chiamata equivale a due chiamate alla funzione di compressione sottostante. Se si passa alla funzione di compressione SHA256, si ottiene almeno un raddoppio della velocità. Se si passa a Poseidon, si può ottenere un guadagno di 100 volte, risolvendo tutti i problemi (almeno per gli hash): a 1,7 milioni di hash al secondo (54MB), anche 1 milione di record di validatori può essere "letto" nella prova in pochi secondi.
• Se si usa Orbit, si archiviano direttamente i record dei validatori già mescolati: se si scelgono un certo numero di validatori (come 8192 o 32768) come comitato per uno slot, li si mette direttamente uno accanto all'altro nello stato, così basta pochissimo hash per leggere tutte le chiavi pubbliche dei validatori nella prova. Questo consente anche aggiornamenti efficienti dei bilanci.
• Aggregazione delle firme: qualsiasi schema di aggregazione delle firme ad alte prestazioni comporterà una qualche forma di prova ricorsiva, con nodi diversi della rete che provano sottoinsiemi di firme. Questo distribuisce naturalmente il lavoro di prova tra più nodi, riducendo molto il carico sul "prover finale".
• Altri schemi di firma: per le firme Lamport+Merkle, servono 256+32 hash per verificare una firma; moltiplicato per 32768 firmatari, fa 9437184 hash. Ottimizzando lo schema di firma, si può migliorare ulteriormente con un piccolo fattore costante. Se si usa Poseidon, si può provare tutto in uno slot. Ma in pratica, usare uno schema di aggregazione ricorsiva è ancora più veloce.

Collegamenti con la ricerca esistente?

• Prove concise del consenso Ethereum (solo per il comitato di sincronizzazione)
• Helios in SP1 conciso
• Precompilati BLS12-381 concisi
• Verifica delle firme aggregate BLS basata su Halo2

Cos'altro resta da fare e quali sono i trade-off:

In realtà, ci vorranno anni prima di ottenere una prova di validità del consenso di Ethereum. Questo è in linea con il tempo necessario per implementare la finalità single-slot, Orbit, cambiare gli algoritmi di firma e fare l'analisi di sicurezza necessaria per avere abbastanza fiducia nell'uso di funzioni hash "aggressive" come Poseidon. Quindi, la scelta più saggia è risolvere prima questi altri problemi, tenendo conto della STARK-friendliness durante il processo.

Il principale trade-off sarà probabilmente nell'ordine delle operazioni, tra un approccio più graduale alla riforma del livello di consenso di Ethereum e un approccio più aggressivo che cambia molte cose in una volta sola. Per l'EVM, l'approccio graduale ha senso perché minimizza l'impatto sulla retrocompatibilità. Per il livello di consenso, l'impatto sulla retrocompatibilità è minore, e ripensare in modo più "olistico" i dettagli della beacon chain per ottimizzare la STARK-friendliness può essere vantaggioso.

Come interagisce con le altre parti della roadmap?

Nella riprogettazione a lungo termine della PoS di Ethereum, la STARK-friendliness deve essere una priorità, specialmente per la finalità single-slot, Orbit, cambiamenti negli schemi di firma e aggregazione delle firme.