A blockchain can publish a commitment to data without every observer already possessing the underlying bytes. Rollups and other users need those bytes to reconstruct or verify state. Data availability sampling reduces an individual node's download burden by requesting selected pieces from an encoded dataset. With an appropriate coding scheme and sampling assumptions, repeated successful samples provide evidence against substantial withholding. This is a probabilistic availability check, not execution of all the transactions.

An illustrative design expands data into redundant pieces so that a sufficient subset can reconstruct the original. A verifier requests some unpredictable pieces rather than the entire block. An adversary withholding enough pieces to prevent reconstruction risks being detected by these requests. Ethereum's PeerDAS specification describes a particular networking and column-based design; its exact parameters and obligations should be taken from the relevant specification version rather than generalized from another chain's implementation.

Available transaction data can still describe an invalid state transition, and data that is available now may not remain archived forever. Execution validity, consensus finality, and long-term storage are separate questions. Sampling security also depends on peer connectivity, honest data distribution, and the assumptions behind the coding and retrieval scheme. When comparing networks, ask who samples, who reconstructs, how failures are handled, and how users obtain historical data after the protocol's required retention period ends.