🍚 blog

Native rollupsを翻訳する

JP
cryptography

Native rollups（ネイティブロールアップ）は、Ethereum ResearcherのJustin Drakeによって2025/01/21に投稿された、L2ロールアップのセキュリティカウンシルや攻撃ベクトルを排除するための提案です。Justinはこのアイデアを2024/04のZK Summit 11でも話しています。

概要

ネイティブなL1 EVM実行エンジンをアプリケーションレイヤーに公開するエレガントなEXECUTE プレコンパイルの導入を提案します。ネイティブ実行ロールアップ/ネイティブロールアップとは、ユーザーtxのバッチに対するEVM状態遷移をEXECUTEで検証するロールアップです。これを「プログラマブル実行シャード」と考えることができ、これはプレコンパイルを包みこんで、シーケンス、ブリッジング、強制インクルージョン、ガバナンスなどのEVM外のシステムロジックを扱う導出関数を提供します。

EXECUTEプレコンパイルはバリデータによって直接強制されるため、(zk)ELクライアント多様性を享受し、バグが無くL1ハードフォークを通じたEVMのアップグレードに前方互換性をもたらすEVM-equivalenceを提供します。

EXECUTEプレコンパイルは、EVMのエミュレーションとメンテナンスのために複雑なインフラ（例: fraud proofゲーム、SNARK回路、セキュリティカウンシル）を取り除くことで、EVM-equivalentなロールアップ開発を大幅に簡素化します。EXECUTEを用いれば、シーケンス、強制インクルージョン、ガバナンスの特別な処理を不要にするシンプルな導出関数を用いて、数行のSolidityコードだけで最小限のネイティブおよびベースロールアップをデプロイできます。

さらには、ネイティブロールアップはリアルタイム決済を楽しむことができ、リアルタイムの証明を心配する必要がないため、同期的なコンポーザビリティを大幅に簡素化します。

この文書は2部構成で、提案されたプリコンパイルの説明から始まり、ネイティブロールアップに関する議論で終わります。

筆者による抽象的な図解:

従来のロールアップ
従来のロールアップ

ネイティブロールアップ
ネイティブロールアップ

Part1: EXECUTEプレコンパイル

構成

インプット: pre_state_root, post_state_root, trace, gas_used

アウトプット: true/false

以下の場合にのみtrueを返す

  1. traceは適切にフォーマットされた実行トレースである（例: L2トランザクションリストと対応する状態アクセス証明）
  2. トレースのステートレス実行がpre_state_rootで始まりpost_state_rootで終わる
    • traceは、calldata、ブロブ、状態、またはメモリから入手可能なEthereumデータを指していなければなりません。
  3. トレースのステートレス実行は確かにgas_usedを消費する
    • L1ブロック全体でEXECUTE呼び出しに消費された累積ガスを計測し価格設定するため、EIP-1559スタイルのメカニズムが存在します。具体的には、累積ガスリミットEXECUTE_CUMULATIVE_GAS_LIMITと累積ガスターゲットEXECUTE_CUMULATIVE_GAS_TARGETがあります。（L1 EVMがバリデータによってステートレスに強制可能になった場合、これらの累積リミットとターゲットはL1のEIP-1559メカニズムと統合される可能性があります。）
    • プリコンパイルの呼び出しには固定のL1ガスコストEXECUTE_GAS_COSTがかかり、さらにgas_used * gas_priceが追加されます。ここでgas_price（ETH/ガスで表される）はEIP-1559スタイルのメカニズムによって設定されます。プリコンパイルがfalseを返す場合でも、全額の前払いが引き落とされます。

再実行による強制

EXECUTE_CUMULATIVE_GAS_LIMITが十分に小さい場合、バリデータは単純にトレースを再実行することでEXECUTE呼び出しの正確性を検証できます。再実行に基づくプリコンパイルの初期デプロイは、プロトダンクシャーディングでブロブの単純な再ダウンロードがそうであるように、フルDankshardingへの足掛かりとして機能することができます。注意すべき点は、単純な再実行はバリデータに対してステートの増加や帯域幅のオーバーヘッドを引き起こさず、実行のオーバーヘッドはCPUコア間で並列化可能であることです。

