カスタム仮想マシン（Custom VM）

カスタム仮想マシンとは？

カスタム仮想マシン（Custom VM）とは、独自のルールに基づいてトランザクションを処理し、プログラムを実行し、状態を管理し、計算リソースを計測するよう設計されたブロックチェーン実行環境です。

簡単に言えば、ブロックチェーン上でプログラムに許可される処理と、有効な各トランザクションがブロックチェーンの状態をどう変えるかを決める部分です。

パフォーマンス、セキュリティ、プログラミング、プライバシー、アプリケーション機能の要件が異なる場合、チームはEthereum Virtual Machineのような既存環境を使わずにカスタムVMを構築することがあります。

「カスタム」とは、特定のブロックチェーン、ロールアップ、アプリケーションチェーン、暗号学的証明システムのニーズに合わせて、実行環境を新たに作成、変更、最適化したことを意味します。

カスタムVMでは、独自の命令セット、アカウント構造、ストレージ規則、トランザクション形式、手数料モデル、システム関数、スマートコントラクト言語が導入される場合があります。

また、すべてを一から設計するのではなく、既存の仮想マシンを変更することもあります。

たとえばSolanaの公式プログラム実行ドキュメントでは、sBPFをSolanaのランタイム向けに調整したeBPFバイトコードのカスタム版と説明しています。

ブロックチェーンノードは、残高、コントラクト、所有権、アプリケーションの状態について合意するため、同一の方法でトランザクションを実行しなければなりません。そのため、ブロックチェーンVMは重要です。

誠実なノードが同じトランザクションを実行して異なる結果を生成すると、ネットワークが分岐したり、ブロックが拒否されたりする可能性があります。

このため、ブロックチェーンVMには決定性、安全性、リソース制限、厳密な仕様が必要です。

ブロックチェーン仮想マシンの役割

ブロックチェーン仮想マシンは、すべての検証ノードが同じ結果を再現できる、制御されたコンピューターのように機能します。

トランザクションやプログラム命令を受け取り、現在のブロックチェーン状態に適用します。

VMは、トランザクションがプロトコルのルールに従っているか、送信者に必要な権限があるか、実行に十分なリソースがあるかを確認します。

次に、トークンの送金、コントラクトストレージの変更、NFTのミント、レンディングポジションの更新、ガバナンス投票など、許可された処理を実行します。

実行後、他のノードが独立して検証できる新しい状態を生成します。

Ethereum Virtual Machineのドキュメントでは、EVMをEthereumノード間で一貫してコードを実行する分散型仮想環境と説明しています。

カスタムVMも広い意味では同じ役割を担いますが、アーキテクチャや実行ルールが異なる場合があります。

通常、VMがブロックチェーンのすべての機能を担うわけではありません。

コンセンサスはノードがブロックの順序や受け入れについて合意する方法を定め、VMは順序付けられたトランザクションの処理内容を決めます。

データ可用性は、検証に必要なトランザクションデータを取得できるかどうかを扱います。

モジュラーシステムでは、セトルメントが結果、証明、紛争の最終的な承認先を定めます。

カスタムVMは特に実行レイヤーに属しますが、その設計はこれら他のレイヤーにも影響し得ます。

ブロックチェーンがカスタムVMを構築する理由

汎用の実行環境では想定するアプリケーションに必要なパフォーマンスや機能が得られない場合、ブロックチェーンはカスタムVMを構築します。

高頻度取引向けのブロックチェーンでは、並列トランザクション実行、予測可能な手数料、高速な状態アクセスが求められることがあります。

ブロックチェーンゲームでは、ネイティブなデジタル資産、低コストの操作、アカウント権限、ゲーム内オブジェクトの効率的な保存が必要になる場合があります。

プライバシー重視のチェーンでは、機密状態、ゼロ知識証明のサポート、制限されたデータアクセスが求められることがあります。

ロールアップでは、ゼロ知識暗号で証明しやすい実行環境が必要になる場合があります。

アプリケーション特化型ブロックチェーンでは、汎用のスマートコントラクトプラットフォームではなく、慎重に制御された少数の操作だけを必要とすることがあります。

カスタムVMによって、開発者はこうした目標に合わせてブロックチェーンを最適化できます。

一方で、チームはより多くのインフラを自ら構築・維持しなければなりません。

カスタムコンパイラー、ウォレット、デバッガー、ブロックエクスプローラー、セキュリティツール、ソフトウェア開発キット、開発者向けドキュメントが必要になる場合があります。

高度に最適化されたVMは優れたパフォーマンスを発揮できても、ツールが使いにくければ開発者を集めにくい可能性があります。

カスタムVMとEthereum Virtual Machineの比較

Ethereum Virtual Machine（EVM）は、Ethereumのスマートコントラクトで使用される実行環境であり、暗号資産業界全体で広く採用される互換性の基準となっています。

開発者は通常、SolidityやVyperでEVMコントラクトを記述し、EVMバイトコードにコンパイルします。

EVMはスタックベースのアーキテクチャを採用し、実行リソースをGasで計測します。

成熟した大規模な開発者エコシステムには、ウォレット、ライブラリ、テストフレームワーク、セキュリティツール、コントラクト標準がそろっています。

カスタムVMは、主要な設計上の判断のほぼすべてでEVMと異なる場合があります。

スタックの代わりにレジスターを使う、並列実行をサポートする、別のアカウントモデルを採用する、EVMのGasではなく計算ユニットやウェイトでリソースを課金する、といった設計が可能です。

EVMコントラクトでは通常使われないプログラミング言語をサポートすることもあります。

EVMを使う主な利点は互換性です。

カスタムVMの主な利点は、特定の用途に合わせて実行環境を最適化できる自由度です。

ただし、EVM互換性とカスタム実行は、必ずしも完全な二者択一ではありません。

カスタムの中核VMを使いつつ、EVMバイトコード用のインタープリターや互換レイヤーを追加するネットワークもあります。

たとえば、公式のEraVMドキュメントでは、ZK向けに最適化したVMを中核の実行環境としながら、EVMインタープリターでEthereum形式のバイトコードをサポートするアーキテクチャを説明しています。

この方法なら、カスタム実行の利点をすべて手放さずに、エコシステムとの一定の互換性を実現できます。

カスタムVMとカスタムブロックチェーンランタイムの違い

カスタムVMとカスタムブロックチェーンランタイムは、同じ意味として使われることがありますが、両者の違いが重要な場合もあります。

仮想マシンは通常、定義された命令セットに従ってバイトコードを実行します。

ランタイムはより広い概念であり、トランザクション処理やブロックチェーンの状態遷移を定めるロジックを指します。

独立したスマートコントラクトのバイトコードを開発者がデプロイする、従来型のVMを使うブロックチェーンもあります。

一方、制限のないスマートコントラクトVMを提供せず、チェーンの大部分のビジネスロジックを単一のランタイムにコンパイルするブロックチェーンもあります。

Polkadot SDKのノードとランタイムに関するドキュメントでは、ランタイムを、プラットフォームに依存しない実行のためにWebAssemblyへコンパイルされたブロックチェーンの状態遷移ロジックと説明しています。

Cosmos SDKのアーキテクチャドキュメントでは、ビジネスロジックを定義してトランザクションを処理するモジュールから構成される状態機械として、ブロックチェーンアプリケーションを説明しています。

こうしたシステムはカスタム実行を提供しますが、カスタムVMではなく、ランタイム、アプリケーション状態機械、実行環境と呼ばれる場合があります。

そのため、暗号資産に関する議論ではカスタムVMという用語が厳密でない意味で使われることがあります。

名称だけに頼らず、実際のアーキテクチャを確認してください。

カスタムVMの主な構成要素

命令セット

命令セットは、プログラムが実行できる低水準の操作を定めます。

命令には、算術演算、メモリーの読み書き、値の比較、署名検証、別のコントラクトの呼び出し、データの返却などがあります。

命令セットが小さければ分析や証明が容易になる可能性があり、大きければより直接的な機能を提供できる場合があります。

カスタムVMの設計者は、すべての命令について明確で決定的な意味が定義されていることを確認しなければなりません。

状態モデル

状態モデルは、ブロックチェーンがアカウント、残高、コントラクト、トークン、オブジェクト、保存データをどのように表すかを定義します。

Ethereumに似たグローバルなアカウントベースの状態を使うVMもあります。

未使用トランザクションアウトプット、独立したオブジェクト、Key-Valueストア、アプリケーション固有の記録などを使うものもあります。

状態モデルは、トランザクションの並列性、ウォレットの設計、コントラクト権限、開発者体験に大きく影響します。

メモリーとストレージ

メモリーは通常、一度の実行中に使われる一時データを指し、ストレージはトランザクション終了後も保持されるデータを指します。

検証ノードが変更を再現または検証しなければならないため、ブロックチェーンの永続ストレージは高コストです。

カスタムVMでは、コストを削減したり証明の生成を効率化したりするため、専用のストレージ配置を導入することがあります。

ストレージ規則では、許可なく別のコントラクトに属するデータを変更できないようにする必要があります。

リソース計測

リソース計測は、トランザクションが消費できる計算、メモリー、ストレージ、帯域幅の量を制限します。

リソース上限がなければ、攻撃者は無限に実行されるプログラムや、ノードが他のトランザクションを処理できなくなるほどのリソースを消費するプログラムを送信できてしまいます。

EVMはGasを使いますが、他の実行環境は計算ユニット、ウェイト、サイクル、個別のリソース区分などを用いることがあります。

