# Data Availability The question this note answers: was the data actually published, so that anyone can verify the state? Careful with the name — it's not about storing data forever. Availability is about the moment of publication: could every interested party have obtained the data needed to check the claimed state? The distinction sounds pedantic until you see the attack it guards against. ## The attack that defines the problem Suppose a rollup posts a new state root to L1: ```text new_state_root = X ``` but withholds the transactions behind it. The root is on-chain, looking official. But nobody can verify whether `X` is honest — and, worse, nobody can construct the proofs they'd need to exit their own funds. The state is committed; the evidence is missing. Users are stuck trusting the one party that has the data, which was exactly what the whole design was trying to avoid. That's why availability gets treated as its own layer, separate from execution and settlement. A commitment without published data is a claim you can't audit. ## How chains answer it - **Post everything on L1.** Rollups originally published transaction data as calldata. Secure, but expensive — you're buying permanent storage when you only needed publication. - **Blobs (EIP-4844).** Ethereum added blob-carrying transactions: large data chunks whose commitments are visible to the EVM but whose contents live outside execution, priced separately and pruned after a few weeks. Cheaper publication, same availability guarantee at the moment it matters. - **DA sampling.** Light nodes fetch random chunks of a block. If enough random samples succeed, the whole block is almost certainly available — availability verified without downloading everything. This is the core trick behind dedicated DA layers like Celestia. - **Committees / validiums.** Trust a named set of parties to keep data available. Cheaper still, and a genuine trust assumption — see [[Trust Assumptions]]. The takeaway worth keeping: rollups need cheap data *publication* more than they need L1 execution. Once you see that, the whole blob roadmap makes sense. ## Where this matters - [[09 Scaling - Rollups and Data Availability]] — the full treatment - [[10 Bridges and Interoperability]] — a bridge is only as sound as the data behind the state it believes - [[Finality]] — a "final" state you cannot reconstruct is a weaker promise than it sounds