Vitalikが提唱する長期的なL1実行層の提案全文：EVMに代わるRISC-V
TechFlow厳選深潮セレクト
Vitalikが提唱する長期的なL1実行層の提案全文：EVMに代わるRISC-V
目標は、実行層の効率性と簡潔性を大幅に向上させるとともに、拡張性のボトルネックを突破することです。
Web3業界の深掘り報道に専念し潮流を洞察翻訳：KarenZ、Foresight News
4月20日、Vitalik ButerinはEthereum Magiciansプラットフォームにて、イーサリアムの長期的なL1実行層に関する重要な提案を行いました。彼は、現在のEVM（イーサリアム仮想マシン）に代わってRISC-Vアーキテクチャを採用し、スマートコントラクト記述用の仮想マシン言語とすることを提唱しています。これにより、実行層の動作効率を根本的に向上させ、現在の主要なスケーリングボトルネックの一つを突破するとともに、実行層の簡潔性を大幅に高めることを目指しています。
Foresight Newsはこの提案の全文を翻訳し、読者がこの技術的構想を理解できるように支援します。以下は提案原文の翻訳内容です：
本稿では、コンセンサス層のBeam Chain計画と同等の野心を持つ、イーサリアム実行層の未来に関する大胆なアイデアを提示します。この提案は、イーサリアム実行層の効率を大幅に高め、主要なスケーリング課題の一つを解決し、実行層の簡素化を著しく進めるものであり、実際上、それが達成可能な唯一の道である可能性すらあります。
核心的な構想：スマートコントラクト記述用の仮想マシン言語として、EVMの代わりにRISC-Vを採用する。
重要な補足事項：
-
アカウントモデル、コントラクト間呼び出し、ストレージなどの概念は完全に維持される。これらの抽象化はうまく機能しており、開発者にとっても使い慣れたものである。SLOAD、SSTORE、BALANCE、CALLなどのオペコードは、RISC-Vのシステムコールとして再定義される。
-
この方式では、スマートコントラクトはRustで記述可能となるが、筆者は多くの開発者が引き続きSolidityまたはVyperを使用してコントラクトを開発すると予測している。これらの言語は、RISC-V向けの新しいバックエンドとして対応されるだろう。なぜなら、Rustで書かれたスマートコントラクトは実際のところ可読性が低く、一方でSolidityやVyperはより明確で読みやすいからである。開発体験への影響はほとんどなく、開発者が変更に気づかない可能性すらある。
-
従来のEVMコントラクトは引き続き実行可能であり、新たなRISC-Vコントラクトとは完全に双方向互換性を持つ。その実現方法にはいくつかの選択肢があり、後ほど詳述する。
Nervos CKB VMはすでに先駆的な例であり、実質的にはRISC-Vの実装である。
なぜこのような措置が必要なのか？
短期的には、ブロック単位のアクセスリスト、遅延実行、分散型履歴ストレージ、およびEIP-4444といった近々導入予定のEIPにより、イーサリアムL1の主なスケーリング課題は解決されつつある。中期的には、ステートレス性とZK-EVMによってさらに多くの問題が解消される見込みだ。長期的には、イーサリアムL1のスケーリングにおける主な制約要因は以下の3点になると考えられる：
-
データ可用性サンプリングおよび履歴ストレージプロトコルの安定性
-
ブロック生成の競争性を維持する必要性
-
ZK-EVMの証明能力
ここで主張したいのは、ZK-EVMの代わりにRISC-Vを採用することで、（2）と（3）のキーボトルネックを解決できるという点である。
下表は、Succinct ZK-EVMがEVM実行層の各処理段階において必要なサイクル数を示したものである：
図解：主な時間消費箇所は、deserialize_inputs、initialize_witness_db、state_root_computation、block_executionの4つ
このうち、initialize_witness_dbとstate_root_computationは状態ツリーに関連しており、deserialize_inputsはブロックおよびワitnessデータを内部表現に変換するプロセスを指す。実際には、ワitnessデータのサイズに比例して50％以上が占められている。
現在のkeccak 16分木Merkle Patricia Treeを、証明に適したハッシュ関数を用いた二分木に置き換えることで、これらは大きく最適化可能である。Poseidonを使用すれば、ノートパソコン上で毎秒200万回のハッシュ証明が可能になる（一方、keccakは約15,000 hash/sec）。Poseidon以外にも多くの代替手段がある。全体として、これらのコンポーネントには大きな最適化余地がある。また、bloomフィルタの削除により、accrue_logs_bloomも排除できる。
残る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という「中間層」を取り除くことで同程度の顕著な改善が得られると直感的に考えられる）
実装の詳細
この提案には複数の実装方法がある。最も破壊的でない方法は、両方の仮想マシンを同時にサポートし、コントラクトがどちらかを選んで記述できるようにするというものだ。両タイプのコントラクトは同じ機能にアクセスできる：永続的ストレージ（SLOAD/SSTORE）、ETH残高の保持、呼び出しの送受信など。EVMコントラクトとRISC-Vコントラクトは相互に呼び合い可能である。RISC-V側から見れば、EVMコントラクトの呼び出しは特殊な引数を持つシステムコールの実行に相当し、EVMコントラクトがメッセージを受信すれば、それはCALLとして解釈される。
より革新的なプロトコルレベルのアプローチとしては、既存のEVMコントラクトを、RISC-Vで書かれたEVMインタプリタコントラクトを呼び出す形に変換する方法がある。つまり、EVMコントラクトがコードCを持っている場合、EVMインタプリタがアドレスXにあるならば、そのコントラクトはトップレベルのロジックに置き換えられ、外部から引数Dで呼び出されたとき、(C, D)を引数としてXを呼び出し、返値を待って転送する。もしEVMインタプリタ自体がそのコントラクトを呼び出してCALLやSLOAD/SSTOREの実行を要求すれば、そのコントラクトはそれらの操作を実行する。
折衷案としては、上記の第二の方法を採用しつつ、「仮想マシンインタプリタ」という概念をプロトコルレベルで明示的にサポートし、そのロジックはRISC-Vで記述することを要請するというものだ。EVMが最初のインスタンスとなり、今後他の言語（Moveなどが候補）もサポート可能となる。
第二および第三のアプローチの主な利点は、実行層の仕様を極めて簡素化できる点にある。SELFDESTRUCTの削除のような漸進的簡素化でさえ非常に困難であることを考えると、このようなアプローチこそが唯一の現実的な簡素化の道である可能性がある。Tinygradは「コード行数1万行以内」という厳格な制約を守っているが、最適なブロックチェーン基盤はこれを容易に満たすべきであり、さらに簡素化されるべきである。Beam Chain計画はイーサリアムのコンセンサス層を大幅に簡素化する可能性を持っているが、実行層でも同様の進歩を遂げるためには、こうした急進的な変革が唯一の実現可能な道であるかもしれない。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@VitalikButerin