リソース体系では、不正利用を防げるだけのコストを高価な処理に課しつつ、正当なアプリケーションの利用が非現実的にならないようにする必要があります。

ホスト関数とシステムコール

カスタムVMでは、ブロックチェーン固有の機能にアクセスするため、プログラムがホスト関数やシステムコールを利用できることがよくあります。

暗号署名の検証、ブロック情報の読み取り、別のプログラムの呼び出し、資産の作成、イベントの発行、許可された外部データへのアクセスなどが可能です。

Solanaのシステムコールのリファレンスには、暗号処理、ログ記録、メモリー操作、プログラム間呼び出しなど、ランタイム関数が記載されています。

システムコールは効率を高めますが、仕様策定、テスト、セキュリティ確保が必要な範囲も広げます。

カスタムVM内でのトランザクション実行

トランザクションは通常、ノードまたはRPCエンドポイントを通じてブロックチェーンに送られます。

ネットワークは、形式、署名、手数料、リプレイ保護などの基本要件を確認します。

コンセンサスまたはブロック生成ソフトウェアが、他のトランザクションに対する順序を決めます。

次にカスタムVMがトランザクション、関連状態、実行対象プログラムを読み込みます。

権限を確認し、実行コンテキストを初期化します。

VMはリソース消費を追跡しながら命令を処理します。

実行が成功すると、結果として生じた状態変更が確定されます。

実行に失敗した場合、通常、プロトコルの規則に従って状態変更の一部または全部がロールバックされます。

失敗した処理にも計算リソースが使われているため、トランザクション手数料は請求される場合があります。

すべての検証ノードは、同じ開始状態と順序付けられたトランザクションから、同じ最終結果を生成しなければなりません。

この要件を決定的実行と呼びます。

カスタムVMにおける決定性

決定性とは、同一の入力がすべての誠実なノードで同一の出力を生成することです。

これにより、正しいブロックチェーン状態をめぐってバリデーターが対立するのを防ぎます。

通常のコンピューターアプリケーションでは、ローカル時計、OSのランダムデータ、浮動小数点計算、マシンごとに結果が異なる可能性のあるインターネット要求などを利用できます。

ブロックチェーンVMでは、こうした不確実性の要因を制限するか、厳密に定義する必要があります。

ランダム性を使う場合、プログラムがコンピューターに乱数を求めるのではなく、通常はプロトコルで承認された情報源が必要です。

外部情報は通常、制限のないウェブ要求ではなく、オラクルや検証済みメッセージを通じて取り込みます。

オーバーフロー、除算、丸め、数値の上限を含め、算術処理の動作を厳密に定めなければなりません。

カスタムVMが決定性を維持できないと、コンセンサスの失敗、チェーン分岐、証明の誤りにつながる可能性があります。

サンドボックスと分離

カスタムVMは通常、ノードのOSへのアクセスを制限するサンドボックス内でプログラムを実行します。

スマートコントラクトがバリデーターの個人ファイルを読んだり、任意のネットワーク接続を開いたり、ホストマシンを乗っ取ったりできてはなりません。

サンドボックスは、プログラムがアクセスできるメモリー領域、ストレージ領域、ホスト関数を定義します。

また、呼び出しの深さ、スタックサイズ、メモリーの拡張、実行時間も制限します。

強固な分離によって、ユーザーがアップロードした悪意あるプログラムからバリデーターを保護できます。

他のコントラクトからの不正アクセスから、コントラクトを保護する役割もあります。

ブロック処理中にバリデーターが攻撃者のコードを実行する可能性があるため、サンドボックスの突破はネットワークに深刻なセキュリティ問題を引き起こしかねません。

そのため、カスタムVMの実装には、慎重な監査、ファジングテスト、依存関係の確認、安全なコンパイラー設計が必要です。

スタックベースとレジスターベースのカスタムVM

スタックベースのVMでは、多くの処理で値をスタックに積み、命令が入力を必要とするときに取り出します。

よく知られたスタックベースの仮想マシンにEVMがあります。

レジスターベースのVMでは、処理中の値を名前付きまたは番号付きのレジスターに保存します。

レジスターベースの設計では、一部の計算に必要な命令数を減らし、より予測可能なパフォーマンスを実現できる場合があります。

公式のFuelVMアーキテクチャドキュメントでは、FuelVMをブロックチェーン実行向けに設計されたレジスターベースの仮想マシンと説明しています。

どちらのアーキテクチャも、すべてのブロックチェーンで自動的に優れているわけではありません。

スタックベースのシステムには、比較的単純なバイトコードと確立されたツール群がある場合があります。

レジスターベースのシステムは、特定の処理負荷で実行やコンパイラーの利点をもたらす場合があります。

最適な選択は、性能目標、証明システム、開発言語、セキュリティ目標、実装の複雑さによって異なります。

カスタムVMと並列実行

