作者：PSE Trading Analyst @cryptohawk

TL;DR

1.仮想マシンは、プログラムに実行環境を提供するソフトウェアシミュレーションのコンピュータシステムです。さまざまなハードウェアデバイスをシミュレートし、プログラムを制御された互換性のある環境で実行できます。

2.イーサリアム仮想マシン（EVM）は、イーサリアムのスマートコントラクトを実行するためのスタックベースの仮想マシンです。zkEVMはEVMの等価性/互換性において一定のzk-proof生成効率の最適化を行っています。

zkVMはEVMの等価性/互換性を放棄し、zkに優しい優先度を高めています。

プライバシーzkVMはzkVMにネイティブプライバシー機能を追加したものです。

SVM、FuelVM、MoveVMの共通点は、並行実行を通じて性能の極致を追求していますが、設計の詳細にはそれぞれの特徴があります。

ESC VM、BitVMはそれぞれETHとBTCチェーン上で一定の革新的な計算レイヤーの実験を行っていますが、現状では実際のニーズは低いです。

3.EVMの巨大なユーザーエコシステムは、EVMを放棄するブロックチェーンネットワークが短期間で競争することが難しいことを決定づけています。そのため、非EVMエコシステムはトランスレーター/コンパイラー/バイトコードインタープリター、さらにはVM互換レイヤーを通じてEVMエコシステムのユーザーを引き入れ、非EVMの仮想マシンの特性を利用して新しいエコシステムの物語を構築することが、成功への必須の道となります。

1.1 VMとは？

仮想マシン（VM）は、計算リソースを仮想化するための構成要素であり、アプリケーションやオペレーティングシステムを実行するための機能をほぼコンピュータと同じように持っています。この仮想マシンの概念は新しいものではなく、この技術は多くの技術エコシステムで広く使用されています。

ブロックチェーンの文脈において、仮想マシン（VM）はプログラムを実行するソフトウェアであり、通常はブロックチェーンのスマートコントラクトを実行するためのランタイム環境と呼ばれます。仮想マシンは通常、さまざまなハードウェアデバイスをシミュレートすることで、仮想のコンピュータ環境を提供します。異なる仮想マシンがシミュレートできるハードウェアデバイスは異なりますが、通常はCPU、メモリ、ハードディスク、ネットワークインターフェースなどが含まれます。チェーン上のトランザクションが提出されると、仮想マシンはそのトランザクションを処理し、そのトランザクションの実行によって影響を受けるブロックチェーンの状態を更新します（ネットワーク全体の現在のグローバル状態）。ネットワーク状態を変更する具体的なルールはVMによって定義されます。トランザクションを処理する際、VMはスマートコントラクトコードをノード/バリデーターのハードウェアが実行できる形式に変換します。

VMの中で最も重要なコアはLLVM（low-level-virtual-machine）であり、コンパイラの最も重要なコアと見なすことができます。図は原始EVMの運用方案であり、スマートコントラクトはLLVM IRの中間コードを通じて変換され、バイトコードに変換されます。これらのバイトコードはブロックチェーン上に保存され、スマートコントラクトが呼び出されると、バイトコードは対応するオペコードに変換され、EVMとノードハードウェアによって実行されます。

1.2 主流のVM

1.2.1 EVM------ブロックチェーンVMの中で一石を投じ、EVMが独占的に八斗を占め、残りは二斗を分け合う

代表プロジェクト：Optimism、Arbitrum

現在、業界内で開発者とユーザーの活発度が最も高いブロックチェーンエコシステムとして、イーサリアム仮想マシンEVMはスタックベースの仮想マシンであり、CPU、メモリ、ストレージ、スタックなどのハードウェアデバイスをシミュレートすることで、スマートコントラクトの命令を実行し、スマートコントラクトの状態とデータを保存するための仮想コンピュータ環境を提供します。EVMの命令セットには、算術操作、論理操作、ストレージ操作、ジャンプ操作など、さまざまなオペコードが含まれています。

EVMがシミュレートするメモリとストレージは、スマートコントラクトの状態とデータを保存するためのデバイスです。EVMはメモリとストレージを二つの異なる領域と見なし、メモリとストレージを読み書きすることでスマートコントラクトの状態とデータにアクセスします。

EVMがシミュレートするスタックは、命令のオペランドと結果を保存するために使用されます。EVMの命令セットの大多数の命令はスタックベースであり、スタックからオペランドを読み取り、結果をスタックに戻します。

