クロスチェーントークンを再び交換可能にする方法シリーズのパートIをまだ読んでいない場合は、おそらく読む価値がありますチェックしてみてfirst—it breaks down why bridged tokens lose fungibility and the challenges this creates. In Part II, we explore ERC-7281, a new standard that streamlines クロスチェーン token transfers, enhances reliability, and gives issuers greater control.

より良いアプローチの必要性

これまで、ブリッジトークンの代替可能性の問題や、流動性の断片化、ネイティブトークンの非正規表現がネイティブでないブロックチェーン上で流通している際のユーザーエクスペリエンスの問題を解決するためのさまざまなソリューションを模索してきました。

• カノニカルロールアップ/サイドチェーンブリッジを介して、リモートチェーン上のトークンのカノニカル表現を作成します
• サードパーティーブリッジサービスを介して、リモートチェーン上でトークンの正規表現をミントする
• 発行元が運営するキャノンブリッジサービスを介して、リモートチェーン上のトークンの正規表現をミントします

これらのアプローチのそれぞれにはトレードオフがあります。そのため、ERC-7281の提案では、それぞれのアプローチから最良の部分を取り入れ、より包括的で効率的かつアクセスしやすいソリューションを作成しようとしています。これにより、セキュリティ、主権、ユーザーエクスペリエンスを犠牲にすることなく、クロスチェーンでトークンを展開したいプロトコルにとって、より良い方法が提供されます。

ERC-7281: ソブリンブリッジトークン多くの異なるブリッジによって打ち出された表現と互換性があり、交換可能なトークンの正準表現の作成を可能にする提案です。ERC-7281 は ERC-20 インターフェースを拡張して機能します:

• 正規のERC-20トークンを鋳造および燃焼するための機能。
• トークン所有者の能力

1) ブリッジオペレータを割り当てて、チェーン間でブリッジされたときにトークンを発行および破棄します;

2) 承認された各ブリッジオペレーターのトークンの鋳造と焼却をレート制限する—たとえば、中央集権型のブリッジには小さな制限を設定し、より安全なプロトコルにはより高い制限を設定します。

ERC-7281とERC-20トークンのわずかな違いを考慮すると、EIPの著者は前者を「xERC-20」と表現しています。ERC-20トークンの概要が必要な読者には、OpenZeppelinが素晴らしいトピックに関するガイド.

実質的には、各ERC-20トークン契約は、ERC-20インタフェースを実装し、グローバルなトークン供給を定義し、どのアドレスがトークンを所有し、いくつ所有しているかの情報を格納します。ERC-20には、ユーザーのトークンへのアクセス（承認を介した）を管理するための便利な機能が含まれており、特定のアドレスの総流通供給量や残高などのトークンに関する情報を取得するための機能も含まれています。

ERC-7281がERC-20仕様に追加する追加機能の1つは、WETH（Wrapped Ether）契約に類似したラッパー契約として機能するオプションのロックボックスです。 Lockbox契約は、おなじみのミントおよびバーンメカニズムを介してERC-20トークンをxERC-20トークンにラップし、バーン/ミントインターフェイスがなく、アップグレードできない既存のERC-20トークン契約と互換性があります。

前の記事で紹介されたフレームワークを使用すると、ERC-7281を「トークン発行者を信頼+（承認済み）ブリッジプロバイダを信頼」アプローチとして、マルチチェーントークンの発行を分類することができます。複数のチェーンに展開されたERC-7281トークンは、発行者によって制御されます（通常、主権を放棄する必要があるクロスチェーントークンの代替設計とは異なります）。発行者は承認されたブリッジがセキュリティインシデントに苦しんでいるリスクにさらされていますが、発行者は手動で承認されたブリッジプロバイダを選択し、レート制限をかけることでこのリスクを管理しています。

このレポートで探究する大きな違いは、トークン発行者が特定のブリッジオペレーターが発行/焼却できるトークンの数に動的な制限を課すことで、ブリッジハックや悪用への露出を調整できることです。ERC-7281は、トークン発行者が複数のブリッジプロバイダーをホワイトリストに登録して、同じ標準トークンをチェーン間で発行できるようにするため、単一のプロバイダーへの依存を減らすことも可能にします。

両方の機能により、ERC-7281はプロトコルのトークンのクロスチェーン・ブリッジングを容易にする従来のアプローチよりも大幅に改善され、ユーザー、相互運用性インフラプロバイダー（特にアグリゲーター）、およびアプリケーション開発者にとってプラスの第二次効果があります。次のセクションで仕様を議論した後、ERC-7281の実装の利点と欠点について検討します。

ERC-7281の概要:ソブリンブリッジトークン

ユーザーのためにトークンを焼却し、鋳造する

仕様では、プロジェクトは、IXERC20インターフェースを実装した新しいERC20互換トークン契約を展開します。ブリッジオペレーターは、元のチェーンでのデポジットを燃やした後、宛先チェーンのユーザーのためにトークンを鋳造します。鋳造プロセスは、トークンの金額がブリッジの制限を超えていないことを確認し、成功した場合は、トークンの総供給量とブリッジの鋳造制限を更新します。

既存のERC-20トークンには、「ロックボックス」ロジックが適用されます:ブリッジプロバイダーは、ユーザーが預けたERC-20トークンをロックボックスコントラクトに転送することでxERC-20トークンにラップします。その後、ロックボックスはブリッジが同量のxERC-20トークンを鋳造することを承認します。

