Content Identifier (CID)

A CID is not just a raw hash; it's a self-describing identifier. The first bytes of a CID explicitly tell you how to decode the rest. This eliminates ambiguity and ensures future-proof compatibility.

• Multicodec Prefix: Indicates the cryptographic hash function used (e.g., sha2-256, blake2b-256).
• Multihash: Contains the hash digest itself, prefixed by its length, making it self-verifying.
• Multibase Encoding: The final string is encoded in a base that is itself identified by a single character prefix (e.g., b for base32), ensuring safe transport across different systems.

The core principle of a CID is that the address of the data is a cryptographic hash of the data itself. This creates a permanent, immutable link between the identifier and the content.

• Tamper-Proof: Any change to the underlying data produces a completely different CID.
• Deduplication: Identical data blocks will always resolve to the same CID, regardless of who added them or from where.
• Verifiability: Upon retrieval, you can re-hash the data to confirm it matches the CID, ensuring integrity without trusting the provider.

The CID specification has evolved to address limitations. Understanding the difference between CIDv0 and CIDv1 is critical for modern development.

• CIDv0: A legacy format that is always a base58-encoded multihash starting with Qm. It is implicitly protobuf-encoded and sha2-256 hashed, offering no flexibility.
• CIDv1: The current standard that uses explicit multicodec prefixes. It supports multiple codecs (e.g., dag-pb, raw, json) and bases, making it far more versatile and future-proof.

CIDs are the native linking primitive for the InterPlanetary Linked Data (IPLD) model. IPLD treats all hash-linked data structures as a unified Merkle DAG.

• Merkle DAGs: CIDs link data blocks together to form directed acyclic graphs, enabling complex data structures like Git repositories or blockchains.
• Codec Agnosticism: IPLD uses the CID's codec field to decode the data block into a canonical data model, allowing you to traverse links between blocks encoded in different formats (e.g., a dag-cbor block linking to a raw block).

A raw CID string can be decomposed into its constituent parts for inspection and debugging. Tools and libraries exist to parse any valid CID.

• Anatomy of a CIDv1: <multibase-prefix><cid-version><multicodec-content-type><multihash-function><multihash-length><hash-digest>
• Practical Tools: The cid.ipfs.tech website and command-line tools like ipfs cid format allow you to convert between versions and inspect the embedded codecs and hashes.
• Example: The CID bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi can be parsed to reveal it's a CIDv1 using raw codec and sha2-256 multihash.

Beyond addressing, a CID functions as a compact, portable proof of data integrity. It is a fundamental building block for verifiable systems.

• Verifiable Compute: A computation's output can be referenced by its CID, allowing a third party to verify the result without re-executing the logic.
• Software Supply Chain: Container images and packages can be addressed by CID to guarantee that a deployment uses the exact, untampered artifact.
• Data Provenance: By chaining CIDs in a Merkle DAG, you create an immutable, cryptographically verifiable history of data transformations.