Celestia 研究者が 6 種の Rollup バリアントを分析：Sequencer=アグリゲーター+ヘッダー生成者

著者：NashQ、Celestia研究者
原文タイトル:Redefining Sequencers: Understanding the Aggregator and the Header Producer
翻訳：Faust、Geek Web3

翻訳者注：Rollupモデルをより理解しやすく、分析しやすくするために、Celestiaの研究者NashQはRollupのシーケンサー（Sequencer）を2つの論理的な実体、すなわちアグリゲーターとヘッダー生成者に分けました。また、彼は取引の順序付けプロセスを3つの論理的なステップ、すなわち包含、順序付け、実行（inclusion, ordering, and execution）に分けました。

この分析の視点に基づき、主権Rollupの6つの重要なバリエーションがより明確に理解できるようになります。NashQは異なるRollupバリエーションの検閲耐性と活性について詳細に議論し、各Rollupバリエーションのノードが信頼最小化状態で必要とする最低限の構成（Trustless状態を達成するためにRollupユーザーが少なくともどのタイプのノードを運用する必要があるか）についても探討しました。

この記事はCelestiaの視点からRollupを分析しており、EthereumコミュニティのRollupモデルの分析方法とは異なりますが、Ethereum RollupとCelestia主権Rollupの多くの相互接続点や、後者の影響力の高まりを考慮すると、Ethereum愛好者にとっても非常に読む価値があります。

Rollupとは何ですか？

Rollupは、その「取引データ」を別のブロックチェーンに公開し、その合意とデータの可用性を引き継ぐブロックチェーンです。

なぜ「取引データ」という言葉を特に使ったのかというと、これはRollupブロックとRollupデータの違いに関係しています。最も簡潔なRollupは、以下の最初のバリエーションのようなRollupデータだけで十分です。

Rollupブロックは、特定のブロック高におけるブロックチェーンの帳簿を表すデータ構造です。RollupブロックはRollupデータとRollupヘッダーで構成されています。ここで、Rollupデータは一連の取引や取引間の状態変化の集まりである可能性があります。

バリエーション1：悲観的Rollup / Based Rollup

Rollupを構築する最も簡単な方法は、ユーザーが取引を別のブロックチェーンに公開させることです。私たちは後者を合意とデータの可用性層（DA - Layer）と呼びます。以下ではDA層と略します（翻訳者注：Ethereumコミュニティでよく言われるLayer1に近い）。

私が紹介する最初のRollupバリエーションでは、RollupネットワークのノードはDA層に含まれるRollup取引を再実行して、帳簿の最終状態を確認する必要があります。これが悲観的Rollupです！

悲観的Rollupは、全ノードのみをサポートするRollupです。 これらの全ノードは、Rollup帳簿に含まれるすべての取引を再実行して、その有効性を確認する必要があります。

しかし、この場合、誰がRollupのシーケンサーSequencerを担っているのでしょうか？実際、Rollupの全ノード以外に、Rollup帳簿に含まれる取引を実行した実体はありません。一般的に、シーケンサーは取引データを集約し、Rollupヘッダーを生成します。しかし、上記の悲観的RollupにはRollupヘッダーがありません！

議論を容易にするために、シーケンサーを2つの論理的な実体に分けることができます：アグリゲーターAggregatorとヘッダー生成者。Rollupヘッダーを生成するには、まず取引を実行し、状態変換を完了してから対応するヘッダーを計算する必要があります。しかし、アグリゲーターは状態変換を完了する必要はなく、集約ステップを実行できます。

順序付けSequencingは「集約 + Rollupヘッダーの作成」のプロセスです。

集約aggregation *は、取引データをバッチBatchとしてまとめるステップです。1つのバッチには通常、多くの取引が含まれます（翻訳者注：BatchはRollupブロックのヘッダー以外の部分のデータです）。

ヘッダー生成 *ステップは、Rollupヘッダーを作成するプロセスです。RollupヘッダーはRollupブロックのメタデータであり、少なくともそのブロック内の取引データに対するコミットメントを含んでいます（翻訳者注：ここで言うコミットメントは、取引処理結果の正確性に対する約束を指します）。

この視点から、Rollupの各部分コンポーネントが誰によって担われているかがわかります。まず、アグリゲーターAggregatorの部分を見てみましょう。前述の悲観的Rollupにはヘッダー生成プロセスがなく、ユーザーは取引を直接DA層に公開します。これは、DA層ネットワークが実質的にアグリゲーターとして機能していることを意味します。

したがって、悲観的Rollupは、集約ステップをDA層に委任するRollupバリエーションであり、シーケンサーSequencerを持ちません。このようなRollupは時折「based rollup」と呼ばれます。

Based RollupはDA層と同じ検閲耐性と活性を持っています（活性はシステムがユーザーのリクエストに応じる速度を測定します）。このようなRollupのユーザーが信頼最小化（最もTrustlessに近い）状態を達成するには、少なくともDA層ネットワークの軽ノードとRollupネットワークの全ノードを運用する必要があります。

バリエーション2：共有アグリゲーターを使用した悲観的集約

共有アグリゲーターを使用した悲観的集約について議論しましょう。この考えは、Evan Forbesが共有シーケンサー設計に関するフォーラムの投稿で提案しました。その重要な仮定は、共有シーケンサーが取引の順序付けの唯一の正式な方法であるということです。Evanは共有シーケンサーの利点を次のように説明しています：

「Web2と同等のユーザー体験を達成するために、共有シーケンサーは迅速に生成されるソフトコミットメントを提供します（あまり信頼性のない保証ではあります）。これらのソフトコミットメントは、最終的な取引順序に関するいくつかの保証を提供し（取引順序が変更されないことを約束する）、Rollup帳簿の状態更新のステップを前倒しで行うことを可能にします（ただし、最終確定はまだ行われていません）。

Rollupブロックデータが基盤層Base Layer（ここではDA層を指します）に確認されて公開されると、Rollup帳簿の状態更新が最終的に確定します。」

上記のRollupバリエーションは依然として悲観的Rollupの範疇に属します。なぜなら、このようなRollupシステムには全ノードしかなく、軽ノードが存在しないからです。各Rollupノードはすべての取引を実行して、帳簿の状態更新の有効性を保証する必要があります。このようなRollupには軽ノードがないため、Rollupヘッダーも必要なく、ヘッダー生成者も必要ありません。（翻訳者注：一般的に、ブロックチェーンの軽ノードは完全なブロックを同期する必要はなく、ブロックヘッダーのみを受信します）

Rollupヘッダー生成のステップがないため、上記のRollupの共有シーケンサーは取引を実行して状態を更新する必要がなく（ヘッダー生成の前提条件）、単に取引データを集約するプロセスを含むことができます。したがって、私はこれを共有アグリゲーターshared aggregatorと呼ぶことを好みます。

このバリエーションでは、Rollupユーザーが信頼最小化状態で少なくとも必要とするのは、

DA層の軽ノード + 共有アグリゲーターネットワークの軽ノード + Rollup全ノードです。

この時点で、共有アグリゲーターネットワークの軽ノードを通じて公開されたアグリゲーターヘッダーを検証する必要があります（ここで指すのはRollupヘッダーではありません）。上記で述べたように、共有アグリゲーターは取引の順序付けの作業を担っており、公開されたアグリゲーターヘッダーには、DA層で公開されたバッチに対応する暗号的コミットメントが含まれています。

こうすることで、Rollupノードの運営者は、DA層から受け取ったバッチが共有アグリゲーターによって作成されたものであり、他の誰かによるものではないことを確認できます。

（上記の内容はやや難解なため、図を再度確認してください）

包含Inclusionは、取引をブロックチェーンに含めるプロセスです。

順序付けOrderingは、取引を特定の順序でブロックチェーンに配置するプロセスです。

実行Executionは、ブロックチェーン内の取引を処理し、状態更新を完了するプロセスです。

共有アグリゲーターが包含と順序付けの作業を担っているため、Rollupの検閲耐性はそれに依存します。

Lssを共有アグリゲーターの活性、LdaをDA-Layerの活性と仮定すると、このRollupモデルの活性はL = Lda && Lssとなります。言い換えれば、2つの部分のいずれかに活性障害が存在する場合、Rollupにも活性障害が存在します。

簡単のために、私は活性をbool値として考察します。共有アグリゲーターが故障した場合、Rollupは運転を続けることができません。DA層ネットワークが故障した場合、共有アグリゲーターはRollupブロックにソフトコミットメントを提供し続けることができます。しかし、この時点で、Rollupの各属性は完全に共有アグリゲーターネットワークに依存し、後者の属性は元のDA層の属性に比べてしばしば劣ります。

では、上記のRollupソリューションの検閲耐性についてさらに探討しましょう：

このソリューションでは、DA層は特定の取引を検閲することができません（翻訳者注：取引の検閲は特定の取引をブロックチェーンに載せないことを拒否することが多いです）。それは、共有アグリゲーターが提出した全取引バッチに対して取引検閲を行うことができます（特定のバッチをDA層に含めることを拒否する）。

