CID在Filecoin与IPFS中的意义及数据安全保障机制

CID（content identifier，内容标识符）是一种用于在分布式信息系统（如IPFS或Filecoin）中引用内容的格式。在IPFS中，它是长这样的：

QmcRD4wkPPi6dig81r5sLj9Zm1gDCL4zgpEj9CfuRrGbzF

这串字符并不是表示内容存储的位置，而是根据内容本身形成的一种地址。CID中的字符数取决于底层内容的加密哈希，而不是内容本身的大小。

如果要创建一个CID，第一步就是转换输入数据，即使用加密算法将任何大小的输入（数据与文件）映射到固定大小的输出，这种转换称为密码哈希摘要，简称哈希。它的存在是为你创建出一个数字“指纹”。

使用加密算法生成的散列具有以下特征：

确定性：相同输入应该总是产生相同哈希。

不相关：输入中的一个小变化应该会产生一个完全不同的散列。

单向：从哈希中重建数据应该是不可行的。

独特性：只有一个文件可以产生一个特定的哈希值。

并不是所有的哈希算法都是非常安全的，而不同系统使用的加密算法也有所区别。为了支持多种哈希算法，IPFS与Filecoin使用multihash，即多重哈希。

之前的文章中，星际云存曾简单介绍过多重哈希，它是一种自描述的哈希，本身包含描述其长度和生成它加密算法的元数据，支持多种哈希算法，而非依赖于某种特定的哈希算法，是一种面向未来的哈希。

多重哈希遵循TLV模式(type-length-value)。用于生成哈希的加密算法sha2-256的标识符为type，哈希的实际长度为length，实际的哈希值为value。在IPFS中首次创建文件时，系统会使用base58btc编码来创建CID。

base58btc与多重哈希开启了CID的第一个版本，即CIDv0，它的前缀仍然有被发现的风险。为了解决这些问题，一个新版本CID出现了，即CIDv1。

但是当我们试图读取数据本身时，我们怎么知道使用的编码方法呢？该数据可能是使用CBOR、Protobuf、JSON进行了编码，哪个才是正确的呢？

CIDv1引入了另一个前缀，即唯一标识所使用的编码方法，叫做多编解码器前缀（multicodec prefix），它指示了对数据使用的编码。

多编解码器支持不同类型的编码，每种编码都有自己的短编解码器标识符，使用编解码器编码的数据前缀（以dag-pb为例）表示为红色的部分。其他部分则分别代表了如下含义：

为了区分不同版本的CID，CIDv1还在这个基础上添加了更多前缀，以表示自己目前使用的版本。

现在的CID是这样的：

为了让这串CID变得人类更方便阅读，需要将上述这些二进制通过基本编码转换为字符串。上文提到过，CIDv0中，哈希编码使用的是base58btc，通过它可以安全地解释CIDv0哈希。但有时由于一些限制，还需要一些能支持更多基本编码的方式，也就意味着还需要加上新的前缀——Multibase前缀。

Multibase前缀用于表示在字符串和二进制格式之间转换CID时使用的基本编码，它仅用于CID的字符串形式：

上文为二进制，下文为字符串

上文以Qm开头的为base58btc编码的CIDv0，下文以b开头的则为使用base32编码，是大部分IPFS默认使用的标识符

任何CIDv0都可以转换为CIDv1，但由于CIDv1支持multibase而CIDv0不支持，因此大部分时候都不能逆向转换。在具有以下属性的CIDv1才可转化为CIDv0：

multibase=base58btc

multicodec=dag-pb

multihash-algorithm=sha2-256

multihash-length=32（32字节，相当于256位）

现在，你应该了解一个CID具体包含了什么，不同CID之间的区别又是什么，在去中心化网络中，这些都是非常基础且重要的部分。CID代表着掌控数据的“钥匙”，由Multiformats项目定义的各种自描述值构成。希望你能在这篇中有所收获。

热点：ipfs 数据