What Is a Blob Transaction? Ethereum's Data Availability Layer

A blob transaction is a special Ethereum transaction type, introduced by EIP-4844 in the Dencun upgrade, that carries a large chunk of data — called a "blob" — attached to it, without that data being processed by Ethereum's smart contract execution environment. Blobs exist purely so that anyone can verify data was made available at a specific point in time; they are stored temporarily, not permanently, and priced through their own fee market separate from regular transaction gas.

Why blobs were needed

Rollups, the layer 2 networks described in /blog/layer2-guide, need to publish the transaction data behind their activity back to Ethereum so that anyone — not just the rollup operator — can independently reconstruct and verify the rollup's state. This requirement is central to Ethereum's /blog/rollup-centric-roadmap-explained: rollups inherit Ethereum's security specifically because their data is anchored on layer 1.

Before blobs existed, rollups used ordinary "calldata" to publish this data, which meant it was processed like any other transaction input and stored permanently by every node forever. That permanence was overkill for data whose only real job is to be available long enough for verification — hence the case, explained further in /blog/dencun-upgrade-explained, for a purpose-built alternative.

How blobs differ from calldata

Property	Calldata	Blob data
Processed by EVM	Yes	No
Storage duration	Permanent	Roughly 18 days
Fee market	Shared with general /glossary/gas	Separate blob-specific market
Typical use	General transaction inputs, contract calls	Rollup batch data
Cost to publish	Higher, tied to L1 congestion	Lower, tied to blob-space demand

Because blobs aren't run through contract logic, nodes only need to briefly hold onto the raw data long enough for the network to reach consensus that it was genuinely published and available — after that window, it can be safely discarded since anyone who needed a permanent copy (such as a rollup's own infrastructure) has had time to download and store it independently.

The temporary storage window

Blobs are pruned from most nodes after a set period, generally cited as around 18 days. This design assumes that anyone who cares about the data long-term — rollup operators, indexers, block explorers — retrieves and archives it during that window rather than relying on Ethereum's base layer to store it forever. Ethereum's job is to guarantee the data was available and unaltered at the time of publication, not to serve as permanent cold storage for it.

A separate fee market

Blob transactions have their own base fee, adjusting up or down based on how many blobs recent blocks have included relative to a target, independent of the regular gas base fee described in /blog/what-is-eip-1559-base-fee-burn. This separation is deliberate: it prevents a surge in ordinary transaction activity from spiking rollup costs, and vice versa, since the two are now competing for different, dedicated block space rather than the same shared pool.

What this means for everyday users

Most people never construct a blob transaction directly — this is largely infrastructure used by rollup operators posting batches of transactions on behalf of their users. The visible effect for an ordinary user is indirect: transacting on a rollup that adopted blob transactions tends to be noticeably cheaper than it was previously, because the rollup's cost of publishing data to Ethereum dropped. Users who transact directly on Ethereum mainnet through a /wallet still pay ordinary gas as covered in /blog/what-is-gas-limit-vs-gas-price, since that fee market is unaffected by blobs.

How blob capacity is expected to grow over time

Dencun launched with a deliberately conservative target for how many blobs each block could carry, prioritizing network stability during the initial rollout over maximizing capacity immediately. Subsequent upgrades are expected to gradually raise this target as the network demonstrates it can handle the additional data load safely, part of a longer-term vision sometimes called "danksharding" that aims to scale blob capacity substantially further, described in more detail in /blog/what-is-sharding-ethereum. This incremental approach reflects a broader pattern in Ethereum's development: shipping a working, conservative version of a new capability first, then scaling it up gradually as real-world usage validates the design.

Data availability sampling and the longer-term vision

Part of the reason blob capacity can't simply be raised arbitrarily overnight is that every node currently downloads the full blob data for every block to verify it was made available. Ethereum's longer-term research agenda includes a technique called data availability sampling, which would let individual nodes verify that data was published by checking only small random samples of it, rather than downloading everything — a change that could allow blob capacity to increase substantially without proportionally increasing what any single node must handle. This is still an area of active research and development rather than something already live on mainnet.

Limitations and what blobs don't do

Blob transactions don't make Ethereum store rollup data forever, and they don't process the underlying transactions themselves — the rollup's own infrastructure and fraud-proof or validity-proof systems handle that. Blobs solely solve the data availability problem: guaranteeing the underlying batch data was genuinely published so it can be checked or challenged during the temporary retention window.

Bottom line

Blob transactions give rollups a purpose-built way to publish data to Ethereum that's cheaper than ordinary calldata, temporary rather than permanent, and priced in its own separate market. They were the central innovation of the Dencun upgrade and are a key mechanism behind lower fees on major layer 2 networks.