此事故是否会削弱大家对 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 开始出现区块提议丢失的问题。 (责任编辑：admin)