PeerDAS in Fusaka: what actually changes, what could break

PeerDAS (EIP-7594) is the main feature of Ethereum’s Fusaka upgrade. The Ethereum Foundation announced testnets on Sept 26, 2025 (Holesky Oct 1; Sepolia Oct 14; Hoodi Oct 28) and outlined a plan to raise blob capacity with "Blob-Parameter-Only" (BPO) forks after PeerDAS is live. These forks move the per-block blob target/max from today’s 6/9 to 10/15, then 14/21, with mainnet timing depending on testnet results.

Pectra went live on May 7, 2025 (epoch 364032). Since then Ethereum has run at ~6/9 blobs per block, up from Dencun’s 3/6. The EF notes mainnet often already hits the 9-blob ceiling, which is why controlled increases are needed.

PeerDAS changes how the network checks blob data availability. Instead of every node downloading full blobs, each grabs small slices of an erasure-coded dataset and checks them against KZG commitments. With current parameters, a node only needs about 1/8 of the data for a local availability check, and in theory that fraction could fall further (1/16, 1/32) as parameters evolve. Once enough slices are present, reconstruction is possible. The EIP specifies custody groups, subnet selection, and proof handling in the gossip layer to make this work.

If PeerDAS works as designed, the immediate benefit is more room for Ethereum front-ends (layer 2s). Dencun (EIP-4844) already moved rollup data to blobs and cut costs; fees dropped to cents or less and have mostly stayed there. But that also pushed blob-fee revenue for L1 to cycle lows in 2025. Raising throughput beyond the 9-blob ceiling is the next step if we want front-end throughput to keep growing without spikes.

At this phase — post conceptual validation — the risks aren’t in the math but in the real network. Data-withholding attacks remain the classic threat in any DAS scheme. The EIP’s analysis shows why randomized sampling makes successful withholding unlikely at scale, but results still depend on peer-to-peer behavior under stress. The EF’s gradual BPO plan reflects this caution: start slow, monitor subnet responsiveness and data recovery, then expand. Developers will watch whether testnets reveal latency differences across custody subnets, how fast nodes replace missing data during partitions, and whether higher blob limits increase centralization by favoring well-connected validators.

If the EF can deliver PeerDAS with this cadence and keep the network stable as limits rise from 9 to 15 and 21, front-end chains like Base and Arbitrum gain space to grow and fees should trend lower with fewer spikes. If peer-to-peer glitches like slow sampling, subnet stalls, or coordinated withholding appear under load, the ramp pauses until tuning fixes them. The next proof point will come from Fusaka testnets and their BPOs.

Source: EF Fusaka testnet announcement: https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement