著者：グレイクラブ、Shenchao TechFlow
イーサリアムの開発者たちは、EVMを避けられるなら避けるという暗黙の習慣を持っている。
過去数年、チェーン上で新しい暗号学操作が必要になるたびに、開発者の最初の反応はEVM内でそれを実装することではなく、仮想マシンを回避し、プロトコル層に直接ハードコードされたショートカットである「プリコンパイル契約」の追加を申請することだった。
3月1日、ヴィタリク・ブテリンはX上で長文の投稿をし、この薄い紙をはがした。彼の原語の要旨は、イーサリアムのすべての意義はその汎用性にあり、EVMが十分でないならば、私たちはこの問題に正面から取り組み、より優れた仮想マシンを構築すべきである、というものだった。
彼は二つの具体的な手術用ナイフを提示した。
最初の一刀：「データ構造」を変更
最初の変更はイーサリアムのステートツリーに適用されます。これはイーサリアムの「帳簿インデックスシステム」と理解できます。誰かが残高を確認したり、トランザクションを検証したりするたびに、このツリーを下って調べる必要があります。
問題は、現在この木があまりにも「太い」ことです。イーサリアムは「六分岐ケッカーメルクリパトリシア木」という構造を使用しています（名前が呪文のように長い）。Vitalikが提案したEIP-7864では、これをより簡潔な二分木に置き換えようとしています。
たとえば、以前は1つのデータを確認するのに六叉路で何度も方向を選んでいたのが、今では左と右の2択だけになりました。その結果、マーチル枝の長さは元の4分の1に短縮されます。軽クライアントにとっては、データを検証するために必要な帯域幅が大幅に削減されます。
しかし、ヴィタリクは木の形を変えるだけでは満足せず、「葉の文字」、つまりハッシュ関数も変更したいと考えています。候補はBlake3とPoseidonの2つです。
- Blake3は安定した速度向上をもたらします；
- Poseidonはより攻撃的で、理論的には証明効率をさらに数十倍向上させることができるが、セキュリティについてはさらなる監査が必要である。
注目すべきは、この方案がこれまでコミュニティで長年議論されてきたVerkle Treesを実際に置き換えた点である。Verkleは2026年のハードフォークの優先方案であったが、その基盤となる楕円曲線暗号が量子計算の脅威にさらされているため、2024年半ばから人気が低下し、二分木方案が台頭した。
第二の手：「仮想マシン」を交換し、EVMをスマートコントラクトに変える
もう一つの変更はより大膽で、より議論を呼ぶ：長期的にEVMをRISC-Vアーキテクチャで置き換えること。
RISC-Vはオープンソースの命令セットであり、元々ブロックチェーンとは関係なかったが、現在ではほぼすべてのZK証明システム内で使用されている。Vitalikの論理は非常に単純だ：証明器がすでにRISC-Vという言語を話しているなら、なぜ仮想マシンは別の言語を話して、その間に翻訳層を挟む必要があるのか？翻訳層を削除すれば、効率は自然と向上する。
RISC-Vのインタプリタはわずか数百行のコードで実現できる。Vitalikは、これがブロックチェーン仮想マシン应有的姿であると述べた。
彼は三段階の計画を立てた。第一段階では、新しい仮想マシンでプリコンパイル済みの契約を実行し、既存のプリコンパイルの80％を新しいVMコードで再実装する。第二段階では、開発者が新しい仮想マシンの契約を直接デプロイし、EVMと並行して実行できるようにする。第三段階では、EVMを退役させるが、完全な後方互換性を実現するために、新しい仮想マシン上で動作するスマートコントラクトとして書き直す。
古い車の所有者は車を買い替える必要はありません。エンジンが静かに交換されただけで、ステアリングはそのままです。
この二つの要素を合わせると、どれほど重要でしょうか？ヴィタリックは数値を示しました：状態ツリーと仮想マシンを合わせて、イーサリアムの証明ボトルネックの80％以上を占めています。言い換えれば、この二つの部分を変更しない限り、イーサリアムはZK時代におけるスケーリングで立ち止まったままです。
Arbitrumは同意しません：倉庫でフォークリフトを使うからといって、宅配便の運転手にもフォークリフトを運転させることはできません
しかし、これは誰もが首肯するような話ではありません。
昨年11月、Arbitrumのコア開発チームであるOffchain Labsは、詳細な技術的反論を発表した。4人の研究者は、RISC-VはZK証明に適しているが、コントラクトの「配布形式」には適していない、という核心的な見解を示した。
彼らは重要な区別を示しました。「配送命令セット」（dISA）と「証明命令セット」（pISA）は同じものである必要はないということです。あなたの倉庫で荷物を運ぶのにフォークリフトが最も効率的だとしても、宅配便の運転手が自宅までフォークリフトで届ける必要があるわけではありません。
Offchain Labsは、スマートコントラクト層にWebAssembly（WASM）を採用することを提唱しており、その理由は非常に堅実である：WASMは標準的なハードウェア上で高効率で実行され、大多数のイーサリアムノードはRISC-Vチップを実行していないため、強制的に切り替えるにはエミュレーターが必要になる。WASMには成熟した型安全検証メカニズムが備わっており、WASMのツールチェーンエコシステムはすでに数十億の実行環境で実証されている。
さらに重要なのは、彼らが単に口で言うだけでなく、Offchain Labs が Arbitrum 上でプロトタイプを実現していることです。WASM をスマートコントラクトの配布形式として使用し、RISC-V にコンパイルして ZK 証明を行います。両層はそれぞれの役割を果たし、互いに干渉しません。
彼らはまた、深く考えさせられるリスクを指摘した：ZK証明の分野では技術の進化が極めて速く、最近ではRISC-Vの実装が32ビットから64ビットに切り替わった。もし今この段階でRISC-VをイーサリアムL1に固定してしまうと、2年後により優れた証明アーキテクチャが登場した場合どうなるのか？急速に移動する標的に対して賭けをかけるのは、イーサリアムのスタイルではない。
より大きな背景：L2が「離乳」し始めている
この提案を理解するには、より広い背景が必要です。
ちょうど1か月前、ヴィタリックはイーサリアムに「専用のL2ロードマップ」が必要かどうかを公に疑問を呈し、L2陣営から一斉の反応を引き起こした。Espresso SystemsのCEOであるベン・フィッシュはCoinDeskに対して、ヴィタリックの意図は、L2の当初の目的がイーサリアムのスケーリングを支援することだったが、今やイーサリアム自身が高速化しているため、L2の位置づけも当然変化すべきだ、ということだと的確に述べた。
興味深いことに、L2はパニックになるのではなく、むしろ「イーサリアムからの脱却」を積極的に進めている。OP Labsの共同創設者であるJing Wangは、L2を独立したウェブサイトに例え、イーサリアムを下層のオープンな決済標準と述べた。PolygonのCEOであるMarc Boironはさらに明確に、真の課題はスケーリングではなく、支払いのような実際のシナリオに特化したブロック空間を構築することだと語った。
言い換えれば、ビタリクの今回の実行層への大規模な変更は、より大きなトレンドの技術的な裏付けである：イーサリアムは自らのコア機能への制御権を取り戻しており、L2たちは強制されたり、ついに独自の存在理由を見出したりしている。
これは実現できますか？
ビタリック自身も、仮想マシンの置き換えについては開発者コミュニティ全体での広範な合意がまだ得られていないことを認めている。状態ツリーの改革はより成熟しており、EIP-7864には具体的な草案と推進チームがすでに存在する。しかし、RISC-VによるEVMの置き換えはまだ「ロードマップ」の段階にとどまっており、コードに実装されるにはまだ距離がある。
しかしVitalikは先週、印象的な発言をしました：イーサリアムはすでに飛行中に1回ジェットエンジンを交換しました（The Mergeを指す）、今後さらに約4回交換できるでしょう——状態ツリー、簡素化されたコンセンサス、ZK-EVM検証、仮想マシンの置換。
イーサリアムのGlamsterdamアップグレードは2026年前半に実装される見込みで、その後にHegotaが続きます。両方のハードフォークの詳細はまだ確定していませんが、状態ツリーの改革と実行層の最適化が明確な主要な方向性です。
イーサリアムの物語は、「できるかできないか」の問題ではなかった。PoWからPoSへ、L1すべてに取り組むからRollup中心へと移行し、それは万メートルの高空でエンジンを分解する能力と勇気をすでに証明している。
今回動かすのはより深い部分——新しい機能を追加するのではなく、古い基盤を掘り起こして再コンクリート打ちすることだ。これは深く計画されたリニューアルなのか、それともますます複雑になる無底洞なのか？その答えはおそらく2027年にならなければ明らかにならない。
しかし、少なくとも1つは確実なこと：イーサリアムは、ZK時代に「パッチを貼り続ける古いシステム」でいるつもりはない。パッチをどう外し、エンジンをどのモデルに換えるかという議論そのものが、結論よりも価値があるかもしれない。