Gli sviluppatori di Ethereum hanno messo in pausa l'attivazione dell'upgrade Glamsterdam sulla testnet Hoodi a causa di preoccupazioni sul comportamento degli smart contract già distribuiti con le nuove regole di prezzo del gas dell'upgrade. La decisione è stata presa durante la chiamata All Core Devs Execution #248, come ha dichiarato l'Ethereum Foundation nel suo annuncio del 22 ottobre.

Punti chiave della decisione:

• Il costo di stato di un nuovo storage slot sale da 20.000 a 97.920 gas.
• L'aumento previsto del limite di gas di Hoodi a 200 milioni è stato anch'esso rimosso.
• Nessuna data di attivazione di Glamsterdam sul mainnet è stata fissata.
• La revisione Last Call dell'EIP-8037 si chiude il 1° novembre.

L'ultimo passo della testnet prima del mainnet è in pausa

Glamsterdam era previsto per l'attivazione su Hoodi il 26 ottobre alle 17:42:48 UTC. Il rinvio rimuove sia l'attivazione di Amsterdam sul livello di esecuzione sia quella di Gloas sul livello di consenso — le due metà dell'upgrade — insieme al programma che avrebbe portato il limite di gas di Hoodi a 200 milioni nello stesso momento. La modifica cambia la configurazione futura della testnet senza ripristinarne la cronologia, e non è stata fissata alcuna data sostitutiva.

Durante Fusaka, l'upgrade precedente, Hoodi è stata la terza e ultima testnet a effettuare il fork prima del mainnet, e la Foundation ha detto che il mainnet sarebbe seguito almeno 30 giorni dopo, secondo The Block. In quell'implementazione, il fork finale sulla testnet era l'ultimo checkpoint pubblico prima del mainnet. Glamsterdam ha già superato una prova generale a 200 milioni gas su Sepolia, dove la correzione è stata un aggiornamento di Prysm ai valori predefiniti dei validator — un problema di configurazione del client. Questa volta la questione è come si comportano i contratti già distribuiti. La Foundation non ha fissato una data di mainnet per Glamsterdam e dichiara che gli utenti del mainnet e i possessori di ETH non devono intraprendere alcuna azione.

Un aumento del prezzo dello storage che riduce il gas di esecuzione su alcune scritture

L'EIP-8037 esiste per rallentare la crescita dello stato di Ethereum, i dati che ogni nodo deve memorizzare. I suoi autori stimano tale stato a circa 390 GiB a gennaio 2026. Stimano che, con i prezzi attuali, un limite di gas di 200 milioni potrebbe superare i 650 GiB — il livello al quale i nodi iniziano a rallentare — in meno di un anno. La loro risposta è addebitare 1.530 gas per byte di nuovo stato, portando il costo di stato di un nuovo storage slot da 20.000 a 97.920 gas e quello di un nuovo account da 25.000 a 183.600.

Per mantenere possibili distribuzioni di contratti di grandi dimensioni, la proposta divide il gas in due pool. Il gas di esecuzione copre il calcolo, mentre il gas di stato copre il nuovo storage. Qualsiasi gas fornito da una transazione oltre 16.777.216 va in un serbatoio separato di gas di stato, dal quale gli addebiti di stato attingono per primi. Quel serbatoio è passato integralmente a ogni sub-call, e i contratti non possono vederlo tramite la lettura standard di gasleft().

Gas di esecuzione richiesto per una scrittura a freddo su un nuovo storage slot, secondo ChainSecurity, con le cifre di EIP-8037 ed EIP-8038:

• Oggi: 22.100
• Glamsterdam, il serbatoio paga l'addebito di stato di 97.920: 12.100
• Glamsterdam, serbatoio vuoto: 110.020

In altre parole, la stessa identica scrittura a freddo può costare circa nove volte più gas di esecuzione con il serbatoio vuoto rispetto a quando il serbatoio copre l'addebito di stato.

