Il roadmap di Ethereum per il 2026 si concentra su due traiettorie: espandere la capacità dei dati dei rollup attraverso i blob mentre si spinge l’esecuzione del layer base a livelli più alti tramite modifiche al limite del gas.
Queste modifiche al limite del gas dipendono dal fatto che i validatori passino dalla riesecuzione dei blocchi alla verifica delle prove di esecuzione ZK.
La prima traiettoria è già ancorata da Fusaka, rilasciato il 3 dicembre 2025.
Fusaka
Secondo ethereum.org, Fusaka implementa PeerDAS più modifiche ai soli parametri dei blob (BPO) che possono aumentare il throughput dei blob in passi misurati.
La seconda traiettoria è meno meccanizzata perché si basa su bozze di EIP, implementazione client e operazioni dei validatori che devono rimanere entro i vincoli di decentralizzazione, inclusi larghezza di banda, propagazione dei blocchi e struttura del mercato delle prove.
PeerDAS è posizionato come la leva di “rampa di capacità” più chiara perché è progettato per scalare la disponibilità dei dati dei rollup senza costringere ogni nodo a scaricare ogni blob.
Secondo ethereum.org, i target dei blob non saltano immediatamente all’attivazione, quindi possono raddoppiare ogni poche settimane fino a un target massimo di 48 mentre gli sviluppatori monitorano la salute della rete.
Secondo optimism.io, il team di Optimism ha inquadrato lo scenario di fascia alta 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 quadro, la domanda pratica per il 2026 è se la domanda arriverà come utilizzo di blob piuttosto che come aumento delle offerte per l’esecuzione L1.
Un’altra questione aperta è se la stabilità p2p e la larghezza di banda dei nodi rimarranno entro le tolleranze degli operatori man mano che il rollout delle BPO aumenta.
Sul lato esecuzione, Ethereum sta già testando un throughput più alto attraverso il coordinamento piuttosto che un hard fork.
GasLimit.pics ha riportato un ultimo limite del gas di 60.000.000, con una media delle 24 ore di circa 59.990.755 al momento indicato.
Questo livello è importante perché fornisce un punto di riferimento per ciò che i validatori hanno accettato nella pratica.
Espone anche il limite dello “scaling sociale” prima che la latenza, il carico di validazione e lo stress della pipeline del mempool e del MEV diventino vincolanti.
Un modo semplice per tradurre il discorso sul limite del gas in intervalli di throughput è il gas al secondo, utilizzando il tempo di slot di 12 secondi di Ethereum (gas al secondo equivale a limite del gas diviso 12).
I numeri seguenti mantengono esplicita la matematica e separano le transazioni EVM del layer base dalle affermazioni sul throughput dei rollup.
| Scenario | Limite gas | Gas/sec (≈ gas/12) | Transazioni/sec a 21k gas | Transazioni/sec a 120k gas |
|---|---|---|---|---|
| Livello di coordinamento attuale | 60.000.000 | 5.000.000 | ≈238 | ≈42 |
| Caso limite gas 2× | 120.000.000 | 10.000.000 | ≈476 | ≈83 |
| Caso fascia alta (richiede cambio validazione) | 200.000.000 | 16.666.667 | ≈793 | ≈139 |
Glamsterdam
Il branding dell’aggiornamento pianificato per il 2026 racchiude diverse idee orientate all’esecuzione in “Glamsterdam”, una lista abbreviata che è stata discussa intorno alla separazione enshrined proposer-builder (ePBS, EIP-7732), alle Block-Level Access Lists (BAL, EIP-7928) e al ripricing generale (EIP-7904).
Secondo le pagine EIP per EIP-7732, EIP-7928 e EIP-7904, ciascuna rimane in forma di bozza.
Il ripricing mira alle discrepanze dello schedule del gas che persistono da anni.
Secondo EIP-7904, sostiene che correggere il prezzo errato del calcolo può aumentare il throughput utilizzabile, riconoscendo al contempo il rischio di DoS e la realtà dei contratti che hardcodano le assunzioni sul gas.
Le BAL sono inquadrate come infrastruttura per il parallelismo.
Secondo EIP-7928, l’EIP cita letture disco parallele, validazione transazioni parallela, calcolo state-root parallelo e “aggiornamenti di stato senza esecuzione”, stimando una dimensione media compressa delle BAL di circa 70-72 KiB come overhead.
Nella pratica, questi guadagni si materializzano solo se i client adottano la concorrenza attraverso i veri colli di bottiglia.
Dipendono anche dal fatto che i dati extra e i passaggi di verifica evitino di diventare un loro proprio costo di latenza.
Secondo EIP-7732, l’ePBS si trova al centro sia delle discussioni sul MEV che sul throughput perché mira a disaccoppiare la validazione dell’esecuzione dalla validazione del consenso nel tempo.
Quel margine temporale è anche dove possono manifestarsi nuove modalità di fallimento.
Secondo arXiv, un articolo accademico sul “problema dell’opzione gratuita” per l’ePBS stima l’esercizio dell’opzione in circa lo 0,82% dei blocchi in media sotto una finestra di opzione di 8 secondi, raggiungendo circa il 6% nei giorni ad alta volatilità nelle sue condizioni modellate.
Ethereum nel 2026
Per la pianificazione del 2026, quella ricerca sposta l’attenzione verso la liveness sotto stress, non solo i risultati delle fee in stato stazionario.
La scommessa più strutturale dietro i limiti del gas “molto alti” è l’adozione delle prove ZK da parte dei validatori.
Il roadmap “Realtime Proving” della Ethereum Foundation descrive un percorso a fasi in cui un piccolo insieme di validatori esegue prima i client ZK in produzione.
Poi, solo dopo che una supermaggioranza dello stake si sente a suo agio, i limiti del gas possono salire a livelli in cui la verifica delle prove 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 delinea vincoli importanti per la fattibilità piuttosto che per la narrazione, incluso il targeting di sicurezza a 128 bit (con 100 bit accettati temporaneamente), dimensione della prova sotto i 300 KiB ed evitare la dipendenza da wrapper ricorsivi con trusted setup, secondo blog.ethereum.org.
L’implicazione di scaling è legata ai mercati delle prove: l’offerta di prove in tempo reale deve essere economica e credibile senza concentrarsi in un insieme ristretto di prover che ricrea le dipendenze in stile relay di oggi in un altro livello dello stack.
Dopo Glamsterdam, “Hegota” è posizionato come uno slot nominato per la fine del 2026 che riguarda ancora più il processo che lo scope.
Secondo blog.ethereum.org, la Ethereum Foundation ha pubblicato una timeline per le headline 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 le non-headline.
Una meta-EIP Hegotá esiste come bozza (EIP-8081) ed elenca gli elementi come considerati piuttosto che bloccati, incluso FOCIL (EIP-7805) attualmente considerato, secondo EIP-8081.
Il valore di reporting a breve termine in quel programma è che crea punti di decisione datati che investitori e builder possono tracciare senza dedurre impegni dai nomi in codice.
Il primo è che le proposte headline per Hegota chiudono il 4 febbraio.
Il post Il roadmap di Ethereum per il 2026 include questo rischio del validatore che è più grande di quanto pensi è apparso per la prima volta su CryptoSlate.
