Pectra gave wallets a new superpower. Fusaka does the same for data. Here's how PeerDAS, EOF, and the rest of the fork reshape Ethereum's scaling story in late 2026.
Fusaka is the next Ethereum hardfork after Pectra. Its two marquee features are PeerDAS (EIP-7594), which scales blob throughput via data availability sampling, and EOF, which modernizes EVM bytecode. The practical outcome: cheaper L2 fees, healthier rollup economics, and a foundation for full Danksharding.
Ethereum's post-Merge roadmap has settled into a steady rhythm: roughly one execution-plus-consensus hardfork per year. Dencun (2024) gave us blobs. Pectra (2025) gave us smart EOAs via EIP-7702 and raised the validator MaxEB. Fusaka — Fulu on the consensus layer, Osaka on execution — is the 2026 entry, and its center of gravity is data availability.
The reason is simple arithmetic. Blob demand grew faster than blob supply. Throughout 2025, blob base fees repeatedly spiked whenever a meme season or a major L2 bridge event drove simultaneous posting from Base, Arbitrum, Optimism, and Linea. The cap of six blobs per block (target three) became the new rollup bottleneck. Fusaka's job is to break that ceiling without asking home stakers to download more data.
PeerDAS (EIP-7594) is the first production deployment of data availability sampling on Ethereum. The core insight: if a blob is erasure-coded across many columns, a validator can verify that the blob was published by downloading only a small random subset of those columns. As long as enough validators each sample a different subset and can reconstruct the full data if needed, the network is safe even though no single node ever sees the whole thing.
That's a huge deal for Ethereum because it decouples per-node bandwidth from total blob throughput. In Dencun and Pectra, every node had to download every blob, which is why the blob target sits where it does. With PeerDAS, the network can raise the blob target meaningfully — early parameterization proposals target 48 blobs per block with a cap of 72 — while keeping the per-validator download budget essentially flat.
The second headline feature, EOF (EVM Object Format), is unglamorous but long overdue. Today's EVM bytecode has no header, no version, no explicit code vs data separation. JUMPDEST analysis has to run on every contract call. Tooling has to guess which bytes are reachable code and which are inline metadata. EOF fixes all of that.
Under EOF, contracts are deployed with a container format: a magic prefix (0xEF00), a version, and a sequence of labeled sections — code, data, and function types. The validator runs once at deploy time. From then on, the EVM can skip JUMPDEST analysis, use cheaper function calls (CALLF/RETF), and — crucially — evolve safely, because legacy bytecode and EOF bytecode are distinguishable from byte zero.
Solidity and Vyper ship EOF targets out of the box in 2026. Most framework upgrades will be silent. The practical impact for builders: slightly cheaper deployments, cleaner ABI decoding in tools, and a clean slate for future EIPs that would have been too risky on legacy bytecode.
For rollup teams, Fusaka is the most important upgrade since Dencun. Blob posting is the single largest cost line for every major L2. If Fusaka lands on schedule with a 48-blob target, median blob base fees should fall sharply outside peak windows, and the worst peak-fee events should become much rarer. Based rollups and shared sequencing experiments that depend on tight blob inclusion guarantees get a friendlier environment too.
The competitive picture shifts. Alt-DA solutions like Celestia, EigenDA, and Avail have thrived partly because Ethereum blobspace was scarce. PeerDAS narrows that gap. Expect L2s to reassess the Ethereum-DA vs alt-DA trade-off once real Fusaka throughput data is available on mainnet.
JUMPDEST introspection or raw bytecode patching. EOF breaks those assumptions.No upgrade this ambitious ships without tail risk. The three to watch: PeerDAS gossip liveness under adversarial conditions (will the column subnets stay healthy if a large fraction of validators misbehave?), EOF tooling coverage (every debugger, profiler, and fuzzer needs to understand the new container), and the blob fee market dynamics after the target rises — historically, sudden capacity increases have created temporary oversupply before demand catches up, which affects ETH burn and L1 revenue projections.
None of these are showstoppers, but they're why Fusaka is taking longer than a minimal fork would. The client teams have explicitly optioned for more devnet cycles rather than rushing to mainnet.