ブロック提案ウィンドウが終了した後、証明者は BP に対応する完全なトランザクション データを明らかにする必要があります。証明者によって投票された BP が選択された場合 (最高スコアは L1 コントラクトを通じて照会できます)、投票中に指定された証明ツリーのインデックスに対応するサブ証明ツリーを構築する必要があります。
**興味深い考え:**アンクルブロックと冗長な証明者作業について: B52 スキームは、各ラウンドで最も高いスコアを持ち効果的な BP が出現した後、このラウンドに出現する他の BP (完全な証明を提出した) をアンクルとして実際に使用します。ブロックすると、特定のおじさんブロック報酬を割り当てます。
これは実際には ETH POW コンセンサスメカニズムのアプローチに従っており、計算能力の過度の集中を避けるために、小規模マイニングプール/個々のマイナーの利益を保護するために、ブロック報酬の一部を受け入れられなかったブロック提案者 (マイナー) に割り当てる必要があります。計算能力が大規模なマイニング プールによって独占されることを回避します。したがって、イーサリアムが優れたパフォーマンスを発揮するアンクルブロックメカニズムを採用することも非常に賢明な選択です。
Aztec Labs の B52 提案の解析: ZK-Rollup はどのようにシーケンサー ノードの分散化を実現しますか?
著者: 0xhh、EthStorage
編集者: ファウスト、Geek web3
はじめに: Rollup が普及して以来、Sequencer の分散化は常に Ethereum/Celestia コミュニティの焦点であり、Layer2 の研究開発においては乗り越えられない山でもあります。この点に関して、さまざまなロールアップ スキームがノードの分散化に関するアイデアを提案しており、このトピックに非常に幅広い想像力の余地を提供しています。
この記事の著者は、有名な ZKRollup プロジェクト Aztec を例に挙げ、Aztec Labs が最近提案した B52 と Fernet という 2 つの提案を出発点として、ZKR がリーダーのシーケンサー ノードの分散化をどのように実現するかを分析します。
提案 B52: パーミッションレスシーケンサー方式
提案 B52 は、次の (理想的な) ことを達成することを目的としています。
分散型シーケンサー ネットワーク、L2 ノード自体が各ラウンドの提案者を選出します
分散型証明者ネットワーク、証明者ノードのハードウェア要件が低い
ロールアップは全体として検閲に対して優れた耐性を持っています。
L2で生成されたMEV値はL2ノードで取得される
L2 ブロックが DA 層に送信されると、より効果的なファイナリティが得られますが、不可逆的なファイナリティは ValidityProof (有効性証明) が送信されるまで待つ必要があります。
L2 トークンは優れた経済モデルを持つことができる
L2 ブロックとトランザクション データの両方が L2 p2p ネットワーク内で伝播されます
L2 は L1 のセキュリティを継承します
このスキームは、L2 ブロック生成プロセス全体を 3 つの時間段階に分割します。
このうちBPW（ブロック提案）ステージは、複数のシーケンサーSeuqnecerが異なるブロックを提案して競い合い、Proverが候補ブロックを選択して投票するプロセスです。
BAW (ブロック受け入れ) は、証明者がブロックの有効性証明を作成し、それを送信するプロセスです。
ブロック提案ウィンドウ (ブロック提案段階):
BPW は、ブロック提案、ブロック投票、集計 の 3 つの段階に細分できます。
ブロック提案 (BP) フェーズでは誰でもトランザクションを収集し、独自の BP コンテンツをブロードキャストできます。 BP コンテンツには、txs 注文ハッシュ、証明者報酬パーセンテージ、バーン トークン量の 3 つの部分が含まれます。
txs order hash: プロポーザーは、L2 トランザクション プール (mempool) から最も価値のあるトランザクションのバッチを選択して並べ替え、このトランザクションのバッチのハッシュ値を構築するブロックに入れます。
証明者報酬パーセンテージ: シーケンサーから証明者に共有されるブロック報酬パーセンテージ
バーン トークン量: 提案者によって破棄されるように提案された L2 ネイティブ トークンの数。その後、提案された BP が L2 p2p ネットワークに送信されます。
ブロック投票ステージ:
証明者は、p2p ネットワーク内のさまざまな提案者によって提案された BP を受け取った後、最も多くの報酬を獲得できる BP に投票します。ただし、投票の構成は非常に特殊です。
投票={ブロックハッシュ、プルーフツリーのインデックス}
BlockHash は証明者が投票する提案のハッシュであり、証明ツリーのインデックスは証明者が構築に参加する証明ツリーのリーフ インデックス値です (後述)。
集約集約: プロポーザーは、L2 p2p ネットワーク内の BP に対する証明者の投票を収集し、それらを集約して BP に入れ、L1 に送信します (各 BP には通常、それ自体に関連する投票レコードのみが含まれます)。
ここでは、BP が選択され、Rollp 元帳に含まれるための前提条件を強調する必要があります。
最高スコアを獲得:
スコア(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2
NUM_PROVERS (x) は BP によって取得された証明者投票の数、BURN_BID は BP によって破棄されることが提案された L2 トークンの数です。 BURN_BID が高くなるほど、最終的に BP 提案者が得る報酬が少なくなるため、この値は適切に設定する必要があります。
同時に、ブロック提案ウィンドウの終了前に BP を L1 に送信する必要があり、ブロック受け入れウィンドウの終了前に対応する有効性証明を L1 にアップロードする必要があります。
注: BP スコアの計算では、投票数が最大の割合を占め、次にバーン トークンの数が続きます。同時に、B52 スキームにより、複数のプロポーザー (実際にはシーケンサー) が有効な BP クォータをめぐって競合することができます。
B52 スキームでは、提案者 (シーケンサー) が事前にステーク トークンを使用せずに、自身の BP 内のバーン トークンの数を指定することのみを必要とします (EIP1559 の方法と同様)。これにより、ネットワークがよりパーミッションレス (アクセス許可なし) になる可能性があります。 L2ネイティブトークンにとっても有益であり、デフレを生み出します。
さらに、BP には完全なトランザクション データは含まれず、トランザクション シーケンスのハッシュのみが含まれますが、その理由はイーサリアム PBS スキームと同様であり、他の提案者による MEV のスパイ行為を防ぐことを目的としています。
ブロック受け入れウィンドウ (ブロック受け入れ段階) の詳細な説明:
ブロック提案ウィンドウが終了した後、証明者は BP に対応する完全なトランザクション データを明らかにする必要があります。証明者によって投票された BP が選択された場合 (最高スコアは L1 コントラクトを通じて照会できます)、投票中に指定された証明ツリーのインデックスに対応するサブ証明ツリーを構築する必要があります。
アステカのブロックに 2^13=16384 個のトランザクションが含まれており、証明者が 2048 人いると仮定すると、各証明者は 2^3=8 トランザクションからなるサブ証明ツリーを構築し、証明者は自身で構築したサブ証明ツリーを L2 p2p にブロードキャストします。通信網。提案者がそれを受け取ると、すべてのサブプルーフ ツリーを 1 つのブロックプルーフに集約します。
次に、Propsoer は集約された証明を L1 ロールアップ コントラクトに送信し、コントラクトは証明の正確さと対応する状態遷移結果を検証します。ここで、証明者が意図的に証明を提出しなかった場合、提案者が約束したブロック報酬の配当を獲得できないだけでなく、証明者になるためには減額されることに注意してください。事前にトークンを誓約します。したがって、Proposer (Sequencer) とは異なり、Prover は Permissionless ではありません。
State Advances (状態の進行段階) の詳細な説明:
ブロック受け入れウィンドウが終了すると、ロールアップ コントラクトは、ロールアップ台帳に含める最高スコアのブロックを選択し、提案者 (シーケンサー) が宣言した割合に従ってブロック報酬 Reward を提案者と証明者にそれぞれ送信します。前進。
**上記は Aztec の B52 ソリューションです。ただし、この記事の著者は、B52 提案にはいくつかの潜在的な問題があると考えています。 **
質問 1: 最高スコアのブロックの有効性証明が不完全な場合。提案で示されている解決策は、提案者が証明の 50% のみを提供した場合、ブロック報酬の 50% のみを取得できるため、提案者が意図的に完全な証明を提出しないという動機がないようにするというものです。同時に、証明者は証拠を契約書に直接提出することもできます。
提案の説明によると、完全なトランザクションの有効性証明なしでブロックを受け入れることは許容されます。これは実際には不合理です。理由は、zkrollup は、有効性の証明が与えられた場合にのみ、このブロックに対応する新しい状態が有効であると宣言するからです。
提案者が L1 に提出した集合証明に特定のトランザクションの証明が欠けている場合、このトランザクションの後に発生するすべてのトランザクションの状態遷移証明が無効であることは明らかです (トランザクションは順番に実行され、状態依存関係があるため)。また、このブロックに対応する新しい状態が有効であるかどうかを確認することもできません。
したがって、現時点では、すべてのトランザクション証明が送信されるまで無限に待機するブロック受け入れウィンドウに入るのが合理的な方法です。
質問 2: **最高スコアのブロックが不正なブロックであるかどうか (これは B52 スキームでは説明されていません)。 **BP にはトランザクション シーケンスのハッシュのみが含まれるため、悪意のある提案者は実際に二重支払いトランザクションなどの問題のあるトランザクションを意図的に構築する可能性があります。そこで今回は、実際には、最もスコアの高いBPが不正ブロックであることを証明するために、誰でも不正証明を提出できる機能をL1契約に追加する必要がある。
そして、この種の報告には報酬が与えられるべきであり、提案者がコントラクトに送信した書き込みトークンを、違法な証明を提出した報告者ノードに報酬を与えることができます。
**興味深い考え:**アンクルブロックと冗長な証明者作業について: B52 スキームは、各ラウンドで最も高いスコアを持ち効果的な BP が出現した後、このラウンドに出現する他の BP (完全な証明を提出した) をアンクルとして実際に使用します。ブロックすると、特定のおじさんブロック報酬を割り当てます。
これは実際には ETH POW コンセンサスメカニズムのアプローチに従っており、計算能力の過度の集中を避けるために、小規模マイニングプール/個々のマイナーの利益を保護するために、ブロック報酬の一部を受け入れられなかったブロック提案者 (マイナー) に割り当てる必要があります。計算能力が大規模なマイニング プールによって独占されることを回避します。したがって、イーサリアムが優れたパフォーマンスを発揮するアンクルブロックメカニズムを採用することも非常に賢明な選択です。
ロールアップ分散化の観点からの B52 提案の重要性: 提案者は分散化されており、誓約を必要とせず、参加基準は低い; ただし、最も価値のあるブロックを自分で構築する必要があり、投票を集める必要があるためです。実際、提案者のハードウェアしきい値は提案に記載されているほど低くはありません (たとえば、帯域幅がそれほど低くない可能性があります)。
したがって、最終的にブロックを生成できる提案者は、MEV のキャプチャに最も優れているブロック ビルダーであることが多いため、最終的には Mev-Boost ビルダーに似た比較的集中型のネットワークになるでしょう。
同時に、B52 スキームの証明者は資産を担保する必要がありますが、生成する必要があるのはサブツリー証明のみであるため、ブロック全体の証明を完全に生成する必要があるスキームと比較して、**証明者の分散度はより良くなります（ハードウェア要件を下げることができます）。 **
アクティブなライブネス: L2 にはトランザクションと投票/BP をブロードキャストするための独自の p2p ネットワークがあり、Sequencer と Prover は比較的分散化されているため、ネットワーク全体のライブネスは良好です。しかし、上で述べた 2 つの問題を解決する必要があります。1 つは、最高スコアを持つブロックが正当なブロックでなければならないということ、もう 1 つは、新しいブロックに入る前に、完全なブロック証明が L1 に送信されるまで待つ必要があるということです。州。したがって、TX プルーフの特定の部分の欠如によるロールアップ ネットワーク全体の誤動作 (ダウンタイム) を防ぐために、より効果的なインセンティブ メカニズムが必要です。
**検閲への耐性: **誰でもブロック提案 BP を公開できることを保証し、提案者だけがブロック証明を提出できるわけではないことを保証できれば、ネットワークは検閲に対して十分な耐性を持つことになります。
**ファイナリティ: **L2 のファイナリティはネットワークの稼働状態と密接に関係しています。これは、最終的に検証されたファイナリティはブロック プルーフの送信を待つ必要があるためですが、実際には、BP に対応するブロック コンテンツを信頼することもできます。 (悪意のあるトランザクションが含まれていない限り) スコアが最も高くなります。
このブロックは、ブロック受け入れウィンドウの開始時に表示されます。つまり、ユーザーは、ブロック提案ウィンドウが表示され、送信したトランザクションが受け入れられるブロックを待つだけで済みます。
L1 セキュリティの継承: 有効性証明を送信してステータスを更新する L2 として、L1 のセキュリティを継承できます。
提案フェルネット: 法的な提案者を選択するために VDF を導入します
フェルネット スキームの導入: VDF を通じて、ブロック生成サイクルの各ラウンドで、委員会内のさまざまなノード (つまり、シーケンサー ノードのセット) に対して推定スコアが設定され、ブロックはシーケンサーによって提案されます。最終スコアの最高点が有効な作品となります。
**まず、委員会に参加するにはどうすればよいですか?実際には、L1 で 16 ETH をプレッジし、**プレッジ操作が完了してから 4 つの L1 ブロックを待ってから、シーケンサー委員会に参加する必要があります。 Sequencer Committee から抜け出すには、L1 コントラクトの Unstake 関数を呼び出す必要があります。その後、さらに 3 日後にプレッジの残額を取り戻すことができます。
では、VDFとは何でしょうか？検証可能な遅延関数は検証可能な遅延関数です。この数学関数は厳密なシリアル実行特性を満たしています。いくつかの計算ステップを実行し、少なくとも予測可能な時間を消費します。 VDFで算出された一様正規分布を満たす値をScoreとして記録するため、SequencerはVDF Scoreを算出後、提案者としての選出確率を判定することができます。 **
シーケンサーの VDF は次のように計算されます。
スコア = VDF( プライベートキー , パブリック入力 )
public inputs = { 現在のブロック番号 , randao }
randao は、シーケンサーが将来のすべてのブロック高さで独自の VDF スコアを事前に計算するのを防ぐために使用される乱数です。
Fernet のプロセス全体は主に 3 つの段階に分かれています。
**提案フェーズ:**PROPOSAL_PHASE_L1_BLOCKS = 2 イーサリアム ブロック (このフェーズは 2 つの L1 ブロックにわたって続きます)
このステージの開始時に、各シーケンサーは VDF を使用して、現在のブロックの高さで対応する VDF スコアを計算します。 シーケンサーが、自分の VDF スコアが今回ブロックを生成する権利を獲得する可能性が高いと判断した場合 (スコアが正規分布を満たすと仮定)、プロポーザルから L1 にロールアップ コントラクトを送信します。プロポーザルには、前の L2 ブロックを指すトランザクション シーケンスのハッシュが含まれます。
unproven block: ロールアップ契約への提案のブロック内容のみが送信されます。次に、**シーケンサーは、未証明ブロックに対応するブロックの内容と VDF の証明を L2 p2p ネットワークに送信する必要があります。 **
ProvingPhase: PROVING_PHASE_L1_BLOCKS= 50 L1 ブロック (このフェーズでは 50 L1 ブロックが維持されます (約 10 分))
Prover は、L2 p2p ネットワークからブロック コンテンツ内の対応するトランザクションをすべて受信し、より高い VDF スコアを持つブロックの Proof を構築します。 Proof の構築も、複数の証明者が並行して連携する方法を採用しています (B52 スキームと同様)。
したがって、Sequencer は複数の異なるトランザクションに対応する Proof を最後に Block Proof (VDF Proof を含む) に集約し、L1 の Rollup コントラクトに送信する必要があります。 Block Proof を提出した Block Content は誰でもロールアップ契約に提出できます。
ファイナライズ: ブロックをファイナライズするには、L1 トランザクションを送信する必要があります。ファイナライズできるブロックは、ブロック コンテンツとブロック プルーフが送信され、指定された前のブロックがファイナライズされている必要があります。上記の条件を満たすことに基づいて、最高のスコアも必要です。
パイプライン ブロックの生成メカニズム: Fernet はパイプライン ブロックの生成メカニズムを採用していることに注意してください。N 番目のブロックの提案フェーズが終了すると、N+1 番目のブロックの提案が始まります (Aptos や他のパブリック チェーンも同様のプラクティスを持っています)。ただし、N+1 番目のブロックの場合は、L1 最終ブロック トランザクションを送信して検証に合格して最終ブロックになる前に、N 番目のブロックがファイナライズされるまで待つ必要があります。
潜在的な攻撃の次元: VDF スコアが最も高いシーケンサーが意図的に L2 p2p でブロック コンテンツをブロードキャストしない場合、ブロックの再編成が発生する可能性があります。
reorg 内の L2 ブロック数の計算: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 ブロック
解決策: アンクル ブロック メカニズムを増やして、L2 スロット (ブロック生成タイム スロット) ごとに完全な候補ブロックが 1 つだけになることを回避します。
分散化の観点からの Fernet の重要性: Sequencer は 16 ETH を誓約することで Sequencer Committee に参加し、参加閾値は高くありません (しかし低くはありません)。証明者は誓約を必要としませんが、証明者が証明を生成しなかった場合でもペナルティはありません。これは基本的に B52 スキームの逆です。
**アクティブなライブネス: **VDF+アンクルブロックメカニズムにより、各ラウンドに複数のブロックプロデューサーが存在することが保証されるため、ネットワーク全体のライブネスが保証されます。
**MEV: **MEV に関する考慮事項は最も特別であり、この計画では PBS を導入する予定で、シーケンサーとして高い VDF スコアを計算した後、ブロック ビルダーを直接見つけてより価値のあるブロックを構築できるようになります。
**検閲への耐性: **Fernet もイーサリアムと同じ PBS メカニズムを採用するため、本質的に、Fernet の反検閲問題はイーサリアムの PBS の問題と同等です。