Layla Zulfa
The intricate dance of innovation and implementation continues within the Ethereum ecosystem as core developers diligently work on two pivotal network upgrades: Glamsterdam and Hegotá. These upgrades, while distinct in their feature sets, represent crucial steps in Ethereum’s ongoing evolution towards enhanced scalability, security, and user experience. The current development cycle, as detailed in recent All Core Developer (ACD) calls, highlights both the ambitious scope of these changes and the inherent complexities involved in pushing the frontier of decentralized technology.
Glamsterdam: Navigating the Technical Labyrinth
The Glamsterdam upgrade, Ethereum’s immediate next major hard fork, is progressing, albeit at a measured pace. The core development community acknowledges that the implementation of its headline feature, enshrined Proposer-Builder Separation (ePBS), is proving more challenging than initially anticipated. This is compounded by the inherent complexities of other significant, albeit less publicized, features such as gas repricings.
Enshrined Proposer-Builder Separation (ePBS) stands as a cornerstone of Glamsterdam. It represents a fundamental shift in how blocks are constructed and validated on the Ethereum network. Currently, block production often involves a "builder" (typically a sophisticated entity like a MEV-relay or block builder) and a "proposer" (the validator selected to propose the next block) operating largely outside the direct protocol. ePBS aims to bring this crucial separation within the protocol’s consensus mechanism. The rationale behind ePBS is multifaceted: it seeks to mitigate Maximal Extractable Value (MEV) by decentralizing the block-building process, enhance network censorship resistance, and improve overall protocol security by reducing the power of any single entity to manipulate block content.
The technical hurdles for ePBS are substantial. By moving this two-party coordination into the protocol, developers must now account for a myriad of potential scenarios, including disagreements, failures, or malicious behavior between the proposer and builder. This necessitates a fundamental rethinking across the entire Ethereum stack, from the consensus layer to the execution layer, requiring every component to "reason about ‘partial blocks’" and manage complex inter-party coordination. This deep-seated change touches virtually every aspect of how the network operates, demanding meticulous design and robust testing.
Beyond ePBS, Glamsterdam incorporates several other vital enhancements. A bundle of gas repricings, primarily prioritized under EIP-8007, aims to optimize transaction costs and improve network efficiency. These repricings are not merely arbitrary adjustments; they involve a detailed analysis of opcode costs and resource utilization to ensure that gas fees accurately reflect the computational burden placed on the network. This re-evaluation is critical for maintaining a healthy economic model for transaction processing and preventing denial-of-service attacks. The current reports on gas repricing complexities highlight the detailed work required to ensure these changes are safe and effective.
Another feature gaining significant traction and vocal support from ecosystem developers is EIP-7954, which proposes an increase to the maximum contract size. This enhancement is crucial for developers building increasingly complex decentralized applications (dApps) on Ethereum. Larger contract sizes allow for more intricate logic, richer functionalities, and potentially more secure smart contract architectures, removing a current bottleneck for innovative projects. The collective advocacy from the development community underscores its importance for fostering a vibrant and unconstrained dApp ecosystem.
On the execution layer side, Block-level Access Lists (BALs), outlined in EIP-7928, are making predictable progress. BALs represent a profound re-evaluation of how gas and state access mechanisms function within the Ethereum Virtual Machine (EVM). They are foundational to the successful implementation of ePBS, providing the necessary infrastructure for the protocol to manage and verify partial blocks efficiently. Development teams are currently running dedicated devnets for BALs, systematically working through the expectedly difficult problems associated with such a core architectural change.
The development roadmap for Glamsterdam involves a series of rigorous testing phases. Developers are aiming to launch the first generalized Glamsterdam devnet in the near future, contingent upon the stabilization of the current ePBS-focused devnet. This will be followed by several iterations of devnets, progressively incorporating more of the non-headliner features. Once a stable devnet, fully equipped with all the scheduled features, is achieved, client releases will be cut, followed by comprehensive security reviews. The final stages involve deployment to public testnets, and upon confirmation of their stability, the much-anticipated mainnet fork date will be officially announced. While a Q2 mainnet launch for Glamsterdam appears increasingly unlikely given the current pace, the dedication to thoroughness over speed is a testament to Ethereum’s commitment to security and stability.
Hegotá: Charting the Path Beyond Glamsterdam
Looking ahead, Hegotá is slated as the upgrade immediately following Glamsterdam, and its feature selection process has largely concluded. The consensus layer has identified EIP-7805, known as FOCIL (Future of Consensus Layer Improvements), as its major headliner. While specific details of FOCIL are yet to be widely disseminated in simplified terms for the broader public, its selection indicates a strategic focus on core consensus mechanics, likely aimed at further enhancing the security, efficiency, or decentralization of the proof-of-stake system.
A significant point of discussion and "heated debate" for Hegotá’s execution layer feature selection centered around an Account Abstraction (AA) proposal, specifically EIP-8141, known as "Frame transactions." Account Abstraction is a highly anticipated feature that promises to revolutionize user experience on Ethereum by allowing smart contracts to initiate and pay for transactions, effectively turning every wallet into a smart contract wallet. This enables features like social recovery, multi-factor authentication, customizable transaction fees, and batching of transactions, making blockchain interactions significantly more user-friendly and flexible. However, despite its widespread community support, a consensus on the specific implementation choices for EIP-8141 could not be reached among client developers. Consequently, the proposal has been moved to "Considered for Inclusion" (CFI) status as a non-headliner. This decision, however, comes with a firm commitment from core developers to continue working on an Account Abstraction proposal that can garner broader support across client teams and the wider community, ensuring this crucial functionality remains a priority.
There is also a growing interest within the Ethereum community and developer circles in prioritizing quantum resistance. The advent of quantum computing poses a theoretical long-term threat to current cryptographic schemes, including those underpinning blockchain security. While no standalone quantum resistance proposal has been introduced for Hegotá, the topic is frequently discussed, often as an integral part of broader Account Abstraction packages. This highlights a proactive approach to future-proofing the network against emerging threats.
The process for proposing non-headlining features for Hegotá commenced on April 9th, allowing any interested party to submit an Ethereum Improvement Proposal (EIP) by integrating it into the "Proposed for Inclusion" section of the fork’s meta EIP (EIP-8081). The closing date for these submissions will be announced with at least two weeks’ notice, ensuring ample time for community participation. The most current information regarding Hegotá’s process and timeline is consistently updated on the dedicated Hegotá Forkcast page, providing transparency and accessibility for all stakeholders. The ultimate timeline for Hegotá’s deployment will be heavily influenced by the progress and successful implementation of Glamsterdam in the coming months, underscoring the interconnected nature of these upgrade cycles.
Enhancing Network Capacity: The Gas Limit
A continuous area of focus for Ethereum’s development teams is the network’s gas limit. Gas limits dictate the maximum amount of computational work that can be included in a single block, directly impacting transaction throughput and network capacity. Currently, devnets are actively testing increased gas limits, with a baseline target of 60 million units for Glamsterdam and subsequent upgrades. However, testing extends to significantly higher limits to thoroughly understand the implications of such increases and identify necessary optimizations. Much of the gas repricing work being implemented in Glamsterdam is specifically designed to enable these higher gas limits safely and efficiently, ensuring that increased capacity does not compromise network stability or security. The ability to increase the gas limit is vital for Ethereum to handle a growing volume of transactions and support more complex dApps without experiencing prohibitive congestion or high fees.
Empowering Community Participation: The EIP Champion’s Handbook
In a move to further decentralize and streamline the upgrade process, the Protocol Support team has published new resources, including the "EIP Champions Handbook." This comprehensive guide is designed to assist authors and advocates in championing their feature proposals through the rigorous Ethereum Improvement Proposal (EIP) process. It provides clear guidance on how to seek stakeholder feedback, navigate technical requirements, and engage with the core development community. This initiative aims to lower the barrier to entry for community members to contribute to Ethereum’s evolution, fostering a more inclusive and robust development pipeline.
Broader Implications and the Path Forward
The current development landscape reflects a maturing blockchain ecosystem grappling with complex technical challenges. While previous upgrades like Fusaka demonstrated remarkable speed in their implementation, Glamsterdam’s inherent complexity, particularly with ePBS, has tempered expectations for rapid deployment. This slower pace, however, is not indicative of a lack of commitment but rather a diligent approach to ensuring the highest standards of security and stability for a network that secures billions of dollars and supports a global decentralized economy. The client developers, despite the significant technical hurdles, appear resolute and undeterred by the challenge.
The strategic decision to select a single headliner for Hegotá, coupled with the open process for non-headliner features, suggests a flexible approach. Depending on the success and timeline of Glamsterdam, and the community’s ability to coalesce around a robust Account Abstraction proposal, Hegotá could potentially follow Glamsterdam in a comparatively shorter timeframe. The possibility remains that a well-defined and widely supported Account Abstraction EIP could be elevated to a headliner status in Hegotá, acknowledging its profound importance for the Ethereum community and its long-term vision.
The re-emergence and enthusiastic adoption of resources like the "strawmap" this year highlight the community’s desire for a guiding framework in feature selection. While not an "official Ethereum roadmap," such tools have proven beneficial in fostering alignment and consensus on priorities during the upgrade process, helping to inform feature choices and ensure that development efforts are directed towards the most impactful enhancements for the network. The ongoing work on Glamsterdam and Hegotá underscores Ethereum’s continuous commitment to its foundational principles of decentralization, security, and scalability, all while striving to improve the user and developer experience for its global community.
Relevant All Core Developer Calls (January 21st – April 9th):
The progress outlined above is a direct result of ongoing discussions and decisions made in numerous All Core Developer calls across various tracks:
- All Core Devs – Implementers (ACDT): 76, 75, 74, 73, 72, 71, 70, 69, 68, 67
- All Core Devs – Consensus (ACDC): 176, 175, 174, 173
- All Core Devs – Execution (ACDE): 234, 233, 232, 231, 230, 229
These regular meetings serve as the primary forum for client developers, researchers, and community members to discuss, debate, and collectively steer the future development of the Ethereum protocol, ensuring a decentralized and robust decision-making process.
