Ethereum PeerDAS and BPO Forks: How Blob Capacity Scales

Ethereum scales data availability for rollups through blobs, and two mechanisms set how that capacity grows. PeerDAS, live since the Fusaka upgrade on December 3, 2025, lets nodes check blob data by sampling only part of it. Blob-Parameter-Only (BPO) forks, specified in EIP-7892, change the blob target and maximum through narrow scheduled updates instead of full network upgrades. Together they let capacity rise in steps while the network's behaviour is observed.

What Fusaka Changed for Blob Data

Fusaka went live on December 3, 2025, and ethereum.org's Fusaka page lists PeerDAS as its scaling feature for blobs, which make layer 2 transactions cheaper. Blobs are the data containers rollups post to Ethereum. Their capacity is set by protocol parameters, so raising it is a protocol decision with real network effects.

How PeerDAS Sampling Works

EIP-7594, now Final, defines PeerDAS as a networking protocol. Blob data is arranged into cells grouped in columns, and each column is tied to a gossip subnet. Each node keeps a deterministic set of columns based on its node ID and samples columns from its peers in every slot.

Three details matter for builders:

Reconstruction threshold: a node that obtains at least 50% of the columns can rebuild the full data matrix. Below that, it requests missing columns from peers.
Sampling cost: with the current parameters, the local availability check requires about 1/8 of the blob data. The EIP notes that smaller samples could lower this to 1/16 or 1/32.
Transaction limit: the EIP introduces a limit of 6 blobs per transaction, which clients must enforce during submission, propagation and block processing.

Why BPO Forks Exist

The problem BPO forks address is pace. EIP-7892, now Final as an Informational EIP, argues that large and infrequent blob-parameter changes are costly, and that layer 2 demand for data availability keeps growing. A BPO fork changes only three parameters: target, max and baseFeeUpdateFraction. Those values are managed through a blob schedule configuration, and the new values take effect at a specified activation time.

The EIP's example schedules are marked as illustrative. For the second BPO fork, EIP-8135 lists a blob target of 14, a maximum of 21 and a baseFeeUpdateFraction of 11684671.

Ethereum.org describes the intended path: blob counts stay unchanged right after Fusaka activates, then rise in steps toward a maximum of 48 blobs per block, with developers monitoring node stability at each step (ethereum.org PeerDAS page).

Fact, Analysis and Uncertainty

Verified from primary sources: Fusaka's activation date, PeerDAS sampling and reconstruction rules, the 6-blob transaction limit, the BPO parameters and the BPO2 values in EIP-8135.

SignorCrypto analysis: a higher blob ceiling does not guarantee cheaper rollup costs. The fee mechanism reacts to usage, so a rollup cost model should read the active blob schedule and the observed blob fee market, not a fixed number from an article.

Uncertainty: this article does not verify current blob utilization or the activation time of every BPO step after BPO2. Third-party reports exist on those points, but they were not used as evidence here.

FAQ

No. PeerDAS lets nodes check availability by sampling columns, and each node custodies only a deterministic subset of data.

Does a BPO fork require a full Ethereum hard fork? No. According to EIP-7892, a BPO fork modifies only blob-related parameters through configuration, without client code changes.

Does a higher blob maximum lower rollup fees? Not automatically. Capacity is one input. Fees depend on how much blob space is used and on the blob base fee mechanism.

Sources

Next Step for Protocol Builders

If your team is designing a rollup, data-availability layer or blob-cost model and needs help turning these parameters into a tested architecture, talk to the SignorCrypto team about the integration and delivery scope.