執筆者: グレイ・ロブスター、Deep Tide TechFlow

Ethereum 開発者には暗黙の習慣があり、可能であれば EVM に触れないようにします。

過去数年間、ブロックチェーン上で新たな暗号化操作が必要になるたびに、開発者の最初の反応はそれを EVM に実装することではなく、「コンパイル済みコントラクト」の追加を要求することでした。これは、仮想マシンをバイパスしてプロトコル層で直接ハードコードされるショートカットです。

3月1日、Vitalik Buterin氏がXに長文の投稿を投稿し、事態は一気に動き出しました。彼の主張は、「イーサリアムの真髄はその汎用性にある。EVMが不十分なら、真正面から問題に取り組み、より優れた仮想マシンを構築すべきだ」というものでした。

彼は2本の特別な手術用メスを提供しました。

最初のステップ：「データ構造」を変更する

最初の変更は、イーサリアムの状態ツリーを対象としています。これはイーサリアムの「台帳インデックスシステム」のようなもので、残高を確認したりトランザクションを検証したりするには、ツリーを辿って移動する必要があります。

問題は、現状のツリーが「太りすぎ」であることです。Ethereumは「ヘキサフォーク型ケチャック・メルケル・パトリシアツリー」（名前が呪文のように聞こえます）と呼ばれる構造を採用しています。VitalikのEIP-7864では、これをよりシンプルなバイナリツリーに置き換えることが提案されています。

例えば、以前はデータのクエリを実行するために、六角形の交差点で何度も方向を選択する必要がありましたが、今では左と右を選択するだけで済みます。その結果、メルケル枝の長さは元の4分の1に短縮されました。軽量クライアントの場合、データ検証に必要な帯域幅が大幅に削減されます。

しかし、ヴィタリックは木の形を変えるだけでは満足しませんでした。彼は「葉のフォント」、つまりハッシュ関数も変えたいと考えていました。解決策として、Blake3とPoseidonという2つの候補がありました。Blake3は安定した高速化をもたらす可能性があり、Poseidonはより革新的で、理論的には証明効率を数十倍向上させることができましたが、セキュリティには依然としてさらなる監査が必要でした。

このスキームは、コミュニティで長年議論されてきたVerkle Treesに取って代わるものであることは注目に値します。Verkleはかつて2026年のハードフォークで推奨されていたスキームでしたが、楕円曲線暗号が量子コンピューティングの脅威にさらされているため、2024年半ばから徐々に人気が薄れ、二分木スキームが主流となりました。

2 番目のステップ: 「仮想マシン」を変更して、EVM をスマート コントラクトに変換します。

2 番目の変更はより大胆で、より物議を醸すものでした。それは、EVM を長期的に RISC-V アーキテクチャに置き換えることです。

RISC-Vはオープンソースの命令セットで、元々はブロックチェーンとは全く関係がなかったのですが、現在ではほぼすべてのZK証明システムの内部で使用されています。Vitalikの論理は単純明快です。証明者が既にRISC-Vで処理しているのであれば、仮想マシンが別の言語で処理し、さらに間に翻訳層を追加する必要があるでしょうか？翻訳層をなくすことで、効率は自然に向上します。

RISC-Vインタープリタは数百行のコードしか必要としません。Vitalik氏は、ブロックチェーン仮想マシンはこうあるべきだと述べています。

彼は 3 段階のアプローチを計画しました。まず、新しい仮想マシンでコンパイル済みコントラクトを実行し、既存のコンパイル済みコントラクトの 80% を新しい VM コードで書き換えます。次に、開発者が新しい仮想マシンにコントラクトを直接デプロイし、EVM と並行して実行できるようにします。最後に、EVM は廃止されますが、消滅するわけではなく、新しい仮想マシンで実行されるスマート コントラクトとして書き換えられ、完全な下位互換性が実現されます。

既存の車のオーナーは、車を買い替える必要はありません。エンジンだけが静かに交換され、ステアリングホイールはそのままです。

これら2つを組み合わせるとどれほど重要なのでしょうか？Vitalikは数値を示しました。状態ツリーと仮想マシンを合わせると、Ethereumの証明ボトルネックの80%以上を占めています。言い換えれば、これら2つの要素に対処しなければ、ZK時代におけるEthereumのスケーリングは停滞してしまうでしょう。

Arbitrum はこれに反対します。倉庫でフォークリフトが使用されているからといって、配送ドライバーにフォークリフトの運転を強制することはできません。

しかし、これは誰もが同意する話ではありません。

Arbitrum はこれに反対します。倉庫でフォークリフトが使用されているからといって、配送ドライバーにフォークリフトの運転を強制することはできません。

しかし、これは誰もが同意する話ではありません。

昨年11月、Arbitrumの中核開発チームであるOffchain Labsは、詳細な技術的反論を発表しました。4人の研究者の主張の中心は、RISC-Vは確かにZK証明には適しているものの、契約の「配信フォーマット」には適していないというものでした。

