在台灣擁有相當程度知名度的公鏈 Sui，在台灣時間 14 號深夜傳出網路停滯狀況。官方指出，主網目前一度無法正常處理交易，部分去中心化應用（dApp）與區塊瀏覽器服務，包括 Slush、SuiScan 等，可能出現暫時無法連線或交易延遲的情形。Sui Core 團隊已即刻介入處理，並承諾將在問題釐清後對外公布進一步進展。
Table of Contents
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 分鐘，展現相當高的協作效率。
風險提示
加密貨幣投資具有高度風險，其價格可能波動劇烈，您可能損失全部本金。請謹慎評估風險。
