イーサリアムはエンジンを交換しようとしている
TechFlow厳選深潮セレクト
イーサリアムはエンジンを交換しようとしている
今回は、より深い部分に手を加えます。新機能を追加するのではなく、古い基礎を掘り起こして再構築します。
Web3業界の深掘り報道に専念し潮流を洞察執筆：グレイ・ロブスター、TechFlow
イーサリアムの開発者には、暗黙の了解がある。「EVM（Ethereum Virtual Machine）に手をつけるのは、やむを得ない場合のみ」。
ここ数年、ブロックチェーン上に新たな暗号演算が必要になるたび、開発者の第一反応は、EVM内でその機能を実装することではなかった。代わりに、仮想マシンをバイパスし、プロトコル層でハードコードされた高速経路である「プリコンパイル契約（precompiled contract）」の追加を申請するのが常であった。
3月1日、ヴィタリク・ブテリン氏がX（旧Twitter）で長文の投稿を行い、この「薄い紙一枚」を完全に破り捨てた。彼の言葉を要約すれば、「イーサリアムの本質的価値はその汎用性にある。もしEVMが十分でないと感じられるなら、正面からこの問題に向き合い、より優れた仮想マシンを構築すべきだ」というものである。
彼は、具体的な二つの改革案を提示した。
第一の改革：「データ構造」の置き換え
最初の変更は、イーサリアムの状態ツリー（state tree）に向けられる。これは、イーサリアムの「台帳インデックスシステム」とも言えるものであり、ユーザーが残高を照会したり、トランザクションを検証したりする際、常にこのツリーを辿って下位ノードへと降りていく必要がある。
問題は、このツリーが現在あまりにも「太すぎる」点にある。イーサリアムは「6分岐Keccakメルクル・パトリシア木（Merkle Patricia Tree）」という、まるで呪文のような名前の構造を採用している。これに対し、ヴィタリク氏が提案するEIP-7864では、より簡潔な2分岐木（binary tree）への置換が提唱されている。
たとえれば、従来は1つのデータを検索する際に6方向の交差点で何度も選択を繰り返す必要があったのが、今後は単に「左か右か」の2択で済むようになる。その結果、メルクルブランチの長さは元の4分の1まで短縮される。ライトクライアントにとっては、データ検証に必要な帯域幅が大幅に削減されることになる。
ただし、ヴィタリク氏はツリーの「形」だけを変えることに満足していない。さらに「葉っぱに記載された文字」、つまりハッシュ関数自体の置き換えも目指している。候補となるのは、Blake3とPoseidonの2つである。Blake3は安定した性能向上をもたらす一方、Poseidonはさらに大胆な選択で、理論的にはゼロ知識証明（ZK proof）の効率を数十倍も向上させ得るが、そのセキュリティについてはさらなる監査が必要とされる。
なお、この案は、これまでコミュニティで長年にわたり議論されてきたVerkle Treesを事実上代替するものである。Verkle Treesは2026年のハードフォークで採用される予定の最有力候補だったが、その基盤となる楕円曲線暗号が量子コンピューティングによる脅威にさらされているという懸念から、2024年半ば以降、次第に支持を失い、2分岐木案が台頭したのである。
第二の改革：「仮想マシン」の置き換え——EVMを単一のスマートコントラクトへ
二つ目の変更は、さらに大胆かつ議論を呼ぶものである：長期的にEVMをRISC-Vアーキテクチャで置き換えるという提案である。
RISC-Vはオープンソースの命令セットアーキテクチャであり、本来はブロックチェーンとは無縁の存在であったが、現在ではほぼすべてのゼロ知識証明（ZK）システム内部で既に採用されている。ヴィタリク氏の論理は極めて明快だ。「証明器（prover）がすでにRISC-Vという言語を話しているのだから、なぜ仮想マシンだけが別の言語を話し、その間で翻訳処理を挟まなければならないのか？翻訳層を排除すれば、当然ながら効率は向上する」。
RISC-Vインタープリターはわずか数百行のコードで実現可能である。ヴィタリク氏は、これこそがブロックチェーン用仮想マシンに求められる姿だと断言する。
彼は、三段階の移行計画を提示している。第一段階として、新仮想マシン上でプリコンパイル契約を実行し、既存の80％のプリコンパイルを新VMコードで再実装する。第二段階では、開発者が新仮想マシン向けのコントラクトを直接デプロイでき、EVMと並列して実行可能とする。第三段階では、EVMは廃止されるが、それは「消滅」を意味しない——EVM自体が、新仮想マシン上で動作する一つのスマートコントラクトとして再実装され、完全な後方互換性が確保されるのである。
古い車のオーナーは、車を買い替える必要はない。エンジンだけが静かに交換され、ステアリングホイールはそのまま使い続けられるのだ。
この二つの改革が合わせてどれほど重要かについて、ヴィタリク氏は明確な数字を示している：状態ツリーと仮想マシンは、イーサリアムにおけるゼロ知識証明のボトルネックの80％以上を占めている。言い換えれば、これら二つの要素を変更しなければ、イーサリアムはZK時代におけるスケーラビリティ向上において、実質的に原地踏みを強いられることになる。
Arbitrumは異議あり：「倉庫でフォークリフトを使うからといって、配達員にもフォークリフトを運転させるべきではない」
しかし、これは誰もが賛成する話ではない。
昨年11月、Arbitrumのコア開発チームであるOffchain Labsが、詳細な技術的反論を発表した。4名の研究員が提示した核心的な主張は以下の通りである：「RISC-Vは確かにZK証明に適しているが、コントラクトの『配信フォーマット』（delivery format）としては不適切である」。
彼らは、重要な区別として、「配信命令セット」（dISA：delivery Instruction Set Architecture）と「証明命令セット」（pISA：proof Instruction Set Architecture）は必ずしも同一である必要がないと指摘する。「倉庫ではフォークリフトで荷物を運ぶのが最も効率的だが、だからといって宅配員が顧客の玄関先までフォークリフトで走らせるべきではない」のである。
Offchain Labsは、コントラクト層にはWebAssembly（WASM）を採用すべきだと主張する。その根拠は極めて堅実である：WASMは標準ハードウェア上で高い実行効率を発揮するが、大多数のイーサリアムノードはRISC-Vチップを搭載していないため、強制的に切り替えるとシミュレーターが必要になってしまう。また、WASMには成熟した型安全性検証機構があり、そのツールチェーンエコシステムは、数十億もの実行環境で実証済みである。
さらに重要なのは、彼らが単なる理論的主張にとどまらず、すでに実証済みである点である。Offchain Labsは、Arbitrum上でプロトタイプを実際に稼働させている：WASMをコントラクトの配信フォーマットとして使用し、その後、ZK証明のためにRISC-Vへとコンパイルするという二段階アプローチを成功させている。各レイヤーがそれぞれの役割を果たし、相互干渉しない設計である。
さらに、彼らはもう一つの深刻なリスクにも言及している：ZK証明分野の技術進化は極めて速く、最近ではRISC-Vの実装が32ビットから64ビットへと切り替わっている。もし今ここでRISC-VをイーサリアムL1に「固定」してしまうと、2年後にさらに優れた証明アーキテクチャが登場した場合、どう対応するのか？まさに「移動中の標的」に賭けることは、イーサリアムのスタイルではないと警告する。
より大きな背景：L2が「離乳」を始めている
今回の提案を正しく理解するには、もう少し広い文脈が必要である。
ちょうど1か月前、ヴィタリク氏が「イーサリアムには専用のL2ロードマップがまだ必要なのか？」と公然と疑問を呈したことで、L2陣営全体が一斉に反応を示した。Espresso SystemsのCEOベン・フィッシュ氏はCoinDeskに対し、的確な一言を述べている：「ヴィタリク氏の真意は、L2が当初イーサリアムのスケーラビリティを支えるために設けられたものであったが、今やイーサリアム自身が高速化しようとしているため、L2の役割も必然的に変化せざるを得ないということだ」。
興味深いことに、L2プロジェクトは混乱するどころか、むしろ積極的に「イーサリアム依存からの脱却」を進めている。OP Labsの共同創設者ジン・ワン氏は、L2を独立したウェブサイトに例え、イーサリアムをその基盤となるオープンな決済規格に喩えた。PolygonのCEOマルク・ボワロン氏はさらに率直に、「真の課題はスケーラビリティではなく、支払いといった実世界のユースケースに特化した独自のブロックスペースを構築することだ」と述べている。
言い換えれば、ヴィタリク氏による実行層の大規模改修は、こうしたより大きな潮流を反映する技術的注釈である：イーサリアムは、自らのコア能力に対する支配権を取り戻そうとしている一方で、L2は、やむを得ずあるいはついに、自立した存在意義を見出しつつあるのだ。
これは実現可能なのか？
ヴィタリク氏自身も認めているように、仮想マシンの置き換えについては、現時点で開発者コミュニティの広範な合意は得られていない。一方、状態ツリーの改革はより成熟しており、EIP-7864にはすでに具体的な草案と推進チームが存在する。だが、RISC-VによるEVM置換については、まだ「ロードマップ」段階にとどまり、実際のコード実装には至っていない。
とはいえ、ヴィタリク氏は先週、非常に印象的な発言をしている：「イーサリアムは、すでに飛行中にジェットエンジンを一度交換したことがある（『The Merge』を指す）。今後も、さらに約4回のエンジン交換が可能だ——状態ツリー、コンセンサスの簡素化、ZK-EVM検証、そして仮想マシンの置き換えである」。
イーサリアムのGlamsterdamアップグレードは2026年前半の実施が予定されており、その後にHegotaが続く。これらのハードフォークの具体的な内容はまだ最終決定されていないが、状態ツリー改革と実行層の最適化は、確実なメインテーマである。
イーサリアムの歴史は、常に「できるかどうか」を問うものではなかった。PoWからPoSへの移行、L1中心主義からRollup中心主義への転換を通じて、イーサリアムは、高度1万メートルの空中でエンジンを分解・交換する能力と胆力をすでに証明してきたのである。
今回挑戦されるのは、さらに深部の領域——新機能の追加ではなく、旧来の地盤を掘り起こして根本から作り直すことである。これは、長期的な視点に立った賢いリニューアルなのだろうか、それとも、修正を重ねるごとに複雑化していく終わりなき迷宮なのだろうか？その答えは、おそらく2027年になって初めて明らかになるだろう。
ただ、一つ確かなことがある。イーサリアムは、ZK時代において「パッチを当て続ける老朽化システム」としての地位を維持するつもりはないということだ。では、そのパッチをどこから剥がし、エンジンをどんな仕様に交換すべきか——この議論そのものが、結論よりもはるかに価値があるかもしれない。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
深潮TechFlow
