クロスチェーントークンを再び交換可能にする方法:パートI

この2部作のレポートでは、ERC-7281について探求します。これは、クロスチェーントークンを同質化するための新しい提案です。パート1では、問題(ブリッジトークンの非同質性)を紹介し、現在の解決策を分析します。

紹介

モジュラーマキシは、ブロックチェーンの間をアリスのように飛び回るドメインとユーザーが100万以上存在し、最先端のテクノロジーや新しいアプリケーション、ステーキング/流動性提供の月の目標リターン、高いパフォーマンス、そして他のブロックチェーンでの超低トランザクション手数料を利用できるので、なぜ1つのチェーンに固執する必要がありますか?

しかし、ブロックチェーン間の移動は、アリスがワンダーランドを通るよりもはるかに複雑です。これは、現在のブロックチェーン間の相互運用性のアプローチに固有の制限(クロスチェーンブリッジなど)が主な原因です。特に、現在のクロスチェーンブリッジは、安全ではない(ブリッジハックで25億ドル以上が失われています)、遅い、高価、または機能が制限されているか、リストからのプロパティの組み合わせを表示します。

ブリッジング業界に悩まされている他の問題は、より微妙ですが、モジュラーマキシのマルチチェーンエコシステムの夢をユーザーや開発者に悪夢に変えるだけの十分な問題です。これの例として、異なるチェーンにクロスチェーンプロトコルを介してブリッジされたときに、交換可能なトークン(ERC-20など)が非交換可能になる方法があります。その結果、トークンは転送可能な資産としての特徴を損ないます。本記事では、ERC-7281: Sovereign-Bridged Tokensという、トークンの交換可能性を維持する解決策を探求します。

ERC-7281は、トークン発行者によって承認された複数のブリッジによるリモートドメイン上でERC-20トークンの正規表現の鋳造と燃焼を可能にするために、Ethereumでの代替標準であるERC-20を拡張しています。これにより、ERC-20トークンをクロスチェーン経由で異なるルート/ブリッジを介して送信しても、目的地でユーザーがトークンの交換可能なバージョンを受け取ることが保証されます(つまり、2つのトークンは1:1で交換可能です)。重要なことは、ERC-7281を採用するプロトコルは、ブリッジがブリッジトークンを制御する従来の状況と異なり、ブリッジトークンの制御を維持し、ブリッジの障害時に書き込み操作をレート制限できるということです。

理論上同一のERC-20トークンでも、異なるチェーン上での不同一性の例として、USDCを使用しましょう。Ethereum Layer 2 (L2)ネットワークアービトラム、ベース、オプティミズムなど、一般的なERC-20トークンをイーサリアムL1からこれらのチェーンに移動するために、正規のブリッジを使用するのが一般的です。L1 を発信する L2 トークンのこれらのバージョンは、一般に単に「ブリッジ [トークン名の挿入]」と呼ばれます。

USDCの場合、一般的なシンボルはUSDC.e、USDC.bなどです。時間の経過とともに、CircleはUSDCのデプロイをL2を含む他のチェーンに拡大し、USDCは正規のブリッジを介してすでに稼働しています。この2つのトークンは、同じエンティティによって鋳造され、同じ価格ですが、技術的に異なる、代替不可能なトークンであるため、「相互運用可能」ではありません - ネイティブUSDCはCircleのCCTPブリッジを介してブリッジすることができますが、ブリッジされたUSDCは正規ブリッジを介してのみL1にブリッジバックすることができます。

ERC-7281は、ERC-20の拡張を導入することで、トークンのデプロイヤーがそれに対する様々なブリッジソースを割り当て、パラメータ化できるように修正しています。上記の例では、CircleはユニバーサルUSDCトークンをすべてのL2に展開できます。ここで、正規のブリッジ(Circle Mint、Circle CCTP、その他の承認されたブリッジなど)がすべて、それぞれのロジックに従ってトークンを鋳造できる能力を割り当てられます。鋳造者がハッキングされるリスクを最小限に抑えるために、デプロイヤーは各鋳造者が特定の期間内にいくつのトークンを鋳造し、燃やすことができるかを制限できます。信頼性の高いブリッジ(正規のL2ブリッジなど)はより高い制限を持ち、中央集権的なコンセンサスを持つブリッジはより低い制限を持ちます。

ERC-7281は交換可能なクロスチェーントークンの創造を試みる最初の試みではありませんが、以前の提案に関連する問題(ベンダーロックイン、トークン発行者の主権の喪失、ブリッジトークンの流動性の起動コストの高さ、インフラのオーバーヘッド、およびブリッジの障害への露出の増加など)を解決します。

この2部構成のレポートでは、主権ブリッジドトークン標準を導入する理由と、ERC-7281(またはxERC-20とも呼ばれる)仕様の包括的な概要について検討します。また、ERC-7281の導入によるユーザー、開発者、インフラプロバイダー、およびEthereumエコシステムの他の関係者に対するポジティブな利点と潜在的な欠点についても議論します。

ブロックチェーンブリッジについての復習

非代替トークンの懸け橋の問題に入る前に、まず懸け橋のトークンが存在する理由を理解することが役立ちます。これには、懸け橋の運用と動機を理解する必要があります。なぜなら、懸け橋の運用者が懸け橋のトークンバージョンを作成する責任を負っているからです。

ブリッジは、ブロックチェーン間で情報を転送するための仕組みです。純粋な通貨情報以外にも、ブリッジはトークンレートや他のチェーン上のスマートコントラクトの状態など、任意の有用な情報を伝えることができます。ただし、アセット(トークン)を1つのチェーンから別のチェーンに転送することが、現在のブリッジを使用するユーザーの最も一般的な使用例です。

異なるクロスチェーン資産移転の手法は様々ですが、トークンブリッジングワークフローは通常、3つの高レベルパターンのいずれかに従います。

ロックしてミントするブリッジ

  • ユーザーは、トークンをそのネイティブまたは「ホーム」チェーン(最初に発行されたチェーン)から別のチェーンにブリッジしたいと希望しています。2つのブロックチェーンは相互運用可能ではありません。各チェーンは異なるアーキテクチャとプロトコルデザインを実装しているため、ユーザーはチェーンAのウォレットアドレスからチェーンBのウォレットアドレスに直接トークンを転送することができません。
  • 橋のオペレーターは、ユーザーが元のチェーンに預けたトークンをスマートコントラクトでエスクローし、ターゲットチェーンで展開されたトークンコントラクトを介してネイティブトークンの「ラップ」表現を作成します。
  • ユーザーが逆方向にブリッジを架けたい場合(宛先チェーン→元のチェーン)、彼らは宛先チェーンのブリッジにラップされたトークンを返し、このブリッジのロジックに従ってこれを検証し(例:ZKプルーフまたは外部クォーラム)、ホームチェーン上のエスクローから元のトークンを解放します。

ブリッジを燃やして作る

  • エスクローでトークンをロックする代わりに、このアプローチではトークンをソースチェーン上で焼却(破壊)します;
  • その後、ブリッジは目的のチェーンに等しい量を鋳造します;
  • 逆向きのトリップでは、新しいトークンがソースチェーン上で造幣される前に、ブリッジされたトークンが宛先チェーンで燃やされます;
  • これにより、クロスチェーンの転送が可能ながら、総トークン供給量を維持します。

アトミックスワップ

  • この方法は、直接、他の当事者と共にソースチェーン上の資産を宛先チェーン上の資産と交換します。
  • アトミックスワップは、同じ秘密値で相互に資金をロックし、それらをアンロックすることによって機能します。つまり、どちらかの側で秘密が明らかにされた場合、他の側でも明らかにすることができます。これにより、スワップはアトミック性の特性を持ちます。
  • アトミシティとは、スワップが完全に(両側で)完了するか、まったく完了しないことを意味し、詐欺や部分的/失敗した転送を防ぎます。

最初のアプローチ(ロックと鋳造)は現在最も一般的です。 ブリッジによって鋳造されたネイティブトークンとその対応するラップトークンとの間の価値の同等性は、ユーザーが資産をクロスチェーンで「転送」し、初めて発行されたチェーンとは異なるチェーンでトークンを使用できるようにします。

しかし、インテントベースのブリッジングなど、新しい設計が非常に人気を集めています。 「インテント」は、特定の手順を概説するのではなく、取引の望ましい結果を表現することをユーザーに可能にします(「100 USDCを100 DAIにスワップする」)。インテントは、特にペアリングされた場合に、人々にとってオンチェーンの体験を大幅に簡素化し、暗号通貨の使用を容易にするため、強力なUXの解除として登場しました。チェーンの抽象化ソリューション.

クロスチェーンの意図ユーザーがブリッジングの基盤の複雑さを気にすることなく、チェーン間でトークンを転送できるようにします。意図ベースのブリッジでは、ユーザーはソースチェーンに資金を預けて、宛先チェーンでの希望する結果(「意図」)を指定します。専門のオペレーターである「フィラー」または「ソルバー」は、要求されたトークンを宛先チェーンのユーザーに事前に送信することで、この意図を実現できます。その後、オペレーターは移転が行われたことを証明し、ソースチェーン上のロックされた資金を請求します。

一部の意図ベースのブリッジは、裏でロックアンドミントのメカニズムを活用しています。この場合、ブリッジはラップトークンをミントし、ユーザーの意図を満たしたフィラーに送信するか、フィラーが介入しなかった場合は直接ユーザーに送信します。意図ベースのブリッジは、ソルバーネットワークを介して効率の良い追加の層を提供しますが、それらは依然として従来のロックアンドミントブリッジと同じ原則に基づいています。

私たちは、従来のブリッジングまたは意図ベースのブリッジングを通じて作成された包装トークンそれぞれを、ブリッジのオペレーターからのIOUと考えることができます。このIOUは、エスクロー契約から基礎となるトークンの量を解放することを約束しています。これらの包装アセットの価値は、ブリッジオペレーターの(知覚される)ホルダーからの要求を処理する能力と直接的に相関しています。この要求は、トークンのホームチェーンにエスクローされたネイティブトークンを引き出すためのものです。

ソースチェーン上の基礎トークンをロックし、そのラップされた表現を宛先チェーン上で鋳造するために承認されたブリッジは、トークンの総供給量が一定であることを保証します。基礎トークンの1単位につき、対応するラップトークンの単位がちょうど1単位鋳造され、その逆も同様です。アプリケーションがラップトークンを交換媒体として受け入れるか、ラップされた資産を通貨として使用する場合、アプリケーションの開発者とユーザーは、ブリッジプロバイダーがラップトークンを裏付ける「実際の」資産を保護することを信頼しています。

なぜ橋が必要なのですか?

外部チェーン上で資産の合成バージョンで取引できる能力は、橋が資産の表現を作成することで可能になります。この機能は、クロスチェーンの相互運用性の利点を開発者やユーザーが活用できるようにし、それによりより多くの流動性へのアクセス、新しいユーザーへの露出、およびユーザーの柔軟性(異なるチェーンのお気に入りのアプリとの摩擦なく相互作用できる)などの利点があります。

実際にこれがどのように機能するのか、なぜ開発者とユーザーの両方にとって重要なのかをより良く理解するために、架空の分散型取引所であるBobDEXを使用した具体的な例を見てみましょう。この例では、ラップトークンがクロスチェーンの拡張を可能にする方法を示し、利点と発生する可能性のある問題を強調します。

BobDEXは、BobがEthereum上で作成した自動マーケットメーカー(AMM)の取引所であり、異なる資産間での信頼できるスワップを可能にします。BobDEXには、ガバナンストークンおよびLP報酬トークンとして機能するネイティブトークン$BOBがあります。後者の場合、BobDEXは流動性提供者(LP)にBOBトークンを発行し、プールに供給された資産をスワップするDEXユーザーが支払う手数料の一部を受け取る権利を与えます。

BobDEXの市場シェアは大幅に成長していますが、Ethereum L1の制限がさらなる成長を妨げています。例えば、高いガス料金や取引の遅延のために、一部のユーザーはEthereum上のBobDEXを使用したくないと考えています。同様に、他のユーザーはEthereum上でネイティブの$BOBトークンを保持せずに、$BOBトークンの価格に露出したいと考えています。

問題を解決するため、Bob は、低手数料で高スループットの Layer 2(L2)ロールアップである Arbitrum 上に BobDEX のバージョンを展開し、Arbitrum-Ethereum ブリッジを介して L2 上で BOB トークンのラップバージョン(wBOB)を展開します。Arbitrum 上の BobDEX は、LP 報酬とガバナンスにネイティブの BOB トークンの代わりに wBOB を使用する以外は、Ethereum 上の BobDEX と同じです。

アプリケーショントークン(wrapped BOBとネイティブBOB)の違いは、ユーザー(例:流動性提供者)がArbitrum上のBobDEXとやり取りする際には影響しません。wBOBトークンは、Arbitrum-Ethereumブリッジに保持されている実際のBOBトークンで裏付けられているため、wBOBトークン保有者はブリッジ契約とやり取りすることで、簡単にEthereum上のネイティブBOB ERC-20トークンと交換することができます。

ボブとユーザーにとってウィンウィンの状況です:

  1. Bobは、特にBobDEXで取引する際に低いガス料金と高速なトランザクション確認を望むユーザーを引き付けることができます
  2. LPは、Ethereumの高いガスコストと長い確認時間を扱うことなく、BobDEXに流動性を供給することで報酬を獲得することができます
  3. Hodlersは、BOBトークンの価格変動による利益を得るために、BOB ERC-20契約とのやり取りなしで市場でwBOBトークンを購入することができます。

ブリッジングの利点は、ブリッジトークンの流動性を活用した相互運用可能なイノベーションの向上や新たなユースケースの開拓にも及びます。たとえば、アリスは、アリトラム上でwBOBを担保として受け入れるレンディングプロトコルであるAliceLendを作成することで、wBOBの有用性を拡大し、新たな市場を生み出すことができます。貸出と借入

AliceLendに流動性を供給する貸し手は、ユーザーがローンを返済できない場合、AliceLendは自動的に担保として預けられたwBOBトークンをオークションにかけて貸し手に返済することが保証されています。この場合、清算されたwBOBの担保の買い手はBobDEXのLPの役割を引き受け、wBOBトークンが元のBOBトークンと1:1で交換できるという同じ保証を受けます。

クロスチェーンのブリッジングは、現在の形式で実現可能な解決策を提供しています。以前は孤立していたEthereum L2間の相互運用性そして、新しいアプリケーション(例:クロスチェーンレンディングやクロスチェーンDEX)の容易化を促進しています。しかし、ブリッジエコシステムは現在、さらなる成長を妨げる制約に直面しています。クロスチェーントークンの非代替性などの問題について、後述で詳しく調査します。

なぜブリッジトークンは代替不可能になるのですか?

以前に説明したロックアンドミントのブリッジングワークフローは紙上ではシンプルに見えますが、実際には正しく動作するために多くのエンジニアリングとメカニズム設計の努力が必要です。

最初の課題は、ブリッジされたトークンの包装バージョンが常に、ソースチェーンでロックされたネイティブトークンによってバックアップされていることを確認することです。攻撃者が、ソースチェーンにネイティブトークンを預けずに、リモートチェーンでトークンの表現を偽造すると、(詐欺的に偽造された)包装トークンをホームチェーン上のネイティブトークンと交換して、包装トークンを鋳造する前にブリッジ契約に預け入れた正当なユーザーが預金を引き出せなくなってしまう可能性があります。

2番目の課題は、ブリッジトークンの性質に由来する微妙なものであり、同じリモートチェーンでブリッジプロバイダーによって鋳造されたトークンの2つの表現は、1:1で他のトークンと交換することはできません。トークンをチェーン間で移動する際の問題に関連するこの側面を説明するために、異なるルートを介してブリッジされたトークンを交換しようとする2人のユーザーの例を別の例として使用することができます。

  • アリスは、カノニカルなアービトラムブリッジを介して、イーサリアムからアービトラムにUSDCをブリッジし、アービトラムで200 USDC.eを受け取ります。一方、ボブはAxelarを介してUSDCをアービトラムにブリッジし、アービトラムで200 axlUSDCを受け取ります。アリスとボブは、アリスが200 USDCをボブに送信し、ボブが400 USDCをイーサリアムに引き出すために(200 USDTと引き換えに)合意します。
  • BobはaxlUSDCを通じて400 USDCを引き出そうと試みますが、200 USDCしか受け取らず、ブリッジがBobに提供できるのは200 USDCだけだと説明するメッセージも一緒に受け取ります。Bobは混乱しています。ラップされたERC-20トークンは「交換可能」であり、誰もがどのアプリケーションでもERC-20トークンを1:1で交換できるようにする不整合を示すべきではありません。
  • ボブはクロスチェーンブリッジングについての厳しい教訓を学びました。「交換可能なERC-20トークン」ということは常に「このトークンを他のERC-20トークンと1:1でアプリケーション間で交換できる」という意味ではありません。ボブはアリスとの危険な取引を試みますが、アリスがトークンを返さない可能性があるため、壮観に失敗します。

スワップでラグドした後のボブ

BobとAliceが同じ基礎資産のラップト版を受け取った場合、なぜBobは400 USDCを引き出すことができないのでしょうか?異なるチェーンで発行されたトークンは互換性がないため、ネイティブチェーンで発行されたトークンの表現は、ユーザーがトークンのネイティブチェーンに戻る際に支払いを約束するブリッジからのIOUです(残高に応じて)。

すべての橋渡しトークンの価値は、それに関連する橋渡しプロバイダーによって保持されたホームチェーン上の預金と、宛先チェーン上での表現の発行に結び付けられています。Bobの橋渡しプロバイダーは、その預金からカバーできる金額であるため、Bobに200 USDCしか支払えません。Aliceの200 USDCは、決して預金を受け取らず、また、AliceにIOUを発行していないため、Bobの橋渡しプロバイダーを介して引き出すことはできません。Bobが残りのトークンにアクセスできるようになる前に、AliceはEthereum上のArbitrumからロックされたUSDCを引き出し、Bobの橋渡しプロバイダーを介して橋渡しする必要があります。

ボブとアリスのジレンマは、競合するブリッジプロバイダーによって鋳造された基礎資産の非代替表現が複数存在するドメイン間のブリッジングに問題があることを示しています。同じ資産の異なるERC-20表現のもう1つの問題は、それらを単一の流動性プールで取引することができないことです。

前の例を使用すると、チェーン上にaxlUSDCとUSDC.eがある場合、それらをETHと逆にスワップするためには、ETH/axlUSDCとETH/USDC.eの2つの流動性プールを展開する必要があります。これにより、トレーディングプールの流動性が本来よりも小さくなる「流動性の断片化」という問題が発生します。なぜなら、本質的に同じトレーディングペアに適した複数のプールが存在するためです。

解決策は、BobとAliceがソースチェーンのブリッジから引き出すことなくトークンを交換できるように、目的地チェーンで単一の「正規」バージョンのトークンが流通することです。チェーンごとに正規のトークンを持つことは、開発者にも利益をもたらします。ユーザーはトークン流動性に関する問題を解決する必要なく、エコシステム間を迅速に移動できます。

では、各チェーン上で使用および転送されることを期待しているトークンの正規バージョンを実装する方法はどのようになりますか?次のセクションでは、複数のチェーン上で正規トークンを作成するための人気のあるアプローチの一部について説明します。

異なるチェーン間での標準トークンの実装

1つのチェーンごとに正規のトークンを作成することは簡単ではなく、さまざまなトレードオフと利点を持つ複数のオプションが存在します。正規のトークンを作成する場合、特定のトークンの価値を裏付けるIOUsの存在について誰を信頼するかを考える必要があります。トークンの作成者であり、異なるチェーン間で使用および転送可能なトークンにしたい場合、可逆性の問題に直面せずに実現するためには4つのオプションがあります:

  1. カノニカルロールアップ/サイドチェーンブリッジを介してカノニカルトークンを発行する
  2. サードパーティのブリッジプロバイダーを介してカノニカルトークンを作成します
  3. トークン発行者ブリッジを介して正規のトークンを作成する
  4. アトミックスワップを使用した直接のマルチチェーン発行

最初の3つのオプションは、トークンのクロスチェーン移動を促進するために様々なブリッジング機構に依存しています。ただし、トークンの作成者として、サポートされている各チェーンでトークンをネイティブに発行することにより、ブリッジングを完全にバイパスすることも選択できます。このアプローチでは、ラップトークンやブリッジインフラストラクチャーに頼らずに、チェーンごとに別々だが調整されたトークンの展開を維持し、原子スワップによりチェーン間の信頼できる交換が可能になります。

ただし、この手法にはクロスチェーンでの流動性の維持とアトミックスワップの促進のための高度なインフラストラクチャが必要です。複数のネイティブデプロイメントを管理する複雑さは、歴史的には大規模なプロトコルと十分な技術リソースを持つプロトコルに限定されていました。

1. カノニカルロールアップ/サイドチェーンブリッジを介してカノニカルトークンを発行する

チェーンに正規の(祀られた)ブリッジがある場合、ネイティブチェーンからのブリッジを希望するユーザーのために、プロトコルのトークン表現を作成する権利を割り当てることができます。チェーンのカノニカルブリッジを介してルーティングされるトランザクション(入出金)は、通常、チェーンのバリデーターセットによって検証され、ホームチェーン上のデポジットが鋳造されたすべての表現を確実に裏付けるというより強力な保証を提供します。

カノニカルブリッジはトークンのカノニカル表現を生成していますが、他の表現はまだ存在しています。これは、カノニカルブリッジにはしばしばユーザーに最高の体験を提供することを妨げる制限があるためです。たとえば、Arbitrum/OptimismからEthereumにブリッジをかける場合、ロールアップのカノニカルブリッジを介して行うと、トランザクションは検証者によって検証され、場合によっては争われるため、7日間の遅延が発生します。詐欺証明, もし無効であれば、ロールアップの決済レイヤー(Ethereum)が取引バッチを決済する前に。

クイックな出口を希望するRollupユーザーは、保留中のRollup出口の所有権を引き継ぎ、ユーザーの希望するターゲットチェーンに前払い流動性を提供できる他のブリッジプロバイダーを使用する必要があります。このようなブリッジが従来のロックアンドミントモデルを使用する場合、異なるプロトコルによって発行されたトークンの複数のラップされた表現が生じ、先ほど説明した同じ問題に直面することになります。

独立した検証者セットを持つサイドチェーンは、引き出しがサイドチェーンのコンセンサスプロトコルが引き出しトランザクションを含むブロックを確認するときに実行されるため、レイテンシが低くなります。Polygon PoSブリッジは、サイドチェーンを異なるドメイン(EthereumロールアップやEthereumメインネットを含む)に接続する典型的なブリッジの例です。

注:元のPolygon PoSチェーンを指します。計画された有効なチェーンクロスチェーンとして利用されるであろう。Polygonは、外部のバリデータによってセキュリティが確保されたサイドチェーンから、Ethereumのコンセンサスによってセキュリティが確保されたバリディウムへの切り替えが完了すると、L2となります。

ただし、サイドチェーンブリッジもロールアップの正規ブリッジと同様の弱点を共有しています。ユーザーは接続されたチェーンのペア間でのみブリッジを行うことができます。正規ブリッジを使用して他のブロックチェーンにブリッジすることはできません。例えば、Arbitrumブリッジを使用して現在のArbitrumからOptimismへのブリッジを行うことはできませんし、Polygon PoSブリッジを介してPolygonからAvalancheへのブリッジを行うこともできません。

1.1. 流動性ブリッジを使用して正規のトークンを鋳造する

ロールアップのネイティブブリッジに頼ると、キャノニカルトークンの移動にはいくつかの問題があります。たとえば、流動性が低く、資産の移動に遅延が生じることがあります。プロトコルは、この問題を解決するために流動性ブリッジと連携し、スピーディな引き出しと低遅延のブリッジを実現しています。

このアレンジメントでは、承認された流動性ブリッジ(a)は、ソースチェーン上のプロトコルのトークンの包まれた表現を作成し、(b)プロトコル所有の流動性プールを介して、目的地での正規の表現に包まれたトークンを交換します。

宛先チェーン上のトークンの正規表現は通常、正規サイドチェーン/ロールアップブリッジによって鋳造されるバージョンですが、例外も存在します(後で見るように)。例えば、Optimism上のUSDTの正規バージョンはOptimism Bridgeによって鋳造されたopUSDTです。

各流動性ブリッジは、異なる流動性プールに預けられた資産のペア間でスワップを実行するための自動マーケットメーカー(AMM)を備えたDEXのように機能します。流動性提供を促進するために、AMMプールはプール契約に正規トークンをロックアップするホルダーにスワップ手数料の一部を共有します。

これはUniswapのモデルに似ています。唯一の目立つ違いは、アセットペアが通常、流動性ブリッジのトークンの正規表現に対するトークンの表現です。例えば、Hopを介してUSDTをOptimismにブリッジするユーザーは、huSDT:opUSDTプールを介してOptimism上でhUSDTと交換する必要があります。

流動性ブリッジを介したブリッジングのワークフローは次のようになります:

  • ソースチェーン上でネイティブトークンをロックします
  • ターゲットチェーン上のネイティブトークンのミントブリッジ表現
  • AMMプールを介して、ターゲットチェーン上でブリッジされた表現と正規表現をスワップする
  • ユーザーに正規のトークンを送信する

このプロセスは、すべての流動性ブリッジ(Across、Celer、Hop、Stargateなど)に対して同様です。ただし、通常はエンドユーザーからは抽象化されています - 特にソルバ/フィラーによって - そして多くの動くパーツが関与していても、単一のトランザクションのように感じられるでしょう。

ソースチェーンに戻る際、ユーザーは正規表現を燃やすか、正規トークンをブリッジ表現と交換し、それを燃やして証明書を提供します。確認されたら、ユーザーは最初にロックされたネイティブトークンを引き出すことができます(前の操作と同様に、トークンを元のチェーンに戻す詳細はユーザーから隠され、ソルバーによって管理されます)。

リキッドリティブリッジングは優れています、主にそれはロールアップブリッジングにおける遅延の問題を修正するからです。例えば、Hopは、特定のパーティーである「Bonders」として知られる専門家に、L2のユーザーの引き出し取引の妥当性を証明することを許可し、ロールアップのL1ブリッジからの引き出しのコストを先負わせます。それぞれのBonderはL2チェーンのフルノードを実行し、ユーザーの出口取引が最終的にL1で確認されるかどうかを決定し、ユーザーが不正な引き出しを開始し、Bonderに損失をもたらすリスクを減らします。

