以太坊2.0主网事故回顾

https://beaconcha.in/epoch/32302

事故总结

自epoch 32302以来，信标链丢失了大量的块建议。由于Prysm在ETH2客户机中拥有最多的用户，因此问题最有可能发生在Prysm上。过了一会儿，我们在本地重现了这个错误。这实际上是一个与ETH1数据投票和验证器存放相关的已知问题。尽管这个问题以前已经向我们报告过，但我们不能复制这个bug并将其视为一个孤立的事件。而这个问题从来没有在任何一个测试网或主网中广泛传播过。这是这一问题首次导致区块提案失败。

在这18个时代，几乎所有的Prysm信标节点都不能产生新的块。32320恢复正常运行，大家普遍认为事故已经结束。然而，大约24小时后，事故再次发生，造成类似影响。

官方发布的事故事后分析报告已经出炉。请访问以下链接：https://docs.google.com/document/d/1nJr6_ bd-UnLBxvhT8lcRYdAZr69QdVQ3zJNUr3LgW-0/编辑

审查详细说明了事故发生的时间；本文分析了ETH2质押的根本原因，列举了ETH2质押人和参与人应注意的问题。

影响

一些初步数据显示，在第一次事故中，每个受影响的核查人员平均损失122950 Gwei（在编写本报告时为0.30美元）。事故发生后24小时内，同样的事故再次发生，每名受影响的核查人员损失约0.22美元。

一些关键事实：

➤ 没有验证者被罚款

➤ 它对信标链的终结没有影响

➤ 参与率仍然很高（最低点为84.8%）（编者按，这一数据与Ben Edgington撰写的最新一期ETH2进度更新不同）

➤ 不管客户端类如何，大多数验证器都会丢失两到三个证书

这不像是恶意或故意攻击

经过整个团队大约30个小时的努力，我们诊断出了根本原因，并在UTC时间4月25日早上6点为所有Prysm节点部署了修复版本。在节点完全升级之前，类似的事故还是最后一次发生。在给了足够的时间升级客户端后，这种事故没有再发生，有证据表明问题已经完全解决。

问答

成为验证者的捷径

这次事故会不会削弱人们对ETH2的信心？

不能。此次事故没有导致共识失效，与ETH2主网规模相比，事故影响范围非常小（第一次事故中，每个受影响的验证者平均损失约0.3美元）。ETH2自创世以来一直非常强大，验证者的参与率很高，每个时代都已经敲定。从我们的角度来看，故障解决后，网络有能力恢复到完美状态，这增强了社会各界对以太坊抗灾能力的信心。

这次事故会不会削弱人们对普赖马特实验室团队的信心？

我们对这起事故的反应和解决方法与ETH2测试网的故障处理完全不同。事故发生后，我队立即排除了错误信息；定量影响；当等待解决方案时，它会给验证者一个明确的响应步骤。此外，只有在我们完全确定解决方案后，我们才会让您升级客户端版本。值得注意的是，由于Prysm客户端是以太坊2.0网络中用户比例最大的软件，任何一个bug都可能导致更严重的问题。

对于核心开发人员来说，他们工作的关键是“绑定复杂性”。像ETH2这样的分布式系统有如此多的变量，以至于每个团队都尽一切努力来减少bug的可能性。当然，这个软件中的bug是不可避免的，我们承认prymatic实验室确实出了问题。但我们希望展示我们团队解决问题的动机和能力，并为验证者平衡速度和准确性的问题。

事故根本原因总结

ETH2和ETH1松散连接。ETH2只需要ETH1来验证验证者的存款验证。换句话说，即使验证器对垃圾数据进行投票，ETH2 POS链也可以继续运行。唯一会受到影响的是，在POS链再次对正确的ETH1数据进行投票之前，无法添加新的验证者存款。这种“投票”是在“投票周期”中进行的，目前在主网络上设置为64个时段（约6.8小时）。

投票方法是一个简单的“绝对多数”原则，ETH2验证器规范对此进行了解释。不幸的是，普赖斯特在运用这一原则（以绝对多数投票）时失去了一些有效性。在这次事故中，由于Prysm中的一个bug，一个块提议者创建了一个完全无效的ETH1存放树根，而其他Prysm节点首先找到了块提议。然后，他们有效地投了赞成票，因为Prysm客户遵循简单的“绝对多数投票”原则，没有明确的核实。

然后，所有的Prysm节点“滚雪球”为无效信息投票，导致区块支持者无法将带有存款的区块打包到链中。这是因为这些存放不会验证节点的ETH1存放树根，因此阻止建议将失败。投票期过后，问题会自动解决，但如果错误没有修复，问题还会再次发生。

实际上，这次ETH1 deposit data树根无效的根本原因是deposit cache初始化中有一个bug，但是只有部分使用Prysm客户端的信标节点受到影响。这导致这些节点生成错误的存款树根，而其他Prysm节点对其进行了投票，从而导致了事故。

事件时间线

注意，以下是技术细节！你可以跳到下一节，阅读解决方案和事故教训。

