「セキュリティ」タグの記事が 70 件 件あります

9人の見知らぬ人たちに6億2500万ドルの現金を渡し、そのうち少なくとも5人が決して自分に対して共謀しないと信じることを想像してみてください。これは本質的に、2022年3月に Ronin Bridge のユーザーが行ったことです。そして Lazarus Group は、それが非常に危険な考えであることをわずか6時間足らずで証明しました。Ronin のハッキング、Wormhole の3億2000万ドルの悪用、そして Nomad の混乱を極めた1億9000万ドルの群衆による流出には、共通の欠陥があります。それは、誠実さを保つために数学ではなく人間に依存しているということです。

ゼロ知識証明（Zero-knowledge proofs）は、クロスチェーン・インフラストラクチャの根本的な信頼モデルを変えようとしています。「誰がこのトランザクションを保証するのか？」と問う代わりに、ZK ブリッジは「このトランザクションがチェーン A の履歴の有効な一部であることを証明できるか？」と問いかけます。これは、正しい暗号技術のみが回答できる問いです。長年の理論的研究を経て、ZK ブリッジは 2024年から 2025年にかけてプロダクション規模に達し、数十億ドルの資産を保護し、証明コストはわずか1年で 45分の1 にまで低下しました。

リスク、監査、コンプライアンスを犠牲にせず、市場スピードで動くカストディと実行スタックを設計する方法。

エグゼクティブサマリー​

カストディと取引はもはや別々の世界で運用できません。今日のデジタル資産市場では、顧客資産を安全に保管するだけでは不十分です。価格がミリ秒単位で変動する中で取引を実行できなければ、リターンを逃すだけでなく、MEV（最大抽出可能価値）やカウンターパーティーの失敗、運用ボトルネックといった回避可能なリスクに顧客をさらすことになります。最新のカストディ・実行スタックは、最先端のセキュリティとハイパフォーマンスエンジニアリングを融合させる必要があります。具体的には、マルチパーティ計算（MPC）やハードウェアセキュリティモジュール（HSM）による署名、ポリシーエンジンとプライベートトランザクションルーティングによるフロントランニング防止、オフチェーン決済を活用したアクティブ/アクティブインフラでベニューリスクを低減し、資本効率を向上させます。コンプライアンスはオプションではなく、Travel Rule のデータフロー、イミュータブルな監査ログ、SOC 2 などのフレームワークにマッピングされたコントロールをトランザクションパイプラインに組み込む必要があります。

「カストディ速度」が今重要な理由​

従来、デジタル資産カストディは「鍵を失わない」ことを最優先にしていました。これは依然として基本ですが、要求は変化しています。現在は ベストエグゼキューション と 市場の健全性 が同等に不可欠です。取引がパブリックメンプールを通過すると、洗練されたアクターが取引を観測し、順序を入れ替えたり「サンドイッチ」したりして利益を抽出します。これは MEV の典型例であり、実行品質に直結します。プライベートトランザクションリレー を活用して機密オーダーフローを公開から隠すことは、リスク軽減の有力手段です。

同時に ベニューリスク も永続的な懸念です。単一取引所に大口残高を集中させると、カウンターパーティーリスクが顕在化します。オフチェーン決済ネットワークは、取引所提供の信用枠を利用しつつ資産を分離・破産回避型カストディに保つことで、この課題を解決します。結果として安全性と資本効率が大幅に向上します。

規制当局もギャップを埋めつつあります。FATF の Travel Rule の施行や IOSCO、金融安定理事会（FSB）などの勧告は、デジタル資産市場を 「同リスク・同ルール」 の枠組みへと押し進めています。つまり、カストディプラットフォームはデータフローと監査可能なコントロールを根本からコンプライアンス対応に設計しなければなりません。

設計目標（「良い」姿）​

ハイパフォーマンスなカストディスタックは、以下のコア原則に基づいて構築されるべきです。

• 予算化可能なレイテンシ：クライアントの意図からネットワークブロードキャストまでの各ミリ秒を測定・管理し、厳格な SLO（サービスレベル目標）で強制する。
• MEV 耐性のある実行：機密オーダーはデフォルトでプライベートチャネルへルーティング。パブリックメンプールへの露出は意図的な選択に留める。
• 鍵素材の確実な保証：プライベートキーは決して境界を越えてはならない。MPC シャード、HSM、TEE（Trusted Execution Environment）いずれであっても同様。鍵ローテーション、クォーラム強制、堅牢なリカバリ手順は必須。
• アクティブ/アクティブの信頼性：障害に耐える設計。RPC ノードとサイナーのマルチリージョン・マルチプロバイダー冗長化を実装し、回路遮断器やキルスイッチでベニュー・ネットワーク障害に自動対応。
• コンプライアンス・バイ・コンストラクション：コンプライアンスは後付けではなく、Travel Rule データ、AML/KYT 検査、イミュータブル監査トレイルを組み込んだアーキテクチャとし、SOC 2 の Trust Services Criteria に直接マッピング。

参考アーキテクチャ​

以下の図は、上記目標を満たすカストディ・実行プラットフォームのハイレベルアーキテクチャを示しています。

• Policy & Risk Engine はすべての指示の中心的ゲートキーパーです。Travel Rule ペイロード、速度制限、アドレスリスクスコア、サイナークォーラム要件などを評価し、鍵素材にアクセスする前に全てをチェックします。
• Signer Orchestrator は資産とポリシーに応じて最適な制御プレーンへ署名リクエストをルーティングします。具体例は以下の通りです
  • MPC（マルチパーティ計算）：閾値署名スキーム（t‑of‑n ECDSA/EdDSA）で信頼を複数のパーティやデバイスに分散。
  • HSM（ハードウェアセキュリティモジュール）：ハードウェアで鍵管理を強制し、決定的なバックアップとローテーションポリシーを提供。
  • TEE（例：AWS Nitro Enclaves）：署名コードを隔離し、測定済みソフトウェアに鍵をバインド。
• Execution Router は最適経路でトランザクションを送信します。情報感度が高い大口注文は プライベートトランザクション送信 を優先し、フロントランニングを回避。必要に応じてパブリック送信にフォールバックし、マルチプロバイダー RPC のフェイルオーバーでネットワーク障害時も高可用性を確保します。
• Observability Layer はシステム状態をリアルタイムで可視化。メンプール・ブロックのサブスクリプション、取引後のリコンシリエーション、そして イミュータブル監査レコード をすべての決定・署名・ブロードキャストに対して記録します。

セキュリティ構成要素（重要性）​

• 閾値署名（MPC）：鍵を分散管理し、単一のマシンや人物が単独で資金を移動できないようにします。最新の MPC プロトコルは高速かつ悪意ある攻撃に耐える署名を実現し、実運用のレイテンシ予算に適合します。
• HSM と FIPS 準拠：HSM は耐タンパーなハードウェアで鍵境界を強制し、FIPS 140‑3 や NIST SP 800‑57 といった標準に基づく監査可能な保証を提供します。
• 証明付き TEE：鍵を測定済みコードにバインドし、KMS と連携して証明されたワークロードのみに鍵素材を解放。承認されたコードだけが署名可能になります。
• MEV 対策のプライベートリレー：プライベートリレーは取引を直接ブロックビルダーやバリデータへ送信し、パブリックメンプールを迂回。フロントランニングやその他の MEV リスクを大幅に低減します。
• オフチェーン決済：資産を分離カストディに保持しつつ、取引所提供の信用枠で取引を実行。カウンターパーティーエクスポージャーを抑制し、決済速度を向上、資本効率を改善します。
• SOC 2 / ISO へのコントロールマッピング：運用コントロールを認知されたフレームワークに文書化・テストすることで、顧客・監査人・パートナーがセキュリティとコンプライアンスを独立検証可能にします。

レイテンシ・プレイブック：ミリ秒の行方​

低レイテンシ実行を実現するには、トランザクションライフサイクルのすべてのステップを最適化します。

• Intent → Policy Decision：ポリシー評価ロジックをメモリ上に常駐させ、KYT やアロウリストデータを短い TTL でキャッシュし、可能ならサイナークォーラムを事前計算。
• Signing：コールドスタートを避けるため、永続的な MPC セッションと HSM キーハンドルを使用。TEE ではエンクレーブを固定し、アテステーション経路を温め、セッションキーを安全に再利用。
• Broadcast：HTTP よりも永続的な WebSocket 接続で RPC ノードに送信。実行サービスをプライマリ RPC プロバイダーのリージョンに同居させ、レイテンシが急上昇した場合は冪等リトライとマルチプロバイダーへのヘッジ送信を実施。
• Confirmation：トランザクションステータスをポーリングせず、ネットワークから直接レシート・イベントをサブスクライブ。これらの状態変化をリアルタイムでリコンシリエーションパイプラインに流し、ユーザーへ即時フィードバックと内部帳簿更新を行う。

各ホップに対して厳格な SLO を設定（例：ポリシーチェック < 20 ms、署名 < 50‑100 ms、ブロードキャスト < 50 ms（通常負荷時））し、p95/p99 が逸脱した際はエラーバジェットと自動フェイルオーバーで対処します。

設計段階でのリスク＆コンプライアンス​

モダンなカストディスタックは、コンプライアンスをシステムの根幹に据える必要があります。

• Travel Rule オーケストレーション：すべての送金指示で送信者・受取者情報を生成・検証。未知の VASP への送金は自動的にブロックまたは迂回し、暗号化された受領証を監査用に記録。
• アドレスリスク＆アロウリスト：オンチェーン分析と制裁リストをポリシーエンジンに直接組み込み。デフォルトは「拒否」姿勢とし、明示的に許可されたアドレスまたはポリシー例外のみ送金を許可。
• イミュータブル監査：すべてのリクエスト・承認・署名・ブロードキャストをハッシュ化し、追記専用台帳に保存。SIEM へリアルタイムでストリームし、脅威検知と監査証跡の提供を実現。
• コントロールフレームワーク：技術・運用コントロールを SOC 2 の Trust Services Criteria（Security, Availability, Processing Integrity, Confidentiality, Privacy）にマッピングし、継続的なテストと検証プログラムを実装。

オフチェーン決済：安全なベニュー接続​

機関投資家規模のカストディスタックは、取引所へのエクスポージャーを最小化すべきです。オフチェーン決済ネットワーク はその鍵となります。これにより、資産は自社の分離カストディに保持されたまま、取引所の信用枠で取引が可能になります。結果として、破産リスクが抑制され、決済速度が向上し、資本効率が大幅に改善されます。

実装例：MPC、HSM、TEE の組み合わせ​

まとめ​

• カストディと取引は 同時に高速・安全・コンプライアンス対応 が求められる。
• MPC、HSM、TEE を組み合わせたハイブリッド署名基盤で鍵素材の安全性を確保。
• ポリシーエンジンとプライベートリレーで MEV を実質的に排除。
• オフチェーン決済でベニューリスクと資本コストを最小化。
• すべてのデータフローと操作を SOC 2 / ISO にマッピングし、イミュータブル監査ログで証跡を残す。

この設計指針に従うことで、機関投資家や規制当局の期待に応える、高速かつ信頼性の高いデジタル資産カストディスタック を構築できます。

LayerZero v2、Hyperlane、IBC 3.0 のような相互運用性プロトコルは、マルチチェーン DeFi エコシステムの重要なインフラとして台頭しています。それぞれがクロスチェーンメッセージングと共有流動性に対して異なるアプローチを取り、独自のセキュリティモデルを持っています：

• LayerZero v2 – 分散型検証者ネットワーク (DVN) を使用した証明集約モデル
• Hyperlane – マルチシグ検証者委員会を多用するモジュラーフレームワーク
• IBC 3.0 – Cosmos エコシステムにおける信頼最小化リレーヤーを備えたライトクライアントプロトコル

このレポートでは、各プロトコルのセキュリティメカニズムを分析し、ライトクライアント vs マルチシグ vs 証明集約 の長所と短所を比較し、それらが DeFi の構成可能性と流動性に与える影響を検証します。また、現在の実装、脅威モデル、採用レベルをレビューし、これらの設計選択がマルチチェーン DeFi の長期的な存続可能性にどのように影響するかについての見通しで締めくくります。

主要なクロスチェーンプロトコルのセキュリティメカニズム​

LayerZero v2：分散型検証者ネットワーク (DVN) による証明集約​

LayerZero v2 は、モジュラーでアプリケーション設定可能なセキュリティレイヤーを重視するオムニチェーンメッセージングプロトコルです。中心的なアイデアは、アプリケーションが 1 つ以上の独立した分散型検証者ネットワーク (DVN) でメッセージを保護できるようにすることです。これらの DVN は集合的にクロスチェーンメッセージを証明します。LayerZero の証明集約モデルでは、各 DVN は基本的にメッセージを独立して検証できる検証者のセットです (例：ブロック証明や署名のチェック)。アプリケーションは、メッセージを受け入れる前に複数の DVN からの集約された証明を要求することができ、しきい値を持つ「セキュリティスタック」を形成します。

デフォルトでは、LayerZero はいくつかの DVN をすぐに利用できるように提供しています。例えば、LayerZero Labs が運営する 2-of-3 マルチシグ検証を使用する DVN や、Google Cloud が運営する DVN などです。しかし重要なのは、開発者が DVN を自由に組み合わせられることです。例えば、特定の DVN の署名に加えて、他の 5 つのうち任意の 2 つの署名を必要とする 「1 of 3 of 5」 の設定を要求することができます。この柔軟性により、異なる検証方法 (ライトクライアント、zk プルーフ、オラクルなど) を 1 つの集約された証明に組み合わせることが可能です。事実上、LayerZero v2 は v1 のウルトラライトノードモデル (1 つのリレーヤー + 1 つのオラクルに依存) を、DVN をまたいだ X-of-Y-of-N マルチシグ集約へと一般化しています。各チェーン上のアプリケーションの LayerZero エンドポイントコントラクトは、必要な DVN クォーラムがそのメッセージに対して有効な証明を書き込んだ場合にのみ、メッセージを配信します。

セキュリティ特性： LayerZero のアプローチは、要求されたセット内の少なくとも 1 つの DVN が正直である (または 1 つの zk プルーフが有効であるなど) 限り、信頼最小化されています。アプリが 独自の DVN を必須の署名者として実行できるようにすることで、LayerZero はアプリチームの検証者によって承認されない限り、いかなるメッセージも拒否できるようにします。これにより、セキュリティを大幅に強化できます (中央集権化のコストはかかりますが)、アプリの署名なしにクロスチェーンメッセージが実行されることはありません。一方で、開発者はより分散化された DVN クォーラム (例：15 の独立したネットワークのうち 5 つ) を選択して、より強力な信頼分散を実現することもできます。LayerZero はこれを「アプリケーション所有のセキュリティ」と呼んでいます：各アプリは、DVN を設定することで、セキュリティ、コスト、パフォーマンスの間のトレードオフを選択します。すべての DVN の証明は、最終的に不変の LayerZero エンドポイントコントラクトによってオンチェーンで検証され、パーミッションレスなトランスポートレイヤーを維持します。欠点は、セキュリティが選択された DVN の強度に依存することです。設定された DVN が共謀したり侵害されたりすると、不正なクロスチェーンメッセージを承認する可能性があります。したがって、堅牢な DVN を選択するか、より弱いセキュリティのリスクを負うかは、各アプリケーションの責任となります。

Hyperlane：モジュラー ISM を備えたマルチシグ検証者モデル​

Hyperlane は、ターゲットチェーンでメッセージが配信される前に検証を行うオンチェーンのインターチェーンセキュリティモジュール (ISM) を中心とした相互運用性フレームワークです。最も単純な (そしてデフォルトの) 設定では、Hyperlane の ISM はマルチシグネチャ検証者セットを使用します。これは、オフチェーンの検証者からなる委員会がソースチェーンからの証明 (多くの場合、すべての送信メッセージのマークルルート) に署名し、宛先チェーンでしきい値以上の署名が必要とされるものです。言い換えれば、Hyperlane はパーミッション制の検証者クォーラムに依存して、「メッセージ X が確かにチェーン A で発行された」ことを確認します。これは、ブロックチェーンのコンセンサスに似ていますが、ブリッジレベルでのものです。例えば、Wormhole は 19 のガーディアンと 13-of-19 のマルチシグを使用しており、Hyperlane のアプローチも精神的には似ています (ただし、Hyperlane は Wormhole とは異なります)。

重要な特徴は、Hyperlane がプロトコルレベルで単一の固定された検証者セットを持っていないことです。代わりに、誰でも検証者を実行でき、異なるアプリケーションは異なる検証者リストとしきい値を持つ ISM コントラクトをデプロイできます。Hyperlane プロトコルはデフォルトの ISM デプロイメント (チームがブートストラップした検証者セットを含む) を提供しますが、開発者は自由に検証者セットやセキュリティモデルをカスタマイズできます。実際、Hyperlane は複数のタイプの ISM をサポートしており、複数の検証方法を組み合わせる集約 ISM や、メッセージパラメータに基づいて ISM を選択するルーティング ISM などがあります。例えば、アプリは Hyperlane のマルチシグ と 外部ブリッジ (Wormhole や Axelar など) の両方の署名を要求することで、冗長性を通じてより高いセキュリティ基準を達成できます。

セキュリティ特性： Hyperlane のマルチシグモデルの基本的なセキュリティは、検証者の大多数の正直さに由来します。しきい値 (例：8 人中 5 人) の検証者が共謀すれば、不正なメッセージに署名できるため、信頼の前提は約 N-of-M マルチシグ信頼です。Hyperlane はこのリスクに対処するため、EigenLayer リステーキングと統合し、検証者が不正行為に対してスラッシュされる可能性のあるステークされた ETH を預けることを要求する経済的セキュリティモジュール (ESM) を作成しています。この「アクティブ検証サービス (AVS)」は、Hyperlane の検証者が無効なメッセージ (ソースチェーンの履歴に実際には存在しないメッセージ) に署名した場合、誰でも Ethereum 上で証明を提示してその検証者のステークをスラッシュできることを意味します。これにより、不正行為を経済的に抑制することでセキュリティモデルが大幅に強化されます。Hyperlane のクロスチェーンメッセージは、検証者の社会的評判だけでなく、Ethereum の経済的な重みによって保護されるようになります。しかし、トレードオフとして、スラッシングを Ethereum に依存することは、Ethereum のライブネスへの依存を生み出し、不正証明が時間内に提出可能であることを前提とします。ライブネスに関しては、Hyperlane は、しきい値を満たすのに十分な検証者がオンラインでない場合、メッセージ配信が停止する可能性があると警告しています。プロトコルは、柔軟なしきい値設定を許可することでこれを緩和します。例えば、より大きな検証者セットを使用して、時折のダウンタイムがネットワークを停止させないようにします。全体として、Hyperlane のモジュラーマルチシグアプローチは、検証者セットへの信頼を追加するコストと引き換えに、柔軟性とアップグレード可能性 (アプリが独自のセキュリティを選択したり、複数のソースを組み合わせたりできる) を提供します。これは真のライトクライアントよりも弱い信頼モデルですが、最近のイノベーション (リステークされた担保やスラッシングなど) により、多くのチェーンに展開しやすいままで、実際には同等のセキュリティ保証に近づくことができます。

