Layla Zulfa
The Ethereum network has recently marked significant milestones in its ongoing evolution, most notably with the successful deployment of the Fusaka upgrade and the strategic implementation of Blob Parameter Only (BPO) forks. These advancements are critical steps in Ethereum’s ambitious scaling roadmap, directly enhancing the network’s capacity and preparing it for future innovations. Concurrently, core developers are actively progressing on the next major upgrade, Glamsterdam, while shaping the foundational features for the subsequent Hegotà hard fork, signaling a relentless pursuit of a more scalable, decentralized, and censorship-resistant blockchain.
The "Checkpoint" series, a crucial communication initiative, provides high-level updates on these intricate developments from the Ethereum All Core Developer (ACD) calls. These calls, known for their deep technical discussions, drive the network’s future. For those seeking immediate and comprehensive insights, Forkcast has emerged as an invaluable resource, publishing detailed summaries, chat logs, and transcripts of ACD and breakout calls, often within hours of their conclusion. This commitment to transparency ensures the community remains informed about the complex decisions and technical progress underpinning Ethereum’s continuous advancement.
Fusaka Upgrade: A Leap Forward in Data Availability
The period since the last "Checkpoint" update has been defined by the successful activation of the Fusaka upgrade. This monumental hard fork introduced Data Availability Sampling (DAS), a pivotal scaling solution designed to enhance how the Ethereum network handles and verifies data. Specifically, Fusaka incorporated PeerDAS (Peer Data Availability Sampling), a sophisticated mechanism that allows a greater volume of data to be processed and stored securely on the network. This is not merely an incremental improvement; it represents a foundational shift towards realizing Ethereum’s long-term vision of becoming a global, high-throughput settlement layer.
Data Availability Sampling is a cornerstone of Ethereum’s scaling strategy, particularly for supporting Layer 2 (L2) rollups. L2 solutions like optimistic rollups and ZK-rollups bundle transactions off-chain and then post a summary or proof back to the Ethereum mainnet. For these L2s to function securely, the underlying data for these bundled transactions must be available on the mainnet for anyone to verify. DAS ensures this data availability without requiring every node to download and store every piece of data, thereby significantly reducing the burden on individual nodes and allowing for vastly increased data throughput.
Following the Fusaka launch, official Ethereum channels and prominent figures like Vitalik Buterin took to social media to elucidate the importance of PeerDAS. They highlighted its role in securely scaling the network and articulated how these improvements integrate into the broader "Danksharding" roadmap. This public discourse underscored the critical nature of these technical updates, emphasizing that secure scaling is paramount for Ethereum’s integrity and its ability to serve a global user base effectively. The successful deployment of Fusaka demonstrates the core developers’ capability to deliver complex, high-impact protocol changes, reinforcing confidence in Ethereum’s future trajectory.
Blob Parameter Only (BPO) Forks: Agile Scaling for Layer 2s
Complementing the Fusaka upgrade, Ethereum has introduced and successfully utilized Blob Parameter Only (BPO) forks. This innovation represents a significant advancement in the network’s ability to adapt its scaling parameters without necessitating a full, complex network-wide hard fork. BPO forks allow for the adjustment of blob counts—the dedicated data segments introduced with the Dencun upgrade (protodanksharding)—independently of the larger, more infrequent fork cycles. This newfound flexibility is crucial for responding dynamically to the increasing demand for Layer 2 data space.
The concept of blobs was initially introduced to provide a dedicated, cheaper space for L2 data, distinct from general transaction data. This was a game-changer for reducing L2 transaction costs. With BPO forks, Ethereum can now increase the number of blobs per block as needed, directly responding to the growth in L2 usage. The first two BPO forks were rigorously stress-tested and subsequently integrated into the Fusaka update. The inaugural BPO fork went live shortly after Fusaka, followed by a second at the beginning of January. These implementations have effectively increased Ethereum’s target blob capacity to 14 blobs per block, with a maximum allowance of 21. This translates to a substantial 2.3x increase in available data space for L2 solutions compared to the pre-Fusaka era, offering considerable relief for rollup operations and further driving down transaction costs for end-users.
During recent core developer discussions, while acknowledging the success of the initial BPO forks, it was agreed that pursuing a third BPO fork is not an immediate priority. The current increased capacity is deemed sufficient until blob usage demonstrably rises to exhaust the existing allowances. This strategic pause reflects a measured approach to network upgrades, ensuring that resources are allocated efficiently and that changes are implemented in response to genuine network demand rather than preemptively. The agility afforded by BPO forks empowers Ethereum to scale incrementally and responsibly, providing a robust foundation for the continued growth of its L2 ecosystem.
Glamsterdam: The Horizon of Decentralization and Efficiency
With Fusaka successfully deployed, the focus of Ethereum’s core development community has firmly shifted towards the Glamsterdam upgrade. This forthcoming hard fork is poised to introduce two highly anticipated features: enshrined Proposer-Builder Separation (ePBS) and Block-level Access Lists (BALs). Both are critical components in Ethereum’s long-term vision for enhanced decentralization, censorship resistance, and network efficiency.
Enshrined Proposer-Builder Separation (ePBS) is arguably the more complex and transformative of the two. It seeks to mitigate the risks associated with Maximal Extractable Value (MEV) by separating the roles of block proposal and block building. Currently, block proposers (validators) can also build blocks, giving them significant power over transaction ordering and inclusion, which can lead to MEV extraction and potential centralization risks. ePBS aims to "enshrine" this separation directly into the protocol, ensuring that block building is handled by a competitive market of "builders" who construct optimal blocks, while "proposers" merely select the most profitable block from those submitted. This design is expected to democratize access to MEV, reduce censorship potential, and enhance the overall decentralization of the network. Given its profound implications for the validator set and the economic incentives of the network, ePBS requires extensive research, design, and testing, making its development a multi-faceted endeavor.
Block-level Access Lists (BALs), while less complex than ePBS, are equally important for improving transaction efficiency and providing better pre-confirmation guarantees. BALs allow transactions to explicitly declare the state they intend to access (e.g., specific contract addresses or storage slots). This information can be leveraged by clients and proposers to optimize block construction, improve transaction processing, and potentially enable stronger pre-transaction guarantees for users. This feature aims to streamline execution, reduce gas costs for certain transaction types, and make the network more predictable for users and developers alike. Development on BALs is progressing well, with dedicated devnets already established for testing.
The timeline for Glamsterdam is necessarily iterative, with core developers emphasizing the need to stabilize headliner features on devnets before integrating additional EIPs. The initial pool of non-headlining feature proposals for Glamsterdam was a formidable 50, presenting a significant challenge for client and testing teams tasked with familiarizing themselves with each specification and making informed recommendations. Through a rigorous evaluation process, this list has been meticulously refined to a more manageable set of 17 "Considered" features. These are deemed essential and high-impact, and will be gradually added to devnets in small batches. Any feature proving problematic or likely to cause significant delays may be removed from the "Considered" set, underscoring a pragmatic approach to upgrade scope. A more definitive timeline for Glamsterdam is anticipated once a stable ePBS devnet is established and all selected EIPs have undergone thorough testing. This meticulous process highlights the core developers’ commitment to network stability and security above all else.
Hegotà: Defining the Next Era
Even as Glamsterdam progresses, the Ethereum community is already looking ahead to the subsequent upgrade, Hegotà. The naming convention for Ethereum upgrades follows the stars, and the initial choice, Heka, was replaced with Heze (a star in the International Astronomers Union catalog) after a community developer noted Heka’s absence from the official registry. Combined with Bogotá, the location of a prominent Ethereum conference, the upgrade was officially christened Hegotà. This detail, though minor, reflects the community-driven nature of Ethereum’s development and its adherence to established traditions.
The primary focus for Hegotà at this early stage is the selection of its headlining features. One prominent proposal is Fork-choice Inclusion Lists (FOCIL), a critical censorship resistance mechanism. FOCIL was initially considered for Glamsterdam but was moved to Hegotà to manage the scope of the former, given its complexity as a cross-layer EIP impacting both the consensus and execution layers, particularly the Engine API. FOCIL aims to enhance transaction inclusion guarantees, making it harder for validators to censor specific transactions. This is a highly sensitive and vital area for maintaining the network’s neutrality and decentralization, explaining its strong support among core developers and the broader Ethereum community.
Currently, FOCIL is being evaluated alongside other potential headliner proposals for Hegotà. As of this update, there is at least one other competing proposal, indicating a healthy debate around the most impactful features for the network’s future. The timeline for Hegotà’s feature selection is structured to encourage broad community participation:
- January 8th – February 4th: Headliner proposals are actively being solicited. Anyone with a well-researched EIP can propose it using the template on the Ethereum Magicians forum.
- February 5th – February 26th: A dedicated period for discussion and finalization of headliner features. Proposers will present their ideas on ACD calls, and community feedback will be actively sought. The goal is to reach a consensus on Hegotà’s primary features by February 26th.
- 30 days following headliner decision (deadline TBD): A window for proposing non-headliner EIPs will open. As with headliner proposals, individuals are encouraged to propose features but must be prepared to champion them through the rigorous development process.
Beyond FOCIL, early discussions for Hegotà have also touched upon encrypted mempools, another mechanism aimed at combating MEV extraction and front-running by concealing transaction details until they are included in a block. There has also been conversation around implementing 6-second slots (EIP-7782), which would significantly reduce block times, enhancing transaction finality and user experience. However, it remains unclear whether 6-second slots will be proposed for Hegotà or reserved for a later upgrade, potentially the I-star fork. The active participation of the community during the February discussion period is crucial for influencing these decisions and ensuring that Hegotà incorporates the most impactful and consensus-supported features.
The Evolving Ethereum Improvement Process
The sheer volume of proposed features for Glamsterdam—starting with 50 non-headliner EIPs—provided a stark illustration of both the vibrancy of the Ethereum ecosystem and the challenges inherent in its decentralized development model. Navigating through such a large number of proposals places a significant burden on client and testing teams, who must meticulously review each specification, assess its technical feasibility, potential impact, and resource requirements before making informed recommendations. This experience underscored the need for clearer processes and designated windows for EIP submissions.
The Ethereum Improvement Proposal (EIP) process is the formal mechanism by which new features or standards are introduced to the network. An EIP begins as a detailed specification, guided by the foundational EIP-1, and must be championed by a technical point-of-contact willing to guide it through research, discussion, and implementation phases. While the process aims for inclusivity and broad participation, the workload on core teams is immense. The Glamsterdam experience has, however, led to a more structured approach, with clearer guidelines on when and how to propose features, which is expected to streamline future upgrade cycles like Hegotà.
The intricate nature of cross-layer EIPs, such as FOCIL, which require coordination between both the consensus and execution layers and interact with critical components like the Engine API, adds another layer of complexity. Pairing such a feature with other significant changes requires careful consideration to avoid compounding technical debt or delaying the upgrade. The discussions around potential headliners for Hegotà, including FOCIL, encrypted mempools, and 6-second slots, reflect the ongoing prioritization efforts to balance ambitious innovation with practical implementation challenges. The continuous refinement of the EIP process, driven by lessons learned from past upgrades, is vital for maintaining Ethereum’s development velocity and ensuring the network’s long-term health and security.
Broader Impact and Future Outlook
The recent advancements—Fusaka’s Data Availability Sampling, the flexible Blob Parameter Only forks, and the ambitious plans for Glamsterdam and Hegotà—collectively underscore Ethereum’s unwavering commitment to its core principles of scalability, decentralization, and censorship resistance. These upgrades are not isolated events but interconnected pieces of a grander strategy to transform Ethereum into a robust, high-performance global settlement layer that can support a vast array of decentralized applications and services.
The enhanced data availability and flexible scaling mechanisms directly empower Layer 2 solutions, enabling them to process more transactions at lower costs. This, in turn, fuels innovation across the decentralized finance (DeFi), non-fungible token (NFT), and broader Web3 ecosystems. Future features like ePBS and FOCIL aim to solidify Ethereum’s political decentralization, ensuring that the network remains resilient against centralizing forces and censorship. This continuous, iterative development process, characterized by transparent discussions in ACD calls and the structured EIP framework, is a testament to the dedication of the global Ethereum community.
The journey ahead for Glamsterdam and Hegotà will involve rigorous testing, extensive community engagement, and careful prioritization of features. The transparent nature of the core development process, facilitated by resources like Forkcast, allows the entire community to observe, participate, and contribute to the evolution of the network. As Ethereum continues to build out its "Surge," "Verge," "Purge," and "Splurge" phases, each upgrade brings the network closer to its ultimate vision, reinforcing its position as a leading blockchain platform. The ongoing work represents not just technical improvements, but a collective effort to build a more open, equitable, and resilient digital future.
For those interested in delving deeper into the specifics of these developments, transcripts and summaries of the relevant All Core Developer calls from November 14th to January 19th are available through Forkcast, including ACDT calls 62-66, ACDC calls 170-172, and ACDE calls 225-228. These resources provide an unparalleled level of insight into the technical debates and decisions shaping the future of Ethereum.
