以太坊 2.0 主网事故回顾

雍和比特币 https://beaconcha.in/epoch/32302事端概要 从 epoch 32302 开端，信标链丢掉了许多区块提议。由于 Prysm 是 Eth2 客户端中用户最多的，因而问题最有或许呈现在 Prysm 上。一段时刻之后，咱们在本地重现了该过错。这其实是咱们已知的一个与 eth1 数据投票和验证者存款相关的问题。虽然之前现已有人向咱们陈述过此问题了，可是咱们无法重现这个 bug 并将其视为孤立事情。而且这个问题从未在任何测验网或许主网中广泛传播过。这是该问题初次导致区块提议失利事端。在这 18 个 epochs 内，简直全部 Prysm 信标节点都无法出产新区块。Epoch 32320 又开端正常运转了，其时咱们普遍认为该事端现已完毕了。可是大约 24 小时后，该事端再次发生，构成了相似的影响。关于此事端的正式过后剖析陈述已发布，拜访链接检查：https://docs.google.com/document/d/1nJr6_bd-UnLBxvhT8lcRYdAZr69QdVQ3zJNUr3LgW-0/edit该回忆具体介绍了事端的时刻线；剖析了底子原因以及列出了 Eth2 质押者和参加者需求留意的问题。影响 一些开端数据标明，第一次事端中，每个受影响的验证者均匀丢掉 122950 gwei (按文章攥写时的价格核算为 0.3 美元)。而该次事端发生的 24 小时内，又发生了第2次相同的事端，每个受影响的验证者丢掉约为 0.22 美元。一些要害实际：

• 没有验证者被罚没
• 对信标链的敲定没有影响
• 参加率仍是很高 (最低点也有 84.8%) （编者注，此数据与 Ben Edgington 编写的最新一期《Eth2 开展更新》有收支。)
• 大大都验证者丢掉 2 到 3 个证明，不论哪个客户端类
• 这次不像是一次歹意或成心的进犯