IBC 3.0：信頼最小化リレーヤーを備えたライトクライアント​

Cosmos エコシステムで広く使用されている Inter-Blockchain Communication (IBC) プロトコルは、根本的に異なるアプローチを取ります。新しい検証者セットを導入するのではなく、オンチェーンのライトクライアントを使用してクロスチェーンの状態を検証します。IBC では、各チェーンのペアが接続を確立し、チェーン B はチェーン A のライトクライアントを保持します (逆も同様)。このライトクライアントは、本質的に相手チェーンのコンセンサス (例：検証者セットの署名やブロックハッシュの追跡) の簡略化されたレプリカです。チェーン A がチェーン B にメッセージ (IBC パケット) を送信すると、リレーヤー (オフチェーンのアクター) が証明 (パケットのマークルプルーフと最新のブロックヘッダー) をチェーン B に運びます。その後、チェーン B の IBC モジュールは、オンチェーンのライトクライアントを使用して、その証明がチェーン A のコンセンサスルールのもとで有効であることを検証します。証明が確認されれば (つまり、パケットが A のファイナライズされたブロックにコミットされていれば)、メッセージは受け入れられ、B のターゲットモジュールに配信されます。本質的に、チェーン B は仲介者ではなく、チェーン A のコンセンサスを直接信頼します。これが、IBC がしばしば信頼最小化された相互運用性と呼ばれる理由です。

IBC 3.0 は、このプロトコルの最新の進化 (2025 年頃) を指し、パフォーマンスと機能のアップグレードを導入しています：低遅延のための並列リレーイング、特殊なユースケースのためのカスタムチャネルタイプ、リモート状態を読み取るためのインターチェーンクエリなどです。特筆すべきは、これらのいずれも中心的なライトクライアントのセキュリティモデルを変更するものではなく、速度と機能を強化するものであることです。例えば、並列リレーイングは、複数のリレーヤーが同時にパケットを運ぶことでボトルネックを回避し、セキュリティを犠牲にすることなくライブネスを向上させることを意味します。インターチェーンクエリ (ICQ) は、チェーン A のコントラクトがチェーン B にデータ (証明付き) を要求できるようにし、そのデータは A の B に対するライトクライアントによって検証されます。これにより、IBC の機能はトークン転送を超えて、より一般的なクロスチェーンデータアクセスにまで拡張されますが、依然として検証済みのライトクライアント証明に基づいています。

セキュリティ特性： IBC のセキュリティ保証は、ソースチェーンの完全性と同じくらい強力です。チェーン A が正直な多数派 (または設定されたコンセンサスしきい値) を持ち、チェーン B の A に対するライトクライアントが最新であれば、受け入れられたパケットは 必ず A の有効なブロックから来たものでなければなりません。ブリッジの検証者やオラクルを信頼する必要はありません。唯一の信頼の前提は、2 つのチェーンのネイティブなコンセンサスと、ライトクライアントの信頼期間 (この期間を過ぎると古いヘッダーは失効する) などのいくつかのパラメータです。IBC のリレーヤーは信頼される必要はありません。有効なヘッダーやパケットを偽造することはできず、それらは検証に失敗するからです。最悪の場合、悪意のあるまたはオフラインのリレーヤーはメッセージを検閲または遅延させることができますが、誰でもリレーヤーを実行できるため、少なくとも 1 人の正直なリレーヤーが存在すれば、最終的にライブネスは達成されます。これは非常に強力なセキュリティモデルです：事実上、デフォルトで分散化されパーミッションレスであり、チェーン自体の特性を反映しています。トレードオフはコストと複雑さにあります。別のチェーン上でライトクライアント (特に高スループットのチェーンの) を実行することは、リソースを大量に消費する可能性があります (検証者セットの変更の保存、署名の検証など)。Tendermint/BFT を使用する Cosmos SDK チェーンでは、このコストは管理可能で IBC は非常に効率的ですが、異種のチェーン (Ethereum や Solana など) を統合するには、複雑なクライアント実装や新しい暗号技術が必要です。実際、IBC を介して非 Cosmos チェーンをブリッジングする動きは遅く、Polymer や Composable といったプロジェクトが、IBC を Ethereum などに拡張するためにライトクライアントや zk プルーフに取り組んでいます。IBC 3.0 の改善 (最適化されたライトクライアント、異なる検証方法のサポートなど) は、これらのコストを削減することを目指しています。要約すると、IBC のライトクライアントモデルは、最も強力な信頼保証 (外部の検証者が一切不要) と堅牢なライブネス (複数のリレーヤーが存在する場合) を提供しますが、その代償として実装の複雑性が高く、参加するすべてのチェーンが IBC プロトコルをサポートしなければならないという制約があります。

ライトクライアント、マルチシグ、証明集約の比較​

各セキュリティモデル – ライトクライアント (IBC)、検証者マルチシグ (Hyperlane)、集約証明 (LayerZero) – には、それぞれ明確な長所と短所があります。以下では、主要な側面でこれらを比較します：

セキュリティ保証​

• ライトクライアント (IBC): ソースチェーンのコンセンサスにオンチェーン検証を固定することで、最高のセキュリティを提供します。新たな信頼レイヤーは存在しません。ソースブロックチェーン (例：Cosmos Hub や Ethereum) がブロックを二重生成しないと信頼するなら、それが送信するメッセージも信頼できます。これにより、追加の信頼の前提と攻撃対象領域が最小化されます。しかし、ソースチェーンの検証者セットが破損した場合 (例：Tendermint で >⅓、PoS チェーンで >½ が不正を働く)、ライトクライアントは不正なヘッダーを受け取る可能性があります。実際には、IBC チャネルは通常、経済的に安全なチェーン間で確立され、ライトクライアントはリスクを軽減するためにパラメータ (信頼期間やブロックファイナリティ要件など) を持つことができます。全体として、信頼最小化はライトクライアントモデルの最大の利点です。各メッセージには暗号的な有効性の証明があります。

• マルチシグ検証者 (Hyperlane および同様のブリッジ): セキュリティは、オフチェーンの署名者セットの正直さに依存します。典型的なしきい値 (例：検証者の ⅔) が、各クロスチェーンメッセージまたは状態のチェックポイントに署名する必要があります。利点は、十分な評判の良い、または経済的にステークされた検証者がいれば、これをかなり安全にできることです。例えば、Wormhole の 19 のガーディアンや Hyperlane のデフォルト委員会がシステムを侵害するには、集合的に共謀する必要があります。欠点は、これが新たな信頼の前提を導入することです。ユーザーはチェーンに加えてブリッジの委員会も信頼しなければなりません。これは、いくつかのハッキングで失敗点となっています (例：秘密鍵が盗まれたり、内部関係者が共謀したりした場合)。Hyperlane のリステークされた ETH 担保のような取り組みは、このモデルに経済的セキュリティを追加します。無効なデータに署名した検証者は、Ethereum 上で自動的にスラッシュされます。これにより、マルチシグブリッジはブロックチェーンのセキュリティに近づきます (不正行為を金銭的に罰することで) が、それでもライトクライアントほど信頼最小化されてはいません。要するに、マルチシグは信頼保証において弱いです。少人数のグループの多数派に依存しますが、スラッシングや監査によって信頼性を高めることはできます。

• 証明集約 (LayerZero v2): これは、ある意味で中間的な立場です。アプリケーションがセキュリティスタックにライトクライアント DVN や zk プルーフ DVN を含めるように設定した場合、その保証はそれらのチェックに対して IBC レベル (数学とチェーンのコンセンサス) に近づくことができます。委員会ベースの DVN (LayerZero の 2-of-3 デフォルトや Axelar アダプターなど) を使用する場合、そのマルチシグの信頼の前提を継承します。LayerZero モデルの強みは、複数の検証者を独立して組み合わせられることです。例えば、「zk プルーフが有効である」かつ「Chainlink オラクルがブロックヘッダーは X であると言っている」かつ「我々自身の検証者が署名する」ことを要求することで、攻撃の可能性を劇的に減らすことができます (攻撃者はすべてを一度に破る必要があります)。また、アプリが独自の DVN を必須とすることで、LayerZero は、そのように設定されていれば、アプリの同意なしにメッセージが実行されることはないと保証します。弱みは、開発者が (より安い手数料や速度のために) 緩いセキュリティ設定を選択した場合、セキュリティを損なう可能性があることです。例えば、未知の当事者が運営する単一の DVN を使用することは、単一の検証者を信頼するのと同様です。LayerZero 自体は意見を持たず、これらの選択をアプリ開発者に委ねているため、セキュリティは選択された DVN の質に依存します。要約すると、証明集約は非常に強力なセキュリティ (複数の独立した証明を要求することで、単一のライトクライアントよりも高い) を提供できますが、設定を誤ると弱いセットアップも許容してしまいます。柔軟性があり、アプリは高価値のトランザクションにはセキュリティを強化し (例：複数の大手 DVN を要求)、低価値のトランザクションにはそれを緩和できます。

ライブネスと可用性​

• ライトクライアント (IBC): ライブネスはリレーヤーとライトクライアントが最新の状態を保つことに依存します。良い点は、誰でもリレーヤーを実行できるため、システムが特定のノードセットに依存しないことです。1 つのリレーヤーが停止しても、別のリレーヤーがその仕事を引き継ぐことができます。IBC 3.0 の並列リレーイングは、すべてのパケットを 1 つのパスでシリアル化しないことで、可用性をさらに向上させます。実際には、IBC 接続は非常に信頼性が高いですが、ライブネスが低下するシナリオもあります。例えば、リレーヤーが長期間更新を投稿しないと、ライトクライアントが期限切れになり (例：信頼期間が更新なしに経過した場合)、安全のためにチャネルが閉じられる可能性があります。しかし、そのようなケースはまれであり、アクティブなリレーヤーネットワークによって緩和されます。もう 1 つのライブネスの考慮事項は、IBC パケットがソースチェーンのファイナリティに従うことです。例えば、Tendermint で 1〜2 ブロック (数秒) 待つのが標準です。全体として、IBC は少なくとも 1 つのアクティブリレーヤーが存在する限り高い可用性を提供し、遅延は通常、ファイナライズされたブロックに対して低い (数秒) です。マルチシグのように検証者のクォーラムがオフラインになるという概念はなく、ブロックチェーン自体のコンセンサスファイナリティが主な遅延要因です。

• マルチシグ検証者 (Hyperlane): 検証者セットが小さい場合、ライブネスは弱点になる可能性があります。例えば、ブリッジが 5-of-8 のマルチシグを持ち、4 人の検証者がオフラインまたは到達不能な場合、しきい値を満たせないためクロスチェーンメッセージングは停止します。Hyperlane のドキュメントでは、設定されたしきい値によっては、検証者のダウンタイムがメッセージ配信を停止させる可能性があると指摘しています。これが、稼働時間を向上させるために、より大きな委員会やより低いしきい値 (安全性のトレードオフあり) を選択する理由の一部です。Hyperlane の設計では、必要に応じて新しい検証者をデプロイしたり、ISM を切り替えたりできますが、そのような変更には調整/ガバナンスが必要になる場合があります。マルチシグブリッジが持つ利点は、しきい値の署名が集まれば通常は迅速に確認できることです。マルチシグの証明自体がファイナリティであるため、宛先チェーンでソースチェーンのブロックファイナリティを待つ必要はありません。実際、多くのマルチシグブリッジは数秒以内にメッセージに署名し、リレーします。したがって、一部のチェーンでは遅延がライトクライアントと同等かそれ以下になる可能性があります。ボトルネックは、検証者が遅い、地理的に分散している、または手動のステップが関与する場合です。要約すると、マルチシグモデルはほとんどの場合、高いライブネスと低遅延を実現できますが、ライブネスのリスクが検証者セットに集中しています。あまりにも多くの検証者がクラッシュしたり、彼らの間でネットワーク分断が発生したりすると、ブリッジは事実上ダウンします。

• 証明集約 (LayerZero): ここでのライブネスは、各 DVN とリレーヤーの可用性に依存します。メッセージは、必要な DVN から署名/証明を収集し、その後ターゲットチェーンにリレーされる必要があります。良い点は、DVN が独立して動作することです。(セットのうちの) 1 つの DVN がダウンしていて、それが必須でない場合 (「M of N」の一部に過ぎない場合)、しきい値が満たされる限りメッセージは進行できます。LayerZero のモデルは、一部の DVN の障害を許容するようにクォーラムを設定することを明示的に許可しています。例えば、「2 of 5」の DVN セットは、3 つの DVN がオフラインであってもプロトコルを停止させることなく処理できます。さらに、誰でも最終的なエグゼキューター/リレーヤーの役割を実行できるため、メッセージ配信に単一障害点はありません。プライマリリレーヤーが失敗した場合、ユーザーや他の当事者が証明を持ってコントラクトを呼び出すことができます (これは IBC のパーミッションレスなリレーヤーの概念に類似しています)。したがって、LayerZero v2 は、システムを 1 つの仲介者に縛り付けないことで、検閲耐性とライブネスを目指しています。しかし、必須の DVN がセキュリティスタックの一部である場合 (例えば、アプリが常に独自の DVN の署名を要求する場合)、その DVN はライブネスの依存関係になります。それがオフラインになると、それが復旧するかセキュリティポリシーが変更されるまでメッセージは一時停止します。一般的に、証明集約は堅牢に設定できます (冗長な DVN と任意の当事者によるリレーイングにより)、すべての検証者が一度にダウンする可能性は低いです。トレードオフは、複数の DVN に連絡することが、単一のより高速なマルチシグと比較して、少し多くの遅延を引き起こす可能性があることです (例：複数の署名を待つ)。しかし、それらの DVN は並行して実行でき、多くの DVN (オラクルネットワークやライトクライアントなど) は迅速に応答できます。したがって、LayerZero は高いライブネスと低遅延を達成できますが、正確なパフォーマンスは DVN の設定方法に依存します (一部はソースチェーンで数ブロックの確認を待つかもしれず、それが安全のために遅延を追加する可能性があります)。

コストと複雑性​

• ライトクライアント (IBC): このアプローチは、実装は複雑だが、互換性のあるチェーンで一度設定すれば安価に使用できる傾向があります。複雑さは、各タイプのブロックチェーンに対して正しいライトクライアント実装を作成することにあります。本質的に、チェーン A のコンセンサスルールをチェーン B のスマートコントラクトにエンコードすることになります。同様のコンセンサスを持つ Cosmos SDK チェーンではこれは簡単でしたが、Cosmos を超えて IBC を拡張するには、重いエンジニアリングが必要でした (例：Polkadot の GRANDPA ファイナリティ用のライトクライアントの構築、または zk プルーフを用いた Ethereum ライトクライアントの計画)。これらの実装は些細なものではなく、非常に安全でなければなりません。また、オンチェーンのストレージオーバーヘッドもあります。ライトクライアントは、相手チェーンの最近の検証者セットや状態ルート情報を保存する必要があります。これにより、チェーン上の状態サイズと証明検証コストが増加する可能性があります。結果として、例えば Ethereum メインネット上で直接 IBC を実行する (Cosmos のヘッダーを検証する) ことは、ガス代の観点から高価になります。これが、Polymer のようなプロジェクトがこれらのライトクライアントをメインネット外でホストするために Ethereum ロールアップを作成している理由の 1 つです。Cosmos エコシステム内では、IBC トランザクションは非常に効率的です (多くの場合、ガス代は数セント程度)。これは、ライトクライアントの検証 (ed25519 署名、マークルプルーフ) がプロトコルレベルで十分に最適化されているためです。ユーザーにとって IBC の使用は比較的低コストであり、リレーヤーは宛先チェーンで通常のトランザクション手数料を支払うだけです (ICS-29 ミドルウェアを介して手数料でインセンティブを得ることができます)。要約すると、IBC のコストは開発の複雑さに前倒しされていますが、一度実行されれば、ネイティブで手数料効率の良いトランスポートを提供します。接続されている多くの Cosmos チェーン (100 以上のゾーン) は共通の実装を共有しており、これが標準化によって複雑性を管理するのに役立っています。

• マルチシグブリッジ (Hyperlane/Wormhole/etc.): ここでの実装の複雑さはしばしば低くなります。コアとなるブリッジングコントラクトは、主に保存された公開鍵に対して一連の署名を検証する必要があります。このロジックは、完全なライトクライアントよりも単純です。オフチェーンの検証者ソフトウェアは運用上の複雑さ (チェーンイベントの監視、メッセージのマークルツリーの維持、署名収集の調整など) を導入しますが、これはブリッジ運営者によって管理され、オフチェーンに保たれます。オンチェーンコスト：いくつかの署名 (例えば 2 つまたは 5 つの ECDSA 署名) を検証することはそれほど高価ではありませんが、単一のしきい値署名やハッシュチェックよりも多くのガスを消費することは確かです。一部のブリッジは、集約署名スキーム (例：BLS) を使用して、オンチェーンコストを 1 回の署名検証に削減しています。一般的に、Ethereum や同様のチェーンでのマルチシグ検証は中程度のコストがかかります (各 ECDSA 署名チェックは約 3000 ガス)。ブリッジが 10 の署名を必要とする場合、検証だけで約 3 万ガスかかり、それに加えて新しいマークルルートの保存などがあります。これは通常、クロスチェーン転送が高価値の操作であることを考えると許容範囲ですが、積み重なる可能性があります。開発者/ユーザーの観点から見ると、マルチシグブリッジとの対話は簡単です。デポジットするか、送信関数を呼び出すだけで、残りはオフチェーンで検証者/リレーヤーによって処理され、その後証明が提出されます。アプリ開発者にとっては、ブリッジの API/コントラクトを統合するだけなので、複雑さは最小限です。複雑さの考慮事項の 1 つは、新しいチェーンの追加です。すべての検証者は、メッセージを監視するために各新しいチェーンのノードまたはインデクサーを実行する必要があり、これは調整の頭痛の種になる可能性があります (これは一部のマルチシグ設計で拡張のボトルネックとして指摘されていました)。Hyperlane の答えはパーミッションレスな検証者 (ISM に含まれていれば誰でもチェーンに参加できる) ですが、ISM をデプロイするアプリケーションは依然として最初にそれらのキーを設定する必要があります。全体として、マルチシグモデルは異種のチェーン間でブートストラップするのが容易であり (チェーンごとに特注のライトクライアントは不要)、市場投入までの時間を短縮できますが、オフチェーンでの運用上の複雑さと中程度のオンチェーン検証コストが発生します。

