著者: 2077 リサーチ

編集：グレンドン、テックブニュース

シリーズの第 1 部「クロスチェーン トークンを再び交換可能にする方法」をまだ読んでいない場合は、まずそれを読むことをお勧めします。クロスチェーン トークンの交換性が失われた根本的な原因と、それがもたらす体系的な課題が詳細に分析されています。パート2では、クロスチェーントークン転送メカニズムを再構築し、信頼性を高め、発行者にさらに洗練されたガバナンス権限を提供する革新的な標準ERC-7281に焦点を当てます。

前回の記事では、クロスチェーントークンの互換性の問題を解決し、非ネイティブチェーン上で流通するネイティブトークンの非標準バージョンによって引き起こされる流動性の断片化とユーザーエクスペリエンスの低下の問題を解決するためのさまざまな技術的なパスについて体系的に説明しました。

• 標準のロールアップ/サイドチェーン ブリッジ プロトコルを介してターゲット チェーン上に作成されたネイティブ トークンの標準バージョン。

• サードパーティのクロスチェーン サービスを利用して、ターゲット チェーン上のネイティブ トークンの標準バージョンを生成します。

• 対象チェーン上で標準的なクロスチェーントークンの鋳造を実現するために、トークン発行者が独自に運営する標準的なブリッジングサービス。

上記の解決策にはすべて長所と短所があります。したがって、ERC-7281（xERC-20とも呼ばれる）の設計哲学は、さまざまなソリューションの利点を統合して、クロスチェーントークンの展開を実現したいプロトコル向けに、より包括的で効率的かつスケーラブルなソリューションを構築し、セキュリティ、主権、ユーザーエクスペリエンスを確保しながら画期的なバランスを実現することです。

ERC-7281とは何ですか? ERC-7281: ソブリン クロスチェーン トークンは、さまざまなクロスチェーン プロトコルによって作成されたトークンと互換性があり、交換可能なトークンの標準バージョンを作成する提案です。この標準では、ERC-20 インターフェースを拡張することで、次のコア機能が導入されています。

• 標準 ERC-20 トークンの発行と破棄の機能。

• トークン保有者のガバナンス権：1. 指定されたクロスチェーンブリッジプロバイダーに、クロスチェーン転送中にトークンの鋳造/破壊操作を実行する権限を与える。 2. 承認されたクロスチェーン ブリッジ プロバイダーごとに動的な鋳造/破壊の制限を設定します (たとえば、集中型クロスチェーンにはより小さな制限を設定し、より安全なプロトコルにはより高い制限を設定します)。

ERC-7281 と ERC-20 トークン標準の微妙な技術的違いを考慮して、標準設定者はこれを「xERC-20」と名付けました。 ERC-20 トークン標準インフラストラクチャを体系的に理解したい読者は、OpenZeppelin が公開した技術ガイドを参照できます。

本質的には、各 ERC-20 トークン コントラクトは、標準インターフェイスを実装してグローバル トークン供給を管理し、アドレス保有を記録し、トークン承認管理、総循環クエリ、アドレス残高取得などの基本機能を備えています。

ERC-7281 トークン標準では、ERC-20 標準の上にオプションの「ロックボックス」契約モジュールが追加されます。ラッパー コントラクト (機能は WETH コントラクトに類似) として、Lockbox コントラクトは、一般的な鋳造および破壊メカニズムを通じて、従来の ERC-20 トークンを xERC-20 トークン バージョンに変換できます。この設計により、ERC-7281 は、破棄/鋳造インターフェースがなくアップグレードできない既存の ERC-20 トークン コントラクトとの下位互換性も実現します。

最初の部分の分析フレームワークによれば、ERC-7281 は、「トークン発行者の信頼 + (承認された) クロスチェーン ブリッジ プロバイダーの信頼」というクロスチェーン トークン鋳造パラダイムとして分類できます。主な利点は次のとおりです。

• クロスチェーンERC-7281トークンは発行者によって完全に管理されます（主権の移転を必要とするほとんどのクロスチェーントークンソリューションとは異なります）

• 発行者は、承認されたクロスチェーン ブリッジでセキュリティ インシデントが発生するリスクに依然として直面していますが、承認されたクロスチェーン ブリッジ プロバイダーを手動で選択して制限することでこれを管理できます。

このレポートで強調されている重要なブレークスルーは、トークン発行者が指定されたクロスチェーン ブリッジ プロバイダーの鋳造/破壊クォータを動的に調整し、クロスチェーン セキュリティ インシデントのリスク エクスポージャーを正確に調整できることです。さらに、ERC-7281 は複数のクロスチェーン ブリッジ プロバイダーのホワイトリスト メカニズムをサポートしており、異なるプロバイダーがチェーン全体で同じ標準トークンを発行できるため、発行者の単一プロバイダーへのパス依存性が効果的に低減されます。

これら 2 つの機能により、ERC-7281 は従来のアプローチを大幅に改善し、プロトコル トークンのクロスチェーン ブリッジングを容易にし、ユーザー、相互運用性インフラストラクチャ プロバイダー (特にアグリゲータ)、およびアプリケーション開発者にプラスの二次的効果をもたらします。以下の記事では、技術仕様の詳細を掘り下げ、ERC-7281 を実装することの潜在的な利点と欠点を体系的に評価します。

ERC-7281 の説明: ソブリン クロスチェーン トークン

ユーザートークンの発行と破棄の仕組み

ERC-7281 標準によれば、プロジェクトは「IXERC​​20 インターフェース」に準拠する新しい ERC20 互換トークン コントラクトを展開する必要があります。クロスチェーン ブリッジ プロバイダーは、ユーザーがソース チェーンに預けたトークンを破棄した後、ターゲット チェーンに同量のトークンを発行できます。鋳造プロセス中に、システムはトークンの数がブリッジの鋳造制限を超えているかどうかを確認します。検証に合格すると、トークンの総供給量とクロスチェーンブリッジの鋳造制限が更新されます。

既存の ERC-20 トークンについては、Lockbox ロジックを採用する必要があります。クロスチェーン ブリッジ プロバイダーは、ユーザーが預けた ERC-20 トークンをパッケージ化のために Lockbox コントラクトに転送し、xERC-20 トークンに変換します。その後、Lockbox はプロバイダーに同量の xERC-20 トークンを発行する権限を与えます。

ターゲット チェーン上のブリッジによって生成された xERC-20 トークンは、ソース チェーン上で「burn() 関数」を使用して破棄されます。このプロセスにより、破壊されるトークンの数がブリッジの破壊制限を超えないことが保証されます。ブリッジのトランスポート層は、破棄メッセージをターゲット チェーンに中継します。ターゲット チェーンのクロスチェーン ブリッジ コントラクトはメッセージを検証し、そのチェーン上のユーザー アドレスに同量の xERC-20 トークンを発行します。

逆に、トークンをソースチェーンに戻すには、クロスチェーンブリッジプロバイダーがターゲットチェーン上の xERC-20 トークンを破棄し、ユーザーのアドレスとトークン数量を提供します。破棄の受信は、トランスポート層によってソース チェーンに中継されます。破棄メッセージが検証されると、クロスチェーン ブリッジ プロバイダーは、ソース チェーン上のユーザーに対して xERC-20 トークンの鋳造および破棄操作を実行します。トークン コントラクトが破棄証明書を確認すると、ユーザーは元の ERC-20 トークンを取得できます。ソース チェーンの破壊操作により、トークンの総供給量とクロスチェーン ブリッジの破壊制限が同時に削減されます。

重要なのは、xERC-20 契約が資格情報の検証なしでの鋳造操作を技術的にサポートしていることです。この記事では標準的な検証プロセスについて説明していますが、トークン発行者は、クロスチェーン メッセージ検証を実装していないクロスチェーン ブリッジをホワイトリストに登録するか、新しい検証メカニズムを採用するかを選択できます。最終的な意思決定権は発行者のリスク許容度によって決まります。

トークンの発行と破棄のレート制限メカニズム

setBridgeLimits 関数は、トークン コントラクト所有者だけが呼び出すことができる保護された関数です。この関数を使用すると、ブリッジ コントラクトのアドレスを設定し、ブリッジがユーザーに対して発行できるトークンの最大数 (mintingLimit) と、ブリッジがバーンできるトークンの最大数 (burningLimit) を指定できます。所有者は制限を動的に調整して、クロスチェーン ブリッジ プロバイダーのセキュリティ体制の変化に柔軟に対応できます。例えば：

• クロスチェーンブリッジインフラストラクチャに脆弱性が見つかった場合、リスクの露出を制御するために mintingLimit を下げることができます。

• 逆に、クロスチェーンブリッジのセキュリティアップグレードが完了すると、発行限度額を増やすことができます。

xERC-20 標準には、トークンの処理が許可されているクロスチェーン ブリッジの破壊および鋳造制限をチェックする機能も含まれています。 「mintingMaxLimitOf」はクロスチェーンブリッジが発行できるトークンの最大数を返し、「burningMaxLimit」はクロスチェーンブリッジが指定された時間内に破棄できるトークンの最大数を返します。さらに、これらの関数は、クロスチェーン ブリッジが事前に設定された制限に達する前に破棄して発行できる残りのトークンの数を表示します。

この設計は、クロスチェーン ブリッジ アグリゲータにとって非常に重要です。クロスチェーン ブリッジがソース チェーン/ターゲット チェーンの破壊または鋳造制限に達すると、トランザクションの遅延や失敗が発生します。したがって、アグリゲータは、十分な利用可能なクォータを持ち、ターゲットのトランザクション量をサポートするクロスチェーン ブリッジにリクエストをルーティングする傾向があります。

レート制限パラメータ分析

xERC-20 トークン インターフェース標準で定義されている「ブリッジ」構造には、「burningParams」と「mintingParams」が含まれています (xERC-20 トークン レート制限機能のパラメーターは、ブリッジが定義済みの時間内にバーンおよびミントできるトークンの数を制御します)。 「maxLimit」はトークンの鋳造と破棄の最大限度を定義し、事前定義されたレート (ratePerSecond) で毎秒増加します。

ここで、混乱を招く可能性のある問題に対処したいと思います。「maxLimit」(破壊と鋳造の制限に設定) は、特定の時間範囲内での鋳造と破壊の操作に対する制限、つまり、事前に設定された時間枠内で事前定義されたしきい値に基づく鋳造と破壊のレート制限です。 「currentLimit」は、クロスチェーンブリッジが鋳造または破壊できる量を定義し、事前定義されたレートで増加します。対照的に、「maxLimit」は、クロスチェーンブリッジが 1 日に発行または破棄できるトークンの数を定義します。

バーニングおよびミントパラメータは、主にトークン所有者（およびクロスチェーンブリッジプロバイダー）に関係します。ただし、最大値と電流制限パラメータは、ユーザーとクロスチェーン ブリッジ プロバイダーの両方にとって重要な考慮事項です。たとえば、現在の制限により、ターゲット リンクで xERC-20 トークンを受信するときに、ユーザーが遅延を経験することなくクロスプロトコル ブリッジを安心して使用できる範囲に影響する可能性があります。

xERC-20 ロックボックス

初期の ERC-20 トークンでは、トークン供給量を増減する機能は指定されていませんでした (初期のトークン経済では、主に固定総供給モデルが採用されていました)。したがって、すべての ERC-20 トークンに鋳造および焼却機能が備わっているわけではありません。 ERC-7281 は、現在のほとんどのクロスチェーン ブリッジで好まれている鋳造および破棄のメカニズムを使用しているため、Lockbox を通じて ERC-20 トークンとの下位互換性を実現する必要があります。

元の標準（つまり、プロジェクトが IXERC​​20 インターフェイスを実装する新しいトークン コントラクトを展開する）では、クロスチェーン ブリッジ プロバイダーは、ソース チェーンでデポジットをロックした後、ターゲット チェーン上のユーザーのトークンを作成するために mint() を呼び出すだけで済みます。 Lockbox コントラクトは、WETH ラッパー コントラクトに基づいて設計されています。対応する ERC-20 トークンをロックボックスに預けるための deposit() 関数を実装し、リモート チェーン上のラップされたトークンを破棄した後、クロスチェーン ブリッジ プロバイダーが ERC-20 トークンのロックを解除するための withdraw() 関数を実装します。

この標準で強調されている最初の 2 つのエラー タイプ (「IXERC​​-20Lockbox_NotNative」と「IXERC​​-20Lockbox_Native」) は、ユーザーが間違ったロックボックス コントラクトにトークンを預けようとしたときに発生します。ロックボックスは、サポートするトークンの種類に応じて、ネイティブ (または非ネイティブ) になります。

ネイティブ ロックボックスには、バリデーターにガス料金を支払うために使用されるトークンであるネイティブ トークンが保持されます。 xERC-20 トークンにラップするためのネイティブ ロックボックスを持つトークンの典型的な例は ETH です。ETH を xERC-20 トークンにラップするには、ロックボックスの depositNative() 関数を呼び出して ETH を預け、ERC 7281 互換バージョンの ETH トークンを受け取る必要があります。

非ネイティブの Lockbox は、USDC、DAI、WETH、USDT などの ERC-20 トークンを保存できます。たとえば、USDC を xERC-20 トークンに発行するには、ユーザーは USDC をロックした後、Lockbox コントラクトで deposit() を呼び出す必要があります。 ETH で deposit() を呼び出すと、非ネイティブの Lockbox コントラクトは ERC-20 トークンのみをラップおよびアンラップできるため、それらの資金は永久にロックされます。さらに、ネイティブ Lockbox コントラクトは ERC-20 トークンではなくネイティブ トークンで動作するように設計されているため、ERC-20 トークンを使用して depositNative() を呼び出すと同様の結果が生成されます。

このように、標準の ERC-20 トークンを、ミント/バーニングをサポートする xERC-20 トークンにラップすることで、Lockbox は標準の重要な互換性レイヤーを提供します。ただし、他のクロスチェーンソリューションを xERC-20 に統合する場合など、Lockbox を使用してラップされたトークンを返すだけでは実現できない場合もあります。このため、プロジェクトではアダプタ コントラクトを実装する場合があります。

アダプタ契約

クロスチェーン プロトコルが xERC-20 トークンに固有の操作 (鋳造/破棄、イベント ログなど) を認識しない場合、アプリケーション層はアダプタ コントラクトを構築できます。これらのコントラクトは自動化されたラッパーおよびアンラッパーとして機能し、ERC-20 の承認 + 呼び出しの動作を、xERC-20 標準で要求されるより微妙な鋳造/燃焼スキームに効果的に変換します。

これは、多くのクロスチェーン プロトコル (Chainlink の CCIP など) が依然として従来の ERC-20 の動作に最適化されているため必要です。アダプタ コントラクトは、次のロジックを実装することで、この互換性のギャップを埋めることができます。ロックボックスにトークンを預けてソース チェーンに xERC-20 バージョンを生成し、ターゲット チェーンでメッセージを受信した後、終了メカニズムをトリガーして標準アセットに戻します。

このプロセスにより、ユーザーは、基盤となる xERC-20 でサポートされているパッケージング メカニズムの影響を受けることなく、最終的に一貫した標準トークンを受け取ることができます。そうすることで、アダプタによりプロトコルは xERC-20 以外の標準クロスチェーン ブリッジとシームレスに統合され、サポートされる相互運用可能なソリューションの範囲が広がります。

ERC-7281 を選ぶ理由ソブリンクロスチェーントークンの標準ケース

一般的に、ERC-7281 には 4 つの主要な目標があります。

1. 互換性: ネイティブ チェーンから別の (L1/L2) チェーンにトークンをブリッジするユーザーは、常にターゲット チェーン上のクロスチェーン トークンの標準バージョンを受け取る必要があります。前述の理由（流動性の断片化やトークンの構成性の低さなど）により、非ネイティブ チェーンで同じトークンの複数の非代替バージョンを流通させることは問題があります。 ERC-20 標準を作成するための当初のビジョンは、Ethereum 上のトークンがアプリケーションと Ethereum インフラストラクチャ間でシームレスに交換および相互運用可能であることを保証することでした。しかし、ロールアップ中心のスケーリング ロードマップを採用した後、アトミックな構成可能性の欠如が明らかになり、多くの異なるドメインの作成によってこれらの互換性プロパティが低下しました。 xERC-20 により、さまざまなクロスロールアップブリッジ間の流動性を統合したマルチロールアップトークン標準に集約できるようになり、Ethereum の本来のビジョンが復元されます。

2. セキュリティ: カウンターパーティリスクを軽減するために、トークン発行者は、クロスチェーンブリッジプロバイダーのセキュリティインフラストラクチャの評価に基づいて、独立して選択し、複数のプロバイダーに接続する権利を持つ必要があります。同時に、発行者は効果的なリスク分離メカニズムを確立する必要があります。ブリッジ サービス プロバイダーの一部がセキュリティ インシデントに遭遇した場合、単一の攻撃によってプロトコルの総ロック値 (TVL) が完全に崩壊するのを防ぐために、その影響の範囲を厳密に制限する必要があります。

3. 流動性依存性ゼロのクロスチェーン トークンのコールド スタート: プロトコル DAO は、マルチチェーン スケーリング プランの一環として、クロスチェーン トークンの流動性をブートストラップするために多大な (財務) リソースを費やすことを強制されるべきではありません。流動性ベースのクロスチェーンは、ユーザーエクスペリエンスに悪影響を及ぼすだけでなく、サポートされるチェーンの数が急増するにつれて、プロジェクト当事者による流動性提供インセンティブへの支出が実現不可能になる可能性があります。

