Blobspace: Understanding EIP-4844 and Rollup Data Costs

By DeFi Intel Research · Reviewed 2026-07-02 · 11 min read · intermediate

EIP-4844 blobspace Ethereum, introduced via the Dencun upgrade, fundamentally reshapes how rollups post data to L1. Before blobs, every batch of L2 transactions was stored in Ethereum’s permanent calldata, competing directly with regular smart contract execution for block space. This created a costly bottleneck: L2 users paid high fees because rollups passed on those L1 data costs. Blobspace solves that by creating a separate, ephemeral data layer—blobs—that is cheaper to use and doesn’t crowd out normal transactions.

This guide provides a deep dive into blob gas markets, the trade-offs between blobs and calldata, and the concrete impact on L2 fee structures. Whether you’re a developer optimizing rollup batch submission or a power user curious why Ethereum L2 fees dropped dramatically, you’ll find the mechanics, economics, and practical considerations laid out clearly.

What Is Blobspace and Why Was It Needed?

Blobspace is a temporary data storage area on Ethereum designed exclusively for rollups to post their compressed transaction data. Unlike calldata—which is stored permanently on-chain and indexed by Ethereum clients—blobs are only kept for about 18 days (approximately 4096 epochs). This ephemeral nature is acceptable because rollups themselves already provide long-term data availability (DA) through their own committees or external DA layers; Ethereum only needs to guarantee that the data was available during the period when anyone can dispute a state transition.

Before EIP-4844, every blob of data a rollup submitted was posted as calldata, which incurred high costs because calldata bytes must be accessible forever and occupy permanent state. For example, a typical Optimism batch with 100 KB of calldata could cost over $100 in gas, which then got passed down to end users. Blobspace slashes these costs by roughly 90–99% because blob gas is priced separately and blobs are pruned after the DA window. The need was acute: L2 activity was exploding, and high L1 data costs were the primary barrier to sub-cent transaction fees on rollups.

How EIP-4844 Created Blobspace: Blob Gas vs. Regular Gas

EIP-4844 introduces a new transaction type (0x03) that contains one or more blobs alongside the standard execution payload. Each blob is a fixed size of 128 KB, and a transaction can include up to 6 blobs per block (though the target is 3). The key innovation is a separate fee market for blob “gas.” While regular execution uses the EIP-1559 base fee mechanism for computational gas, blobs have their own base fee that adjusts based on blob supply and demand.

Blob gas is not interchangeable with regular gas. A transaction consumes both execution gas (for verifying the blob commitment and calling the rollup’s inbox contract) and blob gas (for the blob itself). The total fee paid is: execution gas * (base fee + priority fee) + blob gas * blob base fee. The blob base fee starts at 1 wei per unit and can increase or decrease based on how many blobs are included relative to a target of 3 per block. If the network is congested with blobs, the base fee rises; if underutilized, it falls. This creates a dynamic market that keeps blob inclusion economical.

Example: In a block with 4 blobs (above target), the blob base fee might be 50 gwei. In a block with only 1 blob, it could drop to 1 gwei. This adaptive pricing prevents spam while ensuring low costs during normal usage.

The Blob Gas Market: Target, Excess, and Base Fee Mechanics

The blob gas market operates via a mechanism very similar to EIP-1559 but with different parameters:

• Target: 3 blobs per block (or 393,216 blob gas units, since each blob costs 131,072 units).
• Excess: The protocol tracks how many blobs have been included beyond the target over a rolling window. This excess value directly determines the blob base fee:

blob_base_fee = 1 wei * exp(excess_blob_gas / 4000000)

Where excess_blob_gas accumulates the difference between actual blob gas used and the target each block, clamped between 0 and max. This exponential curve ensures that even small sustained excesses can push fees up quickly, discouraging congestion. For instance, if the network consistently sees 5 blobs per block (2 above target), the excess builds, and the base fee grows exponentially until demand subsides.

This design has two critical effects for rollups: (1) during normal periods, blob base fees are extremely low (often single-digit wei), making blob posts nearly free compared to calldata; (2) during data-availability spikes—like a popular NFT mint on a rollup—the base fee can spike, but even at elevated levels, blobs remain cheaper than calldata because calldata competes for the same blockspace as DeFi trades and has a much higher fee floor.

