Vitalikの長期的なL1実行層提案：EVMをRISC-Vに置き換える
原題: 長期的な L1 実行レイヤーの提案: EVM を RISC-V に置き換える
原文ソース: Vitalik Buterin
原文翻訳: KarenZ、Foresight News
4 月 20 日、Vitalik Buterin 氏は、Ethereum Magicians プラットフォーム上で、Ethereum の長期的な L1 実行レイヤーに関する重要な提案を発表しました。彼は、既存のEVM（イーサリアム仮想マシン）を置き換えてRISC-Vアーキテクチャを採用し、スマートコントラクトを記述する仮想マシン言語とすることを提案し、イーサリアム実行層の動作効率を根本的に向上させ、現在の大きな拡張ボトルネックの1つを打破し、実行層の簡素化を大幅に図ることを目指しました。
Foresight News は、読者がこの技術的概念を理解できるように、提案の全文をまとめました。以下は元の提案をまとめたものです:
この論文は、イーサリアムの実行層の将来について、コンセンサス層に対するビームチェーン計画に劣らず野心的な、革新的なアイデアを提案しています。この提案は、イーサリアムの実行層の効率を大幅に改善し、スケーリングの主要なボトルネックの1つに対処し、実行層を大幅に簡素化することを目的としており、実際、この目標を達成する唯一の方法である可能性があります。
コアコンセプト: スマート コントラクトを記述するための仮想マシン言語として EVM の代わりに RISC-V を使用します。
重要な注意:
· アカウント システム、クロス コントラクト呼び出し、ストレージなどの概念は完全に保持されます。これらの抽象化はうまく機能し、開発者はそれに慣れています。 SLOAD、SSTORE、BALANCE、CALL などのオペコードは RISC-V システムコールに変換されます。
· このモードでは、スマート コントラクトを Rust で記述できますが、ほとんどの開発者は、新しいバックエンドとして RISC-V に適応される Solidity (または Vyper) でコントラクトを記述し続けると予想されます。 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 つのステップは、deserialize_inputs、initialize_witness_db、state_root_computation、block_execution です。
このうち、initialize_witness_db と state_root_computation は状態ツリーに関連しており、deserialize_inputs はブロックおよび監視データを内部表現に変換するプロセスを含んでいます。実際、50% 以上が監視データのサイズに比例しています。
これらの部分は、現在の keccak 16 進 Merkle パトリシア ツリーを、簡単に証明できるハッシュ関数を使用するバイナリ ツリーに置き換えることで大幅に最適化できます。 Poseidon を使用すると、ラップトップで 1 秒あたり 200 万ハッシュを証明できます (keccak の場合は約 15,000 ハッシュ/秒)。ポセイドン以外にも選択肢はたくさんあります。一般に、これらのコンポーネントには最適化の余地がまだたくさんあります。さらに、ブルームを削除することで accrue_logs_bloom を排除できます。
残りの block_execution は、現在の証明サイクルの約半分を占めます。全体的な証明効率を 100 倍向上させるには、EVM 証明効率を少なくとも 50 倍に増やす必要があります。 1 つの解決策は、EVM のより効率的な証明実装を作成することです。もう 1 つの解決策は、現在の ZK-EVM 証明器が実際に EVM を RISC-V にコンパイルして証明を実行し、スマート コントラクト開発者が RISC-V 仮想マシンに直接アクセスできるようにすることです。
一部のデータでは、特定のケースで効率の向上が 100 倍を超える可能性があることが示されています。
実際のアプリケーションでは、残りの証明時間は主に現在のプリコンパイル操作によって占有される可能性があります。 RISC-V をメインの仮想マシンとして使用すると、Gas スケジュールは実際の証明時間を反映し、経済的な圧力により開発者はコストの高いプリコンパイルの使用を減らすようになります。それでも、利益はそれほど劇的ではないだろうが、相当な利益が得られると信じる十分な理由がある。
(通常の EVM 実行では、「EVM 操作」と「その他の操作」に費やされる時間も 50/50 に近いため、EVM を「中間層」として削除すると、同様に大きなメリットが得られると直感的に考えます)
実装の詳細
この提案は、複数の方法で実装できます。最も混乱の少ないソリューションは、両方の仮想マシンを同時にサポートし、どちらでも契約を記述できるようにすることです。どちらのタイプのコントラクトも同じ機能にアクセスできます（永続ストレージ（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 も候補)。
2 番目と 3 番目のオプションの主な利点は、実行層の仕様を大幅に簡素化できることです。 SELFDESTRUCT を削除するなどの段階的な簡素化でさえ難しいことを考えると、このアプローチが唯一実行可能な簡素化パスである可能性があります。 Tinygrad は「コード行数は 10,000 行以内」という厳格なルールに従っており、最適なブロックチェーン基盤レイヤーはこの制限を簡単に満たし、さらに合理化できるはずです。 Beam Chain プロジェクトは、Ethereum のコンセンサス レイヤーを大幅に簡素化することを約束しており、この根本的な変更は、実行レイヤーで同様の改善を達成するための唯一の実行可能な道筋となる可能性があります。
BlockBeats の公式コミュニティに参加しよう：
Telegram 公式チャンネル：https://t.me/theblockbeats
Telegram 交流グループ：https://t.me/BlockBeats_App
Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia
