Blob space is Ethereum’s temporary data-availability capacity for rollups. EIP-4844 introduced blob-carrying transactions and a separate fee market so rollups can publish batches of data without putting that payload into permanent EVM-readable transaction data.
What a Blob Is
A blob is a large data object attached to a blob-carrying Ethereum transaction. The transaction records commitments to the blobs, but the EVM cannot read the blob contents directly. Smart contracts can work with the commitment and its versioned hash; rollup nodes and other participants retrieve the actual data from the consensus network while it is available.
This makes blobs different from ordinary calldata. Calldata is part of the execution-layer transaction and remains in Ethereum’s permanent transaction history. Blob contents are retained by the network for a limited period—about 18 days under the current availability window—then nodes may prune them. The commitment remains in the block, but it is not a substitute for keeping the original data. Rollups and archival services therefore need their own data-retention arrangements when they need the payload later.
How Blob Space Is Used
Rollups commonly batch user transactions, execute them on a Layer 2 network, and post data or proofs to Ethereum. Blob data gives those systems a dedicated way to make transaction data available for verification and state reconstruction. The blob contents are not the rollup’s execution environment and do not make its transactions execute inside Ethereum’s EVM.
Blob gas has a fee market separate from ordinary execution gas. Its price responds to blob demand relative to the protocol target. This can lower a rollup’s data-posting cost when capacity is available, but it does not guarantee a particular fee reduction: rollup fees also depend on compression, batching, L2 execution, settlement, and each project’s own fee policy.
Ethereum’s Current Blob Capacity
EIP-4844 launched with a target of three blobs and a maximum of six per block. Later protocol updates increased those limits. As of 25 October 2026, Ethereum mainnet’s BPO2 parameters set a target of 14 blobs and a maximum of 21 per block. The target is the level used by the fee-adjustment mechanism; the maximum is a block limit, not a promise that every block will include that many blobs.
Fusaka also introduced PeerDAS, which lets participating nodes check blob availability by sampling data rather than downloading every blob in full. BPO upgrades and PeerDAS are related parts of Ethereum’s data-availability scaling work, but they do different things: PeerDAS changes how availability can be checked, while a BPO changes blob parameters such as the target and maximum.
Limits and Trade-Offs
Blob data is temporary by design, so it should not be treated as permanent file storage. The on-chain commitment can help verify data that is obtained elsewhere, but it cannot reconstruct data that has disappeared. A rollup’s security and recovery assumptions therefore include who retains its data and how users or independent operators can retrieve it.
Blob capacity is also finite. If demand rises above the target, the separate blob fee can increase even when ordinary execution gas is inexpensive. Additional capacity can reduce pressure, but raising limits must account for network bandwidth, node resources, and reliable data propagation.
Related Terms
See Also
- Are Layer 2 Networks Actually Decentralized? — examines the operators, upgrade controls, and trust assumptions behind Layer 2 systems that rely on Ethereum.
- Does Ethereum TPS Include Layer 2 Transactions? — explains how Layer 2 activity relates to Ethereum’s base-layer transaction statistics.
- Is Ethereum Staking Making the Network More Centralized? — looks at a separate network-level trade-off that helps put Ethereum’s scaling design in context.
Sources
- Ethereum Improvement Proposal 4844 — defines blob-carrying transactions, blob commitments, EVM inaccessibility, the initial limits, and the temporary storage policy.
- Ethereum Improvement Proposal 7691 — documents the later Prague-era increase to a target of six and a maximum of nine blobs per block.
- Ethereum Improvement Proposal 7892 — describes the Blob Parameter Only upgrade mechanism for changing blob targets, maxima, and fee parameters.
- Ethereum Improvement Proposal 8135: BPO2 — gives Ethereum mainnet’s BPO2 activation details and current 14-target, 21-maximum blob parameters.
- Ethereum.org: Blockchain Data Storage Strategies — explains blobs’ rollup use, separate pricing, limited availability window, and why data must be retained elsewhere for longer access.
- Ethereum Foundation: Checkpoint 8 — summarizes Fusaka, PeerDAS, the two BPO increases, and why the third BPO was not then a priority.