Ethereum Fusaka upgrade: what to expect after Pectra

Every Ethereum upgrade in recent memory has followed the same emotional arc: years of research and argument, months of devnet testing, a wave of speculation about which features made the cut, and then — within days of activation — almost nothing visible to the average user. Fusaka, the upgrade that follows Pectra, is likely to fit that pattern on the surface while quietly delivering one of the most consequential capacity changes in the network’s history. Where Pectra improved staking flows, account abstraction and validator UX, Fusaka is built almost entirely around a single objective: scale the data layer that rollups depend on. Its centerpiece, PeerDAS, changes how Ethereum handles blob data and opens the door to a multiple-fold increase in the volume of data the network can process per block — which translates, downstream, into cheaper L2 transactions, cheaper rollup operations and a very different cost structure for the entire layer 2 ecosystem. Alongside that centerpiece sit a handful of smaller EIPs that tighten gas economics, improve smart contract capabilities and prepare the ground for the even more ambitious upgrades that follow. Understanding what Fusaka actually contains — and what it deliberately defers — is the difference between expecting a fee-free revolution and recognizing the gradual, compounding work of scaling a decentralized network without breaking it.

Where Fusaka sits in the roadmap

Naming conventions in Ethereum follow the same discipline as metro systems: each execution-layer upgrade takes its name from a star or astronomical object. The Merge, Shanghai, Cancun, Deneb, Prague, Electra — and now Fusaka, a contraction of “Fusu” and “Osaka,” the two city Devcon host names that seeded the codename. The upgrade is the first full hard fork after Pectra activated in mid-2025, and its scope reflects a deliberate philosophy: rather than bundling dozens of EIPs into a single massive release, the post-Pectra roadmap favors focused upgrades, each carrying a small number of deeply tested changes.

The timeline as it stood through 2025 and into 2026:

Milestone	Period	What happened or is expected
Pectra activation	Mid-2025	Account abstraction, staking improvements, higher blob target and max
Fusaka devnets and testnets	2025	PeerDAS implementations tested across successive devnets; final scope locked
Fusaka activation	Late 2025, planned	PeerDAS, BPO fork machinery and the supporting EIP set go live
First BPO forks	Rolling through 2026	Blob capacity parameters raised in steps without hard forks
Gas limit increase	2025–2026, community decision	Execution block gas limit raised from 30M toward 45M and beyond, via consensus

The table’s most distinctive row is the BPO one. “Blob parameter-only” forks are a new mechanism introduced by EIP-7892: lightweight forks that change only blob-related configuration — target and maximum blob counts — without touching any other consensus logic. The purpose is to separate capacity tuning from feature work. Earlier, raising blob capacity required waiting for the next full upgrade; under the BPO mechanism, the network can adjust blob throughput on a faster cadence, with safety checks between each step, while reserving full hard forks for code-level changes. This is a governance innovation as much as a technical one, and it signals how Ethereum intends to scale from here: in measured, reversible increments rather than dramatic leaps.

PeerDAS: the centerpiece, explained plainly

PeerDAS — peer data availability sampling, specified in EIP-7594 — is the heart of the upgrade, and its logic can be described without mathematics. Before Fusaka, every consensus node validating a block had to download and hold the complete set of blob data attached to it. Blobs are large, and their capacity was therefore capped at what a solo staker’s home connection could handle. Data availability sampling, which DAS in general enables, breaks each blob into erasure-coded fragments distributed across the network; a node then downloads only a random sample of fragments and can verify with overwhelming statistical certainty that the full data exists somewhere — without ever holding it all. Distributed storage replaces complete storage, and the ceiling on blob capacity lifts accordingly.

What this means at each layer of the ecosystem:

• For rollups. More blob capacity per slot means more transaction data per unit of time, and blob prices — which had been the dominant cost line for rollups during congestion — become structurally cheaper. Layer 2 fees that had settled around fractions of a cent gain further headroom, and rollups can lower their own overhead margins.
• For validators. Node bandwidth and storage requirements grow more slowly than capacity grows, because sampling means no single node holds everything. The upgrade is explicitly designed to let capacity expand without pricing home stakers out of the network.
• For the base layer. The blob base fee market — the pricing mechanism introduced with EIP-4844 — continues to operate as before, but with more room beneath the ceiling, meaning fewer fee explosions during rollup demand spikes.

The capacity numbers deserve careful framing. The first BPO fork after Fusaka was designed to raise the blob target and max to multiples of the Pectra-era figures, and subsequent BPO forks push further, with the research community targeting an eventual path toward gigabytes per slot over successive upgrades. None of this arrives in a single step: each increase is gated by network health measurements, and the BPO mechanism exists precisely so that capacity can be dialed back if the sampled data reveals stress. The realistic near-term expectation is not “cheap forever” but “cheaper most of the time, with much higher ceilings before congestion bites.”

The supporting cast: the EIPs that matter beyond PeerDAS

Fusaka’s final scope settled into a compact set of changes, most of them small in code but meaningful in effect. The list below is the practical map of the upgrade’s content after PeerDAS and the BPO machinery:

1. EIP-7623 — a floor price for calldata. Dense calldata had been a loophole by which L2s published data below its true resource cost; this EIP raises the cost of calldata-heavy transactions so that the cheapest viable path remains blobs. It is an economics fix with no user-visible interface, and it primarily restructures the incentive landscape between L1 data publication and rollups.
2. EIP-7825 — a per-transaction gas cap. Introducing a protocol-level ceiling of about 16.7 million gas per transaction, this change prevents any single transaction from monopolizing a block, improving predictability for block builders and removing an attack vector that had been theoretical for years.
3. EIP-7883 — modexp repricing. The modular exponentiation precompile, used in zero-knowledge proofs and certain cryptographic operations, gets a repricing that corrects underpriced workloads and better reflects actual computation cost.
4. EIP-7918 — a floor on the blob base fee. Blob pricing gains a lower bound tied to execution gas prices, preventing the pathological scenario where blobs became nearly free during extended inactivity and then repriced violently on demand. The result is smoother blob market behavior.
5. EIP-7917 — predetermined proposer schedule. The validator selection sequence for upcoming slots becomes computable ahead of time from the beacon state, which improves reliability for proposer-based applications and prep proposer commitments — a building block for future inclusion-list designs against censorship.
6. EIP-7939 — the clz opcode. A small but beloved addition for developers: count-leading-zeros as a native EVM operation, which makes certain arithmetic and bit-manipulation patterns dramatically cheaper to compute on-chain.
7. EIP-7951 — the secp256r1 precompile. Native verification for the elliptic curve used in Apple’s Secure Enclave, Android keystores and passkeys — a gateway for passkey-based wallet authentication and mobile-grade cryptographic verification inside smart contracts.

Two absences are as telling as the inclusions. EIP-4844’s successor capacity increases were handled through BPO forks rather than protocol code, as described. And EOF — the EVM Object Format, the long-debated overhaul of contract bytecode structure — was cut from the upgrade after sustained community disagreement about its timing and value. Its fate remains open: the debate moved rather than concluded, and a future fork may pick it up in revised form. Users and developers expecting EOF tooling in Fusaka should plan around its absence.

What the upgrade changes for each audience

The same upgrade reads very differently depending on where a person stands relative to the network, and the practical consequences divide cleanly:

• For regular users. The dominant effect is indirect: cheaper and more reliable L2 fees as blob capacity rises, and slightly smoother mainnet behavior from the gas floor adjustments. Nothing changes about wallets, keys or interaction patterns; the upgrade is infrastructure, and its benefits arrive as quieter fee charts.
• For rollup teams. The most significant planning variable is BPO cadence: capacity will rise in steps through 2026, and rollup economics — data publication strategies, blob batching, fee policies — should be designed against a rising, tunable ceiling rather than a fixed one.
• For node and validator operators. Software updates are mandatory on the usual schedule, with the added operational consideration that bandwidth, disk and memory profiles will evolve as blob capacity grows. Home stakers remain viable by design — that is the entire point of sampling — but operators should expect gradual growth in resource needs and should follow capacity forks rather than treating the network as static between hard forks.
• For developers. The secp256r1 precompile and the clz opcode open new patterns: passkey-native authentication flows and cheaper arithmetic-heavy logic. Neither is urgent for existing contracts, but both belong in the toolkit for anything designed after Fusaka.

