Why Ethereum’s Fusaka upgrade matters after PeerDAS testnet results

Fusaka’s PeerDAS (EIP-7594) changes how Ethereum handles blob data. Before this, every full node downloaded every blob to verify availability. PeerDAS uses Reed-Solomon erasure coding to split each blob into 128 columns. When a block proposer organizes encoded blobs into a 2D matrix, they must divide the data into 128 columns and disseminate those columns across 128 subnets to ensure the network can reconstruct the original data if half the pieces disappear. This approach reduces bandwidth requirements for validators by 8x.

The network uses 128 subnets for PeerDAS. A validator staking 32 ETH participates in 8 subnets. For every additional 32 ETH, the validator gains one more subnet. High-performance nodes that connect to all 128 subnets act as supernodes. Validators with an effective balance of 4,096 ETH or more can opt to run as supernodes, custodying all 128 columns. PeerDAS uses KZG commitments to allow each small sampled piece to be verified against the blob commitment without trusting the peer who served it. These supernodes provide the backbone that guarantees reconstruction remains possible.

The friction in scaling

The Hoodi testnet exposes the friction in the scaling plan. Increasing the number of blobs per block increases latency for validators. In the Hoodi testnet, which used BPO2 with a 14 target and 21 maximum, the p99 failed attestation rate reached 37% for 21 blobs. Most validators experience low latency, but the unluckiest 1% suffer significantly. As blob counts climb, the tail latency increases linearly. I find the connection between higher blob counts and failing attestations hard to ignore.

Proposers face increased workloads. They must compute and upload more data per block. Proposers organize encoded blobs as a 2D matrix and split it into 128 columns. They compute a KZG commitment per column and disseminate each column separately to the 128 sub-networks. This creates pressure on the proposer-builder separation supply chain. Validators must receive blocks and required blob columns within 4 seconds of the slot starting. For 15 blobs, the p99 latency reaches 12.4 seconds. If the number of blobs exceeds 9, some nodes fail to receive the block in time. Will the network reach the 72-blob target without crashing?

L2 economics and data costs

Lower data costs change L2 economics. PeerDAS allows rollups to post more data, which reduces fees. In February 2026, an Arbitrum swap cost a user $0.008. A year earlier, the same swap cost $0.34. You might think scaling requires massive hardware, but PeerDAS changes the math for everyone.

L2 networks like Base and Arbitrum benefit from this capacity. In the 60 days before Pectra, rollups paid a daily average of $16,250 in blob fees. Since Pectra, they pay only $11,015 daily. In early 2026, ENS cancelled its Namechain L2 because the collapse in gas and blob fees removed the cost case for a dedicated chain. Prior to the Dencun upgrade, rollups paid for data by stuffing it into regular transaction calldata, competing for the same gas as everything else on L1. Dencun introduced blobs, which created a separate fee market and a separate data lane. Nodes must hold onto rollup blob data for at least 18 days before pruning. PeerDAS makes it possible to increase blob targets without pricing out home stakers. This maintains the neutrality of the network.