Longyearbyen, Svalbard – In a remarkable display of decentralized collaboration, over 100 Ethereum core contributors convened this past week above the Arctic Circle, in the remote Norwegian archipelago of Svalbard. Hosted in the northernmost settlement of Longyearbyen, this intensive gathering, dubbed the "Soldøgn Interop," served as a critical sprint for the upcoming "Glamsterdam" network upgrade, aiming to significantly enhance Ethereum’s scalability and efficiency. Against a backdrop of perpetual daylight, mirroring Ethereum’s own 24/7 uptime, developers worked tirelessly, delivering pivotal advancements that promise to reshape the network’s future.
The week culminated in three groundbreaking achievements: a consensus on a post-Glamsterdam gas limit floor of 200 million, the successful implementation of stable ePBS (enhanced Proposer-Builder Separation) running with external builders, and the finalization of repricing numbers for EIP-8037. These milestones are not merely technical tweaks; they represent a concerted leap towards a more robust, performant, and sustainable Ethereum. Beyond Glamsterdam, significant strides were also made on features slated for the subsequent "Hegotå" upgrade, including FOCIL (Fork Choice Improved Liveness) and native account abstraction, alongside a host of other critical discussions.
The Arctic Crucible: Why Svalbard?
The choice of Svalbard, a land of stark beauty and scientific significance, was no accident. This remote territory is one of the few places on Earth where individuals of any nationality can live and work without a visa, fostering an environment of open access that resonates deeply with Ethereum’s global, permissionless ethos. More profoundly, Svalbard is home to the Global Seed Vault and the Arctic World Archive – cold-storage facilities tunneled deep into the permafrost, safeguarding humanity’s most vital data, from crop seeds to historical manuscripts and, notably, a snapshot of Ethereum’s source code itself. This symbolic alignment with preserving crucial information for future generations underscored the long-term vision driving the core developers’ work.
Adding to the unique atmosphere, from late April through August, Svalbard experiences "Soldøgn" – the midnight sun, where the sun never sets. This continuous daylight became a powerful metaphor for Ethereum’s own unceasing operation, inspiring core developers to maximize their productivity throughout the week, working around the clock to push the network forward.
A Week of Intense Collaboration: The Soldøgn Interop Format
The Soldøgn Interop marked a return to a highly effective format previously employed in successful gatherings like Amphora, Edelweiss, and Nyota. Unlike last year’s Berlinterop, which may have explored broader themes, Soldøgn focused on a single-track week of concentrated, multi-client progress towards a specific upgrade – in this case, the crucial task of hardening Glamsterdam. This dedicated approach allowed teams from various client implementations to work in close proximity, rapidly identifying and resolving issues that would typically take weeks or months to address asynchronously. The compressed timeline fostered an environment of intense collaboration, turning potential months of asynchronous progress into just days.
Glamsterdam’s Core Pillars: Scaling Ethereum for the Future
The overarching goal of the Soldøgn Interop was unambiguous: to fortify Glamsterdam implementations and establish a definitive target for a post-upgrade gas limit floor. Raising the gas limit safely is a complex, multi-faceted challenge, directly impacting network capacity and transaction costs. Glamsterdam tackles this by addressing how blocks are constructed and proposed, optimizing client implementations under heavy load, and managing the scaling of state-creation costs in tandem with increased throughput.
By Friday, the core developers had achieved their objective, demonstrating a stable multi-client Glamsterdam devnet. This network incorporated the latest ePBS, repricing, and block access list specifications, underpinned by robust benchmarking data that firmly anchored the proposed 200M gas limit. This significant increase in block processing capacity holds immense implications for Ethereum’s ability to handle a greater volume of transactions, potentially leading to lower fees and faster confirmation times for users.
The Pursuit of Throughput: Raising the Gas Limit
For the uninitiated, the "gas limit" dictates the maximum amount of computational work (gas) that can be included in a single Ethereum block. A higher gas limit means more transactions and more complex operations can be processed per block, directly increasing the network’s throughput. However, simply increasing this limit without careful consideration can lead to network instability, increased node requirements, and potential centralization risks. Glamsterdam’s innovations in ePBS, Block-Level Access Lists (BAL), and EIP-8037 are designed to mitigate these risks, ensuring the network can scale safely and sustainably. The agreed-upon 200M gas limit floor represents a substantial increase over current levels, signaling a new era of expanded capacity for Ethereum.
Enhanced Proposer-Builder Separation (ePBS): Streamlining Block Production
A cornerstone of the Glamsterdam upgrade and a primary focus of Soldøgn was ePBS. This mechanism fundamentally restructures how blocks are constructed and proposed on Ethereum. In essence, ePBS separates the role of block proposer (the validator chosen to propose a block) from the role of block builder (entities that assemble the transactions into a block). This separation aims to reduce the power of proposers, enhance censorship resistance, and create a more efficient block production market.
During the interop, ePBS’s restructuring of slots – by adding explicit deadlines for block construction, payload reveal, and attestations – was thoroughly tested. This clear allocation of time for execution is crucial, as it directly increases the "headroom" available for raising the gas limit without compromising network stability.
The week began with ambitious goals: a 4 Execution Layer (EL) x 4 Consensus Layer (CL) Glamsterdam devnet by Monday evening. Initial attempts revealed critical issues, pushing the target to Tuesday, when a 4×3 configuration achieved sufficient stability for stress testing to commence. The remainder of the week evolved into an intensive ePBS hardening cycle: continuous stress testing, identification and resolution of edge cases, and iterative fixes. A Tuesday morning breakout session dedicated to the Builder API significantly simplified the specification around validator registration, the bid/header/commitments flow, the trust model for builder payments, and circuit-breaker behavior. Mid-week debugging efforts pinpointed cross-client inconsistencies, particularly concerning execution-request invalidation of beacon requests, which a new test suite exposed across all client implementations. By Thursday, CL teams reported stable ePBS, with EL-side bid pathways resolving into Friday.
While significant progress was made, two questions remain genuinely contentious among All Core Developers (ACD): whether a request signature should commit to the receiving builder, and how to design a 1 ETH-staked-builder model that is resilient against P2P Sybil-based liveness attacks. Despite these outstanding points, by Friday, nearly all clients were successfully running together on glamsterdam-devnet-2, with the external builders pipeline thoroughly tested end-to-end.
Block-Level Access Lists (BAL) & Execution Layer Optimizations
If ePBS is Glamsterdam’s consensus-layer scaling story, its execution layer counterpart is defined by two dominant pieces: gas repricings and Block-Level Access Lists (BAL, EIP-7928). BALs are designed to provide clients with crucial information about a block’s read/write set up front. This foresight enables advanced optimizations such as parallel execution, batched I/O operations, and parallel state-root computation – all vital factors in determining how large a block clients can comfortably process.
The Soldøgn BAL track operated on dedicated devnets, distinct from the Glamsterdam ePBS chains, ensuring that optimization benchmarks were not entangled with consensus-layer stabilization efforts. Each optimization was placed behind its own feature flag, allowing for isolated comparison and measurement. The BAL benchmark dashboard and its accompanying leaderboard proved invaluable, highlighting each client’s worst-case scenarios across the test suite. This data-driven approach allowed teams to strategically focus on improving the slowest paths first, effectively raising the gas limit floor for the entire network, not just for the fastest individual implementation.
Calibrating Costs: EIP-8037 and Gas Repricings
Glamsterdam also incorporates several Execution Layer (EL) gas repricings, meticulously calibrating transaction costs to better align with actual resource usage at higher throughputs. EIP-8037, a proposed increase in state-creation gas costs, lies at the heart of this effort. Its purpose is to raise the price of writing new state, thereby preventing a higher gas limit from translating into unbounded state growth – a critical safeguard for the long-term health and decentralization of the network.
Heading into Soldøgn, the EIP-8037 specification included dynamic per-state-byte pricing, tied to the block gas limit. This dynamic approach proved cumbersome for testing and benchmarking. Early in the week, teams agreed to simplify this by adopting a fixed cost_per_state_byte, with future repricings to be handled at subsequent fork boundaries rather than within a single fork.
The accounting model for EIP-8037 underwent a more iterative journey. A Monday breakout moved state-gas accounting from mid-execution to the end-of-call-frame. A Tuesday follow-up addressed account creation costs, code deposit costs, and CREATE-transaction reverts. By Wednesday, reservoir refund/refill edge cases forced a fundamental rethinking. The Thursday breakout ultimately reverted accounting to the opcode level, concluding that the primary complexity lay within the reservoir model itself. By Friday, the specification had stabilized on bal-devnet-6, with the BAL track delivering the final repricing numbers.
This rapid iteration and resolution of complex technical and design issues within days, rather than weeks of asynchronous communication, vividly underscores the immense value of interop events like Soldøgn. The three threads – ePBS, BAL optimizations, and EIP-8037 repricings – converged to enable the headline achievement of the week: a credible 200M post-Glamsterdam gas limit floor. This substantial increase is deemed possible because ePBS provides more time for execution within a slot, BAL optimizations offer clients the necessary throughput headroom, and EIP-8037 ensures that the higher gas limit does not lead to uncontrolled state growth.
Beyond the Core: Other Glamsterdam Enhancements
Beyond the core pillars of ePBS, BALs, and repricings, much of the remaining Glamsterdam scope was refined and hashed out during numerous breakout sessions throughout the week.
Consensus Layer EIPs
CL teams finalized decisions on several smaller Glamsterdam EIPs:
- EIP-8061 (exit/consolidation churn increase) was included in
glamsterdam-devnet-1, addressing validator set dynamics. - EIP-8080 (exits via the consolidation queue) was ultimately declined for inclusion, indicating a preference for alternative approaches to validator management.
- EIP-8045 (slashed-validator duty removal) was scoped down to proposer duties within the look-ahead window only, focusing on immediate security concerns.
- EIP-7688 (SSZ stable containers) remains within Glamsterdam’s scope but was held out of
glamsterdam-devnet-1while the team works through issues related to bounded gossip-message size for attestations under progressive lists.
Sync Architecture & Hardening
A Wednesday-morning EL/CL sync architecture breakout decided to defer EIP-8237 out of Glamsterdam. This decision was made to preserve optionality for a longer-term "top-up sync" architecture, which could be implemented in a future fork. In its place, the group agreed to draft a new EIP that standardizes forkchoiceUpdated / newPayload / getPayload sequencing, specifies a snap-sync initiation handshake, and tightens valid/invalid consistency between the engine API surfaces. These changes aim to improve the reliability and predictability of client synchronization.
Hardening the network against potential attacks and edge cases was a constant theme. A Thursday session delved into fork-choice compliance testing frameworks, the Diamond repository of reproducible CL edge-case scenarios, and buildoor, EthPandaOps’s external-builder testing tool. The live demo of buildoor during the session prompted a long stream of attack scenarios suggested by attendees on the spot, highlighting the collaborative and proactive approach to security.
Gazing Forward: The Road to Hegotå and Beyond
While Glamsterdam was the immediate focus, several breakout sessions looked towards the next major upgrade, "Hegotå," and even further into Ethereum’s roadmap.
Native Account Abstraction
A deliberately proposal-agnostic session on native Account Abstraction kicked off discussions for a highly anticipated feature. This session focused on outlining the fundamental requirements and constraints any future design must satisfy. Goals included support for alternative signature schemes, transaction aggregation, batching, account recovery mechanisms, gas sponsorship, flexible nonces, and keystore wallets. These ambitious feature-set goals were balanced against hard constraints such as public-mempool compatibility, statelessness, and robust Layer 2 (L2) denial-of-service (DoS) resistance, ensuring that future advancements maintain the network’s core principles.
FOCIL (Fork Choice Improved Liveness)
A Thursday FOCIL breakout provided updates on its implementation, with early prototypes already functional. Multi-client interop and a dedicated FOCIL devnet were identified as immediate next steps. Two notable design decisions emerged: disabling FOCIL during 2-epoch non-finality (mirroring proposer-boost circuit-breaker behavior for safety), and adopting an index-based bookmark approach to ensure compatibility with frame transactions and EIP-7702. FOCIL aims to improve the responsiveness and robustness of the network’s fork choice mechanism.
Network Innovations: ETH P2P and Validator Set Growth
Further out on the roadmap, a long-running ETH P2P track sketched a QUIC-based replacement for libp2p. This new peer-to-peer communication protocol aims for privacy-by-default and slot-aware integration, promising significant improvements in network efficiency and security. An erasure-coded broadcast prototype, also discussed, simulated approximately six times faster propagation than GossipSub on 2.4 MB payloads, indicating a massive potential boost in block propagation speed. The CL track also surfaced a strong sentiment towards eventually deprecating validator consolidations entirely – proposing a final fork that supports them, then enforcing an exit-then-redeposit mechanism afterwards. This long-term solution aims to provide a cleaner and more manageable answer to the challenge of validator-set state growth, ensuring the network remains lean and efficient.
Refining Governance: The ACD Process Evolution
On Wednesday afternoon, Nixo and Ansgar, the two All Core Developers Execution (ACDE) co-leads, facilitated a crucial session to gather input from core contributors regarding the ACD process itself. This session revisited the "headliner construct," debated the merits of a "strawmap" (a tentative roadmap), and formalized the EIP SFI (Specification Freeze & Implementation) criteria. The group broadly favored retaining headliners but advocated for loosening the rigid EIP-vs-theme structure, accepting "theme + candidate EIP" as a more flexible pattern. The per-fork year assignments in the strawmap past 2026 were flagged as overly canonicalized and likely to be softened, acknowledging the fluid nature of blockchain development.
A new four-point SFI definition was put forward, with All Core Developers Testing (ACDT) signaling readiness and ACDE/ACDC (All Core Developers Consensus) retaining the final call. A new prioritization-ordering process, to be produced after Call For Inclusion (CFI) decisions and reflected in the meta-EIP, will replace SFI’s old role in driving devnet inclusion, starting with Hegotå. These changes aim to streamline the decision-making and implementation process for future network upgrades.
Leadership Transitions
In related news regarding call coordination, Alex Stokes announced he would be taking a three-month sabbatical starting the following week. Pari will cover ACDC moderation in the interim, with Barnabas filling in for ACDT. This ensures continuity in leadership for these critical developer calls. The current leadership structure sees Nixo and Ansgar chairing ACDE, Pari as interim for ACDC, and Mario, Barnabas, and Danceratopz rotating ACDT moderation.
Synergistic Progress: The Unseen Benefits of Interop
Beyond the formal agenda items, the in-person nature of Soldøgn allowed teams to make significant progress on a myriad of other topics. This included developing better test harnesses, dramatically compressing Hive feedback loops from hours to minutes, improving engine-API plumbing (such as gossip deduplication, batched calls, and light-client-driven head discovery), and engaging in hard tradeoffs around client diversity. The sheer density of expertise and the ability to have real-time, face-to-face discussions facilitated resolutions and innovations that would be far more challenging in a distributed setting. The full compendium of session notes is publicly available at soldogn.xyz, offering a detailed look into the breadth of work accomplished.
Next Steps and Future Outlook
With the Soldøgn Interop now concluded, core developers will return home to translate the prototypes and agreements forged in Svalbard into production-ready code. The coming weeks will be characterized by intense focus on hardening client implementations against the new specifications, finalizing comprehensive test coverage, and merging the draft pull requests into the main codebase.
As always, the final decisions for critical values such as the 200M gas limit target and the definitive repricing numbers for EIP-8037 will be publicly announced and discussed during the upcoming AllCoreDevs calls, accessible via the Ethereum Protocol YouTube channel. These discussions are expected to be the major topics of the immediate future, providing the wider Ethereum community with definitive timelines and specifications for the Glamsterdam upgrade.
The success of the Soldøgn Interop stands as a testament to the dedication and collaborative spirit of the Ethereum core contributors. A special commendation goes to EthPandaOps for their organizational prowess, and to every individual who worked under the midnight sun, including the Ethrex crew, who marked their first interop experience. This incredibly productive week, a pivotal moment in Ethereum’s ongoing evolution, will also be commemorated in a full-length short film, capturing the unique journey of building the future of decentralized technology at the edge of the world.
