導入

モジュール式の格言によれば、暗号通貨の未来は、不思議の国をさまようアリスのように、相互接続された 100 万以上のドメインとブロックチェーン間を行き来するユーザーです。最先端の技術、斬新なアプリケーション、ステーキング/流動性提供による驚異的な利益、高いパフォーマンス、他のブロックチェーンの超低トランザクション手数料を利用できるのに、なぜ 1 つのチェーンに固執する必要があるのでしょうか。

しかし、ブロックチェーン間の移動は不思議の国のアリスの旅よりもはるかに複雑です。主な原因は、ブロックチェーンの相互運用性に対する現在のアプローチに固有の制限 (例: クロスチェーン ブリッジ) です。特に、現在のクロスチェーン ブリッジは、安全性が低い (ブリッジのハッキングで 25 億ドル以上が失われる)、速度が遅い、高価である、機能が制限されている、またはリストの特性が混在している、のいずれかです。

ブリッジング業界を悩ませている他の問題はより微妙ですが、それでも、モジュラー マキシのマルチチェーン エコシステムの夢をユーザーと開発者にとって悪夢に変えるには十分です。その一例は、代替可能なトークン (ERC-20 など) がさまざまなクロスチェーン プロトコルを介して異なるチェーンにブリッジされると代替不可能になり、譲渡可能な資産としての機能が損なわれることです。この記事では、トークンの元のコントラクトがどこに存在するかに関係なく、チェーン間でトークンの代替可能性を維持しようとするソリューション、ERC-7281: ソブリン ブリッジ トークンについて説明します。

ERC-7281 は、イーサリアムで代替可能なトークンを作成するための事実上の標準である ERC-20 を拡張し、トークン発行者が承認した複数のブリッジによってリモート ドメインで ERC-20 トークンの正規表現を鋳造および焼却できるようにします。これにより、トークンが異なるルート/ブリッジを介してクロスチェーンで送信された場合でも、ERC-20 トークンをブリッジするユーザーは、送信先でトークンの代替可能なバージョンを受け取ることができます (つまり、2 つのトークンを 1:1 で交換できます)。重要なのは、ERC-7281 を採用するプロトコルは、ブリッジされたトークンの制御を維持し (ブリッジがブリッジされたトークンを制御する現状とは異なり)、鋳造操作をレート制限して、ブリッジに障害が発生した場合のリスクを軽減できることです。

異なるチェーンにまたがる理論上は同一の ERC-20 トークン間の非代替性の例として、USDC を使用しましょう。Arbitrum、Base、Optimism などのEthereum レイヤー 2 (L2) ネットワークでは、一般的な ERC-20 トークンを Ethereum L1 からこれらのチェーンに移動するために、正規のブリッジを使用するのが一般的です。L1 から派生した L2 トークンのこれらのバージョンは、一般に単に「ブリッジされた [トークン名を挿入]」と呼ばれます。

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

ERC-7281 は、トークンのデプロイヤーがブリッジのさまざまなソースを割り当て、パラメーター化できる ERC-20 拡張機能を導入することで、この問題を修正しました。上記の例では、Circle はすべての L2 にユニバーサル USDC トークンをデプロイできます。この場合、正規のブリッジ (Circle Mint、Circle CCTP、その他の承認済みブリッジなど) はすべて、ロジックに従ってトークンをミントできるものとして割り当てられます。ミントがハッキングされるリスクを最小限に抑えるために、デプロイヤーは、特定の期間内に各ミントがミントしてバーンできるトークンの数を制限できます。正規の L2 ブリッジなどの信頼性の高いブリッジには高い制限があり、集中型コンセンサスを持つブリッジには低い制限があります。

ERC-7281 は代替可能なクロスチェーン トークンを作成する最初の試みではありませんが、ベンダー ロックイン、トークン発行者の主権の喪失、ブリッジ トークンの流動性のブートストラップにかかる高コスト、インフラストラクチャのオーバーヘッド、ブリッジ障害のリスクの増加など、以前の提案に関連する問題を修正します。

この 2 部構成のレポートでは、ソブリン ブリッジ トークン標準を導入する根拠を検証し、ERC-7281 (xERC-20 とも呼ばれる) 仕様の包括的な概要を示します。また、ユーザー、開発者、インフラストラクチャ プロバイダー、および Ethereum エコシステムの他の関係者にとっての ERC-7281 実装のプラスの利点と潜在的な欠点についても説明します。

ブロックチェーンブリッジの復習

代替不可能なブリッジ トークンの問題に取り組む前に、そもそもブリッジ トークンが存在する理由を理解しておくと役立ちます。そのためには、ブロックチェーン ブリッジの目的と運用を理解する必要があります。ブリッジ トークン バージョンの作成はブリッジ オペレーターが担当するからです。

ブリッジは、ブロックチェーン間で情報を転送するためのメカニズムです。純粋に金銭的な情報以外にも、ブリッジはトークン レートや他のチェーンのスマート コントラクトの状態など、あらゆる有用な情報を渡すことができます。ただし、現在ブリッジとやり取りするユーザーにとって最も一般的な使用例は、あるチェーンから別のチェーンに資産 (トークン) を転送することです。

クロスチェーン資産転送を容易にするアプローチはさまざまですが、トークン ブリッジング ワークフローは通常、次の 3 つの高レベル パターンのいずれかに従います。

橋をロックして鋳造する

• ユーザーは、トークンをネイティブ チェーンまたは「ホーム」チェーン (最初に発行されたチェーン) から別のチェーンにブリッジしたいと考えています。2 つのブロックチェーンは相互運用可能ではありません。各チェーンは異なるアーキテクチャとプロトコル設計を実装しているため、ユーザーはチェーン A のウォレット アドレスからチェーン B のウォレット アドレスにトークンを直接転送できません。

• ブリッジ オペレーターは、ユーザーが元のチェーンに預けたトークンをスマート コントラクトでエスクローし、ターゲット チェーンにデプロイされたトークン コントラクトを介してネイティブ トークンの「ラップされた」表現を作成します。

• ユーザーが逆方向（宛先チェーン → 元のチェーン）にブリッジする場合、ラップされたトークンを宛先チェーンのブリッジに返します。ブリッジはブリッジのロジック（ZK 証明や外部クォーラムなど）に従ってこれを検証し、元のトークンをホームチェーンのエスクローから解放します。

  
  

橋を燃やして鋳造する

• このアプローチでは、トークンをエスクローにロックする代わりに、ソース チェーン上のトークンをバーン (破棄) します。

• 次に、ブリッジは宛先チェーンに同等の金額を発行します。

• 逆方向のトリップでは、新しいトークンがソース チェーンで生成される前に、ブリッジされたトークンが宛先チェーンでバーンされます。

• これにより、クロスチェーン転送を可能にしながら、トークンの総供給量が維持されます。

  
  

アトミックスワップ

• このアプローチでは、ソース チェーン上の資産を別の当事者と宛先チェーン上の資産と直接交換します。
• アトミック スワップは、同じ秘密値を持つ資金を相互にロックしてロックを解除することで機能します。つまり、どちらかの側で秘密が明らかにされた場合、もう一方の側でも秘密が明らかにされる可能性があります。これにより、スワップにアトミック性という特性が与えられます。
• アトミック性とは、スワップが完全に完了するか（両側で）、まったく完了しないかのいずれかであり、不正行為や部分的/失敗した転送を防ぐことを意味します。

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

しかし、インテントベースのブリッジングなどの新しい設計がかなり人気になっています。「インテント」を使用すると、ユーザーは結果を達成するための具体的な手順を説明する代わりに、トランザクションの望ましい結果を表現できます（「100 USDC を 100 DAI に交換する」）。インテントは、特にチェーン抽象化ソリューションと組み合わせると、人々のオンチェーン エクスペリエンスを大幅に簡素化し、暗号通貨を使いやすくするため、強力な UX ロック解除として登場しました。

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

一部のインテント ベース ブリッジは、内部でロック アンド ミント メカニズムを活用しています。この場合、ブリッジはラップされたトークンをミントし、ユーザーのインテントを満たしたフィラーに送信するか、フィラーが介入しなかった場合は直接ユーザーに送信します。インテント ベース ブリッジはソルバー ネットワークを通じて効率性をさらに高めますが、基本的には従来のロック アンド ミント ブリッジと同じ原則に依存しています。

従来のブリッジングで作成されたか、意図ベースのブリッジングで作成されたかに関係なく、各ラップされたトークンは、ブリッジ オペレーターからの IOU として考えることができます。これは、基礎となるトークンの一定額をエスクロー コントラクトから解放することを約束するものです。これらのラップされた資産の価値は、トークンのホーム チェーンにエスクローされたネイティブ トークンを引き出すという保有者からの要求を処理するブリッジ オペレーターの (認識されている) 能力と直接相関しています。

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

なぜ橋が必要なのでしょうか?

資産の表現を作成するブリッジによって実現される、リモート チェーン上の資産の合成バージョンと取引する機能は強力な機能であり、開発者とユーザーは同様にクロスチェーン相互運用性のメリットを活用できます。これらのメリットには、より多くの流動性へのアクセス、新規ユーザーへの露出、ユーザーの柔軟性 (異なるチェーンのお気に入りのアプリと摩擦なくやり取りできる) などがあります。

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

BobDEX は、異なる資産間のトラストレスなスワップを可能にするために Bob が Ethereum 上に作成した自動マーケット メーカー (AMM) 取引所です。BobDEX にはネイティブ トークン $BOB があり、これはガバナンス トークンと LP 報酬トークンの両方の役割を果たします。後者の場合、BobDEX は流動性プロバイダー (LP) に BOB トークンを発行し、プールに流動性を提供するユーザーに、プールに預けられた資産をスワップする DEX ユーザーが支払う手数料の一定割合を受け取る権利を与えます。

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

この問題を解決するために、ボブは Arbitrum に BobDEX のバージョン (低料金、高スループットのレイヤー 2 (L2) ロールアップ) をデプロイし、Arbitrum-Ethereum ブリッジを介して L2 に BOB トークンのラップされたバージョン (wBOB) をデプロイします。Arbitrum 上の BobDEX は Ethereum 上の BobDEX と同じですが、LP 報酬とガバナンスにネイティブ BOB トークンではなく wBOB を使用します。

アプリケーション トークン (ラップされた BOB とネイティブ BOB) の違いは、Arbitrum で BobDEX とやり取りするユーザー (流動性プロバイダーなど) の観点からは違いはありません。wBOB トークンは Arbitrum-Ethereum ブリッジで保持されている実際の BOB トークンによって裏付けられているため、wBOB トークンの所有者はブリッジ コントラクトとやり取りすることで、Ethereum 上のネイティブ BOB ERC-20 トークンと簡単に交換できます。

この状況はボブとユーザーにとって双方にメリットがあります。

1. Bobは、BobDEXでの取引時に低いガス料金と迅速な取引確認を求めるユーザーを中心に、より多くのユーザーを引き付けることができます。

2. LPは、イーサリアムの高額なガスコストや長い承認時間を気にすることなく、BobDEXに流動性を供給することで報酬を得ることができます。

3. ホドラーは、イーサリアムのBOB ERC-20契約とやり取りすることなく、市場でwBOBトークンを購入してBOBトークンの価格変動から利益を得ることができます。

   
   

ブリッジングの利点は、構成可能なイノベーションの強化や、ブリッジされたトークンの流動性を活用する新しいユースケースの実現にも及びます。たとえば、アリスは、借り手から wBOB を担保として受け入れる AliceLend という貸付プロトコルを Arbitrum 上に作成し、wBOB の有用性を拡大して貸付と借入の新しい市場を創出することができます。

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

現在の形式のクロスチェーン ブリッジングは、(以前はサイロ化されていた) Ethereum L2 間の相互運用性を確保し、新しいアプリケーション (クロスチェーン レンディングやクロスチェーン DEX など) を促進する実用的なソリューションを提供してきました。しかし、ブリッジング エコシステムは現在、クロスチェーン トークンの非代替性など、さらなる成長を妨げる制限に直面しています。この問題については、後ほど詳しく説明します。

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

前述のロックとミントのブリッジング ワークフローは、紙の上では単純に見えますが、実際には正しく機能させるには多くのエンジニアリングとメカニズム設計の労力が必要です。

最初の課題は、ブリッジ トークンのラップされたバージョンが常にソース チェーンでロックされたネイティブ トークンによって裏付けられていることを保証することです。攻撃者がソース チェーンにネイティブ トークンを預けることなくリモート チェーンでトークンの表現を鋳造すると、（不正に鋳造された）ラップされたトークンをホーム チェーンのネイティブ トークンと交換し、ブリッジ コントラクトに預けてからラップされたトークンを鋳造した正当なユーザーが預金を引き出せないようにすることで、ブリッジを破産させることができます。

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

• アリスは、正規の Arbitrum ブリッジを介して、イーサリアムから Arbitrum に USDC をブリッジし、Arbitrum で 200 USDC.e を受け取ります。一方、ボブは Axelar を介して Arbitrum に USDC をブリッジし、Arbitrum で 200 axlUSDC を受け取ります。アリスとボブは、アリスがボブに 200 USDC を送金し (200 USDT と引き換え)、ボブがイーサリアムに 400 USDC を引き出せるようにするという契約を締結します。
• ボブは axlUSDC 経由で 400 USDC を引き出そうとしましたが、ブリッジがボブに提供できる USDC は 200 USDC しかないことを説明するメッセージとともに、200 USDC しか受け取れませんでした。ラップされた ERC-20 トークンは「代替可能」であるはずであり、どのアプリケーションでも ERC-20 トークンを 1:1 で交換できないような差異は発生しないはずであるため、ボブは混乱しました。
• ボブはクロスチェーン ブリッジングについて厳しい教訓を学びます。「代替可能な ERC-20 トークン」は必ずしも「このトークンをアプリケーション間で他の ERC-20 トークンと 1:1 で交換できる」という意味ではありません。ボブはアリスと危険な取引をしようとしますが (アリスがトークンを返却しない可能性があるため危険です)、見事に失敗します。

