Rollupの波の中、VMはまだ語るべき物語を持っている

2023.10.30

共有先

TechFlow厳選深潮セレクト

Rollupの波の中、VMはまだ語るべき物語を持っている

EVMの膨大なユーザーエコシステムは、それを見捨てたブロックチェーンネットワークが短期間で対抗することは困難であることを決定づけている。

2023.10.30 - 07:01:16

Rollup

Web3業界の深掘り報道に専念し潮流を洞察

EVMの膨大なユーザーエコシステムは、それを見捨てたブロックチェーンネットワークが短期間で対抗することは困難であることを決定づけている。

執筆：PSE Trading Analyst @cryptohawk

TL;DR

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

2. イーサリアム仮想マシン（EVM）はスタックベースの仮想マシンであり、イーサリアムスマートコントラクトの実行に使用される。zkEVM は EVM と同等／互換性を保ちつつ、zk-proof の生成効率を最適化している。一方、zkVM は EVM との互換性を放棄し、zkフレンドリーな設計を優先している。privacy zkVM は zkVM に加え、ネイティブなプライバシー機能を追加したものである。SVM、FuelVM、MoveVM は並列実行により性能を極限まで追求しており、それぞれ設計上の特徴がある。ESC VM および BitVM は ETH および BTC チェーン上で計算層に関する革新的な実験を行っているが、現時点での実用的な需要は低い。

3. EVM は膨大なユーザーエコシステムを持っており、これを放棄するブロックチェーンネットワークは短期間では太刀打ちできない。そのため、非EVMエコシステムはトランスレータ／コンパイラ／バイトコードインタプリタ、あるいはVM互換レイヤーを通じてEVMユーザーを惹きつけ、非EVMのVM特性を活かして新たなエコシステムストーリーを構築することが成功への必須条件となる。

1.1 VMとは何か？

仮想マシン（VM）は、計算資源の仮想化における基本構成要素であり、アプリケーションやオペレーティングシステムの実行といった、ほぼコンピュータと同様の機能を持つ。この概念自体は新しいものではなく、多くの技術エコシステムで広く利用されている。

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

VMの中核をなす重要な要素がLLVM（low-level-virtual-machine）であり、これはコンパイラの最も重要なコアと考えられる。図は元来のEVMの動作方式を示しており、スマートコントラクトはLLVM IRという中間コードを介してバイトコードに変換される。このバイトコードはブロックチェーン上に保存され、スマートコントラクトが呼び出されると、バイトコードが対応するOpcodeに変換され、EVMとノードハードウェアによって実行される。

1.2 主要なVM

1.2.1 EVM——ブロックチェーンVM界の独占王者、EVMが八斗を占め、残り二斗を他の全VMが分ける

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

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

EVMが模倣するメモリとストレージは、スマートコントラクトの状態とデータを保存するための装置である。EVMはメモリとストレージを別々の領域として扱い、読み書きによってスマートコントラクトの状態とデータにアクセスする。

EVMが模倣するスタックは、命令のオペランドと結果を保存するために使用される。EVMの命令セットの大部分はスタックベースであり、スタックからオペランドを読み取り、結果をスタックに戻す。

EVMの設計プロセスは明らかにボトムアップであり、まず模倣するハードウェア環境（スタック、メモリ）を確定し、それに基づいて独自のアセンブリ命令セット（Opcode）とバイトコード（Bytecode）を設計した。イーサリアムコミュニティはEVMの実行効率向上のために、2つのコンパイル型高級言語—SolidityとVyper—を開発した。Solidityについては説明不要だが、VyperはVitalikがSolidityの一部欠陥を改善するために設計したEVM向け高級言語である。しかしコミュニティでの採用が低く、徐々に歴史の舞台から退いた。

1.2.2 zkEVM——両方欲しい派：EVM環境互換＋グローバルステートルート変換に対するzk-proof生成サポート

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

zk-proof計算を念頭に置いて設計されていないEVMは、特殊なOpcode、スタックベースのアーキテクチャ、ストレージコスト、証明コストなどの点で、証明回路にとって不都合な特性を持っている。一方、zkEVMはzk-proof計算との互換性を重視した形でスマートコントラクトを実行するVMであり、EVMの実行プロセスをzk-proof／validity-proofによってより効率的かつ低コストで検証可能にする。OP Rollupの実行層がEVMをそのまま流用すればよいのに対し、ZK RollupにとってはEVMのzkフレンドリー化が余分な課題となる。