彼らは重要な違いを指摘しました。それは、「配送指示書セット」（dISA）と「証明指示書セット」（pISA）は必ずしも同じである必要はないということです。倉庫ではフォークリフトを使うと最も効率的ですが、だからといって配達員も商品を玄関先まで配達する際にフォークリフトを使う必要があるわけではありません。

Offchain Labsは、コントラクト層にWebAssembly（WASM）を使用することを提唱していますが、その理由は非常に確固たるものです。WASMは標準ハードウェアで非常に効率的ですが、ほとんどのEthereumノードはRISC-Vチップを実行せず、強制的な切り替えにはエミュレーターが必要になります。WASMには成熟したタイプのセキュリティ検証メカニズムがあり、WASMのツールチェーンエコシステムは実際に数十億の実行環境でテストされています。

さらに重要なのは、彼らがただ口先だけで言っているわけではないということです。Offchain LabsはすでにArbitrum上でプロトタイプを動作させています。WASMをコントラクト配信フォーマットとして使い、それをRISC-VにコンパイルしてZK証明を実現しています。2つのレイヤーは互いに干渉することなく、それぞれ独自の処理を実行します。

彼らはまた、考えさせられるリスクも提起しました。ZK証明分野の技術は急速に変化しており、RISC-V実装は最近32ビットから64ビットに移行しました。もし今RISC-VがイーサリアムのL1に実装されているとして、2年後にもっと優れた証明アーキテクチャが登場したらどうなるでしょうか？急速に動く的を狙うのは、イーサリアムのスタイルではありません。

より大きな文脈: レベル 2 の化学者は、外部ケアへの依存から「離脱」し始めています。

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

わずか1か月前、ヴィタリック氏はイーサリアムに「専用のL2ロードマップ」がまだ必要かどうか公に疑問を呈し、L2陣営からの反発を引き起こしました。Espresso SystemsのCEO、ベン・フィッシュ氏はCoinDeskに対し、次のように的確に述べています。「ヴィタリック氏の指摘は、L2の当初の目的はイーサリアムのスケールアップを支援することだったが、イーサリアム自体の高速化が求められるようになった今、L2の役割は当然ながら変化する必要があるということです。」

興味深いことに、L2ブロックチェーンはパニックに陥るどころか、積極的に「脱イーサリアム化」を進め始めています。OP Labsの共同創設者であるJing Wang氏は、L2を独立したウェブサイトに例え、イーサリアムは基盤となるオープンな決済標準だと説明しました。PolygonのCEOであるMarc Boiron氏は、より率直にこう述べています。「真の課題はスケーリングではなく、決済のような現実世界のシナリオに適した独自のブロック空間を構築することです。」

言い換えれば、ヴィタリック氏による実行レイヤーの大幅な見直しは、より大きなトレンドに対する技術的な脚注に過ぎない。イーサリアムはコア機能に対する制御を取り戻しつつあり、一方でL2レイヤーは強制的に独立した存在の理由を見つけつつある、というより、ようやく独自の存在理由を見つけつつあるのだ。

これは実現可能でしょうか?

Vitalik氏自身も、仮想マシンの置き換えに関して開発者コミュニティに幅広いコンセンサスが得られていないことを認めています。状態ツリーの改革はより成熟しており、EIP-7864にはすでに具体的な草案と実装チームが存在します。しかし、RISC-VがEVMを置き換えることになるのでしょうか？これはまだ「ロードマップ」の段階であり、コードとして記述されるには程遠い状況です。

しかし、先週、ヴィタリックは印象的な発言をしました。イーサリアムはすでに飛行中にジェットエンジンを1回変更しており（マージに言及）、今後さらに4回ほど変更する可能性があります（ステートツリー、簡素化されたコンセンサス、ZK-EVM検証、仮想マシンの置き換え）。

イーサリアム・グラムスターダム・アップグレードは2026年前半に開始される予定で、その後にヘゴタ・アップグレードが続く。2つのハードフォークの詳細は未定だが、ステートツリーの改革と実行レイヤーの最適化が主要なテーマとなる。

イーサリアムの歴史は、「できるかどうか」を巡るものではありません。PoWからPoSへ、L1オールインからロールアップハブへ。高度1万メートルで自らのエンジンを解体する能力と勇気があることを証明してきました。

今回の工事は、新しい機能を追加するのではなく、古い基礎を掘り起こし、コンクリートを流し込むという、より奥深い作業を伴う。これは綿密に計画された改修なのか、それともますます複雑化する底なし沼なのか。おそらく2027年には明らかになるだろう。

しかし、少なくとも一つ確かなことは、イーサリアムはZK時代において「パッチを当てた古いシステム」になるつもりはないということです。パッチをどのように削除し、どのエンジンに置き換えるかという議論自体が、結論よりも価値があるかもしれません。