Real-time blob base fee and utilization can be monitored on dashboards like Blobscan or Dune Analytics dashboards by @hildobby, which show spot fees and historical averages.

Trade-offs: Blobs vs. Calldata — A Comparison

The trade-off is clear: blobs sacrifice permanent availability for massive cost savings. Rollups that require long-term L1 data availability must supplement blobs with their own DA solutions (e.g., Celestia) or keep a copy off-chain. But for the vast majority of users, the 18-day window is sufficient—it covers the fraud proof period (optimistic rollups) or allows enough time for zk-rollup provers to fetch the data.

Impact on L2 Fee Structures: Real-World Examples

The introduction of blobspace on March 13, 2024 caused an immediate and dramatic drop in L2 transaction fees. Let’s examine three major rollups:

• Arbitrum: Before Dencun, a simple ETH transfer often cost $0.10–$0.30. Post-4844, typical fees fell to $0.001–$0.005. The reason: Arbitrum posts its batch data as blobs instead of calldata, and the blob base fee has remained near its 1 wei minimum for most blocks.
• Optimism (and Base, its fork): Similarly, Optimism’s average transaction fee dropped from $0.05–$0.20 to under $0.01. Base, which was already cheap, saw fees fall to $0.001 on average.
• zkSync Era: Although zk-rollups have cheaper verification costs, they also benefited. zkSync’s fee reduction was less dramatic (roughly 50-70% cut) because their fixed costs from proof generation were already dominant, but the data component became negligible.

These savings are direct: L2 sequencers post batches roughly every few minutes, and each batch of ~500 transactions might have cost 0.01 ETH in calldata; as a blob, the same batch costs under 0.0001 ETH. The savings are passed on to users through lower L2 fees.

Data from L2BEAT and Dune dashboards confirm that post-4844, the share of rollup costs coming from L1 DA dropped from ~90% to less than 10% for optimistic rollups, making execution cost the new dominant factor.

Data Availability Considerations: Blob Retention and Light Clients

Blobs are only stored by Ethereum full nodes for approximately 18 days (defined as 4096 epochs, or ~18.2 days). After that, they are pruned—meaning the raw blob data is no longer available from Ethereum’s peer-to-peer network. However, the commitment (a KZG polynomial commitment) remains in the beacon state, allowing anyone to verify that a blob existed at a certain block. This design is intentional: Ethereum is not a permanent data warehouse; it only needs to provide data availability during the window when rollups need to detect fraud or generate proofs.

For light clients, blobs are a boon. Before EIP-4844, a light client verifying the state of a rollup would need to download all calldata to ensure the data was available. That’s expensive. With blobs, a light client can download only the blob headers (32-byte commitments) and sync with the beacon committee’s attestations that the blob data was actually published—a much lighter task. This enables trust-minimized light clients for L2 on mobile and browser wallets.

If a rollup needs longer data availability, it can: (1) store blobs permanently using a service like Etherscan’s blob explorer (which archives them), (2) fall back to calldata for critical data, or (3) use a dedicated DA layer like Celestia or EigenDA, which offer cheaper storage with longer retention.

Blob Transaction Types and Sidecars: Technical Underpinnings

EIP-4844 defines a new transaction type with type byte 0x03. The transaction payload includes:

• Blob versioned hashes: A list of hashes (each 32 bytes) that identify each blob. These are computed from the KZG commitment.
• Blob data: The actual opaque blob bytes (up to 6 blobs of 128 KB each). This data is not included in the execution payload; instead, it is transmitted separately via blob sidecars in the gossip network.
• KZG commitments: One per blob, to allow efficient verification.
• Proofs: Also one per blob, used to verify the commitment against the blob.

When a validator proposes a block, they include the blob versioned hashes in the beacon block body, while the full blob data is gossiped alongside as a sidecar. This separation means that execution clients (like Geth) do not need to process or store blob data—they only see the hash commitments. Beacon nodes and validators store the sidecars temporarily to serve blob requests from light clients or rollup nodes.

