通俗バージョン：簡単に「翻訳」して、技術プロが @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の型システムは厳格ですが、明示的な型変換（explicit casting）操作については、依然として開発者の正しい判断に依存しています。プログラムがu256からu64への型変換を積極的に実行する際、コンパイラはこれが意図的な設計なのか論理的なエラーなのかを判断できません。また、このセキュリティインシデントは、コンセンサスメカニズム、トランザクション処理、状態管理など、Suiの中核的な基盤機能とは無関係です。 Sui Networkは、Cetusプロトコルによって送信されたトランザクション指示のみを忠実に実行し、この脆弱性はアプリケーション層プロトコル自体の論理的な欠陥に起因します。言い換えれば、どんなに進んだプログラミング言語でも、アプリケーション層の論理エラーを完全に防ぐことはできません。Moveはほとんどの基盤のセキュリティリスクを回避できますが、開発者によるビジネスロジックの境界チェックや数学演算のオーバーフロー保護を代替することはできません。そうです：プロとさらにコミュニケーションを取りましたが、以前の @CetusProtocol のハッキング攻撃に関する技術分析には具体的な詳細において誤差がありましたので、ここに訂正いたします。以前、これは数学的計算のオーバーフローに関する脆弱性であることを正確に特定しました。攻撃者は特殊な数値を構築することで、「小さな投資で大きなリターン」を得るという核心的な論理は正しいです。また、皆さんが関心を持つMove言語の安全性に関する疑問への回答も正しいです。数学計算の誤りの現象を見ただけで、型変換の問題だと推測しましたが、実際には他の関数の境界チェックの問題でした。実際、Move言語はu256からu64などへの型変換に対して厳格な審査メカニズムを持っており、この種の明示的な変換は通常、安全チェックが行われます。具体的な脆弱性の位置と技術的実装メカニズムは修正が必要です。本当の問題は`get\_delta\_a`関数のオーバーフロー検査メカニズムが無効になったことにあります：1）関数の作用：指定された流動性を追加する際に必要なトークンAの数量を計算する。2）重要な欠陥：`checked\_shlw`関数のオーバーフローチェックにエンコードエラーがあり、無効な大流動性値を防ぐことができませんでした；3）攻撃利用：ハッカーは特別な流動性値を構築し、無効チェックを回避し、最終的に`div\_round`の切り上げメカニズムを通じて、必要なトークンAの数を14に変えます。攻撃効果：1つのトークンAを使って巨額の流動性を鋳造し、その後資金プールを抜き取る。
Cetus Protocolに対するハッカー攻撃事件の技術プロによる分析を解読する
通俗バージョン：簡単に「翻訳」して、技術プロが @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の型システムは厳格ですが、明示的な型変換（explicit casting）操作については、依然として開発者の正しい判断に依存しています。プログラムがu256からu64への型変換を積極的に実行する際、コンパイラはこれが意図的な設計なのか論理的なエラーなのかを判断できません。
また、このセキュリティインシデントは、コンセンサスメカニズム、トランザクション処理、状態管理など、Suiの中核的な基盤機能とは無関係です。 Sui Networkは、Cetusプロトコルによって送信されたトランザクション指示のみを忠実に実行し、この脆弱性はアプリケーション層プロトコル自体の論理的な欠陥に起因します。
言い換えれば、どんなに進んだプログラミング言語でも、アプリケーション層の論理エラーを完全に防ぐことはできません。Moveはほとんどの基盤のセキュリティリスクを回避できますが、開発者によるビジネスロジックの境界チェックや数学演算のオーバーフロー保護を代替することはできません。
そうです：
プロとさらにコミュニケーションを取りましたが、以前の @CetusProtocol のハッキング攻撃に関する技術分析には具体的な詳細において誤差がありましたので、ここに訂正いたします。
以前、これは数学的計算のオーバーフローに関する脆弱性であることを正確に特定しました。攻撃者は特殊な数値を構築することで、「小さな投資で大きなリターン」を得るという核心的な論理は正しいです。また、皆さんが関心を持つMove言語の安全性に関する疑問への回答も正しいです。
数学計算の誤りの現象を見ただけで、型変換の問題だと推測しましたが、実際には他の関数の境界チェックの問題でした。実際、Move言語はu256からu64などへの型変換に対して厳格な審査メカニズムを持っており、この種の明示的な変換は通常、安全チェックが行われます。
具体的な脆弱性の位置と技術的実装メカニズムは修正が必要です。
本当の問題は
get\_delta\_a関数のオーバーフロー検査メカニズムが無効になったことにあります：1）関数の作用：指定された流動性を追加する際に必要なトークンAの数量を計算する。
2）重要な欠陥：
checked\_shlw関数のオーバーフローチェックにエンコードエラーがあり、無効な大流動性値を防ぐことができませんでした；3）攻撃利用：ハッカーは特別な流動性値を構築し、無効チェックを回避し、最終的に
div\_roundの切り上げメカニズムを通じて、必要なトークンAの数を14に変えます。攻撃効果：1つのトークンAを使って巨額の流動性を鋳造し、その後資金プールを抜き取る。