Ethereum: due bozze rivali per evitare che Glamsterdam rompa i vecchi contratti, ma nessuna è stata testata

Domenica 8 novembre due sviluppatori di Ethereum hanno depositato bozze rivali che cercano di evitare che l’aggiornamento Glamsterdam rompa i contratti già in funzione sulla mainnet. EIP-8488, di Leo Glisic, lascerebbe ogni contratto esistente ai prezzi del gas di oggi e obbligherebbe i nuovi contratti a usare un nuovo set di opcode. Una seconda bozza, di Giulio Rebuffo e ancora senza numero definitivo, farebbe correre due contatori di gas in parallelo: uno che i contratti vedono, uno che determina la commissione. Entrambe puntano allo stesso problema, blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il repricing del gas di Glamsterdam contenuto in EIP-8037 ed EIP-8038, e nessuna ha ancora codice per i client, risultati di test o un posto nell’agenda di una call degli sviluppatori.

I due testi sono stati aperti come pull request sul repository ethereum/EIPs, quello di Rebuffo alle 15:58 UTC e quello di Glisic alle 19:40 UTC, e secondo GitHub sono entrambi in stato Draft, in attesa della revisione di un editor. CoinDesk ha riportato i due depositi nelle prime ore di lunedì. Arrivano mentre Glamsterdam è fermo: la prova generale dell’aggiornamento sulla rete di test Hoodi è stata annullata a ottobre e non ha una nuova data, una storia raccontata per intero nella nostra pagina su il fork di Glamsterdam rinviato su Hoodi.

Cosa cambia con il repricing del gas di Glamsterdam: EIP-8037 ed EIP-8038

Le due EIP al centro della disputa rendono molto più cara la scrittura di nuovi dati su Ethereum. EIP-8037, «State Creation Gas Cost Increase», prezza lo stato al byte: una costante chiamata CPSB è fissata a 1.530 gas per byte, scelta in modo che lo stato memorizzato della catena cresca di circa 120 GiB l’anno con un limite di gas di 150 milioni. Quel gas di stato è inoltre misurato a parte rispetto al normale gas di esecuzione, in quello che il testo chiama reservoir. EIP-8038 alza il prezzo di lettura e scrittura dello stato già esistente.

Entrambe le proposte sono state in «Last Call», la fase finale di revisione, con scadenza al 1° novembre 2026. Il 9 novembre il sito delle EIP mostrava ancora quello stato per tutte e due. Le cifre principali, tratte dai due testi:

EIP-8037 stima che un nuovo account costerà circa sette volte quanto costa oggi, un nuovo slot di storage circa cinque volte e il rilascio di un contratto da 24 kB circa otto volte. Con una base fee di 0,08 gwei, quel rilascio da 24 kB viene a costare circa 0,003 ETH, poco più di 6 dollari con ETH intorno a 2.090 dollari alle 08:09 UTC. A quell’ora ether perdeva il 6,52% nelle 24 ore, in linea con un mercato sceso del 6,68%; nessuna fonte collega il calo a questo dibattito.

Cosa si rompe: i vecchi contratti che contano su un gas fisso

Prezzi più alti, da soli, renderebbero solo le transazioni più care. Il guaio è il codice che dà per scontato un prezzo. Molti contratti inviano una quantità fissa di gas insieme a una chiamata verso un altro contratto, e molti non possono essere modificati dopo il rilascio. Se la chiamata improvvisamente richiede più di quella quantità fissa, fallisce, ha spiegato CoinDesk.

La Ethereum Foundation lo aveva segnalato ad agosto. I suoi team di ricerca, EthPandaOps e specifiche hanno rieseguito transazioni passate con il nuovo listino e hanno scritto che «un piccolo gruppo di smart contract si basa su ipotesi che il nuovo listino sposta». Il loro post del 24 agosto ordina i risultati in quattro gruppi, da «nessun cambiamento» a «potenzialmente rotto», e indica le abitudini a rischio: la dotazione di 2.300 gas di transfer e send in Solidity, valori di gas scritti a mano nelle chiamate, logiche che si ramificano su gasleft() e transazioni prefirmate con limiti di gas fissi. Per gli utenti comuni il post diceva che «non serve alcuna azione».

