Perché Ethereum ha bisogno di ZK-VM: il percorso definitivo per la scalabilità

Autore: Ebunker

Tra le numerose idee per il scaling di Ethereum, la ZK è la direzione più complessa e anche la più cruciale.

Guardando all’intera rete, Vitalik e la Ethereum Foundation sono quelli che puntano di più sulla ZK. La ZK è un po’ come il figlio più piccolo della famiglia Ethereum: riceve più attenzioni di tutti, ma il suo futuro è anche il più incerto.

Qualche giorno fa, la Ethereum Foundation ha pubblicato la roadmap Kohaku, una pianificazione dei componenti di base per i wallet privati. La roadmap sottolinea ancora una volta che molte funzionalità chiave continueranno a dipendere dall’implementazione di ZK-EVM o ZK-VM.

Allora, perché Ethereum ha così tanto bisogno della ZK-VM?

La risposta è semplice: per migliorare le prestazioni, senza sacrificare la sicurezza.

Il collo di bottiglia delle prestazioni: verifica universale e limite GAS

Abbiamo già detto che il modo più immediato per migliorare le prestazioni di Ethereum è aumentare il limite GAS, cioè rendere i blocchi più grandi.

Ma il problema è che aumentare il limite GAS ha un costo: blocchi troppo grandi sono un peso enorme per i nodi.

Attualmente, Ethereum utilizza una modalità di verifica chiamata “verifica universale”, cioè ogni nodo deve verificare completamente ogni blocco. Questo meccanismo è semplice e sicuro, ma estremamente ridondante.

Se il limite GAS aumenta in modo significativo, il carico computazionale di ogni nodo aumenterà di pari passo.

Considerando che l’intervallo tra i blocchi di Ethereum è di soli 12 secondi, e che bisogna lasciare tempo per la propagazione dei blocchi e l’ordinamento MEV, il tempo effettivo a disposizione dei validatori per la verifica è solo di circa 4–8 secondi, lasciando pochissimo margine per gestire un carico maggiore.

Ethereum dopo la ZK: da “verifica universale” a “verifica unica universale”

Se Ethereum L1 diventasse completamente ZK, la modalità di verifica passerebbe da “verifica universale” a “verifica unica universale”. In questo modello, quando un blocco viene assemblato, viene prima generata una prova ZK.

La caratteristica della ZK è che la generazione della prova è lenta, ma la verifica è estremamente veloce. Quindi, i nodi devono solo verificare una volta che la prova sia corretta, senza dover eseguire ripetutamente tutte le transazioni nel blocco.

Questo significa che Ethereum può aumentare notevolmente il limite GAS senza aumentare in modo significativo il carico sui nodi.

Una metafora efficace è questa: prima, quando presentavi una richiesta di permesso su DingTalk (inviavi una transazione), ogni dirigente (nodo) doveva verificare uno per uno se avevi ancora giorni di permesso disponibili (verifica universale), e solo dopo l’approvazione di tutti la procedura era completata.

Dopo la ZK, il sistema verifica prima che tu abbia effettivamente giorni di permesso, poi presenta una prova a tutti i dirigenti (ZK), che devono solo fidarsi e approvare rapidamente (verifica unica universale).

Dopo la ZK, presenti comunque la richiesta di permesso (invi una transazione), il sistema rileva che hai giorni di permesso residui e informa direttamente tutti i dirigenti “questa persona ha giorni di permesso”, e i dirigenti si fidano completamente del sistema (ZK), così l’approvazione è molto più veloce (verifica unica universale).

Questo è il motivo per cui Ethereum vuole implementare la ZK.

Le sfide della crittografia e i casi di studio

Ovviamente, realizzare tutto ciò richiede un enorme lavoro ingegneristico e un livello di difficoltà crittografica molto elevato, quindi Ethereum deve collaborare con team specializzati.

Il ricercatore della Ethereum Foundation Justin ha menzionato il protocollo Brevis, che è attualmente uno dei casi di studio leader in questo campo.

Brevis si concentra sulla ZK-VM, e la sua più recente tecnologia Pico Prism è una delle soluzioni più veloci per generare prove ZK nelle condizioni attuali.

Secondo i dati di test, con la dimensione attuale dei blocchi di Ethereum di 45 M GAS, Brevis utilizza 64 GPU RTX 5090 e può completare la prova del 99,6% dei blocchi in 12 secondi, di cui il 96,8% può essere completato in 10 secondi.

Per mantenere la decentralizzazione, Ethereum richiede che il costo dei dispositivi per la prova ZK non superi i 100.000 dollari.

Anche se GPU di fascia più alta (come H200 o B200) possono generare le prove più velocemente, ciò aumenterebbe notevolmente la soglia di accesso. L’attuale design di Brevis si colloca esattamente entro questo limite.

Perché anche la “copertura dei 10 secondi” è fondamentale? Perché i blocchi MEV di solito vengono generati in 1–3 secondi, e aggiungendo 10 secondi per la generazione della prova si riempiono esattamente i 12 secondi dell’intervallo tra i blocchi.

Conclusione: la logica del percorso verso la ZK di Ethereum

Se Ethereum vuole accelerare il miglioramento delle prestazioni di L1, deve aumentare il limite GAS;

Per aumentare in sicurezza il limite GAS, deve promuovere la ZK;

E per implementare elegantemente la ZK (generazione della prova in meno di 10 secondi, costo hardware inferiore a 100.000 dollari), è necessario uno sforzo congiunto tra la comunità crittografica e l’ecosistema crypto.

La ZK è la direzione più complessa ma anche la più determinata nella roadmap di scaling di Ethereum.

Non riguarda solo le prestazioni, ma rappresenta la soluzione definitiva con cui Ethereum cerca un equilibrio tra sicurezza e decentralizzazione.