Ethereum Glamsterdam, rinviato l’aggiornamento sulla testnet Hoodi per verifiche sugli smart contract
L’attivazione di Glamsterdam sulla testnet Ethereum Hoodi, inizialmente programmata per il 26 ottobre 2026, è stata rinviata dopo che gli sviluppatori hanno individuato possibili problemi di compatibilità tra le nuove regole di calcolo del gas e alcuni smart contract già operativi sulla rete principale. La decisione è stata comunicata il 22 ottobre dalla Ethereum Foundation, al termine della riunione All Core Developers Execution numero 248, senza indicare una nuova data per il rilascio.
Il rinvio dell’aggiornamento Ethereum Glamsterdam riguarda una fase di collaudo del protocollo e non comporta modifiche immediate alla blockchain utilizzata dagli utenti. Il problema richiede però un approfondimento prima di procedere, perché coinvolge il comportamento di contratti che gestiscono operazioni finanziarie e che potrebbero reagire diversamente alle nuove condizioni di esecuzione.
La programmazione originaria prevedeva l’attivazione su Hoodi alle 17:42:48 UTC del 26 ottobre, in corrispondenza dell’epoch 132.352. Nella stessa occasione sarebbe stato portato a 200 milioni il limite di gas previsto per la testnet. Entrambe le operazioni sono state eliminate dalla configurazione di aggiornamento.
La Ethereum Foundation ha precisato che il rinvio non modifica la cronologia della blockchain Hoodi e non costituisce un annullamento delle transazioni già eseguite. È stata semplicemente ritirata l’attivazione futura delle nuove regole, in attesa che vengano completate le verifiche tecniche.
Il problema dell’EIP-8037 e le conseguenze per gli smart contract
Al centro della decisione si trova la proposta EIP-8037, denominata State Creation Gas Cost Increase, che interviene sul costo delle operazioni responsabili della creazione di nuovi dati permanenti sulla blockchain.
Ethereum utilizza il gas per misurare le risorse necessarie all’esecuzione delle transazioni. Ogni operazione svolta dalla Ethereum Virtual Machine comporta un consumo determinato dalle regole del protocollo. Queste regole influenzano tanto il costo delle transazioni quanto il comportamento dei programmi che vengono eseguiti sulla rete.
La proposta EIP-8037 introduce un meccanismo di contabilizzazione separata per il gas associato alla creazione dello stato, cioè l’insieme delle informazioni permanenti che i nodi Ethereum devono conservare. L’obiettivo è rendere il costo della memorizzazione più coerente con le risorse effettivamente richieste, evitando che l’aumento della capacità della blockchain provochi una crescita eccessiva dei dati conservati.
Il cambiamento riguarda, tra le altre operazioni, la creazione di account, l’allocazione di nuove posizioni di archiviazione e la distribuzione degli smart contract. La proposta prevede anche un sistema di riserva del gas destinato alla creazione dello stato, distinto dalla disponibilità utilizzata per l’esecuzione ordinaria.
È proprio questa separazione a richiedere ulteriori controlli.
Alcuni smart contract esistenti si basano su comportamenti precisi del gas residuo per stabilire se un’operazione sia riuscita, debba essere interrotta oppure possa essere ripetuta. Modificando la contabilizzazione delle risorse, una chiamata interna potrebbe consumare il gas in maniera diversa rispetto alle condizioni per le quali il contratto era stato originariamente progettato.
Le analisi di sicurezza richiamate anche dalla stampa specializzata hanno evidenziato possibili conseguenze sulla gestione delle chiamate che terminano con un errore. Il rischio è che determinate procedure proseguano oppure registrino risultati inattesi quando un contratto secondario esaurisce le risorse disponibili.
Il problema può avere conseguenze particolarmente delicate nelle applicazioni finanziarie decentralizzate, dove più contratti interagiscono all’interno della stessa operazione.
Un contratto può, per esempio, eseguire una chiamata verso un altro programma e decidere come procedere in base all’esito ricevuto. Se le nuove regole alterano la quantità di gas disponibile o il comportamento delle chiamate fallite, alcune verifiche progettate per proteggere l’operazione potrebbero non funzionare come previsto.
Queste condizioni non significano necessariamente che tutti i contratti interessati presentino vulnerabilità sfruttabili. La compatibilità dipende dalla struttura del codice, dalla gestione delle eccezioni e dalle sequenze di operazioni coinvolte.
L’attenzione riguarda anche EIP-8038, una proposta collegata che aggiorna i costi delle operazioni di accesso e modifica dello stato. Le due modifiche incidono su aspetti differenti della contabilizzazione del gas, ma i loro effetti devono essere valutati congiuntamente quando vengono eseguiti contratti già distribuiti.
Le verifiche servono quindi a stabilire quali programmi possano subire cambiamenti di comportamento e se siano necessarie modifiche alle specifiche prima dell’attivazione sulla rete principale.
Non risulta confermato un attacco già sfruttato sulla mainnet Ethereum come conseguenza dell’aggiornamento. Le criticità segnalate riguardano la compatibilità e i rischi di sicurezza associati a regole che non sono ancora state introdotte sulla rete principale.
La distinzione è sostanziale: individuare un possibile problema durante la revisione di un aggiornamento consente di intervenire prima che il cambiamento venga applicato a contratti che gestiscono risorse economiche reali.
Perché Sepolia ha completato l’aggiornamento mentre Hoodi è stata fermata
Il percorso di rilascio di Glamsterdam aveva già raggiunto una fase avanzata. Il 6 ottobre 2026 l’aggiornamento era stato attivato sulla testnet Sepolia, secondo il calendario comunicato dalla Ethereum Foundation a settembre.
Sepolia è una rete pubblica di prova che permette agli sviluppatori di verificare il funzionamento delle applicazioni e delle modifiche al protocollo senza utilizzare direttamente la mainnet. Attraverso questa infrastruttura vengono testate le nuove funzionalità, il comportamento dei client e le conseguenze operative degli aggiornamenti.
L’attivazione di Glamsterdam su Sepolia ha rappresentato un passaggio importante, ma il completamento di un aggiornamento su una singola testnet non costituisce una garanzia assoluta di compatibilità con tutte le applicazioni Ethereum.
Le reti di prova non riproducono integralmente la varietà dei contratti, dei capitali e delle interazioni presenti sulla blockchain principale. Alcuni comportamenti emergono soltanto quando vengono analizzate applicazioni particolarmente complesse oppure combinazioni di operazioni poco frequenti.
Hoodi svolge un ruolo complementare nella preparazione degli aggiornamenti del protocollo. La rete viene utilizzata anche per verificare le attività dei validatori, il coordinamento tra i client e il funzionamento dell’infrastruttura di consenso in condizioni più vicine a quelle operative.
La Ethereum Foundation aveva annunciato il 16 ottobre il passaggio successivo su Hoodi, prevedendo l’attivazione congiunta delle modifiche denominate Amsterdam, relative al livello di esecuzione, e Gloas, associate al livello di consenso.
Il calendario è stato però superato dalla decisione del 22 ottobre.
Il rinvio dell’aggiornamento Ethereum Glamsterdam su Hoodi non comporta la disattivazione delle funzionalità già introdotte su Sepolia. Le due reti seguono configurazioni e procedure operative distinte.
Gli sviluppatori possono continuare a utilizzare le infrastrutture disponibili per le verifiche compatibili con lo stato delle rispettive reti. Non possono invece considerare il 26 ottobre come riferimento valido per i test che richiedono l’attivazione di Glamsterdam su Hoodi.
Proposer-builder separation e block-level access lists: cosa cambia con Glamsterdam
Il problema relativo al gas interessa una parte di un intervento più ampio. L’aggiornamento Ethereum Glamsterdam comprende infatti modifiche strutturali al funzionamento della blockchain, con l’obiettivo di aumentare la capacità di elaborazione senza compromettere la possibilità di verificare autonomamente le operazioni.
Una delle innovazioni principali è la proposer-builder separation, prevista dalla proposta EIP-7732.
Nell’architettura Ethereum, il proposer è il validatore incaricato di proporre un blocco, mentre il builder è il soggetto che costruisce il contenuto esecutivo del blocco stesso, selezionando e organizzando le transazioni.
Attualmente questa separazione può avvenire attraverso infrastrutture esterne al protocollo, utilizzate per mettere in relazione i validatori e i costruttori dei blocchi. Si tratta di un sistema che ha contribuito allo sviluppo del mercato della costruzione dei blocchi, introducendo però dipendenze operative da componenti intermedi.
La soluzione prevista da Glamsterdam, definita enshrined proposer-builder separation o ePBS, porta la distinzione dei ruoli direttamente nelle regole di Ethereum.
La modifica introduce procedure per la selezione dei builder, la gestione dei pagamenti e la verifica della tempestiva disponibilità dei dati necessari alla validazione. Consente inoltre di separare temporalmente alcune attività che oggi devono essere svolte entro finestre particolarmente ristrette.
Secondo la documentazione tecnica di Ethereum, l’obiettivo è ampliare il tempo disponibile per la propagazione dei dati e rendere più efficiente la gestione di blocchi di dimensioni maggiori.
Un secondo intervento riguarda le block-level access lists, previste dall’EIP-7928.
Attualmente l’esecuzione delle transazioni richiede di individuare progressivamente gli account e le porzioni di memoria coinvolte. Questo meccanismo introduce dipendenze che rendono complessa l’elaborazione parallela di molte operazioni.
Le nuove liste permettono di conoscere gli accessi allo stato effettuati durante l’esecuzione di un blocco, insieme ai risultati delle modifiche prodotte dalle transazioni.
Tali informazioni consentono ai client di organizzare più efficacemente la lettura dei dati, individuare dipendenze e preparare alcune operazioni di verifica in parallelo.
L’obiettivo è ridurre il lavoro ripetitivo richiesto ai nodi e creare le condizioni tecniche per aumentare la capacità della rete.
La disponibilità delle liste può inoltre facilitare determinate procedure di sincronizzazione, permettendo di ricostruire aggiornamenti dello stato attraverso le informazioni registrate senza dover necessariamente rieseguire ogni transazione.
Non significa che tutte le operazioni Ethereum diventeranno automaticamente parallele. Le transazioni che modificano gli stessi dati devono comunque rispettare le dipendenze necessarie a mantenere risultati deterministici.
La progettazione delle access lists costituisce piuttosto una base tecnica per migliorare progressivamente l’efficienza dell’esecuzione e della verifica.
Le modifiche alla struttura dei blocchi, alla contabilizzazione del gas e alla gestione dello stato sono strettamente collegate. Aumentare la capacità di elaborazione senza controllare i costi della memorizzazione potrebbe infatti incrementare le risorse hardware richieste ai nodi, rendendo più difficile la partecipazione indipendente alla rete.
Il limite di 200 milioni di gas e le verifiche richieste agli operatori
Il programma originario prevedeva che Hoodi raggiungesse un limite di gas di 200 milioni in concomitanza con l’attivazione di Glamsterdam.
Il gas limit di un blocco determina la quantità complessiva di lavoro computazionale contabilizzato che può essere inclusa secondo le regole del protocollo. Un limite maggiore permette potenzialmente di elaborare più attività, ma richiede anche attenzione ai tempi di esecuzione, alla propagazione dei blocchi e alle risorse utilizzate dai nodi.
L’aumento previsto per Hoodi era parte della sperimentazione necessaria a valutare la sostenibilità di una rete con capacità superiore.
La decisione di rinviare Glamsterdam ha comportato anche la rimozione di questo incremento programmato. Non è quindi corretto considerare il valore di 200 milioni come un parametro già attivato su Hoodi il 26 ottobre.
Sul piano operativo, la Ethereum Foundation ha chiesto ai gestori dei nodi di controllare le configurazioni dei software utilizzati.
Ethereum è composta da un livello di esecuzione, responsabile dell’elaborazione delle transazioni e dell’aggiornamento dello stato, e da un livello di consenso, che coordina validatori e produzione dei blocchi.
Entrambe le componenti devono applicare regole compatibili con quelle riconosciute dalla rete.
Un client che conservasse la precedente configurazione potrebbe tentare di applicare le nuove regole all’epoch originariamente previsto, mentre il resto della rete continuerebbe a utilizzare quelle precedenti.
Per evitare problemi di coordinamento, gli operatori devono utilizzare versioni che recepiscano espressamente il rinvio.
Le comunicazioni aggiornate della Ethereum Foundation riportano release specifiche per i principali client, tra cui Lighthouse, Lodestar, Prysm e Teku per il consenso, oltre a Besu, Erigon, go-ethereum, Nethermind e Reth per l’esecuzione.
La compatibilità non può essere dedotta dalla sola presenza del supporto a Glamsterdam. Una versione preparata per l’attivazione iniziale potrebbe contenere ancora la data successivamente cancellata.
Anche i gestori dei validatori e delle infrastrutture esterne impiegate nella costruzione dei blocchi devono verificare le istruzioni dei rispettivi fornitori.
Per gli utenti ordinari e i possessori di ETH, invece, il rinvio non richiede interventi su wallet, token o transazioni della rete principale.
Il calendario della mainnet resta senza una data ufficiale
La conseguenza più evidente del rinvio riguarda la programmazione delle successive fasi di rilascio.
Al 29 ottobre 2026, le comunicazioni ufficiali consultate non indicano una nuova data di attivazione dell’aggiornamento Ethereum Glamsterdam su Hoodi e non stabiliscono un’epoch definitiva per il passaggio alla mainnet.
La pagina dedicata a Glamsterdam nella roadmap pubblicata su ethereum.org riporta ancora un riferimento al quarto trimestre 2026 per l’attivazione sulla rete principale, accompagnato dall’indicazione che la data non è confermata.
Nella stessa pagina compare anche un precedente riferimento al fork di Hoodi del 27 ottobre, ma il documento risulta aggiornato al 14 settembre 2026. Quel calendario è stato superato dalle comunicazioni successive della Ethereum Foundation, che hanno prima fissato il 26 ottobre e poi annullato l’attivazione.
La differenza tra le date presenti nei diversi documenti dipende quindi dal loro aggiornamento, non dall’esistenza di due attivazioni distinte.
Durante le discussioni tecniche erano state considerate anche possibili finestre di rilascio sulla mainnet nel mese di dicembre. Si trattava tuttavia di ipotesi subordinate al completamento dei test, non di un calendario approvato.
Il rinvio di Hoodi modifica le condizioni sulle quali si basavano quelle previsioni.
Prima di stabilire una nuova attivazione sarà necessario completare l’analisi delle interazioni tra EIP-8037, EIP-8038 e gli smart contract esistenti, valutare eventuali correzioni delle specifiche e coordinare le versioni aggiornate dei diversi client.
Rimane inoltre da verificare se le modifiche al sistema di contabilizzazione del gas potranno essere mantenute nella forma prevista oppure richiederanno adattamenti.
La questione assume rilievo soprattutto per le applicazioni decentralizzate già distribuite. Una modifica del protocollo può incidere su contratti che non sono facilmente aggiornabili e che continuano a gestire operazioni secondo regole fissate al momento della loro pubblicazione.
I test su contratti esistenti e l’analisi dei comportamenti in condizioni di esaurimento del gas diventano quindi determinanti per valutare la compatibilità dell’aggiornamento.
La prossima decisione operativa attesa riguarda la definizione di una nuova configurazione per Hoodi. Solo dopo ulteriori verifiche e il coordinamento tra i gruppi di sviluppo potrà essere annunciato un calendario ufficiale per l’attivazione di Glamsterdam sulla rete principale Ethereum.
