Highlights of Ethereum's All Core Devs Meeting (ACDE) #205

The All Core Devs Execution (ACDE) call #205, held on February 13, 2025, provided significant updates on Ethereum’s network upgrade process, testnet scheduling, system contract deployments, and EIP testing requirements. The meeting focused on finalizing the Pectra hard fork, ensuring the smooth rollout of client releases, addressing the growing scope of Fusaka, and discussing process improvements for EIPs.

Developers also debated the implications of stricter testing requirements for EIP inclusion, reviewed lessons from previous upgrades, and explored future scalability solutions such as the Max Blob Flag.

Pectra Updates

Ethereum’s Pectra hard fork is now in its final testing phase, with Devnet 6 running smoothly and testing the MEV workflow from end to end. Participation levels in Devnet 6 have remained high, reflecting strong client engagement and stability across implementations.

One of the most critical topics of discussion in ACDE #205 was the scheduling of testnet forks to prepare for Pectra’s activation. Developers confirmed that the Holesky testnet fork will take place on February 24 at Epoch 115,968, while Sepolia will fork on March 5 at Epoch 222,464.

These testnet forks serve as preliminary tests before Pectra is deployed on the Ethereum mainnet, ensuring that any unexpected issues are identified and resolved before full activation. The mainnet fork date for Pectra is expected to be approximately 30 days after the Sepolia fork, provided that there are no significant issues during the testnet upgrades.

While the testnet forks have been scheduled, an important issue that arose in the meeting was the lack of deployment of system contracts for several key EIPs, including EIP-2935, EIP-7002, and EIP-7251. These contracts are essential for enabling new protocol features and ensuring the correct execution of proposed improvements.

Developers agreed that deploying these system contracts should be prioritized and completed before Monday’s testing call, allowing them to be included in upcoming testnet forks. Client teams were also reminded that all Pectra releases must be finalized by February 14, ensuring that there are no delays in the upgrade process.

Once all client releases are available, the Ethereum Foundation will publish a blog post officially announcing the Pectra testnet forks, providing the broader community with details about the upgrade schedule, necessary software updates, and guidance on how to participate.

Fusaka Fork Updates

As discussions about Pectra’s implementation neared completion, the focus shifted to Fusaka, Ethereum’s next scheduled hard fork. The list of EIPs proposed for inclusion (PFI) in Fusaka continues to grow, with several high-priority EIPs already being considered. These include:

• EIP-7692: Ethereum Object Format (EOF)
• EIP-7666: EVM-ifying the identity precompile
• EIP-7863: Block-level warming
• EIP-7823: Setting upper bounds for MODEXP
• EIP-7793: A precompile for retrieving the index of a transaction within a block
• EIP-7843: A precompile for retrieving the current slot number
• EIP-7732: Encrypted Proposer-Builder Separation (ePBS)

A major point of discussion was EIP-7723, which introduces stricter testing requirements for EIPs at different stages of inclusion. Under the new framework, EIPs that reach the "Call for Inclusion" (CFI) stage should have an open pull request (PR) against both the EELS and EEST. Once an EIP moves to the "Stage for Inclusion" (SFI), it must have PRs against both EELS and EEST.

The purpose of these new requirements is to enhance testing quality, reduce bottlenecks in the upgrade process, and ensure that every EIP has a robust implementation before being included in a fork. However, this proposal led to significant debate among developers. Some were concerned that introducing these requirements would create an additional burden on client teams and delay the proposal process.

Others worried that the EELS team would gain excessive control over which EIPs move forward, potentially slowing innovation. To address these concerns, a compromise was proposed in which EELS/EEST testing would be a "should" requirement at the CFI stage but a "must" requirement at SFI. Additionally, developers agreed that instead of requiring fully merged implementations, draft PRs would be acceptable as a preliminary step.

To prevent unnecessary delays and uncertainty, developers agreed that Fusaka’s scope should be finalized by April 10. In the lead-up to this, EIPs must be proposed for inclusion by March 13, while client teams will have until March 27 to submit feedback on the proposed EIPs. The objective is to ensure that Fusaka’s scope is well-defined early, allowing implementation work to begin immediately after Pectra’s deployment.

EOF Implementation & Testnet Progress

EOF, one of the most anticipated upgrades in Fusaka, is progressing through various testing phases. The first Fusaka Devnet has been deployed using EOF’s Pectra specifications, with plans to clean up the spec by April, aligning with Pectra’s mainnet activation.

Developers are also evaluating several potential changes to EOF, including:

• Restoring TXCREATE into the specification
• Deprecating EIP-7698’s contract creation transaction
• Adding a metadata section to the EOF container
• Introducing light-level introspection opcodes

Although EOF is a high-priority feature for Fusaka, there was pushback from some Geth developers who questioned its inclusion in the upcoming fork. Discussions on specific elements of EOF, such as the TXCREATE mechanism, will continue asynchronously.

Max Blob Flag & Validator Node Requirements

One of the scalability concerns raised during ACDE #205 was Ethereum’s growing data availability layer, particularly with the introduction of blobs for rollups. Given that not all validators have equal bandwidth or storage capabilities, the Max Blob Flag was proposed as a solution to allow validators to set a limit on the number of blobs they accept.

This proposal received mixed feedback from the community. While some validators appreciated having more control over their resource constraints, others worried that limiting blob inclusion could impact rollup performance and transaction throughput. Additionally, concerns were raised about whether smaller validators would be economically disadvantaged by opting to accept fewer blobs.

The proposal received broad support from most Ethereum Execution Layer (EL) clients, except Erigon, and further testing will be conducted to determine its overall impact.

Related Articles

1. Highlights of Ethereum's All Core Devs Meeting (ACDC) #150
2. Highlights of Ethereum's All Core Devs Meeting (ACDE) #204
3. Highlights of Ethereum's All Core Devs Meeting (ACDC) #149
4. Highlights of Ethereum's All Core Devs Meeting (ACDE) #203