Ethereum (ETH) ha provato in generale il suo prossimo maxi-upgrade il 6 ottobre. Al di fuori dei canali degli sviluppatori se ne sono accorti in pochi. Eppure, da quel momento, la testnet Sepolia gira con nuove regole su chi costruisce i blocchi, come viene prezzato il gas e quanta capacità di lavoro può contenere un singolo blocco.
Questo approfondimento scompone le 18 modifiche chiave di Glamsterdam – guidate dalla proposer-builder separation “incorporata” nel protocollo (ePBS), dalle access list a livello di blocco e da una nuova struttura di prezzi del gas – e ne analizza l’impatto su commissioni, MEV, rollup e sull’obiettivo di spingere il limite di gas fino a 200 milioni.
- Glamsterdam è attivo sulla testnet Sepolia di Ethereum dal 6 ottobre 2026; gli sviluppatori hanno fissato al 26 ottobre l’upgrade su Hoodi. Non esiste ancora una data concordata per il mainnet, anche se una proposta preliminare di calendario indica alcune finestre a inizio dicembre.
- L’aggiornamento porta il passaggio di mano tra proposer e builder dentro il protocollo, introduce access list a livello di blocco per il processamento in parallelo e ridetermina i prezzi con cui Ethereum addebita la creazione e la lettura di stato.
- Dopo Glamsterdam, gli sviluppatori hanno trovato un consenso su un “pavimento” per il gas limit di 200 milioni, oltre tre volte l’attuale default di 60 milioni; l’effetto sulle fee dipenderà però dalla domanda e dall’adozione da parte dei validatori.
Che cos’è l’upgrade Glamsterdam di Ethereum e perché conta
Glamsterdam è l’upgrade di rete successivo a Fusaka, e il suo nome unisce due componenti. La parte di execution layer si chiama Amsterdam, in omaggio alla città che ha ospitato Devconnect nel 2022, mentre la parte di consensus prende il nome di Gloas, da una stella.
La Ethereum Foundation ha pubblicato l’annuncio per la testnet il 28 settembre, programmando l’attivazione su Sepolia all’epoch 353.024, slot 11.296.768, alle 13:53:36 UTC del 6 ottobre.
Il fork è arrivato puntuale.
La ricercatrice indipendente di Ethereum Christine D. Kim ha segnalato il 9 ottobre che l’upgrade su Sepolia “è andato liscio”. Gli sviluppatori hanno quindi pianificato Glamsterdam per Hoodi, la seconda e ultima testnet pubblica, per lunedì 26 ottobre, con le release dei client attese per il 16 ottobre.
Il perimetro dell’upgrade è raccolto nella proposta di tracciamento EIP-7773, che coordina 18 cambiamenti core, supportati da cinque proposte di networking e due informative.
Sul mainnet, però, la situazione è diversa. La foundation ha chiarito che le date per Hoodi e soprattutto per il mainnet “non sono ancora state decise”, ed ethereum.org continua a indicare soltanto un obiettivo generico nel quarto trimestre 2026.
Una bozza di proposta di scheduling su GitHub mette sul tavolo l’1 dicembre, l’8 dicembre e il 9 dicembre come possibili date per il mainnet, ma la community di sviluppatori non ha ancora trovato un accordo.
Perché conta? Per anni, Ethereum ha spinto la gran parte del lavoro di scalabilità sui rollup, mantenendo il livello base estremamente prudente. Glamsterdam segna un cambiamento di impostazione visibile.
La foundation presenta l’upgrade come il passo successivo nel piano per scalare il Layer 1. Le sue funzioni di punta servono soprattutto a consentire alla chain principale di gestire in sicurezza molta più attività, allineando i prezzi del gas ai costi effettivi di esecuzione e di crescita dello stato.
Da leggere anche: Interfaccia intelligente di ChatGPT porta grafici e calcolatrici nelle risposte per 1,2 mld di utenti
In che cosa Glamsterdam è diverso da Pectra e Fusaka
Gli ultimi due upgrade di Ethereum erano concentrati soprattutto su staking e dati. Glamsterdam, invece, interviene sull’execution: la parte del sistema che esegue effettivamente le transazioni.
Pectra è entrato in funzione il 7 maggio 2025, all’epoch 364.032. Ha consentito ai wallet retail di delegare capacità a smart contract tramite l’EIP-7702, ha innalzato il saldo massimo per validatore da 32 a 2.048 Ether e ha portato l’obiettivo di blob a sei per blocco, con un massimo di nove.
Fusaka è stato attivato il 3 dicembre 2025 alle 21:49:11 UTC. Il suo elemento di punta è stato PeerDAS, EIP-7594, che consente ai nodi di verificare i blob di dati campionandone solo piccole porzioni invece di scaricarne l’intero contenuto.
Fusaka ha introdotto anche i cosiddetti “blob-parameter-only forks”, piccoli upgrade di configurazione che modificano la capacità in blob senza accorpare altre novità. Due di questi sono seguiti il 9 dicembre 2025 e il 7 gennaio 2026.
Nell’aggiornamento “January Checkpoint” la foundation ha scritto che Ethereum ora punta a 14 blob per blocco, con un massimo di 21, definendolo un aumento di 2,3 volte dello spazio dati per i Layer 2 rispetto al periodo pre-Fusaka.
Sul fronte execution, Fusaka ha fissato un tetto per singola transazione a circa 16,8 milioni di gas e impostato il gas limit di default per blocco, nei client software, a 60 milioni.
Glamsterdam ribalta le priorità. Invece di aumentare ancora lo spazio per i dati dei rollup, riscrive il modo in cui i blocchi vengono prodotti, validati e prezzati, per rendere possibile un aumento sostanziale di quel limite di 60 milioni.
Se Pectra e Fusaka hanno ampliato i “tubi” per i Layer 2, Glamsterdam interviene nella sala macchine del Layer 1.
Da leggere anche: TRON può davvero proteggere 95 mld $ di stablecoin da attacchi quantistici? Sun assicura che è pronto
Che cos’è la proposer-builder separation “incorporata”, o ePBS
Oggi, la maggior parte dei blocchi di Ethereum non è assemblata dai validatori che li propongono. Esistono builder specializzati che competono per costruire il blocco più redditizio; un validatore che utilizza il software MEV-Boost di Flashbots seleziona l’offerta economicamente più alta.
Questo passaggio si appoggia sui relay, che agiscono da intermediari fidati. Il relay trattiene il blocco del builder, mostra al proposer solo header e offerta economica e rilascia il contenuto completo una volta che il proposer ha firmato.
Il modello funziona, ma resta completamente fuori dal protocollo. Se un relay fallisce, si comporta in modo scorretto o censura il flusso, le regole di consenso di Ethereum non offrono meccanismi di tutela.
L’EIP-7732 porta lo scambio dentro Ethereum stesso. Riconosce i builder come partecipanti del protocollo e assegna ai validatori un nuovo compito, chiamato “payload timeliness attestations”.
Nel nuovo flusso, il proposer include nel beacon block l’impegno firmato del builder su un execution payload; il builder rivela il payload solo in un secondo momento. Il protocollo gestisce direttamente il pagamento al proposer, riducendo la dipendenza da middleware di fiducia.
Un sottoinsieme di validatori forma il “payload timeliness committee”: questi membri attestano se il builder ha rivelato il payload in tempo e se i dati blob associati erano disponibili.
La modifica separa in modo più netto la validazione di consenso da quella di execution, ed è qui che entra in gioco la scalabilità.
La roadmap su ethereum.org spiega che questa separazione amplia la finestra di tempo per la propagazione dei dati sulla rete da circa 2 secondi a circa 9 secondi. Più tempo significa che i validatori possono gestire in sicurezza payload molto più pesanti.
I relay non svaniranno dall’oggi al domani. La stessa pagina ricorda che builder e proposer potranno continuare a usare relay off-protocol o altri middleware per funzioni avanzate non ancora coperte dal core protocol.
Da leggere anche: Claude Mythos 5 è finito su siti governativi: Anthropic interrompe i test
Come Glamsterdam può cambiare la MEV e l’economia dei validatori di Ethereum
La maximum extractable value, o MEV, è il margine di profitto derivante dall’ordinamento, inclusione o esclusione delle transazioni. Tramite MEV-Boost, una parte consistente di questo valore affluisce ai validatori sotto forma di offerte dei builder, ma il mercato dietro tali offerte è altamente concentrato.
La dashboard Relayscan di Flashbots mostrava Titan responsabile del 52,6% dei blocchi MEV-Boost nelle 24 ore fino alla mattina del 12 ottobre. Quasar era al 18,5% e BuilderNet al 13,3%, lasciando tre builder a gestire complessivamente circa l’84% del flusso.
ePBS non elimina la MEV, né spezza automaticamente la concentrazione tra i builder. Cambia però il modello di fiducia: il pagamento al proposer non dipende più dal fatto che un relay mantenga o meno le proprie promesse.
Per gli staker, il beneficio si manifesta sul margine. Un validatore solo ottiene un canale, garantito dal protocollo, per “vendere” spazio nel blocco, mentre i builder sono tenuti a vincolare una quota di stake per partecipare al sistema.
Gli staker ottengono anche uscite più rapide. Con l’EIP-8061, la capacità di exit scala con l’ammontare totale di Ether in staking: secondo ethereum.org, ciò la quadruplica ai livelli attuali e raddoppia lo spazio per operazioni di consolidamento tra validatori.
Il rovescio della medaglia è una finestra di sicurezza più corta per i nodi che si disconnettono. Ethereum.org indica che il periodo di “weak subjectivity” – oltre il quale un nodo che torna online ha bisogno di un checkpoint recente e affidabile – si riduce da circa 15,7 giorni a circa 7 giorni.
Durante il Soldøgn interop a Svalbard, un meeting primaverile che ha riunito poco più di 100 core contributor, gli sviluppatori hanno messo in evidenza due nodi controversi di ePBS. Uno riguarda la difesa da attacchi Sybil su una rete peer‑to‑peer, in un design che richiede ai builder soltanto 1 ETH di stake.
La preoccupazione è riaffiorata alla vigilia di Sepolia. In una call di consenso del 17 settembre, lo sviluppatore di Prysm Potuz ha avvertito che il test Ether a costo zero permetterebbe a un attaccante di vincere le aste con builder usa‑e‑getta per poi trattenere i payload: «Posso avviare un migliaio di builder in un attimo».
I primi dati su Sepolia mostrano un mercato ancora poco profondo. In un riepilogo comunitario della call execution-layer dell’8 ottobre, EthPandaOps è citato nel riferire che solo quattro o cinque builder erano attivi, con gli operatori principali assenti e molti blocchi costruiti ancora localmente.
ePBS mostrerà il suo valore solo quando veri builder competitivi si contenderanno i blocchi: per questo Hoodi sarà il banco di prova decisivo.
Da leggere anche: iPhone Duo potrebbe salutare di persona gli utenti al primo avvio del pieghevole da 1.999 $
Che cosa sono le block-level access list e come migliorano l’elaborazione delle transazioni
Oggi i client Ethereum processano in larga parte le transazioni di un blocco in sequenza, una dopo l’altra. Non è possibile sapere in anticipo quali account o slot di storage verranno toccati da ciascuna transazione; eseguirne due in parallelo espone al rischio di collisioni.
L’EIP-7928 introduce le block-level access list, o BAL: strutture che registrano ogni account e slot di storage toccato da un blocco, insieme alle modifiche di stato apportate da ciascuna transazione. Le liste vengono costruite dai builder e il loro riferimento è incluso nell’header di blocco. Con quella mappa in mano, i client possono svolgere più attività in parallelo:
- Caricare dallo storage su disco tutto lo stato necessario in una sola passata, invece di scoprirlo passo dopo passo.
- Validare in parallelo, su core CPU distinti, le transazioni che non si sovrappongono sullo stesso stato.
- Calcolare in modo più efficiente la state root a fine blocco.
- Aggiornare lo stato usando i risultati registrati, senza dover riprodurre una per una tutte le transazioni, accelerando così la fase di sync.
Una modifica di rete complementare, la EIP-8159, consente ai nodi di scambiarsi queste liste tra loro. Un’altra, la EIP-8189, utilizza i dati BAL per riparare lo stato durante lo snap sync.
Al workshop Soldøgn, i team dei client hanno misurato le prestazioni di ciascuna ottimizzazione BAL dietro una propria feature flag. L’obiettivo era accelerare per prima cosa i colli di bottiglia più lenti di ogni client, perché migliorare l’implementazione più debole alza il gas limit sicuro per l’intero ecosistema.
BAL ed ePBS lavorano in coppia. ePBS concede più tempo di esecuzione all’interno di ogni slot, e i BAL permettono ai client di usare quel tempo in maniera decisamente più efficiente.
Da leggere anche: Bezos: l’IA potrebbe portarci alla settimana lavorativa di tre giorni dopo il taglio di 30.000 posti in Amazon
Come Cambieranno la Contabilità del Gas e i Costi di Esecuzione con Glamsterdam?
L’ultima revisione profonda dei prezzi del gas per le operazioni di stato risale all’hard fork Berlin del 2021. Da allora, lo stato di Ethereum è cresciuto in modo sostanziale e i recenti aumenti del gas limit hanno accelerato ulteriormente questa espansione.
Un post della Foundation rivolto agli sviluppatori di smart contract ha spiegato il 24 agosto che il nuovo schema di pricing supporta “all’incirca un incremento di 3x della capacità base”. La riprezzatura di queste operazioni, si legge, è un prerequisito per alzare ancora il gas limit.
Due EIP sostengono la parte principale della riforma. EIP-8037 aumenta e misura separatamente il costo di creazione di nuovo stato, mentre EIP-8038 alza il costo di lettura e scrittura dello stato attraverso operazioni come SLOAD, SSTORE e l’accesso a conti “freddi”.
EIP-8037 fissa un prezzo di 1.530 gas per ogni nuovo byte di stato, derivato da un obiettivo di crescita annua dello stato di 120 GiB con un gas limit di riferimento di 150 milioni.
A queste condizioni, un nuovo storage slot costa 97.920 unità di “state gas” contro le 20.000 attuali, e la creazione di un nuovo account passa a 183.600 unità rispetto alle 25.000 di oggi. Il deployment di un contratto alla dimensione massima di 24 KiB diventa circa otto volte più costoso.
Lo “state gas” ottiene anche un suo contatore dedicato. Il tetto per transazione introdotto con Fusaka si applica ora solo al gas di esecuzione, e un blocco viene considerato pieno sulla base della metrica — esecuzione o stato — che arriva per prima al proprio limite.
Il resto del pacchetto gas è più circoscritto, ma nell’insieme è significativo:
- EIP-7778 esclude i rimborsi di gas dal calcolo del block gas limit, pur continuando a riconoscere agli utenti i rimborsi su quanto pagato.
- EIP-7976 alza il costo minimo del calldata a 64 gas per byte per le transazioni con molto payload.
- EIP-7981 tariffa i dati delle access list allo stesso prezzo di 64 gas per byte.
- EIP-2780 ricostruisce il gas intrinseco delle transazioni sulla base del consumo reale di risorse, con un costo base di 12.000 gas.
- EIP-7954 aumenta la dimensione massima dei contratti da 24 KiB a 64 KiB.
L’attuale bozza di EIP-2780 mantiene un semplice trasferimento di Ether verso un account esistente a 21.000 gas, mentre un trasferimento che crea un nuovo account aggiunge 183.600 unità di state gas. La pagina di ethereum.org su Glamsterdam, aggiornata per l’ultima volta il 6 agosto, continua però a descrivere trasferimenti fino al 71% più economici.
I numeri non sono definitivi. Diverse proposte, tra cui EIP-2780 ed EIP-8037, restano in “Last Call” fino al 1° novembre, ed ethereum.org segnala che l’ambito degli interventi potrà ancora cambiare prima del lancio su mainnet.
Da leggere anche: Zcash punta a gennaio per rendere “quantum ready” il 70% di ZEC, ma manca una data
L’Aggiornamento Può Aumentare il Throughput di Layer 1 e Ridurre le Commissioni?
Il dividendo atteso è il throughput. A Soldøgn, gli sviluppatori si sono allineati su un “floor credibile di 200 milioni per il gas limit post-Glamsterdam”, circa 3,3 volte l’attuale default di 60 milioni.
Questo valore poggia su tre pilastri. ePBS estende la finestra temporale per l’esecuzione, le ottimizzazioni BAL liberano margine nei client e l’EIP-8037 impedisce che un gas limit più ampio produca una crescita incontrollata dello stato.
Sepolia gira già oggi con un gas limit a 200 milioni, programmato all’epoch di fork tramite EIP-8261, che trasforma il gas limit in un parametro fissato a livello di fork.
Il codice client per Hoodi pianifica lo stesso limite di 200 milioni. I riassunti delle call indicano che anche mainnet seguirà un approccio basato su fork epoch, ma per ora non è stato ancora annunciato ufficialmente né un valore né una data per mainnet.
Le fee scenderanno? Ethereum.org afferma che Glamsterdam “con ogni probabilità ridurrà le commissioni per l’utente medio”. Più spazio nei blocchi, a parità di domanda, tende a spingere i prezzi verso il basso, ma l’esito dipende da quanto nuovo traffico andrà a riempire quella capacità extra.
Le operazioni “state-heavy”, come la creazione di nuovi account o di nuovi storage slot, costeranno più gas: l’upgrade ridistribuisce i costi almeno quanto li riduce.
Da leggere anche: Kalshi sfida la NFL alla Corte Suprema: 1,8 miliardi di dollari in gioco in una sola domenica di football
Cosa Devono Preparare Wallet, Smart Contract, Infrastrutture e Validator?
Per i detentori retail, la risposta è: nulla. La Foundation chiarisce che gli utenti mainnet non devono fare alcuna azione, ed ethereum.org avverte che chiunque chieda di “aggiornare” i propri ETH sta con ogni probabilità tentando una truffa.
Per tutti gli altri, invece, c’è lavoro da fare, e la riprezzatura del gas è il capitolo più rilevante. La riproduzione delle transazioni storiche di mainnet ha evidenziato un gruppo ristretto di contratti che potrebbero rompersi o degradare, in genere perché basati su assunzioni hardcoded sul gas.
Secondo la Foundation, un semplice aumento del gas limit lato chiamante risolve la maggior parte dei casi individuati, e una larga maggioranza di smart contract resta completamente indifferente alla modifica.
La checklist, ricavata dalle indicazioni della Foundation e dei team client, è la seguente:
- Gli sviluppatori di smart contract dovrebbero verificare gli indirizzi con lo strumento Foundation per i contratti potenzialmente impattati e testare le correzioni sul testnet Platåberget, prestando particolare attenzione allo stipend fisso di 2.300 gas di Solidity, ai valori di gas hardcoded e alla logica che dipende dal gas rimanente.
- Wallet, provider RPC e tool per nodi devono aggiornare i moduli di gas estimation, perché i valori di gas “in cache” sottostimeranno i costi reali e causeranno transazioni in errore.
- Exchange, bridge e indexer possono sfruttare i nuovi log introdotti da EIP-7708, che fanno emettere un evento standard a ogni trasferimento o burn non nullo di Ether.
- Gli operatori di nodi devono aggiornare sia il client di esecuzione sia quello di consenso prima di ogni attivazione, e i validator devono aggiornare beacon node e validator client.
- Gli operatori di staking e i team dei builder dovrebbero studiare in anticipo i nuovi compiti e le nuove interfacce ePBS, inclusa la payload timeliness committee, prima di ogni fork.
I client di esecuzione già pronti per Sepolia includevano Geth 1.17.7, Nethermind 2.1.0, Besu 26.9.0, Erigon 3.7.1, Reth 2.7.0 e Ethrex 29.0.1. Sul fronte consenso, l’elenco comprendeva Lighthouse 8.3.0-rc.0, Prysm 7.2.1, Teku 26.9.1, Lodestar 1.49.0, Nimbus 26.10.0 e Grandine 3.0.0-rc.0.
Le impostazioni predefinite del gas limit mostrano quanto i dettagli possano pesare. La release 7.2.0 di Prysm e la release Sepolia di Teku lasciavano entrambi i validator fermi a 60 milioni dopo il fork, a meno che gli operatori non impostassero manualmente i 200 milioni.
Prysm ha integrato una correzione il 2 ottobre, così che i validator senza configurazione esplicita seguano automaticamente lo schedule dei 200 milioni di Sepolia; la Foundation ora indica Prysm 7.2.1 come versione raccomandata. I validator Teku che vogliono passare a 200 milioni devono ancora impostare il valore tramite flag di configurazione.
Da leggere anche: Catastrofe IA entro 12 mesi? OpenAI e Anthropic si preparano al possibile impatto
Come Cambia il Rapporto tra Ethereum Layer 1 e le Reti Layer 2 con Glamsterdam?
Glamsterdam non abbandona i rollup. La roadmap ufficiale inquadra l’upgrade come un passo avanti sia nell’obiettivo “Scale L1” sia in “Scale Blobs”.
Il legame è tecnico. Poiché ePBS amplia la finestra di propagazione dei blocchi, ethereum.org sostiene che Ethereum può veicolare in sicurezza molta più capacità dati, inclusi più blob per i rollup, senza mettere sotto stress la rete.
Glamsterdam in sé non fissa nuovi parametri per i blob. Dall’epoca di Fusaka, la capacità blob viene regolata tramite fork separati “blob-parameter-only”, così che la capacità dati per i rollup possa continuare a crescere su una propria traiettoria.
Gli sviluppatori, su questo fronte, non hanno fretta. Il “January Checkpoint” indicava che un terzo fork di questo tipo non è una priorità finché l’utilizzo di blob non avrà raggiunto i precedenti aumenti.
Due funzionalità più puntuali aiutano direttamente le soluzioni Layer 2. EIP-7997 introduce un contract factory deterministico allo stesso indirizzo su tutte le chain EVM partecipanti, così da consentire deployment di wallet e applicazioni agli stessi indirizzi su più reti.
La seconda, EIP-8070, aggiunge una sparse blobpool, una modifica di networking che cambia il modo in cui i nodi gestiscono le transazioni blob.
La tensione strategica però esiste. Un Layer 1 più economico e veloce rende più appetibile il deployment diretto su mainnet, mettendola implicitamente in concorrenza con i rollup che lì vanno a regolarsi.
La risposta di Ethereum, finora, è scalare entrambi i livelli in parallelo. La roadmap tratta capacità di esecuzione e capacità blob come due obiettivi distinti ma paralleli, e il disegno di Glamsterdam riflette questo doppio mandato, non una scelta aut-aut tra L1 e L2.
Per gli utenti dei rollup, l’effetto pratico è un livello di settlement sottostante più robusto e con minori assunzioni di fiducia.
Da leggere anche: ETF su XRP raccolgono 8 milioni di dollari in piena ondata di vendite sui fondi crypto guidata da Bitcoin
Cosa Viene Dopo Glamsterdam nella Roadmap di Scalabilità di Ethereum?
Il prossimo fork è Hegotá. Come Glamsterdam, il nome combina una città dell’execution layer, Bogotá, con una stella del consensus layer, Heze.
I protagonisti sono già stati scelti. Il cluster Protocol della Foundation ha indicato EIP-7805, le fork-choice enforced inclusion lists (FOCIL), per il livello di consenso, ed EIP-8141, le Frame Transactions, per il livello di esecuzione.
FOCIL era inizialmente candidata per Glamsterdam. Gli sviluppatori l’hanno spostata al fork successivo per contenere la portata complessiva dell’upgrade.Checkpoint di gennaio della foundation
FOCIL consente a più validatori di imporre ai builder l’inclusione di transazioni valide, affrontando direttamente il rischio di censura generato dalla concentrazione del mercato dei builder. Le Frame transactions rendono programmabili validazione e pagamento del gas, offrendo agli account un percorso nativo di uscita dalle attuali chiavi secp256k1.
La tier list di accompagnamento del cluster ha valutato 62 EIP proposte, basandosi su 397 giudizi di priorità espressi da un gruppo di circa 60 partecipanti. Due proposte sono state classificate come “must-ship”, 15 come “attese in shipping” e 28 sono state scartate.
La tabella di marcia è aggressiva. Il cluster ritiene che i team client possano realisticamente iniziare l’implementazione di Hegotá verso fine quarto trimestre 2026, e l’intera pianificazione presuppone che Glamsterdam venga rilasciato a dicembre: un’ipotesi di lavoro, non una data ufficialmente calendarizzata.
Oltre Hegotá, il cluster struttura le proprie attività intorno a cinque grandi filoni di ricerca, ciascuno su più fork:
- Fast finality, con l’obiettivo di ridurre il tempo di finalizzazione da minuti a secondi; la “decoupled consensus” è il candidato principale per il fork successivo a Hegotá.
- Sicurezza post-quantum, con un target autoimposto di arrivare a un Layer 1 quantum‑resistant – su esecuzione, consenso e dati – entro dicembre 2029.
- Privacy, a partire da Hegotá con il supporto a livello di protocollo per transazioni private trustless e resistenti alla censura direttamente su Layer 1.
- State, che comprende un nuovo trie, una crescita dello stato sostenibile e un accesso realmente decentralizzato allo stato corrente e storico.
- zkEVM, con il passaggio delle execution proofs da opzionali a obbligatorie, così che i validatori finiscano per verificare prove anziché rieseguire ogni singolo blocco.
Da leggere anche: Vendita Bitcoin di MARA non provata dopo che 81 milioni di dollari arrivano in un wallet Galaxy Digital
Conclusione: cosa significa Glamsterdam per Ethereum
Glamsterdam è meno una singola feature e più una riorganizzazione strutturale del layer di base di Ethereum. Porta il mercato dei builder dentro il protocollo, fornisce ai client una mappa per il lavoro in parallelo e rende più trasparente – e costoso – l’utilizzo di stato permanente.
Il lancio su Sepolia è filato liscio, ma i test più critici devono ancora arrivare. Potuz ha sottolineato che Hoodi ospita sia pool di staking sia home staker, rendendolo un fork molto più delicato rispetto a Sepolia.
Una proposta di scheduling dei core developer fissa il fork Hoodi all’epoch 132.352, corrispondente alle 17:42:48 UTC del 26 ottobre. Non esiste ancora una data per il mainnet, e la foundation ha chiarito che verrà diffuso un annuncio separato.
I nodi aperti sono tanto economici quanto tecnici. La reale partecipazione dei builder, l’adozione del gas limit più elevato da parte dei validatori e il grado in cui la domanda andrà effettivamente a riempire il nuovo spazio determineranno cosa Glamsterdam riuscirà davvero a consegnare.
Se il piano funzionerà, il layer di base di Ethereum scalerà secondo una propria logica interna, con i rollup che costruiranno sopra di esso invece di reggere da soli l’intero carico.
Prossimo articolo: Debutto Evernorth sul Nasdaq spostato al 12 ottobre: cosa cambia con il rinvio della fusione
