Soldøgn Interop: Ethereum Core Contributors Forge Path to Scalability in Arctic Circle

This past week, a select contingent of over 100 Ethereum core contributors convened in the remote and breathtaking landscape of Longyearbyen, Svalbard, nestled above the Arctic Circle, for the Soldøgn Interop. This intensive week-long gathering was dedicated to the critical task of advancing the network’s capabilities, with a primary focus on hardening the "Glamsterdam" network…

 Avatar

by

14 minutes

Read Time

This past week, a select contingent of over 100 Ethereum core contributors convened in the remote and breathtaking landscape of Longyearbyen, Svalbard, nestled above the Arctic Circle, for the Soldøgn Interop. This intensive week-long gathering was dedicated to the critical task of advancing the network’s capabilities, with a primary focus on hardening the "Glamsterdam" network upgrade and laying the groundwork for significant scalability improvements. The event, reminiscent of previous successful interop sessions like Berlinterop, Amphora, Edelweiss, and Nyota, adopted a singular, focused track, allowing developers to concentrate their collective efforts on achieving specific, ambitious goals.

The ambitious agenda at Soldøgn Interop culminated in the achievement of three pivotal objectives by the close of the week. Firstly, the contributors reached a crucial consensus on a post-Glamsterdam gas limit floor of 200 million. This represents a substantial increase from the current gas limit, signaling a significant step towards enhanced transaction throughput. Secondly, stable implementations of eligible Proposer-Builder Separation (ePBS) were successfully demonstrated, operating in conjunction with external builders, a vital component for optimizing block production. Lastly, the final repricing numbers for EIP-8037, a key proposal aimed at recalibrating gas costs for state creation, were definitively locked in. Beyond these core achievements, substantial progress was also made on other significant features, including advancements in Hegotá initiatives such as FOCIL (Forward-Compatibility Layer) and native account abstraction, alongside a broad spectrum of other critical development topics.

The Strategic Choice of Svalbard

The selection of Svalbard as the venue for this crucial development summit was far from arbitrary. This remote archipelago in the Arctic Ocean holds unique significance, serving as one of the few locations globally where individuals can reside and work without visa requirements, irrespective of their nationality. More profoundly, Svalbard is home to the Svalbard Global Seed Vault and the Arctic World Archive, two pioneering cold-storage facilities meticulously engineered into the permafrost. These institutions serve as humanity’s ultimate safeguard, housing invaluable backups of vital crops, literature, films, manuscripts, and crucially, source code that could be essential for future generations. Notably, a snapshot of Ethereum’s own source code is preserved within the Arctic World Archive, a testament to the project’s commitment to long-term data integrity. Furthermore, Svalbard experiences the phenomenon of the midnight sun from late April through August, where daylight persists for 24 hours. This perpetual uptime mirrors the operational philosophy of the Ethereum network itself, a characteristic that core developers keenly leveraged throughout the demanding week of collaborative work.

Soldøgn Interop Recap ☀️

Hardening Glamsterdam for Enhanced Scalability

The overarching objective of the Soldøgn Interop was to solidify the implementations of the Glamsterdam upgrade and establish a definitive target for the network’s gas limit following its deployment. The challenge of safely increasing the gas limit is a multifaceted one, requiring careful consideration of several interconnected elements. Glamsterdam directly addresses these challenges by refining how blocks are constructed and proposed, by expanding the operational headroom available to client implementations under sustained load, and by optimizing the scaling of state creation costs in tandem with projected increases in transaction throughput.

In practical terms, the week’s intensive efforts resulted in the establishment of a stable, multi-client Glamsterdam development network. This network was configured to run the latest iterations of ePBS, alongside finalized specifications for gas repricing and block access lists. Crucially, comprehensive benchmarking data was generated, providing a robust foundation for the proposal of a credible and sustainable gas limit increase. A significant portion of the developers’ time was dedicated to hands-on coding, often extending into the early hours of the morning. These intense coding sessions were interspersed with focused breakout discussions to facilitate alignment on design decisions and to explore longer-term strategic roadmap items.

