Research · Ethereum
Blobs and data availability
Last reviewed 2026-09-21Source: EIP-4844 and ethereum.org data-availability documentationMechanism descriptions only; no blob price or capacity figures are claimed.
What a blob transaction carries
A blob transaction is a transaction type that carries, in addition to its ordinary fields, a set of blobs and a commitment to each one. The commitment is a cryptographic digest of the blob's contents, and it is what the execution layer stores and what the consensus layer commits to. The blob itself is not part of the execution payload: it is not accessible to the EVM, it cannot be read by a contract, and it does not affect the state root.
The commitment scheme is what makes the arrangement useful. Ethereum uses KZG commitments, which have a property that a simple hash does not: a commitment can be opened at a chosen point, and the opening can be verified against the commitment without the verifier holding the whole blob. That is what allows a node to check that a piece of data belongs to a committed blob without downloading all of it, and it is the foundation of the sampling scheme that lets nodes verify availability without storing everything.
Blobs are also temporary. The protocol retains them for a bounded period and then prunes them, on the reasoning that a rollup needs its data to be available long enough for anyone to reconstruct its state, but not forever. The commitment persists in the chain's history, so the fact that a blob existed and what it committed to remains verifiable; only the data itself is discarded. That is a deliberate trade between the cost of permanent storage and the assurance that the data was available when it mattered.
A separate fee market
| Aspect | Ordinary block space | Blob space |
|---|---|---|
| Priced by | The base fee and priority fee on gas | A separate base fee on blobs, with its own adjustment |
| Executable | Yes; the EVM reads calldata | No; the EVM cannot read blob contents |
| Retention | Permanent, as part of the chain | Bounded; blobs are pruned after a fixed period |
| Primary consumer | Contracts and ordinary transfers | Rollups posting transaction data |
| Commitment | The transaction's own hash | A KZG commitment per blob, verifiable by opening |
Last reviewed 2026-09-21Source: EIP-4844, SpecificationThe blob fee market and retention rules are specified in the EIP.
The separate fee market is the part of the design that changed what a rollup pays. Before blobs, a rollup posted its data as calldata, which meant it competed for the same block space as every ordinary transaction and paid the same gas price. A busy period on the base layer therefore raised a rollup's costs directly, and the rollup's users felt it. With blobs, the data is priced in its own market, and congestion in ordinary block space does not automatically raise the cost of posting a batch.
The separation is not a subsidy. Blob space is still scarce and still priced by demand, and when many rollups want to post at once the blob base fee rises. What the separation buys is that the two demands are priced independently, so a spike in ordinary transaction demand does not consume the capacity a rollup needs, and a spike in rollup demand does not raise the cost of an ordinary transfer. The two markets interact only through the block's overall size limit.
The design also has a limit worth stating. Blob space is bounded per block, and the bound is set by the protocol rather than by demand. When the bound is reached, the blob base fee rises until enough demand is priced out, exactly as the gas base fee does. Blobs therefore make rollup data cheaper than calldata under normal conditions, but they do not make it free, and a world in which every rollup wanted to post at maximum size would still be constrained by the base layer's capacity.
Why availability is a safety property
A rollup's state commitment is only meaningful if the data behind it can be obtained. If a sequencer posts a commitment and withholds the data, no one can recompute the state, no one can produce a fraud proof, and no user can prove what they own in order to exit. The commitment would still be on the base layer, and it would be worthless. This is why data availability is treated as a safety property: without it, the rollup's guarantees collapse to whatever the sequencer chooses to honour.
The sampling scheme is the mechanism that makes availability checkable without requiring every node to store every blob. The blob is encoded with an erasure code that expands it into many pieces, any sufficient subset of which reconstructs the whole. A node downloads a random sample of the pieces and checks each against the commitment. If enough samples verify, the node can be confident that the whole blob is available, because a producer that withheld a large fraction of the pieces would fail the sampling with high probability.
The scheme has an important limitation: it establishes that the data was available at the time it was posted, not that it will remain available. Because blobs are pruned, a rollup that relies on the base layer alone for its data has a window during which its state can be reconstructed and after which it cannot. That is why rollups generally maintain their own archives and why the question of who stores a rollup's history is a live one. The base layer provides the guarantee at posting time; keeping the data afterwards is a separate arrangement.
Sources and references
The blob transaction format, the commitment scheme and the fee market described above are taken from EIP-4844 and Ethereum's developer documentation.
- The blob transaction and its fee market. Ethereum Improvement Proposals, EIP-4844: Shard Blob Transactions: the blob-carrying transaction type, the KZG commitments, and the independent blob fee market.
- Data availability explained. ethereum.org, Data availability: why a rollup's data must be obtainable and how availability is checked.
- The consensus-layer view of blobs. Ethereum Consensus Specs, Deneb — The Beacon Chain: how blobs are committed to and retained by the consensus layer.
- Rollups and the cost of posting data. ethereum.org, Scaling: how rollups use the base layer and what they post to it.
Related reading
- Research HubEvery dataset on the site, with methodology and provenance.
- Altcoin ResearchAltcoins measured against Bitcoin: design intent, consensus, execution, scaling and market structure.
- The ETH-BTC Correlation RecordHow the correlation is measured, how it behaves across windows, and where it breaks down.
- The ETH/BTC RatioWhat the ratio measures, how to read its trend, and why it is not a forecast.
- ETH During Bitcoin Bull PhasesAssociation within a common market factor, and what co-movement cannot establish.
- ETH During Bitcoin Bear PhasesDrawdown depth and duration compared over identical windows, and the limits of the comparison.