EVMの設計プロセスは明らかにボトムアップであり、まずシミュレートするハードウェア環境（スタック、メモリ）を決定し、それに基づいて独自のアセンブリ命令セット（オペコード）とバイトコードを設計しました。イーサリアムコミュニティはEVMの実行効率のために二つのコンパイル型の高級言語、SolidityとVyperを設計しました。Solidityは言うまでもなく、VyperはVitalikがSolidityに存在するいくつかの欠陥を改善した後に設計されたEVM高級言語ですが、コミュニティではあまり高い採用度を得られず、次第に歴史の舞台から姿を消しました。

1.2.2 zkEVM------私は全てを求める：EVM環境の互換性 + グローバル状態ルート変換生成zk-proofのサポート

代表プロジェクト：Taiko、Scroll、Polygon zkEVM

EVMは構築時にzk-proof計算を考慮していなかったため、特に特殊なオペコード、スタックベースのアーキテクチャ、ストレージコスト、証明コストなどの面で証明回路に対して友好的ではありませんでした。一方、zkEVMはzk-proof計算に互換性を持たせた方法でスマートコントラクトを実行する仮想マシンであり、EVMの実行プロセスをzk-proof/validity-proofを通じてより効率的かつ低コストで検証できるようにします。OP Rollupの実行レイヤーがEVMをそのままコピーするだけで済むのに対し、EVMをZKに友好的に構築することはZK Rollupの追加の課題です。

ZK-rollupsはイーサリアム仮想マシン（EVM）との互換性が容易ではありません。回路内で一般的なEVM計算を証明することは、単純な計算（前述のトークン転送など）を証明するよりも難しく、リソースを多く消費します。

しかし、ゼロ知識技術の進歩は、EVM計算をゼロ知識証明に包むことへの関心を再燃させました。これらの努力は、プログラム実行の正確性を効果的に検証できるゼロ知識EVM（zkEVM）実装を作成することを目指しています。

EVMと同様に、zkEVMは特定の入力に対して計算を実行した後、状態間で変換を行います。異なる点は、zkEVMがプログラム実行の各ステップの正確性を検証するためのゼロ知識証明を作成することです。有効性証明は、仮想マシンの状態（メモリ、スタック、ストレージ）と計算自体に関わる操作の正確性を検証できます（つまり、その操作が正しいオペコードを呼び出し、それを正しく実行したかどうか）。

アイデアは素晴らしいですが、現実は厳しいです。現在、RollupはZKに友好的でありながらEVMとの互換性（さらには等価性）を両立させることが難しい状況です。つまり、イーサリアムL1の実行レイヤーを可能な限り完全にコピーし、ハッシュ、状態ツリー、トランザクションツリー、事前コンパイルなどを含め、イーサリアムL1の実行クライアントがそのまま使用できるようにするか、EVMの互換性を放棄し、既存のオペコードを再構築して回路内で証明/検証を行い、スマートコントラクトを実行できるようにする必要があります。

1.2.3 zkVM------魚と熊掌は両立できない：zk-proof効率指向の非EVM仮想マシン

代表プロジェクト：Starknet、Zksync、RISC ZERO

zkVMはEVMの互換性を放棄し、データ証明と状態更新を核心目標とし、暗号学と高級言語の間に共通の合意を見出し、さまざまなアプリケーションに対して一般的なフレームワークを提供します。

StarkwareはZK分野で早期にスタートし、技術的な蓄積が豊富で、一定の技術的先進性を持っています。彼は代表的なZK中心主義の技術アーキテクチャであり、ZKを中心にCairo VMとCairoの言語を構築しています。その欠点は、Cairoの学習コストが高いことです。

ZKsyncのフレームワークはEVMとZKの両方の特徴を兼ね備えており、Solidityと独自に開発した回路言語Zincを融合させ、コンパイラ内部で両者をIRレベルで統一しています。その利点は、コンパイラコアのLLVMが多様な言語に対応できることです。

RISC ZeroはRISC-Vアーキテクチャを基にしたシミュレーターを使用して、プログラマーがRust、C/C++、Goなどの一般的な言語でzkVM用のプログラムを書くことを可能にします。これにより、アプリケーションロジックはSolidityで表現できる内容に制限されず、チェーンに依存しないコードを書くことができます。

1.2.4 プライバシーzkVM------zkに優しい + ネイティブプライバシーサポートがエコシステムの新たな火花を点火する試み

代表プロジェクト：Aleo、Ola、Polygon Miden

ブロックチェーンは公共台帳システムであり、すべての取引がチェーン上で行われるため、アドレスやアカウントに関連する資産情報の状態変化は公開され透明です。したがって、拡張ソリューションに取り組むだけでなく、一部のブロックチェーンチームは次に実現すべき重要な機能はプライバシーであると信じています。

