IPFS文件长什么样？我们该如何构建？

IPFS的核心是一个分布式系统，用于存储和访问文件，网站，应用程序和数据。它与传输层无关，这意味着它可以在各种传输层上进行通信，包括传输控制协议（TCP），uTP，UDT，QUIC，TOR甚至是蓝牙。

相比于HTTP，IPFS的传输速度之所以更快，在于IPFS是通过哈希标识的方式查找文件的，当你拥有哈希后，你会询问并连接到的网络“谁拥有此内容（哈希）”。然后连接到相应的节点并下载，也就是说，这能形成点对点覆盖，从而实现非常快速并且广泛和即可使用的路由。

IPFS 节点

IPFS本质上是一个用于检索和共享IPFS对象的P2P系统。IPFS节点是具有两个字段的数据结构。

• 数据 ：大小小于256 kB的非结构化二进制数据的容量

• 链接 ：可以链接到其他IPFS节点

链接结构具有三个数据字段：

• 名称：链接的名称

• 哈希：链接IPFS对象的哈希

• 大小：链接的IPFS节点的累积大小，包括跟随其链接的位置

IPFS节点通常由其Base58编码的哈希引用。例如，让我们使用IPFS命令行工具查看带有哈希QmarHSr9aSNaPSR6G9KFPbuLV9aEqJfTk1y9B8pdwqK4Rq的IPFS对象：

你可能会注意到，所有哈希都以“ Qm”开头。因为散列实际上是一个多散列，这意味着散列本身在多散列的前两个字节中指定了散列函数和散列的长度。在上面的示例中，十六进制的前两个字节为1220，其中12表示这是SHA256哈希函数，而20表示哈希的长度（以字节为单位），即32个字节。

数据和命名的链接给IPFS对象的集合A的结构梅克尔DAG - DAG意味着向无环图，并梅克尔表示这个是使用密码散列到地址内容的加密认证的数据结构。

为了可视化图形结构，我们将通过节点中带有Data的图形可视化IPFS对象，并且将Links指向图形边缘指向其他IPFS对象，其中Link的名称是图形边缘上的标签。

现在，我们将给出可以由IPFS对象表示的各种数据结构的示例。

文件系统

IPFS可以轻松表示一个由文件和目录组成的文件系统。我们可以通过以下案例来分解文件的表达方式。

小档案 

一个小文件（<256 kB）由IPFS对象表示，数据为文件内容（加上小页眉和页脚），没有链接，即，链接数组为空。请注意，文件名不是IPFS对象的一部分，因此两个具有不同名称和相同内容的文件将具有相同的IPFS对象表示形式，因此具有相同的哈希值。我们可以使用ipfs add命令向IPFS添加一个小文件：

我们可以使用ipfs cat查看上述IPFS对象的文件内容：

使用ipfs对象查看基础结构可获得收益：

我们将该文件可视化如下：

大文件

大型文件（> 256 kB）由指向<256 kB的文件块的链接列表表示，并且只有最小的Data指定此对象表示大型文件，文件块的链接具有空字符串作为名称。

 目录结构

目录由指向代表文件或其他目录的IPFS对象的链接列表表示。链接的名称是文件和目录的名称。例如，考虑目录test_dir的以下目录结构：

文件hello.txt和my_file.txt都包含字符串Hello World！ n。文件testing.txt包含字符串Testing 123 \ n。

当将此目录结构表示为IPFS对象时，它看起来像这样：

请注意，对包含Hello World！ n的文件进行了自动重复数据删除， n该文件中的数据仅存储在IPFS中的一个逻辑位置（由其哈希地址寻址）。

IPFS命令行工具可以无缝地跟随目录链接名称来遍历文件系统：

版本文件系统

IPFS可以表示Git用于版本化文件系统的数据结构。Git提交对象在Git Book中进行了描述。Commit对象的主要属性是它具有一个或多个链接，其名称为parent0，parent1等，指向先前的提交，以及一个名称对象的链接（Git中的树），该链接指向该提交所引用的文件系统结构。 

让我们用同样的例子，我们以前的文件系统的目录结构有两个一起提交：第一次提交是原来的结构，并在第二次提交，我们已经更新了文件my_file.txt到了另一个世界，而不是原始的Hello World。

在此还要注意，我们具有自动重复数据删除功能，因此第二个提交中的新对象只是主目录，新目录my_dir和更新的文件my_file.txt。

区块链

区块链具有自然的DAG结构，因为过去的区块始终通过其后继区块的哈希值进行链接。以太坊区块链等更高级的区块链也有一个关联的状态数据库，该数据库具有Merkle-Patricia树结构，也可以使用IPFS对象进行仿真。

我们假设一个简单的区块链模型，其中每个块包含以下数据：

• 交易对象清单

• 到上一个块的链接

• 状态树/数据库的哈希

然后可以在IPFS中按以下方式对该区块链进行建模：

我们看到将状态数据库放在IPFS上时获得的重复数据删除，在两个块之间，只需要显式地存储已更改的状态条目，而不是整个状态（这将大大增加数据负担）。

这里有趣的一点是，将数据存储在区块链上与将数据哈希存储在区块链上之间的区别。在以太坊平台上，我们需要支付高昂的费用才能将数据存储在关联的状态数据库中，以最大程度地减少状态数据库的膨胀。因此，这是一种常见的设计模式，即较大的数据不存储数据本身，而是存储状态数据库中数据的IPFS哈希。

通常，区块链将每个矿工复制的全球分类帐中的内容（也就是链本身中存储的数据）与链中可能引用但未在所有节点之间复制的数据进行区分。

如果在IPFS中已经表示了具有相关状态数据库的区块链，那么将哈希存储在区块链上和将数据存储在区块链上之间的区别就变得模糊了，因为无论如何所有内容都存储在IPFS中，并且仅区块的哈希需要状态数据库的哈希值。在这种情况下，如果有人在区块链中存储了IPFS链接，我们可以无缝地跟随该链接来访问数据，就好像数据存储在区块链本身中一样。

但是，通过查看矿工在创建新区块时需要处理的内容，我们仍然可以区分链上和链下数据存储。在当前的以太坊网络中，矿工需要处理将更新状态数据库的交易。为此，他们需要访问完整状态数据库以便能够在更改后的任何地方对其进行更新。

因此，在以IPFS表示的区块链状态数据库中，我们仍然需要将数据标记为“链上”或“链外”。对于矿工来说，“链上”数据对于本地采矿是必不可少的，并且该数据将直接受到交易的影响。“链外”数据将必须由用户更新，而无需由矿工接触。