MASTR · CRYPTO & WEB3
Data availability, historical storage and the limits of a hash
A commitment can authenticate data without supplying it. Publishing data now and preserving it for years are related but different jobs.
I capitoli e i grafici tecnici sono in inglese. La navigazione è disponibile in sette lingue.
Can another participant reconstruct and check the state?
A fingerprint is not the document
A cryptographic commitment can let someone check whether supplied data matches an expected value. It cannot reconstruct arbitrary missing data from the commitment alone. This distinction is essential to blockchains that outsource execution or distribute large amounts of transaction information. A perfectly valid-looking root hash is not enough if the data needed to check the state transition is withheld.
Availability supports independent checking
Participants need access to the information required by the protocol’s verification process. A full node may download and execute relevant data. Other designs use techniques such as erasure coding and sampling to increase confidence that encoded data was made available under stated assumptions. A sample is not a magical recovery of the entire history; its security depends on how data is encoded, distributed and checked.
Validity asks a different question
A validity proof can show that a computation followed defined rules. Availability asks whether required data can be obtained. Confidentiality asks who can read it. These properties may interact, but none is a synonym for the others. An encrypted object can be available but unreadable to a party without the key. A valid computation can still leave users needing additional data to recover their individual state.
History needs a preservation plan
A network can make data available during the period required for verification without promising indefinite storage by every node. Ethereum’s blob transactions illustrate the distinction between a data-publication mechanism and permanent application storage. Applications and researchers with longer retention needs require archives or other preservation arrangements. Do not tell an NFT buyer that an unrelated consensus feature guarantees their image will remain downloadable forever.
Ask operational questions
Who stores the data, for how long, and how can a new participant retrieve it? What happens after an operator shuts down? Which part is reproducible from the remaining records? Where does a client get a trusted checkpoint, if it needs one? These questions make modular designs understandable without reducing them to slogans about cheap storage or limitless scale.
Esempio spiegato
A researcher records a transaction’s hash and later loses the transaction data and execution context. The hash can authenticate a recovered copy, but cannot by itself recreate the evidence. Preservation requires the bytes and enough metadata to interpret them.
Domande da ricordare
- Separate commitment from the committed data.
- Specify the retention period.
- Identify the reconstruction path.