Data availability is not a promise to store history forever

A rollup can publish a commitment to data without putting every byte inside an Ethereum execution transaction. It can demonstrate that a state transition is valid without promising that every provider will serve its history forever. Those distinctions matter whenever a network claims that its data is “on Ethereum.”

Three questions deserve separate answers: was the required data made available, was the computation correct, and can someone retrieve the history later? A strong answer to one does not automatically settle the other two.

Availability is about access to the required data

Data availability concerns whether participants can obtain the data needed for the relevant verification or reconstruction task. A short commitment identifies particular data cryptographically, but does not itself supply the underlying bytes.

Ethereum's data-availability documentation explicitly distinguishes availability from later retrievability. Data can have been made available when required without every node remaining responsible for storing and serving it indefinitely.

For a reader assessing a rollup, the word “data” also needs a definition. The system may publish compressed inputs or state-related information according to its design. Do not assume that the posted bytes are a convenient copy of every user-facing transaction receipt, event index and account-history screen.

Blobs and calldata have different jobs

Ethereum's EIP-4844 introduced blob-carrying transactions. The blob contents are distinct from ordinary execution calldata: Ethereum's execution environment can read versioned hashes of blob commitments through BLOBHASH, but cannot simply read the complete blob contents as transaction calldata.

The consensus layer handles blob-data availability. The original design deliberately permits blob data to stop being retained by ordinary nodes after a limited period. Blobs are therefore a temporary availability resource, not a promise of permanent archival storage.

No current universal retention duration is assumed here. EIP-4844's original parameters and later protocol specifications belong to particular versions. The documentation checked on 23 September 2026 supports the durable distinction—limited protocol retention versus long-term archival responsibility—without establishing that every node or provider deletes data at the same instant.

Ethereum's storage-strategies guide describes calldata as bytes carried inside a transaction and recorded in its block. Historical calldata is consequently part of execution history, unlike the separate temporary blob payload. That still does not mean an arbitrary RPC provider must offer unlimited historical queries. An application's service contract and the protocol's data rules are different things.

Availability sampling does not execute the rollup

It is possible to check availability without requiring every participant to download every original byte. EIP-7594's PeerDAS specification describes erasure-coded data, columns and sampling among peers. The redundancy allows reconstruction from sufficient pieces and helps make withholding detectable through sampling.

The purpose of this mechanism is access to data at scale. Authenticating a sampled piece against its commitment does not itself prove that a rollup executed its transactions correctly. Nor does successful sampling create a permanent archive. Those are separate responsibilities.

This is also why a generic explanation should not carry EIP-4844's original “every node downloads every blob” description forward as a timeless requirement. Availability mechanisms can evolve while the distinction between availability, execution and storage remains useful.

A validity proof can coexist with a data problem

Validity proofs establish that a specified computation satisfies its verification rules. They do not automatically reveal all the information a user needs to reconstruct state or exercise an exit path. The earlier guide to validity proofs and privacy explores another limit on what a proof tells its audience.

Validium provides a concrete comparison. Ethereum's validium documentation describes systems that use validity proofs while keeping transaction data off Ethereum. Such designs have additional data-availability assumptions. Withholding data can obstruct users' access to funds even when the proof system prevents invalid state transitions under its stated assumptions.

That comparison is about the availability arrangement, not a claim that every validium or every rollup has the same recovery procedure.

A worksheet for a data-availability claim

Use the worksheet alongside L2 finality and withdrawal analysis. A claim about secure verification becomes more informative when it identifies both the data needed during operation and the parties expected to preserve access afterward.