Layla Zulfa
The Ethereum network continues its relentless evolution, marked by significant advancements in scalability, security, and decentralization. A recent "Checkpoint" update, a high-level overview of core development activities, highlights the successful deployment of the Fusaka upgrade, the ongoing progress of the Glamsterdam hard fork, and the initiation of proposals for the subsequent Hegotá upgrade. These developments underscore Ethereum’s commitment to enhancing its foundational infrastructure to support a burgeoning ecosystem of decentralized applications and Layer 2 solutions.
In a move to increase transparency and accessibility for the broader community, Forkcast, a dedicated platform, has begun publishing comprehensive summaries, chat logs, and transcripts for all All Core Dev (ACD) calls, including various breakout sessions. These resources are typically available within hours of the meetings, offering unparalleled insight into the complex discussions and decisions shaping Ethereum’s future. This initiative is particularly valuable given the intricate and often dense nature of core developer discussions, ensuring that stakeholders and enthusiasts alike can stay informed.
The Fusaka Leap: Enhancing Scalability with Data Availability Sampling
The period since the last core development update has been defined by the successful activation of the Fusaka upgrade. This monumental hard fork introduced Data Availability Sampling (DAS), specifically PeerDAS (Ethereum Improvement Proposal EIP-7594), a critical technology designed to significantly enhance Ethereum’s data processing capabilities. DAS is a cornerstone of Ethereum’s long-term scaling strategy, enabling the network to process more data efficiently and securely, which is vital for the viability and performance of Layer 2 scaling solutions like rollups.
The importance of Fusaka was widely communicated, with official channels like the @ethereum Twitter account and co-founder Vitalik Buterin actively explaining PeerDAS. Their messages emphasized not only the technical intricacies but also the broader vision: how secure scaling through innovations like DAS is fundamental to Ethereum’s roadmap, ensuring that the network can handle increased transaction volumes without compromising its decentralized and secure properties. This public engagement highlights the developers’ commitment to educating the community on complex protocol changes and their impact. Fusaka’s deployment represents a significant step forward in realizing the "Surge" phase of Ethereum’s roadmap, which focuses on sharding and data availability. By improving the efficiency with which data can be verified, DAS lays the groundwork for a future where Ethereum can support an exponentially larger number of transactions.
Dynamic Scaling: The Innovation of Blob Parameter Only (BPO) Forks
Beyond the Fusaka hard fork, a crucial development has been the operationalization of Blob Parameter Only (BPO) forks. This innovative mechanism allows for the adjustment of blob parameters—which dictate the amount of data available for Layer 2 transactions—independently of full network-wide hard fork cycles. Historically, any protocol change, no matter how minor, required a full hard fork, a process that demands extensive coordination and testing across the entire network. BPO forks introduce a new level of agility, enabling Ethereum to dynamically scale its data availability as needed, directly responding to the demands of Layer 2 networks.
The first two BPO forks were rigorously stress-tested and successfully integrated into the Fusaka deployment. The initial BPO fork went live just days after Fusaka, followed by a second in early January. These successful implementations have already led to a substantial increase in data capacity. Ethereum now targets 14 blobs per block, with a maximum allowance of 21. This represents a remarkable 2.3x increase in Layer 2 data space compared to the pre-Fusaka era, providing crucial bandwidth for rollups and other scaling solutions to operate more cost-effectively and efficiently.
While the capability for further BPO forks exists, core developers have indicated that a third such adjustment is not an immediate priority. The current strategy is to monitor existing blob usage. Developers will only consider another increase once the demand from Layer 2 solutions fully utilizes the recently expanded capacity, demonstrating a pragmatic approach to scaling that prioritizes efficient resource allocation and avoids unnecessary changes to the protocol. This flexible approach ensures that the network can adapt to real-world usage patterns, providing immediate benefits to users and developers on Layer 2.
Glamsterdam on the Horizon: Enshrined PBS and Block-level Access Lists
Looking ahead, the next major network upgrade, dubbed Glamsterdam, is fully scoped, with significant progress underway on its two headlining features: enshrined Proposer Builder Separation (ePBS) and Block-level Access Lists (BALs). Glamsterdam is poised to address critical areas of network health and transaction efficiency.
Enshrined Proposer Builder Separation (ePBS) is a complex but vital upgrade aimed at mitigating the risks associated with Maximal Extractable Value (MEV). MEV refers to the profit validators can extract by reordering, censoring, or inserting transactions within blocks. Currently, MEV extraction often leads to centralization pressures as specialized entities gain an advantage. ePBS seeks to decentralize the block-building process by separating the roles of block proposers (validators) and block builders, allowing builders to compete for the right to construct blocks and then submit them to proposers for inclusion. This separation is intended to make MEV extraction more transparent, fair, and less centralizing, ultimately strengthening Ethereum’s censorship resistance and decentralization. Given its profound implications for the network’s economic and political structure, ePBS is a technically challenging feature, and its development requires extensive research and testing before deployment.
Block-level Access Lists (BALs), the second headliner for Glamsterdam, aim to improve transaction processing efficiency and potentially offer some Denial-of-Service (DoS) attack resistance. While specific details of BALs (such as EIP-7702) are still being refined, they generally involve mechanisms that allow transactions to declare which parts of the state they will access. This information can help block builders and validators optimize block construction and verification, leading to more predictable transaction execution and potentially lower gas costs for users.
Development timelines reflect the complexity of these features. While BALs have already seen the establishment of dedicated devnets (developer networks) for testing, ePBS, being a much more intricate change, will require a longer period before its devnets are ready. Core developers are diligently working through the technical challenges to ensure the stability and security of these foundational changes.
The scoping process for Glamsterdam also highlighted the intensive effort involved in selecting features for a hard fork. Initially, core developers faced a daunting list of 50 proposed non-headlining features. Through rigorous evaluation, this list has been meticulously whittled down to a more manageable set of 17 "necessary and high-impact" features. These selected EIPs will be progressively added to devnets in small batches, allowing for thorough testing and integration. The developers maintain flexibility, noting that any feature proving problematic or causing significant delays could be removed from the "Considered" set to maintain the overall upgrade timeline. A clearer timeline for Glamsterdam’s mainnet deployment is anticipated once a stable ePBS devnet is established and all individual EIPs have undergone comprehensive testing.
Shaping Hegotá: A Call for Innovation and Community Engagement
Even as Glamsterdam progresses, the Ethereum community is already laying the groundwork for the subsequent hard fork, now officially named Hegotá. The name itself reflects a minor but interesting detail in the naming convention: the original H-star name, Heka, was replaced with Heze after a community developer pointed out that "Heka" is not listed in the International Astronomical Union (IAU) catalog, a standard followed for previous star-based upgrade names. The final name, Hegotá, is a combination of Heze (a star name) and Bogotá (the city, continuing the tradition of naming upgrades after cities).
The primary focus for Hegotá will be on selecting its major feature(s). One prominent candidate is Fork-choice Inclusion Lists (FOCIL), a robust censorship resistance mechanism. FOCIL was initially considered for Glamsterdam but was deferred to streamline that fork’s scope. Given its strong support among core developers and the wider Ethereum community, FOCIL has moved to "Considered" status for Hegotá. It will be evaluated alongside other headliner proposals during the upcoming discussion period. FOCIL is particularly complex as it’s a "cross-layer EIP," meaning it impacts both the consensus layer (the beacon chain) and the execution layer (the EVM), especially through the Engine API that connects them. This complexity necessitates careful consideration, especially if paired with other major changes.
Currently, there is only one other competing proposal for Hegotá’s headliner status, though more are expected. Other potential features that have been discussed for Hegotá or subsequent upgrades include encrypted mempools, which aim to protect transactions from front-running and other MEV strategies, and EIP-7782, which proposes 6-second slots (reducing the block time). While 6-second slots could dramatically increase transaction throughput and finality, its significant impact means it might be held for a later upgrade like I-star.
The timeline for Hegotá’s feature selection is structured to encourage broad participation and rigorous evaluation:
- January 8th – February 4th: Headliner proposals are actively being accepted. Anyone can propose a headlining feature using a template available on the Ethereum Magicians forum.
- February 5th – February 26th: This period is dedicated to discussing and finalizing the chosen headliner(s) for Hegotá. Proposers will present their EIPs on ACD calls, and community feedback will be actively solicited.
- 30 days following headliner decision (deadline TBD): After the main features are decided, proposals for non-headlining EIPs will be accepted. Similar to headliners, anyone can propose a non-headliner, provided they are committed to championing it through the development process.
This transparent and community-driven approach is a hallmark of Ethereum’s decentralized governance, allowing a wide range of ideas to be considered and implemented based on technical merit and community consensus. Active engagement during the February discussion period is crucial for those who wish to see specific features prioritized.
The Ethereum Improvement Proposal (EIP) Process: A Deep Dive
Understanding how a feature makes it into Ethereum is key to appreciating the network’s decentralized development model. The process for introducing a new feature or change is formalized through an Ethereum Improvement Proposal (EIP). These proposals are first meticulously specified, using EIP-1 (the very first EIP, which defines the EIP process itself) as a foundational guide. Once specified, EIPs are proposed during designated windows and must be "championed" by a technical point-of-contact who guides them through the various stages of discussion, refinement, and eventual implementation. A detailed guide, "2026_championing_an_EIP.md," outlines this entire process, providing a roadmap for aspiring contributors.
The experience with Glamsterdam’s non-headliner features served as a significant learning curve for the development community. The initial influx of 50 proposed features was described as "an absolute beast" for all involved. This high volume, while potentially indicating increased participation from a growing pool of knowledgeable contributors, also presented substantial challenges. Client teams (who develop the software that runs the Ethereum network) and testing teams are responsible for familiarizing themselves with each proposal, evaluating its feasibility, impact, and readiness, and then making informed recommendations for inclusion. Reviewing 50 complex technical specifications represents an immense workload, consuming valuable time and resources.
This challenge has reinforced the importance of clear processes and focused communication. The current, more structured approach to EIP proposals for Hegotá, with distinct windows for headliner and non-headliner submissions, aims to streamline this evaluation. It also highlights the critical role of client and testing teams, whose efforts are essential to ensuring the robust implementation of any network upgrade. The sheer volume of proposals for Glamsterdam underscored the need for efficient review mechanisms and a clear prioritization framework to manage the continuous flow of innovation within the Ethereum ecosystem.
The ongoing discussions around Hegotá’s potential headliners, such as FOCIL and encrypted mempools, further illustrate the complexities. FOCIL, as a cross-layer EIP impacting both consensus and execution layers, presents particular integration challenges. There’s also ongoing debate about features like 6-second slots (EIP-7782), with uncertainty about whether it will be proposed for Hegotá or deferred to a later upgrade like I-star due to its significant protocol changes. This dynamic environment necessitates active community engagement. Developers strongly encourage active participation and support for preferred major features during the February discussion period, emphasizing that community voice plays a vital role in shaping Ethereum’s future trajectory.
Looking Ahead: Ethereum’s Continuous Evolution
The continuous cycle of upgrades—from Fusaka’s successful launch to Glamsterdam’s meticulous development and Hegotá’s early planning stages—epitomizes Ethereum’s commitment to continuous improvement. Each hard fork, each EIP, and each core developer discussion contributes to building a more scalable, secure, and decentralized global computing platform. The process is iterative, collaborative, and deeply rooted in open-source principles, with the All Core Developer calls serving as the vibrant heartbeat of this ongoing innovation. The transparency provided by resources like Forkcast ensures that this complex journey remains accessible and accountable to the global community that relies on and contributes to Ethereum. As the network matures, these structured development cycles become ever more critical in balancing ambitious technological advancements with the imperative of network stability and security.
Relevant Core Developer Calls (November 14th – January 19th):
For those interested in the granular details of these developments, the following All Core Dev calls provide comprehensive insights:
- 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, along with the newly available summaries and transcripts on Forkcast, offer a transparent window into the collaborative and rigorous process that drives the world’s leading smart contract platform forward.
