The developers behind Ethereum’s PeerDAS blob scaling breakthrough

Scaling through PeerDAS

Danny Ryan, Dankrad Feist, Francesco D’Amato, Hsiao-Wei Wang, and Alex Stokes designed the PeerDAS protocol. This mechanism uses 1D Reed-Solomon erasure coding to extend blob data. The process splits 128KB blobs into 128 columns, and nodes manage these pieces via a dedicated gossip protocol. Each node manages a subset of these columns based on its unique ID. This scaling method increases throughput from 220 to 3,500 user operations per second. I see this as an eightfold increase in capacity. Every node uses KZG commitments to verify the integrity of the data. The developers, including Tim Beiko, Hudson Jameson, Lane Rettig, and George Hallam, coordinate these changes through weekly meetings. Each cell in a column holds approximately 2KB of data. Because the protocol applies 1D Reed-Solomon erasure coding to extend blob data into 128 columns, a node can reconstruct the original data if it acquires at least 50% of the columns from its peers. Nodes custody blob data for 4,096 epochs, which is about 18 days.

Node requirements and stake

Node requirements change based on the amount of ETH a user stakes. You should check your hardware if you plan to run a validator. Regular validators with one validator handle at least 8 random column subnets, and for every additional 32 ETH staked, these nodes must store an extra data column. This means nodes staking 1,824 ETH handle at least 64 columns, while those with 3,872 ETH or more act as supernodes. Supernodes must subscribe to all 128 subnets and custody all columns to provide the network backbone by continuously healing data gaps. I find the requirement for supernodes to handle all 128 columns creates a heavy burden for those with 4,096 ETH or more. Because nodes only download 1/8th of the total data, bandwidth remains manageable. Full nodes with 0 ETH require about 16GB of space for a 14-blob target, whereas validator nodes with 32 ETH require about 32GB of space. Supernodes require about 500GB of space. Non-validating nodes handle at least 4 data columns and process 1/32nd of the data.

Pectra features and BPO forks

The Pectra upgrade brought several EIPs to the mainnet. EIP-7251 raised the maximum effective balance to 2048 ETH. EIP-7691 increased the target blob count to 6 and the maximum to 9. These updates use Blob-Parameter-Only (BPO) forks to adjust capacity. This mechanism allows the network to scale without waiting for a full hard fork. The first two BPO forks were stress-tested successfully and baked into Fusaka, with the first going live a few days after Fusaka and the second in the beginning of January. These BPO forks increased the target to 14 blobs and the maximum to 21. EIP-7702 enables user addresses to mimic smart contracts during a transaction. EIP-7002 allows validators to trigger exits via the execution layer. EIP-6110 moves validator deposits to the execution layer for simpler onboarding. EIP-7623 increases calldata costs to encourage rollup usage of blobs. EIP-2537 adds new precompiles for BLS12-381 curve operations. EIP-2935 creates a system contract for serving historical block hashes. EIP-7549 moves the committee index outside of the signed attestation. EIP-7840 adds a blob schedule to execution layer config files to manage target and maximum blob counts. This allows clients to avoid the complexity of exchanging this information via the Engine API. Does the reliance on BPO forks create too much complexity for client developers?