Medalla 测试网网络动荡始末,Part-2-区块链毕设资料

这是qklbishe.com第4286 篇区块链毕业设计资料
提供毕设资料分析,通过本文《Medalla 测试网网络动荡始末,Part-2-区块链毕设资料》可以理解其中的代码原理,这是一篇很好的区块链代码论文资料

引介

Medalla 测试网网络动荡始末,Part-2

Ajian   |     |   36 次阅读

引介 Eth2

Medalla 测试网网络动荡始末,Part-1


编者注:北京时间 2020 年 8 月 20 日晚上,Medalla 测试网从肇始于 8 月 15 日的网络动荡中恢复,重新获得终局性。

但我们的探究,还不能止步。

第三份材料,来自 Lighthouse 客户端团队的常规更新日志。在这份日志中,Lighthouse 团队含蓄地承认,在网络动荡期间,因为网络长期无法获得终局性,Lighthouse 客户端出现了内存占用过高的问题。

Lighthouse 更新 #28(节选)

(……)

Medalla 测试网

在上次更新之后,Medalla 公开多客户端测试网已经启动。已有超过 20,000 个验证者和至少 5 个不同的客户端实现在上面运行。

测试网启动初期比较艰难,因为大量质押者在创始期间掉线。这就导致参与率低于预期。很快,许多质押者加入,测试网开始获得终局性,且运行得相当顺利。在过去几周时间里,我们有机会在这个测试网上进行了大量的客户端互操作性测试和性能调整。

见证消息的打包

在 Medalla 测试网上,我们观察到的主要问题之一是见证消息被打包的比率。每个验证者必须在每个时段(epoch)内产生一条见证消息。这些见证消息将被打包进未来的区块中,而一旦被打包,与该见证消息关联的验证者就会得到奖励。虽然在一个只有 lighthouse 客户端的 Medalla 测试网中,我们看到了 100% 的见证消息打包率(即所有产生的见证消息都被打包进了区块中),但是一些见证消息被跳过了(没有被打包进未来的第一个区块中)。想要解决这一问题绝非易事,因为这个过程有点复杂,且听我细细道来。

在每个时段内,验证者都会被分成不同的委员会。委员会中的每个验证者都必须将他们的见证消息发布到一个(与所属委员会相关的)特定的 gossipsub 子网内。在委员会的所有验证者中,需要有个伪随机的验证者子集(大约 16 个)来收集并聚合所有的见证消息。然后,这些 “聚合者” 将聚合过的见证消息发布到一个全局性的 “聚合” gossipsub 通道中。这使得区块提议者只需订阅 “聚合” 通道就够了,因此他们只需关注按每个委员会的被组合过的见证消息,而无需关注所有验证者发布在 gossipsub 子网内的见证消息。然后,区块提议者会选择能使其利润最大化的聚合见证消息并将这些见证消息打包它所提议的区块里。

此过程中许多地方都有可能出现故障,进而阻止验证者的见证消息被打包进区块中。首先,客户端节点需要找到同样订阅了所需子网的其他对等节点。如果不存在这样的对等节点,那么它发布的见证消息就无法传播,更不可能进行任何被打包进区块中的步骤。如果客户端已经找到了足够多的对等节点,接下来就要依赖于子网中的 “聚合者” 首先从 gosispsub 子网中接收并聚合节点的见证消息。聚合者的客户端实现可能有所不同,也有可能不认同它们在子网上收到的见证消息。在这里,客户端之间传播见证消息的时间也很重要,要确保在聚合者聚合见证消息之前送达见证消息。然后,聚合者必须将见证消息发布到全局 “聚合” 通道内。(在见证消息所发布的时段内的)区块生产者必须关注聚合者发布的见证消息并决定是否将这些消息包含在其区块中。最后两个步骤可以由网络上的任何节点完成,这部分的挑战在于让所有客户端实现在整个流程中协调一致地工作。

这就是我们团队(我相信也是其他客户端实现团队)的目标 —— 让我们所有的验证者实现 100% 的见证消息打包率。但这将是一项跨客户端的调试和工程工作,此过程中会涉及到大量的迭代,并可能伴随客户端的进展而不断改进。

