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

At the All Core Developers Execution (ACDE) Call #218, Ethereum client teams & researchers met to review Fusaka Devnet-4 outcomes, address stability issues, and set priorities for the upcoming Devnet-5. The call focused on resolving cross-client divergences in blob-fee calculation, improving boot-node diversity, and unifying fork-parameter logic through updated specifications & static tests.

Developers postponed timeline decisions for Sepolia & Holesky forks until Devnet-5 finalises cleanly, ensuring stability before scheduling public testnet releases. Glamsterdam upgrade planning advanced, with ePBS (EIP-7732) & BAL (EIP-7928) confirmed as headliners, while other proposals like FOCIL remain under conditional inclusion. The discussion also covered refinements to the BAL specification, stronger pre-ACD testing processes, feedback on the “Safe-Head” proposal, and consensus on ModExp repricing & contract size increases to be stress-tested in Devnet-5.

• Fusaka Devnet Progress
• Fusaka Timelines
• Glamsterdam Headliners Finalised
• Block-Level Access Lists (BAL) Specification
• Testing & Process Improvements
• “Safe-Head” Proposal
• Testing & Process Improvements
• ModExp & Contract-Size Changes

Fusaka Devnet Progress

Devnet-4 progressed cleanly through BPO 1–2, but during BPO 3, several issues surfaced across execution layer (EL) and consensus layer (CL) clients. The primary objective at this stage is to fix these issues, align fork-boundary rules, introduce a new chain configuration RPC, improve boot-node diversity, and then proceed with launching Devnet-5.

This next network iteration is expected to have a healthier client mix and increased stability before any timeline decisions are finalised.

1. The first major issue occurred with Erigon, which computed the blob-fee incorrectly and subsequently forked away from other EL clients. While the fix has already been merged in Geth and other ELs, Erigon’s team is still investigating the underlying cause.
2. Lighthouse and Nimbus both faced difficulties in peer discovery and network synchronisation due to limited boot-node diversity, as most boot nodes were initially Lighthouse+Geth pairs. To improve this, half the boot nodes were switched to Prysm+Geth pairs, but further client-side fixes are required.

Despite these challenges, there is no expectation of mass validator slashing because the super-node topology mirrors mainnet, which should allow finality once fixes are in place. Additionally, all teams are required to update fork-ID logic in their clients prior to the launch of Devnet-5.

A key specification inconsistency was identified in how clients handle the base-fee update fraction when a fork occurs. Some implementations relied on the parent block’s constants, while others used those of the current block.

This mismatch contributed to the divergence observed in Devnet-4. The decision was made to standardise the approach.

Moreover, it was agreed that future EIPs must explicitly state whether to use current or parent parameters to prevent ambiguity. In preparation for Devnet-5, boot-node diversity will be further improved to ensure robust peer discovery and stable synchronisation for clients like Lighthouse and Nimbus.

This involves moving beyond the initial Lighthouse+Geth pairing and building on the Prysm+Geth additions made during Devnet-4. Alongside this, all EL and CL teams must update fork-ID logic and finalise the other technical fixes before the new devnet is launched.

The planning process for Devnet-5 will only begin once Devnet-4 finalises cleanly. This new devnet will feature greater minority-client representation, with Grandine, Erigon, and Lodestar expected to collectively represent around 3–5% of the network, while Lighthouse and Prysm remain at realistic levels.

This mix is intended to reflect mainnet conditions more accurately while also surfacing bugs in less-used clients. Collectively, these steps aim to deliver a smoother, more predictable launch for Devnet-5 and a stronger foundation for subsequent Fusaka development stages.

Fusaka Timelines

The Fusaka upgrade involves several interdependent components, including changes tested in Devnet-4 and the upcoming Devnet-5. The purpose of timeline planning is to coordinate client releases and testnet forks so that major features like ePBS (EIP-7732) and BAL (EIP-7928) can be deployed without risking instability.

However, because Devnet-4 remains unstable, all timeline decisions have been put on hold until stability is achieved. Alex Stokes proposed a tentative schedule that included Sepolia and Holesky client releases on 8 September 2025, followed by a Holesky fork on 15 September 2025 and a Sepolia fork on 29 September 2025.

This schedule aimed to maintain forward momentum on the Fusaka rollout. Several core development teams objected to the proposed schedule for three main reasons.

1. First, Devnet-4 was still unstable, with BPO 3 exposing execution and consensus client bugs, peer discovery issues, and blob-fee calculation errors.
2. Second, static test suites for fork-parameter calculations, including update-fraction logic, were not yet complete.
3. Third, multiple clients were still running on feature branches rather than stable mainline code, raising the risk of regressions when merging.

The consensus was to postpone all schedule decisions until Devnet-5 is clean and stable. Only after a successful Devnet-5 finalisation will firm dates be set for public testnet forks such as Sepolia and Holesky, as well as execution and consensus client releases.

A key condition is that these timelines should reflect code merged into main branches rather than feature branches. The responsibility for revisiting the Fusaka timelines lies with coordinators and client teams.

Glamsterdam Headliners Finalised

In the Glamsterdam upgrade plan, one Consensus-Layer (CL) EIP and one Execution-Layer (EL) EIP are designated as “headliners.” These headliners act as the anchor features for the upgrade cycle, meaning they must be implemented and tested before any additional features are introduced.