ZK-rollupはイーサリアム仮想マシン（EVM）との互換性を得るのが難しい。回路内で汎用的なEVM計算を証明することは、前述のトークン送金のような単純な計算を証明するよりも困難で、リソースを多く消費する。

しかし、ゼロ知識技術の進歩により、EVM計算をゼロ知識証明で包むことへの関心が再燃している。これらの取り組みは、プログラム実行の正しさを効率的に検証できるゼロ知識EVM（zkEVM）の実装を目指している。

EVMと同様に、zkEVMも特定の入力に対する計算を実行した後に状態を遷移させる。違いは、zkEVMはさらに各ステップの正しさを検証するためのゼロ知識証明を作成することにある。有効性証明は、仮想マシンの状態（メモリ、スタック、ストレージ）および計算自体の操作の正しさ（つまり、正しいOpcodeを呼び出し、正しく実行したかどうか）を検証できる。

理想は美しくても、現実は厳しい。現在のRollupは、ZKフレンドリー化とEVM互換性（あるいは同等性）の両立が難しく、どちらかを選ばざるを得ない。つまり、イーサリアムL1の実行層（ハッシュ、ステートツリー、トランザクションツリー、プリコンパイルなど）を可能な限り忠実に複製し、イーサリアムL1の実行クライアントをそのまま使ってRollupブロックを処理できるようにするか、あるいはEVM互換性を捨てて、回路内での証明／検証のために既存のOpcodeを再設計するかの二者択一である。

1.2.3 zkVM——魚と熊手は両方得られない：zk-proof効率を重視した非EVM仮想マシン

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

zkVMはEVM互換性を捨て、データ証明と状態更新を主眼に置き、暗号学と高級言語の間に共通層を見出し、多様なアプリケーションに共通のフレームワークを提供する。

Starkwareは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 Privacy zkVM——zkフレンドリー＋ネイティブプライバシー機能でエコシステムに新風

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

ブロックチェーンはパブリックレジャーシステムであり、すべての取引がチェーン上で行われるため、アドレスまたはアカウントに関連する資産情報の状態変化は公開されている。そのため、スケーラビリティソリューションの開発に加えて、いくつかのブロックチェーンチームは次のキーファンクションとしてプライバシーを捉えている。

Privacy zkVMは、zkフレンドリーな拡張性サポートに加え、そのプログラミング言語がネイティブにプライバシー機能をサポートしているため、上位層のアプリケーション開発者がプライバシー関連のdappを開発できる。これにより、MEV問題の根本的解決やユーザーのデータ所有権の保護など、新たなユースケースと大きなストーリーが生まれる。もちろん、Privacy zkVMの設計の複雑さはより大規模な技術チームを必要とし、実現にはまだ数年かかるかもしれない。

1.2.5 SVM——潮流が引いた後にも残る火花：性能設計が極致に達した実行環境

代表プロジェクト：Eclipse Mainnet、Nitro、MakerDAO Chain（可能性あり）

SVM、すなわちSolana仮想マシンは、高性能実行環境を主軸としており、スマートコントラクトは主にRust言語で記述される。シングルスレッド計算のEVMやEOS WASM実行環境と比べ、Solanaトランザクションが実行時に読み書きするすべての状態を事前に宣言することを要求することで、重複しないトランザクションおよび同じ状態のみを読み込むトランザクションの並列実行を実現している。

また、大量のトランザクションブロックを迅速に検証・ブロードキャストするために、SolanaネットワークではCPU設計でよく使われるパイプライン最適化が広く採用されている。これは、一連のステップで処理される入力データストリームを扱い、各ステップに異なるハードウェアが担当する仕組みである。典型的なたとえは洗濯機と乾燥機で、複数の衣類を順番に洗浄→乾燥→折り畳みを行う。洗浄は乾燥の前、乾燥は折り畳みの前に実行されなければならないが、これら3つの操作はそれぞれ独立したユニットによって実行される。

さらに、SVMはレジスタベースであり、EVMよりもはるかに小さな命令セットを持ち、ZKでの証明が容易になっている。楽観的Rollupでは、レジスタベースの設計によりチェックポイントの設定が簡単になる。

1.2.6 Fuel VM——バフ全盛：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は、ユーザーが非常に低いコストでスマートコントラクトのストレージおよび実行を回避し、事前に合意されたプロトコルルールに従って、トランザクションの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上に構築されるP2P実行チャネル

代表プロジェクト：ZeroSync

