What is Blobspace?

Blobspace is the dedicated data capacity in Ethereum used for storing blobs, a temporary form of data introduced primarily for Layer 2 Rollups. Instead of publishing large amounts of Rollup data as ordinary transaction calldata, Rollups can place that information into blobs, which have their own capacity limits and fee market.

Blobspace was introduced with EIP-4844, also known as proto-danksharding, as part of Ethereum’s Dencun upgrade in March 2024. The main objective was to make data availability cheaper for Rollups. Layer 2 systems execute transactions outside Ethereum mainnet, but they still need to publish enough information for their state to be reconstructed or verified. Before blobs, much of this information was posted as calldata, competing directly with ordinary Ethereum transactions for expensive execution-layer blockspace.

A blob contains 4,096 field elements of 32 bytes each, giving it a raw size of 131,072 bytes, or 128 KiB. Unlike ordinary transaction data, blobs are not intended to remain permanently available through Ethereum nodes. They are retained long enough for Rollup verification and reconstruction needs and then can be pruned. This makes blobspace a specialized data availability resource rather than permanent blockchain storage.

Ethereum has continued to expand blobspace since its introduction. Pectra increased blob capacity in 2025, and Fusaka introduced PeerDAS and Blob Parameter Only upgrades. By 2026, Ethereum targets 14 blobs per block and allows a maximum of 21, substantially increasing the amount of Rollup data that can be made available without proportionally increasing the bandwidth required from every validator.

Why Ethereum Created Separate Blobspace

Ethereum blockspace is expensive because every transaction competes for limited network resources. Execution-layer calldata must be processed as part of ordinary Ethereum transactions and historically remains part of blockchain history. Rollups posting large quantities of compressed transaction data through calldata were therefore competing with swaps, token transfers, smart contract calls, and other Layer 1 activity.

This created a scaling problem. Rollups could execute transactions cheaply outside Ethereum, but publishing their data back to Layer 1 remained a significant component of transaction costs. If Ethereum simply increased normal block sizes dramatically, node bandwidth, storage, and hardware requirements could rise enough to damage decentralization.

Blobspace creates a separate data lane optimized specifically for temporary data availability. A Rollup can attach blobs to a special blob-carrying transaction. The execution layer receives commitments identifying those blobs, while the consensus and data availability mechanisms ensure that the blob contents were available to the network.

The separation also allows Ethereum to scale data availability independently from EVM computation. Increasing blob capacity does not mean that Ethereum is simultaneously allowing the same increase in smart contract execution.

This is important to Ethereum’s Rollup-centric scaling strategy. Rather than trying to execute every user transaction on Layer 1, Ethereum provides settlement and data availability while Rollups handle much of the computation.

How Blobs Use Ethereum Blockspace

A blob-carrying transaction is not simply a normal transaction containing a very large data field. Blobs have a separate protocol treatment.

Each blob contains 4,096 elements, with each field element occupying 32 bytes. This produces a nominal blob size of 128 KiB. The data itself is transmitted alongside Ethereum’s consensus-layer networking rather than being inserted into the EVM’s normal calldata space.

The EVM cannot directly read the full contents of a blob. Instead, a blob transaction includes versioned hashes derived from cryptographic commitments to the blobs. Ethereum uses KZG commitments so that specific claims about blob data can be checked cryptographically without inserting the entire blob into EVM-accessible state.

This creates a clear division between blob data and normal transaction data.

The distinction allows Rollups to publish large amounts of compressed transaction information without paying the same price structure as applications that require actual EVM execution.

Blob Gas and the Blob Fee Market

Blobspace has its own fee mechanism called blob gas. This market operates separately from regular Ethereum gas.

A transaction that uses blobs therefore deals with two types of resources. Ordinary transaction processing still consumes execution gas, while the blob data consumes blob gas. Congestion in one market does not translate directly into identical pricing pressure in the other.

Each blob corresponds to 131,072 units of blob gas. Ethereum tracks blob usage relative to a protocol target. If blocks consistently use more blobspace than the target, the blob base fee rises. If usage remains below the target, the fee falls.

The mechanism resembles EIP-1559 because prices adjust automatically according to demand rather than relying only on users bidding against one another. However, the blob fee market is independent from Ethereum’s ordinary execution gas market.

This separation has an important practical effect. A sudden surge in Layer 1 DeFi activity can increase normal gas fees without necessarily producing the same increase in blob fees. Similarly, heavy Rollup demand can make blobspace more expensive while leaving the execution gas market relatively less affected.

Several factors determine what Rollups actually pay for blobspace:

• current blob demand, the target blob count, the size and number of blobs required by the Rollup, compression efficiency, and how frequently the Rollup publishes batches;
• whether multiple Rollups are competing for capacity at the same time, the current blob base fee, and how efficiently the Rollup fills each available blob.

