紹介

現在、イーサリアム上でロールアップのカンブリア爆発が起こっています。執筆時点で、L2Beatによると91のライブL2＆L3があり、82のアップカミングがあります。その結果、流動性、ユーザーエクスペリエンス、および開発者ツールの面でかなりの分断が生じています。相互運用性への現在の解決策は、サードパーティのブリッジ、外部ラップアセット、および意図フレームワークの組み合わせに依存しており、それぞれが独自の問題を抱えています。

1. 流動性ブリッジはしばしば最大の暗号ハックの標的となります（例：321百万ドルのワームホールブリッジハック)
2. 外部で包装された資産は望ましくありません。データによると、可能な限り資産をネイティブ形式で保持したいと考える人々が多いことが示されています（たとえば、正準的に橋渡しされた資産は220億ドルであり、外部で包装された資産はわずか30億ドルしかありません）。L2Beat)
3. インテントフレームワークは、相互運用性を促進するために追加料金が必要であり、信頼性のあるサードパーティに依存しています（たとえば、Degenチェーンユーザー）トークンの>80%を失う公式のブリッジが非正規であるため）a. 中央集権的な意図のフレームワークは、競争が低下することを意味し、これは最適でない価格設定とパフォーマンスにつながる可能性があります

この記事では、断片化されたロールアップエコシステム間の相互運用性ソリューションの6つのレベルを定義し、議論することで、信頼できる相互運用性の景観を調査します。

ソースロールアップからL1への非同期引き出しのデフォルトケースから始め、ターゲットロールアップに手動でブリッジングし、1つのトランザクション内でのクロスロールアップの相互運用性の仮想的なアーキテクチャで終わります。相互運用性の各レベルがユーザーエクスペリエンス、開発者エクスペリエンス、MEVポテンシャル、およびロールアップ自体（インフラストラクチャの変更に特に関連する）にどのように影響するかを探ります。

この記事では、主にEthereumとそのL2に焦点を当て、トラストレスな相互運用性に重点を置いています。 この場合の「トラストレスな相互運用性」とは、プロトコル内のチャネルを指し、すでに多くのロールアップが必要とするインフラ外での転送を促進するための第三者が必要としないものを指します。

プレリミナリー

定義

基本的に、信頼性のない相互運用性には、相互運用を希望する任意の2つのプロトコルがアクセスする必要がある共有リソースが必要です。Ethereum L1の場合、すべてのスマートコントラクトはEthereumの完全な状態を共有する同じ環境に存在するため、常に最高レベルの相互運用性を持ちます。ただし、L2は別々のブリッジ契約を介して決済層を共有するだけなので、相互運用性ははるかに制限されています。

トラストレス相互運用性の階段を進むのに役立つ重要な共有インフラストラクチャコンポーネントは、共有シーケンサ、スーパービルダー、共有決済です。これらの共有レイヤによって開かれた保証と新機能は関連していますが、本質的には直交しています。

1. 共有シーケンサー/スーパービルダー：主に速度とユーザーエクスペリエンスのアップグレード。
2. 共有決済：外部ラッピングなしでの資産スワップとプロトコル内メッセージング。

始めるにあたり、まず、導入部で示唆されているトラストレス相互運用性の6つのレベルを定義します。

1. L1 Async:
   → L1がロールアップに解決される手動資産転送を介した相互運用性。
2. アトミックインクルージョン：
   → クロスロールアップバンドル内のすべての取引が、バンドルに関与する各ロールアップの次のブロックに含まれるか、含まれないかのいずれかが保証されます。
3. 共同決済：
   → 同じブリッジ契約を介してL1に接続する複数のロールアップ。
4. アトミック実行：
   → クロスロールアップバンドルのすべての取引が次のブロックで正常に実行されるか、またはバンドルに関与する各ロールアップで実行されないことを保証するか、またはどちらも実行されないことを保証する。 正常な実行とは、各取引がリバートせずに実行され、バンドル内の各ロールアップの更新された状態に反映されることを指す。
5. ブロックレベルの合成性:
   → クロスロールアップバンドルにおける次のブロック保証は、依存トランザクション（ロールアップAのtx Aの結果に依存するロールアップBのtx Bなど）を含むことができます
6. Tx-Level Composability:
   → 1つのトランザクションのみで、多くのロールアップに状態変更を引き起こすことができるスマートコントラクトレベルの相互運用性（バンドルなし）。 任意のプロトコルを任意のロールアップで使用することは、1つのチェーン上で異なるスマートコントラクトを使用するのと論理的に等価であることを意味します。 重要なことは、任意の呼び出しの前の状態変更が、それが戻ったときに取り消される可能性があるということです。

