ロールアップ同士の信頼不要な相互運用性：概要、構築、および課題

著者：マーシャル・ヴィレテルJr. ソース：*1kx 翻訳：シャンオッパ、ゴールドエコノミー

イントロダクション

ETHプロトコル上のrollupの数は急激に増えています。L2Beatのデータによると、本文執筆時点で、すでに91個のL2とL3がリリースされ、82個のリリースが予定されています。そのため、流動性、ユーザーエクスペリエンス、開発者ツールの面でも多くの断片化が存在しています。現在の相互運用性の解決策は改善の余地があります。というのも、それらは第三者のブリッジエータ、外部包装資産、意図フレームワークの組み合わせに依存しており、それぞれに問題があるからです。

1. 流動性橋は通常、最大の暗号資産ハッカー攻撃の標的となります（例えば、3.21億ドルの虫洞橋ハッカー攻撃の価値があります）
2. 外部包装の資産は歓迎されていません。データによると、可能な限り、人々は資産をネイティブの形式で保有することを好む傾向があります（たとえば、L2Beatのデータによると、橋渡し資産の価値は220億ドルであり、外部包装の資産の価値はわずか30億ドルです）
3. インテントフレームワークはサードパーティに依存しており、これらのサードパーティには無視できない信頼が必要であり、クロスロールアップアクティビティを促進するために追加料金が請求される（たとえば、公式ブリッジの不適切さにより、Degenチェーンのユーザーは80%以上のトークンを失いました）。中央集権化されたインテントフレームワークは競争が低くなることを意味し、これにより価格設定とパフォーマンスが理想的でない可能性があります

本文では、分散型のRollupエコシステム間の6つのレベルの相互運用性ソリューションを定義し、議論することで、信頼できる相互運用性の展望を調査します。01928374656574839201

デフォルトの状態から始めて、ソースロールアップから非同期でL1に引き出し、手動でブリッジしてターゲットロールアップに到達し、最終的には単一トランザクションでクロスロールアップの組み合わせ可能性の仮定的なアーキテクチャで終了します。各レベルの相互運用性がユーザーエクスペリエンス、開発者エクスペリエンス、MEVポテンシャル、およびロールアップ自体（特定のインフラストラクチャの変更に関連して）にどのように影響するかを検討します。

本文は、イーサリアムおよびそのL2について、そして信頼を必要としないインターオペラビリティに関してのみ議論します。この場合、「信頼を必要としないインターオペラビリティ」とは、プロトコル内のチャネルであり、ほとんどのロールアップで必要とされる基本的なインフラ以外の第三者を必要とせずに転送を促進します。

事前準備

定義

根本的には、信頼が不要な相互運用性には共有リソースが必要であり、相互運用を望む2つのプロトコルはこれらのリソースにアクセスできる必要があります。ETH坊 L1の場合、すべてのスマートコントラクトは共有ETH坊完全状態の同じ環境に存在しているため、常に最高レベルの相互運用性を持っています。しかし、L2は単独のブリッジ契約を介してのみ決済層を共有しており、そのため相互運用性が大きく制限されています。

信頼なしの相互運用性の段階で私たちを前進させるための鍵となる共有インフラストラクチャコンポーネントは、共有オーダラー、スーパービルダー、そして共有決済です。これらの共有レイヤで開かれた保証と新機能は関連していますが、本質的には直交しています。

1. 共有シーケンサー/スーパービルダー：速度とユーザーエクスペリエンスの主な向上。
2. 共有決算：外部パッケージやプロトコル内のメッセージングが必要なく、資産スワップが行われます。

まず、引用で言及されている6つの信頼性のない相互運用性レベルを定義します:

1. L1非同期:
   →決済のL1を集約して手動で資産を移動し、相互運用性を実現します。
2. 原子が含まれています： → すべてのトランザクションが次のブロックに含まれるように、ロールアップバンドル内のすべてのロールアップに含まれるか、または含まれないようにする。
3. 共有請求:
   → 複数のロールアップが同じブリッジ コントラクトを介して L1 に接続されます。 4.アトミック実行:
   → すべてのトランザクションがバンドルに含まれ、関連するすべてのロールアップの次のブロックで実行され、それ以外の場合は実行されないことを保証します。成功した実行は、各トランザクションがロールバックされることなく実行され、バンドル内のすべてのロールアップの更新状態に反映されることを意味します。