4. トークン発行者の主権的管理: 発行者は、非ネイティブ チェーン上で発行されたプロトコル トークンの標準バージョンを引き続き管理する必要があります。非代替性クロスチェーントークンの問題を解決するには、トークンの制御（特に総供給量の制御、鋳造および破棄メカニズムの構成などの管理面）を放棄するコストを負うべきではありません。

次に、これらの目標を拡張して、ERC-7281 がプロトコルとコミュニティにどのようなメリットをもたらすかを理解します。

ERC-7281の利点

ユーザーエクスペリエンスの向上と流動性の断片化の排除

ERC-7281 はさまざまなパス依存性の問題を解決します。パス依存性は、チェーン固有（例：Ethereum から Arbitrum から Optimism への ETH は、Ethereum から Optimism から Arbitrum への ETH とは異なります）またはブリッジ固有（例：Celer 経由の Ethereum から Optimism への ETH は、Connext 経由の Ethereum から Optimism への ETH とは異なります）にすることができます。

パス依存性にはセキュリティ上の価値がありますが、クロスチェーンのユーザーエクスペリエンスと構成可能性に重大な損害を与えます。クロスチェーン DEX シナリオを例にとると、ユーザーが Optimism と Arbitrum の流動性プールに同時に資金を注入する必要がある場合、チェーン間の資産表現の違い (opETH と arbETH など) により自動操作は不可能になります。

ERC-7281 は xERC-20 トークンを導入することでこの問題を完全に排除します。 xERC-20 は、ユーザーがチェーンを通過する回数や使用するクロスチェーン ブリッジ プロバイダーに関係なく、代替可能です。例えば：

• ユーザーは、Arbitrum のラップされた USDT を Ethereum チェーンに引き出すことなく Optimism に転送できます。

• クロスチェーンブリッジプロバイダーは、Arbitrum チェーンの xERC-20 トークンを破棄した後、Optimism で同量のトークンを発行できます。

• ターゲット チェーン トークンの価値は常にロックボックス内のネイティブ資産準備金に固定され、1:1 の厳格な償還が維持されます。

注目すべきは、ERC-7281 は Circle CCTP (クロスチェーン転送プロトコル) と同様の標準トークン展開の利点を実現しますが、契約当事者がクロスチェーン資産を集中的に保管する必要がないことです。その中核となる価値観は次のとおりです。

• 流動性の集約: プロトコル トークンの標準バージョンを中心に統一された市場を形成し、DeFi アプリケーションの有用性を向上させます。

• 運用コストの削減: 同じ資産の異なるバージョンに対して断片化された市場が形成されるのを防ぎます。

トークン発行者の主権管理の強化

xERC-20 は、トークン発行者が特定のオプションを使用してトークンの標準バージョンにロックされる必要がなく、クロスチェーン展開におけるクロスチェーン トークンの設計と管理に対する制御を保持できるため、「ソブリン クロスチェーン トークン」と呼ばれます。 ERC-7281 は、「サードパーティのブリッジを通じて発行された標準トークン」と「トークン発行者が管理するブリッジを通じて発行された標準トークン」のハイブリッドであり、主権、ユーザー エクスペリエンス、分散化を組み合わせています。

ERC-7281 を使用してチェーン全体にトークンを展開するプロジェクトでは、ユーザー エクスペリエンスを損なう、同じネイティブ アセットの互換性のないラップされたバージョンの問題に遭遇することなく、複数のブリッジを介してネイティブ トークンの標準バージョンを作成できます。このようなプロジェクトは、xERC-20 トークン コントラクトとロックボックス (クロスチェーン ブリッジがユーザーのトークンをロック、鋳造、破棄するために使用する) がプロジェクトによって展開および制御されるため、ドメイン間の標準トークンの転送を管理する内部インフラストラクチャを実行するトークン発行者と同レベルのトークンのクロスチェーン展開に対する制御も保持します。

この過小評価されている機能は、有名なプロジェクトがメインチェーン上でネイティブ トークンを発行する場合、特に他のエコシステムのユーザーがさまざまな理由でトークンにアクセスしたいが、ネイティブ チェーン上で保持したくない場合に非常に役立ちます。

この場合、プロジェクトには、チェーン間のトークン間の 1:1 互換性を確保するためにチェーンごとに内部クロスチェーン インフラストラクチャを実行する能力や意欲がなく、また、プロトコルやコミュニティに必ずしも適合していない第三者にトークンの制御を引き渡すことも望んでいません。この状況は、クロスチェーンガバナンスを実装し、ネイティブチェーンでの投票をカウントしながらクロスチェーントークンで投票できるようにする場合に考慮する必要があります。クロスチェーン トークンを制御する一貫性のないクロスチェーン ブリッジ プロバイダーは、プロトコル ガバナンスのボトルネックになります。

上記の理由により、イールドファーミングプロトコルBeefyはxERC-20標準を採用しました。プロジェクトのクロスチェーン ブリッジ ドキュメントに記載されているように、ERC-7281 はプロジェクトにより多くのクロスチェーン トークン オプション (主要なクロスチェーン ブリッジ パートナーがハッキングされた後に必要になったもの) を提供し、クロスチェーン メカニズムの設計をより細かく制御できるようにします。 Beefy の場合、ERC-7281 のホワイトリスト機能により、プロトコルはさまざまなクロスチェーン パートナーを選択し、mooBIFI トークンをブリッジする際の速度、分散化、コスト、セキュリティを最適化するさまざまなオプションをユーザーに提供できます。

オープンな競争と安全を促進するためのインセンティブの再調整

