La scorsa settimana, poco più di 100 contributori principali di Ethereum si sono riuniti oltre il Circolo Polare Artico — a Longyearbyen, nelle Svalbard — per l'Interop Soldøgn: una settimana di intenso lavoro sull'aggiornamento della rete Glamsterdam.
Soldøgn ha seguito il Berlinterop dell'anno scorso, ma è tornato al formato utilizzato da Amphora 🏺, Edelweiss 🏔️ e Nyota ✨: una settimana a percorso unico di progressi mirati e multi-client verso un aggiornamento specifico — in questo caso, il consolidamento di Glamsterdam.
Entro venerdì, il gruppo aveva raggiunto i suoi tre obiettivi principali: allineamento su una soglia minima del limite di gas post-Glamsterdam di 200M, implementazioni ePBS stabili in esecuzione con costruttori esterni e numeri finali di riprezzamento dell'EIP-8037 bloccati. Sono stati compiuti progressi significativi anche sulle funzionalità di Hegotá come FOCIL e l'astrazione dell'account nativa, oltre a una serie di altri argomenti.
Perché le Svalbard?
Le Svalbard sono uno dei pochi posti sulla Terra in cui chiunque, indipendentemente dalla nazionalità, può vivere e lavorare senza visto. Ospitano anche il Global Seed Vault e l'Arctic World Archive, due strutture di conservazione a freddo scavate nel permafrost fuori Longyearbyen. Insieme conservano backup di colture, libri, film, manoscritti e codice sorgente di cui l'umanità potrebbe aver bisogno tra mille anni, incluso uno Snapshot del codice sorgente di Ethereum. Ultimo ma non meno importante, da fine aprile ad agosto, il sole non tramonta alle Svalbard. Hanno un tempo di attività 24/7, proprio come Ethereum, di cui gli sviluppatori principali hanno approfittato al massimo durante la settimana!
Consolidare Glamsterdam, Scalare Ethereum
L'obiettivo della settimana era consolidare le implementazioni di Glamsterdam e derivare un obiettivo per una soglia minima del limite di gas post-aggiornamento. Aumentare il limite di gas in modo sicuro è un problema multidimensionale e Glamsterdam ne affronta diversi: come i blocchi vengono costruiti e proposti, quanto margine hanno le implementazioni dei client sotto carico e come i costi di creazione dello stato scalano insieme alla capacità transazionale.
In pratica, ciò significava concludere la settimana con una devnet Glamsterdam multi-client stabile che eseguisse le ultime specifiche ePBS, di riprezzamento e delle liste di accesso ai blocchi, insieme ai dati di benchmark per ancorare una proposta credibile sul limite di gas.
La maggior parte del tempo è stata trascorsa a testa bassa a scrivere codice, spesso fino alle prime ore del mattino, intervallata da sessioni di gruppo per allinearsi sulle decisioni di progettazione e discutere gli elementi della roadmap a lungo termine.
Tre team della EF hanno fornito l'infrastruttura per la settimana: EthPandaOps ha rilasciato ethIQ e un server MCP panda per supportare i flussi di lavoro basati su agenti dei team; Protocol Support ha configurato soldogn.xyz come singola fonte di verità per gli obiettivi, il programma e le note dell'interop; e il team EF Digital Studio ha ripreso la settimana in video. Aspettatevi il primissimo documentario sull'interop 🔜!
ePBS
Oltre a fare chiarezza nella relazione proponente/costruttore, ePBS ristruttura gli slot aggiungendo scadenze per la costruzione del blocco, la rivelazione del payload e le attestazioni. Questo rende esplicito quanto tempo può essere allocato per l'esecuzione, aumentando il margine che abbiamo per alzare il limite di gas.
I team hanno iniziato la settimana puntando a una devnet Glamsterdam 4 EL × 4 CL entro lunedì sera. I primi tentativi hanno fatto emergere abbastanza problemi da spingere l'obiettivo a martedì, quando una configurazione 4×3 ha funzionato in modo sufficientemente stabile da consentire l'inizio degli stress test.
Da lì, il resto della settimana è stato un ciclo di consolidamento di ePBS: stress test, esposizione di casi limite, correzione, ripetizione. Una sessione di gruppo del martedì mattina sulle API del costruttore ha semplificato sostanzialmente le specifiche relative alla registrazione del validatore, al flusso di offerte/intestazioni/impegni, al modello di fiducia per i pagamenti del costruttore e al comportamento del circuit-breaker. Il debug di metà settimana si è concentrato sui casi limite cross-client — in particolare sull'invalidazione delle richieste della beacon chain da parte delle richieste di esecuzione, dove una nuova suite di test ha rivelato una lacuna in ogni implementazione dei client. Entro giovedì mattina, i team CL segnalavano un ePBS stabile mentre i percorsi delle offerte lato EL erano ancora in fase di debug; questi sono stati risolti tra giovedì e venerdì. Due questioni rimangono genuinamente controverse per l'ACD: se una firma di richiesta debba vincolare il costruttore ricevente e come mantenere un design con costruttore con 1 ETH in staking resiliente contro gli attacchi di liveness basati su Sybil P2P.
Entro venerdì, quasi tutti i client venivano eseguiti insieme su glamsterdam-devnet-2 con la pipeline dei costruttori esterni testata end-to-end!
Ottimizzazioni BAL
Se ePBS è il lato del livello di consenso della storia di scalabilità di Glamsterdam, la controparte del livello di esecuzione ha due elementi dominanti: i riprezzamenti del gas e le Liste di Accesso a Livello di Blocco (BAL). Fornendo in anticipo ai client informazioni sufficienti sul set di lettura/scrittura di un blocco, le BAL consentono l'esecuzione parallela, l'I/O in batching e il calcolo parallelo della radice dello stato, tutti fattori che determinano quanto grande possa essere un blocco che i client possono gestire comodamente.
Il percorso BAL di Soldøgn è stato eseguito sulle proprie devnet, separate dalle catene ePBS di Glamsterdam, in modo che i benchmark di ottimizzazione non fossero intrecciati con il lavoro di stabilizzazione del livello di consenso. Ogni ottimizzazione era protetta dal proprio feature flag, in modo che il lavoro di misurazione della settimana potesse confrontarle isolatamente piuttosto che come un singolo pacchetto. La dashboard dei benchmark BAL e la classifica hanno fatto emergere gli scenari peggiori di ciascun client in tutta la suite di test — concentrandosi prima sul miglioramento dei percorsi più lenti, i team hanno potuto innalzare la soglia minima del limite di gas su tutta la linea, non solo per l'implementazione più veloce.
Riprezzamenti del Gas
Glamsterdam include una serie di riprezzamenti del gas EL, calibrando i costi per adattarli meglio all'utilizzo delle risorse a una maggiore capacità transazionale. L'EIP-8037, l'aumento del costo del gas per la creazione dello stato, è al centro: aumenta il prezzo della scrittura di un nuovo stato in modo che un limite di gas più elevato non si traduca in una crescita illimitata dello stato.
All'inizio di Soldøgn, le specifiche 8037 prevedevano un prezzo dinamico per byte di stato legato al limite di gas del blocco, il che rendeva i test combinatoriamente dolorosi (una matrice di fuzz per fascia di limite di gas) e il benchmarking quasi intrattabile. I team hanno concordato all'inizio della settimana di abbandonare il prezzo dinamico in favore di un cost_per_state_byte fisso, con i futuri riprezzamenti gestiti ai confini dei fork piuttosto che all'interno di un fork.
Il modello di contabilità stesso ha seguito un percorso più iterativo. La sessione di lunedì ha spostato la contabilità del gas di stato da metà esecuzione a fine call-frame; un follow-up di martedì ha chiuso i costi di creazione dell'account, i costi di deposito del codice e i revert delle transazioni CREATE; mercoledì sono emersi casi limite di rimborso/ricarica del serbatoio (reservoir) che hanno costretto a un ripensamento. La sessione di giovedì ha riportato la contabilità a livello di codice operativo (opcode), avendo concluso che la vera complessità risiedeva nel modello del serbatoio, non nel calcolo contabile. Entro venerdì le specifiche si erano stabilizzate su bal-devnet-6, con il percorso BAL che ha fornito i numeri finali di riprezzamento.
L'intero arco narrativo evidenzia uno degli aspetti più importanti dell'interop: la capacità di risolvere problemi complessi di specifiche, implementazione, test, debug e progettazione in ore anziché in settimane. Al loro meglio, le settimane di interop possono comprimere un mese di progressi asincroni in ogni singolo giorno!
Entro venerdì, i tre filoni sono convergenti sul numero principale della settimana: una credibile soglia minima del limite di gas post-Glamsterdam di 200M. Questo aumento significativo è possibile perché ePBS struttura lo slot per dare più tempo all'esecuzione, le ottimizzazioni BAL danno ai client il margine di capacità transazionale sotto quella struttura e l'8037 assicura che il limite di gas più elevato non si traduca in una crescita incontrollata dello stato.
Altri Filoni di Glamsterdam
Oltre a ePBS, BAL e riprezzamenti, la maggior parte del restante ambito di Glamsterdam è stata definita durante le sessioni di gruppo.
I team CL hanno finalizzato le decisioni sugli EIP minori di Glamsterdam: l'EIP-8061 (aumento del tasso di uscita/consolidamento) è stato incluso in glamsterdam-devnet-1; l'EIP-8080 (uscite tramite la coda di consolidamento) è stato rifiutato per l'inclusione; l'EIP-8045 (rimozione dei doveri del validatore che ha subito slashing) è stato ridotto ai soli doveri del proponente all'interno della finestra di look-ahead; e l'EIP-7688 (contenitori stabili SSZ) rimane nell'ambito di Glamsterdam ma è tenuto fuori da glamsterdam-devnet-1 mentre il team lavora sulla dimensione limitata del messaggio di gossip per le attestazioni sotto liste progressive.
Una sessione di mercoledì mattina sull'architettura di sincronizzazione EL/CL ha rinviato l'EIP-8237 fuori da Glamsterdam a favore del mantenimento dell'opzionalità per un'architettura di "sincronizzazione top-up" a lungo termine in un fork futuro. Al suo posto, la sala ha concordato di redigere un EIP che normalizzi il sequenziamento di forkchoiceUpdated / newPayload / getPayload, specifichi un handshake di avvio della snap-sync e rafforzi la coerenza valido/invalido tra le superfici delle API del motore.
Il consolidamento è stato un tema costante della settimana. Una sessione di giovedì ha trattato i framework di test di conformità della fork-choice, il repository Diamond di scenari di casi limite CL riproducibili e buildoor, lo strumento di test per costruttori esterni di PandaOps, dimostrato a metà sessione su un lungo flusso di scenari di attacco suggeriti dai partecipanti sul momento.
Oltre Glamsterdam
Diverse sessioni di gruppo hanno guardato verso Hegotá e i fork successivi.
Una sessione deliberatamente agnostica rispetto alle proposte sull'astrazione dell'account nativa ha dato il via ai lavori, analizzando i requisiti e i vincoli che qualsiasi progetto futuro deve soddisfare. Obiettivi del set di funzionalità come schemi di firma alternativi, aggregazione, batching, recupero, sponsorizzazione del gas, nonce flessibili e portafogli keystore si sono affiancati a vincoli rigidi riguardanti la compatibilità con la mempool pubblica, l'assenza di stato e la resistenza ai DoS sui layer 2 (l2).
Una sessione di giovedì su FOCIL si è concentrata sugli aggiornamenti dell'implementazione: i primi prototipi erano già funzionanti, con l'interop multi-client e una devnet FOCIL dedicata come prossimi passi immediati. Sono state prese anche due importanti decisioni di progettazione: disabilitare FOCIL durante la non definitività di 2 epoche (rispecchiando il comportamento del circuit-breaker del proposer-boost) e adottare un approccio a segnalibro basato su indice per la compatibilità con le transazioni frame / EIP-7702.
Più a lungo termine, un percorso ETH P2P di lunga data ha abbozzato un sostituto basato su QUIC per libp2p con privacy predefinita e integrazione consapevole degli slot, insieme a un prototipo di trasmissione con codifica di cancellazione che ha simulato una propagazione circa 6 volte più veloce rispetto a GossipSub su payload da 2,4 MB. Il percorso CL ha anche fatto emergere un forte sentimento verso l'eventuale deprecazione completa dei consolidamenti — dichiarando un fork finale che li supporti, per poi forzare l'uscita e il successivo rideposito — come risposta a lungo termine più pulita alla crescita dello stato del set di validatori.
Processo ACD
Mercoledì pomeriggio, Nixo e Ansgar, i due co-responsabili dell'ACDE, hanno tenuto una sessione per raccogliere input dai contributori principali sul processo ACD. La sessione ha rivisitato il costrutto headliner, ha dibattuto i pro e i contro di avere una strawmap e ha formalizzato i criteri EIP SFI. La sala voleva in generale mantenere gli headliner ma allentare la rigidità EIP-vs-tema, accettando "tema + EIP candidato" come modello praticabile. Le assegnazioni annuali per fork della straw map oltre il 2026 sono state segnalate come eccessivamente canonizzate e probabilmente verranno ammorbidite. È stata avanzata una nuova definizione SFI in quattro punti, con l'ACDT che segnala la prontezza e l'ACDE/ACDC che mantengono la decisione finale. Un nuovo processo di ordinamento delle priorità — prodotto dopo le decisioni CFI e riflesso nel meta-EIP — sostituirà il vecchio ruolo dell'SFI di guidare l'inclusione nelle devnet, a partire da Hegotá.
Sul lato del coordinamento delle chiamate, Alex Stokes ha annunciato che si prenderà un anno sabbatico di tre mesi a partire dalla prossima settimana, con Pari che coprirà la moderazione dell'ACDC nel frattempo e Barnabas che lo sostituirà per l'ACDT. In sintesi: Nixo e Ansgar presiedono l'ACDE, Pari è ad interim sull'ACDC, e Mario, Barnabas e Danceratopz si alternano nella moderazione dell'ACDT.
Tutto il Resto
Oltre a tutto quanto sopra, i team hanno utilizzato il tempo in presenza per fare progressi su tutto, da migliori infrastrutture di test (comprimendo i cicli di feedback di Hive da ore a minuti), ai miglioramenti dell'infrastruttura delle API del motore (deduplicazione del gossip, chiamate in batching e scoperta della head guidata dai light client), fino ai difficili compromessi sulla diversità dei client e molti altri argomenti. L'elenco completo delle note delle sessioni è disponibile su soldogn.xyz.
Prossimi Passi
Da qui, i team tornano a casa per prendere ciò che è stato prototipato durante la settimana e renderlo pronto per la produzione. Aspettatevi che le prossime settimane siano dedicate a testa bassa al consolidamento delle implementazioni dei client rispetto alle nuove specifiche, alla finalizzazione della copertura dei test e alla trasformazione delle PR in bozza di Soldøgn in codice unito.
Come sempre, le decisioni finali per valori come l'obiettivo del limite di gas di 200M e i numeri finali di riprezzamento saranno prese e condivise pubblicamente nelle chiamate AllCoreDevs. Aspettatevi che questi siano gli argomenti principali della prossima settimana!
Grazie mille a tutti coloro che sono arrivati fino a 78°N e hanno reso questa settimana un successo! Un ringraziamento speciale a EthPandaOps per aver rimesso in riga il gruppo ogni giorno, e a tutti coloro che hanno lavorato sotto il sole di mezzanotte per assicurarsi di raggiungere i nostri obiettivi quotidiani — incluso il team Ethrex, che si è unito a noi per il loro primo interop. È stata una settimana incredibilmente produttiva e, per fortuna, avremo un intero cortometraggio per ricordarla ☀️