すべての記事

バグのないスマートコントラクトが依然として危険なのはなぜですか?

blockchainFebruary 6, 2026·#Blockchain

スマート コントラクトにプログラミング エラーがなくても、経済設計や運用ロジックの間違いにより、数十億ドルの損害が発生する可能性があります。 Tan Phat Digital に参加して、ソース コードの安全性とシステムの安全性の境界を分析してください。

バグのないスマートコントラクトが依然として危険なのはなぜですか?

分散型金融 (DeFi) の爆発的な発展により、「スマート コントラクト」の概念がデジタル経済の中核基盤になりました。従来のプログラミングの考え方では、セキュリティは構文エラーや技術的な実装エラーを排除することとして理解されることがよくあります。しかしタンファットデジタルの専門家が指摘しているように、ブロックチェーン史上最大の経済的損失、特に2025年から2026年初頭にかけての損失は、必ずしもプログラミングの「バグ」に起因するとは限りません。むしろ、「クリーンな」ソース コードを備えたプロトコルでも、構造上のリスクや経済設計の間違いによって崩壊する可能性があります。

このレポートでは、技術的に完璧なスマート コントラクトが依然として非常に危険である理由を分析しています。これは、ソース コードとブロックチェーンの動作環境の間の複雑な相互作用に起因しており、経済的な前提が見落とされがちです。 「コードの安全性」と「システムの安全性」の境界を理解することは、Web3 時代には不可欠です。

ビジネス ロジックの脆弱性と経済的不変条件の違反

ビジネス ロジック エラーは、プログラミング言語のルールには違反しませんが、プロトコルの設計意図に違反するため、最も困難な課題の 1 つです。自動バグ スキャン ツールは、プロジェクトの特定の経済目標に関するコンテキストが欠如しているため、この種のリスクを見逃すことがよくあります。

プログラミング エラーとロジック欠陥の違い

リスクの性質をよりよく理解するには、次の 2 つの概念を区別する必要があります。

  • 従来のプログラミング エラー (バグ): 通常、構文またはコード実行におけるエラー。再入攻撃やオーバーフロー攻撃など。このタイプのエラーは、自動スキャン ツールで非常に検出可能であり、多くの場合、契約が一時停止されたり、取引が取り消されたりすることがあります。

  • ビジネス ロジックの脆弱性: プロセス設計または数学的計算におけるエラー (資産共有率の計算間違いなど)。このタイプのエラーを検出する能力は非常に低く、深いビジネス理解を必要とし、その結果、多くの場合、資産価値の低下や不正なトークンのインフレが発生します。

状態更新の不一致

状態変数の正確な制御は、安全性の前提条件です。開発者が変数間の絶対的な同期を確保できない場合 (たとえば、ユーザー残高は変更するが総供給量は更新しない場合)、脆弱性が発生します。一貫性のない状態更新を伴うエクスプロイトは現在、現実世界の攻撃の約 11% を占めており、標準に準拠したコードであっても、論理チェックが不足している場合には依然として抜け穴が生じる可能性があることが示されています。

経済的不変条件違反

経済的不変条件は、すべてのシナリオで常に保持される必要がある数学的特性です。たとえば、融資プロトコルでは、担保価値は常に融資額より大きくなければなりません。顕著な例は、2025 年 11 月に発生した Balancer V2 エクスプロイトで、約 1 億 2,800 万ドルの損害を引き起こしました。攻撃者は、安定したプールの数式における丸め誤差を利用しました。ソース コードは完全にスムーズに実行されましたが、数学的ロジックに問題があるため、攻撃者は一連の入金と出金を通じて価値を引き出すことができました。

関連項目: トークンノミクス?

フロントランニング攻撃とトランザクション注文 (MEV) によるリスク

スマート コントラクトは完全にプログラムできますが、パブリック トランザクション キュー (mempool) の操作方法によりユーザーが損失を被ることになります。フロントランニング攻撃は、攻撃者が収益性の高いトランザクションを観察し、より高いガス料金を支払って最初に自分のトランザクションを挿入したときに発生します。

