clet.xyz

Over one hundred of Ethereum’s core contributors recently gathered in the remote and stunning landscape of Longyearbyen, Svalbard, above the Arctic Circle, for the Soldøgn Interop. This intensive, week-long event was dedicated to the crucial task of solidifying the "Glamsterdam" network upgrade, a significant step in Ethereum’s ongoing evolution towards enhanced scalability and robustness. The Soldøgn Interop followed the successful "Berlinterop" event of the previous year, but reverted to the highly focused, single-track format that characterized previous milestone interop events like Amphora, Edelweiss, and Nyota. This approach prioritizes concentrated, multi-client collaboration on specific upgrade goals.

The primary objective of the Soldøgn Interop was to harden Glamsterdam implementations and establish a target for a post-upgrade gas limit floor. This endeavor is multifaceted, addressing critical questions about how blocks are constructed and proposed, the headroom available for client implementations under heavy load, and the scaling of state-creation costs in tandem with increased throughput. By the culmination of the week, the developers had achieved three central goals: alignment on a post-Glamsterdam gas limit floor of 200 million, the establishment of stable proposer-builder separation (ePBS) implementations operating with external builders, and the finalization of Ethereum Improvement Proposal (EIP) 8037 repricing numbers. Beyond these core achievements, substantial progress was also made on future features such as "Hegotá" components like FOCIL (Forward-Compatible Layer) and native account abstraction, alongside a broad spectrum of other technical discussions.

The Strategic Choice of Svalbard: A Nexus of Innovation and Preservation

The selection of Svalbard as the venue for Soldøgn was deliberate and symbolic. This remote archipelago in the Arctic Ocean is a unique geopolitical entity, recognized as one of the few places globally where individuals can reside and work without the need for a visa, irrespective of their nationality. This characteristic fostered an environment of open collaboration, drawing in developers from diverse backgrounds.

Furthermore, Svalbard is home to the Svalbard Global Seed Vault and the Arctic World Archive, both remarkable cold-storage facilities tunneled deep into the permafrost. These archives serve as humanity’s ultimate repository, safeguarding backups of vital crops, cultural artifacts, films, manuscripts, and crucially, source code, for potential future use millennia from now. Notably, a snapshot of Ethereum’s source code is already preserved within the Arctic World Archive, a testament to the network’s long-term vision and importance.

The timing of the event also coincided with Svalbard’s "midnight sun" period, from late April through August, where the sun never sets. This 24/7 daylight mirrored the continuous uptime and operational resilience that Ethereum strives to maintain, allowing the core developers to maximize their productive hours, working around the clock to advance the protocol.

Hardening Glamsterdam for Enhanced Scalability

The overarching goal of the Soldøgn Interop was to significantly enhance Ethereum’s scalability through the Glamsterdam upgrade. The challenge of safely increasing the gas limit is a complex, multi-dimensional problem that Glamsterdam is designed to address. This involves optimizing the block construction and proposal mechanisms, ensuring that client implementations have sufficient operational headroom even under peak load, and managing the cost implications of state creation as transaction throughput increases.

The tangible outcomes by the end of the week included a stable, multi-client Glamsterdam development network (devnet) running the latest ePBS, incorporating updated block access list specifications, and generating essential benchmarking data. This data forms the bedrock for proposing a credible and safe increase to the gas limit. A significant portion of the week was dedicated to intense coding sessions, often extending into the early hours of the morning, interspersed with focused breakout sessions to align on critical design decisions and to deliberate on the longer-term roadmap for Ethereum’s development.

Three key Ethereum Foundation (EF) teams provided essential infrastructure and support for the Soldøgn Interop. EthPandaOps deployed "ethIQ," a performance analysis tool, and a "panda" Message Coordination Protocol (MCP) server to facilitate agentic workflows for the development teams. The Protocol Support team established "soldogn.xyz" as the central repository for interop goals, schedules, and detailed meeting notes, serving as the single source of truth for the event. The EF Digital Studio team meticulously documented the week’s proceedings, with a full-length documentary expected to capture the essence of this pivotal interop event.

The Technical Pillars of Glamsterdam: ePBS, BALs, and Gas Repricings

The Glamsterdam upgrade rests on several foundational technical advancements, each addressed during the Soldøgn Interop:

ePBS: Streamlining Block Production and Execution

Proposer-Builder Separation (ePBS) represents a fundamental restructuring of how Ethereum blocks are produced. It introduces explicit deadlines for block construction, payload revelation, and attestations. This structured approach allocates dedicated time for execution, thereby creating more headroom for increasing the gas limit.

The week commenced with an ambitious target: a four-execution layer (EL) to four-consensus layer (CL) Glamsterdam devnet by Monday evening. The initial attempts revealed several challenges, pushing the target to Tuesday, when a 4×3 configuration achieved stability, allowing stress testing to commence. The remainder of the week was dedicated to an intensive ePBS hardening cycle: stress testing, identifying edge cases, implementing fixes, and repeating the process.

