Coordicide更新 — Autopeering(第一篇)

​​Autopeering(节点自动互连)模块

几个月前,我们开发了GoShimmer的源代码,这是IOTA的原型和研究工具,用于实验和测试Coordicide(IOTA的去协调器计划)的构建块。我们很高兴得到社区大量的、和富有成效的参与,对此我们向所有人的贡献和反馈表示感谢!这对于改进GoShimmer和帮助我们更好地重新设计autopeering模块非常有用。

我们很高兴与您分享经过改进的重新设计的autopeering模块的源代码。你可以从以下代码库取得有关的代码:https://github.com/iotaledger/autopeering-sim

背景

在IOTA协议中,节点(或对等节点)是存储Tangle (IOTA的底层数据结构)相关信息的单元。节点通常也是访问和使用Tangle网络的入口点。为了使网络有效地工作,节点之间互相交换信息以保持关于新的账本状态的最新信息。目前,节点之间采用人工配对或连接的方式相互注册为邻居。然而,人工配对可能会受到攻击(例如,社会工程方法),从而影响网络拓扑。为了防止这些攻击,并简化新节点的设置过程,我们在Coordicide白皮书中介绍了一种允许节点自动选择其邻居的机制。在没有节点操作员手动干预的情况下,节点选择其邻居的过程称为autopeering(节点自动互连)

autopeering模块重新设计的目的是在保持GoShimmer中使用的代码库不变的同时能简化模拟。通过模拟来评估自动配对行为和性能对IOTA来说非常重要。它能帮助我们分析和解决很多问题,比如每个节点在被接受之前平均要发送多少配对请求,连接将持续多长时间,协议收敛的速度有多快等等。这将为研究在被控制的环境下的攻击向量奠定基础。

设计

我们在逻辑上将autopeering模块划分为两个主要的子模块:peer discovery(节点发现)neighbor selection(邻居选择)。前者负责发现新的配对并验证他们的在线状态等操作。后者负责为IOTA的节点查找和管理邻居。我们还通过使用Go接口封装了网络层(P2P通信)和存储层(持久化对等信息)。你可以看到一个高层次的设计概述,如下图:

通过这种设计,可以很容易地从数据库切换到更轻量级的内存存储,并从服务器之间的连接切换到进程间的通信。GoShimmer需要服务器和数据库。通过替换它们,将使编写在一台计算机上运行的高效模拟跟编写几行代码一样简单。

模拟

我们已经编写了一个模拟程序来进行展示,其重点在于“邻居选择”子模块。在模拟中,我们假设通过“节点发现”可以知道网络中的所有节点,以便能够单独评估配对选择的效果。具有部分网络视图的场景以及“配对发现”的性能将是进一步模拟和分析的主题。

邻居的选择,特别是决定哪些潜在的邻居是更优的,将决定于他们之间的距离。这个距离函数基于Coordicide白皮书中定义的私有和公共盐(salt)。下一步,我们将实现这个mana机制依赖的距离机制。

目前,仿真可以配置以下参数:

  • N:节点总数
  • T:盐的寿命,以秒为单位;
  • SimDuration:模拟的持续时间,以秒为单位;
  • VisualEnabled:在开始模拟后,通过访问http://localhost:8844来设置的模拟可视化工具的启动/停止开关,
  • dropAll:每次salt更新时删除所有邻居的启动/停止开关,

在运行模拟时,启用可视化工具,会记录动画。它为我们提供了一个很好的对等过程的可视化展示。


新建立的对等点之间的链接用蓝色突出显示,请求和接受对等点分别用蓝色和绿色显示。被删除的链接用红色突出显示。

指标和评估

目前,我们提供了评估脚本来让模拟器支持以下指标:

  • Convergence(收敛性):拥有最多邻居的对等点的比例;
  • Link survival time(链接存活时间):给定的链接在一定时间后仍然处于活动状态的概率;
  • Message analysis(消息分析):统计发送和接收的消息数量(对等请求、对等响应和连接中断)。

我们还包括一个评估脚本plot.py,它用Python和Matplotlib编写。该脚本从模拟代码生成的CSV-output文件中提取数据,并生成收敛和链接生存时间的图形。

例如,从下面的图中可以看到:a)有8个邻居的节点的百分比(在这个配置中8是邻居的最大数量)和一段时间内邻居的平均数量;b)某个链接持续一定时间的概率。

此外,运行模拟将生成一个包含消息分析数据的CSV文件(在datafolder目录中)。你可以在下面的表格中看到一个例子:

在这里,对等请求的平均发送数量(OUTgoing)等于对等请求的平均接收数量(INcoming)。我们就可以很容易地计算出在接受请求(ACCepted)之前发送的对等请求的平均数量:只需将发出的请求除以接受的请求。也就是说,在本例中,9.17 / 7.03 = 1.3。我们还可以提取关于连接丢弃(DROPped)率的信息:在本例中,平均每9.17 / 3.03 = 3.02 条传入消息替换一个对等点。

我们将继续开发更多的“配对发现”和“邻居选择”的模拟,并将它们添加到代码库中!我们还有一个目标,就是最终将模拟中的代码移植到GoShimmer中。由于autopeering和GoShimmer的灵活性和模块化,这将只需要很少的修改就可以实现。如果这个挑战听起来很有趣,那么非常欢迎您帮助IOTA来进行集成!此外,我们正在评估将autopeering集成到当前IOTA协议(包含协调器)的可能性,作为官方主网的一系列改进中的一部分。

在autopeering博客系列文章的下一部分中,我们将深入探讨这个模块的内部工作机制。同时,我们希望这段代码对任何对分析autopeering模块感兴趣的人都有用。欢迎您贡献新的特性的代码!或者,您可以运行模拟并提供反馈,您还可以查看我们的Coordicide资助计划的公开联络方式,以了解更多的合作机会。

一如既往,我们欢迎您在这里或IOTA的官方Discord服务器#tanglemath或#goshimmerl-discussion频道发表评论和提问。

原文地址:https://blog.iota.org/coordicide-update-autopeering-part-1-fc72e21c7e11​​​​

大熊

专栏作者:大熊

个人简介:我共发表了 39 篇文章,总计被阅读了12,768 次,共获得了 449 个赞。

作者邮箱 作者主页 Ta的文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注