Vitalikの新しい提案:現在のEVMをRISC-Vに置き換える

この記事はイーサリアムの実行層の未来に対して過激なアイデアを提案しており、このアイデアはBeamチェーンのコンセンサス層への取り組みと同じくらい野心的です。これはイーサリアムの実行層の効率を大幅に向上させ、主なスケーラビリティのボトルネックの一つを解決することを目的としており、さらに実行層のシンプルさも大幅に向上させることができます。実際、これが唯一の方法かもしれません。

アイデア：EVMの代わりにRISC-Vをスマートコントラクトの仮想マシン言語として使用すること（訳注：RISC-Vは、リスク原理に基づいたオープンな命令セットアーキテクチャであり、Vは第5世代RISCを示します）。

重要な説明:

• アカウント、クロスコントラクト呼び出し、ストレージなどの概念は完全に同じまま維持されます。これらの抽象は非常によく機能し、開発者もそれに慣れています。SLOAD、SSTORE、BALANCE、CALLなどのオペコードはRISC-Vシステムコールになります。
• このような世界では、スマートコントラクトは Rust で書くことができますが、ほとんどの開発者は Solidity（または Vyper）でスマートコントラクトを書くことを続けると予想しています。これは、RISC-V をバックエンドに追加することに適応するでしょう。Rust で書かれたスマートコントラクトは実際にはかなり醜いため、Solidity と Vyper の可読性ははるかに高いです。おそらく devex の変化は小さく、開発者はこの変化にほとんど気付かないかもしれません。
• 従来のEVM契約は引き続き有効であり、新しいRISC-V契約と完全に双方向で相互運用可能です。これを実現する方法はいくつかあり、この記事の後半で紹介します。

1つの前例は、基本的にRISC-VであるNervos CKB VMです。

なぜこれをするのですか？

短期内、イーサリアム L1 の主なスケーラビリティのボトルネックは、ブロックレベルのアクセスリスト、遅延実行、分散型履歴ストレージ、EIP-4444 などの今後の EIP によって解決されるでしょう。中期的には、無状態および ZK-EVM のさらなる問題を解決します。長期的には、イーサリアム Layer1 の拡張における主な制限要因は次のとおりです：

• データ可用性サンプリングと履歴ストレージプロトコルの安定性
• ブロック生成市場の競争力を維持したい
• ZK-EVM検証機能

RISC-Vを使用してZK-EVMを置き換えることで、(2)と(3)の中の1つの重要なボトルネックを解決できると思います。

これは、EVM の実行レイヤーの異なる部分のループ回数を証明するための Succinct ZK-EVM 用の表です：

! nsRqhscTyRR2vPvAOgUE58HVgFHuLUgGxTescWwT.jpeg

多くの時間を費やすのは、逆シリアル化_inputs、初期化_witness_db、状態_root_computation、およびブロック_executionの 4 つの部分です。

initialize_witness_db と state_root_computation は状態ツリーに関係しており、deserialize_inputs はブロックとウィットネスデータを内部表現に変換するプロセスを指します。そのため、実際には50%以上がウィットネスの規模に比例しています。

現在のkeccak 16元Merkle patriciaツリーを証明者フレンドリーなハッシュ関数を使用したバイナリツリーに置き換えることで、これらの部分を大幅に最適化できます。Poseidonを使用すれば、ノートパソコンで毎秒200万回のハッシュ値を証明でき（keccakは毎秒約15,000回のハッシュ値です）、他にも多くの選択肢があります。要するに、これらのコンポーネントを大幅に削減する機会があります。報酬として、bloomを取り除くことでaccrue_logs_bloomからも解放されることができます。

残りは block_execution で、これは今日費やされた証明サイクルの約半分を占めています。全体の証明器の効率を100倍向上させたい場合、少なくともEVM証明器の効率を50倍向上させる必要があるという事実を避けることはできません。私たちができることの一つは、証明サイクルの観点からより効率的なEVM実装を作成しようとすることです。もう一つできることは、ZK-EVM証明器が今日、証明をRISC-VのEVM実装にコンパイルして動作しており、スマートコントラクト開発者がそのRISC-V VMに直接アクセスできるようになっていることに気付くことです。

いくつかのデータは、限られた条件下で、これが効率を100倍以上向上させる可能性があることを示しています。

実際、残りの証明時間は主に今日のプリコンパイルによって主導されると予想しています。RISC-Vを主要な仮想マシンとする場合、ガスプランは証明時間を反映するため、より高価なプリコンパイルの使用を停止するための経済的圧力が存在します。しかし、それでも収益はそれほど印象的ではありませんが、収益が非常に顕著であると確信する十分な理由があります。

（ちなみに、「EVM」と「その他のもの」の間の約50/50の分割も通常のEVM実行に現れ、私たちは直感的に、EVMを「仲介者」として取り除くことで得られる利益も同様に大きいと予想しています）

実装内容

このような推奨事項を実装するには、いくつかの方法があります。 最も中断の少ないアプローチは、2 台の仮想マシンをサポートし、どちらかの仮想マシンでコントラクトを書き込めるようにすることです。 どちらのタイプの契約も、永続ストレージ(SLOADおよびSSTORE)、ETH残高を保持する機能、電話をかけたり受けたりする機能など、同じタイプの機能を使用できます。 EVMコントラクトとRISC-Vコントラクトは、相互に自由に呼び出すことができます。 RISC-Vの観点から見ると、EVMコントラクトを呼び出すことは、いくつかの特別なパラメータを持つシステムコールを行っているように見えます。 メッセージを受信したEVMコントラクトは、それをCALLとして解釈します。

プロトコルの観点から見ると、より根本的なアプローチは、既存のEVMコントラクトを、既存のEVMコードを実行するRISC-Vで記述されたEVMインタプリタコントラクトを呼び出すコントラクトに変換することです。 つまり、EVMコントラクトのコードがCで、EVMインタプリタがアドレスXにある場合、外部からcall引数Dで呼び出され、(C、D)でXを呼び出し、戻り値を待って転送すると、コントラクトはトップレベルのロジックに置き換えられます。 EVMインタプリタ自体がコントラクトを呼び出し、CALLまたはSLOAD/SSTOREの実行を要求した場合、コントラクトはそれを実行します。

中間ルートは第二の選択肢を採用するが、そのために明確なプロトコル機能を作成する必要がある —— 基本的に「仮想マシンインタープリター」の概念を聖典として奉り、その論理をRISC-Vで記述することを要求する。EVMは最初のものであるが、他にも存在する可能性がある（例えば、Moveは候補となるかもしれません）。

第二と第三の提案の主な利点の一つは、それらが実行層の仕様を大幅に簡素化することである。実際、この考えは唯一の実行可能な方法かもしれない。SELFDESTRUCTのような漸進的な簡素化でさえ非常に困難である。Tinygradには、コード量が常に10,000行を超えないという厳格な規則がある。最適なブロックチェーンの基盤層は、これらの境界にうまく適応し、さらに小さくなるべきである。光束チェーンの取り組みは、イーサリアムのコンセンサス層を大幅に簡素化する大きな希望を持っている。しかし、実行層において同様の利益を得るためには、このような徹底的な変化が唯一の実行可能な道かもしれない。