The infrastructure underpinning this intensive collaboration was provided by three dedicated teams from the Ethereum Foundation (EF). EthPandaOps delivered ethIQ, a powerful analytics tool, and a dedicated Panda Message Communication Protocol (MCP) server to streamline agentic workflows. The Protocol Support team established soldogn.xyz as the centralized repository for interop goals, schedules, and detailed meeting notes, ensuring a single source of truth for all participants. Complementing these efforts, the EF Digital Studio team meticulously documented the week’s proceedings through film, promising the release of a comprehensive interop documentary that will offer an intimate look into the collaborative spirit and technical advancements achieved.

The Advancements in Eligible Proposer-Builder Separation (ePBS)

ePBS represents a fundamental restructuring of how Ethereum slots are managed, moving beyond the existing proposer-builder dynamic to introduce explicit deadlines for critical stages of block construction. These deadlines encompass block construction, payload reveal, and attestation finalization. By clearly delineating the time allocated for execution processes, ePBS significantly increases the potential headroom for raising the network’s gas limit.

Soldøgn Interop Recap ☀️

The week commenced with an ambitious target for a four-execution-layer (EL) and four-consensus-layer (CL) Glamsterdam development network to be operational by Monday evening. Initial attempts revealed a number of issues that necessitated a shift in this target to Tuesday, when a 4×3 configuration was achieved and demonstrated sufficient stability to commence rigorous stress testing.

The remainder of the week was characterized by a continuous cycle of ePBS hardening: stress testing, identifying edge cases, implementing fixes, and repeating the process. A dedicated breakout session on Tuesday morning significantly streamlined the Builder API specifications, clarifying validator registration procedures, the bid/header/commitments flow, the trust model for builder payments, and the implementation of circuit-breaker mechanisms. Mid-week debugging efforts focused intensely on cross-client edge cases, particularly concerning the invalidation of beacon requests by execution-layer requests. A newly developed test suite exposed a critical gap in the implementation across all client software. By Thursday morning, consensus layer teams reported stable ePBS operations, while the execution layer’s bid pathways were still undergoing debugging. These issues were largely resolved between Thursday and Friday. Two fundamental questions remain subjects of ongoing debate within the AllCoreDevs (ACD) community: whether a request signature should definitively 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. By Friday, the glamsterdam-devnet-2 was running stably across nearly all participating clients, with the external builder pipeline having undergone successful end-to-end testing.

Optimizing Block-Level Access Lists (BALs)

Complementing ePBS on the consensus layer, the execution layer’s scaling strategy hinges on two primary components: gas repricings and Block-Level Access Lists (BALs), as defined in EIP-7928. By providing clients with detailed upfront information about a block’s read and write sets, BALs facilitate parallel execution, batched I/O operations, and parallel state-root computation. These optimizations are fundamental to determining the maximum block size that client software can comfortably manage.

The BAL track at Soldøgn operated on separate development networks, distinct from the Glamsterdam ePBS chains. This separation ensured that optimization benchmarks were not influenced by the complexities of consensus layer stabilization. Each optimization was implemented behind its own feature flag, allowing for isolated measurement and comparison rather than a bundled approach. The BAL benchmark dashboard and leaderboard effectively highlighted the worst-case scenarios for each client across the test suite. By prioritizing the improvement of the slowest execution paths, the development teams were able to incrementally raise the gas limit floor across the board, benefiting all implementations rather than solely favoring the most performant ones.

Soldøgn Interop Recap ☀️

Strategic Gas Repricings for Sustainable Growth

The Glamsterdam upgrade incorporates a series of execution layer gas repricings, meticulously calibrated to better align with the resource demands of increased transaction throughput. Central to this effort is EIP-8037, which significantly increases the gas cost associated with creating new state. This measure is designed to prevent a higher gas limit from leading to unbounded state growth.