流動性ブリッジは、カノニカルブリッジとは異なり、ユーザーがより多くのチェーン間を移動することも可能にします。たとえば、Hopでは、ユーザーが最初にイーサリアムに引き出す必要なく、ArbitrumとOptimismの間をブリッジすることができます。高速なL2→L1ブリッジングと同様に、高速なL2→L2ブリッジングには、Bondersが送信元L2チェーンの引き出しを確認するためにフルノードを実行し、送信先L2チェーン上のユーザーのトークンの発行コストを先払いする必要があります。これにより、ロールアップ間のより多くの相互運用性が可能になり、ユーザーエクスペリエンスが大幅に向上します。ユーザーは問題なくロールアップ間でトークンを移動することができます。

しかし、流動性ブリッジングにはデメリットもあり、チェーンの橋を使用してL2/L1チェーン上でトークンの正規表現を作成する際の有用性に影響を与えます。

流動性ブリッジの欠点

1. スリッページ

スリッページとは、AMMとのやり取り時に予想されるトークンの量と受け取ったトークンの量の差です。スリッページは、AMMがプール内の現在の流動性に応じてスワップの価格を設定するために発生します。価格設定は、ユーザーが取引を開始してから取引が実行されるまでに変化する可能性があるため、スワップ完了後にペア内の各アセットのプールのバランスを維持するための均衡が保たれます。

ブリッジされた資産の流動性が低い場合、スリッページが増加することもあります。プールが十分な流動性を持っていない場合、大きな取引が価格を大きく変動させ、ユーザーが高い価格でスワップを実行する可能性があります。アービトラージャーは、同じ資産を取引するプール間の不均衡を修正するのに役立つことが期待されていますが、取引活動/価値の低いトークンを含むアービトラージトレードを行うことは避けられるかもしれません。

これは、スリッページが発生する境界ケースを考慮する必要があるため、クロスチェーンアプリケーションを開発する開発者にも影響を与えます。ユーザーは、1つまたは複数の宛先チェーンでトークンの量が減少するため、クロスチェーン操作を完了できない場合があります。

リッジアグリゲーターのようなアプリケーション(先行スリッページなしでスワップをカバーするための十分な流動性があるかどうかを知ることができない)は、最大スリッページ許容量を指定し、それをユーザーに提供される見積もりに通知することで問題を回避しています。これによりトランザクションのリバートを防ぎますが、ユーザーは常にリッジトークンの一部の割合を失います — ブリッジのAMMプールの流動性に関係なく。

2. 流動性制約

流動性ブリッジにおける基本的な課題は、宛先チェーン上で十分な流動性が必要なことです。トラディショナルなロック&ミントブリッジとは異なり、トークンのミントは直接ロックされた資産によって裏付けられるのではなく、流動性ブリッジはAMMプール内の利用可能なトークンに依存してクロスチェーンのトランスファーを完了します。流動性が臨界値を下回ると、ブリッジメカニズム全体が実質的に機能停止する可能性があります。

  • もし流動性が低すぎると、ブリッジ操作は完全に停止する可能性があり、ユーザーは意図した転送を完了できなくなることがあります;
  • ユーザーは、プールの流動性を枯渇させるのを避けるために、大きな送金を小さなトランザクションに分割することを強いられる可能性があります;
  • ボラティリティが高い時期や市場のストレスが高い時期には、流動性プロバイダーは、まさにブリッジ機能が最も必要とされるときに、プールから撤退することがあります。
  • 新しいトークンペアのブートストラップは特に困難であり、ブリッジを稼働させるためには重要な初期流動性が必要です。

流動性要件は循環依存関係を作り出します:ブリッジは信頼性を持って機能するために十分な流動性が必要ですが、流動性プロバイダを引き付けるには、一貫したブリッジの使用と手数料の生成を示す必要があります。この鶏と卵の問題は、特に新しいまたは取引頻度の低いトークンにとって深刻です。これらのトークンは複数のチェーン上で十分な流動性を維持するのに苦労するかもしれません。

3. ミスアライメントしたインセンティブ

流動性ブリッジは、ユーザーが過度なスリッページを被ることなく、目的地のチェーン上で標準的なトークンに対するブリッジされた表現からのスワップをカバーできる範囲で役立ちます。また、ブリッジとのやり取りにかかるガスコストも、ユーザーの視点から見た流動性ブリッジの価値を決定します。そのため、ブリッジアグリゲーターやトークンを発行するプロジェクトチームは、流動性と取引コストに基づいてブリッジを優先的に選択します。

これにより、プロジェクトのトークンをブリッジングしたり、ブリッジアグリゲーターを使用してクロスチェーンでトークンを送信したりするユーザーは、ユーザーエクスペリエンスが向上しますが、流動性に基づいてブリッジを選択すると、流動性プロバイダー(LP)のインセンティブを支出できないブリッジが不利になります。さらに、純粋な取引手数料に基づいてブリッジを選択すると、運用コストを削減するために中央集権的なアプローチを採用し、ブリッジ取引の手数料を低く設定できるブリッジが有利に競争することになります。いずれの場合も、ブリッジはおそらく最も重要な指標であるセキュリティについて競争していません。

流動性ベースのブリッジは、取引活動が低いロングテールアセットにも不利です(これにより、LPを引き寄せる可能性が低くなります)。ロングテールトークンの発行者(またはブリッジングボリュームが低い新しいトークン)は、発行者のトークンの正規の表現に対して(流動性ブリッジを介してブリッジされた)ネイティブトークンのスワップをカバーするために、AMMプールを設定し、流動性をブートストラップするか、ブリッジオペレータと協力して、LPがそのアセットに流動性を供給するための金融インセンティブを増やす必要があります。

4. ブリッジングUXが低い

流動性ブリッジは、カノニカルブリッジの改良版ですが、UXの問題もあります。クロスチェーンスワップでスリッページを受けるだけでなく、ユーザーは宛先チェーンで即座にブリッジングトランザクションを完了できない場合があります。なぜなら、ブリッジには宛先チェーンのカノニカルトークンとの取引をカバーするためのプール流動性が十分にない場合があるからです。ブリッジはユーザーのトークンスワップメッセージが宛先チェーンに到達する時点でどれだけのアセットペアの流動性が存在するかを知ることはできません。そのため、このエッジケースはほとんど避けられません。

この状況でユーザーは2つの選択肢があります(どちらも最適ではありません):

  • ブリッジに十分な流動性があるまで待って、スワップを完了し、正規のトークンを引き出してください。これは、ブリッジ取引で受ける遅延と、プールの流動性が非常に短期間で任意に変化するため、初めに引用されたトークンの量を受け取るかどうかをユーザーが知ることができないため、最適ではありません。
  • ブリッジの独自のトークン表現(例:Hop BridgeのhUSDT)を受け取ります。これはサブオプティマルです。ほとんどのアプリケーションは、ネイティブトークンの正式な表現(例:Optimism Bridgeによって作成されたopUSDT)と統合することを好むため、ユーザーのラップトークンは受け入れられない場合があります。

3. 正規のサードパーティーブリッジを介して正規トークンを発行する

マルチチェーンdappは、dappが展開されているすべてのチェーンでのトークンの正式な表現をミントするために、単一のブリッジを選択することにより、非交換可能なブリッジトークンの問題を回避できます。プロジェクトのトークンの承認された表現をミントする正式なブリッジと同様に、このアプローチでは、リモートチェーンでミントされたトークンをプロジェクトのホームチェーンに展開されたトークン契約にマッピングする必要があり、トークン供給がグローバルに同じであることを保証する必要があります。ブリッジプロバイダーは、トークンのミントとバーニングを追跡し、ホームチェーン上のトークン供給と同期してミントとバーニング操作が実行されるようにする必要があります。

単一のブリッジプロバイダーを使用すると、特に第三者のブリッジが最大1つのチェーンにのみ接続するのに対して、より広範囲のエコシステム間のブリッジをサポートするためにインセンティブを得ているため、プロジェクトチームにとって柔軟性が増します。アプリケーションが展開されているすべてのチェーンでブリッジが存在する場合、ユーザーはホームチェーンに戻す必要なく、クイックにクロスチェーンで移動できます。ブリッジプロバイダーは、ユーザーが宛先チェーンAでトークンを鋳造する前に、宛先チェーンAで鋳造されたトークンが燃やされることを確認するだけでよく、そして標準的なトークンは宛先チェーンB上で(再)マッピングされ、ホームチェーン上のトークンに変換されます。

非代替性ブリッジトークンの問題も解消されます。承認されたブリッジプロバイダーを介してブリッジを行う場合、常に他のブリッジトークンと1:1で交換できます。このアプローチは、流動性ベースのブリッジングの問題を正し、カノニカルブリッジモデルにおいてもっともらしいものにします。

  • ブリッジトランザクションでは、ブリッジプロバイダーはAMMを介して正規の表現に対して表現を変換する必要がないため、ユーザーはスリッページを受けません。ブリッジプロバイダーのトークンは、すべてのドメインでブリッジされたトークンの正規の表現です。これらの表現の価値は、ブリッジプロバイダーがトークンのネイティブチェーン上でロックされたトークンの価値にペッグされています。
  • ユーザーは、ブリッジングにほとんど遅延がないため、ブリッジプロバイダーは、mint()メッセージが到着した直後に、すぐに宛先チェーンでラップされた表現を作成できます。
  • 開発者は、AMM流動性のブートストラップや流動性供給インセンティブプログラムの心配をせずに、ブリッジオペレーターにマルチチェーントークンの展開の管理をアウトソーシングすることができます。

野生に存在する単一のブリッジプロバイダトークンの一部の例には、LayerZeroのOmnichain Fungible Token(OFT)、AxelarのInterchain Token Service(ITS)、CelerのxAsset、およびMultichainのanyAssetが含まれます。すべての例は基本的には独自のトークンであり、異なるブリッジプロバイダを介して送信された同じトークンの表現と互換性がありません。この微妙な詳細は、このブリッジトークンの処理方法に関連するいくつかの問題を強調しています。具体的には以下の点です。

  • ベンダーロックイン
  • 主権喪失
  • 橋の故障に高い露出
  • ターゲットチェーン上でのトークンのカスタム機能の喪失
  • ベンダーがサポートするチェーンに制限されていること
  • 全ての希望するチェーンで同じトークンアドレスを維持できないことは、ユーザーのセキュリティに損害を与えたり、フィッシング攻撃の標的にされる可能性を高めることがあります

正規の第三者ブリッジの利点

1. ベンダーロックイン

1つまたは複数のチェーン上で正式な表現を作成するために1つのブリッジプロバイダを選択することは、開発者がベンダーロックインのリスクにさらされることを意味します。各ブリッジプロバイダが独自の表現を作成し、そのインフラストラクチャ(および統合エコシステムプロジェクト)にのみ互換性があるため、単一のブリッジプロバイダモデルは、将来別のブリッジに切り替えるオプションなしにトークン発行者を特定のブリッジングサービスにロックします。

ブリッジプロバイダーを切り替えることは可能ですが、切り替えコストは高すぎて、ほとんどのプロジェクトがこのルートを選択するのをやめてしまいます。ざっくりした考えを示すと、ある開発者(ここではボブとします)がEthereum上でトークン(BobTokenと呼ぶことにします)を発行し、LayerZero OFTを選択して、Optimism、Arbitrum、BaseでBobTokenの正規バージョンを作成する場合を考えます。BobTokenの供給量は固定で、100万トークンで、LayerZeroを介してブリッジされたトークンはBobTokenの総供給量の50%を占めています。

ビジネス取引は順調に進んでいますが、ボブはユーザーがAxelarなどの競合するブリッジサービスを介してBobTokenをブリッジする方が良いと判断します。しかし、OFTトークンとITSトークンは互換性がないため、ボブは単に「私はAxelar ITSに切り替えて、BobTokenをOptimism、Base、およびArbitrumで正規表現化する」と言うことはできません。その結果、ボブは古いユーザーと新しいユーザーの両方にとって頭痛の種を作る可能性があります。2つのBobTokenは交換可能ではないため(前述の問題を再導入する可能性があります)。さらに、LayerZeroのバージョンのBobTokenと統合されたアプリケーションは、AxelarのバージョンのBobTokenを代替として受け入れることができません。これにより、BobTokenの流動性がBobTokenの競合する表現が共存するさまざまなチェーンで分断されます。

遷移を可能にするために、ボブは、LayerZero で鋳造された BobToken の包装された表現をユーザーに解除させ、ブリッジされた OFT トークンを燃やして Ethereum 上の BobToken をアンロックするトランザクションを送信する必要があります。ユーザーは、Axelar を使用して Ethereum 上でトークンをロックし、宛先チェーン上で正規の BobToken(Ethereum 上のトークン契約の供給にマッピングされたもの)を受け取ることで、新しい正規の BobToken の表現に切り替えることができます。これにはコストがかかり、DAO プロジェクト管理チームにとっては大規模な調整と運用のオーバーヘッドも発生するため、選択したプロバイダーに固執することが通常は最も安全なオプションです。

しかし、これにより、ベンダーロックインによって、契約条件を守ることができないブリッジプロバイダーが失敗した場合に切り替えることが不可能になり、開発者のボブのような開発者は問題のある状況に置かれます。また、ブリッジはほぼ無限のレバレッジを提供します。ブリッジプロバイダーは、ユーザーがBobTokensをブリッジする際に理由が明確でないままユーザーのブリッジ操作を制限する、ブリッジ手数料を引き上げる、さらにはブリッジ操作を検閲するなどの任意の操作を行うことができます。この場合、ボブは手を縛られており、不良なサードパーティのブリッジからの完全な切り替えは、ビジネス上の関係を維持することと同じくらい複雑です。