宛先チェーンのブリッジによって鋳造されたxERC-20トークンは、burn()関数を使用してソースチェーンでバーンされます。このプロセスにより、トークンの量がブリッジの燃焼制限を超えないようにし、xERC-20トークンの総供給量を増やし、減少させます。ブリッジのトランスポート層は、書き込みメッセージを宛先にリレーします。宛先側のブリッジコントラクトは、メッセージを検証し、そのチェーン上のユーザーのアドレスに同量のxERC-20トークンを鋳造します。このミントにより、トークンの総供給量とブリッジのミント制限が減少します。

トークンをホームチェーンに戻すために、ブリッジオペレータはリモートチェーンでxERC-20トークンを焼却し、ユーザーのアドレスとトークン数量を提供します。焼却レシートは輸送層によってホームチェーンに中継されます。焼却メッセージが検証された場合、ブリッジオペレータはユーザーのためにホームチェーンで新しいxERC-20トークンを鋳造および焼却します。トークン契約による焼却レシートの検証後、ブリッジオペレータはユーザーに預託されたERC-20トークンを解放します。ホームチェーンでのxERC-20トークンの焼却は、トークンの総供給量およびブリッジの焼却制限を減らします。

重要な点は、xERC-20コントラクトは、ブリッジが証明を検証することなく、技術的にトークンを鋳造できることです。標準的な(つまり、予想される)アプローチについて説明しましたが、メッセージ検証を一切実装していないブリッジ、またはクロスチェーンメッセージを検証するための新しいメカニズムを実装しているブリッジは、xERC-20トークンをミントしてバーンするためにホワイトリストに登録することができます。それはすべて、トークン発行者が何を受け入れることができるかによります。

トークンのミントとバーンのレート制限

関数 setBridgeLimits は、トークン契約の所有者のみが呼び出すことができる保護された関数です。この関数を使用すると、ブリッジコントラクトのアドレスを設定し、ブリッジがユーザーのために鋳造(mintingLimit)および燃焼(burningLimit)できるトークンの最大量を指定できます。所有者はこれらの制限を更新して、必要に応じてブリッジの機能を調整できるようにすることができます。たとえば、ブリッジプロバイダーのインフラストラクチャでセキュリティの問題が発見された場合、mintingLimitを下げてリスクを最小限に抑えることができます。逆に、セキュリティの向上により、ミンティング制限が増加する可能性があります。

xERC-20仕様には、トークンを処理するために承認されたブリッジの燃焼および鋳造の上限をチェックする機能も含まれています。「mintingMaxLimitOf」は、ブリッジが鋳造できるトークンの最大量を返し、「burningMaxLimit」は、指定された期間中にブリッジが燃やせるトークンの最大量を返します。さらに、これらの機能により、ブリッジが設定された上限に達する前に燃やしたり鋳造したりできる残りのトークンが表示されます。

これらのビューア機能は、トランザクションをルーティングする前に、さまざまなブリッジプロバイダーの利用可能な制限を知る必要があるブリッジアグリゲーターに役立ちます。ブリッジがソースチェーンまたはデスティネーションチェーンのバーンまたはミント制限に達すると、進行中のトランザクションとユーザーエクスペリエンスに影響を与える可能性があります。したがって、アグリゲーターは、ミントとバーンの制限に達しておらず、特定の量のスワップを実行できるブリッジにリクエストをルーティングすることを好みます。

レート制限パラメータ

xERC-20トークンインターフェース仕様には、「burningParams」と「mintingParams」を含む「Bridge」構造体が含まれています（xERC-20トークンのレート制限関数のパラメータは、ブリッジが事前定義された期間においてどれだけのトークンを燃やしたり作成できるかを制御します）。 「maxLimit」はトークンの発行と燃焼の最大制限を定義し、事前定義されたレート（「ratePerSecond」）で毎秒増加します。

ここで混乱の可能性があるポイントに対処します：「maxLimit」（焼却および鋳造リミットの両方に設定されています）は、特定の時間枠での鋳造および焼却操作の上限のように聞こえますが、事前に定義されたしきい値に応じて鋳造および焼却を抑制するレート制限ではありません。「currentLimit」は、橋が鋳造または焼却できる量を定義し、事前に定義されたレートで増加します。対照的に、「maxLimit」は、橋が1日に鋳造または焼却できる量を定義します。

バーニングとミントのパラメータは、主にトークンの所有者(およびブリッジオペレーター)に関連しています。ただし、最大制限パラメータと電流制限パラメータは、ユーザーとブリッジ オペレータにとって重要な考慮事項です。たとえば、現在の制限は、ユーザーが宛先でxERC-20トークンを受信する際に遅延が発生することなく、クロスチェーンプロトコルを使用して自信を持ってブリッジできる量に影響を与える可能性があります。

xERC-20 ロックボックス

元のERC-20トークンには、通貨供給量を増やしたり減らしたりするための機能が明示されていませんでした（かつての「トークノミクス」は、一定数のトークンを生成し、数年後に希少であるとユーザーに伝えることを意味していました）。したがって、すべてのERC-20トークンには鋳造および焼却機能があるわけではありません。ERC-7281は、ほとんど（もしくはすべて）のブリッジで好まれている鋳造および焼却メカニズムを使用しているため、旧式または非更新可能なERC-20トークンはERC-7281と直接動作しません。

Lockbox契約は回避策を提供し、既存のトークンとの後方互換性を可能にします。元の仕様（つまり、プロジェクトがIXERC20インターフェースを実装した新しいトークン契約を展開する）、ブリッジオペレーターは宛先チェーンでユーザーのためにトークンを鋳造するためにmint()を呼び出すだけです（ソースチェーンでの預金をロックした後）。

Lockbox コントラクトは、WETH ラッパーコントラクトの設計から大きく借用しています。対応するERC-20トークンをロックボックスに預けるためのdeposit()関数と、リモートドメインでラップされたトークンを燃やした後にブリッジオペレーターがERC-20トークンのロックを解除するためのwithdraw()関数を実装しています。

仕様書で強調されている最初の2つのエラータイプ（“IXERC-20Lockbox_NotNative”および“IXERC-20Lockbox_Native”）は、ユーザーが誤ったLockbox契約にトークンを預け入れようとすると発生します。 Lockboxは、サポートしているトークンの種類によってネイティブまたは非ネイティブになることがあります。

ネイティブロックボックスは、ガス手数料をバリデータに支払うために使用されるトークン、すなわちネイティブトークンを保管します。xERC-20トークンにラップするためのネイティブロックボックスを持っているトークンの例としてETHがあります：ETHをxERC-20トークンにラップするには、LockboxのdepositNative（）関数を呼び出してETHを預け入れ、ETHのERC7281互換表現を受け取る必要があります。

通常の（非ネイティブの）ロックボックスは、USDC、DAI、WETH、USDTなどのERC-20トークンを保管します。たとえば、xERC-20トークンとしてUSDCを作成するには、ユーザーはUSDCをロックした後、ロックボックス契約にdeposit()を呼び出す必要があります。

ETHでdeposit()を呼び出すと、通常のLockboxコントラクトはERC-20トークンのみをラップおよびアンラップできるため、これらの資金は永久にロックされます。ERC-20トークンを使用してdepositNative()を呼び出すと、ネイティブロックボックスコントラクトはERC-20トークンではなくネイティブトークンで動作することを意図しているため、同様の結果が得られます。

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

アダプタ契約

ブリッジングプロトコルがxERC-20トークン固有のオペレーション（発行/破棄、対応するログ記録など）を認識するよう設計されていない場合、アプリはアダプターコントラクトを構築することができます。これらのコントラクトは自動ラッパーおよびアンラッパーとして機能し、標準のERC-20承認+コールの動作をxERC-20が必要とするより微妙な発行/破棄スキームに効果的に変換します。

これは必要です。なぜなら、多くのブリッジプロトコル（たとえば、ChainlinkのCCIP）は従来のERC-20の動作に最適化されているためです。アダプター契約は、この互換性のギャップを埋めるためにそのようなロジックを確立することができます：それはトークンをLockboxに預け入れて、ソースチェーン上でxERC-20表現を生成し、後で、宛先チェーンでメッセージを受信すると、正規の資産に戻すための引き出しメカニズムをトリガーします。

このフローにより、ユーザーは最終的に、xERC-20 による内部のラッピング メカニズムの影響を受けずに、一貫性のある正規のトークンを受け取ることができます。これにより、アダプターはプロトコルを xERC-20 に準拠していないブリッジとシームレスに統合し、サポートする相互運用可能なソリューションの範囲を増やすことができます。

なぜERC-7281なのか？主権を持つブリッジトークン標準の必要性

大まかに言うと、ERC-7281には4つの大きな目標があります。

1. 代替可能性:トークンのネイティブチェーンから別の(L1/L2)チェーンにトークンをブリッジするユーザーは、常に宛先でブリッジされたトークンの正規表現を受け取る必要があります。同じトークンの複数の非代替性バージョンが非ネイティブチェーンで流通していることは、前述の理由(流動性の断片化やトークンの構成可能性の低さなど)で問題があります。

ERC-20仕様を作成した当初のビジョンは、アプリケーションとイーサリアムインフラストラクチャ間でのイーサリアム上のトークン間の代替性とシームレスな相互運用を確保することでした。しかし、ロールアップ中心のスケーリングロードマップを採用した後、アトミックコンポーザビリティの欠如という問題が発生し、多くの異なるドメインが作成されると、それらの代替性特性が低下しました。xERC-20は、さまざまなクロスロールアップブリッジの流動性を統一されたマルチロールアップトークンに集約することを可能にし、イーサリアムの当初のビジョンを復元します。

1. セキュリティ：取引相手リスクを軽減するために、トークン発行者はセキュリティインフラの評価に基づいて競合するブリッジプロバイダーを選択できるようにすべきです。さらに、トークン発行者は、パートナーブリッジプロバイダーに影響を与えるセキュリティインシデントの影響から意味のある保護を受けるべきです。1〜2つのブリッジサービスに対する孤立した攻撃が全体のTVLを一掃するべきではありません。

2. クロスチェーントークンのための流動性フリーブートストラップ：プロトコルDAOは、マルチチェーン拡張計画の一環としてブリッジトークンの流動性をブートストラップするために、大幅な（財務上の）リソースを費やさなければならないべきではありません。流動性ベースのブリッジングはUXにとって悪いだけでなく、プロジェクトチームがブロックチェーンの数がすぐに増えると、流動性提供インセンティブへの支出が不可能になるかもしれません。

