探索 CID 的来龙去脉

IPFS搬运工 2021-01-15 11:36 376

当我们在分散的Web上与对等体交换数据时,我们依靠内容寻址(而不是集中式Web的位置寻址)来安全地定位和识别数据。本文中,了解重要的分散Web概念的基础知识,如内容寻址、加密哈希、内容标识符 (CID)和与对等方共享。

01 什么是 CID?

CID规范起源于IPFS,现在采用多格式,支持广泛的项目,包括IPFS、IPLD、libp2p和Filecoin。本部分将介绍 CID本身的解剖,这些分布式信息系统都用作引用内容的核心标识符。

内容标识符(CID)是自描述内容寻址标识符。它不指示内容的存储位置,但它基于内容本身形成一种地址。CID 中的字符数取决于基础内容的加密哈希,而不是内容本身的大小。由于IPFS中的大多数内容都是使用进行哈希处理的,因此您遇到的大多数CID大小相同(256位,相当于32字节)。这使得它们更易于管理,尤其是在处理多个内容时。sha-256

例如,如果我们在IPFS网络上存储了aardvark的图像,其CID将看起来像这样:

Qmcrd4wkppi6dig81r5slj9zm1gdcl4zgpej9cfurrgbzf

创建CID的第一步是使用加密算法转换输入数据,该算法将任意大小的输入(数据或文件)映射到固定大小的输出。此转换称为加密哈希摘要或只是哈希。

图片

使用的加密算法必须生成具有以下特征的哈希:

1、确定性:相同的输入应始终生成相同的哈希。

2、不相关:输入中的小变化应生成完全不同的哈希。

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

4、唯一:只有一个文件可以生成一个特定的哈希。

请注意,如果我们在aardvark图像中更改单个像素,我们的加密算法将为图像生成完全不同的哈希值。当我们使用内容地址获取数据时,我们保证会看到该数据的预期版本。这与集中式Web上的位置寻址大不相同,其中给定地址(URL)上的内容可能会随着时间而变化。

加密哈希不是IPFS所独有的,而且有许多散列算法,如 、和 、不再安全等。IPFS默认情况下使用 sha2-256,但 CID 几乎支持任何强加密哈希算法。sha2-256blake2bsha3-256sha3-512sha1md5

02 多哈希

有时,散列算法可能被证明是不安全的,这意味着它不再符合我们前面定义的特征。这种情况已经发生了。随着时间的推移,其他算法可能不足以用于IPFS和其他分布式信息系统中的内容寻址。因此,为了支持多个加密算法,我们需要能够知道使用哪种算法来生成特定内容的哈希。

图片

那么,我们该怎么做呢?为了支持多哈希算法,我们使用多哈希。

多哈希格式

多哈希是一种自描述的哈希,它本身包含元数据,描述其长度和生成它的加密算法。多格式CID是面向未来的,因为它们使用多哈希来支持多个哈希算法,而不是依赖于特定的哈希算法。

多哈式遵循模式 。从本质上讲,"原始哈希"的前缀是应用的哈希算法和哈希的。TLVtype-length-valuetypelength

图片

1、type:用于生成哈希的加密算法的标识符(例如,的标识符将 - 以十六进制表示) -请参阅所有标识符的多代码表sha2-256180x12

2、length:哈希的实际长度 (相当于 32 字节)sha2-256256

3、value:实际哈希值

为了将CID表示为压缩字符串而不是普通二进制(一系列 s 和 s),我们可以使用基础编码。

首次创建IPFS时,它使用编码创建看起来像这样1的CIP:10base58btc

QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU

多哈希格式和编码启用了CID的第一个版本(现在称为版本 0),其初始字符仍然很容易发现。base58btcCIDv0Qm...

然而,随着时间的推移,人们开始怀疑这种多哈希格式是否足够:

1、我们怎么知道使用什么方法来编码数据?

2、我们怎么知道使用什么方法来创建CID的字符串表示形式?我们会一直使用吗?base58btc

为了解决这些顾虑,有必要对下一个版本的CID进行演化。

03 CIDv1:多代码前缀

CIDv0使用多哈希支持多个哈希函数。这意味着我们可以使用不同的哈希算法成功生成特定内容的哈希,以后能够使用此哈希识别内容。

但是,当我们试图读取数据本身时,我们怎么知道使用的编码方法?它可以编码与CBOR,原型,普通JSON等。若要解决此问题,请引入另一个唯一标识所用编码方法的前缀。

多代码前缀指示对数据使用哪种编码。

图片

多码c支持许多不同类型的编码,每个编码都有自己的短编解码器标识符,如完整表所示。

在上面的示例中,我们可以看到使用编解码器编码的数据如何在我们的CID中表示。是许多不同类型的IPLD(行星间链接数据)编解码器之一。由于IPFS始终对数据使用这些IPLD格式之一,因此IPFS CID中的多代码前缀将始终是IPLD编解码器。

但是,需要注意的是,多代码不仅由IPFS和IPLD使用。除了多哈希和其他一些自描述协议一样,它是多格式项目的一部分,该项目从IPFS中剥离出来,现在支持各种各样的其他项目和协议,包括我们在这里学习的 CID规范。

CIDv1:版本前缀

