What Is the Difference Between Content‑Addressable Storage and Location‑Based Addressing

Content-addressable storage (CAS) makes the address a function of the bytes — you run a cryptographic hash over the content and use the digest as the key, so the name is derived from the data and cannot drift from it; location-based addressing does the opposite, giving data a name (a path, a URL, a disk offset) that is assigned independently of the bytes and stays fixed while the bytes underneath are free to change.

That single design choice — is the name computed from the content, or assigned to a place? — is what produces every downstream property: deduplication, tamper-evidence, immutability, and location-independent retrieval on one side; mutability, human-readable names, and in-place updates (plus link rot) on the other.

The mechanism, step by step

A CAS write is a pure pipeline: address = H(content). Because H is deterministic, the same input always yields the same address, and (for a good hash) different inputs practically never do. Git is the cleanest real example — every blob, tree, and commit is stored under the SHA-1 of a small header plus its bytes. Here is exactly what Git computes for the string hello\n (the \n is a real newline byte, so the payload is 6 bytes):

1. Build the object: "blob" + " " + "6" + "\0" + "hello\n" — the type, a space, the byte length, a NUL separator, then the raw content.
2. Hash it: SHA-1("blob 6\0hello\n").
3. The digest is the address: ce013625030ba8dba906f756967f9e9ca394464a. Git stores the zlib-compressed object at .git/objects/ce/013625030ba8dba906f756967f9e9ca394464a.

Now trace three writes to see every CAS property fall out of that one rule:

Write 2 is the whole point of CAS and the place the earlier draft used the wrong word: two identical inputs producing the same digest is a hash match, not a hash collision. A collision is the pathological case where different inputs hash to the same digest — the thing a cryptographic hash is designed to make infeasible. Dedup relies on matches; collisions would break CAS (see Pitfalls). Write 3 shows integrity for free: change one byte and the address changes completely (ce013625… vs d7a963a6…), so a stored object can never silently disagree with its own name — re-hash on read and compare.

Location-based addressing, and why it is the default

A path like C:\Users\Name\photo.jpg or a URL like https://example.com/img/photo.jpg names a slot. The filesystem walks directory entries (or DNS + the server's routing walks host and path) to reach that slot and returns whatever currently lives there. The name is assigned by a human or an allocator, never derived from the bytes, so: (a) you can overwrite in place and every existing reference silently sees the new version — ideal for a homepage or a mutable database row; (b) the same bytes copied to two paths are two independent objects with no notion that they are equal; and (c) if the slot moves or its host disappears, the name resolves to nothing — a 404, the canonical failure of location addressing (link rot).

Pitfalls

• Saying "collision" when you mean "match." Identical content → identical digest is the mechanism working as intended (dedup). A collision is two different inputs mapping to the same digest — and it is a genuine threat, not just pedantry: if an attacker finds one, they can swap malicious bytes under a trusted address. This is why Git is migrating off SHA-1 (the SHAttered attack produced two distinct PDFs with the same SHA-1 in 2017) toward SHA-256. Choose the hash for your threat model.
• Treating a content hash as a mutable pointer. CAS addresses are immutable by construction, so "give me the latest version" is not a CAS operation. Every system layers a mutable index on top (Git branches/refs, IPFS's IPNS, a Docker tag). Forgetting this leads to designs that re-derive and re-distribute a new hash to every consumer on each edit — quadratic pain for high-churn data.
• Unbounded version growth. Because each edit is a new object and old objects are never overwritten, high-churn data accumulates. Git needs gc/packing; a naive CAS archive of a frequently-edited file stores every revision forever. Budget for garbage collection and reference-counting.
• Assuming CAS gives you availability. A content hash guarantees integrity and identity, not that anyone still holds the bytes. On IPFS an unpinned CID can become unretrievable even though the address is "permanent." Permanence of the name is not persistence of the data.
• Hashing on the hot write path. Hashing multi-GB objects costs real CPU and memory bandwidth on every write, and you can't stream-forward until the digest is known. For latency-sensitive mutable writes this overhead is pure tax that location addressing never pays.

When to use it / when not to

Concrete signals that point to CAS: the data is write-once / rarely-mutated (build artifacts, packages, media, snapshots); you need tamper-evidence or reproducibility ("the artifact behind this hash is provably the one I tested"); many references share identical bytes and dedup pays off (backups, container layers); or you want location-independent retrieval across a distributed/decentralized fleet where any holder can serve the bytes.

Signals that point to location addressing: the data mutates in place and consumers must always see "current" (a homepage, a config file, a DB row); humans need to read, guess, or organize the names hierarchically; write latency matters and you can't afford a hashing step; or a single owner legitimately controls and moves the resource.

Trade-offs vs. the alternative

Choosing CAS over location addressing buys you free integrity checks, automatic dedup, immutable/verifiable references, and any-node retrieval. It costs you: a required mutable-name layer for "latest" (extra indirection and a second system to keep consistent), opaque non-human-readable addresses, hashing CPU on every write, version bloat plus GC, and a discovery mechanism (an index or a DHT) to find who holds a given hash. Choosing location addressing buys simplicity, in-place mutation, human-friendly names, and the fastest possible writes — at the cost of no integrity guarantee, no dedup, and brittle links that rot when things move.

Choose CAS when the content is effectively immutable and you value verifiable identity, dedup, or decentralized retrieval more than write speed and readable names. Prefer location addressing when content changes frequently in place, references must track the newest state automatically, and human-readable, fast, single-owner access is what you actually need. Most real systems combine them — an IPFS gateway URL (https://gateway/ipfs/{CID}) or a content hash embedded in a path gives you a readable, resolvable location wrapping a verifiable content address.

Takeaways

• The one distinction: CAS derives the name from the bytes (address = H(content)); location addressing assigns a name to a place, independent of the bytes. Every other property follows from that.
• Identical content → identical address is a match (the basis of dedup and integrity). A collision is different content → same address — an attack you must design the hash choice against, not a feature.
• CAS gives integrity, dedup, and immutability for free but needs a mutable index for "latest," pays hashing cost on writes, and accumulates versions. Location addressing is fast, mutable, and readable but offers no integrity and rots.
• They compose: wrap a content address inside a location (gateway URL, hash-in-path) to get verifiability plus a resolvable, readable handle.

Re-authored and deepened for this guide. Sources: the Git internals model of objects (Scott Chacon & Ben Straub, Pro Git, ch. 10 "Git Objects"); the IPFS content-identifier (CID) and pinning docs (docs.ipfs.tech); the SHAttered SHA-1 collision result (Stevens et al., CWI/Google, 2017) and Git's SHA-256 transition plan; and the classic content-addressable-storage discussion in the DesignGurus system-design answers. Hash values in the worked example were computed with git hash-object.