What Is Data Availability?

In brief

• Data availability (DA) is assurance that data required to verify or reconstruct a state transition was made available to network participants.
• A hash, state root, KZG commitment or validity proof can bind data or prove a computation without publishing the underlying data.
• DA is different from correctness: both the data and the rules for processing it must be valid.
• DA is also different from retrievability or permanent storage: data can be available when consensus checks it and become difficult to fetch years later.
• Ethereum rollups commonly publish compressed data through calldata or blob transactions.
• EIP-4844 introduced blobs with a separate fee market and a limited retention promise.
• EIP-7594 PeerDAS, activated in the Fusaka upgrade in December 2025, lets Ethereum nodes check blob availability by sampling erasure-coded columns.
• Validiums keep state-reconstruction data outside Ethereum and therefore add a committee, validator set or external DA network to the trust model.

The live Layer 2 article explains where DA fits among scaling systems. This article focuses on the information problem itself.

Why a commitment is not enough

Blockchains frequently summarize large data sets with small cryptographic commitments. A state root commits to account state; a transaction root commits to transactions; a blob commitment commits to blob contents. If the underlying data is available, anyone can recompute the commitment and verify that the data matches.

If a producer publishes only the commitment and withholds the data, verifiers face a problem. They may know exactly which data set was promised but cannot:

• execute its transactions;
• calculate the resulting state;
• build a fraud proof for an invalid transition;
• reconstruct a user’s current witness or balance;
• continue producing blocks from that state; or
• serve the missing history to a new participant.

Availability is therefore part of independent verification, not an optional backup feature.

Availability, validity and retrievability

Three properties are often conflated:

Data availability

Was the required data exposed to the network in a way that participants could obtain and verify during the protocol’s relevant window?

Execution validity

Does applying the protocol’s rules to that data produce the claimed result? Full execution, a fault proof or a validity proof can establish this under different designs.

Data retrievability

Can somebody fetch the historical data later—perhaps months or years after consensus no longer needs every node to retain it?

A data set can be available but invalid. It can be validly processed but withheld from users. It can also have been available and accepted at block time but later pruned by ordinary nodes. Archives, indexers and storage networks address long-term retrieval; they are not identical to the consensus-layer DA check.

The distinction now matters for calldata too. Calldata is part of Ethereum’s canonical transaction history and was traditionally described as permanent onchain data, but Ethereum’s history-expiry work means ordinary full nodes need not retain all old execution history forever. “In canonical history” is safer than “every node stores it permanently.”

Why optimistic rollups require DA

An optimistic rollup provisionally accepts claims and gives challengers time to prove a fault. A challenger must know the ordered transactions and relevant prior state to reproduce the disputed computation. If an operator can hide that information while still getting a commitment accepted, an honest watcher cannot build the proof.

Publishing rollup data to Ethereum makes withholding much harder because Ethereum’s validators and nodes enforce the DA rules for the block. The fault-proof system still needs:

• a challenge window no longer than the period in which the required data is guaranteed available;
• working software that reconstructs the rollup state;
• an honest participant monitoring claims; and
• a practical route to submit the challenge before protocol clocks expire.

DA enables a challenge; it does not ensure that someone will make it.

Why validity rollups also need DA

A validity proof can establish that a hidden transition followed a circuit’s rules. That protects state correctness, but users and new operators still need enough information to interpret the resulting state and continue from it.

An operator that withholds state differences may be unable to steal funds through an invalid proof, yet can make balances, witnesses, exits or future transactions unavailable to parties that lack the missing state. The exact impact depends on what users already know and which escape mechanisms the rollup provides, so “no data means nobody can ever exit” is too absolute.

An Ethereum validity rollup publishes sufficient state-reconstruction information to Ethereum. A validium publishes the proof to Ethereum but keeps that information elsewhere. The validity proof remains a correctness guarantee; the external DA provider becomes a liveness and recovery assumption.

