London, UK – [Date of publication, e.g., January 25, 2025] – The world of Ethereum core development is a dynamic and intricate landscape, constantly evolving at a rapid pace. For those seeking to keep abreast of the foundational changes shaping the future of decentralized technology, the All Core Developer (ACD) calls serve as the pulse of innovation. Recognizing the complexity and sheer volume of these discussions, the "Checkpoint" series emerges as an indispensable guide, offering high-level updates roughly every 4-8 weeks to distill the most critical advancements. This latest installment sheds light on monumental milestones achieved, ongoing endeavors, and the ambitious roadmap ahead, underscored by a renewed commitment to scaling, security, and decentralization.
In a significant boon for transparency and community engagement, Forkcast has emerged as a vital resource, now providing comprehensive summaries, chat logs, and full transcripts for each All Core Dev (ACD) call and various breakout sessions. These invaluable resources are typically made available within hours of the calls concluding, democratizing access to the deepest technical discussions that drive Ethereum’s progress.
TL;DR: A Snapshot of Progress
The past few months have been nothing short of transformative for the Ethereum ecosystem. The Fusaka upgrade has successfully shipped, marking a pivotal moment in the network’s scaling journey by introducing Data Availability Sampling. Complementing this, Ethereum now boasts the ability to adjust blob parameters independently from traditional fork cycles, a critical enhancement for Layer 2 (L2) scalability. Looking ahead, the next major upgrade, Glamsterdam, is fully scoped, with development progressing steadily on its headline features. Beyond Glamsterdam, the architectural blueprint for Hegotà, the subsequent upgrade, is beginning to take shape, with proposals for its major features actively being solicited until February 4th. This iterative, community-driven approach ensures Ethereum’s continuous evolution, adapting to emergent needs and pushing the boundaries of blockchain technology.
The Fusaka Leap: Bolstering Scalability with Data Availability Sampling
Since the last "Checkpoint" update, the Ethereum network successfully activated the Fusaka upgrade, a landmark event that dramatically advanced the network’s scaling capabilities. The centerpiece of Fusaka is the implementation of Data Availability Sampling (DAS), specifically in the form of PeerDAS (Peer-to-Peer Data Availability Sampling). This innovative technology is crucial for the long-term vision of Ethereum, particularly in supporting the burgeoning ecosystem of Layer 2 solutions.
Data Availability Sampling allows nodes to verify the availability of large blocks of data without needing to download the entire block. Instead, nodes sample small, random portions of the data. If enough nodes can successfully sample their assigned portions, it provides a high statistical probability that the entire block’s data is available. This mechanism is paramount for rollups (a type of L2 solution), which post transaction data back to the Ethereum mainnet. By ensuring that this data is readily available for anyone to reconstruct the state of the L2, DAS provides the security guarantees necessary for rollups to operate trustlessly and efficiently.
The significance of PeerDAS was widely echoed across official Ethereum channels. Both the official @ethereum Twitter account and co-founder Vitalik Buterin took to social media to elaborate on the technical intricacies and profound implications of this upgrade. The discussions highlighted not only how PeerDAS works but also why scaling securely is an absolute imperative for Ethereum’s future. Buterin, in particular, contextualized these improvements within the broader roadmap, emphasizing how each upgrade incrementally builds towards a more robust, decentralized, and scalable global computing platform. Fusaka, therefore, isn’t just an upgrade; it’s a foundational step towards enabling Ethereum to handle orders of magnitude more transactions, fostering a vibrant and accessible decentralized internet.
Agile Scaling: The Strategic Implementation of Blob Parameter Only (BPO) Forks
One of the most impactful, yet perhaps less visible, advancements to emerge recently is the operationalization of Blob Parameter Only (BPO) forks. This innovative mechanism empowers Ethereum to adjust critical blob parameters – the dedicated data space for Layer 2 transactions – independently from the comprehensive, time-consuming cycles of full network upgrades. This flexibility marks a significant strategic shift, allowing the network to adapt its scaling capacity with unprecedented agility, directly responding to the demands of L2 usage.
Blobs, formally known as "data blobs" introduced with the Dencun upgrade, provide a cost-effective way for L2s to post transaction data to the Ethereum mainnet. Prior to BPO forks, any adjustment to the number of blobs per block would necessitate a full network hard fork, a process requiring extensive coordination, testing, and deployment across all client teams. This rigid structure meant that increasing L2 data space could only happen at predetermined intervals, potentially creating bottlenecks if L2 adoption surged unexpectedly.
With BPO forks now a reality, Ethereum has demonstrated its ability to fine-tune its data availability layer on the fly. The first two BPO forks were successfully stress-tested and integrated into the Fusaka upgrade, with the initial adjustment going live just days after Fusaka’s main activation, and a subsequent increase implemented in early January. These adjustments have significantly expanded the data throughput capacity for L2s. The network now targets 14 blobs per block and allows for a maximum of 21, representing a remarkable 2.3x increase in available L2 data space compared to the pre-Fusaka era. This expansion directly translates to lower transaction fees and increased throughput for users interacting with applications on Layer 2 networks.
Despite the proven success of these initial BPO forks, core developers have adopted a prudent approach. Discussions have centered on the technical readiness for a potential third BPO fork, but a consensus was reached that further increases are not a top priority at this moment. The current strategy is to monitor blob usage closely, ensuring that the existing capacity is adequately utilized before introducing additional changes. This ensures that network resources are allocated efficiently and that adjustments are driven by real-world demand rather than speculative expansion. This measured approach underscores the maturity of Ethereum’s development process, balancing rapid innovation with stability and resource optimization.
Glamsterdam on the Horizon: Enshrining Key Protocol Enhancements
As the network celebrates the successful deployment of Fusaka and the newfound flexibility of BPO forks, attention is now firmly fixed on the next major network upgrade: Glamsterdam. This upcoming fork is poised to introduce two significant protocol enhancements: enshrined Proposer-Builder Separation (ePBS) and Block-level Access Lists (BALs), both of which are critical for enhancing network decentralization, mitigating Maximal Extractable Value (MEV), and improving transaction predictability.
Enshrined Proposer-Builder Separation (ePBS) is arguably the more complex of the two headliners. Its primary goal is to decentralize block production and mitigate the centralizing pressures of MEV. Currently, block proposers (validators) can also act as block builders, creating opportunities for them to extract MEV by reordering, censoring, or including specific transactions. ePBS aims to separate these roles, allowing specialized "builders" to construct blocks and submit bids to "proposers" (validators), who then select the highest-bidding valid block without necessarily knowing its contents. This separation is "enshrined" because it’s built directly into the protocol, rather than relying on external, off-chain solutions like the current MEV-Boost. While ePBS promises significant benefits for network health and fairness, its implementation involves deep changes to the consensus layer, making its development and testing a formidable task. Consequently, while substantial progress is being made, a full devnet for ePBS is still some time away.
In contrast, Block-level Access Lists (BALs), while also a significant improvement, present a comparatively less complex implementation challenge. BALs aim to improve transaction predictability and potentially reduce MEV by allowing transaction senders to specify the state slots their transaction will access. This provides a clearer picture to block builders about a transaction’s resource usage, potentially enabling more efficient block construction and reducing the need for speculative transaction inclusion. The development of BALs is notably further along, with dedicated devnets (developer networks) already active and undergoing rigorous testing. This head start allows developers to iron out kinks and ensure stability ahead of the broader Glamsterdam integration.
The journey to Glamsterdam also highlights the rigorous process of EIP (Ethereum Improvement Proposal) selection. Initially, a staggering 50 non-headlining features were proposed for inclusion in Glamsterdam. This large volume, while a testament to the vibrant developer community, presented a significant challenge for client and testing teams. The monumental task of reviewing, understanding, and making informed recommendations on so many diverse proposals was described by developers as an "absolute beast." Through diligent effort and collaborative discussion, this extensive list has been meticulously whittled down to a more manageable set of 17 necessary and high-impact features. This rigorous vetting ensures that only the most critical and well-vetted EIPs are considered, preventing scope creep and potential delays.
The timeline for Glamsterdam remains dynamic, contingent on the stability of development efforts. As with every major fork, the headlining features – ePBS and BALs – must first reach a stable state on dedicated devnets. Only after this foundational stability is achieved can the additional "Considered" EIPs be incrementally added and tested in small sets. This iterative approach allows for granular debugging and minimizes the risk of introducing unforeseen issues. Developers are acutely aware that if any of these supplementary features prove problematic or risk unduly delaying the overall fork, they may be removed from the "Considered" set and deferred to a future upgrade. The full list of these "Considered" features is available for community review, emphasizing transparency in the selection process. A more definitive timeline for Glamsterdam is expected to emerge once a stable ePBS devnet is established, followed by even greater clarity as each EIP undergoes comprehensive testing within a devnet environment.
Peering into the Future: The Hegotà Upgrade and its Headliner Contenders
Beyond Glamsterdam, the Ethereum community is already laying the groundwork for the next major network upgrade, provisionally named Hegotà. The naming convention itself underwent a slight adjustment: the initial H-star name, Heka, was replaced with Heze after a community developer astutely pointed out that "Heka" is not listed in the International Astronomers Union (IAU) catalog, which serves as the traditional source for star names in Ethereum’s upgrade nomenclature. The final name, Hegotà, is a portmanteau of Heze and Bogotá, adhering to the established convention of combining a star name with a city from a past Devcon location.
The primary focus for Hegotà is the selection of its headlining features, and a key contender that has garnered significant support is Fork-choice Inclusion Lists (FOCIL). FOCIL is a crucial censorship resistance mechanism, designed to prevent validators from arbitrarily excluding transactions from blocks. It was initially considered for Glamsterdam but was strategically moved to Hegotà to manage the scope and complexity of the upcoming fork. Given its strong backing from core developers and the broader Ethereum community, FOCIL is currently in "Considered" status for Hegotà, undergoing evaluation alongside any other headliner proposals. Its cross-layer nature, touching both the consensus and execution layers (particularly the engine API), makes it a complex feature to implement, necessitating careful consideration when paired with other significant changes.
As of the current "Checkpoint," FOCIL is not without competition. There is at least one other formal proposal vying for headliner status, and ongoing conversations hint at additional potential contenders. These include discussions around encrypted mempools, another mechanism aimed at combating censorship and MEV by shielding transaction contents until they are included in a block, and the intriguing prospect of 6-second slots, which would halve the current block time and significantly increase transaction throughput. However, it remains unclear whether 6-second slots will be formally proposed for Hegotà or reserved for a later "I-star" upgrade. The active proposal period underscores the open and meritocratic nature of Ethereum’s development, where diverse ideas are welcomed and rigorously debated.
The timeline for proposing and finalizing Hegotà’s headlining features is clearly defined, encouraging broad community participation:
- January 8th – February 4th: This is the current window for Headliner proposals. Anyone with a well-researched and specified Ethereum Improvement Proposal (EIP) that could serve as a major feature for Hegotà is encouraged to submit it using the template provided on the Ethereum Magicians forum.
- February 5th – February 26th: Following the proposal deadline, the submitted headliner EIPs will be presented and discussed during ACD calls. Proposers will have the opportunity to articulate their features, and the community will be invited to provide feedback and engage in rigorous debate. The goal is to reach a collective decision on Hegotà’s headlining features by February 26th.
- 30 days following headliner decision (deadline TBD): Once the major features are finalized, a subsequent window will open for proposals of non-headlining EIPs. These smaller, yet still impactful, improvements will further refine and optimize the network. Specific deadlines for these proposals will be announced, so continuous engagement with "Checkpoint" updates is advised. Like headliner proposals, anyone can champion a non-headliner EIP, provided they are willing to see it through the rigorous development and testing process.
Active community involvement during these periods is crucial. Whether it’s lending support to an existing proposal or championing a new one, the collective voice of the Ethereum ecosystem plays a significant role in shaping the network’s future.
Navigating the Protocol: The Ethereum Improvement Proposal (EIP) Process
For those who have ever wondered how a desired feature makes its way into the core Ethereum protocol, the process is formalized through Ethereum Improvement Proposals (EIPs). This structured methodology ensures that all proposed changes are thoroughly documented, reviewed, and vetted by the broader community and core developers. A comprehensive guide, "2026 championing an EIP," outlines the detailed steps involved in shepherding a feature from concept to implementation.
The journey begins with the initial specification of a proposed feature, meticulously crafted according to the guidelines set forth in EIP-1, the foundational document that defines the EIP process itself. Once specified, an EIP is proposed during a designated window, such as the current one for Hegotà headliners. Crucially, each EIP requires a "champion" – a technical point-of-contact who is committed to driving the proposal through its various stages, answering questions, addressing concerns, and coordinating with client teams.
The recent experience with Glamsterdam highlighted both the strengths and challenges of this open process. The sheer volume of 50 proposed non-headliner features for Glamsterdam was, by all accounts, an "absolute beast" for the development ecosystem. This surge in proposals can be attributed to several factors: an increasing number of high-context participants within the community, and a growing clarity in the EIP process itself, which has empowered more developers to understand when and how to propose their features effectively.
However, this increased participation comes with a significant workload for client and testing teams. These teams are ultimately responsible for implementing and validating any proposed changes. They must familiarize themselves intimately with each EIP’s specification, assess its technical feasibility, identify potential risks, and make informed recommendations regarding its urgency and impact. Reviewing 50 complex technical specifications to make such critical decisions demands an immense amount of "homework" and collaborative effort. This intensive process underscores the necessity of the rigorous vetting that reduced Glamsterdam’s non-headliner list to a more manageable 17 features.
Looking ahead to Hegotà, the expectation is for more headliner proposals to emerge, competing with established contenders like FOCIL and encrypted mempools. The complexity of cross-layer EIPs like FOCIL, which impact both the consensus and execution layers, presents unique challenges when paired with other significant changes. The discussions around proposals like 6-second slots, while promising for throughput, must also consider their implications on network stability and decentralization. Regardless of individual preferences, the February discussion period for Hegotà headliners will be a critical juncture. Active community engagement and vocal support for preferred features will be instrumental in shaping the final decisions, ensuring that Ethereum’s future reflects the collective vision of its diverse ecosystem.
Relevant ACD Calls: A Glimpse into the Discussions
For those who wish to delve deeper into the specific discussions that have shaped these updates, the following All Core Developer calls provide comprehensive insights into the period between November 14th and January 19th:
ACDT (All Core Developers – Technical):
ACDC (All Core Developers – Consensus Layer):
ACDE (All Core Developers – Execution Layer):
These calls represent the raw, unvarnished dialogue among the brilliant minds dedicated to advancing Ethereum. Reviewing their summaries and transcripts offers an unparalleled understanding of the technical challenges, proposed solutions, and strategic decisions that define the network’s evolution.
Implications and the Road Ahead
The progress outlined in this "Checkpoint" update vividly illustrates Ethereum’s unwavering commitment to its ambitious roadmap. The successful activation of Fusaka and the agile capabilities introduced by BPO forks represent significant strides in "The Surge" phase, dramatically enhancing the network’s scalability and laying the groundwork for a future where L2s can thrive with unprecedented efficiency and lower costs.
Looking towards Glamsterdam, the focus on ePBS and BALs signifies a deep dive into "The Scourge" and "The Verge" phases, addressing critical issues of decentralization, MEV mitigation, and transaction fairness. These are not merely technical upgrades but fundamental shifts aimed at preserving Ethereum’s core values in an increasingly complex and competitive landscape. The meticulous process of EIP selection and rigorous devnet testing reflects a mature development paradigm, prioritizing network stability and security above all else.
Finally, the early planning for Hegotà, with the active solicitation of headliner proposals like FOCIL, underscores the continuous forward momentum. This proactive approach ensures that Ethereum remains at the forefront of blockchain innovation, constantly adapting to new challenges and seizing new opportunities. The transparent and community-driven EIP process, despite its inherent complexities, empowers a global network of contributors to shape a truly decentralized future. As Ethereum continues its journey through "The Purge" and "The Splurge" – phases focused on streamlining and optimizing the protocol – these iterative upgrades are foundational, propelling the network closer to its vision of a global, scalable, and resilient decentralized operating system. Staying informed and engaged with these developments is not just for developers; it’s essential for anyone who believes in the transformative power of a decentralized web.