现在,我们添加了多代码,我们的版本1 CID包含以下字段:

<multicodec><multihash-algorithm><multihash-length><multihash-hash>

但是,如果您还记得前面的课程,版本0 CID仅包含部件,那么我们如何区分不同版本的CID?你猜对了, 更多的前缀!<multihash-*>

图片

现在我们的CID如下所示:

<cid-version><multicodec><multihash>

表示 CID (0 或 1) 的版本。<cid-version>

04 CIDv1:多基前缀

因此,现在我们的CIDv1在二进制(0s和1s)给我们的信息:

<cid-version><multicodec><multihash>

由于二进制 CIP 不是很人性化,我们可以以字符串形式表示这些二进制 CID(二进制数据表示为文本)。例子:

bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

在二进制格式和字符串格式之间转换数据需要基本编码,因此在使用字符串CD时,我们了解应用于二进制数据的基本编码类型非常重要。但是,我们如何识别这一点呢?

哈希始终使用进行编码。这意味着我们可以安全地解释哈希值,假设它们正在使用。但是,由于环境限制(例如 DNS 名称),我们还需要支持其他基本编码的能力。为此,我们可以再加一个前缀!

CIDv0base58btcCIDv0base58btc

05 多基前缀

多基前缀表示在字符串格式和二进制格式之间转换 CID 时使用的基本编码,仅在 CID 的字符串形式中使用:

图片

让我们以字符串形式检查两个 CID 示例:

图片

我们知道第一个是 ,因为它以开头。从0开始的所有哈希都可以安全地解释为版本0的CID。

CIDv0Qm...Qmbase58btc

第二个示例以开头的base编码前缀标识符,默认情况下,大多数IPFS实现都使用该标识符。bbase32

有关标识符的完整列表,请参考下图。

图片

06 一个哈希,多个 CID 版本

您可以将任何IPFS CID粘贴到方便的CID检查器中,以可视化其所有前缀及其表示内容。

我们将使用CIDv0 和 CIDv1格式查看此工具的一些结果。

示例 1:CIDv1

bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

第一个示例是版本 1 CID。

图片

查看CID检查器工具的结果,我们可以看到该工具能够为我们分析的几个部分:

1、Human Readable CID: 分解 Cid 的每个部分, 以便我们人类易于阅读

2、Multibase:是基的标识符,在这种情况下,对于 。codebbase32

3、Multicodec:是编解码器的标识符,在这种情况下,IPLD 格式code0x70dag-pb

4、Multihash:将多哈希分解为使用的哈希算法(是 )的代码,哈希的长度(256位,相当于32字节),以及内容哈希本身(摘要十六进制)。18sha2-256

从"人类可读CID"细分中,我们可以看到在添加适当的CIDv1前缀之前,内容的原始哈希是 。C3C4733EC8AFFD06CF9E9FF50FFC6BCD2EC85A6170004BB709669C31DE94391A

示例 2:CIDv0

QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR

图片

此版本0 CID 显示了一些不同的结果:和 都被列为"隐式"。由于版本0 2D 没有这些前缀,因此它们始终假定为和分别。

multibasemulticodecbase58btcdag-pb

在标签下,我们看到:这是相同的CID从第一个示例!CID检查器为我们提供了从CIDv0转换为CIDv1的转换。

Base32CIDV1bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

另请注意,"人类可读 CID"(前缀后部分)的末尾在此CIDv0示例中与CIDv1示例中完全相同:C3C4733EC8AFFD06CF9E9FF50FFC6BCD2EC85A6170004BB709669C31DE94391A

为什么?这两个CID指向相同的内容。基本上,它是在CID规范的两个不同版本中表示的相同哈希

C3C4733EC8AFFD06CF9E9FF50FFC6BCD2EC85A6170004BB709669C31DE94391A

转换 CID 版本

您可以将任何前缀转换为,因为隐式前缀在变为显式。但是,由于支持多个编解码器和多个基,并且不支持,因此并非所有代码都可以转换为 。实际上,只有具有以下属性的才能转换为 :

CIDv0CIDv1v0v1CIDv1CIDv0CIDv1CIDv0CIDv1CIDv0

1、multibase=base58btc

2、multicodec=dag-pb

3、multihash-algorithm=sha2-256

4、multihash-length=32(32 字节,相当于256 位)

为了验证这一理论,您可以在此处查看我们心爱的 aardvark 图像,该映像托管在 IPFS网络上:https://ipfs.io/ipfs/QmcRD4wkPPi6dig81r5sLj9Zm1gDCL4zgpEj9CfuRrGbzF

1、打开浏览器中的链接,从URL的末尾复制CID(QmcRD4wkPPi6dig81r5sLj9Zm1gDCL4zgpEj9CfuRrGbzF)

2、在新的浏览器窗口中,将其粘贴到CID检查器工具中,并查找屏幕底部显示的等效CIDv1值

3、回到aardvark 选项卡中,将CID替换为原始URL 中转换后的CID并刷新页面v0v1

你应该看到我们的阿尔德瓦尔克相同的图像。



本文来源:星际视界IPFSNEWS
版权声明:原站点及作者保留权利。文章为作者独立观点,不代表IPFS.CN社区的立场。
收藏 分享

全部评论