Because one blob has a fixed capacity, inefficiently using half-filled blobs can increase the effective data cost per Layer 2 transaction. Rollup batching and compression therefore remain important even when blob fees are low.

Blobspace Capacity Has Increased Over Time

Blobspace was intentionally introduced with conservative limits. The goal was to observe how Ethereum’s peer-to-peer network behaved under real blob traffic before increasing throughput.

When Dencun introduced EIP-4844 in March 2024, Ethereum targeted 3 blobs per block and allowed a maximum of 6. With a raw size of 128 KiB each, the maximum represented roughly 0.75 MiB of additional blob data in a block.

Pectra, activated in May 2025, increased the target to 6 blobs and the maximum to 9. This raised available capacity while Ethereum continued preparing for more advanced data availability scaling.

Fusaka activated in December 2025 and introduced PeerDAS, or Peer-to-Peer Data Availability Sampling. Two subsequent Blob Parameter Only adjustments increased the target first to 10 and then to 14 blobs per block, while the maximum rose to 15 and then 21.

The progression can be summarized as follows:

1. Dencun: 3 target blobs and 6 maximum blobs per block.
2. Pectra: 6 target and 9 maximum, followed after Fusaka by BPO1 at 10/15 and BPO2 at 14/21.

The important point is not only that the numbers increased. Ethereum also changed how blob data is distributed and verified, making larger blob counts more sustainable.

PeerDAS and Why Blobspace Can Scale Further

Originally, Ethereum consensus nodes downloaded complete blobs. That approach works when blob counts are relatively small, but continuously increasing the number of blobs would eventually create substantial bandwidth requirements for validators.

PeerDAS changes this model. Instead of requiring every validator to download every blob in full, blob data is erasure-coded and distributed so that nodes can sample portions of the available data. The network can obtain strong confidence that the complete data is available without every participant downloading all of it.

This is fundamental to long-term blobspace scaling. If every node had to receive every additional byte, multiplying blob throughput would multiply bandwidth requirements across the validator network. Data availability sampling allows the system to increase total data capacity while distributing the work more broadly.

Fusaka’s introduction of PeerDAS therefore represents more than a simple blob-count increase. It changes the architecture supporting blob availability.

Blob Parameter Only forks complement this system. Instead of requiring a major named Ethereum upgrade every time blob capacity changes, the network can adjust blob-related parameters separately. This makes it possible to increase data availability incrementally while monitoring node performance, network stability, and actual Rollup demand.

Blobspace Is Temporary, Not Permanent Storage

A common misunderstanding is that blobspace is cheap Ethereum storage. It is not.

Blob data is designed to remain available only for a limited protocol window. Nodes do not need to preserve every historical blob indefinitely. The protocol requires blobs to be available long enough for Rollups and other participants to verify recent data, after which nodes may prune them.

Historically, the EIP-4844 model used a retention window of at least 4,096 epochs, approximately 18 days. The purpose of that window is not archival storage. It provides enough time for Rollup participants to obtain the information needed to reconstruct state, generate proofs, or challenge incorrect claims where applicable.

A Rollup itself is responsible for maintaining whatever longer-term history its users or infrastructure require. Independent archival services can also preserve old blob data, but permanent archival availability is not the consensus requirement that blobspace provides.

This distinction is economically important. Requiring every Ethereum node to keep every Rollup transaction forever would continuously increase disk requirements. Temporary availability allows Ethereum to provide large amounts of data bandwidth without converting the entire volume into permanent consensus storage.

What Blobspace Means for Rollup Economics

For Rollups, blobspace changes the cost structure of using Ethereum. Layer 2 transaction fees generally contain several components, including local execution cost and the cost of publishing information needed for data availability. Before EIP-4844, the Layer 1 data component could represent a large proportion of the total cost.

Blobs created a specialized market in which Rollups could purchase temporary data availability without competing directly for the same resource used by normal EVM execution. This allowed transaction costs on many Rollups to fall substantially after Dencun.

However, blobspace is not unlimited or free. As more Rollups use Ethereum and publish more batches, competition for the blob target increases. The independent blob fee market is designed to respond by raising prices when demand exceeds the desired capacity.

This creates an economic incentive for Rollups to compress transactions more efficiently, fill blobs more completely, adjust posting frequency, or use alternative data availability strategies where appropriate.

Blobspace can therefore be understood as Ethereum’s dedicated bandwidth market for Rollup data. Its capacity can increase as Ethereum’s data availability architecture improves, while its pricing mechanism allocates that capacity when demand becomes high.

The importance of blobspace is not that it executes more Ethereum transactions directly. It allows many more transactions to be executed elsewhere while still publishing the data needed to anchor those systems to Ethereum. As Ethereum’s scaling strategy becomes increasingly Rollup-centered, the amount, cost, and availability of blobspace become central factors in the capacity and economics of the wider Ethereum ecosystem.