在整个团队经过大约 30 个小时的尽力之后，咱们确诊了其底子原因，并在 UTC 时刻 4 月 25 日早上 6 点为全部 Prysm 节点布置了修正版别。在节点没有彻底晋级之前，相似的事端仍发生了终究一次。给节点运转者满足的时刻晋级客户端之后，此类事端没有再发生过了，而且有依据标明该问题已得到彻底处理。问题解答 成为验证者的捷径此事端是否会削弱咱们对 Eth2 的决心？不会。该事端并没有构成一致失利，而且该事情的影响规划与 Eth2 主网的规划比较十分小 (在第一次事端中，每个受影响的验证者均匀丢掉约 0.3 美元)。自创世以来，Eth2 一向都十分强壮，验证者参加率十分高，而且每个 epoch 都完结了敲定。从咱们的视点来看，毛病处理了之后，网络有才能康复到完美运转的状况，反而增强了社区对以太坊的恢复才能的决心。此事端是否会削弱咱们对 Prysmatic Labs 团队的决心？咱们对此次事端做出的反响和处理办法与此前咱们处理 Eth2 测验网中的毛病时彻底不同。此次事端发生后，咱们团队立刻扫除了过错信息；量化影响；以及在等候处理方案时，给验证者们列出了清晰的应对进程。再者，咱们彻底确认了处理方案之后，才去让咱们晋级客户端版别。值得留意的是，由于 Prysm 客户端是以太坊 2.0 网络中用户占比最大的软件，因而呈现的任何 bug 都或许会引起更严峻的问题。关于中心开发者来说，作业的要害是要“束缚复杂性” (bound complexity)。比如 Eth2 之类的散布式体系具有如此多的变量，咱们每个团队都尽全部尽力以削减其出 bug 的或许性。当然，在这个的软件中，呈现 bug 是不可防止的，而且咱们供认，Prysmatic Labs 的确出错了。可是咱们期望能够展现出咱们团队处理问题的动力与才能，一同为验证者平衡速度和准确性之间的问题。事端底子原因总结Eth2 和 Eth1 链松散地连接着，Eth2 仅在验证者存款验证时需求用到 Eth1。也便是说，即便验证者对垃圾数据进行了投票，Eth2 PoS 链也能够持续运转。而唯一会影响到的事便是，新的验证者存款无法增加，直到 PoS 链再次对正确的 Eth1 数据进行投票。此“投票”是在“投票周期”中完结的，现在主网上将该周期设置为 64 epochs (大约 6.8 小时)。投票的办法为一个简略的“绝对大都”准则，Eth2 验证者标准中有解说其运作办法。不幸的是，Prysm 在实施该准则 (依照绝对大都准则投票) 时，丢掉了一些验证。该事端中，由于 Prysm 呈现了 bug，导致一名区块提议者创建了一个彻底无效的 Eth1 存款树根，而其他 Prysm 节点首要发现了该区块提议。随后，他们对此投了有用票，由于 Prysm 客户端遵从的是简略的“绝对大都投票”准则，而没有做清晰的验证。然后，全部 Prysm 节点”滚雪球“般地对无效信息投票，导致了区块提议者无法将具有存款的区块打包进链。这是由于，这些存款对节点的 Eth1 存款树根未进行验证，所以区块提议会失利。而在投票期完毕之后，该问题就主动处理了，但假如 bug 未修正，将再次呈现这种问题。实际上，这次呈现无效 Eth1 存款数据树根的底子原因是，存款缓存初始化中呈现了 bug，但仅影响了运用 Prysm 客户端的一部分信标节点。这导致这些节点出产过错的存款树根，而其他 Prysm 节点对其进行投票，然后构成了此次事端。事情时刻线 留意，下面是技术细节！咱们能够跳到下一部分，阅览处理方案以及该次事端带来的经验经验。区块提议失利Epoch 32302 开端呈现区块提议丢掉的问题。Nishant 通知了团队，并召开了全体会议。然后，咱们经过本地的主网信标节点重现事端，并开端了查询。查询显现，Prysm 对古怪的、过错的 eth1 存款树根投票咱们留意到 Prysm 的节点正对古怪的树根投票，该默克尔根用于验证 PoS 链中的验证者存款合约的存款完整性。在公共浏览器上检查了开端的区块提议者的前史信息之后 (为了维护该验证者，就不发布其身份了)，咱们揣度这并不是一同进犯事情。扫除法开端的怀疑是关于 Prysm 如安在验证者提议代码途径中处理 eth1 数据投票。尤其是，咱们企图扫除一些问题：1.打包存款进区块这里有问题吗？2.存款日志信息获取和 eth1 信息混了或许不确认吗？3.咱们的存款默克尔树呈现问题了吗？在接下来的 16 个小时左右，咱们花费了许多的时刻一起尽力确诊潜在的问题。咱们梳理了代码行，企图经过单元测验来重现毛病进程，并测验了各种办法。虽然咱们现已有了一个潜在的处理方案，咱们也因缺少决心而对发布修正版别而严峻。较合理的底子原因此前在处理 Eth2 测验网中的 bug 时，咱们得到了一些经验经验，光对底子原因有决心是不行的。在高危险的情况下，在向用户发布处理方案之前，咱们需求有 100% 的决心。在事端发生后 28 小时，咱们坐下来并问自己：”咱们还有什么是不知道的呢？咱们还能够问什么问题来让咱们更挨近发生毛病的底子原因呢？”然后咱们知道了以下几点：1.咱们的稀少默克尔树 (sparse merkle tree) 完成并没有严峻的 bug，由于它运用主网和 Prater 测验网的存款，与 Lighthouse 和 Protolambda 的 Eth2 zrnt 完成相匹配。2.咱们用于从 Eth1 节点检索 Eth1 数据的代码途径没有 bug，也没有回来不正确的数据。咱们不知道的有：1.无效的存款树根是坐山观虎斗发生的2.为什么这个问题在一些节点中是能够重现的，而其他节点不能够3.为什么 Prysm 节点在确认区块中的存款数量时，呈现了”off-by-one“过错修正问题为了答复这些问题，咱们看了初始化咱们的存款树的代码途径。成果发现，在前期增加了一个缓存层以防止质押者每次发动他们的节点时都必须下载全部验证者存款记载。此外，咱们增加了一个新功用——在客户端内部能够从一个内嵌的创世状况中发动 Prysm。在填充缓存时，咱们存款树的一个过错预设导致信息的讹谬：问题本源实际证明，假如咱们的存款树是空的，函数 len(items) 将一向回来 1。这意味着当实际上咱们应该把 lastReceivedMerkleIndex 的值设为 -1 时，咱们会把它设为 0。上面的代码会导致一些在该代码途径的 Prysm 节点跳过把第 0 笔存款嵌入到树里。咱们代码库的其他部分都指向问题出在咱们存款树完成的这个古怪部分，而不是这个代码途径。为了查验这个假定，咱们测验运用 Protolambda 供给给咱们的测验夹具尽或许地仿制代码途径。咱们直觉咱们漏了将第 0 笔存款嵌入到存款树。当然，咱们能够在一个可重复的测验中找到导致整个事情发生的、有问题的存款树根！然后，咱们环绕该代码途径增加条件，以防止该条件再次呈现，并预备推出终究确认的修正版别。问题处理 底子原因总结

