Layla Zulfa
The Ethereum ecosystem continues its relentless pace of innovation, marked by a series of critical upgrades and strategic planning for future enhancements. Recent "Checkpoint" updates, designed to distill the intensive discussions from Ethereum’s All Core Developer (ACD) calls, highlight significant milestones including the successful deployment of the Fusaka upgrade, the implementation of flexible Blob Parameter Only (BPO) forks, and the active development of the upcoming Glamsterdam and Hegotá upgrades. These developments underscore Ethereum’s unwavering commitment to scalability, decentralization, and robust censorship resistance, charting a clear course for the blockchain’s evolution.
Keeping abreast of the multifaceted discussions and technical decisions made during the All Core Developer calls is a substantial undertaking for any community member or stakeholder. To address this, the "Checkpoint" series provides high-level summaries every 4-8 weeks, offering a concise overview of core development progress. Furthermore, for those seeking deeper engagement, platforms like Forkcast now promptly publish call summaries, chat logs, and full transcripts for all All Core Dev and associated breakout calls, often within hours of their conclusion, fostering greater transparency and accessibility within the developer community.
A Period of Accelerated Progress: Key Highlights
The period under review has been particularly dynamic. The Fusaka upgrade has successfully gone live, introducing crucial scaling capabilities. Alongside this, the network has gained the agility to adjust blob parameters independently of rigid fork cycles through BPO forks, a significant operational improvement. Looking ahead, the next major upgrade, Glamsterdam, is fully scoped with active development underway on its primary features. Preparations are also intensifying for the subsequent upgrade, Hegotá, with proposals for its major features currently being solicited, setting a deadline of February 4th for submissions. This structured approach to development ensures a methodical yet agile progression of the Ethereum roadmap.
Fusaka: A Leap Forward in Data Availability and Scaling
The Fusaka upgrade represents a pivotal achievement in Ethereum’s scaling journey, introducing Data Availability Sampling (DAS) via EIP-7594. This enhancement is foundational for the network’s long-term strategy, particularly for supporting Layer 2 (L2) scaling solutions such as rollups. By enabling nodes to verify the availability of data blobs without needing to download the entire dataset, DAS significantly reduces the computational burden on individual nodes while drastically increasing the network’s data throughput capacity.
The importance of Fusaka and its implications for secure scaling were widely communicated by official Ethereum channels and prominent figures within the community. The official @ethereum Twitter account, along with co-founder Vitalik Buterin, actively engaged with the public to explain the intricacies of PeerDAS (a key component of DAS), articulate why "scaling securely matters," and clarify how these advancements integrate into Ethereum’s broader vision. This educational outreach underscored the developer community’s dedication not only to implementing advanced technical solutions but also to ensuring their impact and necessity are well understood by the wider ecosystem. For instance, Vitalik’s explanations often contextualize these technical upgrades within the "roadmap to Serenity" (Ethereum 2.0), emphasizing how each piece contributes to the overall goal of a scalable, secure, and decentralized global computer.
The successful activation of Fusaka is more than just a technical deployment; it’s a testament to the collaborative efforts of numerous client teams and researchers, demonstrating the network’s capacity to deliver complex, high-impact protocol changes. This upgrade paves the way for a new era of efficiency and lower transaction costs on L2s, which depend on the underlying L1 for data availability.
Blob Parameter Only (BPO) Forks: Dynamic Scaling for Layer 2s
A groundbreaking operational shift introduced concurrently with Fusaka is the ability to conduct Blob Parameter Only (BPO) forks. Historically, any alteration to core network parameters required a full hard fork, a process that is resource-intensive and requires significant coordination. BPO forks decouple the adjustment of blob counts from the broader fork cycle, allowing Ethereum to dynamically scale its data layer in response to network demand from L2s.
This newfound flexibility has already been put to the test. The first two BPO forks were successfully stress-tested and integrated into the Fusaka upgrade deployment plan. The initial BPO fork went live just days after Fusaka, followed by a second in early January. These rapid adjustments have significantly increased the network’s capacity for L2 data. Ethereum now targets 14 blobs per block and permits a maximum of 21, representing an impressive 2.3x increase in data space available for L2 transactions compared to pre-Fusaka levels.
This expedited scaling mechanism is crucial for Layer 2 solutions, which bundle transactions off-chain and then post a summary, along with associated data blobs, to the Ethereum mainnet. Increased blob availability translates directly into more efficient and cheaper L2 operations, benefiting end-users through lower fees and faster transaction finality. The successful execution of BPO forks demonstrates Ethereum’s maturity in protocol management, allowing for responsive adjustments to network parameters without incurring the overhead of a full network upgrade.
While the current increased capacity is substantial, developers have indicated that a third BPO fork is not an immediate priority. The focus remains on monitoring existing blob usage, and further increases will be considered only when the current capacity approaches saturation, ensuring resources are allocated efficiently and in response to actual network needs. This measured approach prevents over-provisioning and maintains stability.
Glamsterdam: Enshrining Decentralization and Enhancing Efficiency
The next major network upgrade, tentatively named Glamsterdam, is fully scoped and actively under development, promising to introduce two highly anticipated features: enshrined Proposer-Builder Separation (ePBS) and Block-level Access Lists (BALs). These features are central to Ethereum’s long-term goals of enhanced decentralization, censorship resistance, and improved transaction efficiency.
Enshrined Proposer-Builder Separation (ePBS) is arguably the more complex of the two headliners. Its primary goal is to mitigate the negative externalities of Maximal Extractable Value (MEV) and enhance network decentralization. Currently, block proposers (validators) can also build blocks, giving them significant power over transaction ordering and inclusion, leading to potential centralization and MEV extraction. ePBS separates these roles: proposers are responsible for proposing a block header, while a separate set of "builders" compete to construct the most valuable block body. The proposer then selects the most appealing block header, committing to a block built by an external party. This separation aims to democratize block production, reduce the ability of a single entity to censor transactions, and create a more equitable distribution of MEV. The technical complexities involved in designing and implementing ePBS, which requires significant changes to the consensus layer, mean that a dedicated development network (devnet) is still some time away.
Block-level Access Lists (BALs), while also a significant change, are comparatively less complex than ePBS. BALs aim to improve transaction processing efficiency and predictability. An access list is a set of storage keys and addresses that a transaction intends to access. By providing this information upfront, clients can better predict the state changes a transaction will induce, potentially reducing execution failures and improving block processing times. Unlike ePBS, BALs already have dedicated devnets (e.g., ethpandaops/bal-devnets) up and running, allowing for early testing and iteration.
Navigating the Glamsterdam Development Cycle
The development process for Glamsterdam, like any major Ethereum upgrade, involves a meticulous, multi-stage approach. The initial phase focuses on stabilizing the headlining features, ePBS and BALs, on dedicated development networks. Only after these core components demonstrate stability and reliability will additional Ethereum Improvement Proposals (EIPs) be integrated.
The challenge of selecting these additional features for Glamsterdam was significant. The initial pool of proposed non-headlining EIPs was a staggering 50. This abundance of proposals, while indicative of a vibrant and innovative developer community, placed a considerable burden on client and testing teams. These teams are responsible for thoroughly understanding each EIP’s specifications, assessing its impact, and making informed recommendations regarding its urgency and potential benefits. The process of evaluating such a large volume of complex technical changes was described by some developers as an "absolute beast," highlighting the intensive work involved.
Through diligent review and prioritization, this extensive list has been refined to a more manageable set of 17 "Considered" features. These EIPs are deemed necessary and high-impact enough to be included. They will be incrementally added to devnets in small batches for rigorous testing. This phased integration allows developers to isolate potential issues and assess the cumulative impact of multiple EIPs. Should any EIP prove problematic during testing or risk delaying the overall fork, it may be removed from the "Considered" set to maintain the upgrade’s timeline.
A clearer timeline for Glamsterdam’s deployment is anticipated once a stable ePBS devnet is established and, subsequently, once all "Considered" EIPs have undergone thorough testing within a consolidated devnet environment. This iterative and cautious approach is critical for ensuring the stability and security of the Ethereum network.
Hegotá: Charting the Future with Censorship Resistance
Beyond Glamsterdam, the Ethereum community is already laying the groundwork for the next major upgrade, Hegotá. The naming convention for Ethereum upgrades follows a sequence of star names, starting with "H." The initial proposed name, "Heka," was revised to "Heze" after a community developer pointed out that Heka is not officially recognized in the International Astronomical Union catalog, a standard followed by previous upgrade names. Thus, Heze, combined with the city of Bogotá, yields the current upgrade name: Hegotá.
A significant feature being considered for Hegotá is Fork-choice Inclusion Lists (FOCIL), a crucial mechanism aimed at bolstering censorship resistance. FOCIL was initially considered for Glamsterdam but was moved to Hegotá to manage the scope of the Glamsterdam upgrade, given its complexity. FOCIL has garnered strong support from both core developers and the broader Ethereum community due to its direct impact on network integrity and resilience against censorship.
FOCIL operates by giving proposers a mechanism to enforce the inclusion of certain transactions within a block, even if a block builder attempts to exclude them. This provides a decentralized safeguard against malicious actors or state-level censorship, ensuring that legitimate transactions are eventually processed. Its implementation is particularly challenging as it is a "cross-layer EIP," meaning it requires coordinated changes across both the consensus layer and the execution layer, specifically impacting the engine API that facilitates communication between these two components. This inherent complexity means that FOCIL will likely be a primary headliner for Hegotá, requiring extensive research and development.
As of the current "Checkpoint" update, FOCIL is undergoing evaluation alongside other headliner proposals. While there is strong momentum behind FOCIL, at least one other competing proposal has emerged on the Ethereum Magicians forum, the primary platform for EIP discussions. Other concepts, such as encrypted mempools (which aim to prevent MEV by obscuring transaction details before block inclusion) and even proposals for shorter 6-second slots (EIP-7782, designed to increase block finality), have been discussed as potential candidates for Hegotá or subsequent upgrades. The selection of Hegotá’s headlining features will be a critical decision, shaping the network’s capabilities in the coming years.
The Hegotá Proposal Process and Timeline
The process for proposing and finalizing features for Hegotá is structured and transparent, inviting broad community participation.
- January 8th – February 4th: This period is designated for headliner proposals. Any interested party can propose a major feature for Hegotá by submitting it using a specified template on the Ethereum Magicians forum. This open call ensures that innovative ideas from across the ecosystem are considered.
- February 5th – February 26th: Following the proposal deadline, the focus shifts to intensive discussion and finalization of headlining features. Proposers will present their EIPs during All Core Developer calls, and community feedback will be actively solicited. The goal is to reach a consensus on Hegotá’s primary features by February 26th.
- 30 days following headliner decision (deadline TBD): Once the headliners are decided, a window will open for proposals for minor (non-headlining) features. The exact deadline will be announced in subsequent "Checkpoint" updates. Similar to headliner proposals, anyone can submit a non-headliner EIP, provided they are willing to champion it through the rigorous development and testing process, as outlined in the official EIP championing guide.
This timeline reflects a maturing development process, aiming to provide clarity and structured participation, while also acknowledging the iterative nature of blockchain protocol upgrades.
Understanding Ethereum’s Evolving Development Process
The journey of an EIP, from concept to deployment, is a rigorous one. A proposed feature for Ethereum, formally known as an Ethereum Improvement Proposal (EIP), must first be meticulously specified according to the guidelines set forth in EIP-1. It then needs to be proposed during a designated window and subsequently championed through the entire process by a dedicated technical point-of-contact. This "championing" involves advocating for the EIP, addressing technical questions, coordinating with client teams, and ensuring its readiness for integration into a fork. A comprehensive guide for championing an EIP, updated for 2026, is available on the Ethereum PM GitHub repository, outlining the detailed steps and responsibilities involved.
The experience with Glamsterdam, where developers grappled with a "beast" of 50 proposed non-headliner features, highlighted both the vibrancy and the challenges of Ethereum’s open-source development model. While the sheer volume of proposals indicates an increased number of high-context participants and a clearer understanding of the EIP submission process, it also places immense pressure on client and testing teams. These teams are the bedrock of Ethereum’s development, responsible for implementing changes, familiarizing themselves with complex specifications, and making critical recommendations on the most urgent and high-impact features. Reviewing 50 detailed EIP specifications to provide informed assessments is a colossal undertaking, demanding significant intellectual and time investment.
This experience is shaping future processes. The drive to narrow down the Glamsterdam list to 17 "Considered" features, and the structured timeline for Hegotá proposals, are direct responses to this challenge. The community is actively seeking ways to streamline the review process without stifling innovation.
Looking ahead, the competition for Hegotá’s headliner status is expected to be robust. While FOCIL is a strong contender, its cross-layer nature and impact on the engine API make it complex to pair with another equally intricate feature. The discussions around proposals like 6-second slots (EIP-7782), which could dramatically alter block finality, suggest that future upgrades will continue to push the boundaries of Ethereum’s capabilities. Community engagement during the February discussion period for Hegotá is therefore crucial. Active support and constructive feedback from all stakeholders can significantly influence the direction of these vital upgrades.
Relevant ACD Calls: November 14th – January 19th
- ACDT (All Core Devs – Technical): 66, 65, 64, 63, 62
- ACDC (All Core Devs – Consensus): 172, 171, 170
- ACDE (All Core Devs – Execution): 228, 227, 226, 225
These calls represent the foundational discussions and technical decision-making points that drive Ethereum’s continuous evolution. The summaries and transcripts available through Forkcast serve as invaluable resources for anyone wishing to delve deeper into the intricate details of Ethereum’s ongoing development.
In conclusion, Ethereum’s development trajectory remains focused on delivering a robust, scalable, and decentralized blockchain platform. The successful Fusaka upgrade, the strategic implementation of BPO forks, and the methodical planning for Glamsterdam and Hegotá all underscore a committed and highly collaborative global developer community. Each upgrade is a step towards a more performant and resilient Ethereum, capable of supporting a global, decentralized future.
