メインコンテンツへスキップ
Change page

ブリッジ

最終更新: 2026年2月23日

L1ブロックチェーンとL2スケーリングソリューションが普及し、クロスチェーン化する分散型アプリケーションが増え続ける中、チェーンをまたいだ通信と資産移動は、ネットワークインフラに不可欠な要素となっています。 この機能を提供するために、さまざまな種類のブリッジが開発されています。

ブリッジの必要性

ブリッジは、複数のブロックチェーンネットワークを接続するために開発されました。 これにより、複数のブロックチェーンが接続され、相互運用が可能になります。

ブロックチェーンはサイロ化された環境で存在するため、あるブロックチェーンがそれ自体で他のブロックチェーンと取引したり通信したりすることはできません。 このため、特定のエコシステムにおいて活発なアクティビティやイノベーションが発生していたとしても、他のエコシステムとの接続性や相互運用性が存在しないために、当該エコシステム自体の限界を越えることができません。

ブリッジは、相互に隔離されているブロックチェーン環境を接続する手段を提供します。 ブリッジはブロックチェーン間に転送ルートを確立し、トークン、メッセージ、任意のデータ、さらにはスマートコントラクトの呼び出しまでもが、あるチェーンから別のチェーンへと転送できるようになります。

ブリッジのメリット

ブリッジの有用性は、複数のブロックチェーン間におけるデータの交換や資産の移動を可能にすることで、数多くの新たなユースケースを生み出す可能性を持つ点にあります。

個々のブロックチェーンは、それぞれが独自の強み、弱み、およびアプリケーション開発のアプローチを持っています(速度、スループット、コスト効率など)。 ブリッジは、各ブロックチェーンにおけるイノベーションを他のブロックチェーンでも利用できるようにすることで、暗号資産全体のエコシステムを開発を促進します。

デベロッパーは、ブリッジを通して以下を実現できます:

  • あらゆる種類のデータ、情報、および資産をチェーンを超えて転送できる。
  • ブリッジが個別のプロトコルで提供可能な機能の設計範囲を拡張するため、新たな機能やユースケースが可能になる。 例えば、当初イーサリアムメインネットでデプロイされたイールドファーミング用のプロトコルは、EVM互換のすべてのチェーンに流動性プールを提供できる。
  • 様々なブロックチェーンが持つ独自の強みを活用できる機会を提供する。 例えば、複数のロールアップやサイドチェーン上でDappをデプロイし、ユーザーがそれらをまたいで利用できるようにすることで、様々なL2ソリューションが提供する安価な手数料を提供できる。
  • 様々なブロックチェーンエコシステムに関与しているデベロッパーが連携して、新たなプロダクトを構築できる。
  • 様々なエコシステムから、自社Dappにユーザーやコミュニティを呼び込むことができる。

ブリッジはどのように機能するのか?

ブリッジの設計には多くの種類 (opens in a new tab)がありますが、資産のクロスチェーン転送を可能にする方法として、以下の3つが際立っています。

  • ロック・アンド・ミント – ソースチェーンで資産をロックし、宛先チェーンで資産をミントします。
  • バーン・アンド・ミント – ソースチェーンで資産をバーンし、宛先チェーンで資産をミントします。
  • アトミックスワップ – 他の当事者と、ソースチェーン上の資産を宛先チェーン上の資産と交換します。

ブリッジの種類

ブリッジは通常、以下のカテゴリーに分類されます:

  • ネイティブブリッジ – 通常、特定のブロックチェーンの流動性をブートストラップするために構築され、ユーザーがエコシステムに資金を移動しやすくするためのブリッジです。 例えば、Arbitrum Bridge (opens in a new tab)は、ユーザーがイーサリアムメインネットからArbitrumにブリッジするのを便利にするために構築されています。 その他の同様のブリッジには、Polygon PoSブリッジ、Optimism Gateway (opens in a new tab)などがあります。
  • バリデータまたはオラクルベースのブリッジ – これらのブリッジは、クロスチェーン転送を検証するために、外部のバリデータセットまたはオラクルに依存します。 MultichainやAcrossが含まれます。
  • 汎用メッセージパッシングブリッジ – これらのブリッジは、資産だけでなく、メッセージや任意のデータもチェーン間で転送できます。 例: Axelar、LayerZero、Nomad。
  • 流動性ネットワーク – これらのブリッジは、主にアトミックスワップを介して、あるチェーンから別のチェーンへ資産を転送することに焦点を当てています。 通常、この種類のブリッジはチェーン間のメッセージの受け渡しには対応しません。 ConextやHopが含まれます。

考慮すべきトレードオフ

