FOLLOW THE MECHANISM
- 1Encode
Transaction or state data is prepared with a commitment.
- 2Publish
The network must make the necessary data obtainable.
- 3Check
- 4Reconstruct
Independent participants recover and verify the relevant state.
A conceptual sequence. Real implementations can add steps, intermediaries, and conditions.
A hash is not the underlying history
A block commitment or state root is a compact fingerprint. It can help verify supplied information, but it cannot recreate information that no one provides. Data availability asks whether the data required to verify or reconstruct the accepted state has been made accessible. This differs from trusting a producer who says the data exists. A full node downloading and executing transactions directly faces a different task from a light client that only receives small commitments.
Why rollups need the data
An optimistic rollup’s challengers need transaction data to detect incorrect execution. Users and independent nodes also need enough data to reconstruct state and prepare permitted exits. Validity proofs reduce the work of checking execution but do not eliminate those access needs. A system with externally held data can have different failure modes from one publishing required data to the base chain. A data-availability committee is a specific trust arrangement, not merely another name for onchain publication.
Sampling changes who downloads what
Data-availability sampling uses mathematical encoding and randomly selected pieces to give confidence that the data was published without every participant downloading everything. Erasure coding introduces redundancy so enough pieces can reconstruct the original. The assurance depends on the design, sample distribution and network assumptions. It is probabilistic evidence about availability, not proof that every participant stores all historical data forever. Separating publication assurance from long-term archival storage prevents a common misunderstanding.
Availability is not permanent storage or correctness
Data can be available at acceptance and later require archival providers for convenient retrieval. Available data can also contain invalid transactions, which execution rules must reject. Conversely, a valid-looking commitment can be unusable when needed data is withheld. These are separate dimensions: validity, availability and retention. A complete system description identifies where data is published, who keeps it, how a new node can recover state and what users can do if an operator stops serving it.
MAKE IT CONCRETE
A receipt without the contents
Imagine receiving a book’s cryptographic hash but none of its pages. You can compare a later copy against the hash; you cannot read or reconstruct the book from the hash alone. State commitments have the same basic limitation.
FAILURE PATHS & COMMON MISREADINGS
Where the model can break
- A commitment is not a backup of the data it names.
- Availability at publication does not imply permanent storage by every node.
KEEP EXPLORING