16秒は簡単な部分だった：イーサリアムのzkEVM

はじめに

Ethereum Foundationが2025年12月18日に公開したzkEVMのセキュリティ基盤に関する記事は、同一の文書の中で2つのことを述べている。1つは、リアルタイムプルービングの目標が達成されたという宣言だ。証明のレイテンシは16分から16秒に短縮され、コストは約45分の1になり、zkVMはメインネットブロックの99%について、10万ドル未満のハードウェア上で10秒未満の証明を生成できるようになった。もう1つは、STARKベースの証明システムを支えてきた数学的予想のいくつかが、実は反証されていたという認識だ。つまり、「100ビットのセキュリティ」を謳うzkEVMが、実際には80ビット程度しか達成していない可能性があるということである。

この2つの主張は、別のカテゴリーに属する。前者はエンジニアリング上の成果であり、自己申告かつ公開ダッシュボードで確認できるものだ。後者は、業界がすでにマーケティング資料や監査サマリーで主張してきた内容の撤回である。パフォーマンスの数字は改善した。セキュリティの数字は間違っていた。

この順序こそが興味深い点だ。L1に組み込まれたzkEVMにとって、制約となっていたのは決してスループットではなかった。12秒のブロックを証明するのに16分かかる証明システムはコンセンサスにとって使い物にならないため、まずレイテンシを下げる必要があり、zkVMチームはそれを急速に実現した。しかし、Ethereumのバリデータがトランザクションの再実行をやめて証明の受理に移行すれば、証明システムこそが「何が真実か」を決定するものになる。その世界におけるライブネス障害は、スロットの取りこぼしを意味する。一方、ソウンドネス障害は、コンセンサスが実際には起こらなかった状態遷移を受理してしまうことを意味する。何もないところからトークンが発行され、残高が書き換えられ、ブリッジが抜き取られる。それを捕捉する再実行レイヤーは、もはや下に存在しない。

したがってFoundationの2026年ロードマップは、パフォーマンスのスプリントではなくセキュリティのスプリントである。成果物として掲げられているのは、soundcalcと呼ばれるスコアリングツール、Glamsterdamフォークまでに達成する「600 KiB未満の証明で100ビットの証明可能なセキュリティ」、そして2026年末までに達成する「300 KiB未満の証明と形式的なソウンドネス論証を伴う128ビット」である。ここで重みを持つのは「証明可能」(provable)という語であり、「予想された」(conjectured)との対比である。この区別が重要な意味を持つのは、まさにその予想がすでに一度破綻しているからだ。

リアルタイムプルービングが超えるべきだったもの

このプログラムの起点となった2025年7月10日のFoundationの記事は、リアルタイムプルービングを「進むべき方向」ではなく「達成すべき具体的な数値」のリストとして定義した。メインネットブロックの99%について10秒以内に証明を生成すること。オンプレミスの設備投資を10万ドル未満に抑えること。消費電力を10kW未満に抑えること。証明サイズを300 KiB未満にすること。少なくとも128ビットのセキュリティを確保し、短期的な下限として100ビットを許容すること。トラステッドセットアップを用いないこと。そして完全にオープンソースのコードであること。

それぞれの制約は、最終的な状態が持つべき性質に対応している。10秒というレイテンシの予算は、Ethereumのスロット時間が、次のブロックが生成された後に届く証明のための余地をまったく残さないことに由来する。10万ドルと10kWという上限は、Foundationがプルービングをハイパースケーラーでない運営者にも手が届くものに保ちたいという意図から来ており、これは検閲耐性のための安全策だと位置づけられている。もし一握りの産業施設だけが時間内に証明を生成できるなら、その施設がブロックの証明を拒否することもできてしまう。証明サイズの上限が重要なのは、ネットワーク上のすべてのバリデータがその証明をダウンロードするからであり、600 KiBのオブジェクトがスロット内で全ノードに伝播するのと、50 KiBのそれとでは、帯域幅の問題としてまったく性質が異なる。トラステッドセットアップを排除することで、後からどれだけ監査を重ねても解消できない種類のセレモニーリスクを取り除いている。

これらすべてが仕えている仕組みがステートレスバリデーションである。現在のEthereumバリデータは、フルステートを保持し、ブロック内のすべてのトランザクションを再実行して、提案者が主張するポストステートルートを検証している。この再実行があるために、ノードのハードウェア要件はガスリミットに連動し、ガスリミットを引き上げることが困難な戦いになる。ステートレスバリデーションのもとでは、バリデータはステートを一切保持しない。ブロックと、そのブロックのトランザクションをプレステートルートに対して実行するとクレームされたポストステートルートが得られることを示す簡潔な証明を受け取り、その証明を検証するだけである。検証は安価で、証明対象の計算量にほぼ比例しない。証明の生成は高コストで、計算量に応じてスケールする。

この非対称性こそが、ガスリミットの余地に関する議論の源である。バリデータが再実行ではなく検証を行うなら、10倍大きなブロックを検証するコストはバリデータにとって10倍にはならない。コストが上がるのは証明を生成する側である。Foundationの段階的な計画はこの論理に直接従う。まずバリデータは通常の再実行と並行して、任意でステートレスZKクライアントを動かす。ステーク量の過半数がそれに安心感を持った段階で、証明の検証だけが現実的な対応手段となるレベルまでガスリミットを引き上げる。すべてのバリデータが証明を検証するようになれば、その証明はEXECUTEプリコンパイルに取り込まれ、同じ仕組みがロールアップにも拡張される。

このロードマップを計測するためにエコシステムが使っている公開トラッカー、Ethproofsは、この道のりを5つのフェーズに分けている。パフォーマンススプリント、セキュリティスプリント、遅延プルービング、強制プルービング、組み込み証明である。本分析の基盤となったスナップショットの時点では、パフォーマンススプリントは完了とマークされており、セキュリティスプリントが現在進行中のフェーズとして、100ビットかつ600 KiBというマイルストーンに向けて取り組まれている。残り3つのフェーズはまだ始まっていない。

「ブロックの99%」とトラッカーの数字との距離

Foundationが掲げる「ブロックの99%を10秒未満で」という主張と、Ethproofsのコホートデータは、同じシステムを異なる角度から描写しており、その両者の間のギャップにこそ、残されたエンジニアリング課題が存在する。

Ethproofsの集計データでは、追跡対象となった502,520のブロックスロットのうち、10秒以内に証明が生成されたのは70.2%だった。これは定められた70%という中間しきい値をかろうじてクリアしている。残りの大部分は、遅い証明というより「不在」である。26.2%のスロットでプルーバーがオフラインとして記録され、3.36%が「スタン状態」、0.22%が「麻痺状態」とされた。証明が完了した場合に限定すると、そのうち95.4%は適格ウィンドウ内に収まっていた。

70.2%(無条件)と95.4%(条件付き)というこの2つの数字は、具体的なことを物語っている。証明システム自体は速い。一方、それを取り巻く運用はまだ信頼できる水準に達していない。GPUクラスタで実験的なzkVMを動かしている研究コホートであれば、ダウンタイムが発生するのは当然であり、スロットの4分の1がオフラインだったという事実を基盤となる暗号技術そのものへの評価として読むべきではない。しかし、Foundationのロードマップは最終的に強制プルービングのフェーズに至り、そこでは証明の欠落はダッシュボード上の空白ではなく、コンセンサスに関わる事象になる。そのフェーズに信頼性を持たせるために限りなくゼロに近づける必要がある変数こそがオフライン率であり、パフォーマンススプリントの見出しが触れていない変数でもある。

プルーバーの多様性についても同じ構図が見える。リアルタイムプルービングのコホートで評価された10のプルーバーのうち、週次適格基準を満たしているのは3つだけだ。Zisk(69%)、Axiom(58%)、zkDTVM(8%)である。残りの、Pico、各種Airbenderバリアント、Succinct、Ziren は0%にとどまっている。これは移り変わる状況のスナップショットに過ぎず、これらのチームの何社かはおそらく数週間でこの基準を超えてくるだろう。それでも、これが現時点でネットワークが置かれている構成であり、次節にとって重要な意味を持つ。というのも、Foundationがソウンドネス障害に対する防御策として提案しているのは、まさに多様性だからである。