しかし、Rollupのワークフローに従って、共有アグリゲーターはDA層に取引バッチを提出する際に、すでに取引の順序付けを完了しており、異なるバッチ間の順序も決定しています。したがって、DA層のこの取引検閲は、Rollupの帳簿の最終性確認を遅延させる以外に他の効果はありません。

以上から、私は検閲耐性の重要性は、システム内の情報の流通を制御または操作できる実体が存在しないことを確保することであり、活性はネットワークの中断や対抗行動があってもシステムの機能と可用性を維持することに関係していると考えています。これは現在の主流の学術的定義とは対立しますが、私は自分が説明した概念を用いて定義し続けます。

バリエーション3：Based Rollupと共有アグリゲーターに基づく悲観的Rollup

共有アグリゲーターがユーザーとコミュニティに利益をもたらす一方で、私たちは過度に依存することを避け、ユーザーが共有アグリゲーターからDA層に撤退できるようにする必要があります。私たちは前述の2つのRollupバリエーションを組み合わせ、共有アグリゲーターを使用しながら、ユーザーが直接DA層に取引を提出できるようにします。

最終的なRollup取引シーケンスは、共有アグリゲーターが提出した取引シーケンスと、ユーザーがDA層ブロックに直接提出したRollup取引に依存すると仮定します。これをRollupのフォーク選択ルールと呼びます。

ここでの集約は2つのステップに分かれます。まず、共有アグリゲーターが機能し、いくつかの取引を集約します。次に、DA層は共有アグリゲーターが提出したバッチとユーザーが直接提出した取引を集約できます。

この時の検閲耐性分析はより複雑になります。DA層ネットワークのノードは、次のDA層ブロックが生成される前に、共有アグリゲーターが提出したバッチを検閲する可能性があります。バッチ内の取引データを知った後、DA層ノードはMEV価値を抽出し、まず自分のRollupネットワーク上のアカウントを使用してフロントラン取引を開始し、それをDA層ブロックに先に含め、その後にRollup共有アグリゲーターが提出したバッチを含めることができます。

明らかに、第三のRollupバリエーションのソフトコミットメントによる取引順序の最終的な確定性は、前述の第二のRollupバリエーションよりも脆弱です。この場合、共有アグリゲーターはMEV価値をDA層ノードに提供しています。これについて、私は読者に利益をもたらす検閲MEVを利用する研究講座を視聴することをお勧めします。

現在、DA層ネットワークノードがこのようなMEV取引を実行する能力を低下させるためのいくつかの設計案が登場しています。例えば、「再構成ウィンドウ期間」機能があり、これによりRollupネットワークユーザーが直接DA層に提出した取引が遅延実行されます。Sovereign Labsは「Based Sequencing with Soft Confirmations」という設計提案の中でこれを詳細に説明しており、「優先シーケンサー」の概念を提案しています。

MEV問題はRollupが選択するアグリゲーターのソリューションやRollupのフォーク選択ルールに依存しているため、特定のソリューションはDA層にMEVを漏らさず、他のソリューションは一部またはすべてのMEVをDA層に漏らすことになりますが、これは別の話題です。

活性については、このRollupソリューションは、共有アグリゲーターのみがDA層に取引を提出することを許可するソリューションよりも優れています。共有アグリゲーターに活性障害が発生した場合でも、ユーザーはDA層に取引を提出できます。

最後に、信頼最小化下のRollupユーザーの最低構成について話しましょう：

少なくともDA層の軽ノード + 共有アグリゲーターの軽ノード + Rollup全ノードを運用する必要があります。

この時点で、依然として共有アグリゲーターが公開したアグリゲーターヘッダーを検証する必要があります。これにより、Rollup全ノードはフォーク選択ルールに基づいて取引バッチを区別できます。

バリエーション4：Optimistic Based Rollupと中央集権的ヘッダー生成者

Based Optimistic Rollupと中央集権的ヘッダー生成者と呼ばれるバリエーションについて議論しましょう。このソリューションはDA層を使用してRollup取引を集約しますが、Rollupヘッダーを生成するために中央集権的なヘッダー生成者を導入し、Rollup軽ノードを有効にします。

