Highlights from the All Core Developers Consensus (ACDC) Call #159

The recent All Core Devs Consensus (ACDC) #159 call, held on June 26, 2025, focused heavily on validating the performance of Fusaka Devnet 2, finalizing key specification changes, and initiating a larger discussion around blob throughput scaling via BPO forks.

Alongside technical updates, the community reviewed the results of intensive performance testing, clarified timelines for upcoming devnets, and began preparing for the next major fork, Glamsterdam.

• Fusaka Devnet 2 Launched
• Sunnyside Labs Report
• Fusaka Consensus Layer (CL) Scope Finalized
• BPO Strategy & Timeline
• Expected Proposals in Glamsterdam Fork

Fusaka Devnet 2 Launched

Fusaka Devnet 2 officially launched on June 26, 2025, at 10 AM UTC. This marks a crucial stage in the broader Fusaka upgrade roadmap. The development team has implemented a structured BPO (Blob Parameter Override) rollout, beginning at Epoch 256.

The BPO changes follow a sequence of increasing, decreasing, and again increasing the blob count, ultimately targeting a maximum of 20 blobs. This phased adjustment is designed to simulate high-load conditions and prepare the network for performance at mainnet scale.

Initial performance has been stable, though some client-specific bugs have emerged. Notably, the Nimbus client has exhibited incorrect NFD values and occasionally produced empty blocks. These issues have already been acknowledged by the Nimbus team, who are actively investigating and working toward resolution.

Apart from this, no critical issues were observed with other consensus layer clients. To streamline testing workflows, the Devnet has activated Watchtower, i.e., an automation tool that checks for new commits on relevant branches and triggers Docker image builds every two minutes.

As the Devnet progresses, testing priorities will include checkpoint syncing, validating new status message formats, and assessing full protocol behavior under varying blob loads. These tests will determine whether the network is ready for Devnet 3, which is expected to serve as the final environment before spec freeze.

Sunnyside Labs Report

The Sunnyside team ran 18 high-throughput devnets on Fusaka Devnet-0 & Devnet-1 specs to evaluate client performance under blob-intensive conditions. Most single-client networks achieved 72 blobs/block, even with the GetBlobsV2 API disabled.

• Lighthouse & Prysm performed consistently well, while Nimbus lagged behind at just ~10 blobs.
• Mixed-client setups also hit target throughput, but revealed subtle cross-client timing & performance discrepancies.
• Bandwidth usage emerged as a limiting factor—Grandine & Lighthouse fullnodes used ~20 Mbps, but others like Prysm, Teku, & Lodestar averaged over 80–100 Mbps, raising concerns for home stakers.
• Verification & processing loads were also uneven: Lighthouse and Grandine optimized blob validation better than others.

Attestation disagreement spiked at high blob counts in some clients, but mixed networks helped mask these failures. The report concludes that while 72-blob throughput is technically achievable, client-specific bottlenecks must be addressed before mainnet.

Future devnets will test bandwidth-constrained environments, multi-blob transactions, and EL interoperability. The results also highlight the value of isolating vs mixing clients to identify weak links, guiding ongoing preparations for a stable Fusaka deployment.

Fusaka Consensus Layer (CL) Scope Finalized

The ACDC #159 call marked a key milestone for the Fusaka upgrade, with the core development teams agreeing to freeze the Consensus Layer (CL) specification. Barnabas confirmed that with the merging of four critical PRs, the CL spec was now stable enough to move forward.

1. PR #4393 – Remove peer sampling in Fulu
2. PR #4394 – Serve DataColumnSidecarsByRoot for finalized epochs
3. PR #4406 – Add some clarifications around new ENR changes
4. PR #4407 – Clarify NFD Disconnect Conditions

The upcoming Devnet 3, scheduled for launch within two weeks, will serve as the proving ground for this frozen spec. No additional CL changes are expected between Devnet 2 and Devnet 3, signaling that Fusaka is on track for mainnet readiness, at least from the consensus side.

However, the Execution Layer (EL) specification is still being finalized and will be addressed in the next All Core Devs (ACD) meeting. While there was brief discussion about potential risks, no teams expressed opposition to freezing the CL spec.

BPO Strategy & Timeline

As Ethereum approaches the finalization of Fusaka, attention is shifting toward how to manage Blob-Parameter-Only (BPO) Forks. With Fusaka introducing PeerDAS, developers anticipate needing to increase blob throughput gradually. BPOs allow them to tweak parameters (e.g., maximum blob count) with minimal coordination overhead.

