Ethereumは大規模アップグレードに向けて準備を進めています。

Ethereum開発者の間には暗黙のルールがあります。それは、「可能な限りEVMの利用を避けること」です。

近年、オンチェーンで新たな暗号処理が必要となるたびに、開発者はEVM内部で実装するのではなく、「プリコンパイルドコントラクト」を要求する傾向にあります。これは仮想マシンを迂回し、プロトコル層で処理をハードコードする近道です。

3月1日、Vitalik Buterin氏はX上で長文のスレッドを投稿し、この不文律を公然と破りました。彼の主張は、「Ethereumの価値はその汎用性にある。EVMが不十分なら、問題に正面から向き合い、より優れた仮想マシンを構築すべきだ」というものです。

彼は2つの具体的な解決策を提案しました。

第一の解決策：「データ構造」の変更

最初の変更は、Ethereumのステートツリーに着目しています。これはネットワークの台帳インデックスシステムとして機能し、残高確認やトランザクション検証のたびにこのツリーを辿ることになります。

問題は、現状のツリーが「重すぎる」ことです。Ethereumは「ヘクサリKeccak Merkle Patriciaツリー」という構造を採用しています（呪文のような名称です）。Vitalik氏のEIP-7864は、これをよりシンプルなバイナリツリーに置き換える提案です。

従来はデータを参照するたびに各分岐点で6方向のいずれかを選択していましたが、今後は左右どちらかを選ぶだけで済みます。その結果、Merkleブランチの長さは従来の4分の1に縮小します。ライトクライアントにとっては、データ検証に必要な帯域幅が大幅に削減されます。

Vitalik氏はツリー構造の刷新だけでなく、「リーフのフォント」、つまりハッシュ関数の変更も目指しています。候補はBlake3とPoseidonの2つです。Blake3は一貫した速度向上を実現し、Poseidonはより急進的で理論上は証明効率を数十倍高める可能性がありますが、安全性にはさらなる監査が必要です。

注目すべきは、この提案が従来議論されていたVerkleツリーに取って代わる点です。Verkleは2026年のハードフォークの有力候補でしたが、基盤となる楕円曲線暗号が量子コンピュータの脅威にさらされています。2024年中頃からVerkleは徐々に支持を失い、バイナリツリー案が主流になりつつあります。

第二の解決策：「仮想マシン」の変更—EVMをスマートコントラクト化

2つ目の変更はさらに大胆かつ議論を呼ぶ内容です。それは、EVMを長期的にRISC-Vアーキテクチャへ置き換えるというものです。

RISC-Vはオープンソースの命令セットで、もともとブロックチェーンとは無関係ですが、現在ほぼすべてのZK証明システムが内部で利用しています。Vitalik氏の論理は明快です。「証明者が既にRISC-Vを使っているなら、仮想マシンも同じものを使うべきであり、変換レイヤーを設ける必要はない。」このレイヤーを排除すれば、自然と効率が向上します。

RISC-Vインタープリタは数百行のコードで実装可能です。Vitalik氏は「これこそブロックチェーン仮想マシンのあるべき姿だ」と主張します。

計画は3段階です。まず新しい仮想マシンをプリコンパイルドコントラクトに適用し、既存プリコンパイルの80%を書き換えます。次に、開発者が新VM用のコントラクトをデプロイできるようにし、EVMと並行稼働させます。最後にEVMを廃止しますが、完全に消すのではなく、新仮想マシン上でスマートコントラクトとして再実装し、完全な後方互換性を実現します。

既存ユーザーは車を買い替える必要はなく、エンジンだけが静かに交換され、ハンドルはそのまま残ります。

この2つの変更はどれほど重要なのでしょうか。Vitalik氏は数字を挙げています。「ステートツリーと仮想マシンは、Ethereumの証明ボトルネックの80%以上を占めている。これらを解決しなければ、ZK時代のスケーリングは停滞する。」

Arbitrumの反論：倉庫でフォークリフトを使うからといって、配達員までフォークリフトを運転する必要はない

しかし、全員が賛成しているわけではありません。

昨年11月、Arbitrumのコア開発チームOffchain Labsは詳細な技術的反論を発表しました。4人の研究者は、RISC-VはZK証明には適しているが、コントラクトの「配信フォーマット」としては不適切だと主張します。

彼らは「配信命令セット（dISA）」と「証明命令セット（pISA）」は同一である必要はないと指摘します。倉庫でフォークリフトを使えば効率的ですが、配達員が荷物を届けるのにフォークリフトを使うべきとは限りません。

