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 小时内，又产生了第二次相同的事端，每个受影响的验证者丢掉约为 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 <> 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 会继续专心于帮助你参加到以太坊网络，并推进区块链软件的边界。
视野开拓
…市场营销者正在逐渐将消费者从传统的公司网页吸引到能够提供更友好的感觉的产品和品牌的博客网页上。-《消费者行为学》
