Ethereum Forum JP

トピックで絞り込む

すべてのタグ (157) →

ネイティブzkEVMは実行だけでなく帯域幅もスケールする

29 min read

原文

A native zkEVM scales bandwidth, not just execution — mikeneuder (2026-06-21)

ネイティブzkEVMは実行だけでなく帯域幅もスケールする

zkEVMが実行だけでなく帯域幅もスケールすることを示す図

by mike neuder – sunday, june 21, 2026.
\cdot
実りある議論とコメントをくれたIgnacioとLadislausに感謝します。
\cdot

tl;dr; ネイティブなzkEVM (ゼロ知識イーサリアム仮想マシン)をプロトコルに組み込むことは、イーサリアムのスケーリングロードマップの一部です。このアップグレードは主に実行のスケーリングという観点から語られます。つまり、イーサリアムバリデータはブロック内のトランザクションを完全に実行する代わりに、ブロック全体の正しさを示す暗号学的証明をダウンロードして検証するだけになります。理論的には、これによりイーサリアムのガスリミットが大幅に増加する可能性があります。しかし、これを素朴に行うと、ブロックサイズが線形に増加してしまいます。巨大なブロックをダウンロードする際に発生するレイテンシ (latency) は、ZK証明の検証による計算スケーリングの恩恵を打ち消してしまうでしょう。幸いなことに、ブロックの内容はブロブ内に配置できます。ブロブは、イーサリアムバリデータの全セットが内容全体をダウンロードすることなく、大量のデータに対するコンセンサスを可能にします。このようにして、ネイティブzkEVMは実行のスケーリングと連携して、チェーンの帯域幅 (bandwidth) をスケールさせます。Toniの最近の記事「Blocks Are Dead. Long Live Blobs」はまさにこの点を指摘しており、EIP（Ethereum 改善提案）-8142はこの機能を可能にするための明示的な提案です。この記事では、ネイティブzkEVMのこの重要な利点を強調するために、実装の詳細を避けながらこの点を力説します。

0. 背景

プロトコルがイーサリアムバリデータにブロックの再実行ではなくZK証明の検証を義務付ける「ネイティブ」zkEVMは、イーサリアムレイヤー1のスケーリングロードマップの一部です。通常、zkEVMは主にネットワーク内のイーサリアムバリデータに必要な実行時間 (execution time) を削減するものとして提示されます。ブロック内のすべてのトランザクションを再実行する代わりに、イーサリアムバリデータは単に正しさの暗号学的証明（以下、「証明」）を検証できます。証明の検証時間はブロック内のガス量に対して準線形（O(\log^2 n)）であるため、実行時間がそれに比例して長くなることなく、ガスリミットの大幅な増加が可能になります。PandaOpsチームが収集した実行タイミングデータを見ると、平均してブロックの実行には100ms未満（全12秒スロットの1%未満）しかかからないことがわかります。ブロック自体を構成するトランザクションのリストである実行ペイロード（以下、「ブロック」）のダウンロードも、考慮すべきクリティカルパスの一部です。現在のイーサリアムのブロックは約150〜200KBで、ノード要件に記載されている最低10Mbits/sの接続ではダウンロードに約100msかかります。では、10倍大きいブロックを想像してみてください。現状では、実行とブロックダウンロードのレイテンシ (latency) の両方が線形にスケールし、それぞれ約1秒かかります。ネイティブzkEVMを使用すると、証明検証によるブロック検証ははるかに高速になります（現在の証明検証は50〜200msの範囲で実行され、ポリログスケールにより、大きなガスリミット下でも非常にゆっくりと増加します）。しかし、完全なブロックのダウンロードは依然としてガスリミットに対して線形に増加します。 これにより、次の結論が導き出されます。ガスリミットの増加を分析する際には、ブロック検証とダウンロードのレイテンシ (latency) を一緒に考慮する必要があります。