Prior to the Soldøgn Interop, the EIP-8037 specification featured dynamic per-state-byte pricing, which was intrinsically linked to the block gas limit. This dynamic pricing model presented significant challenges for testing, requiring a complex fuzz matrix for each gas limit band, and made benchmarking an exceptionally difficult task. Early in the week, the development teams reached a consensus to abandon dynamic pricing in favor of a fixed cost_per_state_byte. Future repricing adjustments will be implemented at fork boundaries rather than dynamically within a fork.

The accounting model itself underwent a more iterative refinement process. An initial breakout session on Monday shifted state-gas accounting from the mid-execution stage to the end of the call frame. A subsequent session on Tuesday addressed account creation costs, code deposit costs, and the handling of CREATE transaction reverts. Mid-week, edge cases related to reservoir refunds and refills necessitated a re-evaluation of the model. By Thursday, the accounting model was reverted to the opcode level, with the realization that the primary complexity resided within the reservoir model rather than the accounting computations themselves. By Friday, the specification had stabilized on bal-devnet-6, with the BAL track delivering the final, definitive repricing numbers. This entire process exemplifies the critical role of interop events in resolving complex specification, implementation, testing, debugging, and design issues with remarkable efficiency, compressing weeks of asynchronous progress into mere days.

The convergence of these three critical threads – ePBS, BAL optimizations, and gas repricings – culminated in the week’s headline achievement: the establishment of a credible 200 million gas limit floor for the post-Glamsterdam era. This substantial increase in network capacity is made possible by the synergistic effects of ePBS structuring the slot to afford execution more time, BAL optimizations providing clients with the necessary throughput headroom within that structure, and EIP-8037 ensuring that the elevated gas limit does not result in unsustainable state growth.

Soldøgn Interop Recap ☀️

Beyond Glamsterdam: Charting Future Innovations

Beyond the core focus on ePBS, BALs, and gas repricings, a significant portion of the remaining Glamsterdam scope was thoroughly debated and refined across numerous breakout sessions.

Consensus layer teams finalized key decisions regarding several smaller Glamsterdam EIPs. EIP-8061, which addresses an increase in exit/consolidation churn, was successfully integrated into glamsterdam-devnet-1. EIP-8080, proposing exits via the consolidation queue, was ultimately declined for inclusion in this upgrade. EIP-8045, concerning the removal of slashed validator duties, was scoped down to apply only to proposer duties within the look-ahead window. EIP-7688, focused on SSZ stable containers, remains within the Glamsterdam scope but has been held out of glamsterdam-devnet-1 while teams address the complexities of bounded gossip message sizes for attestations under progressive lists.

A crucial architecture breakout session on Wednesday morning, involving both execution layer (EL) and consensus layer (CL) teams, led to the decision to defer EIP-8237 out of the Glamsterdam upgrade. This decision prioritizes retaining optionality for a more robust, longer-term "top-up sync" architecture in a subsequent fork. In its place, the participants agreed to draft a new EIP that will standardize the sequencing of forkchoiceUpdated, newPayload, and getPayload calls. It will also define a snap-sync initiation handshake and establish greater consistency in valid/invalid states between the engine API surfaces.

Hardening and robustness remained a pervasive theme throughout the week. A dedicated session on Thursday explored frameworks for fork-choice compliance testing. The Diamond repository, a collection of reproducible CL edge-case scenarios, and buildoor, PandaOps’s external builder testing tool, were demonstrated, prompting a stream of attack scenarios suggested by attendees in real-time.

Soldøgn Interop Recap ☀️

Looking Towards Hegotá and Beyond

Several breakout sessions were dedicated to forward-looking discussions on Hegotá and subsequent network upgrades. A deliberately proposal-agnostic session on native Account Abstraction initiated these discussions, meticulously working through the fundamental requirements and constraints that any future design must satisfy. The session identified feature-set goals such as alternative signature schemes, aggregation, batching, recovery mechanisms, gas sponsorship, flexible nonces, and keystore wallet functionalities, alongside critical hard constraints including public mempool compatibility, statelessness, and Layer 2 Denial-of-Service (DoS) resistance.

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

