London, UK – [Date of publication, e.g., February 12, 2025] – Ethereum, the world’s leading smart contract platform, continues its ambitious journey of iterative upgrades, pushing the boundaries of scalability, security, and decentralization. A recent "Checkpoint" update, a high-level summary of the All Core Developer (ACD) calls, reveals a dynamic period marked by the successful deployment of the Fusaka upgrade, significant progress on the upcoming Glamsterdam hard fork, and the initial scoping of Hegotá, the subsequent major network improvement. These advancements underscore Ethereum’s commitment to its long-term vision, often referred to as "The Surge," "The Scourge," and "The Verge," aiming to deliver a more robust, efficient, and censorship-resistant blockchain for its global user base.
The core development team, a decentralized collective of researchers and engineers, operates with remarkable transparency, meticulously documenting their discussions and decisions. Resources like the "Checkpoint" series and the newly enhanced Forkcast platform, which provides near real-time summaries, chats, and transcripts of ACD calls, are vital in keeping the community abreast of these complex, yet crucial, developments. This regular cadence of updates ensures that stakeholders, from developers to end-users, can track the evolution of the network.
A New Era of Scalability: The Fusaka Upgrade and Blob Parameter Adjustments
The period since the last "Checkpoint" has been momentous, primarily defined by the successful activation of the Fusaka upgrade. This hard fork represents a pivotal step in Ethereum’s scaling roadmap, specifically focusing on data availability.
Unpacking Fusaka: Data Availability Sampling (DAS)
Fusaka’s flagship feature is the implementation of Data Availability Sampling (DAS), often referred to as PeerDAS. This technology significantly enhances Ethereum’s capacity to handle data, particularly for Layer 2 (L2) rollups. Before DAS, L2 solutions would post their transaction data directly onto the Ethereum mainnet, which could become a bottleneck as L2 usage grew. DAS introduces a mechanism where instead of every node downloading all rollup data, nodes can verify the availability of data through statistical sampling. This allows for a massive increase in the amount of data that can be processed and verified without overburdening individual nodes.
The importance of Fusaka and PeerDAS was widely broadcasted, with both official Ethereum channels and co-founder Vitalik Buterin taking to social media platforms like X (formerly Twitter) to explain its intricacies. They emphasized why "scaling securely matters" – highlighting that increasing transaction throughput must not come at the cost of decentralization or security. The successful integration of PeerDAS into the Ethereum protocol demonstrates the network’s architectural flexibility and its capacity to implement sophisticated cryptographic and network-level changes, bringing the blockchain closer to its goal of supporting a truly global, high-throughput ecosystem. This step is a foundational component of "The Surge," aiming to dramatically increase transaction capacity and reduce costs.
Dynamic Scaling with Blob Parameter Only (BPO) Forks
Beyond PeerDAS, Fusaka also marked a crucial shift in how Ethereum manages its data capacity for L2s through the introduction of Blob Parameter Only (BPO) forks. This innovation allows for the independent adjustment of "blob" parameters – dedicated data segments for L2 transactions – without requiring a full network-wide hard fork. Previously, any change to core parameters was tied to major fork cycles, leading to slower, less agile responses to network demand.
The ability to conduct BPO forks means Ethereum can now dynamically scale its data availability as L2 usage dictates. The first two BPO forks were successfully stress-tested and baked into the Fusaka deployment, with the first going live just days after Fusaka’s activation and the second following in early January. These forks have increased the targeted blob count to 14 blobs per block, with a maximum allowance of 21. This translates to a substantial 2.3x increase in available data space for L2s compared to pre-Fusaka levels, directly impacting the cost and efficiency of rollup transactions.

