Managing Ethereum blob scaling via PeerDAS and BPO

PeerDAS and data availability

PeerDAS (EIP-7594) divides extended blob data into 128 columns. This mechanism uses Reed-Solomon erasure coding to expand the data. Because PeerDAS utilizes Reed-Solomon erasure coding to expand data, any 50% of the total columns allows a node to reconstruct the entire original blob, which ensures that data remains available even if some pieces are missing. Each blob is divided into 128 columns of roughly 2KB each, creating a 16MB extended blob. Nodes use unique, randomly generated IDs to pick gossip subnets. Regular validators subscribe to at least 8 random column subnets. This process allows nodes to verify data availability via KZG commitments. This polynomial commitment scheme allows a client to verify a single point on the curve to gain a probabilistic guarantee that the data exists. PeerDAS scales blob throughput by 8x. The implementation of PeerDAS provides a reliable method for scaling data without sacrificing decentralization. Each node maintains a set of diverse and reliable peers to satisfy sampling demands. A validator with a single validator receives 1/16th of all data, but this represents 1/8th of the original data because of the expansion.

Hardware demands for node operators

You must prioritize upload bandwidth over disk space as blob counts rise. PeerDAS shifts the burden from downloading data to serving sampled pieces to peers. This protocol places higher pressure on network connections. For example, devnet testing shows that supernodes experience receive peaks of 400 Mb/s and transmit peaks of 300 Mb/s when the network reaches 14 blobs. This massive spike in bandwidth requirement makes local block building difficult for nodes with modest connections. The EIP-7870 recommendation for home nodes suggests a 4 TB NVMe SSD and 64 GB of RAM. It also suggests a 50 Mbps download and 25 Mbps upload connection. As the blob count increases from the current 6 toward higher targets, the bandwidth required to publish a local block grows. For 10 blobs, validating nodes show peaks of 20 Mb/s transmit, whereas 14 blobs push that to 25 Mb/s.

Validators with 32 ETH subscribe to at least 8 random subnets. Full nodes participate in 4 subnets. Supernodes, which hold 4096 ETH or more, subscribe to all 128 subnets to strengthen system resilience. These supernodes continuously heal data gaps in the network.

Scaling via Blob-Parameter-Only forks

The network increases blob capacity through Blob-Parameter-Only (BPO) forks. These pre-programmed upgrades, defined by EIP-7892, increase the maximum number of blobs without requiring wide ecosystem coordination or manual software updates. The number of blobs begins doubling every few weeks following the activation of a BPO. This stepwise approach avoids overwhelming the p2p network before enabling significantly higher data volumes. The current target of 14 blobs per block can expand toward a theoretical limit of 50 to 80 blobs. BPOs address the needs of Layer 2s which require more data as their networks grow. Unlike regular forks that need broad agreement from all clients, BPOs allow for adjustments to the target and maximum number of blobs. Will the p2p gossip protocol maintain stability as the number of columns per block reaches these higher levels? The deployment of BPO1 and BPO2 allows the network to test these increases in a controlled manner. This protocol manages the transition from the current 6 blobs toward much higher throughput. Developers use devnets to test these parameters before they hit the mainnet. The consensus layer remains stable as PeerDAS handles the data load.