Ethereum Si Prepara a Validare i Blocchi Senza Eseguirli – Ecco Come

Un cambiamento sottile ma significativo sta prendendo forma nell'architettura centrale di Ethereum. Invece di convalidare i blocchi rieseguendo ogni transazione, la rete sta preparando un percorso alternativo in cui i validatori confermano la correttezza verificando dimostrazioni a conoscenza zero.

Il lavoro si inserisce nella roadmap Layer-1 di Ethereum per il 2026 e rappresenta un cambiamento strutturale nel modo in cui può essere raggiunto il consenso, non una nuova funzionalità di scaling aggiunta ai margini.

La proposta è emersa pubblicamente dopo che un membro della Ethereum Foundation, noto come ladislaus.eth, ha delineato i progressi verso un design L1-zkEVM. Il cambiamento non altera il modo in cui vengono prodotti i blocchi o ciò che gli utenti inviano on-chain. Invece, modifica il modo in cui i validatori decidono se un blocco è valido. Il primo workshop L1-zkEVM è programmato per l'11 febbraio 2026, segnando l'inizio formale del coordinamento attorno a questo sforzo.

Dalla Riesecuzione Completa alla Verifica delle Prove

Oggi, qualsiasi validatore che voglia attestare un blocco deve rieseguire ogni transazione al suo interno. Ogni nodo ripete indipendentemente lo stesso calcolo, verifica le stesse transizioni di stato e memorizza lo stesso stato di esecuzione. Questo modello è stato mantenuto dalla genesi di Ethereum, ma scala linearmente con l'attività. Limiti di gas più elevati aumentano il carico computazionale, le dimensioni dello stato e i requisiti di larghezza di banda per ogni partecipante.

L'alternativa in fase di sviluppo sostituisce il calcolo ripetuto con la verifica crittografica. Invece di rieseguire le transazioni, un validatore verifica una dimostrazione a conoscenza zero compatta che mostra che l'esecuzione è stata eseguita correttamente. Il tempo di verifica rimane approssimativamente costante indipendentemente dalla complessità interna del blocco. Questa è l'idea centrale dietro le prove zkEVM, ora integrate direttamente nel flusso di lavoro del consenso di Ethereum.

Come Funziona la Pipeline L1-zkEVM

Secondo il design attuale, un client di esecuzione produce un Execution Witness, un bundle di dati autosufficiente sufficiente per convalidare la transizione di stato di un blocco senza mantenere lo stato di esecuzione completo. Un programma guest standardizzato consuma quel witness e verifica la correttezza dell'esecuzione. Una zkVM esegue questo programma e genera una prova che attesta che l'esecuzione ha seguito le regole di Ethereum.

I client di consenso possono quindi verificare quella prova invece di invocare un client di esecuzione completo. I validatori che scelgono questo percorso sono denominati zkAttesters. È importante notare che questo percorso è facoltativo. I validatori possono continuare a rieseguire i blocchi esattamente come fanno oggi.

Questo meccanismo è formalizzato nell'EIP-8025 (Optional Execution Proofs). La proposta non richiede un hard fork e non obbliga i validatori ad adottare la convalida basata su prove. Aggiunge un percorso di verifica parallelo insieme alla riesecuzione.

Integrazione del Consenso e Diversità dei Client

L'EIP-8025 specifica come le prove circolerebbero attraverso la rete peer-to-peer. Le prove di esecuzione da diverse implementazioni di client vengono diffuse su un topic dedicato. Durante l'elaborazione di un blocco, uno zkAttester può verificare queste prove invece di chiamare un client di esecuzione.

L'ipotesi di lavoro attuale è una soglia di 3 su 5. L'esecuzione di un blocco viene accettata una volta che tre prove indipendenti su cinque vengono verificate con successo. Questa soglia può evolversi, ma l'intento è chiaro: preservare la diversità dei client di esecuzione consentendo al contempo la convalida basata su prove. La diversità rimane una caratteristica a livello di protocollo piuttosto che una scelta operativa.

Perché Questo È Importante per i Validatori

Uno zkAttester non ha bisogno di memorizzare lo stato di esecuzione o sincronizzare l'intera catena del layer di esecuzione. La sincronizzazione si riduce al download delle prove recenti dall'ultimo checkpoint finalizzato. Questo riduce drasticamente i requisiti hardware per partecipare al consenso.

Per gli staker solo e i validatori domestici, questo è rilevante. Eseguire un validatore oggi richiede il mantenimento sia di un client di consenso che di un client di esecuzione ad alta intensità di risorse. La verifica delle prove sostituisce la riesecuzione, riducendo le esigenze di storage, calcolo e larghezza di banda. Questo abbassa la barriera d'ingresso senza indebolire le garanzie di verifica.

Le implicazioni si estendono oltre gli attestatori. Poiché le prove zkEVM sono stateless, verificare Ethereum localmente su hardware consumer diventa nuovamente più accessibile. Il principio "non fidarti, verifica" viene rafforzato anziché diluito.

Dipendenze e Vincoli Temporali

Un prerequisito è importante. La generazione di prove richiede tempo e senza pipelining, la finestra è troppo stretta. È qui che ePBS (Enshrined Proposer-Builder Separation) diventa rilevante. Previsto per il prossimo hard fork Glamsterdam, ePBS estende la finestra di dimostrazione da circa uno o due secondi a circa sei o nove secondi. Questa estensione rende la generazione di prove a slot singolo molto più realistica.

Senza ePBS, la verifica delle prove L1 rimane vincolata. Con esso, il design diventa operativamente praticabile.

La Vendita delle Balene XRP Rimane Assente Mentre il Prezzo Scende

Chi È Coinvolto

I team dei client del layer di esecuzione ottengono una nuova superficie di dimostrazione, con ogni client che diventa una potenziale fonte di prove. Il design del prover rimane una questione aperta. Concentrare la dimostrazione in un piccolo insieme di builder sofisticati introduce rischi di liveness, mentre la dimostrazione completamente distribuita solleva sfide di prestazioni e coordinamento. L'obiettivo del design è esplicito: la dimostrazione deve rimanere praticabile al di fuori dei grandi data center.

I fornitori di zkVM che già dimostrano i blocchi Ethereum ottengono un'interfaccia standardizzata su cui costruire. Anche i team Layer-2 ne beneficiano. Una volta che le prove di esecuzione vengono verificate dai validatori, le stesse prove possono servire i rollup nativi attraverso un'infrastruttura condivisa.

In definitiva, gli utenti beneficiano di una verifica più economica, una partecipazione più ampia dei validatori e limiti di gas più elevati e fattibili senza pressioni di centralizzazione.

Stato Attuale

L'EIP-8025 è entrato nel ramo delle funzionalità consensus-specs e sta progredendo verso lo stato di proposta. La roadmap L1-zkEVM per il 2026 è ora pubblica, strutturata attraverso la standardizzazione dei witness di esecuzione, le interfacce zkVM, l'integrazione del consenso, l'infrastruttura del prover, il benchmarking e la verifica di sicurezza formale.

Il workshop dell'11 febbraio 2026 segna l'inizio del coordinamento mirato su questi percorsi. Questo non è un aggiornamento da prima pagina, ma è fondamentale. Se Ethereum scala il suo layer di esecuzione senza scalare i requisiti dei validatori, è così che accade.

Il post Ethereum si sta preparando a convalidare i blocchi senza eseguirli – Ecco come è apparso per primo su ETHNews.