4. ブロックレベルの組み合わせ可能性： → クロスロールアップバンドルの次のブロックには、依存トランザクション（Rollup Bのtx BはRollup Aのtx Aの結果に依存）が含まれることが保証されます
5. トランザクションレベルのコンポーザビリティ:
   → スマートコントラクトレベルの相互運用性は、複数のロールアップ間での状態変化（バンドルなし）を一度のトランザクションで実現するだけで可能です。任意のロールアップ上で任意のプロトコルを使用することは、論理的には異なるスマートコントラクトを使用することと同等です。重要なのは、呼び出し前の状態変更は返される際に復元される可能性があるということです。

各レベルをより深く理解するために、以下のキーユースケースを紹介し、各レベルの機能とユーザー、開発者、集約者、およびMEVの探索者への影響を示します。

サンプル:

1. 同じトークンの転送 → 自分宛てに送る: 2 つのロールアップ間で ETH を ETH に、または ERC-20 を ERC-20 に交換する
2. トークン購入 → クロスロールアップ制限注文：ロールアップAのEth/ERC-20を使用して、ロールアップBのDEXで異なるERC-20を購入し、（オプションで）ロールアップAに送信します

意味:

私たちは、どのようにして何人かの主要な利害関係者に影響を与えるかをさらに理解するために、以下の質問にも答える予定です。

1. ユーザーエクスペリエンス
   このレベルの相互運用性を実現することによって、ユーザーエクスペリエンスはどのように変化するでしょうか？
2. 開発者エクスペリエンス このレベルの相互運用性を実現することで、開発者のエクスペリエンスはどのように変化しますか？
3. MEV ポテンシャル このレベルの相互運用性を実現した場合、新しい MEV 機会が生じる可能性があるのでしょうか？
4. ロールアップの影響 Rollupは、これを実現するために新しいインフラストラクチャに参加する必要がありますか？Rollupの料金構造にはどのような変更がありますか？Rollupがこのインフラストラクチャに参加することで、どのような潜在的な利点がもたらされる可能性がありますか？

ハイレベルな概要

信頼性のない相互運用性への6つの段階への進展

1. L1 非同期

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

適用されません

定義によると、これは現在のデフォルトの信頼できないインターオペラビリティモードを指します。すべてのロールアップはこのように定義されています。なぜなら、それらはL1の上に構築された決済レイヤーとして機能し、L1にブリッジ契約を介してのみアクセスできるためです。彼らは定期的にネットワークを保護するために状態更新を発行します。

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

Optimistic Rollupの場合、セキュリティウィンドウを考慮して引き出しのレイテンシーは約7日です。ZK Rollupでは、引き出しのレイテンシーははっきりしないですが、15分から1日程度の間である可能性があります。ZkSyncも同様の状況です。

また、スマートコントラクトを使用してピアツーピアのアトミックスワップを行うことも可能ですが、これは比較的小規模なユースケースであり、効果的に拡張することはできません。

注意すべきは、現在存在する第三者の解決策です:

1. モビリティブリッジ
2. インテントフレームワーク

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

自分宛てに送る:

1. 標準的なやり方： → ロールアップ A からの資産の引き落とし
   ロールアップ B を手動で入金→
2. サードパーティ： → リキディティブリッジ/ソルバーネットワーク

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

1. ルール： → ロールアップ A からの資産の引き落とし
   →手動入金 ロールアップ B →注文を成行で執行する →返送するには、対象のERC-20を外部でラップする必要があります
2. 第三者
   → 新興のクロス集計制限価格注文のソリューションスペース → 使用意図を促進するためにオープンな設計が取り囲む

これがデフォルトの状態であるため、UX、DevEx、MEVおよび集約の変更については議論する必要はありません。

2. 原子を含む

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

共有シーケンサー *

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

これには共有のソータが必要ですが、理論的には、与えられた2つのロールアップのソータが最大スループットに達していない場合、手動で実装することもできます（各ロールアップに2つのトランザクションを提出するだけです）。これが私たちが基盤に星印を追加した理由です。

