Vitalikの長期L1実行レイヤー提案全文：EVMの代わりにRISC-Vを使用する

原題：『長期L1実行レイヤー提案：EVMをRISC-Vに置き換える』

著者：Vitalik Buterin

編訳：KarenZ，Foresight News

4月20日、Vitalik ButerinはEthereum MagiciansプラットフォームでEthereumの長期L1実行レイヤーに関する重要な提案を行いました。彼は、既存のEVM（Ethereum仮想マシン）をスマートコントラクトの記述に使用する仮想マシン言語としてRISC-Vアーキテクチャに置き換えることを提案し、Ethereum実行レイヤーの運用効率を根本的に向上させ、現在の主要な拡張ボトルネックの一つを突破し、実行レイヤーの簡潔性を大幅に簡素化することを目指しています。

Foresight Newsはこの提案の全文を編纂し、読者がこの技術的な構想を理解する手助けをすることを目的としています。以下は提案原文の編纂内容です：

この記事は、Ethereum実行レイヤーの未来に関する過激なアイデアを提案しており、その野心はコンセンサスレイヤーのBeam Chain計画に匹敵します。この提案は、Ethereum実行レイヤーの効率を大幅に向上させ、主要な拡張ボトルネックの一つを解決し、実行レイヤーを大幅に簡素化することを目的としています。実際、これはこの目標を達成する唯一の方法かもしれません。

核心構想：RISC-VをEVMに置き換え、スマートコントラクト記述の仮想マシン言語とする。

重要な注意事項：

• アカウントシステム、コントラクト間呼び出し、ストレージなどの概念は完全に保持されます。これらの抽象設計はうまく機能しており、開発者は使用に慣れています。SLOAD、SSTORE、BALANCE、CALLなどのオペコードはRISC-Vのシステムコールに変換されます。
• このモデルでは、スマートコントラクトはRustで記述できますが、私はほとんどの開発者が引き続きSolidity（またはVyper）を使用してコントラクトを記述することを予想しています。これらの言語はRISC-Vを新しいバックエンドとして適応させます。Rustで記述されたスマートコントラクトは実際には可読性が低く、SolidityとVyperの方が明確で読みやすいです。開発体験はほとんど影響を受けず、開発者は変化に気づかないかもしれません。
• 旧版EVMコントラクトは引き続き動作し、新版RISC-Vコントラクトと完全に双方向互換性があります。実現方法はいくつかあり、この記事の後半で詳しく探討します。

Nervos CKB VMは先例を開創しており、その本質はRISC-Vの実装です。

なぜこれを行うのか？

短期的には、実施予定のEIP（例えば、ブロックレベルアクセスリスト、遅延実行、分散履歴ストレージおよびEIP-4444）がEthereum L1の主要な拡張ボトルネックを解決します。中期的には、無状態性とZK-EVMを通じてさらに多くの問題を解決します。長期的には、Ethereum L1拡張の主要な制約要因は次のようになります：

1. データ可用性サンプリングと履歴ストレージプロトコルの安定性
2. ブロック生成市場の競争性を維持する必要
3. ZK-EVMの証明能力

私は、ZK-EVMをRISC-Vに置き換えることで（2）と（3）の重要なボトルネックを解決できると論じます。

以下の表は、Succinct ZK-EVMがEVM実行レイヤーの各段階を証明するのに必要なサイクル数を示しています：

図表の説明：4つの主要な時間を要する段階はdeserializeinputs、initializewitnessdb、staterootcomputation、blockexecutionです

ここで、initializewitnessdbとstaterootcomputationは状態ツリーに関連し、deserialize_inputsはブロックと証拠データを内部表現に変換するプロセスに関与します------実際には50％以上が証拠データのサイズに比例します。

