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

Prysm 開發者發布了事後分析報告，解釋了 12 月 4 日威脅以太坊網絡穩定性的 Fusaka 主網事件。

共識客戶端在處理特定證明時因昂貴的狀態重新計算而遭遇資源耗盡，導致驗證者面臨嚴重的運營問題。

這個漏洞在 2025 年 12 月 4 日 21:49（UTC +8：05:49）Fusaka 在區塊時代 411392 啟動後立即出現。

隨著驗證者參與率驟降到 75%，網絡錯過了 41 個區塊時代，導致大約 382 以太坊（ETH）的證明獎勵損失。Prysm 開發者在 v7.0.1 和 v7.1.0 版本中實施永久修復之前，部署了緊急運行時標誌。

資源耗盡推動網絡走向最終性損失

技術故障集中在過時的歷史狀態上，這些狀態在受影響的節點上創造了拒絕服務條件。

Prysm 核心開發者 Terence Tsao 解釋說："歷史狀態在計算內存方面很重，節點可能會因大量並行發生的狀態重放而受到攻擊。"

運行 Prysm 的驗證者（約佔網絡驗證者的 15% 到 22.71%）面臨嚴重的性能下降。參與率從正常水平 95% 以上降低到 75%，使以太坊危險地接近失去最終性。

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

這樣的事件可能會凍結 Layer 2 匯總操作並阻止驗證者提款，直到開發者解決問題。

Fusaka 升級本身引入了 PeerDAS（Peer Data Availability Sampling）技術，旨在將 Layer 2 擴展的 blob 容量增加到八倍。

在 Prysm 漏洞出現之前，升級成功執行，沒有任何停機時間。

十個共識客戶端防止以太坊網絡崩潰

以太坊的客戶端多樣性架構防止了災難性故障。雖然 Prysm 驗證者遇到困難，但包括 Lighthouse、Nimbus 和 Teku 在內的其他十個共識客戶端繼續不間斷地驗證區塊。

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

以太坊基金會迅速為 Prysm 運營者發布了緊急指導。驗證者應用了臨時修復，而 Prysm 開發者則構建永久解決方案。

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