この記事はイーサリアム共同創設者Vitalikによるものです
Odaily Planet Daily（ @OdailyChina ）がまとめました
翻訳：Azuma ( @azuma_eth )
この記事では、Beam Chain のコンセンサス レイヤーの計画と同じくらい野心的な、イーサリアムの実行レイヤーの将来に関する革新的なアイデアを紹介します。この取り組みの目標は、イーサリアムの実行層の効率を大幅に向上させ、スケーリングにおける主要なボトルネックの 1 つを解決するとともに、実行層の複雑さを大幅に簡素化することです。実際、これが簡素化を実現する唯一の方法かもしれません。
この記事の核となるアイデアは、スマート コントラクトの仮想マシン言語として EVM を RISC-V に置き換えることです。
重要な注意事項:
アカウント、クロスコントラクト呼び出し、ストレージなどの概念は完全に保持されます。これらの抽象化はうまく機能し、開発者はそれを使用することに慣れています。 SLOAD、SSTORE、BALANCE、CALL などのオペコードは RISC-V システム コールになります。
開発者は引き続き Solidity または Vyper を選択できます。スマート コントラクトは理論的には Rust で記述できますが、ほとんどの開発者はバックエンドのコンパイル ターゲットとして RISC-V に適合する Solidity (または Vyper) を引き続き使用すると予想されます。これは、Rust で記述されたスマート コントラクトは読みにくく、Solidity と Vyper の方が理解しやすいためです。開発エクスペリエンスはほとんど変わらず、開発者は違いをまったく感じないかもしれません。
新しい契約と古い契約は双方向に相互運用可能になります。従来の EVM 契約は引き続き実行され、新しい RISC-V 契約と完全に相互運用されます。具体的な実施方法については後ほど詳しく説明します。
すでに前例があります。Nervos CKB VM は、基本的に RISC-V ベースの実装です。
なぜこの変更が必要なのでしょうか?
短期的には、イーサリアム レイヤー 1 拡張の主なボトルネックについては、今後の EIP (ブロックレベルのアクセス リスト、遅延実行、分散履歴ストレージ、EIP-4444 など) によって解決される予定です。中期的には、ステートレス性とZK-EVMを通じてさらに多くの問題を解決します。しかし長期的には、イーサリアムレイヤー1の拡張を制限する主な要因は次のようになります。
データ可用性のサンプリングと履歴ストレージ プロトコルの安定性。
ブロック生産のための競争市場を維持する必要性。
ZK-EVM の証明機能。
この記事では、ZK-EVM を RISC-V に置き換えることで、ポイント 2 と 3 の主要なボトルネックを打破できることを示します。
以下は、Succinct ZK-EVM が EVM 実行層の各リンクを証明するために必要なサイクル数の統計表です。
時間のかかる主な 4 つのリンクは、「deserialize_inputs」(データのデシリアライズ)、「initialize_witness_db」(監視データベースの初期化)、「state_root_computation」(状態ルートの計算)、「block_execution」(ブロック実行) です。
「証人データベースの初期化」と「状態ルートの計算」はどちらも状態ツリーに関連していますが、「データのデシリアライゼーション」はブロックと証人データを内部表現に変換するプロセスを指します。つまり、実際には 50% 以上の場合、これは監視データのサイズに関連しています。
これらの手順は、現在の「ケッカック 16 進マークル パトリシア ツリー」を、証明しやすいハッシュ関数を使用する「バイナリ ツリー」に置き換えることで大幅に最適化できます。 Poseidon を使用すると、ラップトップで 1 秒あたり 200 万ハッシュを証明できます (keccak の場合は 1 秒あたり約 15,000 ハッシュ)。 「ポセイドン」以外にも選択肢はたくさんあります。全体として、これらのステップに費やされる時間を大幅に短縮する機会があります。さらに、「accrue_logs_bloom」を削除することで、プロセスをさらに簡素化できます。
残っているのは「ブロック実行」のみで、これは現在の証明サイクルの約半分を要します。全体的な証明効率を 100 倍向上させたい場合は、EVM 証明効率を少なくとも 50 倍向上させる必要があります。 2 つの方法があります。1つは、証明サイクルを短縮するために、より効率的な EVM 実装を作成することです。もう1つは、ZK-EVMの基盤に採用されているRISC-V仮想マシンを開発者が直接使用できるようにすることです。
いくつかのデータによれば、特定のシナリオでは効率が 100 倍以上向上する可能性があります。
実際には、残りの証明時間は主にプリコンパイルによって消費されます。 RISC-Vをメインの仮想マシンとすれば、ガス料金の仕組みが実際の証明時間を反映することになり、経済的な圧力から開発者はコストの高いプリコンパイルの使用を減らすことになる。実際の収益は理論値ほど良くないかもしれませんが、それでも非常に大きいと予想されます。
通常の EVM 実行でも同様に「EVM」と「その他のリンク」が 50/50 に分割されていることは注目に値します。また、EVM を「中間層」として削除すると、同様の効率向上が得られると直感的に考えられます。
実装
上記の提案を実装する方法はいくつかあります。
最も混乱の少ないアプローチは、両方の仮想マシンをサポートし、どちらの仮想マシンでも契約を記述できるようにすることです。どちらのタイプのコントラクトも、永続ストレージ (SLOAD/SSTORE)、ETH 残高管理、呼び出しの送受信など、同じ機能にアクセスできます。EVMコントラクトと RISC-V コントラクトは自由に相互運用できます。RISC-V の観点から EVM コントラクトを呼び出すと、特別なパラメータを持つシステム コール (syscall) と見なされますが、呼び出しを受信した EVM コントラクトはそれを通常の CALL 命令として解析します。
より根本的な解決策としては、既存の EVM コントラクトを変換して、RISC-V で記述された EVM インタープリタ コントラクトを呼び出して、元の EVM コードを実行することです。具体的には、EVM コントラクトにコード C が含まれ、EVM インタープリターがアドレス X にあると仮定すると、コントラクトはトップレベルのロジックに置き換えられます。呼び出しパラメーター D を使用して外部呼び出しが開始されると、ロジックは (C、D) 要求を X に送信し、戻り値を待機して転送します。 EVM インタープリタ自体が CALL、SLOAD、SSTORE などの操作を実行するためにコントラクトを呼び出す必要がある場合、コントラクトは直接応答します。
妥協案としては、2 番目のソリューションを基にして、プロトコル層を通じて「仮想マシン インタープリタ」の概念を明示的にサポートすることです。つまり、インタープリタ ロジックは RISC-V で記述する必要があります。 EVM は最初の公式インタープリターとなり、将来的には他のタイプ (Move 言語インタープリターなど) が導入される可能性があります。
2 番目と 3 番目のオプションの主な利点は、実行層の仕様が大幅に簡素化されることです。 SELFDESTRUCT を削除するなどの段階的な簡素化でさえ難しいことを考えると、このような変更が簡素化を実現する唯一の現実的な方法である可能性があります。 Tinygrad プロジェクトでは、コードの量が 10,000 行を超えないことを厳密に規定しています。理想的なブロックチェーンのベースレイヤーは、より極端なシンプルさを追求する必要があります。 Beam Chain プロジェクトは、Ethereum のコンセンサス レイヤーの簡素化への道を示しており、実行レイヤーにおける同様のブレークスルーは、このような根本的な変更を通じてのみ達成される可能性があります。
