DeFi/DEXのセキュリティ設計 — 資産を守るために押さえる観点

DeFi/DEXは「攻撃される前提」で設計する

DeFi（分散型金融）やDEX（分散型取引所）は、不特定多数の資産がプロトコルに集まります。これは利便性であると同時に、経済的なインセンティブを持った攻撃者を引き寄せることを意味します。一般的なWebサービスのセキュリティに加えて、DeFi/DEX固有のリスクを設計段階で織り込む必要があります。

観点1 — 価格オラクルの信頼性

DeFiの多くは「資産の価格」を前提に動きます。この価格をどこから取るか（オラクル）が、最大の弱点になり得ます。単一のDEXの瞬間価格をそのまま参照すると、その価格を一時的に歪められたときに、誤った清算や不正な利益取得を許してしまいます。

• 複数ソースや時間加重平均（TWAP）など、操作に強い価格参照を採用する
• オラクルが停止・異常値を返したときの挙動を設計する

価格をどう信じるかは、DeFi設計の核心です。

観点2 — 流動性とフラッシュローン

フラッシュローン（同一トランザクション内で巨額を借りて返す仕組み）は、それ自体は正当な機能ですが、価格操作と組み合わせると強力な攻撃手段になります。瞬間的に大量の資金を動かして価格や流動性を歪め、その歪みから利益を抜く——という攻撃が繰り返し報告されています。

設計では、単一トランザクション内で価格と取引が完結する経路に歪みの余地がないか、流動性が薄いペアで想定外の挙動が起きないか、を検証します。

観点3 — 権限設計と中央集権リスク

「緊急時に止められるようにしておく」「パラメータを調整できるようにしておく」といった管理機能は実務上必要ですが、その権限が攻撃対象になります。管理者鍵が単一だと、それが漏れたときに全資産が危険にさらされます。

• マルチシグやタイムロックで権限を分散・遅延させる
• 何を・誰が・どの手順で変更できるかを明文化する

利便性と非中央集権性のバランスを、意図的に設計することが求められます。

観点4 — 監査と継続的な監視

外部監査は重要ですが、「ある時点のコードのレビュー」である点を理解しておく必要があります。デプロイ後も、

• 異常な取引・価格の動きを監視する
• インシデント発生時の対応（停止・連絡・調査）の手順を用意する
• 新たな攻撃手法の動向を追い、必要なら対応する

という継続的な営みが、資産を守り続けるうえで欠かせません。

まとめ

DeFi/DEXのセキュリティは、「攻撃される前提」で、価格情報・流動性・権限・監視を一体で設計することに尽きます。これらは実装後に付け足すものではなく、要件・設計の段階から織り込むべき観点です。

設計前の論点整理には、Web3・ブロックチェーン開発 発注前チェックリストもご活用ください。