どのブリッジも、完璧なソリューションとは言えません。 むしろ、各ブリッジは特定の目的を実現する一方で、トレードオフがあると考えるべきです。 デベロッパーおよびユーザーは、以下の特性に基づいて各ブリッジを評価するとよいでしょう:

  • セキュリティ – システムの検証を誰が担うか? 一般に、外部のバリデータによりセキュリティを保証するブリッジは、当該ブロックチェーンのバリデータがローカル/ネイティブにセキュリティを保証する場合よりもセキュリティが低くなります。
  • 利便性 – トランザクションの完了にかかる時間と、ユーザーが署名する必要があるトランザクションの数はどのくらいか? デベロッパーにとっては、ブリッジを組み込むプロセスの時間や複雑さを検討する必要があります。
  • 接続性 – ブリッジが接続できる宛先チェーンの種類 (ロールアップ、サイドチェーン、他のレイヤー1ブロックチェーンなど) は何か、また新しいブロックチェーンを統合するのはどれくらい難しいか?
  • より複雑なデータの転送能力 – ブリッジは、メッセージやより複雑な任意のデータをチェーン間で転送できるか、それともクロスチェーンの資産転送のみをサポートしているか?
  • コスト効率 – ブリッジを介してチェーン間で資産を転送するのに、どれくらいのコストがかかるか? ブリッジは一般に、固定の手数料またはガス代および特定の転送レートの流動性に基づく変動料金を請求します。 さらに、セキュリティを確保するのにどれだけの手数料が必要になるかに基づき、特定のブリッジにおけるコスト効率を評価することが非常に重要です。

より大まかに見れば、ブリッジはトラステッドとトラストレスの2種類に分類できます。

  • トラステッド – トラステッドブリッジは外部で検証されます。 つまり、チェーン間のデータ送信につき、外部の検証者セット(マルチシグによるフェデレーション、マルチパーティの計算システム、オラクルネットワーク)が介在するブリッジを指します。 これにより、接続性に優れ、完全に汎用化されたメッセージをチェーン間でやりとりすることができます。 さらに、速度やコスト効率の面からも優れている場合が多いです。 ただし、ユーザーはブリッジ自体のセキュリティに依存するため、セキュリティが損なわれる可能性があります。
  • トラストレス – これらのブリッジは、接続しているブロックチェーンとそのバリデータに依存して、メッセージとトークンを転送します。 これらのブリッジが「トラストレス」と呼ばれるのは、(ブロックチェーン自体で想定するものを除き)、新たな信頼想定を追加しないためです。 これにより、トラステッドのブリッジと比較してセキュリティが高いと評価されます。

トラストレスのブリッジを他の要素で評価する場合、汎用型メッセージの受け渡しが可能なブリッジと、流動性ネットワークのブリッジに分けて考える必要があります。

  • 汎用メッセージパッシングブリッジ – これらのブリッジは、セキュリティと、より複雑なデータをチェーン間で転送する能力に優れています。 また、多くの場合コスト効率性も優れています。 ただし、これらの強みを持つ一方で、ライトクライアントのブリッジ(例: IBC)に接続できない点や、オプティミスティック・ブリッジ(例: Nomad)の場合に速度が低下するなどの欠点があります。
  • 流動性ネットワーク – これらのブリッジは、資産の転送にアトミックスワップを使用し、ローカルで検証されるシステムです (つまり、トランザクションを検証するために基盤となるブロックチェーンのバリデータを使用します)。 このため、セキュリティと実行速度の両方が優れています。 さらに、コスト効率性や接続性も比較的優れていると考えられています。 ただし、チェーン間におけるメッセージの受け渡しが不可能であるため、より複雑なデータを扱えないという大きな欠点があります。

ブリッジのリスク

ブリッジは、DeFiにおける最大のハッキング (opens in a new tab)のトップ3を占めており、まだ開発の初期段階にあります。 ブリッジの利用は、以下のようなリスクを伴います:

  • スマートコントラクトのリスク – 多くのブリッジは監査に合格していますが、スマートコントラクトに1つの欠陥があるだけで、資産がハッキングにさらされる可能性があります (例: SolanaのWormholeブリッジ (opens in a new tab))。
  • システミックな金融リスク – 多くのブリッジは、新しいチェーンで元の資産のカノニカルバージョンをミントするために、ラップされた資産を使用します。 ラップされたトークンが悪用された事例はすでに発生しており、エコシステム全体にシステミックリスクをもたらします。
  • カウンターパーティリスク – 一部のブリッジは、バリデータが共謀してユーザーの資金を盗むことはないという仮定にユーザーが依存することを要求する、トラステッドな設計を利用しています。 ユーザーは、これらのサードパーティアクターを信頼しなければならないため、ラグプル、検閲、およびその他の悪意の行為が発生するリスクにさらされています。
  • 未解決の問題 – ブリッジは開発の初期段階にあるため、ネットワークの混雑時や、ネットワークレベルの攻撃やステートのロールバックなどの予期せぬイベントの発生時といった、さまざまな市場状況でブリッジがどのように機能するかについては、多くの未解決の疑問があります。 この不確実性は様々なリスクをもたらすものですが、その影響の度合いはまだ不明です。

Dappでブリッジを利用する方法

以下では、デベロッパがブリッジを活用してDappのクロスチェーン化を検討する際の実践的な応用例について紹介します:

ブリッジの統合

開発中のDappをブリッジに対応させるには、多くの方法が存在します:

  1. 独自のブリッジを構築する – 安全で信頼性の高いブリッジを構築するのは容易ではありません。特に、より信頼を最小化するアプローチをとる場合はなおさらです。 さらに、スケーラビリティや相互運用性に関する豊富な経験や技術的な知識が必要です。 また、ブリッジを管理し、実務上要求される十分な流動性を維持するためには常駐チームが必要です。

  2. ユーザーに複数のブリッジオプションを提示する – 多くのdappsでは、それらと対話するためにユーザーがネイティブトークンを持っている必要があります。 ユーザーが所有するトークンを利用できるようにするために、Dappのウェブサイトでは様々なブリッジのオプションを提供しています。 しかしこの方法は、自社のDappのインターフェイスだけでプロセスを完結できず、他のDappやブリッジとのやりとりが必要になるため、その場しのぎの対策と言わざるを得ません。 また、ユーザーのオンボーディングが複雑になり、ミスが発生する可能性も高まります。

  3. ブリッジを統合する – このソリューションでは、dappがユーザーを外部のブリッジやDEXインターフェイスに送る必要はありません。 このため、ユーザーのオンボーディング体験が向上します。 しかし、このアプローチにも以下のような制限があります:

    • ブリッジに対する評価やメンテナンスは、手間や時間がかかる。
    • ひとつのブリッジを選択することで、単一障害点や依存関係が発生する。
    • 当該ブリッジの機能により、Dappのサービスが制限される。
    • ブリッジだけでは対応できない機能が必要になる場合がある。 チェーン間のスワップなどの機能を追加するには、DEXを含める必要がある場合がある。
  4. 複数のブリッジを統合する – このソリューションは、単一のブリッジの統合に関連する多くの問題を解決します。 一方で、複数のブリッジとの統合は多くのリソースを消費し、暗号資産の分野において最も希少性が高いリソースであるデベロッパーにとって、技術面およびコミュニケーション面での負担が増加してしまいます。

  5. ブリッジアグリゲーターを統合する – dappsのもう一つの選択肢は、複数のブリッジへのアクセスを提供するブリッジアグリゲーションソリューションを統合することです。 ブリッジアグリゲーターはすべてのブリッジの強みを継承するため、各ブリッジが提供する機能のみに制限されなくなります。 特に、通常はブリッジアグリゲーターがDappとブリッジとの統合を管理するため、Dappのデベロッパー側はブリッジとの統合における技術的/運用的な側面を管理する作業から解放されます。

ブリッジアグリゲーターは、このような利点を持つ一方で、欠点もあります。 例えば、より多くのブリッジを活用するオプションを提供することは事実ですが、特定のアグリゲーターのプラットフォームが提供するブリッジよりもさらに多くのブリッジが市場で提供されています。 さらに、ブリッジの場合と同じように、ブリッジアグリゲーターもスマートコントラクトやテクノロジーに由来するリスクにさらされています(対応するコントラクトが多くなれば、リスクも拡大します)。

Dappにブリッジやブリッジアグリゲーターを組み込む場合、統合の度合いに応じて様々なオプションが考えられます。 例えば、ユーザーにおけるオンボーディング体験の向上を目的とするフロントエンドのみの統合では、ウィジェットを搭載すればよいでしょう。 しかし、ステーキングやイールドファーミング等のより複雑なチェーン間のやりとりを実現するには、SDKやAPIを統合する必要があります。

複数のチェーンにdappをデプロイする

複数のチェーンにdappをデプロイするために、開発者はAlchemy (opens in a new tab)Hardhat (opens in a new tab)Moralis (opens in a new tab)などの開発プラットフォームを利用できます。 一般にこれらのプラットフォームには、Dappのクロスチェーン化を実現するコンポーザブルなプラグインが含まれています。 例えば、開発者はhardhat-deployプラグイン (opens in a new tab)によって提供される決定論的デプロイメントプロキシを使用できます。

例:

チェーンをまたいだコントラクトアクティビティの監視

コントラクトにおけるチェーン間のやりとりを監視するには、サブグラフや、Tenderly等の開発プラットフォームを用いて、スマートコントラクトの状態をリアルタイムで観察することができます。 このようなプラットフォームには、コントラクトによって発行されたイベント (opens in a new tab)のチェックなど、クロスチェーンアクティビティのためのより高度なデータ監視機能を提供するツールも含まれています。

ツール

参考リンク

さらに、ブリッジへの理解を深めるのに役立つ、James Prestwich (opens in a new tab)による洞察に満ちたプレゼンテーションをいくつか紹介します。

この記事は役に立ちましたか?