Content Addressing

In one sentence: Every object in the image system is named by the SHA-256 hash of its own bytes, which makes objects immutable, self-verifying, and automatically deduplicated.

The name is the fingerprint

In a content-addressed store you don't choose names — the bytes choose. Store a layer, and its name is sha256(bytes). Three properties fall out at once. Immutability: "modifying" an object is impossible; different bytes are a different name. Verification: anyone holding the blob can re-hash it and detect tampering or corruption — no signatures needed for integrity. Deduplication: if two images share a base layer, the bytes hash identically, so the store holds one copy no matter how many manifests reference it.

flowchart TB
  MA["manifest: web-app"] --> LA["sha256:11aa…
web app files"]
  MA --> BASE["sha256:77ff…
base OS layer
(stored ONCE)"]
  MB["manifest: worker-app"] --> LB["sha256:22bb…
worker files"]
  MB --> BASE
  style BASE fill:#eaf1fe,stroke:#1d63ed,stroke-width:2px
    

Trust through re-hashing

Because names are fingerprints, the engine can accept blobs from anywhere — an untrusted mirror, a cache, a peer — and still be safe, as long as the digest it expected came from somewhere trusted. This is the foundation the registry protocol (Part 3) is built on:

sequenceDiagram
  participant E as Engine
  participant S as Any source (even untrusted)
  E->>S: give me blob sha256:77ff…
  S-->>E: bytes (2 GB)
  E->>E: recompute sha256 over received bytes
  alt hash equals 77ff…
    E->>E: store blob — verified, provenance irrelevant
  else mismatch
    E->>E: discard — corrupted or malicious
  end