Layla Zulfa
Ethereum’s core development ecosystem continues its relentless march towards a more scalable, secure, and decentralized future, as highlighted by the latest "Checkpoint" series update. This periodic briefing, designed to distill the complexities of All Core Developer (ACD) calls into high-level summaries, reveals significant milestones achieved and ambitious plans underway. The network has successfully deployed the Fusaka upgrade, introducing critical data availability enhancements and flexible blob parameter adjustments. Concurrently, the next major upgrade, Glamsterdam, is firmly scoped with development progressing on its transformative features, while the subsequent upgrade, Hegotá, is now entering its crucial proposal phase for headlining features, with a deadline set for February 4th. These developments underscore the robust and dynamic nature of Ethereum’s ongoing evolution, driven by a global community of developers committed to advancing the blockchain’s foundational capabilities.
The Successful Rollout of the Fusaka Upgrade and Data Availability Sampling
A cornerstone achievement since the last "Checkpoint" update is the successful activation of the Fusaka upgrade. This significant network enhancement brought Data Availability Sampling (DAS), specifically PeerDAS (EIP-7594), to the Ethereum mainnet. The implementation of DAS is a pivotal step in Ethereum’s long-term scaling roadmap, often referred to as "The Surge." Prior to DAS, the scalability of Layer 2 (L2) rollups was constrained by the amount of data they could post to the Ethereum mainnet, which was necessary to ensure the integrity and verifiability of their transactions. By enabling data availability sampling, Fusaka allows the network to process and store significantly more data more efficiently, a prerequisite for future sharding implementations.
The importance of this upgrade was amplified by official communications from the Ethereum Foundation and prominent figures like Vitalik Buterin, who took to social media platforms to elucidate the technical intricacies and broader implications of PeerDAS. These explanations emphasized why secure scaling is paramount for Ethereum’s sustained growth and how these improvements integrate into the grand vision for the network. Secure scaling, in this context, means expanding transaction throughput without compromising the network’s fundamental security guarantees or increasing the burden on individual nodes. The Fusaka upgrade, therefore, not only bolsters the current capabilities of L2 solutions but also lays essential groundwork for further advancements in data management and network sharding, ultimately aiming to support a global-scale decentralized internet. This move is expected to alleviate data congestion, potentially leading to lower transaction costs for users interacting with L2s and foster a more vibrant ecosystem of decentralized applications.
Dynamic Scaling with Blob Parameter Only (BPO) Forks
Complementing the Fusaka upgrade’s data availability improvements, Ethereum has also introduced and successfully implemented Blob Parameter Only (BPO) forks. This innovative mechanism allows for the adjustment of blob parameters independently of a full network fork cycle, providing an agile response to the evolving demands of Layer 2 usage. Blobs, introduced in the Dencun upgrade, provide dedicated data space for rollups on the Ethereum mainnet, significantly reducing their transaction costs compared to using traditional calldata.
The flexibility offered by BPO forks is a testament to the core developers’ proactive approach to scaling. The first two BPO forks were rigorously stress-tested and integrated into the Fusaka release, with subsequent activations occurring shortly after Fusaka’s launch and in early January. These adjustments have resulted in a remarkable 2.3x increase in the available data space for L2s compared to pre-Fusaka levels. Currently, Ethereum targets 14 blobs per block, with a maximum capacity of 21. This substantial increase directly benefits L2 networks by providing more cost-effective data storage, which in turn translates to lower fees and faster transaction finality for end-users on these scaling solutions.
During recent core developer discussions, the possibility of a third BPO fork was raised. However, a consensus emerged that further increases in blob capacity would not be prioritized until existing capacity is more fully utilized. This pragmatic approach ensures that development resources are allocated efficiently, responding to actual network demand rather than pre-empting it unnecessarily. This dynamic adjustment capability highlights Ethereum’s commitment to optimizing its resources and adapting to the real-world needs of its growing ecosystem.
Progress Towards the Glamsterdam Upgrade: ePBS and BALs at the Forefront
As the network celebrates the successes of Fusaka and BPO forks, attention is now firmly fixed on the next major upgrade: Glamsterdam. This ambitious fork is fully scoped, with active development underway on its two primary features: enshrined Proposer Builder Separation (ePBS) and Block-level Access Lists (BALs).
Enshrined Proposer Builder Separation (ePBS) represents a monumental architectural shift for Ethereum’s consensus layer. Its primary goal is to mitigate the centralization risks and potential for censorship associated with Maximal Extractable Value (MEV) extraction. Currently, validators have significant control over block content, allowing them to capture MEV by reordering, including, or excluding transactions. ePBS aims to separate the roles of "proposer" (who proposes a block) and "builder" (who constructs the block’s contents). This separation would introduce a marketplace for block production, where builders compete to create the most profitable blocks, and proposers simply select the highest bid, thereby reducing the power of individual proposers and fostering a more decentralized and censorship-resistant block production process. Given the profound changes ePBS entails for the consensus mechanism, it is a considerably more complex undertaking than BALs, and as such, dedicated development networks (devnets) for ePBS are still in the pipeline.
Block-level Access Lists (BALs), on the other hand, aim to enhance transaction efficiency and predictability. BALs allow transactions to explicitly declare which storage slots they intend to access. This information can be used by clients to optimize transaction processing, potentially reducing gas costs and improving block construction. While BALs are also a significant feature, their implementation is less disruptive to the core consensus mechanism than ePBS. Consequently, devnets for BALs are already operational, allowing for early testing and refinement.
The process of selecting additional features for Glamsterdam proved to be a significant challenge, with an initial list of 50 proposed non-headlining features. Core developers and client teams diligently worked to pare this down to a more manageable set of 17 "considered" features deemed necessary and high-impact. These features will be incrementally added to devnets for testing. The timeline for Glamsterdam’s full deployment remains contingent on the stability of these features on devnets, particularly the complex ePBS implementation. A clearer timeline is expected once the first stable ePBS devnet is established and all EIPs have undergone thorough testing. This meticulous approach underscores the network’s commitment to security and stability over rapid deployment.
Charting the Course for Hegotá: Censorship Resistance and Community Proposals
Beyond Glamsterdam, the Ethereum community is already laying the groundwork for the subsequent upgrade, now officially named Hegotá. The name itself reflects the community’s collaborative spirit and adherence to established naming conventions; the original proposed name, Heka, was replaced with Heze (from the International Astronomical Union catalog) + Bogotá, forming Hegotá.
A key feature moved from Glamsterdam to Hegotá to manage the scope of the earlier upgrade is Fork-choice Inclusion Lists (FOCIL). FOCIL is a critical censorship resistance mechanism that has garnered strong support from core developers and the wider Ethereum community. It aims to prevent block proposers from censoring transactions by requiring them to include a list of transactions that must be part of the block, thereby giving users more certainty that their transactions will be processed. FOCIL is particularly complex as it is a "cross-layer EIP," impacting both the consensus and execution layers, specifically the engine API that facilitates communication between them. Its complexity necessitates careful consideration, making Hegotá a suitable target.
The process for selecting Hegotá’s headlining features is currently active and highly participatory. From January 8th to February 4th, anyone in the community can propose a headlining feature using a standardized template on the Ethereum Magicians forum. These proposals will then be presented and discussed during ACD calls, with community feedback actively solicited. The goal is to finalize Hegotá’s headlining features by February 26th. Following this decision, a window will open for proposals for minor, non-headlining features, with a deadline to be announced. This structured approach ensures that the most impactful features receive thorough debate and review, while also allowing for broader community input.
Currently, FOCIL stands as a strong contender for a headliner, though it faces competition from other proposals, including discussions around encrypted mempools (aimed at reducing front-running and MEV) and potentially EIP-7782, which proposes 6-second slots to increase block frequency. The debate surrounding these features will be crucial, with the community encouraged to actively engage and demonstrate support for their preferred proposals during the February discussion period. The inclusion of features like FOCIL or encrypted mempools would significantly bolster Ethereum’s resilience against censorship and improve the fairness of transaction ordering, further solidifying its role as a neutral and robust public good.
The Ethereum Improvement Proposal (EIP) Process: A Framework for Progress
The journey of an Ethereum feature from concept to mainnet deployment is governed by the Ethereum Improvement Proposal (EIP) process. This well-defined framework, guided by EIP-1, outlines how new features are specified, proposed, and championed through the various stages of development. Each EIP requires a technical point-of-contact, known as a "champion," who is responsible for seeing the proposal through its lifecycle, from initial draft to eventual implementation.
The recent experience with Glamsterdam, which saw an initial influx of 50 non-headliner proposals, underscored both the vibrancy of the developer community and the inherent challenges of this open process. While increased participation from "high-context participants" is a positive sign of a thriving ecosystem, it also places a significant burden on client and testing teams. These teams are tasked with familiarizing themselves with each proposal, assessing its feasibility, impact, and urgency, and then making informed recommendations for inclusion. The sheer volume of proposals can be overwhelming, necessitating a rigorous prioritization process to ensure that critical resources are focused on the most impactful and ready-to-implement changes.
This dynamic interaction between community proposals and core developer capacity highlights the delicate balance required to maintain Ethereum’s decentralized development ethos while ensuring efficient and secure progress. The ongoing refinement of the EIP process, including clear timelines for proposals and strong guidance for champions, aims to streamline this critical aspect of network evolution.
Transparency and Community Engagement through All Core Developer Calls
At the heart of Ethereum’s decentralized development lies the transparent and publicly accessible All Core Developer (ACD) calls. These regular meetings are where the technical decisions shaping Ethereum’s future are debated, discussed, and ultimately made. The "Checkpoint" series itself is a derivative of these calls, providing a structured summary for the broader community.
To further enhance transparency and accessibility, Forkcast.org has become an invaluable resource, publishing comprehensive summaries, chat logs, and full transcripts for each ACD call (ACDT for consensus, ACDC for execution, ACDE for general dev-related discussions), often within hours of their conclusion. This rapid dissemination of information ensures that anyone, from independent developers to blockchain enthusiasts and mainstream journalists, can stay abreast of the latest technical discussions and decisions. The availability of these detailed records fosters greater accountability, enables informed community participation, and serves as an institutional memory for the network’s technical evolution. The calls referenced in this update, spanning from November 14th to January 19th, showcase the continuous and iterative nature of core development.
Broader Implications and Future Outlook
The progress detailed in this update—from the activation of Fusaka and dynamic BPO forks to the meticulous planning for Glamsterdam and Hegotá—illustrates Ethereum’s unwavering commitment to its long-term roadmap. These upgrades are not isolated events but interconnected pieces of a grand vision that includes "The Surge" (scaling via rollups and sharding), "The Scourge" (MEV and censorship resistance), "The Verge" (easier verification), "The Purge" (reducing historical data burden), and "The Splurge" (miscellaneous improvements).
The emphasis on Data Availability Sampling and flexible blob parameters directly addresses "The Surge" by enhancing rollup scalability. The work on ePBS for Glamsterdam and FOCIL for Hegotá squarely tackles "The Scourge," aiming to fortify Ethereum’s censorship resistance and decentralization against the challenges posed by MEV. Each step forward reinforces Ethereum’s position as a robust, secure, and adaptable platform for the decentralized economy. The ongoing commitment to community-driven development, facilitated by transparent processes and accessible information, ensures that Ethereum’s evolution remains aligned with the collective vision of its global ecosystem. As these upgrades continue to roll out, they promise to deliver a more efficient, equitable, and resilient blockchain experience for developers, users, and the myriad applications built upon it, cementing Ethereum’s role as a foundational layer for the future of Web3.
