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

ブリッジ

最終編集者: @ta1suke(opens in a new tab), 2024年1月18日

L1のブロックチェーンおよびL2のスケーリングソリューションが一般化し、ますます多くの分散型アプリケーションがクロスチェーンで運用されつつある現在、複数のチェーン間における通信および資産移動を実現する機能がネットワークインフラにおける不可欠な要素となっています。 この機能を提供するために、さまざまな種類のブリッジが開発されています。

ブリッジがなぜ必要か?

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

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

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

ブリッジの利点

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

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

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

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

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

ブリッジの設計(opens in a new tab)には多くの種類がありますが、特に、クロスチェーンで資産を移転する以下の3つの方法が重要です。

  • ロックとミント - ソースチェーン上のアセットをロックした上で、宛先チェーン上でアセットをミントする方式。
  • バーンとミント - ソースチェーン上のトークンをバーンした上で、宛先チェーン上で新たにトークンをミントする方式。
  • アトミックスワップ - ソースチェーン上の資産と、他のユーザーの宛先チェーン上の資産を直接交換する方式。

ブリッジの種類

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

  • ネイティブブリッジ - 通常、特定のブロックチェーンにおいて流動性を自動供給するための構築されたブリッジであり、当該エコシステムに対する資金の転送を容易にするものです。 例えば、 Arbitrumブリッジ(opens in a new tab)は、イーサリアムからArbitrumへの資金転送を容易にするために開発されたブリッジです。 この種類のブリッジとしては、Polygon PoSブリッジやOptimismゲートウェイ(opens in a new tab)等があります。
  • バリデータ/オラクルベースのブリッジ - クロスチェーン間の転送につき、外部のバリデータ群またはオラクルによる検証に依存するブリッジです。 MultichainやAcrossが含まれます。
  • 一般的なメッセージの受け渡しを伴うブリッジ - チェーン間の資産転送につき、メッセージおよび任意のデータと共に実行するもの。 NomadやLayerZeroが含まれます。
  • 流動性ネットワーク - 主に、アトミック・スワップによるチェーン間の資産転送に焦点をあてたブリッジです。 通常、この種類のブリッジはチェーン間のメッセージの受け渡しには対応しません。 ConextやHopが含まれます。

考慮すべきトレードオフ

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

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

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

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

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

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

ブリッジに伴うリスク

ブリッジは、DeFiにおける最悪のハッキング事例(opens in a new tab)上位3位における原因となっており、現在も開発途上の技術です。 ブリッジの利用は、以下のようなリスクを伴います:

  • スマートコントラクトのリスク - 多くのブリッジは監査に合格しているものの、スマートコントラクトに欠陥がひとつでも含まれていれば、資産に対するハッキング攻撃が可能になります(例: Solanaのワームホールブリッジ(opens in a new tab))。
  • システミックな財務リスク - 多くのブリッジでは、原資産の正規バージョンを新規チェーンでミントするためにラップ資産を用います。 ラップされたトークンが悪用された事例はすでに発生しており、エコシステム全体にシステミックリスクをもたらします。
  • カウンターパーティリスク - 一部のブリッジでは、複数のバリデータが共謀してユーザーの資金を奪い取ろうと考えることはないという信頼の想定をユーザーに要求する、信頼ベースの設計を採用しています。 ユーザーは、これらのサードパーティアクターを信頼しなければならないため、ラグプル、検閲、およびその他の悪意の行為が発生するリスクにさらされています。
  • 未解決の問題 - 現在でもブリッジは開発の初期段階にあるため、様々な市場環境(ネットワーク混雑時や、ネットワーク全体への攻撃やステートのロールバックといった予見できないイベントの発生時)においてブリッジがどのように機能するかについては、未確認の事項が多く残っています。 この不確実性は様々なリスクをもたらすものですが、その影響の度合いはまだ不明です。

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

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

ブリッジとの統合

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

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

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

  3. Dapp内にブリッジを組み込む - このアプローチでは、ユーザーは外部のブリッジやDEXインターフェイスとやりとりする必要がなくなります。 このため、ユーザーのオンボーディング体験が向上します。 しかし、このアプローチにも以下のような制限があります:

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

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

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

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

複数のチェーン上でDappをデプロイする

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

例:

コントラクトにおけるチェーン間のやりとりを監視する

コントラクトにおけるチェーン間のやりとりを監視するには、サブグラフや、Tenderly等の開発プラットフォームを用いて、スマートコントラクトの状態をリアルタイムで観察することができます。 これらのプラットフォームにはさらに、コントラクトが発行したイベント(opens in a new tab)をチェックするなど、チェーン間のやりとりを対象としてより充実したデータ監視機能を実現できるツールが含まれています。

ツール

さらに学びたい方へ

ブリッジについてさらに理解を深めたい方は、 ジェイムズ・プレストウィッチ(opens in a new tab)による洞察溢れる講演をご覧ください:

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