Layla Zulfa
Over 100 Ethereum core contributors recently converged above the Arctic Circle in Longyearbyen, Svalbard, for the Soldøgn Interop, a week-long, intensive gathering dedicated to advancing the Glamsterdam network upgrade. This focused summit, held under the perpetual daylight of the Arctic summer, proved exceptionally productive, culminating in critical alignments and significant technical progress aimed at substantially enhancing Ethereum’s scalability and efficiency. Among the most impactful outcomes were the agreement on a post-Glamsterdam gas limit floor of 200 million, the successful implementation of stable ePBS (enshrined Proposer/Builder Separation) with external builders, and the finalization of repricing numbers for EIP-8037.
Background: The Interop Model and Ethereum’s Evolution
The Soldøgn Interop represents a crucial recurring event in Ethereum’s decentralized development cycle, mirroring past successful gatherings like Amphora, Edelweiss, and Nyota. These interops bring together lead developers from various client teams—each building a different implementation of the Ethereum software—to collaborate in person. This multi-client approach is fundamental to Ethereum’s resilience, ensuring that no single point of failure can compromise the network. By working side-by-side, developers can rapidly identify and resolve cross-client compatibility issues, accelerate specification finalization, and collectively push forward the network’s evolution.
Ethereum, the world’s leading programmable blockchain, is in a continuous state of development, with major network upgrades (often referred to as "hard forks") introduced periodically to improve its performance, security, and functionality. These upgrades are complex undertakings, requiring meticulous coordination across numerous independent development teams globally. The Glamsterdam upgrade, the focus of the Soldøgn Interop, is poised to be one of the most significant, addressing core scaling challenges and laying groundwork for future advancements.
Svalbard, a Norwegian archipelago known for its unique geopolitical status, provided an unusually apt backdrop for this high-stakes technical collaboration. As one of the few places globally where individuals can live and work without a visa regardless of nationality, it embodies a spirit of open access and collaboration. Moreover, Svalbard is home to the Global Seed Vault and the Arctic World Archive, subterranean facilities safeguarding critical data for humanity’s distant future, including a snapshot of Ethereum’s own source code. The symbolic resonance of building the future of a global, decentralized network in a place dedicated to preserving humanity’s most vital assets was not lost on the attendees. The continuous daylight, or "midnight sun," from late April through August, also offered a tangible parallel to Ethereum’s intended 24/7 uptime, inspiring developers who often worked into the early hours.
Glamsterdam’s Core Advancements: A Leap in Scalability
The overarching goal for the Soldøgn Interop was to "harden Glamsterdam implementations and derive a target for a post-upgrade gas limit floor." The "gas limit" dictates the maximum amount of computational work that can be included in a single Ethereum block. Increasing this limit safely is paramount for enhancing transaction throughput and reducing network fees, but it presents a multi-dimensional challenge involving block construction, client performance under load, and managing state-creation costs.
Scaling Ethereum: The 200 Million Gas Limit Goal
The headline achievement of the Soldøgn Interop was the credible proposal of a 200 million post-Glamsterdam gas limit floor. This figure represents a monumental increase from the current Ethereum mainnet gas limit of approximately 30 million. Such an increase, once implemented, would dramatically expand the network’s capacity for processing transactions and executing smart contract operations. This enhanced throughput is crucial for supporting the burgeoning ecosystem of decentralized applications (dApps) and user growth. However, raising the gas limit is not merely a matter of changing a number; it requires fundamental architectural changes to ensure network stability and prevent unbounded state growth, which Glamsterdam addresses through several interconnected EIPs (Ethereum Improvement Proposals).
Enhanced Proposer/Builder Separation (ePBS)
A significant portion of the interop focused on advancing ePBS (enshrined Proposer/Builder Separation). ePBS is a critical consensus layer component of Glamsterdam, designed to refine the relationship between block proposers and block builders. By restructuring the block production process and introducing explicit deadlines for block construction, payload revelation, and attestations, ePBS grants more predictable time for execution. This architectural shift directly contributes to the headroom required to safely accommodate a higher gas limit.
The development process for ePBS during the interop was highly iterative. Initial attempts to launch a 4 Execution Layer (EL) x 4 Consensus Layer (CL) Glamsterdam devnet on Monday encountered enough issues to push stabilization to Tuesday. By mid-week, a 4×3 configuration achieved sufficient stability for stress testing, initiating a rigorous "ePBS hardening cycle" of stress, expose edge cases, fix, and repeat. A Tuesday-morning breakout session for the Builder API significantly simplified its specification, streamlining validator registration, bid/header/commitments flow, builder payment trust models, and circuit-breaker behavior. Cross-client edge cases, particularly around execution-request invalidation of beacon requests, were identified and resolved with a new test suite that revealed gaps across all client implementations. By Thursday, CL teams reported stable ePBS, with EL-side bid pathways resolving into Friday. Despite these successes, two contentious questions remain for All Core Developers (ACD): the necessity of a request signature committing to the receiving builder, and how to ensure resilience against P2P Sybil-based liveness attacks for a 1 ETH-staked-builder design. Ultimately, by Friday, nearly all clients were running together on glamsterdam-devnet-2, with the external builders pipeline thoroughly tested end-to-end.
Block-Level Access Lists (BAL) and Execution Layer Optimizations
Complementing ePBS on the execution layer, Block-Level Access Lists (BALs) and associated optimizations form another cornerstone of Glamsterdam’s scaling strategy. BALs, described in EIP-7928, provide clients with upfront information about a block’s read/write set. This crucial data enables parallel execution, batched I/O operations, and parallel state-root computation, all of which are vital for clients to comfortably handle larger blocks.
The BAL optimization track ran on its own dedicated devnets, preventing its benchmarking from being entangled with the consensus-layer stabilization of ePBS. Each optimization was placed behind its own feature flag, allowing for isolated performance measurement. The BAL benchmark dashboard and leaderboard were instrumental, highlighting worst-case scenarios across client implementations. This strategic focus on improving the slowest paths first ensured that the overall gas limit floor could be raised uniformly across the board, rather than being dictated by the performance of only the fastest clients.
Gas Repricing with EIP-8037: Managing State Growth
Integral to the safe increase of the gas limit are the execution layer gas repricings included in Glamsterdam, particularly EIP-8037: State Creation Gas Cost Increase. This EIP is designed to recalibrate gas costs to more accurately reflect resource usage at higher throughputs. Critically, it raises the price of writing new state, preventing a higher gas limit from translating into unbounded state growth, which could burden network participants with excessive data storage requirements.
The development path for EIP-8037 was a prime example of the interop’s iterative problem-solving power. Initially, the EIP-8037 specification included dynamic per-state-byte pricing tied to the block gas limit, which proved combinatorially complex for testing and benchmarking. Early in the week, teams agreed to simplify this by dropping dynamic pricing in favor of a fixed cost_per_state_byte, with future repricings to be handled at subsequent fork boundaries. The accounting model itself saw several iterations: moving state-gas accounting from mid-execution to end-of-call-frame, then addressing account creation costs, code deposit costs, and CREATE-transaction reverts. Reservoir refund/refill edge cases forced a rethink, leading to a reversion of accounting to the opcode level, recognizing the reservoir model as the primary complexity. By Friday, the specification had stabilized on bal-devnet-6, with the BAL track delivering the final repricing numbers. This rapid resolution of complex specification, implementation, testing, debugging, and design issues within days, rather than weeks of asynchronous communication, underscored the immense value of the interop format.
Broader Glamsterdam Scope and Hardening Efforts
Beyond the core triumvirate of ePBS, BALs, and EIP-8037, the Soldøgn Interop addressed numerous other facets of the Glamsterdam upgrade and ongoing network hardening. Consensus layer teams finalized decisions on several smaller Glamsterdam EIPs: EIP-8061 (exit/consolidation churn increase) was included in glamsterdam-devnet-1; EIP-8080 (exits via the consolidation queue) was declined; EIP-8045 (slashed-validator duty removal) was scoped down to proposer duties within the look-ahead window only; and EIP-7688 (SSZ stable containers) remains in Glamsterdam scope but was held out of glamsterdam-devnet-1 pending further work on bounded gossip-message size for attestations under progressive lists.
A significant discussion on EL/CL sync architecture led to the deferral of EIP-8237 from Glamsterdam, preserving optionality for a longer-term "top-up sync" architecture in a future fork. In its place, the group agreed to draft a new EIP that standardizes forkchoiceUpdated, newPayload, and getPayload sequencing, specifies a snap-sync initiation handshake, and tightens valid/invalid consistency across Engine API surfaces.
Network hardening was a pervasive theme throughout the week. A dedicated session explored 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 generated a rapid-fire stream of attack scenarios from attendees, showcasing the interactive and proactive approach to securing the network.
Looking Ahead: Hegotá and Ethereum’s Future Roadmap
The interop also provided a valuable forum for discussions extending beyond Glamsterdam, looking towards the subsequent Hegotá upgrade and even further into Ethereum’s future.
A proposal-agnostic session on native Account Abstraction explored the fundamental requirements and constraints for any future design. Key feature-set goals included alternative signature schemes, aggregation, batching, recovery mechanisms, gas sponsorship, flexible nonces, and keystore wallets. These ambitions were tempered by hard constraints around public-mempool compatibility, statelessness, and Layer 2 (L2) DoS resistance, ensuring practical and secure implementation.
The FOCIL (Fork Choice Improved Liveness) breakout focused on implementation updates, 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) and adopting an index-based bookmark approach for compatibility with frame transactions and EIP-7702.
Further out on the roadmap, a long-running ETH P2P track sketched a QUIC-based replacement for libp2p, aiming for privacy-by-default and slot-aware integration. A prototype for erasure-coded broadcast demonstrated impressive results, simulating approximately six times faster propagation than GossipSub for 2.4 MB payloads, promising significant improvements in network communication efficiency. The CL track also surfaced a strong sentiment towards eventually deprecating validator consolidations entirely, proposing a final fork that supports them before requiring an exit-then-redeposit process. This aims to address the long-term challenge of validator-set state growth.
Governance and Process Evolution
Beyond technical advancements, the Soldøgn Interop served as a crucial venue for refining Ethereum’s core development (ACD) process. Nixo and Ansgar, the two ACDE (All Core Developers – Execution) co-leads, facilitated a session to gather input from core contributors. Discussions revisited the "headliner construct," debated the utility of a "strawmap" for future forks, and formalized EIP SFI (Significance, Feasibility, Impact) criteria. The consensus was to retain headliners but introduce more flexibility, allowing for "theme + candidate EIP" as a viable pattern. The long-term year assignments in the strawmap were deemed overly canonicalized and will likely be softened. A new four-point SFI definition was put forward, empowering ACDT (All Core Developers – Testing) to signal readiness while ACDE and ACDC (All Core Developers – Consensus) retain the final call. A new prioritization-ordering process, to be produced after CFI (Call for Inclusion) decisions and reflected in the meta-EIP, will replace SFI’s traditional role in driving devnet inclusion, starting with Hegotá.
Several changes to ACD call coordination were also announced. Alex Stokes will take a three-month sabbatical, with Pari covering ACDC moderation in the interim, and Barnabas filling in for ACDT. The leadership structure now sees Nixo and Ansgar chairing ACDE, Pari as interim ACDC, and Mario, Barnabas, and Danceratopz rotating ACDT moderation.
The Interop Model: A Catalyst for Progress
The sheer volume and complexity of issues resolved during the Soldøgn Interop underscore the irreplaceable value of these in-person gatherings. Developers made tangible progress on a wide array of topics, from better test harnesses that compressed Hive feedback loops from hours to minutes, to engine-API plumbing improvements like gossip deduplication, batched calls, and light-client-driven head discovery, and critical tradeoffs around client diversity. The collaborative environment fostered by such events enables rapid iteration, cross-pollination of ideas, and accelerated decision-making, effectively compressing months of asynchronous progress into a single, intensely focused week. The comprehensive session notes from the Soldøgn Interop are publicly available at soldogn.xyz.
Next Steps and Outlook
With the Soldøgn Interop concluded, core contributors are now returning to their respective teams to transform the prototypes and agreed-upon specifications into production-ready code. The immediate future will see intensive work on hardening client implementations against the new specs, finalizing test coverage, and merging the draft PRs developed during the week. The final decisions regarding critical values such as the 200 million gas limit target and the definitive repricing numbers will be publicly deliberated and announced on upcoming AllCoreDevs calls, expected to be major topics in the coming weeks.
The Soldøgn Interop stands as a testament to the dedication and collaborative spirit of the Ethereum core development community. The successful advancements on Glamsterdam, coupled with a clear roadmap for Hegotá and beyond, reinforce Ethereum’s commitment to continuous innovation and scalability. The community extends its profound gratitude to all who traveled to 78°N, especially EthPandaOps for their organizational prowess and the Ethrex crew for their inaugural interop participation. The week’s intense work will be commemorated in a forthcoming documentary, capturing this pivotal moment in Ethereum’s ongoing evolution.