しかし、私たちはすべての接続されたロールアップの完全なノードが共有ソーターを実行するとは仮定していませんので、一連の取引の成功を保証することはできません。この場合、共有ソーターは取引のフォーマットが正しいことと次のブロックに含まれることだけを保証できますが、必ずしも成功するとは限りません。

実行保証がないため、プログラムで原子的に含める方法であっても、取引の1つが取り消されるリスクを負わずに完全に L1 Async と同じ状況にあります。

原子的な含まれている保証のみを持つシンプルなクロス集計交換を開始することを検討してください：

1. クロスロールアップ取引のバンドル化 → Tx 1: ソースのRollupでトークンをロック/バーンする → Tx 2：目標のRollup上のユーザーアドレスにトークンをミントする

私たちが保証する可能性があります、つまり、2つの取引が実際にはそれぞれの次のブロックに含まれていますが、最初の取引がロールバックされ、2番目の取引がロールバックされない場合、ユーザーは誤って資金をオンチェーンで目的の割り当てられることになりますが、それらをソースオンチェーンでロックしたり破棄する必要はありません。このような場合には、ダブルスペンディングの問題が発生します。

流動性ブリッジ、意向フレームワーク、xERC-20トークン交換など、どの相互運用性ソリューションもこのようなリスクの影響を受けやすく、このリスクを軽減することはできません。このリスクがあるため、現在のソリューションでは、トランザクションの発行者はオンチェーンのブロックに含まれ、実行されたことが確認された後に、リレーヤーを使用して発行されたメッセージを送信し、目的のオンチェーンで第2のトランザクションを実行する必要があります。

重要なポイント：アトミックスワップは相互運用性の潜在能力に重大な影響を与えません

3. 共有請求

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

プルーフ・オブ・アグリゲーション・レイヤー // 共有ブリッジ契約

ここで事がより面白くなります。共有ブリッジ契約が存在するため、L1に入金されたすべての流動性は、接続されたすべてのロールアップ間で自由に移動できます。これまで、ロールアップ間で交換するには、規範的なチャネルを介さず、外部の資産をラップしたり、サードパーティのソリューションを使用する必要がありました。

共有のブリッジ契約を構築する必要があるのはなぜですか？共有のブリッジ契約を理解するには、ロールアップ間で信頼を必要としない方法で資産を移動することができる理由を考えてみてください。例えば、ロールアップAでETHを所有し、それを破棄し、ロールアップBでネイティブミントを行うことができる場合、Layer1で共有のブリッジ契約を構築する必要はありません。

私たちは、すべてのロールアップがメインネット上のブリッジ契約と同期していないことに気付きました。ロールアップBのブリッジ契約にはまだ50ETHが残っているため、ユーザーは1ETHをL1に引き出すことができません。

この問題を解決するために、当社は外部資産パッケージングプロトコルを設立し、集約中に外部パッケージングバージョンのトークンを発行し、これらのトークンはネットワークの他の場所のネイティブバージョンを象徴しています。

共有セトルメントレイヤーがあると状況は異なります。各接続されたrollupの流動性はすべて同じブリッジ契約にロックされているため、ブリッジ契約内の総価値が一定であり、常に引き出すことができるため、人々はrollup間を自由に移動することができます。

流動性がどこにあるかを把握するために、L1契約レベルでの更新が必要です。これにより、ユーザーはどこからでも引き出しを行うことができますが、すべての接続された集計は共有契約を読み取り/書き込みすることができますので、非常に簡単です。

共有の決済レイヤーを使用すると、自分自身に送信する場合のプロセスは次のようになります。

自分宛てに送る:

1. ユーザーが最初の取引を作成します： →Tx 1：rollup A でEthを引き出す（そして rollup B でミンティングする） →取引は分割され、L1契約に提出されます →それはトランザクションのルートに集約され、そのトランザクションのルートはすべての共有決済ロールアップグループを含んでいます
2. Rollup Bはこのトランザクションのルートをインポートします
3. リレーエータはトランザクションを鋳造工場に提出し、Merkle証明をrollup Bに提出します
4. Rollup B では、Merkle Proof およびトランザクションルートを使用して、削除されたトランザクションを検証します。
5. ユーザーはRollup B上でEthをミントしました
6. Rollup BはL1への証明を提出します

このプロセスは、共有決済エコシステム内のすべての集計に契約がある任意のERC-20に拡張することができます。