一方、コストは2年前にはほとんど誰も予想しなかった水準まで下がってきている。主要なプルーバーが報告する1証明あたりのコストは0.0031ドルから0.0063ドルの範囲で、NVIDIA 5090 GPUを4基から16基用いたクラスタで達成されている。1ブロックを証明するのに1セントの3分の1というのは、ブロック報酬に対する丸め誤差ではなく、考慮に値しないほど小さい額である。ただし、この価格が、フル負荷の電気代、減価償却、冗長性、運営者のマージンを織り込んだ競争市場に晒された後も維持されるかどうかは別の問題であり、研究コホートの経済性は市場の経済性とは異なる。

ソウンドネス障害がなぜ別種の問題なのか

分散システムは常にライブネスとセーフティを区別し、その区別は通常、一方を得るために他方をどれだけ犠牲にするかというトレードオフに帰着する。組み込み型のL1 zkEVMは、このトレードオフを極端に非対称なものにする。

プルービングレイヤーにおけるライブネス障害とは、あるブロックに対してスロット内に有効な証明が届かないことを指す。提案されている設計のもとでは、これは乗り切れる事態である。オプショナルフェーズや遅延フェーズの間はネットワークは再実行にフォールバックできるし、アテスターは未証明のブロックの上に構築することを拒否できるし、本来証明を生成すべきだった者にとって、障害の繰り返しが高くつくようペナルティを設定することもできる。ダメージはスロットの取りこぼしとファイナリティの遅延として計測される。

ソウンドネス障害とは、証明システムが偽の状態遷移に対する証明を受理してしまうことを指す。バリデータがすでに再実行をやめているなら、スタックの他のどこも検証を行っていない。Foundation自身の説明は、これが何を許してしまうかについて率直だ。トークンの発行、ステートの書き換え、資金の窃取である。これを進行中に捕捉できるチェーン停止のような仕組みは存在しない。なぜなら、コンセンサスの観点からは何も異常は起きていないからだ。偽造された状態がそのまま正統なものとして扱われる。

これが、提案されているロールアウトが単一のzkVMを信頼の要とすることを決してしない理由である。Foundationの設計におけるステートレスZKクライアントは、複数の独立して実装されたzkVM(それぞれ異なるEVM実装に対して証明を行う。例示されている数は3つ)からの証明を検証する。バリデータは、そのすべてが検証に通った場合にのみブロックを受理する。類推は明示的だ。これは、クライアント多様性を一層下に適用したものである。単一のzkVMにおけるソウンドネスのバグは、窃盗ではなくライブネス問題になる。なぜなら、他の検証者が偽造された証明を拒否し、そのブロックはアテステーションを得られないからだ。

この議論の弱点は、クライアント多様性そのものがこれまで抱えてきた弱点と同じである。多層防御が機能するのは、各実装が独立して故障する場合に限られる。同じ多項式コミットメントスキームに基づき、同じソウンドネス予想に依存し、重複するツールチェーンを通じてコンパイルされ、同じEVM仕様を対象とする2つのzkVMは、エラーを捕捉する独立した3つの機会を与えているわけではない。それは実質1つの機会を、3つに見せかけているに過ぎない。コホートデータがこれを具体的に示している。ある時点で適格なのが3つの実装だけなのだとすれば、バリデータが利用できる実質的な多様性は、たまたまその時その3つが何であるかに左右され、それらの間にある相関構造はEthproofsのダッシュボードが測定しているものではない。

名目上の多様性が、実は別のラベルの下での集中を再現しているに過ぎない、という失敗モードこそ注視すべき点であり、これはトラッカーのエントリーを増やしただけでは解決しない。

証明可能なビット数と予想されたビット数

ソウンドネス問題に対するFoundationの答えは、自己申告のセキュリティレベルの受け入れをやめ、共通の基準でそれをスコアリングすることだ。その基準がsoundcalcであり、現行の暗号学的な境界値と証明システムのパラメータから、あるzkVMのセキュリティをビット数で推定するツールである。参加チーム全体への統合は2026年2月末までを目標とし、スコアはEthproofs上でパフォーマンス、ライブネス、コストと並べて公開される予定だ。

これがディスクロージャー要件ではなくツールを必要とした理由は、STARKのセキュリティに関する論証がしばしば予想を前提にパラメータ化されているからだ。証明システムの設計者は、基盤となるコードやコミットメントスキームの振る舞いについての特定の予想が成り立つ場合に目標とするセキュリティレベルを達成できるようなパラメータを選び、その目標値を公表する。すると、その数字が流通し始める。「予想Cのもとで安全」と「安全」との間にあるギャップは、「100ビット」という一行のクレームの中では見えなくなる。

12月の記事によれば、こうした基礎的な予想の少なくとも1つが数学的に反証されている。この帰結は学術的なものにとどまらない。反証された予想のもとで100ビットを謳うシステムが、実際に証明されている内容に照らしてスコアリングすると、80ビット程度に近い水準しか提供していない可能性がある。ソウンドネスが80ビットというのは、意欲あるGPU持ちの攻撃者によって即座に破られるものではないが、決済レイヤーを守るには不適切な数字であり、クレームがなされた後ではなく前に発見されているべき数字でもある。

これに続くロードマップは具体的だ。2026年5月末を目標とするGlamsterdamフォークまでに、参加するzkVMは600 KiB以下の証明で100ビットの証明可能なセキュリティを達成すべきとされている。2026年末までには、H-starというラベルのもと、300 KiB未満の証明と、それに伴う形式的なソウンドネス論証を備えた128ビットが目標とされる。

この2つの目標は互いに引っ張り合う関係にある。STARKにおけるセキュリティマージンは主に反復(repetition)から得られるが、反復は証明のサイズを膨張させる。600 KiBで100ビットから300 KiBで128ビットに進むには、構成そのものの「バイトあたりのセキュリティ」を改善する必要がある。この記事が新しい仕組みを指し示しているのはそのためだ。コミットメントスキームとしてのWHIR、JaggedPCS、そして実行トレースとバリデータがダウンロードする最終的なオブジェクトとの間に挟まる証明圧縮のレイヤー数を変える、再構成された再帰アーキテクチャなどである。これらは研究段階のリスクを伴う活発な研究方向であり、このスケジュールはそれらがうまくいくことを前提としている。

ビット数が網羅していないもの

soundcalcについて説明する情報源は、それが何を推定するかは明記しているが、何を除外しているかについては触れていない。そして、この分野でこれまで実際に被害をもたらしてきたのは、その除外リストの中身だ。

暗号学的な境界値と証明システムのパラメータから導かれるソウンドネススコアは、紙の上のプロトコルについての言明である。それは、基盤となる困難性の前提を破れない攻撃者が、ある閾値を超える確率で偽の主張に対する証明を偽造できないということを述べている。だが、入手できた情報源が支持する限りでは、そのスコアは、回路がEVMのセマンティクスを忠実にエンコードしているかどうか、制約システムが「制約不足」で無効なウィットネスでも条件を満たしてしまうかどうか、ウィットネス生成器が制約によって固定されない値を生成していないかどうか、あるいは高レベルの回路記述を制約に翻訳するコンパイラが乖離を生じさせていないかどうか、といったことには触れていない。

これらこそが、実際のzkEVMインシデントを引き起こしてきたバグのクラスである。数学的には非の打ちどころのない128ビットのソウンドネス論証を持つシステムであっても、単一のオペコードの制約セットが本来禁止すべき値を許してしまっているために、偽造された証明を受理してしまうことがあり得る。Foundationの7月の記事は、より広い要件の存在を認めており、形式検証、監査、バグバウンティを時間をかけて必要なものとして挙げている。これは、ビット数だけでは十分でないとFoundation自身が考えていることを示唆する。しかし、公開されるスコアボードに表示されるのはビット単位の数字であり、ダッシュボード上の数字は往々にして、人々が引用する「あの数字」になりがちだ。

soundcalcの対象範囲が実装レベルの正しさにまで及ぶことを意図しているのか、それとも別の検証トラックがそれをカバーするのかは、入手できた情報源からは判断できなかった。このギャップは、スコアがフェーズ移行の判定基準になる前に解消しておくべきものである。

EXECUTEとネイティブロールアップの道筋

このプログラムの3つ目の柱は、すでに出荷されたシステムではなく、設計上の提案である。Justin Drakeによるネイティブロールアップに関する記事は、2025年1月にethresear.chに公開され、L1の実行検証を任意のコントラクトから呼び出せるプリミティブとして公開するEXECUTEプリコンパイルを記述している。

