在主网上线之前，测试网就是用来发明这类问题的。面临这种环境，多几个客户端选择对用户更为有利。

3:18 AM ：Buildkite 单位测试、类型测试、docker 镜像构建乐成。e2e 测试尚未完成。Preston 筹备启动上线流程。

3:05 AM ：Raul 确认该修复措施可以让节点在当地事情。假如存在时钟偏移，修复措施会发生告警日志，可是不会试图基于 roughtime 处事器更新时间。

6:20 AM ：用户陈诉说罚没掩护机制已经启动。这是因为之前的时钟偏移导致验证者超前 4 小时提议区块并生私见证动静。为了制止遭到罚没，Prysm 验证者没有继承提议无效区块。

状态：期待决策。基础原因已找到，问题已缓解。

3:36 AM ：利用新的 docker 镜像对我们的验证者 pod 举办转动启动。

- 图片来历：@prestonvanloon.eth -

1:45 AM ：Discord 频道的用户提出，重启信标链节点和验证者客户端无法临时办理这个问题。最可行的方案是将 roughtime 时钟同步设为可选禁用的成果。

我们抉择将软件改成默认禁用 roughtime 时钟同步，取而代之的是可选择的成果切换（feature flag）。这样可以防备此类问题再次大局限发作。以后刻开始，roughtime 的功效将仅供客户端软件参考，不再用于自动时钟校准。

事发之后，Prysm 客户端团队迅速推出了紧张修复并密切跟踪事态。但 Medalla 测试网仍因为各类原因而继承动荡，无法敲定 epoch。事实上，事发之后，停止发文之时，Medalla 测试网仅在北京时间 2020 年 8 月 20 日破晓曾敲定区块，随后验证者参加度又降到了 66% 以下，未能敲定区块。

2020/08/15

10:46 AM ：Prylabs 团队认为此刻最好的步伐就是期待。用户应该运行 alpha 20 版本或最新的 docker 镜像。

图片来历：@prestonvanloon.eth

编者注：2020 年 8 月 15 日，Medalla 测试网呈现了验证者参加率的大幅下降，起因是 Prysm 客户端默认利用 Cloudflare 公司的 roughtime 处事来较准节点的当地时间，但其时的 roughtime 处事出了错，导致所有 Prysm 节点的当地时间都快了 4 个小时，如此一来，Prysm 节点就与利用其它客户端的节点距脱离来了。

2:40 AM ：Preston 指出只靠紧张修复还不足，我们需要打消将 roughtime 时钟同步作为默认项。

3:34 AM ：对有状态荟萃中 pod 的康健状态举办监控，确保转动更新乐成

5:33 AM ：Alpha 22 版本宣布。链接：

8:13 AM ：再次妨碍

翻译: 阿剑

Prysm 客户端确实出了问题。

4:52 AM ：即时观测竣事。这次时钟偏移妨碍显然已经竣事，并且修复措施已经宣布。已经更新的节点将当即规复，还没有更新的节点需要过段时间规复。监控系统显示，验证者参加度在慢慢回升。

2020/08/16

1:52 AM ：Ivan 完成了 

接待阅读完整的过后观测陈诉，

履历教导

• 我们误觉得，对付 roughtime 处事器妨碍的问题，我们有适当的应急方案。
• 网络中的每个 Prysm 节点同时受到影响，导致验证者参加率大幅低落。
• Prysmatic Labs 团队原觉得，NTP 处事器自己较为分手，并且每个处事器都开放 6 个端口，不会呈现全局妨碍的问题。

• 一位孝敬者已经向我们提交了一个 Pull Request（感激 @ncitron），把 roughtime 时间校准设为可以选择退出的成果。
• 我们已经可以用呼吁行成果标签（flag）当即选择打消 roughtime 时钟校准，这让修复法子变得简朴，并且只需一次 Pull Requtest 就能验证。
• 用户在 Discord 上努力参加接头。当节点呈现问题时，有大量用户提供了具体陈诉和重要指标。
• 我们有一个一连不绝的重同步机制，当它发明时钟偏移量高出 2 秒时，它会不绝更新节点当地的时间。我们一直在从头校准 roughtime 时钟，以便更快办理这一问题。这大概让这次事件提前了约莫 30 分钟至 1 小时竣事。
• roughtime 时钟同步问题好像在约莫 90 分钟后就办理了，并且在我们可以或许紧张宣布新版本前，这个事件就已经竣事了。

2:42 AM ：Raul 开始观测 Kibana ，并利用 fluentd 中的 filter（过滤器）阐明来自 roughtime 的调试日志响应。

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