IPFS——内容寻址、版本化的P2P文件系统（未完成）
声明
这篇文章是来自于IPFS官网：https://docs.ipfs.tech/concepts/further-reading/academic-papers/，
本文的内容为本人翻译原创，如有侵权，请联系本人进行删除。本文末尾的心得感悟为本人原创。
摘要
星际文件系统（IPFS）是一个点对点的分布式文件系统，它试图将所有计算设备与相同的文件系统连接起来。在某些方面，IPFS类似于Web，但IPFS可以被视为单个BitTorrent群，在一个Git仓库中交换对象。换句话说，IPFS提供了一个高吞吐量的内容寻址块存储模型，具有内容寻址超链接。这形成了一个通用的Merkle DAG，一个可以在其上构建版本化文件系统、区块链甚至永久Web的数据结构。IPFS结合了分布式哈希表、激励式区块交换和自认证命名空间。IPFS没有单点故障，节点之间不需要信任。
引言
构建全局分布式文件系统的尝试已有很多。一些系统取得了显著的成功，而另一些则完全失败。在众多的学术尝试中，AFS[6]获得了广泛的成功并沿用至今。其他人没有取得同样的成功。在学术界之外，最成功的系统是主要针对大型媒体(音频和视频)的点对点文件共享应用程序。最值得注意的是，Napster、KaZaA和BitTorrent[2]部署了支持超过1亿同时用户的大型文件分发系统。即使在今天，BitTorrent仍然保持着大规模的部署，每天有数千万个节点在操作[16]。与学术上的文件系统相比，这些应用程序有更多的用户和文件分布。然而，这些应用程序并没有被设计成可以构建的基础设施。虽然有成功的重新用途1，但还没有出现通用的文件系统来提供全局的、低延迟的和分散的分发。
也许这是因为对于大多数用例来说已经存在一个“足够好的”系统:HTTP。到目前为止，HTTP是部署过的最成功的分布式文件系统。再加上浏览器，HTTP产生了巨大的技术和社会影响。它已经成为在互联网上传输文件的事实上的方式。然而，它没有利用过去15年发明的几十种杰出的文件分发技术。从一个角度来看，考虑到向后兼容约束的数量以及在当前模型中投资的强大方的数量，演化Web基础设施几乎是不可能的。但从另一个角度来看，自HTTP出现以来，新的协议不断涌现并得到广泛应用。我们所缺乏的是升级设计:增强当前的HTTP web，并在不降低用户体验的情况下引入新功能。
业界之所以使用HTTP这么长时间，是因为移动小文件相对便宜，即使对于流量很大的小型组织也是如此。但我们正在进入一个数据分发的新时代，面临着新的挑战:(a)托管和分发pb级的数据集，(b)跨组织的大数据计算，(c)高容量高清按需或实时媒体流，(d)海量数据集的版本控制和链接，(e)防止重要文件的意外消失，等等。其中许多可以归结为大量的数据，在任何地方都可以访问。”迫于关键特性和带宽问题的压力，我们已经放弃了HTTP，转而使用不同的数据分发协议。下一步是让它们成为Web本身的一部分。
与高效的数据分发正交，版本控制系统已经设法开发了重要的数据协作工作流。分布式源代码版本控制系统Git开发了许多有用的方法来建模和实现分布式数据操作。Git工具链提供了大型文件分发系统严重缺乏的通用版本控制功能。受Git启发的新解决方案正在出现，例如Camlistore[?]、个人文件存储系统和Dat[?]数据协作工具链和数据集包管理器。Git已经影响了分布式文件系统设计[9]，因为它的内容地址Merkle DAG数据模型使强大的文件分发策略成为可能。有待探索的是这种数据结构如何影响面向高吞吐量的文件系统的设计，以及它如何升级Web本身。
本文介绍了IPFS，一种新颖的对等版本控制文件系统，试图解决这些问题。IPFS综合了过去许多成功系统的经验。仔细的以接口为中心的集成产生的系统比各个部分的总和更大。IPFS的核心原则是将所有数据建模为同一个Merkle DAG的一部分。
背景
本节回顾成功的对等系统的重要特性，IPFS结合了对等系统。分布式哈希表
分布式哈希表（Distributed Hash table, DHT）被广泛用于对等系统的元数据协调和维护。例如，BitTorrent MainlineDHT跟踪torrent swarm的部分节点集合。Kademlia DHT
Kademlia[10]是一种流行的DHT，它提供：- 大规模网络中的高效查找：平均连接log2(n)个节点上的查询。（例如，有1000万个节点的网络需要20跳）。
- 低协调开销：优化发送给其他节点的控制消息数量。
- 通过选择生存时间长的节点来抵抗各种攻击。
- 广泛应用于p2p应用中，包括Gnutella和BitTorrent，形成了超过2000万个节点的[16]网络。
Coral DSHT
虽然有些对等文件系统直接将数据块存储在dht中，但这浪费了存储和带宽，因为数据必须存储在不需要它的节点上。Coral DSHT以三个特别重要的方式扩展了Kademlia： 1. Kademlia将值存储在节点中，节点的id离键值\最近”(使用异或距离)。这没有考虑应用程序数据的局部性，忽略可能已经拥有数据的\远的节点，并强制\最近的节点存储数据，无论它们是否需要。这浪费了大量的存储空间和带宽。相反，Coral将地址存储给能够提供数据块的节点。
2. Coral将DHT API从get_value(key)放宽为get_any_values(key) (DSHT中的\邋遢”)。这仍然有效，因为Coral用户只需要一个(工作的)节点，而不是完整的列表。作为回报，Coral只能将值的子集分配给\最近的“节点”，从而避免了热点(当一个键变得流行时，所有最近的节点会超载)。
3.此外，Coral还根据区域和大小组织了一个独立的dsht层次结构，称为集群。这使得节点可以首先查询其区域内的节点，找到附近的数据而无需查询远处的节点，从而大大减少了查找的延迟。
2. Coral将DHT API从get_value(key)放宽为get_any_values(key) (DSHT中的\邋遢”)。这仍然有效，因为Coral用户只需要一个(工作的)节点，而不是完整的列表。作为回报，Coral只能将值的子集分配给\最近的“节点”，从而避免了热点(当一个键变得流行时，所有最近的节点会超载)。
3.此外，Coral还根据区域和大小组织了一个独立的dsht层次结构，称为集群。这使得节点可以首先查询其区域内的节点，找到附近的数据而无需查询远处的节点，从而大大减少了查找的延迟。