並列実行とは、互いに競合しない複数のトランザクションをブロックチェーンが同時に処理できる仕組みです。

従来の逐次実行では、トランザクションが無関係のアカウントを変更する場合でも、一つずつ処理します。

カスタムVMは、各トランザクションがどの状態を読み書きするかを特定できるよう設計できます。

競合しないトランザクションを複数のプロセッサコアで並行して実行できるようになります。

独立したユーザーが多数いるアプリケーションでは、処理能力の向上につながる可能性があります。

コントラクトが依存関係を宣言せずにグローバル状態のどこにでもアクセスできる場合、並列実行は難しくなります。

カスタムVMでは、実行前に関連するアカウントやオブジェクトをトランザクションで指定する必要がある場合があります。

また、楽観的実行を行い、競合が見つかった場合にトランザクションを再試行することもあります。

スケジューリング、競合検出、状態コミットメントが正しく機能する場合に限り、並列処理によって性能が向上します。

同じ状態を同時に変更しようとする場合、個別には正常に動作する二つのトランザクションでも結果が異なる可能性があるため、開発者は並行性モデルを理解する必要があります。

カスタムVMとスマートコントラクト言語

カスタムVMには通常、対応するバイトコードや実行形式にコンパイルする一つ以上のプログラミング言語が必要です。

Rust、C、C++、Move、WebAssembly互換言語、専用のスマートコントラクト言語などをサポートするVMがあります。

言語は安全性、開発者の生産性、コントラクトのサイズ、コンパイラーの複雑さに影響します。

型や所有権の規則が強い言語は、デプロイ前に一部のバグを防げる可能性があります。

なじみのある言語は開発者を引きつけやすい一方、決定的な実行が難しい機能を含む場合があります。

人間が読めるコードをVMが実行する命令へ変換するため、コンパイラーはセキュリティチェーンの一部です。

コンパイラーにバグがあると、デプロイ済みのバイトコードが開発者のソースコードと異なる動作をする可能性があります。

成熟したエコシステムには、再現可能なビルド、ソースコード検証、コンパイラーのバージョン管理、独立したセキュリティレビューが必要です。

カスタムVMとWebAssembly

一般にWasmと呼ばれるWebAssemblyは、ブロックチェーン実行の基盤として利用できる、移植性の高いバイナリー命令形式です。

ブロックチェーンはランタイムやスマートコントラクトをWasmにコンパイルし、制御された環境で実行できます。

Wasmは複数のソース言語をサポートでき、プラットフォームに依存しない実行形式を提供します。

Polkadot SDKは、ブロックチェーンのランタイムロジックをWasmバイナリーとして保存し、オンチェーンガバナンスを通じてランタイムをアップグレードできます。

公式のランタイムアップグレードのドキュメントでは、この設計によって従来のネットワーク全体のハードフォークを必要とせずに機能を追加したり問題を修正したりできると説明しています。

Wasmを使うブロックチェーンでも、ブロックチェーン固有のホスト関数、リソースコスト、状態規則、トランザクションの動作を定義していれば、カスタムVMとみなされます。

Wasmは実行の基盤を提供しますが、暗号資産分野でその基盤がどう動作するかは、チェーンを取り巻くランタイム規則によって決まります。

カスタムVMとアプリケーション特化型ブロックチェーン

アプリケーション特化型ブロックチェーンは、一つのアプリケーション、市場、または活動分野に合わせて設計されます。

無関係なアプリケーションと汎用VMを共有するのではなく、チェーンは自らのユーザー向けに実行規則を構築できます。

Cosmos SDKの公式概要では、開発者が既定のモジュールを組み合わせ、アプリケーションの要件に合わせたカスタムモジュールを作成できると説明しています。

取引に特化したアプリケーションチェーンには、ネイティブな注文マッチングやリスク管理機能を組み込める場合があります。

ゲームチェーンには、ネイティブなアイテム作成、プレイヤーアカウント、低コストで繰り返し行える操作を組み込める場合があります。

IDチェーンでは、状態変更を検証済みの認証情報や認可された発行者に制限することがあります。

一般的な操作を複雑なスマートコントラクトではなくプロトコル機能にすることで、アプリケーション特化型の実行は効率を高められます。

一方、元のランタイムが想定していなかったアプリケーションを将来の開発者が構築したい場合、柔軟性が低くなるという欠点があります。

ロールアップにおけるカスタムVM

ロールアップは、基盤ブロックチェーンの外部でトランザクションを実行し、データ、コミットメント、証明をセトルメントレイヤーに送信します。

ロールアップは実行ソフトウェアを管理するため、基盤レイヤーのVMをそのまま複製せず、カスタムVMを使うことができます。

カスタムVMは、証明コストを抑えたり、別のアカウントモデルをサポートしたり、専用のアプリケーション機能を提供したりできます。

