Il fork di Glamsterdam su Platåberget è previsto per il 20 agosto. L’obiettivo per l’attivazione sulla mainnet è slittato dalla prima metà del 2026 al quarto trimestre 2026; si tratta però di una data di pianificazione, non di una garanzia sull’attivazione definitiva.

Il percorso di test atteso è il seguente:

1. Attivazione di Glamsterdam su Platåberget.
2. Raccolta dei feedback e correzione dei problemi di compatibilità.
3. Lancio di un devnet non-finality.
4. Attivazione di Glamsterdam su Sepolia e Hoodi.
5. Arrivo sulla mainnet solo dopo la stabilizzazione delle reti di test.

Le modifiche che possono rompere gli strumenti esistenti

Il modello del gas cambia

Glamsterdam comprende un pacchetto coordinato di revisione dei prezzi del gas, con l’obiettivo di sostenere un limite minimo nell’ordine dei 200 milioni di gas. I software che si basano su un limite massimo fissato a priori potrebbero quindi smettere di funzionare correttamente. Tra questi rientrano wallet, indicizzatori e strumenti per la stima del gas.

Non sarà sufficiente modificare un singolo parametro. La EIP-8037 introduce infatti una dimensione separata di state gas per le operazioni che creano nuovo stato nella rete. Nel modello scomposto, un trasferimento verso un account già esistente può mantenere un costo di 21.000 unità di execution gas; un trasferimento verso un account inesistente richiede invece anche il pagamento del runtime state gas.

Gli sviluppatori dovrebbero quindi abbandonare due assunzioni:

• ogni trasferimento standard di ETH costa sempre esattamente 21.000 gas;
• le transazioni Ethereum possono essere descritte con un’unica dimensione universale del gas.

Wallet e servizi dovranno utilizzare stime consapevoli delle regole del protocollo e verificare sia i trasferimenti verso account esistenti sia quelli verso nuovi account su Platåberget. La Ethereum Foundation ha avvertito in modo esplicito che gli strumenti fondati su limiti del gas rigidi potrebbero rompersi.

ePBS modifica la costruzione dei blocchi

La separazione tra proponente e costruttore incorporata nel protocollo, o ePBS, è una delle principali novità di Glamsterdam ed è descritta dalla EIP-7732. La modifica ridefinisce il modo in cui responsabilità di costruzione e validazione dei blocchi vengono rappresentate nel protocollo.

Per questo motivo, i team che gestiscono nodi, builder, relay e validatori dovrebbero testare flussi completi di costruzione e validazione, non soltanto il semplice invio di transazioni.

Le liste di accesso a livello di blocco aggiungono nuove informazioni

Le block-level access lists, specificate dalla EIP-7928, forniscono ai client e agli strumenti infrastrutturali informazioni aggiuntive sugli accessi allo stato previsti nell’intero blocco. La novità richiederà verifiche sui software di esecuzione e sui sistemi che analizzano o modellano il contenuto dei blocchi.

Aumentano i limiti per contratti e initcode

Glamsterdam prevede inoltre limiti dimensionali più ampi:

• dimensione massima di un contratto distribuito: da 24 KiB a 64 KiB;
• dimensione massima dell’initcode: da 48 KiB a 128 KiB.

Gli strumenti per il deployment, i controlli sul bytecode, i framework di sviluppo e i sistemi di indicizzazione dovrebbero verificare questi nuovi confini invece di considerare permanenti i limiti attuali.

La checklist per chi sviluppa su Ethereum

Al di là del nome dell’aggiornamento, il punto concreto è preparare il software. I team che gestiscono applicazioni e infrastrutture Ethereum dovrebbero:

• rimuovere le ipotesi basate su un limite massimo del gas codificato in modo rigido;
• testare i trasferimenti di ETH verso account esistenti e inesistenti;
• gestire, dove necessario, la contabilità separata di execution gas e state gas;
• rivedere stimatori del gas, visualizzazioni delle commissioni e simulazioni delle transazioni;
• verificare i flussi di nodi, builder e validatori legati a ePBS;
• controllare parser di blocchi e indicizzatori con le block-level access lists;
• testare la gestione di contratti e initcode alle nuove dimensioni massime;
• ripetere i test quando Glamsterdam passerà al devnet non-finality, a Sepolia e a Hoodi.