2. プロトコルの主権喪失

ベンダーロックインに関する前のセクションの最後の部分では、正規のサードパーティブリッジを使用する際の別の問題を強調しています:トークン発行者は、利便性とUXの向上と引き換えに、正規のブリッジトークンの制御をトレードオフしています。前の例を使用すると、イーサリアム上のBobTokenは、基礎となるERC-20トークンコントラクトを制御しているため、完全にボブの管理下にありますが、Optimism、Arbitrum、BaseのBobTokenは、これらのブロックチェーン上でBobTokenの正規表現を発行するOFTコントラクトを所有するLayerZeroによって制御されています。

Bob は LayerZero が標準表現をネイティブ トークンの元の設計に合わせることを期待しているかもしれませんが、常にそうであるとは限りません。最悪のシナリオでは、ブリッジプロバイダーが根本的に異なるバージョンのトークンコントラクトを実装しているため、イーサリアム上のBobTokenの動作がOptimism上のBobTokenの動作と大きく異なる可能性があり、プロトコルのユーザーに問題を引き起こします。この問題は、プロトコルとブリッジプロバイダーの目標と利益が異なるプリンシパルエージェントダイナミクスによっても悪化する可能性があります。

3. ブリッジの故障への高い露出

最初のアプローチでは、トークンが各チェーンの正規ブリッジを介してクロスチェーンにブリッジされ、1つのブリッジに影響を与えるエクスプロイトによるトークン発行者へのリスクは、そのブリッジに封じ込められます。例えば、ハッカーが1つの流動性ブリッジを侵害し、担保を預けることなく無限の量のラップドトークンを鋳造したとします。その場合、流動性プールでラップされた資産に利用可能な最大流動性までしか引き出すことができません(例:OptimismでcUSDTをミント→cUSDTを正規のopUSDTにスワップ→、イーサリアム上のネイティブUSDTと交換→ファストブリッジを介してopUSDTをイーサリアムに引き出します)。

サードパーティーの正準ブリッジモデルでは、パートナーブリッジに影響を与える悪用からトークン発行者へのリスクは、影響を受けるブリッジが展開されているリモートチェーン上で攻撃者が発行したトークンの総額と同等です。これは、すべてのチェーン上の正準表現が、他のチェーンで発行された正準トークンと1:1で交換可能であるため可能です。

chain Bのサードパーティブリッジを攻撃者が侵害し、1000トークンを発行する(トークンは最初にchain Aで発行される)が、担保を預けずに行った場合、攻撃者のchain B上のトークンはホームチェーン契約にマッピングされていないため、chain Aから引き出すことはできません。ただし、chain B上のトークンをchain Cにブリッジし、1000 chain Bトークンを1000 chain Cトークンと交換することができます。なぜなら、各クロスチェーントークンは同じブリッジサービスから発信されるため、互換性があり、代替可能です。chain Cトークンはホームチェーン契約にマッピングされており、chain A(トークンのホームチェーン)でトークンをロックしたユーザーによって正当に発行されたため、攻撃者はchain C上でトークンを燃やし、chain A上でネイティブトークンを引き出し、その後、CEXまたはフィアットオフランプを介してトークンを交換して行程を完了する可能性があります。

(ソース)

カスタムトークンの機能の喪失

正規のサードパーティ ブリッジを使用する場合、トークン発行者は、元のデプロイに存在するカスタム機能やトークンの動作を実装する機能を失うことがよくあります。これは、ブリッジプロバイダーが標準化されたERC-20実装コントラクトを使用する傾向があり、元のトークン実装に存在する特殊な機能をサポートしていないために発生します。

クロスチェーンを介したトークンのブリッジでは、通常、投票委任(ZK)、リベースメカニズム(stETH、USDM)、トランスファーキャパビリティ(memecoins)、ブラックリストおよびホワイトリスト機能(USDT、USDC)、一時停止可能なトランスファー、特殊なミンティングルールや権限などの一般的なトークン機能が剥奪されることがあります。これにより、トークンの動作に一貫性がなくなり、これらのカスタム機能に依存する統合が壊れる可能性があります。

ブリッジトークンの標準化は、ブリッジプロバイダーの視点からするとより簡単ですが、実質的にトークンの機能を制限し、発行者が自分のアプリケーションのマルチチェーンエコシステム全体で一貫したトークンの振る舞いを維持する能力を妨げることができます。このような問題は、開発者にとってクロスチェーンの拡張を悪夢にする可能性があり、複数のチェーン上でアプリが存在する夢を実現する障害となります。

サポートされているチェーンは限られています

トークン発行者は、選択したブリッジプロバイダーのネットワークカバレッジと拡張計画に依存することになります。もしブリッジプロバイダーがトークン発行者が拡大したい特定のブロックチェーンネットワークをサポートしていない場合、トークン発行者は2つの劣等な選択肢に直面します:

  • 希望するチェーンのサポートを追加するためにブリッジプロバイダーを待ちます。これには長い時間がかかる場合があり、統合の高コストのために実現しない可能性もあります(例:多くのDappsがそれに展開しないZKsync EraのEVM非同値)。
  • その特定のチェーンには異なるブリッジプロバイダーを使用し、これにより不可分性トークンと流動性の断片化の問題が再導入されます

この制限は、プロトコルの成長戦略と、新興チェーンの新規ユーザーにリーチする能力に大きな影響を与える可能性があります。ブリッジプロバイダーは、人気のあるチェーンのサポートを優先する一方で、トークン発行者にとって戦略的に重要な小規模または新しいネットワークを無視する場合があります。

クロスチェーントークンアドレスの整合性がありません

サードパーティーブリッジプロバイダーは、彼らのテックスタックの特異性により、各チェーンで異なるアドレスを持つブリッジトークンを展開する可能性があります。たとえば、[開心]サポートがない場合CREATE2. アドレスの一貫性の欠如は、多くのUXの問題を引き起こします:

  • セキュリティリスク:ユーザーは各チェーンで異なるトークンアドレスを確認する必要があり、詐欺トークンとのやり取りのリスクが増加します;
  • 統合の複雑さ:開発者は、各ネットワークの有効なトークンアドレスのリストを維持する必要があります;
  • フィッシングリスクの増加:一貫したアドレスのチェックがないため、悪意のある行為者は偽のトークンでユーザーを簡単に騙すことができます。

これらの欠点は、ベンダーロックインの問題や主権の喪失、ブリッジの失敗に対する高いリスクと組み合わさり、クロスチェーントークンの展開における典型的な第三者ブリッジへの依存の制限を強調しています。この理解は、ERC-7281のような代替ソリューションがこれらの課題に包括的な方法で対処するために必要とされる背景を示しています。

3. トークン発行者ブリッジを介してカノニカルトークンをマイントする

開発者がプロジェクトのトークンのクロスチェーン展開を最大限に制御したい場合は、リモートチェーン上のトークンの正規表現の発行を管理できます。これは「トークン発行者を信頼する」と表現され、トークンのすべてのブリッジ表現の価値は、ソースチェーン上のトークンのオリジナルバージョンの発行を担当するプロトコルによってトークンのホームチェーンにロックされたトークンに結び付けられます。

このアプローチを機能させるには、トークン発行者は、ブリッジドトークンのミントとバーンをクロスチェーンで管理するためのインフラストラクチャをセットアップする必要があります(同時に、カノニカルマッピングを介してグローバルな供給が同期するようにします)。

トークン作成者によって発行されたトークンの正規表現の注目すべき例は、次のとおりです。MakerDAOのテレポートそしてサークルのクロスチェーン転送プロトコル(CCTP). テレポートは、高速パスと低速パスの操作によって、ユーザーがEthereumとさまざまなEthereumロールアップ間で正規のDAIを移動することを可能にします。DAIは1つのチェーンで焼かれ、ターゲットチェーンで鋳造されます。CCTPも同様に機能し、サークルによって発行されたネイティブのUSDCをクロスチェーンで転送するための焼却および鋳造メカニズムを可能にします。どちらの場合も、トークンの発行者がトークンの正規表現の鋳造と焼却を制御します。

このアプローチでは、プロトコルのブリッジされたトークンを完全に制御できます。また、同じトークンの代替不可能な表現の問題を、可能な限り最も効果的な方法で解決します - トークンの正規バージョン(デスティネーションチェーンで発行者によって鋳造された)が1つだけ存在するため、ユーザーはトークン発行者がサポートするすべてのエコシステムでトークンを使用して同じエクスペリエンスを得ることができます。

このアプローチにより、アプリケーションも非公式の、ブリッジングされたプロトコルのトークンの流動性フラグメンテーションの排除から利益を得る。開発者は、正規のトークン発行元ブリッジにより、資本効率的でシームレスかつ安全なトークンのチェーン間移動が可能となり、より堅牢なクロスチェーンアプリケーション(例:クロスチェーンスワップやクロスチェーンレンディング)を構築することもできる。

ただし、正規のトークン発行者ブリッジの欠点は、このモデルが、トークンクロスチェーンのデプロイと、クロスチェーンのミントとバーンを実行するために必要なインフラストラクチャ(オラクル、キーパーなど)の維持のオーバーヘッドをカバーするのに十分な資本を持つプロジェクトでのみ実行可能であることです。これはまた、ブリッジされた資産のセキュリティとプロトコルのセキュリティモデルを緊密に結合するという、やや望ましくない効果ももたらします。

ブリッジされたプロトコルのトークンのバージョンとプロトコルのセキュリティとの間の関係は友好的です。なぜなら、正規表現をバックアップするネイティブトークンの安全性はすでにプロトコルのセキュリティに依存しているため、ユーザーや外部開発者が新しい信頼の前提を受け入れる必要はありません。これは特に、の場合に当てはまります。ステーブルコインブリッジCircleやMaker(現在はSky)のような発行者によって運営されており、ユーザーはすでにステーブルコインの発行者が法定通貨のためにステーブルコインの償還をカバーするのに十分な資産を持っていることを信頼しているため、ステーブルコインブリッジのセキュリティを信頼することは難しくありません。

しかし、それはまた、中央の障害点を表しています。トークン発行者のブリッジインフラストラクチャが侵害された場合、マルチチェーンエコシステム内で循環しているすべての正準表現の価値が危険にさらされます。これはまた、中央集権的なカストディアン(たとえば、USDCの場合のサークル)のみが、この正準ブリッジトークンの発行モデルを実装できることを意味します。

最終的な考え

このレポートに示されているように、クロスチェーン資産の代替可能性は、異なるチェーン間を移動する体験に影響を与えるロールアップ相互運用性の重要な部分です。リモートチェーンにブリッジされたときにトークンが代替可能である能力は、特定のユースケースがこの機能に依存しているため、開発者の体験にも影響を与えます。

インフレーブルなクロスチェーントークンの問題を解決するためにさまざまな解決策が提案されており、これには、ネイティブ(確立された)ブリッジを介してカノニカルなトークンを鋳造する、複数のチェーン上でカノニカルなトークンを鋳造するための専用のサードパーティブリッジを使用する、トークンの移動を容易にし、交換性を維持するためにプロトコル所有のブリッジを使用するなどが含まれます。

これらのアプローチは特定の問題を解決する一方で、全ての問題に対処することはできず、それらを使用してクロスチェーン資産の交換性を実現するには望ましくない妥協が必要です。より良いアプローチは見つけることができるのでしょうか?答えは「はい」です。

ERC-7281は、クロスチェーン資産の代替可能性に対する新しいアプローチであり、既存のアプローチに関連するトレードオフを軽減します。別名xERC-20, ERC-7281は、セキュリティ、主権、またはユーザーエクスペリエンスを犠牲にすることなく、プロトコルが複数のチェーン上で正準トークンを効率的に展開することを可能にします。

ERC-7281のユニークな設計により、複数の(ホワイトリストに登録された)ブリッジが、サポートされているすべてのチェーンでプロトコルのトークンの正規バージョンを鋳造することができ、プロトコル開発者はブリッジごとに鋳造制限を動的に調整することができます。この機能は、流動性の断片化、インセンティブの調整、UXの懸念、ブリッジのセキュリティリスク、(クロスチェーントークンの)カスタマイズ性など、マルチチェーンカノニカルトークンの歴史的な提案に関連する問題の多くを解決します。

『クロスチェーン資産の代替可能性』に関する2部作レポートの次であり最後の部分では、ERC-7281について詳しく説明し、xERC-20トークン標準が開発者とユーザーにどのように利益をもたらすかを探求します。ERC-7281を他のマルチチェーンカノニカルトークンの設計と比較し、xERC-20のマルチチェーンカノニカルトークンのアプローチを探求し、標準に基づいて構築するためのプロトコルと開発者の考慮事項を強調します。」

お楽しみに!

免責事項:

  1. この記事は、[2077研究]. すべての著作権は元の著者に帰属します [アレックス・フックそしてエマニュエル・アウォシカ].この転載に異議がある場合は、ゲートラーンチームが promptly で対処します。
  2. 免責事項:この記事に含まれる見解や意見は、著者個人のものであり、投資アドバイスを意味するものではありません。
  3. 記事の翻訳はゲートラーンチームによって他の言語に翻訳されます。特に言及されない限り、翻訳された記事のコピー、配布、または剽窃は禁止されています。

クロスチェーントークンを再び交換可能にする方法:パートI

