说实话，。

下一步是什么？

Lessons 履历

测试网平稳运行了10天，纵然验证者参加率比我们预期中要低 (70%-80%的验证者保持恒久在线)。但这无感冒雅，测试网完全能应付。

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

本期是wnie2打算之外的更新，将针对周末Eth2 Medalla测试网产生的插曲举办回首和阐明。

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

就算我们无法到达这种抱负环境，可是低落单个客户端的极高利用率也能使得网络越发矫健。假设这次只有50%的验证者下线而非80%，网络也会更容易规复。这是因为当客户端呈现问题时，会影响网络的区块发生、证明打包、广播效率、点对点通信以及同步，而这些因素也会对剩余的验证者发生连带效应。

备用方案的有效性

上周引用了我的告诉：

译者注：请运行Prysm客户端的用户尽快进级到

没有产生共鸣失败

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

因此，本文将对此事件举办回首，包罗其效果和下一步的法子。

就其自己而言，，还不敷以造成劫难性的效果。纵然有很多区块丢失，而且面对大量来自将来的证明，剩下的客户端仍然可以或许在原链长举办建树。徐徐地，跟着Prysm节点的时钟调解返来，他们开始回到网络中，而且验证者参加率也开始回升。网络好像在规复正常。

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

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

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

我们将会花更多时间对这个插曲举办全面反思和总结，以下是我小我私家的一些陋见。

时间同步的重要性

客户端多样性的意义

Medalla万岁

“这是首次大局限试验，而之前只是屏幕上的类型，或是玩具网络。点对点网络中有很多方面需要举办测试和优化。到今朝为止，一切都在正常运行中，可是在我们能确保无误之前，还需要更多的时间，更广的局限以及更大的网络压力”。

据Prysmatic团队Raul的说法，此缺陷是造成随后呈现网络杂乱的原因。其次，团队在处理惩罚环境时无意中删除了其1024个验证者的防罚没记录数据库，导致大部门验证者被罚没。

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

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

任何一个客户端都大概会产生雷同环境。所以纵然处于高压状态下，无论是开拓者照旧用户，我们所有人都要沉稳应对，不能一味追求速度。因此当我们在实验规复网络时，遵循了慢工出细活的方法。

袒露问题以绝后患

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