是什么导致以太坊的 Fusaka 升级失败？Prysm 事后分析揭示原因

Prysm 开发者发布了一份事后分析，解释了2025年12月4日 Fusaka 主网事件对以太坊网络稳定性的威胁。
总结

• Fusaka 之后的 Prysm 存在一个 bug，导致验证者参与度降至75%。
• 网络错过了41个 epoch，损失大约382 ETH的证明奖励。
• 多样化的客户端和快速修复使以太坊避免了终结性丧失。

共识客户端在处理特定确认时因昂贵的状态重计算导致资源耗尽，造成验证者面临严重的操作问题。

该 bug 在 Fusaka 于2025年12月4日 UTC 21:49 在 epoch 411392 激活后立即暴露。

由于验证者参与度暴跌至75%，网络错过了41个 epoch，导致约382 ETH的证明奖励损失。 Prysm 开发者在推出永久修复版本 v7.0.1 和 v7.1.0 之前，部署了应急运行时标志。

资源耗尽促使网络接近终结性丧失

技术故障集中在过时的历史状态上，这些状态在受影响节点上造成了拒绝服务（DoS）条件。

Prysm 核心开发者 Terence Tsao 解释说：“历史状态占用大量计算内存，节点可能被大量同时发生的状态重放攻击所 DoS。”

运行 Prysm 的验证者，占网络验证者的约15%到22.71%，性能严重下降。从正常的95%以上的参与率骤降至75%，使以太坊处于濒临失去终结性的危险边缘。

如果这个 bug 影响的是像 Lighthouse 这样的其他共识客户端而不是 Prysm，网络可能会彻底失去终结性。

这种事件可能会冻结 Layer 2 滚动的操作，并阻止验证者提款，直到开发者解决问题。

Fusaka 升级本身引入了 PeerDAS (Peer Data Availability Sampling) 技术，旨在将 Layer 2 扩容的Blob容量提升八倍。

在 Prysm bug 曝光之前，升级已成功执行，无任何停机。

十个共识客户端避免了以太坊网络崩溃

以太坊的客户端多样化架构避免了灾难性失败。尽管 Prysm 验证者陷入困境，另外十个共识客户端包括 Lighthouse、Nimbus 和 Teku 继续不间断验证区块。

去中心化的客户端结构意味着在整个危机期间，大约75%到85%的验证者保持正常操作。这防止了终结性丧失，并使网络在 Prysm 状态恶化的情况下仍能处理交易。

以太坊基金会迅速发布了 Prysm 操作员的紧急指南。验证者应用了临时修复，而 Prysm 开发者则在构建永久解决方案。

到12月5日，网络参与度恢复到近99%，在事件发生后24小时内恢复正常运作。