近日 Sui 公鏈也面臨了暫時停止出塊的窘境,在經歷兩個半小時的停止出塊後,Sui 官方也發布了針對此事件的報告。不過主打高性能公鏈的 Sui 歷經停止出塊,也讓人聯想到先前幾年的 Solana。比較兩者,儘管在程式語言丶架構上都大大不同,但同樣主打高性能公鏈,卻也被詬病不夠去中心化等。
為何一段擁堵控制代碼引發了所有驗證者的崩潰
而根據官方聲明,此次停擺的原因在於 Sui 網路的擁堵控制 代碼中的一段「assert!」觸發了驗證者的崩潰。具體而言,當以下條件同時滿足時,會導致網絡崩潰:
- 擁堵控制啟用 TotalGasBudgetWithCap 模式。
- 接收到包含以下特徵的交易:一個可變共享物件作為輸入丶沒有任何 MoveCall 指令
當這樣的交易進入網絡,所有驗證者同時崩潰,網絡陷入停擺。
擁堵控制是什麼?
Sui 主網的物件導向架構允許大量交易並行處理,這是其實現高性能的方式。然而若多筆交易需寫入同一共享物件,仍需依序執行,且此類交易的處理速度受到限制。為避免共享物件造成的擁堵,Sui 引入擁堵控制機制以限制單個共享物件的交易速率。筆者補充:先前 Sui Foundation 在與 XueDAO 合作的線下讀書會中,提及其邏輯是將有因果關係的交易打包一同執行。
而近期 Sui 升級了擁堵控制系統,引入 TotalGasBudgetWithCap 模式以更精準地評估交易複雜度。不過,此模式的代碼中出現了導致本次事件的漏洞。Sui 團隊表示這次發現問題後即迅速採取行動,通過代碼修復推出了主網 v1.37.4 和測試網 v1.38.1 版本更新。驗證者社群展現了極高的響應效率,從修復發布到網絡恢復僅用了 15 分鐘。
Typus 協議:Sui 的停止出塊與 Solana 完全不同
Sui 的停止出塊不免讓人聯想到 Solana 甚至今年的 TON,對此 Sui 上的 DeFi 協議 Typus 的 CGO Kyrie 也在推特上分享團隊成員對此的看法,他直接地指出這與 Solana 的停止出塊是完全不同的事。因為 Solana 的問題是網路擁塞導致系統崩潰,要解決需要大規模架構改善,而這也表示 Solana 的問題短期內難以根本解決。而 Sui 這次是明確的技術問題,不影響系統基礎架構。
Kyrie 表示這次當機問題出在計算交易成本時的數值溢位 。簡單來說,就像計算機顯示位數不夠,數字太大時會歸零重新計算。系統在這種情況下陷入無限循環,最終導致整個網路停擺。
當系統計算的數值超過可以儲存的範圍時,原本的設計是超過範圍時會計算錯誤,導致系統一直重複運算。而 PR #20365 修正後設定了正確的計算上限,避免這種狀況發生。他也指出這次事件的關鍵在於:問題發生在交易成本計算的程式邏輯上,而不是 Sui 的共識機制或系統架構設計。這也解釋了為什麼修復能這麼快速且直接。
Franklin Templeton 與 Sui 宣布合作關係
在截稿前傳來一個消息,在停止出塊的隔天,Sui Foundation 宣布了與 Franklin Templeton 的合作關係。在聲明中 Franklin Templeton 點名了 Deepbook丶Karrier One 及 ika 這三個協議及基礎設施。不過根據 Franklin Templeton 在區塊鏈的操作,或許可以期待 Sui 這個物件導向,最注重安全性的公鏈與 RWA 的結合。
免责声明:本文提供的信息不是交易建议。BlockWeeks.com不对根据本文提供的信息所做的任何投资承担责任。我们强烈建议在做出任何投资决策之前进行独立研究或咨询合格的专业人士。