阻止建议失败

时代32302开始失去阻止建议。

Nishant通知了小组并召开了全体会议。随后，我们通过主网的本地信标节点再现了事故，并开始调查。

根据调查，普赖斯对奇怪而错误的ETH1矿床树根进行了投票

我们注意到，Prysm的节点在奇怪的树根上投票，该树根用于验证POS链中验证者的存款契约的存款完整性。在公共浏览器上查看原始块提议者的历史信息后（为了保护验证者，我们不披露他的身份），我们推断这不是攻击。

排除法

最初的疑问是关于Prysm如何在验证器建议的代码路径中处理ETH1数据投票。特别是，我们试图排除一些问题：

1；把沉积物打包成块有问题吗？

2；对存款日志信息的访问是否与ETH1信息混合或不确定？

3；我们的默克尔树有问题吗？

在接下来的16个小时左右，我们花了很多时间一起诊断潜在的问题。我们梳理了代码行，试图通过单元测试再现失败过程，并尝试了各种方法。尽管我们已经有了一个潜在的解决方案，但由于缺乏信心，我们对发布修复程序感到紧张。

更合理的根本原因

以前，在处理ETH2测试网络中的bug时，我们学到了一些经验教训。仅仅对根本原因有信心是不够的。在高风险情况下，在向用户宣布解决方案之前，我们需要有100%的信心。事故发生28小时后，我们坐下来问自己：“我们还不知道什么？我们还能要求什么使我们更接近失败的根本原因？”那么我们就知道了：

1；我们的稀疏Merkle树实现没有严重的bug，因为它使用主网络和Prater测试网络的存款来匹配lighthouse和protolambda的ETH2-zrnt实现。

2；我们用于从ETH1节点检索ETH1数据的代码路径没有错误，并且不会返回不正确的数据。

我们不知道的是：

1；无效存款的根源是如何产生的

2；为什么这个问题可以在某些节点上重现，而不能在其他节点上重现

3；为什么Prysm节点在确定区块中的沉积量时会出现“逐个关闭”错误

解决问题

为了回答这些问题，我们查看了初始化存款树的代码路径。研究发现，为了避免出质人每次启动验证者节点时都要下载验证者的所有存款记录，在验证的早期阶段增加了一个缓存层。此外，我们还添加了一个新功能—在客户端中，可以从嵌入式Genesis状态启动Prysm。在填充缓存时，存款树的错误默认值会导致信息损坏

问题的根源

如果我们的存款树是空的，那么函数len（items）总是返回1。这意味着，当我们实际应该将lastreceivedmerkleindex的值设置为-1时，我们会将其设置为0。上面的代码将导致代码路径中的一些Prysm节点跳过并将第0个存款嵌入到树中。其余的代码基指向存款树实现的这个奇怪部分，而不是这个代码路径。

为了验证这个假设，我们尝试使用protolambda提供的测试夹具尽可能多地复制代码路径。我们直觉上错过了将第0个存款嵌入存款树。当然，我们可以在重复测试中找到问题的根源！然后，我们在代码路径周围添加一个条件，以避免该条件再次出现，并准备启动最终的修复版本。

解决问题

根本原因总结

➤ Prysm将ETH1数据保存在磁盘上，以防止用户每次重新启动进程时都必须请求验证者的存款合同日志。

➤ 如果节点重新启动并将ETH1数据保存在磁盘上，我们将从这些数据初始化存款缓存。但是，由于我们的稀疏Merkle树（SMT）辅助包的工作方式与从磁盘上的数据初始化此缓存的代码路径不同，因此我们将跳过将第0个存款嵌入存款树，从而导致无效存款的根源。此代码路径只影响那些自创建后就没有数据库的节点，这些节点后来被修复。

➤ 在官方规范中，Prysm节点遵循“绝对多数”原则实现ETH1数据投票算法，但Prysm没有完全实现算法的一些有效条件。Prysm节点以ETH1数据的绝对多数进行投票，ETH1数据引用现有的块根。这可能导致Prysm节点投票选择由有问题的存款树生成的存款树的哈希值，因为这些存款没有被验证。

➤ 由于网络中的大多数节点都是Prysm节点，由于Prysm节点在一段时间内不能在主网上生成块，因此用绝对多数原则对有问题的存放根进行表决的问题的滚雪球效应已经成为一个严重的问题。

➤ 一旦ETH1数据的投票周期被重置，Prysm节点就可以再次正确地提出块，直到将来遇到漏洞为止。

解决方案

北京时间4月25日星期天13:00，在经历了数小时的不确定性之后，我们发布了问题的解决方案。我们对这个解决方案充满信心，并且我们非常有信心在节点升级之后，这个问题不会出现在ETH2中。

吸收校训

➤ 在这种情况下，对我们的解决方案的信心以及与外部世界的谨慎沟通至关重要

