本期是wnie2计划之外的更新，将在周末回顾和分析Eth2 Medalla测试网络的插曲。

我们大约两周前，也就是8月4日，开始了Medalla，这是一个运行Eth2主网络规范的大型开放多客户端测试网络。关于Medalla测试网络的介绍，请参考上一期。

测试网络已经平稳运行了10天，尽管验证者的参与率低于我们的预期(70%-80%的验证者长时间保持在线)。但是这并没有什么坏处，测试网络完全可以处理它。

然而，在周五晚上，我目睹了控制面板中的验证者参与率突然急剧下降。几分钟内，活动授权码的数量从22，000个减少到大约5，000个，网络中大约80%的授权码消失了。

因此，本文将回顾这一事件，包括其后果和后续步骤。

到底发生了什么？

我们发现网络中每一个运行Prysm客户端的验证程序都突然消失了。由于Prysm是最常用的客户，后果的严重性是可以想象的。

Prysmatic团队在此事件中打开了一份文档报告，并不断更新事件和团队响应的详细信息。这里有一些亮点和我的笔记。

该事件是由时钟同步问题引起的。Prysm客户端被配置为使用Cloudflare的粗略时间来计算时间。(在我看来)原因不是很清楚，但是很明显，Roughtime已经把时间移到了接下来的四个小时，并且持续了一个多小时。Prysm客户验证员突然发现他们的时间快了4个小时，并继续为现有的区块链生成块和证明。

这本身不足以造成灾难性的后果。即使许多区块丢失，并面临来自未来的大量证据，剩余的客户仍然可以建立在原来的链上。渐渐地，随着Prysm节点的时钟向后调整，它们开始返回网络，验证者的参与率开始上升。网络似乎正在恢复正常。

但几个小时后，形势急转直下。

最初的时间过后四个小时，又发生了两件事。首先，Prysm客户将来生成的所有证明开始有效。其次，重新加入网络的Prysm节点开始再次消失，因为没收保护机制被触发以防止它们产生任何矛盾的证据。

这两件事同时发生，导致网络陷入混乱。剩下的客户仍在试图处理他们收到的信息，信标链变成了一个不断分支的丛林。(普瑞斯玛蒂团队的劳尔告诉我，普瑞斯姆第一次修复中的一个错误使情况变得更糟。(

在一段时间内，网络中的信息仍在控制之中。然而，在接下来的24小时左右，导航日益复杂和混乱的分叉所需的内存和中央处理器将变得无法忍受。我看到灯塔客户端使用30GB内存(大约是平时的100倍)。对于库特客户端，即使它使用12GB的Java内存堆并最大化处理器，它也有麻烦了。

请注意，所有这些都发生在周末。由于所有的客户团队都在前线作战，他们需要不断优化内存和效率，以使节点能够应对混乱的网络。

到目前为止，网络正在逐渐恢复。用户报告是不同的，但新版本的普睿司曼和灯塔只能找到正确的链头，并继续建立信标链。Eth2Stats当前显示链头的一些节点或附近的灯塔、普瑞斯姆和库特节点。我们将继续优化库特，减少同步所需的资源。

未出现一致失败

需要明确的一点是，客户端之间没有一致的故障，也就是说，当网络恢复时，所有客户端可以就链路头的状态达成一致，这意味着信标链不会从根本上失败，也不需要硬分叉。

经验

我们将花更多的时间对这一集进行全面的反思和总结。以下是我的拙见。

时间同步的重要性

对第三方时间服务的高度依赖是网络的一个致命点。碰巧，康赛斯收发研究小组的亚历克斯弗拉索夫在详细解释时间同步及其在以太网2.0网络中的重要性之前写了一篇文章。他的工作进展迅速。也许这也是每个人关注这方面的机会。这是他的相关文章和电子邮件。

客户多样性的含义

理想情况下，我们将有四个或更多独立的客户端，每个客户端节点不超过网络的30%。这样，即使一个客户有问题，其影响也不足以引起我们的注意。

即使我们无法实现这一理想情况，降低单个客户端的极高利用率也能使网络更加强健。假设只有50%的验证器离线，而不是80%，网络将更容易恢复。这是因为当客户端出现问题时，它将影响网络块生成、证据打包、广播效率、点对点通信和同步，并且这些因素还将对剩余的验证器产生联合影响。

备份计划的有效性

一些承诺可以将签名密钥切换到其他客户端的热备份节点。这无疑是一个很好的安全网，尽管需要小心避免被罚款：新的验证者可能对现有验证者的投票历史一无所知，所以他们可能会进行矛盾的投票。

将来，一旦我们完成了新的应用编程接口，我们应该能够在不同的信标节点之间切换验证客户端，而不仅仅是密钥。例如，Prysm验证器可以很容易地从Prysm信标节点分离，并重新连接到库特信标节点。这可以解决上述没收问题。

出质人的责任

目前，参与Eth2并不是“一劳永逸”的事情。抵押人需要保持一定的注意力，在论坛之间走动，向开发者提供反馈，并在短时间内更新客户。我非常支持运行你自己的个人验证器，但前提是你要意识到你的责任。

欲速则不达

为什么星期五晚上事情总是出错？

即使在这个时候，保时捷团队的反应也是惊人的。详情请参考团队的事故报告。下面的陈述并不是要给普雷斯曼团队带来不好的影响，普雷斯曼团队的工作确实非常出色，而是要为库特团队在面对类似情况时提供经验。

当如此多的用户失去资产(即使只是一枚试验硬币)并且网络处于高压之下时，他们自然会想要做出快速的反应，但是有时匆忙会造成浪费。

在这次事件中有两件事是可以避免的。首先，在最初的修复版本阿尔法21中有一个缺陷，它要求用户在17小时后回滚。

据公关团队劳尔称，这一缺陷是后来网络混乱的原因。第二，在处理这种情况时，该小组无意中删除了1024名核查人员的反没收记录数据库，导致大多数核查人员被没收。

类似的情况也可能发生在任何客户身上。因此，即使在很大的压力下，我们所有人，无论是开发者还是用户，都应该冷静地对待它，而不是一味地追求速度。因此，当我们试图恢复网络，我们遵循的方式缓慢的工作和细致的工作。

暴露问题以避免未来的麻烦

最后，这一集实际上是必要的。如果在测试网里什么都没有测试，它的意义是什么？保持平稳运行显然是不现实的。

这是一个伟大的考验！这可能是网络可能遭受的最严重的影响。即使我们自己设计，我们也可能无法设计这样的测试。让测试网络遭受这种程度的影响是我们加强客户端的必要条件。

上周，Block引用了我在文章中的声明：

在电子邮件中，PegaSys的工程师Ben Edgington写道，Medalla“是第一个测试网络，具有主网络的规模和配置。”

“这是第一次大规模的实验，但之前它只是屏幕上的一个规范，或者一个玩具网络。对等网络中有许多方面需要测试和优化。到目前为止，一切都在正常运行，但在我们能够确保它是正确的之前，我们需要更多的时间、更大的规模和更大的网络压力。

说实话，我很期待我想要的。

下一步是什么？

目前，所有客户团队都致力于加强客户以应对极端的网络条件。这不是什么大问题。我们应该在接下来的几天内将Medalla恢复到正常状态，这可能会影响所有验证者的平衡，一些验证者将被罚款。

如果在那之后，即使网络能够正常工作，验证者的参与率仍然不能上升，那么我们可以考虑从头开始重新部署存款合同(重新创建也可能是一个不错的选择)。但这只是现阶段的一种选择。