現在のkeccak 16-ary Merkle patricia treeを、証明が容易なハッシュ関数を使用したバイナリツリーに置き換えることで、これらの部分は大幅に最適化できます。Poseidonを使用すれば、ノートパソコン上で毎秒200万回のハッシュを証明できる可能性があります（対照的に、keccakは約15,000 hash/secです）。Poseidon以外にも多くの選択肢があります。全体として、これらのコンポーネントには大きな最適化の余地があります。さらに、bloomを削除することでaccruelogsbloomを排除できます。

残りのblock_executionは現在の証明サイクル（prover cycles）の約半分を占めています。全体の証明効率を100倍向上させるためには、EVMの証明効率を少なくとも50倍向上させる必要があります。解決策の一つは、EVMのためにより効率的な証明実装を作成することです。もう一つの解決策は、現在のZK-EVM証明器が実際にはEVMをRISC-Vにコンパイルして証明を行っていることに注目し、スマートコントラクト開発者がそのRISC-V仮想マシンに直接アクセスできるようにすることです。

一部のデータは、特定の状況下で効率が100倍を超える可能性があることを示しています：

実際のアプリケーションでは、残りのprover時間は主に現在のプレコンパイル（precompiles）操作によって占められる可能性があります。RISC-Vを主仮想マシンとして使用する場合、Gasスケジュールは実際の証明時間を反映し、経済的圧力が開発者に高コストのプレコンパイルの使用を減少させるよう促します。それでも、増益はそれほど顕著ではないかもしれませんが、これらの増益が非常に大きいと信じる十分な理由があります。

（注目すべきは、通常のEVM実行において「EVM操作」と「その他の操作」の時間占有率もほぼ50/50に近いため、EVMを「中間層」として削除することが同等の顕著な増益をもたらすと直感的に考えられます）

実施の詳細

この提案にはさまざまな実現方法があります。破壊的影響が最小限のアプローチは、2つの仮想マシンを同時にサポートし、コントラクトが任意のものを選択して記述できるようにすることです。2種類のコントラクトは同じ機能にアクセスできます：永続ストレージ（SLOAD/SSTORE）、ETH残高を保持する能力、呼び出しの発起/受信など。EVMとRISC-Vコントラクトは相互に呼び出すことができ、RISC-Vの視点から見ると、EVMコントラクトを呼び出すことは特別なパラメータを持つシステムコールを実行することに相当します。一方、メッセージを受信するEVMコントラクトはそれをCALLとして解釈します。

プロトコルの観点からより過激なアプローチは、既存のEVMコントラクトをRISC-Vで記述されたEVMインタープリタコントラクトを呼び出すように変換し、既存のEVMコードを実行することです。つまり、EVMコントラクトにコードCがあり、EVMインタープリタがアドレスXにある場合、そのコントラクトはトップレベルのロジックに置き換えられ、外部から呼び出しパラメータDで呼び出されると、Xを呼び出し(C, D)を渡し、戻り値を待って転送します。もしEVMインタープリタがそのコントラクトを呼び出し、CALLやSLOAD/SSTOREを実行するよう要求する場合、コントラクトはこれらの操作を実行します。

折衷案は、2番目のアプローチを採用しつつ、プロトコルで「仮想マシンインタープリタ」の概念を明確にサポートし、そのロジックをRISC-Vで記述することを要求することです。EVMは最初のインスタンスとなり、将来的には他の言語（Moveが候補かもしれません）もサポートされる可能性があります。

第二および第三のアプローチの核心的な利点は、それらが実行レイヤーの仕様を大幅に簡素化できることです。SELFDESTRUCTのような漸進的な簡素化を取り除くことさえも困難であることを考えると、この考え方は唯一の実行可能な簡素化の道かもしれません。Tinygradは「コードは1万行を超えない」という厳格な規定に従っており、最適なブロックチェーンの基盤はこの制限を容易に満たし、さらに簡素化できるべきです。Beam Chain計画はEthereumのコンセンサスレイヤーを大幅に簡素化することが期待されており、実行レイヤーが同様の向上を実現するためには、このような過激な変革が唯一の実行可能な道かもしれません。