DA レイヤーに liveness 障害がある場合、ロールアップにも liveness 障害が発生します。これに基づいて、ロールアップは、すべての HP がライブネスに失敗した場合にのみライブネスに失敗します。
バリアント 8: 共有アグリゲーター + 分散証明者の ZK ロールアップ
バリアント 8 は、トランザクションの包含と並べ替えに共有アグリゲーター Shared Aggregator (SA) を使用します。SA はトランザクション シーケンス バッチを DA レイヤーに発行します。トランザクション シーケンスが DA レイヤーに送信された後、トランザクションの順序は理論的には変更されません。
バッチが DA 層に送信される前に、共有アグリゲーター SA はまず Batch+ SA ヘッダーをフル ノードと証明者にブロードキャストし、SA ヘッダーをライト ノードにブロードキャストできますが、DA 層上にないバッチは現時点ではまだ不安定であり、いつブロックされる可能性もあります。
共有アグリゲーター SA によって発行されるヘッダーは、HP によって発行されるバッチ ヘッダーと同じではないことに注意してください。 SA ヘッダーには、ロールアップ ノードによって DA 層から読み取られたバッチが、他の人によって偽造されたものではなく、実際に SA によって生成されたものであることを保証するための暗号証明が含まれています。
バリアント 9: 複数の DA を使用した共有アグリゲーター + 分散型証明者 + ZK ロールアップ
バリアント 9 は実際には上記のバリアント 8 に基づいていますが、複数の DA レイヤーがあり、ロールアップのアクティビティを効果的に向上させることができます。バリアント 9 では、共有アグリゲーター SA はトランザクション シーケンス バッチを任意の DA レイヤーに公開でき、独自のニーズに応じてデータを公開するさまざまな DA レイヤーを選択できるため、次のようなロールアップの関連パラメーターを動的に最適化できます。データコスト、セキュリティ、ライブネス、トランザクションレイテンシー、ファイナリティ。
ロールアッププロジェクト当事者のニーズに応じて、最も安く、最も安全で、最もアクティブで、決済速度の高いロールアップをカスタマイズでき、最もスループットの高い DA レイヤーを選択できます。一般に、特定のロールアップ ブロック高さ (10,000 番目など) のバッチが異なる 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 研究者: 4 つの新しいロールアップ スキームの解釈
原作者:NashQ、セレスティア
編纂:リンク「Geek web3」
はじめに: この記事は、4 つの新しいロールアップ バリアントを含む、ロールアップ モデルの分析に関する Celestia 研究者の NashQ の分散したスピーチで構成されています。以前、「Celestia の観点からロールアップを分析: 検閲耐性と 6 つのバリエーションのアクティビティ」という記事で 6 つの異なるロールアップ モデルを挙げましたが、この記事はこのロールアップ モデルに基づいて新たに抽象化した 4 つのカテゴリです。
以前は、NashQ は Sequencer を 2 つのモジュール (アグリゲーター + ヘッダー プロデューサー) に分割し、トランザクション命令のライフサイクルから始めて、Celestia のソブリン ロールアップの動作原理を説明し、検閲防止とさまざまなロールアップ バリアントのアクティビティ、およびユーザー エクスペリエンスについて説明しました。信頼を最小限に抑えることを前提とした最小構成 (つまり、Trustless を実現するには、ロールアップ ユーザーが少なくともどのタイプのノードを実行する必要があるか)。
バリアント 7: ベースのロールアップ + 複数のヘッダー プロデューサ + 「最高のプロトコル MEV」
このロールアップ バリアントでは、ロールアップ ネットワーク ユーザーがトランザクション データを DA 層ブロックに直接パブリッシュし、ヘッダー プロデューサがトランザクションのソートを担当し、MEV が抽出されます。明らかに、ロールアップ バリアント 7 のトランザクション集約/包含プロセスは、以前に導入されたベースド ロールアップと同じであり、DA レイヤーの責任です (ユーザーはトランザクションを DA レイヤーに直接送信します)。ただし、トランザクションの順序はベースド ロールアップとは異なります。ロールアップ、および DA 層ノードは責任を負いません。ソートは HP (ヘッダープロデューサー) の責任です。
以下では、互いに競合し、「最高プロトコル MEV」という名前の MEV 割り当てプロトコルに従う 3 つの HP があると仮定します。このプロトコルは、Cosmos エコシステムの Skip Protocol によって提案されました。イーサリアム PBS スキームとは異なり、ブロック ビルダーはブロックチェーン ネットワークのバリデーターに追加の「チップ」を支払う必要があり、最も多くのチップを支払ったビルダーによって構築されたブロックが採用されます。バリデーターによる。同時に、SKIPプロトコルは「ソブリンMEV」の概念を提案し、パブリックチェーンネットワーク内のすべてのバリデーターとコミュニティが自主的にMEVを割り当てることを許可し、イーサリアムPBSのビルダーがますます増えているという問題を解決することを目的としています。フライホイール効果により、より集中化されます (ただし、これはこの記事の核心ではありません)。
この記事で紹介したロールアップ バリアントでは、さまざまなヘッダー プロデューサーが自分で作成したバッチ ヘッダーでチップ金額を宣言する必要があり、最も多くのチップを支払った HP によって発行されたバッチ ヘッダーが、ロールアップ ノードによって (台帳を通じて) 自動的に受け入れられます。ノードコードに記述されています。フォーク選択アルゴリズムは自動的に行われます)。
さらに、HP がリリースするバッチ ヘッダーは、DA 層上の完全なトランザクション バッチ バッチに対応できる必要があります。
HP が発行したヘッダーにエラーがある場合、たとえば、トランザクション実行結果の Stateroot が間違っている、またはバッチ内のトランザクションが含まれていない (トランザクションが失われた) 場合、正直なロールアップ フル ノードはライト ノードに不正証拠をブロードキャストします。 。しかし、通常 (楽観的に見て)、ライト ノードは HP が発行したヘッダーを受け入れることができ、それに問題はないと信じています。
検閲分析への耐性: このロールアップには、トランザクション レビューを実施できるポイントが 2 つあります。 1 つ目は DA 層に存在し、トランザクションの内容を検閲し、特定のユーザーが関与するトランザクションを拒否できます。 2 番目の層は依然として DA 層に存在しており、HP によって送信されたヘッダーをレビューして特定のヘッダーの組み込みを拒否することができるため、ヘッダーと共謀してレビュー攻撃を通じて MEV を独占することができます。
同時に、HP はトランザクションの順序付けに責任を負い、不正行為の証拠が存在するため (HP がトランザクションに負ける状況をターゲットにすることができます)、HP 自体が検閲攻撃を開始することは多くありませんが、ノードに賄賂を渡すことは可能です。これを行うには、DA レイヤーのノードを使用します (または、いくつかの DA レイヤーを単独で実行します)。これに対する解決策は、ロールアップ トランザクション シーケンスが完了するまでのウィンドウ期間を延長し、悪意のある DA レイヤー ノードによって拒否されたヘッダーを、ウィンドウ期間の終了前に誠実な DA レイヤー ノードによってチェーンに含めることができるようにすることです。 DA層ノードのレビュー 攻撃の難易度。
**アクティビティ:**L = L_da && ( L_hp1 || L_hp2 || L_hp3 )
DA レイヤーに liveness 障害がある場合、ロールアップにも liveness 障害が発生します。これに基づいて、ロールアップは、すべての HP がライブネスに失敗した場合にのみライブネスに失敗します。
バリアント 8: 共有アグリゲーター + 分散証明者の ZK ロールアップ
バリアント 8 は、トランザクションの包含と並べ替えに共有アグリゲーター Shared Aggregator (SA) を使用します。SA はトランザクション シーケンス バッチを DA レイヤーに発行します。トランザクション シーケンスが DA レイヤーに送信された後、トランザクションの順序は理論的には変更されません。
バッチが DA 層に送信される前に、共有アグリゲーター SA はまず Batch+ SA ヘッダーをフル ノードと証明者にブロードキャストし、SA ヘッダーをライト ノードにブロードキャストできますが、DA 層上にないバッチは現時点ではまだ不安定であり、いつブロックされる可能性もあります。
共有アグリゲーター SA によって発行されるヘッダーは、HP によって発行されるバッチ ヘッダーと同じではないことに注意してください。 SA ヘッダーには、ロールアップ ノードによって DA 層から読み取られたバッチが、他の人によって偽造されたものではなく、実際に SA によって生成されたものであることを保証するための暗号証明が含まれています。
Prover は、DA レイヤーからトランザクション バッチ Batch を読み取り (共有アグリゲーターに直接同期することもできます)、ZK Proof+Batch ヘッダーを生成し、それを DA レイヤーに公開します。明らかにプルーバーはHPの役割を果たしました。
Rollup のライト ノードの場合、ZKProof を受信した後、この Batch に含まれるトランザクション シーケンスが最終的に確認されます。もちろん、Prover は DA 層チェーンの下のロールアップ p2p ネットワークを通じて ZKP をブロードキャストすることもできるため、ライトノードでより速く受信できるようになりますが、現時点では ZKP は DA 層に送信されておらず、「ファイナリティ」。
バリアント 9: 複数の DA を使用した共有アグリゲーター + 分散型証明者 + ZK ロールアップ
バリアント 9 は実際には上記のバリアント 8 に基づいていますが、複数の DA レイヤーがあり、ロールアップのアクティビティを効果的に向上させることができます。バリアント 9 では、共有アグリゲーター SA はトランザクション シーケンス バッチを任意の DA レイヤーに公開でき、独自のニーズに応じてデータを公開するさまざまな DA レイヤーを選択できるため、次のようなロールアップの関連パラメーターを動的に最適化できます。データコスト、セキュリティ、ライブネス、トランザクションレイテンシー、ファイナリティ。
ロールアッププロジェクト当事者のニーズに応じて、最も安く、最も安全で、最もアクティブで、決済速度の高いロールアップをカスタマイズでき、最もスループットの高い DA レイヤーを選択できます。一般に、特定のロールアップ ブロック高さ (10,000 番目など) のバッチが異なる DA レイヤーに同時に存在する必要はありませんが、存在する場合は、その内容が一貫している必要があります。同じ高さで異なるコンテンツを持つ 2 つのバッチが異なる DA レイヤーに表示される場合、それは共有アグリゲーターが意図的に台帳をフォークしていることを意味します。
ここでは、Variant 8 と同じ分散型 Prover マーケットを選択します。Prover はヘッダー プロデューサーとして機能し、バッチ ヘッダーと ZKProof をリリースします。この時点で、証明者はバリアント 7 (SKIP プロトコルによって提案) で言及されているチップ オークション メカニズムを通じて競争する必要があります。
Variant 9 のトランザクション決済速度 (最終確認速度) は、ブロック生成が最も速い DA 層の影響を受けます。
検閲への耐性: 共有アグリゲーターは検閲攻撃に関与する可能性がありますが、オプションの DA レイヤーを増やすと、DA レイヤーに関連する検閲攻撃の可能性が減ります。
**活性:**L = ( L_da1 || L_da2) && L_sa && L_pm。
バリアント 9 は、前のバリアントよりもアクティブでした。すべての DA 層ネットワークでライブ障害が発生しない限り、すべてが正常に動作します。
信頼最小化のための最小構成: 異なる DA レイヤーのライト ノード + 共有アグリゲーター ネットワーク ライト ノード + ロールアップ ライト ノード。
明らかに、採用する DA レイヤーが増えれば増えるほど、より多くのライト ノードを実行する必要があります。しかし、そうすることで得られるメリットがコストを上回る可能性があります。
バリアント 10: 2 つの ZK ロールアップ + 分散型証明者、それぞれがチェーン上にライト ノードを持つ (ブリッジ可能)
バリアント 10 は、相互にブリッジできる 2 つの ZK ロールアップを作成するためのバリアント 5 の拡張です。バリアント 5 (Based Rollup+ZKP+Decentralized Prover) と比較すると、バリアント 10 には追加のリレーラーの役割があり、バッチ ヘッダー + ZK-Proof をトランザクションにラップします。このトランザクションが Rollup2 で実行されている Rollup1 ライト ノードに送信される限り、Batch の特定の高さが有効であることを証明できます。もちろん、Rollup2 には DA 層を実行するライト ノードも必要です。
これは、鎖橋間の信頼を最小限に保つための前提条件です。ただし、イーサリアムロールアップ(スマートコントラクトベースのSCロールアップ)からイーサリアムへのクロスチェーンの場合、DA層はイーサリアムそのものであるため、ロールアップのDA層ライトノードを実行する必要はありません。これは、Celestia のソブリン ロールアップとは大きく異なります。Celestia のロールアップは相互にまたがっており、相手の DA レイヤーのライト ノードを実行する必要があります。
Relayer がクロスチェーン トランザクションを送信すると、Rollup2 の Aggregator 2 と HP2 によって処理されます。 Rollup2 のノードがロールアップ間でトランザクションをどのように処理するかを理解するために、両方をグラフに追加します。
Rollup2 の中継者は、Rollup 2 のバッチ ヘッダーと ZKP を取得し、それらを Rollup1 に送り返します。ロールアップ 1 には、ロールアップ 2 ライト ノードと DA レイヤー ライト ノードもあります。
モデルをさらに単純化することができます。 2 つのロールアップが同じ共有アグリゲーターとヘッダー プロデューサーを使用している、つまり、使用している DA レイヤーが重複していると仮定します。
この場合、中継者を直接禁止することができます。バッチ ヘッダーと ZK プルーフは HP によって同じ DA レイヤーに公開されているため、別のロールアップのヘッダーや ZKP などのデータは DA レイヤーで直接読み取ることができ、リレイヤーを介して共有アグリゲーターに渡す必要はなくなりました。
明らかに、同じ DA レイヤーを使用するロールアップはリレーレイヤーに依存する必要はありません (多くのクロスチェーン ブリッジはリレー ノードに依存します)。これにより、クロスチェーン ブリッジのセキュリティ問題を解決できます (この観点から、イーサリアムの SC ロールアップ間のクロススパンは、異なるパブリック チェーン間のクロスチェーンよりも安全です)。
このとき、 **信頼最小化の最小構成:**DA 層ライトノード + ロールアップ ライトノード。