For the community as a whole, Fusaka is also a rehearsal for the next phase of the roadmap — the post-Fusaka hard fork already under research under the Glamsterdam codename, which is expected to carry the long-debated block proposer-builder architecture changes and, potentially, the delayed EOF work. The BPO mechanism and the compressed fork cadence introduced around Fusaka are the infrastructure for that future: faster shipping, smaller scopes, and capacity managed as an operational dial rather than a quinquennial decision.

The risks and honest caveats

Scaling the data layer without compromising decentralization is an engineering discipline with real failure modes, and Fusaka’s design choices acknowledge them rather than eliminate them:

1. Sampling assumptions under stress. PeerDAS’s guarantees are statistical; adversarial conditions that fragment the network or concentrate blob traffic can degrade sampling reliability before outright failure. Client teams built mitigations and monitoring into the rollout, but the mechanism’s performance at high capacity is something the network will learn in production, not in testnets.
2. Client diversity pressure. Larger blob payloads and new p2p behavior load all execution and consensus clients, and implementations are not equally mature. The multi-devnet testing process existed precisely to surface these gaps, and history suggests residual issues are found — and fixed — in the first weeks after activation.
3. The fee expectation gap. Capacity increases reduce congestion pressure but do not abolish demand cycles: rollup traffic has historically expanded to fill available space. Fees trend down over time; they do not approach zero, and promotional claims that Fusaka “makes everything free” misread both the mechanism and the market.
4. Governance novelty. The BPO mechanism is new, and its cadence — parameter changes arriving more frequently than hard forks — asks the community to process capacity decisions at a rhythm it has not previously practiced. Early BPO forks are therefore likely to be conservative.

These caveats do not undermine the upgrade; they describe the difference between a capacity increase that is available and one that is proven. Ethereum’s recent history — from the Merge through Pectra — has been a sequence of mechanisms that behaved in production as designed, with rough edges resolved in weeks. The reasonable posture toward Fusaka is the same: measured confidence, and attention to the first BPO forks rather than the activation day itself.

Conclusion

Fusaka is Ethereum’s scaling upgrade, and it delivers on a promise the network made with EIP-4844: that rollups would get the data layer they needed to carry Ethereum’s activity, priced by an honest market rather than throttled by an artificial ceiling. PeerDAS converts distributed verification into headroom, BPO forks convert that headroom into scheduled, reversible capacity growth, and the supporting EIPs — the calldata floor, the transaction gas cap, the passkey precompile, the arithmetic opcode — tighten the economics and enrich the contract layer in ways that will matter for years after activation.

What Fusaka does not do is equally clear. It does not eliminate fees, does not collapse the L1/L2 division, does not include EOF, and does not compress the roadmap’s remaining ambition — the Glamsterdam generation of proposer-builder changes and continued capacity growth — into a single release. Its significance is better understood as architectural: it establishes the operating pattern for how Ethereum scales from here, in measured steps, with capacity as a dial and hard forks reserved for what truly requires them. For users, the change will be noticed as layer 2 fees drifting lower and staying lower; for rollups, as room to grow; for validators, as a network that keeps demanding slightly more from their machines while never demanding what a datacenter would be needed to provide. That balance — capacity rising, decentralization intact — is not a slogan attached to Fusaka but the specific design constraint the upgrade was built to satisfy, and by the time the next upgrade takes the stage, the blob markets, the BPO cadence and the sampling infrastructure beneath them will have quietly become the new normal.