Platåberget non è quindi soltanto un’anteprima. Il suo valore principale consiste nel far emergere i problemi a valle mentre esiste ancora il tempo per aggiornare il software destinato alla produzione.

Hegotá: 66 proposte, ma una sola funzione programmata

Hegotá è l’aggiornamento Ethereum previsto per il 2027, ma il suo contenuto non è ancora definitivo. Gli sviluppatori stanno esaminando 66 proposte; il processo di selezione prevede una lista proposed-for-inclusion attesa intorno al 27 agosto e le classifiche delle preferenze dei client entro il 10 settembre. Si tratta di tappe decisionali, non dell’impegno a includere tutte le 66 proposte.

È importante distinguere i diversi livelli di stato:

• Scheduled: formalmente programmata per l’inclusione;
• Considered: in esame attivo, ma non confermata;
• Candidate: parte della discussione più ampia e ancora in competizione per risorse di implementazione e test.

Al momento, FOCIL, cioè le Fork-Choice Enforced Inclusion Lists previste dalla EIP-7805, è l’unica funzione formalmente programmata per Hegotá. L’obiettivo è rafforzare la resistenza alla censura consentendo di far rispettare, attraverso il fork choice, liste designate di transazioni. In questo modo si limita la possibilità dei block builder di escludere transazioni idonee.

I principali candidati per Hegotá

Frame Transactions

Le Frame Transactions, definite dalla EIP-8141, sono ancora considerate una possibile inclusione e non una funzione confermata. La proposta introduce un formato di transazione in cui validità, pagamento del gas ed esecuzione possono essere gestiti attraverso una sequenza di frame e chiamate a contratti.

Questa struttura potrebbe offrire a livello di protocollo un percorso verso l’account abstraction e verso modalità più flessibili di pagamento delle transazioni.

I ricercatori Ethereum hanno inoltre discusso Frame Transactions insieme a proposte collegate come possibile base per funzionalità di privacy più native. Questo pacchetto più ampio, tuttavia, non è ancora una parte approvata di Hegotá.

Quick Slots

Ethlabs ha proposto Quick Slots, la EIP-8198, all’interno di una versione di Hegotá volutamente circoscritta e orientata a una produzione dei blocchi e a una finalità più rapide. La riduzione della durata degli slot resta però una proposta: non è ancora un parametro confermato dell’aggiornamento.

La crescita continua della Layer 1

Le raccomandazioni di Ethlabs includono anche il proseguimento del lavoro sulla capacità della Layer 1, insieme a resistenza alla censura, conferme più rapide e account abstraction nativa. Si tratta di priorità per la discussione, non di decisioni equivalenti a un’inclusione formale.

Gli aumenti del limite del gas, gli slot da otto secondi, la crittografia post-quantum e altre proposte relative a validatori, privacy e livello di esecuzione restano sotto esame e non fanno ancora parte del perimetro confermato di Hegotá.

La conclusione per i team Ethereum

Per gli sviluppatori, Glamsterdam è la scadenza tecnica immediata. Platåberget offre un ambiente pubblico per individuare i problemi causati dalla revisione dei costi del gas, dalla contabilità dello state gas, da ePBS, dalle liste di accesso e dai limiti dimensionali più ampi, prima del passaggio a Sepolia, Hoodi e infine alla mainnet.

Hegotá segue una logica diversa: è ancora un esercizio di priorità e progettazione. FOCIL è l’unica funzione attualmente fissata, mentre Frame Transactions, Quick Slots, il lavoro sulla scalabilità e le altre proposte dovranno superare le successive fasi di selezione, implementazione e test.

La distinzione è essenziale: Glamsterdam va trattata come un progetto di compatibilità già operativo; Hegotá come una roadmap in evoluzione, non come un elenco definitivo delle funzioni Ethereum del 2027.

