技術的なバックグラウンドのチームは、基本的な「金融リスク嗅覚」が著しく欠けている。
作者: Haotian
@CetusProtocolのハッカーセキュリティ「レビュー」レポートを読んだ後、あなたは「興味深い」現象を見つけるでしょう:技術的な詳細は非常に透過的に開示され、緊急対応は教科書レベルですが、「なぜハッキングされたのか」という最も重要な魂の拷問は回避的であるようです。
報告はinteger-mateライブラリのchecked\_shlw関数のエラー検査（理論上≤2^192、実際には≤2^256）を大量に説明し、これを「意味の誤解」と定義しています。この説明は技術的に成立していますが、巧妙に外部の責任に焦点を当て、まるでCetusもこの技術的欠陥の無実の被害者であるかのようにしています。
integer-mate
checked\_shlw
問題が発生しました。なぜinteger-mateがオープンソースで広く使用されている数学ライブラリであるにもかかわらず、あなたのところで1つのトークンで天文学的な流動性シェアを得るという不合理なエラーが発生したのでしょうか？
ハッカー攻撃のパスを分析すると、ハッカーが完璧な攻撃を実現するためには、同時に四つの条件を満たす必要があることが分かります：誤ったオーバーフロー検査、大幅なビットシフト演算、切り上げルール、経済的合理性の検証の欠如。
Cetusは、すべての「トリガー」条件で「うっかり」していました。たとえば、ユーザーが2^200のような天文学的な数字を入力することを受け入れ、極度に危険な大幅な移動演算を行い、外部ライブラリのチェックメカニズムを完全に信頼し、最も致命的なのは——システムが「1トークンで天文学的なシェアを得る」という馬鹿げた結果を計算したとき、経済常識のチェックなしに直接実行してしまったことです。
したがって、Cetus が真剣に反省すべき点は以下の通りです：
1）なぜ汎用外部ライブラリのセキュリティテストが十分に行われていないのか？integer-mateライブラリがオープンソースで人気があり広く使用されているとはいえ、Cetusは数億ドルの資産を管理するためにそれを使用しながら、このライブラリのセキュリティの境界がどこにあるのか、ライブラリの機能が無効になった場合に適切な代替手段があるのかを十分に理解していなかったようです。明らかに、Cetusは最も基本的なサプライチェーンセキュリティ意識を欠いています；
2）なぜ天文学的な数字の入力が許可され、境界が設定されないのですか？DeFiプロトコルは分散化を目指すべきですが、成熟した金融システムはオープンであるほど、明確な境界を必要とします。
システムが攻撃者によって巧妙に構築された天文数字の入力を許可するとき、チームは明らかにこのような流動性の要求が合理的であるかを考慮していない。世界最大のヘッジファンドでさえ、このように誇張された流動性のシェアを必要とすることはできない。明らかに、Cetusチームは金融的直感を持つリスク管理の専門家を欠いている。
3）なぜ多回のセキュリティ監査を経ても問題が事前に発見されなかったのか？この言葉は無意識のうちに致命的な認識の誤りを暴露している：プロジェクト側はセキュリティの責任をセキュリティ会社に外注し、監査を免責の証明書と見なしている。しかし現実は厳しい：セキュリティ監査エンジニアはコードのバグを発見するのが得意だが、誰が天方夜譚のような交換比率を算出するシステムをテストすることが不適切かもしれないと考えるだろうか？
数学、暗号学、経済学におけるこの種の境界検証は、現代のDeFiセキュリティにおける最大の盲点です。 監査法人は、「これは経済モデルの設計上の欠陥であり、コードロジックの問題ではない」と言うでしょう。 プロジェクトチームは、「監査では問題は見つからなかった」と不満を漏らしました。 そして、ユーザーは自分のお金がなくなったことだけを知っています!
見てください、これは結局DeFi業界のシステム的な安全の弱点を暴露しています：純粋な技術的背景を持つチームは基本的な「金融リスクの嗅覚」が著しく欠けています。
Cetusのこのレポートを見る限り、チームは明らかに反省が不十分です。
今回のハッキング攻撃に関する技術的な欠陥のみに注目するのではなく、Cetusから始めて、すべてのDeFiチームは純粋な技術的思考の限界を克服し、本当に「ファイナンシャルエンジニア」としての安全リスク意識を育むべきだと思います。
例えば：金融リスク管理の専門家を導入し、技術チームの知識の盲点を補う；多方面からの監査メカニズムを実施し、コード監査だけでなく、必要な経済モデルの監査も補う；「金融嗅覚」を育て、さまざまな攻撃シナリオとそれに対する対策をシミュレートし、異常な操作に常に敏感でいるなど。
これを聞いて、以前のセキュリティ会社での経験を思い出しました。業界のセキュリティの大物たち @evilcos、@chiachih_wu、@yajinzhou、@mikelee205 との交流でも、こうした共通の認識がありました。
業界が成熟するにつれて、コードレベルの技術的バグの問題は減少していくが、境界が曖昧で責任が不明確なビジネスロジックの「意識バグ」が最大の課題である。
監査会社はコードにバグがないことを保証することしかできませんが、「論理に境界を持たせる」ためには、プロジェクトチームがビジネスの本質をより深く理解し、境界を制御する能力が必要です。（以前、多くのセキュリティ監査の後でも依然としてハッカー攻撃を受けた「責任転嫁事件」の根本原因はここにあります）
DeFiの未来は、コード技術が優れていて、ビジネスロジックを深く理解しているチームに属します！
281k 投稿
256k 投稿
167k 投稿
82k 投稿
68k 投稿
67k 投稿
62k 投稿
53k 投稿
51k 投稿
Cetusのセキュリティ問題の教訓：分散型金融チームは何に注意すべきか？
作者: Haotian
@CetusProtocolのハッカーセキュリティ「レビュー」レポートを読んだ後、あなたは「興味深い」現象を見つけるでしょう:技術的な詳細は非常に透過的に開示され、緊急対応は教科書レベルですが、「なぜハッキングされたのか」という最も重要な魂の拷問は回避的であるようです。
報告は
integer-mateライブラリのchecked\_shlw関数のエラー検査（理論上≤2^192、実際には≤2^256）を大量に説明し、これを「意味の誤解」と定義しています。この説明は技術的に成立していますが、巧妙に外部の責任に焦点を当て、まるでCetusもこの技術的欠陥の無実の被害者であるかのようにしています。問題が発生しました。なぜ
integer-mateがオープンソースで広く使用されている数学ライブラリであるにもかかわらず、あなたのところで1つのトークンで天文学的な流動性シェアを得るという不合理なエラーが発生したのでしょうか？ハッカー攻撃のパスを分析すると、ハッカーが完璧な攻撃を実現するためには、同時に四つの条件を満たす必要があることが分かります：誤ったオーバーフロー検査、大幅なビットシフト演算、切り上げルール、経済的合理性の検証の欠如。
Cetusは、すべての「トリガー」条件で「うっかり」していました。たとえば、ユーザーが2^200のような天文学的な数字を入力することを受け入れ、極度に危険な大幅な移動演算を行い、外部ライブラリのチェックメカニズムを完全に信頼し、最も致命的なのは——システムが「1トークンで天文学的なシェアを得る」という馬鹿げた結果を計算したとき、経済常識のチェックなしに直接実行してしまったことです。
したがって、Cetus が真剣に反省すべき点は以下の通りです：
1）なぜ汎用外部ライブラリのセキュリティテストが十分に行われていないのか？
integer-mateライブラリがオープンソースで人気があり広く使用されているとはいえ、Cetusは数億ドルの資産を管理するためにそれを使用しながら、このライブラリのセキュリティの境界がどこにあるのか、ライブラリの機能が無効になった場合に適切な代替手段があるのかを十分に理解していなかったようです。明らかに、Cetusは最も基本的なサプライチェーンセキュリティ意識を欠いています；2）なぜ天文学的な数字の入力が許可され、境界が設定されないのですか？DeFiプロトコルは分散化を目指すべきですが、成熟した金融システムはオープンであるほど、明確な境界を必要とします。
システムが攻撃者によって巧妙に構築された天文数字の入力を許可するとき、チームは明らかにこのような流動性の要求が合理的であるかを考慮していない。世界最大のヘッジファンドでさえ、このように誇張された流動性のシェアを必要とすることはできない。明らかに、Cetusチームは金融的直感を持つリスク管理の専門家を欠いている。
3）なぜ多回のセキュリティ監査を経ても問題が事前に発見されなかったのか？この言葉は無意識のうちに致命的な認識の誤りを暴露している：プロジェクト側はセキュリティの責任をセキュリティ会社に外注し、監査を免責の証明書と見なしている。しかし現実は厳しい：セキュリティ監査エンジニアはコードのバグを発見するのが得意だが、誰が天方夜譚のような交換比率を算出するシステムをテストすることが不適切かもしれないと考えるだろうか？
数学、暗号学、経済学におけるこの種の境界検証は、現代のDeFiセキュリティにおける最大の盲点です。 監査法人は、「これは経済モデルの設計上の欠陥であり、コードロジックの問題ではない」と言うでしょう。 プロジェクトチームは、「監査では問題は見つからなかった」と不満を漏らしました。 そして、ユーザーは自分のお金がなくなったことだけを知っています!
見てください、これは結局DeFi業界のシステム的な安全の弱点を暴露しています：純粋な技術的背景を持つチームは基本的な「金融リスクの嗅覚」が著しく欠けています。
Cetusのこのレポートを見る限り、チームは明らかに反省が不十分です。
今回のハッキング攻撃に関する技術的な欠陥のみに注目するのではなく、Cetusから始めて、すべてのDeFiチームは純粋な技術的思考の限界を克服し、本当に「ファイナンシャルエンジニア」としての安全リスク意識を育むべきだと思います。
例えば：金融リスク管理の専門家を導入し、技術チームの知識の盲点を補う；多方面からの監査メカニズムを実施し、コード監査だけでなく、必要な経済モデルの監査も補う；「金融嗅覚」を育て、さまざまな攻撃シナリオとそれに対する対策をシミュレートし、異常な操作に常に敏感でいるなど。
これを聞いて、以前のセキュリティ会社での経験を思い出しました。業界のセキュリティの大物たち @evilcos、@chiachih_wu、@yajinzhou、@mikelee205 との交流でも、こうした共通の認識がありました。
業界が成熟するにつれて、コードレベルの技術的バグの問題は減少していくが、境界が曖昧で責任が不明確なビジネスロジックの「意識バグ」が最大の課題である。
監査会社はコードにバグがないことを保証することしかできませんが、「論理に境界を持たせる」ためには、プロジェクトチームがビジネスの本質をより深く理解し、境界を制御する能力が必要です。（以前、多くのセキュリティ監査の後でも依然としてハッカー攻撃を受けた「責任転嫁事件」の根本原因はここにあります）
DeFiの未来は、コード技術が優れていて、ビジネスロジックを深く理解しているチームに属します！