サンドイッチ攻撃メカニズム

これは、DEX 取引所における MEV の最も一般的な形式です。攻撃者は価格をつり上げるために事前に購入し、被害者が注文に応じた直後に高額な価格で売却します。ユーザーは最大のスリッページを負担しますが、攻撃者は人為的な価格差から利益を得ます。 2025 年 3 月の具体例として、あるトレーダーは、Uniswap v3 に対する壊滅的なサンドイッチ攻撃により、220,000 USDC を USDT にスワップした際にほぼすべての価値を失いました。

ネットワーク層における MEV リスク

MEV のリスク レベルは構造間で大幅に異なります ネットワーク:

  • イーサリアム レイヤー 1: Mempool は完全に公開されており、ガス料金の優先順位に従って配置されています (優先ガス オークション)。主な攻撃形式は、サンドイッチとアトミック アービトラージです。

  • レイヤー 2 (ロールアップ): 通常、プライベート メモリプールと集中型シーケンサを使用します。主な並べ替えメカニズムは FCFS (先着順) です。ただし、MEV リスクは確率的攻撃やタイミング攻撃の形で依然として存在します。

外部データと Oracle の操作への依存

スマート コントラクト自体は外部データにアクセスできないため、Price Oracle に依存する必要があります。 Oracle の入力データに誤りがある場合 (フラッシュ ローン経由など)、契約はその誤った情報に基づいて壊滅的な措置を実行します。

1 億 1,700 万ドルの損失を引き起こした Mango Markets 攻撃はその代表的な例です。攻撃者は、自己管理アカウント間で大規模な売買注文を実行することで、MNGO トークンの価格を操作しました。仮想価格が急騰すると、攻撃者はこの MNGO 番号を担保として使用し、プラットフォーム上の他の貴重な資産を借り入れます。スマート コントラクトは担保をチェックするという適切な機能を果たしていますが、簡単に操作できる価格ソースを過度に信頼することにリスクがあります。

詳細はこちら: DeFi は人々にどのようなリスクをもたらしますか? new

不変性のパラドックスとアップグレード メカニズム (プロキシ) によるリスク

不変性は信頼性を生み出しますが、エラーを修正する必要がある場合には障壁になります。これを解決するために、プロジェクトではプロキシ設計パターンを使用してロジックをアップグレードします。ただし、これにはストレージ衝突のリスクが伴います。アップグレードで変数の順序が適切に設定されていない場合、データが間違った場所に上書きされ、システムのクラッシュにつながります。

2022 年の Audius ハッキングはその一例で、アップデートにより誤って管理変数が上書きされ、攻撃者が 600 万ドル相当のコミュニティ資金を乗っ取ることができました。さらに、プロキシの使用にはトレードオフも生じます。

  • 不変モデル: 絶対的に信頼性は高いが、エラーを修正できず、データ移行にコストがかかる。

  • アップグレード可能なプロキシ モデル: 柔軟性があり、迅速なエラー修正が可能だが、一元化とストレージの競合のリスクが高い。

  • ハイブリッドモデル (骨化):最初はアップグレードを許可しますが、プロトコルが成熟すると永続的にロックされます。

ガバナンスと DAO 攻撃のリスク

DAO を介した分散型ガバナンスは、多くの場合、権力乗っ取り攻撃 (ガバナンス乗っ取り) の標的になります。攻撃者はコード内のエラーを探すのではなく、選挙システムを「ハイジャック」しようとします。

乗っ取り攻撃と「継承された」エラー

1 億 8,200 万ドルの損害を引き起こした 2022 年の Beanstalk 攻撃は、タイムアウトなし (タイムロック) の危険性を示しています。攻撃者はフラッシュ ローンを使用して過半数の票を獲得し、同じブロック内で出金命令を実行します。