上級1/3/2025, 7:29:44 AM
この2部作のレポートでは、ERC-7281について探求します。これは、クロスチェーントークンを同質化するための新しい提案です。パート1では、問題(ブリッジトークンの非同質性)を紹介し、現在の解決策を分析します。

紹介

モジュラーマキシは、ブロックチェーンの間をアリスのように飛び回るドメインとユーザーが100万以上存在し、最先端のテクノロジーや新しいアプリケーション、ステーキング/流動性提供の月の目標リターン、高いパフォーマンス、そして他のブロックチェーンでの超低トランザクション手数料を利用できるので、なぜ1つのチェーンに固執する必要がありますか?

しかし、ブロックチェーン間の移動は、アリスがワンダーランドを通るよりもはるかに複雑です。これは、現在のブロックチェーン間の相互運用性のアプローチに固有の制限(クロスチェーンブリッジなど)が主な原因です。特に、現在のクロスチェーンブリッジは、安全ではない(ブリッジハックで25億ドル以上が失われています)、遅い、高価、または機能が制限されているか、リストからのプロパティの組み合わせを表示します。

ブリッジング業界に悩まされている他の問題は、より微妙ですが、モジュラーマキシのマルチチェーンエコシステムの夢をユーザーや開発者に悪夢に変えるだけの十分な問題です。これの例として、異なるチェーンにクロスチェーンプロトコルを介してブリッジされたときに、交換可能なトークン(ERC-20など)が非交換可能になる方法があります。その結果、トークンは転送可能な資産としての特徴を損ないます。本記事では、ERC-7281: Sovereign-Bridged Tokensという、トークンの交換可能性を維持する解決策を探求します。

ERC-7281は、トークン発行者によって承認された複数のブリッジによるリモートドメイン上でERC-20トークンの正規表現の鋳造と燃焼を可能にするために、Ethereumでの代替標準であるERC-20を拡張しています。これにより、ERC-20トークンをクロスチェーン経由で異なるルート/ブリッジを介して送信しても、目的地でユーザーがトークンの交換可能なバージョンを受け取ることが保証されます(つまり、2つのトークンは1:1で交換可能です)。重要なことは、ERC-7281を採用するプロトコルは、ブリッジがブリッジトークンを制御する従来の状況と異なり、ブリッジトークンの制御を維持し、ブリッジの障害時に書き込み操作をレート制限できるということです。

理論上同一のERC-20トークンでも、異なるチェーン上での不同一性の例として、USDCを使用しましょう。Ethereum Layer 2 (L2)ネットワークアービトラム、ベース、オプティミズムなど、一般的なERC-20トークンをイーサリアムL1からこれらのチェーンに移動するために、正規のブリッジを使用するのが一般的です。L1 を発信する L2 トークンのこれらのバージョンは、一般に単に「ブリッジ [トークン名の挿入]」と呼ばれます。

USDCの場合、一般的なシンボルはUSDC.e、USDC.bなどです。時間の経過とともに、CircleはUSDCのデプロイをL2を含む他のチェーンに拡大し、USDCは正規のブリッジを介してすでに稼働しています。この2つのトークンは、同じエンティティによって鋳造され、同じ価格ですが、技術的に異なる、代替不可能なトークンであるため、「相互運用可能」ではありません - ネイティブUSDCはCircleのCCTPブリッジを介してブリッジすることができますが、ブリッジされたUSDCは正規ブリッジを介してのみL1にブリッジバックすることができます。

ERC-7281は、ERC-20の拡張を導入することで、トークンのデプロイヤーがそれに対する様々なブリッジソースを割り当て、パラメータ化できるように修正しています。上記の例では、CircleはユニバーサルUSDCトークンをすべてのL2に展開できます。ここで、正規のブリッジ(Circle Mint、Circle CCTP、その他の承認されたブリッジなど)がすべて、それぞれのロジックに従ってトークンを鋳造できる能力を割り当てられます。鋳造者がハッキングされるリスクを最小限に抑えるために、デプロイヤーは各鋳造者が特定の期間内にいくつのトークンを鋳造し、燃やすことができるかを制限できます。信頼性の高いブリッジ(正規のL2ブリッジなど)はより高い制限を持ち、中央集権的なコンセンサスを持つブリッジはより低い制限を持ちます。

ERC-7281は交換可能なクロスチェーントークンの創造を試みる最初の試みではありませんが、以前の提案に関連する問題(ベンダーロックイン、トークン発行者の主権の喪失、ブリッジトークンの流動性の起動コストの高さ、インフラのオーバーヘッド、およびブリッジの障害への露出の増加など)を解決します。

この2部構成のレポートでは、主権ブリッジドトークン標準を導入する理由と、ERC-7281(またはxERC-20とも呼ばれる)仕様の包括的な概要について検討します。また、ERC-7281の導入によるユーザー、開発者、インフラプロバイダー、およびEthereumエコシステムの他の関係者に対するポジティブな利点と潜在的な欠点についても議論します。

ブロックチェーンブリッジについての復習

非代替トークンの懸け橋の問題に入る前に、まず懸け橋のトークンが存在する理由を理解することが役立ちます。これには、懸け橋の運用と動機を理解する必要があります。なぜなら、懸け橋の運用者が懸け橋のトークンバージョンを作成する責任を負っているからです。

ブリッジは、ブロックチェーン間で情報を転送するための仕組みです。純粋な通貨情報以外にも、ブリッジはトークンレートや他のチェーン上のスマートコントラクトの状態など、任意の有用な情報を伝えることができます。ただし、アセット(トークン)を1つのチェーンから別のチェーンに転送することが、現在のブリッジを使用するユーザーの最も一般的な使用例です。

異なるクロスチェーン資産移転の手法は様々ですが、トークンブリッジングワークフローは通常、3つの高レベルパターンのいずれかに従います。

ロックしてミントするブリッジ

  • ユーザーは、トークンをそのネイティブまたは「ホーム」チェーン(最初に発行されたチェーン)から別のチェーンにブリッジしたいと希望しています。2つのブロックチェーンは相互運用可能ではありません。各チェーンは異なるアーキテクチャとプロトコルデザインを実装しているため、ユーザーはチェーンAのウォレットアドレスからチェーンBのウォレットアドレスに直接トークンを転送することができません。
  • 橋のオペレーターは、ユーザーが元のチェーンに預けたトークンをスマートコントラクトでエスクローし、ターゲットチェーンで展開されたトークンコントラクトを介してネイティブトークンの「ラップ」表現を作成します。
  • ユーザーが逆方向にブリッジを架けたい場合(宛先チェーン→元のチェーン)、彼らは宛先チェーンのブリッジにラップされたトークンを返し、このブリッジのロジックに従ってこれを検証し(例:ZKプルーフまたは外部クォーラム)、ホームチェーン上のエスクローから元のトークンを解放します。

ブリッジを燃やして作る

  • エスクローでトークンをロックする代わりに、このアプローチではトークンをソースチェーン上で焼却(破壊)します;
  • その後、ブリッジは目的のチェーンに等しい量を鋳造します;
  • 逆向きのトリップでは、新しいトークンがソースチェーン上で造幣される前に、ブリッジされたトークンが宛先チェーンで燃やされます;
  • これにより、クロスチェーンの転送が可能ながら、総トークン供給量を維持します。

アトミックスワップ

  • この方法は、直接、他の当事者と共にソースチェーン上の資産を宛先チェーン上の資産と交換します。
  • アトミックスワップは、同じ秘密値で相互に資金をロックし、それらをアンロックすることによって機能します。つまり、どちらかの側で秘密が明らかにされた場合、他の側でも明らかにすることができます。これにより、スワップはアトミック性の特性を持ちます。
  • アトミシティとは、スワップが完全に(両側で)完了するか、まったく完了しないことを意味し、詐欺や部分的/失敗した転送を防ぎます。

最初のアプローチ(ロックと鋳造)は現在最も一般的です。 ブリッジによって鋳造されたネイティブトークンとその対応するラップトークンとの間の価値の同等性は、ユーザーが資産をクロスチェーンで「転送」し、初めて発行されたチェーンとは異なるチェーンでトークンを使用できるようにします。

しかし、インテントベースのブリッジングなど、新しい設計が非常に人気を集めています。 「インテント」は、特定の手順を概説するのではなく、取引の望ましい結果を表現することをユーザーに可能にします(「100 USDCを100 DAIにスワップする」)。インテントは、特にペアリングされた場合に、人々にとってオンチェーンの体験を大幅に簡素化し、暗号通貨の使用を容易にするため、強力なUXの解除として登場しました。チェーンの抽象化ソリューション.

クロスチェーンの意図ユーザーがブリッジングの基盤の複雑さを気にすることなく、チェーン間でトークンを転送できるようにします。意図ベースのブリッジでは、ユーザーはソースチェーンに資金を預けて、宛先チェーンでの希望する結果(「意図」)を指定します。専門のオペレーターである「フィラー」または「ソルバー」は、要求されたトークンを宛先チェーンのユーザーに事前に送信することで、この意図を実現できます。その後、オペレーターは移転が行われたことを証明し、ソースチェーン上のロックされた資金を請求します。

一部の意図ベースのブリッジは、裏でロックアンドミントのメカニズムを活用しています。この場合、ブリッジはラップトークンをミントし、ユーザーの意図を満たしたフィラーに送信するか、フィラーが介入しなかった場合は直接ユーザーに送信します。意図ベースのブリッジは、ソルバーネットワークを介して効率の良い追加の層を提供しますが、それらは依然として従来のロックアンドミントブリッジと同じ原則に基づいています。

私たちは、従来のブリッジングまたは意図ベースのブリッジングを通じて作成された包装トークンそれぞれを、ブリッジのオペレーターからのIOUと考えることができます。このIOUは、エスクロー契約から基礎となるトークンの量を解放することを約束しています。これらの包装アセットの価値は、ブリッジオペレーターの(知覚される)ホルダーからの要求を処理する能力と直接的に相関しています。この要求は、トークンのホームチェーンにエスクローされたネイティブトークンを引き出すためのものです。

ソースチェーン上の基礎トークンをロックし、そのラップされた表現を宛先チェーン上で鋳造するために承認されたブリッジは、トークンの総供給量が一定であることを保証します。基礎トークンの1単位につき、対応するラップトークンの単位がちょうど1単位鋳造され、その逆も同様です。アプリケーションがラップトークンを交換媒体として受け入れるか、ラップされた資産を通貨として使用する場合、アプリケーションの開発者とユーザーは、ブリッジプロバイダーがラップトークンを裏付ける「実際の」資産を保護することを信頼しています。

なぜ橋が必要なのですか?

外部チェーン上で資産の合成バージョンで取引できる能力は、橋が資産の表現を作成することで可能になります。この機能は、クロスチェーンの相互運用性の利点を開発者やユーザーが活用できるようにし、それによりより多くの流動性へのアクセス、新しいユーザーへの露出、およびユーザーの柔軟性(異なるチェーンのお気に入りのアプリとの摩擦なく相互作用できる)などの利点があります。

実際にこれがどのように機能するのか、なぜ開発者とユーザーの両方にとって重要なのかをより良く理解するために、架空の分散型取引所であるBobDEXを使用した具体的な例を見てみましょう。この例では、ラップトークンがクロスチェーンの拡張を可能にする方法を示し、利点と発生する可能性のある問題を強調します。

BobDEXは、BobがEthereum上で作成した自動マーケットメーカー(AMM)の取引所であり、異なる資産間での信頼できるスワップを可能にします。BobDEXには、ガバナンストークンおよびLP報酬トークンとして機能するネイティブトークン$BOBがあります。後者の場合、BobDEXは流動性提供者(LP)にBOBトークンを発行し、プールに供給された資産をスワップするDEXユーザーが支払う手数料の一部を受け取る権利を与えます。

BobDEXの市場シェアは大幅に成長していますが、Ethereum L1の制限がさらなる成長を妨げています。例えば、高いガス料金や取引の遅延のために、一部のユーザーはEthereum上のBobDEXを使用したくないと考えています。同様に、他のユーザーはEthereum上でネイティブの$BOBトークンを保持せずに、$BOBトークンの価格に露出したいと考えています。

問題を解決するため、Bob は、低手数料で高スループットの Layer 2(L2)ロールアップである Arbitrum 上に BobDEX のバージョンを展開し、Arbitrum-Ethereum ブリッジを介して L2 上で BOB トークンのラップバージョン(wBOB)を展開します。Arbitrum 上の BobDEX は、LP 報酬とガバナンスにネイティブの BOB トークンの代わりに wBOB を使用する以外は、Ethereum 上の BobDEX と同じです。

アプリケーショントークン(wrapped BOBとネイティブBOB)の違いは、ユーザー(例:流動性提供者)がArbitrum上のBobDEXとやり取りする際には影響しません。wBOBトークンは、Arbitrum-Ethereumブリッジに保持されている実際のBOBトークンで裏付けられているため、wBOBトークン保有者はブリッジ契約とやり取りすることで、簡単にEthereum上のネイティブBOB ERC-20トークンと交換することができます。

ボブとユーザーにとってウィンウィンの状況です:

  1. Bobは、特にBobDEXで取引する際に低いガス料金と高速なトランザクション確認を望むユーザーを引き付けることができます
  2. LPは、Ethereumの高いガスコストと長い確認時間を扱うことなく、BobDEXに流動性を供給することで報酬を獲得することができます
  3. Hodlersは、BOBトークンの価格変動による利益を得るために、BOB ERC-20契約とのやり取りなしで市場でwBOBトークンを購入することができます。

ブリッジングの利点は、ブリッジトークンの流動性を活用した相互運用可能なイノベーションの向上や新たなユースケースの開拓にも及びます。たとえば、アリスは、アリトラム上でwBOBを担保として受け入れるレンディングプロトコルであるAliceLendを作成することで、wBOBの有用性を拡大し、新たな市場を生み出すことができます。貸出と借入

AliceLendに流動性を供給する貸し手は、ユーザーがローンを返済できない場合、AliceLendは自動的に担保として預けられたwBOBトークンをオークションにかけて貸し手に返済することが保証されています。この場合、清算されたwBOBの担保の買い手はBobDEXのLPの役割を引き受け、wBOBトークンが元のBOBトークンと1:1で交換できるという同じ保証を受けます。

クロスチェーンのブリッジングは、現在の形式で実現可能な解決策を提供しています。以前は孤立していたEthereum L2間の相互運用性そして、新しいアプリケーション(例:クロスチェーンレンディングやクロスチェーンDEX)の容易化を促進しています。しかし、ブリッジエコシステムは現在、さらなる成長を妨げる制約に直面しています。クロスチェーントークンの非代替性などの問題について、後述で詳しく調査します。

なぜブリッジトークンは代替不可能になるのですか?

以前に説明したロックアンドミントのブリッジングワークフローは紙上ではシンプルに見えますが、実際には正しく動作するために多くのエンジニアリングとメカニズム設計の努力が必要です。

最初の課題は、ブリッジされたトークンの包装バージョンが常に、ソースチェーンでロックされたネイティブトークンによってバックアップされていることを確認することです。攻撃者が、ソースチェーンにネイティブトークンを預けずに、リモートチェーンでトークンの表現を偽造すると、(詐欺的に偽造された)包装トークンをホームチェーン上のネイティブトークンと交換して、包装トークンを鋳造する前にブリッジ契約に預け入れた正当なユーザーが預金を引き出せなくなってしまう可能性があります。

2番目の課題は、ブリッジトークンの性質に由来する微妙なものであり、同じリモートチェーンでブリッジプロバイダーによって鋳造されたトークンの2つの表現は、1:1で他のトークンと交換することはできません。トークンをチェーン間で移動する際の問題に関連するこの側面を説明するために、異なるルートを介してブリッジされたトークンを交換しようとする2人のユーザーの例を別の例として使用することができます。

  • アリスは、カノニカルなアービトラムブリッジを介して、イーサリアムからアービトラムにUSDCをブリッジし、アービトラムで200 USDC.eを受け取ります。一方、ボブはAxelarを介してUSDCをアービトラムにブリッジし、アービトラムで200 axlUSDCを受け取ります。アリスとボブは、アリスが200 USDCをボブに送信し、ボブが400 USDCをイーサリアムに引き出すために(200 USDTと引き換えに)合意します。
  • BobはaxlUSDCを通じて400 USDCを引き出そうと試みますが、200 USDCしか受け取らず、ブリッジがBobに提供できるのは200 USDCだけだと説明するメッセージも一緒に受け取ります。Bobは混乱しています。ラップされたERC-20トークンは「交換可能」であり、誰もがどのアプリケーションでもERC-20トークンを1:1で交換できるようにする不整合を示すべきではありません。
  • ボブはクロスチェーンブリッジングについての厳しい教訓を学びました。「交換可能なERC-20トークン」ということは常に「このトークンを他のERC-20トークンと1:1でアプリケーション間で交換できる」という意味ではありません。ボブはアリスとの危険な取引を試みますが、アリスがトークンを返さない可能性があるため、壮観に失敗します。

スワップでラグドした後のボブ

BobとAliceが同じ基礎資産のラップト版を受け取った場合、なぜBobは400 USDCを引き出すことができないのでしょうか?異なるチェーンで発行されたトークンは互換性がないため、ネイティブチェーンで発行されたトークンの表現は、ユーザーがトークンのネイティブチェーンに戻る際に支払いを約束するブリッジからのIOUです(残高に応じて)。

すべての橋渡しトークンの価値は、それに関連する橋渡しプロバイダーによって保持されたホームチェーン上の預金と、宛先チェーン上での表現の発行に結び付けられています。Bobの橋渡しプロバイダーは、その預金からカバーできる金額であるため、Bobに200 USDCしか支払えません。Aliceの200 USDCは、決して預金を受け取らず、また、AliceにIOUを発行していないため、Bobの橋渡しプロバイダーを介して引き出すことはできません。Bobが残りのトークンにアクセスできるようになる前に、AliceはEthereum上のArbitrumからロックされたUSDCを引き出し、Bobの橋渡しプロバイダーを介して橋渡しする必要があります。

ボブとアリスのジレンマは、競合するブリッジプロバイダーによって鋳造された基礎資産の非代替表現が複数存在するドメイン間のブリッジングに問題があることを示しています。同じ資産の異なるERC-20表現のもう1つの問題は、それらを単一の流動性プールで取引することができないことです。

前の例を使用すると、チェーン上にaxlUSDCとUSDC.eがある場合、それらをETHと逆にスワップするためには、ETH/axlUSDCとETH/USDC.eの2つの流動性プールを展開する必要があります。これにより、トレーディングプールの流動性が本来よりも小さくなる「流動性の断片化」という問題が発生します。なぜなら、本質的に同じトレーディングペアに適した複数のプールが存在するためです。

解決策は、BobとAliceがソースチェーンのブリッジから引き出すことなくトークンを交換できるように、目的地チェーンで単一の「正規」バージョンのトークンが流通することです。チェーンごとに正規のトークンを持つことは、開発者にも利益をもたらします。ユーザーはトークン流動性に関する問題を解決する必要なく、エコシステム間を迅速に移動できます。

では、各チェーン上で使用および転送されることを期待しているトークンの正規バージョンを実装する方法はどのようになりますか?次のセクションでは、複数のチェーン上で正規トークンを作成するための人気のあるアプローチの一部について説明します。

異なるチェーン間での標準トークンの実装

1つのチェーンごとに正規のトークンを作成することは簡単ではなく、さまざまなトレードオフと利点を持つ複数のオプションが存在します。正規のトークンを作成する場合、特定のトークンの価値を裏付けるIOUsの存在について誰を信頼するかを考える必要があります。トークンの作成者であり、異なるチェーン間で使用および転送可能なトークンにしたい場合、可逆性の問題に直面せずに実現するためには4つのオプションがあります:

  1. カノニカルロールアップ/サイドチェーンブリッジを介してカノニカルトークンを発行する
  2. サードパーティのブリッジプロバイダーを介してカノニカルトークンを作成します
  3. トークン発行者ブリッジを介して正規のトークンを作成する
  4. アトミックスワップを使用した直接のマルチチェーン発行

最初の3つのオプションは、トークンのクロスチェーン移動を促進するために様々なブリッジング機構に依存しています。ただし、トークンの作成者として、サポートされている各チェーンでトークンをネイティブに発行することにより、ブリッジングを完全にバイパスすることも選択できます。このアプローチでは、ラップトークンやブリッジインフラストラクチャーに頼らずに、チェーンごとに別々だが調整されたトークンの展開を維持し、原子スワップによりチェーン間の信頼できる交換が可能になります。

ただし、この手法にはクロスチェーンでの流動性の維持とアトミックスワップの促進のための高度なインフラストラクチャが必要です。複数のネイティブデプロイメントを管理する複雑さは、歴史的には大規模なプロトコルと十分な技術リソースを持つプロトコルに限定されていました。

1. カノニカルロールアップ/サイドチェーンブリッジを介してカノニカルトークンを発行する

チェーンに正規の(祀られた)ブリッジがある場合、ネイティブチェーンからのブリッジを希望するユーザーのために、プロトコルのトークン表現を作成する権利を割り当てることができます。チェーンのカノニカルブリッジを介してルーティングされるトランザクション(入出金)は、通常、チェーンのバリデーターセットによって検証され、ホームチェーン上のデポジットが鋳造されたすべての表現を確実に裏付けるというより強力な保証を提供します。

カノニカルブリッジはトークンのカノニカル表現を生成していますが、他の表現はまだ存在しています。これは、カノニカルブリッジにはしばしばユーザーに最高の体験を提供することを妨げる制限があるためです。たとえば、Arbitrum/OptimismからEthereumにブリッジをかける場合、ロールアップのカノニカルブリッジを介して行うと、トランザクションは検証者によって検証され、場合によっては争われるため、7日間の遅延が発生します。詐欺証明, もし無効であれば、ロールアップの決済レイヤー(Ethereum)が取引バッチを決済する前に。

クイックな出口を希望するRollupユーザーは、保留中のRollup出口の所有権を引き継ぎ、ユーザーの希望するターゲットチェーンに前払い流動性を提供できる他のブリッジプロバイダーを使用する必要があります。このようなブリッジが従来のロックアンドミントモデルを使用する場合、異なるプロトコルによって発行されたトークンの複数のラップされた表現が生じ、先ほど説明した同じ問題に直面することになります。

独立した検証者セットを持つサイドチェーンは、引き出しがサイドチェーンのコンセンサスプロトコルが引き出しトランザクションを含むブロックを確認するときに実行されるため、レイテンシが低くなります。Polygon PoSブリッジは、サイドチェーンを異なるドメイン(EthereumロールアップやEthereumメインネットを含む)に接続する典型的なブリッジの例です。

注:元のPolygon PoSチェーンを指します。計画された有効なチェーンクロスチェーンとして利用されるであろう。Polygonは、外部のバリデータによってセキュリティが確保されたサイドチェーンから、Ethereumのコンセンサスによってセキュリティが確保されたバリディウムへの切り替えが完了すると、L2となります。

ただし、サイドチェーンブリッジもロールアップの正規ブリッジと同様の弱点を共有しています。ユーザーは接続されたチェーンのペア間でのみブリッジを行うことができます。正規ブリッジを使用して他のブロックチェーンにブリッジすることはできません。例えば、Arbitrumブリッジを使用して現在のArbitrumからOptimismへのブリッジを行うことはできませんし、Polygon PoSブリッジを介してPolygonからAvalancheへのブリッジを行うこともできません。

1.1. 流動性ブリッジを使用して正規のトークンを鋳造する

ロールアップのネイティブブリッジに頼ると、キャノニカルトークンの移動にはいくつかの問題があります。たとえば、流動性が低く、資産の移動に遅延が生じることがあります。プロトコルは、この問題を解決するために流動性ブリッジと連携し、スピーディな引き出しと低遅延のブリッジを実現しています。

このアレンジメントでは、承認された流動性ブリッジ(a)は、ソースチェーン上のプロトコルのトークンの包まれた表現を作成し、(b)プロトコル所有の流動性プールを介して、目的地での正規の表現に包まれたトークンを交換します。

宛先チェーン上のトークンの正規表現は通常、正規サイドチェーン/ロールアップブリッジによって鋳造されるバージョンですが、例外も存在します(後で見るように)。例えば、Optimism上のUSDTの正規バージョンはOptimism Bridgeによって鋳造されたopUSDTです。

各流動性ブリッジは、異なる流動性プールに預けられた資産のペア間でスワップを実行するための自動マーケットメーカー(AMM)を備えたDEXのように機能します。流動性提供を促進するために、AMMプールはプール契約に正規トークンをロックアップするホルダーにスワップ手数料の一部を共有します。

これはUniswapのモデルに似ています。唯一の目立つ違いは、アセットペアが通常、流動性ブリッジのトークンの正規表現に対するトークンの表現です。例えば、Hopを介してUSDTをOptimismにブリッジするユーザーは、huSDT:opUSDTプールを介してOptimism上でhUSDTと交換する必要があります。

流動性ブリッジを介したブリッジングのワークフローは次のようになります:

  • ソースチェーン上でネイティブトークンをロックします
  • ターゲットチェーン上のネイティブトークンのミントブリッジ表現
  • AMMプールを介して、ターゲットチェーン上でブリッジされた表現と正規表現をスワップする
  • ユーザーに正規のトークンを送信する

このプロセスは、すべての流動性ブリッジ(Across、Celer、Hop、Stargateなど)に対して同様です。ただし、通常はエンドユーザーからは抽象化されています - 特にソルバ/フィラーによって - そして多くの動くパーツが関与していても、単一のトランザクションのように感じられるでしょう。

ソースチェーンに戻る際、ユーザーは正規表現を燃やすか、正規トークンをブリッジ表現と交換し、それを燃やして証明書を提供します。確認されたら、ユーザーは最初にロックされたネイティブトークンを引き出すことができます(前の操作と同様に、トークンを元のチェーンに戻す詳細はユーザーから隠され、ソルバーによって管理されます)。

リキッドリティブリッジングは優れています、主にそれはロールアップブリッジングにおける遅延の問題を修正するからです。例えば、Hopは、特定のパーティーである「Bonders」として知られる専門家に、L2のユーザーの引き出し取引の妥当性を証明することを許可し、ロールアップのL1ブリッジからの引き出しのコストを先負わせます。それぞれのBonderはL2チェーンのフルノードを実行し、ユーザーの出口取引が最終的にL1で確認されるかどうかを決定し、ユーザーが不正な引き出しを開始し、Bonderに損失をもたらすリスクを減らします。

