原著者: PSEトレーディングアナリスト@cryptohawk
TL;DR
仮想マシンは、プログラムの実行環境を提供する、ソフトウェアでエミュレートされたコンピュータ システムです。さまざまなハードウェア デバイスをシミュレートし、制御された互換性のある環境でプログラムを実行できるようにします。
イーサリアム仮想マシン (EVM) は、イーサリアム スマート コントラクトを実行するために使用されるスタックベースの仮想マシンです。zkEVM は、EVM の同等性/互換性の観点から、特定の zk プルーフの生成効率の最適化を行っています。
zkVM は EVM の同等性/互換性を放棄し、zk との親和性の優先順位を高めます。
プライバシー zkVM は、zkVM にネイティブのプライバシー機能を重ね合わせます。
SVM、FuelVM、MoveVM は並列実行による究極のパフォーマンスの追求という共通点がありますが、設計の細部にはそれぞれ独自の特徴があります。
ESC VM と BitVM は、それぞれ ETH チェーンと BTC チェーンで特定の革新的なコンピューティング層の実験を実施しましたが、現在の環境では実際の実装需要は低いです。
EVM の巨大なユーザー エコシステムは、EVM を放棄するブロックチェーン ネットワークは短期的には競争することが困難であると判断しており、そのため、非 EVM エコシステムでは、トランスレータ/コンパイラ/バイトコード インタプリタ、さらには VM 互換性レイヤーを介して EVM エコシステム ユーザーを導入し、非 EVM エコシステムを利用します。 EVM 仮想マシンの機能を使用して、新しい生態学的な物語を構築することは、成功への必要な道である可能性があります。
1.1 VM とは何ですか?
仮想マシン (VM) は、アプリケーションやオペレーティング システムの実行など、コンピューターとほぼ同じ機能を実行する、仮想化されたコンピューティング リソースの構成要素です。仮想マシンの概念は新しいものではなく、このテクノロジーは多くのテクノロジー エコシステムで広く使用されています。
ブロックチェーンのコンテキストでは、仮想マシン (VM) はプログラムを実行するソフトウェアであり、ブロックチェーン スマート コントラクトを実行するランタイム環境とも呼ばれます。仮想マシンは通常、さまざまなハードウェア デバイスをシミュレートすることによって仮想コンピュータ環境を提供します。仮想マシンごとにシミュレートできるハードウェア デバイスは異なりますが、通常は CPU、メモリ、ハードディスク、ネットワーク インターフェイスなどが含まれます。オンチェーン トランザクションが送信されると、仮想マシンはトランザクションを処理し、トランザクションの実行によって影響を受けるブロックチェーンの状態 (ネットワーク全体の現在のグローバル状態) を更新する責任を負います。ネットワーク状態を変更するための特定のルールは、VM によって定義されます。トランザクションを処理するとき、VM はスマート コントラクト コードをノード/バリデータ ハードウェアが実行できる形式に変換します。
VM の中で最も重要なカーネルは LLVM (low-level-virtual-machine) であり、コンパイラの最も重要なカーネルと見なすことができます。図は本来のEVMの動作スキームを示しており、スマートコントラクトはLLVM IRの中間コードを経てBytecodeに変換されます。これらのバイトコードはブロックチェーンに保存され、スマート コントラクトが呼び出されると、バイトコードは対応するオペコードに変換され、EVM とノード ハードウェアによって実行されます。
1.2 メインストリーム VM
1.2.1 EVM - ブロックチェーン VM には合計 1 つのストーンがあり、EVM には排他的に 8 つのバケットがあり、残りは 2 つのバケットに分割されます。
代表的なプロジェクト：Optimism、Arbitrum
業界で最も活発な開発者とユーザーがいるブロックチェーン エコシステムであるイーサリアム仮想マシン (EVM) は、CPU、メモリ、ストレージ、スタックなどのハードウェア デバイスをシミュレートすることで仮想コンピュータを提供するスタックベースの仮想マシンです。スマートコントラクトの命令を実行し、スマートコントラクトのステータスとデータを保存します。 EVM の命令セットには、算術演算、論理演算、ストレージ演算、ジャンプ演算などのさまざまなオペコードが含まれています。
EVM によってシミュレートされるメモリとストレージは、スマート コントラクトの状態とデータを保存するために使用されるデバイスです。 EVM はメモリとストレージを 2 つの異なる領域として扱い、メモリとストレージを読み書きすることでスマート コントラクトの状態とデータにアクセスできます。
EVM シミュレートされたスタックは、命令のオペランドと結果を保存するために使用されます。 EVM の命令セット内のほとんどの命令はスタックベースであり、スタックからオペランドを読み取り、結果をスタックにプッシュします。
EVM の設計プロセスは明らかにボトムアップであり、最初にシミュレートされたハードウェア環境 (スタック、メモリ) が完成し、次に、対応する環境に従って独自のアセンブリ命令セット (オペコード) とバイトコード (バイトコード) のセットが設計されます。 。 Ethereum コミュニティは、EVM の実行効率を高めるために、2 つのコンパイル済み高レベル言語 (Solidity と Vyper) を設計しました。 Solidity 言うまでもなく、Vyper は Solidity の欠点を改善するために Vitalik によって設計された EVM 高級言語ですが、コミュニティでの採用はそれほど高くなく、徐々に歴史から消えていきました。
1.2.2 zkEVM - すべてが欲しい: EVM 環境との互換性 + zk-proof を生成するためのグローバル ステート ルート変換をサポート
代表的なプロジェクト：太鼓、スクロール、ポリゴンzkEVM
EVM は zk プルーフ計算を念頭に置いて構築されていないため、特に特別なオペコード、スタックベースのアーキテクチャ、ストレージ オーバーヘッド、証明コストの点で、回路の証明には不向きな特性を持っています。 zkEVM は、zk-proof 計算と互換性のある方法でスマート コントラクトを実行する仮想マシンであり、zk-proof/validity-proof を通じて EVM の実行プロセスをより効率的かつコスト効率よく検証できます。 OP Rollup と比較すると、実行層は EVM をコピーするだけでよく、ZK フレンドリーになる EVM を構築することは ZK Rollup にとってさらなる課題です。
ZK ロールアップは、イーサリアム仮想マシン (EVM) との互換性が容易ではありません。回路内の汎用 EVM 計算を証明することは、単純な計算 (前述のトークン転送など) を証明するよりも難しく、リソースを大量に消費します。
しかし、ゼロ知識テクノロジ (新しいタブで開きます) の進歩により、EVM 計算をゼロ知識証明でラップすることへの関心が再燃しています。これらの取り組みは、プログラム実行の正しさを効率的に検証できるゼロ知識 EVM (zkEVM) 実装を作成することを目的としています。 。
EVM と同様に、zkEVM は特定の入力に対して計算を実行した後に状態間を遷移します。違いは、zkEVM はプログラム実行の各ステップの正確さを検証するためにゼロ知識証明も作成することです。妥当性証明は、仮想マシンの状態 (メモリ、スタック、ストレージ) と計算自体に関係する操作の正しさを検証します (つまり、操作が正しいオペコードを呼び出して正しく実行したか)。
アイデアは美しいですが、現実は非常に貧弱です。現時点では、Rollup は ZK フレンドリーさと EVM 互換性 (または同等性) の両方を達成するのが困難です。つまり、ハッシュを含め、イーサリアム L1 実行層を可能な限り完全にコピーする必要があります。 、状態ツリー、トランザクション ツリー、プリコンパイルなどにより、イーサリアム L1 実行クライアントをそのままロールアップ ブロックの処理に使用できるようにするか、EVM 互換性を破棄して、回路内構成証明/検証用の既存のオペコードを再作成して、スマートコントラクトの実行。
1.2.3 zkVM - ケーキを持って食べることはできません: zk 耐性のある効率重視の非 evm 仮想マシン
代表的なプロジェクト：Starknet、Zksync、RISC ZERO
zkVM は EVM の互換性を放棄し、データの証明とステータスの更新を中心的な目標とし、暗号化と高級言語の間の共通点を見つけて、さまざまなアプリケーションに共通のフレームワークを提供します。
Starkware は ZK 分野全体の中でいち早くスタートし、十分な技術を蓄積しているため、技術的には一定のリードを保っています。彼は代表的な ZK 中心の技術アーキテクチャであり、ZK を中心に Cairo VM と Cairo Language を構築しました。欠点は、カイロを学ぶのに費用がかかることです。
ZKsync のフレームワークは EVM と ZK の特性と互換性があり、Solidity と自社開発の回路言語 Zinc を統合し、コンパイラー内の IR レベルで 2 つを統合します。利点は、LLVM のコンパイラ コアが複数の言語と互換性があることです。
RISC Zero は、RISC-V アーキテクチャを使用して、プログラマーが Rust、C/C++、Go などの一般的な言語で zkVM 用のプログラムを作成できるシミュレーターを構築します。これは、アプリケーション ロジックを何に限定する必要がないことを意味します。 Solidity で表現できるため、無関係なコードを記述して連鎖させることができます。
1.2.4 プライバシー zkVM - zk フレンドリー + ネイティブ プライバシー サポート、新しいエコロジカルな火花を点火しようとしています
代表的なプロジェクト：Aleo、Ola、ポリゴンミデン
ブロックチェーンは公開台帳システムとして機能し、すべてのトランザクションはチェーン上で実行されます。つまり、アドレスやアカウントに関連する資産情報を含む状態の変更はオープンかつ透明になります。したがって、一部のブロックチェーン チームは、ソリューションのスケーリングに取り組むことに加えて、次に実装すべき重要な機能はプライバシーであると考えています。
zk フレンドリーで拡張をサポートすることに加えて、Privacy zkVM では、独自のプログラミング言語でネイティブにサポートされているプライバシー機能により、上位層アプリケーション開発者がプライバシー関連の DAPP を開発することもできます。これにより、新しいアプリケーション シナリオと壮大な物語がもたらされます。たとえば、MEV 問題を完全に解決し、ユーザー データの所有権を保護します。もちろん、Privacy zkVM の設計は複雑であるため、実装するには大規模な技術チームが必要であり、それを実現するには数年かかる場合があります。
1.2.5 SVM - 潮が引いても残り火：性能設計を極限まで高めた実行環境
代表的なプロジェクト：Eclipse Mainnet、Nitro、MakerDAO Chain（たぶん）
Solana 仮想マシンである SVM は、高性能の実行環境に焦点を当てており、スマート コントラクトは主に Rust 言語で記述されています。シングルスレッドの EVM および EOS WASM 実行環境と比較して、SVM では、実行時にトランザクションが読み書きするすべての状態を説明することを Solana トランザクションに要求することで、重複しないトランザクションと同じ状態のみを読み取るトランザクションの同時実行が可能になります。
さらに、多数のトランザクション ブロックを迅速に検証/ブロードキャストするために、Solana ネットワーク上のトランザクション検証プロセスでは、CPU 設計で一般的なパイプライン最適化が広範囲に使用されています。入力データ フローが一連のステップで処理され、各ステップがそれを担当する異なるハードウェアを持つ状況を満たすため。典型的な例としては、複数の洗濯物を順番に洗濯/乾燥/折りたたむ洗濯機と乾燥機があります。乾燥前に洗浄、乾燥前に折り作業が必要ですが、これら3つの作業はそれぞれ別の装置で行われます。
さらに、SVM はレジスタベースであり、EVM よりもはるかに小さい命令セットを備えているため、ZK での SVM の実行の証明が容易になります。楽観的なロールアップの場合、レジスタベースの設計によりチェックポイントの設定が容易になります。
1.2.6 Fuel VM——バフスタック: UTXOフレームワーク下の並列仮想マシン
代表プロジェクト：燃料
Fuel VM は、EVM、Solana、WASM、BTC、Cosmos の技術フレームワークをベースに改良されたもので、EVM と比較して次のような特徴があります。
最もユニークなのは、Fuel が SVM と同様のアクセス リストを設定するだけでなく、非重複トランザクションと並行してトランザクションを実行する機能を備えており、さらにトークン UTXO とコントラクト UTXO に分かれる UTXO モデルを採用していることです。アクセス効率とコンピューティング スループットを向上させます。
さらに、Fuel VM は、独自のドメイン固有言語 Sway とサポート ツール チェーン Forc を通じて、強力でスムーズな開発者エクスペリエンスを提供します。その開発環境は、Solidity などのスマート コントラクト言語の利点を維持しながら、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 プロトコル自体は、イーサリアム チェーンの BTC Ordinal に似たプロトコルで、スマート コントラクトや L2 とは異なる低コストの代替手段の探索に重点を置いています。
Ethscripts を使用すると、ユーザーは、事前に合意されたプロトコル ルールを Tx 内の呼び出しデータに適用して計算することで、非常に低コストでスマート コントラクトの保存と実行をバイパスできます。簡単に言えば、成功した Ethereum トランザクションがあり、その呼び出しデータが指定された有効なデータ仕様に準拠しており、一意の「to」アドレスが 0 でない限り、Ethscription は合法的に作成されたと見なされます。アドレスは作成者、「to」アドレスは所有者です。
設計の開始時に、各 Ethscription は画像 NFT などの NFT 形式を好みます。画像コンテンツは、Base 64 形式で calldata に直接書き込まれます。
最近最も人気のある eth は、brc-20 プロトコル仕様を参照して作成された Ethscription です。
ESC VMによって導入されるスマートコントラクトは次のように呼ばれます。"愚かな契約"(Dumb Contract) は論理的なコントラクトとして公開されますが、EVM の形式でチェーン上で相互作用しません。さらに、ESC VM は特別なフォーマットも追加します"コンピュータコマンド"、この形式を使用して作成されたエスクリプションは、ESC VM によって認識され、Deploy - ダム コントラクトのデプロイ、Call - ダム コントラクトの呼び出しなどのダム コントラクトと対話します。
このソリューションにはいくつかの制限があります。"愚かな契約"この機能には支払いがありません。つまり、ダムコントラクトを通じて ETH を送金したい場合は、「ブリッジコントラクト」を経由する必要があり、「ブリッジコントラクト」自体には制御の乱用と資産盗難のリスクがあります。ダムコントラクトを恣意的に作成することは許可されておらず、そのコードは Ethscriptions Protocol ガバナンス提案を通じて定義する必要があります。
まとめると、ESC VM はイーサリアム L1 をデータストレージ層として構築されたコンピューティング層であり、イーサリアム tx の calldata にコントラクトロジック、コントラクトコール、コントラクトコール、その他のデータコンテンツを配置することで実装されます。状態コンセンサスは ESC VM クライアント コンセンサスであり、SmartWeave のデータ ストレージ層が Arweave であることを除いて、Arweave の SmartWeave 実装ロジックに似ています。
1.2.8 ビット VM - 興味深い研究実験: BTC 上のピアツーピア実行チャネル
代表プロジェクト：ZeroSync
ZeroSync の創設者である Robin Linus は、10 月 9 日にホワイト ペーパー「BitVM: Compute Anything On Bitcoin」を発表しました。正確に言うと、これは VM ではなく、コントラクトがビットコインに保存されるチューリング完全なコンピューティング空間を作成する試みです。チェーンですが、コントラクトのロジックはオフチェーンで実行されます。相手が契約に違反したと思われる場合は、チェーン上で異議を申し立てることができ、相手が正しく応答できない場合は、契約内のすべての資金を取り上げることができます。
利点は、ビットコイン プロトコルに変更を加えることなく、新しいオペコードやソフト フォークを必要とせずに、ビットコインにチューリング完全性を与えることができ、いつでも適用できることです。
その欠点も明らかです。第一に、2 者間のトランザクションのみをサポートします (一方が認証し、もう一方が検証します)。第二に、契約を作成するには大量のデータを作成し、多数のトランザクションに事前署名する必要があります。オフチェーンの情報ストレージは巨大です。
以下に技術ロジックを簡単に紹介します。
(1) クリックしてコミットメントを入力します
ポイント入力コミットメントにより、証明者は論理ゲートの入力値 0 または 1 を設定できます。このコミットメントでは、2 つのハッシュ値 H(A 0) と H(A 1) が存在します。証明者はハッシュ プリイメージを明らかにする必要があります、A 0 などの場合、入力値は 0 に設定され、A 1 が明らかになった場合、入力値は 1 に設定されます。
(2) 論理ゲートのコミットメント
入力値を取得したら、ビットコインの AND、NOT、およびその他のオペコードを組み合わせることで、ビットコイン スクリプトで任意の論理ゲートを組み合わせることができます。
(3) バイナリ回路のこだわり
チューリング完全性は、数億の論理ゲートをバイナリ回路に構成することによって達成できます。このバイナリ回路をビットコイン ネットワークにコミットするには、すべての論理ゲートをタップルート アドレスを持つリーフ ノードに配置する必要があります。
(4) チャレンジ/レスポンスリンク
チェーン上の回路をコミットするだけでは十分ではなく、契約の計算結果が正しいことを検証する効果的な方法が両当事者に必要です。理想的な世界では、契約はオフチェーンで実行され、双方が協力的で結果について争いがなければ満足します。ただし、トランザクションの 2 者間で紛争が発生した場合は、チャレンジ/レスポンス リンクを入力して計算結果を確認し、ビットコイン スクリプトを介してチャネル残高を強制的に配布する必要があります。
したがって、BitVM は、ある種のビットコイン ロールアップや L2 とは程遠く、完全な仮想マシン実行環境、グローバル状態、複雑なスマート コントラクトを公開するための高水準言語を備えておらず、任意の数のユーザーが簡単にこれらの契約とやり取りします。非常に一般的な例を使って説明しましょう。BitVM は、誰もがモバイル端末を使用できる時代に、部屋よりも大きい巨大なコンピューターを構築するようなものです。
1.2.9 MoveVM - Facebook の Web2 遺伝的遺産の産物
代表プロジェクト：Aptos、Sui
Move は、安全なスマート コントラクトを作成するためのプログラミング言語です。元々は、Diem ブロックチェーンのサポートを提供するために Facebook によって開発されました。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を使い続けることができます。優れた MetaMask Snap 実装の構築に対する Drift のオープン ソースへの貢献のおかげで、UX は任意の EVM チェーンと対話するのと同等になります。 Eclipse メインネット ユーザーは、MetaMask でネイティブ アプリケーションを操作したり、Salmon などの Solana ネイティブ ウォレットを使用したりできるようになります。
1.3.2 VM バックエンドの互換性
1.3.2.1 トランスレータ/コンパイラ
代表プロジェクト：ラップ
Warp は、有名な Ethereum インフラストラクチャ チームである Nethermind によって開発された Solidity-Cairo トランスレータです。 Warp は Solidity コードを Cairo に変換できますが、実行効率を最大化するために、翻訳された Cairo プログラムを変更して Cairo 機能 (組み込み関数の呼び出し、メモリの最適化など) を追加する必要があることがよくあります。
1.3.2.2 バイトコードインタープリター/VM 互換性レイヤー
代表的なプロジェクト：Kakarot、Neon EVM
Kakarot はカイロで書かれ、Starknet にデプロイされたスマート コントラクトの形式で実装された EVM バイトコード インタープリタであり、スタック、メモリ、実行、および EVM のその他の側面をカイロ スマート コントラクトの形式でシミュレートします。コード変換と比較して、Kakarot は EVM の背後でオペコードとプリコンパイルを段階的に実装し、アカウント アドレス マッピング、ブロック情報取得などの追加処理を実行するアカウント レジストリやブロックハッシュ レジストリなどのコンポーネントを構築します。カカロットのさらなる機能、高いネイティブ互換性。
Neon EVM は、スマート コントラクトとして実行される EVM であり、任意の SVM チェーンに導入できます。 Eclipse メインネット自体は実行環境として SVM を使用しますが、Neon EVM を通じて完全な EVM 互換性 (EVM バイトコード サポートおよび Ethereum JSON-RPC を含む) を実現し、シングルスレッド EVM よりも高いスループットを備えています。さらに、各 Neon EVM インスタンスには独自のローカル料金市場があります。つまり、ブロックの高さ (ブロック コンピューティング ユニットの 1/4) での単一契約アカウント インタラクションに関連するコンピューティング ユニットには上限があるため、ユーザーのみ特定のホットコントラクトとやり取りする必要があるか、ブロックがいっぱいになったときに優先料金を支払う必要があります。この意味で、独自のコントラクトを展開するアプリケーションは、アプリケーション チェーンを近似する利点を得ることができ、それによって、特定のコントラクト インタラクション TX の輻輳によって引き起こされるネットワーク全体のユーザー エクスペリエンス、セキュリティ、または流動性への損害を軽減できます。
参考文献:
1.Cynic Starknet Astro 著「Kakarot: Exploring Starknets Road to EVM Compatibility」
2.「BitVM が白熱した議論を巻き起こす。ビットコイン ネットワークはチューリングの完全性を達成できるのか?」、Haotian 著
3.https://ethereum.org/en/developers/docs/evm/
4.「Starkware の技術アーキテクチャと生態学的レビュー」、Maxlion 著
5.https://twitter.com/muneeb/status/1712461799327416491
6.「プロジェクト研究丨モジュラー高速実行層燃料研究レポート」、Web3 CNより
8.https://docs.ethscriptions.com/overview/introducing-ethscriptions
9. “Analysis of the First Critical Vulnerability of Aptos Move VM”，by Numen Cyber Labs
10. https://ethereum.org/en/developers/docs/evm/
11.“What Is SVM - The Solana Virtual Machine”，by Squads
12.“Introducing Eclipse Mainnet: The Ethereum SVM L2”，by Eclipse
13.https://john-hol.gitbook.io/bitvm/
14.https://bitvm.org/bitvm.pdf
15.“The different types of ZK-EVMs”，by Vitalik Buterin
16. 「Cipholio Research Report: ZkVM の計画と将来について語る」、YOLO SHEN、Cipholio Ventures 著
