Bitcoin Vault -比特币保险库

教程

阅读棉兰测试网的整个网络混乱的故事

这一事实令人不安,但它只是为我们提供了一个检查Eth2网络和节点行为的机会。

编者按:2020年8月15日,梅达拉测试网络的验证者参与率急剧下降。原因是Prysm客户端默认使用Cloudflare的roughtime服务来比较节点的本地时间,但是roughtime服务当时犯了一个错误,导致所有Prysm节点的本地时间都快了4个小时。因此,Prysm节点与使用其他客户端的节点隔离开来。

事件发生后,Prysm客户团队迅速启动了紧急维修,并密切关注情况。然而,由于各种原因,棉兰测试网络仍然动荡不安,不可能最终确定时代。事实上,事件发生后,截至发表时,美达拉测试网只在北京时间2020年8月20日凌晨完成了封锁,随后验证者的参与度降至66%以下,未能完成封锁。

尽管事实令人不安,但它只是为我们提供了一个检查Eth2网络和节点行为的机会。——这个检查和反思的机会不应该错过,否则我们可能还会重复同样的错误。

我们选择了多种材料,试图从多个角度和层面再现完整的事实,并包含了尽可能多的不容忽视的因素。诚然,我们缺少能观察分散网络的全局的上帝之眼,认知的深度必须有其边界。然而,我们仍然希望对混沌网络的恢复过程以及参与这一过程的激励因素有一个完整的描述。到目前为止,这个目标还没有实现。

第一份材料来自Prysm客户工程师在推特上的报告。

Medalla 测试网全局性故障初探

phil.eth:

Medalla,ETH 2.0测试网络,目前无法完成该模块,因为Prysm客户端的粗时时钟同步出现故障。目前,有一个修复计划。请要求Prysm用户更新并重新启动您的客户端。这种意想不到的情况再次显示了客户的多样性和测试网络的重要性。

prestonvanloon.eth:

今天早些时候(8月15日),普瑞斯姆遭遇了持续近90分钟的全球性故障。这一事件的全部经过如下:

大约在世界协调时17336030(北京时间上午1:30)时,@特伦斯链发现其客户的时钟比预定时间提前了4个小时。很快,时钟偏移警报出现了,不和谐的频道被大量的用户报告淹没了。

Prysm客户端有问题。

Medalla测试网络中验证者的参与度急剧下降,其速度甚至超过了$YAM的零回报速度,从75%下降到5%以下。普瑞斯玛蒂实验室团队立即采取了紧急行动。

我们决定更改软件,默认情况下禁用roughtime时钟同步,并将其替换为可选的功能标志。这可以防止此类问题再次大规模爆发。从现在起,roughtime的结果将仅用于客户端软件的参考,不再用于自动时钟校准。