3. トークン発行者の主権：トークン発行者は、非ネイティブチェーンで鋳造されたプロトコルトークンの正規表現を制御し続ける必要があります。非代替ブリッジトークンの問題を解決することは、特にプロジェクトのブリッジトークンの制御、特に総供給量の制御や鋳造・焼却メカニズムの構成などの管理的側面を第三者ブリッジに委任する必要はありません。

これらの目標をさらに拡大して、ERC-7281がプロトコルやコミュニティに提供する利点を見てみましょう。

ERC-7281の利点を分析する

UXの改善と流動性の断片化の排除

ERC-7281は、序論で説明した経路依存問題のさまざまなバージョンを解きます。

パスの依存性は、チェーン固有のもの（例：Ethereum → Arbitrum → OptimismからブリッジされたETHは、Ethereum → Optimism → ArbitrumからブリッジされたETHとは異なります）またはブリッジ固有のもの（例：EthereumからOptimism経由でCelerにブリッジされたETHは、EthereumからConnext経由でOptimismにブリッジされたETHとは異なります）。

パス依存性は貴重なセキュリティ機能ですが、UXとクロスチェーンの相互運用性にも悪影響を及ぼすことがあります。たとえば、ユーザーは、OptimismとArbitrumで動作するクロスチェーンDEXにリキッドティをプログラムで供給することができません。アプリケーションはopETHまたはarbETHを受け入れる必要があります。

ERC-7281は、ユーザーがいくつのチェーンを横断したり、どのブリッジプロバイダーを使用してトークンをブリッジしたりしても、交換可能なままのxERC-20トークンを導入することで問題を解消します。たとえば、ユーザーがArbitrumからOptimismにラップされたUSDTを引き出さずに移動したい場合、ブリッジプロバイダーはArbitrumでxERC-20トークンを焼却し、OptimismでxERC-20を鋳造することができます。Optimismで鋳造されたトークンの価値は、Lockboxに預けられたトークンとペッグされたままであり、1:1で裏付けられたままにリマップされます。

重要なのは、ERC-7281は、CircleのCCTP(Cross-Chain Transfer Protocol)のような標準的なブリッジドトークンをデプロイする利点を提供し、プロトコルがブリッジドトークンを一元的に保管する必要がないことです。例えば、流動性はプロジェクトのトークンの標準的な表現を中心に統合されるため、DeFiアプリケーションのトークンの有用性が向上し、同じ資産の異なるバージョンに対して異なる市場を作成するオーバーヘッドが削減されます。

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

xERC-20は「ソブリンブリッジドトークン」と呼ばれ、トークン発行者はトークンの正規表現を鋳造するための特定のオプションを使用することに縛られず、デプロイメント間でブリッジドトークンの設計と管理の制御を保持します。ERC-7281は、「サードパーティのブリッジを介した正規トークンの鋳造」と「トークン発行者が制御するブリッジを介した正規トークンの鋳造」のハイブリッドであり、主権、ユーザーエクスペリエンス、分散化を同じパッケージに組み合わせています。

ERC-7281を使用してトークンをクロスチェーンでデプロイするプロジェクトは、同じネイティブアセットの非代替性ラップバージョンの問題に遭遇することなく、複数のブリッジを介してネイティブトークンの正規表現をミントでき、ERC-20トークンの構成可能性と代替可能性を活用したいユーザーのUXを壊すことができます。また、xERC-20トークンコントラクトとLockbox(ブリッジがユーザーのトークンをロック、ミント、バーンするために利用する)がプロジェクトによってデプロイされ、制御されているため、このようなプロジェクトは、ドメイン間の正規トークンの転送を管理するための社内インフラストラクチャを運営するトークン発行者と同様のレベルのトークンのクロスチェーン展開に対する制御を保持しています。

この控えめな機能は、ハイプロファイルなプロジェクトがホームチェーンで発行されたネイティブトークンを持っている場合に便利です。他のエコシステムのユーザーは、さまざまな理由でネイティブチェーン上で保有せずにトークンに露出したいと思っています。

プロジェクトは、すべてのチェーンについてインハウスのブリッジインフラを実行する能力や意欲を持っておらず、ブリッジされたトークン間の1:1の互換性を確保するため、またはプロトコルやコミュニティと必ずしも一致しない第三者にトークンの制御権を譲渡したくないと考えています。ブリッジされたトークンで投票が可能なクロスチェーンガバナンスを実装する際には、ネイティブチェーンで投票が集計される一方で、コントロールがブリッジされたトークンを持つ非一致のブリッジプロバイダーは、プロトコルガバナンスの障害点となり得ます。

イールドファーミングのプロトコルであるBeefyも、この理由からxERC-20を採用しています。プロジェクトのブリッジドキュメンテーションで説明されているように、ERC-7281は、主要なブリッジパートナーがハッキングを受けた後に必要になったトークンのブリッジングのためのより多くのオプションをプロジェクトに提供し(このテーマは暗号ネイティブに急速に馴染みつつあります)、ブリッジングメカニズムの設計をよりきめ細かく制御できるようにしました。Beefyの場合、ERC-7281の許可リスト機能により、プロトコルはさまざまなブリッジングパートナーを選択し、mooBIFIトークンをブリッジする際の速度、分散化、コスト、セキュリティの最適化からユーザーにさまざまなオプションを提供することができました。

インセンティブの再配置により、オープンな競争とセキュリティが向上します

流動性ベースのブリッジングは、流動性インセンティブに費やす財務能力を持つプロジェクトを好むことが多い - トークン発行者はLPインセンティブにほとんど支出せず、優れたブリッジUXを提供したいと考えているため、標準的なL1/L2ブリッジを使用するプロトコルでは、流動性が最も重要な要素となります。これは、ブリッジアグリゲーターによるブリッジプロバイダーの選択にも及び、新しいブリッジングサービス(安全なインフラストラクチャを持つサービスであっても)がより確立されたブリッジングプロトコルと競争することを難しくしていると言えるでしょう。

ERC-7281は、流動性ベースのブリッジングの必要性を取り除くことで問題を解決します。正準トークンをミントしてスワップする必要がないため、どんなサイズのブリッジでも、リモートドメインでプロジェクトのトークンをミントするために承認されることができます。トークン発行者はブリッジの失敗への露出を最小限に抑えたいため、より多くのプロトコルが、流動性よりもクロスチェーンブリッジのセキュリティデザインに注力する可能性が高いでしょう。

これは、「最も流動性の高い橋を勝たせる」のではなく、「最も安全な橋を勝たせる」というケースになるため、オープンな競争を奨励する。このオープンコンペティションは、流動性/セキュリティ以外の機能(手数料、API/SDK、アプリケーション統合など)で競争するブリッジの形をとることができます。これらの機能は、主に開発チームの専門知識に依存するため、最初からアプリケーションに組み込むのが間違いなく簡単です。対照的に、流動性とブリッジングの量は、ブートストラップがより複雑で、事業開発、資金調達、業界とのつながり、マーケティングなどを組み合わせる必要があります。

トークン発行者のためのより良いリスク管理

ERC-7281は、トークンの鋳造および燃焼に設定可能なレート制限を導入し、ノンネイティブチェーン上で正準トークンを鋳造するためのサードパーティブリッジと連携するプロトコルのリスクプロファイルを劇的に改善します。パートナーブリッジプロバイダーがハッキングされたり、侵害された場合、攻撃者が引き起こす最大の被害は、侵害されたブリッジに割り当てられた制限に相当します。トークン発行者がレート制限のパラメータを注意深く選択すれば、ブリッジへの孤立した攻撃がプロトコルの支払能力にほとんど影響を与えないはずです。

ブリッジごとにレート制限を設定することで、プロトコルDAOのリスク評価プロセスを改善することも可能です。現在、ブリッジのリスク評価には数か月かかることがあり、カノニカルな第三者ブリッジのハッキングからの影響が大きいためです。プロトコルは、選択したブリッジのセキュリティが徹底的に精査され、コミュニティにより強力な安全性の保証が行われるようにしたいと考えています。努力と時間の無駄遣いであるだけでなく、ブリッジセキュリティのマラソン分析は、選択したブリッジがゼロデイ攻撃に対して免疫であることを保証するわけではありません。

ERC-7281の採用により、リスク評価がよりダイナミックになります。プロジェクトは引き続きブリッジプロバイダーのデューデリジェンスを完了し、適切なレート制限の特性を選択する必要があります。ただし、リスク評価のタイムラインは、プロトコルがすべてか何もかの状態でなくなったことを反映して短縮される可能性があります。1つのオプションを選ぶために数ヶ月を費やす代わりに、プロジェクトは最初に複数のブリッジプロバイダーを選択し、セキュリティの評価に基づいて異なるミンティング制限を設定することができます。トークン発行者はその後、セキュリティレビューを実施し、特定のブリッジパートナーのミンティング制限を増減させるか、ブリッジからのミンティング権利を取り消すかを決定できます（たとえば、ハッキングや脆弱性の開示に対応して）。

ERC-7281は、ブリッジのセキュリティにおける最先端の進歩に参加したいが、技術がコミュニティによって徹底的にテストされ検証されるまで、特定の技術を完全に採用することをためらうプロジェクトの障壁を低く抑えます（つまり、イノベーターのジレンマ）。ブリッジプロバイダーが新しいインフラを提案し、セキュリティ保証を大幅に向上させると報告した場合、プロトコルはブリッジに限られたマイニング権を割り当て、提案されたシステム設計への信頼が高まるにつれて、ブリッジのマイニング制限を徐々に増やすことができます。

流動性に関する懸念を取り除くのと同様に、鋳造権を割り当てる前にブリッジの技術スタックを100%信頼するプロトコルの必要性をなくすことで、新規参入者と旧来のプレイヤーとの間に平等な競争が生まれます。トークン発行者は、安全性と分散化へのより高いコミットメントを示したという理由だけで、トークン発行者がミント権を撤回し、小規模なプロジェクトに再割り当てする柔軟性を持つようになったため、古いプレイヤーはセキュリティに対するより良いアプローチを繰り返すインセンティブを持つことができます。これにより、サードパーティのブリッジと連携するプロトコルの別のリスク要因も排除されます:選択したブリッジプロバイダーが、ブリッジセキュリティの欠陥や問題が急速に開示および発見されるペースにもかかわらず、トークン発行者がそのような活動の実行が困難であるために懲罰的な措置(たとえば、別のブリッジプロバイダーへの移行)を強制できないことを知っているため、セキュリティの革新を停止するリスクも排除されます。

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

流動性ベースのブリッジの価格設定が予測できないため、トークンを任意の数のチェーンにルーティングする必要がある複雑なアプリケーションワークフローを構築することは、今日では困難です。たとえば、Ethereum → Linea → Base からブリッジするブリッジ アグリゲーターには、次の 2 つのオプションがあります。