EIP-8037 ammette una rottura tutta sua. Poiché il reservoir del gas di stato può rimpinguare il gas che un contratto vede, il codice che misura il lavoro leggendo due volte l’opcode GAS e sottraendo può ottenere un numero negativo. Per i contratti già sulla mainnet con questo schema, l’EIP dice che il problema non si può risolvere. Wallet, la chiamata eth_estimateGas del software dei nodi e i bundler ERC-4337 devono tutti essere aggiornati per prezzare le due dimensioni.

A ottobre la società di audit ChainSecurity ha poi trovato una versione più insidiosa del rischio: i rimborsi possono lasciare giusto il gas sufficiente perché il gestore dei fallimenti di un contratto arrivi in fondo, così un fallimento pensato per essere ritentato viene registrato come definitivo. I suoi risultati, i 13 contratti della mainnet che il 22 ottobre diceva di aver individuato (senza nome, con la comunicazione ai rispettivi team in corso) e la decisione di ottobre di ritirare la data di Hoodi sono raccontati nel nostro articolo su la regola di Glamsterdam che gli sviluppatori hanno annullato per i depositi di staking e nella pagina su Hoodi. ChainSecurity non ha dimostrato che un grande protocollo in produzione possa essere sfruttato, aveva osservato CoinDesk all’epoca.

EIP-8488: i vecchi contratti tengono il vecchio listino

La bozza di Glisic, intitolata «Versioned Opcodes for Gas Repricing», aggiunge alla Ethereum Virtual Machine un secondo set di istruzioni. Ogni opcode il cui costo cambia con EIP-8037 o EIP-8038 riceve un gemello V2, come SSTORE_V2, CALL_V2 o CREATE2_V2, prezzato sul nuovo listino. I contratti rilasciati prima del fork continuano a girare sul vecchio listino «a tempo indeterminato», come dice la bozza.

Dopo l’attivazione, ogni nuovo codice runtime viene scansionato quando viene memorizzato. Se contiene un vecchio opcode che ha un gemello V2, il rilascio fallisce. Se passa, all’account viene assegnato un campo code_version impostato a 2. Un nuovo DELEGATECALL_V2 rifiuta di eseguire codice con versione inferiore a 2, perché delegatecall esegue il codice di qualcun altro dentro lo storage del chiamante. CALL e STATICCALL semplici possono invece raggiungere qualsiasi contratto, vecchio o nuovo.

La bozza toglie anche GAS e GASLIMIT dal set V2, quindi i nuovi contratti non possono leggere affatto il gas residuo. L’argomento di Glisic è che il codice che non vede il contatore del gas non può costruire ipotesi che un repricing successivo romperebbe. Cosa prenderebbe il posto di gasleft() per il codice che ne ha bisogno, come i segnali standard di esaurimento del gas o le ricevute del gas speso, è lasciato a proposte collaterali.

I protocolli aggiornabili passerebbero ai nuovi prezzi non appena sostituiscono la propria implementazione, e il limite di gas potrebbe poi salire a gradini man mano che più attività gira su codice V2, spiega la sezione sulle motivazioni, che la definisce «una terza opzione» tra applicare il repricing a tutti e abbandonarlo.

Quando abcoathup, che assegna i numeri alle EIP per conto degli editor, gli ha dato l’8488 lunedì alle 01:06 UTC, Glisic, che l’aveva depositata come 8888, ha risposto: «Mi accontento di tre 8 invece di quattro, immagino». Ha aggiunto di non poter aprire un thread di discussione su Ethereum Magicians, il forum dove si discutono le EIP, perché il suo account è stato cancellato e il suo IP bloccato. Il motivo indicato era l’uso di account fantoccio (sock-puppeting), che a suo dire faceva apertamente. Il link di discussione della sua bozza punta ancora al thread di EIP-8038.

La bozza di Rebuffo: due contatori di gas, un solo conto

La pull request n. 12637 di Rebuffo, «Separate execution credits and billing credits», lascia in pace gli opcode e divide invece il contatore del gas. Entrambi i contatori partono dal limite di gas della transazione. I «credits» scendono secondo il vecchio listino e sono tutto ciò che l’EVM vede: gasleft() restituisce credits, le chiamate inoltrano credits, la dotazione di 2.300 si paga in credits. Il «billing» scende secondo il nuovo listino e decide quanto paga chi invia.

