Sui 又當機!官方:網路停滯,主網目前無法處理交易

Neo
分享
Sui 又當機!官方:網路停滯,主網目前無法處理交易

在台灣擁有相當程度知名度的公鏈 Sui,在台灣時間 14 號深夜傳出網路停滯狀況。官方指出,主網目前一度無法正常處理交易,部分去中心化應用(dApp)與區塊瀏覽器服務,包括 Slush、SuiScan 等,可能出現暫時無法連線或交易延遲的情形。Sui Core 團隊已即刻介入處理,並承諾將在問題釐清後對外公布進一步進展。

Sui 出現網路停滯狀況

台灣時間 14 號深夜,Sui 主網出現網路停滯(network stall)狀況,官方指出,主網目前一度無法正常處理交易,部分去中心化應用(dApp)與區塊瀏覽器服務,包括 Slush、SuiScan 等,可能出現暫時無法連線或交易延遲的情形。Sui Core 團隊已即刻介入處理,並承諾將在問題釐清後對外公布進一步進展。

值得注意的是,這並非 Sui 首次發生主網全面停擺。回顧 2024 年 11 月 21 日,Sui 主網曾在太平洋時間凌晨約 1:15 至 3:45 間完全停止運作,當時所有驗證者節點同時進入崩潰循環,導致整個網路無法處理任何交易。相關事件也引發市場對「高效能公鏈在追求吞吐量的同時,是否犧牲系統穩定性」的討論。

廣告 - 內文未完請往下捲動

(Sui 上線後首次停止出塊:開發者表示問題不大,隔天 Franklin Templeton 宣布合作關係)

回顧上次當機主因:擁堵控制程式碼觸發驗證者崩潰

根據官方技術說明,2024 年 11 月的停擺事件,源自 Sui 擁堵控制(congestion control)模組中的一段 assert! 檢查邏輯。當特定條件同時成立時,會直接導致所有驗證者節點崩潰,進而使整個網路陷入停滯。

觸發條件包括:

  • 擁堵控制機制啟用 TotalGasBudgetWithCap 模式
  • 網路接收到一筆交易,具備「可變共享物件作為輸入」
  • 該交易未包含任何 MoveCall 指令
  • 在上述條件疊加下,驗證者會於成本計算流程中發生異常,導致同步崩潰。

什麼是擁堵控制?Sui 高效能設計的必要配套

Sui 採用物件導向(object-centric)的帳本模型,允許大量交易並行執行,這也是其高吞吐量的重要基礎。然而,若多筆交易同時嘗試寫入同一共享物件,仍必須依序處理,容易形成效能瓶頸。

因此,Sui 引入擁堵控制機制,限制單一共享物件在單位時間內可被處理的交易數量,以避免系統被少數高頻共享物件拖慢。先前 Sui Foundation 亦曾在與 XueDAO 合作的線下讀書會中說明,其核心邏輯是將具有因果關係的交易進行分組與批次執行。

近期 Sui 對該機制進行升級,新增 TotalGasBudgetWithCap 模式,用於更精準地評估交易計算成本與複雜度。不過,該模式中的程式邏輯漏洞,正是導致當次主網停擺的關鍵。

Sui 團隊在確認問題後迅速提交修補程式(PR #20365),並推出主網 v1.37.4 與測試網 v1.38.1 更新版本。官方指出,在修復版本釋出後,驗證者社群高度配合升級,從修補發布到網路全面恢復,僅花費約 15 分鐘,展現相當高的協作效率。

風險提示

加密貨幣投資具有高度風險,其價格可能波動劇烈,您可能損失全部本金。請謹慎評估風險。