Il fork di Glamsterdam su Platåberget è previsto per il 20 agosto. L’obiettivo per l’attivazione sulla mainnet è slittato dalla prima metà del 2026 al quarto trimestre 2026; si tratta però di una data di pianificazione, non di una garanzia sull’attivazione definitiva.

Il percorso di test atteso è il seguente:

1. Attivazione di Glamsterdam su Platåberget.
2. Raccolta dei feedback e correzione dei problemi di compatibilità.
3. Lancio di un devnet non-finality.
4. Attivazione di Glamsterdam su Sepolia e Hoodi.
5. Arrivo sulla mainnet solo dopo la stabilizzazione delle reti di test.

Le modifiche che possono rompere gli strumenti esistenti

Il modello del gas cambia

Glamsterdam comprende un pacchetto coordinato di revisione dei prezzi del gas, con l’obiettivo di sostenere un limite minimo nell’ordine dei 200 milioni di gas. I software che si basano su un limite massimo fissato a priori potrebbero quindi smettere di funzionare correttamente. Tra questi rientrano wallet, indicizzatori e strumenti per la stima del gas.

Non sarà sufficiente modificare un singolo parametro. La EIP-8037 introduce infatti una dimensione separata di state gas per le operazioni che creano nuovo stato nella rete. Nel modello scomposto, un trasferimento verso un account già esistente può mantenere un costo di 21.000 unità di execution gas; un trasferimento verso un account inesistente richiede invece anche il pagamento del runtime state gas.

Gli sviluppatori dovrebbero quindi abbandonare due assunzioni:

• ogni trasferimento standard di ETH costa sempre esattamente 21.000 gas;
• le transazioni Ethereum possono essere descritte con un’unica dimensione universale del gas.

Wallet e servizi dovranno utilizzare stime consapevoli delle regole del protocollo e verificare sia i trasferimenti verso account esistenti sia quelli verso nuovi account su Platåberget. La Ethereum Foundation ha avvertito in modo esplicito che gli strumenti fondati su limiti del gas rigidi potrebbero rompersi.

ePBS modifica la costruzione dei blocchi

La separazione tra proponente e costruttore incorporata nel protocollo, o ePBS, è una delle principali novità di Glamsterdam ed è descritta dalla EIP-7732. La modifica ridefinisce il modo in cui responsabilità di costruzione e validazione dei blocchi vengono rappresentate nel protocollo.

Per questo motivo, i team che gestiscono nodi, builder, relay e validatori dovrebbero testare flussi completi di costruzione e validazione, non soltanto il semplice invio di transazioni.

Le liste di accesso a livello di blocco aggiungono nuove informazioni

Le block-level access lists, specificate dalla EIP-7928, forniscono ai client e agli strumenti infrastrutturali informazioni aggiuntive sugli accessi allo stato previsti nell’intero blocco. La novità richiederà verifiche sui software di esecuzione e sui sistemi che analizzano o modellano il contenuto dei blocchi.

Aumentano i limiti per contratti e initcode

Glamsterdam prevede inoltre limiti dimensionali più ampi:

• dimensione massima di un contratto distribuito: da 24 KiB a 64 KiB;
• dimensione massima dell’initcode: da 48 KiB a 128 KiB.

Gli strumenti per il deployment, i controlli sul bytecode, i framework di sviluppo e i sistemi di indicizzazione dovrebbero verificare questi nuovi confini invece di considerare permanenti i limiti attuali.

La checklist per chi sviluppa su Ethereum

Al di là del nome dell’aggiornamento, il punto concreto è preparare il software. I team che gestiscono applicazioni e infrastrutture Ethereum dovrebbero:

• rimuovere le ipotesi basate su un limite massimo del gas codificato in modo rigido;
• testare i trasferimenti di ETH verso account esistenti e inesistenti;
• gestire, dove necessario, la contabilità separata di execution gas e state gas;
• rivedere stimatori del gas, visualizzazioni delle commissioni e simulazioni delle transazioni;
• verificare i flussi di nodi, builder e validatori legati a ePBS;
• controllare parser di blocchi e indicizzatori con le block-level access lists;
• testare la gestione di contratti e initcode alle nuove dimensioni massime;
• ripetere i test quando Glamsterdam passerà al devnet non-finality, a Sepolia e a Hoodi.