プライバシーzkVMはzkに優しい拡張サポートの特性を除去し、そのプログラミング言語がネイティブにサポートするプライバシー特性により、上層アプリケーション開発者がプライバシー関連のdappを開発できるようにします。これにより、MEV問題の根本的な解決やユーザーデータの所有権の保護など、新しいアプリケーションシナリオと壮大な物語がもたらされるでしょう。もちろん、プライバシーzkVMの設計上の複雑さは、より大規模な技術チームによる実現を必要とし、実現には数年の時間が必要かもしれません。

1.2.5 SVM------潮が引いた後にも残る余燼：性能設計が極致に達した実行環境

代表プロジェクト：Eclipse Mainnet、Nitro、MakerDAO Chain(maybe)

SVM、すなわちSolana仮想マシンは、高性能な実行環境を主打ちし、スマートコントラクトは主にRust言語で記述されます。単一スレッド計算のEVMやEOS WASM実行環境に対して、Solanaはトランザクションが実行時に読み書きするすべての状態を記述することを要求することで、SVMは非重複トランザクションと同じ状態を読み取るトランザクションの並行実行を実現しました。

さらに、大量のトランザクションブロックを迅速に検証/ブロードキャストするために、Solanaネットワーク上のトランザクション検証プロセスでは、CPU設計で一般的なパイプライン最適化が広く使用されています。これは、一連のステップ処理の入力データフローを満たし、各ステップに異なるハードウェアが責任を持つ状況に対応します。典型的な比喩は洗濯機と乾燥機であり、順番に洗濯/乾燥/折りたたむ多くの衣服を処理します。洗濯は乾燥の前に行われ、乾燥の前に折りたたむ必要がありますが、これらの三つの操作はそれぞれ別々のユニットによって実行されます。

さらに、SVMはレジスタに基づいており、EVMよりもはるかに小さい命令セットを持っているため、SVMの実行はZKで証明するのが容易です。楽観的Rollupにとって、レジスタベースの設計はチェックポイントを設定するのが容易になります。

1.2.6 Fuel VM------buffが積まれた：UTXOフレームワーク下の並行仮想マシン

代表プロジェクト：Fuel

Fuel VMはEVM、Solana、WASM、BTC & Cosmos技術フレームワークに基づく改良であり、EVMと比較して以下の特徴があります：

最も独特なのは、FuelはSVMのようにアクセスリスト（access lists）を設定し、非重複トランザクションの並行実行能力を持つだけでなく、UTXOモデルを採用し、トークンUTXOとコントラクトUTXOを分けることで、アクセス効率と計算スループットをさらに向上させています。

さらに、Fuel VMは独自のドメイン特化言語SwayとサポートツールチェーンForcを通じて強力でスムーズな開発者体験を提供し、その開発環境はSolidityなどのスマートコントラクト言語の利点を保持しつつ、Rustツールエコシステムから導入された例を採用しています。

将来的にはFuel VMはSway言語のアップグレード内容を実現し、バイトコードサイズに関するコンパイラ最適化、Swayがより多くのバックエンドをサポート（EVMバックエンドはすでに開発中）、抽象化がより経済的になること、より多くのアプリケーションがSolidity/VyperからSwayに移行すること、コンパイラレベルの再入分析の改善などが含まれます。

1.2.7 ESC VM------Ordinal/Smartweaveの後継者：イーサリアム上の計算レイヤー

代表プロジェクト：Ethscriptions Protocol

ESC VM、すなわちEthscriptions Virtual Machineは、Ethscriptions Protocolが提案したスマートコントラクトのソリューションです。Ethscriptions Protocol自体はイーサリアムチェーン上でBTC Ordinalに類似したプロトコルであり、スマートコントラクトやL2とは異なる低コストの代替案を探求することに焦点を当てています。

Ethscriptionsは、ユーザーが極めて低コストでスマートコントラクトのストレージと実行を回避できるようにし、事前に合意されたプロトコルルールを通じてTx内のcalldataに計算を適用します。簡単に言えば、成功したイーサリアムトランザクションがあり、そのcalldataが規定の有効なデータ仕様に合致し、唯一で「to」アドレスが0でない場合、合法的にEthscriptionが作成されたと見なされ、「from」アドレスが作成者、「to」アドレスが所有者となります。

設計当初、各EthscriptionはNFTの形式に偏っており、例えば画像NFTは画像内容をBase64形式でcalldataに直接書き込むことができます：

最近人気のあるethsは、brc-20のプロトコル仕様を参考にして作成されたEthscriptionです：

ESC VMが導入するスマートコントラクトは「ダムコントラクト」（Dumb Contract）と呼ばれ、論理コントラクトとして公示されますが、EVM形式でチェーン上の相互作用を行うことはありません。また、ESC VMは「計算機命令」という特別な形式を追加し、この形式で作成されたethscriptionsはESC VMによってダムコントラクトと相互作用することが認識されます。例えば、Deploy - ダムコントラクトをデプロイ、Call - ダムコントラクトを呼び出すなどです。

このソリューションにはいくつかの制限があります。一つは「ダムコントラクト」の関数がpayableではないため、ダムコントラクトを通じてETHを送信したい場合は「ブリッジコントラクト」を通じて行う必要があり、「ブリッジコントラクト」自体には権限の乱用や資産の盗用リスクが存在します。二つ目はエコシステムに入場制限があり、任意のダムコントラクトの作成が許可されず、そのコードはEthscriptions Protocolのガバナンス提案を通じて定義される必要があります。

まとめると、ESC VMはイーサリアムL1をデータストレージ層として使用し、その上に計算層を構築し、コントラクトロジック、コントラクト呼び出し、コントラクト呼び出しなどのデータ内容をイーサリアムtxのcalldata内に配置することで実現されます。ESC VMのグローバル状態コンセンサスはESC VMクライアントのコンセンサスであり、ArweaveのSmartWeave実現ロジックに近似していますが、SmartWeaveのデータストレージ層はArweaveです。

1.2.8 Bit VM------興味深い研究実験：BTC上のピアツーピア実行チャネル

代表プロジェクト：ZeroSync

ZeroSyncの創設者Robin Linusは10月9日に「BitVM：Compute Anything On Bitcoin」というホワイトペーパーを発表しました。正確には、これはVMではなく、ビットコインチェーン上に契約を保存し、その契約の論理実行がオフチェーンで行われるチューリング完全な計算空間を作成しようとしています。相手が契約違反をしたと考えた場合、自分はチェーン上で挑戦を開始でき、相手が正しい応答をできない場合、自分は契約内のすべての資金を持っていくことができます。

その利点は、ビットコインプロトコルに対して何の変更も必要なく、オペコードも新たに必要なく、ソフトフォークも不要で、いつでも適用できることです。

その欠点も明らかで、一つは二者間の取引のみをサポートすること（片方が証明し、もう片方が検証する）、二つ目は契約を作成するために大量のデータを作成し、大量のトランザクションを事前に署名する必要があり、オフチェーン情報の保存コストが膨大であることです。

以下は技術論理の簡単な紹介です：

（1）ポイント入力コミットメント

ポイント入力コミットメントは、証明者が論理ゲートに入力値0または1を設定できるようにします。このコミットメントには二つのハッシュ値H（A0）、H（A1）が存在し、証明者はハッシュの原像を明らかにする必要があります。例えばA0を明らかにすれば、入力値は0に設定され、A1を明らかにすれば、入力値は1に設定されます。

（2）論理ゲートコミットメント

入力値が得られたら、ビットコインのAND、NOTなどのオペコードを組み合わせることで、ビットコインスクリプト内で任意の論理ゲートを組み合わせることができます。

（3）バイナリ回路コミットメント

数億の論理ゲートを組み合わせてバイナリ回路を構成することで、チューリング完全性を実現できます。このバイナリ回路をビットコインネットワークにコミットするためには、すべての論理ゲートをTaprootアドレスの葉ノードに配置する必要があります。

（4）挑戦 - 応答段階

単に回路をチェーン上にコミットするだけでは不十分で、取引の両者は契約の計算結果が正しいかどうかを検証するための有効な方法を必要とします。理想的な状況では、契約はオフチェーンで実行され、両者が協力的で結果に争いがない場合は皆が満足します。しかし、取引の両者に争いがある場合、挑戦 - 応答段階に入って計算結果を検証し、ビットコインスクリプトを通じてチャネルの残高を強制的に分配する必要があります。

したがって、BitVMは決して何らかのBitcoin RollupやL2ではなく、完全な仮想マシン実行環境、グローバル状態、複雑なスマートコントラクトを公開するための高級言語を持たず、任意の数のユーザーがこれらの契約と簡単に相互作用することを許可するものではありません。非常に分かりやすい例えで言うと、BitVMは誰もがモバイル端末を使える時代に、部屋よりも大きな巨大なコンピュータを構築したようなものです。

1.2.9 MoveVM------Facebook Web2の遺伝子を受け継いだ産物

代表プロジェクト：Aptos、Sui