バリデータは再実行のためにトレースのコピーを明示的に保持する必要があり、これによりDAS（データ可用性サンプリング）を通じてダウンロードしないサンプルデータのポインタを使用することはできません。Optimistic ネイティブロールアップは依然としてデータをブロブに投稿することができ、fraud proofゲームではcalldataにフォールバックします。また、OptimisticネイティブロールアップはEXECUTE_CUMULATIVE_GAS_LIMITを大幅に超えるガスリミットを持つことができます。これは、fraud proofのチャレンジを解決するために、EXECUTEプリコンパイルが小さなEVMセグメントに対して一度だけ呼び出される必要があるからです。

歴史的な注記として、2017年にVitalikは類似の「EVM inside EVM」プリコンパイル、EXECTXを提案していました。

SNARKsによる強制

大きなEXECUTE_CUMULATIVE_GAS_LIMITを解除するためには、バリデータがオプションでSNARK証明を検証するのは自然なことです。ここからは、無効なブロック（または無効なトランザクション）が無操作（no-ops）として扱われる1スロット遅延実行を仮定します。（遅延実行についての詳細は、ethresearchのこの投稿、EIP、このFrancescoデザインを参照してください。）1スロット遅延実行は証明に数秒、つまり一つのスロット全体を提供します。また、これによりMEV駆動の証明競争による中央集権化ベクトルを回避します。

注意すべき点は、EXECUTEがSNARKによって強制されても、明示的な証明システムや回路はコンセンサスに組み込まれないことです。（EXECUTEプリコンパイルは明示的な証明を入力として取りません。）代わりに、各ステーキングオペレーターは今日のELクライアントの選択と同様に、自分が信頼するzkEL検証クライアントを自由に選ぶことができます。この設計決定の利点は、次の「オフチェーン証明」セクションで説明されます。

ここからは、Attester-Proposer Separation（APS）の文脈での交互の実行とコンセンサススロットを持つ洗練された実行プロポーザーを仮定します。証明を適時に（1スロット以内に）生成するよう合理的な実行プロポーザーを奨励するため、attesterは実行ブロックnの証明が利用可能な場合にのみ実行ブロックn+1にattestすることを義務付けます。（ブロックn+1とブロックnのEXECUTE証明をp2pレイヤーで一緒にバンドルすることを提案します。）証明をスキップする実行プロポーザーはスロットを逃す可能性があり、手数料やMEVを見逃すことになります。さらに、実行スロットを逃した場合に固定のペナルティ（例えば1 ETH）を適用し、それが証明のコストを常に上回るように設定します。

APSの文脈では、実行スロットを逃した場合でもコンセンサスブロックの生成はブロックされません。しかし、ライトクライアントがステートレス再実行なしでチェーンの先端の状態を容易に読み取るために、証明の適時生成は重要です。次の実行プロポーザーがスロットを逃した場合でも、ライトクライアントのために証明が適時に生成されるように、我々は利他的少数派の証明者仮定に依存します。一人の利他的な証明者であれば1スロット以内に証明を生成できます。必要のない冗長な証明を避けるために、ほとんどの利他的な証明者は予備で待機し、1スロット以内に証明が到着しない場合にのみ作動し、最大2スロットの遅延でフェイルセーフとして機能する可能性があります。

注意すべき点は、EXECUTE_CUMULATIVE_GAS_LIMITが、利他的少数派の証明者仮定が信頼できるものであるために、また実行提案が非現実的に洗練されていないために、十分に低く設定される必要があることです。保守的な政策では、EXECUTE_CUMULATIVE_GAS_LIMITを高性能のMacBook Proのようなラップトップでもシングルスロットの証明が可能なレベルに設定します。より実用的かつ積極的な政策では、小規模なGPUクラスター、そして最終的には十分に一般化したSNARK ASIC証明者を対象にする可能性があります。

オフチェーン証明