A significant breakthrough occurred during a Tuesday morning breakout session focused on the Builder API, which substantially simplified the specifications related to validator registration, the bid/header/commitments flow, the trust model for builder payments, and circuit-breaker mechanisms. Mid-week debugging efforts zeroed in on cross-client edge cases, particularly concerning the invalidation of beacon requests by execution requests. A newly developed test suite exposed discrepancies across all client implementations. By Thursday morning, CL teams reported stable ePBS operations, while EL-side bid pathways were still undergoing debugging, with resolutions achieved by Friday. Two contentious issues remain for the AllCoreDevs (ACD) process: whether a request signature should commit to the receiving builder, and how to ensure the resilience of a 1 ETH-staked builder design against peer-to-peer Sybil-based liveness attacks. Ultimately, by Friday, nearly all participating clients were operating on "glamsterdam-devnet-2" with the external builder pipeline tested end-to-end.

BAL Optimizations: Enhancing Execution Layer Efficiency

If ePBS represents the consensus layer’s contribution to Glamsterdam’s scaling efforts, the execution layer’s counterparts are gas repricings and Block-Level Access Lists (BALs). By providing clients with upfront information about a block’s read and write sets, BALs enable parallel execution, batched input/output operations, and parallel state-root computation. These advancements are critical in determining the maximum block size clients can comfortably handle.

The BAL track at Soldøgn operated on separate devnets, distinct from the Glamsterdam ePBS chains, ensuring that optimization benchmarks were not entangled with the stabilization of the consensus layer. Each optimization was managed behind its own feature flag, allowing for isolated comparative measurements. The "BAL benchmark dashboard" and leaderboard highlighted client performance under worst-case scenarios across the test suite. By prioritizing the improvement of the slowest execution paths, developers aimed to elevate the gas limit floor uniformly across all implementations, rather than merely optimizing for the fastest ones.

Gas Repricings: Calibrating Costs for Higher Throughput

Glamsterdam incorporates several execution layer gas repricings, designed to better align costs with resource utilization at higher transaction volumes. Central to these changes is EIP-8037, which increases the gas cost for state creation. This measure aims to prevent unbounded state growth that could otherwise accompany a higher gas limit.

Leading up to Soldøgn, the EIP-8037 specification featured dynamic per-state-byte pricing, directly tied to the block gas limit. This dynamic approach presented significant testing challenges, requiring a separate fuzz matrix for each gas limit band, and made benchmarking nearly intractable. Early in the week, the development teams agreed to transition from dynamic pricing to a fixed "cost_per_state_byte." Future repricing adjustments will be handled at future fork boundaries rather than within the current fork.

The accounting model itself underwent an iterative refinement process. An initial breakout session on Monday shifted state-gas accounting from mid-execution to the end of the call frame. A follow-up session on Tuesday addressed account creation costs, code deposit costs, and CREATE-transaction reverts. Wednesday revealed edge cases related to reservoir refunds and refills, necessitating a re-evaluation of the model. By Thursday, the accounting model reverted to an opcode level, with the realization that the primary complexity resided within the reservoir model itself, not the accounting computation. By Friday, the specification had stabilized on "bal-devnet-6," with the BAL track delivering the finalized repricing numbers. This iterative process underscores the critical role of interop weeks in resolving complex specification, implementation, testing, debugging, and design issues within hours, compressing weeks of asynchronous progress into daily advancements.

The convergence of these three threads—ePBS, BAL optimizations, and gas repricings—culminated in the week’s headline achievement: a credible target of a 200 million gas limit floor post-Glamsterdam. This substantial increase is made possible by ePBS structuring the slot to provide more time for execution, BAL optimizations offering clients the necessary throughput headroom within that structure, and EIP-8037 ensuring that the higher gas limit does not lead to uncontrolled state growth.

Addressing Other Glamsterdam Development Threads

Beyond the core advancements in ePBS, BALs, and gas repricings, the Soldøgn Interop also saw progress on a variety of other Glamsterdam-related EIPs and architectural considerations:

• Consensus Layer EIPs: CL teams finalized decisions on several smaller Glamsterdam EIPs. EIP-8061, which addresses an increase in exit/consolidation churn, was integrated into "glamsterdam-devnet-1." EIP-8080, concerning exits via the consolidation queue, was ultimately declined for inclusion in this upgrade. EIP-8045, focused on the removal of slashed validator duties, was scoped down to only affect proposer duties within the look-ahead window. EIP-7688, introducing SSZ stable containers, remains within Glamsterdam’s scope but was held out of "glamsterdam-devnet-1" to allow for further work on bounded gossip message sizes for attestations under progressive lists.

• Execution Layer/Consensus Layer Sync Architecture: A dedicated EL/CL sync architecture breakout session on Wednesday morning resulted in the decision to defer EIP-8237 from Glamsterdam. This decision preserves optionality for a more advanced "top-up sync" architecture in a future fork. In its place, the teams agreed to draft an EIP that standardizes the sequencing of forkchoiceUpdated, newPayload, and getPayload calls, specifies an initiation handshake for snap sync, and enhances consistency between the engine API surfaces for valid and invalid states.