Il gas può anche fluire indietro durante l'esecuzione. La cancellazione di uno slot creato in precedenza nella stessa transazione ricarica immediatamente fino a 97.920 gas, e una sub-call che fa revert può restituire gli addebiti di stato pagati. Il saldo di gas visibile di un contratto può quindi aumentare a metà esecuzione. L'EIP avverte che i contratti che misurano il lavoro come differenza tra due letture del gas possono ottenere un risultato negativo, e che i contratti già distribuiti con tale design non possono essere corretti.

Come un attaccante potrebbe sfruttare le nuove regole

La società di sicurezza ChainSecurity ha descritto il rischio in un'analisi del 13 ottobre. I contratti spesso intercettano unaata fallita e registrano il risultato, il che permette a un chiamante dannoso di fornire deliberatamente troppo poco gas affinché un'operazione valida fallisca mentre il contratto ha ancora abbastanza gas per salvare quel fallimento. La tecnica è nota come insufficient gas griefing, e può bloccare in modo permanente un nuovo tentativo o rimuovere la richiesta di un utente.

Per i contratti che fanno affidamento sull'esaurimento del gas dello stesso gestore degli errori:

• Passo 1: L'attaccante invia una chiamata con troppo poco gas.
• Passo 2: L'operazione target esaurisce il gas.
• Oggi: Anche il gestore esaurisce il gas, tutto fa revert e l'utente può riprovare.
• Glamsterdam: Il serbatoio o il gas ricaricato permette al gestore di completare l'operazione e salvare il fallimento in modo permanente.

I contratti che verificano il gas rimanente dopo una chiamata fallita possono essere ingannati quando ricariche di gas o un intermediario che fa revert riportano il saldo sopra la loro soglia. Anche i budget di gas fissi possono risultare insufficienti, perché l'EIP-8038 aumenta il costo dell'accesso allo stato esistente: la prima modifica a uno slot caldo esistente sale da 2.900 a 10.100 gas.

Non ogni difesa si rompe. ChainSecurity dichiara che una verifica effettuata prima della chiamata garantisce ancora la consegna del gas richiesto, purché il budget copra ogni percorso di esecuzione con i nuovi prezzi senza contare sul serbatoio. L'azienda sconsiglia di affidarsi del tutto alle verifiche del gas dopo la chiamata. L'avviso della Foundation nomina solo l'EIP-8037 e non cita il lavoro dell'azienda, che copre anche l'EIP-8038.

Cosa devono fare operatori e sviluppatori

Gli operatori di Hoodi devono aggiornare i client di esecuzione e di consenso prima del 26 ottobre, utilizzando release le cui note confermino esplicitamente che la vecchia attivazione è stata rimossa. Le tabelle di versione dell'annuncio originale non valgono come conferma. Al 23 ottobre, la Foundation aveva elencato release aggiornate per due client, e ha detto che altre verranno aggiunte man mano che saranno confermate.

I validator devono aggiornare sia il beacon node sia il client del validator, e chiunque gestisca infrastrutture esterne per la costruzione di blocchi deve seguire le istruzioni del proprio fornitore. I team applicativi dovrebbero smettere di pianificare test su Hoodi intorno alla data originale.

Per gli sviluppatori di contratti, la checklist di ChainSecurity parte da ogni chiamata che consente all'esecuzione di continuare dopo un fallimento. Comprende il tracciamento dell'intero percorso, inclusi i proxy; l'identificazione degli slot impostati e cancellati nella stessa transazione e degli intermediari che fanno revert; la rivisitazione dei budget fissi; e il forzamento del fallimento delle sub-call confrontando il risultato sotto entrambi i set di regole. Ove possibile, una chiamata fallita dovrebbe far fare revert all'intera operazione. Anche wallet e software per nodi devono aggiornare la stima del gas per il modello a due pool, secondo l'EIP.

Le prossime decisioni spettano agli sviluppatori core. La revisione Last Call dell'EIP-8037 — la finestra finale di revisione prima che una proposta venga finalizzata nel processo di Ethereum — si chiude il 1° novembre, l'indagine potrebbe portare a modifiche delle specifiche, e una nuova data per Hoodi saràata in una futura chiamata.

Questo articolo è fornito solo a scopo informativo e non costituisce consulenza finanziaria o di investimento. I calendari degli upgrade di Ethereum e le specifiche tecniche possono cambiare durante i test.

Fonte: Coindoo