Ethereum rinvia Glamsterdam: un problema nei contratti blocca Hoodi

📌 In Sintesi

• Ethereum Foundation annuncia il rinvio dell’upgrade Glamsterdam sulla testnet Hoodi, previsto per il 26 ottobre 2026, senza indicare una nuova data di attivazione.
• La decisione nasce dalla necessità di approfondire gli effetti di EIP-8037 sugli smart contract esistenti. Viene annullato anche l’aumento programmato del gas limit a 200 milioni.
• Gli operatori dei nodi Hoodi devono aggiornare le configurazioni prima del 26 ottobre. La mainnet Ethereum non subisce modifiche e gli utenti ETH non devono intervenire.

Ethereum rinvia l’aggiornamento Glamsterdam sulla testnet Hoodi dopo che gli sviluppatori hanno individuato potenziali problemi di compatibilità fra il nuovo sistema di contabilizzazione del gas e gli smart contract già utilizzati sulla blockchain. La decisione, annunciata dalla Ethereum Foundation il 22 ottobre 2026, cancella l’attivazione fissata per il 26 ottobre alle 17:42:48 UTC e sospende anche l’aumento del gas limit a 200 milioni. Il nodo tecnico riguarda EIP-8037, la proposta che modifica i costi delle operazioni capaci di creare nuovo stato permanente sulla rete. Il rinvio interessa esclusivamente Hoodi: non costituisce un’interruzione della blockchain principale e non richiede alcuna operazione ai possessori di ETH.

Ethereum cancella Glamsterdam su Hoodi dopo la riunione ACDE #248

La decisione è stata presa durante la riunione All Core Developers Execution numero 248, quando gli sviluppatori hanno concordato sulla necessità di ulteriori verifiche prima di applicare le nuove regole alla testnet. Nel comunicato ufficiale della Ethereum Foundation del 22 ottobre viene confermata la cancellazione dell’attivazione precedentemente associata all’epoch 132.352, corrispondente allo slot 4.235.264 di Hoodi. La modifica riguarda sia Amsterdam, il pacchetto di aggiornamenti dell’execution layer, sia Gloas, che interessa il consensus layer. Contestualmente è stato ritirato il calendario che prevedeva di portare il gas limit della rete di prova a 200 milioni nella medesima epoca. Non si tratta di un rollback della blockchain o dell’annullamento delle transazioni precedenti, ma della rimozione di un aggiornamento ancora da eseguire dalle configurazioni dei client. Gli sviluppatori non hanno indicato una nuova data né un nuovo epoch di attivazione. La scelta modifica il calendario già annunciato il 16 ottobre e interrompe temporaneamente il percorso di sperimentazione avviato con il precedente aggiornamento Glamsterdam su Sepolia del 6 ottobre, che aveva consentito di verificare l’aumento della capacità elaborativa in un ambiente differente da Hoodi.

Leggi anche: Ethereum oltre la blockchain: la roadmap di Vitalik Buterin guarda al 2030

EIP-8037 cambia il costo del gas e può alterare gli smart contract

EIP-8037 introduce una separazione fra il gas necessario all’esecuzione del codice e quello destinato alla creazione di nuovo stato permanente, con l’obiettivo di impedire che l’aumento della capacità dei blocchi provochi una crescita insostenibile dei database dei nodi. La specifica ufficiale EIP-8037 propone un parametro chiamato CPSB, Cost Per State Byte, che quantifica il costo della nuova occupazione di memoria persistente. Nel modello esaminato, la creazione di uno slot di storage passa da un costo tradizionale di 20.000 gas a una componente di 97.920 unità di state gas, alla quale si aggiungono le componenti di esecuzione.

Anche la creazione di nuovi account e la distribuzione degli smart contract diventano più costose. La modifica è progettata per contenere la crescita dello stato intorno a 120 GiB annui, prendendo come riferimento un gas limit di 150 milioni. Il problema nasce dal fatto che molti contratti già distribuiti utilizzano soglie di gas predeterminate o ricavano il comportamento delle operazioni dal valore restituito da gasleft(). Con il nuovo modello alcune assunzioni possono diventare errate: una chiamata che prima falliva in una determinata condizione potrebbe completare un percorso successivo, mentre un’operazione considerata sufficientemente finanziata potrebbe non disporre più del gas necessario. L’interfaccia del contratto rimane identica, ma il risultato operativo può cambiare, rendendo necessario verificare l’effetto dell’aggiornamento sul codice già esistente.

ChainSecurity individua il rischio dei fallimenti che non producono più revert

