抱负环境是我们会有四个及以上独立客户端，每个客户端节点所占比例不高出网络的30%。如此一来，纵然有一个客户端呈现了问题，而影响都不敷以引起我们的留意。

我们在差不多两周前启动了Medalla，也就是8月4日，这是一个大型的、果真的多客户端测试网，运行Eth2主网类型。关于Medalla测试网的先容，可以参阅上期。

客户端多样性的意义

然而周五的黄昏，我在节制板中目击了验证者参加率溘然断崖式下降。在几分钟之内，活泼验证者从22000低落到5000阁下，网络中约80%的验证者都消失了。

今朝参加Eth2并不是“一劳永逸”的事。质押者们需要保持必然留意力，游走于论坛之间，为开拓者提供反馈而且可以或许在短时内更新客户端。我很是支持各人运行本身的小我私家验证者，但前提是对本身应包袱的责任有所意识。

时间同步的重要性

质押者的责任感

但几小时之后，景象又急转直下。

请运行Prysm客户端的用户尽快进级到Alpha.23版本：

今朝，所有客户端团队都在致力于强化客户端，使其可以或许应对极度的网络环境。问题不大，我们应该在接下来的几天内就能使Medalla规复到正常状态，大概会对所有验证者的余额发生影响，也会有一些验证者面对罚没。

事件起因是时钟同步 (clock sync)呈现问题。Prysm客户端的设置利用了Cloudflare的Roughtime来计较时间。(在我看来) 其起因还不长短常明晰，但很显然Roughtime将时间推移到了将来的四小时，而且一连了一个多小时。Prysm客户端验证者们溘然发明他们的时间快了四个小时，而且继承为尚不存在的区块链生成区块和证明。

这两件事同时产生，让网络陷入了杂乱。剩下的客户端仍在尽力地处理惩罚他们所吸收到的信息，信标链酿成了不断分支的森林。(Prysmatic团队的Raul汇报我，Prysm首次修复中的一个bug使得环境恶化)

在一段时间之内，网络中的信息仍处于可控范畴内。但在接下来的24小时阁下，要导航愈加巨大杂乱的分叉，所需的内存和CPU变得难以承担。我看到一个Lighthouse客户端利用了30GB内存 (约为凡是环境下的100倍)，对付Teku客户端来说，纵然利用12GB的Java内存堆并最大化处理惩罚器，也碰着了贫苦。

最后，这次插曲其实是有须要的。假如测试网中什么都没测试出来，那它有何意义？一直处于顺滑运行的状态显然是不现实的。

有一点需要明晰的是，客户端之间没有产生共鸣失败，也就是说网络规复时，所有客户端都能就链头状态告竣共鸣，也就意味着信标链不会从基础上失败，，也不需要举办任何硬分叉。

纵然产生在这个时间，Prysmatic团队做出的响应令人赞叹。详情请参阅该团队的事件陈诉。我以下的表述并非意在给Prysmatic团队带来不良影响，他们的事情简直很是精彩，而是为Teku团队在面对相似处境的时候提供履历。

我们发明，网络中每个运行Prysm客户端的验证者都溘然消失了。由于Prysm是使费用最高的客户端，其效果严重性可想而知。

这次事件中有两件事是可以制止的。首先，在初始修复版本Alpha.21中有一个缺陷，导致要求用户在17小时后举办回滚。

在未来，一旦我们完成了新的API，应该可以实此刻差异的信标节点之间切换验证者客户端的本领，而不只仅是密钥。譬喻，一个Prysm验证者可以或许等闲地离开Prysm信标节点，而且从头毗连到Teku信标节点。这可以或许办理上面提到的罚没问题。

在初始时间产生的四小时之后，又产生了两件事。首先，所有Prysm客户端在将来生成的证明都开始具备有效性。其次，从头插手网络的Prysm节点又开始消失了，原因是为了防备他们生成任何相悖的证明，罚没掩护机制被触发了。

为什么老是在周五黄昏出岔子？

请留意，这一切都产生在周末。感激所有奋战在一线的客户团队们，为了使节点可以或许应对杂乱的网络，他们需要不断地优化内存和效率。

没有产生共鸣失败

高度依赖第三方时间处事对付网络来说是一个致命点。可巧的是，ConsenSys TX/RX研究团队的Alex Vlasov之前就撰文详尽阐释了时间同步及其在

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。