Lo sviluppatore della Ethereum Foundation Marius van der Wijden ha dichiarato in un aggiornamento del 6 novembre che gli sviluppatori core non effettueranno il fork del testnet Hoodi finché i problemi individuati dalla società di sicurezza ChainSecurity non saranno risolti. Hoodi è la rete di test pubblica in cui Ethereum prova le modifiche al protocollo prima che raggiungano la mainnet. Ha chiesto agli sviluppatori di contratti e agli auditor di verificare i propri progetti rispetto a otto invarianti del gas che il prossimo aggiornamento Glamsterdam viola. Il gas è l'unità con cui Ethereum prezza ogni operazione eseguita da una transazione: quando tali prezzi cambiano, il codice scritto secondo i vecchi valori può comportarsi in modo diverso anche se il codice in sé resta invariato.

Un'invariante, in questo contesto, è una regola che il codice considera sempre vera — ad esempio, "un budget di gas fisso è sufficiente per questa chiamata" o "una delega confermata in un blocco ha surtito effetto". Il repository delle invarianti della Foundation elenca otto assunzioni che cambiano con Glamsterdam e indica che la maggior parte dei risultati trovati finora ne riguarda due.

Due proposte riplasmano i costi del gas

Due proposte guidano il cambiamento. EIP-8037 alza il prezzo della creazione di nuovo stato — nuovi account, slot di storage e codice deployato — e lo contabilizza separatamente dall'esecuzione ordinaria. EIP-8038 alza il prezzo della lettura e dell'aggiornamento dello stato già esistente. Secondo la specifica su cui il repository esegue i test, la scrittura su uno slot di storage nuovo sale da 22.100 gas a 110.020, l'aggiornamento di uno slot esistente "warm" da 2.900 a 10.100 e il deploy del codice da 200 gas per byte a 1.530. Queste cifre cambiano se cambia la specifica.

La pausa ai test di Glamsterdam è seguita alla revisione del 13 ottobre di ChainSecurity, come già riportato. Il repository estende tali risultati con la scansione condotta dalla Foundation stessa sui contratti verificati su Sourcify, un registro pubblico del codice sorgente dei contratti, e con casi offchain come il software che legge le ricevute delle transazioni.

Una transazione confermata in un blocco non prova più che una delega sia stata applicata

EIP-7702 consente a un normale account Ethereum di eseguire codice di smart contract firmando un'autorizzazione che punta a un contratto delegato. Il meccanismo è attivo con l'aggiornamento Pectra del 2025 ed è alla base delle funzionalità smart account che i wallet hanno introdotto da allora. L'autorizzazione è pensata per un uso singolo. Prima di Glamsterdam, il suo costo integrale veniva addebitato in anticipo, quindi una transazione che non poteva pagarlo era invalida e non raggiungeva mai un blocco. Se una transazione era stata confermata, la delega era stata applicata.

La voce INV-8 del repository spiega cosa cambia con EIP-8037. Parte del costo ora dipende dallo stato dell'account e viene addebitata solo durante l'elaborazione dell'autorizzazione. Delegare da un account vuoto costa 235.606 gas, contro i 25.000 di prima. Una transazione con budget calcolato sul vecchio valore può essere accettata, esaurire il gas durante l'applicazione dell'autorizzazione e finire in un blocco con stato fallito. La delega viene annullata, e così anche l'incremento del nonce dell'account, il contatore che marca un'autorizzazione come usata. L'autorizzazione firmata, tuttavia, è ora pubblica e resta valida.

Di per sé, questo lascia il wallet non configurato piuttosto che compromesso. Il pericolo nasce quando il contratto delegato permette a chiunque di chiamare la sua funzione di setup. Un attaccante può allora ripresentare l'autorizzazione esposta in una propria transazione, chiamare prima setup e dichiararsi proprietario dell'account. Il front-running delle autorizzazioni nel mempool pubblico era già possibile. Il punto del repository è che una transazione fallita ora pubblica da sola un'autorizzazione valida, quindi instradarla privatamente non offre alcuna protezione. Il pattern è documentato con codice di esempio, e nessun wallet interessato viene nominato.