各レベルをさらに理解するために、次の主要なユースケースを通じて歩み、各レベルの力とユーザー、開発者、ロールアップ、MEVサーチャーに対する影響を示します。

説明的な例：

1. 同じトークンの転送
   → セルフ送信：2つのロールアップ間でEthをEthまたはERC-20をERC-20に交換する
2. トークン購入
   → クロスロールアップリミットオーダー：Rollup AからEth/ERC-20を使用して、Rollup BのDEXで異なるERC-20を購入し、（オプションで）Rollup Aに送り返す

意味:

次に、ロールアップエコシステムにおける主要株主への影響をさらに理解するために、以下の質問にも回答されます。

1. ユーザーエクスペリエンス
   この相互運用性レベルを達成することで、ユーザーエクスペリエンスはどのように変わりますか？
2. 開発者体験
   この相互運用性のレベルを達成することで、開発者の体験はどのように変わりますか？
3. MEVポテンシャル
   この相互運用性のレベルを達成した場合、新しいMEVの機会の可能性はありますか？
4. ロールアップの影響
   このためには、ロールアップは新しいインフラにオプトインする必要がありますか？ロールアップの手数料体系の変更点は何ですか？ロールアップがこのインフラに参加することで得られる可能性のある利点は何ですか？

ハイレベルな概要

主要利害関係者への変更概要

トラストレス相互運用性に向けた6段階の進化

1. L1非同期

必要なインフラストラクチャ:

N/A

定義どおり、これは現在のデフォルトのトラストレス相互運用性モードを指します。すべてのロールアップは、L1を決済レイヤーとして構築され、定期的に状態の更新を投稿してネットワークをセキュリティ確保するために、ブリッジ契約を介してのみそのL1にアクセスします。

この場合、信頼できるクロスロールアップアクティビティを実行する唯一の標準的な方法は、元のロールアップから資産を取り出し、標準的なブリッジを介してL1上で利用可能になった後、それらを手動でターゲットロールアップに入金することです。

楽観的ロールアップの場合、この引き出し遅延は、故障証明ウィンドウを考慮に入れて約7日です。ZKロールアップでは、引き出し遅延はより確実ではありませんが、ZkSyncの場合、15分から1日いっぱいの間である可能性があります。

また、スマートコントラクトを使用したピア・ツー・ピアのアトミックスワップも可能ですが、これはより小規模なユースケースであり、効果的にスケーリングされていません。

現在存在するサードパーティソリューションに注意する価値があります:

1. 流動性ブリッジ
2. インテントフレームワーク

私たちの両方の例には、第三者のソリューションが必要です。

自分に送信:

1. カノニカルに
   Rollup Aから資産を引き出す
   → Rollup B へ手動で入金する
2. 第三者：
   → リクイディティブリッジ / ソルバーネットワーク

クロスロールアップリミットオーダー

1. カノニカルに
   Rollup Aから資産を引き出す→
   → Rollup B に手動で入金する
   → リミット注文を実行する
   → 送り返すには、対象のERC-20を外部でラップする必要があります
2. 第三者
   → クロスロールアップリミットオーダーの新興ソリューションスペース
   → この目的を達成するためにインテントを使用するオープンな設計があります

これがデフォルトの場合であるため、UX、DevEx、MEV、およびロールアップの変更については議論する必要はありません。

2. アトミックインクルージョン

必要なインフラストラクチャ

共有シーケンサー *

アトミックインクルージョンは、クロスロールアップバンドルが次のブロックに含まれることを保証するだけです。

これには共有シーケンサーが必要ですが、もし2つの特定のロールアップのシーケンサーが最大スループットに達していない場合、手動でそれを行うことが理論的には可能です（各ロールアップに対して2つのトランザクションを単独で提出するだけで済みます）。これが、必要なインフラストラクチャにアスタリスクを追加した理由です。

ただし、共有シーケンサーが接続されたロールアップの各フルノードを実行しているとは限らないため、トランザクションのバンドルの成功実行を保証することはできません。この場合の共有シーケンサーは、トランザクションが適切に形成され、次のブロックに含まれることだけを保証でき、成功裏に実行されることを必ずしも保証するものではありません。

実行の保証がないため、トランザクションの 1 つが元に戻るリスクを負うことなく、意味のある方法でアトミック インクルードをプログラムで利用することは不可能です。その結果、基本的には L1 非同期の相互運用性とまったく同じ状況になります。

単純なクロスロールアップスワップを原子的なインクルージョン保証のみで開始することを検討してください。

1. クロスロールアップスワップバンドル
   → Tx 1：ソースロールアップ上でトークンをロック/燃やす
   → Tx 2：宛先ロールアップ上のユーザーアドレスにトークンを発行