ただし、カスタム実行は既存のウォレット、コントラクト、開発ツールとの互換性を難しくする可能性があります。

別のエコシステムの資産やアプリケーションをサポートするため、ブリッジやインタープリターが必要となる場合があります。

また、セトルメントレイヤーがカスタムVMの結果をどのように検証するかを定めなければなりません。

オプティミスティックロールアップは、不正証明や紛争解決ゲームを利用することがあります。

ゼロ知識ロールアップは、カスタムVMが規則に従ったことを示す有効性証明を提出する場合があります。

ソブリンロールアップは、実行の正しさについて自らのノードと社会的コンセンサスに大きく依存することがあります。

そのため、カスタムVMはロールアップのセキュリティと相互運用性のモデルの一部となります。

カスタムVMとモジュラーブロックチェーン

モジュラーブロックチェーンの設計では、実行、コンセンサス、データ可用性、セトルメントを別々の構成要素に分けます。

この分離により、ロールアップのチームはカスタムVMを選択または構築する自由度が高まります。

Celestiaのデータ可用性のドキュメントでは、複数の実行レイヤーが共有のデータ可用性・セトルメント基盤を利用できると説明しています。

ある実行レイヤーはEVMを使い、別の実行レイヤーはWasm、ゼロ知識VM、アプリケーション固有の状態機械を使うことができます。

こうした柔軟性はモジュラーアーキテクチャの主な利点の一つです。

一方、カスタムVMがデータを取得する方法、メッセージを検証する方法、ブリッジと通信する方法、他のシステムが信頼できる結果を生成する方法を定める必要があります。

データが利用できなかったり、ブリッジが侵害されたりすれば、高性能なVMであってもモジュラーチェーンの安全性は保証されません。

カスタムVMとゼロ知識証明

ゼロ知識仮想マシン（zkVM）は、プログラムを実行しながら、その実行が正しかったことを示す暗号学的証明を生成します。

多くの場合、その証明は計算全体をやり直すより効率よく検証できます。

RISC Zero zkVMのドキュメントでは、任意のRustコードの正しい実行を証明するシステムを説明しています。

技術仕様によると、このVMは32ビットRISC-V命令セットを実装しています。

証明可能な計算向けに設計または適応された場合、zkVMは特殊なカスタムVMの一種です。

カスタムzkVMでは、証明生成を効率化するため、命令、メモリーアクセス、ハッシュ、算術処理を最適化できます。

これにより、ロールアップは大量の実行をコンパクトな証明で検証しやすくなります。

ただし、証明生成には多大な計算リソース、専用ハードウェア、慎重に監査された暗号技術が必要な場合があります。

ゼロ知識証明の有効性と、アプリケーション全体の安全性を混同してはいけません。

アプリケーションの規則に有害な経済設計やプログラミング上の誤りがあっても、VMが規則に従ったことを証明できる場合があります。

カスタムVMとEVM互換性

カスタムVMは、EVMと同一でなくてもEVM互換である場合があります。

EVM互換とは通常、開発者がSolidityのコントラクトをデプロイしたり、使い慣れたEthereum形式のツールをほとんど変更せず使えたりすることを意味します。

EVM同等性はさらに強い主張であり、実行動作がEthereumのEVMに近いことを意味します。

カスタムコンパイラーがSolidityを別の命令セットに変換することがあります。

インタープリターがカスタムVM内でEVMバイトコードを実行することもあります。

互換レイヤーが異なる内部状態や証明システムを使いながら、Ethereum APIを再現する場合もあります。

それぞれの方法には、パフォーマンス、Gasの挙動、デバッグ、コントラクトの前提、アップグレードの複雑さに関するトレードオフがあります。

EVM互換チェーンが、あらゆる例外的な状況でEthereumとまったく同じ動作をすると想定してはいけません。

オペコード、プリコンパイル、ブロック情報、手数料、ファイナリティ、トランザクション順序の違いが、アプリケーションに影響する場合があります。

カスタム仮想マシンの利点

第一の利点は、アプリケーションに特化したパフォーマンスです。

あらゆるアプリケーションを汎用の実行モデルに合わせるのではなく、VMが一般的な処理を最適化できます。

第二の利点は、柔軟な状態モデルです。

開発者は用途に合ったアカウント、オブジェクト、UTXO、モジュール、その他のモデルを選べます。

第三の利点は、並列実行の向上です。

VMがトランザクションの依存関係を明らかにすることで、競合しない処理を同時に実行できる場合があります。

第四の利点は、専用のセキュリティです。

命令セットを限定したり、アプリケーションランタイムを制限したりすることで、攻撃者が試みられる処理の数を減らせる場合があります。

第五の利点は、暗号学的証明を効率化できることです。

カスタムVMは、ゼロ知識証明システムに合わせた命令やメモリー配置を利用できます。

第六の利点は、ユーザー体験の向上です。