Starknet offers a concrete rollup example: its documentation describes publishing compressed state differences to Ethereum so observers can reconstruct state. Other validity rollups may publish transaction data, state differences or another sufficient representation.

How EIP-4844 blobs work

EIP-4844 introduced type-3, or blob-carrying, transactions for rollup data. A blob is a fixed-format collection of field elements propagated beside the beacon block rather than exposed directly to EVM execution.

The transaction contains versioned hashes derived from KZG commitments to its blobs. Contracts can access those hashes and verify claims about evaluations through a precompile, but they cannot read arbitrary blob bytes. Ethereum’s consensus and networking layers handle publication and availability.

Blobs have:

• a fee market separate from normal execution gas;
• commitments that bind the published bytes;
• protocol checks that the referenced data is available; and
• a limited serving/retention window rather than an indefinite storage guarantee.

EIP-4844 specified a minimum request window of 4,096 epochs—about 18 days. After the guaranteed window, rollup operators, archives and other services can retain copies, but Ethereum does not promise that ordinary nodes will continue serving them.

That is enough for protocol use because a rollup consumes the data to advance state while it is available. It is not enough by itself for a permanent public archive.

From full downloads to PeerDAS

At EIP-4844’s launch, nodes checked blob availability by obtaining the blob sidecars associated with a block. Scaling blob capacity by making every node download every blob would eventually raise bandwidth and storage requirements.

Data availability sampling changes the burden. The data is erasure-coded into a larger set of recoverable pieces. Nodes request and verify selected pieces. With enough independent sampling, a producer cannot withhold a significant portion of the data while convincing many honest nodes that all pieces are available, except with a very small probability.

EIP-7594 defines Ethereum’s PeerDAS design:

• blobs are extended with one-dimensional erasure coding;
• the extended data is divided into cells and columns;
• KZG proofs authenticate cells against the blob commitments;
• nodes custody deterministic column subsets and sample columns from peers; and
• obtaining at least half of the columns permits reconstruction of the full data matrix.

PeerDAS activated on Ethereum mainnet with Fusaka on December 3, 2025. This corrects older descriptions that presented Ethereum DAS only as future work. It applies to blob data; it should not be confused with a general claim that light clients independently re-execute all Ethereum transactions.

Data availability committees and external networks

A data availability committee (DAC) consists of identified parties that store data or attest that they can provide it. Some designs require a threshold of committee signatures before accepting a state update. A bonded validator set can add penalties for withholding.

This can be cheaper than publishing all data to Ethereum, but the guarantee depends on committee membership, threshold, incentives and recovery procedures. If enough members collude, disappear or lose their copies, users can lose access even when a validity proof shows that prior execution was correct.

External DA networks use their own consensus and sampling rules. They may provide stronger decentralization than a small DAC, but they still add another protocol whose security and retention assumptions must be evaluated.

DA is not IPFS or permanent storage

IPFS helps identify, route and transfer content-addressed data. Pinning can preserve copies. Those are useful retrieval tools, but an IPFS CID alone does not prove that data was available to Ethereum validators at the moment a rollup state was accepted.

Conversely, an Ethereum blob can satisfy consensus DA even if nobody promises to pin it forever. A rollup can use Ethereum for timely availability and separate archives for long-term retrieval.

The questions are different:

• DA: could verifiers obtain the data when safety depended on it?
• Storage: who keeps paying to retain copies?
• Retrieval: how does a future user locate and download a copy?

Questions users and developers should ask

When a network says it “inherits Ethereum security,” ask:

• What exact data is published to Ethereum?
• Is it calldata, blobs or only a commitment?
• Can independent software reconstruct the current state from that publication?
• What is the protocol retention window?
• Does the dispute period fit inside it?
• If data is external, who attests and what threshold can withhold it?
• Can users force inclusion or exit if the sequencer stops?
• Who operates archival copies after normal pruning?

DA answers whether information was available. It does not replace analysis of sequencers, bridges, proof systems or upgrade keys.