Highlights of Ethereum's All Core Devs Meeting #201

• Devnet Updates
  • Mekong Testnet
  • Devnet 5
• Pectra Scope Finalization
  • BLS Gas Pricing
  • EIP-7623 Inclusion
  • EIP-7762 Adjustments
• History Expiry and Protocol Changes

The main agenda of this call revolved around critical updates and discussions on Ethereum's development roadmap, including Pectra updates, progress on Mekong & DevNet-5, and key topics such as BLS gas pricing and the inclusion of EIP-7623.

Devnet Updates

Mekong Testnet

The Mekong testnet is operational, achieving approximately 97% attestation performance. However, some issues persist, particularly in the Ethereum.js and Nimbus EL implementations, which are being addressed by the respective teams. Significant progress has been made by the Grandine team, which has resolved most critical issues.

Devnet 5

For Devnet 5, the focus is on preparing for its launch by integrating necessary PRs and updates. Currently, three PRs remain open: two related to Execution APIs and one concerning SSZ support for the builder API. Changes to EIP-7691, which involve the update fraction sensitivity, also require final approval and merging.

EIP-7691 introduces changes to the update fraction specifications. A detailed discussion revolved around determining the optimal sensitivity levels for block adjustments. The team settled on a middle ground that balances increasing and decreasing blob targets, aiming for a slightly less than 12% increase for a full block and a corresponding decrease for an empty block. This proposal is nearing completion, requiring only minor approvals and typo corrections before being merged.

The team is working to achieve consensus on unresolved issues, particularly those related to balancing increased and decreased blob target rates. The priority is to ensure that all relevant PRs are thoroughly reviewed and integrated, with a focus on stability and functionality.

Pectra Scope Finalization

BLS Gas Pricing

Disagreements over appropriate gas pricing for BLS operations led to proposals ranging from coarse to more granular pricing models. The aim is to avoid overpricing while ensuring network performance is not compromised. One of the most significant issues discussed was gas pricing for BLS operations. Various teams proposed scaling factors ranging from 2x to 3x to address performance bottlenecks.

While coarser pricing was seen as an interim solution, the preference for a more nuanced approach led to calls for additional analysis and consensus among teams. Concerns were also raised about the implications of pricing adjustments for production clients and their readiness to adopt these changes.

EIP-7623 Inclusion

EIP-7623 focuses on capping transaction payload sizes to improve network performance and security. The proposal addresses concerns about gas sheltering and backwards compatibility. Updates were made to incorporate feedback from the Ethereum community, including elaboration on security considerations and compatibility.

The changes aim to limit execution layer (EL) payload sizes, ensuring they remain manageable as the network scales. Teams expressed optimism about including this in the upcoming update, though its testing and implementation complexities were discussed as potential roadblocks.

Debates around this EIP focused on whether its inclusion aligns with the broader goals of Pectra, especially given its potential impact on implementation timelines.

EIP-7762 Adjustments

The discussion explored the feasibility of introducing changes to the blob base fee as part of Pectra without introducing undue complexity. EIP-7762 proposes adjustments to the blob base fee to enhance pricing mechanisms and improve market dynamics. This involves introducing a minimum base fee and an excess gas reset.

The proposed changes aim to stabilize volatile fee markets, particularly during periods of fluctuating demand, which have caused inefficiencies for rollups. The proposal received mixed reactions, with some client teams favoring its inclusion and others raising concerns about the added complexity and testing overhead.

History Expiry and Protocol Changes

The History Expiry Proposal (EIP-7639) aims to reduce the burden of storing historical data, particularly block bodies and receipts from before the Ethereum Merge. This change is expected to save significant disk space (estimated at several hundred gigabytes) and alleviate concerns about exceeding the four-terabyte storage limit. The proposal specifies that clients will no longer be required to respond to requests for this historical data over the DevP2P protocol after the drop date of May 1, 2025.

A critical aspect of this proposal is the introduction of Protocol Version 71, which explicitly prohibits serving pre-Merge block history. This version ensures that clients adhering to the updated protocol can safely assume that they are not expected to provide this data. Discussions also covered whether it is necessary to create a new protocol version or if modifications could be integrated into existing versions.

To address compatibility concerns, some client teams suggested creating a separate sub-protocol for handling requests related to historical data. This approach aims to prevent outdated clients from requesting unavailable data from updated nodes. However, other teams argued that implementing such a sub-protocol might lead to bifurcation in the Ethereum protocol, complicating network operations.

Additionally, the discussions emphasized the need to coordinate with all client teams to ensure a smooth transition.

Readers can watch Ethereum's All Core Devs Meeting #201 here: