クロスチェーンメッセージングと共有流動性：LayerZero v2、Hyperlane、IBC 3.0 のセキュリティモデル
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 のベースコントラクトは、トランスポートレイヤーがラグプルされたり検閲さ れたりしないように不変であり、メッセージングパイプライン自体がアップグレードを通じて無傷で残るという信頼を呼び起こします。
比較を要約すると、以下の表は主要な違いを強調しています：
| 側面 | IBC (ライトクライアント) | Hyperlane (マルチシグ) | LayerZero v2 (集約) |
|---|---|---|---|
| 信頼モデル | ソースチェーンのコンセンサスを信頼する (追加の信頼は不要)。 | ブリッジ検証者の委員会を信頼する (例：マルチシグしきい値)。スラッシングでリスクを軽減可能。 | 選択された DVN に依存する。ライトクライアントやマルチシグを模倣したり、組み合わせたりできる (選択された検証者の少なくとも 1 つを信頼)。 |
| セキュリティ | 最高 – ライトクライアントによる暗号的な有効性の証明。攻撃にはソースチェーンまたはライトクライアントの侵害が必要。 | 委員会が正直な多数派であれば強力だが、ライトクライアントよりは弱い。委員会の共謀や鍵の侵害が主な脅威。 | 潜在的に非常に高い – 複数の独立した証明 (例：zk + マルチシグ + オラクル) を要求できる。しかし、設定可能なセキュリティは、選択された最も弱い DVN の強度に依存する。 |
| ライブネス | 少なくとも 1 つのリレーヤーがアクティブである限り非常に良好。並列リレーヤーと高速なファイナリティチェーンにより、ほぼリアルタイムの配信が可能。 | 通常の条件下では良好 (高速な署名)。しかし、検証者の稼働時間に依存する。しきい値ク ォーラムのダウンタイム = 停止。新しいチェーンへの拡張には委員会のサポートが必要。 | 非常に良好。複数の DVN が冗長性を提供し、どのユーザーもトランザクションをリレーできる。必須 DVN は、設定を誤ると単一障害点になる可能性がある。遅延は調整可能 (例：確認を待つ vs 速度)。 |
| コスト | クライアント実装に初期の複雑さ。コンセンサス (署名、マークルプルーフ) のオンチェーン検証は Cosmos で最適化済み。IBC ネイティブ環境ではメッセージごとのコストは低いが、非ネイティブチェーンでは特別な解決策なしには高価になる可能性あり。 | コアコントラクトの開発複雑性は低い。オンチェーンコストはメッセージごとの署名数に比例する。検証者のオフチェーン運用コスト (各チェーンのノード)。多くの署名が必要な場合、ライトクライアントよりガス代が高くなる可能性があるが、多くの場合管理可能。 | 中程度から高い複雑性。メッセージごとのコストは変動：各 DVN 証明 (署名または SNARK) が検証ガスを追加する。アプリはサービスに対して DVN 手数料を支払う。低価値メッセージにはより少ない、または安価な証明を選択することでコストを最適化可能。 |
| アップグレード可能性 | プロトコルはチェーンのガバナンスを通じて進化する (遅く、保守的)。ライトクライアントの更新には調整が必要だが、標準化により安定性が保たれる。新しいチェーンの追加には新しいクライアントタイプの構築/承認が必要。 | 柔軟 – 検証者セットと ISM はガバナンスまたは管理者によって変更可能。新しいチェーンを迅速に統合しやすい。アップグレードキーやガバナンスが侵害された場合のリスクあり。通常はアップグレード可能なコントラクト (管理者への信頼が必要)。 | 非常にモジュラー – 新しい DVN/検証方法はコアを変更せずに追加可能。アプリは必要に応じてセキュリティ設定を変更できる。コアエンドポイントは不変 (中央集権的なアップグレードなし) だが、悪用を避けるためにセキュリティ変更にはアプリレベルのガバナンスが必要。 |
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.).