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

• Fusaka Updates
• Glamsterdam Updates
• The Weld
• EIPs Discussed

Fusaka Updates

Fusaka Devnet-3 has been running for a couple of weeks and recently went through another round of non-finality testing. The network was deliberately left in a non-finalizing state for several days before being healed.

Participation initially rose to around 62% but then dipped back into the low-50s, which indicated partial recovery but also highlighted some persistent instability. Devnet-5 is also live.

In preparation for Holesky, Shadow Forks dry-runs have been conducted. The plan is to execute a Shadow Fork before Holesky and again before each subsequent testnet once client pull requests are merged or release readiness is indicated.

The deployment process for Fusaka testnets was revisited to ensure a clear and consistent schedule. The timing for Sepolia and Hoodi required more discussion, specifically whether there should be one or two weeks between Holesky and Sepolia.

Community consensus leaned toward a two-week gap between a client release and a “real” testnet like Sepolia, ensuring infrastructure providers and client teams had enough time to test and address potential issues.

Glamsterdam Updates

The call explicitly carved out time for Glamsterdam headliners, namely ePBS and Block-level Access Lists (BALs). These are among the most critical features slated for the upgrade, and the discussion centered on incremental improvements and timelines.

With regard to scheduling, the teams indicated that the first devnet should be ready by the end of the current month. Additionally, a ePBS breakout session is scheduled for Friday, where the scope of devnet-0, targeted for the end of October, will be finalized.

Client teams working on ePBS are particularly encouraged to attend this session. Having concrete devnet timelines and recurring breakout sessions helps reduce scope uncertainty for Glamsterdam features ahead of broader testnet deployment.

The Weld

The STEEL Team announced that in Q4 2025, all code from ethereum/execution-spec-tests (EEST) will be merged into ethereum/execution-specs (EELS) in an initiative called The Weld. This consolidation will unify Python tests, test vector generation frameworks, and related tooling into a single repository.

The primary motivation is to simplify workflows by placing specs and tests together, eliminating version mismatches and reducing developer friction.

• For developers, the change is designed to be minimally disruptive.
• Spec developers will continue to open PRs in the specs repository.
• Test developers will eventually shift their contributions from EEST into EELS.
• Client developers will see no changes, as releases will still be available as before.

Leading up to the transition, all open PRs in EEST will be merged or closed, followed by a short 12–48 hour freeze where core contributors align coding standards and enable CI workflows in the unified repo. After the freeze, contributors will benefit from a smoother and more integrated tooling experience.

Currently, testing relies on a complex setup involving a separate Resolver tool that connects EEST to EELS through HTTP requests, requiring cloning and manual configuration across two repositories. This process makes test coverage and debugging cumbersome.

Post-Weld, all sources will live in one repository, allowing spec implementers to easily add tests, generate coverage reports, and debug by directly stepping into the spec from test code. The result is a cleaner, faster, and more intuitive development environment for the Ethereum ecosystem.

EIPs Discussed

• EIP-7932 explores new transaction structures, proposing the potential shift from RLP to SSZ serialization. The goal is to unify encoding across layers, simplify proof construction, and align Ethereum’s execution layer with its consensus layer.

Developers debated whether moving to SSZ could introduce adoption blockers. Some argued that changing serialization formats risks compatibility issues across clients and tooling, while others saw SSZ as a natural evolution given its wide use in the consensus layer.

• EIP-7980 focuses on signature flexibility, proposing support for alternatives like ED25519 in addition to secp256k1. However, concerns were raised about ED25519’s lack of post-quantum resistance, which makes it unsuitable as a long-term standard.

Many developers emphasized that Ethereum should prioritize account abstraction as a mechanism to support multiple signature schemes at the smart contract level, rather than modifying the protocol itself. The consensus was that precompiles and account abstraction offer safer flexibility, while protocol-level signature changes are too disruptive and risky at this stage.

• EIP-7976 proposes raising the calldata floor cost from 10 gas to 15 gas to reduce worst-case block sizes. The idea is that zero-value calldata bytes currently allow overly large pathological blocks, which place unnecessary stress on execution.

By increasing the floor cost, the maximum block size would be reduced by about 33%, while only affecting roughly 1.5% of transactions, mainly those with unusually large calldata payloads. This adjustment is considered a low-risk, high-reward measure that strengthens execution stability and improves predictability for block production.

• EIP-7981 complements EIP-7976 by addressing the gas model for EIP-2930 access lists. Currently, access lists charge for storage but not their data footprint, which makes it possible to combine them with calldata to create worst-case block scenarios.

This proposal introduces a calldata-like fee for access list data, ensuring that their use aligns with their intended purpose of reducing access costs rather than bloating blocks. The change effectively removes the economic incentive to misuse access lists while preserving their utility for legitimate efficiency gains.

• EIP-2780 reconsiders the base transaction cost, reducing it from 21,000 gas to 6,000 while adding a 25,000 gas surcharge for transactions that create new accounts. The aim is to encourage smaller, more frequent transactions rather than batching large workloads into single transactions, which reduces opportunities for parallel execution.

Some developers noted that this effectively behaves like a gas limit increase, as it would enable more transactions per block. However, the additional surcharge for account creation addresses the state growth issue that prevented similar proposals in the past.

At the close of the call, the chair reminded participants that he would be going on leave at the end of the month, with Ansgar stepping in as interim chair until year-end. This leadership transition was highlighted as particularly relevant since much of the coming period will be occupied by Glamsterdam scoping discussions.

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