12
北京时间8月15日凌晨，Eth2.0客户端执行团队 Prysmatic Labs(旗下客户端是 Prysm )联合创始人 Preston Vanloon表示：Eth2.0测试网 Medalla 上出现时钟 Bug，导致对所有节点造成影响，Prysm 客户端出现了长达近 90 分钟的时钟偏斜(clock skew)，验证器也陆续收到超前 Slot (时隙)区块和证明。
简单来说，这次测试网出现的根源，主要在于 Prysm 客户端的时间服务器 Roughtime 中断，出现时钟偏斜，导致验证者与区块头无法同步，最终影响了测试网 Medalla 正常运行。
(1)事故回溯
所谓时钟偏斜，即区块时间与正常时间出现的偏差。
时间对 Eth2.0 至关重要，每一个区块中都包含时间戳;时间一旦不同步，网络就无法正常运行。
为了防止系统时间不够精准，Prysm 采用了美国 Cloudflare 公司的时间服务器 Roughtime 来校正。并且，为了防止单体机器故障，还选择了 6 台。
然而，问题还是发生了。北京时间 8 月 15 日凌晨，Roughtime 出现故障，这也导致 Prysm 被波及。
根据事后的一份诊断报告：“ Cloudflare 的 Roughtime 服务器都返回了错误的信息，Prysm 节点没有从这种情况适当退避。虽然他们使用 6 台时间服务器，但似乎还不够，因为它们都返回了错误的时间。”
最终的结果是，Prysm 客户端上「时钟偏斜」超过 2 秒的时间长达 90 分钟;并且整个客户端时间也比标准时间提前了 4 个小时。根据 Preston Vanloon 的推文，时钟偏斜发生在北京时间的 15 日凌晨 1 点半-3 点种之间。如下所示：
(时钟偏斜)
事故发生后， Prysm 客户端第一时间停止了 Roughtime 服务器的使用，并号召用户切换到其他客户端。
“我们决定默认情况下禁用「 Roughtime」同步。Roughtime 计算中肯定存在一些错误，我们希望尽快发现它。无论调查结果如何，我们认为都应该选择自动调整时钟或完全取消。”Preston Vanloon 表示。
几个小时后，开发人员完成调查并发布了修复程序。
不过，名为 PR 6898 的修复程序却存在严重缺陷。
开发人员 Raul Jordan 表示：“在修复此错误时，我们无意中删除了Prysm节点起作用的所有关键功能，这使问题变得更加严重。”
(2)后果
由于时间不同步，通过 Prysm 客户端进行验证的“几乎没有人同步到链头”。这也意味着，他们的数据是无效的，也就不能参与验证、获得质押奖励等。
虽然目前Eth2.0 仍然是测试网阶段，这些奖励也不是真实的——包括用户参与验证质押的ETH也是测试网版的，不具有真实流通性。
但这次事故，还是对整个 Medalla 测试网造成了冲击。
由于 prysm 客户端占据 全网 64% 以上的份额，在事件发生后，Medalla 测试网中主动投票的验证者数量与总验证者数量的比值从 75% 左右一度降至 5 %以下。这也意味着，剩余验证者无法达成全网共识，网络无法正常运行。
(网络参与率)
外媒《Trustnodes》报导称，此次事故也造成以太坊网络一度停止：大约 30% 的验证流程失败时，内存问题就开始出现;大约 50% 之后，问题就变得更大;最后在 70% 之后，网络显然就停止了。
因此，在过去两天，Prysm 客户端修缮了自己的客户端，想要尽快启动测试网。
今天下午，星火矿池发出号召，所有运行 Prysm 客户端参与 Medalla 测试网的朋友，请检查自己的客户端是否升级到了 alpha.22 版本。如果尚未升级，请尽快升级，以支援 Medalla 测试网从同步障碍中恢复。
(3)思考
这次事故也反映了多客户端的重要性。
某个客户端使用占比过高，一旦出现问题，最中可能导致整个网络运行受到影响。
但从现实情况来看，Prysm 客户端能够获得青睐也是有原因的。
目前，Eth2.0 上线了 5 个客户端，但 Prysm 提供的教学无疑是最好上手的，所以绝大多数验证者仍使用 Prysm。
因此，对整个以太坊生态来说，要想平衡各个客户端的力量，必须提升其他客户端易用性，而这是一条任重而道远的漫长之路。
最后，我想说这次事故对 Eth2.0 来说也是一次历练。所有的问题在测试网阶段充分暴露，才能保证 Eth2.0 未来的可用性和安全性。
从以太坊过去 5 年的发展来看，相比于 The DAO 攻击、分叉等一系列挑战，这次测试网发生的事故只是小问题，对于以太坊来说，只会愈挫愈勇。
946
604
771
813
232
1034
470
743
928
898
