Negli ultimi dodici mesi, l'ecosistema zkEVM ha subito un'accelerazione drammatica nelle prestazioni. Il tempo di generazione della prova per un blocco Ethereum è sceso da 16 minuti a soli 16 secondi. I costi sono diminuiti di oltre 45×, e gli zkVM moderni sono ora in grado di dimostrare il 99% dei blocchi della mainnet Ethereum in meno di 10 secondi quando eseguiti su hardware target.
Il 18 dicembre, la Fondazione Ethereum (EF) ha formalmente dichiarato un traguardo raggiunto: la prova in tempo reale è ora possibile. I colli di bottiglia fondamentali nelle prestazioni sono stati rimossi.
Ma l'EF ha chiarito che la fase più difficile è solo all'inizio. La velocità senza solidità matematica non è un vantaggio—è un rischio. Ancora più preoccupante, parti delle fondamenta matematiche che sottendono molti zkEVM basati su STARK hanno iniziato a fratturarsi silenziosamente negli ultimi mesi.
La prova in tempo reale non è mai stata solo una questione di latenza
A luglio, l'EF ha definito la “prova in tempo reale” come un obiettivo multidimensionale—non solo per ridurre la latenza, ma per ottimizzare i costi hardware, il consumo energetico, l'apertura e la sicurezza crittografica.
I requisiti target erano espliciti:
Prova almeno il 99% dei blocchi di mainnet entro 10 secondi
Esegui su circa $100,000 di hardware
Consuma non più di 10 kW di potenza
Essere completamente open-source
Raggiungi la sicurezza crittografica a 128 bit
Mantieni le dimensioni delle prove al di sotto di 300 KB
Il post del blog dell'EF del 18 dicembre ha confermato che gli obiettivi di prestazione sono stati raggiunti, basandosi sui dati di benchmark di EthProofs. “In tempo reale” qui è definito rispetto al tempo di slot di 12 secondi di Ethereum, con circa 1,5 secondi riservati per la propagazione dei blocchi. Le prove devono essere pronte abbastanza rapidamente affinché i validatori possano verificarle senza compromettere la vitalità della rete.
Tuttavia, l'EF ha immediatamente spostato l'attenzione dal throughput alla solidità—e il cambiamento è irremovibile.
Perché la velocità senza sicurezza provata è pericolosa
Molte implementazioni di zkEVM rivendicano alti livelli di sicurezza facendo affidamento su assunzioni matematiche non provate. Negli ultimi mesi, diverse di queste assunzioni—soprattutto le assunzioni di “gap di prossimità” nei test a bassa dimensione utilizzati da SNARK e STARK basati su hash—sono state matematicamente distrutte.
Il risultato è netto: set di parametri una volta pubblicizzati come “sicuri a 128 bit” potrebbero offrire una sicurezza reale molto inferiore a quella dichiarata.
Per Ethereum L1, la posizione dell'EF è assoluta:
Solo la sicurezza provabile è accettabile—non “sicuro se l'assunzione X è valida.”
Ecco perché l'EF ha standardizzato sulla sicurezza a 128 bit. Il livello è in linea con gli standard crittografici consolidati, i modelli di sicurezza a lungo termine e le prove empiriche che dimostrano che la sicurezza a 128 bit è oltre le capacità di attacco fattibili oggi.
Il ragionamento è semplice ma severo. Se un attaccante può forgiare una prova zkEVM, il danno è esistenziale:
Minting di token arbitrari
Riscrittura dello stato L1
Rompere il consenso globale di Ethereum
Questo non è un exploit a livello di contratto—è un fallimento a livello di protocollo. Di conseguenza, l'EF tratta un alto margine di sicurezza come non negoziabile per qualsiasi zkEVM destinato all'uso L1.
Tre traguardi obbligatori della Fondazione Ethereum
L'EF ha delineato un chiaro piano con tre checkpoint vincolanti.
1. Integrazione di Soundcalc – Febbraio 2026
Entro la fine di febbraio 2026, tutti i team zkEVM partecipanti devono integrare i propri sistemi di prova e circuiti in soundcalc, uno strumento mantenuto dall'EF che calcola i livelli di sicurezza concreti sulla base dei più recenti limiti crittanalitici e parametri dello schema.
Questo stabilisce una singola metrica condivisa. I team non riporteranno più autonomamente la sicurezza in bit basandosi su assunzioni private. Man mano che la crittoanalisi evolve, soundcalc può essere aggiornato, costringendo le affermazioni di sicurezza a evolversi con esso.
2. “Glamsterdam” – Maggio 2026
Il traguardo di Glamsterdam richiede:
Almeno 100 bit di sicurezza provabile tramite soundcalc
Dimensioni delle prove sotto 600 KB
Una spiegazione pubblica e concisa dell'architettura ricorsiva e del suo argomento di solidità
Questo effettivamente riformula la sicurezza a 128 bit come obiettivo finale, mentre tratta i 100 bit come una soglia di implementazione transitoria.
3. “H-star” – Fine del 2026
Lo standard finale richiede:
Sicurezza provabile completa a 128 bit
Dimensioni delle prove limitate a 300 KB
Un argomento di sicurezza formale che copra l'intero stack ricorsivo
A questo stadio, la sfida non è più l'ingegneria grezza—è il ragionamento e la verifica crittografici formali.
Le leve tecniche che abilitano la sicurezza a 128 bit
L'EF evidenzia diverse innovazioni chiave che rendono questo obiettivo realistico.
Uno dei più importanti è WHIR, un nuovo test di prossimità di Reed–Solomon che funziona anche come schema di impegno polinomiale multilineare. WHIR offre:
Sicurezza trasparente, post-quantistica
Prove più piccole
Verifica più veloce rispetto a FRI a livelli di sicurezza equivalenti
I benchmark a 128 bit di sicurezza mostrano dimensioni delle prove ridotte di ~1.95×, con velocità di verifica migliorate di molti multipli.
L'EF punta anche a JaggedPCS, che evita un padding eccessivo quando codifica le tracce in polinomi, riducendo il sovraccarico del provatore mantenendo impegni concisi.
Tecniche aggiuntive includono:
Grinding, che forza bruta la casualità del protocollo per ottenere prove più economiche o più piccole all'interno dei margini di sicurezza
Architetture ricorsive progettate con attenzione, aggregando molte piccole prove in una singola prova finale con un argomento di solidità unificato
Sforzi di ricerca come Whirlaway sfruttano WHIR per costruire STARK multilineari più efficienti, mentre schemi di impegno sperimentali dallo spazio di disponibilità dei dati continuano a influenzare il design zk.
La matematica sta avanzando rapidamente—ma sta anche abbandonando assunzioni che sembravano sicure solo mesi fa.
Cosa cambia—e cosa rimane incerto
Se le prove sono sempre disponibili entro 10 secondi e rimangono sotto 300 KB, Ethereum può aumentare il suo limite di gas senza costringere i validatori a rieseguire le transazioni. I validatori verificherebbero semplicemente una prova compatta, consentendo un throughput più elevato mantenendo lo staking domestico.
Questo spiega l'insistenza dell'EF su budget rigorosi di potenza e hardware. Un zkEVM che richiede infrastrutture da data center mina le garanzie di decentralizzazione di Ethereum.
Un L1 zkEVM sicuro e con prove piccole sfumerebbe anche la linea tra l'esecuzione L1 e i rollup. Gli L2 potrebbero riutilizzare la stessa infrastruttura di prova tramite precompiles, trasformando i rigidi confini architettonici di oggi in scelte di design configurabili.
Tuttavia, la prova in tempo reale oggi esiste solo in benchmark off-chain. Colmare il divario con migliaia di validatori indipendenti che eseguono provatori a casa rimane una grande sfida.
Le assunzioni di sicurezza rimangono anche fluide. La stessa ragione per cui esiste soundcalc è che i parametri di sicurezza basati su hash SNARK e STARK cambiano man mano che le assunzioni vengono infrante. Un sistema “a 100 bit” oggi potrebbe richiedere una rivalutazione domani.
Non è ancora chiaro se tutti i principali team zkEVM possano soddisfare sia le soglie di sicurezza che i vincoli sulle dimensioni delle prove secondo il programma—o se alcuni comprometteranno accettando assunzioni più deboli o verifiche off-chain estese.
L'EF stessa riconosce che il problema più difficile potrebbe non essere le GPU o la matematica, ma formalizzare e auditare architetture ricorsive. Molti zkEVM consistono in circuiti a strati cuciti insieme con un sostanziale codice di colla. Documentare e dimostrare la solidità di questi stack personalizzati è critico.
Questo è il momento in cui progetti come Verified-zkEVM e framework di verifica formale diventano essenziali—eppure rimangono precoci e irregolari attraverso gli ecosistemi.
Da corsa alle prestazioni a corsa alla sicurezza
Un anno fa, la domanda decisiva era se gli zkEVM potessero dimostrare abbastanza velocemente.
Quella domanda ha trovato risposta.
La nuova domanda è se possono dimostrare in modo solido, a livelli di sicurezza che non dipendono da assunzioni fragili, con prove abbastanza piccole per la rete P2P di Ethereum, e con architetture ricorsive formalmente verificate in grado di garantire centinaia di miliardi di dollari di valore.
La corsa alle prestazioni è finita.
La corsa alla sicurezza è appena iniziata.
📌 Segui per approfondimenti su Ethereum, zk-proof, crittografia e il futuro dell'infrastruttura decentralizzata.
