事实证明，如果我们的存款树是空的，函数 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 中不会再出现。

吸取教训

在事件中，对我们的解决方案有信心和与外界的谨慎沟通是至关重要的 (责任编辑：admin)