Rollup軽ノードは、単一の詐欺証明を通じてRollup取引の有効性を間接的に確認できます。軽ノードはRollupヘッダーの生成者に楽観的な態度を持ち、詐欺証明のウィンドウ期間が終了した後に最終確認を行います。もう一つの可能性は、誠実な全ノードから詐欺証明を受け取り、ヘッダー生成者が誤ったデータを提出したことを知ることです。

私はこの文で単一の詐欺証明の仕組みを詳細に説明するつもりはありません。なぜなら、これはこの文の範囲を超えているからです。単一の詐欺証明の利点は、詐欺証明のウィンドウ期間を7日からある程度短縮できることです。具体的な数値は未確定ですが、数量的には従来の楽観的Rollupよりも小さくなります。軽ノードはRollup全ノードで構成されるP2Pネットワークを通じて詐欺証明を取得でき、後続の争議プロセスを待つ必要はありません。すべての判決は単一の詐欺証明の中で完全に提供されています。

上記のRollupモデルはDA層をアグリゲーターとして使用し、その検閲耐性を引き継ぎます。この時点でDA層は取引の包含と順序付けを担当します。中央集権的なヘッダー生成者はDA層からRollup取引シーケンスを読み取り、それに基づいて対応するRollupヘッダーを構築します。ヘッダー生成者はヘッダーとステートルートをDA層に公開します。これらのステートルートは詐欺証明を作成する際に必要です。簡単に言えば、アグリゲーターは取引の包含と順序付けを担当し、ヘッダー生成者は取引を実行して状態を更新し、ステートルートを得ます。

DA層（この時点でRollupのアグリゲーターも兼ねています）が十分に非中央集権的であり、良好な検閲耐性を持っていると仮定します。また、ヘッダー生成者はアグリゲーターが公開したRollup取引シーケンスを変更できません。今、ヘッダー生成者を非中央集権化すれば、唯一の利点はより良い活性ですが、Rollupの他の属性は最初のバリエーションBased Rollupと同じです。

もしヘッダー生成者が活性障害を起こした場合、Rollupも活性障害を起こします。軽ノードはRollup帳簿の進捗を追跡できなくなりますが、全ノードは追跡できます。この時点で、バリエーション4で説明されたRollupはバリエーション1で説明されたBased Rollupに退化します。明らかに、バリエーション4で説明された信頼最小化の最低構成は：

DA層の軽ノード + Rollup軽ノードです。

バリエーション5: Based ZK-Rollupと非中央集権的Prover Market

悲観的Rollup（Based Rollup）と楽観的Rollupについて議論したので、今度はZK-Rollupを考える時が来ました。最近、Toghrulはアグリゲーター（Sequencer）とヘッダー生成者（Prover）の分離に関する講演を行いました（Zero-Knowledge RollupsにおけるSequencer-Prover Separation）。このモデルでは、取引をRollupデータとして公開する方がState Diffとして公開するよりも処理が容易ですので、前者について重点的に議論します。バリエーション5は、zk-rollupに基づく非中央集権的Prover Marketです。

ここまでで、Rollupの仕組みについてかなり理解できたと思います。バリエーション5では、アグリゲーターの役割をDA層ノードに委任し、後者が取引の包含と順序付けの作業を行います。私はSovereign-Labsの文書を引用します。これはバリエーション5における1つの取引のライフサイクルを非常によく説明しています：

ユーザーは新しいデータブロックをL1チェーン（DA層）に公開します。これらのデータブロックがL1チェーン上で最終確定されると、それは論理的に最終性（変更不可）を持ちます。L1チェーンのブロックが最終確定段階（つまり、ロールバック不可）に入ると、Rollupの全ノードはこれらのブロックをスキャンし、順序に従ってすべてのRollup関連データブロックを処理し、最新のRollup状態根ステートルートを生成します。この時点で、Rollup全ノードの視点から見ると、これらのデータブロックは最終確定を完了しています。

このモデルでは、ヘッダー生成者は非中央集権的なProver Marketが担います。

Prover（ZK VM内で動作する全ノード）の作業プロセスは、通常のRollup全ノードと似た部分があります。すなわち、DA層ブロックチェーンをスキャンし、すべてのRollup取引バッチを順序に従って処理し、対応するゼロ知識証明を生成してDA層チェーンに公開します。（もしRollupシステムがProverを奨励したい場合、後者が生成したZK証明をDA層チェーンに送信させる必要があります。さもなければ、どのProverが最初にZK証明を提出したのかを確認できません）。ある取引バッチに対応するZK証明がチェーン上に公開されると、その取引バッチは全てのRollupノード（軽ノードを含む）にとって最終確定を完了します。

（関連する概念が多いため、図を再度確認してください）

