Vitalik 対トップ開発者：Web3 仮想マシンを巡る〈バーチャルラウンドテーブル〉
TechFlow厳選深潮セレクト
Vitalik 対トップ開発者：Web3 仮想マシンを巡る〈バーチャルラウンドテーブル〉
EVMはエコシステムの互換性を追求し、RISC-Vはハードウェア効率に専念し、WASMは多言語開発を採用し、MoveVMは資産の安全性を重視し、FuelVMは性能の限界を突破する。
Web3業界の深掘り報道に専念し潮流を洞察各ブロックチェーンはそれぞれ独自の強みとストーリーを持っており、技術的にはブロックチェーンのコードモジュールはノード通信、コンセンサス、実行といった点でほぼ同じですが、それぞれが自分たちに最も適した技術やアルゴリズム、特にコンセンサスアルゴリズムや実行層の仮想マシン技術を採用しています。最近ではイーサリアムがEVMノードコードからRISC-V命令セットへの移行を検討していることで、これまであまり注目されてこなかった仮想マシンという技術領域が一般に注目されるようになりました。
先日、私はRISC-Vに関する解説記事をまとめ、その過去と未来について理解を深めていただきました。
EVMからRISC-Vへ？ RISC-Vの歴史とWeb3分野における応用について
本日は、より包括的かつ総合的に仮想マシンについて皆さんと共有したいと思います。私自身、仮想マシンに関する研究は浅いのですが、工夫してネット上の各プロジェクトの仮想マシン専門家たちの設計思想や評論を混成編集し、各仮想マシンの違いと共通点をご理解いただけるようにします。
素材を整理する中で、これらの見解の衝突は中国春秋戦国時代の百家争鳴に非常に似ていると感じました。そこでひらめき、現在流行のラウンドテーブル／スペース形式で彼らの発言を統合し、「仮想のラウンドテーブル会議」として「争鳴」というダイナミックさを際立たせたいと思います。君子は和して同ぜずです。
主要な主張を迅速に把握できるよう、以下に構造化された表で主流Web3仮想マシンの主要特性を横断的に比較し、全文に登場する10名以上の技術リーダーのディープディスカッションから要点を抽出します。
RISC-V、WASM、EVMなど9種類の方式のアーキテクチャ設計、パフォーマンス、実装課題などを網羅：（左右にスワイプして表全体を確認）
2024年にイーサリアムコミュニティで話題になったRISC-VによるEVM置き換え案は激しい議論を呼びました。ここでは各流派のVM設計者を仮想的に招待し、技術的本質、エコシステム適合性、ZKフレンドリー性などの観点から対話を展開します……
司会：まず、@VitalikButerin[1]、イーサリアム共同創設者をお迎えします。EVMは画期的な仮想マシンとして知られていますが、皆さんはご存じの通り、今後さらに良いイノベーションを目指されているとのこと。教えていただけますか？
@VitalikButerin：ネットユーザーの皆さん、こんにちは！ 私はVitalikです。中国のファンの方々からは「小v」と呼ばれることもあります（笑）。最近私が発表したEVM → RISC-Vへの提案についてはすでにご存じでしょう。詳しくはフォーラムの原文[2]（中国語版[3]）をご覧ください。ここでは要点だけ述べます：
・ RISC-Vをスマートコントラクト作成のための仮想マシン言語としてEVMに代えるというアイデアは確かに極端ですが――実際、それが唯一の方法かもしれません。
・ イーサリアムL1の拡張にはいくつかの制約がありますが、実行効率は主なボトルネックの一つであり、効率向上と実行層の大幅な簡素化が必要です。
・ 旧式のEVMコントラクトは引き続き動作し、新式のRISC-Vコントラクトと完全に双方向互換となります。実現方法は複数あります：
・ 最も破壊の少ない方法は両方の仮想マシンを同時にサポートすることです。
・ より極端な方法は、既存のEVMコントラクトをRISC-Vで記述されたEVMインタプリタコントラクトの呼び出しに変換し、既存のEVMコードを実行する方法です。
・ プロトコル上で「仮想マシンインタプリタ」の概念を明示的にサポートし、そのロジックをRISC-Vで記述することを要求します。EVMが最初の事例になります。
・ 将来的には他の言語（Moveが候補になる可能性あり）もサポートできます。
・ 開発体験への影響はほとんどなく、開発者が変化に気づかない可能性さえあります。
・ Nervos CKB VMはすでに先駆的な事例であり、本質的にRISC-Vの実装です[4]。
司会： @VitalikButerin さん、イーサリアムの最新計画を共有いただきありがとうございます。元スレッドでは多くの支持意見がありましたが、一部ではさらなる研究が必要との声もありました。今回のテーマは仮想マシンの優劣比較ですので、RISC-Vの実現可能性に関する詳細は割愛します。もちろん、このテーマに合致するゲストにも参加いただいています。
司会：続いて今日の第二のゲスト、@IAmNickDodson[5]、Fuel Network[6]創設者兼CEO、元ConsenSysメンバー、イーサリアムインフラやツール開発に深く関与し、GethやParityなどのイーサリアムクライアント最適化にも貢献した、VM設計と実装において経験豊富な人物をお迎えします。
@IAmNickDodson：まず、Vitalikさんの投稿はとても刺激的でした。私はイーサリアムメインネット上線前からEVMに触れてきましたが、当時から欠陥があることは認識していました。今でもそれらの問題は残っています。しかし、真の分散型アプリケーション構築の基盤となったことに感謝しています。[src[7]]
司会：なぜ他に既存のソリューションではなく、FuelVMを開発されたのですか？
@IAmNickDodson： FuelVM設計時に、MIPS、RISC-V、x86、ARMなどの命令セットアーキテクチャ（ISA）、WASMなどの仮想マシン方式、そしてブロックチェーン専用VMであるEVM、BitcoinScript、MoveVM、SVMなどを調査しました。それぞれに長所がありますが、私たちの要件を完全に満たすものはありませんでした。後ほどこれらの選定に対する分析と考察を述べますが、その前に、画面の前のみなさんにも次の三つの核心的問題を考えてみてください：このアーキテクチャはブロックチェーンのシナリオ向けに設計されていますか？ 対抗的ガス計量環境下でもパフォーマンスを維持できますか？ EVMに対して本当に改善されていますか？[src[8]]
司会：以上、自己紹介ありがとうございました。次に@IAmNickDodsonの調査順に代表的なVMプロジェクト／技術を選んで、皆さんの見解や分析をお聞かせください。異論があればいつでも参加してください。
MIPS/RISC-V
@IAmNickDodson：これらCPU命令セットは初期のマイクロチップや組み込み機器向けに設計されました。
長所：アーキテクチャがシンプル、ドキュメントが充実、オープンソースエコ、ネイティブマシンコードにコンパイル可能（追加処理が必要な場合あり）、多言語対応（Rust/Goなど）
短所：本質的にCPU命令セット（仮想計算アーキテクチャではない）、MIPS命令セットは過度に基礎的で、x86や専用VMの単一命令の機能を実現するのに多数のオペコードが必要（後述CISC参照）、対抗的ガス計量を考慮せず、ブロックチェーンシナリオ向けに最適化されておらず、ゼロ知識証明処理効率が低い（Starkware/Validaの研究参照）。
ZK技術によりノード計量の必要性が低下しても、高スループットシーンでは依然予測計算／共有証明が必要であり、DoS防止メカニズム（計量）は価値を持ち続けます。[src[9]]
Georgios Konstantopoulos[10]（Paradigm[11]パートナー兼CTO）：もし@VitalikButerinの提案が好きなら、過去数ヶ月間少しずつ開発してきたこのR55[12]もきっと気に入るはずです。[src[13]]
0xpedro.eth/acc[14]：R55を使うと純粋なRustでスマートコントラクトを書け、RISC-Vを使ってイーサリアムクライアント内で実行できます。通常SolidityはEVMバイトコードにコンパイルされますが、R55はRustをRISC-V命令にコンパイルします。これはハードウェア最適化の可能性を解放するオープンソースフレームワークです。イーサリアムでRustを使う？ 興味深いが厄介。RISC-V自体はイーサリアムの状態（ストレージ、呼び出し等）を知らないので、R55はシステムコールを追加します。RISC-Vのecallを使い、Rustコントラクトはストレージ読み取り（例：SLOAD）、コントラクト呼び出し、ログ送信が可能になり、Rustとイーサリアムがシームレスに接続されます。
R55はまだ開発中で、ガスやセキュリティ調整が必要ですが、将来が楽しみです。rollupやアプリチェーンはネイティブRustコントラクトを実行でき、zkEVMはRISC-Vを利用して暗号操作を高速化できます。私の見解では、Rustの安全性と速度はイーサリアムにとって強力な武器です。R55がイーサリアムにRust開発者の波をもたらすでしょうか？ まだ早いかもしれませんが、注目に値します。[src[15]]
Dave Rauchwerk[16]：@VitalikButerin これは素晴らしいアイデアです。RISC-Vの重要な利点の一つは明確な拡張性です。EVMの中心的で性能が重要なオペコードを加速するためのカスタムRISC-V命令セットを定義すべきです。RISC-Vのオープン性により、汎用CPU実行以外にASICやFPGAなどの専用ハードウェア実装が可能です。これにより、シリコン内でのEVMロジックの直接加速が可能となり、L1 TPSがソフトウェアインタプリタやJIT方式より桁違いに向上します。
検証性と安全性：従来の複雑なISAと比べ、RISC-Vのモジュラーで簡潔な設計は形式的検証が容易です。形式検証済みRISC-VコアがEVMロジックを実行すれば、高価値スマートコントラクトの安全性を強固に保証できます。EVM中心のカスタム命令で強化されたRISC-Vは、より高性能で安全、拡張性の高いLayer 1を実現する魅力的な道筋です。
また、既存EVM実装と潜在的なRISC-Vソフトウェアモデルのベンチマーク比較が必要です。revive/PolkaVMはとても良いように見えます—現在RV32EMにのみ対応していますが、議論に値します。[src[17]]
Koute[18]（Parity Technologies[19] PolkaVM担当責任者）：ちょうどPolkaVMが話題に出たので、PolkaVMとは何か、どのように動作するかを詳しく説明します。
PolkaVMは現在riscv64emacにZbb拡張を加えたものをサポートしていますが、大多数（すべて？）の他のRISC-V VMとは異なり、RISC-Vバイナリをそのまま実行することはできません（実際、RISC-V VMではありません！）。オフラインでは、通常のコンパイラでビルドした標準的なRISC-V ELFバイナリを抽出し、VM（RISC-Vのようなネイティブハードウェアではなく）に特化した、より制約が多く、効率的なカスタムバイトコードに変換します。私たちの考え方は、複雑性を可能な限りVM自体（オンチェーンで実行）から排除し、複雑性をできるだけオフラインツール（オフチェーン実行可能）に押し込み、不要な機能を削除することでセキュリティを高めることです（例えば、オリジナルRISC-Vでは任意アドレスにジャンプ可能ですが、PolkaVMバイトコードではコードアドレス空間が完全に仮想化され、どこにもジャンプできず、バイトコード自体もプログラムがアクセス可能なメモリにロードされません）。
パフォーマンス面では、裸のマシン性能に非常に近づいています[1]；最先端のWASM VMと同じくらい速く*、wasmtime並みですが、O(n)の再コンパイル時間を保証し、プログラムをネイティブコードに再コンパイルする速度を数百倍向上させています。具体的には、オリジナルPolkaVMバイトコードからプログラムをネイティブコードに再コンパイルする方が、キャッシュ済み再コンパイル成果物をハッシュ値で検索するよりもはるかに速い（つまり、プログラムの再コンパイルはそのハッシュ計算より速い）、しかも*ランタイム実行パフォーマンスを犠牲にしていません。
我々が主にRISC-Vを使用するのは、それがVMにとって特別に優れたバイトコードだからではなく（実際、それほど優れていない）、シンプルでサポートが良く、他のものに変換しやすいため、両方のメリットを得られます——優れたソフトウェア互換性（既存のコンパイラやプログラミング言語が使える、例えば最近QuakeをPolkaVMに移植しました）、かつカスタムで最適化されたバイトコードの恩恵も得られます（非常に高速なコンパイル、ネイティブに近いパフォーマンス、シンプルさ、カスタマイズ性）。[src[20]]
dilrong[21]：@VitalikButerin は、RISC-Vでイーサリアム仮想マシン（EVM）を置き換えることで、ゼロ知識（ZK）証明の効率が50〜100倍向上すると主張しています。しかし、RISC-Vが本当に優れているのでしょうか？ EVMは約9年安定稼働しており、実績のあるプラットフォームですが、RISC-Vはブロックチェーン実行情報において豊富な実践経験がありません。PolkaVMはすでにRISC-Vを採用していますが、メインネットで徹底的に検証されていないため、まだ十分に検証されていないと考えます。
EVMはスマートコントラクト実行に最適化されていますが、RISC-Vは汎用アーキテクチャとして設計されており、ブロックチェーンユースケース向けのカスタム最適化が不足している可能性があります。RISC-Vの多機能性により他のブロックチェーンのプログラミング言語が利用可能になりますが、Vitalik氏自身も既存のSolidityの改良の方が望ましいと指摘しています。エコシステム全体を新しいアーキテクチャに移行するのは困難な挑戦です。
ソフトウェアでRISC-Vを実装すると避けられないパフォーマンス低下が生じます。エミュレータを使ったソフトウェア実行はタスク処理能力に疑問を呈します。一方、RISC-Vハードウェアを採用すると巨大な移行コストがかかります。私はZK-EVMですでに現在のニーズを満たせると考えます。開発コスト、移行作業量、予期しないバグの可能性を考えると、EVMをRISC-Vに置き換えるのは現実的ではないようです。
確かにRISC-Vへの移行は潜在的利益をもたらすかもしれませんが、ZK-EVMの改良や既存EVMの最適化の方がより実用的で安定した代替案だと考えます。[src[22]]
Eduardo Bart[23]（Cartesi[24]のVMコア開発者）：ブロックチェーンアプリケーション向けRISC-V仮想マシンCartesi Machine[25]の開発に積極的に関与している者として、イーサリアム実行層でのRISC-V探索を支持する見解を共有したいと思います。
私の見解では、RISC-V採用の最大の利点の一つは成熟したツールとエコシステムに即座にアクセスできることです。完全にカスタムの環境を構築する必要がなく、RISC-Vを使うことで開発者（およびコアプロトコル）はGCCやLLVMなどのコンパイラ、デバッガ、ライブラリ、さらにはLinuxなどの完全なOSが数十年蓄積した経験を活用できます。新しく、実績の薄いツールチェーンと比べ、開発者の参入障壁が大きく下がり、コンパイラバグによるリスクも低減する可能性があります。これはRustやC++など標準バックエンドを通じてコンパイル可能な言語で書かれたコントラクトをイーサリアムターゲットとする目標に合致します。LLVMやGCCのバグを懸念する人には、CompCert[26]のように形式検証済みでRISC-Vターゲット可能なコンパイラでセキュリティを強化することが可能です。より広い視点では、RISC-V特権ISA仕様を含む仮想マシン（私が開発中のものなど）上で、正式検証済みのRISC-V OSカーネル（例：seL4[27]）を走らせアプリを実行することも可能で、OS環境での実行を必要とする複雑なアプリケーションにとっては有望な方向です。
一部の人々が提起するパフォーマンス懸念は根拠がありますが、解決可能です。私の経験では、正しく実装されたRISC-Vは実行パフォーマンスを犠牲にしません。u256操作は自然に複数命令に分解されますが、実際には、適切に最適化されたRISC-V仮想マシンでは、ほとんどの場合そのコストはパフォーマンスに大きな影響を与えません。さらに、RISC-V ISAレベルの最適化技術によりこれらのコストを大幅に削減できます。RISC-V ISAは十分な拡張性を持ち、ブロックチェーン向けカスタム拡張を追加して一般的な暗号操作（Keccak256など）を最適化できます。
将来の実行層をRISC-Vのように標準化され、オープンでサポートの整ったISAの上に構築することで、堅固な基盤が得られると考えます。それは既存のソフトウェアエコシステムを活用する道を提供し、開発者体験を簡素化し、RISC-V分野における将来のハードウェア進歩の恩恵を受ける可能性があります。
道は複雑ですが、RISC-Vは拡張性、ツール成熟度、長期メンテナンス性の潜在的利点により、将来のブロックチェーン実行環境として追求に値する方向だと信じます。現在、ブロックチェーン分野で多くの既存RISC-V仮想マシンが存在し、堅牢で直ちに実用可能なRISC-V実装が可能であることを証明しています。具体的には、Cartesi Machineが標準オープンISAの力を示していると考えます。これは安定し高性能なRISC-Vシミュレータで、標準RV64GC ISAを実装し、完全なLinuxソフトウェアスタックや未修正のRV64GC ELFバイナリを実行できます。決定的に重要なのは、浮動小数点演算を含め完全に決定的であること。興味があり実行能力を試したい人は、私のWebCM[28]実験をおすすめします。これはサーバーレス端末で、WebAssemblyにコンパイルされたCartesi Machineシミュレータが駆動するRISC-Vマシンをシミュレートし、ブラウザ内で仮想Linuxを直接実行します。
現在、L1提案はゼロ知識証明に集中していますが、Cartesiは現在、対話型詐欺証明を用い、決定的実行とステートMerkle証明によってオンチェーン検証を実現しています。検証メカニズムは異なりますが、CartesiはRISC-V上で検証可能で決定的な実行環境を構築できることは実現可能かつ価値あることだと確認しています。
もちろん、RISC-VをL1に直接統合しゼロ知識証明を行うには、ガス計量、正確なシステムコールの状態相互作用定義、RISC-V命令向けゼロ知識回路最適化など、独特で重大な課題があります。ゼロ知識証明特定環境下でのパフォーマンスもさらに調査が必要です。幸運にも、多くのRISC-Vゼロ知識仮想マシンプロジェクトがすでにこれらの側面を研究・開発しています。
実装戦略に関して、私は「極端な方法」を真剣に検討すべきと考えます。つまり、RISC-Vにコンパイルされた仮想マシンインタプリタの概念をプロトコルに組み込むことです。この方法により、イーサリアムのコアRISC-V仮想マシンを最小限に抑えつつ柔軟性を持たせ、EVM以外の異なる仮想マシンインタプリタも収容でき、開発者にVM開発でより多くの自由を与える道が開かれます。
要するに、RISC-Vのような標準を利用することで、ツール、開発者の慣れ、柔軟性、さらには将来的なハードウェア加速の可能性において巨大な利点があると信じます。Cartesi Machineでの経験は、RISC-Vが次世代検証可能ブロックチェーン計算の強力で実現可能な基盤であるという見解を強化しました。それがイーサリアムのコア実行層として真剣に検討されているのを見て、とてもわくわくしています。[src[29]]
Xuejie Xiao[30]：こんにちは、私はNervos CKB-VMのオリジナル設計者兼現在のメンテナーです。Nervosとしては、CKB-VMを選択したのは第一原理的思考によるものです：商用CPU上で軽量に実行できるシンプルで安全、高速なサンドボックスが欲しかったのです。結果として、CPU命令セットこそが最良の選択肢であり、RISC-Vが他の選択肢の中でも突出していたのです。もちろん他にもオープンソースRISC CPUコアはありますが、RISC-Vが最も注目されているため、ツールチェーン開発に多くの人が参加するという大きな利点があると考えました。
EVMとRISC-Vを議論する際、どちらにもプリコンパイルを含めるか、またはどちらも含めないかの比較をすべきです。プリコンパイル付きEVMと無しRISC-Vを比較したり、その逆を行ったりするのは不適切だと思います。JITやAOT RISC-V実装、あるいはAVX命令導入を仮定すれば、プリコンパイルなしRISC-V仮想マシンのEVMと同等のパフォーマンスが得られる可能性があります。
私たちの知る限り、RISC-Vは7年前の最良解であり、予見可能な将来においても最良の解であると考えています。誰かがRISC-Vをハードウェアソリューションだと言うならそうかもしれませんが、我々は純粋なソフトウェアでそれを実現しており、それでもニーズを完全に満たしています。この意味で、現状に満足しており、この道を継続します。[src[31]]
司会：CKB仮想マシン（CKB-VM）は、Nervos CKB上でスマートコントラクトを実行するために使用される、RISC-V命令セットに基づく仮想マシンで、Rustで記述されています。興味のある方は2018年に@Xuejie Xiaoが発表したAn Introduction to Nervos CKB-VM[32]をご覧ください。当時の考え方を共有しており、素晴らしい内容です！
ZKM[33]: @VitalikButerin のイーサリアム向けRISC-V計画は非常に大胆ですが、MIPSの成熟度と伝統は注目のダークホースです——低遅延ZK証明に非常に適した固定命令セットです。MIPSは40年間キーシステムを支えてきました——イーサリアムはこの安定性を活用し、同程度（あるいはそれ以上の）効率向上を実現しながら、過度に宣伝され成長途上のISAであるRISC-V採用のリスクを減らすことができます。MIPSはすでに検証済みなのになぜRISC-Vの成長痛に賭けるのでしょうか？[src[34]]
WebAssembly (WASM)
@IAmNickDodson：ブラウザ／分離環境で任意コードを実行するように設計：長所：多言語／環境対応、ネイティブコードにコンパイル可能、オープン仕様が明確、後に計量機能が追加（ただしオーバーヘッド増加）、短所：スタックベースアーキテクチャ（学術研究ではパフォーマンスが低いとされるが、弁証法的に見る必要あり）、ブロックチェーン専用設計ではない、計量機能は後付けパッチでパフォーマンスに影響、デバッグ体験が極めて悪い。
理論的にはWASMは良い選択肢ですが、実際の開発ではデバッグが非常に苦痛です。WASMに完全依存する複数チームと交流しましたが、全員が後悔していると述べていました。比較するとRISC-V/MIPSの方が理解しやすく、それがSuccinct/RISC0などがそれらを選んだ理由かもしれません。[src[35]]
Peter Kieltyka[36]（Sequence[37]共同創設者）：@VitalikButerin これは少し飛躍しているかもしれませんが、Offchain Labsチームが開発したEVM+/Stylusを将来のL1実行層として検討してみてはいかがでしょうか。EVMバイトコードと完全互換で、WASM VM上で動作し、WASM対応言語（例：Rust）をサポートし、パフォーマンスが大幅に向上します。同時にランタイムでEVMバイトコードコントラクトと完全に相互運用可能です。互換性を保ちながら最も簡単なアップグレードパスのように感じます。[src[38]]
Xuejie Xiao[39]：多くの人々はWASMがブロックチェーン仮想マシンの理想形だと考えています。主にWASMがソフトウェア実装向けに設計されたからです（これが意味をなすなら、一旦無視しましょう）。WASM誕生前にJavaScriptのサブセットであるasm.jsが一時流行していたことをご存じですか？ asm.jsは後にWASMに進化し、何故かasm.jsの当初のビジョンよりも遥かに巨大なものになりました（失礼ながら、現在のWASMはasm.jsよりもむしろきれいに新設計されたJVMのように見える）。しかし、asm.jsの当初の目的を忘れてはなりません：JITが90％の時間しか達成できないのに対し、ネイティブCPU命令に確定的にマッピングできるソフトウェアIRへの渇望です。RISC-Vがその目的を達成できるなら、ソフトウェア仮想マシンとして非常に適していると思います。[src[40]]
Hazel Hu[41]（Delphinus Lab[42]）：@VitalikButerin はRISC-Vを強く推していますが、ZK仮想マシンにはこれだけの技術ルートがあるわけではありません。ZK仮想マシンはETH専属でもなく、ETHエコよりも大きくなる可能性のある独立した存在です。ETHはZKVMを必要としますが、ZKVMはイーサリアムエコに限定されません。[src[43]]
ZKシステムはRISC、つまり精簡命令セットを使用します。ここには二つの選択肢があります。一つはCairoのようにZK特有の言語でカスタム命令セットを構築する方法（学習曲線が急すぎる）、もう一つは既存の命令セットを使用する方法です。RISC-Vはその一つです。@RiscZero[44]、@SuccinctLabs[45]、@NexusLabs[46]、@a16z[47]が支援するJoltはいずれもRISC-VベースのZK仮想マシンプロジェクトです。
2018年にはイーサリアムエコでeWASMプロジェクトが開始され、EVMの発明者@gavofyork[48]もWASMによるEVM置き換えの可能性を示唆しました。Polygon創設者@sandeepnailwal[49]もWASMの熱心な支持者でした。しかし、eWASMは工学的複雑性、優先順位の調整、L2ソリューションの台頭により広く採用されず、その後のロードマップで棚上げされました。
@VitalikButerin が提案を発表後、Zebra創設者@shumochu[50]、1kxリサーチパートナー@_weidai[51]らは、WASMの方がイーサリアム実行層に適していると指摘しました。理由は以下の通り：
手順が簡単：RISC-Vはハードウェア実装向けに設計されており、中間表現として使うにはガス消費や実行フロー制御のための仮想マシン層構築が必要で、複雑さが増します。
静的解析がしやすい：WASMにはジャンプ命令がなく、コード構造がシンプルで、コントラクト属性の検証が容易です。
言語サポートが広い：現在のほぼすべての主要プログラミング言語でプログラムをWASMにコンパイルでき、学習コストが大幅に下がります。Miden創設者@bobbinth[52]はさらに、ZKフレンドリー性を追求するならRISC-Vより優れた命令セットを設計するか、WASMコンポーネントモデルを使うべきだと提言しています。[src[53]]
私の所属する@Delphinuslab[54]は業界初のZKWASM仮想マシンをオープンソース化しました。現在はSolidity SDKのみですが、実際にはZKVMのコントラクト決済はどのチェーンにも可能で、将来はSolana、SuiなどのEVM非互換チェーンにも拡大可能です。
ZKWASM仮想マシンには一体どんな用途があるのか？
1. 開発者が最も馴染みのあるプログラミング言語でブロックチェーン世界に入れるようにする。全員にSolidity（およびさらに複雑でニッチなブロックチェーン言語）やRustを学ばせる必要がない
2. より多くのWeb2.5ウェブミニプログラムがワンクリックでブロックチェーンに接続できるようにする。完全に実現すれば、数千のブラウザミニプログラムを迅速にブロックチェーンに展開できる
3. 不可能三角を打破し、分散性、効率、安全のバランスを実現する。[src[55]]
x86/ARM
@IAmNickDodson：この二大CPU命令セットはともにオープンソースではありません：ARMはRISC精簡命令セット、x86はCISC複雑命令セットに属します。CPUハードウェアの進化とともに、両者とも極めて複雑になっています。注目すべきは、CISCがCPU分野でRISCに徐々に取って代わられているにもかかわらず、ブロックチェーンシナリオではCISCの方がむしろ優位であるということです。[src[56]]
Xuejie Xiao[57]：x64は重すぎる（RISC-Vを初めて試したとき、x64でブロックチェーン仮想マシンを構築しようとしている人がいた！）、Armはライセンス問題があるかもしれないし、ないかもしれません。[src[58]]
Bitcoin Script
@IAmNickDodson：初のブロックチェーンVM、ビットコインプログラミング専用設計：
長所：ブロックチェーンとビットコインタンザクションモデルに特化、対抗的環境に適応、マルチシグなどの基本操作をサポート
短所：機能が極めて限定的、ビットコインネットワーク処理能力に大きく制約される
我々はBitcoin ScriptからP2SH（スクリプトハッシュへの支払い）という強力なパラダイム——条件プログラミングを継承しました。この刈り取り可能なプログラムパラダイム（実行後フルノードから削除可能）は、場外取引／マルチシグウォレット／商品オークションなど多様なシナリオをサポートできます。ビットコインアーキテクチャは、VM設計はトランザクションモデルと深く協調する必要があることを示唆しています。[src[59]]
MoveVM
@IAmNickDodson：Metaチームが開発したブロックチェーン専用VM、セキュリティを重視：
長所：ブロックチェーンネイティブ設計、対抗的計量サポート、専用言語Moveとの連携
短所：安全性確保のため大量の状態柔軟性を犠牲に、過度なRISC化（前述分析参照）、エコ分裂（SUI/Aptosで互換性のない変種存在）
2020-21年、Moveエコはほぼ停滞しました。我々は他人のアーキテクチャに縛られて革新できないことを避けるため、採用を見送りました。その「安全」特性はRISCシステムの包装に過ぎず、酷いコード作成を防げません。当時の形式検証は単純なメソッドにしか適用できず、完全アプリには適用できず、費用対効果が極めて低かったのです。[src[60]]
EVM
@IAmNickDodson：ブロックチェーン界のPHPと称されるEVMは、数千億ドル規模のスマートコントラクトを支えています：
長所：ブロックチェーンネイティブ設計、完備された計量メカニズム、全エコ互換、Solidity言語は長年の実績
短所：256ビットワードサイズ設計、呼び出し／コントラクトのみサポート、スクリプト機能不足、条件プログラミング不足（P2SH相当物なし）、過度に単純化されたトランザクションモデル、非効率（ワードサイズとオペコード設計により大量の計算浪費）、高度な状態化設計によりストレージアクセスがパフォーマンスボトルネック
一部チームは新型データベースや状態アクセス方式で問題を解決したと主張していますが、本質的にこれらの計算は回避可能でした。EVMはエコを急速に構築するには適していますが、トランザクションモデルや設計空間の観点からは革新が不足しています。Vitalik氏の発言はまさにその点に気づいているのでしょう。[src[61]]
Alex Vlasov[62]：RISC-Vが本当にEVMより優れているかどうかは不明です。EVMはスタックベースなので、レジスタファイルが小さいです。EVMは256ビット数字を扱いますが、小さめの値が支配的ならこれが問題になるかもしれません。しかし、証明器は実際の実行トレースにアクセスできるため、小さな値に対してより軽量な実装オプション（例：32ビット値のバイト分解は256ビット値より行数が少なくなる）を選べます。[src[63]]
もう一つはスマートコントラクトの形式検証コストです。EVMの命令セット（ISA）はRISC-Vより限定的であり、そのためF/V全体はより複雑になります。RISC-Vスマートコントラクトは通常、より多くのループとメモリ操作を含み、これらは両方ともF/Vに問題を引き起こします。
例えば、ある研究（/www.cs.utexas.edu/~isil/solis.pdf[64]）によると、約5分の1のEVMスマートコントラクトが一つ以上のループを含んでいます。EVMは256ビット値を扱うため、RISC-Vコードではより多くのループが必要です。ループ展開しても、より大きなSMTクエリにつながります。
RISC-Vはより豊かなメモリモデルを持ち、より多くのメモリ操作があるはずです（例：EVMは1024個の256ビットスタックを持つが、EVMは16-32個の32/64ビットレジスタを持つ）。したがって、エイリアス（文法的に異なる二つの式が同一メモリ位置を指す）がより深刻な問題になります。これは静的解析、例えばコールグラフ再構成、ポインタ解析などに影響します。
私の予想では、ループ／エイリアスを含むRISC-Vスマートコントラクトに対して、EVMスマートコントラクトと比較して形式的推論がより困難になると予想されます。[src[65]]
SVM
@IAmNickDodson：Solana仮想マシンは近年台頭：
長所：ブロックチェーンネイティブ設計、対抗的計量サポート、ネイティブコードにコンパイル可能、高性能設計
短所：アーキテクチャが複雑で理解しにくく、Rustなどの言語開発体験が悪く、成熟した専用言語が不足
SVMを選ばなかった主な理由はトランザクションモデルの前提——イーサリアムのようなシンプル設計でスピード重視だが複雑な多方決済を求めていない——が、私たちの計画するトランザクションモデルと一致しなかったためです。[src[66]]
CarioVM
Akash Balasubramani（StarkWareエコマネージャー）：@IAmNickDodson 素晴らしい分析！ CarioVMも含めていたらもっと良かったですね。[src[67]]
@IAmNickDodson：含まれなかったのは2020/21年の調査時にまだ私たちの視野に入っていなかったからです。私はCairoとSTARK技術の熱烈なファンです。[src[68]]
Eli Ben-Sasson（StarkWare共同創設者）： @IAmNickDodson 素晴らしいディスカッション！ 唯一の提案はCairo分析を加えることです。補足させてください： 長所：ブロックチェーン＋zkSTARK効率に特化設計、線形型安全、効率的なガス計量（Sierra）、短所：知名度／ツールチェーン整備度が低い :) [src[69]]
司会：皆さんの素晴らしいコメントに感謝します。最終的にどのような結論に至りましたか？ 皆さんと共有できる洞察は何ですか？
@IAmNickDodson：すべてのVMを調査した結果、仮想マシン自体の重要性が過大評価されていることに気づきました。理論的にはこれらVMは（BitcoinScriptを除き）異なる効率で必要な計算を完了できます。本当に重要なのはVMとトランザクションモデルの協調設計です。多くのチェーンはVMに過度に注目し、トランザクションモデルを無視しています——それがブロックチェーン挙動の核心です。[src[70]]
FuelVMの独自性はまさにここにあり、これらはFuelVMの複合最適化です[src[71]]：
・ メモリ効率（共有メモリコンテキストによりコピー削減）
・ レジスタとメモリの賢明な利用（例：完全なトランザクションを可視メモリに置き、ランタイム自己検査を実現）
・ IOアクセスの極限まで削減
・ トランザクション層の能力強化（トランザクションがより多くを担い、VMがより少ない）
・ トランザクションモデルが状態アクセスとマルチアセット／マルチ条件／マルチ実行モードの流れを両立
・ CISCとRISCの黄金律的バランス
・ グローバル状態木なし（UTXOモデルは時間巻き戻しで自然に二重使用防止）
・ すべてのオペコードが計量効率最適化
・ 述語条件プログラミングなど多様なプログラムタイプをサポート
・ Sway言語がRustのパフォーマンスとSolidityの開発体験を兼ね備える
従来の認識では、ブロックチェーンVMは極めて簡潔な命令（セキュリティとネイティブコードコンパイルの観点から）を追求すべきとされています。しかし問題は、楽観的検証シナリオでは各操作に計量が必要なことです。VMがシンプルであればあるほど、同じ機能を実現するために必要なオペコードが増え、オンチェーン計量計算量も増えます。そのためFuelVMは、より少ない操作でより多くの機能を実現するため、より効率的なオペコードを設計する選択をしました。FuelVMをCISCとRISCの融合体と見なすことができます。より多くの命令は通常バイトコードサイズ増加を意味しますが（帯域制限シナリオでは影響が出るが、圧縮で緩和可能）、楽観的検証の計量オーバーヘッドを大幅に削減し、開発者に強力なツールを提供できます。ZKシナリオでも、複合操作はより良い最適化効果を得られます。シンプル ≠ より良い。[src[72]]
司会：他のVM技術選定を検討しているエンジニアに何か伝えたいことはありますか？ 例えばイーサリアムとか？
@IAmNickDodson：もしイーサリアムがRISCルートを選ぶなら、トランザクションモデルも同時に検討する必要があります。VMはパズルの一部にすぎません——RISC-Vはトークン会計、スマートコントラクトパラダイムの突破、全人類とロボットを支える高性能ブロックチェーンアプリ構築などには対応できません。Fuelは流行ではなく正しいことを選ぶことで、継続的な苦痛（私たちのトークンを見ればわかります）を伴いますが、オープンソースブロックチェーンエコに新たな設計パラダイムを提供しています。
ブロックチェーン構築を検討中で、ブロックチェーン本質に深く適合するアーキテクチャが必要なら、FuelVM/Swayを検討してみてください。パフォーマンスは驚異的です：M4プロセッサで15万TPS、10ミリ秒でソフト確認、トースターからスーパーコンピュータまで幅広く対応。FuelVMについて詳しく知りたい方は、Why the FuelVM is the EVM but greatly improved and what this means for the future of blockchain[73]をご覧ください。
Xuejie Xiao[74]：ZKに関して別の一点。これは個人的なゼロ知識に対する見解ですが、RISC-Vにはゼロ知識に関連する二つの異なる用途があります：1）ZK証明されるプログラムを表現する仮想マシン／IR、2）ZK検証器が動作する基盤プラットフォーム。単純だが正確でない類推として、ゼロ知識証明アルゴリズムの上に仮想マシン（ポイント1）、の下に仮想マシン（ポイント2）があると言えます。これらは別々に議論すべきです。
Nervos CKB-VMは厳格なプリコンパイルなし設計を採用しており、第2点に完全に適合しています：ZK検証器コードをRISC-Vコードにコンパイルし、Nervos CKB-VM上でそのZK検証器を実行できます。この意味で、Nervos CKBは任意のZKソリューションを柔軟にサポートできます。言い換えれば、Nervos CKB-VMはZKアルゴリズムの下の仮想マシン（VM）として優れた選択だと考えます。
第一点は別個のユースケースとして、私はゼロ知識証明の内部メカニズムにあまり詳しくないため、RISC-Vが適切なソリューションかどうか判断できません。ゼロ知識証明アルゴリズムの特定の特性が、ゼロ知識証明アルゴリズムの上に仮想マシンを構築する選択に影響するかもしれないと疑っています。
私は間違っているかもしれませんが、@VitalikButerin はここで第2点、つまりZKアルゴリズムの下の適切なVMについて話しているように感じます。それならば、RISC-VがZK証明に適しているか否かを議論する必要はないのではないでしょうか？
porter | ZKsync[75]：ZKsyncは以下の変更の準備ができています： 新しい証明システムBoojum2はすでにRISC-Vです。いくつかのことが、ZKsyncだけでなくイーサリアム全体に利益をもたらします： 全新のSolidity → LLVM → RISC-Vコンパイラが近日登場予定です。[src[76]]
@alacheng[77]: ZK方向（L1を拡張し、ノード検証時に再実行不要の場合、これらのzkvmがzkevmに取って代わります）、@SuccinctLabs[78]と@RiscZero[79]はいずれもzk risc-v vm、@UntoLabs[80]はsolエコのコア開発者が立ち上げたチェーンで、実行層VMはrisc-v vmです。[src[81]]
司会：各位の素晴らしいシェアに心より感謝します。今回の「仮想ラウンドテーブル会議」はここまでです。時間と篇幅の都合で、他にも特色ある仮想マシンを一つ一つ紹介できず、将来的に更新や第二回を追加するかもしれません。詳細をご希望の方は、各見解／発言末尾の[src]をクリックしてください。
まとめ
この「仮想ラウンドテーブル会議」で、異なるブロックチェーンプロジェクトが全く異なる技術ルートを選んでいることがわかりました——EVMはエコ互換性を追求、RISC-Vはハードウェア効率に集中、WASMは多言語開発を擁護、MoveVMは資産安全を強調、FuelVMはパフォーマンス限界を突破。これはまさに、ブロックチェーンの世界に普遍的に最適な解はなく、それぞれの発展目標に最も適した妥協点があることを示しています
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
