この投稿では、イーサリアムの実行レイヤーの将来における画期的なアイデアが提案されています。これは、ビームチェーンの取引層に対する取り組みが合意層に対するものと同じくらい野心的であり、イーサリアムの実行レイヤーの効率を大幅に向上させることを目指しています。これにより、主要なスケーリングのボトルネックの1つを解消し、実行レイヤーのシンプルさも大幅に向上させることができます。実際、これがその唯一の方法かもしれません。

アイデア：EVMをスマートコントラクトが記述される仮想マシン言語としてRISC-Vで置き換える。

重要な明確化:

• アカウント、クロスコントラクトの呼び出し、ストレージなどの概念はまったく同じままです。これらの抽象化はうまく機能し、開発者はそれに慣れています。SLOAD、SSTORE、BALANCE、CALLなどのオペコードは、RISC-Vシスコールになります。
• そのような世界では、スマートコントラクトはRustで書かれるかもしれませんが、ほとんどの開発者はSolidity（またはVyper）でスマートコントラクトを引き続き書くと予想しています。これは、Rustで書かれたスマートコントラクトはRISC-Vをバックエンドとして追加することに適応するでしょう。実際にかなり醜い、そしてSolidityとVyperはたくさんもっと読みやすい. ポテンシャル的に、devexはほとんど変わらず、開発者はほとんど変化に気づかないかもしれません。
• 古いスタイルのEVM契約は引き続き機能し、新しいスタイルのRISC-V契約と完全に双方向で相互運用可能になります。これを行うための方法はいくつかありますが、この投稿の後半で詳しく説明します。

これに関する1つの前例として、Nervos CKB VMがあります。基本的にRISC-V。

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

短期間では、Ethereum L1のスケーラビリティの主なボトルネックは、次のEIPなどを活用して解決されます。ブロックレベルのアクセスリスト, 遅延実行および分散履歴ストレージプラスEIP-4444中期では、さらなる問題に対処します。ステートレスそしてZK-EVMs. ロングタームでは、イーサリアムL1スケーリングの主要な制限要因となるものが次のようになります:

1. データ利用可能性サンプリングおよび履歴保存プロトコルの安定性
2. ブロック生産を競争市場に維持したいという願望
3. ZK-EVM証明機能

ZK-EVMをRISC-Vで置き換えることで、(2)および(3)の主要なボトルネックが解消されると主張します。

これは、Succinct ZK-EVMがEVM実行レイヤーの異なる部分を証明するために使用するサイクル数の表です。

重要な時間を取る4つの部分があります: deserialize_inputs、initialize_witness_db、state_root_computation、block_execution。

initialize_witness_dbとstate_root_computationの両方は状態ツリーに関連しており、deserialize_inputsはブロックとウィットネスデータを内部表現に変換するプロセスを指します。したがって、それの50%以上がウィットネスサイズに比例しているというのは現実的な話です。

これらの部分は、現在のkeccak 16進Merkle Patriciaツリーを、プロバー向けのハッシュ関数を使用するバイナリツリーに置き換えることで、大幅に最適化することができます。Poseidonを使用すれば、1秒あたり200万ハッシュを証明しますラップトップで（keccakの場合は約15,000ハッシュ/秒）比較すると。ポセイドン以外のオプションも多数あります。全体として、これらのコンポーネントを大幅に削減する機会があります。ボーナスとして、accrue_logs_bloomを排除することもできます。ブルームを取り除く.

これにより、本日費やされたプローバーサイクルの約半分を占めるブロック実行が残ります。合計プローバー効率を100倍にしたい場合、少なくとも50倍のEVMプローバー効率が必要であるという事実を避けることはできません。できることの1つは、プローバーサイクルの点ではるかに効率的なEVMの実装を作成しようとすることです。もう1つの方法は、ZK-EVMプローバーはすでに今日、RISC-VにコンパイルされたEVMの実装を証明することによって動作し、スマートコントラクト開発者にそのRISC-V VMへの直接アクセスを提供していることに気づくことです。

いくつかの数字から、限られたケースでは、これが100倍以上の効率的な利益をもたらす可能性があることを示唆しています。

実際には、私は残りの証明者の時間が今日のプリコンパイルに支配されるようになることを予想しています。もしRISC-Vを主要なVMにすれば、ガススケジュールは証明時間を反映し、より高価なプリコンパイルの使用をやめる経済的圧力が生じるでしょう。しかし、それでも利益はこのようには目覚ましくないでしょうが、非常に重要であると信じる理由があります。

(Incidentally, the roughly 50/50 split between “EVM” and “other stuff” 通常のEVM実行でも表示されます,そして、私たちは直感的に、EVMを「仲介者」として排除することによる利益も同様に大きいと予想しています)

実装の詳細

この種の提案を実装するいくつかの方法があります。最も中断が少ない方法は、2つのVMをサポートし、契約をどちらかで書くことを許可することです。両方の契約タイプは、永続的なストレージ（SLOADおよびSSTORE）、ETH残高を保持する能力、呼び出しを行ったり受けたりする能力など、同じ種類の施設にアクセスできます。EVMとRISC-V契約は、互いに呼び出すことができます。RISC-Vの観点からEVM契約を呼び出すと、特定のパラメータを使用してシステムコールを実行しているように見えます。メッセージを受け取るEVM契約は、それをCALLとして解釈します。

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

中間ルートは、第2のオプションを実行することですが、それに明示的なプロトコル機能を作成します。基本的には、「仮想マシンインタープリター」のコンセプトを確立し、そのロジックをRISC-Vで記述することを要求します。EVMは最初のものになりますが、他にもあります（例：Moveが候補になるかもしれません）。

第2および第3の提案の主な利点は、実行レイヤー仕様を大幅に単純化することです。実際、この種のアイデアは、SELFDESTRUCTを削除するなどの増分的な単純化さえも非常に困難なため、それを行う唯一の実用的な方法かもしれません。Tinygradは厳格なルールを持っています。10000行を超えることはない;最適なブロックチェーンベースレイヤーは、これらのマージンに適合し、さらに小さくなることができるべきです。beamチェーンの取り組みは、イーサリアムのコンセンサスレイヤーを大幅に簡素化するという大きな約束を持っています。しかし、実行レイヤーが同様の利益を得るためには、この種の根本的な変化が唯一の道かもしれません。

免責事項:

1. この記事は[から転載されていますイーサリアムマジシャン]. すべての著作権は元の著者に帰属します [ヴィタリック・ブテリン]. If there are objections to this reprint, please contact the Gate Learnチームが迅速に対応します。
2. 責任の免責事項：この記事で表現される意見や見解は、著者個人のものであり、投資アドバイスを意味するものではありません。
3. Gate Learnチームは、記事を他の言語に翻訳します。翻訳された記事のコピー、配布、または盗用は、特記されていない限り禁止されています。