Layla Zulfa
Ethereum’s core development continues its relentless pace towards a more scalable, decentralized, and robust network, as evidenced by recent milestones and forward-looking strategic planning. The latest "Checkpoint" update, issued roughly every 4-8 weeks to distill the complexities of the All Core Developer (ACD) calls, highlights significant progress across multiple network upgrades. The Fusaka upgrade has successfully gone live, delivering crucial scaling enhancements. Concurrently, the Glamsterdam upgrade is well underway with its ambitious feature set, while the subsequent Hegotál upgrade is now in its critical proposal phase for defining its major functionalities.
For those keen on tracking the intricate details of core development, the platform Forkcast has emerged as an invaluable resource, now providing comprehensive call summaries, chat logs, and transcripts for each All Core Dev (ACD) call and various breakout sessions. These resources are typically made available within hours of the calls, ensuring transparency and accessibility for the broader Ethereum community. This dedication to open communication underscores the collaborative and community-driven ethos at the heart of Ethereum’s ongoing evolution.
The Fusaka Upgrade: A Leap in Scalability
The period since the last "Checkpoint" has been marked by the successful activation of the Fusaka upgrade, a pivotal moment in Ethereum’s journey towards enhanced scalability. Fusaka’s primary contribution is the implementation of Data Availability Sampling (DAS), a sophisticated mechanism designed to allow nodes to verify the availability of data blobs without needing to download the entire dataset. This innovation is a crucial step in Ethereum’s sharding roadmap, dramatically increasing the network’s capacity to process and store data efficiently.
Data Availability Sampling (DAS), specifically the PeerDAS variant integrated into Fusaka, addresses one of the fundamental challenges in blockchain scaling: ensuring that data committed to the network is genuinely accessible to all participants. By enabling light clients to sample small portions of data and cryptographically verify its availability, DAS significantly reduces the computational and storage burden on individual nodes. This, in turn, allows for a substantial increase in the amount of data that can be processed per block, laying the groundwork for more robust Layer 2 (L2) scaling solutions. The secure and efficient scaling offered by DAS is paramount for supporting the growing ecosystem of decentralized applications (dApps) and reducing transaction costs, thereby enhancing the overall user experience on Ethereum.
The significance of Fusaka and PeerDAS was widely acknowledged across the Ethereum ecosystem. Official channels, including the primary @ethereum account and co-founder Vitalik Buterin, utilized social media platforms to elucidate the technical underpinnings and broader implications of PeerDAS. They emphasized its role in securely scaling the network and how these improvements integrate into Ethereum’s long-term vision, often referred to as "the roadmap." The consensus among core developers and the community is that Fusaka represents a substantial stride towards realizing Ethereum’s full potential as a global, high-throughput settlement layer.
Blob Parameter Only (BPO) Forks: Agile Scaling for Layer 2s
A groundbreaking operational advancement introduced alongside Fusaka is the capability to adjust blob parameters independently of full network upgrade cycles through "Blob Parameter Only (BPO) forks." This innovative approach provides Ethereum with unprecedented agility in responding to the escalating demand for Layer 2 data space. Previously, any modification to core network parameters, including those related to blobs, would necessitate a comprehensive hard fork, a process that is inherently time-consuming and resource-intensive.
Blobs, formally introduced with the Dencun upgrade (EIP-4844, also known as proto-danksharding), provide a dedicated and cost-effective data space for Layer 2 rollups. By detaching blob parameter adjustments from larger fork cycles, Ethereum can now dynamically scale its data capacity as needed, without incurring the delays associated with a full network upgrade. This operational flexibility is a testament to the engineering ingenuity within the Ethereum core development community, reflecting a proactive strategy to support the rapid growth of L2 solutions.
The initial BPO forks were rigorously stress-tested and subsequently integrated into the Fusaka upgrade. The first BPO fork went live shortly after Fusaka’s activation, with a second following in early January. These successful deployments have dramatically expanded Ethereum’s capacity for L2 data. The network now targets 14 blobs per block, with a maximum allowance of 21 blobs, representing an impressive 2.3x increase in available data space for L2 transactions compared to the pre-Fusaka era. This expansion translates directly into lower transaction fees and increased throughput for users interacting with applications on L2s, fostering a more accessible and efficient decentralized ecosystem.
Despite the proven success and increased capacity, core developers have indicated that a third BPO fork is not an immediate priority. This decision is rooted in a data-driven approach: further increases will be considered only when current blob usage approaches the existing limits. This measured strategy ensures that network resources are optimized and upgrades are implemented in response to genuine demand, maintaining the stability and efficiency of the protocol.
Glamsterdam: Enshrining Decentralization and Efficiency
The next major network upgrade on Ethereum’s horizon is Glamsterdam, which is currently in active development. This upgrade is poised to introduce two headline features: enshrined Proposer Builder Separation (ePBS) and Block-level Access Lists (BALs). These features aim to significantly enhance the network’s decentralization, censorship resistance, and execution efficiency.
Enshrined Proposer Builder Separation (ePBS): This is a profound architectural shift designed to mitigate the risks associated with Maximal Extractable Value (MEV) and further decentralize block production. Currently, MEV is primarily extracted by block proposers and external "builders" who bundle transactions. This has led to concerns about centralization, as block building can become a specialized and potentially opaque activity. ePBS seeks to move the separation of these roles (proposing a block and building its contents) directly into the protocol itself.
By enshrining PBS, the protocol would mandate that proposers only propose a block header, while a separate set of "builders" would construct the block body. This separation ensures that no single entity has complete control over both block content and order, thereby reducing the potential for MEV-related centralization and enhancing censorship resistance. The implementation of ePBS is a complex undertaking, requiring extensive modifications to the consensus layer and careful consideration of economic incentives. This complexity is reflected in its development timeline, which is expected to be longer compared to other features.
Block-level Access Lists (BALs): In contrast to the deep architectural changes of ePBS, Block-level Access Lists (BALs) focus on improving transaction processing efficiency and predictability. BALs provide a mechanism for transactions to declare in advance which state elements (e.g., contract addresses, storage slots) they intend to access. This pre-declaration allows client software to optimize execution, potentially reducing gas costs and making transaction execution more predictable. BALs are expected to enhance the overall performance and developer experience on Ethereum, providing clearer insights into transaction behavior.
Development for BALs is progressing more rapidly than ePBS, with dedicated devnets already established for testing and refinement. The availability of these devnets underscores the relatively lower complexity of BALs compared to the multi-faceted changes required for ePBS.
Glamsterdam Timeline and Feature Selection:
As with all major network upgrades, the integration of new features into Glamsterdam follows a rigorous, multi-stage process. Headlining features like ePBS and BALs must first achieve a stable state on dedicated devnets. Only after this foundational stability is confirmed can additional Ethereum Improvement Proposals (EIPs) be considered for inclusion. Initially, a substantial list of 50 non-headlining features was proposed for Glamsterdam. Through extensive deliberation and technical evaluation by client and testing teams, this list has been meticulously refined to a more manageable set of 17 "Considered" features. This rigorous pruning process highlights the commitment to maintaining the upgrade’s scope and ensuring that only the most necessary and high-impact changes are included, thereby mitigating potential delays and risks.
These "Considered" features will be incrementally added to devnets in small batches for thorough testing. Any feature that proves problematic or could unduly delay the overall fork may be removed from the final set. The precise timeline for Glamsterdam’s launch will become clearer once a stable ePBS devnet is established and all selected EIPs have undergone comprehensive testing. This iterative and cautious approach is essential for maintaining the security and stability of the Ethereum network.
Hegotál: The Future of Censorship Resistance and Network Optimization
Beyond Glamsterdam, the Ethereum community is already looking ahead to the subsequent upgrade, provisionally named Hegotál. The naming convention itself reflects community engagement; the initial H-star name "Heka" was replaced with "Heze" after a community developer noted its absence from the International Astronomers Union catalog, which previous star names have adhered to. The final name, Hegotál, combines Heze with Bogotá, following the tradition of naming upgrades after cities associated with significant Ethereum events.
Fork-choice Inclusion Lists (FOCIL): One of the leading contenders for a headlining feature in Hegotál is Fork-choice Inclusion Lists (FOCIL), a critical mechanism aimed at bolstering censorship resistance on the network. FOCIL was initially considered for Glamsterdam but was moved to Hegotál to manage the scope of the former upgrade. It enjoys strong support from both core developers and the broader Ethereum community due to its potential to address concerns about transaction censorship. FOCIL is designed to ensure that a minimum number of transactions from a public mempool are included in blocks, even if block builders attempt to exclude them. This mechanism operates across both the consensus and execution layers, particularly interacting with the Engine API, making it a complex but vital addition. Its cross-layer nature means its integration requires careful coordination and extensive testing to avoid unforeseen complications.
As of this update, FOCIL is being evaluated alongside other potential headliner proposals for Hegotál. There is currently one explicitly competing proposal, indicating an active phase of deliberation and technical debate within the core development community. Other significant proposals that could contend for inclusion or be considered for subsequent upgrades include:
- Encrypted Mempools: This concept aims to combat front-running and other MEV-related exploits by encrypting transactions in the mempool, only revealing their contents to the block builder at the point of inclusion. This would level the playing field for users and reduce the profitability of certain MEV strategies.
- 6-second slots (EIP-7782): This proposal suggests reducing the block time from the current 12 seconds to 6 seconds. Such a change would dramatically increase transaction throughput and potentially improve user experience by speeding up transaction finality. However, it also presents significant technical challenges related to network propagation, validator stability, and potential impacts on decentralization. While discussed, it remains unclear whether this will be formally proposed for Hegotál or reserved for a later "I-star" upgrade.
Hegotál Timeline and Community Participation:
The process for defining Hegotál’s features is structured to foster broad community involvement. The period from January 8th to February 4th is designated for proposing headlining features. Anyone with a compelling EIP is encouraged to submit their proposals using the template available on the Ethereum Magicians forum. Following this, from February 5th to February 26th, these headliner proposals will undergo thorough discussion and finalization during ACD calls. Proposers will present their ideas, and community feedback will be actively solicited. The goal is to reach a definitive decision on Hegotál’s headlining features by February 26th.
Once the main features are locked in, a subsequent window will be opened for proposing minor, non-headlining EIPs. The deadline for these proposals will be announced following the headliner decision. Aspiring EIP champions are encouraged to familiarize themselves with the "2026 guide to shepherding a feature into a fork," which outlines the rigorous process from initial specification (guided by EIP-1) to technical championing and eventual inclusion. Active community support for preferred features during the February discussion period is highly encouraged, as it plays a crucial role in shaping the future direction of Ethereum.
The Evolution of the EIP Process:
The experience of managing 50 proposed non-headliner features for Glamsterdam served as a significant learning curve for the core development teams. This surge in proposals, potentially driven by increased participation and clearer process guidelines, highlighted the immense workload placed on client and testing teams. These teams are responsible for familiarizing themselves with each proposal, evaluating its technical feasibility and impact, and making informed recommendations for inclusion. Navigating through dozens of detailed specifications to ensure network stability and security is a monumental task.
The ongoing refinement of the EIP process, including clear windows for proposals and the requirement for technical champions, aims to streamline this effort. By providing explicit guidelines on when and how to propose features, the community is empowered to contribute effectively, while the core teams can better manage the pipeline of innovation. The current emphasis on selecting a limited set of high-impact headliners for Hegotál and then carefully evaluating other EIPs reflects a mature approach to protocol development, balancing ambitious innovation with the imperative of stability and security.
Relevant All Core Developer Calls (November 14th – January 19th):
The progress detailed in this update is the result of extensive collaboration and deliberation across numerous All Core Developer calls. These calls serve as the primary forum for discussing, debating, and deciding upon the technical direction of Ethereum. Summaries, chats, and transcripts for these sessions are available on Forkcast, providing granular insights into the decision-making process:
- ACDT (All Core Devs – Consensus Layer): 66, 65, 64, 63, 62
- ACDC (All Core Devs – Consensus Layer): 172, 171, 170
- ACDE (All Core Devs – Execution Layer): 228, 227, 226, 225
Ethereum’s development trajectory is a testament to continuous innovation and community-driven progress. From the immediate scaling benefits delivered by Fusaka and BPO forks, to the foundational changes envisioned for Glamsterdam and the future-proofing censorship resistance mechanisms proposed for Hegotál, the network is steadily advancing towards its vision of a decentralized, scalable, and resilient global computing platform. The ongoing transparent dialogue and structured approach to EIPs ensure that this evolution is both robust and reflective of the collective will of its vibrant developer community.