The goal is to scale responsibly based on real-world mainnet data, rather than assumptions or pre-launch simulations. This approach ensures that changes are responsive to actual outcomes, while still allowing Ethereum to scale over the next few months.

There was agreement that testnets can be more aggressive than mainnet in blob counts:

1. Testnets like Sepolia or Holesky may jump directly to 20–48 blobs for advanced stress testing.
2. Mainnet will adopt a more measured ramp-up, such as 9 → 18 → 24, to minimize operational risk.

The general consensus is to adopt a staggered, data driven approach to scaling after Fusaka. The plan begins with launching Fusaka using a conservative blob limit, such as 9 or 12 blobs, to ensure initial network stability.

Following the launch, developers will observe mainnet behavior over a period of one to two weeks to collect real performance data. Based on this analysis, they will then schedule BPO1, introducing a modest increase in blob capacity, i.e., potentially raising the limit to around 18.

Further adjustments through BPO2 or BPO3 will be considered later, depending on the network’s response and the insights gained from earlier stages.

A central debate during the discussion focused on whether multiple BPOs such as BPO1, BPO2, and BPO3 should be prebaked into Fusaka client releases. Proponents of prebaking argued that it would reduce coordination overhead and allow for a more predictable upgrade cadence.

By bundling in the BPOs ahead of time, teams could avoid repeated releases and streamline the deployment timeline. On the other hand, opponents expressed concerns about locking in parameter values too early. They warned that doing so without observing real world performance could lead to misalignment with actual network behavior.

Additionally, any need to reverse or adjust a prebaked BPO would require a complex override, potentially undermining operator trust and introducing unnecessary friction.

The dominant consensus leaned toward a balanced approach: bake in only BPO1 for the initial release, and leave BPO2 and future changes open for evaluation based on live network data collected post Fusaka. As it stands, Fusaka is expected to ship with BPO1 preincluded, representing a modest but safe step toward higher throughput.

Decisions on BPO2 and beyond will be made later, once post launch metrics are available. Meanwhile, testnets will continue to operate with higher blob targets, providing a sandbox environment for stress testing under more aggressive parameters.

Expected Proposals in Glamsterdam Fork

As the Fusaka upgrade nears spec freeze, attention is starting to shift toward the next major Ethereum fork: Glamsterdam. Two key items were discussed: an old PR related to slot timing flexibility, and a headliner proposal to halve Ethereum’s slot duration from 12 seconds to 6 seconds.

(I) PR 3510: Preparing for Flexible Slot Timings

This PR resurfaced because it lays essential groundwork for any future changes in slot timing. The core idea was to change how the spec defines critical deadlines (like attestation or aggregation windows), shifting from the current “intervals per slot” format to explicit millisecond-based values.

If Ethereum ever adopts nonsymmetric or shorter slot durations, the existing spec language would become fragile or ambiguous. Updating it now creates a smoother path for upcoming forks that require more flexibility.

There was cautious support for merging the PR, with a few minor concerns about compatibility across clients and configuration handling. Ultimately, developers agreed to merge it only into Glamsterdam testnet branches, where it can be tested safely before impacting mainnet.

(II) EIP-7782: Cutting Slot Times from 12s to 6s

This change could significantly reshape Ethereum’s performance and user experience.

By cutting slot times from 12 seconds to 6 seconds, the network could benefit from much faster transaction inclusion, reducing latency from around six seconds to approximately three.

It would also increase censorship resistance by doubling the number of block producers per minute, making it harder for any single actor to suppress transactions.

In addition, shorter slots could lead to lower DEX fees, as reduced timing windows limit arbitrage opportunities and tighten spreads for liquidity providers.

Finality would also be accelerated, potentially cutting it down from 13 to 19 minutes to under 10.

With the Fusaka CL spec now frozen and Devnet 3 just around the corner, the call concluded on a note of progress and preparedness. Developers agreed that unless unexpected issues arise during testing, there would be no further changes needed to the consensus spec.

The remaining execution-layer items would be finalized in the next All Core Devs call, clearing the path for coordinated client releases and final testing ahead of mainnet readiness. Attention is now turning toward the Glamsterdam upgrade, particularly its potential headliner features like shorter slot times and slot restructuring.

Although no decisions were made in this call, the groundwork has been laid for a more structured debate in the coming weeks. Developers were encouraged to continue these discussions asynchronously before the next ACDC, where firmer priorities for Glamsterdam will likely be set.

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