All Core Devs - Consensus (ACDC) #162, August 07 2025

Protocol Calls & happenings
,
4

ACDC #162 Action Items

  • fusaka-devnet-4 is live! Focus on performance to identify any places to harden PeerDAS.
  • Active discussions are under way to find the right Fusaka timelines. Expect updates here soon. There is general agreement to proceed with Holesky in September.
  • Focus all effort on preparation for Fusaka releases — the main blocker right now seems to be merging in feature branches.
  • EIP-7732 (ePBS) has been selected as the Glamsterdam headliner and moved to SFI.

ACDC #162 Summary
Fusaka

  • fusaka-devnet-3 showing excellent participation with successful testing
    • Non-finality test with 40% network offline - network healed in under one epoch
    • Current test: most super nodes offline with submitted exits for self-healing validation
  • fusaka-devnet-4 launching tomorrow to simulate mainnet-like scale
    • ~10% of mainnet size
    • Testing blob scaling from 8 to 48-72 blobs
    • One day data collection per step to inform PeerDAS scaling limits

BPO Schedule Discussion

  • https://notes.ethereum.org/@jtraglia/fusaka_scheduling
  • Proposed 3 BPOs for a gradual rollout along with Fusaka launch
    • BPO 1: December 15, 2025
    • BPO 2: January 14, 2026
    • BPO 3: February 10, 2026
    • Target: 21 blobs with 32 blob limit after phase 1
  • Alternative compressed timeline suggested
    • November 24 → December 15 → January 14
    • Following the same trajectory gets to 8x scaling by March 2026
  • fusaka-devnet-4 testing will validate actual target/max numbers
  • Point made that realistic spacing is 4 weeks for observation and reaction periods, 3 weeks is doable but tight
  • Agreement: ship fork with data informed by fusaka-devnet-4 to parameters we know are safe to lock in; will adjust via subsequent BPOs pending mainnet analysis

Timeline Concerns from Client Teams

  • Lodestar, Prysm, and Nimbus requesting 4-week delay with the following concerns:
    • Major concern: code not on master branches yet
    • Lots of code across three clients that needs trunk integration
    • No devnets with spec-frozen code on production branches
  • Specific technical gaps also identified
    • Limited private mempool testing without GetBlobs v2
    • Testing for “perfect PeerDAS” configuration and backfill implementations
  • Technical concerns were addressed on the call
    • GetBlobs v2 has in fact been tested with no issues, miscommunication there
    • Acknowledgement of “perfect PeerDAS” and backfill but these are client specific and we are working to mitigate the concerns; these features round out a client against specific edge cases but given implementations in some clients not having them in all clients is not a strict blocker
  • To move forward, we agreed to schedule Holesky in September without requirement for a formal release from clients (we have precedent for this with Holesky already).
  • I’m discussing timelines with clients to find a solution that strikes the right tradeoff between speed and security. Will update on further ACDs.

Beacon API Updates

Glamsterdam Fork Planning

Glamsterdam Implementation Timelines

  • To close the call, we discussed potential timelines for Glamsterdam given ePBS as the headliner, along with the interplay with other EIPs including FOCIL
    • estimates on the CL side for ePBS converged around March/April ’26 for the bulk of implementation work (not mainnet!), with FOCIL adding 1-2 months to those timelines
  • Consensus anchored on a phased approach: stabilize SFI EIPs first, then consider CFI EIPs

edit: updated comment on Glamsterdam timelines to clarify this was not a date for mainnet

1 Like