Un contratto che invia 2.300 gas fissi riceve quindi ancora i 2.300 di sempre. A cambiare è la fine del percorso. Se il billing si esaurisce prima del prossimo addebito, l’intera transazione si interrompe con un nuovo errore, BILLING_OUT_OF_GAS. Nessun contratto può intercettarlo né eseguire un gestore dei fallimenti, ogni frame viene srotolato e chi invia paga l’intero limite di gas. Secondo la bozza, l’interruzione non intercettabile impedisce a un contratto di registrare un fallimento una volta esaurito il billing, che è lo schema su cui ChainSecurity aveva lanciato l’allarme. Il testo aggiunge che i rischi di griefing e di denial of service restano.

Rebuffo è esplicito su ciò che manca. I listini esatti, i punti di addebito, le regole sui rimborsi, i campi delle ricevute e la contabilità dei blocchi sono ancora da scrivere, dice la pull request, e «nessuna implementazione per client di esecuzione né test di consenso è stata eseguita per questo disegno». Il testo si definisce una base di discussione, non una proposta pronta per il rilascio. Lunedì abcoathup ha suggerito il numero 8487 e ha chiesto un thread su Magicians.

Due rimedi rivali e quanto costa ciascuno

In breve, Glisic cambia il listino sotto cui gira un contratto, mentre Rebuffo tiene il vecchio listino dentro l’EVM e cambia soltanto il conto. Ogni approccio ha un prezzo, e le bozze ne ammettono la maggior parte. I punti che seguono sono la lettura di Coindaro dei due testi; finora nessun team dei client ha commentato le pull request.

EIP-8488 lascerebbe i client a gestire per sempre due tabelle di gas, più una V3 in futuro se lo schema si ripete, come prevede la bozza stessa. Più importante per lo scopo del repricing, i contratti già esistenti continuerebbero a scrivere nuovo stato ai prezzi di oggi. Contratti di token, exchange e mercati di prestito rilasciati prima del fork farebbero crescere lo stato della catena al ritmo vecchio finché non migrano. La bozza lo accetta e propone di alzare gradualmente il limite di gas man mano che cresce l’uso di V2.

Una conseguenza non è discussa nella bozza, ed è una lettura di Coindaro, non dell’autore. Il filtro sui rilasci copre CREATE, CREATE2 «o qualsiasi altro percorso di creazione del codice» e respinge il nuovo codice che contiene ancora un opcode legacy con un gemello V2. Una factory già rilasciata, non aggiornabile, che crea nuovi contratti da bytecode scritto prima del fork (un pool, un vault o un wallet per ogni utente, per esempio) vedrebbe quindi quei rilasci andare in revert. Il fatto stride con la frase della bozza secondo cui i contratti esistenti restano «non toccati»: la factory continua a girare, ma uno dei suoi compiti principali si ferma. Quali factory attive sarebbero coinvolte, e se sia prevista un’eccezione, la bozza non lo dice.

Il disegno di Rebuffo conserva il vecchio comportamento solo finché dura il billing, e la bozza lo dice chiaramente. Le transazioni che oggi riescono «ora possono interrompersi con crediti ancora disponibili», avverte la sezione sulla compatibilità. Un contratto non fidato dentro un batch può consumare l’allocazione di billing condivisa e far abortire tutto, compreso il lavoro non correlato. Stima delle commissioni e ricevute dovrebbero riportare due numeri. E far pagare di più non è un limite rigido alle risorse, aggiunge il testo: se il repricing deve frenare la crescita dello stato, le regole dei blocchi devono imporlo a parte.

«Non andrebbe rilasciato così com’è»: la pressione su Glamsterdam

Le bozze sono arrivate in un thread già acceso. Il ricercatore di sicurezza pcaversaccio ha scritto su X che «a mio avviso Glamsterdam non dovrebbe essere rilasciato così com’è, punto», e ha detto di aver sollevato gli aumenti di gas con gli sviluppatori core due settimane prima, secondo CoinDesk. Lo sviluppatore pseudonimo banteg ha indicato «l’elenco già enorme di 200.000 contratti interessati» nello strumento di impatto del repricing della Foundation, sostenendo che il metodo ne manca molti di più. Ha aggiunto, riferisce CoinDesk, che il problema tocca il rilascio e il funzionamento di diversi protocolli di primo piano.