They set the priority for engineering, specification work, and inter-client testing so that all other proposals fit around them rather than competing for early delivery. The core developers have agreed that the CL headliner will be EIP-7732, which introduces enshrined proposer-builder separation (ePBS), and the EL headliner will be EIP-7928, which implements Block-Level Access Lists (BAL).

These two proposals are now the primary focus for development and interoperability testing. ePBS brings protocol-level separation of block proposing and building, reshaping validator duties and builder markets, while BAL makes state access explicit on a per-block basis, enabling greater auditability and potential future parallelisation benefits within the EL.

The decision to focus on ePBS and BAL meant other proposals had to be removed or deferred. EIP-7778, which proposed reducing slot times to six seconds, was dropped because its multi-dimensional fee-market changes conflicted with BAL’s design.

The process for introducing new proposals into Glamsterdam remains open, but only until the Fusaka mainnet releases are prepared. This means that EIP authors still have a window of opportunity to submit CFI proposals for consideration, but once the Fusaka upgrade moves into final release preparation, no new proposals will be accepted for Glamsterdam.

For development teams, the headliner decision means that roadmaps should prioritise ePBS and BAL ahead of any secondary proposals. Testing strategies should also concentrate on these two features, ensuring that test coverage, edge-case scenarios, and interoperability checks are in place.

The immediate focus for all teams is to begin or continue implementation of ePBS and BAL, alongside interoperability testing between clients. Participation in the upcoming BAL breakout session is encouraged, as this will define the final form of the EIP-7928 specification.

Block-Level Access Lists (BAL) Specification

BAL (EIP-7928) is the execution-layer headliner for Glamsterdam, meaning its specification choices directly determine what other features can proceed in the upgrade. It defines how per-block access lists are structured, encoded, and indexed, with the goal of improving auditability, enabling future parallelisation, and ensuring consistent client behaviour.

The decision was made to retain entries for reads such as SLOAD, balance checks, and static calls in the BAL, even though this will add roughly ~50 kB per block. The primary reason for keeping these read entries is that auditors find value in knowing which contracts were touched during execution.

Additionally, these entries may enable future optimisations like parallel batch I/O and transaction parallelisation. This means EL clients will need to ensure both write and read touches are included in the access list for each block.

For the initial implementation, BAL will use RLP encoding. While SSZ offers compact-proof benefits, the current Go SSZ libraries are not mature enough to support production deployment. Keeping RLP ensures consistency with the existing EL serialization approach and avoids integration risks.

System-contract state changes will be separated into pre-execution changes, such as ring-buffer writes and EL-triggered withdrawals, and post-execution changes. Two indexing approaches were discussed: mapping all pre-execution changes to index 0 and all post-execution changes to the end of the list, or ordering indices to match the actual execution sequence.

Toni Wahrstätter will update the EIP with a final proposal and organise a breakout session to reach consensus. To avoid confusion, the group agreed not to call these indices “transaction indices.” Instead, they will be referred to as “block-level access list indices” to make it clear that they apply to the entire block rather than to individual transactions.

Testing & Process Improvements

The main focus is on strengthening testing discipline for major EIPs before they are presented at ACD calls, ensuring that specifications are stable and potential interoperability risks are addressed early. EIP authors are now expected to work closely with the testing team before making their ACD presentations.

This early engagement allows for a clear testing plan, complexity assessment, and resource allocation from the outset. The proactive approach followed by the Block-Access-Lists team was highlighted as a best-practice example.

By engaging the testing team early and enforcing automated test integration, the development process avoids last-minute specification disputes, reduces the likelihood of divergent client implementations, and ensures more predictable Devnet launches. This approach also facilitates repeatable, automated verification for high-impact protocol changes.

“Safe-Head” Proposal

Currently, Ethereum’s consensus and execution layers track a “safe block” that may not always correspond to the fast-confirmed block. The discussion focused on how to better expose fast-confirmation information through APIs, so that applications and infrastructure can make better-informed decisions.

Three approaches were considered.

1. The first is to repurpose the existing safe block tag so that it points to the fast-confirmed block. This would avoid the need for new APIs but would change the current semantics, potentially breaking existing consumers.
2. The second approach is to add a new field such as a fastConfirmedBlock hash, i.e., to the Engine API and JSON-RPC, preserving the current safe block definition while making fast confirmations explicit. This would require client and tooling updates.
3. The third approach would make the meaning of the safe block configurable per consensus-layer client, which would offer flexibility but add configuration complexity.

Data providers, block explorers, and infrastructure operators have been invited to give feedback, i.e., particularly on whether changing the safe block’s meaning would disrupt their systems. Feedback will be collected via the Eth R&D Discord (#execution-specs) before the next ACDE meeting.

ModExp & Contract-Size Changes

The agreed change is to triple the gas cost of the MODEXP precompile in Fusaka. This repricing is intended to prevent MODEXP from becoming a throughput bottleneck.

While Geth and Erigon teams are investigating code-level optimisations to improve efficiency, the repricing remains the consensus solution to maintain predictable performance. The maximum contract size will be increased from 24 KB to 48 KB.

Alongside this, the requirement for a global “warm index” for contract code will be removed, allowing implementations to manage code warming as they see fit. To mitigate potential denial-of-service risks, an additional cold-load gas cost will be introduced.

Stress-testing these changes will be a priority in Devnet-5 to ensure the adjustments do not introduce instability. Repricing MODEXP ensures that no single computational operation can monopolise execution resources, helping to maintain network responsiveness.

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