IPFS：分布式文件存储

在传统的Web中，用户数据是存储在中心化服务器上的。中心化的弊端是，第三方可能会在用户不知情或未同意的情况下随意访问其数据，用户隐私没有保障。

此外，中心化存储可能会导致可用性问题。特别是，如果将数据存储在一个地方，会导致单节点故障。

Web的文件存储

Web使用基于位置的寻址来存储和检索文件。假设我们要从域名abc.com中访问一张猫的图片cat.png。我们将通过网络浏览器访问此位置（i.eabc.com/cat.png），作为回报，我们将获得猫的照片。

但是，如果由于某种原因该文件现已从abc服务器中删除，我们将无法再访问该图片。现在，互联网上可能会有其他人拥有同一张猫的照片的副本，但是我们无法与他们建立联系并获取该照片的副本。

互联网上的许多文件可能具有相同的名称，但内容可能会有所不同。

IPFS解决方案

IPFS是用于点对点协议的文件存储，具有基于内容的寻址而不是基于位置的寻址。这就意味着，我们要查找文件，不需要知道它在哪里（abc.com/cat.png），而是要知道它包含什么（QmSNssW5a9S3KVRCYMemjsTByrNNrtXFnxNYLfmDr9Vaan），它由内容的哈希（hash）表示。

哈希功能为每个文件创建唯一的指纹。因此，如果我们要检索一个文件，我们将询问网络“谁拥有此文件（QmSNssW5a9S3KV...）”，然后来自IPFS网络的拥有该文件的人会将其提供给我们。

我们可以将请求的哈希值与接收到的哈希值进行比较，来验证文件的完整性。如果哈希值匹配，则表明文件未更改。此哈希功能还有助于对网络进行重复数据删除，以使具有相同内容的文件无法提交两次，因为相同的内容会产生相同的哈希。

这样可以优化存储要求，并提高网络性能。

IPFS如何存储

文件存储在IPFS上，会有一个包含以下内容的数据结构：

Data——可以存储多达256KB的Blob（非结构化数据块）。

Links ——链接IPFS对象的数组。

如果我们的文件大于256 KB，则将其拆分并存储在多个IPFS对象中，然后将创建一个空对象，该对象链接文件的所有其他对象。如下图所示：

IPFS数据对象

IPFS用作不可变的存储，一旦将某些内容添加到网络后就无法更改，因为要更改文件就得更改哈希。那么我们如何更新文件？

对此，IPFS使用版本控制系统，广泛地使用在开源的社区中，称为“Git”。IPFS具有提交对象，这有助于跟踪文件自创建以来的所有版本。

每次我们在IPFS网络上添加文件时，都会为该文件创建一个提交对象，并且在我们更新该文件时，会创建一个新的提交对象，该对象指向该文件的较早的提交对象，如下图所示。

IPFS提交对象

文件能永存吗

只有重要文件会保留在网络上，不重要的文件则由垃圾收集器删除，其中文件的重要性由“固定”（pinning）确定。通过固定文件，我们将该文件标记为重要文件，以便在不重要的文件仅被临时缓存的同时，保留该文件。

IPFS的挑战

IPFS最大的挑战之一是保持文件可用。IPFS承诺永久性（permanence），但不承诺持久性（persistence）。举个例子：如果Alice使文件可用，Bob能够访问它；如果Alice脱机，Bob仍可以访问它。当然，前提是垃圾回收器尚未将其删除。

另一方面，如果Bob固定了该文件，即使Alice的节点发生故障，该文件也将保持可访问状态。因此，固定是一个主要问题。现下，已有许多公共固定服务，因此持续性是需要成本的。

另一个限制是文件的实际共享。用户必须通过传统的通信机制与网络上的其他人共享文件链接（内容地址），比如即时消息、电子邮件、Skype及Slack等。

这意味着文件共享未内置于系统中。为了寻求相关的解决方案，人们已经开发了爬虫程序和搜索引擎网络。相信随着不断的完善，IPFS会变得越来越好。