イーサリアムの未来はRISC-VアーキテクチャをEVMの代わりに採用する可能性がある

イーサリアムの共同創設者が最近コミュニティフォーラムで長期的な提案を行い、現在の実行層仮想マシン(EVM)をオープンソースのRISC-V命令セットアーキテクチャに置き換えることを提案しました。彼はこの構想をコンセンサス層のBeam Chainに例え、これが実行層の性能突破とプロトコルロジックの簡素化を実現する唯一の実行可能な道であると考えています。特に零知識証明(ZK Proof)の効率に関しては、EVMを置き換えることで最大100倍の最適化が実現されると予想されています。この提案は、イーサリアムが現在直面しているZK証明の効率、ブロック構築の複雑性、データの可用性などのボトルネック問題を解決することを目指しています。

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

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

EVMに存在する主な問題は次のとおりです:

1. アーキテクチャが古い：256ビットのスタック型構造を使用しており、現代のCPUと互換性がないため、ZK-EVMの実行効率が低下しています。
2. ZK証明のボトルネック：約半分のリソースがEVM自体の実行に使用されており、ZK証明の効率が制限されています。
3. メンテナンス性が悪い：長年の機能の蓄積により規格が混乱し、特定の機能を廃止することが難しい。
4. 開発制限：非標準命令セットがクロス言語サポートを制限し、主流言語を効率的にEVMバイトコードにコンパイルすることが難しい。

対照的に、RISC-Vには以下の利点があります：

1. 高効率な性能：実際のCPUの簡素化された命令セットであり、ハードウェアに優しく、JIT最適化やハードウェアアクセラレーションに使用できます。
2. ZK最適化：ZK証明においてRISC-V命令に直接回路を生成することは、EVM操作の証明よりも簡単です。
3. ツールチェーンの成熟：Rust/C/C++などの主流言語をサポートし、開発のハードルを下げ、エコシステムをより広範囲にします。
4. 一般標準：既存のブロックチェーンプロジェクトで採用されており、成功事例があります。

置き換えパスと課題

三つの代替案が提案されました：

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

実施に直面する技術的課題には、

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

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

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

• レイヤー2：ロールアップは依然としてイーサリアムのスケーリングの主力であり、RISC-VはL1の処理効率とZK検証性能を向上させるが、スループットを直接拡張するものではない。
• データシェーディングとEIP-4844：データの可用性ボトルネックは依然としてEIP-4844とDankshardingによって解決される必要があり、RISC-Vはオンチェーンデータ容量に影響を与えません。
• FaaS、MEV：仮想マシンアーキテクチャとは無関係であり、RISC-Vの推進によって無効になることはありません。

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

コミュニティはこの提案に対して意見が分かれています：

• 支持者は、これはパフォーマンスの課題に対処するための必要な戦略的アップグレードであり、従来の開発者を引き付けるのに役立つと考えています。
• 保守派は、実施の難易度、歴史的な負担、エコツールチェーンの更新コストが大きいことを懸念し、リソースの投入対効果に疑問を呈しています。

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

• Move VM（Aptos/Sui）：新しいリソース指向のVMで、言語の安全性が高いですが、EVMとは互換性がありません。
• FuelVM：並行処理のために設計された新しいVMで、言語Swayを搭載し、互換性は限られています。
• WASM（Stylus）：L2でWASMを契約言語として導入し、現在は特定のL2で実装されており、実現可能性があります。
• あるパブリックチェーン：メインネットでRISC-Vを契約VMの前例として使用し、イーサリアムに実践的な参考を提供する。

将来の影響の見通し

もしイーサリアムがRISC-Vに切り替わると、以下の影響が考えられます：

1.開発者の経験:

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

2. 運用コストとパフォーマンス：

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

3. エコシステムの互換性と発展：

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

4. セキュリティと安定性:

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

この提案は、イーサリアムが未来の性能限界とプロトコルの簡潔さについて深く考察した結果を示しています。実施には数年にわたるプロセスが予想され、技術、コミュニティ、エコシステムの多くの課題を乗り越える必要があります。これは既存の路線を覆すものではなく、基盤を強化し、未来に備えるものです。これは未来への賭けとも見なされ、"基盤は再構築する価値があるのか"についての深い探求でもあります。