• 原題:Decentralizing Rollup: Analyzing Aztec's Decentralized Sequencer Solution

はじめに:Rollupが有名になって以来、シーケンサーの分散化は常にEthereum/Celestiaコミュニティの焦点であり、レイヤー2開発作業で越えるのが難しい山でもあります。 この点に関して、さまざまなロールアッププランがノード分散化のアイデアを提案しており、このトピックに非常に幅広い想像力を提供しています。

本稿の著者は、有名なZKRollupプロジェクトであるAztecを例に、Aztec Labsが最近提案したB52とFernetという2つの提案をエントリーポイントとして、ZKRがシーケンサーノードの分散化をどのように実現しているかを分析しています。

提案B52:パーミッションレスシーケンサースキーム

提案B52は、(理想的には)次の目標を達成することを目的としています。

1. 分散型シーケンサーネットワークで、L2ノードがラウンドごとに提案者を選出します。

2. 分散型証明者ネットワークで、証明者ノードのハードウェア要件が低い。

3. 全体的に優れた耐検閲性を持つロールアップ。

4. L2 で生成された MEV 値は、L2 ノードによって取得されます。

5. L2ブロックをDA層に投入すると、比較的効果的なファイナリティを得ることができます。 不可逆的な最終決定には、有効性証明の提出を完了する必要があります。

6. L2トークンは、まともなトークノミクスモデルを持つことができます。

7. L2 ブロックとトランザクション データの両方が L2 の P2P ネットワークに伝搬されます。

8. L2 は L1 のセキュリティを継承します。

(B52 の提案は Rollup 構造を前提としており、提案者は基本的にシーケンサーです)

この計画では、L2ブロックの生産プロセス全体を3つのタイムステージに分けます。

ブロック提案ウィンドウ(BPW) ブロック承認ウィンドウ(BAW) 状態の進行

その中でもBPW(Block Proposal)ステージは、複数のシーケンサーがそれぞれ異なるブロックを提案して競い合い、Proverが候補ブロックを選んで投票するプロセスです。 BAW(Block Acceptance)は、ProverがブロックのValidity Proof を作成し、送信するプロセスです。 ブロック提案ウィンドウ(ブロック提案フェーズ):BPWは、さらにブロック提案、ブロック投票、集約の3つの段階に細分化できます。

(ブロック提案ウィンドウプロセス図)

ブロックプロポーザル(BP)ステージ:ステージ内の誰でもトランザクションを収集し、自分のBPコンテンツをブロードキャストできます。 BPコンテンツには、txs注文ハッシュ、証明報酬率、バーントークン量の3つの部分が含まれます。

txs order hash: 提案者は、L2トランザクションプール(mempool)から最も価値のあるトランザクションのバッチを選択し、それらをソートしてから、これらのトランザクションのハッシュ値を構築中のブロックに配置します。 証明者報酬率: シーケンサーが証明者と共有するブロック報酬の割合。 burn token amount: 提案者がバーンを提案し、BP を L2 P2P ネットワークに送信する L2 ネイティブ トークンの量。

ブロック投票ステージ:

証明者は、P2Pネットワーク内の異なる提案者から提案されたBPを受け取った後、最も多くの報酬を得ることができるBPに投票します。 ただし、投票の構成は特別です。

投票数={BlockHash, Index of Proof Tree}

BlockHashはProverが投票したいProposalのハッシュで、Index of Proof TreeはProverが構築に参加したいProof Treeのリーフインデックス値です(後述)

アグリゲーション:提案者は、L2 P2Pネットワーク内のBP上のProverから投票を収集し、それらを集約してBPに入れ、L1に送信します(各BPには、通常、それ自体に関連する投票記録のみが含まれます)。

ここで、BPが選択され、ロール元帳に含まれるための前提条件を強調する必要があります。

最高スコアを持つこと:

SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2'

NUM_PROVERS (x)は、このBPが受け取ったProver票の数であり、BURN_BIDは、このBPによってバーンされることが提案されているL2トークンの数です。 BURN_BIDが高ければ高いほど、BP提案者が最終的に得る報酬は少なくなるため、この値は適切に設定する必要があります。

同時に、このBPはブロック提案期間が終了する前にL1に提出する必要があり、対応する有効性証明はブロック承認期間が終了する前にL1にアップロードする必要があります。

注:BPのスコアリングでは、投票数が最も大きな重みを占め、次にバーントークンの数が続きます。 同時に、B52スキームでは、複数の提案者(実際にはシーケンサー)が有効なBPクォータをめぐって競争することができます。

B52スキームは、事前にトークンをステーキングすることなく、提案者(シーケンサー)が自分のBPでバーントークンの数を指定するだけで(EIP1559方式と同様)、ネットワークをよりパーミッションレス(入場許可なし)にすることができ、L2のネイティブトークンデフレーションを助長します。

また、BPには完全なトランザクションデータは含まれていませんが、イーサリアムのPBSスキームに似たトランザクションシーケンスのハッシュのみが含まれており、MEVが他の提案者によって覗き見されたり横取りされたりすることを回避することを目的としています。

ブロック承認ウィンドウの詳細な説明:

(ブロック受付ウィンドウの模式図、写真ではProof Acceptanceと表記)

ブロック提案ウィンドウが終了した後、証明者は自分のBPに対応する完全なトランザクションデータを公開する必要があります。 証明者が投票するBPが選択された場合(L1契約を通じて照会できる最高のスコアを持つ)、投票時に与えられた証明木のインデックスに対応するサブ証明木を構築する必要があります。

Aztecブロックに2^13=16384のトランザクション数量が含まれ、2048個の証明者があると仮定すると、各証明者は2^3=8個のトランザクションで構成されるサブプルーフツリーを構築します。 次に、プルーバーは構築したサブプルーフツリーをL2 P2Pネットワークにブロードキャストします。 それを受け取った後、提案者はすべてのサブプルーフツリーをブロックプルーフに集約します。

次に、Propsoer は集約された証明を L1 ロールアップ コントラクトに送信し、この証明と対応する状態遷移の結果の正確性を検証します。 ここで注意すべきは、Proverが故意に証明を提出しない場合、Proposerが約束したブロック報酬の配当を受け取れないだけでなく、Proverになるには事前にトークンをステーキングする必要があるため、スラッシュされるということです。 したがって、Proposer (Sequencer) とは異なり、Prover はパーミッションレスではありません。

State Advancesの詳細な説明:

ブロック承認ウィンドウが終了すると、ロールアップ契約はロールアップ台帳に含める最高スコアのブロックを選択し、ブロック報酬は提案者(シーケンサー)と証明者に提案者が事前に宣言した割合で送信されます。

上記はアステカのB52スキームです。 ただし、この記事の著者は、B52の提案にはいくつかの潜在的な問題があると考えています。

問題1:最高スコアのブロックの妥当性の証明が不完全であるとします。 提案書で提示された解決策は、提案者が証明の50%しか提供しない場合、ブロック報酬の50%しか得られないため、提案者が意図的に完全な証明を提出しないインセンティブを持たないようにすることです。 同時に、証明者は直接契約書に証明を提出することもできます。

提案の説明によると、ブロックが完全なトランザクションの有効性の証明を持たないことは許容されます。 zkrollup は、このブロックに対応する新しい状態が、妥当性の証明が与えられたときにのみ有効であることを宣言する。

提案者が最終的にL1に提出した集計証明に、あるトランザクションの証明が欠けている場合、このトランザクションの後に発生するすべてのトランザクションの状態遷移証明が無効であることは明らかであり(トランザクションは順番に実行され、状態依存性があるため)、このブロックに対応する新しい状態が有効であることを確認できません。

したがって、現時点では、合理的な方法は、すべてのトランザクションプルーフが送信されるまで、無限に待機するブロック承認ウィンドウに入ることです。

問題2:最高得点のブロックが不正なブロックであるとします(この点はB52プランでは説明されていません)。 BPにはトランザクションシーケンスのハッシュのみが含まれているため、悪意のある提案者は、二重支払いトランザクションなどの問題のあるトランザクションを意図的に構築する可能性があります。 このとき、L1契約に誰でも違法な証明を提出できる機能を追加する必要があります。 この不正な証明は、最高得点のBPが不正なブロックであることを証明するために使用されます。

また、この種のレポートは報われるべきです。 提案者からコントラクトに送られたすべてのバーントークンを、違法な証明を提出したノードへの報酬として渡すことができます。

興味深い考察:おじさんブロックと冗長な証明者作業について:B52プランは、実際には、最高で有効なBPが出現する各ラウンドの後、このラウンドで他のBP(完全な証明を提出した人)を叔父ブロックとして扱い、一定量の叔父ブロック報酬を配布します。

これは実際には、ETH POWコンセンサスメカニズムの慣行に従っています。 計算能力の過度な集中を避けるためには、ブロック報酬の一部を採用されていないブロックの提案者(マイナー)に配分し、小規模マイニングプール/個々のマイナーの利益を保護し、マイニングパワーが大規模マイニングプールに独占されるのを防ぐ必要があります。 したがって、イーサリアムの優れた機能を持つアンクルブロックメカニズムを採用することも非常に賢明な選択です。

ロールアップの分散化の観点からのB52提案の重要性:提案者は分散化されており、誓約を必要とせず、参入障壁が低い。 ただし、最も価値のあるブロックを単独で構築し、他の証明者から票を収集し、すべての証明を集約する必要があるため、提案者のハードウェアしきい値は提案書に記載されているほど低くありません(たとえば、帯域幅はそれほど低くない場合があります)。

したがって、最終的にブロックを作成できる提案者は、MEVのキャプチャに最も長けたブロックビルダーであることが多いため、最終的にはMev-Boost Builderと同様に、より中央集権的なネットワークになります。

同時に、B52スキームのProoverは資産を担保にする必要がありますが、サブツリープルーフを生成するだけでよいため、ブロックプルーフ全体を完全に生成する必要があるソリューションと比較して、Proverの分散化の度合いは高くなります(ハードウェア要件を下げることができます)。

Liveness:L2にはトランザクションと投票/BPをブロードキャストするための独自のP2Pネットワークがあり、SequencerとProverの両方が比較的分散化されているため、ネットワーク全体のLivenessは良好です。 しかし、上記の2つの問題を解決する必要があり、1つは最高得点のブロックが正当なブロックでなければならないこと、もう1つは、新しい状態に入る前に完全なブロック証明がL1に提出されるのを待つ必要があることです。 したがって、txプルーフがないためにロールアップネットワーク全体が正常に動作しない(停止する)ことを回避するには、より効果的なインセンティブメカニズムが必要です。

検閲耐性:誰でもブロック提案BPを公開でき、提案者だけがブロック証明を提出できるようにすれば、ネットワークは優れた検閲耐性を持つことになります。

ファイナリティ:L2のファイナリティは、最終的に検証されたファイナリティがブロックプルーフの提出を待つ必要があるため、ネットワークの活性度と密接に関連していますが、実際には、最高スコアのBPに対応するブロックコンテンツを信頼することもできます(悪意のあるトランザクションが含まれていない限り)。

このブロックはブロック承認ウィンドウの開始時に公開されるため、ユーザーはブロック提案ウィンドウの時間を待つだけで、トランザクションが配置されているブロックを採用することができます。

L1 セキュリティの継承:有効性の証明を送信して状態を更新する L2 は、L1 のセキュリティを継承できます。

Fernetの提案:提案者選定にVDFを導入

Fernetスキームの概要:各ブロック生成サイクルでVDFを利用して、委員会内の異なるノード(シーケンサーノードの集合体)に投影されたスコアが割り当てられ、シーケンサーによって提案された最終スコアが最も高いブロックが有効なブロックになります。

まず、委員会に参加するにはどうすればいいですか? 基本的には、L1に16ETHをステーキングし、ステーキングプロセスが完了した後、4つのL1ブロックを待ってからシーケンサー委員会に参加する必要があります。 シーケンサー委員会を退出するには、L1コントラクトのUnstake関数を呼び出す必要があり、その後、残りのステーキング量を取得するのに3日かかります。

次に、VDFとは何ですか? 検証可能な遅延関数は、厳密な逐次実行特性に従った数学関数です。 特定の計算ステップを実行し、予測可能な時間を消費します。 VDFによって計算された値をスコアとして表し、一様正規分布に従います。 したがって、シーケンサーが VDF スコアを計算すると、正当な提案者として選択される確率を判断できます。

シーケンサーの VDF 計算は次のとおりです。

スコア = VDF( 秘密鍵 , 公開入力 )

パブリック入力 = { current block number , randao }

randao は、シーケンサーが将来のすべてのブロック高さの VDF スコアを早期に計算するのを防ぐために使用される乱数です

Fernetの全体のプロセスは、主に3つの段階に分けられます。

1. 提案フェーズ2。フェーズ 3 の証明。終了

プロポーザルフェーズ:PROPOSAL_PHASE_L1_BLOCKS = 2イーサリアムブロック(このフェーズは2L1ブロック時間続きます)

このフェーズの開始時に、各シーケンサーは現在のブロック高さで独自の VDF スコアを計算します。 シーケンサーは、VDF スコアがこのブロックのブロック生成権を獲得する可能性が高いと判断した場合 (スコアが正規分布を満たしていると仮定した場合)、L1 ロールアップ契約にプロポーザルを提出します。 プロポーザルには、前のL2ブロックを指すトランザクションシーケンスのハッシュが含まれます。

unproven block: ロールアップ契約ブロックの内容にプロポーザルのみを送信したブロック。 次に、シーケンサーは、未証明のブロックとVDFの証明に対応するブロックの内容をL2 P2pネットワークに送信する必要があります。

証明フェーズ: PROVING_PHASE_L1_BLOCKS= 50 L1 ブロック (このフェーズは 50 L1 ブロック、約 10 分間続きます)

証明者は、L2 P2Pネットワークからブロックの内容に対応するすべてのトランザクションを受信し、VDFスコアが高いブロックのプルーフを構築します。 また、Proofの構築には、複数のProverが並行して協力する方法が採用されています(B52スキームと同様)。

したがって、シーケンサーは最終的に複数の異なるトランザクションのプルーフをブロックプルーフ(VDFプルーフを含む)に集約し、L1ロールアップコントラクトに送信する必要があります。 ブロック証明をすでにロールアップ契約に提出しているブロックコンテンツは、誰でも提出できます。

ファイナライズ:ブロックをファイナライズするためにL1トランザクションを送信する必要があり、最終的にファイナライズできるブロックは、提出されたブロックコンテンツとブロックプルーフを満たす必要があり、それが指す前のブロックはファイナライズされている必要があります。 これに基づいて、最高のスコアも必要です。

(パイプライン形式のブロックアウトプロセスでは、前のブロックの提案段階が終了するとすぐに、前のブロックの証明段階が終了するのを待たずに、次のブロックの提案段階が開始されます。

パイプラインブロック生成メカニズム:Fernetがパイプラインブロック生成メカニズムを採用していることは注目に値します。 ブロックNの提案フェーズが終了すると、ブロックN+1の提案が始まります(Aptosや他のパブリックチェーンが行うのと同様)。 ただし、ブロック N+1 の場合、ブロック N がファイナライズされるのを待ってから、L1 の最終ブロック トランザクションを送信し、最終ブロックになるように検証する必要があります。

潜在的な攻撃ベクトル:VDF スコアが最も高いシーケンサーが L2 P2P でブロック コンテンツを意図的にブロードキャストしない場合、ブロックの再編成(再編成)につながる可能性があります。

再編成の L2 ブロック数量の計算: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 ブロック

解決方法: アンクル ブロック メカニズムを導入して、各 L2 スロット (ブロック生成タイム スロット) に完全な候補ブロックが 1 つだけにならないようにします。

Fernetにおける分散化の意義:シーケンサーは16ETHをステーキングしてシーケンサー委員会に参加し、参入敷居は高くありません(ただし、低くもありません)。 プルーバーはステーキングを必要としませんが、プルーバーがプルーフを生成しない場合、ペナルティはありません。 これは基本的にB52スキームとは逆です。

Liveness:VDF + uncleブロックメカニズムにより、各ラウンドに複数のブロックプロデューサーが存在することを保証できるため、ネットワーク全体のLivenessを保証できます。

MEV:MEVの考察は特にユニークです。 このスキームではPBSの導入が計画されているため、シーケンサーは高スコアのVDFスコアを計算した後、ブロックビルダーに直接アプローチして、より価値のあるブロックを構築できます。

検閲耐性:Fernetはイーサリアムと一致するPBSメカニズムも採用するため、本質的に、Fernetの検閲耐性の問題は、イーサリアムのPBS検閲耐性の問題と同等です。

免責事項：

1. この記事は[Geek Web3]、原題「ollup Decentralization: Analysis of Aztec's Decentralized Sequencer Solution」からの転載です,すべての著作権は原作者に帰属します[xhhh,EthStorage]。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。