• 証明集約 (LayerZero): ここでの複雑さは、多くの可能な検証方法の調整にあります。LayerZero は標準化されたインターフェース (Endpoint & MessageLib コントラクト) を提供し、DVN が特定の検証 API に準拠することを期待しています。アプリケーションの観点から見ると、LayerZero の使用は非常に簡単です (lzSend を呼び出し、lzReceive コールバックを実装するだけ) が、その裏では多くのことが行われています。各 DVN は独自のオフチェーンインフラを持つ可能性があります (一部の DVN は、Axelar ネットワークや Chainlink オラクルサービスのように、それ自体がミニブリッジです)。プロトコル自体は複雑です。なぜなら、異なる証明タイプを安全に集約する必要があるからです。例えば、ある DVN は EVM ブロック証明を提供し、別の DVN は SNARK を、また別の DVN は署名を提供し、コントラクトはそれぞれを順番に検証しなければなりません。利点は、この複雑さの多くが LayerZero のフレームワークによって抽象化されていることです。コストは、いくつの、そしてどのタイプの証明が必要かに依存します。SNARK の検証は高価になる可能性があります (オンチェーンの zk プルーフ検証は数十万ガスかかることがあります) が、いくつかの署名の検証は安価です。LayerZero は、アプリがメッセージごとにセキュリティにどれだけ支払いたいかを決定できるようにします。また、DVN にその仕事に対して支払うという概念もあります。メッセージペイロードには DVN サービスの手数料が含まれています。例えば、アプリは DVN とエグゼキューターがメッセージを迅速に処理するようにインセンティブを与える手数料を添付できます。これによりコストの側面が加わります。より安全な設定 (多くの DVN や高価な証明を使用) は手数料が高くなりますが、単純な 1-of-1 DVN (単一のリレーヤーのような) は非常に安価ですが、セキュリティは低くなります。アップグレード可能性とガバナンスも複雑さの一部です。アプリはセキュリティスタックを変更できるため、それを行うためのガバナンスプロセスまたは管理者キーが必要です。これはそれ自体が信頼/管理の複雑さのポイントです。要約すると、LayerZero を介した証明集約は非常に柔軟ですが、内部は複雑です。メッセージごとのコストは、効率的な DVN を選択することで最適化できます (例：最適化された超軽量クライアントを使用したり、既存のオラクルネットワークの規模の経済を活用したりする)。多くの開発者は、(デフォルトが提供されている) プラグアンドプレイの性質を魅力的だと感じるでしょう。例えば、簡単にするためにデフォルトの DVN セットを使用するなどです。しかし、それが理解されていない場合、最適でない信頼の前提につながる可能性があります。

アップグレード可能性とガバナンス​

• ライトクライアント (IBC): IBC 接続とクライアントは、参加チェーンのオンチェーンガバナンス提案を通じてアップグレードできます (特に、ライトクライアントが修正を必要とする場合や、ソースチェーンのハードフォークに対応する更新が必要な場合)。IBC プロトコル自体をアップグレードする (例えば IBC 2.0 から 3.0 の機能へ) にも、ソフトウェアの新しいバージョンを採用するためにチェーンのガバナンスが必要です。これは、IBC が意図的なアップグレードパスを持つことを意味します。変更は遅く、コンセンサスが必要ですが、それはセキュリティ第一のアプローチと一致しています。単一のエンティティがスイッチを切り替えることはできず、各チェーンのガバナンスがクライアントやパラメータの変更を承認しなければなりません。良い点は、これにより脆弱性を導入する可能性のある一方的な変更を防げることです。悪い点は、俊敏性が低いことです。例えば、ライトクライアントにバグが見つかった場合、それを修正するには多くのチェーンにわたる協調的なガバナンス投票が必要になるかもしれません (ただし、緊急時の調整メカニズムは存在します)。dApp の観点から見ると、IBC には「アプリレベルのガバナンス」はあまりありません。それはチェーンによって提供されるインフラです。アプリケーションは単に IBC モジュール (トークン転送やインターチェーンアカウントなど) を使用し、チェーンのセキュリティに依存します。したがって、ガバナンスとアップグレードはブロックチェーンレベル (Hub と Zone のガバナンス) で行われます。興味深い新しい IBC の機能として、カスタムチャネルとルーティング (Polymer や Nexus のようなハブなど) があり、これによりアプリを中断することなく基盤となる検証方法を切り替えることができます。しかし、概して IBC は安定しており標準化されています。アップグレードは可能ですが頻繁ではなく、その信頼性に貢献しています。

• マルチシグブリッジ (Hyperlane/Wormhole): これらのシステムには、コントラクトのアップグレード、検証者セットの変更、パラメータの修正を行うための管理者またはガバナンスメカニズムがしばしば存在します。例えば、セットに新しい検証者を追加したり、キーをローテーションしたりするには、ブリッジの所有者のマルチシグや DAO の投票が必要になる場合があります。Hyperlane がパーミッションレスであるということは、どのユーザーもカスタム検証者セットを持つ独自の ISM をデプロイできることを意味しますが、デフォルトを使用する場合、Hyperlane チームまたはコミュニティが更新を管理する可能性が高いです。アップグレード可能性は諸刃の剣です。一方では、アップグレード/改善が容易であり、他方では、中央集権化のリスクになる可能性があります (特権キーがブリッジコントラクトをアップグレードできる場合、そのキーは理論的にブリッジをラグプルする可能性があります)。適切に統治されたプロトコルはこれを制限します (例：アップグレードにタイムロックを設ける、または分散型ガバナンスを使用する)。Hyperlane の哲学はモジュール性です。そのため、アプリは失敗したコンポーネントを ISM を切り替えることで回避することもできます。これにより、開発者は脅威に対応する力を持つことができます (例：ある検証者セットが侵害された疑いがある場合、アプリは迅速に別のセキュリティモデルに切り替えることができます)。ガバナンスのオーバーヘッドは、アプリがセキュリティモデルを決定し、独自の検証者のキーを管理したり、Hyperlane コアプロトコルからの更新に注意を払ったりする必要があることです。要約すると、マルチシグベースのシステムはよりアップグレード可能であり (コントラクトはしばしばアップグレード可能で、委員会は設定可能)、迅速な改善や新しいチェーンの追加に適していますが、ガバナンスプロセスへの信頼が必要です。過去の多くのブリッジの悪用は、侵害されたアップグレードキーや欠陥のあるガバナンスを介して発生しているため、この分野は慎重に扱う必要があります。プラス面として、新しいチェーンのサポートを追加することは、コントラクトをデプロイし、検証者にそのノードを実行させるだけで済む場合があり、根本的なプロトコルの変更は不要です。

• 証明集約 (LayerZero): LayerZero は不変のトランスポートレイヤー (エンドポイントコントラクトはアップグレード不可) を謳っていますが、検証モジュール (Message Libraries と DVN アダプター) は追記専用で設定可能です。実際には、これは各チェーンのコア LayerZero コントラクトが固定されたままで (安定したインターフェースを提供)、新しい DVN や検証オプションがコアを変更することなく時間とともに追加できることを意味します。アプリケーション開発者は自身のセキュリティスタックを制御できます。DVN を追加または削除したり、確認ブロックの深さを変更したりできます。これはアプリレベルでのアップグレード可能性の一形態です。例えば、特定の DVN が非推奨になったり、より良い新しい DVN (より高速な zk クライアントなど) が登場したりした場合、アプリチームはそれを設定に統合できます。これにより dApp を将来にわたって保証できます。利点は明らかです。アプリは過去のセキュリティ技術に縛られず、新しい開発に (適切な注意を払って) 適応できます。しかし、これはガバナンスの問題を提起します。アプリ内で誰が DVN セットの変更を決定するのか？ 理想的には、アプリが分散化されている場合、変更はガバナンスを通じて行われるか、不変性を望むならハードコードされるべきです。単一の管理者がセキュリティスタックを変更できる場合、それは信頼のポイントです (悪意のあるアップグレードでセキュリティ要件を低下させる可能性があります)。LayerZero 自身のガイダンスは、そのような変更に対して堅牢なガバナンスを設定するか、必要であれば特定の側面を不変にすることを奨励しています。もう 1 つのガバナンスの側面は手数料管理です。DVN とリレーヤーへの支払いは調整可能であり、インセンティブがずれるとパフォーマンスに影響を与える可能性があります (ただし、デフォルトでは市場の力によって手数料が調整されるはずです)。要約すると、LayerZero のモデルは新しい検証方法の追加に関して非常に拡張性が高くアップグレード可能であり (これは長期的な相互運用性にとって素晴らしいこと)、しかし、それらのアップグレードを責任を持って統治するのは各アプリケーションの責任です。LayerZero のベースコントラクトは、トランスポートレイヤーがラグプルされたり検閲されたりしないように不変であり、メッセージングパイプライン自体がアップグレードを通じて無傷で残るという信頼を呼び起こします。

比較を要約すると、以下の表は主要な違いを強調しています：

DeFi における構成可能性と共有流動性への影響​

クロスチェーンメッセージングは、構成可能性 (異なるチェーン上の DeFi コントラクトが相互作用する能力) のための強力な新しいパターンを解き放ち、共有流動性 (あたかも 1 つの市場であるかのようにチェーン間で資産をプールすること) を可能にします。上記で議論したセキュリティモデルは、プロトコルがどれだけ自信を持ってシームレスにクロスチェーン機能を利用できるかに影響を与えます。以下では、各アプローチがマルチチェーン DeFi をどのようにサポートするかを、実際の例とともに探ります：

• LayerZero を介したオムニチェーン DeFi (Stargate, Radiant, Tapioca): LayerZero の汎用メッセージングと Omnichain Fungible Token (OFT) 標準は、流動性のサイロを打ち破るために設計されています。例えば、Stargate Finance は LayerZero を使用して、ネイティブ資産ブリッジングのための統一された流動性プールを実装しています。各チェーンに断片化されたプールを持つのではなく、すべてのチェーン上の Stargate コントラクトが共通のプールを利用し、LayerZero メッセージがチェーン間のロック/リリースロジックを処理します。これにより、Stargate のブリッジでは月間 8 億ドル以上の取引高が生まれ、 значительная共有流動性が実証されました。LayerZero のセキュリティ (Stargate はおそらく堅牢な DVN セットを使用している) に依存することで、ユーザーはメッセージの信頼性に高い自信を持って資産を転送できます。Radiant Capital も別の例です。これは、ユーザーがあるチェーンで預金し、別のチェーンで借り入れができるクロスチェーンレンディングプロトコルです。LayerZero メッセージを活用して、チェーン間でアカウントの状態を調整し、事実上、複数のネットワークにまたがる 1 つのレンディング市場を作り出しています。同様に、Tapioca (オムニチェーンマネーマーケット) は LayerZero v2 を使用し、メッセージを保護するために独自の DVN を必須の検証者として実行しています。これらの例は、柔軟なセキュリティにより、LayerZero が信用調査、担保移動、清算といった複雑なクロスチェーン操作をサポートできることを示しています。構成可能性は、LayerZero の「OApp」標準 (Omnichain Application) から生まれます。これにより、開発者は同じコントラクトを多くのチェーンにデプロイし、メッセージングを介してそれらを連携させることができます。ユーザーはどのチェーンのインスタンスと対話しても、アプリケーションを 1 つの統一されたシステムとして体験します。セキュリティモデルは微調整が可能です。例えば、大規模な転送や清算にはより多くの DVN 署名を要求し (安全のため)、小規模なアクションはより速く/安価なパスを通過させることができます。この柔軟性により、セキュリティも UX も画一的である必要がなくなります。実際、LayerZero のモデルは共有流動性を大幅に向上させました。これは、数十のプロジェクトがトークンに OFT を採用していることからも明らかです (これにより、トークンは別々のラップされた資産としてではなく、「オムニチェーン」として存在できます)。例えば、ステーブルコインやガバナンストークンは OFT を使用して、すべてのチェーンにわたって単一の総供給量を維持できます。これにより、以前のラップトークンが悩まされていた流動性の断片化や裁定取引の問題を回避できます。全体として、信頼性の高いメッセージングレイヤーを提供し、アプリが信頼モデルを制御できるようにすることで、LayerZero は複数のチェーンを 1 つのエコシステムとして扱う新しいマルチチェーン DeFi 設計を触発しました。トレードオフは、ユーザーとプロジェクトが各オムニチェーンアプリの信頼の前提を理解しなければならないことです (それらは異なる可能性があるため)。しかし、OFT のような標準や広く使用されているデフォルトの DVN は、これをより均一にするのに役立ちます。

• IBC におけるインターチェーンアカウントとサービス (Cosmos DeFi): Cosmos の世界では、IBC はトークン転送を超える豊富なクロスチェーン機能を可能にしました。代表的な機能はインターチェーンアカウント (ICA) で、これによりブロックチェーン (またはチェーン A のユーザー) が、あたかもローカルであるかのようにチェーン B のアカウントを制御できます。これは、トランザクションを運ぶ IBC パケットを介して行われます。例えば、Cosmos Hub は Osmosis 上のインターチェーンアカウントを使用して、ユーザーに代わってトークンをステークまたはスワップできます。これらはすべて Hub から開始されます。具体的な DeFi のユースケースは、Stride のリキッドステーキングプロトコルです。Stride (チェーン) はユーザーから ATOM のようなトークンを受け取り、ICA を使用して、それらの ATOM を Cosmos Hub 上でリモートでステークし、stATOM (リキッドステークされた ATOM) をユーザーに発行します。全体のフローは信頼性がなく、IBC を介して自動化されています。Stride のモジュールは、Hub 上のアカウントを制御し、デリゲートおよびアンデリゲートトランザクションを実行し、確認とタイムアウトが安全性を保証します。これはクロスチェーンの構成可能性を示しています。2 つの主権チェーンが共同のワークフロー (ここでステークし、そこでトークンをミントする) をシームレスに実行します。別の例はOsmosis (DEX チェーン) で、IBC を使用して 95 以上の接続されたチェーンから資産を引き入れています。どのゾーンのユーザーも、IBC を介してトークンを送信することで Osmosis でスワップできます。IBC の高いセキュリティのおかげで、Osmosis などは IBC トークンを本物として自信を持って扱えます (信頼できるカストディアンは不要)。これにより、Osmosis は最大のインターチェーン DEX の 1 つとなり、日々の IBC 転送量は多くのブリッジシステムを上回ると報告されています。さらに、IBC 3.0 のインターチェーンクエリ (ICQ) により、あるチェーンのスマートコントラクトが、信頼最小化された方法で別のチェーンからデータ (価格、金利、ポジションなど) を取得できます。これにより、例えば、複数のゾーンの利回り率を照会し、それに応じて資産を再配分するインターチェーンイールドアグリゲーターが可能になります。これらはすべて IBC メッセージを介して行われます。IBC のライトクライアントモデルが構成可能性に与える主な影響は、信頼と中立性です。チェーンは主権を保ちながら、第三者のブリッジリスクを恐れることなく相互作用できます。Composable Finance や Polymer のようなプロジェクトは、IBC を非 Cosmos エコシステム (Polkadot, Ethereum) に拡張し、これらの機能を利用しようとしています。その結果、どのチェーンも IBC クライアント標準を採用すれば、「ブロックチェーンの普遍的なインターネット」に接続できる未来が訪れるかもしれません。Cosmos の共有流動性はすでに значительнаяです。例えば、Cosmos Hub のネイティブ DEX (Gravity DEX) などは、さまざまなゾーンから流動性をプールするために IBC に依存しています。しかし、これまでの制限は、Cosmos DeFi が主に非同期であることです。あるチェーンで開始し、結果はわずかな遅延 (数秒) を伴って別のチェーンで発生します。これは取引やステーキングのようなものには問題ありませんが、より複雑な同期的な構成可能性 (チェーン間のフラッシュローンなど) は、基本的な遅延のため範囲外です。それでも、IBC によって可能になるクロスチェーン DeFi の範囲は広いです。マルチチェーンイールドファーミング (利回りが最も高い場所に資金を移動)、クロスチェーンガバナンス (あるチェーンがガバナンスパケットを介して別のチェーンでアクションを実行するために投票)、さらにはインターチェーンセキュリティ (コンシューマーチェーンがプロバイダーチェーンの検証者セットを活用する) などです。要約すると、IBC の安全なチャネルは、Cosmos にインターチェーン経済を育みました。プロジェクトが別々のチェーンで専門化しながらも、信頼最小化されたメッセージを通じて流動的に連携できる経済です。共有流動性は、Osmosis への資産の流れや、ゾーン間を自由に移動する Cosmos ネイティブのステーブルコインの台頭などに明らかです。

• ハイブリッドおよびその他のマルチチェーンアプローチ (Hyperlane 以降): Hyperlane のパーミッションレスな接続性のビジョンは、資産をブリッジングするための Warp Routes や、さまざまなエコシステムにまたがるインターチェーン dapps といった概念につながりました。例えば、Warp Route は、Ethereum 上の ERC-20 トークンを Solana プログラムにテレポートさせることを可能にし、その裏では Hyperlane のメッセージレイヤーを使用します。具体的なユーザー向けの実装の 1 つは、Hyperlane の Nexus ブリッジで、Hyperlane のインフラを介して多くのチェーン間で資産を転送するための UI を提供します。モジュラーセキュリティモデルを使用することで、Hyperlane はルートごとにセキュリティを調整できます。小規模な転送は単純で高速なパス (Hyperlane 検証者の署名のみ) を通過するかもしれませんが、大規模な転送は集約された ISM (Hyperlane + Wormhole + Axelar のすべてが証明) を必要とする場合があります。これにより、高価値の流動性移動が複数のブリッジによって保護されることが保証されます。これにより、例えば 1000 万ドルの資産をクロスチェーンで移動する際の信頼性が高まります (それを盗むには複数のネットワークを侵害する必要があります) が、その代償として複雑性/手数料が高くなります。構成可能性の観点から、Hyperlane は彼らが**「コントラクトの相互運用性」と呼ぶものを可能にします。チェーン A のスマートコントラクトは、メッセージが配信されれば、あたかもローカルであるかのようにチェーン B の関数を呼び出すことができます。開発者は Hyperlane SDK を統合して、これらのクロスチェーンコールを簡単にディスパッチします。例としては、一部が Ethereum に、一部が BNB Chain に存在するクロスチェーン DEX アグリゲーターが、Hyperlane メッセージを使用して両者間で裁定取引を行うことが考えられます。Hyperlane は EVM および非 EVM チェーン (CosmWasm や MoveVM 統合の初期作業も含む) をサポートしているため、「あらゆるチェーン、あらゆる VM」を接続することを目指しています。この広範なリーチは、通常は簡単に接続できないエコシステムをブリッジングすることで、共有流動性を増加させることができます。しかし、大規模な DeFi における Hyperlane の実際の採用はまだ成長段階です。ブリッジングにおいて Wormhole や LayerZero のような取引量はまだありませんが、そのパーミッションレスな性質は実験を引きつけています。例えば、一部のプロジェクトは、独自の検証者セットを設定でき、複雑なライトクライアントソリューションを待つ必要がないため、アプリ固有のロールアップを Ethereum に迅速に接続するために Hyperlane を使用しています。リステーキング (EigenLayer) が成長するにつれて、Hyperlane はEthereum グレードのセキュリティをあらゆるロールアップに**比較的低い遅延で提供することで、より多くの採用を見るかもしれません。これにより、新しいマルチチェーンの構成が加速する可能性があります。例えば、Optimism ロールアップと Polygon zk-ロールアップが Hyperlane AVS を介してメッセージを交換し、各メッセージは不正であればスラッシュされる ETH によって裏付けられます。構成可能性への影響は、共有標準を持たないエコシステム (Ethereum と任意の L2 など) でさえ、両サイドが信頼するブリッジコントラクト (経済的に保護されているため) を得られることです。時間とともに、これにより、開発者が構成可能性を「ダイヤルイン」 (どのセキュリティモジュールをどのコールに使用するかを選択) できる、相互接続された DeFi アプリのウェブが生まれるかもしれません。