• Prysm 把 eth1 数据保存在磁盘上，以防止用户在每次重启进程时都必须对验证者存款合约日志宣布恳求。
• 假如一个节点重启并把 eth1 数据保存在磁盘上，咱们会从这些数据初始化咱们的存款缓存，但由于咱们的稀少默克尔树 (sparse merkle tree，SMT) 帮忙程序包的作业办法与从磁盘上的数据初始化此缓存的代码途径不相同，咱们会跳过把第 0 笔存款嵌入存款树，构成无效存款树根。这个代码途径只影响那些创世以来还没有数据库的节点，后来被修正了。
• 在官方标准里，Prysm 节点遵从“绝对大都”的准则履行一个 eth1 数据投票算法，可是，Prysm 并没有彻底完成该算法的一些有用条件。Prysm 节点随绝对大都 eth1数据投票进行投票，该投票数据引证的是一个现存的区块根，这或许导致 Prysm 节点投票给一个由有问题的存款树生成的存款树哈希值，由于这些存款是未被验证的。
• 由于网络里大部分的节点都是 Prysm 节点，随绝对大都准则投票给有问题存款根这个问题的滚雪球效应开展成一个严峻问题，由于 Prysm 节点在随后一段时刻里无法在主网上生成区块。
• 一旦 eth1数据投票期重置了，Prysm 节点又能够正确地提议区块了，直到在未来又遇到该缝隙。

处理方案在北京时刻 4 月 25 日周日 13:00，在不确认性中折磨了多个小时后，咱们发布了对该问题的修正。咱们对这个处理方案有十足的掌握，并十分有决心在节点晋级后，该问题在 Eth2 中不会再呈现。汲取校训

• 在事情中，对咱们的处理方案有决心和与外界的稳重交流是至关重要的

当咱们遭受 Eth2 的 Medalla 测验网事端时，咱们上了关于杰出交流的价值的重要一课。每个公共谈论和言语的准确表达都会对事情的成果发生严峻影响。在测验网的事情里，咱们认为一个当即的处理方案是经过公共途径告知咱们“重启你们的节点”。这个草率的决议导致网络上大部分的节点都掉线了，然后力争上游在一堆坏的对等节点里找好的，以完成与区块链的同步。此外，咱们很快发布了一个没有 100% 决心能处理问题的软件晋级热补丁。这给体系带来更多的紊乱，并构成节点运转商对处理方案的疑虑。相较之下，在这次主网新事端的整个进程里，咱们一向留意稳重与准确的交流。别的，在咱们对问题的本源和处理办法有 100% 的决心之前咱们没有发布热补丁。

• 坚持耐性与镇定有助于处理问题

咱们团队经过了曩昔几年构建 Eth2 ，学到了如安在面临窘境时坚持镇定。咱们信任在处理问题进程中，坚持镇定、频频交流状况陈述、确保团队感受到支撑和正面的反应是十分重要的。咱们能够花时刻搜集尽或许多的依据，并与咱们的用户进行详尽的协作，咱们将成功处理这个问题。更重要的是，咱们在开端时就花时刻对事情影响进行量化，以削减质押者与因缺少信息而发生的担忧。这个经验对在高度严峻与睡眠不足的情况下作业十分重要。慢下来，用恰当的办法处理它，并不惜全部代价防止把问题弄得更糟。

• Eth2 测验网不等于主网

