The world of blockchain technology is in a perpetual state of flux, and at its forefront, Ethereum continues its ambitious journey of iterative improvement and expansion. Keeping pace with the rapid advancements and intricate discussions within the Ethereum All Core Developer (ACD) calls can be a formidable task for even the most dedicated enthusiasts. This "Checkpoint" series serves as a vital compass, offering high-level updates on core development approximately every 4-8 weeks, depending on the dynamic landscape of protocol evolution. For those seeking a deeper dive, the Forkcast platform has become an indispensable resource, publishing comprehensive call summaries, chat logs, and transcripts for each ACD and breakout session, often within hours of their conclusion.
Navigating the Frontier of Core Development
Ethereum’s development philosophy is rooted in continuous innovation, driven by a decentralized community of researchers, engineers, and developers. Each upgrade, often named after stars in the IAU catalog and a significant city, represents a collaborative effort to enhance the network’s scalability, security, and decentralization. This report encapsulates the significant strides made in recent months, from the successful deployment of a major upgrade to the meticulous planning for future enhancements that promise to redefine the network’s capabilities. The progress outlined here is not merely incremental; it signifies a fundamental reshaping of how Ethereum processes transactions, ensures data availability, and fortifies itself against emergent challenges.
Main Facts: A Snapshot of Progress
The period under review has been marked by several pivotal developments and strategic decisions that underscore Ethereum’s unwavering commitment to its long-term roadmap.
Firstly, the Fusaka upgrade has successfully shipped, introducing crucial scaling capabilities through Data Availability Sampling (DAS). This marked a significant step towards enabling more efficient and secure data handling for Layer 2 solutions. Alongside Fusaka, the network gained the unprecedented ability to adjust blob parameters independently from major fork cycles, a testament to its evolving agility.
Secondly, the next major upgrade, Glamsterdam, is now fully scoped. Progress is actively underway on its two ambitious headliner features: enshrined Proposer-Builder Separation (ePBS) and Block-level Access Lists (BALs). These features are designed to address critical issues related to censorship resistance, MEV (Maximal Extractable Value), and transactional efficiency.
Finally, the subsequent upgrade, tentatively named Hegotá, has officially opened its proposal window for major features. Key proposals, including Fork-choice Inclusion Lists (FOCIL) for enhanced censorship resistance, are currently being evaluated, with a definitive proposal deadline set for February 4th. This structured approach to feature selection ensures community input and rigorous technical assessment.
Chronology of Innovation: From Deployment to Deliberation
The past few months have been a whirlwind of activity, characterized by the deployment of a critical upgrade, the refinement of scaling mechanisms, and the meticulous planning for future enhancements.
Fusaka’s Triumph: Scaling with Data Availability Sampling
Since the previous Checkpoint update, the Fusaka upgrade successfully went live, marking a significant milestone in Ethereum’s scaling journey. At its core, Fusaka introduced Data Availability Sampling (DAS), a groundbreaking technology formalized in EIP-7594, also known as PeerDAS.
Data Availability Sampling is a crucial component of Ethereum’s long-term sharding roadmap, often referred to as "The Surge." Before sharding can fully realize its potential for massive transaction throughput, the network needs a robust mechanism to ensure that data posted by Layer 2 rollups is indeed available to all participants. Without DAS, verifying the availability of data across numerous shards would require every node to download all data from all shards, an infeasible task that would centralize the network. PeerDAS addresses this by allowing light clients to verify data availability by sampling only small portions of the data, drastically reducing their computational burden while maintaining cryptographic guarantees. This mechanism is vital for the security and efficiency of rollups, which rely on the underlying Layer 1 to provide a secure base for their operations.
The significance of Fusaka and PeerDAS was widely recognized across the Ethereum ecosystem. Both the official @ethereum Twitter account and co-founder Vitalik Buterin took to social media to elaborate on the technical intricacies of PeerDAS, emphasizing why secure scaling is paramount for the network’s long-term viability and how these improvements integrate into the grander vision of a highly scalable, decentralized blockchain. These communications highlighted the critical role PeerDAS plays in laying the groundwork for future sharding phases, ensuring that as Ethereum scales, it does so without compromising its core tenets of decentralization and security.
Agile Scaling with Blob Parameter Only (BPO) Forks
A particularly innovative development integrated with the Fusaka upgrade was the realization of Blob Parameter Only (BPO) forks. This new capability represents a significant leap in Ethereum’s flexibility, allowing core developers to adjust the number of "blobs" per block independently of the larger, more infrequent network upgrade cycles. Blobs, or "data blobs," are a type of transaction data introduced with the Dencun upgrade (specifically EIP-4844) designed to provide a dedicated, cheaper space for Layer 2 (L2) rollups to post their transaction data to the mainnet. By offering this separate data channel, blobs significantly reduce the cost of L2 transactions, making rollups more competitive and accessible.
The ability to conduct BPO forks means Ethereum can now scale its data availability layer "as needed" in response to demand from L2 usage, without the overhead and coordination complexity of a full network hard fork. The first two BPO forks were successfully stress-tested and formally incorporated into the Fusaka upgrade. The first BPO fork went live just days after Fusaka’s activation, with the second following in early January. These initial adjustments successfully increased the network’s capacity for L2 data. Ethereum now targets 14 blobs per block and allows for a maximum of 21, representing a substantial 2.3x increase in L2 data space compared to the pre-Fusaka era. This translates directly to lower transaction fees and greater throughput potential for applications built on Layer 2 networks.
Despite the proven success of these initial BPO forks, core developers have indicated that a third BPO fork is not an immediate priority. The consensus is to monitor current blob usage trends and await a natural uptick in demand before further expanding the capacity. This pragmatic approach ensures that development resources are allocated efficiently, focusing on areas where immediate scaling is most critical.
Glamsterdam on the Horizon: Enshrined PBS and Block-level Access Lists
Looking ahead, the next major network upgrade, Glamsterdam, is fully scoped and development is actively progressing. This fork is set to introduce two monumental headliner features: enshrined Proposer-Builder Separation (ePBS) and Block-level Access Lists (BALs).
Enshrined Proposer-Builder Separation (ePBS) is a highly anticipated protocol change aimed at mitigating the risks associated with Maximal Extractable Value (MEV) and enhancing censorship resistance. In the current model, a single validator (the proposer) is responsible for both building and proposing a block. This gives the proposer significant power over transaction ordering and inclusion, leading to opportunities for MEV extraction that can centralize power and potentially lead to censorship. ePBS separates these roles: "builders" construct optimal blocks by aggregating transactions and MEV, and "proposers" then select the best block from a competitive marketplace of builder bids, without knowing its contents beforehand. This separation aims to democratize block production, reduce the potential for malicious MEV practices, and make it significantly harder for a single entity to censor transactions. Given its fundamental impact on the block production mechanism, ePBS is a complex undertaking, requiring extensive research, specification, and testing.
Block-level Access Lists (BALs), on the other hand, are designed to improve transaction processing efficiency. While the exact details can vary, the general idea behind access lists is to allow transactions to declare the state they intend to access (e.g., specific storage slots or contract addresses). This pre-computation hint can enable clients to more efficiently execute and verify transactions, potentially leading to lower gas costs and improved network performance.
Progress on both features is moving along, though ePBS, due to its inherent complexity and impact on core protocol mechanics, is a much larger and more challenging change than BALs. Consequently, while BALs already boast active development networks (devnets) for testing and refinement, an ePBS devnet is still some time away.
Glamsterdam Timeline
As with all major network upgrades, the headliner features — ePBS and BALs — must first reach a stable state on dedicated devnets before additional EIPs can be integrated. The initial phase involves isolating these complex changes to ensure their robust implementation. Core developers faced the daunting task of sifting through an initial pool of approximately 50 proposed non-headlining features for Glamsterdam. Through rigorous evaluation and prioritization, this list has been meticulously refined to a more manageable set of 17 "Considered" features. These features are deemed either necessary for the network’s health or possess a high impact-to-complexity ratio.
The plan is to progressively add these "Considered" features to devnets in small, controlled sets. This iterative approach allows client and testing teams to thoroughly evaluate each EIP’s compatibility and performance without overwhelming the development process. If any feature proves problematic or threatens to unduly delay the overall fork, developers retain the flexibility to remove it from the "Considered" set. The full list of these features is detailed in relevant EIPs and discussion forums. A more precise timeline for Glamsterdam’s activation is expected once a stable ePBS devnet is established, and further clarity will emerge as each "Considered" EIP successfully undergoes devnet testing.
Charting the Course for Hegotá: Censorship Resistance and Beyond
Following Glamsterdam, the subsequent network upgrade, previously referred to as "H-star," has officially been named Hegotá. The name underwent a slight modification from its initial proposal of "Heka." A community developer noted that "Heka" is not listed in the International Astronomical Union (IAU) catalog, which all previous star names for Ethereum upgrades have traditionally adhered to. Consequently, the star name was changed to "Heze," which, when combined with the city "Bogotá," forms the new upgrade name: Hegotá.
FOCIL: A Headliner for Censorship Resistance
A prominent feature that has gained significant traction for Hegotá is Fork-choice Inclusion Lists (FOCIL). FOCIL is a crucial mechanism designed to bolster censorship resistance on the Ethereum network. Initially considered for Glamsterdam, FOCIL was strategically moved to Hegotá to reduce the scope and complexity of the upcoming Glamsterdam fork. This decision reflects its inherent complexity and the desire to give it adequate focus.
FOCIL aims to prevent malicious proposers from censoring specific transactions or even entire blocks by ensuring that a predefined list of transactions is included in the block’s canonical chain selection process. This mechanism is particularly vital in a world where MEV extraction and sophisticated actors could potentially lead to transaction exclusion or ordering biases. Its strong support among core developers and the broader Ethereum community underscores the network’s commitment to maintaining its open and permissionless nature.
FOCIL is a cross-layer EIP, meaning its implementation touches both the consensus layer (responsible for block validation and finality) and the execution layer (responsible for transaction processing), particularly impacting the Engine API that facilitates communication between these layers. This cross-layer nature adds to its complexity and requires careful coordination among different client teams. As of this report, FOCIL is in a "Considered" status for Hegotá and is being evaluated alongside other potential headliner proposals, with at least one other competing proposal currently on the table. A comprehensive overview of FOCIL and its readiness for Hegotá can be found on the Ethereum Magicians forum.
Hegotá Timeline
The roadmap for Hegotá’s feature selection is clearly delineated, emphasizing community participation and a structured decision-making process:
- January 8th – February 4th: This current window is dedicated to the submission of Headliner Proposals. Any interested party can propose a major feature for Hegotá using the template provided on the Ethereum Magicians forum.
- February 5th – February 26th: Following the proposal deadline, a dedicated period will commence for Headliner Discussion & Finalization. During this time, proposers will present their features on ACD calls, and community feedback will be actively solicited. The goal is to reach a consensus and finalize Hegotá’s headlining features by February 26th.
- 30 days following headliner decision (Deadline TBD): Once the main features are decided, a window will open for Non-Headliner EIP Proposals. A specific deadline for these proposals will be announced, and interested parties are encouraged to keep a close watch on Checkpoint updates. Similar to headliners, anyone can propose a non-headliner, provided they are willing to actively champion it through the intricate development process.
Supporting Data: The Metrics of Progress
The quantitative data emerging from Ethereum’s core development reflects both impressive progress and the inherent challenges of building a global-scale decentralized network. The successful deployment of the first two BPO forks, resulting in a 2.3x increase in L2 data space and the capacity to handle 14 blobs per block (with a maximum of 21), is a tangible metric of enhanced scalability. This directly translates to reduced data posting costs for rollups, making Ethereum’s L2 ecosystem more attractive and competitive.
The journey of refining Glamsterdam’s scope from 50 initial non-headliner EIP proposals down to 17 "Considered" features highlights the immense workload on client and testing teams. Each EIP requires thorough review, understanding of its implications, and often, initial implementation efforts. Reducing this number by nearly two-thirds allows for more focused development, faster iteration, and a higher probability of a timely and stable fork. This metric underscores the importance of a clear, disciplined EIP process and the dedication required from core developers.
Furthermore, the public availability of detailed call summaries, chats, and transcripts on Forkcast for All Core Dev (ACD) calls (ACDT, ACDC, ACDE) provides an unprecedented level of transparency and supporting data for the community. These resources enable anyone to delve into the nuanced discussions, technical debates, and decisions that shape Ethereum’s future, reinforcing the network’s commitment to open governance and collaborative development.
Official Responses and Community Engagement
The discourse surrounding Ethereum’s upgrades is a testament to its vibrant and highly engaged community. The official @ethereum Twitter account and Vitalik Buterin’s posts explaining PeerDAS, secure scaling, and the fit of these improvements within the broader roadmap serve as crucial "official responses." These communications are designed to demystify complex technical concepts for a wider audience, ensuring that the rationale behind major protocol changes is understood beyond the core development circle. They act as public endorsements and educational tools, fostering broader understanding and support.
The heart of Ethereum’s decision-making lies within the All Core Developer (ACD) calls (ACDT, ACDC, ACDE). These regular meetings are where technical specifications are debated, implementation challenges are discussed, and consensus is forged. The rigorous process for incorporating new features, known as Ethereum Improvement Proposals (EIPs), is a structured and transparent one, guided by EIP-1 and detailed in the 2026 guide to championing an EIP. An EIP must be thoroughly specified, proposed during designated windows, and then actively championed by a technical point-of-contact who guides it through the various stages of review, feedback, and eventual implementation.
The experience with Glamsterdam’s non-headliner proposals vividly illustrates both the strengths and challenges of this community-driven process. The sheer volume of 50 initial proposals for Glamsterdam was described as "an absolute beast" for the core developers and client teams. This surge in proposals can be attributed to several factors: an increasing number of high-context participants entering the ecosystem, and a growing clarity in the EIP proposal process itself, which now better defines when and how features should be proposed. While a testament to the community’s innovation, this volume created a significant workload for client and testing teams, who are responsible for familiarizing themselves with each proposal, assessing its feasibility, and making recommendations based on urgency and impact. Evaluating 50 complex technical specifications demands considerable time and intellectual effort.
Looking ahead to Hegotá, the expectation is for a healthy competition among headliner proposals, notably FOCIL, and proposals for encrypted mempools. The complexity of FOCIL, being a cross-layer EIP that intertwines the consensus and execution layers, particularly through the Engine API, makes its pairing with other complex features challenging. There has also been ongoing discussion around the potential inclusion of 6-second slots (EIP-7782) – a proposal to significantly reduce block times – though it remains unclear whether this will be proposed for Hegotá or reserved for a later "I-star" upgrade. The core developers actively encourage community members to participate in the February discussion period, emphasizing that active support for preferred major features can significantly influence their selection for the next upgrade. This underscores the truly decentralized and participatory nature of Ethereum’s evolution.
Implications for the Ethereum Ecosystem
The ongoing developments within Ethereum’s core protocol have profound implications across the entire ecosystem, touching everything from user experience to the foundational security and decentralization of the network.
Enhanced Scalability and Reduced Costs for Layer 2s
The most immediate and tangible implication of the Fusaka upgrade and the subsequent Blob Parameter Only (BPO) forks is a significant boost to the scalability and cost-effectiveness of Layer 2 (L2) solutions. By introducing Data Availability Sampling (DAS) via PeerDAS, Fusaka has laid critical groundwork for a future of massively sharded Ethereum, where L2s can confidently and securely post their data to the mainnet. The 2.3x increase in dedicated L2 data space through BPO forks directly translates to lower transaction fees for users interacting with applications on rollups. As L2s become cheaper and more efficient, they can attract a wider user base, fostering innovation and adoption within the broader decentralized application (dApp) landscape. This iterative scaling ensures that Ethereum can handle growing demand without succumbing to prohibitive costs or network congestion, effectively offloading transactional burden while maintaining L1 security.
Strengthening Decentralization and Censorship Resistance
The features slated for Glamsterdam and Hegotá directly address core tenets of Ethereum’s philosophy: decentralization and censorship resistance. Enshrined Proposer-Builder Separation (ePBS) in Glamsterdam is a monumental step towards combating the centralization pressures arising from Maximal Extractable Value (MEV). By separating the block production process, ePBS aims to dilute the power of individual validators, making it harder for any single entity to influence transaction ordering or exclude transactions for profit. This move is critical for maintaining a fair and equitable transaction environment.
Similarly, Fork-choice Inclusion Lists (FOCIL) for Hegotá are a direct response to concerns about censorship at the protocol level. By giving the network a mechanism to ensure the inclusion of specific transactions, FOCIL fortifies Ethereum’s resilience against attempts to censor legitimate activity. These developments underscore Ethereum’s proactive stance in safeguarding its foundational principles, ensuring that the network remains a neutral and open platform for all.
Developer Experience and Protocol Evolution
For developers, these upgrades present both challenges and opportunities. The rigorous EIP process and the reduction of Glamsterdam’s non-headliner features from 50 to 17 demonstrate a maturing development pipeline. While the sheer volume of initial proposals highlights the vibrant innovation within the community, the strategic reduction signifies a focus on impact and feasibility, ensuring that client and testing teams are not overwhelmed. This iterative process of proposing, debating, and implementing EIPs requires dedicated "champions" who shepherd their proposals through the technical and social layers of development. This collaborative, yet demanding, environment fosters robust solutions but also necessitates a deep understanding of the protocol and a commitment to seeing changes through. The ongoing conversations around features like 6-second slots or encrypted mempools showcase the continuous exploration of new avenues for performance and privacy, constantly pushing the boundaries of what Ethereum can achieve.
The Long-Term Vision: The Road Ahead
These upgrades are not isolated events but integral components of Ethereum’s ambitious long-term roadmap, often conceptualized as "The Surge," "The Verge," "The Purge," and "The Splurge." Fusaka’s DAS lays the groundwork for sharding ("The Surge"). Glamsterdam’s ePBS is a critical step towards enhancing security and decentralization ("The Scourge" and aspects of "The Verge"). Hegotá’s FOCIL further solidifies censorship resistance, aligning with the network’s commitment to robust security. Each upgrade incrementally builds upon the last, moving Ethereum closer to its vision of a highly scalable, secure, and decentralized global computing platform. This continuous, community-driven evolution is what defines Ethereum, ensuring its adaptability and relevance in a rapidly changing technological landscape.
Staying Informed: Key Resources
For those wishing to stay abreast of Ethereum’s core development, the "Checkpoint" series remains an invaluable high-level overview. For deeper engagement, the Forkcast platform offers unparalleled access to the intricacies of ACD calls through its timely summaries, chat logs, and transcripts. The Ethereum Magicians forum is the primary venue for EIP discussions and proposals, offering a direct channel for community input.
The following All Core Developer calls are particularly relevant for understanding the updates covered in this report, spanning from November 14th to 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 resources provide a window into the collaborative and technically intensive environment where the future of Ethereum is meticulously crafted.
Conclusion: Ethereum’s Unwavering Trajectory
The journey of Ethereum’s core development is a testament to the power of decentralized collaboration and a long-term vision. From the successful deployment of the Fusaka upgrade, bringing crucial data availability scaling to the network, to the strategic flexibility introduced by Blob Parameter Only forks, Ethereum continues to refine its capabilities. The meticulous planning for Glamsterdam, with its ambitious ePBS and BALs, and the structured initiation of Hegotá, focusing on critical censorship resistance mechanisms like FOCIL, demonstrate a clear and determined trajectory.
As the network progresses through these named upgrades, each step contributes to a more scalable, secure, and decentralized blockchain. The challenges of coordinating a global developer community and evaluating complex technical proposals are met with transparent processes and a commitment to community input. Ethereum’s evolution is not just about technological advancement; it’s about building a robust and resilient digital infrastructure that can serve as a foundational layer for a decentralized future. The ongoing efforts underscore a powerful message: Ethereum is not just adapting to the future; it is actively building it.