これらすべての場合において、セキュリティモデルと構成可能性の間の相互作用は明らかです。プロジェクトは、セキュリティが盤石である場合にのみ、大規模な流動性プールをクロスチェーンシステムに委託します。そのため、信頼最小化または経済的に保護された設計への推進力があります。同時に、統合の容易さ (開発者体験) と柔軟性は、チームが複数のチェーンを活用する上でどれだけ創造的になれるかに影響します。LayerZero と Hyperlane は開発者向けのシンプルさ (SDK をインポートし、使い慣れた送受信コールを使用するだけ) に焦点を当てていますが、より低レベルである IBC は、モジュールの理解をより多く必要とし、アプリケーション開発者ではなくチェーン開発者によって扱われるかもしれません。それにもかかわらず、3 つすべてが、ユーザーがどのチェーン上にいるかを知る必要なくマルチチェーン dApps と対話する未来に向かって進んでいます。アプリはどこからでもシームレスに流動性と機能を利用します。例えば、レンディングアプリのユーザーはチェーン A で預金し、借り入れがチェーン B のプールから行われたことにさえ気づかないかもしれません。すべてがクロスチェーンメッセージと適切な検証によってカバーされます。

実装、脅威モデル、および実際の採用状況​

これらのプロトコルが現実世界の状況でどのように機能しているか、つまり現在の実装、既知の脅威ベクトル、および採用レベルを評価することが重要です。

• 本番環境での LayerZero v2: LayerZero v1 (2 つのエンティティ、オラクル+リレーヤーモデル) は大きな採用を獲得し、2024 年半ばまでに 500 億ドル以上の転送量を確保し、1 億 3400 万件以上のクロスチェーンメッセージを処理しました。主に EVM チェーンですが、Aptos のような非 EVM チェーンを含む 60 以上のブロックチェーンと統合されており、Solana の実験的なサポートも視野に入っています。LayerZero v2 は 2024 年初頭にローンチされ、DVN とモジュラーセキュリティを導入しました。すでに、Radiant Capital、SushiXSwap、Stargate、PancakeSwap などの主要プラットフォームが、その柔軟性を活用するために v2 への移行または構築を開始しています。注目すべき統合の 1 つは、Flare Network (データに焦点を当てた Layer1) で、一度に 75 のチェーンと接続するために LayerZero v2 を採用しました。Flare は、セキュリティをカスタマイズできる能力に魅力を感じました。例えば、低価値のメッセージには単一の高速 DVN を使用し、高価値のメッセージには複数の DVN を要求するなどです。これは、本番環境では、アプリケーションが実際に「ミックスアンドマッチ」のセキュリティアプローチをセールスポイントとして使用していることを示しています。セキュリティと監査: LayerZero のコントラクトは不変であり、監査されています (v1 は複数の監査を受け、v2 も同様)。v1 の主な脅威はオラクルとリレーヤーの共謀でした。2 つのオフチェーンパーティが共謀すれば、メッセージを偽造できました。v2 では、その脅威はDVN の共謀に一般化されます。アプリが依存するすべての DVN が 1 つのエンティティによって侵害された場合、偽のメッセージがすり抜ける可能性があります。LayerZero の答えは、アプリ固有の DVN を奨励すること (攻撃者はアプリチームも侵害する必要があるため) と、検証者の多様性 (共謀を困難にするため) です。もう 1 つの潜在的な問題は、設定ミスやアップグレードの悪用です。アプリの所有者が悪意を持って些細なセキュリティスタック (自分たちが制御する 1-of-1 DVN など) に切り替えた場合、セキュリティをバイパスして自身のユーザーを悪用する可能性があります。これはプロトコルのバグというよりはガバナンスのリスクであり、コミュニティはオムニチェーンアプリのセキュリティがどのように設定されているかについて警戒を続ける必要があります (できればマルチシグやコミュニティの承認を要求する)。採用に関しては、LayerZero は現在、DeFi のメッセージングプロトコルの中で最も使用されていると言えるでしょう。**Stargate、Circle の CCTP 統合 (USDC 転送用)、Sushi のクロスチェーンスワップ、**多くの NFT ブリッジ、そして数え切れないほどの OFT トークン (プロジェクトがトークンを複数のチェーンで利用可能にするために LayerZero を選択) のブリッジングを支えています。ネットワーク効果は強力です。より多くのチェーンが LayerZero エンドポイントを統合するにつれて、新しいチェーンが「オムニチェーン」ネットワークに参加しやすくなります。LayerZero Labs 自体が 1 つの DVN を運営しており、コミュニティ (Google Cloud、zk プルーフ用の Polyhedra などのプロバイダーを含む) は 2024 年までに 15 以上の DVN を立ち上げています。現在までに LayerZero のコアプロトコルの大規模な悪用は発生しておらず、これは良い兆候です (ただし、他の技術と同様に、アプリケーションレベルのハッキングやユーザーエラーは発生しています)。トランスポートレイヤーをシンプルに保つ (本質的にメッセージを保存し、証明を要求するだけ) というプロトコルの設計は、オンチェーンの脆弱性を最小限に抑え、ほとんどの複雑さをオフチェーンの DVN に移しています。

• 本番環境での Hyperlane: Hyperlane (旧 Abacus) は、Ethereum、複数の L2 (Optimism、Arbitrum、zkSync など)、Cosmos-SDK モジュールを介した Osmosis のような Cosmos チェーン、さらには MoveVM チェーンなど、数多くのチェーンで稼働しています (サポート範囲は非常に広いです)。しかし、その採用は、取引量の点で LayerZero や Wormhole のような既存のプロトコルに遅れをとっています。Hyperlane はしばしば**「主権ブリッジ」ソリューションの文脈で言及されます。つまり、プロジェクトは Hyperlane をデプロイして、カスタムセキュリティを持つ独自のブリッジを持つことができます。例えば、一部の appchain チームは、共有ブリッジに依存せずに自分たちのチェーンを Ethereum に接続するために Hyperlane を使用しています。注目すべき開発は、2024 年半ばにローンチされたHyperlane Active Validation Service (AVS)** で、これは Ethereum リステーキングの最初のアプリケーションの 1 つです。検証者 (多くはトップの EigenLayer オペレーター) が ETH をリステークして Hyperlane メッセージを保護し、当初は高速なクロスロールアップメッセージングに焦点を当てています。これは現在、Ethereum L2 ロールアップ間の相互運用性を良好な結果で確保しており、本質的に Ethereum に結びついた経済的セキュリティを備えた、ほぼ瞬時のメッセージパッシング (オプティミスティックロールアップの 7 日間の待機期間よりも速い) を提供しています。脅威モデルに関しては、Hyperlane の元のマルチシグアプローチは、十分な数の検証者のキーが侵害されれば攻撃される可能性があります (他のマルチシグブリッジと同様)。Hyperlane は過去にセキュリティインシデントがありました。2022 年 8 月、初期のテストネットまたはローンチ中に、攻撃者が 1 つのチェーン上の Hyperlane トークンブリッジのデプロイヤーキーをハイジャックし、トークンをミントできたという悪用がありました (約 70 万ドルの損失)。これはマルチシグ自体の失敗ではなく、デプロイメント周りの運用セキュリティの問題であり、アップグレード可能性とキー管理のリスクを浮き彫りにしました。チームは損失を補償し、プロセスを改善しました。これは、ガバナンスキーが脅威モデルの一部であることを強調しています。管理コントロールを保護することは、検証者を保護することと同じくらい重要です。AVS では、脅威モデルは EigenLayer の文脈に移行します。誰かが誤ったスラッシングを引き起こしたり、不正行為にもかかわらずスラッシュを回避できたりすれば問題になりますが、EigenLayer のプロトコルは Ethereum 上でスラッシングロジックを処理しており、これは正しい不正証明の提出を前提とすれば堅牢です。Hyperlane の現在の採用は、ロールアップスペースや一部のアプリ固有のチェーンで増加しています。まだ競合他社のような数十億ドル規模の流れを処理しているわけではありませんが、開発者が完全な制御と簡単な拡張性を求めるニッチを切り開いています。モジュラー ISM 設計は、創造的なセキュリティ設定が見られる可能性を意味します。例えば、DAO は Hyperlane の署名だけでなく、タイムロックや 2 番目のブリッジ署名を管理メッセージに要求するなどです。Hyperlane のパーミッションレスな精神 (誰でも検証者を実行したり、新しいチェーンにデプロイしたりできる) は、長期的には強力であることが証明されるかもしれませんが、エコシステムが成熟する必要があることも意味します (例：デフォルトセットを分散化するために、より多くのサードパーティ検証者が参加するなど。2025 年現在、アクティブな検証者セットが実際にどれだけ分散化されているかは不明です)。全体として、Hyperlane の軌道は、セキュリティの向上 (リステーキングによる) と使いやすさの向上ですが、IBC や LayerZero と同レベルのコミュニティの信頼を得るには、回復力を示し、主要な流動性を引き付ける必要があります。

• 本番環境での IBC 3.0 と Cosmos Interop: IBC は 2021 年から稼働しており、Cosmos 内で非常に実戦テストされています。2025 年までに、115 以上のゾーン (Cosmos Hub、Osmosis、Juno、Cronos、Axelar、Kujira などを含む) を接続し、月間数百万のトランザクションと数十億ドル規模のトークンフローを処理しています。驚くべきことに、プロトコルレベルでの大規模なセキュリティ障害は一度もありません。注目すべき IBC 関連のインシデントが 1 つありました。2022 年 10 月、IBC コード (すべての v2.0 実装に影響) に重大な脆弱性が発見され、攻撃者が多くの IBC 接続チェーンから価値を流出させる可能性がありました。しかし、それは公に開示される前に協調的なアップグレードを通じて秘密裏に修正され、悪用は発生しませんでした。これは、形式的に検証されたプロトコルでさえバグを持つ可能性があるという警鐘でした。それ以来、IBC はさらなる監査と強化を受けています。IBC の脅威モデルは主にチェーンのセキュリティに関するものです。接続されたチェーンの 1 つが敵対的であるか、51% 攻撃を受けた場合、相手のライトクライアントに無効なデータを送ろうとする可能性があります。緩和策には、安全でないチェーンへの接続を停止または閉鎖するためにガバナンスを使用することが含まれます (例えば、Cosmos Hub のガバナンスは、壊れていると検出された特定のチェーンのクライアント更新をオフにすることを投票できます)。また、IBC クライアントはしばしばアンボンディング期間や信頼期間の調整を持っています。例えば、Tendermint ライトクライアントは、アンボンディング期間より古い検証者セットの更新を受け入れません (長距離攻撃を防ぐため)。もう 1 つの考えられる問題はリレーヤーの検閲です。リレーヤーがパケットを配信しない場合、資金がタイムアウトでスタックする可能性がありますが、リレーイングはパーミッションレスでしばしばインセンティブが与えられているため、これは通常一時的なものです。IBC 3.0 のインターチェーンクエリと新機能が展開されるにつれて、クロスチェーン DeX アグリゲーター (例：Skip Protocol が ICQ を使用してチェーン間で価格データを収集) やクロスチェーンガバナンス (例：Cosmos Hub がインターチェーンアカウントを使用してコンシューマーチェーンである Neutron を管理) などでの採用が見られます。Cosmos を超えた採用も物語です。Polymer や Astria (ロールアップのための相互運用ハブ) のようなプロジェクトは、ハブ/スポークモデルを介して事実上 IBC を Ethereum ロールアップに持ち込んでおり、Polkadot のパラチェーンは IBC を使用して Cosmos チェーンと正常に接続しています (例：Composable Finance が構築した Cosmos と Polkadot 間の Centauri ブリッジは、Cosmos 側で GRANDPA ライトクライアントを使用して IBC を内部で使用しています)。Polymer と DataChain によって進行中の IBC-Solidity 実装さえあり、これにより Ethereum スマートコントラクトが IBC パケットを検証できるようになります (ライトクライアントまたは有効性証明を使用)。これらの取り組みが成功すれば、IBC の使用は Cosmos を超えて劇的に広がり、その信頼最小化モデルがそれらのチェーンのより中央集権的なブリッジと直接競合することになるでしょう。共有流動性の観点から、Cosmos の最大の制限は、Ethereum に匹敵するネイティブステーブルコインや深い流動性を持つ DEX がないことでした。それは、Cosmos ネイティブのステーブルコイン (IST、CMST など) の台頭と、USDC のような資産の接続 (Axelar と Gravity ブリッジが USDC をもたらし、現在 Circle は Noble を介して Cosmos でネイティブ USDC をローンチ) によって変化しています。流動性が深まるにつれて、高いセキュリティとシームレスな IBC 転送の組み合わせは、Cosmos をマルチチェーン DeFi 取引の結節点にする可能性があります。実際、Blockchain Capital のレポートは、IBC が 2024 年初頭までにすでに LayerZero や Wormhole よりも多くの取引量を処理していたと指摘していますが、それは主に Cosmos 間のトラフィックの強さによるものです (これは非常に活発なインターチェーン経済を示唆しています)。今後、IBC の主な課題と機会は、そのセキュリティ精神を犠牲にすることなく異種のチェーンに拡大することです。

要約すると、各プロトコルは進化しています：LayerZero は多くのチェーンやアプリケーションと迅速に統合し、柔軟性と開発者の採用を優先し、アプリが自身のセキュリティの一部となることを可能にすることでリスクを軽減しています。Hyperlane はリステーキングとモジュール性で革新し、設定可能なセキュリティで新しいチェーンを接続する最も簡単な方法を目指していますが、まだ信頼と使用を構築中です。IBC はそのドメイン内での信頼性のゴールドスタンダードであり、現在はより高速に (IBC 3.0)、そして Cosmos を超えてそのドメインを拡張することを望んでおり、強力な実績に支えられています。ユーザーとプロジェクトは、それぞれの成熟度とセキュリティインシデントを考慮するのが賢明です。IBC は長年の安定した運用 (と膨大な取引量) を持っていますが、特定のエコシステムに限定されています。LayerZero は急速に使用を集めていますが、カスタムセキュリティ設定の理解が必要です。Hyperlane は実行面では新しいですが、ビジョンは有望で、経済的セキュリティに向けて慎重な一歩を踏み出しています。

結論と展望：マルチチェーンの未来のための相互運用性アーキテクチャ​

マルチチェーン DeFi ランドスケープの長期的な存続可能性と相互運用性は、おそらく3 つすべてのセキュリティモデルが共存し、さらには相互に補完し合うことによって形作られるでしょう。各アプローチには明確な強みがあり、画一的な解決策ではなく、ライトクライアントモデル (IBC) が主要なルート (特に主要チェーン間) で最高の保証を提供し、証明集約システム (LayerZero) がカスタマイズ可能な信頼で普遍的な接続性を提供し、マルチシグモデル (Hyperlane など) がニッチなニーズに応えたり、新しいエコシステムを迅速に立ち上げたりするスタックが見られるかもしれません。

セキュリティ vs 接続性のトレードオフ: IBC のようなライトクライアントは、「ブロックチェーンインターネット」に最も近いものを提供します。これは、TCP/IP に似た中立で標準化されたトランスポートレイヤーです。これらは、相互運用性が新たな弱点を導入しないことを保証し、これは長期的な持続可能性にとって重要です。しかし、これらは標準に関する広範な合意と、チェーンごとの значительнаяなエンジニアリングを必要とし、新しい接続が形成される速度を遅くします。一方、LayerZero と Hyperlane は、即時の接続性と柔軟性を優先し、すべてのチェーンが同じプロトコルを実装するわけではないことを認識しています。たとえそれが一時的にもう少し信頼を受け入れることを意味するとしても、「any to any」を接続することを目指しています。時間とともに、そのギャップは狭まると予想されます。LayerZero はより信頼最小化された DVN を組み込むことができ (IBC 自体も DVN にラップできるかもしれません)、Hyperlane は経済的なメカニズムを使用してネイティブ検証のセキュリティに近づくことができます。実際、Polymer プロジェクトは、IBC と LayerZero は競合相手である必要はなく、階層化できると考えています。例えば、LayerZero は利用可能な場合に IBC ライトクライアントを DVN の 1 つとして使用できます。このような相互作用は、この分野が成熟するにつれて起こりそうです。

構成可能性と統一された流動性: DeFi ユーザーの視点から見ると、最終的な目標は流動性がチェーンに依存しなくなることです。私たちはすでにその一歩を踏み出しています。オムニチェーントークン (OFT) を使えば、自分のトークンバージョンがどのチェーンにあるかを心配する必要はなく、クロスチェーンマネーマーケットを使えば、別のチェーンの担保に対してどのチェーンでも借り入れができます。アーキテクチャの選択は、これらのシステムに対するユーザーの信頼に直接影響します。ブリッジのハッキングが発生した場合 (歴史的に一部のマルチシグブリッジで起こったように)、それは信頼を破壊し、したがって流動性も破壊します。ユーザーはより安全な場所に後退するか、リスクプレミアムを要求します。したがって、一貫してセキュリティを実証するプロトコルが、最大の流動性プールを支えることになります。Cosmos のインターチェーンセキュリティと IBC は 1 つの道を示しました。ゾーン間の複数のオーダーブックと AMM は、転送が信頼性がなく迅速であるため、本質的に 1 つの大きな市場に構成されます。LayerZero の Stargate は別の道を示しました。統一された流動性プールが多くのチェーンの転送に対応できますが、ユーザーは LayerZero のセキュリティの前提 (オラクル+リレーヤーまたは DVN) を信頼する必要がありました。LayerZero v2 が各プールにさらに高いセキュリティを設定できるようにするにつれて (例：すべての転送を検証するために複数の大手検証者ネットワークを使用)、信頼のギャップを縮めています。マルチチェーン DeFi の長期的な存続可能性は、おそらく相互運用性プロトコルが見えなくても信頼できることにかかっています。インターネットユーザーが TCP/IP について考えないように、暗号ユーザーは dApp がどのブリッジやメッセージングシステムを使用しているかを心配する必要はありません。それは、セキュリティモデルが十分に堅牢で、障害が非常にまれであり、これらの相互運用性ネットワーク間に何らかの収束または構成可能性がある場合に起こります。

相互運用性の相互運用性: 数年後には、LayerZero vs Hyperlane vs IBC を別々の領域として話すのではなく、階層化されたシステムとして話すことが考えられます。例えば、Ethereum ロールアップは Polymer を介して Cosmos ハブへの IBC 接続を持つことができ、その Cosmos ハブは LayerZero エンドポイントも持つかもしれません。これにより、メッセージは安全な IBC チャネルを通じてロールアップから LayerZero のネットワークに転送できます。Hyperlane はフォールバックまたは集約として機能することさえできます。アプリは、究極の保証のために IBC 証明と Hyperlane AVS 署名の両方を要求できます。このようなプロトコル間のセキュリティの集約は、最も高度な脅威モデルにさえ対処できる可能性があります (IBC ライトクライアント と 独立したリステークされたマルチシグなどを同時に破壊することははるかに困難です)。もちろん、そのような組み合わせは複雑さとコストを追加するため、高価値のコンテキストに限定されるでしょう。

