作者：灰色龙虾，深潮 TechFlow
イーサリアムの開発者には暗黙の了解がある：EVMに触れないなら触れない。
過去数年、チェーン上で新しい暗号学的操作が必要になるたびに、開発者の第一反応はそれをEVM内で実装することではなく、「プリコンパイルコントラクト」を追加することだった。これは仮想マシンを迂回し、プロトコル層に直接ハードコーディングするショートカットだ。
3月1日、Vitalik ButerinはX上に長文を投稿し、その壁を完全に打ち破った。彼の要旨は次の通り：イーサリアムの全ての意義はその汎用性にある。もしEVMが十分でないなら、その問題を正面から解決すべきで、より良い仮想マシンを作るべきだ。
彼は具体的な2つのアプローチを示した。
最初の変更はイーサリアムの状態ツリーに関するものだ。これは「イーサリアムの帳簿索引システム」と理解でき、残高照会や取引検証のたびにこの木を下にたどる。
問題は、この木が「太りすぎている」ことだ。イーサリアムは「六叉Keccakマークル木」という構造（名前が呪文のようだ）を採用している。Vitalikが提案したEIP-7864は、これをよりシンプルな二分木に置き換えることだ。
例えるなら、以前はデータを検索するのに六叉の交差点で方向を何度も選ぶ必要があったが、今度は左右だけにする。結果として、マークルの枝の長さは4分の1に短縮される。軽量クライアントにとっては検証に必要な帯域幅が大幅に削減される。
しかしVitalikは木の形状だけを変えることに満足しない。木の葉のハッシュ関数も変更したいのだ。候補はBlake3とPoseidonの二つ。
ちなみに、この案は以前コミュニティで議論されていたVerkle Treesに取って代わるものだ。Verkleは2026年のハードフォークの優先候補だったが、その基盤となる楕円曲線暗号が量子計算の脅威に直面し、2024年中頃から次第に廃れ、二分木案が台頭した。
二つ目の変更はより大胆で議論を呼ぶものだ：長期的にRISC-Vアーキテクチャに置き換える。
RISC-Vはオープンソースの命令セットで、もともとブロックチェーンとは関係なかったが、今やほぼすべてのZK証明システムで使われている。Vitalikの論理はシンプルだ：証明器がすでにRISC-Vを使っているのなら、仮想マシンも別の言語を使う必要はない。翻訳層を排除すれば効率は自然と向上する。
RISC-Vのインタプリタは数百行のコードで済む。Vitalikはこれこそが理想的なブロックチェーンの仮想マシンだと考えている。
彼は三段階の計画を示した：まず、新仮想マシンでプリコンパイルコントラクトを動かし、既存の80％を新VMに書き換える。次に、開発者が新仮想マシンのコントラクトを直接デプロイできるようにし、EVMと並行して動かす。最後に、EVMは廃止されるが、完全に消えるわけではなく、新仮想マシン上で動作するスマートコントラクトに改修され、後方互換性を実現する。
既存のユーザーはそのまま使い続けられる。エンジンだけが静かに変わるだけだ。
これら二つの変更の重要性は？Vitalikは数字を示す：状態ツリーと仮想マシンは、イーサリアムの証明のボトルネックの80％以上を占めている。言い換えれば、これらを動かさなければ、ZK時代のイーサリアムのスケーリングは停滞したままだ。
しかし、これは誰もが賛同した話ではない。
昨年11月、Arbitrumのコア開発チームOffchain Labsは詳細な技術的反論を発表した。4人の研究者の核心は次の通り：RISC-Vは確かにZK証明には適しているが、「交付フォーマット」としては適していない。
彼らは重要な区別を提起した：**「交付命令セット」（dISA）と「証明命令セット」（pISA）は同じものである必要はない。**倉庫がフォークリフトで荷物を運ぶのが最も効率的でも、宅配員がフォークリフトを使う必要はない。
Offchain LabsはWebAssembly（WASM）をコントラクト層に採用すべきだと主張し、その理由は堅実だ：WASMは標準ハードウェア上で高効率に動作し、多くのイーサリアムノードはRISC-Vチップを使っていないため、強制的に切り替えるとエミュレーターが必要になる。WASMは成熟した型安全性検証機構を持ち、ツールチェーンも数十億の実行環境で実証済みだ。
さらに重要なのは、彼らは単なる理論だけでなく、実際にArbitrum上でプロトタイプを動かしていることだ。WASMをコントラクトの交付フォーマットとし、それをRISC-VにコンパイルしてZK証明を行う。二層はそれぞれの役割を果たし、干渉しない。
また、彼らは一つのリスクも指摘している：ZK証明の技術は非常に速く進化しており、最近ではRISC-Vの実装も32ビットから64ビットに切り替わった。今すぐRISC-VをイーサリアムL1に固定すると、数年後により良い証明アーキテクチャが出てきた場合はどうなるのか？動く標的に賭けるのは、イーサリアムのスタイルではない。
この提案を理解するには、よりマクロな背景も必要だ。
ちょうど一ヶ月前、Vitalikはイーサリアムに「専用のL2ロードマップ」が必要かどうかを疑問視した。これに対し、L2陣営は一斉に反応した。Espresso SystemsのCEO Ben FischはCoinDeskに対し、「Vitalikの意図は、L2はもともとイーサリアムのスケーリングを助けるためだったが、今やイーサリアム自体が高速化しているので、L2の役割も変わるべきだ」と述べた。
面白いのは、L2は恐れるどころか、「イーサリアムからの独立」を積極的に進めていることだ。OP Labsの共同創設者Jing WangはL2を「独立したウェブサイトのようなもので、イーサリアムはその基盤のオープンな決済標準だ」と比喩した。PolygonのCEO Marc Boironはもっと直截に言う：真の課題は拡張ではなく、支払いのような実世界のシナリオに特化した独自のブロック空間を作ることだ。
要するに、Vitalikの今回の実行層への大規模な改変は、より大きな潮流の一端だ：イーサリアムは自身のコア能力のコントロールを取り戻しつつあり、L2はそれぞれの存在理由を見出しつつある。
Vitalik自身も認めている：**仮想マシンの置き換えは、現段階では開発者コミュニティの広範な合意を得ていない。**状態ツリーの改革はより成熟しており、EIP-7864には具体的な草案と推進チームもある。しかし、RISC-VによるEVMの置き換えは、まだ「ロードマップ」段階であり、コードに落とし込まれるには距離がある。
しかし、Vitalikは先週、印象的な表明をした：イーサリアムはすでに一度エンジンを換えた（The Mergeを指す）、次は約4回の交換が可能だと——状態ツリー、軽量コンセンサス、ZK-EVM検証、仮想マシンの置き換え。
イーサリアムのGlamsterdamアップグレードは2026年前半に実現予定で、その後Hegotaも続く。具体的な内容は未確定だが、状態ツリーの改革と実行層の最適化が主軸だ。
イーサリアムの物語は「できるかできないか」の問題ではない。PoWからPoSへ、L1からRollupへと変遷し、自らの能力を高空から分解する胆力と実行力を証明してきた。
今回はより深い部分——新機能の追加ではなく、古い土台を掘り起こして再構築する——に取り組む。これは緻密な刷新なのか、それとも修繕を重ねて底なしの迷宮に入るのか。答えは2027年までわからないだろう。
しかし少なくとも一つ確かなことは：イーサリアムはZK時代に「パッチを当てる古いシステム」にはならないということだ。パッチの外し方やエンジンのモデルチェンジについての議論は、もしかすると結論よりも価値があるかもしれない。
関連記事
