この記事はEthereum開発者levochka.ethから提供されました。
Odaily Planet Daily（ @OdailyChina ）がまとめました。翻訳：Azuma ( @azuma_eth )
編集者注:
昨日、イーサリアムの共同創設者であるVitalik氏が、イーサリアムの実行レイヤーのアップグレードに関する革新的な記事を公開しました（「 Vitalik氏の革新的な新記事：実行レイヤーの拡張には『ブレークスルー』が必要、EVMは将来的に反復されなければならない」を参照）。この記事では、スマート コントラクトの仮想マシン言語として EVM の代わりに RISC-V を使用するという希望について述べました。
この記事が公開されるとすぐに、イーサリアム開発者コミュニティでは騒動が起こり、多くの技術リーダーがこの計画についてさまざまな意見を表明しました。記事が公開されて間もなく、第一線のイーサリアム開発者であるlevochka.ethが、原文の下にVitalikの見解を反駁する長い記事を書いた。彼は、ヴィタリックが証明システムとそのパフォーマンスについて誤った仮定を立てており、RISC-V は「スケーラビリティ」と「保守性」の両方を考慮できず、最良の選択ではない可能性があると考えました。
以下は、Odaily Planet Daily が翻訳した levochka.eth のオリジナルコンテンツです。
そんな事はしないでください。
この計画は、証明システムとそのパフォーマンスについて誤った仮定を行っているため、適切ではありません。
仮説を検証する
私の理解する限り、このアプローチの主な議論は「スケーラビリティ」と「保守性」です。
まず、保守性についてお話ししたいと思います。
実際、すべての RISC-V zk-VM では、計算集約型の操作を処理するために「プリコンパイル」を使用する必要があります。 SP 1 のコンパイル済みリストはSuccinctのドキュメントに記載されており、EVM のほぼすべての重要な「計算」オペコードをカバーしていることがわかります。
したがって、ベース レイヤーの暗号化プリミティブに対するすべての変更には、新しい「回路」を記述してこれらのプリコンパイル用に監査する必要があり、これは厳しい制限となります。
実際、パフォーマンスが十分に良ければ、実行クライアントの「非 EVM」部分の保守は比較的容易になる可能性があります。パフォーマンスが十分に良いかどうかはわかりませんが、次の理由からこの部分にはあまり自信がありません。
「状態ツリーの計算」は、実際には、フレンドリーなプリコンパイル (Poseidon など) によって大幅に高速化できます。
しかし、デシリアライゼーションをエレガントかつ保守可能な方法で処理できるかどうかは明らかではありません。
さらに、「ブロック評価時間」に属する可能性があるものの、実際には「非 EVM」部分として分類する必要がある、扱いにくい詳細事項 (ガス計測やさまざまなチェックなど) がいくつかあり、これらの部分はメンテナンスのプレッシャーを受けやすくなることがよくあります。
次に、スケーラビリティについての部分です。
繰り返しますが、 RISC-V では、プリコンパイルを使用せずに EVM ワークロードを処理できる方法は絶対にありません。
したがって、元の記事の「最終的な証明時間は現在のプリコンパイル操作によって左右される」という記述は、技術的には正しいものの、過度に楽観的です。これは、将来プリコンパイルがなくなることを前提としていますが、実際には (この将来のシナリオでは) プリコンパイルは依然として存在し、EVM の計算集約型のオペコード (署名、ハッシュ、大規模な数値アナログ操作など) と完全に一致しています。
フィボナッチの例に関しては、非常に低レベルの詳細に立ち入らずに判断するのは難しいですが、その強みは少なくとも部分的には次の点に由来します。
「解釈」と「実行オーバーヘッド」の違い。
ループ アンローリング (RISC-V の「制御フロー」を削減します。Solidity でこれが実行できるかどうかはわかりませんが、単一のオペコードでも解釈のオーバーヘッドにより多くの制御フロー/メモリ アクセスが生成されます)。
より小さいデータ型を使用します。
ここで指摘しておきたいのは、ポイント 1 と 2 の利点を実現するには、「解釈のオーバーヘッド」を排除する必要があるということです。これは RISC-V の概念と一致していますが、これは現在議論している RISC-V ではなく、類似の「 (?)RISC-V」であり、契約の概念をサポートするなど、特定の追加機能が必要です。
ここで問題が起こります
つまり、ここにはいくつか問題があります。
保守性を向上させるには、EVM をコンパイルできる RISC-V (プリコンパイル付き) が必要です。これが基本的に現在の状況です。
スケーラビリティを向上させるには、まったく異なるもの、つまり「コントラクト」の概念を理解し、Ethereum ランタイムの制限と互換性があり、コントラクト コードを直接実行できる（「解釈のオーバーヘッド」なし）RISC-V のような新しいアーキテクチャが必要です。
今のところ、2 番目のケースを意味していると仮定します (投稿の残りの部分がそれを暗示しているように見えるため)。この環境外のすべてのコードは、依然として現在の RISC-V zkVM 言語で記述されるため、メンテナンスに大きな影響があることにご注意ください。
その他の可能性
高レベルの EVM オペコードからバイトコードをコンパイルできます。コンパイラは、生成されたプログラムが「スタック オーバーフロー」を防ぐなどの不変条件を保持することを保証する責任があります。これをバニラ EVM で実演してみたいと思います。適切にコンパイルされた SNARK は、契約の展開手順とともに提供できます。
特定の不変条件が成り立つという「正式な証明」を構築することもできます。私の知る限り、このアプローチ (「仮想化」ではなく) はすでに一部のブラウザのコンテキストで使用されています。この正式な証明の SNARK を生成することで、同様の結果を得ることができます。
もちろん、最も簡単な選択肢は、ただやってみること...
最小限の「連鎖」MMUの構築
投稿でこれを暗示しているかもしれませんが、思い出させてください。仮想化のオーバーヘッドを排除したい場合は、コンパイルされたコードを直接実行する必要があります。つまり、コントラクト (現在は実行可能プログラム) がカーネル (非 EVM 実装) メモリに書き込むのを何らかの方法で防止する必要があります。
したがって、何らかの「メモリ管理ユニット」(MMU) が必要になります。 「物理的な」メモリ空間はほぼ無限であるため、従来のコンピュータのページング メカニズムは必要ない場合もあります。この MMU は、（アーキテクチャ自体と同じ抽象化レベルにあるため）可能な限りスリムになるはずですが、一部の機能（「トランザクションの原子性」など）はこのレイヤーに移動される可能性があります。
この時点で、証明可能な EVM はこのアーキテクチャ上で実行されるカーネル プログラムになります。
RISC-Vは最良の選択ではないかもしれない
興味深いことに、これらすべての条件下では、このタスクに最適な「命令セットアーキテクチャ」(ISA) は RISC-V ではなく、 EOF-EVM のようなものになる可能性があり、その理由は次のとおりです。
「小さな」オペコードは実際には大量のメモリアクセスをもたらし、既存の証明方法では効率的に処理することが困難です。
分岐のオーバーヘッドを削減するために、最近の論文「Morgana」では、プリコンパイラ レベルのパフォーマンスで「静的ジャンプ」（ EOF に類似）を含むコードを証明する方法を示しています。
私の提案は、コントラクトを個別の実行可能ファイルとして実行できるようにする最小限の MMU を備えた、証明に適した新しいアーキテクチャを構築することです。 RISC-V であるべきではないと思いますが、むしろ SNARK プロトコルの制約に合わせて最適化された新しい ISA 、または EVM オペコードのサブセットを部分的に継承する ISA の方が良いかもしれません。ご存知のとおり、好むと好まざるとにかかわらず、プリコンパイルは今後も存在し続けるため、RISC-V ではここでは何の簡素化ももたらされません。