ガバナンスと分散化: 各モデルは、異なるアクターに異なる権限を与えます。IBC はチェーンのガバナンスの手に、LayerZero はアプリ開発者の手に (そして間接的に、彼らが選択する DVN オペレーターの手に)、Hyperlane はブリッジ検証者とおそらくリステーカーの手に権限を置きます。長期的な相互運用可能なランドスケープは、単一の当事者またはカルテルがクロスチェーントランザクションを支配できないことを保証する必要があります。これは、例えば、1 つのプロトコルがユビキタスになるが、少数のアクターによって制御されている場合のリスクです。それはチョークポイントになる可能性があります (中央集権的なインターネットサービスプロバイダーに類似)。それを軽減する方法は、メッセージングネットワーク自体を分散化すること (より多くのリレーヤー、より多くの DVN、より多くの検証者 – すべてがパーミッションレスで参加できる) と、代替パスを持つことです。この点では、IBC は多くの独立したチームを持つオープンスタンダードであるという利点があり、LayerZero と Hyperlane は両方ともサードパーティの参加を増やす方向に動いています (例：誰でも LayerZero DVN や Hyperlane 検証者を実行できる)。競争とオープンな参加がこれらのサービスを正直に保つ可能性が高いです。L1 のマイナー/検証者がベースレイヤーを分散化させているのと同じように。市場も足で投票します。1 つのソリューションが安全でない、または中央集権的すぎることが証明されれば、開発者は別のソリューションに移行できます (特にブリッジング標準がより相互運用可能になるにつれて)。

結論として、LayerZero v2、Hyperlane、および IBC 3.0 のセキュリティアーキテクチャは、それぞれ異なる哲学を持ちながら、マルチチェーン DeFi のビジョンを現実のものにすることに貢献しています。ライトクライアントは信頼性と中立性を優先し、マルチシグは実用性と統合の容易さを優先し、集約アプローチはカスタマイズと適応性を優先します。未来のマルチチェーン DeFi ランドスケープは、おそらくこれらの組み合わせを使用するでしょう。重要なインフラと高価値の転送は、信頼最小化または経済的に保護された方法で保護され、柔軟なミドルウェアが新しいチェーンやアプリのロングテールに接続します。これらが整備されれば、ユーザーは単一のチェーンを使用するのと同じ信頼と容易さで、統一された流動性とクロスチェーンの構成可能性を享受できるでしょう。前進する道は収束の道です。必ずしもプロトコル自体の収束ではなく、結果の収束です。相互運用性が安全で、シームレスで、標準である世界です。それを達成するには、継続的な厳格なエンジニアリング (悪用を避けるため)、協調的なガバナンス (IBC や普遍的なコントラクトインターフェースのような標準を設定するため)、そしておそらく最も重要なこととして、数学、経済的インセンティブ、インテリジェントな設計の最良の部分を融合させた、セキュリティへの反復的なアプローチが必要です。最終状態は、しばしば引用されるアナロジーを真に満たすかもしれません。インターネット上のネットワークのように相互接続されたブロックチェーン、そして LayerZero、Hyperlane、IBC のようなプロトコルが、DeFi が当面の間乗り続けるオムニチェーンハイウェイを形成するのです。

出典:

• LayerZero v2 アーキテクチャと DVN セキュリティ – LayerZero V2 Deep Dive; Flare x LayerZero V2 announcement
• Hyperlane マルチシグとモジュラー ISM – Hyperlane Docs: Validators; Tiger Research on Hyperlane; Hyperlane restaking (AVS) announcement
• IBC 3.0 ライトクライアントと機能 – IBC Protocol Overview; 3Commas Cosmos 2025 (IBC 3.0)
• 信頼の前提の比較 – Nosleepjohn (Hyperlane) on bridge tradeoffs; IBC vs bridges (Polymer blog)
• DeFi の例 (Stargate, ICA など) – Flare blog on LayerZero (Stargate volume); IBC use cases (Stride liquid staking); LayerZero Medium (OFT and OApp standards); Hyperlane use cases
• 採用と統計 – Flare x LayerZero (cross-chain messages, volume); Range.org on IBC volume; Blockchain Capital on IBC vs bridges; LayerZero blog (15+ DVNs); IBC testimonials (Osmosis, etc.).

スマートコントラクト監査における形式的検証​

形式的検証とは、数学的および論理ベースの技術を用いて、スマートコントラクトの正確性とセキュリティを証明することを指します。実際には、これにはプロパティベースのファズテストやシンボリック実行から、厳密な定理証明やモデル検査まで、さまざまな方法論が含まれます。その目的は、コントラクトが仕様を満たし、考えられるすべての入力と状態において悪用可能なバグを含まないことを保証することです。DeFi プロトコルには数十億ドルがロックされているという高いリスクを考慮すると、形式的手法はイーサリアムやその他のブロックチェーンプラットフォームにとってますます重要になっています。

従来のアプローチ: イーサリアムにおける初期の形式的手法には、Oyente や Mythril のようなシンボリック実行ツールや、Slither や Securify のような静的アナライザーが含まれていました。シンボリック実行は、シンボリックな入力を用いてプログラムのパスを探索し、問題 (例: リエントラシー、整数オーバーフロー) を検出します。一方、静的分析はルールベースのパターンマッチングを使用します。これらのツールは成功を収めてきましたが、限界もありました。例えば、Oyente は単純なコントラクトでさえ多くの誤報を出し、Slither のパターンベースの検出器はいくつかの偽陽性を生み出す可能性がありました。さらに、2023 年の研究では、現在のツールでは悪用可能なコントラクトのバグの 80% 以上 (特に複雑な「ビジネスロジック」のバグ) が見逃されていることが判明し、より堅牢な検証技術の必要性が浮き彫りになりました。

完全検証の可能性と課題: 理論上、形式的検証はすべての状態に対して不変条件を網羅的にチェックすることで、バグの不在を証明できます。Certora Prover や Ethereum Foundation の KEVM フレームワークのようなツールは、形式的仕様に対してスマートコントラクトを数学的に検証することを目指しています。例えば、Certora の「自動化された数学的監査人」は、仕様言語 (CVL) を使用して、ユーザー定義のルールを証明または反証します。しかし実際には、現実世界のコントラクトでプロパティを完全に証明することは、しばしば達成不可能であるか、非常に手間がかかります。検証のためにコードを単純化された形式に書き直す必要があったり、カスタム仕様を作成する必要があったり、ループや複雑な算術には手動で境界や抽象化が必要だったり、SMT ソルバーが複雑なロジックで頻繁にタイムアウトしたりします。Trail of Bits のエンジニアが指摘したように、「バグがないことを証明することは、通常、些細でないコードベースでは達成不可能です」。そして、それを達成するには、多くの場合、ユーザーの多大な介入と専門知識が必要です。このため、形式的検証ツールは伝統的に、コントラクト全体をエンドツーエンドで検証するのではなく、重要なコードの一部 (例: トークンの不変条件やコンセンサスアルゴリズムの検証) に限定的に使用されてきました。

Foundry のファズテストと不変条件テスト​

近年、完全な形式的証明に代わる実用的な代替手段として、プロパティベースのテストが登場しました。イーサリアムの人気開発フレームワークである Foundry は、ファズテストと不変条件テストを組み込みでサポートしています。これらの技術はテストカバレッジを大幅に向上させ、軽量な形式的検証と見なすことができます。Foundry のファズテストは、指定されたプロパティに違反しようと多数の入力を自動的に生成し、不変条件テストはこれを状態変化を伴う一連の操作に拡張します。

• ファズテスト: 特定の入力に対する単体テストを作成する代わりに、開発者は任意の入力に対して成立すべきプロパティや不変条件を指定します。その後、Foundry は何百、何千ものランダムな入力を生成して関数をテストし、プロパティが常に成立することを確認します。これにより、開発者が手動でテストしようと考えつかないようなエッジケースを捉えることができます。例えば、ファズテストでは、関数の戻り値が常に非負であることや、入力に関わらず特定の事後条件が真であることを表明 (assert) するかもしれません。Foundry のエンジンは、関数のシグネチャを分析し、エッジケースの値 (0, max uint など) を導入することで、プロパティを破る可能性のあるコーナーケースを突くインテリジェントなヒューリスティクスを使用します。アサーションが失敗した場合、Foundry はプロパティに違反する反例入力を報告します。

• 不変条件テスト: Foundry の不変条件テスト (別名ステートフルファジング) はさらに進んで、複数の関数呼び出しと状態遷移を連続して実行します。開発者は、コントラクトのライフタイムを通じて真であるべき不変条件関数 (例: 総資産 = ユーザー残高の合計) を記述します。Foundry はその後、ランダムな呼び出しシーケンス (ランダムな入力付き) を生成して多くの可能な使用シナリオをシミュレートし、不変条件が真であり続けることを定期的にチェックします。これにより、特定の操作シーケンスの後にのみ現れる複雑なバグを発見できます。本質的に、不変条件テストはコントラクトの状態空間をより徹底的に探索し、有効なトランザクションのいかなるシーケンスも、述べられたプロパティに違反できないことを保証します。

Foundry が重要な理由: Foundry はこれらの高度なテスト技術をアクセスしやすくしました。ファジングと不変条件の機能は開発者のワークフローにネイティブであり、特別なハーネスや外部ツールは不要で、テストは単体テストと並行して Solidity で記述されます。Rust ベースのエンジンのおかげで、Foundry は何千ものテストを迅速に (並列化して) 実行し、不変条件違反に対する詳細な失敗トレースを提供できます。開発者からは、Foundry のファザーは使いやすく高性能であり、わずかな設定 (例: 反復回数の設定や入力を制約するための仮定の追加) しか必要ないと報告されています。Foundry のドキュメントにある簡単な例は、divide(a,b) 関数のファズテストで、vm.assume(b != 0) を使用して自明な無効入力を避け、result * b <= a のような数学的な事後条件を表明します。このようなテストを何千ものランダムな (a,b) ペアで実行することで、Foundry は手動の推論では見つけるのが難しいエッジケース (オーバーフローの境界など) を迅速に発見するかもしれません。

比較: Foundry のアプローチは、コミュニティにおける先行研究に基づいています。Trail of Bits の Echidna ファザーは、イーサリアム向けの初期のプロパティベースのテストツールでした。Echidna も同様に、ブール値を返す Solidity 関数として表現された不変条件の違反を見つけるためにランダムなトランザクションを生成します。これは「インテリジェントな」入力生成 (カバレッジガイド付きファジングを組み込む) で知られており、多くのバグを発見するために使用されてきました。実際、セキュリティ研究者は Echidna のエンジンが非常に効果的であると指摘しています – 「Trail of Bits の Echidna は、そのインテリジェントな乱数選択により、最高のファザーです」 – ただし、Foundry の統合されたワークフローは、開発者にとってテストの記述をよりシンプルにします。実際には、Foundry のファズテストは、従来の単体テストを補完するものとして、安全な Solidity 開発のための新しい**「最低限の基準」**と見なされることがよくあります。これは (ランダム化されており網羅的ではないため) バグの不在を証明することはできませんが、広範な入力と状態の組み合わせをカバーすることで、信頼性を大幅に向上させます。

ファジングを超えて: 形式的証明と高度なツール​

ファジングと不変条件は多くの問題を捉えますが、より強力な形式的手法が使用されるケースもあります。モデル検査と定理証明は、望ましいプロパティを形式論理で指定し、自動化された証明器を使用してコントラクトコードに対してそれらをチェックすることを含みます。Certora Prover (最近オープンソース化) は、このカテゴリの著名なツールです。これにより、開発者はドメイン固有言語 (CVL) でルールを記述し、コントラクトがそれらのルールに違反していないかを自動的にチェックできます。Certora は、MakerDAO や Compound のようなプロトコルで重要な不変条件を検証するために使用されてきました。例えば、MakerDAO の「DAI 債務不変条件」バグ (4 年間気づかれなかった微妙な会計上の不整合) を特定しました。特筆すべきは、Certora のエンジンが現在複数のプラットフォーム (EVM, Solana の VM, eWASM) をサポートしており、2025 年にオープンソース化することで、イーサリアム、Solana、Stellar で産業グレードの形式的検証を無料で利用可能にしたことです。この動きは、形式的証明が資金力のあるチームだけの贅沢であってはならないという認識を示しています。

その他の形式的ツールには、ランタイム検証アプローチ (例: イーサリアムの KEVM セマンティクス、または Move ベースのチェーン用の Move Prover) があります。特に Move Prover は、Move 言語 (Aptos および Sui ブロックチェーンで使用) に組み込まれています。これにより、コードと並行して形式的仕様を記述でき、リンターや型チェッカーと同様のユーザーエクスペリエンスで特定のプロパティを自動的に証明できます。この緊密な統合により、これらのプラットフォームの開発者が開発の一部として形式的検証を使用する際の障壁が低くなります。

まとめ: 今日のスマートコントラクト監査は、これらの方法論を融合させています。ファジングと不変条件テスト (Foundry と Echidna が代表例) は、使いやすさと一般的なバグの捕捉における有効性から広く採用されています。シンボリック実行と静的アナライザーは、既知の脆弱性パターンを迅速にスキャンするために依然として役立っています (Slither のようなツールはしばしば CI パイプラインに統合されます)。一方、形式的検証ツールは成熟し、チェーンを越えて拡大していますが、その複雑さから、通常は特定の重要なプロパティや専門の監査会社によって使用されます。実際には、多くの監査はこれらのアプローチを組み合わせています。例えば、ファザーを使用してランタイムエラーを見つけ、静的ツールで明らかな間違いを指摘し、形式的仕様チェックで「トークン残高が総供給量を超えない」といった主要な不変条件を確認します。

大規模言語モデルによる AI 支援監査​

OpenAI の GPT-3/4 (ChatGPT) や Codex のような大規模言語モデル (LLM) の登場は、スマートコントラクト分析に新しいパラダイムをもたらしました。これらのモデルは、膨大な量のコードと自然言語でトレーニングされており、プログラムの振る舞いについて推論し、コードを説明し、パターン認識と「常識」的な知識によって特定の脆弱性を検出することさえできます。問題は、AI がスマートコントラクト監査を補強、あるいは自動化できるかということです。

LLM ベースの脆弱性分析ツール​

LLM をスマートコントラクト監査に適用するいくつかの研究努力とプロトタイプツールが登場しています。

• OpenAI Codex / ChatGPT (汎用モデル): 初期の実験では、単に GPT-3 や Codex にコントラクトコードをプロンプト入力し、潜在的なバグを尋ねるだけでした。開発者たちは、ChatGPT がいくつかのよく知られた脆弱性パターンを特定し、修正案を提案することさえできることを見出しました。しかし、応答は当たり外れがあり、信頼できるほど包括的ではありませんでした。最近の学術評価では、脆弱性検出のために ChatGPT に単純なプロンプトを入力することは、ベンチマークデータセットにおいて*「ランダムな予測と比較して有意に良い結果をもたらさなかった」*と指摘されています。つまり、モデルが適切に誘導されない場合、存在しない問題を幻覚 (hallucinate) したり、実際の脆弱性を見逃したりする可能性があります。これは、有用な結果を得るためには、慎重に設計されたプロンプトやファインチューニングが必要であることを浮き彫りにしました。

• AuditGPT (2024): これは、イーサリアムコントラクトの ERC 標準準拠をチェックするために ChatGPT (GPT-3.5/4) を特別に活用した学術ツールです。研究者たちは、多くの ERC20/ERC721 トークンコントラクトが標準の微妙なルールに違反していること (これがセキュリティや互換性の問題につながる可能性がある) を観察しました。AuditGPT は、監査を小さなタスクに分割し、各ルールタイプに特化したプロンプトを設計することで機能します。その結果は印象的でした。実際のコントラクトでのテストで、AuditGPT は*「418 件の ERC ルール違反を成功裏に特定し、偽陽性は 18 件しか報告しなかった」*とされ、高い精度を示しました。実際、この論文は、AuditGPT が ERC 準拠のバグを見つける上で、専門の監査サービスを上回り、より低コストであったと主張しています。これは、(標準ルールのリストを強制するような) よく定義された狭いドメインでは、優れたプロンプトを持つ LLM が驚くほど効果的かつ正確であり得ることを示唆しています。

• LLM-SmartAudit (2024): 別の研究プロジェクトである LLM-SmartAudit は、Solidity コードを監査するためにマルチエージェント対話システムを使用するという、より広範なアプローチを取っています。これは、複数の特化した GPT-3.5/GPT-4 エージェント (例: 正確性に焦点を当てる「監査人」、悪用方法を考える「攻撃者」) を設定し、互いに対話させてコントラクトを分析します。彼らの評価では、LLM-SmartAudit は広範な脆弱性を検出することができました。特筆すべきは、従来のツールとの比較テストで、GPT-3.5 ベースのシステムが最高の総合再現率 (74%) を達成し、テストしたすべての従来の静的およびシンボリックアナライザーを上回ったことです (次点は Mythril の 54% の再現率でした)。また、テストスイートに含まれる 10 種類の脆弱性をすべて見つけることができました (一方、各従来ツールはいくつかのカテゴリで苦戦しました)。さらに、GPT-4 に切り替えて分析を集中させる (彼らがターゲット分析モードと呼ぶもの) ことで、Slither や Mythril のようなツールが完全に見逃した複雑な論理的欠陥を検出できました。例えば、現実世界の DeFi コントラクトのセットに対して、LLM ベースのアプローチは何百ものロジックバグを発見しましたが、静的ツールはそれらの問題を*「検出する上で効果を示さなかった」*とされています。これらの結果は、LLM が従来のアナライザーのパターンマッチングの範囲を超える微妙なバグを捉える可能性を示しています。

• Prometheus (PromFuzz) (2023): ハイブリッドなアプローチは、LLM を使用して他の技術を誘導することです。一つの例は PromFuzz で、GPT ベースの「監査人エージェント」を使用してコードの疑わしい領域を特定し、その後、不変条件チェッカーを自動的に生成してファジングエンジンに供給します。本質的に、LLM は一次分析 (良性および攻撃者の両方の視点から) を行い、ファズテストを脆弱性の可能性が高い箇所に集中させます。評価では、このアプローチは非常に高いバグ発見率を達成しました – 例えば、特定のベンチマークセットで偽陽性ゼロで 86% 以上の再現率 – これは、スタンドアロンのファザーや以前のツールを大幅に上回ります。これは有望な方向性です。AI を使用してファジングのような古典的な技術をオーケストレーションし、強化することで、両方の長所を組み合わせることです。

