是什麼導致以太坊的 Fusaka 升級失敗？ Prysm 事後分析揭示原因

Prysm 開發者發布了一份事後分析，解釋了2025年12月4日 Fusaka 主網事件，該事件威脅到以太坊網絡的穩定性。
摘要

• Fusaka 之後的 Prysm 漏洞導致驗證者參與度降至75%。
• 網絡錯過了41個時期，並損失約382 ETH的證明獎勵。
• 多元的客戶端和快速修復使以太坊避免了最終性喪失。

共識客戶端在處理特定見證時，由於昂貴的狀態重算，導致資源耗盡，令驗證者面臨嚴重的操作問題。

該漏洞在2025年12月4日UTC 21:49，Fusaka在第411392個時期激活後立即浮現。

由於驗證者參與度暴跌至75%，網絡錯過了41個時期，導致約382 ETH的證明獎勵喪失。Prysm 開發者在實施永久修復之前，部署了緊急運行時旗標，版本為 v7.0.1 和 v7.1.0。

資源耗盡推動網絡接近最終性喪失

技術失敗的核心在於過時的歷史狀態，這些狀態在受影響的節點上造成了拒絕服務（DoS）條件。

Prysm 核心開發者 Terence Tsao 解釋說：「歷史狀態是計算內存密集型的，節點可能被大量並行的狀態重放攻擊。」

運行 Prysm 的驗證者，占網絡驗證者約15%到22.71%，遭遇性能嚴重退化。參與度從正常的95%以上下降到75%，使得以太坊危險接近失去最終性。

如果此漏洞影響的是像 Lighthouse 這樣的其他共識客戶端而非 Prysm，網絡可能會完全失去最終性。

此事件甚至可能使 Layer 2 的 Rollup 操作凍結，並阻止驗證者提款，直到開發者解決問題。

Fusaka 升級本身引入了 PeerDAS (Peer Data Availability Sampling) 技術，旨在將 Blob 容量提高八倍，以支援 Layer 2 的擴展。

升級成功完成，沒有停機時間，直到 Prysm 漏洞出現。

十個共識客戶端保障以太坊網絡不倒

以太坊的客戶端多樣性架構避免了災難性失敗。在 Prysm 驗證者陷入困境時，還有包括 Lighthouse、Nimbus 和 Teku 在內的十個其他共識客戶端繼續驗證區塊，未受影響。

去中心化的客戶端結構意味著，大約75%到85%的驗證者在整個危機期間保持正常運作。這避免了最終性喪失，並使網絡在 Prysm 狀態降低的情況下仍能處理交易。

以太坊基金會迅速發布緊急指導，協助 Prysm 運營者應對。驗證者採用了臨時修復措施，而 Prysm 開發者則著手建立永久解決方案。

至12月5日，網絡參與度恢復至近99%，事件發生後24小時內恢復正常運作。