Highlights from the All Core Developers Execution (ACDE) Call #212

The All Core Devs Execution (ACDE) Call 212 spotlighted Ethereum’s ongoing efforts to stabilize Fusaka Devnets, finalize the scope for Devnet 1, and align client teams on key EIP implementations. With Devnet 7 stress testing in full swing and Fusaka Devnet 0 preparing for launch, discussions focused on readiness, PeerDAS validation, and EIPs like 7825 & 7934 that shape Ethereum’s execution environment. The call reflected a broader push toward structured testnet coordination & protocol clarity as Ethereum advances its modular architecture.

• Client Implementation Updates
• Fusaka Devnet 1 Scope
• EIP-7825 (Transaction Gas Limit Cap)
• EIP-7934 (RLP Block Size Limit)
• Review of Additional EIPs for Devnet 2
• Testnet Deployment Strategy

Client Implementation Updates

Devnet 7 is currently active as a platform for basic stress testing of Ethereum’s data availability layer, primarily through stable blob spamming. Its main goal is to assess whether Ethereum clients can successfully sync with the network head and perform historical backfill operations. However, many clients still lack functioning backfill capabilities, and validator custody is yet to be implemented across most of them. These missing features introduce risks of unstable or incomplete testing, prompting teams to ensure these capabilities are in place by Devnet 1 or, at the latest, Devnet 2. Despite these limitations, client onboarding to Devnet 7 has been largely successful, with clients like Besu already showing full participation and successful syncing.

The upcoming Fusaka Devnet 0 is scheduled to launch on the Monday following the call. Compatibility testing across clients is in progress, with Grandine, Prysm, Lodestar, and Teku confirmed to be functional on the consensus layer (CL), while Geth is ready on the execution layer (EL). Some key clients, such as Nimbus and Lighthouse, have yet to release their required branches, and additional EL teams are expected to publish theirs shortly. This new testnet marks a critical phase for evaluating the implementation of Fusaka EIPs and will gradually replace Devnet 7 as the main testing environment.

In parallel, PeerDAS testing has been initiated using a new network partitioning tool from the Ethereum Foundation’s security team. This tool simulates isolated node environments to identify weaknesses in how clients handle partitioned networks. Early tests have already exposed failures, indicating that the testing mechanism is functioning as intended. Developers are now working to investigate and resolve the underlying causes of these failures to ensure PeerDAS resilience under adverse conditions.

To support the Devnet 0 launch, all client teams have been contacted and most have confirmed readiness. The aim is to establish a stable physical testnet by Monday. However, a few teams remain behind on implementing PeerDAS-specific changes, particularly around the Engine API and transaction pool updates. These elements are critical for ensuring full protocol compatibility. In situations where updates are not yet merged into main branches, teams have been encouraged to publish development branches to avoid delaying the network launch.

Fusaka Devnet 1 Scope

The discussion around Fusaka Devnet 1 centered on finalizing which EIPs should be included in its scope. The intent is to avoid overwhelming client teams by spreading changes too broadly across multiple Devnets.

By clearly assigning EIPs to specific Devnets—starting with Devnet 1 and possibly closing out additions with Devnet 2—the community aims to streamline coordination, ensure consistency, and prevent fragmentation. Client teams such as Nethermind, Erigon, and Besu had already shared their input ahead of the call, identifying two priority EIPs for inclusion in Devnet 1: EIP-7825 (Transaction Gas Limit Cap) and EIP-7934 (RLP Block Size Limit).

Both proposals received broad support and were discussed in detail to confirm their relevance, urgency, and feasibility. Participants emphasized that bundling too many EIPs without proper phasing could complicate testing, increase risk, and slow down progress.

Aligning on a shared roadmap for Devnet 1 and 2 gives the ecosystem room to test implementation without introducing instability. Establishing a smaller, agreed-upon EIP set for Devnet 1 would allow client teams to focus efforts and prepare implementations more efficiently. The aim was to lock in the scope for Devnet 1 during this call and push any remaining EIP decisions to the next cycle of discussions for Devnet 2.

EIP-7825 (Transaction Gas Limit Cap)

EIP-7825 (Transaction Gas Limit Cap) proposes introducing a cap on the gas allowed per transaction, aimed at preventing excessively large transactions that can hinder parallel execution and degrade performance. Proponents argued that limiting transaction size helps improve throughput, especially in future architectures that prioritize parallel processing and rollup-friendly batching.

With the rise of Account Abstraction (AA) and bundlers, large multi-operation transactions are expected to become more common. Without a cap, one oversized transaction could monopolize block space and complicate execution, particularly as Ethereum transitions to higher gas limits and more advanced features like block access lists.

4⃣ EIP-7825: Transaction Gas Limit Cap
🔹with @GiulioRebuffo
🔹Explore a proposal with protocol-level cap on the maximum gas used by a transaction.
🗓️ Recording: May 22 at 18:30 UTC#Ethereum #EIPs #Gas #Tansaction @EthCatHerders pic.twitter.com/DLqm2HL85s

— Pooja Ranjan | ranjan.eth (@poojaranjan19) May 20, 2025

However, the proposal also sparked debate. Some contributors felt that the EIP lacked clarity on the real target issue and raised concerns that batching operations into one transaction should not be penalized if the protocol’s resource pricing is already fair.

Others argued that without a cap, attackers could exploit gas-heavy edge cases to create denial-of-service conditions. The proposed limit of 30 million gas per transaction was seen as a reasonable starting point, allowing for large operations while ensuring that multiple transactions can coexist within a block.

