Coordicide更新 — Autopeering(第二篇)
引言
在上一篇博客文章中,我们与您分享了IOTA研究团队对当前自动对等(autopeering)模型的模拟器,以及一些早期的结果。在本系列的第2部分中,我们的目标是让您对 autopeering 算法及其功能有一个清晰的认识。
首先,为什么一定程度的随机性对自动对等很重要?粗略地说,如果一个新节点连接到另一个被邻居广播(gossip)的节点,那么前一个节点接收到的信息将与后一个节点接收到的信息非常相似。这就形成了一种回音室。而且,随着这种网络的增长,攻击者可以通过向新来者广播大量自己的节点来欺骗屏蔽选定的区域。
所以我们的目标是实现一个算法,它能实现以下特性:
1)良好的拓扑特性(即,与节点排列有关的属性),以使建立在其上的投票机制具有良好的收敛性。
2)恶意攻击者成功攻击的可能性微乎其微。
为了做到这一点,我们引入了一种结合了三个不同变量的算法;一个是可验证的,一个是不可预测的,最后一个是与某些稀缺的东西有关的。
autopeering算法
在这里,我们将解释在节点发现已经完成之后,autopeering过程是如何发生的,因为它是在已经共享的模拟器中建模的。每个节点都被设置为:
1)拥有一个公共节点id(一个32字节的字符串)
2)拥有一个公共盐salt(一个20字节的字符串)
3)一个私有盐salt(一个20字节的字符串)
我们定义节点A和B之间的请求距离为:
d_req(A,B) = hash(node_id(A)) XOR hash(node_id(B)+pub_salt(A))
要想请求一个新连接,节点A将计算它所知道的所有节点的“距离”d_req(A,B),并按此距离对节点进行排序。在此之后,节点将从最近的节点到最远的节点开始请求,直到被其他节点接受并建立了k个连接。
我们还定义节点A与B之间的接受距离为:
d_acc(A,B) = hash(node_id(A)) XOR hash(node_id(B)+priv_salt(A))
节点A将在以下情形下在任何时候都会接受来自节点B的请求
1) 它只接受了不到k个请求
或者
2) d_acc(A,B)小于与他的一个被接受的对等点之间的接受距离。在这种情况下,节点A将放弃到其最远接受节点的连接。
节点将定期地改变它们的盐并更新所有的距离。请注意,每个节点的目标是有2k个连接,k通过主动请求其他节点建立,k通过被动接受其他节点的请求建立。
这个算法如何防止攻击?
首先,让我们关注公共/私人盐计划。请求的距离只取决于公共信息。这样,节点可以通过计算距离是否有适当的数量级来验证某个请求是否可以接收,这已经使攻击者的工作变得更困难了,因为现在他必须“生成”一个公共盐,这个盐会将他定位到距离他想要隐藏的节点足够近的位置。此外,如果使用哈希链生成“盐”,节点将自己提交给一个很长的“盐”序列,使得成功的攻击几乎不可能持续很长时间。
现在,由于接受程度取决于只有目标才知道的变量(私有盐),所以攻击者是否与目标建立连接对于攻击者来说是完全不可预测的。这将进一步缩小恶意部分的可能策略,在实践中,在不同的节点之间进行尝试和报错攻击会是唯一可能的策略。这就引出了系统的最后一个组成部分:法力Mana。如果我们用法力值的差异来衡量上述定义的距离,算法将在法力值相同的节点之间建立连接。这样,由于法力被设计为一种稀缺资源,没有攻击者会有足够的法力来尝试这种对参与节点(非零法力)的试错攻击。这使得我们的autopeering机制成为主流分布式账本技术中最有前途的随机化、自动化、不容易被操纵的、对等的算法。
我们希望你喜欢这个关于autopeering模型的系列文章!一如既往,我们欢迎任何提问和评论,无论是在这里还是在我们的Discord服务器。
*备注:该机制在模拟器中尚未实现。
原文链接:https://blog.iota.org/coordicide-update-autopeering-part-2-4e462ba68bd