Il cambiamento pratico ricade su wallet, relayer e indexer. Il repository consiglia di controllare il codice e il nonce dell'account dopo una transazione di delega invece di fidarsi della ricevuta. Qualsiasi autorizzazione fallita dovrebbe essere trattata come esposta e annullata, sia avanzando il nonce dell'account sia delegando di nuovo verso un contratto sicuro. Una modifica della specifica che addebiteresti il costo peggiore in anticipo è stata proposta ma non adottata, e agli sviluppatori è detto di costruire come se il comportamento attuale restasse invariato.

I budget di gas spesso si trovano fuori dal contratto

La voce più ampia, INV-4, copre qualsiasi quantità di gas fissata prima del fork. Ora può non bastare, ovunque sia scritta: nel codice del contratto, in un valore di configurazione, in un messaggio firmato o in software offchain. Quest'ultimo gruppo include i relayer — servizi che inviano transazioni per conto degli utenti — oltre a keeper e sistemi di prelievo degli exchange.

I destinatari per la prima volta sono il trigger più comune. Inviare un token a un indirizzo con saldo zero crea un nuovo slot di saldo, e inviare ETH a un indirizzo vuoto crea un nuovo account, entrambi casi che EIP-8037 prezza molto di più. Secondo il repository, un trasferimento che oggi rientra in 65.000 gas può richiederne più di 150.000.

Dove vive il numero fisso determina quanto diventa grave il shortfall. Nel software offchain, l'intera transazione viene revertita e può essere reinviata con più gas. In un contratto, nelle sue impostazioni o in un messaggio firmato, fallisce solo la chiamata interna. Se il contratto esterno cattura quel fallimento, l'esito è spesso definitivo: un messaggio salvato come fallito, una callback saltata o ricompense registrate in modo errato. Alcuni di questi numeri non possono essere modificati affatto, tra cui le transazioni multisig firmate prima del fork, le meta-transazioni firmate e i messaggi cross-chain già in volo.

INV-7 applica lo stesso problema al gas tenuto in riserva. Le funzioni transfer e send di Solidity passano un importo fisso di 2.300 gas, ma un contratto ricevente che scrive un nuovo slot di storage ora ne richiede più di 110.000. Smart wallet, payment splitter e vault con logica nelle funzioni receive sono i candidati più evidenti.

I percorsi di errore un tempo revertiti ora possono completarsi

L'analisi del 13 ottobre di ChainSecurity spiega perché alcune protezioni superate nelle precedenti audit potrebbero smettere di funzionare. I contratti spesso catturano una chiamata esterna fallita per registrare l'errore, saltare una voce o provare un fallback. Questo diventa pericoloso quando qualcuno fornisce deliberatamente troppo poco gas — un attacco chiamato insufficient gas griefing — perché un'operazione che dovrebbe essere ripetibile viene marcata come definitivamente fallita.

I contratti tipicamente si difendono in due modi. Alcuni controllano quanto gas resta dopo la chiamata. Altri si affidano al fatto che il gestore degli errori sia troppo costoso per completarsi. Glamsterdam indebolisce entrambi. EIP-8037 assegna alle transazioni con limite di gas superiore a 16.777.216 un serbatoio separato per i costi di storage che il consueto controllo gasleft() non vede. Revertire una chiamata o azzerare uno slot appena scritto può anche restituire il gas speso. A parole di ChainSecurity, "Anche con codice del contratto invariato, un percorso di errore che prima veniva revertito ora può completarsi."

La società ora sconsiglia di dedurre il motivo del fallimento di una chiamata dal gas rimasto dopo. Il suo approccio preferito è lasciare revertire l'intera operazione dove possibile, oppure mantenere un percorso di recupero invece di prendere una decisione irreversibile basata sul gas residuo.