このプリコンパイルは、プレステートルート、ポストステートルート、トランザクショントレース、ガス量を受け取り、そのトレースをプレステートに対して実行した結果がガス上限内でポストステートに一致するかどうかを返す。バリデータがその回答をどのように自ら確かめるかは、コンセンサスレイヤーにおいて意図的に未規定とされている。バリデータはトレースを直接再実行してもよいし、同じ主張を証明するSNARKを検証してもよい。特定の証明システムが組み込まれているわけではない。ステーキング事業者は、今日実行クライアントを選ぶのと同じように、自分自身のzkELベリファイアクライアントを、プロトコルの定数としてではなく主観的なローカルの判断として選ぶ。

ガス会計は、このプリミティブを計量可能にするよう設計されている。呼び出しごとに固定のEXECUTE_GAS_COSTがかかり、それに加えて、内部実行で消費されたガスにEXECUTE専用のEIP-1559型の計量価格を乗じたコストがかかる。これには、ブロック内のそうした呼び出し全体に対する別途の累積上限と目標値がある。ガスは、呼び出しがfalseを返した場合でも全額課金される。これにより、無効なトレースを安価に提出するという明白な嫌がらせベクターが取り除かれる。

ネイティブロールアップとは、シーケンシング、ブリッジ、強制インクルージョン、ガバナンスを扱うロジックである「derivation関数」の中でEXECUTEをラップするコントラクトのことである。ロールアップの状態遷移の正しさは、もはやロールアップが自分自身に対して証明するものではなくなる。それは、L1バリデータがL1ブロックの検証の一環としてチェックするものになる。これによってロールアップの攻撃対象領域から取り除かれるものは大きい。間違う余地のある独自のSNARK回路も不要になり、チャレンジウィンドウやボンディングの前提を伴うフラウドプルーフのゲームも不要になり、どちらのバグに対してもバックストップとなっていたアップグレードキーを保持するセキュリティカウンシルも不要になる。ロールアップは構造上EVM互換であり続け、EXECUTEが強制するセマンティクスがその時点でのL1実行の意味そのものであるため、L1のハードフォークを自動的に継承する。

タイミングの仕組みは繊細な部分だ。提案では1スロット分の遅延実行が描かれている。ブロックnの証明を生成するためにプルーバーには丸1スロットの猶予が与えられ、その間にブロックn+1が構築される。アテスターは、ブロックn+1へのアテステーションを、ブロックnの証明が利用可能であることを条件とする。取りこぼしたスロットへのペナルティは約1 ETHという例が示されている。ライトクライアントのライブネスは、利他的な少数派のプルーバーという前提に依拠している。つまり、この設計は、限界的な経済合理性が薄い状況でも、少なくとも一部のプルーバーが証明を生成し続けることを期待している。

Drakeの記事はさらに、オプティミスティックなネイティブロールアップがEXECUTE_CUMULATIVE_GAS_LIMITをはるかに上回るガスリミットで動作できる可能性にも触れている。なぜなら、オプティミスティックな場合、EXECUTEはすべてのブロックを検証するためではなく、小さな係争セグメントをめぐるチャレンジを解決するためにのみ呼び出されるからだ。これはスループットの観点で重要である。ZKパスのコストはL1が計量することを許容する範囲に制約されるのに対し、オプティミスティックパスはEXECUTEを決済オラクルとして用い、それに対する支払いは争いが生じた場合にのみ発生する。

これらはまだ何も出荷されていない。この記事は2025年1月の時点での設計スケッチであり、ペナルティの大きさ、遅延の構造、ガス定数はいずれも仮の値である。このロードマップに関する議論の中で、2026年3月にプルーフオブコンセプトのデモが実施されたとの言及があるが、ここで入手できた情報源はその範囲や結果を記録しておらず、未検証として扱う。プリコンパイルの動作デモから、コンセンサスへの統合、手数料市場のキャリブレーション、生成される証明をスロット内で検証できるクライアントエコシステムの確立までには、まだ相当な距離がある。

L2スタックに残るもの

ネイティブロールアップが実稼働に至った場合、陳腐化するのはロールアップというカテゴリー全体ではなく、ロールアップスタックの特定のレイヤーである。