2026 年、専門家はレガシー コードによるリスクにさらに注意を払います。 2640万ドルの損失をもたらした2026年1月のTruebitハッキングは、もう使用されていないがオンチェーンに残っていた古いコントラクトのバグに起因し、攻撃者が無料でトークンを鋳造できるようになっていました。これは、リスクが新しいコードだけでなく、クリーンアップされていない「レガシー」部分にも存在することを強調しています。

実践ガイド: 投資家向けに管理権限を確認する方法

Tan Phat Digital からの推奨に従って、投資家は Etherscan で次のデューデリジェンス手順を実行する必要があります。

  1. 管理権限を保有するエンティティを確認する権利: owneradmin などの関数を探します。返送先アドレスが個人ウォレット (EOA) の場合、これは最大のリスクです。理想的には、マルチシグ ウォレットまたはタイムロック ウォレットのアドレスである必要があります。

  2. マルチシグ ウォレット識別 (マルチシグ): 管理アドレスが安全なウォレット (Gnosis Safe) であるかどうかを確認します。署名者のリスト (getOwners) と承認のしきい値 (getThreshold) を確認します。 1 つのウォレットが 5/9 であっても、5 つのアドレスすべてが同じ人に属している場合、分散化は単なる幻想です。

  3. タイムロック メカニズムの分析: minDelay 関数を見つけます。この期間 (通常は 24 時間から 7 日間) は、悪意のある提案が検出された場合にユーザーに資本を引き出す時間を与える「緊急ブレーキ」です。

  4. 避けるべき危険信号:

    • 管理者は個人ウォレット (EOA) です。

    • 重要なデータに対してタイムロック メカニズムはありません。

    • TWAP の代わりに Oracle スポット価格 (スポット) を使用します。

    • ブロック エクスプローラーの未検証のソース コード。

    • 初期化されていないプロキシにより、誰でも元の所有権を取得できます。

ランタイム モニタリングとインバリアントの重要性テスト

Web セキュリティ 2026 年 3 年はプロアクティブ モデルに移行します。単一の監査に依存するだけでは十分ではありません。

  • 不変テスト: 開発者は不変のルール (たとえば、負債総額が担保を超えないなど) を定義し、ファジング ツールを使用してそのルールを破る何百万ものシナリオをテストします。

  • リアルタイム モニタリング: Forta Firewall などのツールを使用して、悪意のあるトランザクションが実行される前に影響をシミュレートしてブロックします。

  • Bridge の新しいソリューション: ASAS-BridgeAMM プロジェクトのような「Contained Degradation」に関する新しい研究により、システムは完全にクラッシュするのではなく、Oracle からの異常信号やネットワーク遅延を検出したときに、自動的に制限モード (料金値上げ、制限強化) に切り替わります。

