Layla Zulfa
The dynamic landscape of Ethereum’s core development continues its rapid evolution, as evidenced by recent milestones and strategic planning discussions from the All Core Developer (ACD) calls. These critical gatherings, summarized periodically in the "Checkpoint" series, provide essential high-level updates on the network’s progress, typically every 4-8 weeks. The latest report highlights the successful deployment of the Fusaka upgrade, significant strides in the development of the upcoming Glamsterdam hard fork, and the initial scoping phases for the subsequent Hegotá upgrade, signaling a relentless pursuit of scalability, security, and decentralization.
For those keen to delve deeper into the intricate workings of Ethereum’s development, Forkcast now offers comprehensive resources, including call summaries, chat logs, and transcripts for each All Core Dev (ACD) call and various breakout sessions. These materials are typically made available within hours of the calls, offering unparalleled transparency into the decision-making processes that shape the future of the world’s leading smart contract platform.
Fusaka: A Leap in Data Availability and Scaling
The period since the last "Checkpoint" update has been marked by the successful activation of the Fusaka upgrade, a pivotal moment in Ethereum’s journey toward enhanced scalability. Fusaka introduced Data Availability Sampling (DAS), a groundbreaking technology aimed at increasing the network’s capacity to process and store data efficiently and securely. This advancement is a cornerstone of Ethereum’s "Surge" phase, designed to dramatically improve throughput and reduce transaction costs for users, particularly those interacting with Layer 2 scaling solutions.
Data Availability Sampling, often discussed alongside its implementation as PeerDAS (Proto-Danksharding with Data Availability Sampling), represents a significant architectural shift. Prior to DAS, every node on the Ethereum network was required to download and verify all transaction data, a process that becomes increasingly burdensome as network usage grows. With DAS, nodes can instead verify only a small, randomly selected portion of the data, relying on cryptographic proofs to ensure that the entire data set is indeed available on the network. This innovative approach allows for a substantial increase in data throughput without compromising decentralization or security, as the collective sampling by numerous nodes ensures robust data integrity.
The importance of Fusaka and PeerDAS was underscored by official communications from the Ethereum Foundation and prominent figures like co-founder Vitalik Buterin. Through various channels, including social media platforms, they articulated the technical nuances of PeerDAS, emphasizing why secure scaling is paramount for Ethereum’s long-term viability. These explanations positioned Fusaka as a crucial component within Ethereum’s broader roadmap, highlighting its role in enabling a future where the network can support a global scale of decentralized applications and transactions. The community’s reaction has been largely positive, recognizing Fusaka as a tangible step towards fulfilling the network’s ambitious scaling vision.
Flexible Scaling with Blob Parameter Only (BPO) Forks
In a testament to Ethereum’s evolving agility, Blob Parameter Only (BPO) forks have transitioned from conceptual discussions to operational reality. This innovative mechanism allows the Ethereum network to adjust the number of "blobs" per block independently of full-scale hard fork cycles. Blobs are data packets specifically designed to store off-chain data for Layer 2 rollups, making them a critical component for scaling by providing cheaper and more abundant data space.
The ability to implement BPO forks offers unprecedented flexibility, enabling the network to dynamically respond to the growing demand for Layer 2 data space without enduring the extensive development and testing timelines associated with comprehensive network upgrades. This newfound nimbleness ensures that Ethereum can scale its data availability as needed, directly benefiting Layer 2 solutions by providing them with increased capacity and potentially lower operational costs.
The first two BPO forks were successfully stress-tested and integrated into the Fusaka upgrade itself. Following Fusaka’s activation, the first independent BPO fork went live within days, with a second following in early January. These successful deployments have dramatically increased Ethereum’s Layer 2 data space. The network now targets 14 blobs per block and permits a maximum of 21, representing a substantial 2.3x increase in available data space for Layer 2 transactions compared to the pre-Fusaka era. This expansion is vital for supporting the growing ecosystem of rollups like Arbitrum, Optimism, zkSync, and StarkNet, which rely on Ethereum for data availability and finality.
While the infrastructure for a third BPO fork is in place, core developers have indicated that further increases are not an immediate priority. The current focus is on observing and evaluating the utilization of the recently expanded blob capacity. This strategic pause allows the ecosystem to adapt to the new parameters and ensures that future scaling adjustments are data-driven and responsive to actual network demand. This iterative approach underscores the cautious yet progressive methodology adopted by Ethereum’s core development teams.
Looking Ahead: Glamsterdam’s Ambitious Features
With Fusaka successfully deployed, attention now shifts to the next major network upgrade, Glamsterdam. This upcoming hard fork is fully scoped, with active development underway on its two primary features: enshrined Proposer Builder Separation (ePBS) and Block-level Access Lists (BALs). Glamsterdam is poised to significantly enhance both the security and efficiency of the Ethereum network, albeit through features of varying complexity.
Enshrined Proposer Builder Separation (ePBS) is arguably the more complex of the two headliners. ePBS aims to mitigate the risks associated with Maximal Extractable Value (MEV) by separating the roles of block production (proposer) and block content creation (builder). In the current system, a single validator proposes and builds a block, giving them significant control over transaction ordering and inclusion, which can lead to MEV extraction practices that potentially harm users and centralize power. ePBS introduces a mechanism where builders bid for the right to construct a block, and the proposer then selects the highest-bidding block without necessarily knowing its contents beforehand. This separation aims to democratize access to MEV, reduce its negative externalities, and enhance censorship resistance, thereby strengthening the network’s decentralization. Given its profound architectural implications, ePBS requires extensive research, design, and testing, making its development a substantial undertaking.
Block-level Access Lists (BALs), while also a significant feature, presents a comparatively lower implementation complexity than ePBS. BALs are designed to improve the predictability and efficiency of transaction execution by allowing transactions to specify the state addresses and storage keys they intend to access. This pre-declaration helps validators optimize block processing, potentially reducing gas costs and improving network throughput by enabling more efficient parallel execution and state access. The development of BALs is progressing well, with dedicated devnets already established to test and refine the implementation.
The disparity in complexity between ePBS and BALs means that while BALs are already undergoing rigorous testing on dedicated devnets, a similar testing environment for ePBS will require more time to mature. Core developers are meticulously working through the intricacies of ePBS, ensuring that its implementation is robust and secure before it can be integrated into a devnet for broader testing.
The Road to Glamsterdam: Development and EIP Management
The journey to Glamsterdam involves a meticulous process of EIP (Ethereum Improvement Proposal) selection and integration. As with any major network upgrade, the core headliners (ePBS and BALs) must first achieve a stable state on devnets before additional features can be considered. This structured approach is crucial for managing the inherent risks and complexities of upgrading a global, decentralized network.
Initially, developers faced the daunting task of sifting through an extensive list of approximately 50 proposed non-headlining features for Glamsterdam. This volume underscored both the vibrancy of the Ethereum developer community and the challenges inherent in coordinating such a diverse array of proposals. Through a rigorous evaluation process, this list was eventually distilled to a more manageable set of 17 "Considered" features. These selected EIPs are deemed necessary and high-impact, offering substantial benefits to the network without unduly increasing the complexity or delaying the overall fork timeline.
The strategy involves incrementally adding these "Considered" features to devnets in small batches. This allows client and testing teams to thoroughly evaluate each EIP’s impact, identify potential conflicts, and ensure seamless integration. If any feature proves problematic or threatens to introduce excessive delays, developers reserve the right to remove it from the "Considered" set for Glamsterdam, prioritizing the stability and timely delivery of the core upgrade. The full list of these "Considered" features is publicly available on the Ethereum Improvement Proposals repository, providing transparency into the ongoing selection process.
A more precise timeline for Glamsterdam is anticipated once the first ePBS devnet achieves a stable state. Further clarity will emerge as each "Considered" EIP successfully undergoes testing in these development environments. This phased approach reflects the prudent engineering principles guiding Ethereum’s development, ensuring that each component is thoroughly vetted before mainnet deployment.
Pivoting to Hegotá: Next-Generation Upgrades
Even as Glamsterdam progresses, the Ethereum community is already laying the groundwork for the subsequent network upgrade, tentatively named Hegotá. The naming convention for Ethereum upgrades often combines a star name (following an alphabetical sequence) with a city name, reflecting the global and collaborative nature of its development. The original H-star name, "Heka," was replaced with "Heze" after a community developer highlighted that "Heka" was not listed in the International Astronomers Union catalog, which previous star names have adhered to. Thus, the fork name became Heze + Bogotá = Hegotá.
Fork-choice Inclusion Lists (FOCIL) stands out as a strong candidate for Hegotá’s primary feature. FOCIL, a mechanism designed to enhance censorship resistance, was initially considered for Glamsterdam but was strategically moved to Hegotá to streamline the Glamsterdam fork scope. Its robust support among core developers and the broader Ethereum community underscores its perceived importance for the network’s long-term health and integrity. FOCIL is a cross-layer EIP, meaning it impacts both the consensus layer (responsible for block finality) and the execution layer (responsible for transaction processing), particularly interacting with the Engine API. This cross-layer nature adds to its complexity, making it challenging to pair with another equally complex feature without risking significant delays. FOCIL aims to ensure that even if block builders attempt to censor specific transactions, validators can still force their inclusion in blocks, thereby bolstering the network’s neutrality.
As of this update, FOCIL is undergoing evaluation alongside other headliner proposals for Hegotá. There is at least one competing proposal currently under discussion, highlighting the competitive process for feature inclusion in major upgrades. An overview of FOCIL and its readiness for Hegotá is available on the Ethereum Magicians forum, a key platform for technical discussions and EIP proposals.
Hegotá Timeline and Community Engagement
The process for selecting Hegotá’s headlining features is currently in full swing, emphasizing community participation.
- January 8th – February 4th: This designated period allows anyone to propose a headlining feature for Hegotá. Proposals must follow a specific template available on the Ethereum Magicians forum and are championed through the process by a technical point-of-contact.
- February 5th – February 26th: Following the proposal deadline, these headliner proposals will be presented and discussed during ACD calls. Community feedback will be actively solicited during this period, allowing for broad input on the network’s future direction. The goal is to finalize the selection of Hegotá’s headlining features by February 26th.
- 30 days following headliner decision (deadline TBD): Once the main features are decided, a window will open for proposals of minor (non-headlining) EIPs. Like headliner proposals, anyone can submit these, provided they are committed to championing their EIP through the development process.
This structured timeline ensures a fair and transparent process for incorporating community-driven innovations into the Ethereum protocol.
Beyond FOCIL, discussions around other potential headliners for Hegotá include "encrypted mempools" (to further combat MEV) and "6-second slots" (EIP-7782). The latter, which would reduce the time between blocks, could significantly improve transaction finality and user experience. However, it remains unclear whether 6-second slots will be formally proposed for Hegotá or deferred to a later upgrade like I-star, given its potential impact on network stability and the complexity of its implementation.
The rigorous process for getting a feature into Ethereum, often guided by the principles laid out in EIP-1 and the 2026 guide to championing an EIP, highlights the commitment to thoughtful and secure development. The recent experience with Glamsterdam, where developers grappled with evaluating 50 non-headliner proposals, underscored the need for clear guidelines and efficient prioritization. This experience has refined the process, ensuring that client and testing teams, who bear the responsibility of implementing and validating these changes, can make informed recommendations without being overwhelmed. The increased clarity in the EIP proposal process is already fostering greater participation from high-context community members, leading to a more robust and diverse set of potential improvements.
The Broader Vision: Ethereum’s Strategic Evolution
These ongoing upgrades—Fusaka, Glamsterdam, and Hegotá—are not isolated events but integral components of Ethereum’s long-term strategic roadmap, often colloquially referred to as "The Surge," "The Scourge," "The Verge," "The Purge," and "The Splurge." Each phase addresses specific challenges and introduces critical advancements:
- The Surge: Focused on scaling through rollups and data sharding (like DAS introduced in Fusaka) to dramatically increase transaction throughput.
- The Scourge: Aims to address censorship resistance and MEV risks, with ePBS (Glamsterdam) and FOCIL (Hegotá) being key initiatives in this phase.
- The Verge: Concentrates on state growth and statelessness, making it easier for new nodes to join the network and reducing hardware requirements.
- The Purge: Involves simplifying the protocol and reducing historical data storage, further optimizing node operations.
- The Splurge: Encompasses all remaining minor improvements and optimizations to ensure the network’s long-term health and efficiency.
The coordinated progression through these phases demonstrates a holistic approach to network development, ensuring that Ethereum remains at the forefront of blockchain technology. The focus on modularity, decentralization, and secure scaling underpins every decision made in the ACD calls, reflecting a commitment to building a resilient and accessible global computing platform.
The All Core Developer calls continue to be the pulse of Ethereum’s technical evolution. Recent calls, including ACDT 62-66, ACDC 170-172, and ACDE 225-228, have been instrumental in these discussions, providing the forums for critical decision-making and collaborative problem-solving. As the network matures, the transparency and accessibility of these development processes become even more crucial, empowering the community to understand, participate in, and ultimately shape the future of Ethereum.