La questione tecnica era stata sollevata da ChainSecurity prima della decisione degli sviluppatori. Nella ricerca pubblicata il 13 ottobre sugli effetti del gas in Glamsterdam, gli analisti dimostrano che le modifiche introdotte da EIP-8037 ed EIP-8038 possono alterare il comportamento degli smart contract che gestiscono chiamate fallite. Il problema riguarda soprattutto i meccanismi utilizzati per riconoscere una condizione di out-of-gas e impedirne la trasformazione in un errore definitivo. Nel modello precedente, una chiamata esterna con gas insufficiente poteva lasciare troppo poche risorse per completare l’operazione successiva, provocando il revert dell’intera transazione. Con Glamsterdam, invece, il nuovo sistema di state-gas reservoir e i meccanismi di restituzione del gas possono permettere al contratto chiamante di proseguire, anche quando la chiamata originale ha esaurito il proprio budget. Un esempio particolarmente delicato riguarda i contratti che registrano il fallimento di un’operazione e disabilitano i tentativi successivi: un attaccante potrebbe provocare artificialmente l’esaurimento del gas e indurre il sistema a considerare definitivo un errore che avrebbe dovuto rimanere recuperabile. ChainSecurity non sostiene che tutti i contratti siano vulnerabili, ma individua classi specifiche di logiche che richiedono verifiche prima del fork. La Ethereum Foundation non ha dichiarato che un singolo exploit dimostrato da ChainSecurity sia la causa esclusiva del rinvio; ha confermato più prudentemente la necessità di approfondire le interazioni di EIP-8037 con i contratti presenti sulla mainnet.

I nodi Hoodi devono aggiornarsi: Lodestar e Besu preparano il rinvio

Per gli operatori della testnet il problema è immediato, perché un nodo configurato per eseguire il fork il 26 ottobre potrebbe continuare a seguire un calendario ormai annullato. La Ethereum Foundation invita quindi a controllare le versioni dei client dell’execution layer e del consensus layer e ad applicare soltanto aggiornamenti che dichiarino esplicitamente la rimozione dell’attivazione originaria. Fra le prime versioni indicate nella comunicazione aggiornata figurano Lodestar 1.50.1 per il consensus layer e Besu 26.10.1 per l’execution layer; l’elenco rimane soggetto ad aggiornamenti da parte dei rispettivi sviluppatori. I validatori devono verificare anche i software dedicati alla validazione e le eventuali infrastrutture esterne di costruzione dei blocchi, perché il rinvio riguarda entrambe le componenti del protocollo. Non è sufficiente installare una versione precedentemente descritta come compatibile con Glamsterdam: quella compatibilità poteva riferirsi proprio all’attivazione del 26 ottobre, ormai cancellata. Per gli sviluppatori applicativi diventa inoltre necessario rinviare i test programmati su Hoodi e continuare la valutazione dei contratti nelle reti e negli ambienti disponibili, confrontando il comportamento prima e dopo le modifiche al gas. Nessun intervento è invece richiesto agli utenti della mainnet, agli exchange o ai possessori di ETH in conseguenza di questo specifico annuncio.

Continua con:

Ethereum EEZ porta la prima transazione atomica da L1 a L2 su mainnet

Vulnerabilità di sicurezza negli smart contract: allarme nel Web3

Glamsterdam punta a scalare Ethereum, ma la compatibilità frena il calendario

Il rinvio evidenzia il conflitto tecnico che accompagna l’espansione di Ethereum. Glamsterdam comprende interventi come Enshrined Proposer-Builder Separation (ePBS) e Block-Level Access Lists (BAL), concepiti per rendere più efficiente la produzione dei blocchi e permettere un maggiore volume di elaborazione sulla rete principale. La stessa evoluzione richiede però una revisione dei costi delle operazioni che occupano spazio permanente nei database: aumentare semplicemente il gas limit senza controllare la crescita dello stato rischierebbe di rendere più oneroso mantenere un nodo indipendente, favorendo infrastrutture concentrate presso operatori con maggiori risorse. EIP-8037 tenta di risolvere questo problema attraverso una contabilità più articolata, ma introduce inevitabilmente nuove condizioni di esecuzione che devono essere compatibili con gli smart contract esistenti, compresi quelli utilizzati nella finanza decentralizzata. La Ethereum Foundation aveva già riconosciuto nella valutazione ufficiale dell’impatto del repricing che una minoranza di contratti poteva richiedere interventi preventivi, soprattutto per le assunzioni sui limiti di gas. La sospensione del test Hoodi conferma quindi che l’aumento della capacità non può essere separato dalla stabilità del codice già distribuito. Ethereum non ha cancellato Glamsterdam né annunciato una nuova data per la mainnet: ha interrotto una prova prima che le modifiche al protocollo potessero essere considerate sufficientemente compatibili con l’ecosistema esistente.