Platåberget non è quindi soltanto un’anteprima. Il suo valore principale consiste nel far emergere i problemi a valle mentre esiste ancora il tempo per aggiornare il software destinato alla produzione.

Hegotá: 66 proposte, ma una sola funzione programmata

Hegotá è l’aggiornamento Ethereum previsto per il 2027, ma il suo contenuto non è ancora definitivo. Gli sviluppatori stanno esaminando 66 proposte; il processo di selezione prevede una lista proposed-for-inclusion attesa intorno al 27 agosto e le classifiche delle preferenze dei client entro il 10 settembre. Si tratta di tappe decisionali, non dell’impegno a includere tutte le 66 proposte.

È importante distinguere i diversi livelli di stato:

• Scheduled: formalmente programmata per l’inclusione;
• Considered: in esame attivo, ma non confermata;
• Candidate: parte della discussione più ampia e ancora in competizione per risorse di implementazione e test.

Al momento, FOCIL, cioè le Fork-Choice Enforced Inclusion Lists previste dalla EIP-7805, è l’unica funzione formalmente programmata per Hegotá. L’obiettivo è rafforzare la resistenza alla censura consentendo di far rispettare, attraverso il fork choice, liste designate di transazioni. In questo modo si limita la possibilità dei block builder di escludere transazioni idonee.

I principali candidati per Hegotá

Frame Transactions

Le Frame Transactions, definite dalla EIP-8141, sono ancora considerate una possibile inclusione e non una funzione confermata. La proposta introduce un formato di transazione in cui validità, pagamento del gas ed esecuzione possono essere gestiti attraverso una sequenza di frame e chiamate a contratti.

Questa struttura potrebbe offrire a livello di protocollo un percorso verso l’account abstraction e verso modalità più flessibili di pagamento delle transazioni.

I ricercatori Ethereum hanno inoltre discusso Frame Transactions insieme a proposte collegate come possibile base per funzionalità di privacy più native. Questo pacchetto più ampio, tuttavia, non è ancora una parte approvata di Hegotá.

Quick Slots

Ethlabs ha proposto Quick Slots, la EIP-8198, all’interno di una versione di Hegotá volutamente circoscritta e orientata a una produzione dei blocchi e a una finalità più rapide. La riduzione della durata degli slot resta però una proposta: non è ancora un parametro confermato dell’aggiornamento.

La crescita continua della Layer 1

Le raccomandazioni di Ethlabs includono anche il proseguimento del lavoro sulla capacità della Layer 1, insieme a resistenza alla censura, conferme più rapide e account abstraction nativa. Si tratta di priorità per la discussione, non di decisioni equivalenti a un’inclusione formale.

Gli aumenti del limite del gas, gli slot da otto secondi, la crittografia post-quantum e altre proposte relative a validatori, privacy e livello di esecuzione restano sotto esame e non fanno ancora parte del perimetro confermato di Hegotá.

La conclusione per i team Ethereum

Per gli sviluppatori, Glamsterdam è la scadenza tecnica immediata. Platåberget offre un ambiente pubblico per individuare i problemi causati dalla revisione dei costi del gas, dalla contabilità dello state gas, da ePBS, dalle liste di accesso e dai limiti dimensionali più ampi, prima del passaggio a Sepolia, Hoodi e infine alla mainnet.

Hegotá segue una logica diversa: è ancora un esercizio di priorità e progettazione. FOCIL è l’unica funzione attualmente fissata, mentre Frame Transactions, Quick Slots, il lavoro sulla scalabilità e le altre proposte dovranno superare le successive fasi di selezione, implementazione e test.

La distinzione è essenziale: Glamsterdam va trattata come un progetto di compatibilità già operativo; Hegotá come una roadmap in evoluzione, non come un elenco definitivo delle funzioni Ethereum del 2027.