これは根本的な疑問を提起します。zkEVMをプロトコルに組み込むことの意義は何でしょうか？もし実行のスケーリングの恩恵が、より大きなブロックをダウンロードする際のレイテンシ (latency) の増加によって打ち消されてしまうのであれば？ この記事は、ネイティブzkEVMの2番目の重要な利点は、ブロックダウンロードのレイテンシ (latency) を増加させることなくガスリミットをスケールできることであると主張します。つまり、zkEVM後の世界では、イーサリアムバリデータはブロックデータのごく一部をサンプリングするだけで、トランザクションの内容全体をダウンロードする必要がなくなります。したがって、zkEVMは2つのスケーリングの利点を提供します。(1) トランザクションを実行する代わりに証明を検証することによるレイテンシ (latency) の削減、および (2) ブロック全体をダウンロードする代わりにブロックをサンプリングすることによる帯域幅 (bandwidth) の削減です。(1) は多くの注目を集めますが、ネイティブzkEVMの真のスケーリングの恩恵を実現するためには (2) も不可欠です。[1] [2]

Toniの最近の記事「Blocks Are Dead. Long Live Blobs」はまさにこの点を指摘し、ブロブ内にブロックを含めるための技術的要件を詳しく掘り下げています。さらに、EIP（Ethereum 改善提案）-8142はこの機能を可能にするための明示的な提案です。

この記事は、zkEVMのプロトコル組み込みを正当化し、イーサリアムのスケーリングロードマップの一般的な理解を深める上で不可欠であるため、実装の細部に意図的に触れずにこの点を力説します。セクション1では、現在のブロック検証フローについて説明します。セクション2では、完全なブロックのダウンロードを依然として必要とする素朴なzkEVM実装でそのプロセスがどのように変化するかを示します。セクション3では、イーサリアムバリデータにブロック内容のサンプリングのみを要求する「よりスマートな」zkEVM実装（つまり、EIP-8142を通じて）でのタイムラインを示します。セクション4では、ネイティブzkEVMが他のスケーリング提案とどのように相互作用するかを議論して締めくくります。

1. 現在のブロック検証

今日のイーサリアムでは、ブロック検証フローはシンプルです。単一スロットのプロポーザー、アテステーション（証明）を行うアテスター[3]、およびアグリゲーター[4]のみを考慮します。以下の図は、これをシンプルなタイムラインとして示しています。

現在のブロック検証フローのタイムライン

  1. プロポーザーがブロックを公開します。
  2. アテステーション（証明）を行うアテスターがブロックをダウンロードします。[5]
  3. アテステーション（証明）を行うアテスターがブロックを実行します。
  4. アテステーション（証明）を行うアテスターが現在のカノニカルヘッドに投票します。
  5. アグリゲーターがアテステーション（証明）をアグリゲートにマージします。

このタイムラインからいくつかの重要な点を強調します。

このプロセスは、ビーコンチェーンのローンチ以来、ブロックが検証されてきた方法です（データアベイラビリティをブロックの有効性の前提条件として無視した場合）。イーサリアムのスケーリングロードマップの重要な部分であるzkEVMをプロトコルに組み込むことは、このフローに大きな変化をもたらします。

2. 基本的なzkEVMブロック検証

ネイティブzkEVMでは、各ブロックには、トランザクションが有効であることを示す対応するZK証明が必要です。これにより、特定のコンセンサス層スロットの証明を生成するプルーフ生成者 (prover) と呼ばれる新しいコンセンサス層参加者が導入されます。[7] 以下の図は、この新しいブロック検証フローをシンプルなタイムラインとして示しています。赤い丸は元のものから変更された部分、黄色い丸は全く同じ部分です（ただし番号は振り直されています）。

基本的なzkEVMブロック検証フローのタイムライン

  1. プロポーザーがブロックを公開します。これは現在のブロック検証の(1)と同じです。
  2. プルーフ生成者 (prover) がブロックの証明を生成します。
  3. アテステーション（証明）を行うアテスターがブロックをダウンロードします。これは現在のブロック検証の(2)と同じです。
  4. アテステーション（証明）を行うアテスターがブロックの証明をダウンロードします。
  5. アテステーション（証明）を行うアテスターがブロックの証明を検証します。
  6. アテステーション（証明）を行うアテスターが現在のカノニカルヘッドに投票します。これは現在のブロック検証の(4)と同じです。
  7. アグリゲーターがアテステーション（証明）をアグリゲートにマージします。これは現在のブロック検証の(5)と同じです。

このタイムラインからいくつかの重要な点を強調します。

  • プルーフ生成者 (prover) は、アテステーション（証明）を行うアテスターが検証できるようになる前に証明を生成する必要があります。実際には、ZKバグが無効な状態遷移につながるのを防ぐために、複数の証明が冗長に検証されることが期待されます。したがって、実際には複数のプルーフ生成者 (prover) が行動し、複数の証明がダウンロードされ、検証される必要があります。[8]
  • この素朴なバージョンでは、アテステーション（証明）を行うアテスターは完全なブロック (3) と証明 (4) をダウンロードするため、zkEVMなしの検証フローと比較して帯域幅 (bandwidth) 消費が増加します。証明は300 KiBを目標としているため、そのような証明を3つダウンロードすると、各スロットで約1メガバイトの追加データがダウンロードされます（10Mbit/s接続で0.8秒）。
  • アテステーション（証明）を行うアテスターは、ブロックを直接実行する代わりに、投票 (6) を行う前にzkEVM証明 (5) を検証します。

一見すると、この設定はスケーラビリティにとって悪いです。なぜなら、複数の証明をダウンロードして実行するために必要な追加のレイテンシ (latency) は、ブロックを直接実行するよりも遅くなるからです！さらに、セクション1で議論したように、証明検証がブロック実行よりも大幅な高速化を提供したとしても、ガスリミットの増加に伴いブロック自体のダウンロードも大幅にスケールすることを考慮する必要があります。ガスリミットの高いブロックの帯域幅 (bandwidth) オーバーヘッドを削減しなければ、ネイティブzkEVMは意味のあるスケーリング改善を提供しません。 幸いなことに、この問題にはイーサリアムが完全に活用できるシンプルな解決策があります。簡単に言えば、イーサリアムバリデータは証明を完全にダウンロードできますが、検証を実行するためにブロックの内容をサンプリングするだけで済みます。次のセクションでこれを説明します。

3. よりスマートなzkEVMブロック検証

ブロブにより、イーサリアムにはすでに、個々のノードが内容全体をダウンロードすることなく、大量のデータをチェーンに投稿するためのインフラストラクチャが構築されています。EIP-8142はこの機能を活用し、ブロック全体をブロブに入れ、サンプリングされたブロックの正しさの証明を検証することと組み合わせて、イーサリアムバリデータがサンプリングできるようにします。以下の図は、このブロック検証フローを示しています。前のタイムラインと異なるのは青い丸だけです。

スマートなzkEVMブロック検証フローのタイムライン

  1. プロポーザーがブロックを公開します。これは基本的なzkEVMブロック検証の(1)と同じです。
  2. プルーフ生成者 (prover) がブロックの証明を生成します。これは基本的なzkEVMブロック検証の(2)と同じです。
  3. アテステーション（証明）を行うアテスターは、内容がブロブに含まれているブロックをサンプリングします。
  4. アテステーション（証明）を行うアテスターがブロックの証明をダウンロードします。これは基本的なzkEVMブロック検証の(4)と同じです。
  5. アテステーション（証明）を行うアテスターがブロックの証明を検証します。これは基本的なzkEVMブロック検証の(5)と同じです。
  6. アテステーション（証明）を行うアテスターが現在のカノニカルヘッドに投票します。これは基本的なzkEVMブロック検証の(6)と同じです。
  7. アグリゲーターがアテステーション（証明）をアグリゲートにマージします。これは基本的なzkEVMブロック検証の(7)と同じです。

zkEVMにより、アテステーション（証明）を行うアテスターは、ブロック全体をダウンロードする代わりにブロックをサンプリング (3) できます。 私の意見では、これはブロックの実行時間を短縮することと同じくらい重要です。アテステーション（証明）を行うアテスターは依然としてブロックの証明全体（または複数の証明）をダウンロードする必要がありますが、完全なブロック内容の一部をサンプリングするだけで済むという恩恵を受けます。

これは大きなパラダイムシフトです。ブロックの最大サイズはブロック内のガス量に線形に増加するため、zkEVMなしでガスリミットを増やせば、ダウンロードのレイテンシ (latency) が増加します。逆に、証明サイズはブロック内のガス量に対して準線形（再びO(\log^2 n)）にスケールするため、zkEVM後の世界では、ガス量の増加が証明のダウンロードレイテンシ (latency) に与える影響は準線形になります。これが、ネイティブzkEVMを私にとって非常に魅力的にする根本的な要因です。

