江苏龙网

  1. 首页 > 资讯 > 科技 > >

始末|一文了解Medalla测试网“崩溃”事件始末


始末|一文了解Medalla测试网“崩溃”事件始末
本文插图

外汇天眼APP讯 : 本期是wnie2计划之外的更新 ， 将针对周末Eth2 Medalla测试网发生的插曲进行回顾和分析 。
我们在差不多两周前启动了Medalla ， 也就是8月4日 ， 这是一个大型的、公开的多客户端测试网 ， 运行Eth2主网规范 。 关于Medalla测试网的介绍 ， 可以参阅上期 。
测试网平稳运行了10天 ， 即使验证者参与率比我们预期中要低 (70%-80%的验证者保持长期在线) 。 但这无伤大雅 ， 测试网完全能应付 。
然而周五的傍晚 ， 我在控制板中目睹了验证者参与率突然断崖式下降 。 在几分钟之内 ， 活跃验证者从22000降低到5000左右 ， 网络中约80%的验证者都消失了 。
因此 ， 本文将对此事件进行回顾 ， 包括其后果和下一步的措施 。
究竟发生了什么？
我们发现 ， 网络中每个运行Prysm客户端的验证者都突然消失了 。 由于Prysm是使用度最高的客户端 ， 其后果严重性可想而知 。
Prysmatic团队在此次事件中开放了一个文档报告 ， 并且持续在其中更新事件细节以及团队响应 。 以下是一些重点内容以及我的注释 。

事件起因是时钟同步 (clock sync) 出现问题 。 Prysm客户端的配置使用了Cloudflare的Roughtime来计算时间 。 (在我看来) 其起因还不是非常明确 ， 但很显然Roughtime将时间推移到了未来的四小时 ， 并且持续了一个多小时 。 Prysm客户端验证者们突然发现他们的时间快了四个小时 ， 并且继续为尚不存在的区块链生成区块和证明 。
就其本身而言 ， 还不足以造成灾难性的后果 。 即使有许多区块丢失 ， 并且面临大量来自未来的证明 ， 剩下的客户端仍然能够在原链上进行建设 。 渐渐地 ， 随着Prysm节点的时钟调整回来 ， 他们开始回到网络中 ， 并且验证者参与率也开始回升 。 网络似乎在恢复正常 。
但几小时之后 ， 情形又急转直下 。
在初始时间发生的四小时之后 ， 又发生了两件事 。 首先 ， 所有Prysm客户端在未来生成的证明都开始具备有效性 。 其次 ， 重新加入网络的Prysm节点又开始消失了 ， 原因是为了防止他们生成任何相悖的证明 ， 罚没保护机制被触发了 。
这两件事同时发生 ， 让网络陷入了混乱 。 剩下的客户端仍在努力地处理他们所接收到的信息 ， 信标链变成了不停分支的丛林 。 (Prysmatic团队的Raul告诉我 ， Prysm首次修复中的一个bug使得情况恶化)

在一段时间之内 ， 网络中的信息仍处于可控范围内 。 但在接下来的24小时左右 ， 要导航愈加复杂混乱的分叉 ， 所需的内存和CPU变得难以负担 。 我看到一个Lighthouse客户端使用了30GB内存 (约为通常情况下的100倍) ， 对于Teku客户端来说 ， 即使使用12GB的Java内存堆并最大化处理器 ， 也遇到了麻烦 。
请注意 ， 这一切都发生在周末 。 感谢所有奋战在一线的客户团队们 ， 为了使节点能够应对混乱的网络 ， 他们需要不停地优化内存和效率 。
到目前为止 ， 网络正在逐渐恢复 。 用户报告不尽相同 ， 但是Prysm和Lighthouse的新版本刚好能够找到正确的链头并继续构建信标链 。Eth2Stats当前显示链头或附近的Lighthouse、Prysm和Teku节点的一些节点 。 我们会继续优化Teku ， 减少其在同步时所需的资源 。
没有发生共识失败
有一点需要明确的是 ， 客户端之间没有发生共识失败 ， 也就是说网络恢复时 ， 所有客户端都能就链头状态达成共识 ， 也就意味着信标链不会从根本上失败 ， 也不需要进行任何硬分叉 。
Lessons 经验
我们将会花更多时间对这个插曲进行全面反思和总结 ， 以下是我个人的一些陋见 。
时间同步的重要性

高度依赖第三方时间服务对于网络来说是一个致命点 。 碰巧的是 ， ConsenSys TX/RX研究团队的Alex Vlasov之前就撰文详尽阐释了时间同步及其在以太坊2.0网络中的重要性 。 他的工作在飞速进展当中 ， 或许这也是一次让大家关注到这个方面的契机 。 此处是他的相关文章和ethresear.ch贴文 。


推荐阅读


上一篇：人工智能|品茗施工资料管理软件V2020，智能化自动生成施工资料，限时分享

下一篇：手机|网友的“纠结”！相差1块钱，魅族17 Pro与IQOO 5如何选择？