再確認しますが、zkELのEXECUTE証明はチェーン上に載せず、オフチェーンで共有することを提案します。証明を組み込まないという美しいアイデアは最初にVitalikによって提案され、以下のような複数の利点があります：

  • 多様性: バリデータは信頼する開発チームからの証明検証者（証明システムや回路を含む）を自由に選ぶことができます。今日、検証者が信頼するELクライアントを選ぶのと同じように。これにより多様性を通じて堅牢性が提供されます。zkEL検証クライアント（およびそれらの一部を支えるzkVM）は、複雑な暗号ソフトウェアであり、一つのクライアントのバグがEthereum全体をダウンさせるべきではありません。
  • 中立性: zkEL検証クライアントの市場を持つことで、コンセンサス層が技術の勝者を選ばなくて済みます。例えば、zkVM市場は非常に競争的であり、Risc0やSuccinct、または他の多くのベンダーから勝者を選ぶことは中立的でないと見なされる可能性があります。
  • シンプルさ: 特定のSNARK検証者をコンセンサス層に組み込む必要がないため、コンセンサス層の仕様が大幅に簡素化されます。ステートアクセス証明のフォーマットを組み込むだけで十分で、特定の証明検証実装の詳細は不要です。
  • 柔軟性: バグや最適化が見つかった場合、影響を受ける検証者はハードフォークを必要とせずにクライアントを更新できます。

オフチェーン証明は、管理可能な複数の問題を導入します：

  • 証明負荷とp2pのfragmenttation(断片化): 単一の正統な証明がないため、複数の証明（少なくとも各zkELクライアントごとに一つ）が必要です。各zkELクライアントのカスタマイズ（例えば、一つのRISC-V zkVMを別のものに交換する）は異なる証明を必要とします。同じく、各zkELのバージョンアップデートも異なる証明を必要とします。これにより証明負荷が増加し、証明タイプごとに別のゴシップチャンネルがある場合、p2pネットワークが断片化されます。
  • 少数派zkEL: 少数派のzkELに対する証明生成を奨励するのは難しいです。合理的な実行プロポーザーは、スーパーマジョリティのアテスターに到達し、スロットを見逃さないために十分な証明しか生成しないかもしれません。これに対抗するために、ステーキングオペレーターは今日のVouchオペレーターと同様に、複数のzkELクライアントを並行して実行することを社会的にも奨励されます。k-of-n設定を実行することは、特に攻撃者が任意のEXECUTE呼び出しに対して証明を作成できるような健全性のバグに対するヘッジとして、セキュリティを向上させる追加の利点があります。

オフチェーン証明は、リアルタイム決済L2に対する非効率性も導入します:

  • 代替DAなし: EXECUTEへのtrace inputがL1バリデータに対して利用可能である必要があるため、リアルタイム決済L2（つまり、すぐに正規のステートルートを更新するL2）はL1 DAを消費しなければなりません、つまりロールアップでなければなりません。注意すべきは、fraud proofゲームを通じて決済を遅らせるOptimistic L2にはこの制限がない、つまりvalidiumであることが可能です。
  • ステートアクセスオーバーヘッド: トレースがステートレスに実行可能である必要があるため、読み取りまたは書き込みされたステートトライのリーフを含める必要があります。これにより、通常のL2ブロックに対して小さなDAオーバーヘッドが発生します。注意すべきは、Optimistic L2にはこの制限がないことです。ステートトライのリーフはfraud proofのチャレンジでのみ必要であり、チャレンジャーはトライのリーフを再計算できます。
  • ステート差分なし: trace が与えられた場合、証明はpermissionlessであるべきなので、ロールアップのステート差分は不可能です。しかし、コンセンサスに特化した証明が組み込まれた場合、ステートレスアクセス証明やEVMトランザクションの署名を圧縮することは可能です。

RISC-Vネイティブ実行

今日の事実上のRISC-V zkVMへの収束を考えると、RISC-Vステート遷移をEVMにネイティブに公開する機会があり（Arbitrum Stylus 3におけるWASMと同様）、SNARKフレンドリーであるままです。

Part2: ネイティブロールアップ

ネーミング

ネイティブロールアップの命名について、いくつかの混乱の原因を解消するために議論します：

  • 代替のネーミング: ネイティブロールアップは以前、enshrined rollupsと呼ばれていました。例えば、この文書やこの文書を参照してください。（「canonical rollup」という言葉もPolynyaによって短期間使用されました。）「enshrined」という用語は後で「native」に変更され、これは既存のEVM-equivalentのロールアップがネイティブになるためのアップグレードオプションがあることを示すために。「native」という名前は、2022年11月にDan Robinsonと匿名を希望するLidoの貢献者によって独立して提案されました。
  • based rollups (ベースロールアップ): ベースロールアップとネイティブロールアップは直交する概念です：「based」はL1のシーケンスに関連し、「native」はL1の実行に関連します。ベースであり同時にネイティブであるロールアップは冗談半分に「ultra sound rollup」と呼ばれます。
  • execution shards (実行シャード): 実行シャード（つまり、L1 EVMチェーンのコピーを組み込む）は、ネイティブロールアップと関連するが異なる概念で、ネイティブロールアップより数年前から存在します。（実行シャーディングは以前、Ethereum 2.0のロードマップの「フェーズ2」でした。）ネイティブロールアップと異なり、実行シャードはプログラム可能でなく、カスタムガバナンス、カスタムシーケンス、カスタムガストークンなどがありません。実行シャードはまた、通常固定量でインスタンス化されます（例えば、64または1,024シャード）。残念ながらMartin Köppelmannは、2024年のDevconでの実行シャードに関する講演で「native L2」という用語を使用しました。

利点

ネイティブロールアップには以下のような利点があります：

  • シンプルさ: ネイティブロールアップVMの大部分の複雑さはプリコンパイルによってカプセル化できます。今日のEVM-equivalentのOptimistic RollupやzkRollupは、fraud proofゲームやSNARK検証のために数千行のコードを持っていますが、これが一行のコードに集約される可能性があります。ネイティブロールアップはまた、証明ネットワーク、監視塔、セキュリティカウンシルなどの補助的なインフラを必要としません。
  • セキュリティ: バグのないEVM fraud proofゲームやSNARK検証を構築することは、深い形式検証を必要とする非常に困難なエンジニアリングタスクです。現在のほとんどのoptimisticおよびzk EVMロールアップはおそらく、EVMのステート遷移関数に重大な脆弱性を抱えています。これらの脆弱性から防御するために、中央集権的なシーケンスがしばしば悪意あるブロックの生成を制限する手段として用いられます。ネイティブの実行プリコンパイルは、permissonlessのシーケンスの安全なデプロイを可能にします。L1のセキュリティを完全に継承するpermissionlessのロールアップは、さらにL1のアセットの互換性も完全に継承します。
  • EVM equivalence: ロールアップがL1 EVMルールと同期する唯一の方法は、ガバナンス（通常はセキュリティカウンシルやガバナンストークン）を通じてL1 EVMのアップグレードを反映することです。（EVMのアップデートは毎年ほぼ一度のハードフォークで定期的に発生しています。）ガバナンスは攻撃ベクトルであり、厳密にはL1 EVMからの逸脱であり、どのロールアップも真の長期的なEVM equvalenceを達成することを防ぎます。一方、ネイティブロールアップはガバナンスなしでL1と一緒にアップグレードできます。
  • SNARKのガスコスト: SNARKをオンラインで検証することは高価です。その結果、多くのzkロールアップはコストを最小化するために頻繁にsettleしません。SNARKがオンラインで検証されないため、EXECUTEプリコンパイルは検証のコストを下げる方法として使用できます。ブロック内の複数の呼び出しにわたるEXECUTE証明をSNARK再帰を使用してバッチ処理することで、EXECUTE_GAS_COSTを比較的低く設定できます。
  • 同期的なコンポーザビリティ: 今日、L1との同期的なコンポーザビリティには、同一スロットでのリアルタイム証明が必要です。zkロールアップが例えば100msの超低遅延証明を達成することは特に挑戦的なエンジニアリングタスクです。1スロット遅延ステートルートを持つネイティブ実行プリコンパイルでは、証明の遅延を一つの完全なスロットに緩和できます。
← Go home