最近、面白いことに気づきました。VitalikはEthereumのアーキテクチャについてかなり過激な提案をしており、正直なところ、それについて話す価値があります。

さて、ここ数年、Ethereumの開発者たちには一つの悪い癖があります。ブロックチェーン上で新しい暗号操作が必要になったとき、EVMに正しく実装する代わりに、単にプロトコルレベルで事前にコンパイルされたコントラクトを追加して問題を回避してきました。まるで基礎をやり直すことなく、常に修理を続けているようなものです。Vitalikは本質的に言ったのです：やめろ、それで十分だ。EVMが十分でないなら、修正を積み重ね続けるのはやめて、置き換えよう。

彼は二つの大きな変更を提案しました。最初はEthereumの状態木に関するもので、これはレジスタのインデックスシステムのようなものです。現在、それは複雑な構造で、六叉のKeccak Merkle Patricia Treeと呼ばれています(そう、名前はちょっと狂ってる)。アイデアは、それを単純な二分木に置き換えることです。具体的には、六つの分岐点で進む代わりに、二つの選択肢、左か右だけにするということです。結果として、Merkleの枝の長さは約75%短縮されます。軽量クライアントにとっては、帯域幅の面で非常に大きなメリットです。

しかし、Vitalikはそこにとどまりません。ハッシュ関数も変更したいのです。候補はBlake3かPoseidonです。Blake3は確かに従来型ですが、Poseidonはより野心的で、理論上、証明の効率を数十倍にまで高めることができるかもしれませんが、安全性の監査がもっと必要です。

二つ目の変更はより議論を呼ぶもので、長期的にはEVMをRISC-Vに置き換えるというものです。RISC-Vはオープンソースの命令セットアーキテクチャで、もともとは別の用途のために作られましたが、今ではZK証明システムの中核として広く使われています。論理はシンプルです：すでに全ての証明者がRISC-Vを使っているのに、なぜ仮想マシンだけが別の言語と中間層の翻訳を必要とするのか？非効率的です。RISC-Vのインタプリタは数百行のコードで済みます。

Vitalikは三段階の計画を示しました：まず、事前コンパイルされたコントラクトを新しい仮想マシン上で実行し、その後、既存のEVMと並行してこの新しいアーキテクチャに直接デプロイできるようにし、最後にEVMを廃止し、それを新しい仮想マシン上のスマートコントラクトとして再実装する。互換性の喪失ゼロです。これは洗練されたアプローチです。

彼が示した数字は衝撃的です：状態木と仮想マシンは、Ethereumの証明のボトルネックの80%以上を占めています。つまり、これら二つのコンポーネントに手を加えなければ、ZK時代の真のスケーラビリティは期待できません。

しかし、もちろん全ての人が賛成しているわけではありません。Offchain Labs、Arbitrumの背後にいるチームは、詳細な技術的反論を公開しています。彼らの主張は：RISC-VはZK証明には良いが、コントラクトの配信フォーマットとしては適していないというものです。重要な区別をしています：あなたがエレベーターを運転する必要がないのと同じように、倉庫がエレベーターを使っているからといって、配送者もそれを使う必要はないのです。彼らはWebAssembly（(WASM)）をコントラクト層に推しています。彼らの主張は説得力があります。WASMは標準的なハードウェア上で効率的に動作し、多くのEthereumノードはRISC-Vチップ上で動いていません。Offchain Labsはすでにプロトタイプも実装済みです：コントラクト用のWASMをZK証明用にRISC-Vにコンパイルするというものです。二層構造で、それぞれが自分の役割を果たしています。

興味深いのは、より広い文脈です。数ヶ月前、VitalikはEthereumに特化したL2のロードマップの必要性を疑問視していました。そして、L2はパニックにならず、「Ethereumからの脱却」を積極的に進め始めています。PolygonやOP Labsは、Ethereumを基準の決済レイヤーとして見なすようになり、主要なインフラではなくなりつつあります。これは大きな方向転換です。

Vitalik自身も、EVMの置き換えに関してはまだ広範な合意が得られていないと認めています。状態木の改革は、すでに具体的な計画があるEIP-7864によって進んでいますが、EVMをRISC-Vに置き換えるのは、まだ戦略的な計画段階で、コードに組み込まれていません。

最近彼が述べたことに私も驚きました：EthereumはすでにThe Mergeでジェットエンジンを空中で交換したし、あと4回くらいはできるだろうと。状態木、簡素化されたコンセンサス、ZK-EVMの検証、仮想マシンの置き換え。これは野心的です。

本当の問題は：これは熟慮された改修なのか、それとも穴だらけの拡大し続ける空洞なのか？今のところはわかりません。でも一つ確かなことは、Ethereumは古いシステムに修理を施すだけのものにはなりたくないということです。修理を外す方法と、新しいモデルをどう構築するか、その議論自体が最終的な答えよりも価値があるかもしれません。