IPFS:分布式文件存储

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

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

Web的文件存储

　　Web使用基于位置的寻址来存储和检索文件。假设我们要从域名abc.com中访问一张猫的图片cat.png。我们将通过网络浏览器访问此位置(i.e abc.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使用版本控制系统，广泛地使用在开源的社区中，称为“Git”。IPFS具有提交对象，这有助于跟踪文件自创建以来的所有版本。

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

文件能永存吗

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

IPFS的挑战

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

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

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

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

相关文章

【IPFS星际联盟周刊】IPFS最近动态信息汇总

【IPFS周刊79】IPFS应用又添新成员！

IPFS&Filecoin创始人胡安在Tiwtter为星际联盟点赞

什么是Web3.0之史无前例的Web3.0革命（一）

传统应用已被IPFS应用玩坏了，你再不知道就Out了！

重磅|星际文件系统IPFS迎来史上最大更新