なくなるのは、オーダーメイドのセキュリティ装置である。状態遷移をEXECUTE経由で処理するロールアップは、自前のプルーバー、自前の回路、自前のベリファイアコントラクト、そしてそれらが壊れたときにパッチを当てるために存在するガバナンス構造を維持する必要がなくなる。「証明システムにバグがあったときに実際には何が起きるのか」という問いへの実務上の答えであるセキュリティカウンシルは、キーを保持する理由を失う。EVM互換と手数料の低さを差別化要因としているチームにとって、これはエンジニアリング予算の大部分であり、現在ユーザーに受け入れてもらっている信頼の前提の大部分でもある。

なくならないのは、状態遷移関数より上のすべてである。誰かがトランザクションの順序を決める必要があり、シーケンシング権は現在も多くのロールアップにとって主要な収益源であり続ける。誰かがデータを公開する必要があり、ブロブ手数料という実コストはEXECUTEによって何も減らない。derivation関数は引き続き強制インクルージョンを正しく処理しなければならない。ロールアップの検閲耐性が実際に宿るのはそこであり、そこを間違えればユーザー資金を失う道になることに変わりはない。ブリッジのロジックも引き続き書かれる必要があり、引き続き正しくある必要がある。

そして、ネイティブロールアップは定義上EVM互換であり、それが対応できる対象を限定する。非EVM仮想マシン、改変されたガススケジュール、セマンティクスを変更したネイティブアカウントアブストラクション、その他L1の実行から逸脱するものを動かすロールアップは、L1の実行を強制するプリコンパイルを経由できない。そうしたシステムにとって、EXECUTEはアップグレード経路ではない。両者が重なる領域において、より優れたセキュリティの物語を持つ競合相手である。

L2のガバナンストークンについて正直に言えば、この分析を支える情報源には市場、ガバナンス、トークンエコノミクスに関するデータが一切含まれておらず、バリュエーションへの影響についての主張は何であれ創作になってしまう。構造的に言えることはもっと狭い。セキュリティカウンシルの任命と制約が主な役割であるガバナンストークンは、ある意思決定プロセスに対する請求権であり、ネイティブロールアップはまさにそのプロセスが存在する理由である意思決定を取り除くために設計されている。一方、シーケンシング権、手数料の獲得、エコシステムの調整が役割であるトークンは、EXECUTEが触れない機能に紐づいている。この2つのケースの区別こそ注視すべき点であり、それはカテゴリー一般にではなく、各スタックごとに固有の話である。

移行もただではない。数十億ドル規模のブリッジ資産を抱える稼働中のロールアップが、新しい状態遷移検証経路に移行するということは、ブリッジのアップグレードを実行するということであり、それはこの業界で最もリスクの高いオペレーションである。チームが動くのは、設計がエレガントだからではなく、現状維持が恥ずかしいものになったときだろう。

プルービングの集中とホームバリデータ

2025年7月の記事における検閲耐性の論拠は、ホームプルービングが引き続き実行可能であることに依存している。10万ドルと10kWという目標が存在する理由もそこにある。産業的な運営者しか参入できない証明市場は、少数の当事者がブロックの証明を拒否できてしまう市場であり、強制プルービングのもとではそれが拒否権になる。

ここで混同されがちな2つの役割を分けておく必要がある。検証は安価だ。ステートレスなバリデータが3つの証明をチェックするのにGPUクラスタは不要であり、ステートレスバリデーションのもとでのホームバリデータのハードウェア負担は、今日より低くなる可能性すらある。というのも、フルステートを保持して再実行することこそがコストの重い部分だからだ。集中リスクが存在するのはプルービングの側である。現在のコスト、1証明あたり0.3〜0.6セント程度は、高性能GPUを4基から16基用いたクラスタで達成されている。これは資金力のある個人なら手の届く範囲であり、企業にとっては容易に手が届く範囲だが、ノートパソコンで済む話ではなく、1証明あたり1セント未満という数字が印象的なのも、それを支える資本があってこそである。