ボブとアリスが宛先チェーンで同じ基礎資産のラップされたバージョンを受け取った場合、ボブはなぜ 400 USDC を引き出すことができないのでしょうか? 異なるチェーンで発行されたトークンは互換性がないことを述べたことを思い出してください。そのため、非ネイティブ チェーンで発行されたネイティブ トークンの表現は、ユーザーがトークンのネイティブ チェーンにブリッジバックしたい場合に、ネイティブ トークンの一定額 (残額によって異なります) を返済することを約束するブリッジからの IOU です。

したがって、ブリッジされたすべてのトークンの価値は、ホーム チェーンでのデポジットの保持とデスティネーション チェーンでの表現の鋳造を担当するブリッジ プロバイダーに結び付けられます。ボブのブリッジ プロバイダーは、デポジットからカバーできる資金が 200 USDC しかないため、ボブに支払うことができます。アリスの 200 USDC は、デポジットを受け取ったことも、アリスに IOU を発行したこともないため、ボブのブリッジ プロバイダーを通じて引き出すことはできません。アリスは、イーサリアムのアービトラムからロックされた USDC を引き出して、ボブのブリッジ プロバイダーを通じてブリッジしなければ、ボブは残りのトークンにアクセスできません。

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

前の例を使用すると、チェーン上に axlUSDC と USDC.e があり、それらを ETH に交換したり、その逆を行ったりする場合、2 つの流動性プール (ETH/axlUSDC と ETH/USDC.e) を展開する必要があります。これにより、いわゆる「流動性断片化」問題が発生します。これは、本質的に同じ取引ペアに適したプールが複数あるため、取引プールの流動性が本来よりも小さくなる状況です。

解決策は、宛先チェーンで流通するトークンの単一の「正規」バージョンを用意することです。これにより、ボブとアリスは、ソースチェーンのブリッジから各人が撤退することなくトークンを交換できます。チェーンごとに正規トークンを用意すると、トークンの流動性に関する問題に対処せずに、ユーザーがエコシステム間をすばやく移動できるため、開発者にもメリットがあります。

では、各チェーンで使用され、チェーン間で転送されることが想定されるトークンの正規バージョンを実装するにはどうすればよいでしょうか。次のセクションでは、複数のチェーンで正規トークンを作成するための一般的なアプローチのいくつかについて説明します。

異なるチェーン間での正規トークンの実装

チェーンごとに正規のトークンを作成するのは簡単ではなく、さまざまなトレードオフと利点を持つ複数のオプションが存在します。チェーンごとに正規のトークンを作成するときは通常、特定のトークンの価値を裏付ける IOU の存在について誰を信頼するかを考える必要があります。

あなたがトークンの作成者であり、代替性に関する問題に遭遇することなく、トークンを異なるチェーン間で使用および転送できるようにしたい場合、次の 4 つのオプションがあります。

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

最初の 3 つのオプションは、さまざまなブリッジング メカニズムを利用して、チェーン間でのトークンの移動を容易にします。ただし、トークンの作成者は、サポートされている各チェーンでトークンをネイティブに発行することで、ブリッジングを完全に回避することもできます。このアプローチでは、ラップされたトークンやブリッジ インフラストラクチャに依存するのではなく、チェーン間で個別かつ調整されたトークンの展開を維持し、アトミック スワップによってチェーン間の信頼のない交換が可能になります。

ただし、このアプローチでは、チェーン全体の流動性を維持し、アトミックスワップを容易にするために高度なインフラストラクチャが必要です。複数のネイティブ展開を管理する複雑さにより、このアプローチは歴史的に、かなりの技術リソースを持つ大規模なプロトコルに限定されてきました。

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

チェーンに正規の（エンシュラインド）ブリッジがある場合は、ネイティブ チェーンからブリッジするユーザーに対して、プロトコルのトークンの表現を作成する権限を割り当てることができます。チェーンの正規のブリッジを介してルーティングされるトランザクション（入金と出金）は、通常、チェーンのバリデータ セットによって検証され、ホーム チェーンへの入金がすべての作成された表現を信頼できる形で裏付けるという強力な保証が提供されます。

正規ブリッジはトークンの正規表現を鋳造していますが、他の表現も存在します。これは、正規ブリッジにはユーザーに最高のエクスペリエンスを提供できない制限がしばしばあるために起こります。たとえば、ロールアップの正規ブリッジを介して Arbitrum/Optimism から Ethereum にブリッジすると、ロールアップの決済レイヤー (Ethereum - トランザクション バッチを決済する) がトランザクションを検証者によって検証し、無効な場合は詐欺証明によって異議を申し立てる必要があるため、7 日間の遅延が発生します。

より迅速な終了を望むロールアップ ユーザーは、保留中のロールアップ終了の所有権を引き受け、ユーザーが希望するターゲット チェーンに事前に流動性を提供できる他のブリッジ プロバイダーを使用する必要があります。このようなブリッジが従来のロック アンド ミント モデルを使用すると、異なるプロトコルによって発行されたトークンの複数のラップされた表現が作成され、前述の問題と同じ問題に直面します。

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

