BETHASH官方网站(访问: hash.cyou 领取999USDT）

　　InterPlanetary文件系统（IPFS）是一个点对点分布式文件系统，旨在将所有计算设备与相同的文件系统连接起来。 在某些方面，IPFS与Web很相似，但IPFS可以被看作是一个单一的BitTorrent群，在一个Git存储库内交换对象。 换句话说，IPFS提供了高吞吐量的内容寻址块存储模型，并提供了内容寻址超链接。 这形成了一个广义的Merkle DAG，一个数据结构，人们可以在该数据结构上构建版本化文件系统，区块链甚至永久Web。 IPFS结合了分布式散列表，激励式块交换和自我认证命名空间。 IPFS没有单点故障，节点也不需要相互信任。

　　在构建全球分布式文件系统方面进行了许多尝试。有些系统已经取得了显着的成功，其他系统完全失败。在学术尝试中，AFS [6]得到了广泛的成功，并且今天仍在使用。其他人[7，？]还没有取得同样的成功。在学术界之外，最成功的系统一直是主要针对大型媒体（音频和视频）的点对点文件共享应用程序。最值得注意的是，Napster，KaZaA和BitTorrent [2]部署了大型文件分发系统，为超过1亿同时用户提供支持。即使在今天，BitTorrent仍然有大量的部署，每天有数千万个节点流失[16]。这些应用程序看到的分布式用户和文件数量比文件系统的文件系统分布更多。但是，这些应用程序并不是作为基础设施来设计的。虽然有成功的重新调整1，但没有出现能够提供全球性，低延迟和分散式分布的一般文件系统。

　　也许这是因为大多数用例的“足够好”系统已经存在：HTTP。 到目前为止，HTTP是最成功的“分布式文件系统”。 与浏览器一起使用，HTTP具有巨大的技术和社会影响。 它已经成为通过互联网传输文件的事实上的方式。 然而，它没有利用过去15年发明的数十种辉煌的文件分发技术。 从一个角度来看，考虑到后向兼容性约束的数量以及在当前模型中投入的强大团队的数量，发展中的Web基础架构几乎不可能实现。 但是从另一个角度看，自HTTP出现以来，新的协议已经出现并得到了广泛的应用。 缺乏的是升级设计：增强当前的HTTP网页，并引入新功能而不会降低用户体验。

　　业界已经开始使用HTTP这种长时间的方式，因为移动小文件相对便宜，即使对于拥有大量流量的小型组织也是如此。 但是，我们正在进入一个新的数据分发时代，并面临新的挑战：（a）托管和分发PB级数据集;（b）计算跨组织的大数据;（c）高容量高清晰度按需或实时数据库; 实时媒体流，（d）编辑和链接大量数据集，（e）防止重要文件被意外丢失等等。 其中很多可以归结为“大量数据，可以随时访问”。受关键特性和带宽关系的影响，我们已经放弃了针对不同数据分布协议的HTTP。 下一步是让他们成为Web本身的一部分。

　　正交于高效的数据分发，版本控制系统已经设法开发重要的数据协作工作流程。 分布式源代码版本控制系统Git开发了许多有用的方法来建模和实现分布式数据操作。 Git工具链提供了大型文件分发系统严重缺乏的多功能版本控制功能。 受Git启发的新解决方案正在兴起，如Camlistore [？]，个人文件存储系统，以及Dat [？]数据协作工具链和数据集包管理器。 Git已经影响了分布式文件系统设计[9]，因为它的基于内容寻址的Merkle DAG数据模型使得强大的文件分发策略得以可能实现。 还有待研究的是这种数据结构如何影响高吞吐量定向文件系统的设计，以及它如何升级Web本身。

　　IPFS节点需要一个路由系统，可以找到（a）其他对等节点的网络地址和（b）可以服务特定对象的对等节点。 IPFS使用基于S/Kademlia和Coral的DSHT，使用2.1中讨论的属性来实现此目的。 IPFS的对象大小和使用模式与Coral [5]和Mainline [16]相似，因此IPFS DHT根据其大小对存储的值进行区分。 小值（等于或小于1KB）直接存储在DHT上。 对于较大的值，DHT存储引用，这些引用是可以为块提供服务的对等节点的NodeIds。

　　在IPFS中，数据分发通过使用BitTorrent启发式协议与对等方交换块来实现：BitSwap。像BitTorrent一样，BitSwap同伴正在寻找获取一组块（want_list），并有另一组块交换（have_list）。与BitTorrent不同，BitSwap并不局限于一个种子中的块。 BitSwap可以作为一个持久的市场，让节点可以获取他们需要的数据块，而不管这些数据块属于哪个文件。这些块可能来自文件系统中完全不相关的文件。节点聚集在一起，在市场上交换。

　　/ipfs前缀允许以标准挂载点安装到现有系统中而不会发生冲突（挂载点名称当然是可配置的）。 第二个路径组件（IPFS中的第一个路径组件）是对象的哈希。 情况总是如此，因为没有全球根源。 一个根对象在处理分布式（可能是非连接）环境中的数百万个对象的一致性方面是不可能完成的任务。 相反，我们用内容寻址来模拟根。 所有对象总是可以通过它们的散列来访问 请注意，这意味着给定路径 /bar/baz中的三个对象，所有人都可以访问最后一个对象：