Blob Space

What Is Blob Space?

Blob space is the dedicated data storage capacity on Ethereum created by EIP-4844, activated with the Dencun (Cancun-Deneb) upgrade on March 13, 2024. It refers to the portion of each Ethereum block reserved for large binary data objects called "blobs," which exist on the beacon chain (consensus layer) rather than the execution layer.

Before blob space existed, rollups had to post their transaction data as calldata in regular Ethereum transactions. Calldata competes for the same block space as all other transactions and is stored permanently by every node, making it expensive. Blob space solves this by creating a parallel data market specifically designed for rollup data: large, temporary, and cheap.

The concept is analogous to renting short-term storage instead of buying permanent shelf space. Rollups only need their data available long enough for anyone to verify it and challenge fraud. After that window closes, the data can be discarded without affecting Ethereum's security guarantees.

How It Works

Blob space operates through a new transaction type (Type 3, or 0x03) called a blob transaction. These transactions carry one or more blobs alongside regular execution data, but the blob data itself never enters the execution layer or the EVM.

Blob Structure

Each blob consists of 4,096 field elements, each 32 bytes, totaling approximately 128 KB (131,072 bytes). A single blob transaction can carry up to 6 blobs. The EIP-4844 specification originally set the per-block target at 3 blobs and the maximum at 6, though these parameters have since been increased through subsequent upgrades.

Every blob is paired with a KZG (Kate-Zaverucha-Goldberg) polynomial commitment. This cryptographic commitment allows anyone to verify that a specific piece of data was included in a blob without downloading the entire blob. The execution layer only sees a versioned hash of the KZG commitment, not the blob data itself, keeping execution costs low.

The Blob Fee Market

Blob space has its own fee market, separate from Ethereum's regular gas fees. This market follows an EIP-1559-style pricing mechanism with a key difference: instead of targeting a specific gas usage, it targets a specific number of blobs per block.

The pricing works as follows:

• Each blob consumes exactly 131,072 units of blob gas
• If the number of blobs in a block exceeds the target, the blob base fee increases for the next block
• If blobs fall below the target, the blob base fee decreases
• The adjustment rate mirrors EIP-1559, shifting up to approximately 12.5% per block relative to deviation from the target

This dual fee market means that spikes in regular Ethereum transaction demand (NFT mints, DeFi activity) do not directly increase blob costs for rollups, and vice versa.

Data Pruning

Unlike calldata, which is stored permanently on-chain, blob data is temporary. Consensus layer nodes are required to store blobs for approximately 18 days (4,096 epochs). After this retention window, nodes prune the blob data to reclaim storage.

This 18-day window was chosen to provide ample buffer for rollup security. Optimistic rollups typically have a 7-day challenge period for fraud proofs, so 18 days gives more than double the required availability. Even after pruning, the KZG commitments remain on-chain, so the integrity of the original data can still be verified if anyone has retained a copy.

Accessing Blob Data

EIP-4844 introduces the BLOBHASH opcode, which allows smart contracts to access the versioned hashes of blobs attached to the current transaction. The opcode costs 3 gas and takes an index parameter specifying which blob's hash to retrieve:

// Solidity: retrieve versioned hash of blob at index 0
bytes32 blobHash;
assembly {
    blobHash := blobhash(0)
}

Contracts cannot read blob contents directly. They can only access the versioned hashes, which is sufficient for verifying that expected data was posted without requiring the EVM to process large data payloads.

Blob Capacity Over Time

The blob capacity per block has increased significantly since the initial Dencun launch, reflecting Ethereum's progressive approach to scaling data availability:

The Fusaka upgrade also activated PeerDAS (Peer Data Availability Sampling), which allows nodes to verify blob availability without downloading every blob in full. After PeerDAS, Ethereum uses Blob Parameter Only (BPO) forks to incrementally raise blob limits based on observed network performance, with a long-term goal of reaching 128 or more blobs per block under full danksharding.

Use Cases

Rollup Data Posting

The primary use case for blob space is rollup data availability. Both optimistic rollups (like Arbitrum and Optimism) and ZK-rollups (like zkSync and Starknet) use blobs to post compressed transaction data back to Ethereum. This ensures anyone can reconstruct the rollup state and verify correctness while paying a fraction of what calldata would cost.

Data Availability for Validiums

While validiums typically store data off-chain, some hybrid designs use blob space as a middle ground: cheaper than permanent calldata but with stronger availability guarantees than purely off-chain solutions.

Batch Posting for Layer 2 Sequencers

Layer 2 sequencers batch hundreds or thousands of transactions into compressed data and post them as blobs. This batch posting amortizes the cost of a single blob-carrying transaction across all the L2 transactions contained within it.

Why It Matters

Before blob space, rollup operating costs were dominated by Ethereum L1 data posting fees. During periods of high mainnet congestion, L2 fees could spike to several dollars per transaction simply because calldata was expensive. Blob space decoupled rollup economics from execution layer congestion.

The impact was immediate and dramatic. Within days of the Dencun upgrade, major L2 networks reported fee reductions of 10 to 100x. Transactions that previously cost $0.50 or more on rollups dropped to fractions of a cent. This cost reduction expanded the design space for applications that require high transaction throughput at low cost: gaming, micropayments, social protocols, and high-frequency DeFi strategies.

For a detailed analysis of how the blob fee market affects Layer 2 economics, see the EIP-4844 and Blob Fees research article.

The Path to Full Danksharding

Blob space as implemented by EIP-4844 is explicitly designed as a stepping stone toward full danksharding. The current system uses the same transaction format, fee market structure, and KZG commitment scheme that full danksharding will use, but at a smaller scale.

Full danksharding will expand blob capacity to 64 or more blobs per block and introduce full data availability sampling, where nodes can verify data availability by downloading only small random samples of blob data rather than entire blobs. Combined with erasure coding, this allows Ethereum to scale data throughput without proportionally increasing the bandwidth and storage requirements for individual nodes.

Risks and Considerations

Temporary Data Availability

After the 18-day pruning window, blob data is no longer guaranteed to be available from the Ethereum network. Applications or users who need historical blob data must arrange their own archival solutions. If no one retains the data, it is effectively lost, even though the KZG commitment on-chain can prove what was originally posted.

Blob Fee Volatility

While the blob fee market is separate from regular gas, it can still experience its own congestion and fee spikes. When rollup demand for blob space exceeds the target, blob base fees increase exponentially. During periods of intense L2 activity or when multiple rollups compete for limited blob slots, posting costs can rise sharply.

Centralization Pressure on Blob Producers

As blob counts increase, the bandwidth and storage requirements for block builders and validators grow. Nodes must download, validate, and propagate all blobs in a block within the 12-second slot time. This creates pressure toward more powerful infrastructure for block production, though data availability sampling mitigates this for regular validators.

Dependency on KZG Trusted Setup

The KZG commitment scheme used for blobs relies on a trusted setup ceremony. Ethereum conducted a large-scale ceremony with over 140,000 participants to generate the required parameters. The security assumption is that at least one participant was honest and discarded their secret contribution. While this is considered a very strong guarantee given the scale of participation, it remains a cryptographic trust assumption that does not exist in systems using trustless proof schemes.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.