ビタリックの過激な構想:RISC-Vを用いてイーサリアムEVMを置き換えるとは、何を意味するのか?

robot
概要作成中

作者 | GaryMa 吴はブロックチェーンについて語る

紹介

イーサリアムの共同創設者であるヴィタリック・ブテリン氏は最近、イーサリアム・マジシャンズ・コミュニティで、現在の実行層仮想マシン(EVM)をオープンソースのRISC-V命令セットアーキテクチャに置き換えるという長期的な提案を行いました。 彼はこのアイデアをコンセンサスレイヤーのビームチェーンと比較し、実行レイヤーでパフォーマンスのブレークスルーを達成し、プロトコルロジックを簡素化するための唯一の潜在的な道であると考えています。 特にゼロ知識証明(ZK証明)の効率に関しては、EVMを置き換えることで最大100倍の最適化向上を達成できると期待しています。 この提案は、ZKプルーフ効率、ブロック構築の複雑さ、データの可用性などの観点から、イーサリアムの現在のボトルネックに対処することを目的としています。

この記事では、この提案の動機、技術的詳細、実施経路と課題を平易な言葉で解析し、既存のイーサリアムのスケーリングルートへの影響を探討し、コミュニティの反応と類似の試みを振り返ります。

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

EVMの問題点:

古いアーキテクチャ:EVMは256ビットのスタック構造を使用しており、現代のCPUと互換性がないため、ZK-EVMを実行する際の効率が低下します。

ZK証明のボトルネック:Succinctによると、ZK-EVMは約半分のリソースをEVM自体の実行に使用しており、ZK証明の効率が制限されています。

維持性が悪い:長年にわたる複雑な機能の蓄積、規範が混乱しており、SELFDESTRUCTを廃止するのが難しい。

開発制限:非標準命令セットが言語間のサポートを制限し、主流言語がEVMバイトコードに効率的にコンパイルされにくい。

RISC-Vの利点:

パフォーマンス効率:RISC-Vは、実際のCPUの縮小命令セットであり、ハードウェアフレンドリーであり、JIT最適化やハードウェアアクセラレーションにも使用できます。

ZK最適化:ZK証明においてRISC-V命令の回路を直接生成することは、EVM操作の証明よりも簡単です。

ツールチェーンが成熟:Rust/C/C++などの主要な言語をサポートし、開発のハードルが低く、エコシステムがより広範です。

汎用標準:すでにNervos CKBなどのブロックチェーンが採用しており、成功事例があります。

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

二、置き換えパスと課題:どのように EVM から移行するか?

置き換えの3つの案:

デュアル VM 並行(最も保守的):EVM と RISC-V が並行して動作し、新しいコントラクトは RISC-V を選択可能で、移行期間の互換性を確保します。

チェーン上エクスプレッサーソリューション(過激):すべてのEVM契約はチェーン上のRISC-V契約によって解釈実行される。

インタープリタプラグインメカニズム(妥協):インタープリタをプロトコル要素として扱い、将来的に他のVM(例:Move)を挿入できるようにします。

実装に対する技術的な課題:

実行性能の損失リスク:RISC-V は x86 チップ上でシミュレーション実行する必要があり、初期の効率は最適化された EVM よりも低い可能性があります。

ガスの価格設定を再構築する必要があります:RISC-V命令のために新しいガスモデルを定義し、公平性と安全性を確保する必要があります。

安全なサンドボックス設計:システムコールの制限、コードの自己修正を防止、決定的な実行を保証します。

開発ツールの適合:コンパイラ、デバッガ、安全監査ツールを更新する必要があり、RISC-V バイトコードをサポートします。

移行互換性の問題:一部の契約はEVMの特性に依存しているため、移行には互換性層またはフォールバックメカニズムを慎重に設計する必要があります。

Vitalik は、移行パスとしてオプション 1 を支持し、新旧の契約が相互運用性を維持し、開発者体験が変わらず、ユーザーが気付かない形でのアップグレードを保証すると約束しました。

三、既存のスケーリングルートへの影響:RISC-VはL2やデータシャーディングなどを代替するか?

答えは否定的です:RISC-Vはインフラの最適化であり、既存のスケーリングの道を置き換えることはありません。

レイヤー2:

Rollup は依然としてイーサリアムのスケーリングの主力であり、RISC-V は L1 の処理効率と ZK 検証性能を向上させますが、直接的にスループットを拡張するわけではありません。

より高速な L1 検証は、Rollup の低コストで迅速なデータ提出を助け、全体的なスケーラビリティを向上させることができます。

データシェーディングと EIP-4844:

データ可用性のボトルネックは依然としてEIP-4844(blob)とDankshardingによって解決する必要があり、RISC-Vはチェーン上のデータ容量には影響を与えません。

L1のデータストレージ要件を変更することなく、アーキテクチャの変更を実行します。

FaaS、MEV:

仮想マシンアーキテクチャに依存せず、RISC-Vの進展によって無効にはならない。

まとめ:RISC-Vは「エンジンの交換」、L2/シャーディングは「道路の拡張ネットワーク」、両者は次元が異なり、並行して矛盾しない。

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

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

支持者:これはSolana/Suiなどのパフォーマンスの課題に対処するための必要な戦略的アップグレードであり、従来の開発者を引き付けるのに役立つと考えています。

保守派:実施の難しさ、歴史的負担、エコツールチェーンの更新コストの大きさを懸念し、リソースの投入対効果に疑問を呈する。

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

Move VM(Aptos/Sui):全く新しいリソース指向のVMで、言語の安全性が高いですが、EVMとは互換性がありません。

FuelVM:並行処理のために設計された新しいVMで、言語Swayを搭載しており、互換性は限られています。

WASM (Stylus): L2 のコントラクト言語としての WASM の導入が Arbitrum に実装され、実現可能になりました。

Nervos CKB:メインネットで RISC-V を契約 VM として使用する先例は、イーサリアムに実践的な参考を提供します。

ヴィタリックは、RISC-Vを提案したからといって他の選択肢を拒否しているわけではなく、将来的にはインタープリターメカニズムがMoveやWASMなどのVMを挿入するためにも使用でき、多様な実行エコシステムを構築できると考えています。

  1. 将来の影響の見通し:イーサリアムがRISC-Vに切り替わった場合

デベロッパー体験:

Solidity/Vyperなどの言語は依然として使用可能であり、コンパイラのバックエンドが変更されるだけで言語自体は変わりません。

Rust/Cなどの新しい言語で契約を書くことが可能になるかもしれませんが、移行を強制することはありません。

運営コストとパフォーマンス:

実行効率の向上は、より高いガス上限と低い手数料をもたらします。

RISC-V コントラクトは、プレコンパイルコントラクトへの依存を減らす可能性があり、Gas モデルは ZK 証明コストにより近くなります。

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

双 VM 同時期に既存の契約が継続して実行され、新しい契約は徐々に RISC-V を採用します。

インフラは新しいバイトコード形式をサポートする必要があり、チェーン間の互換性の変動を引き起こす可能性があります(例:BSC、Polygonの去留問題)。

セキュリティと安定性:

新しいアーキテクチャは、プロトコルの信頼性を向上させるために広範なテストと形式的検証が必要です。

より簡潔な実行層は、監査と攻撃面の制御に役立ちます。

エピローグ

Vitalikは、EthereumのEVMをRISC-Vに置き換えることを提案しました。これは、Ethereumが未来の性能限界とプロトコルの簡潔性について深く考えていることを示しています。この提案はまだ初期の議論段階にあり、実施には数年のプロセスが必要であり、技術、コミュニティ、エコシステムの多くの課題を乗り越える必要があります。これは既存の路線を覆すものではなく、基盤を強化し、未来に備えるものです。

ヴィタリックが言ったように、「量的な向上を実現するためには、このような過激な変化が唯一の実現可能な道かもしれない。」

私たちはこれを未来への賭けと見なし、「基盤が再構築する価値があるのか」という深い探求の場とも言えるでしょう。

参考資料:

原文表示
内容は参考用であり、勧誘やオファーではありません。 投資、税務、または法律に関するアドバイスは提供されません。 リスク開示の詳細については、免責事項 を参照してください。
  • 報酬
  • コメント
  • 共有
コメント
0/400
コメントなし
  • ピン
いつでもどこでも暗号資産取引
qrCode
スキャンしてGate.ioアプリをダウンロード
コミュニティ
日本語
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • ไทย
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)