イーサリアム実行層の革新：RISC-Vアーキテクチャの前景と課題

イーサリアムの共同創設者が最近コミュニティで提案した先見的な提案は、オープンソースの RISC-V 命令セットアーキテクチャを既存の実行層仮想マシン（EVM）の代わりに使用することです。この構想は実行層の Beam Chain に例えられ、性能のボトルネックを突破し、プロトコルの論理を簡素化することを目的としています。特にゼロ知識証明（ZK Proof）の効率において、最大 100 倍の最適化向上が実現できると予測されています。この提案は、イーサリアムが現在抱えている ZK 証明の効率、ブロック構築の複雑さ、データの可用性などのボトルネック問題を解決することを意図しています。

! V God Radical提案:イーサリアムEVMをRISC-Vに置き換えると、ZKはスケーリングの最終ソリューションですか?

現在のEVMの限界とRISC-Vの利点

EVM の問題:

• 構造が古い：256ビットスタック式構造は現代のCPUと互換性がなく、ZK-EVMの実行効率に影響を与えます。
• ZK証明のボトルネック：ZK-EVMの約半分のリソースがEVM自体の実行に使われており、証明効率を制限しています。
• メンテナンス性が低い：機能の蓄積が規範の混乱を引き起こし、SELFDESTRUCTを廃止することが難しい。
• 開発制限：非標準命令セットが言語間サポートを制限し、主流言語の効率的なコンパイルが難しい。

RISC-Vの利点:

• 高性能：簡素な命令セットはハードウェアに優しく、JIT最適化やハードウェアアクセラレーションに使用可能です。
• ZKの最適化:RISC-V命令から直接回路を生成し、ZKプルーフプロセスを簡素化します。
• ツールチェーンの成熟：主流言語をサポートし、開発のハードルを下げ、エコシステムを拡大します。
• 一般標準：すでにブロックチェーンプロジェクトに採用されており、成功事例があります。

提案は、RISC-V を契約実行アーキテクチャとして直接採用する方が、ZK-EVM で EVM を RISC-V にコンパイルするよりも、根本的に実行効率と拡張可能性を向上させると考えています。

置き換えパスと課題

置き換えの3つのプラン：

1. ダブルVM共存（保守）：EVMとRISC-Vが並行して実行され、移行期間の互換性が確保されます。
2. チェーン上のインタプリタ方案（過激）：すべての EVM コントラクトはチェーン上の RISC-V コントラクトによって解釈実行される。
3. インタープリタープラグインメカニズム（折衷）：インタープリターをプロトコル要素として扱い、将来他のVMを挿入できるようにします。

実装の技術的な課題:

• 実行性能損失リスク：RISC-Vはx86チップ上でシミュレーション実行する必要があり、初期の効率は最適化されたEVMよりも低い可能性があります。
• ガス価格の再構築：RISC-V 命令のために新しいガスモデルを定義する必要があります。
• セキュアサンドボックス設計：システムコールの制限、コードの自己修正の防止、決定論的実行の保証。
• 開発ツールの適合：コンパイラ、デバッガ、安全監査ツールを更新し、RISC-V バイトコードをサポートします。
• 移行の互換性：一部の契約はEVMの特性に依存しており、互換レイヤーまたはフォールバックメカニズムを慎重に設計する必要があります。

提案は、過渡的な道として双VMの共存を採用する傾向があり、新旧の契約の相互運用性を維持することを約束し、開発者の体験が変わらず、ユーザーが気づかないままアップグレードされることを保証します。

既存のスケーリングルートへの影響

RISC-Vは基盤の最適化であり、既存のスケーリングルートを置き換えるものではありません。

• Layer 2：RISC-V は L1 の処理効率と ZK 検証性能を向上させ、Rollup のコストを低くし、データをより迅速に提出するのに役立ちます。
• データシェーディングと EIP-4844：データの可用性のボトルネックは、blob と Danksharding によって解決する必要があります。
• FaaS、MEV：仮想マシンアーキテクチャに依存せず、RISC-Vの進展の影響を受けません。

RISC-Vは"エンジン交換"、L2/シャーディングは"ネットワーク拡張"、両者は次元が異なり、並行して矛盾しません。

コミュニティのフィードバックと関連する試み

コミュニティの意見の相違：

• 支持者：パフォーマンスの課題に対処するための必要なアップグレードであり、従来の開発者を引き付けるのに役立つと考えている。
• 保守派：実施の難しさ、歴史的な負担、エコロジカルツールチェーンの更新コストを懸念し、投入と産出の比率に疑問を呈する。

類似プロジェクトの参考：

• Move VM(Aptos/Sui):強力な言語セキュリティを備えたリソース指向のVMですが、EVMとは互換性がありません。
• FuelVM：並列処理のために設計され、Sway言語と組み合わせて使用しますが、互換性は限られています。
• WASM（Stylus）：L2にWASMを契約言語として導入し、あるプラットフォームで実現されています。
• あるブロックチェーンプロジェクト：メインネットは RISC-V を契約 VM として使用し、イーサリアムに実践的な参考を提供します。

提案は他の選択肢を排除せず、将来的なインタープリタメカニズムはMoveやWASMなどのVMを挿入するために使用でき、多様な実行エコシステムを構築できると考えています。

将来の影響の見通し

###開発者エクスペリエンス:

• Solidity/Vyperなどの言語は引き続き使用可能であり、コンパイラのバックエンドのみが変更されます。
• Rust/Cなどの新しい言語で契約を書くことが可能になるかもしれませんが、移行は強制ではありません。

运行コストと性能：

• 実行効率の向上により、より高いガス上限とより低い手数料がもたらされます。
• RISC-V コントラクトは、プリコンパイルコントラクトへの依存を減らす可能性があり、Gas モデルは ZK プルーフコストにより近くなります。

エコロジーの互換性と発展：

• ダブルVMの共存期間中、既存の契約は持続的に運用され、新しい契約は徐々にRISC-Vを採用します。
• インフラは新しいバイトコード形式をサポートする必要があり、チェーン間の互換性の変動を引き起こす可能性があります。

セキュリティと安定性:

• 新しいアーキテクチャは広範なテストと形式的検証を必要とし、プロトコルの信頼性を向上させる必要があります。
• よりシンプルな実行層は、監査と攻撃面の制御に役立ちます。

まとめ

イーサリアムのコア開発者がEVMの代わりにRISC-Vを使用する提案を行い、未来の性能限界とプロトコルの簡潔さに対する深い考察を反映しています。この提案はまだ初期の議論段階にあり、実施には数年を要するプロセスになると予想され、技術、コミュニティ、生態系の複数の課題を乗り越える必要があります。これは既存のルートを覆すものではなく、基盤を強化し、未来に備えるものです。

提案者が言うように："量的な向上を実現するためには、この過激な変化が唯一の実行可能な道かもしれない。"

これは未来への賭けであり、「基盤は再構築する価値があるのか」という深い探求でもある。