流動性ブリッジは、カノニカルブリッジとは異なり、ユーザーがより多くのチェーン間を移動することも可能にします。たとえば、Hopでは、ユーザーが最初にイーサリアムに引き出す必要なく、ArbitrumとOptimismの間をブリッジすることができます。高速なL2→L1ブリッジングと同様に、高速なL2→L2ブリッジングには、Bondersが送信元L2チェーンの引き出しを確認するためにフルノードを実行し、送信先L2チェーン上のユーザーのトークンの発行コストを先払いする必要があります。これにより、ロールアップ間のより多くの相互運用性が可能になり、ユーザーエクスペリエンスが大幅に向上します。ユーザーは問題なくロールアップ間でトークンを移動することができます。

しかし、流動性ブリッジングにはデメリットもあり、チェーンの橋を使用してL2/L1チェーン上でトークンの正規表現を作成する際の有用性に影響を与えます。

流動性ブリッジの欠点

1. スリッページ

スリッページとは、AMMとのやり取り時に予想されるトークンの量と受け取ったトークンの量の差です。スリッページは、AMMがプール内の現在の流動性に応じてスワップの価格を設定するために発生します。価格設定は、ユーザーが取引を開始してから取引が実行されるまでに変化する可能性があるため、スワップ完了後にペア内の各アセットのプールのバランスを維持するための均衡が保たれます。

ブリッジされた資産の流動性が低い場合、スリッページが増加することもあります。プールが十分な流動性を持っていない場合、大きな取引が価格を大きく変動させ、ユーザーが高い価格でスワップを実行する可能性があります。アービトラージャーは、同じ資産を取引するプール間の不均衡を修正するのに役立つことが期待されていますが、取引活動/価値の低いトークンを含むアービトラージトレードを行うことは避けられるかもしれません。

これは、スリッページが発生する境界ケースを考慮する必要があるため、クロスチェーンアプリケーションを開発する開発者にも影響を与えます。ユーザーは、1つまたは複数の宛先チェーンでトークンの量が減少するため、クロスチェーン操作を完了できない場合があります。

リッジアグリゲーターのようなアプリケーション(先行スリッページなしでスワップをカバーするための十分な流動性があるかどうかを知ることができない)は、最大スリッページ許容量を指定し、それをユーザーに提供される見積もりに通知することで問題を回避しています。これによりトランザクションのリバートを防ぎますが、ユーザーは常にリッジトークンの一部の割合を失います — ブリッジのAMMプールの流動性に関係なく。

2. 流動性制約

流動性ブリッジにおける基本的な課題は、宛先チェーン上で十分な流動性が必要なことです。トラディショナルなロック&ミントブリッジとは異なり、トークンのミントは直接ロックされた資産によって裏付けられるのではなく、流動性ブリッジはAMMプール内の利用可能なトークンに依存してクロスチェーンのトランスファーを完了します。流動性が臨界値を下回ると、ブリッジメカニズム全体が実質的に機能停止する可能性があります。

  • もし流動性が低すぎると、ブリッジ操作は完全に停止する可能性があり、ユーザーは意図した転送を完了できなくなることがあります;
  • ユーザーは、プールの流動性を枯渇させるのを避けるために、大きな送金を小さなトランザクションに分割することを強いられる可能性があります;
  • ボラティリティが高い時期や市場のストレスが高い時期には、流動性プロバイダーは、まさにブリッジ機能が最も必要とされるときに、プールから撤退することがあります。
  • 新しいトークンペアのブートストラップは特に困難であり、ブリッジを稼働させるためには重要な初期流動性が必要です。

流動性要件は循環依存関係を作り出します:ブリッジは信頼性を持って機能するために十分な流動性が必要ですが、流動性プロバイダを引き付けるには、一貫したブリッジの使用と手数料の生成を示す必要があります。この鶏と卵の問題は、特に新しいまたは取引頻度の低いトークンにとって深刻です。これらのトークンは複数のチェーン上で十分な流動性を維持するのに苦労するかもしれません。

3. ミスアライメントしたインセンティブ

流動性ブリッジは、ユーザーが過度なスリッページを被ることなく、目的地のチェーン上で標準的なトークンに対するブリッジされた表現からのスワップをカバーできる範囲で役立ちます。また、ブリッジとのやり取りにかかるガスコストも、ユーザーの視点から見た流動性ブリッジの価値を決定します。そのため、ブリッジアグリゲーターやトークンを発行するプロジェクトチームは、流動性と取引コストに基づいてブリッジを優先的に選択します。

これにより、プロジェクトのトークンをブリッジングしたり、ブリッジアグリゲーターを使用してクロスチェーンでトークンを送信したりするユーザーは、ユーザーエクスペリエンスが向上しますが、流動性に基づいてブリッジを選択すると、流動性プロバイダー(LP)のインセンティブを支出できないブリッジが不利になります。さらに、純粋な取引手数料に基づいてブリッジを選択すると、運用コストを削減するために中央集権的なアプローチを採用し、ブリッジ取引の手数料を低く設定できるブリッジが有利に競争することになります。いずれの場合も、ブリッジはおそらく最も重要な指標であるセキュリティについて競争していません。

流動性ベースのブリッジは、取引活動が低いロングテールアセットにも不利です(これにより、LPを引き寄せる可能性が低くなります)。ロングテールトークンの発行者(またはブリッジングボリュームが低い新しいトークン)は、発行者のトークンの正規の表現に対して(流動性ブリッジを介してブリッジされた)ネイティブトークンのスワップをカバーするために、AMMプールを設定し、流動性をブートストラップするか、ブリッジオペレータと協力して、LPがそのアセットに流動性を供給するための金融インセンティブを増やす必要があります。

4. ブリッジングUXが低い

流動性ブリッジは、カノニカルブリッジの改良版ですが、UXの問題もあります。クロスチェーンスワップでスリッページを受けるだけでなく、ユーザーは宛先チェーンで即座にブリッジングトランザクションを完了できない場合があります。なぜなら、ブリッジには宛先チェーンのカノニカルトークンとの取引をカバーするためのプール流動性が十分にない場合があるからです。ブリッジはユーザーのトークンスワップメッセージが宛先チェーンに到達する時点でどれだけのアセットペアの流動性が存在するかを知ることはできません。そのため、このエッジケースはほとんど避けられません。

この状況でユーザーは2つの選択肢があります(どちらも最適ではありません):

  • ブリッジに十分な流動性があるまで待って、スワップを完了し、正規のトークンを引き出してください。これは、ブリッジ取引で受ける遅延と、プールの流動性が非常に短期間で任意に変化するため、初めに引用されたトークンの量を受け取るかどうかをユーザーが知ることができないため、最適ではありません。
  • ブリッジの独自のトークン表現(例:Hop BridgeのhUSDT)を受け取ります。これはサブオプティマルです。ほとんどのアプリケーションは、ネイティブトークンの正式な表現(例:Optimism Bridgeによって作成されたopUSDT)と統合することを好むため、ユーザーのラップトークンは受け入れられない場合があります。

3. 正規のサードパーティーブリッジを介して正規トークンを発行する

マルチチェーンdappは、dappが展開されているすべてのチェーンでのトークンの正式な表現をミントするために、単一のブリッジを選択することにより、非交換可能なブリッジトークンの問題を回避できます。プロジェクトのトークンの承認された表現をミントする正式なブリッジと同様に、このアプローチでは、リモートチェーンでミントされたトークンをプロジェクトのホームチェーンに展開されたトークン契約にマッピングする必要があり、トークン供給がグローバルに同じであることを保証する必要があります。ブリッジプロバイダーは、トークンのミントとバーニングを追跡し、ホームチェーン上のトークン供給と同期してミントとバーニング操作が実行されるようにする必要があります。

単一のブリッジプロバイダーを使用すると、特に第三者のブリッジが最大1つのチェーンにのみ接続するのに対して、より広範囲のエコシステム間のブリッジをサポートするためにインセンティブを得ているため、プロジェクトチームにとって柔軟性が増します。アプリケーションが展開されているすべてのチェーンでブリッジが存在する場合、ユーザーはホームチェーンに戻す必要なく、クイックにクロスチェーンで移動できます。ブリッジプロバイダーは、ユーザーが宛先チェーンAでトークンを鋳造する前に、宛先チェーンAで鋳造されたトークンが燃やされることを確認するだけでよく、そして標準的なトークンは宛先チェーンB上で(再)マッピングされ、ホームチェーン上のトークンに変換されます。

非代替性ブリッジトークンの問題も解消されます。承認されたブリッジプロバイダーを介してブリッジを行う場合、常に他のブリッジトークンと1:1で交換できます。このアプローチは、流動性ベースのブリッジングの問題を正し、カノニカルブリッジモデルにおいてもっともらしいものにします。

  • ブリッジトランザクションでは、ブリッジプロバイダーはAMMを介して正規の表現に対して表現を変換する必要がないため、ユーザーはスリッページを受けません。ブリッジプロバイダーのトークンは、すべてのドメインでブリッジされたトークンの正規の表現です。これらの表現の価値は、ブリッジプロバイダーがトークンのネイティブチェーン上でロックされたトークンの価値にペッグされています。
  • ユーザーは、ブリッジングにほとんど遅延がないため、ブリッジプロバイダーは、mint()メッセージが到着した直後に、すぐに宛先チェーンでラップされた表現を作成できます。
  • 開発者は、AMM流動性のブートストラップや流動性供給インセンティブプログラムの心配をせずに、ブリッジオペレーターにマルチチェーントークンの展開の管理をアウトソーシングすることができます。

野生に存在する単一のブリッジプロバイダトークンの一部の例には、LayerZeroのOmnichain Fungible Token(OFT)、AxelarのInterchain Token Service(ITS)、CelerのxAsset、およびMultichainのanyAssetが含まれます。すべての例は基本的には独自のトークンであり、異なるブリッジプロバイダを介して送信された同じトークンの表現と互換性がありません。この微妙な詳細は、このブリッジトークンの処理方法に関連するいくつかの問題を強調しています。具体的には以下の点です。

  • ベンダーロックイン
  • 主権喪失
  • 橋の故障に高い露出
  • ターゲットチェーン上でのトークンのカスタム機能の喪失
  • ベンダーがサポートするチェーンに制限されていること
  • 全ての希望するチェーンで同じトークンアドレスを維持できないことは、ユーザーのセキュリティに損害を与えたり、フィッシング攻撃の標的にされる可能性を高めることがあります

正規の第三者ブリッジの利点

1. ベンダーロックイン

1つまたは複数のチェーン上で正式な表現を作成するために1つのブリッジプロバイダを選択することは、開発者がベンダーロックインのリスクにさらされることを意味します。各ブリッジプロバイダが独自の表現を作成し、そのインフラストラクチャ(および統合エコシステムプロジェクト)にのみ互換性があるため、単一のブリッジプロバイダモデルは、将来別のブリッジに切り替えるオプションなしにトークン発行者を特定のブリッジングサービスにロックします。

ブリッジプロバイダーを切り替えることは可能ですが、切り替えコストは高すぎて、ほとんどのプロジェクトがこのルートを選択するのをやめてしまいます。ざっくりした考えを示すと、ある開発者(ここではボブとします)がEthereum上でトークン(BobTokenと呼ぶことにします)を発行し、LayerZero OFTを選択して、Optimism、Arbitrum、BaseでBobTokenの正規バージョンを作成する場合を考えます。BobTokenの供給量は固定で、100万トークンで、LayerZeroを介してブリッジされたトークンはBobTokenの総供給量の50%を占めています。

ビジネス取引は順調に進んでいますが、ボブはユーザーがAxelarなどの競合するブリッジサービスを介してBobTokenをブリッジする方が良いと判断します。しかし、OFTトークンとITSトークンは互換性がないため、ボブは単に「私はAxelar ITSに切り替えて、BobTokenをOptimism、Base、およびArbitrumで正規表現化する」と言うことはできません。その結果、ボブは古いユーザーと新しいユーザーの両方にとって頭痛の種を作る可能性があります。2つのBobTokenは交換可能ではないため(前述の問題を再導入する可能性があります)。さらに、LayerZeroのバージョンのBobTokenと統合されたアプリケーションは、AxelarのバージョンのBobTokenを代替として受け入れることができません。これにより、BobTokenの流動性がBobTokenの競合する表現が共存するさまざまなチェーンで分断されます。

遷移を可能にするために、ボブは、LayerZero で鋳造された BobToken の包装された表現をユーザーに解除させ、ブリッジされた OFT トークンを燃やして Ethereum 上の BobToken をアンロックするトランザクションを送信する必要があります。ユーザーは、Axelar を使用して Ethereum 上でトークンをロックし、宛先チェーン上で正規の BobToken(Ethereum 上のトークン契約の供給にマッピングされたもの)を受け取ることで、新しい正規の BobToken の表現に切り替えることができます。これにはコストがかかり、DAO プロジェクト管理チームにとっては大規模な調整と運用のオーバーヘッドも発生するため、選択したプロバイダーに固執することが通常は最も安全なオプションです。

しかし、これにより、ベンダーロックインによって、契約条件を守ることができないブリッジプロバイダーが失敗した場合に切り替えることが不可能になり、開発者のボブのような開発者は問題のある状況に置かれます。また、ブリッジはほぼ無限のレバレッジを提供します。ブリッジプロバイダーは、ユーザーがBobTokensをブリッジする際に理由が明確でないままユーザーのブリッジ操作を制限する、ブリッジ手数料を引き上げる、さらにはブリッジ操作を検閲するなどの任意の操作を行うことができます。この場合、ボブは手を縛られており、不良なサードパーティのブリッジからの完全な切り替えは、ビジネス上の関係を維持することと同じくらい複雑です。

