编者按：2020年8月20日晚，梅达拉测试网从8月15日开始的网络动荡中恢复过来，重新获得了最终的胜利。但我们不能停止探索。第三份材料来自Lighthouse客户团队的定期更新日志。在这份日志中，lighthouse团队含蓄地承认，在网络动荡期间，由于网络长期无法获得最终性，lighthouse客户端遇到了内存消耗高的问题。

灯塔更新28（节选）

（……）

Medalla测试网络

自上次更新以来，medalla公共多客户端测试网络已经启动。至少有20000个不同的验证器在上面的客户机上运行。由于初期大量出质人下线，初期试网难以启动。这导致参与率低于预期。很快，许多认捐者加入，测试网络开始获得最终结果并顺利运行。在过去的几周里，我们有机会在这个测试网络上进行了大量的客户端互操作性测试和性能调优。

证人证言的包装

我们在medalla测试网络上观察到的一个主要问题是证人信息的打包率。每个验证器必须在每个历元产生一个见证消息。这些见证消息将被打包到未来的块中，一旦打包，与见证消息相关联的验证器将得到奖励。虽然在一个只有lighthouse客户端的medalla测试网络中，我们看到见证消息的打包率为*（也就是说，生成的所有见证消息都打包成块），但是有些见证消息被跳过（将来不会打包到第一个块中）。解决这个问题不容易，因为过程有点复杂。让我详细解释一下。在每个阶段，核查人员被分成不同的委员会。

委员会中的每个核查人员都必须将他们的证人信息发布到特定的八卦子网（与他们所属的委员会相关）。在委员会的所有验证者中，需要有一个伪随机的验证者子集（大约16个）来收集和汇总所有的证人信息。然后，这些聚合器将聚合的见证消息发布到一个全球“聚合”八卦子频道。这使得区块支持者只需要订阅“聚合”频道，因此只需关注各委员会合并的证人信息，而不必关注八卦子网中所有验证者发布的证人信息。然后，块建议者选择使其利润**化的合计见证消息，并将这些见证消息打包到所建议的块中。

在此过程中，在许多地方可能存在故障，从而阻止验证器的见证消息被打包到块中。首先，客户机节点需要找到也订阅所需子网的其他对等方。如果没有这样的对等节点，它发布的见证消息就无法传播，更不用说打包成块的任何步骤了。如果客户机找到了足够多的对等节点，下一步是依赖子网中的“聚合器”来接收和聚合来自gosisp子网的见证消息。聚合器可能有不同的客户端实现，或者它们可能与在子网上接收到的见证消息不一致。在这种情况下，在客户端之间传播见证消息的时间对于确保在聚合器聚合见证消息之前传递见证消息也很重要。然后，聚合器必须将见证消息发布到全局聚合通道中。

块生成器必须注意聚合器发布的见证消息，并决定是否将其包含在其块中（在发布见证消息的期间内）。**两个步骤可以由网络上的任何节点完成，这部分中的挑战是让所有客户端实现在整个过程中都能一致地工作。这就是我们的团队（我相信其他客户实现团队）的目标是为我们所有的验证者实现*的见证消息打包。随着客户机的不断改进，客户机的调试工作也会不断改进。在过去的一周里，我们看到了各个团队在这方面的巨大进步。通过减少其他部分客户端的处理负载，提高了低性能节点的打包率。

梅达拉断层

8月14日，cloudfair的rough time服务器出现问题，导致所有Pry节点的时钟偏移，所有的见证消息和块都被拒绝。这实际上相当于驱逐掉链中的所有Pry节点，这些节点约占整个网络的70%（详细的帐户信息在这里）。由于大量验证器离线，主链无法实现最终性。这是多客户端链和客户端多样性的重要原因之一：在这样的事件中，即使一种类的客户端离线，区块链也可以继续工作。

尽管这是一个灾难性的失败（整个网络中如此大比例的客户机同时离线），但对于客户机实现者来说，这是观察其客户机如何处理此类事件的**机会。对于我们来说，我们可以看到大量无效块和见证消息涌入八卦子频道，这导致了lighthouse客户端的一些处理瓶颈。我们已经观察到奇怪的内存使用和一些有趣的同步极端，这是由于Pry客户机中的多个fork造成的。这使我们能够识别出这些在不利环境下发生的热事件，然后进行纠正，最终获得一个更稳定的客户端，这进一步使它能够处理这些极端情况。我们正在做很多这样的更新，想象一下一旦我们完成了，我们将拥有一个更加健壮和高性能的客户端。（……）

稳定性、性能和同行管理