コホートの構成もこの点を裏付けている。評価対象10社のうち適格なプルーバーが3社というのは、市場ではなく研究グループの規模である。この比率が、7つのチームが最適化の途上にあるという立ち上げ期の反映なのか、それともプルービングには規模の経済が働き小規模な運営者を締め出す構造的な帰結なのかは、ある一時点のスナップショットからは判断できない。どちらの解釈もデータと矛盾しない。適格基準を満たしているプルーバーのハードウェアのサプライチェーン、電気代へのエクスポージャー、地理的分布については、どこを探しても追跡されたデータを見つけることはできなかった。

同じ種類の不確実性は、現状で最も具体的なユーザー向けの利点であるガスリミットの議論にも当てはまる。この計画は、ステーク量の過半数がZKクライアントを問題なく運用できるようになった時点でL1のガスリミットを引き上げるというものだ。もしステートレスバリデーションがバリデータのコストをガスリミットから本当に切り離すのであれば、それは大きく持続的な恩恵になる。しかし、この提案はプルービングのキャパシティが許容可能なコストでガスリミットに応じてスケールすることを前提としており、プルービングのコストは証明対象の計算量に応じて実際にスケールする。ガスリミットを10倍にするということは、同じスロット内で証明すべきトレースが10倍大きくなるということだ。現在のコスト数値は、今日のガスリミットのもとでのブロックについてのものである。

観測可能になるべきもの

パフォーマンススプリントは、第三者が公開ダッシュボードで確認できる数字を生み出した。これは、たいていのインフラロードマップが提供するものよりも多くを与えてくれる。セキュリティスプリントは外部から検証するのが難しい。証明可能なセキュリティスコアは、多くの読者にはその正しさを評価できない証明についての言明であり、かつ最も危険なバグのクラスは、そのスコアがカバーしていないように見えるものだからだ。

このプログラムの信頼性を、さらなるレイテンシの改善以上に押し上げるのは、次のようなことだろう。

• Ethproofs上で、各プルーバーごとのsoundcalcスコアを、そのシステムが依拠している予想とそうでない予想を明示した形で公開すること。それによって、読者は3つの適格なプルーバーが3つの独立した故障モードを表しているのか、実質1つに過ぎないのかを判断できるようになる。
• 追跡対象スロット全体のオフライン率が、現在の~26%から、強制プルービング(そこでは証明の欠落はダッシュボード上の空白ではなくコンセンサスに関わる事象になる)を乗り切れる水準まで低下すること。
• 各フェーズ移行についての、公開された数値基準。遅延プルービングから強制プルービング、組み込み証明への移行は、現時点ではフェーズの名称によって説明されているだけで、ステークの比率や、独立に検証された実装の数、あるいは次の段階に進むために必要な継続的な信頼性の数値によっては説明されていない。
• 組み込み型システムでソウンドネス障害が起きた後に何が起こるのかへの答え。偽造された証明がトークンを発行し、コンセンサスがそれを受理してしまった場合、回復への道は社会レイヤーでのフォークしかなく、これはEthereumが常に持ってきたのと同じ答えだが、引き金が目に見えるエクスプロイトではなく暗号的なバグである場合は、はるかに居心地の悪いものになる。

2026年のマイルストーン、すなわち2月までのsoundcalc統合、5月のGlamsterdamまでの600 KiBで100ビット、年末までの300 KiBで128ビットかつ形式的なソウンドネス論証は、Foundationが自ら設定した目標であり、Ethproofsのフェーズ表示が今も現在進行形としてセキュリティスプリントを示していること自体が、ここで得られる唯一の独立したステータス信号である。これらの期日が守られたかどうかは、この分析の基盤となった情報源からは確認できない。

確立しているのは、難易度の順序だ。16分から16秒への短縮は、明確な指標と公開のリーダーボードを持つチームによる、18か月の集中したエンジニアリングによって達成された。予想された100ビットから証明された128ビットへ進むには、新しい暗号技術が実際に機能し、新しい制約システムが正しく、そして測定基準が、最も定量化しやすいバグではなく、歴史的に実際の障害を引き起こしてきたバグをカバーしなければならない。

参考文献

• Shipping an L1 zkEVM #1: Realtime Proving, Ethereum Foundation, July 2025
• Shipping an L1 zkEVM #2: The Security Foundations, Ethereum Foundation, December 2025
• Ethproofs, live prover tracker
• Native rollups: superpowers from L1 execution, Justin Drake, ethresear.ch, January 2025