Ethereum Glamsterdam, rinviato il fork della testnet Hoodi del 26 ottobre: nessuna nuova data

Aggiornamento del 22 ottobre 2026, 16:45 UTC: il fork Glamsterdam previsto su Hoodi per il 26 ottobre è stato tolto dal calendario e non è stata fissata una nuova data. La configurazione della rete è stata ripristinata con la pull request #33 del repository eth-clients/hoodi, unita alle 15:02 UTC (le 17:02 in Italia) durante la call All Core Devs Execution (ACDE #248), e team di client come Lodestar e Besu hanno seguito con modifiche analoghe che eliminano anche il gas limit di 200 milioni previsto. Finora non è stata data alcuna motivazione ufficiale. Le date candidate di dicembre per la mainnet dipendevano da un fork di Hoodi senza intoppi e ora sono incerte; il prossimo appuntamento è la call del livello di consenso ACDC #190, il 29 ottobre alle 14:00 UTC (le 15:00 in Italia).

Perché il fork di Hoodi è stato ritirato: che cosa si sa

La pull request, scritta da Barnabas Busa del team DevOps della Ethereum Foundation, non indica alcun motivo. Toglie l’orario di attivazione di Amsterdam dal file genesis e tutti i parametri Gloas e lo schedule del gas limit dalla configurazione di consenso, riportando i file allo stato precedente alla programmazione del fork. La modifica corrispondente di Lodestar, la pull request #10461, unita alle 16:15 UTC, riporta all’infinito l’epoch del fork Gloas su Hoodi e precisa che il fork è stato tolto dal calendario «nella call ACD di oggi». Besu ha unito la propria modifica, «Unschedule Amsterdam on Hoodi», alle 15:22 UTC; pull request simili per Prysm, Nimbus ed ethrex erano ancora aperte nel pomeriggio.

L’ordine del giorno della call, ACDE #248, si apriva con la sicurezza di Glamsterdam. Il 21 ottobre un ricercatore di sicurezza aveva riportato i risultati di un audit su due proposte del pacchetto che modificano il prezzo del gas, la EIP-8037 e la EIP-8038, chiedendo agli sviluppatori core di discuterne. Nessuno sviluppatore ha collegato pubblicamente quei risultati alla decisione, e alle 16:40 UTC il resoconto della call non era ancora stato pubblicato.

The Defiant ha riportato l’annullamento lo stesso giorno, scrivendo che agli operatori dei nodi viene chiesto di usare software senza il fork programmato, mentre l’attivazione sulla mainnet resta da decidere.

Il resto di questa pagina, pubblicata il 16 ottobre, è stato corretto nei punti in cui il rinvio cambia le cose.

