IPFS家族（一）

IPFS这个项目其实很大，并不像大家想象的是一个东西，IPFS是由很多模块组成，每一个模块现在都已经独立成项目了，并且有自己的主页。让我们来简单看一下IPFS家族成员。

协议实验室的主页：https://protocol.ai/projects/

在协议实验室的主页上面，可以找到目前的五个个项目：

IPFS：ipfs.io

Filecoin: filecoin.io

libp2p: libp2p.io

IPLD：ipld.io

Multiformats：multiformats.io

(协议实验室的是有多喜欢io的域名)

其中IPFS和FIlecoin我们已近很熟悉了，也是我们主角（男一号和女一号），今天主要介绍那些背后默默无闻的支持者。

先放一张IPFS的结构图

libp2p

IPFS团队在开发IPFS协议的时候，采用的是高度模块化的方式进行的。就像搭积木一样，将各个功能独立独立起来进行。当然这也是现在软件工程里面的基本要求，不过IPFS团队在此基础上更进一步，各个木块之间几乎完全解耦合。

libp2p是什么？

在过去的相当长时间里，开发者构建一个p2p网络并不是一件容易的事情。复杂的网络环境、各种各样的通信协议和网络设备的存在使得创建大规模的点对点网络变得复杂并且困难。IPFS团队将点对点(peer-to-peer)网络的网络层从IPFS工程里面分离出来，形成一个独立的项目，这就是libp2p。该项目不仅可以供IPFS使用，也可以提供其它项目使用，作为一个p2p工程的底层协议存在。

之前的文章里面曾经提到过IPFS的网络连通性做的非常棒，在各种复杂的网络环境下都能够轻松应对，这与IPFS团队在libp2p上面的精心设计是分不开的。

如果哪个团队或者开发者想构建一个基于p2p网络的项目，不妨参考一下或者直接使用libp2p作为底层协议，会减少很多很多的开发量(发现了什么？如今如火如荼的区块链项目，有了libp2p，可以为大家节省很多工作量，当然，因为fork的存在，现在的项目大多数并不是从0开始的)。

下面我们来看看libp2p里面都有什么东东？

Transports：传输层，TCP，uTP，QUIC，SCTP......

Discovery：网络发现层，mDNS，bootstrap，DNS，Kad......

Peer Routing: 节点路由，mDNS, KadDHT......

NAT Traversal: NAT穿越层......

Content Routing: 内容寻址......

libp2p的主要功能是

发现节点

连接节点

发现数据

传输数据

它类似我们现实世界的快递公司。它连接着千千万万个节点，除了负责分发数据，还负责查找数据。它是一个大杂烩，综合了各种协议、框架，让它们一起和谐的工作。

当前实现版本：

js

go

IPLD

IPLD定义了基于内容寻址的统一数据结构类型。它是一个转换器，可以把现有的异构的数据结构（基于内容寻址）统一成一种格式，方便不同系统之间的数据交换和互操作。

为什么要构建IPLD？

通过哈希进行内容寻址的技术已经广泛应用于各种分布式系统。从加密货币的区块链到备份代码的每一次提交，再到各种web内容，他们背后的逻辑几乎是相同的， 然后由于数据结构的不兼容，造成了这些数据无法互相操作。IPLD作为中间层统一了这些异构的数据结构，使得不同的数据可以进行数据交换。

IPLD的组成：

CID（Self-describing content-addressed identifiers for distributed systems）：基于内容寻址的自我描述标识

IPLD tree：基于 JSON、Protobuf和路径导航的跨协议的数据模型

IPLD Resolvers: IPLD转换器，可以添加新的协议到IPLD里面

当前已实现的IPLD数据结构

Git

Bitcoin

Ethereum

IPFS

未来会有更多的数据结构添加进来，第三方的开发也可以把自己的数据结构提交到IPLD里面。截止到目前，IPLD在github上的关注度并不像是IPFS那么引人注目。不过相信随着IPFS应用推进，IPLD项目也会也来越多的收到关注。至少它几乎可以统一目前区块链项目的绝大部分数据。作为一个中间层可以很方便的进行链之间的数据交换，IPFS团队已经帮大家造好了轮子。

Multiformats

该项目的是一系列协议的集合，它在现有协议基础上对值（值：通常是具有某一项表达意义的）进行自我描述改造，即从值上就可以知道该值是如何产生的。听起来是不是有点难以理解，别着急，下面咱们使用具体的例子来说明这是一个什么东西。

当前multiformats协议里面包含以下协议。

multihash - self-describing hashes

multiaddr - self-describing network addresses

multibase - self-describing base encodings

multicodec - self-describing serialization

multistream - self-describing stream network protocols

multigram (WIP) - self-describing packet network protocols

我们以第一个multihash为例子来说明什么是multiformats。通常情况下我们使用的哈希计算方法都是某一种实现方式，比如sha1，sha2-256等。哈希计算在我们的软件工程里面几乎随处可见，特别是区块链项目。multiformats将所有的哈希值计算统一成同样的格式，这会为系统开发者带来很多好处，比如加密函数升级等。

multihash:

升级后的哈希值的结构为：

我们有一个使用sha2-256函数生成的哈希值（如下），其长度为32（16进制0x20）：

41dd7b6443542e75701aa98a0c235951a28a0d851b11564d20022ab11d2589a8

规定sha2-256的代表数字为12(16进制)

于是我们得出来新的哈希值：

122041dd7b6443542e75701aa98a0c235951a28a0d851b11564d20022ab11d2589a8

新的哈希值具有自我描述性质，它说明了自己是怎么来的。怎么样，是不是一下子变得开朗起来。

小编把python版本的multihash实现撸了一遍，目前multihash总共实现了以下6种哈希函数，建议以后的开发者使用这个升级版的哈希加密算法，好处多多：

sha1

sha2-256

sha2-512

sha3

blake2b

blake2s

其它几个multi协议就不在一一介绍，感兴趣的读者可以到以下页面学习

https://multiformats.io/

https://github.com/multiformats/multiformats

未完待续。。。。。。

想参与讨论的读者可以在公众号回复：联系方式，或者直接点击菜单里面的 联系作者