medalla测试网络事件帮助我们确定了灯塔中需要改进的一些关键领域。我们一直致力于分析客户机，寻找处理瓶颈、过度内存消耗和整体客户机稳定性。当lighthouse客户端解码/处理大量块/见证消息时，我们观察到性能下降。这些数据最初由核心执行器（管理基本客户端操作的线程池）处理，这意味着lighthouse的核心组件在处理块/见证消息时会延迟。我们一直在寻找计算量大的进程，并将这些进程从核心执行器转移到它们自己的任务处理器，这样灯塔核心组件即使在高负载下也能按预期运行。结果表明，这种改变提高了灯塔用户的见证信息打包率。我们还发现灯塔中的区域分配过多（超过需要）。我们正在积极寻找和跟踪内存溢出和不必要的内存分配，因为我们在medalla故障期间观察到一些灯塔节点的内存使用出现了小峰值。同时，客户机中存在已知的死锁，这种死锁在CPU较少的节点上更为频繁。我们也在积极寻找这一僵局并缩小其范围。我们应该能很快消除这个问题。**，自上次更新以来，我们增强了对等管理系统。除了评分机制外，我们还积极跟踪当前和过去已知的同龄人。当使用默认参数运行灯塔节点时，它通常连接到50个对等节点，并且连接的节点数量在50到55个之间波动。默认情况下，Lighthouse的目标是连接到50个对等节点，并允许在阈值的10%内添加其他节点。这使得新节点很容易加入网络（即使我们已经连接了50个对等节点，我们也不会拒绝连接到新节点），并允许我们与新的对等节点交换对等池，从而移除其他性能较差或恶意的对等节点。如果您运行的lighthouse节点的对等节点在50和55之间波动，请不要担心，这是您需要的行为，并且您的节点正在按预期运行。（……）

（结束）

链接到原文：

https://lighthouse.sigmaprime.io/update-28.html

作者：灯塔队

翻译与校对：曾米阿健

编者按：第四份材料是8月17日ETH2的**消息，它概述了事件的顺序和相关问题。

ETH2-2020年8月17日的**消息（节选）

怎么回事？

不可否认，当时网络上所有的Pry验证者突然消失了。由于Pry客户端是应用最广泛的客户端，其影响是巨大的。prysmatic团队正在编写一份详细的事故报告（编者注：本系列的第1部分），其中包含所有细节及其应对措施。以下是一些要点和我的评论。问题是时钟同步。Pry客户端配置为使用cloudflare的rough time服务来计算时间。目前还不清楚这是怎么发生的（至少对我来说是这样），但很明显，劳夫泰姆报告的时间是在4小时之后，而且持续了一个多小时。结果，所有的Pry客户突然发现自己跳到4小时后，高兴地开始为一个不存在的区块链制作区块和见证信息。这本身并不是灾难性的。

因为剩余的节点可以继续构建原始链，所以它们可以忽略许多“来自未来”的见证消息，尽管它们必须跳过许多块。这样，慢慢地，Pry节点将开始返回（因为时钟已经被调整），并且参与度将再次上升，因此问题将得到解决！但事情并非如此。几个小时后，情况变得更糟了。在最初的事故发生四个小时后，两件事开始浮现。首先，所有来自Pry客户机的原始“来自未来”的见证消息开始成为有效的见证消息。其次，时钟调整后重新加入网络的Pry节点又消失了，因为Pry客户端的没收保护措施被激活，以防止它们发送任何与之前的见证消息冲突的见证消息。

这两件事结合在一起的结果就是混乱。当剩下的节点努力处理它们接收到的杂波时，信标链会断开，形成一片分叉森林。更新：pryatic团队的劳尔告诉我，他们第一次修复时的一个严重缺陷加剧了问题。在一段时间内，处理这些消息的任务是可以管理的。然而，在24小时之后，处理这些日益复杂的大量分叉所需的内存和CPU开始变得难以实现。我发现lighthouse客户机使用30gb的内存（大约是正常数量的100倍），而teku客户机则使用12gb的Java堆栈。整个周末都有，所以一定要记住这一点。在客户端团队的帮助下，他们一直致力于优化节点的内存利用率和效率，使节点能够处理网络的混乱。现在整个网络正在慢慢恢复。虽然用户的反应各不相同，但新推出的Pry客户端和lighthouse客户端可以有效地找到正确的链头，继续构建信标链。ETH2stats显示了一些灯塔、Pry和teku节点，这些节点现在已被发现或靠近链头。我们正在提高teku客户的效率，使他们不会落后，资源消耗是可持续的。

什么没发生

客户之间没有共识失败，这意味着当每个人到达区块链的**区块时，所有客户都可以就区块链头区块的状态达成一致。这是一件很好的事情，这意味着信标链没有从根本上断开，也不需要任何硬分支。（……）