链正集团矿金所讲解IPFS底层基础原理

链正集团是一家以战略投资为目标的大型专业性投资集团，总部设立于中国广州。集团成立至今分支机构已遍布国内外，历经多年发展始终秉承“ 链天下之商 · 正百业之气”的宏伟使命持续深耕，并成功投资运营：数字矿业、链正实业、链正投资、链正商服、链正教育等一批新兴产业；依托领先的科研创新技术，宏厚的资本运作实力，严谨的风险管控系统，强大的资源整合能力和成熟的市场运营经验，从而实现赋能百业的“链正梦”！当下有为，未来可期，链正人将持续以高度的社会责任感、诚信共赢的经营理念与社会各界精诚合作，开拓进取，共创未来！

IPFS底层基础

这一章的内容相对较多，也相对独立。你可以选择先阅读这一章，了解这几个基础性系统的设计思路和算法细节;或者暂时跳过这一章，直接去了解IPFS系统设计。在这一章中，我们会着重介绍IPFS的几个基础性的子系统和数据结构，包括DHT、BitTorrent、Git和自验证文件系统，以及Merkle结构。

分布式哈希表(DHT)

第1代P2P文件网络需要中央数据库协调，例如在2000年前后风靡一时的音乐文件分享系统Napster。在Napster中，使用一个中心服务器接收所有的查询，服务器会向客户端返回其所需要的数据地址列表。这样的设计容易导致单点失效，甚至导致整个网络瘫痪。在第2代分布式文件系统中，Gnutella使用消息洪泛方法(messageflooding）来定位数据。查询消息会公布给全网所有的节点，直到找到这个信息，然后返回给查询者。当然，由于网络承载力有限，这种盲目的请求会导致网络快速耗尽，因此需要设置请求的生存时间以控制网络内请求的数量。但无论如何，这种方式所需的网络请求量非常大，很容易造成拥堵。到了第3代分布式文件系统中，DHT的创新提供了新的解决方案。DHT (Distributed Hash Table)主要思想如下:全网维护一个巨大的文件索引哈希表，这个哈希表的条目形如<Key,Value>。这里Key通常是文件的某个哈希算法下的哈希值(也可以是文件名或者文件内容描述)，而Value则是存储文件的IP地址。查询时，仅需要提供Key，就能从表中查询到存储节点的地址并返回给查询节点。当然，这个哈希表会被分割成小块，按照一定的算法和规则分布到全网各个节点上。每个节点仅需要维护一小块哈希表。这样，节点查询文件时，只要把查询报文路由到相应的节点即可。下面介绍3种IPFS引用过的有代表性的分区表类型，分别是Kademlia DHT、Coral DHT和S/Kademlia。

Kademlia DHT

Kademlia DHT是分布式哈希表的一种实现，它的发明人是PetarMaymounkov和David Mazieres。Kademlia DHT拥有一些很好的特性，如下:

节点ID与关键字是同样的值域，都是使用SHA-1算法生成的160位摘要，这样大大简化了查询时的信息量，更便于查询。

可以使用XOR，计算任意两个节点的距离或节点和关键字的距离。

查找—条请求路径的时候，每个节点的信息是完备的，只需要进行Log(n)量级次跳转。

可根据查询速度和存储量的需求调整每个节点需要维护的DHT大小。

KAD网络对之前我们说的DHT有较大的改进，一个新来的网络节点在初次连接网络时会被分配一个ID;每个节点自身维护一个路由表和一个DHT，这个路由表保存网络中一部分节点的连接信息，DHT用于存放文件信息;每个节点优先保存距离自己更近的节点信息，但一定确保距离在[2n-2(n+1)-1]的全部节点至少保存k个(k是常数)，我们称作K-Bucket;每个网络节点需要优先存储与自己的ID距离较小的文件;每次检索时，计算查询文件的哈希值与自己的ID的距离，然后找到与这个距离对应的K-Bucket，向K-Bucket中的节点查询，接受查询的节点也做同样的检查，如果发现自己存有这个数据，便将其返回给查询的节点。

下次更新我们详细说明一下KAD网络算法细节。

本文内容来源于《IPFS原理与实践》，文章仅科普，不构成投资建议。

—-

编译者/作者：深圳链正集团陈佳

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。