IPFS开发者大会记录

上周有幸与@zeckli一起去巴塞罗那参加了IPFS开发者大会。

Matters正在建立一个分布式的作品发布网络，与其他分布式应用一样，核心问题是数据的存储与传输。

IPFS生态中提供了一系列通用的工具和协议，用于建立各种不同类型的分布式应用，使得IPFS成为了许多分布式项目关注的重点。

这次与会的项目种类繁多，比如工厂中的物联网、docker image分布式分发、分布式的npm与Guix、以太坊+IPFS域名管理、分布式身份认证等等。我们也通过世界各地一百多位开发者，一窥分布式技术与生态的进展。

三天的大会中，最开始是几门workshop形式的课程，介绍IPFS的基本结构与用法，让与会者有基本的共识。

IPFS拆分下来，大体可以看做两个子项目， IPLD与libp2p 。

一般通过加密算法验证的系统，数据都会存储在通过哈希算法（hash）构造的树状结构中，被称作哈希树（hash tree，或默克尔树Merkle tree）。 IPLD定义了数据之间相连的通用方式，负责建构、验证及调取哈希树，通用于以太坊、比特币、git等数据结构。

libp2p则是IPFS之外应用最广的一个子项目，从边缘运算到新型的区块链项目，都可以看到它的影子。 libp2p主要负责处理客户端之间通过不同端口和协议相互连接。这一部分原本非常繁琐，而libp2p在不同的协议和算法之上建立了良好的抽象层，极大简化了开发过程，也降低了不同协议之间转换的成本。

除了workshop形式的课程外，三天的大会中有许多lightning talk，简短地介绍不同的分布式项目。此外，还有许多不同形式的分组讨论，以头脑风暴和hackathon的方式，理解或者解决某个具体问题，是与世界各地高手一起协作的好机会。

有一次我参加了DHT （distributed hash table，分布式哈希表）的小组，同组的正好有OpenBazaar的开发者，向其他人很详细地介绍了DHT的运作方式和局限。 DHT是个分布式key-value数据库，也是“分布式”的核心。目前IPFS采用的是Kademlia算法，简单直接、容易实现，但是也有一些问题，比如单个文件访问评率过高会让部分节点过载。 Coral DSHT算法的一些设计可以解决这个问题，也会很快引入到IPFS中。

另一次参加了关于动态数据的讨论，同组的是radicle （一个非常酷的项目！）的开发者和IIT Bombay的CS教授，一起讨论目前IPFS处理动态数据上的局限及可能的改良措施。目前IPFS中的动态数据，主要是通过IPNS提供指针，指向不同的IPFS哈希值，并由IPNS发布者私钥签署验证。但目前IPNS的更新速度非常缓慢。解决IPNS效率问题的一个方案是整合进PubSub机制，目前已经开发完成，还在测试之中。

从很多更有IPFS开发经验的团队那里，我们也了解到了IPFS当前的其他局限，之后的计划与设计中也会更加留心。

一个是网络地址转换（NAT）。当节点在一个内网中时，节点的IP由内网的路由分配，与外部其他节点的联通需要转换IP地址。但是目前IPFS的NAT功能尚不够完善，特别是在需要穿透多层路由时，有时无法连接上其他节点。

另一个问题是内置的匿名机制。节点最后相连仍然需要通过IP地址，所以目前DHT中也是可以看到其他节点的IP的。一种解决思路是通过Tor或者I2P进行传输，与其他暗网一样掩盖用户IP。但是这样的就会牺牲掉传输性能，特别是对于Tor。这一部分的功能开发刚刚开始，但应该比较容易修补和整合。

不过关于匿名机制，葡萄牙的一位开发者开发了p3lib ，提供了另一个思路。 p3lib不是去掩盖IP，而是去混淆不同节点想要获取的数据包。这样监听者虽然能够看到节点的IP，但是无法知道哪个节点获取了什么数据。这个方案目前已经可用了，并且似乎效率不错。

IPFS camp的与会项目中，像Matters这样直接面向普通用户、解决日常问题的项目占极少数。大部分项目仍然很“技术”，要么面向开发者、解决开发过程的问题，要么是从已有的技术出发、畅想能够实现什么。这些项目虽然能够推动分布式技术本身的发展，但是本身很难在市场上立足。

虽然对于每个思考过网络结构的人，都知道分布式网络会带来更好的未来，但是如果分布式网络无法提供中心化网络没有的功能，市场仍然没有动力去完成这个转变。所以在一个unconf环节，我们几个人在一起头脑风暴了一下哪些场景中分布式网络必不可少。

大家都想到最显著的场景是突破信息封锁，及保证信息的保存。比特币的流行和黑市交易以及跨境转账是分不开的，也算需要突破金融机构的封锁。随着各国政治独裁与民族主义的兴起，能够更好保障信息自由和安全的技术会更加重要。 Matters也是因为这个原因决定打造分布式应用。

另一个巨大的应用场景是物联网。这次看到的项目中，数据规模最大的当属Actyx ，用IPFS解决工厂中物联网的问题。因为在工厂中有大量机器相互协作，并且有强烈的电磁场干扰，用中心化的路由和服务器既浪费带宽，又容易被屏蔽。于是这些机器之间直接相连，通过IPFS进行高效快速的互动。

类似的场景还有很多，自动驾驶是快速涌现的一个。自动驾驶的场景中，每一条车流都是一个天然的计算机集群，相互之间需要交流与互动，天然适合形成无线网状网络。这一方面可以降低信号延迟、加快反应速度，另一方面可以节省整个地区所需要的信号带宽、降低开支。虽然中心化架构仍然是大部分工程师最熟悉的方案，但有一些自动驾驶公司已经开始试验分布式网络了。

另一个场景是局域网。分布式网络在没有互联网运营商提供服务时，仍然可以运作。在大规模集会或者突发灾害中，会成为最可靠的信息通道。现在berty等分布式即时通讯项目在通过libp2p搭建这样的网络。 Nodle这样的项目则更进一步，将区块链加入到流量分享之中，等于让物联网中的每个设备都成为了一个微型的互联网提供商。

另一个大家讨论到的问题是，分布式项目如何生存。毕竟，中心化的平台持有了所有的数据与权力，不管是从数据间接获取利润，还是从用户直接获取利润，都相对容易。分布式项目则会难很多，团队如何生存就成了很大的问题。

这次到场的qri项目，为分布式项目的生存提供了一个范例：让软件开源，并保证分布式情况下可用；同时提供付费的中心化服务，用以增加效率，或者提供其他分布式应用本身无法满足的功能。

短短几天下来，我对于IPFS团队的能力和动机有了很多信任。 Protocol Lab集结了一批分布式领域有信仰、有能力的开发者，相信未来的网络该是、也会是分布式的，并联手一步步把这个未来变成现实。

因为Filecoin的成功，IPFS社区已经开始有投机者出现，但总体还是维持了友善和纯粹的技术氛围。 Protocol Lab的团队本身也还没有多少变现的想法，包括Filecoin获得的资金也都依协议锁死在Filecoin本身的开发上。

过去大半年我们在Matters网站上进行的牛刀小试，并未发现太大问题。但是下一步客户端的开发，则一定会触到IPFS的瓶颈，需要更多依赖和参与IPFS社区。 Matters曾与IPFS团队有过初步联系，这次也和IPFS浏览器部分的负责人专门讨论了客户端的计划。他表示，因为IPFS团队对中国的网络环境了解有限，很需要我们来提issue，他也愿意来推动Matters所需要的优化。

这三天初识社区，比较全面地了解了IPFS的进展，也建立了一些联系。客户端的设计、后续与社区的协作，相信也都会因此更加顺利。