Prysm’s Recommendation for Fusaka

Our general thinking is:

We believe that the aggressive pace called for by the community, including core devs, will require more frequent and smaller forks. Scope and time are coupled in software engineering—if we want a concrete timeline, the scope needs to stay flexible:

$scope=f(time)$. In the past, we’ve done the reverse:

$time=f(scope)-morefeatures$

That’s led to delays in upgrades, while prioritizing features with limited support. To avoid this, we propose clearly signaling priorities and aligning timelines with the readiness of the most impactful protocol changes.

Our thinking for Fusaka is:

We support an aggressive but achievable goal of upgrading mainnet to Fusaka by the end of Q3 2025. To make that happen, we propose a minimal scope focused on what matters most for the consensus layer. EIP-7594 (Peer DAS) and EIP-7892 (BPO forks) should be treated as the top priority. Everything else mentioned in EIP-7607 should be considered deferred. No additional features in this cycle—a small and fast fork, with Peer DAS as the only consensus-layer change. We’re committed to shipping this fork by the end of Q3 2025. Aside from EIPs, we’d also like to amend the Multiplexing section of p2p-interface.md to say that clients “MUST support yamux and MAY NOT use Mplex”. Client teams would deprecate mplex and require all peers to use either QUIC or yamux, with a strong preference for QUIC. Teams can begin flipping defaults early, ideally before Fusaka, so that when Fusaka ships with mplex deprecated, it’s a non-event.

Note: we did not express any opinion on the execution layer EIP not out of exclusion but because we are not experts on it so we will leave it to the EL teams.

Why EIP-7594?

• Data availability scaling is the most valuable and urgent upgrade for Ethereum today
• We're confident in its progress and believe it can ship before the end of Q3 2025

Why EIP-7892?

• Provide a lightweight and repeatable way to scale DA w/o requiring massive, disruptive changes
• They make scaling blobs more predictable and build confidence in Ethereum’s scaling roadmap
• We think it’s relatively easy to implement and test and can be shipped before the end of Q3 2025

---

If we can’t ship Fusaka under a minimal scope by Q3 2025:

Then we should fully shift Fusaka into H1 2026 and plan for a larger fork instead. We propose a “big and slow” fork that would expand the scope to include EIP-7732 (ePBS) and EIP-7805 (FOCIL), along with smaller improvements like better attestation usage.

Why EIP-7732?

• It scales execution by reducing validation and propagation time
• It improves data availability propagation time
• It enables trustless exchange between proposer and builder
• It lowers reorg and missing block rates and improves liveness
• It strengthens the chain’s censorship resistance
• We think the complexity is well studied
• There's already real progress—Prysm and Teku finalized a multi-client devnet, which sets the stage for broader implementation

Note: EIP-7732 in isolation is a consensus layer only change

Why EIP-7805?

• It improves the entropy of block construction
• It reduces reliance on dominant builders by giving power back to the validator set
• It strengthens the chain’s censorship resistance
• There’s real progress - multiple client implementations have a single-client finalized devnet

Note: EIP-7805 in isolation requires execution layer, engine API, and consensus layer changes