流動性ベースのブリッジは通常、流動性インセンティブに資金を提供する財務能力を持つプロジェクトを優先します。トークン発行者は流動性プロバイダー (LP) インセンティブへの支出を抑え、優れたクロスチェーン ブリッジ ユーザー エクスペリエンスを提供したいと考えているため、流動性は標準の L1/L2 ブリッジを使用するプロトコルにとって最も重要な要素になります。これは、クロスチェーン ブリッジ アグリゲータによるクロスチェーン ブリッジ プロバイダーの選択にも適用され、新しいクロスチェーン サービス (安全なインフラストラクチャを備えたものであっても) が、より確立されたクロスチェーン プロトコルと競合することがより困難になると考えられます。

ERC-7281 は、クロスチェーン流動性の必要性を排除することでこの問題を解決します。非標準トークンを鋳造して標準トークンと交換するのではなく、あらゆる規模のブリッジが承認されて、ターゲット チェーン上でプロジェクトのトークンを鋳造できるようになります。トークン発行者がクロスチェーン障害のリスクを最小限に抑えることを目指すにつれて、流動性を優先するのではなく、クロスチェーンブリッジのセキュリティ設計に重点を置くプロトコルが増える可能性があります。

これにより、「最も流動性の高いブリッジが勝つ」のではなく、「最も安全なブリッジが勝つ」というケースになるため、オープンな競争が促進されます。このオープンな競争は、流動性/セキュリティ以外の機能（手数料、API/SDK、アプリ統合など）を競うクロスチェーンブリッジの形をとることがあります。これらの機能は主に開発チームの専門知識に依存するため、最初からアプリケーションに組み込むのが簡単です。対照的に、流動性とクロスチェーンボリュームは立ち上げがより困難であり、ビジネス開発、資金調達、業界とのつながり、マーケティングなどの要素の組み合わせが必要です。

トークン発行者にとってより優れたリスク管理を提供する

ERC-7281 は、トークンの鋳造と燃焼に対して設定可能なレート制限を導入し、非ネイティブ チェーン上で標準トークンを鋳造するサードパーティのクロスチェーン プロトコルを使用する際のリスク プロファイルを大幅に改善します。協力しているクロスチェーン ブリッジ プロバイダーがハッキングまたは侵入された場合、攻撃者が引き起こす可能性のある最大の損害は、損傷したブリッジの制限に等しくなります。トークン発行者がレート制限パラメータを慎重に選択すれば、単一のクロスチェーンブリッジに対する単独の攻撃がプロトコルの支払能力に与える影響は最小限に抑えられる可能性があります。

さらに、各クロスチェーン ブリッジのレート制限を構成すると、プロトコル DAO のリスク評価プロセスも改善されます。 ERC-7281 を採用すると、リスク評価がより動的になります。プロジェクトでは、適切なレート制限プロパティを選択するために、クロスチェーン ブリッジ プロバイダーに対してデューデリジェンスを実行する必要があります。ただし、リスク評価のタイムラインは短縮できます。複数のクロスチェーン ブリッジを分析して 1 つを選択するのに数か月を費やす代わりに、プロジェクト関係者は複数のクロスチェーン ブリッジ プロバイダーを選択し、セキュリティ評価に基づいて異なる発行制限を設定できます。トークン発行者は、セキュリティレビューを実施して、選択したクロスチェーンブリッジパートナーの発行制限を増やすか減らすか、またはクロスチェーンブリッジから発行権を撤回するか（たとえば、ハッキングや脆弱性の開示への対応として）を決定できます。

ERC-7281 は、クロスチェーン ブリッジ セキュリティ テクノロジを採用したいが、コミュニティによって実戦テストされ、厳密に検証されるまでテクノロジを完全に採用することに消極的なプロジェクトが直面する障壁 (つまり、イノベーターズ ジレンマ) も軽減します。クロスチェーンブリッジプロバイダーが、セキュリティ保証を大幅に向上させるとされる新しいインフラストラクチャを提案したとします。この場合、プロトコルは、ブリッジに制限付きの鋳造権を割り当て、提案されたシステム設計への信頼が高まるにつれてブリッジの鋳造制限を徐々に増やすことで、「試す」ことができます。

流動性に関する懸念を解消するのと同様に、鋳造権を割り当てる前にプロトコルがクロスチェーン ブリッジ技術スタックを 100% 信頼する必要性をなくすことで、新規参入者と既存のプレーヤーの間に平等な競争の場を作り出すことができます。トークン発行者は鋳造権を撤回して小規模なプロジェクトに再割り当てする柔軟性を持つようになり、後者はセキュリティと分散化に対する高いコミットメントを示すため、既存のプレーヤーはより優れたセキュリティ メソッドを反復するインセンティブを持ちます。

同時に、これにより、サードパーティのクロスチェーン ブリッジと連携するプロトコルが直面する別のリスク要因も排除されます。クロスチェーン ブリッジのセキュリティにおける脆弱性や問題が開示され発見される速度にもかかわらず、選択されたクロスチェーン ブリッジ プロバイダーは、トークン発行者が懲罰的措置を実施できない (たとえば、別のクロスチェーン ブリッジ プロバイダーにすばやく移行する) こと、およびそのような活動を実施することが非常に難しいことを認識しているため、セキュリティの革新を停止する可能性があります。

エコシステム間のコンポーザビリティの向上

流動性に基づくブリッジ価格設定が予測不可能なため、現在では、任意の数のチェーンを介してトークンをルーティングする必要がある複雑なアプリケーション ワークフローを構築することは困難です。たとえば、Ethereum → Linea → Base のブリッジ アグリゲータには 2 つのオプションがあります。

流動性に基づくクロスチェーン ブリッジの価格設定が予測不可能なため、現在、任意の数の Anthrouter トークンを通過する必要がある複雑なアプリケーション ワークフローを構築することは困難です。たとえば、Ethereum → Linea → Base からのクロスチェーン ブリッジ アグリゲータには、次の 2 つのオプションがあります。

• スリッページ許容パラメータを設定し、各チェーンでユーザーが受け取るトークンの最小数に基づいてクロスチェーン ルーティングの価格設定を実行します (クロスチェーン メッセージが各レイヤーに到達したときに利用可能な流動性の量によって異なります)。

• スリッページ許容パラメータは設定されておらず、1 つ以上のチェーンで受信されたトークンの量が予想量よりも少ない場合に、オンチェーン流動性 (DEX 経由など) を取得するためのロジックが作成されます。

対照的に、特定のトークンの鋳造を許可するクロスチェーンブリッジの mintingLimit と burningLimit をチェックすることで、ブリッジアグリゲータは、クロスチェーントランザクションの各ドメインにいくつのトークンが存在する必要があるかを事前に知ることができます。

確かに、トランザクションがブロードキャストされてからドメインに到着するまでの間に、クロスチェーン ブリッジが maxLimit に達する可能性があります。つまり、ユーザーはターゲット チェーンで標準トークンを受信できなくなります。しかし、ERC-7281 は次の理由からこの点に関しては依然として改善されています。

• トランザクションの進行中にクロスチェーン ブリッジ プロバイダーが mintingLimit に達した場合、クロスチェーン トランザクションは一時停止され、レート制限パラメータが調整された後に再試行されます。今日の流動性ブリッジとは異なり、ユーザーは標準トークンの独自にラップされたバージョンを受け取ることはありません。

• クロスチェーン ブリッジ アグリゲータは、クロスチェーン トランザクションがいつ実行されるか、および予想されるトークンの量について、より高い予測可能性を提供します。 mintingLimit と burningLimit は、ブロックを時間の尺度として使用するように設定されているため (レート制限パラメータのセクションに示されているように)、クロスチェーン ブリッジがトークンの鋳造と燃焼を再開するタイミングを計算するのは簡単です。対照的に、クロスチェーンブリッジの流動性がいつ増加するかを予測することは、「ロシアンルーレット」をプレイすることに等しい。

流動性の予測不可能な変化は、再試行されたクロスチェーン取引の価格設定も予測不可能にすることを意味します。クロスチェーン ブリッジ アグリゲータ (または別のアプリケーション) が、クロスチェーン ブリッジ流動性プール内のトークン ペアの現在の価格に基づいてクロスチェーン スワップを見積もるとします (この価格はプールの総流動性に基づいています)。しかし、プールの流動性が急激に低下したため、取引は実行できませんでした。トランザクションが中断され、後で再試行されると想定します。この場合、アプリ開発者は、以前の見積もりがまだ正確であるかどうか、または流動性がユーザーが最初に取引を送信したときと同じレベルに達するかどうかを知る方法がありません。

クロスチェーン xERC-20 トークンは流動性の変化の影響を受けないため、ユーザーはクロスチェーン取引がすぐに実行されなくてもスリッページが発生しないことを確信できます。

この改善された構成可能性の恩恵を受けるのは、クロスチェーン ブリッジ アグリゲータだけではありません。あらゆるクロスチェーン アプリケーションは、xERC-20 トークンの代替可能性を活用して、より魅力的なアプリケーションを作成できます。

ただし、パス依存性の問題により、現時点でこれを実現するのは容易ではありません。開発者が Ethereum から ETH にクロスチェーンし、Arbitrum DEX で貸付ポジションを開き、その利益を使って Optimism で NFT を購入し、その後 Ethereum にクロスチェーンしたいとします。このプロセスでは、ユーザーが独自のバージョンに簡単に交換できないため、開発者はこれらのチェーン上のクロスチェーン ブリッジ プロバイダーとの統合を確実に行う必要があります。しかし、プロジェクトが xERC-20 を採用し、クロスチェーン トークンが代替可能になると、状況は変わります。

このワークフローは、Circle CCTP を例に挙げると、上で説明したトークン発行者のクロスチェーン ブリッジに似ています。

Circle のクロスチェーン転送プロトコルにより、ユーザーはさまざまなチェーンのエコシステムに閉じ込められることなく、USDC トークンの統一された標準バージョンを持つことができます。すべてのクロスチェーン転送は、バーンおよびミントスキームを使用したプロトコルを通じて処理されます。

ただし、CCTP は集中型プロトコルであり、Circle のオペレーターのみが USDC トークンを破棄および発行する権限を有しますが、xERC-20 では、さまざまなセキュリティ メカニズムを備えた複数のエンティティがクロスチェーン転送を操作できるようにすることで、信頼リスクを排除できます。

ロールアップ中心のマルチチェーンの未来というイーサリアムのビジョンをサポートする

ERC-7281 は、Ethereum のロールアップ中心のロードマップを加速させる可能性もあり、既存の L2 チェーンの堅牢なセキュリティが不足している可能性のある新しい EVM L2 にトークンを展開する自信をプロジェクトに与えます。たとえば、フェーズ 0 ロールアップの標準ブリッジは、Ethereum L1 がブリッジのセキュリティを保証しないため、安全性が低くなります。トークン プロジェクトは、標準ブリッジに限定的な鋳造権を付与し、ロールアップがフェーズ 1 に入った後に鋳造制限を増やすことで、このようなチェーンに徐々に展開できます。

このプロセスは、L2 がステージ 2 (ロールアップの分散化とセキュリティの最高レベル) に到達するまで継続できます。このメカニズムにより、リスクを最小限に抑えながら、新しく起動されたチェーンにプロトコルを展開できます。これにより、新しい L2 がトークンの流動性とアプリケーションをブートストラップしやすくなり、ロールアップ設計の分野でプロジェクトがさらに革新することを奨励できるため、Ethereum エコシステムにメリットがもたらされます。

ERC-7281 実装の潜在的な欠点

DAOプロジェクト管理チームのコスト増加

ERC-7281 はプロトコルにとって非常に魅力的ですが、xERC-20 トークンの管理にかかる運用コストが膨大であるため、DAO は ERC-7281 の採用をためらう可能性があります。 DAO プロジェクト チームは、さまざまな展開にわたって xERC-20 トークンを管理するために、多大な運用オーバーヘッドを負担する必要があります。

