ある時、私は気づいたのですが、Ethereumの近年の興味深い伝統は次のようなものです：仮想マシン自体を改良する代わりに、開発者たちは事前にコンパイルされたコントラクトを通じてそれを回避しているのです。しかしVitalikはそこにとどまらない。最近、彼はこれをゼロからやり直す詳細な計画を公開しました。

計画の第一部はEthereumの状態木に関するものです。簡単に言えば、これはデータを常に検索するインデックスシステムのようなものです。問題は、現在の構造—六方向のKeccak Merkle木—があまりにも巨大すぎることです。Vitalikが提案するEIP-7864は、これを二分木に置き換えるものです。六方向の選択の代わりに、単に左か右を選ぶだけです。その結果、Merkle木の長さは4分の1に短縮されます。軽量クライアントにとっては、帯域幅の要求が大幅に低減されることを意味します。

しかし、それだけではありません。Vitalikはハッシュ関数自体も変更したいと考えています。候補は二つあります：安定した高速化をもたらすBlake3と、理論的には証明の効率を何十倍も向上させる可能性のあるPoseidonですが、安全性はまだ検証中です。この計画は、長年コミュニティで議論されてきたVerkle Treesを実質的に置き換えるものでしたが、量子計算の脅威により人気を失っていました。

第二のステップはさらに野心的です：EVM自体をRISC-Vアーキテクチャに置き換えることです。シンプルなロジックは、ZK証明システムがすでにRISC-Vを理解しているなら、仮想マシンも別の言語を使う必要はないというものです。翻訳層を排除することで、すべてが自動的に高速化されます。Vitalikは三段階の計画を立てています：まず、事前にコンパイルされたコントラクトの80%を新しいVMに書き換える、次に開発者が直接コントラクトを展開できるようにする、そして最後に古いEVMを運用から引き上げる—ただし削除するのではなく、新しいマシン上のスマートコントラクトとして書き直すのです。古いコントラクトは、エンジンを交換可能な車のように動き続けるでしょう。

Vitalikは、状態木と仮想マシンはEthereumの制約の80%以上を占めていると述べています。これらを変えなければ、ZK時代のスケーリングは進まないでしょう。

しかし、全員が賛成しているわけではありません。Arbitrum Offchain Labsのチームは詳細な技術的反論を公開しました。彼らの立場は、RISC-VはZK証明には適しているが、コントラクトのフォーマットとしては必ずしも良くないというものです。彼らは、(dISA)の命令セットと、(pISA)の証明用命令セットを区別しています。彼らの意見では、それは同じものであるべきではありません。彼らはWebAssemblyをコントラクトレベルの標準とし、その後RISC-Vにコンパイルして証明を行うことを提案しています。すでにArbitrum上でプロトタイプを動かしており、動作しています。さらに、リスクも指摘しています：ZK技術は急速に進化しており、もし今RISC-VをL1に固定したら、2年後はどうなるのか？

この議論は、より大きな変化の中で行われています。Vitalikは最近、EthereumのL2の個別ロードマップの必要性を疑問視し始めました。興味深いことに、L2はパニックに陥ることなく、自らの役割を再考し始めています。Ethereum自体が高速化すれば、L2は単なるスケーリングだけでなく、実際のユースケースに特化した独自の領域を見つける必要があります。

Vitalik自身も、EVMの置き換えについてはまだコンセンサスが得られていないと認めています。状態木の改革はさらに進展しており、EIP-7864は具体的な計画を持っています。しかし、RISC-Vへの置き換えはまだロードマップの段階です。Glamsterdamのハードフォークは2026年前半を予定しており、その後Hegotaも続きます。詳細は未確定ですが、状態木の改革と実行レベルの最適化は確定した方向性です。

Ethereumの歴史は、「可能性」に関するものでした。PoWからPoSへの移行、L1からRollupへと、システムはすでに高高度でエンジンを解体できることを証明しています。今回は、より深い変革についてです：機能の追加ではなく、基盤そのものの刷新です。これは計画的な修理なのか、それとも複雑化する穴なのか？答えは2027年以降に明らかになるでしょう。ただ一つ確かなことは、Ethereumは古いシステムのパッチを施すだけのものではないということです。この議論自体—パッチの扱い方やエンジンの選択についての議論—は、もしかすると、どんな結論よりも価値があるのかもしれません。