イーサリアムはブロックを実行せずに検証する準備を進めている – その方法とは

イーサリアムのコアアーキテクチャの内部で、微妙ながら重大な変更が進行しています。すべてのトランザクションを再実行してブロックを検証するのではなく、ネットワークはバリデーターがゼロ知識証明を検証することで正確性を確認する代替経路を準備しています。

この作業は2026年のイーサリアムのLayer-1ロードマップに含まれており、コンセンサスに到達する方法の構造的な変更を表しており、エッジに追加される新しいスケーリング機能ではありません。

この提案は、ladislaus.ethとして知られるイーサリアム財団のメンバーがL1-zkEVM設計に向けた進捗を概説した後、公開されました。この変更は、ブロックがどのように生成されるか、またはユーザーがオンチェーンで何を送信するかを変更しません。代わりに、バリデーターがブロックが有効かどうかを判断する方法を変更します。最初のL1-zkEVMワークショップは2026年2月11日に予定されており、この取り組みに関する正式な調整の開始を示しています。

完全な再実行から証明認証へ

今日、ブロックを証明したいバリデーターは、その中のすべてのトランザクションを再実行する必要があります。各ノードは独立して同じ計算を繰り返し、同じ状態遷移をチェックし、同じ実行状態を保存します。このモデルはイーサリアムの創設以来維持されてきましたが、アクティビティに応じて線形にスケールします。より高いガスリミットは、すべての参加者の計算負荷、状態サイズ、帯域幅要件を増加させます。

開発中の代替手段は、繰り返しの計算を暗号認証に置き換えます。トランザクションを再実行する代わりに、バリデーターは実行が正しく実行されたことを示すコンパクトなゼロ知識証明を検証します。認証時間は、ブロックが内部的にどれほど複雑であったかに関係なく、ほぼ一定のままです。これがzkEVM証明の背後にある中心的なアイデアであり、現在イーサリアムのコンセンサスワークフローに直接組み込まれています。

L1-zkEVMパイプラインの仕組み

現在の設計では、実行クライアントが実行ウィットネスを生成します。これは、完全な実行状態を保持することなくブロックの状態遷移を検証するのに十分な自己完結型のデータバンドルです。標準化されたゲストプログラムがそのウィットネスを消費し、実行の正確性をチェックします。zkVMがこのプログラムを実行し、実行がイーサリアムのルールに従ったことを証明する証明を生成します。

その後、コンセンサスクライアントは、完全な実行クライアントを呼び出す代わりに、その証明を検証できます。この経路を選択するバリデーターはzkAttesterと呼ばれます。重要なことに、この経路はオプションです。バリデーターは、今日と同じようにブロックを再実行し続けることができます。

このメカニズムはEIP-8025(オプション実行証明)の下で正式化されています。この提案はハードフォークを必要とせず、バリデーターに証明ベースの検証を採用することを強制しません。再実行と並行して検証経路を追加します。

コンセンサス統合とクライアントの多様性

EIP-8025は、証明がピアツーピアネットワーク全体でどのように循環するかを指定します。異なるクライアント実装からの実行証明は、専用のトピックでゴシップされます。ブロックを処理する際、zkAttesterは実行クライアントを呼び出す代わりに、これらの証明を検証できます。

現在の作業仮定は3/5の閾値です。5つの独立した証明のうち3つが正常に検証されると、ブロックの実行が受け入れられます。この閾値は進化する可能性がありますが、意図は明確です。証明ベースの検証を許可しながら、実行クライアントの多様性を維持します。多様性は、運用上の選択ではなく、プロトコルレベルの機能として残ります。

バリデーターにとって重要な理由

zkAttesterは、実行状態を保存したり、完全な実行レイヤーチェーンを同期したりする必要はありません。同期は、最後に確定したチェックポイント以降の最近の証明をダウンロードすることに削減されます。これにより、コンセンサスへの参加のハードウェア要件が劇的に低下します。

ソロステーカーやホームバリデーターにとって、これは重要です。今日バリデーターを実行するには、コンセンサスクライアントとリソース集約的な実行クライアントの両方を維持する必要があります。証明認証は再実行を置き換え、ストレージ、計算、帯域幅の要求を削減します。これにより、認証保証を弱めることなく参入障壁が低くなります。

影響はアテスターを超えて広がります。zkEVM証明はステートレスであるため、コンシューマハードウェア上でイーサリアムをローカルで検証することが再びよりアクセスしやすくなります。「信頼せずに検証する」という原則は、希釈されるのではなく強化されます。

依存関係とタイミング制約

1つの前提条件が重要です。証明生成には時間が必要であり、パイプライン処理がないと、ウィンドウが狭すぎます。これがePBS(組み込み型プロポーザー・ビルダー分離)が関連する場所です。今後のGlamsterdamハードフォークを対象としたePBSは、証明ウィンドウを約1〜2秒から約6〜9秒に延長します。この延長により、シングルスロット証明生成がはるかに現実的になります。

ePBSがなければ、L1証明認証は制約されたままです。それがあれば、設計は運用上実行可能になります。

影響を受けるのは誰か

実行レイヤークライアントチームは新しい証明サーフェスを獲得し、各クライアントが潜在的な証明ソースになります。プルーバー設計は未解決の問題です。少数の洗練されたビルダーに証明を集中させると、ライブネスリスクが生じますが、完全に分散された証明は、パフォーマンスと調整の課題を引き起こします。設計目標は明確です。証明は大規模データセンターの外で実行可能である必要があります。

すでにイーサリアムブロックチェーンブロックを証明しているzkVMベンダーは、構築するための標準化されたインターフェースを獲得します。Layer-2チームも恩恵を受けます。実行証明がバリデーターによって検証されると、同じ証明が共有インフラストラクチャを通じてネイティブロールアップにサービスを提供できます。

最終的に、ユーザーは、より安価な認証、より広範なバリデーター参加、および中央集権化の圧力なしでより高い実行可能なガスリミットから恩恵を受けます。

現在のステータス

EIP-8025はconsensus-specsの機能ブランチに入り、提案ステータスに向けて進行しています。2026年のL1-zkEVMロードマップは現在公開されており、実行ウィットネス標準化、zkVMインターフェース、コンセンサス統合、プルーバーインフラストラクチャ、ベンチマーク、正式なセキュリティー認証全体で構造化されています。

2026年2月11日のワークショップは、これらのトラック全体での集中的な調整の開始を示します。これは見出しを飾るアップグレードではありませんが、基盤となるものです。イーサリアムがバリデーター要件をスケールせずに実行レイヤーをスケールする場合、これがその方法です。

投稿Ethereum Is Preparing to Validate Blocks Without Running Them – Here is HowはETHNewsに最初に掲載されました。