Review record

  **Content-addressed storage (CAS)** identifies stored objects using a digest derived from their representation. A request names the content expected, while a storage service or retrieval protocol locates a copy. This separates an object's identity from a particular server or pathname. RFC 6920 standardizes one way to name information with hashes; individual storage systems use their own object formats and identifier schemes. [RFC 6920](https://www.rfc-editor.org/rfc/rfc6920.html)    CAS is useful for archives, version control, and shared build artifacts. Its central promise is precise identity and verification under the chosen hash scheme. Persistence, trustworthy authorship, and successful reconstruction require additional mechanisms. This article covers the software storage pattern, representative implementations, and its limits for [digital preservation](/wiki/digital-preservation); it is not a survey of associative-memory hardware or a commercial product catalogue.    ## Addressing content  

− A simplified store accepts bytes, computes a digest, and records a mapping from that digest to the bytes. Repeating a write with identical input can reuse the existing object. Reading by digest allows the recipient to hash the retrieved representation and check it against the requested value. The Venti archival server is a concrete implementation of this block-level design: it uses a hash of a block's contents as the identifier for read and write operations, applies a write-once policy, and coalesces duplicate blocks. These are properties of Venti's design, not guarantees supplied by every content-addressed store. [Quinlan and Dorward, Venti](https://www.usenix.org/legacy/publications/library/proceedings/fast02/quinlan/quinlan_html/index.html)

+ A simplified store accepts bytes, computes a digest, and records a mapping from that digest to the bytes. Repeating a write with identical input can reuse the existing object. Reading by digest allows the recipient to hash the retrieved representation and check it against the requested value. The Venti archival server is a concrete implementation of this block-level design: it uses a hash of a block's contents as the identifier for read and write operations, applies a write-once policy, and coalesces duplicate blocks. The paper further describes these writes as idempotent because repeated writes of the same data need no additional storage. This is payload-based idempotence, distinct from the caller-intent and retry semantics discussed in [idempotency keys](/wiki/idempotency-keys). These are properties of Venti's design, not guarantees supplied by every content-addressed store. [Quinlan and Dorward, Venti](https://www.usenix.org/legacy/publications/library/proceedings/fast02/quinlan/quinlan_html/index.html)

    The digest is not a compressed copy from which an arbitrary object can be recovered. A separate copy must exist. Nor is a content name necessarily a network address: a client may resolve it through a local index, an archive resolver, or a network lookup. RFC 6920 distinguishes identifying information from locating and transporting it. [RFC 6920](https://www.rfc-editor.org/rfc/rfc6920.html)    An illustrative workflow is:    ```text  … 89 unchanged lines …    ## Relationship to reproducible builds    [Reproducible builds](/wiki/reproducible-builds) ask whether specified artifacts can be recreated from the documented source, instructions, and environment. Content addressing helps name and compare the inputs and outputs. It does not cause a nondeterministic build to become deterministic or recreate missing dependencies. [Reproducible Builds: Definition](https://reproducible-builds.org/docs/definition/)    For an archival handoff, a useful proposed record contains the identifier scheme, representation rules, retained locations, exact source revision, reconstruction instructions, and known verification limits. Such a record lets a later investigator distinguish byte identity, availability, rebuildability, and the truth of any claims made inside the artifact.