Ethereum expands blob storage, PeerDAS boosts data availability checks

Ethereum has introduced a specialized system for handling rollup transaction data through blob storage, allowing rollups to publish large volumes of data to the Ethereum network without including that data in standard smart contract execution. This approach offers a temporary solution for making such data available, as blob contents are pruned from the network after a specific period.

How Ethereum blobs work

The March 2024 adoption of EIP-4844 brought type-3 transactions to Ethereum, enabling the inclusion of blobs—data packets each holding 128 KiB. While these blobs themselves cannot be read directly by the Ethereum Virtual Machine (EVM), each is paired with a cryptographic commitment. This mechanism allows nodes to verify data integrity without directly seeing the complete content.

Rollups, which process transactions on separate layers before submitting summaries and related data back to Ethereum, batch their transactions and post the necessary verification data in blobs. The network then uses the accompanying KZG commitment to validate that the data available matches what is required for rollup verification.

Rollup data published through blobs is not added to the execution layer, but instead is posted to offer data availability for a set period, allowing nodes and verifiers to check its integrity using the cryptographic commitment attached.

Ethereum’s approach to blob data emphasizes data availability rather than permanent storage. Blob contents are pruned after 4,096 epochs—equivalent to roughly 18 days—meaning these blobs serve rollups and verifiers’ immediate needs but are unsuitable as an enduring archive.

As a result, long-term storage or archival needs cannot rely on Ethereum blob storage. Developers and users seeking permanent records must look to alternatives outside the blob system.

Blob fees and network capacity

The blob storage system operates on a separate fee market from standard Ethereum transactions. EIP-4844 initially set the benchmark for three blobs per block, with a maximum of six, but subsequent protocol updates adjusted these numbers. The January 2026 BPO2 protocol update increased the target to 14 blobs per block and set the cap at 21, effectively scaling up the available space for Layer 2 rollup data.

Recent network metrics reflected this increased capacity. As of November 7, 2026, Ethereum had seen 24.9 million total blobs, with an average fee of $0.42 per blob, according to the Ethereum.org resources dashboard. These fee levels remain subject to fluctuations in network demand and technical parameters.

PeerDAS and improvements in data sampling

PeerDAS, a protocol enhancement activated by the December 2025 Fusaka upgrade, allows Ethereum nodes to verify blob data availability more efficiently. Rather than requiring every node to download entire blobs, PeerDAS uses erasure coding and sampling for availability checks.

EIP-7594 outlines that nodes can reconstruct the full data set once they obtain half of its components, so each node only needs to download about one-eighth of total blob data. This substantially reduces the bandwidth and storage overhead for each participant, enabling a more decentralized and resilient data availability check for rollups.

PeerDAS does not alter the temporary nature of blob storage; files are still pruned after the same period.

Mini dictionary: PeerDAS is a data availability sampling system for Ethereum that lets nodes check if rollup data is accessible without retrieving every blob in full. Instead, nodes download and verify a subset of data, leveraging erasure coding to confirm overall availability.

Benefits and limitations

Blobs provide rollups with a dedicated, affordable way to publish transaction data on Ethereum, separating their availability strategy from standard contract execution. However, the trade-off is impermanence: once the pruning window ends, blob data becomes inaccessible through Ethereum’s network.

The system allows for scalable Layer 2 activity and improved transparency, but fees and capacity are still influenced by evolving network conditions. In addition, users should recognize that while blobs improve data handling, they do not address risks associated with smart contracts, bridges, or rollup-specific vulnerabilities.

Blobs help rollups scale efficiently, but their contents are pruned after about 18 days, requiring alternative arrangements for any long-term archival needs.

Blob data primarily serves rollup operators and validators, enabling them to guarantee the published data’s short-term accessibility and fostering greater efficiency for Layer 2 solutions.

For end-users, understanding blobs clarifies why some Layer 2 solutions carry different transaction fees and data guarantees versus mainnet transactions. However, accessing blob data directly through ordinary contracts or as a permanent archive is not possible.