jakiro
出典：Vitalik Buterin、Ethereum Magicians;編集：タオ・Zhu、ビッチンビジョン
この記事では、イーサリアムの実行層の将来に関する積極的なアイデアを紹介します。これは、コンセンサス層に対するビームチェーンの努力と同じくらい野心的です。イーサリアム実行層の効率を大幅に向上させ、主要なスケーリングボトルネックの1つを解決し、実行層のシンプルさを大幅に改善することを目的としています。実際、これが唯一の方法です。
アイデア：EVMスマートコントラクトを作成するための仮想マシン言語としてRISC-Vを使用します。
重要な説明：
-
アカウント、クロスコントラクトコール、ストレージなどの概念はまったく同じままです。これらの抽象化はうまく機能し、開発者はそれらに慣れます。 Sload、Sstore、Balance、Call、およびその他のオペコードは、RISC-Vシステムコールになります。
-
このような世界では、スマートコントラクトは錆びて書くことができますが、ほとんどの開発者は、RISC-Vをバックエンドとして追加することに適応するSolidity（またはVyper）でスマートコントラクトを書き続けることを期待しています。これは、錆びたスマートコントラクトが実際には非常にugいものであるのに対し、堅実さとvyperははるかに読みやすいためです。おそらく、Devexの変化は小さく、開発者はこの変化にほとんど気付かないかもしれません。
-
古いスタイルのEVM契約は引き続き有効であり、新しいRISC-V契約と完全に双方向の相互運用可能になります。これを行うにはいくつかの方法がありますが、この記事の後半で説明します。
1つの先例は、基本的にRISC-VであるNervos CKB VMです。
なぜこれをするのですか？
近いうちに、Ethereum L1スケーラビリティの主要なボトルネックは、ブロックレベルのアクセスリスト、レイテンシ実行、分散型歴史的ストレージ、EIP-4444などの今後のEIPで対処されます。中期的には、StatelessnessとZK-EVMのさらなる問題に対処します。長期的には、Ethereum Layer1拡張の主な制限要因は次のとおりです。
-
データの可用性サンプリングと履歴ストレージプロトコルの安定性
-
ブロック生産市場の競争力を維持したいと考えています
-
ZK-EVM検証機能
ZK-EVMをRISC-Vに置き換えると、（2）および（3）でキーボトルネックを解くことができると思います。
これは、EVM実行レイヤーのさまざまな部分を証明するために、簡潔なZK-EVMが使用するループの数です。
多くの時間をかける4つの部分があります：Deserialize_inputs、intiality_witness_db、state_root_computation、およびblock_execution。
intialize_witness_dbとstate_root_computationはどちらも状態ツリーに関連しており、deserialize_inputsは、ブロックと証人データを内部表現に変換するプロセスを指します。したがって、実際、50％以上が証人規模に比例します。
これらの部品は、現在のKeccak 16メンバーのマークルパトリシアツリーを、プレーバーに優しいハッシュ機能を使用するバイナリツリーに置き換えることで、大幅に最適化できます。 Poseidonを使用すると、ラップトップで1秒あたり200万匹のハッシュを証明できます（Keccakは1秒あたり約15,000のハッシュハッシュです）。 Poseidon以外には他にも多くのオプションがあります。全体として、これらのコンポーネントを大幅に削減する機会があります。ボーナスとして、Bloomを取り除くことでAccrue_logs_bloomを取り除くことができます。
残りはblock_executionであり、今日のプルーフサイクルの約半分を占めています。プローバーの全体的な効率を100倍増加させたい場合は、EVMプローバーの効率を少なくとも50回増やす必要があるという事実を避けることはできません。私たちにできることの1つは、プルーフサイクルにより効率的なEVM実装を作成することです。もう1つのことは、ZK-EVM ProverがEVM実装がRISC-Vにコンパイルされ、Smart Contract開発者がそのRISC-V VMに直接アクセスできることを証明することで機能したことに注意してください。
一部のデータは、これが限られたケースで100倍以上効率を高めることができることを示唆しています。
実際、残りの校正時間は今日の事前コンパイルによって支配されると予想しています。 RISC-Vをプライマリ仮想マシンとして使用する場合、ガス計画は証明時間を反映しているため、より高価なプレキサイラーの使用を停止するという経済的圧力があります。しかし、それでも、利点はそれほど印象的ではありませんが、利点が非常に重要であると信じる正当な理由があります。
（ちなみに、「EVM」と「その他のもの」の間で約50/50が分割されていることは、通常のEVM実行にも表示されます。EVMから「ミドルマン」として削除する利点が同様に大きいはずだと直感的に期待しています）
実装の詳細
このような提案を実装するには、いくつかの方法があります。最も破壊的なアプローチは、2つの仮想マシンをサポートし、いずれかの仮想マシンで契約を書き込むことを許可することです。どちらのタイプの契約でも、同じタイプの施設を使用できます。永続的なストレージ（SLOADおよびSSTORE）、ETHバランスを保持する能力、電話をかける能力など。EVMとRISC-Vの契約はお互いに自由に電話をかけます。 RISC-Vの観点から、EVM契約を呼び出すことは、いくつかの特別なパラメーターでシステムコールを行っているようです。メッセージを受信するEVM契約は、それを呼び出しとして解釈します。
プロトコルの観点からは、より根本的なアプローチは、既存のEVM契約をRISC-Vで記述されたEVMインタープリター契約を呼び出す契約に変換することです。つまり、EVM契約にコードCがあり、EVMインタープリターがアドレスXにある場合、契約はトップレベルのロジックに置き換えられます。コールパラメーターdを使用して外部から呼び出されると、xは（c、d）で呼び出され、戻り値を待機して転送します。 EVMインタープリター自体が契約を呼び出し、コールまたはスロード/SSTOREを実行する必要がある場合、契約はそうします。
中間ルートは2番目のオプションを取得することですが、それのための明確なプロトコル関数を作成することです – 基本的に、「仮想マシンインタープリター」の概念はガイドとして使用され、その論理はRISC -Vで記述する必要があります。 EVMは最初になりますが、他の人がいるかもしれません（たとえば、移動は候補者かもしれません）。
2番目と3番目の提案の主な利点の1つは、実行レイヤーの仕様を大幅に簡素化することです。実際、このアイデアは唯一の実行可能なアプローチかもしれません。 TinyGradには、コードボリュームが10,000行を超えないという厳格なルールがあります。最適なブロックチェーンファンデーションレイヤーは、さらに小さく、これらの境界に適応できるはずです。ビームチェーンの取り組みは、イーサリアムのコンセンサス層を大幅に簡素化することに大きな希望を持っています。しかし、実行レイヤーの場合、この根本的な変化は、同様の利点を得るための唯一の実行可能な方法かもしれません。
