Ethereum Fusaka upgrade begins its staged rollout across public testnets in October and targets mainnet for early December. The headline change is PeerDAS (peer data availability sampling), a redesign that lets nodes validate rollup data without downloading every blob. Because PeerDAS expands capacity, developers will use Blob‑Parameter‑Only (BPO) forks to raise blob limits gradually and safely. This explainer clarifies what BPO forks are, how they work in practice, what changes across testnets starting now, and what users and builders should watch next.
What is “Fusaka” and why BPO forks matter
Fusaka is Ethereum’s next network upgrade after Pectra. It focuses on scaling the blob data layer that rollups use for posting batches. Instead of leaping straight to large blob caps, core devs are applying incremental BPO forks that only adjust two values per block: the blob target (average) and blob maximum (hard cap). This controlled approach reduces risk, gives client teams room to observe network behavior, and provides rollups a predictable capacity runway.
How Blob‑Parameter‑Only forks work (step‑by‑step)
- PeerDAS activates with Fusaka, enabling nodes to verify the availability of data using probabilistic sampling rather than full blob downloads.
- BPO forks adjust parameters only: no new EIPs or features ship in these steps. Clients typically don’t require new software; instead the network applies a coordinated parameter update.
- Staged increases: the plan introduces successive BPOs (BPO1, BPO2, and potentially more later) to lift capacity while monitoring side‑effects (latency, gossip bandwidth, orphan rates).
- Measure and iterate: telemetry across testnets (Holesky, Sepolia, Hoodi) informs whether each increment behaves as expected before mainnet changes proceed.
- Mainnet ramp: once testnets validate safety, mainnet adopts the same increments on a published schedule.
BPO scope vs. a full hard fork
BPO forks are intentionally narrow. They do not add features, opcode changes, or consensus tweaks; they only modify blob target and maximum. In contrast, a traditional hard fork bundles multiple EIPs and requires client releases and wider coordination. BPOs therefore ship faster, lower risk and specifically tune throughput.
Key parameters and timeline
Below is a concise view of what’s planned and when. Times are indicative based on today’s public schedules and may adjust per client readiness.
Planned blob parameters
| Fork | Target blobs per block | Max blobs per block | Expected effect (qualitative) |
|---|---|---|---|
| Current (post‑Pectra baseline) | 6 | 9 | Status quo since proto‑danksharding activation (EIP‑4844 era), rollups compete for blobs during peaks. |
| BPO1 | 10 | 15 | Less frequent blob scarcity, lower fees for L2 posting during busy periods; small p2p bandwidth uptick expected. |
| BPO2 | 14 | 21 | Second step toward higher capacity; stress‑tests PeerDAS networking improvements. |
Figure 1. Fusaka Ethereum planned blob targets and maximums across Baseline, BPO1 and BPO2.
Testnet rollout window (October)
| Testnet | Phase | What happens |
| Holesky | Fusaka + BPOs begin early October | Activate Fusaka, then BPO1 and BPO2 on schedule to validate parameter increases under real load. |
| Sepolia | Mid October | Mirrors Holesky changes to confirm behavior with a different node/operator mix. |
| Hoodi | Late October | Final public test before mainnet scheduling. |
Benefits and risks
Pros
Safety‑first scaling: parameter‑only upgrades reduce complexity and allow rapid rollback if needed.
Lower L2 posting costs: more blobs per block reduce congestion pressure on rollup batch publishing.
Figure 2. Illustrative inverse relationship between target blobs per block and relative L2 posting cost.
Predictability for builders: a published sequence of BPOs signals capacity growth, aiding fee modeling and throughput planning.
Risks / trade‑offs
Network bandwidth: raising blob limits increases gossip load; weaker nodes may need tuning or better peering.
MEV dynamics: larger blob capacity may subtly shift builder/relayer incentives around blob inclusion.
Rollup heterogeneity: not all L2s benefit equally; gains depend on batch frequency, compression, and inclusion strategies.
Quick primer: blobs, PeerDAS and rollups
Blobs are inexpensive data payloads used by rollups to publish transaction batches. Validators confirm the data is available without having to keep it permanently. PeerDAS replaces full downloads with statistical sampling among peers to check availability, drastically reducing bandwidth needs and letting the network lift blob limits without compromising security assumptions. As blob capacity rises, rollups can batch more often or larger, improving latency and smoothing fees.
What is a BPO fork and will I need to update my client?
A BPO is technically a fork but it does not introduce new features; it only bumps blob parameters. Client updates are usually not required for each BPO step because no new logic ships in these increments. Operators should still monitor announcements for any exception.
How soon will mainnet see higher blob limits?
After the October testnet cycle completes and metrics look healthy, mainnet adopts the same increments around the Fusaka timeline in early December, followed by the staged BPOs in subsequent weeks per the public schedule.
Will higher blob limits break smaller nodes or home validators?
They should not, given PeerDAS efficiency and incremental ramps. However, operators on constrained connections may want to review p2p settings and keep clients up to date to handle modest bandwidth increases.
What is Fusaka Ethereum?
Fusaka Ethereum is the next network upgrade that enables PeerDAS and prepares the chain for higher blob capacity through Blob Parameter Only forks. It focuses on scaling data availability for rollups without changing execution semantics.
What future does Ethereum have after Fusaka Ethereum?
With PeerDAS and staged capacity increases, Ethereum can support larger rollup throughput while preserving decentralization. This sets the stage for more competitive fees and faster confirmations across L2 ecosystems through 2026 and beyond.
How reliable is Ethereum for builders and users today?
Ethereum remains highly reliable thanks to client diversity, rigorous testnet phases and conservative parameter ramps. Fusaka Ethereum continues this tradition by isolating changes to data availability and measuring real world effects before mainnet.
What is happening with Ethereum right now?
Testnets are activating Fusaka Ethereum and the first BPO steps in October. Core teams are measuring bandwidth, propagation and blob utilization to calibrate mainnet parameters for December.
What to watch next
Telemetry from Holesky/Sepolia: p2p bandwidth, block propagation times, orphan rates, and blob utilization under peak load.
Rollup responses: L2s may adjust batch intervals or compression settings to exploit new capacity; watch for throughput targets from major L2 teams.
Potential additional BPOs: core devs have discussed more than two increments if metrics warrant, giving Ethereum a repeatable capacity lever ahead of future upgrades.
Holesky sunset: with activations concluding, Holesky’s retirement timeline matters for test infrastructure and tooling.
Sources and methodology
This explainer draws on public communications and technical notes by Ethereum core developers and community threads discussing BPO forks, PeerDAS and the Fusaka schedule. We prioritized primary sources and recent engineering updates published in late September and early October.
Conclusion
Fusaka’s PeerDAS makes blob scaling feasible without overburdening validators. BPO forks then turn that capability into reality through small, measured steps. If testnets validate the approach this month, mainnet will likely see materially higher blob capacity within weeks, translating into lower posting costs and steadier throughput for rollups. For users, the change should be invisible. For builders, it’s a practical capacity roadmap.
2 Comments
Pingback: The Crypto Tides - Tokenised stocks need real investor safeguards models gaps and the path forward (October 2025)
Pingback: The Crypto Tides - Ethereum Fusaka Sepolia upgrade readiness for OP Stack and Erigon 3.2.0