Quei 200.000 sono il conteggio dei contratti che lo strumento di replay elenca come interessati, non di contratti di cui sia stato dimostrato lo sfruttamento. La Foundation ordina i risultati del replay in quattro gruppi, da «nessun cambiamento» a «riesce con modifiche», a «risolvibile con un aumento del limite di gas», fino a «potenzialmente rotto», e stare nell’elenco non colloca un contratto nell’ultimo. I team possono cercare i propri contratti nello strumento.

Altri media hanno riferito che la Foundation ha coinvolto società di audit, con CoinCentral che cita lo sviluppatore di Geth Marius van der Wijden sul lavoro con ChainSecurity e Dedaub.

Cosa succede ora: ACDC il 12 novembre, ACDE n. 249 il 19 novembre

Sul calendario del repository ethereum/pm ci sono due call degli sviluppatori core. All Core Devs Consensus n. 191 si riunisce giovedì 12 novembre alle 14:00 UTC, e All Core Devs Execution n. 249 giovedì 19 novembre alle 14:00 UTC, quattro settimane dopo la n. 248 a causa di Devcon. Le agende di entrambe indicano «Glamsterdam» come primo punto. Nessuna nomina EIP-8488 o la bozza di Rebuffo e, lunedì mattina, nessun commento alle due issue chiede di aggiungerle.

Prima che una delle due bozze venga discussa, gli editor delle EIP devono ancora farne il merge, ed entrambi gli autori sono stati invitati ad aprire un thread sul forum. Il 29 ottobre gli sviluppatori avevano stimato che il prossimo test privato di Glamsterdam potesse arrivare tra il 16 e il 20 novembre al più presto, ha riferito CoinDesk; quel piano è precedente a entrambe le bozze. Non esiste una nuova data per Hoodi e nemmeno per la mainnet: le date di dicembre discusse prima del rinvio sono elencate nella nostra pagina su Hoodi.

Stando alla cornice delle stesse bozze, gli sviluppatori core hanno ora quattro opzioni. Possono applicare il repricing a tutti e chiedere ai progetti coinvolti di adattarsi, escludere i contratti esistenti come propone Glisic, o separare le commissioni dall’esecuzione come propone Rebuffo. Oppure possono togliere le due EIP da Glamsterdam, cosa che, dice EIP-8488, rinvierebbe i controlli sulla crescita dello stato che sostengono un limite di gas più alto.

Cosa significa per chi detiene ETH, per chi fa staking e per gli sviluppatori

Oggi sulla mainnet non cambia nulla. Glamsterdam è attivo solo sulla rete di test Sepolia, dove si è attivato il 6 ottobre, e il post di ottobre della Foundation sul rinvio di Hoodi diceva che agli utenti della mainnet e a chi detiene ETH non era richiesta alcuna azione.

I compiti a casa spettano agli sviluppatori. Un contratto che inoltra una quantità fissa di gas, usa transfer o send, si ramifica su gasleft() o si affida a transazioni prefirmate andrebbe controllato fin da ora con lo strumento sul repricing, qualunque versione della correzione prevalga. I team che gestiscono wallet o bundler ERC-4337 dovranno gestire due dimensioni di gas con EIP-8037 così com’è scritta, o due contatori con la bozza di Rebuffo.

Gas, repricing e hard fork in due paragrafi

Ogni operazione di Ethereum ha un prezzo in unità di gas, e la commissione pagata da un utente è il gas usato moltiplicato per il prezzo del gas. La nostra voce di glossario sulle commissioni gas spiega le basi. Il repricing cambia il numero di unità che un’operazione costa, non il prezzo per unità.

Cambiare quei costi richiede un hard fork: tutti i nodi devono passare alle nuove regole allo stesso blocco, altrimenti la catena si divide. Per questo un fork di prova su Hoodi deve andare bene prima che si fissi una qualsiasi data per la mainnet, come spiega la nostra guida a soft fork e hard fork. Il prossimo passo pubblico in calendario è la call sul consenso del 12 novembre.