共有アグリゲーターはユーザーとコミュニティに利益をもたらしますが、共有アグリゲーターへの過度の依存は避け、ユーザーが共有アグリゲーターから DA レイヤーに撤退できるようにする必要があります。前に紹介した 2 つのロールアップ バリアントを組み合わせることで、ユーザーは共有アグリゲーターを使用しながらトランザクションを DA レイヤーに直接送信できるようになります。 **
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Celestia の観点からのロールアップの分析: 6 つのバリアントの耐性と活性のレビュー
著者: NashQ、Celestia 研究員
翻訳标题：シーケンサーの再定義: アグリゲーターとヘッダープロデューサーを理解する
編集: ファウスト、ギーク Web3
翻訳者注: Rollup モデルを理解し、分析しやすくする目的で、Celestia の研究者 NashQ** は、Rollup のシーケンサー (Sequencer) を 2 つの論理エンティティ (アグリゲーターとヘッダー ジェネレーター) に分割しました。同時に、トランザクションの順序付けプロセスを、包含、順序付け、実行という 3 つの論理的なステップに分割しました。 **
この分析的思考の導きにより、ソブリン ロールアップの 6 つの重要なバリエーションがより明確になり、理解しやすくなります。 **NashQ は、さまざまなロールアップ バリアントの検閲耐性と生存性について詳細に説明し、信頼最小化状態 (つまり、トラストレス状態を達成するためにロールアップ ユーザーが実行する必要があるもの) での各ロールアップ バリアントのノードの最小構成についても説明しました。少なくともノードの種類)。 **
この記事は Celestia の観点から Rollup を分析しますが、これは Ethereum コミュニティが Rollup モデルを分析する方法とは異なりますが、Ethereum Rollup と Celestia ソブリン Rollup の間の多くの相互関係、および後者の影響力の増大を考慮すると、イーサリアム愛好家の皆さん、この記事も非常に読む価値があります。
ロールアップとは何ですか?
ロールアップは、その「トランザクション データ」を別のブロックチェーンに公開し、そのコンセンサスとデータの可用性を継承するブロックチェーンです。
なぜ「ブロック」ではなく「トランザクションデータ」という言葉をわざわざ使用したのでしょうか?これには、ロールアップ ブロックとロールアップ データの区別が含まれます。最もコンパクトなロールアップでは、以下の最初のバリアントのようなロールアップ データのみが必要です。
ロールアップ ブロックは、特定のブロックの高さでブロックチェーン台帳を表すデータ構造です。ロールアップ ブロックは、ロールアップ データとロールアップ ヘッダーで構成されます。その中で、ロールアップ データはトランザクションのバッチである場合もあれば、トランザクションのバッチ間の状態の変化である場合もあります。
バリアント 1: 悲観的なロールアップ / ベースのロールアップ
ロールアップを構築する最も簡単な方法は、ユーザーが別のブロックチェーンにトランザクションを公開できるようにすることです。これをコンセンサスおよびデータ可用性レイヤー (DA レイヤー) と呼びます。以下では単に DA レイヤーと呼びます (翻訳者注:イーサリアムコミュニティでよく言われるレイヤー1に似ています）。
これから紹介する最初のロールアップ バリアントでは、ロールアップ ネットワークのノードは、台帳の最終状態をチェックするために、DA 層に含まれるロールアップ トランザクションを再実行する必要があります。これは悲観的なロールアップです。
ペシミスティック ロールアップはフル ノードのみをサポートするロールアップであり、これらのフル ノードはロールアップ台帳に含まれるすべてのトランザクションを再実行して有効性を確認する必要があります。
しかしこの場合、ロールアップのシーケンサは誰が務めるのでしょうか?実際、ロールアップの完全なノードを除いて、ロールアップ台帳に含まれるトランザクションを実行したエンティティはありません。一般に、シーケンサーはトランザクション データを集約し、ロールアップ ヘッダーを生成します。しかし、上記の悲観的なロールアップにはロールアップ ヘッダーがありません。
説明の便宜上、シーケンサーをアグリゲーター アグリゲーターとヘッダー ジェネレーターという 2 つの論理エンティティに分割することができます。ロールアップ ヘッダーを生成するには、まずトランザクションを実行し、状態遷移を完了してから、対応するヘッダーを計算する必要があります。ただし、アグリゲーターの場合、集約ステップを続行するために状態遷移を完了する必要はありません。
ソート順序付けは、「集計 + ロールアップ ヘッダーの作成」のプロセスです。
集計は、トランザクション データをバッチにまとめるステップです。通常、バッチには多くのトランザクションが含まれます (翻訳者注: バッチとは、ヘッダーを除くロールアップ ブロック内のデータの一部です)。
ヘッダー生成ステップは、ロールアップ ヘッダーを作成するプロセスです。 Rollup Header は、Rollup ブロックに関するメタデータであり、少なくともブロック内のトランザクション データのコミットメントを含みます (訳者注: ここで言うコミットメントとは、トランザクション処理結果の正確性に対するコミットメントを指します)。
上記の観点から、Rollup の各部分の責任者が誰であるかがわかります。まず、アグリゲーター Aggregator の部分を見てください。前述の悲観的なロールアップにはヘッダー生成プロセスがなく、ユーザーはトランザクションを DA レイヤーに直接パブリッシュします。これは、DA レイヤーのネットワークが本質的にアグリゲーターとして機能することを意味します。
したがって、ペシミスティック ロールアップは、シーケンサー Sequencer を持たない DA レイヤーに集約ステップを委任するロールアップのバリアントです。このタイプのロールアップは「ベース ロールアップ」と呼ばれることもあります。
ベースのロールアップには、DA 層と同じ検閲耐性とアクティビティがあります (アクティビティは、ユーザー要求に対するシステムのフィードバック速度を測定します)。このタイプのロールアップのユーザーが最小限の信頼状態 (トラストレスに最も近い状態) を実現したい場合は、DA 層ネットワークの少なくとも 1 つのライト ノードとロールアップ ネットワークのフル ノードを実行する必要があります。
バリアント 2: 共有アグリゲーターを使用した悲観的な集約
共有アグリゲーターを使用した悲観的な集約について説明します。このアイデアは、共有シーケンサー設計に関するフォーラム投稿で Evan Forbes によって提案されました。その重要な前提は、共有シーケンサーがトランザクションを順序付けする唯一の正式な方法であるということです。 Evan は、共有シーケンサーの利点を次のように説明しています。**
「Web2 と同等のユーザー エクスペリエンスを実現するために、** 共有シーケンサーは高速生成のソフト コミットメント (あまり信頼性の高い保証ではありません) を提供できます。これらのソフト コミットメントは、最終的なトランザクション順序についてある程度の保証を提供します (つまり、コミットメント トランザクション順序は保証されません)。変更）、ロールアップ台帳のステータスを更新する手順を事前に実行できます（ただし、ファイナライズはまだ完了していません）。**
ロールアップ ブロック データが確認され、ベース レイヤーのベース レイヤー (ここでは DA レイヤーを指す必要があります) にリリースされると、ロールアップ台帳のステータスの更新が完了し、確定されます。 」
前述のロールアップのバリアントは依然として悲観的なロールアップのカテゴリに属します。これは、このタイプのロールアップ システムにはフル ノードのみが存在し、ライト ノードが存在しないためです。各ロールアップ ノードは、台帳ステータスの更新の有効性を確認するためにすべてのトランザクションを実行する必要があります。このタイプのロールアップにはライト ノードがないため、ロールアップ ヘッダーもヘッダー ジェネレーターも必要ありません。 (翻訳者注: 一般に、ブロックチェーンのライトノードは完全なブロックを同期する必要はなく、ブロックヘッダーを受信するだけです)
Rollup Header の生成ステップがないため、前述の Rollup 共有シーケンサには、Header 生成の前提条件であるステータス更新のためのトランザクションを実行する必要はなく、トランザクション データを集約する処理のみが含まれます。したがって、私はこれを共有アグリゲーター共有アグリゲーターと呼びたいと思います。
このバリアントでは、ロールアップ ユーザーは少なくとも DA レイヤー ライト ノード + 共有アグリゲーター ネットワークのライト ノード + ロールアップ フル ノードを信頼最小化状態で実行する必要があります。
この時点で、共有アグリゲーター ネットワークのライト ノードを通じて、公開されたアグリゲーター ヘッダー (ロールアップ ヘッダーではない) を検証する必要があります。前述したように、共有アグリゲーターはトランザクションのソート作業を実行し、公開されたアグリゲーターのヘッダーに、DA レイヤーでリリースされたバッチに対応する暗号化コミットメントが含まれています。
このようにして、Rollup ノード オペレーターは、DA レイヤーから受信したバッチ Batch が他のアグリゲーターではなく共有アグリゲーターによって作成されたことを確認できます。
※インクルージョンとは、トランザクションをブロックチェーンに組み込むプロセスです。 ※ソート 順序付けとは、ブロックチェーン内のトランザクションを特定の順序で並べるプロセスを指します。 ※実行とは、ブロックチェーン内でトランザクションを処理し、ステータスの更新を完了するプロセスを指します。
共有アグリゲータが包含と並べ替えを処理するため、Rollup の検閲耐性は共有アグリゲータに依存します。
L_ss が共有アグリゲーターのアクティビティ、L_da が DA レイヤーのアクティビティであると仮定すると、ロールアップ モデルのアクティビティは L = L_da && L_ss となります。つまり、2 つの部分のいずれかに liveness 障害がある場合、ロールアップにも liveness 障害が発生します。
簡単にするために、liveness を bool 値として見ていきます。共有アグリゲーターに障害が発生すると、ロールアップは動作を継続できなくなります。 DA 層ネットワークに障害が発生した場合でも、共有アグリゲーターはロールアップ ブロックのソフト コミットメントを提供し続けることができます。しかし現時点では、Rollup の属性は共有アグリゲーター ネットワークに完全に依存しており、後者の属性は元の DA レイヤーよりもはるかに劣っていることがよくあります。
上記のロールアップ スキームの検閲耐性を引き続き調査してみましょう:
このスキームでは、DA レイヤーは一部の特定のトランザクションをレビューできません (翻訳者注: トランザクション レビューでは、特定のトランザクションがチェーンにアップロードされることを拒否することがよくあります)。共有アグリゲーターによって送信されたトランザクションのバッチ全体に対してのみ開始できます。 トランザクション レビュー(バッチを DA レイヤーに含めることを拒否しました)。
ただし、Rollup ワークフローによれば、共有アグリゲーターがトランザクション バッチ Batch を DA レイヤーに送信する時点で、トランザクションの並べ替えはすでに完了しており、異なるバッチ間の順序も決定されています。したがって、DA レイヤーでのこの種のトランザクション レビューは、ロールアップの元帳の最終確認を遅らせる以外の効果はありません。
要約すると、検閲耐性のポイントは、単一のエンティティがシステム内の情報の流れを制御したり操作したりできないことを保証することである一方、ライブネスには、ネットワークの停止や障害が発生した場合でもシステムの機能と可用性を維持することが含まれると考えています。対立的な行動。これは現在主流の学術的定義と矛盾しますが、私が明確に述べた概念の定義を引き続き使用します。
バリアント 3: ベースのロールアップと共有アグリゲーターに基づく悲観的なロールアップ
共有アグリゲーターはユーザーとコミュニティに利益をもたらしますが、共有アグリゲーターへの過度の依存は避け、ユーザーが共有アグリゲーターから DA レイヤーに撤退できるようにする必要があります。前に紹介した 2 つのロールアップ バリアントを組み合わせることで、ユーザーは共有アグリゲーターを使用しながらトランザクションを DA レイヤーに直接送信できるようになります。 **
最終的なロールアップ トランザクション シーケンスは、共有アグリゲーターによって送信されたトランザクション シーケンスと、DA レイヤー ブロック内のユーザーによって直接送信されたロールアップ トランザクションに依存すると想定します。これをロールアップのフォーク選択ルールと呼びます。
ここでの集計は 2 つのステップに分かれています。まず、共有アグリゲーターが機能し、いくつかのトランザクションを集約します。次に、DA レイヤーは、共有アグリゲーターによって送信されたバッチと、ユーザーによって直接送信されたトランザクションを集約できます。
**現時点では、検閲抵抗分析はもう少し複雑です。 **DA レイヤー ネットワーク ノードは、次の DA レイヤー ブロックが生成される前に、共有アグリゲーターによって送信されたバッチを確認する場合があります。バッチ内のトランザクション データを知った後、DA レイヤー ノードは MEV 値を抽出できます。ネットワーク上のアカウントは、フロントから開始します。トランザクションを実行し、最初にそれらを DA レイヤー ブロックに含めてから、ロールアップ共有アグリゲーターによって送信されたバッチを含めます。
明らかに、3 番目のタイプのロールアップ バリアントのソフト コミットメントによって保証されるトランザクション注文の最終性は、前述の 2 番目のタイプのロールアップ バリアントよりも脆弱です。この場合、共有アグリゲーターは MEV 値を DA 層ノードに渡します。この点に関して、私は読者に、収益性の高い検閲済み MEV の活用に関する研究講義を視聴することをお勧めします。
現在、ロールアップ ネットワーク ユーザーによって DA 層に直接送信されたトランザクションの実行を遅らせる「再編成ウィンドウ期間」機能など、DA 層のネットワーク ノードがそのような MEV トランザクションを実行する能力を低下させるいくつかの設計スキームが登場しています。 。 Sovereign Labs は、「優先シーケンサー」の概念を導入した、ソフト確認を使用したベースド シーケンシングと呼ばれる設計提案でこれを詳細に説明しています。
MEV 問題はロールアップによって選択されたアグリゲータ スキームとロールアップ フォークの選択ルールに依存するため、一部のスキームでは MEV が DA 層にリークされず、一部のスキームでは MEV の一部またはすべてが DA 層にリークされますが、これは別の話題。
活性に関しては、このロールアップ スキームは、共有アグリゲーターのみがトランザクションを DA レイヤーに送信できるようにするスキームよりも利点があります。共有アグリゲーターで liveness 障害が発生した場合でも、ユーザーはトランザクションを DA レイヤーに送信できます。
最後に、信頼の最小化におけるロールアップ ユーザーの最小構成について説明します。
少なくとも DA レイヤー ライト ノード + 共有アグリゲーター ライト ノード + ロールアップ フル ノードを実行します。
この時点では、ロールアップ フル ノードがフォーク選択ルールに従ってトランザクション バッチを区別できるように、共有アグリゲーターによって発行されたアグリゲーター ヘッダーを検証する必要があります。
バリアント 4: オプティミスティック ベースのロールアップと集中ヘッダー ジェネレーター
Based Optimistic Rollup と呼ばれるバリアントと集中ヘッダー ジェネレーターについて説明します。 **このソリューションは DA レイヤーを使用してロールアップ トランザクションを集約しますが、ロールアップ ライト ノードを有効にするためにロールアップ ヘッダーを生成する集中ヘッダー ジェネレーターが導入されています。 **
ロールアップ ライト ノードは、1 回の不正行為の証明を通じてロールアップ トランザクションの正当性を間接的にチェックできます。ライト ノードはロールアップ ヘッダーの生成に関して楽観的であり、不正防止ウィンドウ期間が終了した後に最終確認を行います。もう 1 つの可能性は、ヘッダー ジェネレーターが誤ったデータを送信したという不正行為の証拠を誠実なフル ノードから受け取った可能性です。
単一ラウンドの不正行為の証明がどのように機能するかについては、この記事の範囲を超えているため、ここでは詳しく説明しません。 1 ラウンドの不正証明の利点は、不正証明ウィンドウ期間を 7 日間からある程度短縮できることであり、具体的な値はまだ決定されていませんが、従来の楽観的ロールアップよりも桁が小さくなります。ライトノードは、すべての基準が単一の不正証明で完全に提供されるため、ロールアップフルノードで構成されるP2Pネットワークを通じて、その後の紛争プロセスを待つことなく不正証明を取得できます。
上記のロールアップ モデルは、DA レイヤーをアグリゲーターとして使用し、その検閲耐性を継承します。この時点での DA 層は、トランザクションの格納と順序付けを担当します。集中ヘッダー ジェネレーターは、DA レイヤーからロールアップ トランザクション シーケンスを読み取り、それに応じて対応するロールアップ ヘッダーを構築します。ヘッダー ジェネレーターは、ヘッダーとステートルートを DA レイヤーに公開します。これらの Stateroot は、不正証拠を作成するときに必要です。 ** つまり、アグリゲーターはトランザクションの組み込みと並べ替えを担当し、ヘッダー ジェネレーターはトランザクションを実行して状態を更新し、Stateroot を取得します。 **
DA レイヤー (この時点ではロールアップのアグリゲーターとしても機能します) が十分に分散化されており、検閲に耐性があると仮定します。さらに、ヘッダー ジェネレーターは、アグリゲーターによって公開されたロールアップ トランザクションの順序を変更できません。ヘッダー ジェネレーターが分散化されている場合、唯一の利点はライブ性の向上ですが、ロールアップの他のプロパティは最初のバリアント ベース ロールアップと同じです。
ヘッダー ジェネレーターが liveness に失敗すると、ロールアップも liveness に失敗します。ライト ノードはロールアップ台帳の進行状況を追跡できませんが、フル ノードは追跡できます。この時点で、バリアント 4 で説明されているロールアップは、バリアント 1 で説明されているベース ロールアップに縮退します。どうやら、バリアント 4 で説明されている信頼を最小限に抑える最小構成は次のとおりです。
**DA レイヤー ライト ノード + ロールアップ ライト ノード。 **
バリアント 5: ベースの ZK ロールアップと分散型プルーバー マーケット
悲観的ロールアップ (ベースド ロールアップ) と楽観的ロールアップについて説明しましたが、今度は ZK ロールアップについて検討します。最近、Toghrul はアグリゲーター (シーケンサー) とヘッダー ジェネレーター (証明者) の分離に関する講演を行いました (ゼロ知識ロールアップにおけるシーケンサーと証明者の分離)。このモデルでは、パブリッシュ トランザクションを State Diff よりも Rollup データとして処理する方が簡単なので、前者に焦点を当てます。 **バリアント 5 は、zk-rollup に基づく分散型 Prover Market です。 **
ここまでで、ロールアップの仕組みについては理解できたはずです。バリアント 5 は、アグリゲーターの役割を DA 層ノードに委任し、トランザクションの組み込みと並べ替えの作業を実行します。 Sovereign-Labs のドキュメントを引用します。このドキュメントには、バリアント 5 のトランザクションのライフサイクルがわかりやすく説明されています。
ユーザーは、新しいデータ ブロックを L1 チェーン (DA 層) に公開します。これらのデータ ブロックが L1 チェーン上で最終化されると、それは論理的に最終的 (変更不可能) になります。 L1 チェーンのブロックが終了段階に入った後 (つまり、ロールバックできません)、ロールアップのフル ノードがこれらのブロックをスキャンし、ロールアップに関連するすべてのデータ ブロックを順番に処理し、最新のロールアップ ステート ルート Stateroot を生成します。 。この時点で、ロールアップ フル ノードの観点からは、これらのデータ ブロックは完成しています。
このモデルでは、ヘッダー ジェネレーターは分散型プルーバー マーケットによって機能します。
Prover 証明者ノード (ZKVM で実行されるフル ノード) の作業プロセスは、通常のロールアップ フル ノードのプロセスと似ており、DA 層のブロックチェーンをスキャンし、すべてのロールアップ トランザクション バッチを順番に処理して、対応するゼロ知識証明を生成し、公開します。 DA レイヤーチェーン上にあります。 (ロールアップ システムが証明者を動機付けたい場合、後者は生成された ZK 証明を DA 層チェーンに送信する必要があります。そうしないと、どの証明者が最初に ZK 証明を提出したかを判断できなくなります)。特定のトランザクション バッチに対応する ZK プルーフがチェーンにリリースされると、トランザクション バッチはすべての Rolup ノード (ライト ノードを含む) の目で確定されます。
バリアント 5 は、DA 層と同じ検閲耐性を備えています。分散型証明者市場は、ロールアップトランザクションをレビューすることができません。DA 層がすでに標準トランザクション順序を決定しているため、より良いアクティビティを取得してインセンティブ市場を作成するためだけであるため、ヘッダージェネレーター (ここでは証明者を指します) は分散型変更になります。
ここでのアクティビティは L = L_da && L_pm (証明者のアクティビティ) です。 Prover Market のインセンティブが一貫していない場合、またはアクティブな障害がある場合、Rollup ライト ノードはブロックチェーンの進行状況を同期できませんが、Rollup フル ノードは同期できます。フル ノードの場合、これは単なるフォールバックです。ベースドロールアップ/ペシミスティックロールアップへ。ここでの信頼最小化の最小構成は、オプティミスティック ロールアップの場合と同じです。
DA レイヤー ライト ノード + ロールアップ ライト ノード。
バリアント 6: ハイブリッド ベースのロールアップ + 集中型オプティミスティック ヘッダー ジェネレーター + 分散型証明者
DA レイヤー ノードを引き続きロールアップ アグリゲーターとして機能させ、トランザクションの組み込みと順序付けの作業を DA レイヤー ノードに委任します。
以下の図からわかるように、ZK ロールアップとオプティミスティック ロールアップは両方とも、ロールアップ台帳のソースとして、DA レイヤー上の同じ順序付けされたトランザクション バッチを使用します。これが、両方の証明システムを同時に使用できる理由です。DA 層上の順序付けられたトランザクションのバッチ自体は、証明システムの影響を受けません。
まずファイナリティについて話しましょう。ロールアップ フル ノードの観点から見ると、DA レイヤーのブロックがファイナライズされると、それに含まれるロールアップ トランザクション バッチもファイナライズされ、変更できなくなります。しかし、私たちはライトノードの観点から見たファイナリティをより重視しています。集中ヘッダー ジェネレーターが一部の資産を抵当にし、生成されたロールアップ ヘッダーに署名し、計算されたステートルートを DA レイヤーに送信すると仮定します。
前のバリアント 4 と同様に、ライト ノードはヘッダー ジェネレーターを楽観的に信頼し、発行したヘッダーが正しいと信じて、フル ノード ネットワークからの不正行為の証明を待ちます。不正証明のウィンドウ期間が終了し、フルノード ネットワークが不正証明を発行していない場合、ロールアップ ライト ノードの観点からは、ロールアップ ブロックが完了します。
重要な点は、ZK 証明を取得できれば、不正証明期間が終了するまで待つ必要がないということです。 1 ラウンドの不正証明に加えて、不正証明を ZK 証明に置き換え、悪意のあるヘッダー ジェネレーターによって生成された偽のヘッダーを破棄できます。
ライト ノードがロールアップ トランザクションのバッチの ZK プルーフを受信すると、バッチが完了します。
これで、高速なソフト コミットメントと高速なファイナリティが実現しました。
バリアント 6 は、DA レイヤーに基づいているため、DA レイヤーと同じ検閲耐性を備えています。生存性については、L = L_da && (L_op || L_pm) になります。これは、生存性の保証を追加することを意味します。集中型ヘッダー ジェネレーターまたは分散型プルーバー マーケットのいずれかにライブネス障害が発生した場合、2 つのうちもう一方に退化する可能性があります。
このバリアントでは、ユーザーの信頼を最小化するための最小構成は次のとおりです。
**1 つの DA レイヤー ライト ノード + 1 つのロールアップ ライト ノード。 **
まとめ：
アグリゲーターとヘッダー ジェネレーター。
シーケンサーの作業を、封じ込め、並べ替え、実行という 3 つの論理プロセスに分割します。
悲観的なロールアップとベースのロールアップは別のものです。
ニーズに応じて、さまざまなアグリゲーターおよびヘッダー ジェネレーター ソリューションを選択できます。
この投稿で紹介されている各ロールアップ バリアントは、同じデザイン パターンに従っています。
最後に、いくつか思うことがあります。以下について考えてください。