L’upgrade Ethereum Glamsterdam doveva arrivare sull’ultima testnet pubblica lunedì 26 ottobre 2026 alle 17:42:48 UTC, cioè le 18:42 in Italia, quando Hoodi avrebbe fatto il fork all’epoch 132.352 (slot 4.235.264). Quel fork ora è rinviato, senza una nuova data. Su Hoodi i grandi operatori di staking, i custodi e i block builder tengono i loro ambienti di prova, quindi è questa la prova generale che decide quando potrà seguire la mainnet. La programmazione del fork era all’ordine del giorno della call All Core Devs Execution dell’8 ottobre (ACDE #247) e la configurazione era stata unita al repository della rete il giorno dopo.

Sepolia è passata per prima, il 6 ottobre, e il nostro articolo sull’attivazione su Sepolia spiega che cosa cambia con il pacchetto. Per la rete principale di Ethereum invece non c’è ancora nulla di deciso. Sul tavolo c’erano alcune date candidate a dicembre, tutte legate al buon esito di Hoodi, e ora sono incerte.

Il fork previsto su Hoodi: data, epoch e gas limit

Il fork era fissato al tempo UNIX 1793036568. Per chi legge dall’Italia sarebbero state le 18:42 di lunedì sera, ora solare: le lancette tornano indietro di un’ora nella notte tra il 24 e il 25 ottobre, quindi lo scarto con UTC sarà già di un’ora sola. Per riferimento, la stessa ora corrisponde alle 18:42 a Parigi, alle 17:42 a Dakar e ad Abidjan, alle 18:42 a Lagos e alle 19:42 a Nairobi. Nello stesso istante i client di esecuzione dovevano passare ad Amsterdam e quelli di consenso a Gloas, i due nomi che compongono Glamsterdam.

Barnabas Busa, del team DevOps della Ethereum Foundation, ha scritto il calendario nella pull request #31 del repository eth-clients/hoodi. La stessa modifica portava il gas limit dei blocchi a 200 milioni all’epoch del fork, con uno schedule ricopiato da quello di Sepolia; oggi i blocchi della mainnet sono limitati a circa 60 milioni. La release 26.10.1 di Teku, pubblicata il 15 ottobre, indica lo stesso momento: «È un aggiornamento obbligatorio per il fork Glamsterdam di Hoodi (epoch 132352, cioè 26 ottobre 2026 alle 17:42:48 UTC)», si legge nelle note di rilascio.

Due documenti ufficiali sono rimasti indietro. La Ethereum Foundation non ha pubblicato un annuncio dedicato a Hoodi (il suo post sulle testnet di Glamsterdam riguarda solo Sepolia) e la tabella delle attivazioni nella meta EIP-7773 al 16 ottobre aveva ancora vuota la riga di Hoodi. I numeri di questa pagina vengono quindi dalla configurazione della rete e dalle note di rilascio dei client.

Che cosa si prova su Hoodi: ePBS con staker e builder veri

Le 18 EIP di Glamsterdam sono passate in Last Call durante la call di testing ACDT #99, come riportato da Ethereal News il 9 ottobre: di fatto il perimetro dell’upgrade è congelato. Quella che ha più bisogno di Hoodi è la EIP-7732, la proposer-builder separation incorporata nel protocollo (ePBS), perché cambia la routine di ogni operatore di validatori.

Le note di Lodestar v1.50.0 spiegano bene che cosa succede al fork. Fee recipient e gas limit arriveranno dalle proposer preferences firmate. Il beacon node comincia a rifiutare, con un errore 410, le due chiamate che oggi i validator client usano per annunciarsi (prepare_beacon_proposer e register_validator). Le offerte dei builder arrivano dentro il protocollo, attraverso la rete peer-to-peer, e i builder esterni si configurano sul validator client invece che tramite relay collegati al beacon node. Beacon node e validator client vanno aggiornati insieme. Prysm 7.2.1 ha aggiunto flag lato validatore come --builder-urls e --builder-min-bid per lo stesso scopo.

È proprio la parte che il settore dello staking deve ancora dimostrare di saper gestire. «Dobbiamo ancora fare molti test con builder reali su Hoodi», ha scritto il 15 ottobre dgusakov, che interviene per conto di Lido, nel thread della call ACDC #189. Pooja Ranjan ha preparato una bozza di checklist sulla preparazione dell’ecosistema a Glamsterdam che parte dalla EIP-7732, dopo la richiesta di un’istituzione finanziaria che sta testando i nuovi compiti dei validatori.

Anche il resto del pacchetto avrebbe incontrato per la prima volta un carico di staking reale. Jochem Brouwer, preparando la call ACDT #100, ha messo in fila tre modifiche: la dimensione massima di un contratto passa da 24 a 64 KiB, il gas limit da 60 a 200 milioni e la lettura di un account da 2.600 a 3.000 gas. Messe insieme, ha scritto, portano a circa otto volte il numero massimo di byte che l’EVM può leggere in un blocco. Cambiano anche i costi del gas per i calldata e per la creazione di stato, e le note di Besu aggiungono che Amsterdam rifiuta qualsiasi transazione con un gas limit superiore a 2^32 − 1. I contratti che hanno quantità di gas scritte nel codice rischiano di rompersi.

I test continuano a far emergere bug. Geth v1.17.8, rilasciata l’8 ottobre, ha corretto diversi rischi di denial of service, la maggior parte dei quali poteva verificarsi solo con Amsterdam attivo, secondo le sue note di rilascio.

I client pronti per Hoodi al 16 ottobre

Ai team dei client era stato chiesto di pubblicare le release per Hoodi entro venerdì 16 ottobre, dieci giorni prima del fork, una scadenza ribadita nell’ordine del giorno della ACDT #100. Quando abbiamo controllato le pagine delle release su GitHub quel giorno alle 14:06 UTC, queste versioni programmavano esplicitamente il fork di Hoodi:

Altri sette client non avevano ancora una release per Hoodi. Le loro ultime versioni erano Geth v1.17.8 (8 ottobre), Nethermind 2.1.0 (1° ottobre), Reth v2.7.0 (28 settembre) ed Erigon v3.7.1 (2 ottobre) sul lato esecuzione, e Prysm v7.2.1 (5 ottobre), la pre-release Lighthouse v8.3.0-rc.0 (1° ottobre) e la pre-release Grandine 3.0.0-rc.0 (30 settembre) sul lato consenso. Le note di Lighthouse dicono ancora che il fork Gloas «non è ancora programmato su Hoodi né sulla mainnet».

Per Hoodi questa tabella non è più attuale. Dal 22 ottobre i team dei client stanno togliendo il fork dalla loro configurazione di Hoodi: Lodestar e Besu hanno unito la modifica quel giorno, e per Prysm, Nimbus ed ethrex c’erano pull request aperte. Chi gestisce un nodo dovrebbe leggere le prossime note di rilascio del proprio client, sia di esecuzione sia di consenso, e usare la versione indicata per Hoodi.

Che cosa devono fare operatori di nodi, staker e sviluppatori

Con il fork fuori dal calendario, le cose da fare cambiano:

• Chi gestisce un nodo Hoodi non ha più la scadenza del 26 ottobre. Segue le release dei client che tolgono il fork ed evita di lasciare in funzione una versione che lo attiverebbe da sola.
• Chi fa staking su Hoodi per ora mantiene le impostazioni attuali dei builder. La nuova configurazione ePBS descritta nelle note dei client conterà solo quando ci sarà una nuova data, e lo schedule del gas limit a 200 milioni è stato tolto insieme al fork.
• Builder e relay dovranno comunque testare su Hoodi le loro interfacce ePBS, il principale punto aperto prima della mainnet, quando il fork sarà riprogrammato.
• Chi sviluppa app e strumenti prova i contratti con i nuovi costi del gas, con il log ora emesso sui trasferimenti di ETH (EIP-7708) e con nuovi opcode come SLOTNUM. Hardhat v3.19.0 ha esteso il supporto sperimentale a Glamsterdam.

I fornitori di staking e i custodi europei che offrono staking nel quadro di MiCA, in Italia sotto la vigilanza di Consob e Banca d’Italia, perdono una data di test certa: la loro prova su Hoodi ora aspetta un nuovo calendario.

Chi possiede ETH non deve fare niente. Le monete di Hoodi non hanno valore e il fork della testnet lascia ogni saldo della mainnet esattamente dov’è. Se qualcuno vi chiede di collegare un wallet, firmare una transazione o inviare ETH «per Glamsterdam», è una truffa: la nostra guida per evitare le truffe crypto descrive i trucchi più comuni. Anche chi gestisce un nodo sulla mainnet, per ora, non ha nulla da installare.

Chi fa home staking farebbe bene a tenere d’occhio l’hardware. Brouwer sostiene che i 500 MB/s di lettura e scrittura sequenziale previsti dalle specifiche minime attuali (EIP-7870) sono troppo pochi per Glamsterdam, e ha proposto una nuova EIP di specifiche minime per ogni fork. È una proposta, non una decisione.

Data di Ethereum Glamsterdam sulla mainnet: dicembre ora è incerto

Il post della Foundation sulle testnet era chiaro: «Questo annuncio riguarda Sepolia; non programma un upgrade della mainnet». I primi numeri concreti sono arrivati il 15 ottobre, quando Busa ha scritto che, «assuming a sucessful hoodi fork» (in inglese, con il suo refuso), la mainnet dovrebbe puntare all’epoch 493.056, che cade il 1° dicembre 2026 alle 20:38:47 UTC (le 21:38 in Italia). L’alternativa è l’epoch 494.592, l’8 dicembre alle 16:29:11 UTC (le 17:29 in Italia). Lido ha risposto nello stesso pomeriggio chiedendo l’8 dicembre, per avere il tempo di testare i builder.

Entrambe le date erano solo proposte. L’ordine del giorno della ACDE #248 del 22 ottobre indicava come candidate l’1, l’8 o il 9 dicembre, con l’obiettivo di fissare la data nella call di consenso della settimana successiva «se Hoodi va liscio». Con il fork di Hoodi tolto dal calendario quella condizione non si è realizzata, e per la mainnet non è stata proposta alcuna nuova data. Glamsterdam è all’ordine del giorno della ACDC #190, il 29 ottobre alle 14:00 UTC (le 15:00 in Italia). Per la mainnet non è stato pubblicato alcuno schedule del gas limit.

Questa pagina verrà aggiornata quando saranno annunciati una nuova data per Hoodi o l’epoch della mainnet.

Che cosa non si sa ancora

Gli sviluppatori non hanno spiegato pubblicamente perché il fork di Hoodi è stato ritirato; alle 16:40 UTC il resoconto della ACDE #248 non era ancora stato pubblicato. Hoodi non ha una nuova data, e restano aperti l’epoch della mainnet, il gas limit della mainnet e la sorte della proposta sulle specifiche hardware. Nel frattempo gli sviluppatori hanno cominciato a definire il perimetro del fork successivo a Glamsterdam, Hegotá.