人気バージョン:技術ボスによる@CetusProtocolハッカーの分析を解釈するための簡単な「翻訳」: この攻撃は、型変換中のデータの切り捨てに現れる古典的な整数オーバーフローの問題を明らかにします。 分解された技術的な詳細: 1)脆弱性の場所:問題はget_amount_by_liquidity関数のタイプ変換メカニズムで発生し、U256からU64へのキャスト変換により高レベルのデータ損失が発生します。 2) 攻撃プロセス: 1.攻撃者は、add_liquidity機能を通じて大量の流動性パラメータを渡します。 2. システムコールget_delta_b関数の計算に必要なBトークンの数。 3.計算プロセスでは、2つのU128タイプのデータを乗算し、理論的な結果はU256タイプである必要があります。 主な問題: 関数が戻ると、u256 の結果が u64 にキャストされ、その結果、高レベルの 128 ビット データが切り捨てられます。 3)利用効果:もともと大量のトークンを鋳造する必要があった流動性クォータが、ごく少数のトークンで完了できるようになりました。 攻撃者は、非常に低コストで大量の流動性を取得し、流動性の一部を破壊することでプールの裁定取引を実現します。 簡単に例えると、8桁しか表示できない電卓を使用して10億×10億を計算するのと同じように、20桁の計算結果には最後の8桁しか表示できず、最初の12桁は直接消えます。 攻撃者はこの脆弱性を悪用します。 誤解のないように言っておきますが、この脆弱性は@SuiNetworkの基盤となるセキュリティアーキテクチャとは何の関係もなく、Move言語のセキュリティの「栄光」は当分の間、まだ信頼性があります。 なぜでしょうか。 Move 言語には、リソース管理と型セキュリティの点で大きな利点があり、二重支払いやリソース漏洩などの低レベルのセキュリティ問題を効果的に防ぐことができます。 ただし、今回の Cetus プロトコルは、アプリケーション ロジックのレベルでは数学的エラーであり、Move 言語自体の設計上の欠陥ではありません。 具体的には、Moveの型システムは厳密ではあるものの、明示的なキャストについては開発者の正しい判断に依存しています。 プログラムが U256 から U64 への型変換をアクティブに実行する場合、コンパイラはこれが意図的なエラーなのか論理的なエラーなのかを判断できません。 また、このセキュリティインシデントは、コンセンサスメカニズム、トランザクション処理、状態管理など、Suiの中核的な基盤機能とは無関係です。 Sui Networkは、Cetusプロトコルによって送信されたトランザクション指示のみを忠実に実行し、この脆弱性はアプリケーション層プロトコル自体の論理的な欠陥に起因します。 率直に言って、高度なプログラミング言語をいくら使っても、アプリケーション層での論理エラーを完全に排除することはできません。 Move は、基本的なセキュリティリスクのほとんどを防ぐことができますが、ビジネスロジックの境界チェックや数学演算のオーバーフロー保護で開発者を置き換えることはできません。