• Hardening and Testing Frameworks: A persistent theme throughout the week was the hardening of the network. A Thursday session focused on fork-choice compliance testing frameworks, the "Diamond" repository of reproducible CL edge-case scenarios, and "buildoor," PandaOps’s external builder testing tool. The latter was demonstrated mid-session, showcasing its ability to simulate a long stream of attack scenarios suggested by attendees in real-time.

Looking Towards Hegotá and Future Forks

Several breakout sessions at Soldøgn cast their gaze towards "Hegotá" and subsequent network upgrades, exploring foundational elements for Ethereum’s future:

• Native Account Abstraction: A proposal-agnostic session dedicated to native account abstraction initiated discussions on the requirements and constraints for future designs. Key feature goals included alternative signature schemes, aggregation, batching, recovery mechanisms, gas sponsorship, flexible nonces, and keystore wallets. These were considered alongside critical hard constraints such as public mempool compatibility, statelessness, and Layer 2 Denial-of-Service (DoS) resistance.

• FOCIL Implementation: A Thursday breakout focused on FOCIL implementation updates. Early prototypes demonstrated functional capabilities, with multi-client interop and a dedicated FOCIL devnet identified as immediate next steps. Two significant design decisions were made: FOCIL will be disabled during two-epoch non-finality periods, mirroring the behavior of the proposer-boost circuit breaker, and an index-based bookmark approach will be adopted for compatibility with frame transactions and EIP-7702.

• Ethereum Peer-to-Peer Network Evolution: Further out on the roadmap, a dedicated ETH P2P track explored the potential for a QUIC-based replacement for libp2p. This envisioned protocol would feature privacy-by-default functionalities and slot-aware integration. Additionally, a prototype for erasure-coded broadcast demonstrated approximately six times faster propagation than GossipSub for 2.4 MB payloads. The CL track also surfaced a strong sentiment towards eventually deprecating consolidations entirely. The proposed approach involves declaring a final fork that supports them, followed by a forced exit and redeposit mechanism, seen as a cleaner long-term solution to validator-set state growth.

Refining the AllCoreDevs (ACD) Process

On Wednesday afternoon, Nixo and Ansgar, the co-leads of the AllCoreDevs Engineering (ACDE) working group, facilitated a session to gather input from core contributors regarding the ACD process. The discussion revisited the "headliner" construct for selecting hard fork features, debated the merits of maintaining a "strawmap" of proposed upgrades, and formalized the criteria for EIP Special Fork Inclusion (SFI). The consensus leaned towards retaining headliners but with a more flexible approach to the rigidity between EIPs and overarching themes, accepting a "theme plus candidate EIP" model. The per-fork year assignments in the straw map beyond 2026 were identified as overly canonicalized and likely to be softened. A new four-point SFI definition was proposed, signaling readiness from the AllCoreDevs Technical (ACDT) group, with ACDE and the AllCoreDevs Coordination (ACDC) group retaining the final decision-making authority. A new prioritization and ordering process, to be implemented after CFI (Consensus Fork Improvement) decisions and reflected in the meta-EIP, will replace the former role of SFI in driving devnet inclusion, commencing with the Hegotá upgrade.

In terms of call coordination, Alex Stokes announced a three-month sabbatical commencing the following week. Pari will assume interim ACDC moderation duties, and Barnabas will fill in for ACDT. The leadership structure for AllCoreDevs will therefore be: Nixo and Ansgar chair ACDE; Pari serves as interim ACDC moderator; and Mario, Barnabas, and Danceratopz will rotate ACDT moderation responsibilities.

Broader Progress and Future Outlook

Beyond the major development threads, the Soldøgn Interop provided invaluable in-person time for teams to advance numerous other areas. This included the development of improved test harnesses, significantly compressing Hive feedback loops from hours to minutes, and enhancements to engine API plumbing, such as gossip deduplication, batched calls, and light-client-driven head discovery. Teams also grappled with critical tradeoffs concerning client diversity and a multitude of other technical topics. Comprehensive session notes are publicly available on soldogn.xyz.

The immediate next steps involve developers returning to their respective teams to transition the prototypes developed during the interop week into production-ready code. The coming weeks will see intense focus on hardening client implementations against the new specifications, finalizing test coverage, and merging the draft pull requests from Soldøgn.

As is customary, final decisions on key values, such as the 200 million gas limit target and the precise repricing numbers, will be formally announced and shared publicly during AllCoreDevs calls. These critical decisions are expected to be the primary focus of upcoming discussions.

The success of the Soldøgn Interop is a testament to the dedication and collaborative spirit of the Ethereum core contributors who traveled to the remote Arctic location. Special recognition is due to EthPandaOps for their daily organizational efforts and to all those who worked diligently under the extended daylight hours to meet daily objectives, including the Ethrex crew, who participated in their first interop event. The week was exceptionally productive, and the anticipation for the forthcoming documentary promises a comprehensive record of this significant milestone in Ethereum’s ongoing journey toward a more scalable, secure, and decentralized future.