Further down the roadmap, a long-running Ethereum peer-to-peer (P2P) track outlined the potential for a QUIC-based replacement for libp2p, designed with privacy-by-default features and slot-aware integration. This track also explored a prototype for erasure-coded broadcasts, which simulated approximately six times faster propagation than GossipSub on 2.4 MB payloads. The CL track also surfaced a strong consensus toward the eventual deprecation of consolidations entirely. This approach envisions declaring a final fork that supports consolidations, followed by a mandatory exit-then-redeposit mechanism, as a cleaner long-term solution to validator set state growth.

Refining the AllCoreDevs Process

On Wednesday afternoon, Nixo and Ansgar, the co-leads for AllCoreDevs (ACD), facilitated a session to gather input from core contributors regarding the ACD process. The discussion revisited the established "headliner" construct, deliberated on the advantages and disadvantages of maintaining a strawmap, and formalized the criteria for EIP Special Fork Inclusion (SFI). The general sentiment favored retaining headliners but with increased flexibility regarding the rigidity between specific EIPs and broader themes, accepting a "theme plus candidate EIP" as a viable development pattern. The strawmap’s per-fork year assignments extending beyond 2026 were identified as potentially over-canonicalized and likely to be softened. A new four-point SFI definition was proposed, with the AllCoreDevs Directing Team (ACDT) signaling readiness and the AllCoreDevs Executive (ACDE) and AllCoreDevs Coordinating Committee (ACDC) retaining final decision-making authority. A new prioritization and ordering process, to be implemented after Community Fork Inclusion (CFI) decisions and reflected in a meta-EIP, will supersede SFI’s previous role in driving devnet inclusion, commencing with the Hegotá upgrade.

Soldøgn Interop Recap ☀️

Regarding call coordination, Alex Stokes announced a three-month sabbatical commencing the following week. Pari will assume interim ACDC moderation duties during this period, while Barnabas will step in for ACDT. The current leadership structure is as follows: Nixo and Ansgar chair ACDE, Pari serves as interim on ACDC, and Mario, Barnabas, and Danceratopz will rotate ACDT moderation responsibilities.

Addressing Miscellaneous Development Threads

In addition to the core initiatives, teams leveraged the in-person gathering to make progress on a diverse array of topics. This included the development of improved test harnesses, significantly compressing Hive feedback loops from hours to mere minutes. Advancements were also made in engine API plumbing improvements, such as gossip deduplication, batched calls, and light-client-driven head discovery. Furthermore, critical trade-offs were addressed regarding client diversity, alongside numerous other technical subjects. A comprehensive record of all session notes is publicly available at soldogn.xyz.

The Road Ahead: From Interop to Implementation

Following the highly productive Soldøgn Interop, the participating teams will now return to their respective workstreams to transition the prototypes developed during the week into production-ready code. The coming weeks are expected to be characterized by intensive efforts focused on hardening client implementations against the newly established specifications, finalizing comprehensive test coverage, and formally merging the draft pull requests generated at Soldøgn into the main codebase.

As is standard practice within the Ethereum development ecosystem, final decisions regarding critical parameters, such as the 200 million gas limit target and the definitive repricing numbers, will be publicly announced and ratified during the AllCoreDevs calls. These discussions are anticipated to be the central focus of upcoming weekly meetings.

Soldøgn Interop Recap ☀️

The success of this intensive week in Longyearbyen is a testament to the dedication and collaborative spirit of all involved. Special commendation is due to EthPandaOps for their daily organizational efforts and to every individual who worked tirelessly under the perpetual daylight of the Arctic summer to ensure daily goals were met, including the Ethrex crew, who participated in their first interop event. The week proved exceptionally productive, and the forthcoming documentary promises a valuable record of these significant advancements.

About the Author

About the Author

Easy WordPress Websites Builder: Versatile Demos for Blogs, News, eCommerce and More – One-Click Import, No Coding! 1000+ Ready-made Templates for Stunning Newspaper, Magazine, Blog, and Publishing Websites.

BlockSpare — News, Magazine and Blog Addons for (Gutenberg) Block Editor

Search the Archives

Access over the years of investigative journalism and breaking reports