在过去的一周里,我们已经看到各个团队在这方面的巨大进展。通过设法降低客户端在其它部分的处理负载,我们已经提高了低性能节点的打包率。

Medalla 故障

8 月 14 日,Cloudfare 的 Roughtime 服务器出了问题,导致所有的 Prysm 节点出现了时钟偏差,它们所有的见证消息和区块都被否定了。这其实等同于驱逐出链上所有的 Prysm 节点,这些节点占据了全网 70% 左右的份额 (这里有详细的账户信息)。由于大量的验证者掉线,主链无法实现终局性。这就是多客户端链以及客户端多样性重要的原因之一:在诸如此类的事件中,即便一类客户端实现掉线,区块链也能持续运转。

尽管这是一个灾难性的故障(占全网如此大比例的客户端同时掉线),但对于客户端的实现者来说,这是一个绝佳的机会来观察他们的客户端如何处理此类事件。

对我们来说,我们可以看到大量无效区块和见证消息涌入 gossipsub 通道中,进而导致了 Lighthouse 客户端遇到了一些处理上的瓶颈。我们已经观察到了奇怪的内存使用情况,还有一些有趣的同步极端情况,这是由于 Prysm 客户端的多条分叉导致的。这使得我们可以找出这些发生在不利情况下的热点事件,进而纠正它们,最终获得一个更加稳定的客户端,进一步使得其有能力处理这些极端情况。

我们正致力于完成许多诸如此类的更新,想象一下,一旦大功告成,我们将拥有一个更加强健和高性能的客户端。

(……)

稳定性、性能以及对等节点的管理

Medalla 测试网上发生的事故帮助我们找到了 Lighthouse 中需要改进的一些关键领域。我们一直致力于分析客户端、寻找处理瓶颈、过度的内存占用和整体的客户端稳定性。

我们观察到,在 Lighthouse 客户端 解码/处理 大量的 区块/见证消息 时出现了性能下降。这些数据最初是由核心执行器(core-executor,一个管理基本客户端操作的线程池)来处理的,这意味着 Lighthouse 的核心组件在处理 区块/见证消息 时会被延迟。我们一直在寻找此类运算量很大的进程,并将此类进程从核心执行器上转移到它们自己专属的任务处理器上,从而使得即便在高负载的情况下, Lighthouse 核心组件也能按照预期运行。结果表明这一改动提高了 Lighthouse 用户的见证消息打包率。

我们还在 Lighthouse 中找到了一些内存分配过多(超出实际所需)的区域。我们正在积极寻找和追踪内存溢出和不必要的内存分配,因为我们观察到在 Medalla 故障期间,一些 Lighthouse 节点的内存使用出现了小高峰。

同时,客户端中还存在一个已知的死锁,在 CPU 数量较少的节点上发生频率更高。我们也正在(已经有段时间了)积极地寻找这个死锁并缩小它的范围,应该很快可以干掉这个问题。

最后,自从上次更新以来,我们已经增强了对等节点管理系统。除了评分机制,我们还积极地跟踪当前和过去已知的对等节点。当使用默认参数运行一个 Lighthouse 节点时,它通常会连接到 50 个对等节点,且连接的节点数会在 50~55 之间波动。默认情况下,Lighthouse 的目标是连接到 50 个对等节点,并允许 10% 阈值以内的额外节点接入。这就使得新的节点可以轻松地加入网络(即便我们已经连接了 50 个对等节点,也不会拒绝连接新节点),并允许我们与新的对等节点交换节点池(peer-pool),从而移除其它性能不佳或恶意的对等节点。

如果你所运行的 Lighthouse 节点连接的对等节点在 50~55 之间波动,不用担心,这就是所需的行为,你的节点正如预期的那样运行。

(……)

(完)

文章部分来自互联网,侵权联系删除
www.qklbishe.com

区块链毕设网(www.qklbishe.com)全网最靠谱的原创区块链毕设代做网站
部分资料来自网络,侵权联系删除!
资源收费仅为搬运整理打赏费用,用户自愿支付 !
qklbishe.com区块链毕设代做网专注|以太坊fabric-计算机|java|毕业设计|代做平台 » Medalla 测试网网络动荡始末,Part-2-区块链毕设资料

提供最优质的资源集合

立即查看 了解详情