1. クロスチェーンルーティングのスリッページ許容パラメータと価格実行を設定し、ユーザーが各レイヤーに到達する際の利用可能な流動性の量に応じて、各チェーンでユーザーが受け取るトークンの最小量に基づいています。
2. スリッページ許容パラメータを設定しないでください。代わりに、1つまたは複数のチェーンで受信したトークンの量が予想される量よりも少ない場合、オンチェーンの流動性（例：DEX経由）をソースとするロジックを作成してください。

比較すると、ブリッジアグリゲーターは、特定のトークンをミントすることが許可されたブリッジのmintingLimitおよびburningLimitをチェックすることで、クロスチェーン取引に関与する各ドメインで期待されるトークンの数を事前に把握することができます。認められることに、ブリッジはトランザクションをブロードキャストする時点とトランザクションがドメインに到達する時点の間にmaxLimitに達することがあります。つまり、ユーザーは目的地で正規のトークンを受け取ることができなくなります。

ただし、ERC-7281は、次の理由から、この点ではまだ改善されています。

1. トランザクションが処理中にブリッジオペレーターがmintingLimitに達した場合、ブリッジングトランザクションは保留され、後でレート制限パラメータが調整されたときに再試行されます。ユーザーは、今日の流動性ブリッジとは異なり、正規のトークンの独自のラップ表現を受け取りません。
2. ブリッジアグリゲーターは、ブリッジトランザクションがいつ実行されるか、および予想されるトークンの数について、より予測可能性が高くなります。mintingLimitとburningLimitは、時間の尺度としてブロックを使用するように設定されているため(レート制限パラメータのセクションで示)、ブリッジがトークンの鋳造と燃焼を再開するタイミングを簡単に計算できます。対照的に、ブリッジで流動性がいつ増加するかを予測することは、ロシアンルーレットをプレイするのと同じです。

流動性の予測不可能な変動は、リトライされるブリッジトランザクションの価格にも予測不可能性をもたらします。ブリッジアグリゲーター（または他のアプリケーション）が、ブリッジの流動性プール内のトークンペアの現在の価格に基づいてクロスチェーンスワップの見積もりを提示したとします（この価格は総流動性に基づいています）。しかし、プールの流動性が急激に減少したため、トランザクションを実行できない場合があります。取引が保留され、後でリトライされると仮定します。その場合、アプリケーション開発者は、前回の見積もりが正確であるか、またはユーザーが最初にトランザクションを送信したときと同じレベルの流動性に達するかどうかを把握することができません。

xERC-20トークンのブリッジングは流動性の動きの対象外なので、ユーザーはクロスチェーン取引が即時に実行されなくても、スリッページが発生しないことを確信することができます。

このコンポーザビリティの向上の恩恵を受けているのは、ブリッジング アグリゲーターだけではありません。どのクロスチェーンアプリケーションでも、xERC-20トークンの代替性を利用して、よりエキサイティングなアプリケーションを作成することができます。開発者がイーサリアムからETHをブリッジし、Arbitrum DEXでレンディングポジションを開き、その利益をOptimismでNFTを購入してからイーサリアムにブリッジバックしたいと考えているとします。ここでは、開発者は、プロプライエタリなバージョンを簡単に交換できないため、これらのチェーン上のブリッジプロバイダーと統合する必要がありますが、xERC-20の採用後にプロジェクトのブリッジトークンが代替可能になると、これは当てはまりません。

このワークフローは、以前に説明したトークン発行者ブリッジと類似しています。Circle CCTPを例に取りましょう。

CircleのCross-Chain Transfer Protocolは、ユーザーがチェーンのエコシステムに囚われることなく、USDCトークンの統一された正規バージョンを持つことを可能にします。すべてのクロスチェーン転送は、バーンアンドミント方式を使用してそのプロトコルを通じて処理されます。

しかし、CCTPが中央集権型プロトコルである一方、Circleの運営者だけがUSDCトークンを焼却および発行する権限を持つため、xERC-20は複数のエンティティがさまざまなセキュリティメカニズムを持ってクロスチェーン転送を運営することを許可することで信頼リスクを解消します。

イーサリアムのロールアップ中心の、マルチチェーンの未来を支援する

ERC-7281は、確立されたL2チェーンのような強力なセキュリティプロファイルを持たない可能性のある新しいEVM L2にトークンをデプロイする自信をプロジェクトに与えることで、イーサリアムのロールアップ中心のロードマップを加速させることができます。たとえば、ステージ0ロールアップの正規ブリッジは、イーサリアムL1がブリッジのセキュリティを保証しないため、安全性が低くなります。トークンプロジェクトは、正規のブリッジに限定的な鋳造権を付与し、ロールアップがステージ1に進むと鋳造制限を増やすことで、そのようなチェーンにゆっくりと展開することができます。

このプロセスは、L2 がステージ 2 (ロールアップの分散化とセキュリティの最高ステージ) に達するまで続行できます。新たにローンチされたチェーンにプロトコルをリスクを最小限に抑えてデプロイできるメカニズムは、新しいL2がトークンの流動性とアプリケーションをブートストラップしやすくすると同時に、ロールアップデザインスペース内でのさらなるイノベーションを促進することで、イーサリアムエコシステムに利益をもたらします。

ERC-7281を実装することの潜在的な欠点

DAOプロジェクト管理チームのオーバーヘッド増加

ERC-7281はプロトコルにとって非常に魅力的ですが、DAOはさまざまな展開でxERC-20トークンを管理するためにDAOプロジェクトチームが負担しなければならない膨大な運用オーバーヘッドのためにxERC-20トークンを採用するのをためらうかもしれません。

ジェラール・ペルスーンの多数のチェーンでブリッジされたトークンを管理するERC-20からxERC-20に移行した後にプロトコルが実行する必要がある一度限りおよび繰り返しのタスクの非完全なリストが含まれています。

非常に長いタスクリストです

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

例えば、あるプロトコルが以前に社内のインフラでクロスチェーントークンを管理していたとします(例:チェーンごとに個別のトークンコントラクトをデプロイし、ミントとバーンを制御するなど)。その場合、ERC-7281は根本的な変更のようには見えません。ただし、コアブリッジインフラストラクチャの管理をブリッジ開発チームにアウトソーシングするために使用されるプロジェクトでは、追加のワークロードが懸念されます。

例えばLidoチームの中核メンバーが概説しました（すべての展開でxERC-20トークンとしてwstETHを展開する提案に対する応答として）PMチームの現在の責任は相互運用性インフラに関連しており、そのセットを対比しました。Lido DAOがすべてのドメインでwstETHをxERC-20バージョンに移行するように投票した場合、同じチームメンバーが引き受ける責任のセットと対比されました。

上記の会話からもわかるように、xERC-20トークンの管理はプロトコルやコミュニティメンバーにとって無視できないほどの運営オーバーヘッドをもたらします。たとえば、ブリッジ制限にはブリッジセキュリティの積極的な監視と評価が必要で、ミンティング制限の調整に関する情報提供が必要です。また、ブリッジ制限に関する意思決定（またはミンティング権利の引き出し/割り当て）はDAOの投票の対象となる場合があります（これらの選択が頻繁に必要な場合、DAOメンバーは投票の疲労を感じるかもしれません）。

ただし、これはERC-7281に対する価値判断と解釈すべきではありません。各プロジェクトには異なるリスクプロファイル、長期目標、リソースがあり、これらの要因が長期的な利益が短期および継続的なコストを上回るかどうかを決定します。ERC-7281を採用する長期的な利益が短期および継続的なコストを上回るかどうかを決定します。

例えば、小規模なプロジェクトでは、xERC-20トークンの発行のオーバーヘッドを管理するのが難しく、AxelarのITS(Interchain Token Service)やWormholeのNTT(Native Token Transfers)のようなマネージドマルチチェーントークンブリッジングサービスを選択することになるかもしれません。より確立されたプロジェクトは、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からの積極的なガバナンスが必要です。これには、鋳造制限の設定、Lockbox契約のアップグレード、鋳造または焼却トークンの一時停止などのパラメータの設定が含まれます。これらの決定はセキュリティに敏感であり、クローズドな会議の決定の責任を避けるためにDAOによって統治される必要があります。

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

例えば、Lidoのような注目を集めるプロジェクトは、ガバナンスの問題について精査を受けています。トークン管理に対する制御を追加することで、ガバナンスの接収のリスクが高まります。プロジェクトがすべてのERC-20トークンをロックボックスに統合し、それをDAOが統治する場合、ガバナンス攻撃は広範な影響を及ぼす可能性があります。攻撃者はロックボックスの制御を取得し、他のチェーン上のxERC-20トークンを無価値にする制限のない悪意のあるブリッジプロバイダーを導入することができます。

このシナリオは、マルチパーティコンピュテーション（MPC）署名インフラストラクチャの脆弱性に遭遇したMultichain exploitと類似しており、この脆弱性により、ハッカーがEthereumとDogecoin上でネイティブトークンを保管していた主要なMultichainアドレスを侵害することができました。これらのトークンは、FantomやMoonriverのようなノンネイティブチェーン上で鋳造されたトークンを裏付けており、これにより、EthereumとDogecoin上のMultichainのスマート契約への攻撃の結果、他のプロジェクトが損失を被るというドミノ効果が生じました。

最大限に分散化されたプロトコルとの非互換性

ERC-7281は、トークンがトークンガバナンスを備えたプロトコルまたは中央集権的なエンティティ(CircleのUSDCやCZKCステーブルコイン).しかし、プロトコルが最大限に分散化され、正式なガバナンスがない場合、LiquityのLUSDステーブルコインは、xERC-20標準と互換性を持たせるのが難しいトークンの一例です。

xERC-20 トークンには、特定のパラメーターの決定、つまり発行枚数や焼却枚数の制限、特定のブリッジプロバイダーをホワイトリストに登録するかどうかなどの決定が必要です。これは、xERC-20 トークンの存続には継続的なガバナンスが必要であることを示しています。プロジェクトがプロトコルの重要な部分（例：DAOのトークン契約）を時間の経過とともに分散化したい場合、これは問題を引き起こし、分散化計画を複雑化させる可能性があります。

コアコンポーネント(Lockboxコントラクトおよびブリッジプロバイダー)に影響を与えるエクスプロイトによるリスクの増大

パス依存性がどのように機能するか、また、チェーン A に影響を与えるエクスプロイトがチェーン B に影響を与えない、またはチェーン A 上のブリッジ A が関与するエクスプロイトがチェーン B 上のブリッジ B に影響を与えないことを保証するのに役立つ理由については、すでに説明しました。ERC-7281 は、パス依存性を排除し、これには利点がありますが、セキュリティに関するトレードオフも導入します。

