Highlights of Ethereum's All Core Devs Meeting #202

• Devnets Updates
• EIP-7742
• Chain ID Modifications
• Gas Pricing & BLS Precompiles
• EIP-2935
• Max Payload Sizes & Block Transmission

The main agenda of this core developers' call was to review the progress of Devnet 5, finalize specs, and discuss updates on Pectra EIPs. Key discussions included updates on Devnet 5 implementation and testing, chain ID revisions, configuration updates for future Devnets, and gas repricing. Core Devs also addressed the removal of redundant BLS precompiles, system contract updates for better consistency and error handling, and payload size limitations to improve block transmission scalability.

Devnets Updates

Mekong remains operational and continues to serve as a key platform for testing. Devnet 5 has seen progress, with specs released and client teams actively working on implementations, though full readiness has not yet been achieved. Some clients, such as Lodestar, are reportedly prepared for additional interoperability testing.

Significant progress has been made by clients like Besu and Teku, which have successfully produced blocks based on Devnet 5 specs. Testing readiness has seen improvements with interoperability tools like the Kurtosis config being employed. Once all pending PRs are merged, the testing team plans to update scenarios and prepare an execution-layer (EL) test release. These steps are critical for transitioning to finalized specs for Devnet 5.

Moving forward, client teams are encouraged to expedite their implementations to bring Devnet 5 into a fully operational state. The ultimate objective is to finalize Devnet 5 and set the stage for testing new enhancements, such as those proposed for DevNet 6.

EIP-7742

The group reviewed the decision to replace configuration EIP-7742 with an updated approach for passing configurations in Genesis. The proposed EIP by lightclients garnered general support during earlier discussions. Since there were no objections, it was agreed that this EIP would be integrated into the Pectra specs and reserved for Devnet 6 rather than Devnet 5.

Source: [EIPsInsight](https://eipsinsight.com/eips/eip-7742

Chain ID Modifications

There was extensive discussion about proposals to handle chain IDs more efficiently:

1. Protolambda proposed modifying the chain ID size to U256, arguing that the current approach of including large chain IDs repeatedly is unnecessary and inefficient.
2. Felix suggested removing the chain ID from transactions altogether, relying instead on the outer transaction's chain ID.

The group debated both proposals. Protolambda supported Felix's approach for its elegance and efficiency but raised concerns about maintaining compatibility for multi-chain authorizations. Ultimately, the decision was to implement the U256 change for Devnet 5 while considering Felix's broader proposal for future iterations. The goal is to simplify and finalize these updates for the next development phase.

Gas Pricing & BLS Precompiles

The benchmarking for BLS precompiles was completed in collaboration with multiple client teams. The new pricing aims to make BLS operations more affordable and efficient for developers.

The group reviewed the final gas pricing proposals and decided to merge them into the upcoming Devnet. The consensus was that the updated gas costs reflected fair adjustments based on performance metrics.

Another key discussion revolved around the redundancy of certain BLS precompile operations. Core Devs proposed removing the multiplication precompile, as it duplicates functionality already handled by multiscalar multiplication. The proposal received broad support, with participants agreeing that future additions, if needed, would be easier than removing established precompiles.

EIP-2935

Several audits were conducted on system contracts, including EIP-2935, revealing no critical vulnerabilities but identifying opportunities for improvement. These updates aim to enhance uniformity and correctness across contracts, aligning EIP-2935 with others in the system.

Two significant changes were proposed: reducing the buffer length from 8192 to 8191 for consistency and replacing the return value of zero with a revert for out-of-bounds arguments, making error handling clearer and more uniform.

Source: EIPsInsight

The revisions sparked discussions, particularly around the decision to revert out-of-bound arguments instead of returning zero. While some argued that returning zero might simplify certain use cases, the consensus was that reverting offers better clarity and consistency across the board. These changes will help standardize system contract behavior, even if additional adjustments are required in specific scenarios.

After careful deliberation, the devs decided to finalize and merge the updates into Devnet 5, ensuring their inclusion in the next release. Auditors will present their compiled findings in early January, while client teams are expected to integrate the changes and verify them through further testing.

Max Payload Sizes & Block Transmission

The consensus layer currently has a 10-megabyte limit on the size of data transmitted in a single frame, designed as a spam protection mechanism. However, as gas prices and block sizes increase, this limit is at risk of being exceeded. This could cause significant delays in transmitting and validating blocks, especially under high network activity.

The gas limit’s role in determining block size further complicates matters, as the absence of an upper bound creates the potential for excessively large blocks.

Several approaches were discussed to address the issue:

1. Size Agreement Between Layers: Introduce a maximum size for the transaction list in execution payloads, forcing block builders and mempools to consider byte sizes when adding transactions.
2. Dynamic Sizing Based on Gas Limit: Derive the size limit from the gas limit to ensure alignment between network activity and transmission capacity. However, this approach adds complexity to the consensus layer and may strain validation mechanisms.
3. Hard Capping Block Size: Introduce a fixed upper limit for block sizes, regardless of gas usage, to prevent excessively large blocks and simplify block validation. This approach was favored for its simplicity and effectiveness in addressing immediate concerns.

This marked the final core developers' call of 2024. The next call is scheduled for January 9, 2025.

Wishing you Happy Holidays, from the EtherWorld Team!

Readers can watch Ethereum's Execution Layer Meeting 202 here: