作者:dean
翻译&校对:裴奇&阿剑
来源：以太坊爱好者
如果你一直在研究以太坊或者相关的技术，你可能听说过discv4或discv5。但这些究竟是什么呢？它们是如何工作的呢？它们出众的地方在哪里呢？想要回答这些问题，我们需要从头开始梳理一下。这篇博文假定读者对这个领域比较陌生，因此没有技术背景的人也可以阅读。
开篇
故事的开端：在P2P网络中，节点的相互发现及网络成型的过程会面临一些问题。
早年间的P2P文件共享技术，比如Napster，使用单个服务器共享信息，信息中记录谁拥有什么文件。某个节点向中心服务器发起连接并提交记录自己所拥有文件的列表。另一个节点之后向同一个中心服务器发起连接，寻找自己所需文件的存储节点，然后和找到的节点建立联系。然而这是一个有缺陷的系统——系统很容易遭受攻击，而且中心化服务器节点可能会吃官司。
因此，点对点网络亟需另一种解决方案。研究者们经过数年研究和实验，提出了分布式哈希表。
分布式哈希表
2001年，研究者们为DHT提出了4种新的协议，分别是Tapestry、Chord、CAN以及Pastr，这4个协议在核心功能上各有取舍和改变，因此拥有不同的特性。
上文中一直都在说DHT。那么DHT到底是什么呢？
分布式哈希表是一个分布式的键值列表。参与到DHT的节点可以很轻松地检索到某个键对应的值。
假定一个网络中，有9个键值对和3个节点，理想情况下，每个节点只需要存储3个键值对，意味着如果要更新某个键值对，只有部分网络节点需要更新。大致想法是这样的，网络中的任何节点都可以基于信息在节点间分布的方式，知道要去哪里寻找它所需要的特定键值对。
Kademlia
现在我们知道DHT是什么了，那我们来看看discv4的前身Kademlia。Kademlia是PetarMaymounkov和DavidMazières于2002年发明的DHT协议。我觉得这个协议可能是最流行，而且使用最广泛的DHT协议。它的工作原理很简单，让我们来看看吧。
在Kademlia中，节点和值通过距离来排列。这里的距离不是地理位置上的距离，而是基于标识符的表示方法。通过使用一些距离函数，可以计算出两个标识符之间的距离。
Kademlia使用XOR作为距离函数。XOR函数的特点在于，只有当输入不同时，输出才为true。下面是用二进制标识符表示的例子。
上面的这个例子是说，十进制数字153和50之间的距离是171。
使用XOR作为距离函数有很多原因，包括：
某个ID与它自己的距离是0。
距离是对称的，A到B的距离和B到A的距离相同。
遵循三角不等式，如果A，B，C是三角形上的三点，那么A到B的距离，小于或等于A到C的距离加上B到C的距离。
综上，节点可以根据距离函数来确定哪个节点离它更近，并基于这种“距离”来做决策。
Kademlia节点存储着一个路由表。路由表中包含多个列表。每后一个列表所记载的节点都比前一个列表中的节点离得远一点。每个节点维护离自己最近节点的信息；另一个节点离得越远，本地节点保存的相关信息就越少。
假定我想要找到一个特定的节点。我要做的就是向我已知的节点发送请求，这些节点返回他们的记录中离我的目标节点更近的邻居节点。我重复此过程，直到某群邻居帮我找到目标节点。
对值来说也是同样的过程。值跟节点之间的距离是确定的，因为值和节点的标识符ID以相同的方式组织，因此我们可以计算这个距离。如果我想查找一个值，我只需要寻找离这个值的键最近的邻居节点，直到找到存储这个值的节点。
为了让Kademlia节点支持这些功能，协议通过下面这些消息来通信。
PING-用来检测一个节点是否还在运行。
STORE-在一个节点上存储给定键的值。
FINDNODE-向给定ID返回所请求的最近节点。
FINDVALUE-和FINDNODE一样，区别在于，如果一个节点存储着特定的值，它将会直接将值返回。
这是对Kademlia的一个非常简化的讲解，中间跳过了各种重要的细节。想要更全面的了解，力荐原论文或者更深层次的设计规范。
Discv4
对背景做好铺垫之后，终于来到discv4了，这是以太坊当前的节点发现协议。Discv4协议本身是基于Kademlia的，但在某些部分做了改动。例如，discv4中不再使用DHT中的值部分。
Kademlia主要用于网络的组织，因此我们可以使用路由表定位其他节点。但discv4中完全不使用DHT中的值部分，因此我们可以抛弃Kademlia中使用的命令FINDVALUE和STORE。
前文中，Kademlia的查询方法描述了节点如何得到对等节点。节点向另一些节点发起请求，得到离自己更近的节点。重复此请求过程，直到无法找到任何新的节点。
此外，discv4添加了相互的终端验证功能。这是为了确保发起FINDNODE请求的节点正在参与同一个节点发现协议。
最后，所有的discv4节点都应该维护最新的ENR记录。记录里包含一个节点的信息。任何节点都可以使用特定于discv4的包，叫做ENRRequest，去请求ENR记录。
如果你想知道关于ENRs的更多细节，请移步至我的另一篇博文NetworkAddressesinEthereum。
然而，discv4也引入了一些问题。让我们来看看其中的几个。
首先，按照discv4目前的工作方式，是无法区分节点间的次级协议的。也就是说，如果一个以太坊节点将以太坊Classic节点，Swarm或Whisper节点加入它的DHT，那么只有和这些节点发生多次通信之后，才能发现这些节点的无效性。这种无法区分次级协议的能力使得它很难找到特定的节点，比如支持轻客户端的以太坊节点。
其次，为了防御重放攻击，discv4使用了时间戳。当某个主机的时钟发生错误时，这种方式会导致各种各样的问题。欲了解更多详情，请查阅discv4规范的“KnownIssues”部分。
最后，终端的互验证工作中也存在问题。因为信息有丢包的可能，所以没有办法断定两个对等节点是否都已验证过对方。也就是说，我们可能自认为已经被验证过了，但跟我们通信的对等节点却并不这么认为；他们可能会因此丢弃我们的FINDNODE包。
Discv5
最后，让我们来看一下discv5。Discv5是discv4的迭代版本，将作为Eth2.0的节点发现协议。Discv5旨在修复discv4中存在的诸多问题。
第一个改变是FINDNODE的工作方式。传统的Kademlia以及discv5都使用标识符。而在discv5中，我们使用对数距离，也就是说，发送FINDNODE请求后，响应中包含的节点，都与发送方节点在特定的对数距离内。
对数距离指：先计算出距离，然后使用以2为底数的log函数，即log2(AxorB)。
其次一个很重要的改变就是discv5一直致力于解决的，存在于discv4的最大问题：次级协议的区分。Discv5添加了主题表。主题表是先进先出的列表，表中包含提供特定服务的节点。节点通过在对等节点中注册广告将自己添加进这个列表。
截至本文写作之时，这个次级协议区分方案中的写操作依然存在一些问题。对一个节点来说，目前没有有效的方法将广告发布在多个对等节点上，因此需要向每个对等节点发送单独的请求，这对于大规模网络来说效率很低。
此外，一个节点向多少个对等节点上发布广告，以及向哪些对等节点投放都是不清楚的。更多详情请查阅devp2p#136。
Discv5中还有很多小的改变，但是这些改变没那么重要，因此在这篇总结中就省略了。
虽然discv5解决了一些discv4中存在的问题，但还有一些问题，discv5仍没有解决，比如不可靠的终端验证。写这篇博文之时，discv5还没有提出新的方法去提升终端验证的处理过程。
正如你所见，discv5的工作仍在进行中，目前还需要克服一些很大的挑战。如果这个协议解决了这些问题，那么它将会是对原始Kademlia实现的一个巨大提升。
希望这篇文章能帮助你理解什么是发现协议以及发现协议是如何工作的。如果你对整个协议感兴趣，可以在github上查阅。
原文链接:?https://vac.dev/kademlia-to-discv5
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。