当我们遇到ETH2的medalla测试网络事故时，我们学到了一个关于良好沟通价值的重要教训。每一次公众评论和语言的准确表达都会对活动的结果产生严重影响。在testnet事件中，我们认为一个直接的解决方案是通过公共通道告诉您“重新启动节点”。这个仓促的决定导致网络上的大多数节点离线，然后在一堆坏节点中争先恐后地寻找好节点与区块链同步。此外，我们很快发布了一个软件升级的热补丁，它没有100%的信心来解决这个问题。这给系统带来了更多的混乱，并导致节点运营商对解决方案产生怀疑。

相比之下，在新主网事故的整个过程中，我们一直注重细致准确的沟通。此外，直到我们对问题的根本原因和解决方案有100%的信心，我们才发布热补丁。

耐心和冷静有助于解决问题**

我们的团队在过去几年里一直在构建ETH2，并学会了如何在逆境中保持冷静。我们认为，保持冷静，经常沟通状态报告，确保团队在解决问题的过程中感受到支持和积极反馈是非常重要的。我们可以花时间收集尽可能多的证据，并与我们的用户仔细合作，我们将成功地解决这个问题。更重要的是，我们从一开始就花时间量化事件的影响，以减少出质人的担忧和信息的缺乏。这一课对于在高压力和睡眠不足的情况下工作非常重要。放慢脚步，以正确的方式解决问题，不惜一切代价避免让事情变得更糟。

➤ * * ETH2测试网络不等于主网**

对于Prysm客户端，我们在公共ETH2测试网络中对Prysm的预产品候选版本进行了广泛的测试和监视。Prater和Pyrmont测试网络是用户在加入ETH2主网之前测试设置的好工具。然而，在这些测试网络中，四个产品级ETH2客户机的比例接近平均水平，也就是说，没有一个客户机在验证器中占有很大的份额。不幸的是，这可能没有考虑到大多数人使用客户端时出现的漏洞。未来，prymatic实验室将在靠近主网络或50%的prymatic网络节点的环境中进行内部测试。

此外，我们建议其他客户也在自己的内容测试中加入这样的环境，这样当他们成为大多数客户时，也可以了解自己客户的潜在问题。

出质人该怎么想

为什么要用普瑞斯客户做抵押

https://launchpad.ETHereum.org

人们选择经营普瑞斯，因为从一开始，我们的团队就致力于让他们更容易参与以太坊的承诺。我已经和我们的用户谈过很多次了。很多人选择一个客户并不是因为微优化或者与其他客户相比收入差异相对较小，而是因为我们让他们的体验更简单——好的文档，它总是为所有社区成员提供重要的帮助。ETH2对于初学者来说是可怕的，它的承诺充满了不确定性和风险。我们团队的使命是让用户知道我们在他们身边，无论他们的问题有多小，我们都会支持他们。特别是，我们关注的是可能不熟悉命令行和UNIX操作系统的普通抵押人。

在未来，您可以对我们的团队有以下期望：

➤ 提高实现规范条件的准确性，确保在编写任何代码之前对预设的有效条件进行充分的审查和质疑

➤ 我们不需要改进体验，但我们需要加倍努力，使普赖斯比今天高出许多倍，以便使用我们客户的抵押人能够更轻松地参与网络，包括改进网络界面。

➤ 普瑞斯将在ETH1ltgt；ETH2在合并之前提供了关键的功能和改进。

➤ 我们相信，健康的竞争能够形成一个强有力的激励机制来促进ETH的权益，并证明更多的人能够参与其中，因此更安全，因为所有的客户团队都在不断改进自己的软件

➤ 我们的团队致力于以最高的专业水准解决出质人可能遇到的问题。我们相信，我们会处理我们在路上可能遇到的任何问题，并向我们的社区保证，我们将使认捐人体验我们的首要任务。

➤ 最后，我们相信有许多重要的功能可以使Prysm成为ETH2更具吸引力的软件，我们将继续朝着这个目标迭代

➤ Prysm对验证者的收入进行了一些高级优化，并没有将其设置为所有出质人的默认起点。我们相信，这些职能释放后，普利司曼的抵押人将看到最高水平的收入。

回顾客户多元化对话

自从ETH2创建以来，我们听到的一个共同主题是客户多样性。ETH2是一个分布式系统，由来自世界各地的人作为验证者。不同的人使用不同的软件参与区块链的共识。如果某个软件出现严重问题，如果运行网络的客户端分布均衡，影响会更小。

早在今年1月，莱昂纳多·鲍蒂斯塔·戈麦斯就发布了一份数据分析报告，结果显示，实际的Prysm节点占网络的65%。这一事件也表明，普赖斯特核查占了大多数今天。

https://github.com/leobago/BSC-ETH2/tree/master/armiarma

我们建议您客观地看待每个客户机：它的软件、它的社区和它的弹性，然后决定哪个软件和它背后的团队最适合您的需求。如果ETH2客户机缺少对您重要的内容，我们强烈建议您以不选择其客户机为理由发出函数请求。Prymatic实验室将继续致力于帮助您参与以太坊网络，推动区块链软件的发展。