4. zkEVMと他のスケーリング技術の比較

zkEVMはイーサリアムのスケーリング計画の重要な部分です。上記で議論したように、zkEVM世界の主な利点は、ブロック検証とダウンロードのレイテンシ (latency) を大幅に増加させることなく、ガスリミットを大幅に増加させることができる点です。これは素晴らしいことですが、チェーン全体のスループット (throughput)だけがスケーリングにとって重要な指標ではありません。

  • zkEVM vs. 短いスロット: 短いスロット（および「クイック」スロット）は、スロットのエンドツーエンドのレイテンシ (latency) を削減することを目的としています。（特に、アテステーション（証明）の伝播と集約が行われるスロット時間の後半8秒をターゲットにしています。上記の図を参照してください。）ある意味では、zkEVMのスケーリングロードマップは、短いスロットの目標と相反します。これは、ブロック生成にプルーフ生成ステップ（基本的なzkEVMブロック検証の2）を導入すると、ブロック生成フローに別の参加者が加わり、証明をネットワークの残りの部分と共有するための別の通信ラウンドが追加されるという単純な現実から来ています。さらに、zkEVMチェーンは、最速のプルーフ生成者 (prover) が証明を完了できる速度でしか進行できません。[9] 12秒スロットの場合、「リアルタイム証明」は手の届く範囲にありますが、スロット時間を短縮するには、プルーフ生成者 (prover) のレイテンシ (latency) をそれに応じて短縮する必要があります。最後に、短いスロットの現在のビジョンでは、ブロックごとのガスリミットを低く設定し、チェーンの1秒あたりのガスリミットを効果的に維持することが含まれています。しかし、zkEVMの世界では、ガスリミットとは無関係に固定の証明コストがあるため、短いスロットはその作業の償却に不利に働きます。全体として、短いスロットとzkEVMの間はそれほどゼロサムではありません。zkEVMは根本的に帯域幅 (bandwidth) スケーリング技術であり、短いスロットはレイテンシ (latency) の削減に焦点を当てています。プルーフ生成者 (prover) のレイテンシ (latency) を十分に削減でき、証明サイズが十分に小さく迅速にダウンロードできる限り、これらのスケーリング技術は実際には互いにうまく補完し合います。
  • zkEVM vs. ePBS (enshrined Proposer-Builder Separation): ePBS (enshrined Proposer-Builder Separation)はブロック生成パイプラインを変更します。プロポーザーは、ブロックの内容を見ることなくブロックヘッダーにコミットできるようになります。さらに、主要なアテステーション（証明）を行うアテスターセットは、ブロックの内容と有効性にも盲目的に、そのコミットメントのデータアベイラビリティに投票します（t=3で）。ペイロード適時性委員会（ランダムにサンプリングされた512のバリデータのサブセット）のメンバーのみが、ブロック自体のタイミングと有効性に投票し、t=9で行います。この6秒の遅延は、プロトコルをフリーオプション問題にさらしますが（これは重大な脆弱性ですIMO）、ブロックがダウンロードされ実行されるための追加時間を提供します。zkEVMの未来では、この時間は証明が生成され検証されるためにも役立ちます。ePBS (enshrined Proposer-Builder Separation)がグラムステルダムハードフォークの主要なEIP（Ethereum 改善提案）であることを考えると、コミュニティはフリーオプション問題によって露呈する経済的リスクよりもこれらのスケーリングの恩恵[10]を重視しているようです。
  • zkEVM vs. 高速ファイナリティ: 高速ファイナリティ（および高速確認ルール）は、ネイティブzkEVMとは完全に直交しています。イーサリアムのファイナリティは現在エポック（32スロット）のスケールで動作しており、高速ファイナリティの目標はこれをより少ないスロット数に削減することです。zkEVMはこの目標を助けも妨げもしません。

イーサリアムのスケーリングパズルには多くのピースがあります。この記事は、特にzkEVMのスケーリングの恩恵を考慮する際、ブロック実行を証明検証に置き換えることによって生じる計算スケーリング (compute scaling) と同等に、ブロブ内のブロックによって可能になる帯域幅 (bandwidth) スケーリングを考慮すべきであると主張します。

