近日 Sui 公鏈也麵臨了暫時停止出塊的窘境，在經歷兩個半小時的停止出塊後，Sui 官方也發布了針對此事件的報告。不過主打高效能公鏈的 Sui 歷經停止出塊，也讓人聯想到先前幾年的 Solana。比較兩者，儘管在程式語言丶架構上都大大不同，但同樣主打高效能公鏈，卻也被詬病不夠去中心化等。

Table of Contents

為何一段擁堵控制代碼引發了所有驗證者的崩潰

報告中指出 2024 年 11 月 21 日凌晨，Sui 主網在太平洋時間約凌晨 1:15 至 3:45 經歷了一次全面停擺。所有驗證者進入崩潰循環，導致整個網路無法處理任何交易。此次事件突顯了高效能公鏈在提升效能同時，穩定性仍需高度關注。

而根據官方聲明，此次停擺的原因在於 Sui 網路的擁堵控制 (congestion control) 代碼中的一段「assert!」觸發了驗證者的崩潰。具體而言，當以下條件同時滿足時，會導致網絡崩潰：

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

1. 擁堵控制啟用 TotalGasBudgetWithCap 模式。
2. 接收到包含以下特徵的交易：一個可變共享物件作為輸入丶沒有任何 MoveCall 指令

當這樣的交易進入網絡，所有驗證者同時崩潰，網絡陷入停擺。

擁堵控制是什麼？

Sui 主網的物件導向架構允許大量交易並行處理，這是其實現高效能的方式。然而若多筆交易需寫入同一共享物件，仍需依序執行，且此類交易的處理速度受到限制。為避免共享物件造成的擁堵，Sui 引入擁堵控制機制以限制單個共享物件的交易速率。筆者補充：先前 Sui Foundation 在與 XueDAO 合作的線下讀書會中，提及其邏輯是將有因果關係的交易打包一同執行。

而近期 Sui 升級了擁堵控制系統，引入 TotalGasBudgetWithCap 模式以更精準地評估交易複雜度。不過，此模式的代碼中出現了導致本次事件的漏洞。Sui 團隊表示這次發現問題後即迅速採取行動，通過代碼修復(PR #20365)推出了主網 v1.37.4 和測試網 v1.38.1 版本更新。驗證者社群展現了極高的響應效率，從修復發布到網絡恢復僅用了 15 分鐘。

Typus 協議：Sui 的停止出塊與 Solana 完全不同

Sui 的停止出塊不免讓人聯想到 Solana 甚至今年的 TON，對此 Sui 上的 DeFi 協議 Typus 的 CGO Kyrie 也在推特上分享團隊成員對此的看法，他直接地指出這與 Solana 的停止出塊是完全不同的事。因為 Solana 的問題是網路擁塞導致系統崩潰，要解決需要大規模架構改善，而這也表示 Solana 的問題短期內難以根本解決。而 Sui 這次是明確的技術問題，不影響系統基礎架構。

Kyrie 表示這次當機問題出在計算交易成本時的數值溢位 (overflow)。簡單來說，就像計算機顯示位數不夠，數字太大時會歸零重新計算。系統在這種情況下陷入無限循環，最終導致整個網路停擺。

當系統計算的數值超過可以儲存的範圍時，原本的設計是超過範圍時會計算錯誤，導致系統一直重複運算。而 PR #20365 修正後設定了正確的計算上限，避免這種狀況發生。他也指出這次事件的關鍵在於：問題發生在交易成本計算的程式邏輯上，而不是 Sui 的共識機制或系統架構設計。這也解釋了為什麼修復能這麼快速且直接。

Franklin Templeton 與 Sui 宣佈合作關係

在截稿前傳來一個訊息，在停止出塊的隔天，Sui Foundation 宣佈了與 Franklin Templeton 的合作關係。在聲明中 Franklin Templeton 點名了 Deepbook丶Karrier One 及 ika 這三個協議及基礎設施。不過根據 Franklin Templeton 在區塊鏈的操作，或許可以期待 Sui 這個物件導向，最注重安全性的公鏈與 RWA 的結合。