Offchain Labsはコントラクト層にWebAssembly（WASM）を推奨しています。理由は明快です。WASMは標準的なハードウェア上で効率的に実行でき、ほとんどのEthereumノードはRISC-Vチップを搭載していません。強制的に切り替える場合はエミュレータが必要です。WASMは型安全性検証も成熟しており、ツールチェーンエコシステムも数十億回の実行環境で実証されています。

重要なのは、これは単なる理論ではないという点です。Offchain LabsはすでにArbitrum上でプロトタイプを稼働させています。コントラクト配信フォーマットとしてWASMを採用し、それをZK証明用にRISC-Vへコンパイル。2つのレイヤーが独立して動作します。

さらに、彼らは興味深いリスクも指摘しています。ZK証明技術は急速に進化しており、最近ではRISC-V実装が32ビットから64ビットへと移行しました。今RISC-VをEthereum L1に固定してしまうと、2年後により優れた証明アーキテクチャが登場した場合どうなるのか。急速に変化する技術に賭けるのはEthereumの流儀ではありません。

より広い文脈：L2の「自立」始まる

この提案を理解するには、より広い視点が必要です。

わずか1か月前、Vitalik氏は「Ethereumに専用のL2ロードマップはまだ必要か？」と公開で問いかけ、L2エコシステム全体が反応しました。Espresso SystemsのCEO Ben Fisch氏はCoinDeskで「Vitalik氏の主張は、L2はもともとEthereumのスケーリング支援のために存在していたが、Ethereum自体が高速化することでL2の役割も自然と変化する」という点だと述べています。

興味深いのは、L2側がパニックに陥るのではなく、積極的に「非Ethereum化」を進めていることです。OP Labsの共同創業者Jing Wang氏はL2を独立したウェブサイト、Ethereumを基盤となるオープンな決済標準になぞらえました。PolygonのCEO Marc Boiron氏は「本当の課題はスケーリングではなく、決済など現実のユースケースのための独自ブロックスペースを創出することだ」と率直に語っています。

つまり、Vitalik氏による実行レイヤーの刷新は、より大きな流れの技術的脚注に過ぎません。Ethereumが中核機能の主導権を取り戻す一方で、L2は自ら、あるいは必然的に独立存在の理由を見出しつつあります。

成功するのか？

Vitalik氏自身、仮想マシンの置き換えについては開発者全体の合意が得られていないことを認めています。ステートツリー改革の方はより成熟しており、EIP-7864にはすでにドラフトと専任チームが存在します。しかしEVMからRISC-Vへの移行はまだ「ロードマップ」段階で、実装には程遠い状況です。

それでも、先週Vitalik氏は印象的な発言をしました。「Ethereumはすでに飛行中にジェットエンジンを取り替えた（The Mergeを指す）し、あと4回は可能だ——ステートツリー、単純化されたコンセンサス、ZK-EVM検証、仮想マシンの置き換え。」

EthereumのGlamsterdamアップグレードは2026年前半に予定されており、Hegotaがそのすぐ後に続きます。2つのハードフォークの具体的内容はまだ未定ですが、ステートツリー改革と実行レイヤーの最適化が主要テーマとなることは確定しています。

Ethereumの物語は「実現可能かどうか」ではありません。PoWからPoSへ、L1集中からRollup中心へと、巡航高度でエンジンを組み替える能力と覚悟を証明してきました。

今回は、単なる新機能追加ではなく、「古い土台を引き剥がし、再構築する」ことが問われています。これは慎重に設計された刷新なのか、それとも複雑化の果てしない泥沼なのか。答えが出るのは2027年以降かもしれません。

しかし、少なくとも1つは確かです。EthereumはZK時代に「継ぎ接ぎだらけの旧式システム」であり続けるつもりはありません。パッチをどう外し、どんなエンジンを搭載するか——その議論自体が結論以上に価値あるものとなるでしょう。

免責事項:

1. 本記事はTechFlowより転載しており、著作権は原著者[Gray Lobster]に帰属します。転載にご異議がある場合は、Gate Learnチームまでご連絡ください。関連手続きに従い速やかに対応いたします。

2. 免責事項：本記事の見解および意見は著者個人のものであり、投資助言を構成するものではありません。

3. 本記事の他言語版はGate Learnチームが翻訳しています。Gateの明記がない限り、翻訳記事の無断転載・配布・盗用を禁じます。