Highlights from the All Core Developers Exceution (ACDE) Call #215

The recent All Core Developers Exceution (ACDE) Call #215, held on July 3, 2025, centered on validating the performance gains from Fusaka Devnet 2, finalizing crucial EIP specifications, & kick-starting broader discussions around blob throughput scaling via BPO forks.

Alongside deep technical reviews, participants examined intensive performance test results, aligned on timelines for Devnet 3 as the “happy-path” stress test, & set the stage for the next major fork, Glamsterdam.

• Fusaka Scope & Devnet Planning
• Glamsterdam Process & Scheduling
• History Expiry Roadmap

Fusaka Scope & Devnet Planning

During Devnet-2, participation stalled at only around 56 % of clients successfully finalizing the network. This low completion rate was traced back to fork-ID miscalculations in Besu and mishandling of 4-byte IDs by Nethermind, while the EL/CL Nimbus clients were unable to sync at all.

To prevent similar issues going forward, the teams agreed to adopt a standardized eth_config JSON-RPC method (EIP-7910) for fetching genesis parameters, such as gas costs and blob limits, rather than relying on disparate client-side objects. Finally, the role of Devnet-2 was formally redefined as a “bug-hunt” sandbox, with Devnet-3 designated as the “happy-path” network for validating the finalized Fusaka scope under near-production conditions.

EIP-7907 doubles the maximum contract bytecode size from 24 KB to 48 KB, a 2× increase versus an earlier 10× proposal, striking a balance between supporting larger Wasm/C++ based contracts and containing potential DoS risks. The proposal keeps the code-size index (a warming read) as an implementation detail rather than a consensus parameter, allowing clients to opt in without affecting block validity rules.

Inclusion is gated by three pull requests:

• one removing the EXTCODESIZE warming (PR #11),
• one for clarification fixes (PR #9910),
• & one handling large contract entry points (PR #9955).

In Devnet-3, teams will stress test EIP-7907 by spamming small transactions and replaying large block scenarios to surface any DoS weaknesses, with the option to pull the EIP if severe issues arise. After deeming the previous dynamic “6 to 12” blob jump in the BPO schedule overengineered, the specification now adopts a hard cap of six blobs per transaction via EIP-7594, fully removing the maxBlobsPerTx parameter from EIP-7892.

Under the revised repricing plan, the gas cost for the ModExp precompile (EIP-7883) is tripled to ensure safe operation even at a 100 M gas block limit, prioritizing performance. Similarly, the secp256r1 curve precompile (EIP-7951) sees its gas cost doubled to maintain parity with existing elliptic curve ADD and MUL operations.

EIP-7918 finalizes the BLOB_BASE_COST constant at 2¹³, balancing blob inclusion incentives with disciplined fee levels. This parameter applies uniformly across all blobs, ensuring predictable cost behavior in both mainnet and Devnet-3 environments.

Glamsterdam Process & Scheduling

The formal window for proposing “headliner” EIPs in the Glamsterdam meta-EIP closed on June 20, 2025. Initially, the team aimed to make a final headliner decision by July 17, 2025, but this schedule was shifted to allow more in-depth technical review & broader community input.

Two dedicated ACDE review calls have been scheduled: on July 31, 2025, & August 14, 2025, during which each EIP author will present their proposal, respond to questions, & refine specifications ahead of the final selection. To aid this process, the live matrix at forkcast.org tracks each headliner’s scope, stakeholder impact, & implementation status, and authors are encouraged to keep their entries up-to-date.

When Glamsterdam first started, some proposals moved too quickly straight into CFI before we even had a proper PFI step. To fix this, two pull requests were opened:

1. Update EIP-2926: revive eip-2926 to introduce code chunking in glamsterdam #9927
2. Update EIP-7773: Move previously CFI'd Glamsterdam EIPs to PFI #9970

From now on, each team should:

1. Base their work on the official Glamsterdam Meta EIP branch.
2. Update the list of EIPs waiting in PFI.
3. Wait for the headliner EIPs to be chosen before they move ahead with their own specification or code.

History Expiry Roadmap

Originally, ERAE-1 was designed solely for pre-merge history, coupling execution-layer data (blocks, transactions, receipts) with consensus-layer proofs. Over time, it became clear that execution and consensus layers have different archival needs, and a unified post-merge format was needed to enable rolling history expiry up to and beyond the Cancun fork.

The steering goal is to gather feedback over the next few weeks, finalize the spec by end-of-July, then migrate clients off ERAE-1 onto this unified format. Once frozen:

1. Clients will deprecate ERAE-1 and transition to ERAE-E.
2. Archive nodes can bootstrap solely from ERAE-E files, without downloading separate beacon or consensus data.

A blog post (forthcoming “this week or early next week”) will formally announce the change. Teams are collecting feedback on timelines and any client-specific concerns, aiming for broad consensus before coupling this change with the Fusaka Devnet-3 milestone.

The ACDE Call #215 successfully validated key updates from Fusaka Devnet 2 & refined essential EIP parameters. It also laid the groundwork for Devnet 3 & the upcoming Glamsterdam fork.

These coordinated efforts keep the Ethereum community aligned on performance goals, specification changes, & future upgrade timelines.

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