关于 Prysm 客户端，咱们在公共 Eth2 测验网中对 Prysm 产品前的候选版别进行了广泛的测验和监听。Prater 和 Pyrmont 测验网都是用户在参加到 Eth2 主网前用来测验他们的设置的好东西。可是，这些测验网都预设四个产等第 Eth2 客户端的占比是挨近均匀分的，即没有哪个客户端在验证者中有显着的大都比例。不幸的是，这或许没有考虑到当某个客户端为大大都人所运用时才会呈现的缝隙。在未来，Prysmatic Labs 会在一个更挨近主网环境、或一个 Prysm 网络节点 50% 的环境里进行内部测验网里进行测验。此外，咱们主张其他客户端也在它们自己的内容测验中参加这样的环境，在它们成为大大都客户端的时分，它们也能够了解自己客户端的潜在问题。质押者应该考虑什么 为什么运用 Prysm 客户端做质押https://launchpad.ethereum.org人们挑选运转 Prysm 时由于从一开端咱们团队现已专心于使他们参加以太坊质押的体会更简略。我与咱们的用户沟经过很屡次，许多人挑选一个客户端不是由于微观上的优化或与其他客户端比较相对小的收益不同，而是由于咱们使得他们的体会更简略——杰出的文档资料，一向给全部的社区成员供给重要的协助。关于新手来说 Eth2 是可怕的，质押也充溢不确认性和危险。咱们团队的任务是让用户知道咱们在他们身边，以及不管他们的问题多小都会得到咱们的支撑。特别地，咱们一向重视那些或许对命令行不太熟悉、不太了解 UNIX 操作体系的一般质押者。在未来，你能够对咱们团队有以下等待：

• 进步完成标准条件的准确性，确保预设和有用条件在任何代码被写入前都被充沛审阅和质疑
• 咱们不因要进步这个体会，还要加倍尽力，使 Prysm 比今日非难许多倍，使运用咱们客户端的质押者更简单参加网络，包含网页界面的改进。
• Prysm 将在研发方面加倍尽力，在 eth1 lt;gt; eth2 的兼并前供给要害的功用与改进。
• 咱们信任健康的竞赛能构成一个强壮的激励机制，推进 ETH 的权益证明能有更多人参加，也因而更安全，由于全部客户端团队都不断改进他们的软件
• 咱们团队致力于以最高的专业水准来处理和质押者或许会遇到的问题。咱们信任咱们做好处理咱们路上会遇到的任何问题，并向咱们的社区保证咱们会把质押者体会作为咱们的最高优先级。
• 终究，咱们信任还有许多重要功用能够使 Prysm 变成参加 Eth2 的、更有吸引力的软件，咱们将朝着这个方针不断迭代
• Prysm 有一些验证者收益的高档优化还没对全部质押者设为默许发动。咱们信任这些功用发布后，Prysm 的质押者会看到最高水平的收益。

回忆客户端多样性的对话 自 Eth2 创世以来，咱们一向听到的一个一起主题是客户端多样性。Eth2 是一个有世界各地的人作为验证者参加的散布式体系。不同人用不同的软件参加到区块链的一致里，假如某个软件呈现严峻问题，假如运转网络的客户端完成由一个平衡散布的话，影响会更小。Leonardo Bautista-Gomez 早在一月的时分发布了一份数据剖析，成果实际 Prysm 节点占网络的65%，此次事情也显现 Prysm 验证者在今日占了大大都。https://github.com/leobago/BSC-ETH2/tree/master/armiarma咱们主张你们客观地看待每个客户端：它的软件、它的社区、还有它的耐性，然后决议选哪个软件及其背面的团队是最适合你的需求的。假如某个 Eth2 客户端缺少了对你来说很重要的东西，者正式你不选他们的客户端的理由，咱们强烈推荐你提出一个功用恳求。Prysmatic Labs 会持续专心于协助你参加到以太坊网络，并推进区块链软件的鸿沟。假如你想交流和对本文由疑问的话，请参加咱们的Discord。参阅• 事情的交流 https://www.reddit.com/r/ethstaker/comments/mxpz57/regarding_the_recent_beacon_chain_incident/• 过后反省陈述 https://docs.google.com/document/d/1nJr6_bd-UnLBxvhT8lcRYdAZr69QdVQ3zJNUr3LgW-0/edit?usp=sharing• Medalla 测验网事情 https://medium.com/prysmatic-labs/eth2-medalla-testnet-incident-f7fbc3cc934ahttps://medium.com/prysmatic-labs/tagged/blockchain)原文链接：https://medium.com/prysmatic-labs/eth2-mainnet-incident-retrospective-f0338814340c来历 |Prysmatic Labs作者 |Raul Jordan