Moveは、安全なスマートコントラクトを記述するためのプログラミング言語で、最初はFacebookによって開発され、Diemブロックチェーンをサポートしていました。Diemブロックチェーンプロジェクトが中止された後、Aptos、Suiを代表とするプロジェクトがMove言語の利用を継続しています。Moveブロックチェーンの最大の特徴は、データストレージがグローバルストレージを採用し、アカウントアドレスを根とする木で構成され、各アドレスがリソースデータとモジュールコードを保存できることです。

Moveには二つの異なるタイプのプログラムがあります：モジュールとスクリプト。モジュールは構造体タイプを定義し、これらのタイプに対して操作を行う関数のライブラリです。構造体タイプはMoveのグローバルストレージモデルを定義し、モジュール関数はストレージを更新するルールを定義します。モジュール自体もグローバルストレージに保存されます。一方、スクリプトは実行可能ファイルのエントリーポイントであり、従来の言語のmain関数に類似し、グローバルストレージに公開されていない一時的なコードスニペットです。

まとめると、Moveモジュールはシステムの実行ファイルが実行時にロードされる動的ライブラリモジュールに似ており、スクリプトはメインプログラムに似ています。ユーザーは自分のスクリプトを作成してグローバルストレージにアクセスし、モジュールを呼び出すことができます。また、モジュールを公開したりスクリプトを実行したりするにはMove VMを介して操作します。

1.3 エコシステムの発展傾向

EVMネットワーク効果がこれほど強力な現在、EVMユーザーが非EVMチェーンエコシステムに移行することは、新興ブロックチェーンプロジェクトの最大の成長点となっており、これによりより多くのDappの相互運用性がもたらされ、将来的により迅速なユーザー成長を引き起こす可能性があります。

1.3.1 ウォレットフロントエンドの互換性

EVMユーザーを非EVMチェーンに引き込むことは常に主要な障害でしたが、最近発表されたMetamask Snapがこの障害を打破します。EVMユーザーはMetaMaskを引き続き使用でき、ウォレットを切り替える必要はありません。Driftのオープンソースの貢献により、優れたMetaMask Snapの実装が構築され、UXは任意のEVMチェーンとの相互作用に相当します。Eclipseメインネットのユーザーは、MetaMask内のネイティブアプリケーションと相互作用したり、Solanaのネイティブウォレット（Salmonなど）を使用したりすることができます。

1.3.2 VMバックエンドの互換性

1.3.2.1 トランスレーター / コンパイラー

代表プロジェクト：Wrap

WarpはSolidity-Cairoトランスレーターであり、現在、イーサリアムの著名なインフラチームNethermindによって開発が完了しています。WarpはSolidityコードをCairoにトランスレートできますが、トランスレートされたCairoプログラムはしばしば修正やCairoの特性（組み込み関数の呼び出し、メモリの最適化など）を追加する必要があります。

1.3.2.2 バイトコードインタープリター / VM互換レイヤー

代表プロジェクト：Kakarot、Neon EVM

KakarotはStarknet上にデプロイされたCairoで記述されたEVMバイトコードインタープリターであり、Cairoスマートコントラクトの形式でEVMのスタック、メモリ、実行などの側面をシミュレートしています。コードのトランスレートに比べて、KakarotはEVMの背後にあるオペコードと事前コンパイルを逐条実装し、アカウントレジストリ、ブロックハッシュレジストリなどのコンポーネントを構築してアカウントアドレスのマッピングやブロック情報の取得などに対して追加の処理を行い、Kakarotはより高いネイティブな互換性を持つようになりました。

Neon EVMは、スマートコントラクトとして実行されるEVMであり、任意のSVMチェーン上にデプロイできます。Eclipseメインネット自体はSVMを実行環境として採用していますが、Neon EVMを通じて完全なEVM互換性（EVMバイトコードのサポートとイーサリアムJSON-RPCを含む）をもたらし、スループットは単一スレッドEVMよりも高くなります。さらに、各Neon EVMインスタンスには独自のローカル料金市場があり、特定のブロック高で単一コントラクトアカウントの相互作用に関連する計算ユニットには上限（ブロック計算ユニットの1/4）が存在します。したがって、ユーザーは特定のホットコントラクトとの相互作用やブロックが満杯のときに優先料金を支払う必要があります。この意味では、アプリケーションが独自のコントラクトをデプロイすることで、アプリケーションチェーンに近い利点を得ることができ、特定のコントラクトの相互作用トランザクションが混雑した場合に全体のネットワークユーザー体験、安全性、流動性に対する破壊を軽減することができます。