Starknet又宕机了：执行层与证明层打架，18分鐘活動被回滾

以太坊L2網路Starknet在本週一發生主網宕機，根據1月11日發布的事後分析報告，這次事故源於執行層(blockifier)與證明層之間的狀態不一致。在特定的跨函數調用與回滾組合場景下，執行層錯誤記錄了已被回滾的狀態寫入，導致交易執行異常。雖然相關交易未獲得L1最終性確認，但事件觸發了區塊重組，約18分鐘的鏈上活動被回滾。更值得關注的是，這已經是Starknet在2025年以來第二次重大中斷事件。

技術細節：執行層vs證明層的"不同步"

事故的根本原因

這次宕機的技術原因相對複雜。Starknet的架構涉及兩個關鍵層級：執行層負責處理交易邏輯，證明層負責生成零知識證明並提交到以太坊主網。在這次事故中，當特定的函數調用和回滾操作組合出現時，執行層(blockifier)錯誤地記錄了一個本應被回滾的狀態寫入，這導致了兩個層級之間的狀態衝突。

好消息是證明層正確地識別了這個錯誤，拒絕了這筆有問題的交易，未將其提交到帳本。這個"自我糾正"機制防止了錯誤狀態被永久化到以太坊主網。

為何需要重組

由於執行層和證明層的不一致，網路被迫進行區塊重組來恢復正常狀態。這次重組導致約18分鐘的網路活動被回滾，使用者需要重新提交交易。對於非時間敏感的交易影響較小，但對於頻繁交易者或需要快速執行的操作（比如緊急平倉）來說，可能造成實際損失。

歷史對比：問題越來越頻繁

雖然這次回滾時間更短（18分鐘vs1小時），但頻率問題開始顯現。從9月到1月，Starknet在不到半年內經歷了兩次重大中斷，且故障類型不同，反映出系統在不同層級都存在潛在風險。

團隊的因應與承諾

立即行動

Starknet團隊在發布事後分析報告的同時，做出了幾項承諾：

• 加強程式碼測試流程，特別是針對邊界條件和複雜場景的測試
• 強化程式碼審計機制，防止類似的狀態不一致問題
• 根據相關資訊，Starknet計畫推出v0.14.1版本，包含哈希函數升級和更快出塊等優化

這些措施表明團隊在主動改進系統穩定性，但能否有效防止未來的故障仍需時間驗證。

對生態的影響評估

使用者層面

這次事故的實際影響相對有限，因為：

• 回滾時間較短（18分鐘），受影響的交易數量相對較少
• 交易未獲得L1最終性確認，所以沒有資金真正丟失
• 使用者主要需要重新提交交易，而不是面臨資產損失

生態層面

但從更大的角度看，頻繁的宕機事件對Starknet的生態發展構成挑戰：

• 降低使用者對網路穩定性的信心
• 可能影響DeFi應用的部署意願
• 與其他L2專案（如Arbitrum、Optimism）的競爭中處於劣勢

值得注意的是，根據相關資訊，Starknet正在積極拓展應用場景，比如與Noon合作推出比特幣Vault、與AlchemyPay等專案合作。這些生態建設能否抵消穩定性問題帶來的負面影響，是接下來需要觀察的重點。

總結

Starknet的這次宕機事故反映了L2網路在複雜場景下的技術挑戰。與其說這是一個嚴重的安全漏洞，不如說是系統在邊界條件處理上的不足。證明層的"自我糾正"機制有效防止了資金損失，但頻繁的中斷問題不能忽視。

關鍵是看Starknet的改進措施是否真正有效。加強測試和審計是必要的，但能否從根本上解決這類問題，還要看後續版本的表現。對於生態參與者來說，在信任Starknet的同時，也需要關注其穩定性的改善進展。