The intricate world of Ethereum core development, characterized by its rapid evolution and complex decision-making processes, is currently navigating significant milestones and challenges. This update provides a high-level overview of the latest progress and discussions surrounding upcoming Ethereum upgrades, focusing on the current state of "Glamsterdam" and the emerging plans for its successor, "Hegotā." While the pace of development for Glamsterdam has proven more deliberate than initially anticipated, the community is actively shaping the future of the network, with key features being defined and implementation complexities being addressed.
Glamsterdam: A Steady but Challenging Path Forward
Ethereum’s next major upgrade, codenamed Glamsterdam, is in active development, with a comprehensive list of proposed and scheduled features available for review. The upgrade’s progression follows a structured process, with features categorized as "Scheduled for Final Inclusion" (SFI) or "Considered for Final Inclusion" (CFI). SFI features are virtually guaranteed to be part of the upgrade upon its launch, while CFI features, though highly probable, are subject to implementation complexity, compatibility with SFI features, and overall development timelines. The precise definitions of these stages are undergoing refinement to enhance clarity and accuracy in describing the development lifecycle.
A significant portion of Glamsterdam’s feature set involves a bundle of gas repricing initiatives, aimed at optimizing transaction costs and network efficiency. Ecosystem developers have also voiced strong support for EIP-7954, which proposes an increase in the maximum contract size. This EIP is thus gaining significant traction and is likely to be prioritized for inclusion.
However, a primary challenge in the Glamsterdam development cycle is the implementation of enshrined Proposer-Builder Separation (ePBS). This groundbreaking feature fundamentally alters how block production operates by introducing a sequential process within the consensus layer, rather than the current external protocol arrangement. This shift necessitates that the protocol itself manages potential disagreements or failures between the proposer and builder. Consequently, every layer of the Ethereum stack must adapt to reason about "partial blocks" and the complexities of two-party coordination, touching virtually all aspects of the protocol.
On the execution layer, Block-level Access Lists (BALs) represent a fundamental re-evaluation of gas and state access mechanisms. While the BAL devnets are making steady progress, the inherent difficulty of these challenges is well-recognized. Developers are currently targeting the deployment of the first generalized Glamsterdam devnet in the near future, contingent on the stabilization of the ongoing ePBS devnet. Subsequent iterations will incorporate an increasing number of non-headliner features. Once a stable devnet encompassing all slated features is achieved, client releases will be made, followed by rigorous security reviews. Successful testnet deployments will ultimately precede the announcement of the mainnet fork date.
The implementation of ePBS, in particular, has presented a steeper learning curve than initially projected. The intricacies of managing consensus-level coordination between proposers and builders, along with the handling of potential disputes, require meticulous engineering and extensive testing. This complexity directly impacts the timeline, suggesting that a Q2 launch for Glamsterdam might be optimistic.
Hegotā: Charting the Course for the Next Upgrade
As Glamsterdam progresses, attention is turning to its successor, Hegotā. The major feature for this subsequent upgrade has been identified as FOCIL (EIP-7805), selected as the consensus layer headliner. The execution layer, meanwhile, engaged in a robust debate regarding an Account Abstraction proposal. Ultimately, a lack of complete consensus on specific implementation details led to the proposal, EIP-8141 (Frame transactions), being designated as a Considered for Inclusion (CFI) feature. This signifies a commitment to further work on an Account Abstraction proposal that garners broader support among client developers and the wider community.
The development of Hegotā also highlights a growing interest in quantum resistance within the Ethereum ecosystem. While no standalone proposals solely focused on quantum resistance have emerged yet, it is being incorporated as a component within broader Account Abstraction proposals. This indicates a forward-thinking approach to securing the network against future technological advancements.
Starting April 9th, the process for proposing non-headliner features for Hegotā is open. Developers can submit proposals by integrating their EIPs into the "Proposed for Inclusion" section of the upgrade’s meta EIP (EIP-8081). The deadline for these submissions will be announced with at least two weeks’ notice. Comprehensive and up-to-date information regarding the Hegotā process and timeline is readily available on its dedicated Forkcast page.
The launch date for Hegotā will be intrinsically linked to the progress and successful deployment of Glamsterdam. A smoother and more timely completion of Glamsterdam’s development would naturally accelerate the timeline for Hegotā.
Gas Limit Enhancements: Pushing the Boundaries of Network Capacity
Ongoing testing of gas limit increases on devnets is a critical component of Ethereum’s evolution. The objective is to enable significantly higher gas limits in both Glamsterdam and future upgrades. The current target for the baseline gas limit is 60 million gas. However, extensive testing is being conducted at much higher limits to thoroughly understand the implications and identify necessary optimizations for achieving these elevated thresholds. Much of the gas repricing work currently being integrated into Glamsterdam is foundational to enabling these safer, higher gas limits, which are crucial for supporting more complex and data-intensive decentralized applications.
The strategic increase of gas limits, coupled with efficient gas repricing mechanisms, is essential for scaling Ethereum and accommodating the growing demand for its services. This process involves careful consideration of network stability, security, and user experience to ensure a seamless transition to higher capacity.
Empowering EIP Champions: New Resources for Proposal Development
The Protocol Support team has launched new resources aimed at assisting authors and advocates in championing feature proposals and soliciting stakeholder feedback. The newly published EIP Champions Handbook, accessible on the Protocol Support team’s website, provides a comprehensive guide for navigating the complex process of getting a feature integrated into an Ethereum upgrade. This initiative underscores the commitment to fostering a more accessible and collaborative development environment, empowering community members to contribute to the network’s ongoing evolution.
The enthusiasm surrounding rapid Ethereum forks, initially ignited by the swift succession of Fusaka and Pectra, has been tempered by the more deliberate pace of Glamsterdam’s development. However, the commitment of client developers to tackling the intricate challenges is unwavering. While a Q2 launch for Glamsterdam appears unlikely, the selection of a single headliner for Hegotā presents an opportunity for a potentially shorter development cycle for that upgrade, contingent on the efficiency of the non-headliner proposal process. It remains a possibility that the community could coalesce around a compelling Account Abstraction proposal, elevating it to headliner status due to its significance.
The "strawmap," published this year, has successfully reignited community enthusiasm for a guiding framework to inform feature choices during upgrade cycles. This informal roadmap appears to be a beneficial tool in fostering community consensus on development priorities, even though it does not represent an official Ethereum roadmap.
Relevant All Core Developer (ACD) Calls
The progress and discussions surrounding these upgrades are meticulously documented through a series of All Core Developer (ACD) calls. These calls provide a transparent forum for developers to deliberate, debate, and decide on the technical direction of the Ethereum network. The period from January 21st to April 9th has seen extensive engagement across various ACD call series, including:
- ACDT (All Core Developers on Tenderly): Calls 76, 75, 74, 73, 72, 71, 70, 69, 68, 67. These calls likely focus on the technical implementation and testing of specific features.
- ACDC (All Core Developers on Consensus): Calls 176, 175, 174, 173. These discussions are central to the consensus layer aspects of the upgrades, including ePBS and FOCIL.
- ACDE (All Core Developers on Execution): Calls 234, 233, 232, 231, 230, 229. These calls address the execution layer, including gas repricing, BALs, and Account Abstraction proposals.
The detailed records of these calls, accessible via the provided links, offer invaluable insight into the intricate decision-making processes and the technical challenges being overcome by the Ethereum core development community. This continuous dialogue and iterative refinement are fundamental to the robust and secure evolution of the Ethereum network. The commitment to transparency and community involvement in these critical development phases underscores the decentralized ethos of Ethereum.
