Data Availability, Explained Without the Hype

Data availability is the concept most often skipped in explanations of modular blockchains, partly because the name is misleading. It is not about storage, archives or uptime. It is about a narrow adversarial question: if someone publishes a commitment to some data, can everyone else actually obtain that data?

Why it matters at all

Consider a rollup that publishes a state root — a commitment saying “after these transactions, the state is X” — accompanied by a validity proof. The proof is sound. The maths checks out.

Now suppose the operator does not publish the underlying transaction data.

The state is provably correct and simultaneously useless. Nobody can reconstruct the balances. Nobody can build the Merkle proof needed to withdraw. Users cannot exit, because exiting requires demonstrating what you own, and demonstrating what you own requires the data.

This is the data withholding attack, and its significance is that correctness is not sufficient. A system can be cryptographically perfect and functionally dead. That is why data availability is a separate property with its own guarantees rather than an implementation detail.

Publishing to the base layer

The simplest guarantee: post the data to a chain where every full node already downloads and stores everything. If the data is in a block that thousands of nodes accepted, it is available by construction — any of them can serve it.

This is expensive, which is the entire reason alternatives exist. Blob-style transaction types improve the economics substantially by providing a separate, cheaper space for data that consensus does not need permanently, typically pruned after a few weeks — long enough for anyone who cares to have retrieved it.

Data availability sampling

The scaling idea underneath most modular designs. A light client that cannot download a whole block instead requests a number of small random pieces. If the data has been erasure-coded, reconstructing the whole requires only some fraction of the pieces — so withholding enough to make reconstruction impossible means withholding a large proportion, which random sampling detects with high probability after a handful of requests.

The result is that a client doing very little work gets a strong probabilistic guarantee that the data exists somewhere. That is genuinely elegant, and it is the technical basis for treating data availability as a separable layer.

The caveats are worth stating: it needs enough independent samplers to be meaningful, it depends on erasure coding being done correctly, and it usually requires a way to prove that the coding itself was not malformed.

Committees and the trade-off

A common intermediate design is a committee that attests the data was made available, with the rollup accepting a state root only if enough committee members sign. This is dramatically cheaper than posting everything on chain.

It is also a different security model, and it should be described as one. The guarantee is no longer “anyone can reconstruct this from a chain they already trust” but “a threshold of these named parties says the data exists”. If that threshold colludes or simply fails, users may be unable to exit — the withholding scenario above, reached by a different route.

That can be an entirely reasonable engineering choice. What is not reasonable is describing it with the same language as base-layer publication.

The questions to ask

Where does the data go — a base layer, a dedicated DA chain, or a committee? If a committee, who is on it, what is the threshold, and what happens if it fails? Can a user exit using only data they can obtain independently? And is there a fallback if the primary DA path becomes unavailable?

The last one is the most revealing, because many designs do not have an answer.