共有ブリッジ契約は、すべての接続の集約としてプロトコル内のメッセージパッシングレイヤーと見なすことができるため、理論的にはこのプロセスは任意のメッセージパッシングスタンダードに拡張できます。

これにより、コンポジション性に近づくことができますが、状態変化がL1で反映された後にのみ集約プルーフとメッセージングが必要なため、レイテンシーが高くなります（ただし、L1非同期の場合よりは明らかに低くなります）。また、複雑なロールアップ間のアクティビティ（例えば、ロールアップA上の資産からロールアップB上のDEXを使用してクロスロールアップ制限価格注文を開始する）は、ユーザーにとってまだ手間のかかるプロセスです。なぜなら、彼らはまだ自分自身に送信し、対象のロールアップで手動で資産を交換しなければならないからです。この場合、アトミックなクロスロールアップバンドルを作成することはできません。

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

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

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

重要なポイント：共有の決済では、共有ブリッジ契約およびプルーフ集約層で外部パッケージ化されていない資産の転送や任意のメッセージパッシングが可能ですが、無視できないレイテンシー（L1 Asyncよりはるかに短いですが）が発生し、クロス集約原子束を作成することはできません。

4. アトミック実行

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

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

原子実行により、クロスボリュームのバンドルの成功を保証できますが、依存トランザクションのないクロスボリュームのバンドルのユースケースは、最初に予想されたよりも少ないことがわかります。

もし依存するトランザクションの一つがキャンセルされた場合、他のすべてのトランザクションは無効になり、キャンセルされなければならない。これは、ロールアップ間でのトークンの破棄とミンティングの場合と同様です。ターゲットのロールアップでのトークンのミンティングは、ソースのロールアップで破棄またはロックされているかどうかに依存します。そのため、破棄とミンティングのトランザクションは依存関係のあるグループと言えます。

目標取引を作成する中間業者（例えば、スーパービルダー）がいない場合、このバンドルを作成することはできません。

他のユーザー以外の関係者が関与しない場合、クロスロールアップトランザクションのビルドにはどのような条件が必要ですか。ソースロールアップでのアセットのロック/バーンと、ターゲットロールアップでのアセットのミンティングを行うためには、バンドルパッケージを作成する必要がありますが、問題が発生しました:

1. ソースロールアップ上の契約は、元のソース資産をロック/破棄するときにのみメッセージを発行でき、ターゲットロールアップ上でのトランザクションの呼び出しや作成はできません。 →これはメッセージプロトコルとリレーネットワークが存在する理由です。 → メッセージは、ターゲットで呼び出しを構築するために使用できる必要がありますが、実際にはトランザクション自体を作成することはできません。
2. ターゲットロールアップでミンティングするための2番目のトランザクションを作成します： → ユーザー自身はこのtxを作成することはできません。なぜなら、彼らはrollup B上のトークンを作成する権限を持っていないからです →つまり）目標チェーンは、トークンがソースチェーンで焼却/ロックされていることを証明する必要がありますが、この証明は初期トランザクションの実行前まで利用できません。これは私たちの原子性の要件を破壊します。→理論的には、他のどのチェーン上でもトークンを燃やすことができますが、そのトークンは元のチェーン上でのみ生成されることになります。 ミント権を持つ第二のトランザクションを作成したい場合、目的のオンチェーンでいつでも「ミント」トランザクションを作成できます。元のオンチェーンで「破壊」またはロックを作成する必要はありません。これは大きな欠陥です。

私たちは見ることができますが、私たちは交差総括的な束ねられたパッケージの実行を保証できますが、価値のある資産を転送するために最初にそれらを構築する方法に困難を抱えています。01928374656574839201

ただし、cross-rollupバンドルに依存しないいくつかのアトミックな実行例がまだ存在しています。その1つがcross-rollupアービトラージです。

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

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

原子的な実行を許可し、さらなる組合せ可能性を実現しないインフラストラクチャを構築することは非常に困難です。インフラストラクチャはすでに原子的な実行機能を備えているため、完全なブロックレベルの組合せ可能性を実現することは、その困難さに比べて相対的な利益が非常に大きいです。

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

