data availability

Data availability is the guarantee that the data behind a block or rollup batch has actually been published, so that anyone who wants to can download it and check the chain for themselves. It answers a deceptively simple question: 'Was the data really made available to everyone, or is the producer only claiming it was?' It is one of the most subtle and important problems in scaling, because you cannot verify, challenge, or reconstruct what you cannot see — and crucially, you cannot prove the absence of data after the fact.

Why it is the linchpin of rollups: both kinds need the data, but for different reasons. An optimistic rollup needs published transaction data so an honest verifier can re-execute the batch and build a fraud proof; if a sequencer hides the data, no one can prove it cheated, and the optimistic security model collapses. A ZK rollup proves execution is correct with a validity proof, but users still need the data to know their own balances and to be able to exit if the operator vanishes. In both cases, withholding data is an attack even when the state transition itself is valid.

There is an important distinction between availability and storage. Data availability is about whether the data was broadcast and downloadable at the moment it mattered — a fleeting, network-wide property — not whether it is archived forever. This is what makes EIP-4844 blobs sensible: they guarantee availability for about 18 days (long enough for anyone to download and for disputes to resolve) and are then pruned, because permanent storage is a separate concern that anyone who cares can handle off-chain. Dedicated data-availability layers like Celestia, and sampling techniques, exist precisely to provide this guarantee cheaply and at scale.