2. プロトコルの主権喪失

ベンダーロックインに関する前のセクションの最後の部分では、正規のサードパーティブリッジを使用する際の別の問題を強調しています:トークン発行者は、利便性とUXの向上と引き換えに、正規のブリッジトークンの制御をトレードオフしています。前の例を使用すると、イーサリアム上のBobTokenは、基礎となるERC-20トークンコントラクトを制御しているため、完全にボブの管理下にありますが、Optimism、Arbitrum、BaseのBobTokenは、これらのブロックチェーン上でBobTokenの正規表現を発行するOFTコントラクトを所有するLayerZeroによって制御されています。

Bob は LayerZero が標準表現をネイティブ トークンの元の設計に合わせることを期待しているかもしれませんが、常にそうであるとは限りません。最悪のシナリオでは、ブリッジプロバイダーが根本的に異なるバージョンのトークンコントラクトを実装しているため、イーサリアム上のBobTokenの動作がOptimism上のBobTokenの動作と大きく異なる可能性があり、プロトコルのユーザーに問題を引き起こします。この問題は、プロトコルとブリッジプロバイダーの目標と利益が異なるプリンシパルエージェントダイナミクスによっても悪化する可能性があります。

3. ブリッジの故障への高い露出

最初のアプローチでは、トークンが各チェーンの正規ブリッジを介してクロスチェーンにブリッジされ、1つのブリッジに影響を与えるエクスプロイトによるトークン発行者へのリスクは、そのブリッジに封じ込められます。例えば、ハッカーが1つの流動性ブリッジを侵害し、担保を預けることなく無限の量のラップドトークンを鋳造したとします。その場合、流動性プールでラップされた資産に利用可能な最大流動性までしか引き出すことができません(例:OptimismでcUSDTをミント→cUSDTを正規のopUSDTにスワップ→、イーサリアム上のネイティブUSDTと交換→ファストブリッジを介してopUSDTをイーサリアムに引き出します)。

サードパーティーの正準ブリッジモデルでは、パートナーブリッジに影響を与える悪用からトークン発行者へのリスクは、影響を受けるブリッジが展開されているリモートチェーン上で攻撃者が発行したトークンの総額と同等です。これは、すべてのチェーン上の正準表現が、他のチェーンで発行された正準トークンと1:1で交換可能であるため可能です。

chain Bのサードパーティブリッジを攻撃者が侵害し、1000トークンを発行する(トークンは最初にchain Aで発行される)が、担保を預けずに行った場合、攻撃者のchain B上のトークンはホームチェーン契約にマッピングされていないため、chain Aから引き出すことはできません。ただし、chain B上のトークンをchain Cにブリッジし、1000 chain Bトークンを1000 chain Cトークンと交換することができます。なぜなら、各クロスチェーントークンは同じブリッジサービスから発信されるため、互換性があり、代替可能です。chain Cトークンはホームチェーン契約にマッピングされており、chain A(トークンのホームチェーン)でトークンをロックしたユーザーによって正当に発行されたため、攻撃者はchain C上でトークンを燃やし、chain A上でネイティブトークンを引き出し、その後、CEXまたはフィアットオフランプを介してトークンを交換して行程を完了する可能性があります。

(ソース)

カスタムトークンの機能の喪失

正規のサードパーティ ブリッジを使用する場合、トークン発行者は、元のデプロイに存在するカスタム機能やトークンの動作を実装する機能を失うことがよくあります。これは、ブリッジプロバイダーが標準化されたERC-20実装コントラクトを使用する傾向があり、元のトークン実装に存在する特殊な機能をサポートしていないために発生します。

クロスチェーンを介したトークンのブリッジでは、通常、投票委任(ZK)、リベースメカニズム(stETH、USDM)、トランスファーキャパビリティ(memecoins)、ブラックリストおよびホワイトリスト機能(USDT、USDC)、一時停止可能なトランスファー、特殊なミンティングルールや権限などの一般的なトークン機能が剥奪されることがあります。これにより、トークンの動作に一貫性がなくなり、これらのカスタム機能に依存する統合が壊れる可能性があります。

ブリッジトークンの標準化は、ブリッジプロバイダーの視点からするとより簡単ですが、実質的にトークンの機能を制限し、発行者が自分のアプリケーションのマルチチェーンエコシステム全体で一貫したトークンの振る舞いを維持する能力を妨げることができます。このような問題は、開発者にとってクロスチェーンの拡張を悪夢にする可能性があり、複数のチェーン上でアプリが存在する夢を実現する障害となります。

サポートされているチェーンは限られています

トークン発行者は、選択したブリッジプロバイダーのネットワークカバレッジと拡張計画に依存することになります。もしブリッジプロバイダーがトークン発行者が拡大したい特定のブロックチェーンネットワークをサポートしていない場合、トークン発行者は2つの劣等な選択肢に直面します:

  • 希望するチェーンのサポートを追加するためにブリッジプロバイダーを待ちます。これには長い時間がかかる場合があり、統合の高コストのために実現しない可能性もあります(例:多くのDappsがそれに展開しないZKsync EraのEVM非同値)。
  • その特定のチェーンには異なるブリッジプロバイダーを使用し、これにより不可分性トークンと流動性の断片化の問題が再導入されます

この制限は、プロトコルの成長戦略と、新興チェーンの新規ユーザーにリーチする能力に大きな影響を与える可能性があります。ブリッジプロバイダーは、人気のあるチェーンのサポートを優先する一方で、トークン発行者にとって戦略的に重要な小規模または新しいネットワークを無視する場合があります。

クロスチェーントークンアドレスの整合性がありません

サードパーティーブリッジプロバイダーは、彼らのテックスタックの特異性により、各チェーンで異なるアドレスを持つブリッジトークンを展開する可能性があります。たとえば、[開心]サポートがない場合CREATE2. アドレスの一貫性の欠如は、多くのUXの問題を引き起こします:

  • セキュリティリスク:ユーザーは各チェーンで異なるトークンアドレスを確認する必要があり、詐欺トークンとのやり取りのリスクが増加します;
  • 統合の複雑さ:開発者は、各ネットワークの有効なトークンアドレスのリストを維持する必要があります;
  • フィッシングリスクの増加:一貫したアドレスのチェックがないため、悪意のある行為者は偽のトークンでユーザーを簡単に騙すことができます。

これらの欠点は、ベンダーロックインの問題や主権の喪失、ブリッジの失敗に対する高いリスクと組み合わさり、クロスチェーントークンの展開における典型的な第三者ブリッジへの依存の制限を強調しています。この理解は、ERC-7281のような代替ソリューションがこれらの課題に包括的な方法で対処するために必要とされる背景を示しています。

3. トークン発行者ブリッジを介してカノニカルトークンをマイントする

開発者がプロジェクトのトークンのクロスチェーン展開を最大限に制御したい場合は、リモートチェーン上のトークンの正規表現の発行を管理できます。これは「トークン発行者を信頼する」と表現され、トークンのすべてのブリッジ表現の価値は、ソースチェーン上のトークンのオリジナルバージョンの発行を担当するプロトコルによってトークンのホームチェーンにロックされたトークンに結び付けられます。

このアプローチを機能させるには、トークン発行者は、ブリッジドトークンのミントとバーンをクロスチェーンで管理するためのインフラストラクチャをセットアップする必要があります(同時に、カノニカルマッピングを介してグローバルな供給が同期するようにします)。

トークン作成者によって発行されたトークンの正規表現の注目すべき例は、次のとおりです。MakerDAOのテレポートそしてサークルのクロスチェーン転送プロトコル(CCTP). テレポートは、高速パスと低速パスの操作によって、ユーザーがEthereumとさまざまなEthereumロールアップ間で正規のDAIを移動することを可能にします。DAIは1つのチェーンで焼かれ、ターゲットチェーンで鋳造されます。CCTPも同様に機能し、サークルによって発行されたネイティブのUSDCをクロスチェーンで転送するための焼却および鋳造メカニズムを可能にします。どちらの場合も、トークンの発行者がトークンの正規表現の鋳造と焼却を制御します。

このアプローチでは、プロトコルのブリッジされたトークンを完全に制御できます。また、同じトークンの代替不可能な表現の問題を、可能な限り最も効果的な方法で解決します - トークンの正規バージョン(デスティネーションチェーンで発行者によって鋳造された)が1つだけ存在するため、ユーザーはトークン発行者がサポートするすべてのエコシステムでトークンを使用して同じエクスペリエンスを得ることができます。

このアプローチにより、アプリケーションも非公式の、ブリッジングされたプロトコルのトークンの流動性フラグメンテーションの排除から利益を得る。開発者は、正規のトークン発行元ブリッジにより、資本効率的でシームレスかつ安全なトークンのチェーン間移動が可能となり、より堅牢なクロスチェーンアプリケーション(例:クロスチェーンスワップやクロスチェーンレンディング)を構築することもできる。

ただし、正規のトークン発行者ブリッジの欠点は、このモデルが、トークンクロスチェーンのデプロイと、クロスチェーンのミントとバーンを実行するために必要なインフラストラクチャ(オラクル、キーパーなど)の維持のオーバーヘッドをカバーするのに十分な資本を持つプロジェクトでのみ実行可能であることです。これはまた、ブリッジされた資産のセキュリティとプロトコルのセキュリティモデルを緊密に結合するという、やや望ましくない効果ももたらします。

ブリッジされたプロトコルのトークンのバージョンとプロトコルのセキュリティとの間の関係は友好的です。なぜなら、正規表現をバックアップするネイティブトークンの安全性はすでにプロトコルのセキュリティに依存しているため、ユーザーや外部開発者が新しい信頼の前提を受け入れる必要はありません。これは特に、の場合に当てはまります。ステーブルコインブリッジCircleやMaker(現在はSky)のような発行者によって運営されており、ユーザーはすでにステーブルコインの発行者が法定通貨のためにステーブルコインの償還をカバーするのに十分な資産を持っていることを信頼しているため、ステーブルコインブリッジのセキュリティを信頼することは難しくありません。

しかし、それはまた、中央の障害点を表しています。トークン発行者のブリッジインフラストラクチャが侵害された場合、マルチチェーンエコシステム内で循環しているすべての正準表現の価値が危険にさらされます。これはまた、中央集権的なカストディアン(たとえば、USDCの場合のサークル)のみが、この正準ブリッジトークンの発行モデルを実装できることを意味します。

最終的な考え

このレポートに示されているように、クロスチェーン資産の代替可能性は、異なるチェーン間を移動する体験に影響を与えるロールアップ相互運用性の重要な部分です。リモートチェーンにブリッジされたときにトークンが代替可能である能力は、特定のユースケースがこの機能に依存しているため、開発者の体験にも影響を与えます。

インフレーブルなクロスチェーントークンの問題を解決するためにさまざまな解決策が提案されており、これには、ネイティブ(確立された)ブリッジを介してカノニカルなトークンを鋳造する、複数のチェーン上でカノニカルなトークンを鋳造するための専用のサードパーティブリッジを使用する、トークンの移動を容易にし、交換性を維持するためにプロトコル所有のブリッジを使用するなどが含まれます。

これらのアプローチは特定の問題を解決する一方で、全ての問題に対処することはできず、それらを使用してクロスチェーン資産の交換性を実現するには望ましくない妥協が必要です。より良いアプローチは見つけることができるのでしょうか?答えは「はい」です。

ERC-7281は、クロスチェーン資産の代替可能性に対する新しいアプローチであり、既存のアプローチに関連するトレードオフを軽減します。別名xERC-20, ERC-7281は、セキュリティ、主権、またはユーザーエクスペリエンスを犠牲にすることなく、プロトコルが複数のチェーン上で正準トークンを効率的に展開することを可能にします。

ERC-7281のユニークな設計により、複数の(ホワイトリストに登録された)ブリッジが、サポートされているすべてのチェーンでプロトコルのトークンの正規バージョンを鋳造することができ、プロトコル開発者はブリッジごとに鋳造制限を動的に調整することができます。この機能は、流動性の断片化、インセンティブの調整、UXの懸念、ブリッジのセキュリティリスク、(クロスチェーントークンの)カスタマイズ性など、マルチチェーンカノニカルトークンの歴史的な提案に関連する問題の多くを解決します。

『クロスチェーン資産の代替可能性』に関する2部作レポートの次であり最後の部分では、ERC-7281について詳しく説明し、xERC-20トークン標準が開発者とユーザーにどのように利益をもたらすかを探求します。ERC-7281を他のマルチチェーンカノニカルトークンの設計と比較し、xERC-20のマルチチェーンカノニカルトークンのアプローチを探求し、標準に基づいて構築するためのプロトコルと開発者の考慮事項を強調します。」

お楽しみに!

免責事項:

  1. この記事は、[2077研究]. すべての著作権は元の著者に帰属します [アレックス・フックそしてエマニュエル・アウォシカ].この転載に異議がある場合は、ゲートラーンチームが promptly で対処します。
  2. 免責事項:この記事に含まれる見解や意見は、著者個人のものであり、投資アドバイスを意味するものではありません。
  3. 記事の翻訳はゲートラーンチームによって他の言語に翻訳されます。特に言及されない限り、翻訳された記事のコピー、配布、または剽窃は禁止されています。
今すぐ始める
登録して、
$100
のボーナスを獲得しよう!
It seems that you are attempting to access our services from a Restricted Location where Gate is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Thailand, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.