台湾で一定の知名度を持つパブリックチェーンSuiは、台湾時間14日深夜にネットワークの停止状況を報告しました。公式によると、メインネットは一時的に正常に取引を処理できなくなり、一部の分散型アプリ（dApp）やブロックブラウザサービス（Slush、SuiScanなど）が一時的に接続不能や取引遅延の状態になる可能性があります。Sui Coreチームは直ちに対応に入り、問題の解明後に進展を外部に公表することを約束しています。
Suiのネットワーク停止状況
台湾時間14日深夜、Suiメインネットはネットワークのスタール（network stall）状態を示しました。公式は、メインネットが一時的に正常に取引を処理できなくなり、一部のdAppやブロックブラウザサービス（Slush、SuiScanなど）が一時的に接続不能や取引遅延の可能性があると指摘しています。Sui Coreチームは即座に対応し、問題の解明後にさらなる進展を公表することを約束しています。
また、これはSuiのメインネットが初めて全面停止した事例ではありません。2024年11月21日には、太平洋時間の深夜1:15から3:45まで、Suiメインネットが完全に停止し、すべての検証者ノードが同時にクラッシュループに入り、ネットワーク全体が取引処理不能となった事件がありました。この事件は、「高性能パブリックチェーンがスループットを追求する一方で、システムの安定性を犠牲にしているのか」という議論を引き起こしました。
(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分で済み、非常に高い協調性を示したと述べています。
この記事「Suiまた当機！公式：ネットワーク停止、メインネットは現在取引処理不能」最初に掲載されたのは鏈新聞 ABMediaです。
