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

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

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

カストディと取引はもはや別々の世界で運用できません。今日のデジタル資産市場では、顧客資産を安全に保管するだけでは不十分です。価格がミリ秒単位で変動する中で取引を実行できなければ、リターンを逃すだけでなく、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.).

暗号を送るとき、あなたのルーティンは何ですか？ 多くの人は、取引履歴から受取人のアドレスをコピーすることです。 結局、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 環境の保護に役立つことを願っています。