【IPFS相关】为什么我们在NuCypher上进行自己的“行星内”节点发现

在过去三个月左右的几乎所有关于分布式网络架构的随意谈话都很快(至少部分)讨论了节点发现 – 通常在6分钟左右。

节点发现再次成为一个大话题。

有两个自然(我认为当下正确)的结论可以从对该主题的兴趣重新抬头中得出：

正在开发分布式应用程序的人认为节点发现很重要。

没有单一的通用节点发现方法可以获得广泛的信心。

当我(在这些早期会话期间)提到我们NuCypher 已经推出了我们自己的节点发现时，我的会话伙伴通常会感兴趣。但有时他们非常吃惊 – 想知道为什么我们不使用devp2p或类似的东西。这件事发生在devcon4，今年我向我的好朋友Piper Merriam描述了我们的“学习循环”，他对这一主题(以及关于人类和平共处的未来)的看法非常有意义。我的估计。

devp2p不是很理想吗?

也许你认为上面的第2点是{lib | dev} p2p的一种分类 – 它不是。libp2p一般(特别是devp2p)是一个很棒的运动，它寻求解决的非常具体的问题具有很好的前景。这篇文章并不意味着至少要嘲笑这项技术!

但devp2p试图解决的问题是，如果我正确理解生态系统，恰当地描述为具有(以及其他)以下属性：

大量节点(为了这篇文章的目的，我将使用20,000作为高和低数字之间的区别)

节点难以预测的推出速度

拜占庭容错的外化解决方案，如IPFS与Merkle DAG和以太坊一起做的工作证明(以及宁静，证据证明)

用于崩溃容错的外部化解决方案，如IPFS，支持分布式固定，以太网支持完整节点(以及Serenity，分片)

(在大多数情况下……)所讨论的节点以及它们适合的应用程序至少部分地由高带宽和高等待时间表征。

这是对世界上许多最酷项目的一个很好的描述，当然包括IPFS。当我第一次听到“星际文件系统”这个短语时，我立即*理解了问题空间。这是一个非凡项目的完美名称。

因此，我们将上述现象称为“星际网络”。

正如您可能已经预测的那样，我的断言是libp2p(因此devp2p)不是*通用*解决方案，而是特定于星际网络。

devp2p的基本协议基本上是Kademlia(DHT)。

当我们首次在我们的代理重加密网络上破土动工时，我们的想象力将Kademlia插入到几乎每个NuCypher需求中。当我们遇到这种令人头疼的问题时，我们开始向Brian Muller开放了对Kademlia的流行Python实现的拉请求，称为(小k)kademlia  - 这样做，有机会反复与Muller互动，谁是一个非常运动的开源维护者，并且几乎合并了我们所有的PR。

决定留在一个星球上

经过几轮迭代式处理(小-k)kademlia(以及devp2p的简短实现，只是意识到它完全相同)，我们就意识到了一个令人沮丧的实现：

与许多新兴的分散技术一样，我们的网络本质上不是星际的。

我说“起初压抑”因为我们不仅受到IPFS(拓扑隐喻及其功能集)的深刻启发，而且我们也看到(并继续观察)NuCypher作为IPFS的理想匹配，两者都在一起结合使用具有访问管理和隐私功能的分布式文件系统，超出任何集中式系统可用的功能。

(我们都希望成为星际的，对吧?)

建立分散的访问管理已经教给我们一些东西(这是这篇文章的精髓，至少对我而言)：星际联盟(如IPFS)需要行星内支持系统才能真正令人兴奋(并且真正分散)。

(让我说明“行星” – 无论是“内部”还是“内部”比喻 – 并不意味着节点确实(甚至可以)在不同的行星上工作。这只是一种思考风格的方式。对这两种范式有意义的稳健性和效率。)

行星内范式

由于我已经给出了上述“星际”的一些关键特征，我现在将给出我们网络的一些属性，我认为这些属性是“行星内”：

少量节点(可能少于5,000个，可能少得多)

对于节点运营商和应用程序开发人员而言，这是一个合理可预测的部署

协议中的拜占庭和崩溃容错，使用区块链数据但不使用区块链节点作为传输

节点发现是一种完整的，而不是用螺栓固定的机制

需要低带宽; 期望的低延迟

这种范例的缺点是显而易见的：像IPFS这样的东西不能轻易地在这种节点发现风格上构建。

但是，优点很大：

节点可能会在第一次迭代时(即，在引导时)了解他们需要知道的每个节点。分片，汉明距离和覆盖拓扑引入的复杂性消失了。

“欺骗”节点(即那些声称自己不是某些人的节点)从未在第一时间传播。

节点可以彼此共享(并用作协议的基础)网络的“全貌”，并且知道一旦拥有它就停止尝试学习。

一切都是TLS，不需要CA或其他权限 – 没有人可以声称在没有由她的钱包地址签名的证书的情况下运行节点。

此外，行星内网络对“星系”中其他地方的问题具有很强的鲁棒性。对于行星内网络，使用devp2p和基于以太坊的节点发现感觉就像通过火星上的蜂窝塔呼唤你的母亲一样。

一旦我们意识到这一点，很快就会发现我们只希望区块链用于我们节点发现的拜占庭容错方面，并且我们不想依赖区块链节点进行传输。

那么现有的行星内解决方案呢?

我不知道任何先前的协议或实现明确地将自己称为“行星内行星”，但有一些可能合理的资格 – PING，SWIM，Smudge，Gossip – 我相信还有其他人。

在这一点上，也许我已经说服你，行星内解决方案对于某个问题空间是有利的。也许我已经说服你Kademlia / devp2p，尽管它们很棒，但并没有完全解决这个问题。

在这些现有的解决方案中，我们最接近选择Gossip，因此我将概述我们没有这样做的原因：

我们仍然需要推出自己的验证方案来集成基于令牌的拜占庭容错。使用基于整数令牌的方案没有明显的方法来阻止传播。这就是我们需要的全部原因。

python实现是想要的; 它只有2个提交，虽然看似很好，但直接使用套接字和多处理库，而不是提供其他好的地方来挂钩。

由于节点发现是我们网络的核心功能，我们不希望强迫人们运行NuCypher进程以外的任何东西，除了区块链节点(即我们不想运行Apache Gossip)。没有现成的八卦解决方案，不需要我们大幅增加我们的旋转高度。

尽管存在这些问题，但学习循环仍有可能最终完全实现Gossip。

我们解决了什么

到目前为止，我们只调用了我们的解决方案，它(目前)与NuCypher代码库紧密耦合，即“学习循环”。

它基于Twisted(我并不羞于描述为我使用过的最高质量的开源项目)和hendrix，其核心开发人员包括我自己和NuCypherino Kieran Prasch。

我们只投入了大约4天的工作时间(以及更多关于修饰的工作)，所以它更像是原型而不是最终解决方案。尽管如此，它正在为我们当前的测试网络提供动力，而且似乎正在踢屁股。

tl; dr – 这是节点发现在NuCypher中的工作原理：

智能合约列出了一些“种子节点” – 由(钱包地址，主机和端口)组成的三元组 – 我们将其称为“播种者”合同。

为了引导，节点或用户(在我们的说法中称为“ 学习者 ”)选择一个已知节点，将其视为“教师”。它可以是但不一定是播种机合同中列出的节点之一。

学习者首先检查以确保教师首先确定足够的NU作为NuCypher节点。

学习者连接到教师并检索其TLS证书。

使用此(迄今未验证的)证书，学习者与教师建立TLS连接并请求验证元数据。

教师提供签名，表明其已使用其钱包密钥对签署了TLS证书。这是我们基于令牌的积分拜占庭容错。它还提供网络上所有已知节点的列表，包括由每个节点的钱包密钥对签名的TLS证书。

学习者继续每5秒检查一次新节点(进行一些优化以防止必须再次下载整个列表)。

在没有学习新节点的情况下经过10轮之后，循环减慢，因此学习仅每90秒发生一次(如果发现新节点则再次加速)。