注: ここで言及しているのは、決済にイーサリアムを使用する予定のバリディウム チェーンではなく、元の Polygon PoS チェーンです。外部バリデーターによって保護されたサイドチェーンからイーサリアム コンセンサスによって保護されたバリディウムへの切り替えが完了すると、Polygon は 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 プール経由で hUSDT を Optimism にスワップする必要があります。

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

• ソースチェーン上のネイティブトークンをロックする
• ターゲットチェーン上のネイティブトークンのMintブリッジ表現
• AMM プールを介してターゲット チェーン上のブリッジ表現を正規表現と交換します。
• 正規トークンをユーザーに送信する

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

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

流動性ブリッジングは、主にロールアップ ブリッジングのレイテンシーの問題を解決するため、優れています。たとえば、Hop では、「Bonders」と呼ばれる専門の当事者が、L2 でのユーザーの引き出しトランザクションの有効性を証明し、ロールアップの L1 ブリッジからの引き出しコストを前払いすることができます。各 Bonder は L2 チェーンのフル ノードを実行し、ユーザーの終了トランザクションが最終的に L1 で確認されるかどうかを判断できるため、ユーザーが不正な引き出しを開始して Bonder に損失をもたらすリスクが軽減されます。

流動性ブリッジは、標準的なブリッジとは異なり、ユーザーがより多くのチェーン間を移動できるようにします。たとえば、Hop を使用すると、ユーザーは最初に Ethereum に引き出すことなく、Arbitrum と Optimism 間をブリッジできます。高速 L2→L1 ブリッジと同様に、高速 L2→L2 ブリッジでは、Bonders がソース L2 チェーンのフルノードを実行して引き出しを確認してから、宛先 L2 チェーンのユーザーのトークン発行コストを前払いする必要があります。これにより、ロールアップ間の構成性が高まり、ユーザーが問題なくロールアップ間でトークンを移動できるため、ユーザーエクスペリエンスが大幅に向上します。

しかし、流動性ブリッジングには、チェーンのエンシャリンド ブリッジを使用して L2/L1 チェーン上のトークンの正規表現を作成するという実用性に影響する欠点もあります。流動性ベースのブリッジングの欠点については、次のセクションで説明します。

流動性ブリッジの欠点

1. スリッページ

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

ブリッジ資産の流動性が低いと、スリッページも増加する可能性があります。プールの一方の側を再調整するのに十分な流動性がプールにない場合、大規模な取引によって価格が大きく変動し、ユーザーがより高い価格でスワップを実行する可能性があります。裁定取引業者は、同じ資産を取引するプール間の格差を是正するのに役立つことが期待されていますが、取引アクティビティ/価値が低いトークンを含む裁定取引は控えられる可能性があります。

これは、スリップが発生するエッジケースを考慮する必要があるクロスチェーン アプリケーションを構築する開発者にも影響します。ユーザーは、1 つ以上の宛先チェーンでトークンの受信量が少ないため、クロスチェーン操作を完了できません。

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

2. 流動性制約

流動性ブリッジの基本的な課題は、宛先チェーンに十分な流動性が絶対的に必要であることです。トークンの鋳造がロックされた資産によって直接裏付けられる従来のロックアンドミントブリッジとは異なり、流動性ブリッジはクロスチェーン転送を完了するために AMM プール内の利用可能なトークンに依存します。流動性が臨界しきい値を下回ると、ブリッジメカニズム全体が事実上機能しなくなる可能性があります。

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

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

3. インセンティブの不一致

流動性ブリッジは、ユーザーが過度のスリッページを被ることなく、ブリッジされた表現から宛先チェーン上の標準トークンへのスワップをカバーできる範囲で役立ちます。ブリッジとのやり取りのガスコストも、ユーザーの観点から流動性ブリッジの価値を決定します。したがって、トークンを発行するブリッジ アグリゲータとプロジェクト チームは、流動性の量とトランザクション コストに基づいてブリッジを優先順位付けします。

これにより、プロジェクトのトークンをブリッジするユーザーや、ブリッジ アグリゲータを使用してトークンをクロスチェーンで送信するユーザーの UX が向上しますが、流動性に基づいてブリッジを選択すると、流動性プロバイダー (LP) インセンティブに費やすことができないブリッジは不利になります。さらに、純粋な取引手数料に基づいてブリッジを選択すると、運用コストを削減するために集中型アプローチを採用し、ブリッジ取引に低い手数料を請求できるブリッジが有利になるように競争が偏ります。どちらの場合も、ブリッジはおそらく最も重要な基準であるセキュリティで競争しているわけではありません。

流動性ベースのブリッジは、取引活動が少ないロングテール資産にも不利です（LPを引き付ける可能性が低くなります）。ロングテールトークン（またはブリッジボリュームの少ない新しいトークン）の発行者は、AMMプールを設定して流動性をブートストラップし、ネイティブトークン（流動性ブリッジを介してブリッジ）を発行者のトークンの正規表現と交換するか、ブリッジオペレーターと協力して、LPがその資産に流動性を供給するための金銭的インセンティブを高める必要があります。

4. ブリッジングUXが貧弱

流動性ブリッジは標準ブリッジの改良版ですが、UX の問題がないわけではありません。クロスチェーン スワップのスリップに耐えるだけでなく、ブリッジには宛先チェーン上の標準トークンとの取引をカバーするのに十分なプール流動性がないため、ユーザーは宛先チェーンでブリッジ トランザクションをすぐに完了できない可能性があります。ブリッジは、ユーザーのトークン交換メッセージが宛先チェーンに到達するまでに資産ペアの流動性がどれだけ存在するかを知ることができないため、このエッジ ケースはほとんど避けられません。

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

• ブリッジが十分な流動性を備えてスワップを完了し、正規トークンを引き出すまで待機します。ブリッジング トランザクションで遅延が発生するため、またプールの流動性が非常に短い期間で任意に変化する可能性があるため、ユーザーは最初に見積もったのと同じ量のトークンを受け取るかどうかわからないため、これは最適ではありません。
• ブリッジの独自のトークン表現（例：Hop Bridge の hUSDT）を受け取ります。ほとんどのアプリケーションはネイティブ トークンの標準表現（例：Optimism Bridge によって生成された opUSDT）との統合を優先し、ユーザーのラップされた資産を受け入れない可能性があるため、これは最適ではありません。

2. 正規のサードパーティブリッジを介して正規のトークンを鋳造する

マルチチェーン dapp は、単一のブリッジを選択して、dapp がデプロイされているすべてのチェーンで dapp のトークンの正規表現をミントすることで、非代替ブリッジ トークンの問題を回避できます。プロジェクトのトークンの承認済み表現をミントする正規ブリッジと同様に、このアプローチでは、リモート チェーンでミントされたトークンをプロジェクトのホーム チェーンにデプロイされたトークン コントラクトにマッピングする必要があります。これにより、トークンの供給がグローバルに同じままになります。ブリッジ プロバイダーは、トークンのミントとバーンを追跡し、ミントとバーンの操作がホーム チェーンのトークン供給と同期していることを確認する必要があります。

単一のブリッジ プロバイダーを使用すると、プロジェクト チームにさらなる柔軟性がもたらされます。特に、最大 1 つのチェーンにしか接続しない標準ブリッジと比較して、サードパーティ ブリッジはより広範なエコシステム間のブリッジをサポートするよう奨励されるためです。アプリケーションがデプロイされているすべてのチェーンにブリッジが存在する場合、ユーザーはホーム チェーンに戻って撤退する必要なく、チェーン間をすばやく移動できます。ブリッジ プロバイダーは、ユーザーが宛先チェーン B でトークンをミントする前に宛先チェーン A でミントされたトークンがバーンされ、チェーン B 上の標準トークンがホーム チェーンのトークンに (再) マップされるようにするだけで済みます。

代替不可能なブリッジトークンの問題も解消されます。ユーザーが承認されたブリッジプロバイダーを介してブリッジすれば、他のブリッジトークンと常に 1:1 で交換できます。このアプローチにより、標準的なブリッジモデルにおける流動性ベースのブリッジの問題がさらに解決されます。

• ブリッジ プロバイダーは AMM を介してその表現を正規表現に変換する必要がないため、ユーザーはブリッジ トランザクションでスリップに悩まされることはありません。ブリッジ プロバイダーのトークンは、すべてのドメインでブリッジされたトークンの正規表現です。これらの表現の値は、トークンのネイティブ チェーンでブリッジ プロバイダーによってロックされたトークンの値に固定されます。

• ブリッジ プロバイダーは、 mint() メッセージが宛先に到着するとすぐに宛先チェーン上でラップされた表現を作成できるため、ユーザーはブリッジングの遅延をほとんどまたはまったく経験しません。

• 開発者は、AMM 流動性のブートストラップや流動性提供インセンティブ プログラムを気にすることなく、マルチチェーン トークンの展開の管理をブリッジ オペレーターにアウトソーシングできます。

  
  

シングルブリッジプロバイダートークンの例として、LayerZero の Omnichain Fungible Token (OFT)、Axelar の Interchain Token Service (ITS)、Celer の xAsset、Multichain の anyAsset などがあります。これらの例はすべて本質的に独自のトークンであり、異なるブリッジプロバイダー経由で送信された同じトークンの表現とは互換性がありません。この微妙な詳細により、ブリッジされたトークンを処理するこのアプローチに関するいくつかの問題が浮き彫りになります。具体的には、次のとおりです。

• ベンダーロックイン
• 主権の喪失
• 橋梁の破損リスクが高い
• 対象チェーン上のトークンのカスタム機能が失われる
• ベンダーがサポートするチェーンに限定される
• すべての希望するチェーンで同じトークンアドレスを維持できないため、ユーザーのセキュリティが損なわれたり、フィッシング攻撃に対して脆弱になったりする可能性があります。