バリエーション5はDA層と同じ検閲耐性を持っています。非中央集権的なProver MarketはRollup取引を検閲することができません。なぜなら、DA層ではすでに規範的な取引順序が確定しているからです。より良い活性を得るため、またインセンティブ市場を作成するために、ヘッダー生成者（ここではProver）を非中央集権化したのです。

ここでの活性はL = Lda && Lpm（Proverの活性）です。もしProver Marketのインセンティブが不一致であったり、活性障害が発生した場合、Rollup軽ノードはブロックチェーンの進捗を同期できなくなりますが、Rollupの全ノードは同期できます。全ノードにとっては、これは単にバリエーション1で述べたBased Rollup/悲観的Rollupに戻るだけです。ここでの信頼最小化の最低構成は楽観的Rollupの場合と同じで、

DA層の軽ノード + Rollup軽ノードです。

バリエーション6：ハイブリッド型Based Rollup + 中央集権的楽観的ヘッダー生成者 + 非中央集権的Prover

私たちは依然としてDA層ノードをRollupのアグリゲーターとして機能させ、取引の包含と順序付けの作業を委任します。

下の図からわかるように、ZK Rollupと楽観的RollupはDA層上の同じ順序の取引バッチを使用してRollup帳簿のソースとしています。これは私たちが2つの証明システムを同時に使用できる理由です：DA層上の順序の取引バッチ自体は証明システムの影響を受けません。

まず、最終性について話しましょう。Rollup全ノードの視点から見ると、DA層自身のブロックが最終確定を完了したとき、その中に含まれるRollup取引バッチも最終確定不可変更になります。しかし、私たちは軽ノードの視点からの最終性にもっと関心があります。中央集権的なヘッダー生成者がいくつかの資産を担保にし、生成されたRollupヘッダーに署名し、計算されたステートルートをDA層に提出したと仮定します。

前のバリエーション4と同様に、軽ノードはヘッダー生成者を楽観的に信頼し、彼が公開したヘッダーに誤りがないと信じ、全ノードネットワークからの詐欺証明を待ちます。詐欺証明のウィンドウ期間が終了し、全ノードネットワークが詐欺証明を公開しなかった場合、Rollup軽ノードの視点から見ると、Rollupブロックは最終確定を完了したことになります。

重要なのは、ZK証明を取得できれば、詐欺証明のウィンドウ期間が終了するのを待つ必要がないことです。単一の詐欺証明の代わりにZK証明を使用し、悪意のあるヘッダー生成者が生成した誤ったヘッダーを排除できます！

軽ノードが特定のRollup取引バッチに対応するZK証明を受け取ったとき、そのバッチは最終確定を完了します。

これで、迅速なソフトコミットメントと迅速な最終性が得られました。

バリエーション6は依然としてDA層と同等の検閲耐性を持っています。なぜなら、これはDA層に基づいているからです。活性については、L = Lda && (Lop || L_pm)となり、活性保証が追加されます。中央集権的なヘッダー生成者または非中央集権的なProver Marketのいずれかに活性障害が発生した場合、私たちはもう一方のソリューションに退化できます。

このバリエーションにおけるユーザーの信頼最小化の最低構成は：

1つのDA層軽ノード + 1つのRollup軽ノードです。

要約：

1. Rollupの重要な役割であるシーケンサーSequencerを2つの論理的な要素に分けます：

アグリゲーターとヘッダー生成者。

2. シーケンサーの作業を3つの論理的なプロセスに分けます：包含、順序付け、実行。

3. 悲観的RollupとBased Rollupは同じものです。

4. 必要に応じて、異なるアグリゲーターとヘッダー生成者のソリューションを選択できます。

5. この記事で紹介されている各Rollupバリエーションは、同じ設計パターンに従っています：

最後に、いくつかの考えを持っています。考えてみてください：

クラシックなRollup（Ethereum Rollupを指す）は、上記のバリエーションの中でどのように分類されますか？

すべてのバリエーションにおいて、私たちはアグリゲーターに包含と順序付けを担当させ、ヘッダー生成者に取引を実行させます。もしアグリゲーターが取引の包含のみを担当し、ヘッダー生成者が取引の順序付けと実行を担当する場合、どうすればよいでしょうか？オンチェーンオークションのステップを導入することを考慮すると、これらの3つの作業を完全に分離できますか？

共有ヘッダー生成者/ヘッダー生成者市場とは何ですか？

誰がMEV価値を捕らえますか？ユーザーはそれを取り戻せますか？