• その他の AI ツール: コミュニティでは、他にもさまざまな AI 支援監査のコンセプトが見られます。例えば、Trail of Bits の「Toucan」プロジェクトは、OpenAI Codex を監査ワークフローに統合しました (その発見については後述)。一部のセキュリティスタートアップも AI 監査人を宣伝しており (例: 「ChainGPT Audit」サービス)、通常は GPT-4 をカスタムプロンプトでラップしてコントラクトをレビューします。オープンソースの愛好家は、Solidity のスニペットを受け取って潜在的な問題をアウトプットする ChatGPT ベースの監査ボットをフォーラムで作成しています。これらの多くは実験的なものですが、一般的な傾向は明らかです。AI は、自動化されたコードの説明やドキュメント生成から、脆弱性の検出、さらには修正案の提案まで、セキュリティレビュープロセスのあらゆるレベルで探求されています。

LLM 監査人の能力と限界​

LLM は、スマートコントラクト監査において注目すべき能力を示しています。

• 広範な知識: GPT-4 のような LLM は、無数のコードと脆弱性についてトレーニングされています。一般的なセキュリティの落とし穴 (リエントラシー、整数オーバーフローなど) や、過去のいくつかのエクスプロイトについても「知って」います。これにより、バグを示す可能性のあるパターンを認識し、ドキュメントからベストプラクティスを思い出すことができます。例えば、ERC-20 の transferFrom がアローワンスをチェックすべきことを覚えており (そのようなチェックがないことを違反としてフラグ付けするかもしれません)。既知のパターンのみをフラグ付けする静的ツールとは異なり、LLM は新しいコードに推論を適用し、ツール開発者によって明示的にコーディングされていない問題を推測できます。

• 自然な説明: AI 監査人は、潜在的な問題について人間が読める説明を提供できます。これは開発者体験にとって非常に価値があります。従来のツールはしばしば解読に専門知識を要する不可解な警告を出力しますが、GPT ベースのツールは平易な英語でバグを説明し、修正案を提案することさえできる段落を生成できます。例えば、AuditGPT は ERC ルール違反をフラグ付けするだけでなく、なぜコードがルールに違反したのか、そしてその影響が何であるかを説明しました。これは、経験の浅い開発者をセキュリティコンセプトに慣れさせるのに役立ちます。

• 柔軟性: プロンプトエンジニアリングにより、LLM は異なる側面に焦点を当てたり、カスタムのセキュリティポリシーに従うように指示されたりすることができます。固定されたルールのセットに限定されません – プロパティやパターンを言葉で説明できれば、LLM はそれをチェックしようと試みることができます。これにより、独自の不変条件やロジックを持つ可能性のある新しいプロトコルの監査に魅力的になります (カスタムの静的分析をゼロから書くのは非現実的でしょう)。

しかし、重大な課題と信頼性の問題も観察されています。

• 推論の限界: 現在の LLM は、セキュリティ分析に必要な複雑な論理的推論に苦労することがあります。Trail of Bits は、*「モデルは、コントラクトの所有権、リエントラシー、関数間の関係など、特定の高レベルの概念についてうまく推論することができません」*と報告しました。例えば、GPT-3.5/4 はリエントラシーが理論上何かを理解しているかもしれませんが (そしてそれを説明することさえできるかもしれませんが)、関数をまたいだ呼び出しシーケンスと状態変化を理解する必要がある場合、リエントラシーの脆弱性を認識できないかもしれません。モデルはまた、複数コントラクト間の相互作用や時間依存のロジックを含む脆弱性を見逃す可能性もあります。なぜなら、それらは単一のコードスニペット分析の範囲を超えるからです。

• 偽陽性とハルシネーション: 大きな懸念は、LLM が自信に満ちたように聞こえるが、誤った結論を出す可能性があることです。監査において、「ハルシネーション」とは、実際には存在しない脆弱性をフラグ付けしたり、コードを誤解したりすることかもしれません。Trail of Bits の Codex (GPT) を用いた実験では、より大規模な現実世界のコントラクトにスケールアップするにつれて、「偽陽性とハルシネーションの率が非常に高くなり」、監査人をあまりにも多くの偽の報告で遅らせるほどになったことがわかりました。この予測不可能性は問題です – あまりにも頻繁にオオカミ少年を叫ぶツールは、開発者に信頼されません。AuditGPT が偽陽性を低く抑えることに成功したこと (何百もの発見のうち 18 件のみ) は心強いですが、それは制約されたドメインでのことでした。汎用的な使用では、AI の発見をフィルタリングするために、慎重なプロンプト設計や、おそらく人間のレビューのループが必要です。

• コンテキストの限界: LLM にはコンテキストウィンドウの制限があり、一度に「見える」コードの量に限りがあります。複雑なコントラクトはしばしば複数のファイルと何千行にも及びます。AI がコードベース全体を取り込めない場合、重要な関連性を見逃す可能性があります。コードスライシング (コントラクトをチャンクで供給する) のような技術が使用されますが、それらはより広い視野を失うリスクがあります。LLM-SmartAudit チームは、GPT-3.5 の 4k トークン制限では、より大きなコンテキストを持つ GPT-4 に切り替えるまで、いくつかの大規模な現実世界のコントラクトを分析できなかったと指摘しました。それでも、分析を部分に分けることは、システム全体を考慮した場合にのみ現れるバグを見落とす原因となる可能性があります。これにより、(複数の相互作用するコントラクトを持つ) プロトコル全体の AI 分析は、現時点では真の課題となっています。

• 統合とツール: AI 監査人を取り巻く堅牢な開発者向けツールが不足しています。LLM 分析を実行することは、リンターを実行するほど簡単ではありません。モデルへの API 呼び出し、プロンプトエンジニアリングの処理、レート制限、AI の応答の解析などが含まれます。ある監査チームが述べたように、「LLM を従来のソフトウェアと統合するためのソフトウェアエコシステムはあまりにも未熟で、すべてが面倒です」。AI 監査人を CI パイプラインに継続的にデプロイし、その不確実性を管理するための既製のフレームワークは事実上存在しません。これは徐々に改善されていますが (一部のプロジェクトでは、コードレビューに GPT-4 を使用する CI ボットを模索しています)、まだ初期段階です。さらに、AI が特定の結果を出した理由をデバッグすることは困難です – 決定論的なツールとは異なり、モデルが何かをフラグ付けしたり見逃したりするに至ったロジックを簡単に追跡することはできません。

• コストとパフォーマンス: GPT-4 のような大規模モデルの使用は高価であり、遅くなる可能性があります。AI 監査を CI/CD パイプラインに組み込みたい場合、コントラクトごとに数分が追加され、大規模なコードに対してはかなりの API コストが発生する可能性があります。ファインチューニングされたモデルやオープンソースの LLM はコストを軽減できますが、GPT-4 ほど高性能ではない傾向があります。コードセキュリティのためのより小規模で特化したモデルに関する研究が進行中ですが、現在のところ、最高の結果は大規模なプロプライエタリモデルから得られています。

要約すると、LLM 支援監査は有望ですが、万能薬ではありません。 AI がテストを生成したり、特定の側面を分析したりするのを助けるハイブリッドなアプローチが見られますが、監査全体をエンドツーエンドで行うわけではありません。例えば、AI が潜在的な不変条件やリスクのある領域を提案し、それを人間や別のツールが調査するかもしれません。あるセキュリティエンジニアが述べたように、推論のギャップや統合のハードルを考えると、この技術はまだ重要なタスクで人間の監査人を置き換える準備ができていません。しかし、それはすでに有用なアシスタントになることができます – 従来のツールが及ばない場合に*「不完全なものが何もないよりはるかに良いかもしれない」*のです。

さまざまなツールチェーンの精度と信頼性​

議論されたさまざまな監査アプローチの精度、カバレッジ、信頼性を比較することは有益です。以下は、研究および業界の評価からの知見の要約です。

• 静的分析ツール: Slither のような静的アナライザーは、迅速なフィードバックと使いやすさで評価されています。これらは通常、高い適合率を持ちますが、再現率は中程度です – つまり、報告される問題のほとんどは真の問題ですが (設計上、偽陽性は少ない)、特定のクラスの脆弱性しか検出しません。2024 年のベンチマーク研究 (LLM-SmartAudit の RQ1) では、Slither がテストスイート内の既知の脆弱性の約 46% を捕捉したことがわかりました。Mythril (シンボリック実行) はわずかに優れており、54% の再現率でした。各ツールは特定のバグタイプに強みを持っていましたが (例: Slither は算術問題や tx.origin の使用を見つけるのが非常に得意で、シンボリックツールは単純なリエントラシーシナリオを見つけるのに優れています)、どれも包括的なカバレッジを持っていませんでした。Slither のような成熟したツールの偽陽性は比較的低く、開発者は*「最小限の誤報と迅速な実行 (コントラクトあたり 1 秒未満)」*を宣伝しており、CI での使用に適しています。それでも、静的ツールはコードが複雑なパターンを使用している場合に誤動作する可能性があり、実際には処理されているエッジケースをフラグ付けしたり、既知のアンチパターンに一致しない深いロジックバグを見逃したりすることがあります。

• ファジングとプロパティテスト: Foundry のファズ/不変条件テストや Trail of Bits の Echidna のようなファザーは、ランタイムエラーや不変条件違反を見つけるのに非常に効果的であることが証明されています。これらのツールは、バグが報告された場合 (アサーションが失敗した場合)、それが実際の反例実行であるという意味で、偽陽性がほぼゼロである傾向があります。トレードオフは偽陰性にあります – バグがテストされた入力空間や実行回数内で現れない場合、見過ごされる可能性があります。カバレッジは、ファザーが状態空間をどれだけうまく探索するかに依存します。十分な時間と優れたヒューリスティクスがあれば、ファザーは静的分析が見逃した多くの高深刻度のバグを発見してきました。例えば、Echidna は、形式的検証の努力を要した MakerDAO と Compound のバグを迅速に再現することができました。しかし、ファジングはすべてのロジックミスを見つけることを保証するものではありません。コントラクトがより複雑になるにつれて、ファザーはより深い状態に到達するために追加の不変条件を記述したり、より賢い検索戦略を使用したりする必要があるかもしれません。メトリクスの観点から、ファジングには単一の「再現率」の数値はありませんが、逸話的な証拠によれば、重要な不変条件は、もし破れるのであれば、通常ファザーによって破られることができます。見つかったものに対する信頼性は高いですが (偽の報告に対する手動のトリアージは不要)、ファズテストに合格したことが正確性の証明ではないことを覚えておく必要があります – それは単に信頼性の向上です。

• 形式的検証ツール: 適用可能な場合、形式的検証は最高の保証を提供します – 証明が成功すれば、状態の 100% がプロパティを満たすことを意味します。精度の観点からは、証明できるプロパティに対しては事実上完璧 (健全かつ完全) です。ここでの最大の問題は、結果の精度ではなく、使用の難しさと範囲の狭さです。形式的ツールは、実際には偽陰性を持つこともあります。複雑さのために真のプロパティを証明できない場合があり (結果なしまたはタイムアウトとなり、これは偽陽性ではありませんが、実際には安全なものを検証できないことを意味します)。また、仕様のエラーを持つこともあり、ツールが意図したプロパティではないものを「証明」してしまうことがあります (ユーザーエラー)。実際の監査では、形式的手法はいくつかの重要なバグを捉えてきました (Certora の成功例には、微妙な SushiSwap のバグや PRBMath ライブラリの問題をデプロイ前に捉えたことが含まれます)。しかし、その実績は、それらがどれだけ包括的に適用されるかが稀であることによって制限されています – Trail of Bits が指摘したように、「ファジングによって見つかった多くのバグとは対照的に、形式的検証のみによって発見された公開された問題を見つけるのは困難でした」。したがって、形式的検証は成功した場合は非常に信頼性が高いですが、ツールチェーン全体のカバレッジへの影響は、必要な労力と専門知識によって制約されます。

• LLM ベースの分析: AI 監査人の精度は現在、新しい技術 (および新しいモデル) が急速に限界を押し上げているため、変動する目標です。いくつかのデータポイントを拾うことができます。

• ERC ルールに焦点を当てた AuditGPT システムは、非常に高い適合率 (偽陽性数で約 96%) を達成し、静的ツールや人間が見落とした何百もの問題を発見しました。しかし、これは構造化されたプロンプトを持つ狭いドメインでのことでした。ChatGPT が任意の脆弱性ハンティングで 96% の精度を持つと一般化すべきではありません – 制御された設定の外では、そのパフォーマンスは低くなります。

• より広範な脆弱性検出において、LLM-SmartAudit (GPT-3.5) は、中程度の偽陽性率でベンチマークにおいて約 74% の再現率を示し、これは単一の従来ツールよりも優れていました。特化したプロンプトを持つ GPT-4 (TA モード) にアップグレードすると、大幅に改善されました – 例えば、1,400 の現実世界の脆弱性のセットに対して、GPT-4 エージェントは特定のイシューの約 48% と複雑なロジックイシューの約 47% を発見しましたが、Slither/Mythril/Conkas はそれぞれそれらの特定の複雑なイシューを約 0% (なし) しか見つけませんでした。これは、LLM が静的分析が完全に見逃すタイプのバグにカバレッジを劇的に拡大できることを示しています。一方で、LLM はイシューの半分以上を見つけられなかったため (したがって、かなりの偽陰性もあります)、報告したものの中にどれだけの偽陽性があったかは明らかではありません – この研究は適合率よりも再現率に焦点を当てていました。

• Trail of Bits の Codex/GPT-4 「Toucan」 実験は、信頼性の問題を示しています。当初、小さな例では、Codex は慎重なプロンプトで既知の脆弱性 (所有権の問題、リエントラシー) を特定できました。しかし、スケールアップを試みるとすぐに、一貫性のない誤った結果に遭遇しました。彼らは*「平均的なサイズのコードでさえ失敗の数が多かった」と報告し、予測が困難でした。最終的に、彼らは GPT-4 (2023 年初頭時点) はインクリメンタルな改善に過ぎず、関数間のフローに関する推論のような「重要な機能が欠けている」と結論付けました。その結果、AI は静的ツールからの偽陽性を実質的に減らすことはなく*、監査ワークフローを確実に高速化することもしませんでした。言い換えれば、汎用 LLM の監査人としての現在の信頼性は、その試行においてプロの監査人によって不十分と見なされました。

まとめると、各ツールチェーンには異なる強みがあります。

• 静的ツール: 既知の問題の迅速な検出に信頼性があります。ノイズが少なく、しかしバグの種類は限定的です (ベンチマークでの再現率は中程度で約 40–50%)。
• ファズ/不変条件テスト: 非常に高い適合率 (偽のアラートはほとんどなし) で、機能的および状態依存のバグを見つけるのに強いです。カバレッジは広い可能性がありますが、保証されていません (単純なメトリクスはなく、時間と不変条件の質に依存します)。十分なガイダンスがあれば、形式的証明が見つけるであろう同じバグをしばしば見つけます。
• 形式的検証: 特定のプロパティに対する絶対的な正確性のゴールドスタンダードです。成功裏に適用されれば、それらのプロパティに対しては実質的に 100% の再現率/適合率です。しかし、実際には狭い問題に限定され、かなりの労力を必要とします (まだ完全な監査のためのワンボタンソリューションではありません)。
• AI (LLM) 分析: 潜在的に高いカバレッジ – 他のツールが見逃したカテゴリを含むバグを見つけることができます – しかし、適合率は変動します。特化した設定では、(AuditGPT が ERC チェックで示したように) 適合率と網羅性の両方を兼ね備えることができます。慎重な制約がなければ、広範な網を投げかけ、結果を人間が検証する必要があります。脆弱性検出における ChatGPT の「平均的な」精度は目覚ましいものではありませんが (ある研究では推測に近い)、LLM を使用した最高のエンジニアリングシステムは、従来のツールを超えるパフォーマンスを発揮しています。AI の出力をより信頼できるものにするための活発な研究があります (例: 複数のエージェントに相互検証させる、または LLM と静的推論を組み合わせて AI の結論を再確認する)。

アプローチを組み合わせることで最良の結果が得られることは注目に値します。例えば、Slither を実行し (ノイズなしで手軽な問題を捉えるため)、次に Foundry/Echidna を使用してより深い振る舞いをファズし、おそらく LLM ベースのツールを使用して考慮されていないパターンや不変条件をスキャンするかもしれません。それぞれが他のツールの死角をカバーします。

現実世界での採用における課題と限界​

実際には、形式的検証や AI ツールを開発ワークフローに採用するには、実用的な課題が伴います。いくつかの主要な問題は次のとおりです。

• 開発者体験と専門知識: 従来の形式的検証には急な学習曲線があります。形式的仕様 (CVL, Coq, Move の仕様言語など) を書くことは、コードを書くことよりも数学的な証明を書くことに似ています。多くの開発者はこの背景を欠いており、形式的手法の専門家は不足しています。対照的に、Foundry でのファジングや Solidity での不変条件の記述ははるかにアクセスしやすいです – それは追加のテストを書くように感じられます。これが、イーサリアムコミュニティで形式的証明よりもファズテストが急速に普及した大きな理由です。Trail of Bits チームは、ファジングは多くの場合、形式的手法よりも**「同様の結果を生み出すが、スキルと時間は大幅に少なくて済む」**と明示的に述べています。したがって、形式的検証は異なるバグを捉えることができますが、多くのチームはより少ない労力で十分な結果を得られる簡単なアプローチを選択します。

• 開発ワークフローへの統合: ツールが広く採用されるためには、CI/CD パイプラインや日常のコーディングに適合する必要があります。Slither のようなツールはここで輝きます – それは*「CI/CD セットアップに簡単に統合でき、自動化を合理化し、開発者を支援します。」* 開発者は Slither や Mythril を GitHub Action に追加し、問題が見つかった場合にビルドを失敗させることができます。Foundry のファズテストは、毎回 forge test の一部として実行できます。不変条件テストは、CloudExec のようなツールを使用してクラウドで継続的に実行することもでき、失敗は fuzz-utils を使用して自動的に単体テストに変換できます。これらの統合により、開発者は迅速なフィードバックを得て、反復作業を行うことができます。対照的に、Certora Prover のようなものは、歴史的に別のプロセスとして (または外部の監査チームによって) 実行され、結果を出すのに数時間かかる場合がありました – これは毎回のコミットで実行するようなものではありません。AI ベースのツールも統合のハードルに直面しています。API を呼び出し、その出力を CI で決定論的に処理することは簡単ではありません。また、セキュリティとプライバシーの問題もあります – 多くの組織は、分析のために独自のコントラクトコードをサードパーティの AI サービスに送信することに不安を感じています。セルフホストの LLM ソリューションは、まだ大手クラウド API ほど強力ではないため、これは AI 監査人の CI 採用における難点です。

• 偽陽性とノイズ: 多くの偽陽性や低深刻度の発見を報告するツールは、開発者の信頼を低下させる可能性があります。静的アナライザーは過去にこれで苦労してきました – 例えば、一部のツールの初期バージョンは、ユーザーに警告の洪水をもたらし、その多くは無関係でした。シグナルとノイズのバランスは非常に重要です。Slither は最小限の誤報で賞賛されていますが、Securify のようなツール (その研究形態では) はしばしば手動でのフィルタリングが必要な多くの警告を生成しました。LLM は、議論したように、適切にターゲットを絞らないとノイズを生成する可能性があります。これが、現在 AI の提案が通常、絶対的なものではなく助言として受け取られる理由です。チームは、別のセキュリティチームや監査の文脈で実行される場合に、ノイズの多いツールを採用する可能性が高くなりますが、日常的な使用では、開発者は明確で実行可能な結果を低ノイズで提供するツールを好みます。理想は、仮説ではなく、明確なバグに対してのみ**「ビルドを失敗させる」**ことです。その信頼性を達成することは、特に AI ツールにとって、継続的な課題です。