実行レイヤーに、アカウント復旧、手数料の肩代わり、セッション権限、予測可能な手数料を組み込める場合があります。

第七の利点は、プロトコルレベルの機能です。

ネイティブ資産、注文板、プライバシー規則、ガバナンスなどを実行環境に直接組み込めます。

カスタムVMのリスクと制約

第一のリスクは実装上の誤りです。

新しいVMは、多数のネットワークで使われてきた成熟した実行環境より、実運用でのテストが少ない傾向があります。

第二のリスクは、開発ツールの不足です。

信頼できるコンパイラー、デバッガー、テストフレームワーク、セキュリティスキャナー、コントラクトライブラリが不足する場合があります。

第三のリスクは、エコシステムとの互換性の制限です。

既存のコントラクト、ウォレット、インフラは、変更なしでは動作しない場合があります。

第四のリスクは、仕様の複雑さです。

命令、リソースコスト、状態規則、システム関数をすべて正確に文書化しなければなりません。

第五のリスクは、アップグレードの中央集権化です。

強いガバナンス制御なしに単一チームがVMを変更できる場合、ユーザーはそのチームが有害な動作を導入しないと信頼する必要があります。

第六のリスクは、セキュリティエコシステムの未成熟です。

監査担当者は、新しいバイトコード形式や実行モデルの経験が少ない場合があります。

第七のリスクは、経済的な価格設定の誤りです。

リソースコストが適切でなければ、サービス妨害攻撃が安価になったり、正当なアプリケーションの利用料が高くなりすぎたりする場合があります。

第八のリスクは、分断です。

互換性のないカスタムVMが増えすぎると、開発者、流動性、ツール、ユーザーが孤立したエコシステムに分散する可能性があります。

カスタムVMのセキュリティ要件

安全なカスタムVMは、異なるノードの実装やハードウェア環境でも決定的に実行されなければなりません。

信頼できないプログラムをバリデーターのOSから隔離する必要があります。

コントラクトストレージ、ユーザー残高、システム権限への不正アクセスを防止しなければなりません。

攻撃者が枯渇させ得るすべてのリソースを計測する必要があります。

整数の上限、メモリー境界、再帰、コントラクト呼び出し、失敗条件を安全に処理しなければなりません。

実行に失敗した場合に状態変更をどう取り消すかを定義する必要があります。

トランザクション、チェーン、ドメインをまたいだ署名のリプレイを防ぐ必要があります。

権限を持つホスト関数やシステムコントラクトを、不正な呼び出し元から保護しなければなりません。

コンパイラーとバイトコード検証ツールは、不正形式や危険なプログラムを拒否する必要があります。

アップグレード手続きには、レビュー、テスト、緊急時の計画、明確なガバナンスが必要です。

セキュリティテストには、単体テスト、統合テスト、差分テスト、ファジング、プロパティテスト、敵対的な経済シミュレーションを含めるべきです。

可能であれば、独立した複数の実装を用意することで、一つのコードベースでは見つからない仕様上の誤りを検出しやすくなります。

カスタムVMのアップグレード

セキュリティバグの修正、命令の追加、パフォーマンスの向上、新たな暗号技術のサポートのため、カスタムVMをアップグレードする必要が生じる場合があります。

すべてのノードが適切な時点から新しい規則を使い始めなければならないため、VMの規則変更は慎重に扱う必要があります。

アップグレードが不適切だと、一部のノードが受け入れるトランザクションを他のノードが拒否し、ネットワークが分岐する可能性があります。

予定されたソフトウェアリリースやハードフォークを通じてVMのアップグレードを調整するブロックチェーンもあります。

ランタイムをオンチェーンに保存し、ガバナンスを通じて変更を承認するものもあります。

ロールアップでは、アップグレード可能なセトルメントコントラクト、セキュリティ委員会、マルチシグ、ガバナンスのタイムロックを使うことがあります。

ユーザーは、誰がカスタムVMのアップグレードを承認できるか、変更の発効前に猶予期間があるかを理解する必要があります。

不変のVMはガバナンスリスクを抑える一方、緊急修正が難しくなります。

アップグレードしやすいVMは迅速に対応できますが、アップグレード権限者への信頼がより強く求められます。

開発者がカスタムVMを評価する方法

まず、VMが対応するプログラミング言語とコンパイラーの成熟度を確認してください。

命令セット、アカウントモデル、ストレージ、手数料、トランザクションのライフサイクルに関するドキュメントを確認してください。

公開されたソースコードからコントラクトを検証できるか調べてください。

デバッグ、ローカルテスト、テストネット、デプロイ、監視のツールを確認してください。

VMがリエントランシー、コントラクト間呼び出し、並行処理、失敗したトランザクションをどう扱うか理解してください。

VMとコンパイラーツールチェーンのセキュリティ監査を確認してください。