Core developers noted the successful execution of these initial BPO forks, demonstrating the robustness of this new mechanism. While a third BPO fork is technically feasible, developers have agreed that it is not an immediate priority. The current blob capacity is deemed sufficient, and further increases will only be pursued when actual L2 usage begins to approach the existing limits, showcasing a pragmatic, demand-driven approach to scaling. This flexible scaling mechanism is crucial for accommodating the rapid growth of the Layer 2 ecosystem and ensuring that Ethereum remains the dominant settlement layer.
Shaping the Future: The Glamsterdam Upgrade
With Fusaka successfully deployed, the focus has now firmly shifted to Glamsterdam, the next major network upgrade. This hard fork is fully scoped, and development teams are actively working on its ambitious set of features, which promise to bring significant enhancements to Ethereum’s security, decentralization, and transaction processing.
Enshrined Proposer Builder Separation (ePBS): A Deep Dive
One of Glamsterdam’s two headlining features is the implementation of enshrined Proposer Builder Separation (ePBS). This is a highly anticipated and complex change designed to mitigate the risks associated with Maximal Extractable Value (MEV). MEV refers to the profit validators (formerly miners) can extract by reordering, censoring, or inserting transactions within a block. While MEV is a natural consequence of transaction ordering, it can lead to centralization pressures, as specialized entities (builders) optimize block construction for MEV extraction, potentially creating an unfair advantage and even censorship concerns.
ePBS aims to separate the roles of "proposer" (the validator chosen to propose the next block) and "builder" (an entity that constructs the block content). Builders bid for the right to construct a block, and the proposer selects the highest-bidding valid block, without necessarily knowing its internal transaction order or content until after selection. "Enshrined" means this separation is hard-coded into the protocol itself, rather than relying on external, off-chain solutions like the current MEV-Boost system. This ensures a higher degree of trustlessness and decentralization.
The complexity of ePBS is considerable, touching fundamental aspects of block production and validator incentives. While progress is being made, the development of a stable devnet for ePBS is still some way off, reflecting the meticulous testing and coordination required for such a profound protocol change. Its successful deployment would be a monumental step towards a more fair and decentralized transaction landscape, directly addressing concerns around validator influence and potential censorship, aligning with "The Scourge" phase of the roadmap.
Block-level Access Lists (BALs) and Enhanced Transaction Flow
The second major feature slated for Glamsterdam is Block-level Access Lists (BALs). While less complex than ePBS, BALs are critical for improving transaction efficiency and potentially offering a degree of censorship resistance. BALs allow transactions to declare the state they intend to access (e.g., specific contract addresses or storage slots) before execution. This pre-declaration can enable more efficient block building by providing builders with better information for parallelizing execution and optimizing resource allocation.
Furthermore, BALs can enhance censorship resistance by making it harder for validators to selectively omit transactions. If a transaction declares its intent to access certain state, and that state is indeed relevant to the block, it becomes more transparent if the transaction is excluded without a valid reason. Devnets for BALs are already in operation, indicating good progress on this front. The implementation of BALs aims to make transaction processing more predictable and robust, benefiting both users and developers.

