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。在填充缓存时，我们存款树的一个错误预设导致信息的讹误：

(责任编辑：admin)