既存のウォレット、カストディツール、インデクサー、インフラがネットワークに対応しているか確認してください。

公表されている性能が単純なベンチマークだけでなく、現実的なアプリケーションでも得られるか検証してください。

安全なプログラムでも実行環境の変更に影響されるため、アップグレード権限者についても調べてください。

暗号資産ユーザーがカスタムVMを採用するチェーンを評価する方法

一般のユーザーがVMのすべてのオペコードを読む必要はありませんが、主な信頼上の前提は理解しておくべきです。

カスタムVMが十分な期間、本番環境で稼働しているか確認してください。

監査、技術仕様、インシデント報告、アップグレード通知が公開されているか確認してください。

ウォレットに人が理解しやすい取引内容が表示されるかを把握してください。

カスタムVMのチェーンと他のネットワーク間で資産を移動する際、ブリッジに依存するか確認してください。

チェーンの取引手数料、ファイナリティの規則、シーケンサーの仕組み、出金手順を理解してください。

高いトランザクション処理能力が、強い分散性やセキュリティを自動的に意味すると考えてはいけません。

使い慣れないネットワークやアプリケーションは、価値の高い資産を移す前に少額で試してください。

カスタムVMは便利な機能を実現できますが、ユーザーにはスマートコントラクト、ブリッジ、ウォレット、ガバナンス、市場のリスクが残ります。

カスタムVMの一般的な用途

並列実行を必要とする高スループットのスマートコントラクトネットワークに使われます。

ネイティブなビジネスロジックや制御されたトランザクション形式を必要とするアプリケーションチェーンに使われます。

低コストで多数の状態更新を必要とするブロックチェーンゲームに使われます。

専用の注文処理やリスク計算を必要とする分散型金融システムに使われます。

機密性の高いプログラムやゼロ知識プログラムを実行するプライバシーシステムに使われます。

効率的な有効性証明を必要とするロールアップに使われます。

IDやアクセス制御の要件を持つ企業向けまたは許可型ネットワークに使われます。

クロスチェーンメッセージを効率的に検証する必要がある相互運用レイヤーに使われます。

新しい状態モデル、プログラミング言語、取引手数料の仕組みを扱うブロックチェーン研究にも使われます。

カスタムVMに関するよくある誤解

誤解の一つは、EVM以外のブロックチェーンはすべて従来型のカスタムVMを備えているというものです。

汎用のユーザー作成バイトコードに対応せず、コンパイルされたランタイムやアプリケーション固有の状態機械を使うチェーンもあります。

もう一つの誤解は、カスタムVMは自動的にEVMより高速だというものです。

性能は、状態アクセス、ノードのハードウェア、ネットワーク、コンセンサス、データ可用性、処理負荷、実装品質にも左右されます。

三つ目の誤解は、カスタム実行によって自動的にセキュリティが向上するというものです。

専用VMは一部のリスクを減らせる一方、新たな実装やツール上のリスクを生み出す場合があります。

四つ目の誤解は、EVM互換ならEthereumと完全に同じ動作になるというものです。

互換システムでも、実行、手数料、プリコンパイル、ファイナリティ、インフラに違いがある場合があります。

五つ目の誤解は、zkVMによってすべてのアプリケーションが安全になるというものです。

zkVMは定義された実行規則に従ったことを証明しますが、アプリケーションの経済設計やユーザーの判断が適切だったことまでは証明しません。

六つ目の誤解は、ユーザーがチェーンのVMを気にする必要はないというものです。

VMはウォレット対応、取引手数料、コントラクトのセキュリティ、資産標準、開発活動、ブリッジの必要性に影響する場合があります。

カスタム仮想マシンの将来

暗号資産がロールアップ、モジュラーブロックチェーン、アプリケーション特化型チェーン、ゼロ知識実行へと進むなか、カスタムVMの重要性は増しています。

将来、一つのネットワークで複数の実行環境をサポートするシステムが登場する可能性があります。

ある環境ではEVMコントラクトを実行し、別の環境ではネイティブなWasm、RISC-V、アプリケーション特化型プログラムを処理することが考えられます。

インタープリターやコンパイラーレイヤーによって、異なるVM間でアプリケーションを移行しやすくなる可能性があります。

ゼロ知識証明の進歩によって、より汎用的なプログラムを効率的に検証できるようになる可能性があります。

状態アクセスを安全に予測できるアプリケーションでは、並列実行の研究によって処理能力が向上する場合があります。

カスタムアカウントシステムは、復旧、支出上限、パスキー、セッション権限、手数料の肩代わりを実行レイヤーに直接組み込むことがあります。

長期的な課題は、特化と相互運用性のバランスを取ることです。

高度に特化したVMは一つの処理を非常に効率よく実行できる一方、暗号資産ユーザーには共有ウォレット、資産、流動性、標準、セキュリティツールも必要です。