Ultimately, the group aligned on including EIP-7825 in Devnet 1, agreeing that it provides a performance safeguard for the evolving Ethereum ecosystem.

EIP-7934 (RLP Block Size Limit)

EIP-7934 proposes placing an explicit cap on the size of RLP-encoded execution layer (EL) blocks, aligning them more closely with consensus layer (CL) constraints. Currently, there’s an implicit cap based on the network’s ability to propagate blocks efficiently, but this EIP formalizes it.

Supporters of the EIP argued that making this constraint explicit improves predictability, avoids extreme block sizes, and reduces edge-case risks—especially in scenarios involving client syncing, MEV block building, or peer-to-peer propagation. The cap would make block sizes more manageable for clients and would help prevent missed slots due to oversized blocks.

Some developers raised concerns about the computational cost of continuously RLP-encoding blocks during construction. However, it was clarified that clients can pre-calculate the size using existing encoded transaction lengths and fixed-size headers, thus avoiding expensive re-encoding.

Teams like Nethermind already had prototype implementations and found the overhead minimal. There was also discussion about syncing implications and whether the cap should be stricter (e.g., 7.5MB instead of a looser upper bound). Despite minor disagreements on cap size and enforcement methods, consensus was reached to include EIP-7934 in Devnet 1, reinforcing the need for tighter operational boundaries on block size.

Review of Additional EIPs for Devnet 2

1. EIP-7907: Contract Code Size Limit Increase:

• This EIP proposes raising the maximum allowed size for contract code from its current limit to 256 kilobytes, with the init code capped at 512 kilobytes. The goal is to meet growing developer demands for more complex smart contracts and improve EVM usability.
• While teams like Besu and Erigon supported its inclusion in Devnet 2, Nethermind expressed caution. Their concern was the lack of performance analysis on how clients would handle larger code sizes, especially in conjunction with other Fusaka changes like higher gas limits and longer slot times.
• Critics requested deeper benchmarking on code load times, database impact, and potential state/code bloat before committing. While there is broad community interest in this EIP, it was decided to defer final inclusion until further data is available over the next two weeks.

2. EIP-7918: Blob Base Fee Bounding:

• EIP-7918 proposes tying the blob base fee to the execution layer base fee, introducing a minimum cost for blob transactions. The aim is to correct underpricing of blob-related compute overhead and improve fee market stability.
• It received support from multiple client teams, including Besu, Erigon, and Nethermind. While technically simple to implement—requiring only a constant to be set—strategically, it’s more nuanced. Some contributors emphasized the need for caution, as changes to blob pricing can significantly impact Layer 2 rollups.
• The consensus was to tentatively move forward, acknowledging that the constant value could still be tuned. Final decisions on fee levels would depend on further analysis and feedback, likely before Devnet 2 deployment.

3. EIP-7212: R1 Curve Precompile:

• This proposal aims to introduce a new cryptographic precompile for the R1 elliptic curve, which is widely used in zero-knowledge proof systems and rollups. It has garnered support from several clients, but concerns were raised about the current specification.
• Testing teams flagged it as complex and potentially flawed, requiring a rewrite or clarification. Developers emphasized that precompiles demand cryptographic certainty—any ambiguity could compromise security.
• The plan is to rewrite the EIP with minor fixes, ensuring backward compatibility with rollups that already implemented the current version. Despite the complications, there was strong sentiment to move this into Devnet 2, with championing efforts led by community cryptographers.

4. EIP-5920: Pay Op Code:

• EIP-5920 introduces a mechanism to send ETH to a recipient without requiring code execution, streamlining simple ETH transfers. However, this EIP proved the most divisive.
• Erigon opposed it outright, citing concerns over execution model violations, while Besu and Nethermind offered mixed views. Supporters pointed out that the same functionality exists today via self-destruct, though in a less elegant form.
• Due to unresolved concerns and competing priorities, no consensus was reached on its inclusion. The group agreed to review it alongside other pending EIPs and make a final decision before Devnet 2.

Testnet Deployment Strategy

A significant portion of the call focused on Ethereum’s testnet infrastructure—specifically, how to manage risk and stability for developers deploying apps and protocols. Alon Muroch proposed a long-term vision for the Holesky (Hoodi) testnet to serve as a stable, mainnet-like staging environment that forks only when Ethereum mainnet does.

The goal is to reduce developer disruptions caused by frequent or unexpected testnet forks, which can invalidate smart contracts or break integration pipelines. Alon advocated for keeping Hoodi as the last testnet to fork before mainnet, preserving its integrity and positioning it as a reliable platform for production-grade deployment trials.

While some community members supported this approach, others raised concerns about maintaining “forever-running” testnets. Running nodes for long-lived testnets is resource-intensive, and historically, most nodes on these networks have been maintained by client teams or EF infrastructure.

To address this, the idea of community-maintained infrastructure was proposed, involving projects like Lido, Gnosis, and others that already operate nodes for staking or integration testing. Developers agreed that having fewer, more predictable testnets with longer lifespans would improve the developer experience—especially if paired with clear guidance on forking sequences and risk levels.

If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@etherworld.co for clarifications or updates.

Related Articles

1. Highlights of Ethereum's All Core Devs Meeting (ACDC) #153
2. Highlights of Ethereum's All Core Devs Meeting (ACDE) #207
3. Highlights of Ethereum's All Core Devs Meeting (ACDC) #152
4. Highlights of Ethereum's All Core Devs Meeting (ACDE) #206
5. Highlights of Ethereum's All Core Devs Meeting (ACDE) #205
6. Highlights of Ethereum's All Core Devs Meeting (ACDC) #150