1. ユーザー： 変化は起こらないかもしれませんが、第三者が意図のような解決策を提供する可能性はありますが、具体的な実装方法はまだ明確ではありません 2.開発者:
   変わらないかもしれません
2. MEVサーチャー:
   原子実行を考慮すると、クロスロールアップアービトラージはさらに安全です
3. ロールアップ： Rollupは、相互運用性を望む各Rollupからのトランザクションを含むブロックを提出するために、共有ソータ/スーパービルダーを使用する必要があります。これにより、Rollupの収益構造が変わる可能性がありますが、現時点ではそれがどのように変わるかはまだはっきりしていません。- ソート市場は、成熟したビルダーがToBスペースを購入してロールアップ収益を増やすことを許可することで、増加する可能性があります

重要なヒント：ロールアップバンドルはアトミック実行を保証しますが、バンドルの一部を作成するスーパービルダーがない場合、これらのバンドルがどのように構築されるかはわかりません。したがって、アトミック実行自体が相互運用性に影響を与える可能性は低いです。デフォルトでは、共有シーケンサー/スーパービルダーはブロックレベルの組み合わせ可能性を構築する必要があります。

5. ブロックレベルの組合せ可能性

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

共有ソーター // スーパービルダー // 証明集約層* // 共有ブリッジ契約*

（* = オプション）

共有シーケンサーと共有決済層に関する議論では、このレベルの相互運用性を記述するために通常使用される用語は「同期可能性」です。

この用語を少し変更して、より具体的にしました。用語を「ブロックレベルの組み合わせ可能性」に更新すると、ロールアップ間でクロスロールアップトランザクションパッケージを組み合わせることができ、これらのトランザクションパッケージは次のブロックに含まれ、正常に実行されます。同期可能性はトランザクションレベルの組み合わせ可能性と混同される可能性がありますが、次のセクションで詳しく説明します。重要なのは、これには中間者（共有ソートインフラストラクチャ）が必要であり、トランザクションパッケージの実行者および作成者の依存先になることです。

このレベルでは、私たちは、単純に自分自身に送信するだけでなく、他のRollup上のdappに参加するための本当の組み合わせ可能性を見始めています。

共有シーケンサーを追加して取引を作成できるようになったため、クロス・カット包を作成し、開発者はプログラミングを通じてそれを利用できます。

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

1. ブロックレベルの組み合わせ可能性
2. ブロックレベルの組み合わせ可能性 + 共有決済レイヤー

この2つのケースでは、より複雑なアクティビティのためにトランザクション束を作成することができますが、第2のケースでは、決済を共有することで、ネイティブアセットを使用することができ、これはクロスアグリゲートDEXアクティビティにより良い価格インパクトをもたらす可能性があります。

ブロックチェーンの原子的な実行の利点と、トランザクションパッケージの依存関係を作成する追加の能力を持つ、ブロックレベルの組み合わせ性を活用することによって、2つのイラストレーション例を見てみましょう。

xERC-20を使用して同じトークンの転送を行います（共有決済なし）：

1. ユーザーはERC-20を所有しています
2. ユーザーはdappを使用してtxを作成します： →ERC-20をxERC-20ロックボックスに預け入れ、xERC-20パッケージ版を受け取る xERC-20を破壊する→
   →共有ソートインフラストラクチャにメッセージを送信して、クロスロールアップ転送が開始されたことを示し、関連データを添付して交換を促進します
3. Superbuilder は取引を拾い、クロスロールアップバンドルを作成します → Tx 1: 上記のラップとバーンのトランザクション
   → Tx 2：Rollup BでxERC-20をミントする
4. Superbuilderはこのクロスロールアップを共有ソーターに提出します。 → Superbuilderは、2つの連結したロールアップの完全なノードを実行しているため、彼らはペーパー取引を行い、バンドルが正常に実行されることを保証します。もし取引のいずれかがロールバックされた場合、バンドル全体がロールバックされます。
5. 共有ソータは、2つの取引を含むブロックをDAレイヤーに提出し、状態の変更を実行するノードに送信します
6. xERC-20はRollup B上でユーザーにミントされます

共有清算レイヤーがあると、プロセスがさらに簡素化されます。ERC-20をxERC-20にラップして交換する必要がないためです。

今、私達はクロスロールアップリミットオーダーについて見てみましょう。つまり、Rollup BでRollup Aの異なるERC-20を使用してERC-20を購入し、生成されたERC-20をRollup Aに送り返すことです。この場合、共有決済レイヤーがあるとは仮定しませんが、共有決済レイヤーがある場合には類似のプロセスが存在します。唯一の違いは、資産を外部でラップする必要がないことです。

このケースで必要な取引は次のとおりです：

1. AでERC-20を包装して破壊します 2.BでxERC-20をミントします
2. Bで元のxERC-20と目標のERC-20を交換する
3. B上で目標のERC-20をパッケージ化して廃棄する 5.xERC-20をミントします

以下は可能な作業フローです:

フロー：

1. ユーザーは最初の取引を開始します： →xERC-20をパッケージ化し、破棄し、交換パラメータ（ターゲットチェーン、DEXアドレス、交換するERC-20、制限価格注文価格、戻るブール値があるかどうか）を指定するメッセージを送信します
2. スーパービルダーはトランザクションを見てバンドルを作成します： → Tx 1: ユーザーが上記のトランザクションを作成します → Tx 2：目的地でxERC-20をミンティングする必要があります（スーパービルダーはミンティング権限を持っている必要があります） → Tx 3：tx 1からのデータを使用してリミット注文を行う → Tx 4：B上でERC-20を包装し、破壊し、指値注文が完全に執行されたと仮定し、元のチェーンにメッセージを送信してミントする → Tx 5：元のチェーンでの交換出力からミント目標 xERC-20

超级构建器がブロックを作成し、取引を整理するため、それにより各取引をシミュレートし、取引がキャンセルされた場合にはバンドルを省略することができます。たとえば、ユーザーが指値注文を完全に執行できないことが判明した場合、ブロックの実行前にバンドルを省略します。

共有された決済層のない共有並べ替えインフラストラクチャがない場合、EthとxERC-20の外部ラップバージョンを使用する必要があります。これは、パッケージ化された資産の流動性プールが薄くなり、DEXの市場状況が悪化する可能性があるためです。この場合、ユーザーはより緩和された制限、より高いスリッページ耐容度、およびサブオプティマルな価格を受け取る可能性があります。USDCが関係している場合、例外があります。共有された決済のない共有並べ替え機は、Circleと協力して、ロールアップを超えたUSDC契約の独占的権利を取得し、ロールアップを超えたネイティブUSDCの転送と交換を促進することができます。

共有決済層があるため、この外部の包装は必要ありませんし、ネイティブの資産スワップの流動性プールがより深いため、より良い価格を提供する可能性がありますが、プロセスは基本的に同じです。

楽観的にシーケンサーを信頼する

Rollupは、共有のソータ/スーパービルダーに楽観的に信頼する必要があります。これにより、効果的なクロスRollupバンドルが作成されます。これは、このクロスRollupバンドルには依存取引が含まれており、各Rollupはこれらの取引をそのまま検証することはできません。そのため、それぞれのRollupがオンチェーンにブロックを追加し、L1の決済層に集約するまで、これらの取引を検証することはできません。例えば、元のEthの破壊とETHのミントがあります。重要なのは、Ethが元のチェーンで実際に破壊され、その後ターゲットのチェーンでミントされることです。そうでないと、ダブルスペンディングの可能性があります。

しかし、この完全なバンドルを1つのブロックで実行するには、すべてのトランザクションがそのブロック内に存在する必要があります。つまり、トランザクションがブロック自体よりも前に無効な状態を表している場合でも（たとえば、ユーザーがブロックの前にEthを持っていない場合でも）、交換対象のオンチェーンに存在する Eth があります。したがって、私たちはソーターが実際に有効な依存関係を含めたバンドルを跨いでいることを信頼しなければなりません。後で、各トランザクションの有効性を証明するために証拠を提出することができます。

しかし、パッケージ化された資産を使用する場合、それらはL1に格納されたネイティブな流動性に影響を与えないため、それほど重要ではありませんが、悪意のあるソーターやコードによる誤動作のリスクを相殺するフォールバックメカニズムが必要です。これらのエラーによって、トランザクションバンドルが復元された依存トランザクションと一緒に実行されることが許容されます。

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

1. ユーザー ユーザーエクスペリエンスの大規模アップグレードを行い、単一のブロック内でクロス集計制限価格注文を許可します
2. 開発者
   クロスロールアップアクティビティには、クロスロールアップの意識が必要で、カスタムプリコンパイルを使用する必要があるかもしれません。開発者はトランザクションだけでなく、バンドルの観点から考える必要がありますが、スーパービルダーやカスタムロールアップインフラは、多くの開発者の複雑さを取り除くかもしれません。 3.MEVサーチャー
   MEV検索者はL1戦略を使用するクロス集約バンドルでの機会は基本的に同じですが、これはPBS（プロポーザー-ビルダー分離）の実装方法に依存します。 → 複数のトランザクションを束ねたクロスモザイクパッケージは、単一の取引と見なされるため、フロントランニングやホールディングによってこれらのパッケージからMEVを見つけることができます。ただし、価格が許容スリッページ額を超えない限り（そうでないと、パッケージ全体が元の状態に戻り、MEVの試みは失敗します）。
3. ロールアップ 共有のソーティングインフラ（スーパービルダーを含む）に参加し、共有の決済層において Eth の破棄/ミントへのアクセスを許可するために、ソーティングマシンに参加する必要があります。 → ブロックスペースを建設者に売却することでMEVを内部化することができます

6. 可交易组合性のレベル

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

VMレベル変更 // 共有決済 // スーパービルダー

取引レベルの組み合わせ可能性とは、EVMオンチェーンのスマートコントラクトで共有されている同じレベルの機能を指します。この場合、単一のトランザクションで複数のロールアップの状態を同時に更新し、呼び出しが成功しなかった場合でも、呼び出し前のすべての状態変更を元に戻すことができます。実際には、ブロックレベルの組み合わせ可能環境で、原子取引パッケージは、単一のロールアップをまたいで、また、複数のVMをまたいでトランザクションを完了できます。共有決済レイヤーとスーパービルダーに加えて、すべての接続されたロールアップにVMレベルの変更が必要です。

ここでは、可能性のあるメカニズムについて高レベルで説明しました。（Espressoチームに帰属すると我々が知っている範囲では）。最初に、ユーザーはすべての状態が取引されたロールアップまたは関連するすべてのロールアップで構築されたブロックに対してクロスロールアップ取引を提出するスーパービルダーです。スーパービルダーがペーパートレードを行い、入出力対リストを形成し、それぞれの関連するロールアップに1つずつ、そのリストはクロスロールアップメッセージが取引で必要であり予想されることを指定します。（なお、スーパービルダーはすべての関連するロールアップに対して一定期間セキュアな順序を持っている場合にのみこれを行うことができます）。その後、スーパービルダーはシミュレートされたブロックを各ロールアップの提案者に送信するとともに、クロスロールアップ取引の予想される入出力対リストを送信します。実行中、各ロールアップは自身の状態遷移関数を通常通り実行し、クロスロールアップ取引リストからの入力が正しいと仮定します。決済の際、入出力リストは共有決済レイヤの証明集約段階で交差比較され、安全であることが証明されます。具体的には、クロスロールアップ取引の予想される入力が別のロールアップで指定された出力と一致しない場合、決済プロセスはクロスロールアップ取引全体を拒否します。

フラッシュローンを除いて、トランザクションレベルの組み合わせ可能性によって開放される新機能は限られていますが、開発者はロールアップ間を横断するアプリケーションの作成体験を大幅に向上させることができます。すべての接続チェーンと相互作用することができるDAppを作成することができ、ロールアップバンドルを考慮する必要はありません。これにより、マルチロールアップ環境でのイノベーションがはるかに容易になります。さらに、新しいユースケースや動作が現れる可能性もあります。

取引レベルの組み合わせ可能性には、多くの未解決の設計上の問題があります。まず、開発者がどのようにしてスマートコントラクトにクロスロールアップ呼び出しを追加または削除するかを慎重に考慮する必要があります。制限なしに任意の組み合わせ可能性を許可することは、単一のロールアップに戻ることを意味します。私たちは、ここでの答えは、開発者が明示的に示すことができるようにすることです。つまり、どの部分がクロスロールアップ可能性があるか、例えば、Solidityの修飾子（「組み合わせ可能」など）を使用して、契約の特定のエントリーポイントをクロスロールアップ可能な呼び出し可能としてマークすることです。

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