Gerard Persoon は、「多数のチェーン上のクロスチェーン トークンの管理」の中で、ERC-20 から xERC-20 に移行した後にプロトコルが実行する必要がある 1 回限りのタスクと定期的なタスクの非網羅的なリストを提供しています。

提案されている解決策の 1 つは、DAO がクロスチェーン xERC-20 トークンの管理に関連するタスクの一部をサードパーティのサービスにアウトソーシングすることですが、これは単に人的資源のコストとサービスの雇用コストの間のトレードオフです。

以前は内部インフラストラクチャを使用してクロスチェーン トークンを管理していたプロトコルがあるとします (たとえば、チェーンごとに個別のトークン コントラクトを展開し、発行とバーンを制御するなど)。この文脈では、ERC-7281 は根本的な変更ではないようです。しかし、クロスチェーン ブリッジ開発チームにコア クロスチェーン インフラストラクチャの管理をアウトソーシングすることに慣れているプロジェクトでは、追加の作業負荷が懸念されるでしょう。

xERC-20 トークンの管理は、プロトコルとコミュニティ メンバーに無視できない追加管理コストを課すことになります。たとえば、クロスチェーン ブリッジの制限では、クロスチェーン ブリッジのセキュリティを積極的に監視および評価して、この情報に基づいて鋳造制限を調整する必要があります。また、クロスチェーン ブリッジの制限 (または鋳造権の取り消し/割り当て) に関する決定には、DAO 投票が必要になる場合があります (このような決定を頻繁に行う必要がある場合、DAO メンバーは投票疲れを感じる可能性があります)。

ただし、これを ERC-7281 の価値判断として見るべきではありません。各プロジェクトには、リスク プロファイル、長期目標、リソースが異なります。これらの要素が組み合わさって、ERC-7281 を採用することによる長期的なメリットが短期的および継続的なコストを上回るかどうかが決まります。

たとえば、小規模なプロジェクトでは、xERC-20 トークンの発行を管理するコストが高くなるため、Axelar の ITS (Inter-chain Token Service) や Wormhole の NTT (Native Token Transfer) などのマネージド マルチチェーン トークン クロスチェーン サービスを使用することを選択する場合があります。より成熟したプロジェクトでは、xERC-20 トークンの発行にかかる運用コストを管理するためのリソースがあり、クロスチェーン トークンの管理にかかる追加のオーバーヘッドに見合うだけの ERC-7281 による制御が実現できると判断する場合があります。

既存のトークンをxERC-20標準に移行することの難しさ

ミント/バーニングインターフェースを持たないプロジェクト、またはトークン契約をアップグレードして IERC20 を使用できず、ネイティブトークンの標準バージョンが非ネイティブチェーン上ですでに流通しているプロジェクトの場合、xERC-20 トークンへの移行は、トークン所有者、取引所 (DEX および CEX)、パートナーブリッジ、従来の ERC-20 トークンと統合するさまざまなアプリケーションを含む複雑な参加者ネットワークを伴う、長くて調整の厳しいプロセスです。この部分の作業が完了したとしても、移行プロセスを完了するには、プロトコルが ERC-20 を xERC-20 に解凍するコストを負担する必要があります。

ERC-7281 標準の説明で説明したように、ユーザー向けにラップされた xERC-20 を作成するには、既存のトークンをロックボックスにロックする必要があります。ただし、レガシー ERC-20 トークンの段階的な廃止はすぐに行われる可能性があり、新しい (レガシー) ERC-20 トークンの鋳造を凍結するタイムラインについてコミュニティとコミュニケーションをとる別の長期的なプロセスが必要になります。繰り返しになりますが、これはプロトコルの観点からは価値があるかもしれません。ただし、得られる利益は、プロトコルのトークンと互換性のある xERC20 のバージョンへのエコシステム全体の移行を調整するコストを正当化するのに十分ではない可能性もあります。

DAOガバナンスはよりリスクが高い

ERC-7281 を使用して複数のドメインで xERC-20 トークンを管理するには、プロトコルを監視する DAO による積極的なガバナンスが必要です。これには、鋳造制限、ロックボックス契約のアップグレード、トークンの鋳造またはバーンの一時停止などのパラメータの設定が含まれます。これらの決定は機密事項であり、非公開で行われた決定に対する責任を回避するために DAO によって管理される必要があります。

ERC-7281 は、サードパーティのクロスチェーン ブリッジではなく、プロトコルがこれらの決定を制御できるように設計されています。これは、DAO がすでにネイティブ チェーン上のトークンを管理しているために必要であり、この制御を求めるプロトコルやコミュニティにとって、他のチェーン上のトークンにガバナンスを拡張することは理にかなっています。ただし、一部のプロトコルでは、ガバナンスと安定性に関する懸念から、この追加の DAO 制御を望まない場合があります。

たとえば、Lido はガバナンスの問題に関する精査に直面しており、トークン管理に対する制御を強化すると、ガバナンスの乗っ取りのリスクが高まります。プロジェクトがすべての ERC-20 トークンを 1 つのロックボックスに統合し、DAO を通じて管理している場合、ガバナンス攻撃は広範囲にわたる影響を及ぼす可能性があります。攻撃者はロックボックスを制御し、発行制限のない悪意のあるクロスチェーンブリッジプロバイダーを導入し、他のチェーン上の xERC-20 トークンを無価値にする可能性があります。

この状況は、マルチチェーン脆弱性に似ています。マルチパーティコンピューティング (MPC) 署名インフラストラクチャの脆弱性により、ハッカーが、Ethereum および Dogecoin 上のネイティブ トークン (Fantom や Moonriver などの非ネイティブ チェーンで生成されたトークンをサポートするトークン) を保持する主要なマルチチェーン アドレスを侵害することができました。これにより、「ドミノ効果」が発生し、Ethereum および Dogecoin 上のマルチチェーン スマート コントラクトへの攻撃により、他のプロジェクトが損失を被りました。