読んでくれてありがとう！

  1. zkEVMを持つことによる潜在的なステートレス性の恩恵は無視していることに注意してください。この記事の目的は、長期的なメモリとディスク消費ではなく、リアルタイムの帯域幅 (bandwidth) とレイテンシ (latency) リソースに焦点を当てることです。それらも重要ですが、短期的にはスロットのタイミングとリソースがスケーリングのボトルネックです。 ↩︎

  2. 帯域幅 (bandwidth) が十分に速くスケールすれば、より大きなブロックを完全にダウンロードすることが可能になり、より帯域幅 (bandwidth) 効率的なブロック検証フローの必要性がなくなる可能性も注目に値します。この世界では、チェーンは計算量に制約され、ネイティブzkEVMの計算スケーリングの恩恵が支配的な要因となるでしょう。直感的には、計算量はグローバルな帯域幅 (bandwidth) よりも速くスケールしているように見えますが、これを検証することは行うべき重要な経験的健全性チェックです。 ↩︎

  3. 完全なバリデータセットは32のグループに分割され、各グループはエポック内で単一のスロットに投票し、各バリデータはエポックごとに正確に1回投票します。 ↩︎

  4. アグリゲーターはアテステーション（証明）を単一のより大きなアテステーション（証明）にマージしますが、これに対して報酬を受け取ることも、行わないことに対して罰せられることもありません。 ↩︎

  5. このタイムラインは、ブロブトランザクションのサンプリングがブロック検証フローの一部であるという事実を無視していますが、これはこの議論には関係ありません。 ↩︎

  6. これは、ブロックがアテステーション（証明）期限前にダウンロードされるが、検証と投票が後に行われるというエッジケースを無視しています。正直な仕様によれば、有効なブロックが期限までにダウンロードされる限り、アテステーション（証明）を行うアテスターはそれをフォーク選択ビューで考慮すべきです。「バリデータは、(a) 割り当てられたスロットの期待されるブロックプロポーザーから有効なブロックを受信した場合、または (b) スロット開始からget_attestation_due_ms()ミリ秒が経過した場合のいずれか早い方に、関連するアテステーション（証明）サブネットにアテステーション（証明）を作成しブロードキャストすべきです。」もちろん、ブロックが有効であることは実行するまでわかりませんが、仕様は期限後に実行が行われることを許容しているように見え、クライアントがこれをどのように実装するかはこの記事にとって重要ではありません。 ↩︎

  7. プルーフ生成者 (prover) が実際にプロトコルに組み込まれた役割にならず、ビルダーが構築するブロックの証明を提供することが期待される可能性もあります。これは、ソロステーカーが（ZK証明を提供できないため）自分でブロックを構築する能力を完全に排除しますが、FOCIL (強制オンチェーンインクルージョンリスト)を通じて「インクルーダー」としてブロックの内容に貢献する可能性があります。このアンバンドリングがどのようなものになるかについては、こちらを参照してください。 ↩︎

  8. 複数の証明を検証することは、今日のイーサリアムバリデータが行っている単一の実行層クライアントでブロックを実行するよりも、実際にはより堅牢なブロック検証フローであることに注意してください。事実上、複数の証明を検証することは、ノードに複数の実行層バイナリを実行するように要求することなく、より広範なクライアント多様性を得るための非常に安価な方法として機能します。 ↩︎

  9. プルーフ取得に関する最近の論文の宣伝ですが、脚注5がこれをうまく捉えています。「このパラダイムの下では、zkEVMはより速いペースで動作できます。ネットワーク内の誰かがトランザクションを実行し、正しい証明を生成できる限り（トランザクションデータをサンプリングし、生成された証明を検証することが十分に軽量であるため、バリデータネットワーク全体がそれを行うことができます）。証明システムのプルーフ生成者 (prover) 効率によっては、これは改善になる場合もならない場合もあります。一方では、最も遅い参加者ではなく、最も速い参加者のペースで動作しますが、他方では、その参加者はトランザクションを実行し、正しさのZK証明を作成する必要があります。」 ↩︎

  10. EIP-7886は、ブロックの遅延実行を可能にし、フリーオプション問題なしに同様のパイプライニング (pipelining) の恩恵を提供したでしょうが、もはやアクティブな提案ではありません。 ↩︎

2 posts - 2 participants

Read full topic

グラフビュー