• スケーラビリティとパフォーマンス: 形式的検証は計算集約的になる可能性があります。前述のように、ソルバーは複雑なコントラクトでタイムアウトする可能性があります。これにより、大規模なシステムへのスケーリングが困難になります。1 つのプロパティを検証するのに数時間かかる場合、コードの変更ごとに数十のプロパティをチェックすることはありません。ファズテストもスケーラビリティの限界に直面します – 巨大な状態空間や多くのメソッドを持つコントラクトを組み合わせ的に探索するのは遅くなる可能性があります (ただし、実際にはファザーはバックグラウンドや夜間に実行して探索を深めることができます)。AI モデルには固定のコンテキストサイズがあり、モデルの容量を増やすのは高価です。GPT-4 の 128k トークンのコンテキストは恩恵ですが、それに数百キロバイトのコントラクトコードを供給するのはコストがかかり、非常に大規模なプロジェクトにはまだ十分ではありません (多くのコントラクトを持つ複雑なプロトコルを想像してみてください – それを超える可能性があります)。また、マルチチェーンのスケーリングもあります。プロジェクトが異なるチェーン上のコントラクト間の相互作用 (イーサリアム ↔ 別のチェーン) を含む場合、そのクロスチェーンロジックを検証または分析することはさらに複雑で、現在のツールの範囲を超える可能性があります。

• 人間の監督と検証: 最終的には、ほとんどのチームは最終的な承認のために専門の人間の監査人に依存しています。自動化されたツールは補助であり、代替ではありません。これらのすべてのツールの 1 つの限界は、既知のプロパティやパターンの範囲内で動作することです。まったく新しいタイプのバグや、DeFi プロトコルの設計における微妙な経済的欠陥を見逃す可能性があります。人間の監査人は、直感と経験を用いて、攻撃者がシステムにどのようにアプローチするかを、ツールが明示的にプログラムされていない方法で検討します。コントラクトがすべての自動チェックに合格したが、後で人間がビジネスロジックや創造的な攻撃ベクトルに脆弱性を見つけたケースがありました。したがって、課題は誤った安心感を避けることです – 開発者は形式的ツールと AI の出力を正しく解釈し、「問題は見つかりませんでした」がコードが 100% 安全であることを意味すると思い込んではなりません。

• 仕様とテストの維持: 特に形式的検証において、1 つの実用的な問題は仕様のドリフトです。仕様 (不変条件、ルールなど) は、コードが進化するにつれて古くなる可能性があります。コードとその形式的仕様が同期していることを確認することは、簡単な管理タスクではありません。開発者が注意を怠ると、証明は単にコードの実際の要件にもはや関連しないものを証明しているために「合格」するかもしれません。同様に、不変条件テストは、システムの期待される動作が変化するにつれて更新する必要があります。これには、すべてのチームが持っているわけではない不変条件駆動開発の文化が必要です (ただし、それを奨励する動きはあります)。

要約すると、主な限界は技術の生の能力よりも人とプロセスです。形式的および AI 支援の手法はセキュリティを大幅に向上させることができますが、開発者のワークフローとスキルセットに適合する方法で展開する必要があります。心強いことに、不変条件駆動開発 (初日から重要な不変条件を書き留める) のようなトレンドが勢いを増しており、ツールは高度な分析をよりプラグアンドプレイにするために徐々に改善されています。主要なツール (例: Certora Prover) のオープンソース化や、人気のあるフレームワーク (Foundry) へのファジングの統合は、障壁を下げています。時間とともに、「平均的な開発者」ができることと「博士号を持つ研究者」ができることのギャップは、これらの強力な検証技術を使用する点で狭まると予想されます。

オープンソース vs 商用監査ツール​

スマートコントラクトセキュリティツールの状況には、オープンソースプロジェクトと商用サービスの両方が含まれます。それぞれに役割があり、しばしば互いに補完し合います。

• オープンソースツール: イーサリアムエコシステムで広く使用されている監査ツールの大部分はオープンソースです。これには、Slither (静的アナライザー)、Mythril (シンボリック実行)、Echidna (ファザー)、Manticore (シンボリック/コンコリック実行)、Securify (ETH Zurich のアナライザー)、Solhint/Ethlint (リンター)、そしてもちろん Foundry 自体が含まれます。オープンソースツールが好まれる理由はいくつかあります。(1) 透明性 – 開発者はツールがどのように機能するかを見ることができ、悪意のあるものや隠されたものがないことを信頼できます (オープンなエコシステムでは重要です)。(2) コミュニティの貢献 – ルールや機能は広範なコミュニティによって追加されます (例えば、Slither には多くのコミュニティが貢献した検出器があります)。(3) コスト – 無料で使用できるため、Web3 の多くの小規模プロジェクト/スタートアップにとって重要です。(4) 統合 – オープンツールは通常、法的なハードルなしにローカルまたは CI で実行でき、プロジェクト固有のニーズに合わせてカスタマイズまたはスクリプト化できることが多いです。

オープンソースツールは急速に進化しています。例えば、Slither の新しい Solidity バージョンやパターンへのサポートは、Trail of Bits によって継続的に更新されています。ConsenSys が開発した Mythril は、イーサリアムだけでなく、バイトコード上で動作することで任意の EVM 互換チェーンを分析できます – これは、オープンツールがチェーンを越えて簡単に再利用できることを示しています。オープンツールの欠点は、しばしば*「自己責任で使用」*することであり、公式のサポートや保証がないことです。商用製品の UI のような洗練さやスケーラビリティがないかもしれません。しかし、ブロックチェーンでは、多くの企業でさえ、内部でコアツールとしてオープンソースを使用しています (時にはわずかなカスタム変更を加えて)。

• 商用サービスとツール: いくつかの企業がセキュリティ分析を製品として提供しています。例としては、MythX (ConsenSys Diligence によるクラウドベースのスキャン API)、Certora (オープンソース化する前にプローバーをサービスとして提供)、CertiK と SlowMist (監査で使用したりダッシュボード経由で提供したりする内部スキャナーと AI を持つ企業)、そして Securify from ChainSecurity (会社は買収され、そのツールは内部で使用された) や SolidityScan (監査レポートを出力するクラウドスキャナー) のような新しい参入企業があります。商用ツールは、よりユーザーフレンドリーな体験や統合されたサービスを提供することを目指していることが多いです。例えば、MythX は IDE 拡張機能や CI プラグインと統合されており、開発者はコントラクトを MythX に送信して、脆弱性スコアや問題修正の詳細を含む詳細なレポートを受け取ることができました。これらのサービスは通常、偽陽性を最小限に抑えるように調整された分析技術の組み合わせ (パターンマッチング、シンボリック実行など) を内部で実行します。

商用ツールの価値提案は、通常、利便性とサポートです。脆弱性の知識ベースを継続的に更新し、結果の解釈に関するカスタマーサポートを提供する場合があります。また、クラウドで重い計算を処理することもあります (そのため、ローカルでソルバーを実行する必要がありません)。しかし、コストが要因です – 多くのプロジェクトは、無料の代替手段が利用可能であるため、これらのサービスの料金を支払わないことを選択します。さらに、分散化の精神に基づき、一部の開発者はセキュリティのためにクローズドソースのサービスに依存することに躊躇します (「信頼するな、検証せよ」という精神)。2025 年の Certora Prover のオープンソース化は注目すべき出来事です。それは、ハイエンドの商用ツールだったものをコミュニティリソースに変えました。この動きは、有料ライセンスなしで誰でも自分のコントラクトを形式的に検証しようと試みることができ、コードのオープン性により研究者がツールを改善したり、他のチェーンに適応させたりできるため、採用を加速させると期待されています。

• 人間による監査サービス: ソフトウェアツールだけでなく、多くの監査は専門の会社 (Trail of Bits, OpenZeppelin, Certik, PeckShield など) によって行われていることにも言及する価値があります。これらの会社は、上記のツール (主にオープンソース) と独自のスクリプトを組み合わせて使用します。これらの取り組みの成果物は、しばしば非公開にされるか、監査レポートで要約されるだけです。商用監査会社でさえオープンソースツールに大きく依存しているため、ここには「オープン vs 商用」という二分法は正確にはありません。差別化は、専門知識と手作業の労力にあります。とはいえ、一部の会社は、自社に優位性を与えるために、独自の AI 支援監査プラットフォームを開発しています (例えば、*「ChainGPT」*が内部監査に使用されているという報告や、CertiK がオンチェーン監視のために Skynet という AI を開発しているという報告がありました)。これらは公開ツールではないため、その精度や方法は広く文書化されていません。

実際には、一般的なパターンはオープンソースが第一で、商用は任意です。チームは開発とテスト中にオープンツールを使用します (簡単に統合でき、必要なだけ実行できるため)。その後、デプロイ前に追加のチェックとして 1 つか 2 つの商用サービスを使用するかもしれません – 例えば、MythX スキャンを実行して「セカンドオピニオン」を得たり、Certora のような高度なツールを使用して重要なコンポーネントを形式的に検証する会社を雇ったりします。境界線が曖昧になるにつれて (Certora がオープンソースになり、MythX の結果がオープンツールと重複することが多い)、区別は能力よりもサポートと利便性に関するものになりつつあります。

注目すべきクロスオーバーは、Certora のマルチチェーンサポートです – Solana と Stellar を正式にサポートすることで、オープンな代替手段が少ないプラットフォームに対応しています (例えば、イーサリアムには多くのオープンツールがありますが、Solana には最近までほとんどありませんでした)。セキュリティツールが新しいエコシステムに拡大するにつれて、少なくともオープンソースが追いつくまでは、商用製品がギャップを埋めることが増えるかもしれません。

最後に、オープン vs 商用はここでは敵対的ではないことに注意する価値があります。それらはしばしば互いに学び合います。例えば、学術/商用ツールで開拓された技術 (Securify で使用された抽象解釈など) は、最終的にオープンツールに取り入れられ、逆に、オープンツールの使用から得られたデータは商用ツールの改善を導くことができます。両者が求める最終結果は、エコシステム全体のセキュリティ向上です。

クロスチェーンへの適用性​

イーサリアムはこれらのツールのほとんどの焦点となってきましたが (スマートコントラクト活動におけるその優位性を考えると)、形式的検証と AI 支援監査の概念は他のブロックチェーンプラットフォームにも適用可能です。以下にその適用方法を示します。

• EVM 互換チェーン: BSC, Polygon, Avalanche C-Chain など、イーサリアム仮想マシンを使用するブロックチェーンは、すべての同じツールを直接使用できます。ファズテストや静的分析は、コントラクトがイーサリアムメインネットにデプロイされるか Polygon にデプロイされるかを気にしません – バイトコードとソース言語 (Solidity/Vyper) は同じです。実際、Mythril と Slither は、アドレスからバイトコードを取得することで、任意の EVM チェーンのコントラクトを分析できます (Mythril は RPC エンドポイントさえあればよい)。これらのチェーン上の多くの DeFi プロジェクトは、イーサリアムプロジェクトと同様に Slither と Echidna を実行します。BSC や Avalanche 上のプロトコルの監査は、通常、イーサリアムの監査と同一のツールキットを使用します。したがって、EVM コンテキストでのクロスチェーンは、主にイーサリアムのツールチェーンを再利用することを意味します。

• Solana: Solana のスマートコントラクトは Rust で書かれ (通常は Anchor フレームワーク経由)、BPF 仮想マシン上で実行されます。これはイーサリアムとは非常に異なる環境であるため、イーサリアム固有のツールはそのままでは機能しません。しかし、同じ原則は適用されます。例えば、Rust のネイティブなファジングライブラリや cargo-fuzz のようなツールを使用して、Solana プログラムでファズテストを行うことができます。Solana での形式的検証は、最近までほとんど存在しませんでした。Certora と Solana のエンジニアの協力により、仕様に対して Rust/Anchor コントラクトを証明できるSolana プログラム用の社内検証ツールが生まれました。前述のように、Certora はプローバーを Solana の VM に拡張し、開発者は Solidity と同様に Solana プログラムの振る舞いに関するルールを記述してチェックできるようになりました。これは、Solana の迅速な開発アプローチが、多くのコントラクトがイーサリアムで見られるような厳格なテストなしでローンチされたことを意味するため、重要です。形式的ツールはそれを改善できます。Solana の AI 監査も考えられます – Rust を理解する LLM に、Solana プログラムの脆弱性 (所有権チェックの欠落や算術エラーなど) をチェックするようにプロンプトを入力することができます。Solana 固有のパターンに関するファインチューニングが必要かもしれませんが、Rust の人気を考えると、GPT-4 は Rust コードの読み取りにかなり習熟しています。近いうちに「ChatGPT for Anchor」スタイルのツールも登場するかもしれません。

• Polkadot および Substrate ベースのチェーン: Polkadot のスマートコントラクトは、ink! フレームワークを使用して Rust で書く (WebAssembly にコンパイルする) か、EVM パレット (Moonbeam が行うように) を実行して Solidity を使用することができます。ink!/Wasm の場合、検証ツールはまだ初期段階です。一般的な Wasm 検証フレームワーク (例えば、Microsoft の Project Verona などが Wasm の安全性を検討しています) を使用して、Wasm コントラクトのプロパティを形式的に検証しようと試みることができます。Certora のオープンソースプローバーは、Stellar の WASM スマートコントラクトのサポートも言及しており、これは Wasm ベースのチェーンの概念と似ています。したがって、Polkadot の Wasm コントラクトにも適用可能である可能性が高いです。ink! コントラクトのファズテストは、Rust テストを書くことで行うことができます (Rust のプロパティテストは同様の役割を果たせます)。ink! コントラクトの AI 監査は、Rust コードの分析を伴いますが、これも LLM が適切なコンテキストで実行できます (ただし、いくつかのヒントなしでは特定の ink! マクロやトレイトについては知らないかもしれません)。

さらに、Polkadot は並列スマートコントラクト開発のために Move 言語を模索しています (一部のコミュニティフォーラムで示唆されています)。Move が Polkadot のパラチェーンで使用されるようになれば、Move Prover が付属し、設計による形式的検証機能がもたらされます。Move の安全性への重点 (リソース指向プログラミング) と組み込みのプローバーは、形式的手法のクロスチェーン伝播を最初から示しています。

• その他のブロックチェーン: Tezos (Michelson スマートコントラクト) や Algorand (TEAL プログラム) のようなプラットフォームは、それぞれ形式的検証の取り組みを行ってきました。例えば、Tezos には Mi-Cho-Coq というツールがあり、Michelson の形式的セマンティクスを提供し、プロパティの証明を可能にします。これらはより学術的な側面が強いですが、明確に定義されたコントラクトセマンティクスを持つブロックチェーンであれば、形式的検証の対象となり得ることを示しています。AI 監査は、原則として、どのプログラミング言語にも適用できます – それは LLM を適切にトレーニングまたはプロンプト入力する問題です。あまり一般的でない言語の場合、LLM は十分な例で事前トレーニングされていない可能性があるため、効果的であるためにはいくつかのファインチューニングが必要かもしれません。

• クロスチェーンインタラクション: 新しい課題は、チェーン間の相互作用 (ブリッジやインターチェーンメッセージングなど) を検証することです。ここでの形式的検証は、複数のチェーンの状態と通信プロトコルをモデル化することを含むかもしれません。これは非常に複雑で、現在ほとんどのツールの範囲を超えていますが、特定のブリッジプロトコルはセキュリティのために手動で分析されています。AI はクロスチェーンコードのレビューに役立つかもしれません (例えば、Cosmos 上の IBC プロトコルと相互作用する Solidity コントラクトをレビューするなど) が、まだ既製のソリューションはありません。

本質的に、イーサリアムのツールが他のチェーンへの道を開きました。多くのオープンソースツールが適応されています。例えば、Solana (Rust) 用の Slither のような静的アナライザーを作成する取り組みがあり、不変条件テストの概念は言語に依存しません (プロパティベースのテストは多くの言語に存在します)。強力なエンジン (Certora の複数の VM 用など) のオープンソース化は、クロスチェーンセキュリティにとって特に有望です – 同じプラットフォームを使用して、Solidity コントラクト、Solana プログラム、Move コントラクトを検証できます。ただし、それぞれに適切な仕様が書かれている必要があります。これにより、業界全体でより均一なセキュリティ体制が促進されます。

また、AI 支援監査はすべてのチェーンに利益をもたらすことにも注目する価値があります。なぜなら、モデルはどのコンテキストの脆弱性についても教えることができるからです。AI に適切な情報 (言語仕様、そのエコシステムでの既知のバグパターン) が提供される限り、同様の推論を適用できます。例えば、ChatGPT には適切なプロンプトで Solidity コントラクトまたは Move モジュールを監査するように依頼でき、両方を行います – それがその概念を持っていれば、*「この Move モジュールはリソース保存に違反する可能性がある」*といったことさえ捉えるかもしれません。限界は、AI がそのチェーンの十分なトレーニングデータに触れていたかどうかです。最も人気のあるイーサリアムは、モデルを Solidity に最も得意になるように偏らせている可能性があります。他のチェーンが成長するにつれて、将来の LLM やファインチューニングされた派生モデルもそれらをカバーできるようになるでしょう。

結論​

スマートコントラクトの形式的検証と AI 支援監査は、急速に進化している分野です。現在、コードの信頼性を向上させる決定論的な静的アナライザーやファジングフレームワークから、人間のようにコードについて推論できる最先端の AI まで、豊富なツールキットがあります。かつてはニッチな学術的追求であった形式的検証は、より良いツールと統合を通じてより実用的になりつつあります。AI は、現在の限界にもかかわらず、セキュリティ分析の自動化において画期的な能力の片鱗を見せています。

まだ万能の解決策はありません – 現実世界の監査は、多層防御を達成するために複数の技術を組み合わせています。Foundry のファズテストと不変条件テストは、デプロイ前に期待される基準をすでに引き上げており (基本的なテストをすり抜ける多くのエラーを捉えています)、AI 支援監査は、慎重に使用すれば、監査人のための強力な補助となり、手動レビューだけでは不可能な規模と速度で問題を指摘し、コンプライアンスを検証できます。しかし、これらのツールを駆動し、その発見を解釈し、チェックすべき適切なプロパティを定義するためには、人間の専門知識が依然として不可欠です。

今後、これらのアプローチのさらなる収束が期待できます。例えば、AI が形式的仕様の記述や不変条件の提案を助けるかもしれません (「AI、この DeFi コントラクトにはどのようなセキュリティプロパティが成立すべきか？」)。ファジングツールは、入力をよりインテリジェントに生成するために AI を組み込むかもしれません (PromFuzz が行うように)。形式的検証エンジンは、どの補題やヒューリスティクスを適用するかを決定するために機械学習を使用するかもしれません。これらすべてが、イーサリアムだけでなく、すべてのブロックチェーンプラットフォームで、より安全なスマートコントラクトに貢献するでしょう。究極のビジョンは、重要なスマートコントラクトがその正確性に高い信頼性を持ってデプロイできる未来です – この目標は、どちらか一方だけではなく、形式的手法と AI 支援の相乗効果によって達成される可能性が高いです。

Sources:

• Foundry fuzzing and invariant testing overview
• Trail of Bits on fuzzing vs formal verification
• Trail of Bits on formal verification limitations
• Patrick Collins on fuzz/invariant vs formal methods
• Trail of Bits on invariants in audits
• Medium (BuildBear) on Slither and Mythril usage
• AuditGPT results (ERC compliance)
• Trail of Bits on LLM (Codex/GPT-4) limitations
• LLM-SmartAudit performance vs traditional tools
• “Detection Made Easy” study on ChatGPT accuracy
• PromFuzz (LLM+fuzz) performance
• Certora open-source announcement (multi-chain)
• Move Prover description (Aptos)
• Static analysis background (Smart contract security literature)

暗号を送るとき、あなたのルーティンは何ですか？ 多くの人は、取引履歴から受取人のアドレスをコピーすることです。 結局、0x1A2b...8f9E のような 40 文字の文字列を暗記できる人はいません。 これは誰もが使う便利なショートカットです。

しかし、その便利さが綿密に仕掛けられた罠だったらどうでしょうか？

ブロックチェーンアドレス汚染 と呼ばれる破壊的に効果的な詐欺が、まさにこの習慣を悪用しています。 カーネギーメロン大学の最新研究によると、この脅威は驚異的な規模に達しています。 たった 2 年間で、Ethereum と Binance Smart Chain（BSC）ネットワークだけで、詐欺師は 2.7 億件以上の攻撃試行 を行い、1,700 万人の被害者 を狙い、少なくとも 8,380 万ドル を盗み出しています。

これはニッチな脅威ではなく、現在稼働している最大かつ最も成功した暗号フィッシングスキームの一つです。 仕組みと、資産を守るためにできることをご紹介します。

詐欺の仕組み 🤔​

アドレス汚染は視覚的トリックのゲームです。 攻撃者の戦略はシンプルながら巧妙です。

1. 類似アドレスの生成
   攻撃者は、あなたが頻繁に送金するアドレスを特定し、強力なコンピュータで 先頭と末尾の文字が全く同じ 新しい暗号アドレスを生成します。 多くのウォレットやブロックエクスプローラはアドレスを短縮表示する（例：0x1A2b...8f9E）ため、偽アドレスは一目で本物と見分けがつきません。

2. 取引履歴への「汚染」
   次に、攻撃者はその類似アドレスをあなたのウォレット履歴に入れます。 これは「汚染」トランザクションを送ることで実現します。 方法は以下のいずれかです。

   • ごく小額の送金：偽アドレスから極小額（例：$0.001）を送金し、あなたの最近の取引リストに表示させます。
   • ゼロ価値転送：多くのトークンコントラクトに備わっている機能を悪用し、偽のゼロドル転送を作成します。 これにより、偽アドレスが「あなた」から送られたように見え、信頼性が増します。
   • 偽トークン転送：価値のない偽トークン（例：USDTT）を作成し、過去の実際の取引額に似せた転送を偽アドレスへ行います。

3. ミスを待つ
   罠は完成です。 次に正当な相手に支払う際、取引履歴を確認し、正しいと思われるアドレスをコピーして送金します。 ミスに気付いた時には資金は既に消えており、ブロックチェーンは不可逆的なので銀行に電話しても取り戻すことはできません。

犯罪組織の実態 🕵️‍♂️​

これは単独ハッカーの仕業ではありません。 研究は、これらの攻撃が大規模で組織化された、極めて利益率の高い犯罪集団によって実行されていることを示しています。

標的プロファイル​

攻撃者は小口アカウントに時間を浪費しません。 以下の条件を満たすユーザーを体系的に狙います。

• 資産が豊富：ステーブルコインの残高が多い。
• 取引が活発：頻繁に送金を行う。
• 高額トランザクション：大きな金額を移動させる。

ハードウェアの軍拡競争​

類似アドレスの生成は総当たり計算タスクです。 マッチさせる文字数が増えるほど指数関数的に難易度が上がります。 多くの攻撃者は標準的な CPU で「ほどほどに」偽アドレスを作りますが、最も高度な犯罪集団はさらに一歩進んでいます。

このトップティアの集団は、ターゲットアドレスの 20 文字 まで一致させた偽アドレスを生成しています。 標準的なコンピュータではほぼ不可能であり、研究者は GPU ファーム を使用していると結論付けました。 つまり、高性能ゲームや AI 研究で使われるような大規模な GPU クラスタを投入しているのです。 巨額の投資を行い、被害者から容易に回収しているため、ビジネスとして急成長しています。

資金を守る方法 🛡️​

脅威は高度ですが、防御策はシンプルです。 悪習慣を断ち、注意深いマインドセットを取り入れることが鍵です。

1. 全ユーザーへの必須対策（最重要）

   • アドレス全体を確認する：Confirm をクリックする前に、5 秒余分に時間を取り、アドレス全体を文字ごとに目視で確認してください。 先頭と末尾だけを見るのはやめましょう。
   • アドレス帳を活用する：信頼できるアドレスをウォレットのアドレス帳や連絡先リストに保存し、送金時は必ずこの保存済みリストから選択してください。 動的な取引履歴から選ばないように。
   • テスト送金を行う：大口や重要な支払いの場合、まずごく小額を送金し、受取人が受領したことを確認してから本送金してください。

2. ウォレット開発者への提案

   • ユーザーインターフェースを改善し、デフォルトでアドレスの表示文字数を増やす、または「ごく小額・ゼロ価値の取引しか行っていないアドレスへの送金」時に強力な警告を出す機能を追加してください。

3. 長期的解決策

   • Ethereum Name Service（ENS） のように、人間が読める名前（例：yourname.eth）をアドレスにマッピングできるシステムは、この問題を根本的に解消します。 広範な採用が鍵です。

分散型の世界では、あなたが自分自身の銀行であり、同時に自分自身のセキュリティ責任者でもあります。 アドレス汚染は便利さと不注意を狙う静かな脅威です。 意識的に二重チェックを行うことで、あなたの努力で得た資産が詐欺師の罠にかかることを防げます。

ブロックチェーン技術、特に Ethereum が提供する主な約束のひとつは、ある程度の匿名性です。バリデータと呼ばれる参加者は、暗号的な仮名の背後で活動し、現実世界の身元とそれに伴うセキュリティを保護するとされています。

しかし、ETH Zurich などの研究者が執筆した最近の論文「Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue」では、この前提に致命的な欠陥があることが示されました。彼らは、バリデータの公開識別子と実行マシンの IP アドレスを直接結びつける、シンプルかつ低コストな手法を実証しています。

要するに、Ethereum バリデータは多くの人が考えるほど匿名ではありませんでした。この発見は Ethereum Foundation からバグ賞金を受け取るほどの重要性が認められました。

脆弱性の仕組み：ゴシップの欠陥​

脆弱性を理解するには、まず Ethereum バリデータがどのように通信しているかを簡単に把握する必要があります。ネットワークは 100 万を超えるバリデータで構成され、彼らは常にチェーンの状態に「投票」しています。この投票は アテステーション と呼ばれ、ピアツーピア（$P2P$）ネットワークを通じて全ノードにブロードキャストされます。

バリデータが多数いるため、全員が全投票を全員に送信するとネットワークは瞬時に飽和してしまいます。そこで Ethereum の設計者は賢いスケーリング手法を導入しました。ネットワークは 64 個の独立した通信チャネル、すなわち サブネット に分割されています。

• デフォルトでは、各ノード（バリデータソフトウェアを実行するコンピュータ）は 64 個のサブネットのうち 2 つ のみを購読します。ノードの主な役割は、その 2 つのチャネル上のすべてのメッセージを忠実に中継することです。
• バリデータが投票を行う際、アテステーションはランダムに 64 個のサブネットのいずれかに割り当てられてブロードキャストされます。

ここに脆弱性があります。 たとえば、チャネル 12 と 13 のトラフィック管理を担当しているノードが、突然チャネル 45 のメッセージを送ってきたとします。

これは強力な手がかりです。なぜそのノードが自分の担当外のチャネルのメッセージを処理するのか？ 最も論理的な結論は そのノード自体がメッセージを生成した ということです。つまり、チャネル 45 のアテステーションを作成したバリデータは、まさにそのマシン上で動作していると推測できます。

研究者はこの原理をそのまま利用しました。自前のリスニングノードを設置し、ピアがどのサブネットからアテステーションを送ってくるかを監視したのです。ピアが公式に購読していないサブネットからメッセージを送ったとき、高い確信を持ってそのピアが元のバリデータをホストしていると推測できました。

この手法は驚くほど効果的でした。4 台のノードを 3 日間稼働させるだけで、チームは 161,000 を超えるバリデータ の IP アドレスを特定し、全 Ethereum ネットワークの 15% 以上 を露出させました。

なぜ重要か：匿名性除去のリスク​

バリデータの IP アドレスが公開されることは決して軽視できません。個々のオペレーターだけでなく、Ethereum ネットワーク全体の健全性を脅かす標的型攻撃の入口となります。

1. 標的型攻撃と報酬の盗難
Ethereum は次にブロックを提案するバリデータを数分前に公表します。このバリデータの IP アドレスが分かれば、攻撃者は DDoS 攻撃 を仕掛け、トラフィックで埋め尽くしてオフラインにできます。バリデータが 4 秒間の提案ウィンドウを逃すと、次のバリデータに権利が移ります。もし攻撃者がその次のバリデータであれば、被害者が本来得るべきブロック報酬や取引手数料（MEV）を奪取できます。

2. ネットワークのライブネスと安全性への脅威
資金力のある攻撃者はこの「スナイプ」攻撃を繰り返し、ブロックチェーン全体を遅延させたり停止させたりする ライブネス攻撃 を実行できます。さらに深刻なシナリオでは、取得した情報を用いてネットワーク分断攻撃を仕掛け、チェーン履歴に対する合意が崩れ、安全性攻撃 が成立する恐れがあります。

3. 中央集権的現実の露呈
研究はネットワークの分散性に関する不快な真実も明らかにしました：

• 極端な集中：ある IP アドレスが 19,000 台以上 のバリデータをホストしているケースが発見されました。単一マシンの障害がネットワーク全体に過大な影響を与える可能性があります。
• クラウド依存：特定されたバリデータの 90% が AWS や Hetzner といったクラウドプロバイダー上で稼働しており、個人のホームステーカーではありません。これは重要な集中点です。
• 隠れた依存関係：大手ステーキングプールは独立した運営と主張しますが、研究では競合プールのバリデータが 同一物理マシン 上で動作している事例が見つかり、見えないシステムリスクが潜んでいることが判明しました。

対策：バリデータはどう守るべきか？​

幸いなことに、この匿名性除去手法に対抗する方法はいくつか存在します。研究者は以下の緩和策を提案しています：

• ノイズを増やす：バリデータは 2 つ以上、場合によっては全 64 のサブネットを購読できます。これにより、観測者が中継メッセージと自生成メッセージを区別しにくくなります。
• 複数ノードの活用：オペレーターはバリデータの役割を異なる IP を持つ複数マシンに分散させられます。たとえば、1 台のノードでアテステーションを処理し、別のプライベートノードだけで高価値ブロックの提案を行う、といった構成です。
• プライベートピアリング：バリデータは信頼できる仲間ノードとプライベート接続を確立し、メッセージをリレーさせることで、真の送信元を小さな信頼グループ内に隠すことができます。
• 匿名ブロードキャストプロトコル：Dandelion のように、メッセージをランダムな「ステム」経路で伝搬させてから広範にブロードキャストする手法を導入すれば、送信元特定をさらに困難にできます。

結論​

この研究は、分散システムにおけるパフォーマンスとプライバシーのトレードオフを鮮明に示しています。スケーラビリティを追求した結果、Ethereum の $P2P$ ネットワークは最も重要な参加者の匿名性を犠牲にした設計となっていました。

脆弱性を公にしたことで、研究者は Ethereum コミュニティに対し、問題解決に必要な知識とツールを提供しました。彼らの取り組みは、将来に向けてより堅牢で安全、そして真に分散化されたネットワークを構築するための重要な一歩です。

シリコンバレーのスタートアップでは、Docker Compose はコンテナ化アプリケーションを迅速にデプロイ・管理するための好まれるツールの一つです。しかし、利便性にはしばしばセキュリティリスクが伴います。Site Reliability Engineer（SRE）として、セキュリティ脆弱性が壊滅的な結果を招くことを痛感しています。本記事では、Docker Compose と Ubuntu を組み合わせた実務でまとめたベストなセキュリティ実践を共有し、Docker Compose の便利さを享受しつつシステムの安全性を確保する方法をご紹介します。

I. Ubuntu システムのセキュリティ強化​

コンテナをデプロイする前に、Ubuntu ホスト自体のセキュリティを確保することが重要です。主な手順は以下の通りです。

1. Ubuntu と Docker を定期的にアップデート​

システムと Docker の両方を最新の状態に保ち、既知の脆弱性を修正します。

sudo apt update && sudo apt upgrade -y
sudo apt install docker-ce docker-compose-plugin

2. Docker 管理権限を制限​

Docker の管理権限を厳格にコントロールし、特権昇格攻撃を防止します。

sudo usermod -aG docker deployuser
# 一般ユーザーが簡単に Docker 管理権限を取得できないようにする

3. Ubuntu ファイアウォール (UFW) を設定​

ネットワークアクセスを適切に制限し、不正アクセスを防止します。

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

4. Docker と UFW の連携を適切に設定​

デフォルトでは Docker が iptables を直接操作し、UFW をバイパスします。手動で制御することを推奨します。

Docker 設定ファイルを編集します。

sudo nano /etc/docker/daemon.json

以下の内容を追加します。

{
  "iptables": false,
  "ip-forward": true,
  "userland-proxy": false
}

Docker サービスを再起動します。

sudo systemctl restart docker

Docker Compose でアドレスを明示的にバインドします。

services:
  webapp:
    ports:
      - "127.0.0.1:8080:8080"

II. Docker Compose のセキュリティベストプラクティス​

以下の設定は Docker Compose v2.4 以降を対象としています。Swarm モードと非 Swarm モードの違いに注意してください。

1. コンテナ権限を制限​

デフォルトで root で実行されるコンテナはリスクが高いため、非 root ユーザーに変更します。

services:
  app:
    image: your-app:v1.2.3
    user: "1000:1000" # 非 root ユーザー
    read_only: true # 読み取り専用ファイルシステム
    volumes:
      - /tmp/app:/tmp # 書き込みが必要なディレクトリだけマウント
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

解説

• 読み取り専用ファイルシステムはコンテナ内部での改ざんを防止します。
• マウントするボリュームは必要最小限に留めます。

2. ネットワーク分離とポート管理​

内部ネットワークと外部ネットワークを明確に分離し、機密サービスが外部に露出しないようにします。

networks:
  frontend:
    internal: false
  backend:
    internal: true

services:
  nginx:
    networks: [frontend, backend]
  database:
    networks:
      - backend

• frontend ネットワーク: 公開可。
• backend ネットワーク: 完全に内部限定。

3. シークレット管理の安全化​

機密情報は Compose ファイルに直接記載しないでください。

単一マシンモードの場合:

services:
  webapp:
    environment:
      - DB_PASSWORD_FILE=/run/secrets/db_password
    volumes:
      - ./secrets/db_password.txt:/run/secrets/db_password:ro

Swarm モードの場合:

services:
  webapp:
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    external: true # Swarm の組み込みシークレット管理を利用

注意

• Docker Swarm のネイティブシークレットは Vault や AWS Secrets Manager など外部ツールを直接利用できません。外部シークレットストレージが必要な場合は、読み取り処理を自前で組み込む必要があります。

4. リソース制限（Compose バージョンに合わせて）​

コンテナがホストリソースを使い果たすのを防ぎます。

単一マシンモード（推奨 v2.4）:

version: "2.4"

services:
  api:
    image: your-image:1.4.0
    mem_limit: 512m
    cpus: 0.5

Swarm モード（v3 以上）:

services:
  api:
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M

注記: 非 Swarm 環境では deploy セクションのリソース制限は 無効 です。Compose ファイルのバージョンに注意してください。

5. コンテナヘルスチェック​

ヘルスチェックを設定し、問題を早期に検知してサービス停止時間を短縮します。

services:
  webapp:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s

6. latest タグの使用を避ける​

本番環境で latest タグを使用するとバージョン管理が曖昧になります。明示的にイメージバージョンを指定してください。

services:
  api:
    image: your-image:1.4.0

7. ログ管理の適切化​

コンテナログがディスク容量を圧迫しないように制限します。

services:
  web:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

8. Ubuntu の AppArmor 設定​

Ubuntu ではデフォルトで AppArmor が有効化されています。Docker のプロファイル状態を確認しましょう。

sudo systemctl enable --now apparmor
sudo aa-status

Ubuntu 上の Docker はデフォルトで AppArmor を有効にしますが、同時に SELinux を有効化すると競合するため推奨されません。

9. 継続的なアップデートとセキュリティスキャン​

• イメージ脆弱性スキャン: CI/CD パイプラインに Trivy、Clair、Snyk などを組み込みます。

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image your-image:v1.2.3

• 自動セキュリティアップデート: 既知の脆弱性を修正するため、少なくとも週に一度はイメージをリビルドします。

III. ケーススタディ：Docker Compose 設定ミスから得た教訓​

2019 年 7 月、Capital One は 1 億人以上の顧客情報が流出する大規模なデータ侵害を受けました12。主因は AWS 設定ミスでしたが、同時にコンテナのセキュリティ問題も関与していました。

1. コンテナ権限の問題: 攻撃者は過剰な権限を持つ WAF コンテナの脆弱性を突きました。
2. ネットワーク分離の不備: 侵害されたコンテナから他の AWS リソースへアクセスでき、ネットワーク分離が不十分でした。
3. 機密データの露出: 設定ミスにより大量の顧客データが取得可能になっていました。
4. セキュリティ設定ミスの蓄積: コンテナとクラウドサービスの設定エラーが重なり、重大なインシデントに繋がりました。

この事故により Capital One は数億ドル規模の罰金と長期的な信頼危機に直面しました。権限管理、ネットワーク分離、機密データ保護の重要性を改めて認識させる事例です。

IV. 結論と推奨事項​

Docker Compose と Ubuntu の組み合わせはコンテナアプリケーションを迅速にデプロイする便利な手段ですが、セキュリティはプロセス全体に組み込む必要があります。

• コンテナ権限とネットワーク分離を厳格に管理する
• 機密情報の漏洩を防止する
• 定期的なセキュリティスキャンとアップデートを実施する
• エンタープライズ規模になるほど、Kubernetes など高度なオーケストレーションへ移行し、セキュリティ保証を強化することを推奨します

セキュリティは終わりなき取り組みです。本記事が Docker Compose + Ubuntu 環境の保護に役立つことを願っています。