元のソース: joncharbonneau.substack.com
著者: ジョン・シャルボノー
最初のレベルのタイトル
導入
ケルビンは ZK ロールアップは偽物だと考えていますが、私はどれも偽物だと思います。"rollup"少なくとも現時点では、どちらも真実ではありません。では、実際のロールアップを作成するにはどうすればよいでしょうか?
画像の説明
出典: L2ビート
この記事では、次の点について概説します。
必須のトランザクションパッケージ化メカニズム— ロールアップオペレーターがユーザーを検閲した場合でも、ユーザーは自分のトランザクションを強制的に検閲に耐えられるようにできる必要があります。
L2 シーケンサーの分散化と (オプションの) ローカルコンセンサス— シングルタイプシーケンサ、PoA、PoS リーダー選出、PoS コンセンサス、MEV オークション、ベースレイヤベースのロールアップ、PoE など。
共有シーケンサーとクロスチェーンのアトミック性— これは本当に面白くて、まったく新しいことですね。
MEV キャプチャ可能な設計- FCFS (First Come First Served) の変更点を簡単に紹介します。暗号化された取引プールについては、私の最近の投稿を参照してください。
最初のレベルのタイトル
副題
スマート コントラクト ロールアップ (SCR)
まず、イーサリアムの一般的なロールアップである SCR の動作原理を簡単に確認します。大まかに言うと、SCR は基本的に次のもので構成されます。
1. 順序付けされた入力配列のバッチ (L1 上にあるため、トランザクション データは DA レイヤーで公開する必要があります)。
2. (ロールアップ ノード ソフトウェア) それら上で実行されるコード。
画像の説明
cr: How Rollups *actually* work - Kelvin Fichter
より具体的には、従来のシーケンサーは、ロールアップ ブロックの状態ルートと呼び出しデータ (最終的にはデータ BLOB の形式) を L1 のスマート コントラクトに公開することによって、ロールアップ ブロックへのコミットメントを生成します。新しいブロックはロールアップ ペア ブロック ヘッダーを継続的に拡張します。オンチェーン コントラクトは、ブロック ヘッダーのハッシュを保存するロールアップ ライト クライアントを実行します。有効性の証明を受け取るか、不正行為の証明期間が終了すると、スマート コントラクトは決済を完了します。未確定の ORU ブロックが無効な場合、そのブロック (および後続のすべてのブロック) は、不正なプルーフ ペアのコミットによりロールバックされ、孤立してしまいます。証拠は安全なブリッジングに役立ちます。
トランザクション バッチの送信には、悪意のある動作の発生を防止するために、ある種のマージン/デポジット ルールを適用する必要があります。たとえば、不正なバッチが送信されると (つまり、無効なステート ルート)、デポジットは破棄され、一定の割合で不正な挑戦者に分配されます。
SCRには「マージコンセンサス」、つまりオンチェーンで検証可能なコンセンサスプロトコルがあります。ロールアップ プロトコルは完全に L1 スマート コントラクト内で実行できます。メインチェーンの任意のコンセンサスルールには影響せず、それらのルールのサポートも必要ありません。
分散型コンセンサス プロトコルには通常、4 つの主な特徴があります (以下は非常に簡略化されたバージョンであり、さまざまなタイプのコンセンサス プロトコルを完全にリストしたものではないことに注意してください。リーダーレス プロトコルなど)。
1. ブロック有効性機能- 状態遷移関数。ブロックの正当性はオフチェーンで実行され、その後、その正当性は正当性証明または不正証明メカニズムによって証明されます。
2. フォーク選択ルール- 有効な 2 つのチェーンから選択する方法。 Rollup は構造上フォークを使用しないように設計されているため、複雑なフォーク選択ルールは厳密には必要ありません。
3. リーダー選出アルゴリズム- 新しいブロックを追加してチェーンヘッドを拡張することでブロックチェーンを拡張できるリーダーを選出します。
4. アンチシビルメカニズム- PoW、PoSなど
1 と 2 が達成されたと考えることができ、シーケンサーを分散化するための最小要件は、何らかの形式の Sybil 攻撃 + リーダー選出です。 Fuel Labs は長年この陣営を支持しており、PoS について次のように主張しています。
ロールアップの完全なコンセンサスプロトコルには使用しないでください (つまり、ロールアップバリデータ/発注者がブロックに投票します)
ロールアップでのリーダー選出にのみ使用する必要があります
副題
ソブリンロールアップ (SR)
SRは依然としてDAとコンセンサスのためにトランザクションデータをL1に公開しますが、SRはロールアップで「決済」クライアントを処理します（James Prestwichは「決済層」は愚かだと言いました、私はすでに愚かなので、それは問題ではありません）。 DA レイヤーはデータが存在することを示しますが、ロールアップがどの正規チェーンであるかは定義しません。
SCR - L1 スマート コントラクトによって決定されるロールアップ正規チェーン
画像の説明
ソース: セレスティア
関連するメモ: グローバルな正規チェーンは存在しない (どのチェーンが正規チェーンであるかを決定するブリッジのみ) という興味深い指摘があり、これに対して強力な反論が行われました。およびその他の関連する長いツイートでは、主権と (自動) コンポーザビリティの間のロールアップのトレードオフを説明しています。これらの見解と、ビットコイン ソブリン ロールアップに関する最近の長いツイートをご覧になることをお勧めします。
最初のレベルのタイトル
副題
ユーザーが開始した必須トランザクションのパッケージ化
スマートコントラクトロールアップ
前述したように、シーケンサーは通常、トランザクションをバッチ処理し、それらを L1 スマート コントラクトに発行する役割を果たします。ただし、ユーザー自身がコントラクトに一部のトランザクションを直接挿入することもできます。
もちろん、これは非効率的でコストがかかるため、シーケンサーがトランザクションのバッチ処理と、通常のプロセスでこれらのバッチをまとめて送信する処理を行います。これにより、多くのトランザクションにわたって固定コストが償却され、より適切な圧縮が可能になります。
シーケンサーは最終的にこれらのトランザクションを L1 で公開することをコミットしますが、よりソフトな事前確認のために出力を計算できます。
シーケンサーがこれらのトランザクションを L1 にパブリッシュすると、出力が確定します。
通常、ユーザーは資産を L1 から L2 にブリッジする場合に、自分自身でトランザクションを送信するだけで済みます。これは L1 コントラクトへの入力として追加され、対応する L1 ロック資産によって裏付けられた資金を鋳造する時期が来たことを L2 に伝えます。
お金を L1 に引き出したい場合は、L2 でそれを破棄し、L1 にお金を返すように指示できます。 L1 は L2 に何が起こったのか知りません (L1 はトランザクションを実行しませんでした)。そのため、L1 の資金のロックを解除するリクエストとともに証拠を提出する必要があります。
私は L2 から来ているため、シーケンサーはこの引き出しリクエストを開始して L1 にコミットできます。ただし、これを行うと、L2 シーケンサーの検閲耐性 (CR、検閲耐性) を信頼する必要があり、L1 と同じセキュリティ保証が得られなくなることを意味します。おそらくシーケンサーがあなたを気に入らないか、シーケンサーがクラッシュしたため、あなたは永遠に L2 で立ち往生しているのでしょう。
Rollup は、さまざまな手段を通じて局所的に CR を向上させることができます。これには、L2 ユーザー検閲の可能性を最小限に抑えるため、高額の賭け金を含む L2 コンセンサス セット、一部のトランザクション パックリストのさまざまなバリエーション、しきい値暗号化の追加などが含まれる可能性があります。それはそれで素晴らしいことですが、理想的には、L2 ユーザーにも L1 と同じ検閲耐性の保証を提供したいと考えています。
画像の説明
出典: Starknet 脱出ハッチ調査
ただし、L2 ユーザーにとってトランザクションを直接 L1 に強制することしか選択肢がない場合、これは理想的ではありません。これは、特に L1 インタラクションのコストがますます高くなっているため、多くの価値の低いユーザーにとっては現実的ではない可能性があります。より高度な設計では、ロールアップ間のアトミック トランザクションを強制することで、この制限を回避できる場合があります。 Kalman Lajkó は魅力的なデザインに取り組んでおり、ぜひ一読をお勧めします。共有プルーフと共有 DA レイヤーを備えたシステムで、クロスロールアップの必須トランザクション パッケージ化を可能にすることを期待しています。
ソブリンロールアップ
SR では強制パッケージングの動作が異なります。これは、前述したように、SR では SCR とは異なるフォーク選択ルールが適用されるためです (これについては Sovereign Labs が投稿しています)。
SCR では、L1 スマート コントラクトはロールアップのフォーク選択ルールを実行します。 ZK プルーフの検証に加えて、そのプルーフが (他のプルーフ フォークではなく) 以前のプルーフに基づいて構築されていること、および L1 で送信されたすべての関連する必須インクルージョン トランザクションを処理したこともチェックします。
SR は、その ZK 証明を L1 DA レイヤーに公開し、(L1 が検証しない場合でも) calldata/blob の形式で誰もが ZK 証明を利用できるようにすることができます。次に、新しい証明は以前の有効な証明に基づく場合にのみ有効であるというルールを追加するだけです。このルールはクライアント側で強制できますが、その場合、ユーザーはジェネシス ブロックまたはチェックポイントに至るまでチェーンの履歴をスキャンする必要があります。
あるいは、呼び出しデータを L1 ブロック ヘッダーにリンクし、ステートメントを追加することもできます。「DA 層の証明 (ブロック X から始まりブロック Y で終わる) をスキャンしました。この証明は最新の効率的なデータに基づいています」実証施工」。これは、クライアント側でフォーク選択ルールを強制することなく、証明でフォーク選択ルールを直接証明します。
副題
取引のファイナライゼーションの階層と迅速なファイナライゼーションのための ZK
イーサリアムでのオンチェーン証明検証は通常非常に高価であるため、現在の ZKR (StarkEx など) は数時間ごとにのみ STARK をイーサリアムにリリースする傾向があります。トランザクションの数に比べてプルーフの増加は非常に遅いことが多いため、この方法でトランザクションのバッチを生成すると、効果的にコストを節約できます。ただし、このように長いファイナライズ時間は理想的ではありません。
ロールアップが (完全なトランザクション データではなく) オンチェーン上の状態の違いを公開するだけの場合、完全なノードであっても証明がなければこのファイナリティを保証できません。ロールアップの完全なトランザクション データがチェーンにパブリッシュされる場合、少なくともすべての完全なノードが L1 でトランザクションを終了できます。
通常、ライトノードはソフト確認のために集中シーケンサーのみに依存します。ただし、ZKR は、すべてのライト クライアントがリアルタイムで確認できるように、p2p レイヤーで ZK プルーフを迅速に生成して配布し、L1 速度でファイナリティを提供できます。後で、これらの証明を再帰的にバッチ処理して L1 に公開できます。
これは Sovereign Labs が計画していることであり、Scroll のような同様のスキームも他にあります。Scroll は、中間の ZK 証明をオンチェーンで公開する (ただし検証はしない) ことを計画しているため、ライトクライアントはかなり迅速に同期できます。これら 2 つの構造を使用すると、ロールアップはオーバーヘッドを節約するためにバッチをチェーンに送信するのを待つ代わりに、L1 の速度でブロックのファイナライズを開始できます。ただし、どちらの場合も、「ハード ノックアウト時間」は絶対最小値 (L1 速度) まで短縮されるだけであることに注意してください。
さまざまなシーケンサーの設計が L1 ブロック時間よりも早く完成することはありません。さまざまなシーケンサー設計でできる最善のことは、さまざまな設計によって提供されるさまざまなレベルの確実性を備えた、L1 ブロック時間よりも高速な事前確認を提供することです (たとえば、コンセンサスセットの事前確認ではなく、分散型の L2 事前確認を信頼することもできます)単一タイプの信頼できるシーケンサー)。
Patrick McCorry 氏も最近、ロールアップ トランザクションのファイナリティのレイヤーについて概要を説明しました。ここまでで、おそらく基本的な概念は理解できたと思います。
トランザクションの「ファイナリティ」には、誰がコミットメントを提供したか (およびロールアップ構造がどのようになっているのか) に応じてさまざまなレベルがあります。
副題
シングルタイプシーケンサー
現在、ほとんどのロールアップには、トランザクションのバッチを送信するための許可されたシーケンサーがあります。これは非常に効率的ですが、住みやすさや検閲への耐性が低くなります。適切な保護策があれば、これは多くのユースケースで許容される可能性があります。
CR — 前述の、ユーザーによる強制的なトランザクションの組み込みのメカニズム。
アクティブ— 一部のプライマリ シーケンサがダウンした場合のホット バックアップ オプション (ZKR 証明者や ORU 不正防止バックアップなど、許可を必要としない)。バックアップ シーケンサーもダウンした場合、誰でも引き継ぐことができます。
たとえば、ロールアップのガバナンスによってバックアップ シーケンサーを選択できます。この設定により、ユーザーはセキュリティ、検閲耐性、およびライブ性を獲得できます。長期的に見ても、単一のアクティブ シーケンサーが実行可能な選択肢になる可能性があります。
Base がトレンドの始まりとなる可能性は十分にあります。企業は、エンタープライズ ブロックチェーンについて誇大宣伝されてきたのと同じくらい、自社の製品を管理し、最適化できるようになりましたが、実際には、パーミッションレスで安全で相互運用可能なチェーンになる可能性があります。
Base は最終的にシーケンサーのセットを分散化する予定ですが、重要なのは、他のスキームでは分散化が必要ないのに対し、厳密には分散化が「必要」ではないということです (または、小規模なシーケンサー セットのように、非常に限られた範囲でのみ分散化が必要です)。明確にしておきますが、これにはロールアップが安全で検閲耐性を維持するために必要な手順を実装する必要があります (任意のインスタント アップグレード機能の削除、堅牢なプルーフの実装、トランザクション パッケージ化の強制、MEV オークションなど)。そして、現在のロールアップは安全ではありません。
これは、分散型サービスに取って代わるものではなく、集中型/管理型サービスに比べて大幅な改善となります。ロールアップはデザインスペースを単純に拡張します。これは、ほとんどのロールアップ チームにとってシーケンサーの分散化が最優先事項ではない主な理由でもあります。ユーザーのセキュリティ、検閲への耐性を確保し、ロールアップ オペレーターに対する信頼を低下させるには、他の項目の方がはるかに重要です。
副題
権限証明 (PoA)
単一タイプのシーケンサーに対する当面の改善点は、地理的に分散された少数のシーケンサー (おそらく他の評判の良い企業) の実装を可能にすることです。シーケンサーは単純にラウンドロビン方式で均等に回転させることができます。彼らに保証金を課してもらうことは、正直な行動を奨励するのに役立ちます。
副題
シーケンサー オークション、別名 MEV オークション (MEVA)
画像の説明
出典: ZK ロールアップの分散化
副題
リーダー選出のための許可のない PoS
誰でも許可なくシーケンサーとして参加できますが、ステーク (おそらく L2 のネイティブ トークン) が必要です。プレッジ メカニズムは、スマート コントラクトを通じてベース レイヤで確立することも、ロールアップで直接確立することもできます。 Rollup は、この PoS と何らかの形式のオンチェーンランダム性を使用して、リーダー選択メカニズムを実装できます (一部の L1 が行うように)。
誰かがブロックをソートする権利を得る確率 = 総誓約数に対する ta の誓約額の割合。間違った/悪意のあるシーケンサーには、損失報酬、妨害行為ペナルティ、およびスラッシュを通じてペナルティを課すことができます。
上記の理由により、これにはシーケンサーのコンセンサスが必要ないことに注意してください。ロールアップでは L1 をコンセンサスとして使用するため、ローカルのコンセンサスは必要ありません。ステーキング ウェイトはローテーション メカニズムで主要な役割を果たし、どのシーケンサーがブロックを提案できるかを決定しますが、他のシーケンサーによって提案されたブロックに投票する必要はありません。
これにより、任意の長さのエポックの順序付け権限が付与されます。参加者は、連続するロールアップ ブロックを 100 個、または 1000 個などを注文する権利を持っている場合があります。サイクルが長いほど効率が良く、一度に必要なシーケンサーは 1 つだけです。しかし、拡大独占を可能にすることには別の外部性もあります。あるいは、リーダーは通常の L1 のように各ブロックを交互に配置することもできます。
Dymension
ディメンションもそのようなプロジェクトの 1 つです。 Dymension Hub は、正直多数の PoS メカニズムを使用する Cosmos の典型的な L1 になります。その L2 (「RollApp」) は、データ可用性ストアとして Celestia に依存しながら、決済とコンセンサスにそれを使用します (したがって、これらの L2 は、「ロールアップ」ではなく、事実上「オプティミスティック チェーン」になります)。
Litepaper によると、分散型 RollApp ソートには、Dymension Hub に DYM (Dymension のネイティブ資産) をステーキングする必要があります。リーダーの選出は、DYM ステークの対応する金額によって決定されます。これらのシーケンサーは、それぞれのロールアップから収益 (手数料およびその他の MEV) を獲得し、関連する基礎的なコストを Dymension Hub と Celestia に支払います。
このメカニズムのおかげで、このスタックにキャプチャされたほぼすべての値は DYM トークンに直接蓄積されます。ソートにネイティブ トークンを使用するロールアップ (後述するように、StarkNet が STRK で行うことを意図しているように) は、値を独自のトークンに蓄積します。 Dymension Hub の設定は Ethereum ロールアップの設定と似ており、シーケンサーの選択には ETH のみを使用できます。
副題
リーダー選出と L2 コンセンサスのためのパーミッションレス PoS
L2 誓約は、必要に応じて、L1 ファイナライゼーション前のシーケンサー選択および L2 ローカル コンセンサスにも使用できます。
PoS シーケンサー リーダーの選出— 前述したように、何らかの形でリーダーを選出する必要があります。
PoS コンセンサス— トランザクションが L1 によって完了する前に、L2 バリデーターが一時的な L2 コンセンサスに達するよう奨励し、より強力な事前確認を提供します。上で述べたように、これは厳密には必須ではありませんが、魅力的なオプションです。
さらに、STRK は次の目的で何らかの形式で使用できます。
DA の PoS コンセンサス— 別のコンセンサスが必要な代替 DA チェーン (volition などの alt-DA) の提供を奨励するために使用されます。
証明する— 証明者に STARK を生成するよう奨励します。
取引プロセスは次のとおりです。
1. シーケンス— シーケンサーはトランザクションを順序付けし、ブロックを提案します
2. L2 コンセンサス— StarkNet コンセンサスプロトコルは、提案されたブロックに署名します
3. プルーフの生成— 証明者はコンセンサスブロックの証明を生成します
4. L1ステータス更新— プルーフを L1 に送信して状態を更新します
副題
L2 コンセンサスが必要ですか、それとも L1 コンセンサスだけが必要ですか?
これまで見てきたように、L2 は独自のローカル コンセンサスを実装する場合と実装しない場合があります (つまり、L2 バリデーターは、最終的なコンセンサスを求めて L1 に送信する前にブロックに署名します)。たとえば、L1 スマート コントラクトは、独自のルールに基づいて異なる反応を示す可能性があります。
リーダー選挙とローカルコンセンサスを利用したPoS— 「L2 コンセンサスによって署名されたブロックのみを受け入れます。」
リーダー選挙を使用した PoS— 「現在、選択されたシーケンサーのみがブロックを送信できます。」
ロールアップにローカルのコンセンサスがない場合、必要なのは次のことだけです。
ロールアップ ブロック プロポーザル プロセスをパーミッションレスにします。
特定のブロックの高さに最適なブロックを選択するための基準を作成します。
ノードまたは決済コントラクトにフォーク選択ルールを強制させる
L1から継承されたコンセンサスとファイナリティ
どちらの場合でも、L2 の値はロールアップ トークンに蓄積できることに注意してください。 L2 トークンが何らかの形式のリーダー選挙 (コンセンサス投票ではなく) にのみ使用される場合でも、権利の順序付けによって生成される価値は依然として L2 トークンに蓄積されます。
L2コンセンサスのデメリット（リーダー選出のみ）
次に、L1 が最終決定される前にローカルのコンセンサスがあるかどうかのトレードオフについて説明します。
Fuel Labs チームが提唱した議論の 1 つは、L2 のローカルコンセンサスが検閲への抵抗を軽減するというものです。 「これにより、大多数のバリデーターが新しいブロックを検閲できるようになり、ユーザーの資金が凍結される可能性があります。ロールアップはイーサリアムによって保護されているため、ロールアップを保護するためのPoSは必要ありません。」 ここでは少しグレーゾーンです。前述したように、たとえシーケンサーがトランザクションを検閲しているように見えても、ロールアップは依然として検閲に耐えるスキームを提供することができます (たとえば、トランザクションを L1 に直接強制する、またはカルマン・ライコ氏が取り組んでいるようなより複雑な設計など)。
別の言い方をすれば、完全なコンセンサスは単に"効率が低い"。例えば：
一度に 1 つのボックス内のすべてを実行する 1 つのシーケンス リーダーのみ、
一度に 1 つのボックス内のすべてを実行するのは 1 つの順序リーダーだけであり、その後、他のすべてのノードが提案に投票して合意に達する必要があります。
前者は後者よりもはるかに単純です。
もちろん、これは、選択した特定のシーケンサーの設計とコンセンサスメカニズムによって大きく異なります。
また、ここやここなどで、シーケンサーの分散化における PoS の使用について懸念を表明している人もいることに注意してください。 L1 と L2 の複雑な関係により、特定の種類の攻撃への対処がより困難になる場合があります。
L2 コンセンサスの追加利点 (およびリーダー選挙)
おそらくシーケンサーの最大の目標は、L1 によって提供される完全な安全性よりも先に、より高速なソフト確認応答をユーザーに提供することです。 StarkNet のメカニズム要件を見てください。
「堅牢かつ高速な L2 ファイナリティが StarkNet の目標です。StarkNet の状態は、トランザクション バッチが L1 によって証明されるまでファイナライズされないため (これには数時間かかる場合があります)。したがって、次のバッチが証明される前に、L2 は集中型プロトコルに移行します。」トランザクションの実行が計画されている順序について有意義なコミットメントを行う必要があります。」
何らかの形式のコンセンサス（多くの発注者によって提供される経済的安全性によって裏付けられたもの）を追加すると、この期間中により強力な保証を提供するのに役立ちます（ロールアップブロックの事前確認は問題ありません）。
「スタークネットのコンセンサスは、セキュリティと生存性の侵害は、悪意のある過半数の利害関係者を含む参加者の一部を削減することによって強制できるという強い責任感を持たなければなりません。」
副題
L1 はロールアップのソートを担当します
上記のメソッドはすべて、シーケンサーに何らかの形式でロールアップ ブロックを作成する権限を与えます。たとえば、PoS は参加に許可がありませんが、特定のスロットに対して選択された L2 シーケンサーが、その時点でブロックをコミットできる唯一のパーティです。また、L2 シーケンサーに特権を与えないという関連提案もあります。これらの設計は、トランザクションの順序付けに L1 自体に依存します。
完全な「無政府状態」
ヴィタリックはこの「完全な無政府状態」のアイデアを 2021 年に思いつきました。誰でもいつでもトランザクション バッチを送信できます。ロールアップを延長する最初のトランザクションが受け入れられます。これは、シーケンサーを分散化する方法について上で説明した 2 つの最小要件を満たしています。
反魔女— L1 によって提供されるシビル耐性 (つまり、トランザクション手数料とブロック サイズ/ガス キャップ)。
リーダー選挙— リーダーの選出は暗黙的に行われ、遅延します。
L1 はすでにセキュリティを提供しているため、これで十分です。 L2 ブロックが L1 にパブリッシュされている場合、それらが無効な場合、または無効なブロックの上に構築された場合にのみ孤立します (ロールバックされます)。それらが有効で L1 に公開されている場合、L1 自体と同じセキュリティが保証されます。
Vitalik 氏は、このソリューションの大きな問題は、効率が非常に低いことだと指摘しました。複数の参加者が並行してバッチを送信できますが、正常にパッケージ化されるのは 1 つだけです。これにより、プルーフを生成するときに大量のエネルギーが浪費され、トランザクションのバッチを発行するために大量の不必要なガスが浪費されます。自分のトランザクションがすぐに含まれるかどうかを知るのは非常に面倒で非効率的です。
基本チェーンに基づくロールアップ (Based Rollups)
ただし、このアナーキーな設計は PBS を通じて実現可能になりました。これにより、L1 ブロックごとに最大 1 つのロールアップ ブロックを使用する、より厳密な順序付けが可能になるため、ガスが無駄になりません。 (無駄な計算があるかもしれませんが)。 L1 ビルダーは、他の L1 ブロックと同様に、最高値のロールアップ ブロックのみを含めることができ、検索者の入力入札に基づいてそのブロックを構築できます。計算の無駄を避けるために、デフォルトで ZK 証明プロセスをパーミッションレスにすることも合理的です (パーミッションレスのロールバックを許可する対応するメカニズムを使用します)。
これは、Justin Drake によって最近提案された「Basic Chain-Based Rollup」の核となるアイデアです。彼はこの用語を、L1 (「ベース」レイヤー) が順序付けを支配するロールアップを指すために使用しています。 L1 提案者は、(おそらくビルダー経由で) ロールアップ ブロックを自分の L1 ブロックに確実に含める必要があるだけです。これは、L1 の活性化と分散化を即座に実現する簡単なセットアップです。これにより、L2 シーケンサーがトランザクションをレビューしている間に強制的なパッキング トランザクションを解決するなど、いくつかの難しい問題を回避できます。また、シーケンサーの署名検証が必要ないため、ガスのオーバーヘッドをいくらか削減できます。
興味深い疑問は、これらの L2 トランザクションがどこで処理されるかということです。 L2 クライアントは、L1 サーチャー/ビルダーがトランザクションを受信して、それらに対してブロックやデータ BLOB を作成できるように、これらのトランザクションをどこかに送信する必要があります。送信先は次のとおりです。
L1トランザクションプール— これらは、解釈するための特別なメタデータとともに、「情報を持った」検索者/構築者に送信できます。ただし、これにより、L1 トランザクション プールの負荷が大幅に増加する可能性があります。
各 L2 の新しい p2p トランザクション プール— この方針に沿ったいくつかの解決策は、より説得力があるように思えます。シーカー/ビルダーは、通常のチャネルに加えて、これらの新しいトランザクション プールからのトランザクションの調査と解釈を開始します。
MEV の軽減— Rollup は、FCFS のさまざまなバリアント、暗号化されたトランザクション プールなどを創造的に使用できます。
事前確認— L2 ユーザーは、迅速なトランザクションの「確認」を好みます。基本チェーンに基づくロールアップは、最大でも L1 ブロック時間 (12 秒) にフォールバックするか、トランザクションの完全なバッチが公開されるまでさらに長く待機します。
明らかな欠点は、基礎となるチェーンベースのロールアップによりシーケンサーの柔軟性が制限されることです。例えば：
興味深いことに、これはまさに初期のロールアップ チームが構築していたものです。
https://twitter.com/DZack 23/status/1635503593070657536? s= 20
ジャスティンは、再テイク（再テイク）が役立つ可能性があると指摘しました。
https://twitter.com/jon_charb/status/1635898303106756609? s= 20
これらはすべて、少なくともホワイトペーパーで言及されている、EigenLayer の研究分野です。これが現実的な解決策であるかどうかは不明です。再ステークを通じてこれらの欠点を効果的に改善するために、すべてのステーカーが再ステークを実行することを選択することが期待されるかもしれません。したがって、このアイデアを次の方法で実装する方が論理的であるように思えます。そうしたいステーカーのサブセットに、別の共有注文レイヤーをオプトインさせます (これについては後で詳しく説明します)。
効率性の証明 (PoE)
昨年、Polygon Hermez は PoE と呼ばれる提案を行いました。これは、ZKR に固有のもう 1 つの L1 シーケンスのバリアントです。ここでのシーケンサーは完全にオープンな役割であり、誰でもトランザクションのバッチを送信できます (つまり、ベースチェーンに基づいて完全にアナーキー/ロールアップなので、同じ制限があります)。 PoE メカニズムは、2 つの当事者による 2 つのステップで構成されます。
シーケンサー
シーケンサーは L2 ユーザー トランザクションを収集し、選択されたすべての L2 トランザクションからのデータを含む 1 つの L1 トランザクションを送信することでトランザクションのバッチを作成します。シーケンサーは、受け取った経済的価値に基づいてブロックをコミットするか、ユーザーにサービスレベルのエクスペリエンスを提供します（たとえば、ユーザーがトランザクションをより迅速に完了することを望んでいるために、これによって L2 トランザクションがより高価になる場合でも、すべての L1 ブロックでトランザクションのバッチを公開します）。 。
アグリゲーター
アグリゲーター
ここではアグリゲーターを ZK 証明者と呼びます。繰り返しますが、これは許可のない役割であり、誰でも競争できます。とてもシンプルです:
トランザクション データを含むソートされたバッチは、L1 上の発生場所に従って L1 上でソートされます。
PoE スマート コントラクトは、最新の有効な状態に更新された最初の有効性証明を受け入れます。これには、まだ検証されていない 1 つ以上の提案されたバッチが含まれます。
アグリゲーターは独自の費用便益分析を自由に実行して、プルーフを発行する適切な頻度を見つけます。ゲームに勝った場合は手数料の一部を受け取りますが、新しい証明の発行までに時間がかかると、固定の検証コストがより多くのトランザクションで償却されます。アグリゲーターが最近証明 (新しい状態を証明するものではない) を公開した場合、コントラクトは復帰機能のみを実行します。 Provers は計算を無駄にしますが、ガスの大部分を節約します。
料金は次のように割り当てられます。
L2 トランザクションの料金は、有効性の証明を作成するアグリゲーターによって処理および分配されます。
すべての取引手数料は、各バッチの対応するシーケンサーに送信されます。
単一のバッチを作成する許可に対してシーケンサーによって預けられた料金は、有効性の証明にバッチを含めてアグリゲーターに送信されます。
ピュアフォーク選択ルール
Rollkit SR には、ここで説明されているように、特権シーケンサーのない任意のロールアップを指す「純粋なフォーク選択ルール」という非常によく似た概念があります。ノードは DA 層のルールに従ってソートされ、「先着順」のフォーク選択ルールが適用されます。
L1 ソートの経済性
L2 トランザクションによって生成された MEV が L1 ブロック プロデューサー レベルでキャプチャされるようになるため、これらの L1 順序付け設計は重要な経済的意味を持ちます。 「従来の」L2 順序付けモデルでは、L2 トランザクションによって生成された MEV は、L2 シーケンサー/コンセンサス参加者/オークション メカニズムによってキャプチャされます。この場合、どれだけの MEV がベース層に漏れるかは不明です。
これが良いことなのか悪いことなのかを言うのは難しいです。
利点— これは「L1 経済連合」に似ています (例: ETH はより多くの価値を獲得できます)。
危害— このベースレイヤーのインセンティブを心配する人もいるでしょう（例：ビットコインマイナーの集中化リスク、しかしおそらく手遅れでしょう）。
最初のレベルのタイトル
ZK世代の奨励
簡単な余談になりますが、PoE における上記の競争市場は、最速のアグリゲーターを中心に集中化する可能性があることに注意してください。 ZK プルーバー市場には、大きく分けて 2 つの経済的問題を解決する必要があります。
証明者にこの証明を作成するよう促す方法
証明の送信をパーミッションレスにして、競争力のある堅牢な市場にする方法 (例: ネットワークに影響を与えずに主要証明者がダウンした場合)
副題
競争市場
極端な例では、オープンな競争モードを設けることもできます。パーミッションレス証明者市場では、ロールアップ シーケンサー/コンセンサスによって生成されたブロックの証明を作成するためにすべての証明者が競い合います。最初に証明を作成した人は、証明者に割り当てられた報酬を受け取ります。このモデルは、最適な証明者を見つけるのに非常に効率的です。
これは、Proof of Work マイニングに非常によく似ています。ただし、ここには独特の違いがあります。証明は決定論的な計算です。したがって、小さいながらも一貫したアドバンテージを持つ証明者は、ほぼ「常に」勝ちます。この市場は集中的な状況を容易に形成します。
PoW マイニングでは、ランダム性の方が優れた特性を持っています。マイニング パワーが 1% あれば、1% の報酬が得られるはずです。
副題
回転ベースの機構 (ステーキングウェイトなど)
あるいは、証明者をローテーションして、各証明者にチャンスを与えることもできます（たとえば、何らかの賭け金に基づいて、または評判に基づいて）。これはより分散化される可能性がありますが、証明の遅延などの非効率性が生じる可能性があります (「遅い」証明者には証明を作成する機会がありますが、別の証明者はすでに証明をより速く効率的に作成できる可能性があります)。ただし、最終的に有効となる証明は 1 つだけなので、多くの証明者が競って証明を作成することによる計算の無駄を防ぐことができます。
さらに、自分の番になった人が（悪意または偶然に）証拠を提出できなかった場合、問題が発生します。ラウンドが長い場合 (たとえば、その時点で順番が回っている証明者が何時間も証明生成を独占できる場合)、証明者がダウンした場合、プロトコルを回復するのは困難になります。ラウンドタイムが短い場合は、他の証明者が介入して、主証明者が証明を生成できなかった部分を取り戻すことができます。
誰でもプルーフを公開できるようにすることもできますが、指定された証明者のみが一定期間報酬を受け取ります。したがって、これらの指定された証明者がダウンした場合、他の証明者は証明を発行できますが、報酬は得られません。計算にリソースを費やしても見返りがないので、これは利他的です。
Scroll は、ランダムに選択された「ローラー」(証明者) に実行トレースを割り当てる、より回転ベースのアプローチを模索しています。
また、ソート時にプルーフをユーザー レベルでどのように請求するかについても、興味深い質問がたくさんあります。これらのトピックに関する詳細な議論はここでご覧いただけます。
- Scroll の Ye Zhang 氏は、記事「Decentralized zk-Rollup」の中で、L2 コンセンサスを必要とせずに注文権を得るステーキング + MEV オークションに基づくこのような回転ローラー ネットワークの可能性について議論しています。
- 「スクロール アーキテクチャの概要」では、考えられるローラー モデルについて詳しく説明します。
- Starknet 分散プロトコル IV - プロトコルの証明
最初のレベルのタイトル
共有ソート
初期のソリューションのほとんどは、各ロールアップがシーケンサーを完全に独自に分散する方法を見つけ出す必要があると想定していました。ただし、前述の L1 ソート オプションなどは当てはまりません。多くのロールアップは、共有シーケンサー (SS、共有シーケンサー) の使用を選択できます。これにはいくつかの大きな利点があります。
平らに寝ます— シーケンサーを分散化する方法について心配するのはやめてください。それは難しいことです。このオプションを埋め込むだけです。追加のバリデータのサブセットを採用して管理する必要はありません。 「モジュラー」の名の下に資金調達に関する売り込みは常に多く存在しますが、これは実際、トランザクションの順序を別のレイヤーに剥ぎ取る非常に「モジュラー」なアプローチです。 Shared Sequencing (Shared Sequencing) は、実際には SaaS (Sequencing as a Service) 企業です。
セキュリティと分散化を統合する— 個別のロールアップごとに多数の小さな委員会を実装するのではなく、単一の発注層で強力な経済的安全性 (より強力な事前確認) とリアルタイムの検閲耐性を構築します。
迅速な取引確認— 他の単一タイプのロールアップ シーケンサーでもこれを行うことができますが、ユーザーは共有順序付けによる超高速のサブ L1 ブロックタイムの事前確認も取得できることに注意してください。
クロスチェーンの原子性— チェーン A とチェーン B の両方でトランザクションを同時に実行します (これは複雑なので、以下でさらに詳しく説明します)。
まだ L1 データとトランザクション順序付けのスループットに制限されています
L1 ブロック時間よりも速い高速トランザクション確認を L2 ユーザーに提供する機能が失われます (ただし、最終的な L1 コンセンサスの前の保証は弱くなります)。
多くの L2 のシーケンサーとしてローカル L1 を単純に使用すると、基本的にいくつかの欠点があります。
L1 順序付けでできる最善の方法は、L1 での計算ボトルネック (たとえば、トランザクションの実行がスループット ボトルネックである場合) を除去し、通信の複雑さの小さな要素の改善を達成することです。
副題
Metro - Astria の共有シーケンサー
副題
注文と実行を分離する
現在の Rollup ノードは実際に 3 つのことを処理します。
ここで重要な特性は、「実行と順序の分離」です。この場合、シーケンサーは共有されます。
注文レイヤーとして使用することを選択したさまざまなチェーンの注文トランザクション
実行しない（または証明しない）これらのトランザクションは、次の結果ステータスを生成します。
並べ替えはステートレスです。共有シーケンサー ノードは、すべての異なるロールアップの完全な状態を保存する必要がなくなりました。計算の実行が不要になります。従来のシーケンサーが現在直面している大きなボトルネックはもう存在しません。
コンセンサスは、実行がコンセンサスから分離されている場合に特に効率的になります。このプロセスは情報ブロードキャスト層にのみ制限されます (したがって高速になります)。ノードは、順序付けられたトランザクションのブロックを生成し、すべての操作を実行せずにそのブロックで合意に達するだけであれば、非常に効率的になります。命令の合意に達した後は、別の当事者が実行と証明を行うことができます。
プーリング シーケンサーのセキュリティと分散化
共有シーケンサー ノードは、比較的軽量なままであり、水平方向に拡張することもできます (コンセンサス ノードのランダムなサブセットを選択して、トランザクションの異なるサブセットを順序付けることによって)。その結果、この順序層がより分散化される可能性があります。従来のシーケンサーは、チェーンの大規模な状態を保存し、その完全な実行を実現する必要があります。
さらに、多くのチェーンにわたってリソースをプールします。PoS コンセンサスを多くのロールアップ間で分割する必要はありません。すべてを 1 か所にまとめてください。このアプローチは、独自のシーケンサーのサブセット (反組換え) を実装する多くのロールアップよりも、より多くのスラッシュ可能な価値が賭けられる、より分散化された (検閲耐性のある) シーケンサーのサブセットをもたらす可能性があります。これは次の理由から重要です。
順序付けは、リアルタイム検閲への抵抗とロールアップ ユーザーの生存性を守るための最初の防御線です。
実行と証明 - 強力な分散化要件がなくても、順番に実行できます。私たちに必要なのは正直なパーティーだけです。
ソフトコンセンサスと順序付け — 共有シーケンサーにより、ユーザーに迅速な事前確認を提供します
確認済みのコンセンサスと DA — トランザクション データは、全員が確認できるように DA レイヤーで最終化されます。
簡単な実行と証明 — 誰でも実行して、確認されたトランザクション状態の証明を生成できます
トランザクションの順序付けに関する合意に達すると、実行 (および証明) をまったく別のチェーンに遅らせることができます。
執行層で行われる作業は、検閲への抵抗の原因ではないため、分散化する必要はありません。モノリシック シーケンサーは検閲耐性には理想的ではありませんが、検閲耐性の欠点はシーケンサーの実行フローとは何の関係もありません。彼らの検閲は、トランザクションを注文してパッケージ化する能力から来ています。また、実行層では、共有シーケンサーがソートされたトランザクション入力をすでに提供しているため、検閲耐性が得られます。そうすれば、その後の国家コミットメントの計算と比較をそれほど分散化する必要はありません。
ソフト実行
高速ソフト実行の最初のステップは、ユーザーが好むものです。
このような優れたユーザー エクスペリエンスを提供するには、何らかの形式のコンセンサス (または集中型シーケンサー) が必要です。
Celestia のようなベースレイヤーのコンセンサスだけに依存している場合、注文と梱包に関するこれらの甘い約束を保証することはできません。共有注文層に多額の価値が賭けられた分散型委員会がある場合、高速ブロック生成 (サブ L1 ブロック時間) についてかなり強力な約束を提供できます。
したがって、共有シーケンサーによってブロックが作成されると、ユーザーはソフトな確認を得ることができます。誰でもコンセンサストランザクションをダウンロードして、事前に州に適用できます。この確認の強度は、共有シーケンサーの構築 (分散化、経済的安全性、フォーク選択ルールなど) によって異なります。データが実際にベース レイヤに公開されると、これらの取引は完了したと見なされます。その後、状態ルートと関連する証明の最終計算を生成して送信できます。
遅延ロールアップ (遅延ロールアップ)
「Lazy Rollup」はとても簡単です。これらのロールアップは、トランザクションがすべて順序付けされて DA レイヤーに公開されるまで待機し、その後、それらのトランザクションをダウンロードし、オプションでフォーク選択ルールを適用してトランザクションのサブセットを選択し、トランザクション処理を実行して、それらのトランザクションを状態中間に適用できます。その後、ブロックチェーン ヘッダーを生成してブロードキャストできます。
共有シーケンサーは完全な状態にアクセスする方法でブロックを生成できないため、無効な状態遷移をチェックする機能がないことに注意してください。したがって、共有シーケンサーの「遅延ロールアップ」を使用するステート マシンは、無効なトランザクションを処理できなければなりません。ノードは、順序付けされたトランザクションを実行して結果の状態を計算するときに、無効な/ロールバックされたトランザクションを単純に削除できます。即時実行を実装する従来のロールアップにはこの制限はありません。
ロールアップがトランザクションをオンチェーンにパッキングする前に状態にアクセスして圧縮する必要がある場合、ここでは機能しません。たとえば、ここでのロールアップには、ブロックに含まれるすべてのトランザクションが有効であるというブロック有効性ルールがあります。ロールアップに圧縮されたトランザクションが必要だが、状態へのアクセスは必要ない場合、このタイプのロールアップ専用に特別な共有シーケンサーを作成できます (たとえば、Fuel v2 やプライベート トランザクション プールを使用したロールアップなど)。
ガソリンを払う
この共有シーケンサーが機能するには、ユーザーが自分のトランザクションを L1 に含めるために料金を支払う何らかのメカニズムが必要です。共有注文層のガス料金は、ほとんどのロールアップ トランザクション タイプに既に含まれている既存の署名とアドレスを使用するだけで支払うことができます。これには、共有シーケンサーが、さまざまな実装で必要とされる最小状態 (署名、ノンス、アカウントからのガスの減算などの実装など) を認識している必要があります。あるいは、支払いには、共有シーケンサー上でラップされたトランザクションが含まれる場合があり、そこでは誰でもラップされた任意のデータに対して支払うことができます。オープンなデザイン空間です。
フォーク選択のルール
ロールアップは、使用する共有シーケンサーのフォーク選択ルールを継承できます。ロールアップのフル ノードは、実際には共有シーケンサーのライト クライアントとなり、特定のコミットメントをチェックして、特定のブロックの高さに対してどのロールアップ ブロックが正しいかを示します。
ただし、共有シーケンサーのフォーク選択ルールの継承はオプションです。基本レイヤーに送信されたすべてのトランザクション データを処理する (必ずしも実行する必要はありません) ようにロールアップに要求するだけです。これは、基本層の検閲耐性とライブ性を効果的に継承しますが、ユーザーが好む共有シーケンサーが享受している機能の多くが犠牲になります。
MEV
ロールアップが共有シーケンサーのフォーク選択ルールを継承し、高速なソフト実行を実現したいと仮定すると、この共有シーケンサーは当然、MEV 側からは非常に集中的な位置に置かれることになります。これにより、ロールアップがトランザクションのパッケージ化と順序付けをどのように考慮するかが決まります。
ただし、これは、ロールアップが共有シーケンサーによって提供されたトランザクションを、または提供された順序で実行する必要があるという意味ではありません。技術的には、独自のロールアップ オペレーターが 2 回目の処理を実行して、実行後に共有シーケンサーによって発行されたトランザクションを並べ替えることができます。ただし、上で述べたように、そもそも共有シーケンサーを使用する場合の優れた機能のほとんどが失われるため、これが起こる可能性は低いと思われます。
この場合でも、MEV はトランザクションをパッケージ化する権利を持っているため、共有順序付けレイヤーにまだ存在する可能性があります。本当に望むのであれば、ロールアップで処理の 2 回目のラウンドで特定のトランザクションを除外することもできます (たとえば、何らかの有効性条件を利用して特定のトランザクション タイプを除外する) こともできますが、これは当然面倒になり、抵抗が減ります。共有シーケンサーの利点が失われます。
共有シーケンサーを交換する
ブロックチェーンでフォークするのが難しいのは、あらゆる形式の共有された価値の状態です。 ETH 対 ETC または同様の ETH 対 ETH POW のようなものを見てください。社会的合意によって何が「本物のイーサリアム」であるかが決まります。私たち全員が同意できる「真実」の状態には価値があります。
ただし、共有シーケンサーは実際には単なるサービス プロバイダーであり、価値のある状態が関連付けられていません。特定の共有シーケンサーにロールアップを使用すると、フォーク機能が維持され、他の順序付けメカニズムのサポートに切り替えるために必要なハード フォークが小さくなるだけです (共有シーケンサーが抽出する値が多すぎる場合など)。これにより、共有シーケンサーの競争力が維持されることが期待されます。
副題
Espresso Sequencer,ESQ — EigenLayer によって保証されるセキュリティ
あなたは、EigenLayer ホワイトペーパーで、再ステーキングの潜在的な消費者の 1 つとして分散型共有シーケンサーについて言及しているのを見たことがあるかもしれません。この共有シーケンサーは ETH リステーカーによって保護され、多くの異なる L2 のトランザクション順序を処理できます。
Espresso は、共有シーケンサーの計画を公表したばかりです。 EigenLayer の再ステーカーを利用して、コンセンサスのセキュリティを提供できます。視覚的にわかりやすくするために、現在のロールアップは次のようになります。
Espresso のような共有シーケンサーを使用したロールアップは次のようになります。
Espresso Sequencer (ESQ) は、一般的なアイデアとして Metro に非常に似ています。これも同様に機能し、トランザクションの実行を注文から切り離します。これに加えて、ESQ はトランザクションのデータ可用性も提供します。
HotShot コンセンサスと Espresso データの可用性 (DA)
簡単な背景として、イーサリアムは現在、コンセンサス メカニズムとして Gasper を使用しています (ファイナライゼーション ツールとして Casper FFG + フォーク選択ルールとして LMD GHOST)。関連する「長すぎて読むことができない」点は次のとおりです。Gasper は、大部分のノードがネットワークからドロップアウトする可能性がある悲観的な状況 (動的可用性) の下でもネットワークの稼働状態を維持します。これは、最終的なプレフィックスを持つ動的に利用可能なチェーンを維持する 2 つのプロトコル (Casper FFG と LMD Ghost) を効果的に実行します。しかし、Gasper はネットワークのリアルタイムの稼働性を維持しながら、トランザクションの高速ファイナリティ (ネットワークが許す限り迅速にトランザクションを確認する機能) を犠牲にしています。
一般に、ESQ には次のものが含まれます。
HotShot —ESQ は HotShot コンセンサス プロトコルの上に構築されており、Gasper とは異なり、動的な可用性よりも高速なファイナリティ (楽観的な応答性) を優先します。また、イーサリアムのように、サポートされるバリデーターの数を信じられないほどまで拡張することもできます。
Espresso DA — ESQ は、チェーンのオプションの DA オプションも提供します。このメカニズムは、コンセンサスを拡大するためにも使用されます。
シーケンサー スマート コントラクト— このスマート コントラクトは、HotShot コンセンサスを検証し、チェックポイント (ソートされたトランザクション ログ内のポイントへのコミットメント) を記録するライト クライアントとして機能します。さらに、ESQ の HotShot PoS コンセンサスのステーカーの管理も担当します。
ネットワーク層— HotShot と Espresso DA に参加しているノード間でのトランザクションとコンセンサス メッセージの通信を可能にします。
Rollup REST API — Espresso シーケンサーと統合するための L2 ロールアップ API。
DAの状況を詳しく見てみましょう。楽観的なケースでは、高帯域幅ノードが他のすべてのノードにデータを提供し、個々のブロックの可用性も、ランダムに選択された小規模な委員会によってサポートされます。 DDoS や小規模委員会に対する賄賂攻撃のリスクを考慮し、(ステークされたコンピューティングによって) すべてのノードの割合が十分に高い限り、検証可能な情報分散化 (VID) を使用して、DA を保証する信頼性の高い (ただし低速な) バックアップ パスを提供します。攻撃されてない。
取引の流れ
取引の流れ
シーケンサー契約— HotShot は、L1 シーケンサー コントラクトと直接対話します。このコントラクトは HotShot コンセンサスを検証し、他の参加者がその順序付けされたブロックを表示するためのインターフェイスを提供します。コントラクトには、完全なブロックではなく、ブロック コミットメントの追加専用のログが保存されます。ただし、誰でもコミットメントに対してブロックを検証できます。
L2契約— ESQ を使用する各 L2 には、依然として独自のイーサリアム L1 ロールアップ コントラクトがあります。各ロールアップに送信された状態更新を (有効性/不正証明によって) 検証するには、各ロールアップ コントラクトが、決定的な状態更新につながる認証されたブロックのシーケンスにアクセスできる必要があります。ロールアップ コントラクトは、シーケンサー コントラクトと連携してこれらをクエリします。
共有シーケンサーに転送されたトランザクションは順序付けされ、L1 で最終処理される前にロールアップの実行者と証明者に送り返されます。共有シーケンサーは、ブロックを検証するための証明書とともに、ブロックへのコミットメントをその L1 シーケンサー コントラクトに送信します。これにより、L1 ロールアップ コントラクトは、ロールアップ状態更新証明をコンセンサス出力として認定されたブロック コミットメントと比較できるようになります。
副題
クロスチェーンの原子性
Espresso の記事で述べたように、共有シーケンサーは、クロスチェーンのアトミック性に関連するいくつかの興味深いユースケースを提供できます。
「複数のロールアップにわたる共有注文層により、クロスチェーンのメッセージングとブリッジングがより安く、より速く、より安全になることが約束されています。別のチェーンのシーケンサー用の軽量クライアントを構築する必要がないことは、無償の利点であり、スペースを節約できる可能性があります。ロールアップ間のブリッジングでは、特定のロールアップが他のロールアップのコンセンサスを個別に同期する必要がなくなるため、継続的な節約も実現できます。また、共有シーケンサはブリッジングに安全性の利点も提供します。トランザクションがファイナライズされた場合にそれを保証できます。ロールアップでは、(同時にでも) 別のロールアップで確定された場合にのみ含まれます。
さらに、共有シーケンサにより、異なるロールアップ トランザクション間のアトミックな依存関係を表現するユーザーの能力が強化されます。通常、アリスはボブのロールアップ B トランザクション t' の外で、自分のロールアップ A トランザクション t に署名して公開します。この場合、アリスのトランザクションはボブのトランザクションよりずっと前に命令され、ボブに長い中止オプション（例えば、トランザクションを中止する）を与えることができる。このオプションの不均衡は、アリスとボブが 2 つのトランザクションを 1 つの署名付きバンドルとして一緒に送信できる共有シーケンサーによって軽減できます (つまり、シーケンサーは 2 つのトランザクションを 1 つとして扱う必要があります)。 」
これは、オンチェーンのアクティビティがついに成長し始めるにつれて、クロスドメイン MEV に影響を及ぼします (私はそう願っています)。代表的な例は「アトミック・アービトラージ」です。同じ資産が 2 つの異なるチェーンで 2 つの異なる価格で取引されます。シーカーは、約定のリスクなしで同時に 2 つの取引を実行することで利益を裁定したいと考えています。例えば：
トランザクション 1 (T 1) — ロールアップ 1 (R 1) で ETH 安値を購入
トランザクション 2 (T 2) — ロールアップ 2 (R 2) で ETH を高価格で売却する
アトミック アービトラージを達成するには、両方のトランザクションが約定されるか、どちらも約定されないかのどちらかです。両方のロールアップが同じ共有シーケンサーを選択した場合、シーカーに対してこのアトミックな裁定取引を実現できます。ここでシーケンサーを共有すると、次のことが保証されます。
T 1 は、次の場合に限り、R 1 への命令ストリームに含まれます。
T 2 は R 2 への命令ストリームにも含まれます
ロールアップ仮想マシンがそれぞれのストリーム内のすべてのトランザクションを順番に実行すると仮定すると (つまり、無効な命令はないが、一部の命令はエラーをスローする可能性はあるが状態には影響しない)、次のことも保証できます。
T 1 は、次の場合にのみ R 1 上で実行されます。
T 2 は R 2 上でも実行されます
ただし、これは、共有ステートマシン (たとえば、完全にイーサリアム L1 上) でトランザクションを実行する場合と同じ保証ではありません。前述したように、共有シーケンサーはこれらのロールアップの状態を保持せず、トランザクションを実行しません。したがって、トランザクション (R 1 または R 2 上) が実行時にロールバックされないという完全な保証はありません。
これの上に高レベルのプリミティブを直接構築することには問題があります。たとえば、この共有シーケンサー上にインスタントの「バーンミント」クロスチェーン ブリッジ機能を構築しようとすると、まったく同じブロックの高さで次のことを同時に実行できます。
R 1 の入力の 1 つをバーンアウトします。
R2 に出力をキャストします
次のような状況に遭遇する可能性があります。
R 1 での破棄動作は、他のトランザクションによって無効化されるなど、予期しないエラーをスローする可能性がありますが、
R 2 でのキャスト行為はいかなる理由があっても無効になることはなく、完全に実行されます。
これがどれほど大きなことになるかがわかります。
両方のトランザクションが入力ストリームに含まれて実行されている限り、両方のトランザクションの期待される結果を決定できる場合もありますが、多くの場合、そうではありません。これは未解決の質問ですが、プロセスでは次のことが考えられます。
確保する— T 1 と T 2 はそれぞれのストリームに含まれ、(おそらく) 両方とも実行されます。
保証しません— 両方のトランザクションが正常に実行され、その結果として期待される状態が得られます。
この「保証」は、アトミック・アービトラージ（サーチャーが各チェーンでこれらのトランザクションを実行するために必要な資産をすでに所有している場合）には十分かもしれませんが、共有ステートマシンの同期構成可能性ではないことは明らかです。クロスチェーンのフラッシュローンのようなものでは、この保証だけでは十分ではありません。
ただし、これは他のクロスチェーン メッセージング プロトコルと組み合わせると、他の設定でも役立つ可能性があります。クロスロールアップメッセージングプロトコルと併用した場合に、クロスチェーンアトミックNFTスワップがどのように促進されるかを見てみましょう。
- T 1 は、R 1 で ETH を U 1 (ユーザー 1) から SC 1 (スマート コントラクト 1) に移動します。
- T 2 は、R 2 で NFT を U 2 (ユーザー 2) から SC 2 (スマート コントラクト 2) に移動します。
- SC 1が最初にSC 2からNFTが入金されたことを確認するメッセージを受信した場合に限り、U 2はETHを引き換えることができます。
- SC 2は、SC 2が最初にSC 1からETHが入金されたことを確認するメッセージを受信した場合に限り、U 1がNFTを引き換えることを許可します。
- 両方のスマート コントラクトはタイムロックを実装しているため、どちらかが失敗した場合でも、すべての当事者が資産を回復できます。
ここで共有シーケンサーを使用すると、2 人のユーザーがステップ 1 でアトミック コミットを行うことができます。次に、何らかの形式のクロスロールアップ メッセージングを使用して、結果の状態を相互に確認し、アセットのロックを解除してスワップを実行します。
アトミックにするための共有シーケンサーがない場合、当事者は価格について合意することができます。ただし、U1 はトランザクションを送信でき、U2 は待機してトランザクションを中止するかどうかを決定できます。共有シーケンサーを使用すると、トランザクションはロックされます。
共有シーケンサーによって達成されるクロスチェーンのアトミック性についてはこれですべてです。要約:
ここで提供される保証の正確な強度と有用性はまだ証明されていません
これは、クロスチェーンのアトミックアービトラージやその他のアービトラージに非常に役立つ可能性があります。