標準的なサードパーティブリッジを使用することの欠点

1. ベンダーロックイン

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

ブリッジプロバイダーを切り替えることは可能ですが、切り替えコストが高すぎるため、ほとんどのプロジェクトではこの方法を採用しません。大まかに説明すると、開発者 (ここでは Bob と呼びます) が Ethereum でトークン (BobToken) を発行し、Optimism、Arbitrum、Base で BobToken の標準バージョンを作成するために LayerZero OFT を選択したとします。BobToken には 1,000,000 トークンの固定供給量があり、LayerZero 経由で生成されたブリッジトークンは、流通している BobToken の総供給量の 50% を占めます。

ビジネス契約は、ボブが競合するブリッジ サービス (例: Axelar) を介して BobToken をブリッジする方がユーザーにとって有利であると判断するまで、順調に進みます。ただし、ボブは「Optimism、Base、および Arbitrum で BobToken の標準表現を作成するために Axelar ITS に切り替えます」と簡単に言うことはできません。OFT トークンと ITS トークンは互換性がないため、2 つの BobToken は代替可能ではない可能性があるため、ボブは古いユーザーと新しいユーザーの両方に頭痛の種を引き起こすリスクがあります (前述の問題が再び発生します)。さらに、LayerZero バージョンの BobToken と統合されたアプリケーションは、Axelar バージョンの BobToken を代替として受け入れることができず、競合する BobToken 表現が共存するさまざまなチェーンで BobToken の流動性が分散されます。

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

しかし、ベンダー ロックインにより、ブリッジ プロバイダーが契約条件を遵守できなかったり、機能スイートが限られていたり、広範なエコシステム統合が欠如していたり、UX が貧弱だったりする場合、切り替えが不可能になるため、ボブのような開発者は問題のある立場に置かれます。また、ブリッジにほぼ無限の影響力を与えます。ブリッジ プロバイダーは、明確な理由もなく BobToken をブリッジするユーザーのレート制限、ブリッジ料金の引き上げ、さらにはブリッジ操作の検閲など、恣意的な操作を行うことができます。この場合、ボブは手をこまねいている状態です。欠陥のある標準的なサードパーティ ブリッジから完全に切り離すことは、ビジネス関係を維持するのと同じくらい複雑だからです。

2. 議定書の主権の喪失

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

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

3. 橋梁の破損リスクが高い

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

サードパーティの正規ブリッジ モデルでは、パートナー ブリッジに影響を与えるエクスプロイトによるトークン発行者へのリスクは、影響を受けるブリッジが展開されているリモート チェーンで攻撃者が発行するトークンの合計量に相当します。これは、すべてのチェーン上のすべての正規表現を他のチェーンで発行された正規トークンと 1:1 で交換できるため可能です。

攻撃者がチェーン B のサードパーティ ブリッジを侵害し、担保を預けることなく 1000 トークン (トークンは当初チェーン A で発行されます) を鋳造したとします。チェーン B の攻撃者のトークンはホーム チェーン コントラクトにマッピングされていないため、チェーン A から引き出すことはできません。それでも、チェーン C にブリッジして、1000 チェーン B トークンを 1000 チェーン C トークンと交換することはできます。各クロスチェーン トークンは同じブリッジ サービスから生成されるため、互換性があり、代替可能であることに注意してください。チェーン C トークンは、チェーン A (トークンのホーム チェーン) でトークンをロックしたユーザーによって正当に鋳造されたため、ホーム チェーン コントラクトにマッピングされます。これにより、攻撃者はチェーン C でトークンをバーンし、チェーン A でネイティブ トークンを引き出し、CEX または法定通貨オフランプを介してトークンを交換することで、旅程を完了できる可能性があります。

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

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

投票委任 (ZK)、リベース メカニズム (stETH、USDM)、転送手数料機能 (ミームコイン)、ブラックリストおよびホワイトリスト機能 (USDT、USDC)、一時停止可能な転送、特別な鋳造ルールや権限などの一般的なトークン機能は、トークンがサードパーティ プロバイダーを介してブリッジされるときに削除されることがよくあります。これは、ブリッジされたバージョンでは通常、基本的な ERC-20 実装が使用されるためです。この機能の損失により、異なるチェーン間でのトークンの動作に不整合が生じ、これらのカスタム機能に依存する統合が壊れる可能性があります。

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

5. サポートされているチェーンが限られている

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

• ブリッジプロバイダーが目的のチェーンのサポートを追加するのを待ちます。これには長い時間がかかるか、統合コストが高いためにサポートが追加されない可能性があります (例: ZKsync Era の EVM 非同等性により、多くの dapps がデプロイされない)
• 特定のチェーンに別のブリッジプロバイダーを使用すると、代替不可能なトークンと流動性の断片化の問題が再び発生します。

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

6. クロスチェーントークンのトークンアドレスの不一致

サードパーティのブリッジプロバイダーは、テクノロジースタックの特殊性（たとえば、 CREATE2をサポートしていないなど）により、各チェーンに異なるアドレスを持つブリッジトークンを展開する場合があります。アドレスの一貫性が欠如すると、多くの UX 問題が発生します。

• セキュリティリスク: ユーザーは各チェーン上で異なるトークンアドレスを検証する必要があり、不正なトークンとやり取りするリスクが高まります。
• 統合の複雑さ: 開発者は各ネットワークの有効なトークン アドレスのリストを管理する必要があります。
• フィッシングリスクの増大: チェック対象となる一貫したアドレスがないため、悪意のある人物が偽のトークンでユーザーを騙すことが簡単になります。

これらの欠点は、ベンダー ロックイン、主権の喪失、ブリッジ障害のリスクの高さといった前述の問題と相まって、クロスチェーン トークンの展開に標準的なサードパーティ ブリッジに依存することの重大な限界を浮き彫りにします。これを理解することで、これらの課題をより包括的に解決するために ERC-7281 などの代替ソリューションが必要な理由を理解するのに役立ちます。

3. トークン発行者ブリッジを介して正規トークンを発行する

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

このアプローチが機能するには、トークン発行者が、ブリッジトークンのクロスチェーンでの鋳造と焼却を管理するためのインフラストラクチャを構築する必要があります（同時に、正規マッピングによってグローバル供給が同期されていることを確認します）。トークン作成者が発行するトークンの正規表現の注目すべき例としては、MakerDAO の Teleportと Circle のCross-Chain Transfer Protocol (CCTP)があります。

Teleport を使用すると、ユーザーは高速パスおよび低速パス操作を介して、Ethereum とさまざまな Ethereum ロールアップ間で正規の DAI を移動できます。DAI は 1 つのチェーンでバーンされ、ターゲット チェーンでミントされます。CCTP も同様に機能し、バーン アンド ミント メカニズムを介してネイティブ USDC (Circle によって発行) のクロスチェーン転送を可能にします。どちらの場合も、トークン発行者はトークンの正規表現のミントおよびバーンを制御します。

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

このアプローチにより、アプリケーションは、同じエコシステム内で流通しているプロトコルのトークンの非公式なブリッジ表現によって引き起こされる流動性の断片化を排除するメリットも得られます。また、標準的なトークン発行者ブリッジにより、チェーン間での資本効率が高く、シームレスで安全なトークンの移動が可能になるため、開発者はより堅牢なクロスチェーン アプリケーション (クロスチェーン スワップやクロスチェーン レンディングなど) を構築することもできます。

ただし、標準的なトークン発行者ブリッジの欠点は、このモデルが、トークン クロスチェーンの展開と、クロスチェーンの鋳造と焼却を実行するために必要なインフラストラクチャ (オラクル、キーパーなど) の維持にかかるオーバーヘッドをカバーするのに十分な資本を持つプロジェクトにのみ実行可能であることです。また、ブリッジされた資産のセキュリティとプロトコルのセキュリティ モデルが密接に結びつくという、やや望ましくない影響もあります。

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

しかし、これはまた、中心的な障害点でもあります。トークン発行者のブリッジ インフラストラクチャが侵害された場合、マルチチェーン エコシステムで流通しているすべての正規表現の価値が危険にさらされます。これは、中央管理人 (USDC の場合は Circle など) だけが、この正規ブリッジ トークン発行モデルを実装できることも意味します。

最後に

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

代替不可能なクロスチェーン トークンの問題を解決するために、さまざまなソリューションが提案されています。その多くは、このレポートで取り上げています。これには、ネイティブ (エンシュラインド) ブリッジを介して標準トークンを鋳造すること、専用のサードパーティ ブリッジを使用して複数のチェーンにまたがる標準トークンを鋳造すること、プロトコル所有のブリッジを使用してトークンの移動を容易にし、代替可能性を維持することが含まれます。

これらのアプローチは特定の問題を解決しますが、すべての問題に対処することはできません。また、クロスチェーン資産の代替性を実現するためにこれらのアプローチを使用すると、望ましくないトレードオフが発生します。より優れたアプローチを見つけることはできるでしょうか? 答えはイエスです。

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

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

クロスチェーン資産の代替可能性に関する 2 部構成のレポートの次の部分 (最終部分) では、ERC-7281 を詳細に取り上げ、xERC-20 トークン標準が開発者とユーザーにどのようなメリットをもたらすかを検討します。ERC-7281 を他のマルチチェーン標準トークンの設計と比較し、マルチチェーン標準トークンに対する xERC-20 のアプローチを検討し、標準に基づいて構築しようとしているプロトコルと開発者にとっての考慮事項を強調します。

乞うご期待！