La roadmap di Ethereum per il 2026 include questo rischio per i validatori che è più grande di quanto pensi

La roadmap di Ethereum per il 2026 si concentra su due direttrici: l'espansione della capacità dei dati dei rollup tramite blob, mentre si punta ad aumentare l'esecuzione del layer di base attraverso modifiche al gas limit.

Queste modifiche al gas limit dipendono dal passaggio dei validatori dal rieseguire i blocchi al verificare le prove di esecuzione ZK.

La prima direttrice è già ancorata da Fusaka, rilasciato il 3 dicembre 2025.

Fusaka

Secondo ethereum.org, predispone PeerDAS più modifiche ai parametri dei blob BPO (blob parameter only), che possono aumentare il throughput dei blob in passi misurati.

La seconda direttrice è meno meccanizzata perché si basa su EIP in bozza, implementazione dei client e operazioni dei validatori che devono rimanere entro i limiti della decentralizzazione, inclusi banda, propagazione dei blocchi e struttura del mercato delle prove.

PeerDAS è presentato come la leva di “aumento della capacità” più chiara perché progettato per scalare la disponibilità dei dati dei rollup senza costringere ogni nodo a scaricare ogni blob.

Secondo ethereum.org, gli obiettivi dei blob non aumentano immediatamente all’attivazione, poi possono raddoppiare ogni poche settimane fino a un massimo di 48, mentre gli sviluppatori monitorano la salute della rete.

Il team di Optimism ha definito il caso limite superiore come “almeno 48 blob target per blocco”, abbinato a un aumento del throughput lato rollup da circa 220 a circa 3.500 UOPS sotto quel target.

Anche in quel contesto, la questione pratica per il 2026 è se la domanda arriverà come utilizzo dei blob piuttosto che come aumento delle offerte sull’esecuzione L1.

Un’altra domanda aperta è se la stabilità p2p e la banda dei nodi rimarranno entro le tolleranze degli operatori man mano che aumenta il rollout dei BPO.

Dal lato dell’esecuzione, Ethereum sta già testando un throughput più elevato tramite coordinamento invece di un hard fork.

GasLimit.pics ha riportato un gas limit più recente di 60.000.000, con una media sulle 24 ore di circa 59.990.755 al momento indicato.

Quel livello è rilevante perché fornisce un punto di riferimento su ciò che i validatori hanno accettato in pratica.

Mette anche in evidenza il limite della “scalabilità sociale” prima che latenza, carico di validazione, mempool e pressione sulla pipeline MEV diventino vincolanti.

Un modo semplice per tradurre il discorso sul gas limit in intervalli di throughput è gas al secondo, usando il tempo slot di 12 secondi di Ethereum (gas al secondo uguale a gas limit diviso 12).

I numeri sottostanti mantengono il calcolo esplicito e separano le transazioni EVM del layer base dalle affermazioni sul throughput dei rollup.

Glamsterdam

L’aggiornamento previsto per il 2026, “Glamsterdam”, racchiude diverse idee orientate all’esecuzione in una sigla discussa in relazione alla separazione tra proposer e builder istituzionalizzata (ePBS, EIP-7732), Block-Level Access Lists (BALs, EIP-7928) e riprezzamento generale (EIP-7904).

Secondo le pagine EIP di EIP-7732, EIP-7928 ed EIP-7904, ognuna di queste è ancora in forma di bozza.

Il riprezzamento mira a correggere le discrepanze nella schedule del gas che permangono da anni.

Secondo EIP-7904, si sostiene che correggere il prezzo errato del calcolo può aumentare il throughput utilizzabile, pur riconoscendo il rischio DoS e la realtà dei contratti che codificano rigidamente le ipotesi di gas.

I BAL sono presentati come infrastruttura per il parallelismo.

L’EIP cita letture parallele del disco, validazione parallela delle transazioni, calcolo parallelo dello state-root e “aggiornamenti di stato senza esecuzione”, stimando una dimensione media compressa dei BAL di circa 70-72 KiB come overhead, secondo EIP-7928.

Nella pratica, questi guadagni si materializzano solo se i client adottano la concorrenza sui veri colli di bottiglia.

Dipendono anche dal fatto che i dati extra e i passaggi di verifica non diventino a loro volta una tassa sulla latenza.

ePBS è centrale sia nelle discussioni su MEV che su throughput perché mira a decouplare la validazione dell’esecuzione da quella del consenso nel tempo, secondo EIP-7732.

Quella flessibilità temporale però è anche dove possono emergere nuovi modelli di fallimento.

Un articolo accademico sul “problema dell'opzione gratuita” per ePBS stima l’esercizio dell’opzione in circa lo 0,82% dei blocchi in media con una finestra di opzione di 8 secondi, raggiungendo circa il 6% nei giorni ad alta volatilità nelle condizioni modellate, secondo arXiv.

Ethereum nel 2026

Per la pianificazione del 2026, quella ricerca indirizza l’attenzione verso la liveness sotto stress, non solo sugli esiti stabili delle fee.

La scommessa strutturale dietro gas limit “molto elevati” è l’adozione delle ZK-proof da parte dei validatori.

La roadmap “Realtime Proving” della Ethereum Foundation descrive un percorso a tappe in cui un piccolo gruppo di validatori esegue dapprima client ZK in produzione.

Solo dopo che una super-maggioranza dello stake è a suo agio, il gas limit può aumentare a livelli in cui la verifica della prova sostituisce la riesecuzione per la validazione pratica su hardware ragionevole, secondo il post della fondazione del 10 luglio 2025 su blog.ethereum.org.

Lo stesso post indica vincoli rilevanti per la fattibilità, non per la narrativa, tra cui puntare a una sicurezza a 128 bit (con 100 bit accettati temporaneamente), dimensione della prova sotto i 300 KiB e l’evitare l’uso di wrapper ricorsivi con trusted setup, secondo blog.ethereum.org.

L’implicazione di scalabilità è legata ai mercati delle prove: la fornitura di prove in tempo reale deve essere economica e credibile senza concentrarsi in un set ristretto di prover che ricreerebbe le dipendenze attuali in stile relay in un altro layer dello stack.

Dopo Glamsterdam, “Hegota” è previsto come slot nominato per la fine del 2026, ancora incentrato più sul processo che sull’ambito.

La Ethereum Foundation ha pubblicato una timeline principale con una finestra di proposta dall’8 gennaio al 4 febbraio, seguita da discussione e finalizzazione dal 5 al 26 febbraio, poi una finestra per i non-headliner, secondo blog.ethereum.org.

Un meta-EIP Hegotá esiste come bozza (EIP-8081) e elenca gli elementi come in considerazione e non definitivi, incluso FOCIL (EIP-7805) attualmente in esame, secondo EIP-8081.

Il valore informativo nel breve termine di quella timeline è che crea punti decisionali datati che investitori e sviluppatori possono monitorare senza dover dedurre impegni dai nomi in codice.

Il primo è che le proposte headliner di Hegota si chiudono il 4 febbraio.

L’articolo La roadmap di Ethereum per il 2026 include un rischio per i validatori più grande di quanto si pensi è apparso per la prima volta su CryptoSlate.