Al-Bassam, Sonnino and Buterin investigate how light clients can gain stronger assurance without downloading and executing every block. Their paper combines fraud proofs from validating nodes with probabilistic checks that block data can be obtained. The construction uses erasure coding and sampling so an attacker cannot make a block unreconstructable merely by hiding an arbitrarily tiny, undetectable fragment.

The paper presents a protocol, implementation and evaluation under explicit network and honest-node assumptions. Read those assumptions before interpreting its discussion of dishonest majorities. Sampling does not make communication unnecessary, and fraud proofs need someone able to inspect the relevant data. The result concerns a defined threat model, not a guarantee that a client surrounded entirely by malicious peers will always learn the truth.

Consider a simplified teaching model in which half of an encoded block's shares are unavailable. If each query independently samples a uniformly random share, the probability of ten queries all landing on available shares is one divided by 1,024. That calculation explains why repeated sampling can build confidence. It is not a measurement of any deployed protocol, because real systems must justify independence, peer connectivity and the fraction that must be withheld to prevent reconstruction.

Change the example so an attacker answers a targeted client selectively while hiding data from everyone else. The question now involves publication and network behavior, not only a probability formula. A rigorous reading asks who gathers samples, whether they are shared, how coding correctness is established and when the decision is made. Never transplant a toy sampling probability into a product's security claim without those details.

EIP-7594 describes PeerDAS, an Ethereum data-availability sampling design. It distributes responsibility for data columns across peers, with custody and sampling duties rather than requiring every node to download all blob data. The specification explains why validators have additional custody requirements and how participants can voluntarily store more data. This is a concrete networking design around availability, not just a commitment format.

For a reading exercise, follow a column from publication through peer custody to a sampling request. Identify what verifies the returned data and what happens when a request fails. The specification's parameters and fork context matter; an explainer should not turn an implementation parameter into a timeless constant. Likewise, support in a specification and successful operation by a particular node are distinct pieces of evidence.

Ethereum's developer documentation distinguishes the need to access data from the separate task of checking that execution is valid. A validity proof can confirm that a state transition follows rules while the data required for another participant to reconstruct that state remains unavailable. Rollups depend on publishing appropriate data to their availability layer; systems with different publication arrangements make different trust tradeoffs.

Availability also has a time dimension. Evidence that data was distributed during a protocol's required window is not a promise of indefinite archival retrieval. A wallet restoration tool or historical explorer may need additional storage services. When evaluating an application, write down the data needed, who publishes it, how long it remains retrievable and what a user can do if the operator disappears. This turns an abstract label into an operational question.