ヴィタリックの新提案：EVMスマートコントラクトの仮想マシン言語としてのRISC-V

Source: Vitalik Buterin, Ethereum Magicians; Compiled by Tao Zhu, Golden Finance

この記事では、イーサリアムの実行レイヤーの将来に対する急進的なアイデアを紹介します。それは、コンセンサス層に対するビームチェーンの取り組みと同じくらい野心的なものです。それはイーサ実行レイヤーの効率を劇的に改善し、主要なスケーリングボトルネックの1つに対処し、また実行レイヤーのシンプルさを劇的に改善することを目指しています。

そのアイデアとは、EVMスマートコントラクトを記述するための仮想マシン言語としてRISC-Vを使用することです。

重要な明確化:

• アカウント、クロスコントラクト呼び出し、ストレージなどの概念はまったく変わりません。これらの抽象化はうまく機能し、開発者はそれに慣れている。 SLOAD、SSTORE、BALANCE、CALLなどのオペコードは、RISC-Vシステムコールになります。

• そのような世界では、スマートコントラクトはRustで書くこともできますが、ほとんどの開発者は、バックエンドとしてRISC-Vを追加することに対応するSolidity（またはVyper）でスマートコントラクトを書き続けるだろうと予想しています。というのも、Rustで書かれたスマートコントラクトは実際には非常に醜いのに対し、SolidityやVyperはずっと読みやすいからだ。おそらくdevexの変更はとても小さいので、開発者はほとんど気づかないかもしれない。

• 古いEVMコントラクトは引き続き機能し、新しいRISC-Vコントラクトと完全に双方向に相互運用できます。これにはいくつかの方法がありますが、この記事の後半で説明します。

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

なぜこのようなことをするのですか?

短期的には、イーサネットL1のスケーラビリティにおける主要なボトルネックは、ブロックレベルのアクセスリスト、遅延実行、分散履歴ストレージ、およびEIP-4444などの今後のEIPで対処されます。長期的には、イーサネットのレイヤー1拡張の主な制約は次のとおりです。

• データ可用性のサンプリングと履歴保存プロトコルの安定性

• 。ブロック生産市場の競争力を維持したい

• ZK-EVMの検証機能

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

以下は、Succinct ZK-EVM が EVM 実行レイヤーのさまざまな部分を正当化するために使用するループ カウントの表です:

かなりの時間を要する部分が4つあります。

initialize_witness_dbとstate_root_computationはどちらもステートツリーに関連しており、deserialize_inputsはブロックと証人のデータを内部表現に変換するプロセスを指します。実際には50%以上がウィットネスサイズに比例します。

現在のkeccak $16 Merkle patriciaツリーを、証明者に優しいハッシュ関数を使用する分岐ツリーに置き換えることで、これらの部分で多くの最適化を行うことができます。Poseidonを使えば、ラップトップで1秒間に200万ハッシュを証明できる（keccakの1秒間に15,000ハッシュに対して）。Poseidonに代わるものはたくさんある。全体として、これらのコンポーネントを大幅に削減するチャンスがある。ボーナスとして、ブルームを取り除くことで、accrue_logs_bloomを取り除くことができます。

唯一残っているのはblock_executionで、これは今日費やされているプルーフサイクルの約半分を占めています。もし全体的な証明効率を100倍にしたいのであれば、EVM証明効率を少なくとも50倍にする必要があることは避けられない。私たちにできることのひとつは、証明サイクルの点でより効率的なEVM実装を作ることです。

いくつかのデータは、限られたケースでは、これが効率の100倍以上の増加につながることを示唆しています。https://img.jinse.cn/7364315_watermarknone.png" title="7364315" alt="JuLOouHUiv8vXajoUnYsOnYyFtRiCpO8cvkOUhPu.jpeg">実際、残りのプルーフ時間は、今日のプリプルーフに大きく支配されると予想しています。今日のプリコンパイルが大部分を占めると予想される。もしRISC-VをプライマリVMとして使用するのであれば、ガスプログラムはプルーフ時間を反映し、より高価なプリコンパイルの使用を止める経済的な圧力がかかるでしょう。

（ちなみに、「EVM」と「他の何か」のほぼ半々の割合は、通常のEVM実装でも発生します。私たちは直感的に、「仲立ち」としての EVM を取り除くことによる利益も同様に大きくなるはずだと期待しています)

Implementation details

この種の提案を実装する方法はいくつかあります。最も破壊的でない方法は、2つの仮想マシンをサポートし、コントラクトをどちらか一方に記述できるようにすることです。RISC-Vの観点からは、EVMコントラクトを呼び出すことは、いくつかの特別なパラメータを持つシステムコールを行っているように見えます。メッセージを受信したEVMコントラクトは、それをいくつかの特別なパラメータを持つシステムコールとして解釈します。プロトコルの観点からより根本的なアプローチは、既存のEVMコントラクトを、既存のEVMコードを実行するRISC-Vで書かれたEVMインタプリタコントラクトを呼び出すものに変換することです。つまり、EVMコントラクトがコードCを持ち、EVMインタプリタがアドレスXにある場合、コントラクトをトップレベルロジックに置き換え、コールパラメータDで外部から呼び出された場合、(C, D)でXを呼び出し、戻り値を待って転送します。EVMインタープリタ自身がコントラクトを呼び出し、CALLまたはSLOAD/SSTOREを実行するように要求した場合、コントラクトはそれを実行します。

中間の選択肢は、2番目の選択肢を取ることですが、そのための明示的なプロトコル関数を作成することです。基本的には、「仮想マシンインタプリタ」の概念を確立し、そのロジックがRISC-Vで記述されることを要求します。 EVMが最初になるだろうが、他にもあるかもしれない（例えば、Moveが候補になるかもしれない）。

2番目と3番目の提案の主な利点の1つは、実行レイヤーの仕様を大幅に簡略化できることです -- 実際、SELFDESTRUCTを削除するような漸進的な簡略化でさえ非常に難しいので、このアイデアは唯一の実行可能なアプローチかもしれません。 Tinygradには、コード量が10,000行を超えてはならないという厳格なルールがある。最良のブロックチェーン・ベースレイヤーは、それ以下でないとしても、この境界線内にうまく収まるはずだ。Beamchainの努力は、Etherのコンセンサス層を大幅に簡素化する上で大きな可能性を秘めている。Beamchainの取り組みは、Etherのコンセンサス層を大幅に簡素化する上で大きな可能性を秘めている。しかし、実行層については、このような抜本的な変更が同様の利益を得るための唯一の実行可能な道かもしれない。