ZeroSyncの創設者Robin Linusは10月9日、「BitVM：Compute Anything On Bitcoin」と題するホワイトペーパーを発表した。正確にはVMではなく、チューリング完全な計算空間を構築しようとするもので、コントラクトはビットコインチェーン上に保存されるが、そのロジックの実行はオフチェーンで行われる。相手が違反したと判断した場合、当事者はチェーン上でチャレンジを提起でき、相手が適切に応答できなければ、当事者はコントラクト内のすべての資金を獲得できる。

その利点は、ビットコインにチューリング完全性を与えるために、ビットコインプロトコルの変更、新しいOpcode、ソフトフォークを必要とせず、いつでも適用可能であることにある。

しかし、明らかな欠点もある。第一に、二人間の取引（一方が証明、他方が検証）のみをサポートしている。第二に、コントラクトを作成するには大量のデータと事前署名された多数のトランザクションが必要で、オフチェーンのデータ保存コストが非常に高い。

以下は技術ロジックの簡単な紹介である：

（1）点入力コミットメント

点入力コミットメントは、証明者が論理ゲートの入力値を0または1に設定できるようにする。このコミットメントには2つのハッシュ値H(A0)、H(A1)が存在し、証明者がA0のハッシュ原像を明らかにすれば入力値は0となり、A1を明らかにすれば1となる。

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

入力値が決まれば、ビットコインのAND、NOTなどのOpcodeを組み合わせることで、ビットコインスクリプト内で任意の論理ゲートを構成できる。

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

億単位の論理ゲートを組み合わせてバイナリ回路を構成すれば、チューリング完全性を実現できる。このバイナリ回路をビットコインネットワークにコミットするには、すべての論理ゲートをTaprootアドレスの葉ノード内に格納する必要がある。

（4）チャレンジ－レスポンスフェーズ

回路をチェーン上にコミットするだけでは不十分であり、取引双方には契約の計算結果が正しいかを検証する有効な手段が必要である。理想的には、契約はオフチェーンで実行され、双方が協力的で結果に異議がない場合が望ましい。しかし、双方に争いがある場合は、チャレンジ－レスポンスフェーズに入り、計算結果を検証し、ビットコインスクリプトによってチャネル残高を強制的に分配する。

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

1.2.9 MoveVM——Facebook Web2遺伝子の継承者

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

Moveは安全なスマートコントラクトを記述するためのプログラミング言語であり、もともとFacebookが開発し、Diemブロックチェーンを支えるために使用された。Diemプロジェクトの終了後、AptosやSuiなどのプロジェクトがMove言語の使用を引き継いでいる。Moveブロックチェーンの最大の特徴は、データストレージにグローバルストレージを採用しており、アカウントアドレスをルートとするツリーで構成され、各アドレスはリソースデータとモジュールコードを保存できる。

Moveには2種類の異なるタイプのプログラムがある：モジュールとスクリプト。モジュールは構造体の型とそれらの型に対して操作を行う関数を定義するライブラリである。構造体型は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バイトコードインタプリタであり、スマートコントラクトの形でEVMのスタック、メモリ、実行などをエミュレートする。コードのトランスレーションに比べ、KakarotはEVMのOpcodeとプリコンパイルを1つずつ実装し、Account RegistryやBlockhash Registryなどのコンポーネントを備えており、アカウントアドレスのマッピング、ブロック情報の取得などに追加処理を施しているため、より高いネイティブ互換性を持つ。

Neon EVMは、任意のSVMチェーン上にデプロイ可能な、スマートコントラクトとして動作するEVMである。Eclipseメインネット自体はSVMを実行環境として採用しているが、Neon EVMにより完全なEVM互換性（EVMバイトコードサポートおよびイーサリアムJSON-RPC）を実現しており、シングルスレッドEVMよりも高いスループットを持つ。さらに、各Neon EVMインスタンスは独自のローカル料金市場を持ち、1ブロック高さにおける単一コントラクトアカウントの相互作用に関連する計算ユニットに上限（ブロック計算ユニットの1/4）があるため、ユーザーは特定のホットコントラクトとの相互作用やブロックが満杯のときのみpriority feeを支払えばよい。この意味で、アプリケーションが自身のコントラクトを展開すれば、ほぼアプリケーションチェーンと同等の利点を得られ、特定のコントラクトのtx混雑がネットワーク全体のユーザーエクスペリエンス、セキュリティ、流動性に与える悪影響を軽減できる。