All Core Devs - Execution (ACDE) #218, August 14, 2025

Protocol Calls & happenings
,
4

ACDE TL;DW

Fusaka

  • The issues that came up indevnet-4 warrant a new devnet. We’ll have devnet-5 to test the fixes (no other spec changes).
  • On Monday’s ACDT, we’ll determine when to launch devnet-5 , ideally before ACDC next week
  • We didn’t set dates yet, will wait until devnets & testing stabilizes before doing that

Glamsterdam

  • EPBS & BALs are confirmed as headliners :tada:
  • FOCIL still CFI’d, will decide on inclusion once EPBS & BALs are live on devnets
  • Deadline for other EIP PFI proposals is when we put out Fusaka mainnet releases (moved from Aug 21st)
  • We discussed many spec changes for BALs, @toniwahrstatter update the EIP based on the conversation and set up a BAL breakout room to discuss further once we have an updated spec

We didn’t have much time to discuss the other topics, but two EIPs were shared on the agenda, and we briefly continued the safe head discussion by @mkalinin

Full Summary (AI-gen :robot:)

ACDE #218 Summary – August 14 2025

Action Items

  1. Devnet‑4 Stabilisation & Devnet‑5 Launch

    • Fix outstanding bugs: Devnet‑4 launched cleanly through BPO 1–2, but BPO 3 exposed several problems.

      – Erigon computed the blob‑fee incorrectly, causing it to fork away from other execution clients; a fix has been merged in Geth and other ELs but Erigon is still investigating.

      – Lighthouse and Nimbus struggled with peer discovery and sync due to poor boot‑node diversity; half the boot nodes have been switched from Lighthouse–Geth to Prism–Geth pairs, but both clients still need fixes to reliably find peers.

      – No mass validator slashing is expected because the super‑node topology mirrors mainnet and should allow finality once the client fixes land.

      – Update fork‑ID logic in all clients and improve boot‑node diversity prior to Devnet‑5. Owners: all EL/CL teams • Due: before Devnet‑5.

    • Update‑fraction specification: when the base‑fee update fraction changes at a fork, use the fork parameters of the current block, not the parent. This applies to constants such as BLOB_BASE_FEE_UPDATE_FRACTION and resolves the inconsistency that triggered the DevNet‑4 fork. Anders Elowsson will update the relevant EIPs, and Mario Vega will publish static tests to ensure all clients implement the same logic.

      Context: some EL clients used the parent block’s update fraction when computing the next block’s parameters; others used the current block’s constants. The call agreed that the current‑block approach is simpler and more consistent, but future EIPs must explicitly specify which set of parameters to use.

    • Chain‑config RPC: estimate and implement a new eth_getChainConfig JSON‑RPC method (mirroring the consensus layer’s engine_getPayloadBodiesByHash) to expose the static fork‑ID configuration used by each client. Devnet‑5 will not launch until all EL clients implement this RPC. Owners: all EL teams • Due: before Devnet‑5.

    • Devnet‑5 planning: once Devnet‑4 finalises cleanly, schedule Devnet‑5 with fixes and increased minority‑client representation (Grandine/Erigon/Lodestar ~3–5 %), keeping Lighthouse/Prism at realistic levels. Owners: PandaOps, client teams • Due: next ACDE if ready.

  2. Fusaka Timelines

    • Postpone schedule decisions: Alex Stokes proposed Sepolia/Holesky client releases on 8 September, a Holesky fork on 15 September and a Sepolia fork on 29 September, but multiple teams objected because Devnet‑4 is still unstable, static tests for fork‑parameter calculations aren’t ready and several clients are running off feature branches. Consensus was to defer timeline discussions until Devnet‑5 is clean and stable. Once Devnet‑5 finalises, dates will be selected for public test‑net forks and client releases. Owners: coordinators • Due: TBD.

  3. Glamsterdam Headliners Finalised

    • ePBS & BAL: Core devs confirmed that EIP‑7732 (ePBS)—enshrined proposer‑builder separation—is the consensus‑layer headliner and EIP‑7928 (Block‑Level Access Lists) is the execution‑layer headliner. Both must be implemented and tested before any additional features are added.

    • Fossil & 6‑second slots: EIP‑7778 (6‑second slots) was removed because its multi‑dimensional fee‑market changes conflicted with block access lists; EIP‑7702 (Fossil)—a proposed in‑protocol Ethereum Virtual Machine (EVM) to support account abstraction—remains CFI. Fossil’s inclusion will be evaluated only after ePBS and BAL are far along.

    • Accept new CFI proposals for Glamsterdam until the Fusaka mainnet releases are prepared (post‑launch proposals close once Fusaka is live). Owners: EIP authors.

  4. Block‑Level Access Lists (BAL) Specification

    • State‑read locations: keep entries for reads (e.g., SLOAD, balance checks, static calls) in the BAL, even though they add ~50 kB per block. Auditors indicated that knowing which contracts were touched is valuable, and these entries may enable future parallel batch I/O and transaction parallelisation.

    • Serialisation: use RLP for now—SSZ provides compact proofs but lacks mature Go libraries; the EL can revisit SSZ once the tooling improves. Tim suggested that migrating peer‑to‑peer messages to SSZ could be a first step, but for Glamsterdam the EL will stick to RLP.

    • System‑contract handling: split pre‑execution system‑contract state changes (e.g., ring buffer writes, EL‑triggered withdrawals) and post‑execution changes. One proposal is to map all pre‑execution changes to index 0 and all post‑execution changes after the final transaction; another is to order indices to mirror the actual execution sequence. Toni Wahrstätter will update the EIP with a concrete proposal and convene a breakout call.

    • Naming: avoid calling these indices “transaction indices”; instead, use “block‑level access list indices.”

  5. Testing & Process Improvements

    • Early collaboration: Mario Vega reminded EIP authors to consult the testing team before ACD presentations. Every Amsterdam candidate should outline its testing requirements and complexity up front to avoid last‑minute surprises. The block‑access‑lists team’s proactive engagement was cited as a model.

    • Static tests: the testing team will publish static test suites for fork‑boundary parameter calculations and the MODEXP gas‑repricing changes. Clients must integrate these tests before launching Devnet‑5 and beyond.

  6. “Safe‑Head” Proposal

    • Mikael Kalinin outlined options for fast‑confirmation exposure: repurpose the existing safe block tag to point to the fast‑confirmed block; add a separate fastConfirmedBlock hash to the Engine API and JSON‑RPC; or make the meaning of the safe block configurable per CL client. The first option requires no API changes but redefines semantics that consumers might rely on. Data providers are encouraged to provide feedback via the Eth R&D Discord (#execution-specs) before the next call.

  7. ModExp and Contract‑Size Changes

    • MODEXP repricing: the EIP‑7883 repricing will triple the cost of the MODEXP precompile in Fusaka. Although geth and Erigon are investigating code‑level optimisations, the repricing remains the consensus fix to prevent MODEXP from becoming a throughput bottleneck.

    • Contract‑size limit: EIP‑7907 will raise the maximum contract size to 48 KB (doubling it from the current 24 KB) and remove the requirement to maintain a global “warm index” for contract code. Implementations will be free to warm code as they see fit; additional cold‑load gas has been added to mitigate DoS vectors. Stress‑testing this change will be a priority in Devnet‑5.

Summary

Devnet‑4 Status & BPO Rule Issues

  • Devnet‑4 launched with BPO 1 and 2 transitions, but BPO 3 exposed multiple issues. Erigon forked off because it used different gas‑calculation logic for block fee; Lighthouse suffered from peer‑discovery problems and couldn’t sync to head; Nimbus also struggled to connect. Boot nodes were all Lighthouse+Geth pairs, so half were switched to Prism+Geth to improve diversity. The network is working toward finalising the chain by end‑of‑day and proceeding to BPO 5 tomorrow.

  • To finalise Devnet‑4 and avoid mass validator slashing, teams must fix EL and CL bugs and ensure super‑node finalisation logic operates correctly.

BPO Update‑Fraction Calculation

  • The update fraction calculation (used when moving from one BPO to the next) had inconsistent implementations. After debate, core devs agreed to use the current block’s fork parameters rather than the parent’s, simplifying the implementation (see the discussion). Anders will update the relevant EIP and Mario will produce static tests to ensure all clients handle future fork boundaries consistently. The decision sets a precedent that future EIPs must explicitly specify whether current or parent parameters are used.

Fusaka Timelines & Devnet‑5 Planning

  • Alex’s proposed timeline (Sep 8 release for Sepolia/Holesky, Sep 15 Holesky fork, Sep 29 Sepolia fork) faced strong pushback because Devnet‑4 still isn’t stable and static tests for fork‑parameter calculations are missing. Several CL teams (Lodestar, Prysm and Nimbus) requested an extra 4 weeks; consensus was to delay timeline discussions until Devnet‑5 is clean and stable and CL branches are merged into main.

  • Devnet‑5 will include fixes from Devnet‑4, static tests and improved minority‑client representation. Launch will be discussed on Monday’s testing call once remaining issues are resolved. Timeline decisions will only follow after a successful Devnet‑5.

Glamsterdam Headliner Finalisation & Scope

  • Core devs confirmed that EIP‑7732 (ePBS) is the consensus‑layer headliner and EIP‑7928 (Block‑Level Access Lists) is the execution‑layer headliner.

  • EIP‑7778 (6‑second slots) was removed due to conflicts with BAL; EIP‑7702 (Fossil) remains CFI and will be revisited only after ePBS and BAL implementations are stable. New proposals for Glamsterdam will be accepted until Fusaka mainnet releases are ready.

  • Initial Glamsterdam timelines were discussed on the ACDC call: CL teams estimate ePBS implementation work converging around March/April 2026; FOCIL adds 1–2 months. Consensus is to follow a phased approach—stabilise SFI EIPs first, then consider CFI EIPs.

Block‑Level Access Lists (EIP‑7928) Decisions

  • State‑read locations will remain in the BAL spec despite increasing size (~21 blobs → 50 kB per block) because they enable parallel batch I/O, transaction parallelisation and auditability.

  • Serialization: RLP will be used for encoding; SSZ was rejected for now due to limited Go‑SSZ library support and to maintain EL serialization consistency.

  • System contracts: pre‑execution changes will be recorded at index 0 and post‑execution changes at the end of the list; indices will be called “block‑level access list indices”.

    Toni (@nerolation) will update the EIP accordingly and schedule a breakout.

Other Discussion Points

  • Max blobs per transaction: final spec sets a cap of 6 blobs per transaction in the PeerDAS API; the max‑per‑tx limit will be removed from the BPO schedule to simplify client logic.

  • Base‑fee update fraction remains in the BPO schedule; removing it would limit future flexibility and require extra mapping between BPOs and fork constants.

  • ModExp repricing: teams acknowledged that client implementations of MODEXP vary widely; consensus was to triple the gas price to avoid bottlenecks, while allowing optimisations to continue (see PR #9855).

  • Safe‑head proposal: @mikaelsq presented a proposal to repurpose the safe block as the “fast confirmed” block or introduce a new RPC (see discussion). Stakeholders are asked to provide feedback, particularly on whether redefining the safe block’s semantics would impact existing API consumers.

  • Testing process: Mario stressed that EIP authors must collaborate with the testing team before presenting to ACD; the block‑access‑lists team’s collaboration was cited as a good example. All pending Glamsterdam EIPs should review testing complexity to avoid delays.

Next Steps

  • Aug 18 Testing Call: assess progress on Devnet‑4 fixes (Lighthouse/Nimbus sync), chain‑config RPC effort, and readiness for Devnet‑5. If fixes land, schedule Devnet‑5 launch.

  • Next ACDE (Aug 28): revisit Fusaka timelines after Devnet‑5, review EIP‑7907 tests, and discuss Glamsterdam progress.

  • BAL Breakout: Toni to circulate updated EIP‑7928 text and organise a breakout session to finalise system‑contract handling and SSZ vs RLP details.

  • Headliner EIPs Implementation: EL/CL teams to begin coding ePBS and BAL; only after stability is proven will Fossil be reconsidered for Glamsterdam.

  • Safe‑Head Feedback: block explorers and API providers to send feedback on the fast‑confirmation proposal before the next ACDE.

2 Likes