最も強力なカスタムVMエコシステムは、技術的な利点に加え、成熟したツール、明確な仕様、強固な監査、信頼できるブリッジを備えると考えられます。

FAQ

暗号資産分野のカスタム仮想マシンとは何ですか？

カスタム仮想マシンとは、独自の規則に基づいてプログラムの実行、トランザクションの処理、状態の管理、計算リソースの課金を行うよう設計されたブロックチェーン実行環境です。

Custom VMとはどういう意味ですか？

Custom VMとは、特定のブロックチェーン、ロールアップ、アプリケーションチェーン、証明システムのニーズに合わせて作成または変更された仮想マシンです。

カスタムVMはEVMと同じですか？

いいえ。EVMは特定の実行環境であり、カスタムVMは異なる命令、状態モデル、言語、手数料、セキュリティ規則を採用する場合があります。

ブロックチェーンがカスタムVMを使うのはなぜですか？

パフォーマンスの向上、並列実行、ネイティブなアプリケーション機能、プライバシーの強化、ゼロ知識証明コストの削減などを目的として使う場合があります。

カスタムVMはSolidityに対応できますか？

はい。カスタムコンパイラー、EVMインタープリター、互換レイヤーを通じて対応できますが、Ethereumと完全に同じ動作になるとは限りません。

ブロックチェーンランタイムはVMと同じですか？

必ずしも同じではありません。ランタイムは広く状態遷移ロジックを定めるもので、VMは通常、定義された命令セットに従ってバイトコードを実行します。

zkVMとは何ですか？

zkVMはプログラムを実行し、その実行が定義された規則に従っていたことを示す暗号学的証明を生成する仮想マシンです。

カスタムVMはEVMより高速ですか？

特定の処理負荷では高速なカスタムVMもありますが、実際の性能はコンセンサス、ストレージ、ネットワーク、ハードウェア、アプリケーション設計にも左右されます。

カスタムVMは安全ですか？

決定性、サンドボックス、監査、適切なリソース計測、成熟したツールチェーンを備えれば安全に設計できますが、新しいVMは本番環境でのテストが少ない場合があります。

カスタムVMで使えるプログラミング言語は何ですか？

Solidity、Rust、C、C++、Move、Wasm互換言語、専用のスマートコントラクト言語などに対応する場合があります。

カスタムVMはトランザクションを並列実行できますか？

はい。独立したアカウント、オブジェクト、ストレージ領域にアクセスするトランザクションを特定できれば、並列実行に対応できます。

カスタムVMにGasは必要ですか？

何らかのリソース制御は必要ですが、Gas、計算ユニット、ウェイト、サイクル、その他の計測方式を使う場合があります。

カスタムVMはアップグレードできますか？

はい。ハードフォーク、ガバナンス、ランタイムの置き換え、アップグレード可能なロールアップコントラクトなどを通じてアップグレードできるものが多くあります。

カスタムVMの主な欠点は何ですか？

開発者が、独自のコンパイラー、ウォレット、ツール、標準、ドキュメントを備えた新たな実行エコシステムを構築し、安全性を確保しなければならない点です。

カスタムVMは暗号資産ユーザーに影響しますか？

はい。取引手数料、ウォレット対応、ファイナリティ、コントラクトのセキュリティ、アプリケーションの利用可能性、資産標準、ブリッジの必要性に影響する場合があります。

まとめ

カスタム仮想マシンは、トランザクション、コントラクト、状態変更の処理方法を定める、ブロックチェーン専用の実行環境です。

ブロックチェーン開発者は、パフォーマンス、プログラミング言語、状態モデル、リソースコスト、プライバシー、並列実行、暗号学的証明をより細かく制御できます。

カスタムVMは、ロールアップ、モジュラーブロックチェーン、アプリケーション特化型チェーン、高性能ネットワーク、ゼロ知識システムで特に重要です。

柔軟性によって、汎用環境では実現が難しかったり非効率だったりする機能を提供できます。

ただし、カスタム実行によって新たな責任も生じます。

チームは、安全なコンパイラー、決定的な規則、リソース計測、サンドボックス、開発ツール、ウォレット対応、監査手続き、安全なアップグレードシステムを構築しなければなりません。

カスタムVMを、公表されているトランザクション速度だけで評価すべきではありません。

開発者とユーザーは、セキュリティ実績、状態モデル、互換性、分散性、ガバナンス、証明システム、データ可用性、支援インフラも評価する必要があります。

優れたカスタムVMは、有意義な技術的改善に加え、明確なドキュメントと成熟したセキュリティ対策を備えています。

暗号資産のアーキテクチャがよりモジュール化・アプリケーション特化型へと進むなか、カスタムVMは、ブロックチェーンが競争し、拡張し、新たな分散型アプリケーションを支えるうえで、今後も重要な役割を果たします。