1. ユーザー： 区块级可组合性と同じ意味を持ち、フラッシュローンなどの他の高度な機能も備えています →UXは、オプトインdappとほぼ同じチェーンを使用します
2. 開発者：Dapp 開発者は、ローカルで契約のクロス集計を呼び出し、その呼び出しの出力（単一の集計呼び出しのようなもの）を使用できるため、 開発者の体験は非常に大きい 改善→ Superbuilder/Sequencer インフラは引き続き、交差集計呼び出しの影響を受ける集計ブロックに取引を配置する必要がありますが、同じバンドルを構築する必要はありません。
3. MEVサーチャー:
   クロスロールアップバンドルは、基本的にはオンチェーンの単一取引に相当するため、MEVポテンシャルが非常に高い
4. ロールアップ：
   仮想マシンレベルの変更と、共有ソータと共有決済レイヤーの選択が必要です →証明を通じて状態を検証できるようになるまで、他のロールアップの入力と出力を信頼する必要がありますが、これには追加の信頼仮定が関わります。ただし、削減メカニズムにより信頼負担を軽減することができます

まとめとエコシステム図

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

1. 共享決済は、外部のラッピング資産を必要とせずに、ロールアップ間での交換を可能にし、すべての接続されたロールアップ間でプロトコル内のメッセージパスを作成します
2. 共有ソート/ Superbuildersは、次のブロックの実行を保証するために、ロールアップバンドルを横断して提供します
3. ブロックレベルの組み合わせ可能性により、複雑で高速で相互依存するロールアップバンドルを作成し、スマートコントラクトからスマートコントラクトレベルの組み合わせ可能なエコシステムを実現します。 → 共有支払を追加することで、外部のパッケージ資産を使用せずにこれらのクロスロールアップバンドルを作成できます
4. 取引レベルの組み合わせ可能性は可能です。新しく開拓されたユースケースはより複雑なユーザーを対象にしているかもしれませんが、それはクロス集計開発体験を大幅に向上させる可能性があります。

現在、多くのプロジェクトが台頭し、これらのネイティブで相互運用可能なエコシステムを作成することを目指しています。以下はこの領域の高位レベルの概要です：

エコシステムマップ

エコシステムマップ

終わり

本文に記載されているフレームワークの技術的な詳細には、まだいくつかの未解決の問題があります。例えば、ブロックレベルの組み合わせ可能なエコシステムにおいて、クロスアグリゲーションのリミット注文を束ねるためには、一部の履行や市場注文のスリッページ許容度に対処するためにより詳細な設計が必要です。ここでは、注文が完全に完了していない場合にクロスアグリゲーションのリミット注文を束ねるパッケージを復元するための潜在的な解決策を提供していますが、設計の余地はあります。

このほか、言及に値するのは、これが現在アプリチェーン分野でますます上昇している思想共有と関係があるということです。アプリチェーンはロングテールL2であり、汎用的または許可されたものであり、特定の関連プロトコルをL2上で孤立させることを目的としています。ブロックレベルの組み合わせ可能性に到達すると、すべての接続されたネットワーク間でネイティブな組み合わせ可能性を持つため、アプリチェーン環境が著しく魅力的になり始める可能性が非常に高いでしょう。

現在、これらのアプリケーションチェーンに流動性を導入することはまだ困難ですが、より大きなチェーンが相互運用可能な環境として接続されると、共有インフラを中心としたエコシステムが見られる可能性があります。

もう一つの重要な未解決問題は、スーパービルダーの周りのデザインスペースがどのように解決されるかです。この分野の開発はまだ初期段階にあり、現在、最も効果的な方法で複雑なビルダーネットワークを作成する方法が明確ではありません。これらのクロス集約パッケージは、最適な方法でブロックに含まれ、集約収入への影響は未解決の問題であり、多くのチームが異なる戦略を探索しています。

最終的には、将来、プロトコル内外のブリッジ接続ソリューションの組み合わせが必要になる可能性があります。これらは協調して、より優れた相互運用性プロセスをすべての人に提供します。私たちは、本文で定義された進展が、最終的なユーザーによりシームレスなクロスロールアップ相互運用性を提供することに注力する開発者や構築者の指南となると信じています。