Un'audit precedente non può colmare da sola tale lacuna, perché ha giudicato il codice secondo le regole del gas in vigore all'epoca. La Foundation ha ingaggiato ChainSecurity e Dedaub accanto alle sue audit interne, ma il post del 6 novembre riconosce di non poter esaminare ogni progetto, in particolare il codice offchain. Anche le scelte di design influenzano la correzione: un limite di gas salvato come impostazione regolabile può semplicemente essere alzato, mentre uno scritto come costante fissa può lasciare ridistribuzione e migrazione come unica via.

Perché Ethereum prosegue con il repricing

L'argomento della Foundation a favore del cambiamento si fonda sull'accuratezza dei prezzi. La sua guida di agosto per gli sviluppatori di contratti indicava che i prezzi del gas per le operazioni di stato erano stati aggiornati l'ultima volta nel fork Berlin del 2021, il fork che ha stabilito l'attuale prezzatura cold-versus-warm per la lettura dello stato. Lo stato di Ethereum — il registro continuo di account, saldi e storage dei contratti che i nodi tracciano — è cresciuto significativamente da allora, e i recenti aumenti del limite di gas ne hanno accelerato la crescita. Il post definisce il repricing un prerequisito per alzare ulteriormente il limite di gas e indica che il nuovo schema deriva da un obiettivo di prestazioni che supporta circa un triplicamento del throughput di base.

Lo stesso post riferiva che il replay delle transazioni storiche della mainnet con i nuovi prezzi ha lasciato invariata la grande maggioranza, e che la maggior parte dei problemi segnalati poteva essere risolta alzando un limite di gas. Ha detto agli utenti ordinari che non era richiesta alcuna azione, perché wallet e infrastrutture aggiornati avrebbero gestito il cambiamento. I risultati di novembre danno più peso a quest'ultima clausola. Gestire il cambiamento ora include il controllo dello stato dell'account dopo una delega fallita e il dimensionamento dei budget dei relayer per i destinatari per la prima volta — lavoro che le vecchie regole del gas non richiedevano mai.

Cosa decideranno le prossime chiamate degli sviluppatori core

Secondo il repository, la Foundation sta raccogliendo feedback in vista della prossima chiamata All Core Developers, il foro permanente in cui vengono concordate le modifiche al protocollo Ethereum. A seconda della risposta, potrebbe modificare leggermente EIP-8037 ed EIP-8038 o lasciarli così come sono. Hoodi resta senza fork finché i problemi non saranno risolti, e il post del 6 novembre non indica una nuova data. Secondo lo stesso post, il lavoro su Hegota, l'aggiornamento previsto dopo Glamsterdam, continua in parallelo.

Prima che Hoodi effettui il fork: chi controlla cosa

• Team di contratti: incollate gli indirizzi nello strumento di ricerca dei contratti interessati della Foundation, poi esaminate qualsiasi codice che hardcoda valori di gas o faccia branching sul gas residuo, sia elencato che meno.
• Wallet e provider RPC: aggiornate la stima del gas per il nuovo schema. La Foundation avverte che le costanti di gas in cache sottostimeranno i costi e causeranno transazioni fallite.
• Relayer, keeper e bundler: rendete i limiti regolabili e ristimate secondo le nuove regole con un margine, testando transazioni su entrambi i lati della soglia del serbatoio.
• Auditor: il repository include istruzioni per eseguire i propri controlli con un agente di coding AI, con codice e risultati mantenuti in locale.

I segnali da seguire sono una data di fork di Hoodi sul blog della Foundation, qualsiasi revisione alla specifica di uno dei due EIP e conferme di correzioni dai progetti interessati. La Foundation ha chiesto ai team di segnalare i problemi privatamente a glamsterdam@ethereum.org anziché in issue pubbliche, affinché i problemi possano essere corretti prima che i dettagli si diffondano.

Questo articolo è apparso originariamente su Coindoo.