Navigating the EIP Landscape: Glamsterdam’s Feature Set
Beyond the two headlining features, every Ethereum hard fork typically includes a number of smaller, yet impactful, Ethereum Improvement Proposals (EIPs). For Glamsterdam, the initial list of proposed non-headlining features was a staggering 50. This high volume, while demonstrating a vibrant and innovative developer community, presented a significant challenge for client and testing teams who are responsible for reviewing, implementing, and testing each EIP.
Through rigorous discussion and prioritization, the core developers have successfully whittled this extensive list down to a more manageable set of 17 "necessary and high-impact" features. This reduction is critical for maintaining a realistic scope for the upgrade, preventing delays, and ensuring the stability of the network. These remaining features will be progressively added to devnets in small batches, allowing for thorough testing and identification of any potential issues. If any feature proves problematic or threatens to unduly delay the overall fork, it may be removed from the "Considered" set. This pragmatic approach ensures that the upgrade remains on track while delivering meaningful improvements.
Glamsterdam’s Path Forward: Devnet Progress and Timeline
The timeline for Glamsterdam is inherently linked to the stability and maturity of its devnets. The priority is to bring the headlining features, ePBS and BALs, to a stable state on these test networks. Given the complexity of ePBS, a definitive timeline will become clearer only after the first stable ePBS devnet is established. Following this, further clarity will emerge as each of the 17 "Considered" EIPs is integrated and tested in the devnet environment. The iterative testing process is a cornerstone of Ethereum’s development methodology, ensuring the robustness and security of every protocol change.
Beyond Glamsterdam: The Vision for Hegotá
Looking further into Ethereum’s future, the next major upgrade after Glamsterdam has been named Hegotá. The naming convention for Ethereum upgrades typically follows the brightest stars in the International Astronomers Union catalog. The initial "H-star" name, Heka, was recently replaced with Heze after a community developer pointed out that Heka was not officially listed. The final name, Hegotá, is a portmanteau of Heze and Bogotá, continuing the tradition of combining a star name with a city where a significant developer conference or event took place.
Fork-choice Inclusion Lists (FOCIL): Strengthening Censorship Resistance
Hegotá is already generating significant discussion, particularly around its potential headlining features. A strong contender is Fork-choice Inclusion Lists (FOCIL), a critical censorship resistance mechanism. FOCIL was originally considered for Glamsterdam but was moved out to reduce the fork’s scope, indicating its substantial complexity and impact. However, its strong support among core developers and the broader Ethereum community highlights its importance.
FOCIL aims to enhance the network’s resilience against censorship by ensuring that legitimate transactions are included in blocks. It is a cross-layer EIP, meaning it impacts both the consensus layer (how blocks are agreed upon) and the execution layer (how transactions are processed), particularly the Engine API which facilitates communication between these layers. This cross-layer nature makes FOCIL inherently intricate, but its potential to safeguard network neutrality and prevent malicious validators from excluding specific transactions is paramount for Ethereum’s long-term health and credibility. As of this update, FOCIL is being evaluated as a headliner alongside other proposals.
The Road to Hegotá: Proposal Process and Milestones
The process for selecting Hegotá’s headlining features is now officially underway. The period from January 8th to February 4th has been designated for headliner proposals. Any community member can propose a feature using a specific template on the Ethereum Magicians forum, an essential platform for EIP discussions.

Following the proposal deadline, the period from February 5th to February 26th will be dedicated to intensive discussion and finalization of the headlining features. Proposers will present their ideas on ACD calls, and community feedback will be actively solicited. The goal is to decide on Hegotá’s core features by February 26th. Once headliners are chosen, a subsequent deadline will be announced for non-headlining EIP proposals, similar to the process for Glamsterdam. The emphasis is on community involvement, with anyone willing to champion an EIP encouraged to participate.
Beyond FOCIL, other proposals are expected to emerge, including potentially encrypted mempools, another mechanism to counter MEV and censorship by obscuring transaction details until they are included in a block. There has also been discussion around EIP-7782, which proposes 6-second slots, a significant change to block timing that could enhance transaction throughput and finality. However, it remains unclear whether 6-782 will be proposed for Hegotá or deferred to a later "I-star" upgrade. The core development team actively encourages community members to engage with these discussions and voice their support for preferred features during the February deliberation period.
The Engine of Innovation: Ethereum’s Core Development Process
The relentless pace of Ethereum’s evolution is a testament to its robust, community-driven development process. However, this process is not without its challenges.
Championing an EIP: A Community-Driven Approach
The path for a proposed feature, known as an Ethereum Improvement Proposal (EIP), to be integrated into the protocol is well-defined. It begins with specifying the EIP according to EIP-1 guidelines, followed by a formal proposal during designated windows. Crucially, each EIP requires a "champion" – a technical point-of-contact willing to guide it through the various stages of review, discussion, and implementation. This distributed model empowers individuals and small teams to contribute meaningfully to the network’s future, fostering a culture of innovation and shared ownership. The 2026 guide on championing an EIP provides a comprehensive roadmap for those looking to contribute.
Balancing Ambition and Execution: Lessons from Glamsterdam
The experience with Glamsterdam’s initial 50 proposed non-headliner features highlighted both the strengths and strains of this decentralized process. The sheer volume of proposals, while exciting, placed a considerable burden on the client and testing teams. These teams are responsible for deeply familiarizing themselves with each EIP’s specifications, assessing its impact, and making informed recommendations on urgency and feasibility. Reviewing 50 complex technical specifications is a significant undertaking, requiring extensive homework and coordination.
This challenge has led to ongoing discussions about refining the EIP proposal and selection process, ensuring that the pipeline remains manageable without stifling innovation. The current strategy of narrowing down features and iteratively adding them to devnets reflects a conscious effort to balance ambitious upgrades with the practicalities of implementation and testing. The lesson learned from Glamsterdam will undoubtedly inform the planning for Hegotá and subsequent upgrades, aiming for an even smoother integration of new features.
Implications for the Ethereum Ecosystem
The continuous stream of upgrades, from Fusaka to Glamsterdam and Hegotá, carries profound implications across the entire Ethereum ecosystem:

