出典：ヴィタリック・ブテリンコンピレーション:KarenZ、Foresight News 4月20日、Vitalik ButerinはEthereum Magiciansプラットフォームで、Ethereumの長期的なL1実行層に関する重要な提案を行いました。彼は、現行のEVM（Ethereum Virtual Machine）に代わってRISC-Vアーキテクチャを採用することを提案し、これはEthereum実行層の運用効率を根本的に向上させ、現在の主要なスケーラビリティのボトルネックの一つを突破することを目指しています。また、実行層の簡潔性を大幅に簡素化することも意図しています。 Foresight Newsはこの提案を全文翻訳し、読者がこの技術的想像を理解できるようにすることを目的としています。以下は提案原文の翻訳内容です： この記事では、イーサリアムの実行層の未来に関する過激なアイデアを提案しています。その野心は、コンセンサス層のビーエムチェーン計画に劣らないものです。この提案は、イーサリアムの実行層の効率を大幅に向上させ、主要なスケーラビリティのボトルネックの1つを解決し、実行層を大幅に簡素化することを目的としています。実際、これはこの目標を達成するための唯一の方法かもしれません。 コアコンセプト：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(ブロックレベルのアクセスリスト、遅延実行、分散履歴ストレージ、EIP-4444など)は、イーサリアムL1の主要なスケーリングボトルネックに対処します。 中期的には、ステートレスとZK-EVMでより多くの問題が解決されるでしょう。 長期的には、イーサリアムのL1スケーリングの主な制限要因は、以下のようになります。 データの可用性サンプリングと履歴ストレージプロトコルの安定性ブロック生産市場の競争力を維持するための需要ZK-EVMの証明 ZK-EVMをRISC-Vに置き換えることで、（2）と（3）の主要なボトルネックを解決できることを証明します。 下表は、Succinct ZK-EVM が EVM 実行レイヤーの各段階に必要なサイクル数を示しています： 図の説明: 時間のかかる 4 つの主な段階は、逆シリアル化\_inputs、初期化\_witness\_db、状態\_root\_computation、およびブロック\です_execution initialize\_witness\_db と state\_root\_computation は状態ツリーに関連しており、deserialize\_inputs はブロックと証人データを内部表現に変換するプロセスに関与しています——実際には 50% 以上が証人データのサイズに比例しています。 これらのセクションは、現在のkeccak 16-ary Merkleパトリシアツリーを、証明しやすいハッシュ関数を使用するバイナリツリーに置き換えることで、大幅に最適化できます。 Poseidonを使用すると、ラップトップで毎秒200万ハッシュを証明できます(比較のために、keccakは約15,000ハッシュ/秒です)。 ポセイドンに加えて、他にも多くのオプションがあります。 全体として、これらのコンポーネントには最適化の余地がたくさんあります。 さらに、ブルームを削除することで、発生\_logs\_bloomを排除できます。 残りの block\_execution は現在の証明周期（prover cycles）の約半分を占めています。全体の証明効率を100倍向上させるには、EVMの証明効率を少なくとも50倍向上させる必要があります。解決策の1つは、EVMのためにより効率的な証明実装を作成すること、もう1つの解決策は、現在のZK-EVM証明器が実際にEVMをRISC-Vにコンパイルして証明を行っており、スマートコントラクト開発者がそのRISC-V仮想マシンに直接アクセスできることに注意することです。 一部のデータは、特定の状況下で効率が100倍以上向上する可能性があることを示しています： 実際には、残りの証明時間は、現在のプリコンパイル操作によってほとんどが占められる可能性があります。 RISC-VをプライマリVMとして使用すると、ガススケジュールは実際のプルーフ時間を反映し、経済的なプレッシャーにより、開発者は高コストのプリコンパイルの使用を減らすようになります。 その場合でも、利益はそれほど大きくありませんが、かなりのものになると信じるに足る十分な理由があります。 （注目すべきは、通常のEVM実行において「EVM操作」と「その他の操作」の時間がほぼ50/50であるため、EVMを「中間層」として削除することが同等の顕著な利益をもたらすと直感的に考えています） 実装の詳細 この提案にはさまざまな実現方法があります。破壊的でない最小のソリューションは、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の実行を要求した場合、コントラクトはこれらの操作を実行します。 妥協案は第二の方案を採用するが、協定を通じて「バーチャルマシンインタプリタ」の概念を明確に支持し、そのロジックをRISC-Vで作成することを要求する。EVMは最初のインスタンスとなり、将来的には他の言語（Moveが候補になる可能性がある）をサポートすることもできる。 第二と第三の選択肢の核心的な利点は、それらが実行層の規範を大幅に簡素化できることです。SELFDESTRUCTのような漸進的な簡素化を除去することさえも困難であることを考慮すると、このアプローチは唯一の実行可能な簡素化の道かもしれません。Tinygradは「コードが1万行を超えない」という厳格な規定に従っており、最適なブロックチェーンの基盤はこの制限を容易に満たし、さらに簡素化するべきです。Beam Chainの計画は、イーサリアムのコンセンサス層を大幅に簡素化することが期待されており、実行層が同様の向上を実現するためには、このような過激な変革が唯一の実行可能な道かもしれません。
Vitalik の長期 L1 エグゼクティブ層提案の全文: EVM を RISC-V に置き換える
出典：ヴィタリック・ブテリン
コンピレーション:KarenZ、Foresight News
4月20日、Vitalik ButerinはEthereum Magiciansプラットフォームで、Ethereumの長期的なL1実行層に関する重要な提案を行いました。彼は、現行のEVM（Ethereum Virtual Machine）に代わってRISC-Vアーキテクチャを採用することを提案し、これはEthereum実行層の運用効率を根本的に向上させ、現在の主要なスケーラビリティのボトルネックの一つを突破することを目指しています。また、実行層の簡潔性を大幅に簡素化することも意図しています。
Foresight Newsはこの提案を全文翻訳し、読者がこの技術的想像を理解できるようにすることを目的としています。以下は提案原文の翻訳内容です：
この記事では、イーサリアムの実行層の未来に関する過激なアイデアを提案しています。その野心は、コンセンサス層のビーエムチェーン計画に劣らないものです。この提案は、イーサリアムの実行層の効率を大幅に向上させ、主要なスケーラビリティのボトルネックの1つを解決し、実行層を大幅に簡素化することを目的としています。実際、これはこの目標を達成するための唯一の方法かもしれません。
コアコンセプト：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(ブロックレベルのアクセスリスト、遅延実行、分散履歴ストレージ、EIP-4444など)は、イーサリアムL1の主要なスケーリングボトルネックに対処します。 中期的には、ステートレスとZK-EVMでより多くの問題が解決されるでしょう。 長期的には、イーサリアムのL1スケーリングの主な制限要因は、以下のようになります。
データの可用性サンプリングと履歴ストレージプロトコルの安定性
ブロック生産市場の競争力を維持するための需要
ZK-EVMの証明
ZK-EVMをRISC-Vに置き換えることで、（2）と（3）の主要なボトルネックを解決できることを証明します。
下表は、Succinct ZK-EVM が EVM 実行レイヤーの各段階に必要なサイクル数を示しています：
図の説明: 時間のかかる 4 つの主な段階は、逆シリアル化_inputs、初期化_witness_db、状態_root_computation、およびブロック\です_execution
initialize_witness_db と state_root_computation は状態ツリーに関連しており、deserialize_inputs はブロックと証人データを内部表現に変換するプロセスに関与しています——実際には 50% 以上が証人データのサイズに比例しています。
これらのセクションは、現在のkeccak 16-ary Merkleパトリシアツリーを、証明しやすいハッシュ関数を使用するバイナリツリーに置き換えることで、大幅に最適化できます。 Poseidonを使用すると、ラップトップで毎秒200万ハッシュを証明できます(比較のために、keccakは約15,000ハッシュ/秒です)。 ポセイドンに加えて、他にも多くのオプションがあります。 全体として、これらのコンポーネントには最適化の余地がたくさんあります。 さらに、ブルームを削除することで、発生_logs_bloomを排除できます。
残りの block_execution は現在の証明周期（prover cycles）の約半分を占めています。全体の証明効率を100倍向上させるには、EVMの証明効率を少なくとも50倍向上させる必要があります。解決策の1つは、EVMのためにより効率的な証明実装を作成すること、もう1つの解決策は、現在のZK-EVM証明器が実際にEVMをRISC-Vにコンパイルして証明を行っており、スマートコントラクト開発者がそのRISC-V仮想マシンに直接アクセスできることに注意することです。
一部のデータは、特定の状況下で効率が100倍以上向上する可能性があることを示しています：
実際には、残りの証明時間は、現在のプリコンパイル操作によってほとんどが占められる可能性があります。 RISC-VをプライマリVMとして使用すると、ガススケジュールは実際のプルーフ時間を反映し、経済的なプレッシャーにより、開発者は高コストのプリコンパイルの使用を減らすようになります。 その場合でも、利益はそれほど大きくありませんが、かなりのものになると信じるに足る十分な理由があります。
（注目すべきは、通常のEVM実行において「EVM操作」と「その他の操作」の時間がほぼ50/50であるため、EVMを「中間層」として削除することが同等の顕著な利益をもたらすと直感的に考えています）
実装の詳細
この提案にはさまざまな実現方法があります。破壊的でない最小のソリューションは、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の実行を要求した場合、コントラクトはこれらの操作を実行します。
妥協案は第二の方案を採用するが、協定を通じて「バーチャルマシンインタプリタ」の概念を明確に支持し、そのロジックをRISC-Vで作成することを要求する。EVMは最初のインスタンスとなり、将来的には他の言語（Moveが候補になる可能性がある）をサポートすることもできる。
第二と第三の選択肢の核心的な利点は、それらが実行層の規範を大幅に簡素化できることです。SELFDESTRUCTのような漸進的な簡素化を除去することさえも困難であることを考慮すると、このアプローチは唯一の実行可能な簡素化の道かもしれません。Tinygradは「コードが1万行を超えない」という厳格な規定に従っており、最適なブロックチェーンの基盤はこの制限を容易に満たし、さらに簡素化するべきです。Beam Chainの計画は、イーサリアムのコンセンサス層を大幅に簡素化することが期待されており、実行層が同様の向上を実現するためには、このような過激な変革が唯一の実行可能な道かもしれません。