最大限に分散化されたプロトコルと互換性がない

ERC-7281 は、トークンがトークン ガバナンスを備えたプロトコルまたは中央集権型エンティティ(Circle の USDC または CZKC ステーブルコインなど) によって発行される場合にのみ要件を満たします。ただし、プロトコルが最大限に分散化されていても正式なガバナンスが欠如している場合、その価値はほとんどありません。Liquity の LUSD ステーブルコインは、xERC-20 標準との互換性を持たせるのが難しいトークンの例です。

xERC-20 トークンでは、エンティティが鋳造および燃焼制限などの特定のパラメータを決定し、特定のクロスチェーン ブリッジ プロバイダーをホワイトリストに登録するかどうかなどの決定を行う必要があります。つまり、xERC-20 トークンの存在には継続的なガバナンスが必要です。プロトコルの主要コンポーネントを時間の経過とともに分散化することを目指すプロジェクト（DAO のトークン契約など）の場合、これが問題を引き起こし、分散化計画を複雑にする可能性があります。

コアコンポーネント（ロックボックス契約とクロスチェーンブリッジプロバイダー）の脆弱性はより大きなリスクをもたらす

パス依存性がどのように機能するか、また、チェーン A に影響を与える脆弱性がチェーン B に影響を与えないこと、またはチェーン A のブリッジ A の脆弱性がチェーン B のブリッジ B に影響を与えないことがなぜ保証されるかについては、すでに説明しました。ERC-7281 標準ではパス依存性が排除され、メリットがもたらされる一方で、セキュリティの面でトレードオフも生じます。

異なるクロスチェーン ブリッジ プロバイダーによって発行されたトークンはクロスチェーン間で交換可能であるため、クロスチェーン ブリッジで利用可能な最大流動性は、クロスチェーン ブリッジの脆弱性がトークン発行者に与える最大の影響を表すものではなくなります。 ERC-7281 標準の作成者は、トークン発行者が不正な鋳造損失を補填するために使用できる金額に基づいて、クロスチェーン ブリッジ プロバイダーのレート制限を設定することを提案しました。しかし、振り返ってみると、選択されたレート制限は過度に保守的であった可能性があります。

上限の高いクロスチェーンブリッジが攻撃された場合、その影響は甚大になり、同じトークンを発行する他のクロスチェーンブリッジのユーザーにまで影響が及ぶ可能性があります。したがって、プロトコルは、複数のクロスチェーンブリッジに鋳造権を分配することでリスクを軽減できます（クロスチェーンブリッジプロバイダーが鋳造できるトークンの数が他のクロスチェーンブリッジと比較して多すぎないようにする）。ただし、この方法でリスクを回避すると、各クロスチェーンブリッジで DAO チームが独立した評価を実施し、より多くのクロスチェーンブリッジと調整する必要があるため、効率が低下し、前述の管理コストが増加する可能性があります。

さらに、DAO によって管理されるロックボックス契約は、ガバナンス攻撃が発生した場合に悪影響をもたらす可能性もあります。安全な DAO ガバナンスがあっても、トークン メインチ​​ェーン上のネイティブ/非ネイティブ ロックボックス コントラクトのバグによって、同様に多くの問題が発生する可能性があります。対照的に、トレジャリー コントラクト (ブリッジ プロバイダーのロックボックス コントラクトに相当) は、対応するブリッジを介してブリッジされたトークンのみを保持するため、1 つのプロバイダーのトレジャリー コントラクトの脆弱性は、そのブリッジにトークンを預けたユーザーにのみ影響するため、この問題は軽減されます。

エコシステム統合のコスト

ERC-7281 標準によってもたらされる追加の管理作業は、プロジェクトの xERC-20 トークンを使用するアプリケーション開発者やサービス プロバイダーにも影響を与えます。クロスチェーン ブリッジ アグリゲータは、スパム トークンやスプーフィング攻撃などの問題を防ぐために、xERC-20 トークンとそれに対応するロックボックス コントラクト間のマッピング関係を追跡する必要があります。これらのマッピングのレジストリは役立つ可能性がありますが、集中化のリスクを招いたり、xERC-20 の採用者を脅威にさらしたりすることなく、そのようなレジストリを構築するのは困難です。

リスクは、攻撃者がトークン レジストリに悪意のある契約を追加し、ユーザーや開発者を騙してトークンを間違ったアドレスに送信する可能性があることから生じます。これにより、L2 ネットワークと L1 ネットワークの両方でトークンの盗難が発生する可能性があります。偽造トークンは、監査済みの標準トークンとは異なり、トークンが異常な動作をするなど、深刻な問題を引き起こす可能性があるため、取引所も同様の課題に直面しています。

要約する

ERC-7281 標準は、交換不可能なクロスチェーン トークンの問題に対する魅力的なソリューションを提供し、トークン クロスチェーン設計におけるユーザー エクスペリエンス、分散化、セキュリティ、柔軟性を向上させる機能を提供します。これらの機能の一部は、ロールアップ中心のロードマップの実現可能性に直接影響し、xERC-20 標準を Ethereum L2 エコシステムにとって重要なインフラストラクチャにします。

現在、Hyperlane、Omni、Sygma、Router Protocol、Everclear など、クロスチェーン ブリッジ分野の主要企業数社が ERC-7281 標準の採用を約束しており、この提案が幅広い注目を集めていることを示しています。すでにトークンのクロスチェーンメカ​​ニズムを備えている既存のトークン発行者（Circle など）の中にも、承認されていないトークンがユーザーや開発者にもたらす課題に対処するために、ERC-7281 標準に関心を示しているところがあります。 ERC-7281 標準の議論をフォローしている開発者や xERC-20 の統合を検討している開発者にとって、 Fellowship of Ethereum MagiciansとxERC-20 の Web サイト、およびxERC-20 Launchpad (xERC-20 トークンの集約的な作成、監視、管理のためのツール) が重要な情報源およびツールになることは言及する価値があります。