- For Users: These upgrades translate directly into a better user experience. Fusaka’s DAS and BPO forks pave the way for significantly cheaper and faster transactions on Layer 2 networks, making dApps more accessible. Glamsterdam’s ePBS and BALs aim to reduce MEV-related costs and improve transaction fairness, while Hegotá’s FOCIL will bolster the network’s censorship resistance, providing greater assurance of transaction inclusion.
- For Developers: The evolving protocol offers new tools and primitives, enabling the creation of more sophisticated and efficient decentralized applications. However, it also requires continuous adaptation and understanding of the latest protocol changes. The clear EIP process and extensive documentation are vital resources for this community.
- For Layer 2s: The scaling improvements are a direct boon for L2 solutions like rollups. Increased blob space reduces their operational costs and enhances their throughput, further solidifying Ethereum as the premier settlement layer for a multi-chain future.
- For Validators: Changes like ePBS will fundamentally alter the block production landscape, aiming to level the playing field and reduce the potential for undue influence from large MEV extractors. This is crucial for maintaining validator decentralization and the overall health of the consensus mechanism.
- For Decentralization and Security: Each upgrade is meticulously designed to reinforce Ethereum’s core tenets of decentralization and security. From robust data availability to censorship resistance mechanisms, the network is being fortified against various threats, ensuring its long-term viability as a global, permissionless computing platform.
Conclusion
Ethereum’s development trajectory remains one of the most ambitious and impactful endeavors in the blockchain space. The successful deployment of Fusaka, bringing significant scaling improvements through Data Availability Sampling and flexible blob parameter adjustments, marks a pivotal milestone. Concurrently, the Glamsterdam upgrade is progressing with its complex headliners, enshrined Proposer Builder Separation and Block-level Access Lists, promising enhanced security and transaction fairness. Looking ahead, Hegotá is already taking shape, with Fork-choice Inclusion Lists emerging as a strong candidate to bolster censorship resistance.
The commitment of the core development community, supported by transparent communication channels like "Checkpoint" and Forkcast, ensures that Ethereum continues its relentless march towards its vision. While challenges inherent in coordinating a global, decentralized network persist, the lessons learned and the processes refined ensure that Ethereum remains at the forefront of blockchain innovation, building a more scalable, secure, and decentralized future for all.
Key Developer Discussions
(November 14th – January 19th)
- ACDT Calls: 66, 65, 64, 63, 62
- ACDC Calls: 172, 171, 170
- ACDE Calls: 228, 227, 226, 225
These calls represent the continuous, in-depth discussions that shape Ethereum’s future, accessible to the public through Forkcast for those keen to dive into the technical details.