それぞれのロールアップの次のブロックに実際に両方の取引が含まれているという原子的な包含の保証があるかもしれませんが、最初の取引がリバートされ、2番目の取引がされない場合、ユーザーは元のチェーンでそれらをロックしたり燃やしたりせずに、宛先チェーンで誤って資金が割り当てられ、二重支払いの問題が発生する可能性があります。

いかなる相互運用ソリューションも、流動性ブリッジ、意図フレームワーク、またはxERC-20スワップであろうとも、このリスクに対して脆弱であり、それを軽減することは不可能です。このリスクのため、現在のソリューションでは、送信トランザクションが成功裏に実行され、ソースチェーンのブロックに含まれていることが必要であり、リレーサーを使用して発信されたメッセージを渡し、宛先チェーンで第2のトランザクションを実行する前に。

重要なポイント：アトミックインクルージョンは相互運用性の可能性にほとんど影響を与えません

3. 共有決済

必要なインフラストラクチャ：

証明集約層 // 共有ブリッジ契約書

ここからがさらに興味深い部分です。L1からのロールアップエコシステムに預けられたすべての流動性は、共有ブリッジ契約の結果、すべての接続されたロールアップ間で自由に移動できます。この時点まで、正規チャネルを通過することなく、外部アセットのラッピングをせずに、または第三者ソリューションを使用せずに、ロールアップ間でのスワップを実行することはできませんでした。

共有ブリッジ契約を構築する理由は何ですか？共有ブリッジ契約を持つことで、ロールアップ間で資産をトラストレスに移動することが可能になる理由を理解するには、ロールアップAにEthを持っていて、それを燃やし、共有ブリッジ契約がない状態でロールアップBでネイティブにミントできる場合に何が起こるかをまず考えてみてください。L1に共有ブリッジ契約が存在しない場合、EthをロールアップAで持ち、それを燃やし、ロールアップBでネイティブにミントできるかどうかを考えてみてください。

各ロールアップがメインネット上のブリッジ契約と同期しなくなることがわかります。 ロールアップBのブリッジ契約にはまだ50 Ethありますので、ユーザーは1 EthをL1に引き出すことができません。

これを解決するために、外部資産ラッププロトコルが構築され、ネットワークの他の場所を象徴するロールアップ全体でトークンの外部ラップバージョンを発行します。

共有決済レイヤーを持つと、状況は異なります。各接続されたロールアップのすべての流動性が同じブリッジ契約にロックされているため、ブリッジ契約内の価値の総額が変わらず、いつでも引き出すことができるため、ロールアップ間を自由に移動できます。

L1契約レベルで更新が必要ですどこ流動性はユーザーがどこからでも引き出すことを可能にするためのものですが、すべての接続されたロールアップは共有契約に読み書きすることができるため、これは些細な問題です。

共有決済レイヤーを使用すると、単純な自己宛送信の場合、フローは次のようになる可能性があります。

送信先自身：

1. ユーザーが最初の取引を作成します：
   → Tx 1：ロールアップAでEthを引き出す（ロールアップBでそのメッセージを使って作成する）
   → トランザクションはバッチ処理され、L1契約に提出されます
   → すべての共有された決済ロールアップをグループ化するトランザクションルートに集約されます
2. Rollup Bはこのtxルートをインポートします
3. リレーは、Merkle Proofと一緒にmintする取引を提出して、ロールアップBに送信します
4. Rollup Bは、Merkle Proofとトランザクションルートを使用してバーントランザクションを検証します
5. ユーザーはRollup BでEthが鋳造されました
6. Rollup BがL1に証明を提出します

このフローを、共有決済エコシステム内のすべてのロールアップに契約を持つ任意のERC-20に拡張できます。

共有ブリッジ契約をプロトコル内のメッセージングレイヤーとして考えることができるため、このフローは理論的には任意のメッセージング標準に実際に拡張することができます。

これにより、コンポーザビリティに近づくことができますが、L1上の状態変更が反映された後に証明を集約し、メッセージを中継する必要があるため、高い遅延が発生します（ただし、L1の非同期ケースよりも顕著に低い）。さらに、ロールアップAの資産を使用してロールアップB上のDEXを使用するなど、複雑なクロスロールアップ活動は、クロスロールアップのリミットオーダーに対して依然としてユーザーにとって手間のかかるプロセスとなります。なぜなら、ユーザーはまだ自分自身に送金し、宛先のロールアップ上で資産を手動で交換する必要があるためです。この場合、原子的なクロスロールアップバンドルを作成することはできません。

共有決済のもう一つの重要な利点は、複数の環境で注文を約定させる流動性プロバイダーやソルバーにとって摩擦が少ないことです。接続されているすべてのロールアップの流動性は同じブリッジ限月に反映されるため、クロスロールアップの流動性を管理するために完全な引き出しウィンドウを待つ必要はありません。

ステークホルダーへの影響:

1. ユーザー:
   L1出金期間なしでネイティブ形式で資産を転送できるようになりました
2. 開発者:
   変更は、トークン発行者に限定され、これらは今、プロトコル内メッセージングを使用して、すべての接続されたロールアップでERC-20のネイティブバージョンを発行できます
3. MEVサーチャー：
   各ロールアップごとに複数のブロックでこれが発生するため、新しいMEVポテンシャルはありません
4. ロールアップ：
   ロールアップは、共有ブリッジ契約の使用を選択する必要があり、おそらくクロスロールアップメッセージを処理するためにプリコンパイルを追加する必要があります

重要な要点：共有決済により、外部ラップされていないアセットの転送や、ブリッジ契約および証拠集約レイヤーを共有するすべてのロールアップ間での任意のメッセージングが可能となりますが、無視できない遅延がまだ発生します（L1 Asyncよりはるかに短いですが）、また、クロスロールアップのアトミックバンドルを作成することはできません。

4. アトミック実行

必要なインフラストラクチャ：

共有シーケンサー // スーパービルダー

アトミック実行により、クロスロールアップバンドルの成功した実行を保証することができますが、依存トランザクションを持たないクロスロールアップバンドルのユースケース数は、最初に期待されるほど多くはありません。

一連の依存トランザクションにおいて1つのトランザクションがリバートされると、他のすべてのトランザクションが無効になり、リバートする必要があります。これはロールアップ間でトークンを焼却および鋳造する場合と同様です。宛先ロールアップでトークンを鋳造するには、ソースロールアップで焼却またはロックされたことが前提となります。つまり、焼却および鋳造トランザクションの束は依存トランザクションの束であると言えます。

このバンドルを作成するには、宛先トランザクションを作成できるスーパービルダーなどの中間者なしには不可能です。

クロスロールアップスワップバンドルをユーザー以外の別の当事者なしに構築するために真実である必要があることを考えてください。バンドルを作成して、ソースロールアップ上で資産をロック/焼却し、宛先ロールアップ上で資産を作成する必要がありますが、問題が発生します。

1. ソースロールアップ上の契約は、元のソースアセットをロック/燃やすときにのみメッセージを発行でき、宛先ロールアップ上でトランザクションを呼び出すことはできません。
   → これがメッセージプロトコルやリレーネットワークが存在する理由です。
   → メッセージは、呼び出し先で行うべき操作の構造を決定するために使用できますが、実際にトランザクションを作成することはできません。
2. mintするために、宛先のロールアップで2番目のトランザクションを作成します:
   → ユーザー自身は、ロールアップB上のトークンの発行権を持っていないため、このtxを作成することはできません
   → つまり）宛先チェーンは、トークンがソースチェーンで燃やされたりロックされた証拠が必要ですが、この証拠は初回トランザクションが実行されてから利用可能になるため、これはアトミック性の要件を破ることになります。
   → 二番目のトランザクションを作成できる可能性がある他のいかなる当事者も、最初に「燃やす」またはソースにロックを作成しなくても、いつでも宛先チェーンで「ミント」トランザクションを作成できる可能性があり、これは大きな脆弱性です。

クロスロールアップバンドルの実行を保証できたとしても、価値のある資産を転送するために最初にそれらをどのように構築するかに困難に直面しています。

ただし、依存するクロスロールアップバンドルなしでのアトミック実行のユースケースはまだいくつかあります。その1つは、クロスロールアップアービトラージです。

アトミック実行でのクロスロールアップDEXアービトラージ

これらの取引には厳格な依存関係がないため、誰でもこのアトミックバンドルを作成し、アトミックな実行を保証する共有シーケンサーに提出できます。

ただし、最初に原子実行の保証を得るには、ロールアップは共有シーケンサーとスーパービルダーにオプトインする必要があります。これにより、すべての接続されたロールアップのフルノードが実行され、原子実行からブロックレベルの組み合わせ可能性へのステップは非常に小さくなります。すべての共有シーケンスソリューションがこれを行うでしょう。必要な唯一の変更は、ブロックビルダーまたは別の第三者が、ユーザーのかわりにトランザクションを作成して依存するクロスロールアップバンドルを完了できるようにすることです。

原子的な実行のみを許可するインフラが構築される可能性は低いですが、さらに進んで相互運用性を持つようになることはあり得ます。フルブロックレベルの相互運用性に飛び込む相対的な利益は、すでに原子的な実行を持つインフラがあるという状況を考慮すると、それを達成する難しさをはるかに上回ります。

ステークホルダーへの影響:

1. ユーザー:
   おそらく変更はありませんが、第三者の手助けソリューションが意図のように原子的になる可能性はありますが、具体的にはどのようになるかは明確ではありません
2. 開発者:
   おそらく変化なし
3. MEVサーチャー：
   クロスロールアップアービトラージは、アトミック実行が与えられた場合、はるかに安全です
4. ロールアップ:
   ロールアップは、相互運用したい各ロールアップからトランザクションを含むブロックを提出する共有シーケンサー/スーパービルダーの使用を選択する必要があります。これにより、ロールアップの収益構造が変わる可能性があります。どのように変わるかはまだ明確ではありません。

• シーケンシングマーケットプレイスは、洗練されたビルダーがToBスペースを購入することで、ロールアップの収益を増加させる可能性があります

重要なポイント: クロスロールアップバンドルは原子的に実行されることが保証されていますが、バンドルの一部を作成するスーパービルダーがいない場合、これらのバンドルがどのように構築されるかは明確ではありません。そのため、単独での原子的な実行が相互運用性にどのように影響するかは不明です。共有シーケンサー/スーパービルダーは、デフォルトでブロックレベルの合成可能性のために構築するべきです。

5. ブロックレベルの合成性

必要なインフラストラクチャ：

共有シーケンサー // スーパービルダー // プルーフ集約レイヤー// 共有ブリッジ契約

(* = optional)

共有シーケンサーや共有決済レイヤーに関する議論の多くでは、この相互運用性レベルを表すためによく使われる用語は「同期コンポーザビリティ」です。

この用語をわかりやすくするために若干修正しました。ブロックレベルの組み合わせ可能性という用語を更新することで、次のブロックに正常に含まれ、実行されるクロスロールアップトランザクションの束内で2つのロールアップ間で構成することが可能であることを意味します。同期的な組み合わせ可能性は、次のセクションで探求するトランザクションレベルの組み合わせ可能性と混同される可能性があります。重要なのは、これには中間者（共有シーケンスインフラストラクチャ）が必要であり、依存トランザクションの束の指揮者および作成者となることです。

このレベルでは、ロールアップ間での真のコンポーザビリティが見られるようになり、単に自分自身に送信するだけでなく、別のロールアップ上でのDAppに参加することが可能になります。

共有シーケンサーを追加することで、トランザクションを作成できるようになり、開発者がプログラムで活用できるクロスロールアップバンドルを作成できるようになりました。

次の 2 つのケースを考慮する必要があります。

1. ブロックレベルの組み合わせ可能性
2. ブロックレベルコンポーザビリティ+共有決済レイヤー

両方のケースで、より複雑なアクティビティのためにクロスロールアップバンドルを作成することができますが、共有決済の場合はネイティブアセットを使用できるため、クロスロールアップDEXアクティビティへの価格への影響がより良い可能性があります。

ブロックレベルの合成性を持つことで、原子的な実行の利点と、依存するトランザクションバンドルを作成する能力を両方とも持っています。2つの例を見てみましょう。

同じトークンの転送、xERC-20経由（共有決済なし）：

1. ユーザーはERC-20を持っています
2. ユーザーはDappを介してtxを作成します:
   → xERC-20ロックボックスにERC-20を預け入れて、xERC-20包装版を受け取る
   →バーンxERC-20
   → 共有シーケンスインフラに、クロスロールアップ転送が開始され、スワップを容易にするための関連データを示すメッセージを送信します
3. スーパービルダーがトランザクションをピックアップし、クロスロールアップ・バンドルを作成します。
   → Tx 1: 前述のラップおよび燃焼トランザクション
   → Tx 2：ロールアップ B で xERC-20 を作成する
4. Superbuilderはこのクロスロールアップを共有シーケンサーに提出します
   → スーパービルダーは、2つの接続されたロールアップのフルノードを実行しているため、トランザクションをシミュレートしてバンドルの成功した実行を保証します。いずれかのトランザクションがリバートされると、バンドル全体がリバートされます。
5. 共有シーケンサーは、両方のトランザクションを含むブロックをDAレイヤーおよび状態変更を実行するノードに提出します
6. xERC-20はRollup B上のユーザーに鋳造されます

共有決済レイヤーを備えることで、流れがさらに簡素化され、最初にERC-20をxERC-20としてラップする必要がなくなります。

今度は、クロスロールアップリミットオーダーを調査しましょう。これは、ロールアップAから異なるイニシャル（異なる）ERC-20を使用して、ロールアップBでERC-20を購入し、結果のERC-20をロールアップAに送信するものです。この場合、共有決済レイヤーを持っているとは仮定していませんが、同様のフローが存在する場合があります。唯一の違いは、アセットを外部でラップする必要がないことです。

この場合に必要な取引は次のとおりです:

1. ERC-20を包んで燃やす
2. B上でxERC-20をミントする
3. B上で初期xERC-20をターゲットERC-20と交換する
4. BでのWrap and BurnターゲットERC-20
5. AでxERC-20をミントする

こちらは、これがどのように機能するかの潜在的なフローです:

クロスロールアップリミットオーダーは、ブロックレベルのコンポーザブル環境で実行されます

フロー:

1. ユーザーが最初の取引を開始します:
   →指定されたスワップパラメータ（送信先チェーン、DEXアドレス、スワップするERC-20、リミットオーダー価格、返送するかどうかのブール値）を伝えるメッセージを含むxERC-20をラップしてバーン
2. スーパービルダーが取引を見てバンドルを作成します:
   → Tx 1: ユーザーは上記のようにtxを作成します
   → Tx 2：宛先でxERC-20を発行します（スーパービルダーは発行権限を持っている必要があります）
   → Tx 3: Tx 1からのデータを使用した指値注文
   → Tx 4: Wrap and Burn ERC-20 on B assuming full fulfillment on limit order with message to mint on source chain
   → Tx 5：ソースチェーン上のスワップの出力からターゲットxERC-20をミントする

スーパービルダーはブロックを作成し、取引を順序付けるため、各取引をシミュレートして、いずれかの取引がリバートする場合にはバンドルを省略することができます。たとえば、ユーザーがリミットオーダーで完全な履行を受け取らないことがわかった場合、ブロックが実行される前にバンドルは省略されます。

共有決済レイヤーなしで共有シーケンスインフラの場合、EthとxERC-20の外部ラップバージョンを使用する必要があり、これによりラップされた資産の流動性プールが薄くなり、DEXの市況が悪化する可能性があります。この場合、ユーザーはより許容スリッページを持つ柔らかい制限を使用し、最適でない価格を受け取ることがあります。これにはUSDCが関与する場合が例外です。共有決済なしの共有シーケンサーがロールアップ間でネイティブUSDCの転送とスワップを促進するために、Circleと協力してUSDC契約の独占的な権利を取得することが可能です。

共有の決済レイヤーを持つため、この外部の包みは必要ありません。また、ネイティブアセットのスワップのための深い流動性プールにより、おそらくより良い価格を提供しますが、流れは基本的に同じです。

楽観的な信頼性のあるシーケンサー

ロールアップは、楽観的に共有シーケンサー/スーパービルダーを信頼する必要があります。これは、各ロールアップのチェーンにブロックが追加され、L1の決済レイヤーに集約されるまで、個々のロールアップが検証できない依存トランザクションが含まれているためです。ソースから宛先へのEthの初期燃焼と鋳造が例です。ソースチェーンでEthが実際に燃やされてから、宛先チェーンで鋳造される必要があるため、ダブルスペンドが可能になります。

しかし、この完全なバンドルを1つのブロックで実行するには、そのブロックにすべての取引が存在している必要があります。たとえ取引がブロックそのものよりも前の状態を表していても（たとえば、ユーザーがブロックの前にEthを持っていない場合でもスワップのための宛先チェーンにEthを持っている場合）、クロスロールアップバンドルに有効な依存関係が実際に含まれていることをシーケンサーに信頼する必要があります。あとで各取引の妥当性を証明するために証拠を提出することもできます。

これは、Wrappedアセットを使用する際には若干重要ではありませんが、それらはL1に格納されているネイティブな流動性に影響を与えないため、依然としてフォールバックメカニズムを備えておく必要があります。これにより、悪意のあるシーケンサーまたはコードのバグにより、依存トランザクションが巻き戻された状態でトランザクションバンドルが実行されるリスクに対抗する必要があります。

ステークホルダーへの影響:

1. ユーザー
   1ブロックでクロスロールアップリミットオーダーを許可するためのUXの大規模なアップグレード
2. 開発者
   クロスロールアップアクティビティに対応するためには、おそらくカスタムプリコンパイルを活用する必要があります。取引だけでなく、開発者はバンドルの観点で考える必要がありますが、おそらくスーパービルダーやカスタムロールアップインフラストラクチャが、ほとんどの開発者の複雑さを抽象化することができるでしょう。
3. MEVサーチャー
   MEVサーチャーは、基本的にクロスロールアップバンドル上でL1戦略を利用する機会がほぼ同等ですが、それはPBS（Proposer-Builder Separation）の実装方法に依存します。
   → クロスロールアップバンドルは基本的に単一の取引と見なされるため、許容されるスリッページ量の範囲外に価格を動かさない限り、フロントランニングやサンドイッチングによって MEV を見つけることができます（さもないと、全体のバンドルがリバートされ、MEV の試みは失敗します）
4. ロールアップ
   共有決済レイヤーの場合、共有シーケンサーへのEthの燃焼/鋳造へのアクセスを許可する必要があり、共有シーケンスインフラストラクチャ（スーパービルダーを含む）にオプトインする必要があります。
   ビルダーにブロックスペースを売ってMEVを内部化することができます

6. トランザクションレベルの合成性

必要なインフラストラクチャ:

VM-Level Changes // 共有決済 // スーパービルダー

トランザクションレベルのコンポーザビリティとは、1つのEVMチェーン上のスマートコントラクトが共有するのと同じレベルの機能を指します。この場合、1 つのトランザクションで複数のロールアップの状態を同時に更新し、呼び出しが正常に返されなかった場合に、呼び出し前の状態変更を元に戻すことができます。実際には、ブロックレベルのコンポーザブル環境でのトランザクションのアトミックバンドルは、単一のクロスロールアップおよびクロスVMトランザクション内で実行できます。これには、共有決済レイヤーとスーパービルダーに加えて、接続されているすべてのロールアップに対して VM レベルの変更が必要です。

ここでは、考えられるメカニズムを大まかに説明します。(この構造は、私たちの知識によると、エスプレッソチームによるものです)。まず、ユーザーは、トランザクションによって状態が変更されたすべてのロールアップ、または関連するすべてのロールアップでブロックを作成できるスーパービルダーにクロスロールアップ トランザクションを送信します。スーパービルダーは、トランザクションをシミュレートし、関係するロールアップごとに 1 つずつ、トランザクション内で必要なクロスロールアップ・メッセージと予期されるクロスロールアップ・メッセージを指定する入出力ペアのリストを作成します。(スーパービルダーは、一定期間、関係するすべてのロールアップに対する安全なシーケンス権限を持っている場合にのみ、これを行うことができます)。次に、スーパービルダーは、シミュレートされたブロックを、各クロスロールアップ・トランザクションで予想される入出力ペアのリストとともに、各ロールアップの提案者に送信します。実行中、各ロールアップは、クロスロールアップ トランザクションのリストからの入力が正しいと仮定して、通常どおり独自の状態遷移関数を実行します。決済中、インプットとアウトプットのリストを相互比較し、共有決済レイヤーのプルーフアグリゲーションフェーズで安全性を証明できます。具体的には、クロスロールアップ トランザクションで予期される入力が、別のロールアップが出力として指定した入力と一致しない場合、決済プロセスはクロスロールアップ トランザクション全体を拒否します。

フラッシュローンを超えたトランザクションレベルのコンポーザビリティによって解除される新機能は限られていますが、クロスロールアップアプリケーションを作成するための開発者体験を大幅に向上させることができます。クロスロールアップバンドルについて考えることなく、すべての接続されたチェーンとやり取りするdappを作成できる能力は、マルチロールアップの景観で革新することをはるかに容易にします。さらに、新しいユースケースや動作が新たに現れる可能性もあります。

トランザクションレベルの相互運用性に関する多くのオープンな設計上の問題があります。まず、デベロッパーがスマートコントラクトのニーズについてクロスロールアップ呼び出しに参加または参加しないかをどのように慎重に検討するかが重要です。制限なしに任意の相互運用性を許可すると、1つのモノリシックなロールアップに逆戻りしてしまう可能性があります。私たちの考えでは、デベロッパーが明示的にクロスロールアップの相互運用性が必要な場所を契約で示す必要があると考えています。たとえば、Solidityの修飾子を使用して示すことができます。コンポーザブル契約の特定のエントリポイントをクロスロールアップ可能としてマークします。

ステークホルダーへの影響

1. ユーザー:
   ブロックレベルの合成性と同じ意味を持ち、フラッシュローンなどの追加の高度な機能を備えています
   → UXは、オプトインするdappsのために1つのチェーンを使用することとほぼ同じです
2. Devs:
   Dappデベロッパーは、ネイティブで契約をクロスロールアップして呼び出し、これらの呼び出しからの出力を単一のロールアップ呼び出しと同様に使用することができるため、開発者の経験が大幅に向上します
   →スーパービルダー/シーケンサーインフラは、クロスロールアップコールが影響を与えるロールアップにトランザクションをブロックに配置する必要がありますが、ブロックレベルの合成性の場合と同じバンドルを構築する必要はありません。
3. MEV検索者:
   クロスロールアップバンドルのMEVポテンシャルが高く、現在は実質的に1つのチェーン上の単一トランザクションとほぼ同等です
4. ロールアップ：
   VMレベルの変更と、共有シーケンサーおよび共有決済レイヤーへのオプトインが必要です \
   他のロールアップの入出力を信頼し、状態を証明する前に追加の信頼前提が関与しますが、スラッシングメカニズムによって信頼の負担を軽減することができます

サマリーとエコシステムマップ

ここで定義された相互運用性の各レベルの技術的詳細を歩くことの後、要約することができます。

1. Shared Settlementは、外部でアセットをラップすることなく、相互にロールアップしたスワップを可能にし、すべての接続されたロールアップ間でプロトコル内メッセージング経路を作成します
2. 共有シーケンス/スーパービルダーは、クロスロールアップバンドルで次のブロックの実行を保証します
3. ブロックレベルコンポーザビリティを使用すると、複雑で高速で依存関係のあるクロスロールアップバンドルを作成し、スマートコントラクトからスマートコントラクトレベルのコンポーザブルエコシステムを実現できます。
   → 共有決済の追加により、これらのクロスロールアップバンドルは外部でラップされた資産を使用せずに作成することができます
4. トランザクションレベルのコンポーザビリティは可能であり、新たに開かれたユースケースはより洗練されたユーザー向けかもしれませんが、クロスロールアップ開発体験を大幅に向上させる可能性があります。

現在、これらのネイティブで相互運用可能なエコシステムを作成するために多くのプロジェクトが登場しています。以下は、その景観の高レベルな概要です。

エコシステムマップ

エコシステムマップ

クロージングの考え

この記事で示されたフレームワーク内の技術的微妙点に関する未解決の問題がまだあります。たとえば、クロスロールアップリミットオーダーのためのブロックレベルのコンポーザブルエコシステムでのバンドルの構築には、部分的な履行や市場注文のスリッページ許容を処理するためのより詳細な設計が必要かもしれません。注文が完全に埋まっていない場合にクロスロールアップリミットオーダーバンドルを元に戻すための1つの潜在的な解決策を提供しましたが、設計空間はオープンです。

さらに、これはアプリチェーンに関して現在のマインドシェアと関連している価値があります。 アプリチェーンは、一般的または許可された長尾のL2であり、特定の関連プロトコルをL2の1つに隔離することを目的としています。 ブロックレベルの合成性に到達すると、すべての接続されたネットワーク間でネイティブな合成性を持つ結果として、アプリチェーン環境が大きなトラクションを得ることがあります。

現時点では、これらのアプリチェーンに流動性を提供することはまだ困難ですが、より大規模なチェーンが相互運用可能な環境へのオンランプとして接続すると、共有インフラストラクチャを中心に壁のある庭園エコシステムが現れる可能性が高いです。

もう1つの重要な未解決の問題は、スーパービルダーのデザインスペースがどのように落ち着くかです。この分野の開発はまだ非常に新興ですし、洗練されたビルダーのネットワークを作成し、クロスロールアップバンドルを作成できる最も効率的かつ効果的な方法がまだ明確ではありません。これらのクロスロールアップバンドルが最適にブロックに含まれる場所、およびロールアップ収益への影響は、多くのチームによって検討されている異なる戦略による未解決の問題です。

最終的には、将来、プロトコル内およびプロトコル外のブリッジソリューションの組み合わせが関係者全員にとってはるかに優れた相互運用性プロセスを提供するために協力して機能することになるでしょう。この記事で定義された進化は、エンドユーザー向けのクロスロールアップ相互運用性をよりシームレスにすることに焦点を当てた開発者やビルダーにとって、ガイドとして役立つと考えています。

クロスロールアップの相互作用に関する完全に新しいパラダイムが発見される可能性もあります。ここで取り上げられていないアプローチに取り組んでいるビルダーである場合、お願いします。リーチアウト(dms are open). テクノロジーはついに十分に成熟し、流動性/エコシステムの断片化に対する解決策を見つけるために本当のプレッシャーをかけることができました。そして、私たちは常に、クリエイティブな解決策を構築するためにリスクを取っている創業者とつながりたいと考えています。

謝辞

この記事は、EthCCで1kxが開催した非常に洞察に富んだロールアップ相互運用性円卓会議から生まれました。特別な感謝を捧げます。Noah Pravecek、エリー・デイビッドソン、そしてテリーこの記事の初期バージョンを読んでフィードバックを提供してくれた方々、およびMarti, mteam, そして ボ ドゥその件に関するさらなる会話のため。

免責事項：

1. この記事は[から転載されましたミラー元のタイトル'ロールアップ間の信頼性のない相互運用性: ランドスケープ、構築、および課題'を転送します。著作権はすべて元の著者[Marshall Vyletel Jr.]に帰属します。この転載に異議がある場合は、お問い合わせください。Gate Learnチームが promptly それを処理します。

2. 責任の免責事項：この記事で表現されている意見は、著者個人のものであり、いかなる投資アドバイスを意味するものではありません。

3. 記事の翻訳はGate Learnチームによって行われます。特記されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。