IPFS技术分析的文件HASH值

不用说，IPFS很流行，太多人关注基于它的Filecoin挖矿。 但能不能得到多少好处，谁也说不准。 毕竟主网和测试网还没有上线。 不过，矿工们在路口的等待并不会减少大家对IPFS相关技术的关注。 除了Filecoin，越来越多的项目也会使用IPFS作为底层存储层或网络数据传输协议。

不要说空话。 笔直走。 IPFS 与传统文件系统的一个重要区别是内容寻址。 顾名思义，文件的内容确定了，它的地址（访问路径）也就确定了。 这与我们通常存储文件的方式不同。 通常，我可以随意更改图像的文件名并将其复制到不同的路径。 这样，同一个文件的访问方式随时都在变化，无法根据文件内容来确定访问路径。 相比之下，内容寻址的IPFS有一个天然的优势——防篡改。 只要修改了一位数据，其地址就会完全改变。 如果想通过修改文件来遮天蔽日，难度会急剧增加。

例如，我创建了一个非常简单的文本文件 demo.txt 并将其上传到 IPFS 网络：

$echo -n "StorSwift" > demo.txt
$ipfs add demo.txt 
added QmSsw6EcnwEiTT9c4rnAGeSENvsJMepNHmbrgi2S9bXNJr demo.txt

于是，我得到了一个HASH值QmSsw6EcnwEiTT9c4rnAGeSENvsJMepNHmbrgi2S9bXNJr，在世界任何地方都可以访问。 也可以通过IPFS网关在浏览器中查看：gateway.ipfs.io/ipfs/QmSsw6EcnwEiTT9c4rnAGeSENvsJMepNHmbrgi2S9bXNJr

下面简单探讨一下这个HASH值是如何得到的。

1.哈希算法：SHA2-256

玩区块链的人，不管对技术多熟悉，都或多或少知道这个概念。 IPFS 网络中存储的每个文件都会有一个唯一的哈希（HASH）值，通过它可以识别文件和访问数据。 只要文件内容稍作修改，HASH就会发生变化。 IPFS采用安全级别较高的算法SHA2-256。 对于任意长度的内容，生成的HASH值长度是固定的，为32字节。

Linux下可以直接使用sha256sum计算SHA2-256格式的HASH值：

$sha256sum demo.txt
6739529c5fb0802b60da9827b1a0942e08ab1a63f4bd855c49a74de55774bbef  demo.txt

得到的结果是64字节。 原因是因为使用了十六进制表示法，每个字符代表4位，加起来就是256位，也就是32个字节。 但是在IPFS中，上面得到的SHA2-256结果不能用来判断文件地址，因为IPFS还有一些额外的因素需要考虑。

之前，我们将 demo.txt 添加到 IPFS。 IPFS 除了文中的 StorSwift 字符外，还会添加一些元数据。 例如，我们可以通过以下命令查看 IPFSF 中存储的内容：

$ipfs object get QmSsw6EcnwEiTT9c4rnAGeSENvsJMepNHmbrgi2S9bXNJr
{"Links":[],"Data":"\u0008\u0002\u0012\tStorSwift\u0018\t"}

返回的是一个JSON格式的字符串，Data表示具体内容。 可以看到除了文件原来的内容外，还增加了一些其他的数据。 IPFS会将文件数据保存为unixfs格式，可以认为是IPFS核心数据结构MerkleDAG的一种表现形式。 具体内容将在后面进行说明。 我们可以通过获取IPFS原始格式的数据，计算出正确的HASH值。 IPFS 中保存的内容会被分成很多块。 因为本例中的文件比较小，所以可以分块保存。 因此，我们可以通过以下命令直接获取IPFS区块的内容：

$ipfs block get QmSsw6EcnwEiTT9c4rnAGeSENvsJMepNHmbrgi2S9bXNJr  | sha256sum
437246839fc6ad5e2b74386df944f99e7cb42998dee02f169644d88ce6b00b8f  -

区块的HASH值用十六进制表示：437246839fc6ad5e2b74386df944f99e7cb42998dee02f169644d88ce6b00b8f。 也是IPFS将文件以特定格式保存后的HASH值。

2. 扩展需求：multihash

是不是可以通过这个HASH值得到我们平时看到的IPFS文件的HASH值呢？ 好像不是这样的，因为我们看到的文件的HASH值都是Qm开头的，这里显然不是正确的数字。 这就涉及到另外一个话题——动态选择HASH算法的设计。

虽然现在SHA2-256还是比较安全的，但是随着技术的发展，说不定会有人突然宣布可以破解了呢？ 那自然需要更高级的算法。 但是IPFS协议是制定好的，不能随便更改。 怎么做？ 虽然现在用的是SHA2-256，但我可以说我支持多种HASH算法，到时候可以升级算法，但不会有大的架构变化。 因此IPFS采用了multihash，一种简单的HASH表示，支持多种HASH算法。 如果以后修改算法，仍然使用multihash来保证表达式的连续性。

multihash 的格式很简单。 具体文档参见：multiformats/multihash。 它实际上是一个字符串，由三部分组成：HASH算法编码、HASH值的长度（字节数）、HASH值。

SHA2-256的编码为0x12，其HASH摘要长度为32字节（十六进制为0x20）。 在上面得到的HASH值的开头加上1220，我们就得到了这个示例文件的multihash编码（十六进制）：

1220437246839fc6ad5e2b74386df944f99e7cb42998dee02f169644d88ce6b00b8f

3.易用性要求：Base58

但是这个HASH值显然不是我们看到的。 怎么了？ 太长了，一堆数字不好读，所以需要重新编码，压缩长度，便于传播。 为此IPFS采用了Base58的编码。 Base58最先被比特币采用，现在在区块链项目中非常流行，常用来表示钱包地址。 做过开发的朋友可能对Base64编码比较熟悉，它可以将任意二进制内容转换成便于软件查看的可读字符。 但是Base64也有一些缺点，就是有些字符不和谐，比如O和0容易混淆，+和/这样的符号容易让人把一个完整的字符串当成两个不同的字符串，形成读法差距。 障碍。 有时候我们用鼠标点击，想自动选中整个字符串，但是因为这些符号的干扰，导致选中操作效率不高。 因此比特币采用的哈希算法是，Base58编码诞生了。 很简单，它类似于Base64，可以将二进制内容转换成可读的字符，但是去掉上面提到的所有干扰字符。

Base58的代码很简单，可以从这里获取：keis/base58

我引用了里面的Python源文件，根据前面生成的multihash代码计算：

>>> import base58
>>> base58.b58encode_int(int("1220437246839fc6ad5e2b74386df944f99e7cb42998dee02f169644d88ce6b00b8f", 16))
'QmSsw6EcnwEiTT9c4rnAGeSENvsJMepNHmbrgi2S9bXNJr'

结果QmSsw6EcnwEiTT9c4rnAGeSENvsJMepNHmbrgi2S9bXNJr正是我们用ipfs add命令得到的HASH值！

补充一下比特币采用的哈希算法是，目前IPFS的multihash值都是1220开头的，按照Base58算法，计算出来的结果都是Qm开头的。

4.总结

你完成了！ 现在对IPFS文件的HASH值有了更清晰的认识，知道了它的来龙去脉。 总结起来就是：

封装原始数据->计算SHA2-256->封装成multihash->转换成Base58

当然，如果上传的是一个目录，或者一个分成多个块的文件，过程会比较复杂。

精彩回顾往事

点击下方“阅读原文”查看热门文章：【重磅】Filecoin Q1 Q2发布，含项目时间表和demo（附视频，全中文翻译）

↓↓↓