下图显示了北京时间1:30到:00之间,Prysm节点时钟偏移超过2秒的时间段,持续约90分钟。(注:下图显示太平洋标准时间。(

-图像源:@ prestonvanlone . eth-图像源:@ prestonvanlone . eth-

现在,我们看着这些数据,思考一个问题,“粗糙时间服务器怎么会偏离这么多?”数据显示所有Prysm服务器报告的偏移小于0.1秒。最后,为什么是4小时前?

-图像源:@ prestonvanlone . eth-图像源:@ prestonvanlone . eth-

我们还在调查这个问题!计算错误的一定是粗糙时间的增量,我们希望尽快找到它。无论调查结果如何,我们认为自动时间校准应该作为一种选择,甚至完全取消。

欢迎阅读完整的事后调查报告,了解最新的调查进展。

在主网络上线之前,测试网络被用来发现这样的问题。面对这种情况,用户选择更多的客户更有利。

原始链接:

https://twitter.com/preston_vanloon/status/1294392007599652865

作者: prestonvanloon.eth

翻译校对:敏敏一建

编者按:第二份材料来自Prysm客户团队的分析报告,附有详细的时间表记录。由此,我们可以了解Prysm客户发出紧急维修的全过程,以及紧急维修带来的联合影响(紧急维修本身也带来问题)。截至本译文出版时,分析报告表明已找到故障的具体原因。值得一提的是,报告的原文使用了世界协调时,我们都将其转换为北京时间。

“roughtime” 事件分析报告

作者:特伦斯、劳尔、普莱斯顿

http://www . sogo.com:待定。根本原因已经找到,问题已经缓解。

状态:梅达拉

Cloudflare的粗糙服务器都返回错误消息,但是Prysm节点没有采取适当的紧急措施。这个错误导致所有Prysm节点的时钟偏移。在时钟偏移的影响下,验证器为高级时隙提出块并产生见证消息。

由于粗时响应错误和时钟偏移,验证者计算出时隙错误,并且所提出的块和所生成的见证消息无效。这个问题影响到全球的参与。北京时间1:30-2336045之间,所有Prysm节点均受到影响。

http://www . sogou.com:Cloudflare服务器的roughtime响应出错。具体来说,“滴答”报告了24小时后的时间。该时间戳是所有六个服务器的数据的平均值,因此所有Prysm节点都产生了4小时的时间调整。

当我们评估由于对roughtime的错误响应而导致的潜在问题时,我们应该首先将roughtime时钟同步设置为一个选项。

网络: Terence首先发现了这个问题。他注意到一个本地信标链节点一直拒绝高级块和见证消息。几分钟后,由于粗略时钟的高偏移,产生了警报。同时,#general和#bug报告通道的用户开始报告本地节点拒绝预先阻止和见证信息的问题。

总结

影响

我们错误地认为我们有一个适当的应急计划来应对服务器故障。

网络中的每一个Prysm节点都同时受到影响,导致验证者的参与率显著下降。

Prysmatic实验室团队认为NTP服务器是分散的,每台服务器都有六个开放端口,因此不会出现全局故障。

根本原因

一位投稿人向我们提交了一份拉取请求(感谢@ncitron),将粗略校准设置为可选退出功能。

我们可以使用命令行功能标志立即选择取消粗略时钟校准,这使得修复措施变得简单,并且只能通过拉一次requ测试来验证。

用户积极参与关于不和谐的讨论。当一个节点出现问题时,大量用户会提供详细的报告和重要的指标。

我们有一个连续的再同步机制。当它发现时钟偏移超过2秒时,它将不断更新节点的本地时间。为了更快地解决这个问题,我们一直在重新调整工作时间。这可能使事件提前30分钟到1小时结束。

粗略的时钟同步问题似乎在大约90分钟内就解决了,而这个事件在我们能够紧急发布新版本之前已经结束了。

解决方案

发现

上午1:25:Terence发现他的本地节点收到了大量的警报,因为它拒绝始终引导该块。这些街区的空位比预定时间提前了四个多小时。

上午1:28:普罗米修斯(Prometheus)监控报警系统收到一个具有高粗时偏移的报警。当时,自网络最后一次完成块以来,已经过去了10个纪元(时间段)。

上午1:35:至少30个用户在不和谐频道上表示他们开始收到以下警报:警告粗略时间:粗略时间报告您的时钟关闭超过2秒偏移=4h0m0.028854657s秒(粗略时间警报:粗略时间报告您的时钟错误超过2秒,偏移=4h0m0.028854657s)

上午1:43:特伦斯在#作战室频道组发送了一条警报消息,称这是一次PS0级别的活动,要求每个人都度过难关。

上午1:45:不和谐信道的用户建议重新启动信标链节点和验证器客户端暂时无法解决此问题。最可行的解决方案是将粗略时钟同步设置为可选的禁用功能。

上午1:51:问题已经上升到多客户聊天室

上午1:52:伊万完成了https://github.com/prysmaticlabs/prysm/pull/6898

2:00上午:特伦斯和512验证测试拉请求号6898本地。

2:20 AM:根据捕获的调试日志,“滴答”服务器已经在一段时间内报告了24小时后的时间。

2:27:劳尔联系了普雷斯顿。普雷斯顿将在一小时后回来制作新版本。同时,我们将发布码头工人的形象。

普雷斯顿指出紧急维修是不够的。我们需要取消毛坯时钟同步作为默认项目。

2:42am: Raul开始调查Kibana,并使用fluentd中的过滤器分析来自roughtime的调试日志响应。

2:43am: terence交叉检查了信标链命名空间中所有pod的kubectl日志。不出所料,pod确实存在粗时时钟偏移问题。

上午2:46:劳尔向公关6898提交了正确的维修计划

上午3:05:劳尔确认修复程序可以使节点在本地工作。如果存在时钟偏移,修复程序将生成一个警报日志,但不会尝试根据roughtime服务器更新时间。

凌晨3:08:特伦斯在我们的不和谐频道上向大家宣布:“普雷森节点出现粗时响应错误,应急措施未能达到预期效果。我们已经发现了故障,将很快进行紧急修复,并在1小时内推出新版本。在即将推出的新版本中,roughtime时钟同步将不再是默认项目。”

上午:18:成功地建立了风筝单元测试、规格测试和码头工人形象。E2e测试还没有完成。普雷斯顿已经准备好开始在线流程。

:22am:生成新版本:https://github.com/prysmaticalbs/prysm/commit/d24f 99d 66 db 22691 b 69 c 76 BC 57 c 7509 e 7 F3 ba 8fe。特伦斯证实,这种方法可以修复其验证节点。Preston开始用新的docker映像依次重新启动我们的有状态集合中的PODs。群集验证器将根据新镜像进行更新(临时磁盘未被保留)。

3:34上午:Docker图像被标记为阿尔法21版本,它具有良好的稳定性和二进制文件已经建立

上午3:34:监控状态集中pod的健康状态,以确保滚动更新成功

3:36上午:使用新的码头工人图像滚动和启动我们的验证器吊舱。

上午4:29:检查日志中返回的延迟值。平均而言,这些值似乎都低于0.1秒。延迟不是调查的关键指标。准确地说,“中点”是需要研究的地方。注:下表中的时间是太平洋标准时间。https://kibana . pry labs . network/goto/e5f 5f 64 a 4426 c 85 AE E1 d 76 ABC 2d 994 be

-图像源:@ prestonvanlone . eth-图像源:@ prestonvanlone . eth-

上午5:32:检查高于2秒的偏移。从该数据可以看出,在持续90分钟的全局故障期间,Prylabs的块外节点的偏移约为14000秒。注:下表中的时间是太平洋标准时间。https://kibana . pry labs . network/goto/6 ce 2d 73 c 13 c 0 eef 600 b 604 fee 6 D8 F4

-图像源:@ prestonvanlone . eth-图像源:@ prestonvanlone . eth-

上午4:41:从普罗米修斯报警系统关于平均偏移的数据中,我们可以清楚地看到北京时间上午1:30到2336045之间存在时钟偏移问题,然后偏移开始下降并恢复正常。

(图片无法复制,请到原文观看)

上午4:52:立即调查结束。这个时钟偏移故障显然已经结束,并且已经发布了修复。已更新的节点将立即恢复,而未更新的节点将需要在一段时间后恢复。监测系统显示,核查员的参与度正在逐步提高。

上午6:20:用户报告惩罚保护机制已启动。这是因为先前的时钟偏移导致验证器提前4小时提出块并生成见证消息。为了避免被没收,Prysm验证器没有继续提出无效块。

上午8:13:再次失败

上午8:13:尼尚特注意到6898号公共关系中有严重的缺陷。只有当粗略功能标志打开时,用户才能设置其功能。

8:16am: Preston更新了“最新”二进制文件以指向alpha 20版本进行临时回滚,并建议用户回滚到alpha 20版本。我们现在正在等待合并PR 7004作为阿尔法22的候选。

上午8:45:值班团队正在评估是否扩展热状态缓存的大小,以便alpha 22版本可以使网络重新启动,从而更快地完成数据块。目前,默认的热状态缓存大小是8个时期,但是自最后一个块被最终确定以来,Medalla测试网络已经通过了近100个时期。

9:12上午:轮班团队决定将默认缓冲区大小更新为64个纪元,并通过功能标签进行配置。经过初步测试,可以将内存使用量增加1.5G。在网络重新启动以完成数据块后,可以调整缓冲区大小。

9:57上午:所有的实验室验证器节点都生成了将被没收的见证消息。紧急修复删除了Prylabs验证器节点的本地存储。没有运行中的外部惩罚保护机制。细节尚待确认.1024名核查员中至少有800人已经或将被没收。

上午10:37:许多用户报告说他们无法同步区块链。目前,网络中有太多的节点需要同时同步。阿尔法22版本已经延期,需要进一步通知。

上午10:46:pry labs团队认为现在最好的方法是等待。用户应该运行阿尔法20或最新的码头工人图像。

经验教训

2:12上午:困难的同步问题正在调查。

上午11:36:尼桑特和维克多发布了初始同步修复。请参见拉取请求7012。

哪里出了问题

1:51上午:合并和拉PR号7012。一些用户报告同步成功。普瑞斯玛蒂实验室开始在数据块节点部署7012。

上午5:15:从委员会0be 1957 c 2897909 b 943 b 80 FD 028 f 5346 E6 CDE 6开发阿尔法22版本

5:33am: Alpha22版本发布。链接:https://github。com/prysmaticalbs/prysm/releases/tag/v 1 . 0 . 0-alpha . 22

上午5:40:通过不和谐频道宣布阿尔法22版本的发布。Prysmatic的轮班团队继续监控同步优化。同时,越来越多的用户同步到最新的块。

上午12:53:阿尔法23版本在线,消息已经在不和谐频道上公布。阿尔法23包含一些同步修复,这有望解决棉兰测试网络的问题。建议用户在运行时打开“- dev”标签以获得更好的体验。

原始链接:

https://docs . Google.com/document/d/11 rmitnrui10 clcy oxy6 B1 inczzkq 30 geu 6 beg 3 ewfk/edit #

作者:保时捷实验室

翻译校对:敏敏一建

Title