The verification cost on L1 is constant: regardless of blob size, the EVM only needs to run a single KZG verification pairing check per blob (costing about 50,000 gas). This is vastly more efficient than reading calldata byte-by-byte for verification, which scales linearly.

Tools like Blobscan and Etherscan now provide blob explorers to inspect the raw data, commitments, and blob gas fees paid per block.

Future of Blobspace: From Proto-Danksharding to Full Danksharding

EIP-4844 is deliberately called Proto-Danksharding—a stepping stone toward full danksharding, with PeerDAS (EIP-7594) as the next milestone on that path. Full danksharding will expand the blob capacity from 6 blobs per block to 64 or more, while also adding data availability sampling (DAS). DAS allows light nodes to randomly sample blob data to verify availability without downloading everything, dramatically scaling the system.

Proto-Danksharding skipped DAS to minimize complexity and get the core economic benefits out quickly. The Pectra upgrade (May 2025) already raised the blob target and maximum (to 6 target, 9 max via EIP-7691), and subsequent upgrades are expected to:

• Further increase the target and max number of blobs per block.
• Implement DAS so that validators no longer need to download all blobs but only check random chunks, lowering node hardware requirements.
• Potentially reduce blob pricing further by smoothing the excess mechanism.

For now, blob capacity remains limited, keeping blobs extremely cheap during normal periods, but also creating a ceiling on L2 throughput—if too many L2s try to post data simultaneously, blob base fees could spike. However, even at elevated fees, blobs remain cheaper than calldata for the foreseeable future. Meanwhile, rollups are already exploring “blob compression” techniques to pack more transactions into each blob.

Common Mistakes When Using Blobs in Rollup Design

Developers migrating from calldata to blobs often stumble on these points:

• Assuming blobs are permanent: Blobs are pruned after 18 days. Don’t design a system that relies on L1 for long-term data storage—use your own DA layer or archive the blobs yourself.
• Ignoring blob base fee fluctuations: During high demand, the blob base fee can spike 10x in a few blocks. Always include a fee estimation routine (e.g., using eth_blobBaseFee RPC) and dynamically adjust batch sizes.
• Overstuffing blobs: Each blob is 128KB, but you can’t mix formats. Pack data efficiently to avoid wasted blob space. Some rollups put only a few hundred bytes in a blob, paying the full blob gas cost—inefficient.
• Forgetting blob verification on L1: Even though blobs are cheap, your inbox contract must verify the KZG commitment. This costs ~50k gas per blob—a small but non-zero execution fee that scales with number of blobs.
• Not monitoring blob inclusion: Occasionally, miners or validators may choose not to include blobs if they don’t pay enough priority fee. Ensure your transaction priority fee covers both execution and blob priority.

Key Takeaways

• Blobspace is a separate, temporary data layer that reduces L2 posting costs by 90–99% compared to calldata.
• Blobs have their own gas market with a dynamic base fee that targets 3 blobs per block; fees adjust exponentially to prevent congestion.
• Major rollups (Arbitrum, Optimism, Base, zkSync) have adopted blobs, leading to sub-cent transaction fees for users.
• The 18-day retention window is sufficient for security but requires rollups to archive data themselves if needed.
• Future upgrades (full danksharding) will increase blob count and introduce data availability sampling for further scalability.
• Developers must account for blob base fee dynamics, efficient blob usage, and the 50k gas verification cost per blob.

Common mistakes to avoid

• Assuming blobs are stored permanently on Ethereum; they are pruned after ~18 days.
• Ignoring blob base fee spikes during high demand; failing to estimate fees dynamically.
• Posting tiny amounts of data in a 128KB blob, wasting blob space and overpaying.
• Not including the KZG verification gas cost (~50k gas per blob) in L1 execution budget.
• Forgetting to set an adequate priority fee for blob transactions, risking delayed inclusion.
• Building critical DA infrastructure relying solely on L1 blob availability without a backup plan.

Frequently asked questions

Related reading

• Rollup
• ZK Rollup
• Ethereum Layer 2 Networks
• How To Understand Smart Contract Upgradeability Risks
• Understanding Transaction Fees Crypto
• What Is Ethereum