意見:L2はユーザーの救世主だが、L1の捕食者である
より多くの人々がL2を使い始めれば、イーサにとってもユーザーにとってもWin-Winになるかもしれない。
JinseFinanceAuthor: Marshall Vyletel Jr. Source: 1kx Translated by: Good Oba, Golden Finance
イーサでのロールアップの数が爆発的に増えている。align: left;">イーサでのロールアップの数が爆発的に増えている。L2Beatによると、本稿執筆時点で91のL2およびL3のロールアップが稼動しており、さらに82のロールアップが進行中だ。その結果、モビリティ、ユーザーエクスペリエンス、開発者ツールの面で多くの断片化が見られる。現在の相互運用性ソリューションは、サードパーティのブリッジ、外部でパッケージ化されたアセット、およびインテント・フレームワークの組み合わせに依存しているため、それぞれ独自の問題点を抱えており、大いに不満が残ります。
流動性ブリッジは、しばしば最大の暗号通貨ハッキングのターゲットになります(例えば、3億2100万ドルのワームホールブリッジのハッキング)
外部パッケージ化された資産は人気がなく、人々は可能な限り本来の形で資産を保有することを好むというデータがあります(例えば、L2Beatによると、正規のブリッジング資産は220億ドルの価値があり、外部パッケージ化された資産は30億ドルの価値しかありません)
インテンションフレームワークは、無視できない量の信頼を必要とし、クロスロールアップ活動を促進するために追加料金を請求するサードパーティに依存しています(例えば、Degenチェーンのユーザーは、規制されていない公式ブリッジングのために80%以上のトークンを失いました)。中央集権的な意図的な枠組みはまた、競争の低下を意味し、最適ではない価格設定とパフォーマンスにつながる可能性があります
本稿では、分散型ロールアップエコシステム間の6つのレベルの相互運用ソリューションを定義し、議論することで、信頼性のない相互運用性の見通しを調査します。
我々は、ソースロールアップからL1への非同期引き出しとターゲットロールアップへの手動ブリッジングというデフォルトのシナリオから始め、単一のトランザクションにおけるクロスロールアップコンポーザビリティの仮想アーキテクチャで終わる。各レベルの相互運用性が、ユーザーエクスペリエンス、開発者エクスペリエンス、MEVの可能性、およびロールアップ自体(特にインフラの変更に関連する)にどのような影響を与えるかを探ります。
本稿では、イーサネットとそのL2に焦点を当て、信頼のない相互運用性だけに焦点を当てます。この文脈では、「信頼性のない相互運用性」とは、ほとんどのロールアップがすでに必要としている必要なインフラストラクチャを超えて、トランスポートを促進するためにサードパーティを必要としないプロトコル内チャネルを指します。
基本的に、トラストレス相互運用性には多くの共有リソースが必要です。相互運用を望む2つのプロトコルは、これらのリソースにアクセスできなければならない。イーサネットL1の場合、すべてのスマートコントラクトはイーサネットの全状態を共有する同じ環境に存在するため、常に最高レベルの相互運用性を持つ。しかし、L2は個別のブリッジング・コントラクトを通じて決済レイヤーを共有するだけなので、相互運用性は大幅に制限されます。
トラストレス相互運用性のはしごを上ることができる重要な共有インフラコンポーネントは、共有シーケンサー、スーパービルダー、および共有セトルメントです。これらの共有レイヤーによって開かれる保証と新機能は関連していますが、本質的には直交しています。
共有シーケンサー/スーパービルダー:スピードとユーザーエクスペリエンスの大幅な向上。
共有決済: 外部パッケージングおよびプロトコル内メッセージングなしで資産交換ができます。
まず、冒頭で述べたトラストレス相互運用性の6つのレベルを定義します:
L1非同期:
→決済済みのL1を集約した相互運用性のための手動資産移転。
アトミック・インクルージョン:
→ロールアップ・バンドル全体のすべてのトランザクションが、そのバンドルに関与する各ロールアップの次のブロックに含まれることを保証するか、または何も含まれない。
共有決済:
→ 複数のロールアップが同じブリッジング契約を通じてL1に接続されます。
アトミック実行:
→ ロールアップバンドル内のすべてのトランザクションが次のブロックに含まれることを保証します。Rollupバンドル内のすべてのトランザクションは、バンドルに関与する各Rollupの次のブロックに含まれ、正常に実行されます。実行に成功するとは、各トランザクションがロールバックされることなく実行され、バンドル内の各Rollupの更新ステータスに反映されることを意味する。
ブロックレベルのコンポーザビリティ:
→ Rollup Bundle全体の次のブロックは、依存するトランザクションを含むことができることが保証される(Rollup B上のtx Bは、Rollup A上のtx Aの結果に依存する)
各レベルをさらに理解するために、各レベルの機能と、ユーザー、開発者、アグリゲーター、MEV検索者への影響を示す、以下の主なユースケースを紹介します。
同じトークンの転送
→ 自己への送信: 2つのロールアップ交換間
トークン購入
→ クロス・ロールアップ・リミット・オーダー:ロールアップAのEth/ERC-20を使用して、ロールアップBからDEXを購入する。
私たちはまた、集約されたエコシステムにおける主要な株主への影響について詳しく知るために、以下の質問に答える予定です。意味合い
ユーザーエクスペリエンス
このレベルの相互運用性を可能にすることで、ユーザーエクスペリエンスはどのように変わるのでしょうか?
開発者のエクスペリエンス
このレベルの相互運用性を有効にすることで、開発者のエクスペリエンスはどのように変わるでしょうか?
MEVの可能性
このレベルの相互運用性を実現した場合、新しいMEVの機会が生まれる可能性はありますか?
Rollupの影響
これを実現するために、Rollupは新しいインフラに参加する必要があるのか、Rollupの料金体系にはどのような変更があるのか、Rollupがそのインフラに参加することで得られる潜在的なメリットは何か。
該当なし
定義では、これは現在のデフォルトの信頼されない相互運用モードを指します。すべてのロールアップは、L1上の決済レイヤーとして構築され、そのL1へのブリッジ契約を通じてのみアクセスできるため、このように定義され、ネットワークを保護するために定期的なステータス更新を公開します。
この場合、トラストを必要としないクロスロールアップ活動を実行する唯一の正規の方法は、正規のブリッジを介してソースロールアップからアセットを抽出し、L1で利用可能になった時点でターゲットロールアップに手動でデポジットすることです。
Optimisticロールアップの場合、出金待ち時間はエラー防止ウィンドウを考慮すると約7日です。ZK Rollupでは、引き出し遅延はそれほど確実ではありませんが、15分から丸1日の範囲になることがあります。
さらに、スマートコントラクトを使用したピアツーピアのアトミック交換も可能ですが、これはユースケースが小さく、効果的にスケールしません。
現在存在するサードパーティのソリューションは注目に値します。
モビリティブリッジ
インテント・フレーミング
私たちの例では、どちらもサードパーティのソリューションが必要です。
自分自身に送る:
規範的な実践:
→ロールアップAから資産を抽出する
→ロールアップBに手動で入金する。手動でロールアップBに入金する
第三者:
→ 流動性ブリッジ/ソルバーネットワーク
スパンロールアップ指値注文
仕様:
→ロールアップAから資産を抽出する
→ロールアップBに手動で入金する
→指値注文を実行する
→送り返すには、ターゲットERC-20が外部になければならない。パッケージング
サードパーティ
→クロスアグリゲート指値注文のための新たなソリューションスペース
→これを促進するために、使用意図の周りにオープンな設計がある
。これがデフォルトなので、UX、DevEx、MEV、集計の変更について議論する必要はありません。
共有シリアライザー *
アトミックインクルードは、クロスサマリーバンドルが次のブロックに含まれることを保証するだけです。
これは共有シーケンサーを必要としますが、2つの与えられたロールアップのシーケンサーがスループットで最大でなければ、理論的には手動で達成できます(各ロールアップに2つの別々のトランザクションを送信するだけです)。これが、必要なインフラストラクチャにアスタリスクを追加した理由です。
ただし、共有シーケンサーが接続された各ロールアップの全ノードを実行することは想定していないため、トランザクションのセットが正常に実行されることを保証することはできません。この場合、共有シーケンサーが保証できるのは、トランザクションが正しくフォーマットされ、次のブロックに含まれることだけであり、必ずしも正常に実行されるとは限らない。
実行の保証がないため、トランザクションの1つが取り消されるリスクを負うことなく、プログラム的に意味のある方法でアトミック封じ込めを活用することは不可能である。したがって、本質的にL1 Async interoperabilityとまったく同じ状況にあります。
アトミック包含保証のみを使用して、単純なクロスサマリー交換を開始することを考えてみましょう:
クロスロールアップ交換Bundle
→ Tx 1: ソースRollup上のトークンをロック/破棄する
→ Tx 2: ターゲットRollup上のユーザーアドレスにトークンを鋳造する
両方のトランザクションが各集約体の次のブロックに実際に含まれるという原子包含保証があるかもしれない。しかし、最初のトランザクションがロールバックされ、2番目のトランザクションがロールバックされない場合、ユーザーはソースチェーン上で資金をロックしたり燃やしたりすることなく、ターゲットチェーン上で資金を誤って配分することになり、二重支払いの問題が発生する。
流動性ブリッジであれ、インテント・フレームワークであれ、xERC-20取引所であれ、どのような相互運用性ソリューションもこのリスクの影響を受けやすく、それを軽減することはまず不可能です。このリスクのため、現在のソリューションでは、リピーターを使って発信メッセージを配信し、ターゲットチェーン上で2番目のトランザクションを実行する前に、開始トランザクションが正常に実行され、ソースチェーン上のブロックに含まれている必要があります。
重要な注記:アトミックインクルードは相互運用性の可能性に大きな影響を与えません
集計レイヤーの証明//共有ブリッジ契約
ここからが面白くなります。共有ブリッジ契約のおかげで、L1からロールアップ・エコシステムに預けられたすべてのモビリティは、接続されたすべてのロールアップ間で自由に移動できる。以前は、規制されたチャネルを通したり、外部で資産をパッケージングしたり、サードパーティのソリューションを使用したりしなければ、ロールアップ間で交換することはできませんでした。
なぜ共有ブリッジ契約なのか?なぜShared Bridge Contractsが信頼性のない方法でロールアップ間のアセット転送を可能にするのかを理解するために、まず、もしあなたがロールアップAにEthを持っていて、それを破棄し、レイヤー1でShared Bridge Contractを作成することなく、ロールアップBにネイティブにキャストすることができたらどうなるかを考えてみましょう。
各ロールアップがメインネットワークのブリッジ契約と同期していないことがわかります。
この問題を解決するために、私たちは外部アセットラッピングプロトコルを構築しました。これは、集約においてトークンの外部ラッピングバージョンを発行し、ネットワーク内の他の場所でネイティブバージョンを象徴します。
共有決済レイヤーでは、状況は異なります。接続された各ロールアップの流動性はすべて同じブリッジ契約にロックされるため、ブリッジ契約の合計値は一定のままであり、常に引き出し可能であるため、ロールアップ間を自由に移動することができます。
ユーザーがどこからでも引き出すことができるようにするためには、流動性がどこにあるかを理解するためにL1コントラクトレベルで更新する必要がありますが、これはすべての接続にわたる集約が共有コントラクトに読み書きできるので簡単です。
共有決済レイヤーを使用すると、単純な自分自身への送金シナリオの場合、プロセスは次のようになります。
自分自身への送信:
ユーザーは最初のトランザクションを作成します:
→Tx 1: on rollup AEth is extracted (and cast on rollup B)
→Transaction is batched and submitted to L1 contract
→It is aggregated into the transaction root, which groups all shared settlement rollups
Rollup B imports into this transaction root
The user creates the initial transaction:
The user creates the initial transaction: リレーはトランザクションを造幣局に提出し、ロールアップBにMerkle Proofを提出する ロールアップBはMerkle Proofとトランザクションを使用する。Rootを使用してトランザクションの破棄を検証する ユーザーはロールアップBでEthをミントする ロールアップBはL1にプルーフを提出する
このフローを、共有決済エコシステム内のすべてのアグリゲーションにコントラクトを持つ任意のERC-20に拡張することができます。
共有ブリッジコントラクトを、接続されたすべてのアグリゲーション間のプロトコル内メッセージングレイヤーと考えることができます。
共有ブリッジ契約は、接続されたすべてのアグリゲーション間のプロトコル内メッセージングレイヤーと考えることができます。
これによってコンポーザビリティに近づきますが、集約の証明とメッセージの配信はL1上の状態変化を反映した後にのみ必要となるため、待ち時間は(L1非同期の場合よりも大幅に低いものの)長くなります。さらに、複雑なクロス・ロールアップ・アクティビティ(例えば、ロールアップ A のアセットからロールアップ B の DEX を使用したクロス・ロールアップ・リミット・オーダー)は、依然として自分自身に送信し、ターゲット・ロールアップのアセットを手動で交換する必要があるため、ユーザーにとって面倒なプロセスである。この場合、アトミックなクロスロールアップバンドルを作成することはできません。
共有決済のもう1つの重要なメリットは、複数の環境で注文を執行する流動性プロバイダーやリゾルバーの摩擦が少なくなることです。接続されているすべてのロールアップにわたる流動性が同じブリッジ契約に反映されるため、クロスロールアップの流動性を管理するために完全な出金ウィンドウを待つ必要がなくなります。
ユーザー:
ネイティブ形式で資産を移動できるようになりました。L1のドローダウン期間は必要ありません
開発者:
変更はトークン発行者に限られ、発行者はインプロトコルメッセージングを使用して、接続されたすべてのRollups上でERC-20のネイティブバージョンを発行できるようになりました
MEVサーチャー:
これはロールアップごとに複数のブロックで発生するため、新たなMEVの可能性はありません
ロールアップ:
ロールアップは、次のものを使用することを選択する必要があります。
重要: 共有決済では、外部パッケージ化されていない資産移転と、共有ブリッジ契約とプルーフ・アグリゲーション・レイヤーのすべてのアグリゲーションにわたる任意のメッセージングが可能ですが、無視できない待ち時間が発生します。L1 Asyncよりはるかに短いとはいえ)、クロスアグリゲーションのアトミックバンドルを作成することはできません。
共有ソーター // スーパービルダー
共有ソーター // スーパービルダー
依存トランザクションのセット内のどれか1つのトランザクションが取り消されると、クロスロールアップ破棄やトークン鋳造の場合と同様に、他のすべてのトランザクションが無効となり、取り消されなければならない。ターゲットロールアップでのトークンの鋳造は、ソースロールアップでトークンが破壊されたかロックされたかに依存するため、破壊と鋳造のトランザクションのセットは依存するトランザクションのセットであると言うことができる。
ターゲット・トランザクションを作成できる仲介者(例えばスーパービルダー)がいなければ、このバンドルを作成することは不可能である。
ユーザー以外の関係者が関与することなく、クロスロールアップ交換バンドルが構築されるために満たされなければならない条件を考えてみましょう。
ソースロールアップ上の契約は、以下の場合にのみ使用できます。
→ これが、メッセージングを使用する理由です。
→ これがメッセージング・プロトコルと中継ネットワークが存在する理由です。
→ メッセージは、ターゲット上で呼び出されるべきものを構築するために使用することはできますが、実際にトランザクション自体を作成することはできません。
ミンティングのためにターゲットのロールアップ上で2つ目のトランザクションを作成する:
→ ユーザーは、ロールアップB上のトークンに対するミンティングの権利を持っていないため、このTXを自分自身で作成することはできない
→(すなわち)ターゲットのチェーンは、トークンがソースのチェーン上で焼かれた/ロックされたことを証明する必要があるが、この証明は最初のチェインの後でないと利用できない。この証明は最初のトランザクションが実行された後でないと利用できない。 → 理論的には、
造幣権を持つ2つ目のトランザクションを作成できる他の当事者は、
ソースチェーン上で最初に "バーン "またはロックを作成することなく、いつでもターゲットチェーン上で "ミント "トランザクションを作成することができます。
クロスアグリゲートバンドルが実行されることは保証できても、貴重な資産を移動させるために、最初にそれをどのように構築するかは難しいことがわかります。
しかし、クロスロールアップバンドルに依存しないアトミック実行のユースケースはまだあります。
これらのトランザクション間には厳密な依存関係がないため、誰でもこのアトミックパッケージを作成し、アトミック実行を保証できる共有シリアライザーに提出することができます。
しかし、そもそもアトミックな実行保証を得るためには、ロールアップは、接続されたすべてのロールアップのフルノードを実行するために、共有シーケンサーとスーパービルダーを選択しなければならないので、すべての共有シーケンシングソリューションがそうであるように、アトミックな実行からブロックレベルのコンポーザビリティへのステップは非常に小さい。必要な唯一の変更は、ブロックビルダーまたはその他のサードパーティが、依存するクロスロールアップバンドルを完了するために、ユーザーに代わってトランザクションを作成できなければならないということです。
コンポーザビリティをさらに可能にすることなく、アトミック実行のみを可能にするインフラが構築される可能性は低い。インフラがすでにアトミック実行を持っていることを考えると、完全なブロックレベルのコンポーザビリティを達成することの相対的な利点は、それを達成することの難しさをはるかに上回ります。
ユーザー:
サードパーティがIntentのようなソリューションを提供するかもしれませんが、おそらく変化はありません。
開発者:
おそらく変わらない
MEV検索者:
。ロールアップ間の裁定取引は、アトミックな実行を考えると、より安全です
ロールアップ:
ロールアップは、相互運用を望む各ロールアップからのトランザクションを含むブロックを提出するために、共有シーケンサー/スーパービルダーを使用することを選択しなければなりません。ロールアップの収益構造を変更する可能性がある。それがどのように変化するかは不明である。
重要な注記:クロスRollupバンドルはアトミックな実行を保証しますが、バンドルの一部を作成するスーパービルダーなしでは、これらのバンドルがどのように構築されるかは不明です。そのため、アトミック実行自体が相互運用性に影響を与える可能性は低い。デフォルトでは、共有シリアライザー/スーパービルダーはブロックレベルのコンポーザビリティを構築する必要があります。
Shared Sequencer // SuperBuilder // Proof Aggregation (プルーフ集約)Layer* // Shared Bridge Contract*
(* = オプション)
共有シーケンサーと共有決済レイヤーに関する議論の多くで、このレベルの相互運用性を説明するために一般的に使用されている用語は次のとおりです。「同期合成可能性」です。
私たちは、より説明的になるようにこの用語を少し修正しました。この用語を「ブロックレベルの合成可能性」に更新することは、次のブロックに含まれ、正常に実行される2つのロールアップ間で、クロスロールアップのトランザクションパッケージを組み合わせることが可能であることを意味します。同期的なコンポーザビリティは、トランザクションレベルのコンポーザビリティと混同される可能性がある。重要なことは、これは、依存するトランザクションパッケージの実行者であり作成者であることができる中間当事者(共有順序インフラストラクチャ)を必要とすることである。
このレベルでは、単に別のRollup上のdappに参加するために自分自身を送信するだけではなく、Rollup間の真のコンポーザビリティを見るようになります。
トランザクションを作成できる共有シーケンサーを追加することで、次のようになります。
トランザクションを作成できる共有シーケンサーを追加することで、開発者がプログラムで活用できるクロスアグリゲートパッケージを作成できるようになりました。
考慮すべき2つのシナリオがあります:
ブロックレベルのコンポーザビリティ
どちらの場合も、より複雑なアクティビティ用にクロスアグリゲートバンドルを作成できますが、2つ目のケースでは、共有セトルメントを使用することで、たとえば、以下のようなことが可能になります。
どちらの場合も、より複雑な活動のためにクロスアグリゲートバンドルを作成することができます。
ブロックレベルのコンポーザビリティにより、アトミック実行の利点と、トランザクション依存のバンドルを作成する追加機能の両方が得られます。2つの例を見てみよう。
xERC-20(共有決済なし)を介して同じトークンを転送する場合:
ユーザーはERC-20を所有しています。
ユーザーはdapp経由でtxを作成します:
→ERC-20をxERC-20ロックボックスに格納し、xERC-20パッケージ版を受け取ります
→xERC-20を破棄します
→クロスロールアップ転送が行われたことを示すメッセージを共有ソート基盤に送信します。交換を促進するために、関連するデータを含むクロスロールアップ転送を開始する
スーパービルダーはトランザクションをピックアップし、クロスロールアップバンドルを作成する
→ Tx 1:上記のようにトランザクションをパッケージ化し破棄する
→ Tx 2
Superbuilderはこのクロスロールアップを共有シーケンサーに提出する
→Superbuilderは接続された2つのロールアップのフルノードを実行しているため、バンドルが完全であることを確認するためにトランザクションをシミュレートする。バンドルが正常に実行されるようにトランザクションをシミュレートする。いずれかのトランザクションがロールバックされると、バンドル全体がロールバックされる。
共有シーケンサーは、2つのトランザクションを含むブロックをDAレイヤーと状態変更を実行したノードに提出する
ロールアップBのxERC-20キャストをユーザーに渡す
共有決済レイヤーを使用すると、交換のために最初にERC-20をxERC-20としてパッケージ化する必要がないため、プロセスがさらに簡素化されます。
次に、ロールアップAの最初の(異なる)ERC-20でロールアップBのERC-20を購入し、結果のERC-20をロールアップAに送り返す、クロスロールアップ指値注文を見てみましょう。共有決済レイヤーの場合にも同様のプロセスが存在する。唯一の違いは、資産の追加的な外部ラッピングが必要ないことです。
このケースで必要なトランザクションは次のとおりです:
A上のERC-20のパッケージ化と破棄
B上のMint xERC-20
B上の初期xERC-20をターゲットERC-20と交換する
B上のターゲットERC-20をパッケージして破棄する
A上のMint xERC-20
以下はその可能性のあるワークフローです:
フロー:
ユーザーが最初のトランザクションを開始:
→xERC-20をパックして破棄し、交換のパラメータを指定するメッセージを送信する(宛先チェーン、DEXアドレス、交換するERC-20、指値注文の価格、送り返すかどうかのブール値)
ユーザーが最初のトランザクションを開始:
→xERC-20をパックして破棄し、交換のパラメータを指定するメッセージを送信する。
SuperBuilderはトランザクションを見て、バンドルを作成します:
→ Tx 1: ユーザーは上記のトランザクションを作成します
→ Tx 2: 送信先でxERC-20をキャストします(SuperBuilderはキャスト権限を持っている必要があります)
→ Tx 3: 上記の交換を使用してxERC-20を破棄します(SuperBuilderはキャスト権限を持っている必要があります)→ Tx 4: 指値注文が完全に満たされたと仮定して、B上のERC-20をパックして破棄し、ソースチェーン上のキャストにメッセージを送信する
→ Tx 5: ソースチェーン上の交換出力からデスティネーションxERC-20をキャストする
SuperBuilderはブロックを作成し、トランザクションをシーケンスするので、各トランザクションをシミュレートし、トランザクションが取り消されたときにバンドルを省略することができます。例えば、ユーザーが指値注文を完全に履行できないことが判明した場合、ブロックが実行される前にバンドルが省略されます。
共有清算レイヤーを持つ共有注文インフラがない場合、EthとxERC-20の外部ラップバージョンを使用する必要があるため、ラップされた資産の流動性プールが薄くなり、DEXの市場環境が悪化する可能性があります。この場合、ユーザーはより緩い指値を使用しなければならず、より高いスリッページ許容度を持ち、最適とは言えない価格を受け取る可能性がある。USDCが関係する場合は例外です。共有決済を行わない共有シーケンサーは、Circleと協力して、ロールアップ間のUSDC契約の独占権を獲得し、ロールアップ間のネイティブUSDCの転送と交換を促進することができます。
共有清算レイヤーの場合、この外部ラッパーは必要なく、ネイティブアセットスワップの流動性プールが深いため、より良い価格を提供する可能性がありますが、プロセスは基本的に同じです。
ロールアップは、効果的なクロスロールアップバンドルを作成するために、共有シーケンサー/スーパービルダーを楽観的に信頼する必要があります。これは主に、このクロスRollupバンドルが、ブロックが各Rollupのチェーンに追加され、L1上の決済レイヤーに集約された後まで、個々のRollupで検証できない依存トランザクションを含むためです。例として、ソースからデスティネーションへのEthの最初の破壊とキャストがある。Ethがソースチェーンで物理的に破壊され、デスティネーションチェーンで鋳造されることが重要です。
しかし、この完全なバンドルをブロック内で実行するには、たとえトランザクションがブロック自体の前の無効な状態を表していたとしても、すべてのトランザクションがそのブロック内に存在しなければなりません(例えば、ブロックの前にユーザーがEthを持っていない場合、取引所の宛先チェーン上にEthが存在します)。したがって、シーケンサーがクロスアグリゲーション・バンドルに本当に有効な依存関係を含んでいることを確信しなければならない。証明は各取引の有効性を証明するために後から提出することができる。
しかしながら、ラップされた資産が使用される場合、L1に保存されたネイティブな流動性に影響を与えないため、これはそれほど重要ではありませんが、それでも悪意のあるシーケンサーや、トランザクションバンドルが復元された依存トランザクションで実行されることを許可するコード内のエラーのリスクを相殺するためのフォールバックメカニズムがなければなりません。
ユーザー
ユーザーエクスペリエンスの大幅なアップグレードが行われ、以下のことが可能になりました。
開発者は
クロスロールアップを意識する必要があり、カスタムプリコンパイルを活用したいと思うかもしれません。開発者は、トランザクションだけでなく、バンドルという観点から考えなければなりませんが、スーパービルダーとカスタムRollupインフラストラクチャは、ほとんどの開発者にとって複雑さを取り除くかもしれません。
MEVサーチャー
MEVサーチャーも基本的に、クロスアグリゲートのバンドルでL1戦略を使用する機会は同じですが、PBS(提案者とビルダーの分離)がどのように実装されるかによります。
→クロス集合バンドルは基本的に個々の取引として扱われるため、許容できるスリッページを超えて価格を押し下げない限り、取引の先取りやピン留めによってMEVを見つけることは可能です(そうするとバンドル全体が回復してしまい、MEVの試みは失敗してしまうからです)
ロールアップ
は共有シーケンス基盤(スーパービルダーを含む)にオプトインする必要があり、共有決済レイヤーの場合、共有シーケンサーのEth破壊/キャスティングへのアクセスを許可されます。
→ ブロックスペースをビルダーに販売することで、MEVを内部化することができます
Transaction level composabilityは、EVMチェーン上のスマートコントラクトで共有される同じレベルの機能を指します。この場合、単一のトランザクションは複数のロールアップの状態を同時に更新することができ、呼び出しが失敗した場合に呼び出し前の状態変更を確実に戻すことができる。事実上、ブロックレベルのコンポーザブル環境におけるアトミックトランザクションパッケージは、単一のクロスロールアップおよびクロスVMトランザクションで完了することができる。これには、共有決済レイヤーとスーパービルダーに加えて、接続されたすべてのロールアップに対してVMレベルの変更が必要です。
ここでは、1つの可能なメカニズムを高レベルで説明します。(
ここでは、可能性のあるメカニズムの1つを高レベルで説明します(私たちの知る限り、この構築はEspressoチームに帰属します)。まず、ユーザーはクロスロールアップトランザクションを、トランザクションによって状態が変更されたすべてのロールアップ、または関連するすべてのロールアップにブロックを構築できるスーパービルダーに送信する。スーパー ビルダーはトランザクションをシミュレートし、関連するロールアップごとに1つずつ、トランザク ションに必要かつ期待されるクロスロールアップメッセージを指定する入出力ペアの リストを作成する。(スーパービルダーは、一定期間、関連する全てのロールアップに対する確実な 順序付けの権利を持っている場合にのみ、これを実行できることに注意すること)。次にスーパービルダーは、各クロスロールアップトランザクショ ンに期待される入出力ペアのリストと共に、シミュレートされたブロックを各ロールア ップの提案者に送信する。実行中、各ロールアップは、ロールアップ間取引のリストからの入力が正しいと仮定して、それ自身の状態遷移関数を通常通り実行する。決済時には、入力リストと出力リストを相互比較し、共有決済レイヤーの証明集約フェーズで安全性を証明することができる。具体的には、クロスロールアップトランザクションに期待される入力のいずれかが、別のロールアップによって指定された出力と一致しない場合、決済プロセスはクロスロールアップトランザクション全体を拒否する。
トランザクションレベルのコンポーザビリティによって解放される新機能は、フラッシュレンディング以上に限られていますが、クロスロールアップアプリを作成する開発者のエクスペリエンスは大幅に改善されます。クロスRollupバンドルについて考えることなく、すべての接続チェーンと相互作用するdappsを作成する能力は、マルチRollup環境での革新をはるかに容易にする。加えて、新しいユースケースや動作が出現する可能性が高い。
トランザクションレベルのコンポーザビリティに関しては、未解決の設計上の問題がいくつかあります。第一に、開発者がRollupの呼び出しにまたがってスマートコントラクトに参加したり終了したりする方法を慎重に検討する必要があります。無制限に任意のコンポーザビリティを許可することは、単一のロールアップに戻ることを意味し、ここでの答えは、開発者が、例えば、Solidity修飾子(例えば、「composable」)を介して呼び出し可能なクロスロールアップとしてコントラクトへの特定のエントリポイントをマークすることによって、それらのコントラクトのどこでクロスロールアップコンポーザビリティを必要とするかを明示的に示すことができるようにすることであると考えています。
ユーザー:
ブロックレベルのコンポーザビリティと同じです。
開発者: ダップ開発者は、コントラクト・クロスアグリゲーションをローカルで呼び出し、その出力を使用することができます。(たとえば、単一の集約呼び出し)、
開発者のエクスペリエンスは大幅に
改善されます→ Superbuilder/Sequencerのインフラは、クロス集約呼び出しによって影響を受ける集約のブロックにトランザクションを配置する必要がありますが、ブロックレベルの合成性と同じバンドルを構築する必要はありません。
MEVサーチャー:
クロスロールアップバンドルは、本質的にチェーン上の単一のトランザクションと同等になりました。ロールアップ:
VMレベルの変更、および共有シーケンサーと共有決済レイヤーの選択が必要
→証明で状態を検証できるようになる前に、他のロールアップからの入力と出力を信頼しなければならない。align: left;">要約とエコシステム図
ここで定義された相互運用性の各レベルの技術的な詳細を理解した後、要約します:
共有ソート(Shared Sort/ ;Superbuilders allow for next block execution guarantee on crossrollup bundles
ブロックレベルのコンポーザビリティは、スマートコントラクトからスマートコントラクトに近いレベルのコンポーザビリティを可能にする、複雑で、高速で、相互依存的なクロスロールアップバンドルの作成を可能にします。スマートコントラクトからスマートコントラクトに近いレベルでのコンポーザブル・エコシステム。
→ これらのクロスロールアップ・バンドルは、共有決済を追加することで、外部パッケージ化されたアセットを使用せずに作成できます
トランザクションレベルのコンポーザビリティが可能であり、新しく開かれたユースケースはより洗練されたユーザーを対象としているかもしれませんが、クロスアグリゲーション開発のエクスペリエンスを劇的にエスカレートさせる可能性を秘めています。
現在、このようなネイティブで相互運用可能なエコシステムを構築することを目的としたプロジェクトが数多く登場しています。
本稿で概説したフレームワークの技術的な詳細については、まだ未解決の問題が数多くあります。例えば、ブロックレベルのコンポーザブル・エコシステムでクロスアグリゲート・リミット・オーダーのバンドルを構築するには、成行注文のパーシャル・フルフィルメントとスリッページ許容のケースを処理するために、より詳細な設計が必要になるかもしれません。ここでは、注文が完全に履行されなかった場合に、クロスアグリゲート指値注文のバンドルを復元する潜在的なソリューションを提供しますが、設計空間はオープンです。
また、これは今日のアプリケーション・チェイニング空間におけるアイデア共有の高まりに関連していることも注目に値します。アプリケーション・チェーンは、汎用的な、あるいは特定の関連プロトコルを単一のL2に分離するためにライセンスされたロングテールのL2です。ブロックレベルのコンポーザビリティに到達するにつれて、アプリケーション・チェイニング環境も、接続されたすべてのネットワーク間でネイティブなコンポーザビリティを持つための大きな牽引力を持ち始めると思われます。
現時点では、このようなアプリケーションチェーンにモビリティを導入することはまだ困難ですが、相互運用可能な環境へのエントリポイントとして大規模なチェーンが接続されれば、共有インフラストラクチャを中心としたウォールガーデンエコシステムが見られるようになるでしょう。
もう1つの重要な未解決の問題は、スーパービルダーをめぐる設計空間にどのように対処するかということです。この分野の開発はまだ初期段階にあり、最も効率的な方法でクロスアグリゲーション・パッケージを作成できる複合ビルダーのネットワークを構築する方法はまだ明確になっていない。これらのクロスアグリゲーション・パッケージをブロックに含める最善の方法と、アグリゲーション収益への影響は未解決の問題であり、多くのチームがさまざまな戦略を模索している。
最終的には、将来的には、プロトコル内およびプロトコル外のブリッジングソリューションの組み合わせが必要になるかもしれません。私たちは、このペーパーで定義された進歩が、エンドユーザーによりシームレスな相互運用性をRollup全体で提供することに注力している開発者や構築者のためのガイドになると信じています。
より多くの人々がL2を使い始めれば、イーサにとってもユーザーにとってもWin-Winになるかもしれない。
JinseFinance注目のビットコインL2プロジェクト4選:BEVM、Merlin、B²Network、BounceBitの見どころとメリットは?
JinseFinanceBTC,レイヤー2,ビットコインL2の定義とL2の包括的視点 ゴールデンファイナンス,L2を具体的にどう定義するか?技術的、生態学的観点から。
JinseFinance一目でわかるレイヤー2,ETH,ETH L2データ なぜL2のセカンダリーマーケットの機会は少なくなっているのか? ゴールデンファイナンス、"肉多ければ狼多し"
JinseFinance長い目で見れば、イーサリアムの将来は、「L1ブロックチェーン+L1トラストフリー等価性を持つL2システム」(以下、「L1+L2」)の組み合わせになると思います。特に、ZK Rollupが普遍的なスマートコントラクトプラットフォーム技術を解決したとき、私はそうなると思います。
JinseFinanceAltのL1競争は白熱しており、NearはDAソリューションを立ち上げ、SuiのTVLは一気に上昇し、Etherだけがメインネットワークをアップグレードするためにまだ減速していない、L2フローティングパラレルEVMと分散シーケンサーは2つの主要な競争ポイントです。
JinseFinance持続可能性は、オンラインを維持し、攻撃に対して耐性があり、あらゆる条件下で使用できるプロトコルとして簡単に定義できます。また、関連性があり、いわば現代のニーズに対応している必要もあります。
Cointelegraphエアドロップは 2 週間も経たないうちに行われましたが、自慢のレイヤー 2 スケーリング ソリューションのチームとマーケット メーカーにはすでに問題が発生しています。
Cointelegraph