よくある質問(FAQ)

  1. 初期化されていないプロキシ コントラクトはなぜ危険ですか? デプロイ直後に initialize() 関数が呼び出されない場合、重要な状態変数 (所有者など) はデフォルト値の 0 になります。攻撃者は自分自身でこの関数を呼び出して、コントラクト全体を制御することができます。  

  2. 再初期化攻撃とは何ですか? これは、攻撃者が (通常は新しいバージョン V2 にアップグレードした後) 初期化機能を再度有効にして、重要なパラメータを上書きしたり、プロジェクトの管理権限を変更しようとしたときに発生するリスクです。  

  3. ストレージ衝突はいつ発生しますか? 新しいロジック コントラクトの変数の構造が、古いプロキシ コントラクトの変数の順序と一致しない場合に発生します。その場合、変数にデータを書き込むと、論理アドレスやその他の重要なパラメータが誤って上書きされる可能性があります。

  4. サンドイッチ攻撃はレイヤー 2 で発生する可能性がありますか? レイヤ 2 にはプライベート メモリプールと MEV を削減する集中型シーケンサーがあることが多いですが、サンドイッチ攻撃はブロック時間予測とシーケンサー ポリシーに基づいて確率的に発生する可能性があります。  

  5. Etherscan でマルチシグ ウォレットを識別するにはどうすればよいですか? エクスプローラーでウォレット アドレスを確認できます。それがスマート コントラクトであり、Gnosis Safe などのフレームワークのソース コードが含まれ、getOwnersgetThreshold などの関数がある場合、それはマルチシグネチャ ウォレットです。  

  6. ASAS-BridgeAMM の「Contained Degradation」とは何ですか?これは「制限付き」動作状態であり、ネットワーク遅延の増加などのリスク信号を検出すると、システムが自動的に取引手数料 (ヘアカット) を増加させ、出金制限を狭め、スリッページを増加させます。

  7. なぜ Rust は完全に安全な言語であるにもかかわらず、依然としてリスクがあり得るのかを覚えておいてください。 Rust はメモリ オーバーフローを防ぎますが、ビジネス ロジック エラー、マシン間の状態の相違、またはシステム クラッシュにつながる同期エラーを防ぐことはできません。

  8. フラッシュ ローンによるガバナンス乗っ取りはどのように機能しますか? 攻撃者は、投票しきい値に達するまで 1 回のトランザクションで大量のトークンを借用し、悪意のある提案を通過させ、即座に実行し、同じブロックでローンを返済します。  

  9. Timelock はフラッシュ ローン攻撃の防止にどのように役立ちますか? Timelock は、ポーリングと実行の間に待機期間 (例: 48 時間) を強制することで、攻撃者がローンを複数日にわたって保持できないため、フラッシュ ローン サイクルを中断します。  

  10. フラッシュ ローン オラクル操作とは何ですか? 攻撃者は多額の借入資本を使用して、流動性プール内の価格を即座に歪める大規模な売買取引を実行します。 DeFiプロジェクトがそのプールから直接価格を取得すると、歪んだ価格が記録されます。  

  11. TWAP は価格操作から絶対に安全ですか? いいえ。攻撃者が平均期間全体 (例: 30 分) を通して価格偏差を維持するのに十分強力な場合、TWAP インデックスは操作された結果を返します。  

  12. インバリアント テストと単体テストの違いは何ですか? 単体テストでは特定の状況 (A の場合は B) がテストされますが、インバリアント テストでは、何百万ものランダムなシナリオをテストすることで、すべてのケースで常に真である必要があるプロパティ (たとえば、負債総額が常に担保未満であるなど) がテストされます。

  13. OpSec 監査はどの要素に焦点を当てますか? コード監査とは異なります。 OpSec 監査は、鍵管理、従業員のアクセス、インシデント対応プロセス、サーバー インフラストラクチャのセキュリティなど、人とプロセスに重点を置いています。  

  14. フラッシュ ローンが取引を成功させるために必要な条件は何ですか? 唯一かつ最も重要な条件は、単一ブロックの同じ取引でローン金額と手数料の全額が貸し手に返還されなければならないことです。  

  15. プロジェクトのタイムロック アドレスを確認するにはどうすればよいですか? Etherscan の [契約] タブにアクセスし、[契約の読み取り] を選択して、owner 関数を見つけます。結果がコントラクトアドレスである場合は、それをクリックして getMinDelay などの Timelock 機能があるかどうかを確認します。

Tan Phat Digital の多層セキュリティの考え方

プログラミング エラーのないスマート コントラクトは、そのセキュリティが経済、ガバナンス、インフラストラクチャの間の相互作用に依存するため、依然として非常に危険である可能性があります。 Tan Phat Digital は、理想的な安全システムには 4 つの保護層が含まれている必要があると考えています。クリーンなソース コード、堅牢な経済設計 (継続的なストレス テスト)、透明性のあるガバナンス (マルチシグ + タイムロック)、プロアクティブな運用 (リアルタイム モニタリング) です。

分散型の世界では、「信頼せず、検証してください」という原則が、舞台裏に隠れたリスクから自社の資産を保護するためのガイドラインです。完璧なコード行です。

シェア

コメント

0.0 / 5(0 件の評価)

コメントするにはログインしてください。

まだコメントはありません。最初のコメントを投稿しましょう。