ブリッジで利用可能な最大流動性は、異なるブリッジプロバイダーによって鋳造されたトークンがドメイン間で代替可能であるため、ブリッジエクスプロイトがトークン発行者に与える潜在的な影響の上限を表すものではなくなりました。ERC-7281の著者は、トークン発行者が不正なミンティングによる損失を補償するために費やすことができる金額に基づいて、ブリッジプロバイダーのレート制限を選択することを提案しています。それでも、選択したレート制限は、振り返ってみると保守的すぎたかもしれません。

高い上限を持つブリッジが危険にさらされると、その影響は顕著になる可能性があります。同じトークンを鋳造する他のブリッジのユーザーにとってもそうです。プロトコルは、鋳造権を多くのブリッジに分散させることでリスクを低減できます（つまり、他のブリッジと比較して1つのブリッジプロバイダーが鋳造できるトークンの数が過度に多くなることを防ぎます）。ただし、このようにリスクをヘッジしようとすると、各ブリッジはDAOチームから独立した評価を必要とし、さらに多くのブリッジと調整することで、前述の管理オーバーヘッドが増加する可能性があります。

DAOによって管理されるLockboxコントラクトは、ガバナンス攻撃が発生した場合に悪影響を及ぼす可能性があります。しかし、安全なDAOガバナンスがあっても、トークンのホームチェーン上のネイティブ/非ネイティブのLockboxコントラクトのバグは、同じくらい多くの問題を引き起こす可能性があります(Sifuは現在、プロジェクトのLockboxコントラクトの所有者であり、資金はSAFUではなくなりました)。それに比べて、この問題は現状では軽減され、Vaultコントラクト(ブリッジプロバイダーのLockboxコントラクトに相当)は、対応するブリッジサービスを通じてブリッジされたトークンのみを保持します。つまり、あるプロバイダーのVaultコントラクトのバグは、そのブリッジにトークンを預けたユーザーにのみ影響します。

エコシステム統合のオーバーヘッド

ERC-7281 による追加の管理作業は、プロジェクトの xERC-20 トークンを使用するアプリケーション開発者やサービスプロバイダーにも影響します。ブリッジアグリゲーターは、スパムトークンやスプーフィング攻撃などの問題を防ぐために、xERC-20トークンとそれに対応するLockboxコントラクトとの間のマッピングを追跡する必要があります。これらのマッピングのレジストリは役立つかもしれませんが、このようなレジストリの設定は、中央集権化のリスクやxERC-20の採用者を脅威にさらすリスクなしには困難です。

リスクは、攻撃者が悪意のある契約をトークンレジストリに追加し、ユーザーや開発者をだますことで、トークンを間違ったアドレスに送信させる可能性があることから発生します。これにより、L2およびL1ネットワークの両方でトークンが盗まれる可能性があります。取引所も同様の課題に直面しており、偽造されたトークンが予期せぬトークンの振る舞いを引き起こし、承認された正規のトークンと異なる重大な問題を引き起こす可能性があります。

結論

ERC-7281は、非代替性ブリッジドトークンの問題に対する説得力のあるソリューションを提供し、トークンブリッジ設計のユーザーエクスペリエンス、分散化、セキュリティ、および柔軟性を向上させる機能を提供します。これらの問題の一部は、ロールアップ中心のロードマップの実行可能性に直接影響し、xERC-20をイーサリアムL2エコシステムの標準的な重要なインフラストラクチャにしています。

Hyperlane、Omni、Sygma、Router Protocol、Everclearなど、ブリッジング分野のいくつかの主要なプレーヤーがERC-7281の採用を約束しており、この提案に対する大きな牽引力を示しています。Circleのような確立されたトークン発行者(トークンをブリッジするための実用的なメカニズムを持つ)でさえ、ユーザーや開発者に影響を与える未承認のトークンによってもたらされる課題に対処するためにERC-7281に関心を示しています。

ERC-7281は、これらの問題に対処すると同時に、リモートドメインで正規トークンを鋳造する以前のアプローチに関連する多くのトレードオフを軽減します。これは、祀られたブリッジとは異なり、流動性のないブートストラップを提供し、トークン発行者ブリッジのようなカスタムインフラストラクチャを必要とせず、承認されたブリッジプロバイダーによるマルチブリッジの標準的なトークン鋳造を可能にすることでベンダーロックインを回避します。

ERC-7281 に関するディスカッションに興味がある方、または xERC-20 の統合を検討している開発者の皆様、イーサリアムマジシャンズのフェローシップそしてxERC-20 の Web サイトは優れたリソースです。コミュニティも構築しました xERC-20 ランチパッドxERC-20トークンを作成、監視、管理するための集約ツールーxERC-20トークンを初めて展開するビルダーや既存のトークンをxERC-20トークン標準に移行するビルダーにとって貴重なツールです。

免責事項：

1. この記事は[から転載されています2077年の研究]. すべての著作権は元の著者に帰属します [2077リサーチ].この再版に異議がある場合は、ゲートラーンチーム、そして彼らはそれを迅速に処理します。
2. 免責事項:この記事で表明されている見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. Gate Learnチームは、記事を他の言語に翻訳します。翻訳された記事をコピー、配布、または盗用することは、明記されていない限り禁止されています。