出典: ヴィタリック・ブテリン
4月20日、ヴィタリック・ブテリン氏は、イーサリアムマジシャンズプラットフォーム上で、イーサリアムの長期的なL1実行レイヤーに関する重要な提案を発表しました。彼は、既存のEVM（イーサリアム仮想マシン）を置き換えてRISC-Vアーキテクチャを採用し、スマートコントラクトを記述する仮想マシン言語とすることを提案し、イーサリアム実行層の動作効率を根本的に向上させ、現在の大きな拡張ボトルネックの1つを打破し、実行層の簡素化を大幅に図ることを目指しました。
Foresight News は、読者がこの技術的ビジョンを理解できるように、提案の全文をまとめました。以下は当初の提案をまとめたものです。
この記事では、コンセンサス レイヤーの Beam Chain 計画に劣らず野心的な、イーサリアムの実行レイヤーの将来に関する革新的なアイデアを提案します。この提案は、イーサリアムの実行層の効率を大幅に改善し、スケーリングの主要なボトルネックの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 を通じてさらに多くの問題が解決されるでしょう。長期的には、イーサリアム L1 拡張の主な制限要因は次のようになります。
- データ可用性のサンプリングと履歴保存プロトコルの安定性
- 競争力のあるブロック生産市場を維持する必要性
- 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 ハッシュ/秒)。ポセイドン以外にも選択肢はたくさんあります。一般に、これらのコンポーネントには最適化の余地がまだたくさんあります。さらに、 bloom を削除することで accrue_logs_bloom を削除できます。
残りの block_executions は、現在の証明サイクルの約半分を占めます。全体的な証明効率を 100 倍向上させるには、EVM 証明効率を少なくとも 50 倍に増やす必要があります。 1 つの解決策は、EVM のより効率的な証明実装を作成することです。もう 1 つの解決策は、現在の ZK-EVM 証明器が実際に EVM を RISC-V にコンパイルして証明し、スマート コントラクト開発者が RISC-V 仮想マシンに直接アクセスできるようにすることです。
いくつかのデータによれば、場合によっては効率の改善が 100 倍を超えることもあります。
実際のアプリケーションでは、残りの証明時間は主に現在のプリコンパイル操作によって占有される可能性があります。 RISC-V をメインの仮想マシンとして使用すると、ガススケジュールは実際の証明時間を反映し、経済的な圧力により開発者はコストの高いプリコンパイルの使用を減らすようになります。それでも、利益はそれほど劇的なものにはならないだろうが、かなりのものになると信じる理由は十分にある。
（通常の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 のコンセンサス レイヤーを大幅に簡素化することを約束しており、この根本的な変更は、実行レイヤーで同様の改善を達成するための唯一の実行可能な道筋となる可能性があります。
全てのコメント