スケーリングの未来：Web3 パラレルコンピューティング分野の全体像
TechFlow厳選深潮セレクト
スケーリングの未来：Web3 パラレルコンピューティング分野の全体像
Web3の並列計算に関するハードコアな解説。
Web3業界の深掘り報道に専念し潮流を洞察執筆：0xjacobzhao 及 ChatGPT 4o
ブロックチェーンの「不可能三角」（Blockchain Trilemma）である「安全性」「非中央集権性」「拡張性」は、ブロックチェーンシステム設計における本質的なトレードオフを示しており、すなわちブロックチェーンプロジェクトが「極致の安全、誰でも参加可能、高速処理」を同時に実現することは非常に困難であるということです。この中で「拡張性」という永遠のテーマについて、現在市場にある主流のブロックチェーンスケーリングソリューションは、パラダイム別に分類すると以下の通りです。
-
実行強化型スケーリング：実行能力をそのまま向上させる。例：並列処理、GPU、マルチコア
-
状態分離型スケーリング：状態／シャードを水平方向に分割。例：シャーディング、UTXO、複数サブネット
-
オンチェーン外委託型スケーリング：実行をチェーン外に移す。例：Rollup、Coprocessor、DA
-
構造分離型スケーリング：アーキテクチャのモジュール化と協調動作。例：モジュールチェーン、共有ソーター、Rollup Mesh
-
非同期並发型スケーリング：Actorモデル、プロセス分離、メッセージ駆動。例：エージェント、マルチスレッド非同期チェーン
ブロックチェーンスケーリングソリューションには、チェーン内並列計算、Rollup、シャーディング、DAモジュール、モジュラー構造、Actorシステム、zk証明圧縮、Statelessアーキテクチャなどが含まれ、実行、状態、データ、構造といった複数レイヤーにわたり、「多層協働・モジュール組み合わせ」による包括的なスケーリング体系を形成しています。本稿では特に並列計算を中心とするスケーリング方式に焦点を当てて紹介します。
チェーン内並列計算 (intra-chain parallelism) とは、ブロック内部でのトランザクション／命令の並列実行に注目するものです。並列メカニズムによって分類すると、そのスケーリング方式は大きく五つに分けられ、それぞれ異なる性能追求、開発モデル、アーキテクチャ哲学を表しており、順に並列粒度が細かくなり、並列強度が高くなり、スケジューリングの複雑さも増し、プログラミングおよび実装の難易度も上昇します。
-
アカウントレベル並列（Account-level）：代表プロジェクト Solana
-
オブジェクトレベル並列（Object-level）：代表プロジェクト Sui
-
トランザクションレベル並列（Transaction-level）: 代表プロジェクト Monad, Aptos
-
呼び出しレベル／マイクロVM並列（Call-level / MicroVM）: 代表プロジェクト MegaETH
-
命令レベル並列（Instruction-level）: 代表プロジェクト GatlingX
チェーン外非同期並列モデルは、Actorエージェントシステム（Agent / Actor Model）を代表とし、これは別の並列計算パラダイムに属します。跨チェーン／非同期メッセージシステム（ブロック同期モデルではない）として、各エージェント（Agent）が独立して動作する「スマートプロセス」となり、並列方式は非同期メッセージ、イベント駆動であり、同期スケジューリングを必要としません。代表プロジェクトにはAO、ICP、Cartesiなどがあります。
一方で広く知られているRollupやシャーディングによるスケーリングソリューションは、システムレベルの並列メカニズムに該当し、チェーン内並列計算には含まれません。これらは「複数のチェーン／実行ドメインを並列に運営する」ことでスケーリングを実現しているものであり、単一ブロック／仮想マシン内部の並列度を向上させるものではありません。このようなスケーリングソリューションは本稿の主な議論対象ではありませんが、アーキテクチャ理念の比較において言及します。
二、EVM系並列強化チェーン：互換性を保ちながら性能限界を突破
イーサリアムの逐次処理アーキテクチャは、シャーディング、Rollup、モジュラー構造など幾度かのスケーリング試みを経てきましたが、実行レイヤーのスループットボトルネックは依然根本的に解決されていません。一方で、EVMおよびSolidityは、現時点において最も豊富な開発者基盤とエコシステム勢力を有するスマートコントラクトプラットフォームです。そのため、エコシステム互換性と実行性能の両立を図るEVM系並列強化チェーンは、新たなスケーリング進化の重要な方向性となっています。MonadとMegaETHはこの方向性において最も代表的なプロジェクトであり、それぞれ遅延実行と状態分解から出発し、高並列・高スループットシナリオ向けのEVM並列処理アーキテクチャを構築しています。
Monadの並列計算メカニズムの解析
Monadは、イーサリアム仮想マシン（EVM）向けに再設計された高性能Layer1ブロックチェーンであり、パイプライン処理（Pipelining）という基本的並列概念に基づき、コンセンサス層で非同期実行（Asynchronous Execution）、実行層で楽観的並列実行（Optimistic Parallel Execution）を実現しています。また、コンセンサス層とストレージ層において、高性能BFTプロトコル（MonadBFT）と専用データベースシステム（MonadDB）を導入することで、エンドツーエンドの最適化を達成しています。
Pipelining：多段階パイプライン並列実行メカニズム
PipeliningはMonadの並列実行の基本理念であり、その核心思想は、ブロックチェーンの実行プロセスを複数の独立した段階に分割し、それらを並列化することで立体的なパイプラインアーキテクチャを形成することです。各段階は独立したスレッドまたはコア上で動作し、クロスブロッキングの並列処理を実現することで、スループットの向上と遅延の低減を達成します。これらの段階には、トランザクション提案（Propose）、コンセンサス確立（Consensus）、実行（Execution）、ブロックコミット（Commit）が含まれます。
Asynchronous Execution：コンセンサス－実行の非同期分離
従来のチェーンでは、トランザクションのコンセンサスと実行は通常同期プロセスであり、この逐次モデルは性能拡張を大きく制限していました。Monadは「非同期実行」により、コンセンサス層、実行層、ストレージ層の非同期化を実現しました。これによりブロック時間（block time）と確認遅延を大幅に削減し、システムの柔軟性を高め、処理プロセスをより細分化し、リソース利用率を向上させました。
主要設計：
-
コンセンサスプロセス（コンセンサス層）はトランザクションの順序決定のみを担当し、コントラクトロジックの実行は行わない。
-
実行プロセス（実行層）はコンセンサス完了後に非同期にトリガーされる。
-
コンセンサス完了後は直ちに次のブロックのコンセンサスプロセスに入り、実行完了を待たない。
Optimistic Parallel Execution：楽観的並列実行
従来のイーサリアムは、状態衝突を回避するためトランザクション実行に厳密な逐次モデルを採用しています。一方、Monadは「楽観的並列実行」戦略を採用し、トランザクション処理速度を大幅に向上させます。
実行メカニズム：
-
Monadは、大部分のトランザクション間に状態衝突がないと仮定し、すべてのトランザクションを楽観的に並列実行する。
-
同時に「衝突検出器（Conflict Detector）」を稼働させ、トランザクション間で同じ状態（読み取り／書き込み衝突など）へのアクセスがあるか監視する。
-
衝突が検出された場合、衝突トランザクションを逐次化して再実行し、状態の正確性を確保する。
Monadは互換性路線を選択しています。EVMルールをできるだけ最小限に変更し、実行中に状態書き込みを遅らせ、動的衝突検出を行うことで並列化を実現しています。これはあたかも「高性能版イーサリアム」であり、成熟度が高く、EVMエコシステムの移行が容易で、EVM世界の並列アクセラレータと言えます。
MegaETHの並列計算メカニズムの解析
MonadのL1ポジショニングとは異なり、MegaETHはEVM互換のモジュラー型高性能並列実行層として位置づけられており、独立したL1パブリックチェーンとしても、イーサリアム上の実行強化層（Execution Layer）あるいはモジュラー部品としても機能可能です。その核心設計目標は、アカウントロジック、実行環境、状態を独立してスケジューリング可能な最小単位に分離・解体し、チェーン内の高並列実行と低遅延応答能力を実現することです。MegaETHが提唱するキーナンスは、「Micro-VMアーキテクチャ＋State Dependency DAG（有向非巡回状態依存グラフ）＋モジュラー同期メカニズム」であり、これらが共同で「チェーン内スレッド化」を指向した並列実行体系を構築しています。
Micro-VM（マイクロ仮想マシン）アーキテクチャ：アカウント即ちスレッド
MegaETHは「各アカウントにマイクロ仮想マシン（Micro-VM）を割り当てる」という実行モデルを導入し、実行環境を「スレッド化」することで、並列スケジューリングの最小分離単位を提供します。これらのVM同士は同期呼び出しではなく非同期メッセージ通信（Asynchronous Messaging）で接続され、多数のVMが独立して実行・保存でき、自然に並列化されます。
State Dependency DAG：依存関係グラフ駆動型スケジューリングメカニズム
MegaETHは、アカウントの状態アクセス関係に基づくDAGスケジューリングシステムを構築し、グローバルな依存グラフ（Dependency Graph）をリアルタイムで維持します。各トランザクションがどのアカウントを変更・読み取ったかをすべて依存関係としてモデル化します。衝突のないトランザクションは直接並列実行でき、依存関係のあるトランザクションはトポロジー順に逐次または遅延スケジューリングされます。この依存グラフは並列実行中の状態整合性と重複書き込み防止を保証します。
非同期実行とコールバックメカニズム
MegaETHは非同期プログラミングパラダイムに基づいて構築されており、Actor Modelのような非同期メッセージ伝達により、従来のEVM逐次呼び出し問題を解決します。コントラクト呼び出しは非同期的（再帰的実行なし）であり、A→B→Cと呼び出す際、各呼び出しが非同期化され、ブロッキング待機が不要になります。コールスタックは非同期呼び出しグラフ（Call Graph）に展開され、トランザクション処理＝非同期グラフの走査＋依存関係解釈＋並列スケジューリングとなります。
まとめると、MegaETHは従来のEVM単一スレッド状態機械モデルを打破し、アカウント単位でマイクロVMをカプセル化し、状態依存グラフでトランザクションをスケジューリングし、同期コールスタックを非同期メッセージメカニズムに置き換えます。これは「アカウント構造→スケジューリングアーキテクチャ→実行プロセス」に至る全次元にわたる再設計された並列計算プラットフォームであり、次世代高性能オンチェーンシステム構築にパラダイムレベルの新アイデアを提供します。
MegaETHは再構築路線を選択しています。アカウントとコントラクトを完全に独立したVMとして抽象化し、非同期実行スケジューリングを通じて極限の並列可能性を解放します。理論的にはMegaETHの並列上限はより高いですが、複雑さの制御も難しく、あたかもイーサリアム理念に基づくスーパーディストリビューテッドオペレーティングシステムのようです。
MonadとMegaETHの設計理念は、シャーディング（Sharding）とは大きく異なります。シャーディングはブロックチェーンを横方向に複数の独立サブチェーン（シャード）に分割し、各シャードが部分的なトランザクションと状態を担当することで、単一チェーンの制約をネットワーク層で拡張します。一方、MonadとMegaETHは単一チェーンの整合性を保持し、実行層のみを横方向に拡張し、単一チェーン内部で極限の並列実行最適化により性能を突破します。両者はブロックチェーン拡張パスにおける縦方向強化と横方向拡張という二つの方向を代表しています。
MonadやMegaETHなどの並列計算プロジェクトは主にスループット最適化に集中しており、チェーン内TPS向上を核心目標とし、遅延実行（Deferred Execution）とマイクロ仮想マシン（Micro-VM）アーキテクチャを通じてトランザクションレベルまたはアカウントレベルの並列処理を実現しています。一方、Pharos Networkはモジュラーかつフルスタック並列のL1ブロックチェーンネットワークであり、その核心並列計算メカニズムは「Rollup Mesh」と呼ばれています。このアーキテクチャはメインネットと特殊処理ネットワーク（SPNs）の協働により、複数仮想マシン環境（EVMおよびWasm）をサポートし、ゼロナレッジ証明（ZK）、信頼できる実行環境（TEE）などの先進技術を統合しています。
Rollup Mesh並列計算メカニズムの解析：
-
ライフサイクル全体の非同期パイプライン処理（Full Lifecycle Asynchronous Pipelining）： Pharosはトランザクションの各段階（コンセンサス、実行、ストレージなど）を分離し、非同期処理方式を採用することで、各段階が独立して並列処理可能となり、全体の処理効率を向上させます。
-
二重仮想マシン並列実行（Dual VM Parallel Execution）： PharosはEVMとWASMの二種類の仮想マシン環境をサポートし、開発者がニーズに応じて適切な実行環境を選択できるようにします。この二重VMアーキテクチャはシステムの柔軟性を高めるだけでなく、並列実行によりトランザクション処理能力を向上させます。
-
特殊処理ネットワーク（SPNs）： SPNsはPharosアーキテクチャのキーコンポーネントであり、モジュラー化されたサブネットワークに似ており、特定タイプのタスクやアプリケーションの処理に特化しています。SPNsにより、Pharosはリソースの動的割り当てとタスクの並列処理を実現し、システムのスケーラビリティと性能をさらに強化します。
-
モジュラー型コンセンサスとリステーキングメカニズム（Modular Consensus & Restaking）： Pharosは柔軟なコンセンサスメカニズムを導入し、複数のコンセンサスモデル（PBFT、PoS、PoAなど）をサポートし、リステーキングプロトコル（Restaking）を通じてメインネットとSPNs間のセキュリティ共有とリソース統合を実現します。
さらに、PharosはマルチバージョンMerkle木、差分符号化（Delta Encoding）、バージョンアドレッシング（Versioned Addressing）、ADSプッシュダウン（ADS Pushdown）などの技術を用い、ストレージエンジンの基底部から実行モデルを再構築し、ブロックチェーン初生高性能ストレージエンジン「Pharos Store」をリリースし、高スループット、低遅延、強力な検証性を持つオンチェーン処理能力を実現します。
総じて、PharosのRollup Meshアーキテクチャはモジュラー設計と非同期処理メカニズムにより、高性能並列計算能力を実現しています。Pharosは跨Rollup並列のスケジューリング調整者であり、「チェーン内並列」の実行最適化者ではなく、SPNsを通じて異種カスタム実行タスクを担います。
Monad、MegaETH、Pharosの並列実行アーキテクチャに加えて、EVM並列エコシステムの重要な補完と先端実験として、GPU加速をEVM並列計算に応用する道を探求するプロジェクトも存在することが観察されています。その中でReddioとGatlingXは二つの代表的な方向性を持っています。
-
ReddioはzkRollupとGPU並列実行アーキテクチャを組み合わせた高性能プラットフォームであり、その核はEVM実行プロセスの再構築にあり、マルチスレッドスケジューリング、非同期状態保存、GPUによるトランザクションバッチの加速処理を通じて、実行レイヤーのネイティブ並列化を実現しています。並列粒度はトランザクションレベル＋操作レベル（マルチスレッドでopcodeを実行）に該当します。この設計はマルチスレッドバッチ処理実行、非同期状態ロード、GPUによるトランザクションロジックの並列処理（CUDA対応並列EVM）を導入しています。Monad／MegaETHと同様、Reddioも実行レイヤーの並列処理に注力していますが、違いはGPU並列アーキテクチャで実行エンジンを再構築し、高スループット・計算集約型シナリオ（AI推論など）向けに設計されている点です。既にSDKをリリースし、統合可能な実行モジュールを提供しています。
-
GatlingXは自称「GPU-EVM」として、より過激なアーキテクチャを提案し、従来のEVM仮想マシンの「命令レベル逐次実行」モデルをGPUネイティブの並列実行環境へ移行しようとしています。その核メカニズムは、EVMバイトコードを動的にCUDA並列タスクにコンパイルし、GPUマルチコアで命令ストリームを実行することで、EVMの順次ボトルネックを最も底層から打破することです。これは命令レベル（Instruction-Level Parallelism, ILP）の並列粒度に該当します。Monad／MegaETHの「トランザクションレベル／アカウントレベル」並列粒度と比べ、GatlingXの並列メカニズムは命令レベル最適化の道筋にあり、仮想マシンエンジンの底層再構築により近いです。現在はコンセプト段階で、ホワイトペーパーとアーキテクチャスケッチを公開済みですが、SDKやメインネットはまだありません。
Artelaは異なる並列設計理念を提示しています。EVM++アーキテクチャとWebAssembly（WASM）仮想マシンを導入し、開発者がEVM互換性を保ちつつ、Aspectプログラミングモデルを利用してオンチェーンで動的に拡張プログラムを追加・実行できるようにします。最小並列単位はコントラクト呼び出し粒度（Function／Extension）であり、EVMコントラクト実行時にExtensionモジュール（「プラグイン可能なミドルウェア」に類似）を注入可能とし、ロジックの分離、非同期呼び出し、モジュールレベルの並列実行を実現します。実行レイヤーの組み合わせ可能性とモジュラー構造に重点を置いています。この理念は将来の複雑多モジュールアプリケーションに新たなアイデアを提供します。
三、ネイティブ並列アーキテクチャチェーン：VMの実行本体を再構築
イーサリアムのEVM実行モデルは当初から「トランザクション全順序＋逐次実行」のシングルスレッドアーキテクチャを採用し、ネットワーク内の全ノードが状態変更に対して決定性と一貫性を持つことを目的としています。しかし、このアーキテクチャは性能面で天然のボトルネックを持ち、システムのスループットと拡張性を制限しています。これに対して、Solana（SVM）、MoveVM（Sui、Aptos）、Cosmos SDKに基づくSei v2などのネイティブ並列計算アーキテクチャチェーンは、設計初期から並列実行を念頭に置いたものであり、以下のような利点があります。
-
状態モデルが天然に分離：Solanaはアカウントロック宣言メカニズム、MoveVMはオブジェクト所有モデル、Sei v2はトランザクションタイプ分類に基づき、静的衝突判定を実現し、トランザクションレベルの並列スケジューリングをサポート。
-
仮想マシンが並列処理向けに最適化：SolanaのSealevelエンジンはネイティブにマルチスレッド実行をサポート。MoveVMは静的並列グラフ分析が可能。Sei v2はマルチスレッドマッチングエンジンと並列VMモジュールを統合。
もちろん、こうしたネイティブ並列チェーンはエコシステム互換性の課題にも直面しています。非EVMアーキテクチャは通常、新しい開発言語（Move、Rustなど）とツールチェーンを必要とし、開発者にとって移行コストが生じます。さらに、状態アクセスモデル、並列制限、オブジェクトライフサイクルなど一連の新概念を習得する必要があり、理解のハードルと開発パラダイムに対する要求が高くなります。
3.1 SolanaおよびSVM系のSealevel並列エンジン原理
SolanaのSealevel実行モデルはアカウント並列スケジューリングメカニズムであり、チェーン内並列トランザクション実行を実現するための核心エンジンです。「アカウント宣言＋静的スケジューリング＋マルチスレッド実行」メカニズムにより、スマートコントラクトレベルの高性能並列を実現します。Sealevelはブロックチェーン領域で初めて本番環境でチェーン内並列スケジューリングを成功裏に実現した実行モデルであり、そのアーキテクチャ思想はその後の多くの並列計算プロジェクトに影響を与え、高性能Layer1並列設計の参考パラダイムとなっています。
核メカニズム：
1、明示的アカウントアクセス宣言（Account Access Lists）： 各トランザクションは提出時にアクセスするアカウント（読み取り／書き込み）を宣言しなければならず、システムはこれに基づいてトランザクション間に状態衝突があるか判断します。
2、衝突検出とマルチスレッドスケジューリング
-
二つのトランザクションがアクセスするアカウントセットに重なりがない → 並列実行可能。
-
衝突あり → 依存順に逐次実行。
-
スケジューラは依存グラフに基づきトランザクションを異なるスレッドに割り当てる。
3、独立実行コンテキスト（Program Invocation Context）： 各コントラクト呼び出しは隔離されたコンテキスト内で動作し、共有スタックがなく、クロス呼び出し干渉を回避。
SealevelはSolanaの並列実行スケジューリングエンジンであり、SVMはSealevel上に構築されたスマートコントラクト実行環境（BPF仮想マシン使用）です。両者はSolanaの高性能並列実行体系の技術的基礎を共同で構成しています。
Eclipseは、Solana VMをモジュラー型チェーン（イーサリアムL2またはCelestiaなど）に展開するプロジェクトであり、Solanaの並列実行エンジンをRollup実行層として利用します。EclipseはSolanaの実行層（Sealevel＋SVM）をSolanaメインネットから切り離し、モジュラー構造に移行する最初期のプロジェクトの一つであり、Solanaの「超並列実行モデル」をモジュラー化し、「Execution Layer-as-a-Service」として提供します。したがってEclipseも並列計算の大分類に含まれます。
Neonの路線は異なり、EVMをSVM／Sealevel環境に導入して実行するものです。EVM互換の実行層を構築し、開発者がSolidityでコントラクトを開発してSVM環境下で実行できるようにしますが、スケジューリング実行にはSVM＋Sealevelを使用します。Neonはむしろモジュラー型ブロックチェーン（Modular Blockchain）の範疇に近く、並列計算の革新を強調していません。
要するに、SolanaおよびSVMはSealevel実行エンジンに依存しており、SolanaのOSスタイルのスケジューリング哲学はカーネルスケジューラに似ており、実行が高速ですが、柔軟性は比較的低い。ネイティブ高性能・並列計算型パブリックチェーンです。
3.2 MoveVMアーキテクチャ：リソースとオブジェクト駆動
MoveVMはオンチェーンリソースの安全と並列実行を目的に設計されたスマートコントラクト仮想マシンであり、その核言語Moveは当初Meta（旧Facebook）がLibraプロジェクトのために開発したもので、「リソース即ちオブジェクト」という理念を強調しています。すべてのオンチェーン状態はオブジェクトとして存在し、明確な所有権とライフサイクルを持ちます。これによりMoveVMはコンパイル時に対象トランザクション間に状態衝突があるか分析でき、オブジェクトレベルの静的並列スケジューリングを実現します。SuiやAptosなどのネイティブ並列パブリックチェーンで広く採用されています。
Suiのオブジェクト所有モデル
Suiの並列計算能力は、独自の状態モデリング方式と言語レベルの静的分析メカニズムに由来します。従来のブロックチェーンがグローバル状態ツリーを採用するのに対し、Suiは「オブジェクト」に基づく状態モデル（オブジェクト中心モデル）を構築し、MoveVMの線形型システムと組み合わせることで、並列スケジューリングをコンパイル時に行える確定的プロセスにしています。
-
オブジェクトモデル（Object Model）はSui並列アーキテクチャの基礎です。Suiはオンチェーンのすべての状態を独立したオブジェクト（Object）として抽象化し、各オブジェクトは唯一のID、明確な所有者（アカウントまたはコントラクト）、型定義を持ちます。これらのオブジェクト間は状態を共有せず、天然の分離性を持ちます。コントラクト呼び出し時には関与するオブジェクト集合を明示的に宣言しなければならず、従来の「グローバル状態ツリー」における状態結合問題を回避します。この設計によりオンチェーン状態が複数の独立単位に分割され、並列実行が構造的に可能なスケジューリング前提となります。
-
静的所有分析（Static Ownership Analysis）はMove言語の線形型システムを活用したコンパイル時分析メカニズムです。システムはトランザクション実行前に対象オブジェクトの所有権から、どのトランザクションが状態衝突を起こさないかを推論でき、それらを並列実行に割り当てることができます。従来の実行時衝突検出とロールバックと比べ、Suiの静的分析メカニズムは実行効率を向上させると同時に、スケジューリングの複雑さを大幅に低減し、高スループット、確定的並列処理能力を実現する鍵となっています。
Suiはオブジェクト単位で状態空間を分割し、コンパイル時所有分析と組み合わせることで、低コストかつロールバック不要のオブジェクトレベル並列実行を実現しています。従来の逐次実行または実行時検出と比べ、Suiは実行効率、システム確定性、リソース利用率の面で顕著な向上を達成しています。
AptosのBlock-STM実行メカニズム
AptosはMove言語に基づく高性能Layer1ブロックチェーンであり、その並列実行能力は主に独自開発のBlock-STM（Block-level Software Transactional Memory）フレームワークに由来しています。Suiが「コンパイル時静的並列」を志向するのに対し、Block-STMは「実行時楽観的並列＋衝突ロールバック」の動的スケジューリングメカニズムであり、複雑な依存関係を持つトランザクションセットの処理に適しています。
Block-STMは1ブロックのトランザクション実行を3段階に分ける：
-
楽観的並列実行（Speculative Execution）： 実行前にすべてのトランザクションは衝突しないと仮定し、システムはトランザクションを複数スレッドに並列スケジューリングして同時実行を試み、アクセスしたアカウント状態（読み取りセット／書き込みセット）を記録。
-
衝突検出と検証（Validation Phase）： システムは実行結果を検証：二つのトランザクション間に読み取り・書き込み衝突がある場合（例：Tx1がTx2が書き込んだ状態を読み取った）、どちらか一方をロールバック。
-
衝突トランザクションのロールバック再試行（Retry Phase）： 衝突トランザクションは再びスケジューリングされ、依存関係が解決されるまで再実行され、最終的にすべてのトランザクションが有効で確定的な状態送信シーケンスを形成します。
Block-STMは「楽観的並列＋ロールバック再試行」の動的実行モデルであり、状態集約型、ロジック複雑なオンチェーントランザクションバッチ処理シナリオに適しており、Aptosが高汎用性、高スループットパブリックチェーンを構築するための並列計算核です。
Solanaは工学的スケジューリング派で、「OSカーネル」のようで、明確な状態境界、制御可能な高頻度取引に適しており、ハードウェアエンジニアスタイル、ハードウェアのようにチェーンを動かす（Hardware-grade parallel execution）。Aptosはシステム耐障害派で、「データベース並列エンジン」のようで、状態結合が強く、コールチェーンが複雑なコントラクト体系に適している。Suiはコンパイル安全派で、「リソース型スマート言語プラットフォーム」のようで、資産分離、組み合わせが明確なオンチェーンアプリケーションに適している。AptosとSuiはプログラム言語エンジニアのように、ソフトウェアのように安全にチェーンを動かす（Software-grade resource security）。三者はWeb3並列計算が異なる哲学の下で技術実装された道筋を代表しています。
3.3 Cosmos SDK並列拡張型
Sei V2はCosmos SDKに基づく高性能取引型パブリックチェーンであり、その並列能力は主に二つの側面に現れます：マルチスレッドマッチングエンジン（Parallel Matching Engine）と仮想マシン層の並列実行最適化。高頻度、低遅延なオンチェーン取引シナリオ（注文簿DEX、オンチェーン取引所インフラなど）にサービスを提供することを目指しています。
核並列メカニズム：
-
並列マッチングエンジン： Sei V2は注文マッチングロジックにマルチスレッド実行パスを導入し、板情報とマッチングロジックをスレッドレベルで分割することで、複数市場（取引ペア）間のマッチングタスクを並列処理し、シングルスレッドボトルネックを回避。
-
仮想マシンレベルの並列最適化： Sei V2は並列実行能力を持つCosmWasm実行環境を構築し、状態衝突がない条件下で一部コントラクト呼び出しを並列実行可能とし、トランザクションタイプ分類メカニズムと組み合わせてより高いスループット制御を実現。
-
並列コンセンサスと実行層スケジューリングの協調： 所謂「Twin-Turbo」コンセンサスメカニズムを導入し、コンセンサス層と実行層間のスループット分離を強化し、全体のブロック処理効率を向上。
3.4 UTXOモデル再構築者Fuel
Fuelはイーサリアムモジュラー構造に基づいて設計された高性能実行層であり、その核並列メカニズムは改良型UTXOモデル（Unspent Transaction Output）に由来します。イーサリアムのアカウントモデルとは異なり、Fuelは資産と状態を表すためにUTXO構造を使用しており、このモデルは天然に状態分離性を持ち、どのトランザクションが安全に並列実行可能かを判断しやすいです。さらに、Fuelは独自開発のスマートコントラクト言語Sway（Rustに類似）を導入し、静的分析ツールと組み合わせることで、実行前に投入衝突を特定し、効率的かつ安全なトランザクションレベルの並列スケジューリングを実現します。性能とモジュール性を兼ね備えたEVM代替実行層です。
四、Actor Model：スマートエージェント並列実行の新パラダイム
Actor Modelは、スマートエージェントプロセス（AgentまたはProcess）を単位とする並列実行パラダイムであり、従来のチェーン上グローバル状態の同期計算（Solana/Sui/Monadなどの「チェーン内並列計算」）とは異なり、各エージェントが独立した状態と行動を持ち、非同期メッセージで通信とスケジューリングを行うことを強調します。このアーキテクチャ下では、オンチェーンシステムは多数の相互に分離されたプロセスが並列実行され、極めて高いスケーラビリティと非同期耐障害性を持ちます。代表プロジェクトにはAO（Arweave AO）、ICP（Internet Computer）、Cartesiがあり、ブロックチェーンを実行エンジンから「オンチェーンOS」へ進化させ、AIエージェント、マルチタスクインタラクション、複雑ロジック編成にネイティブなインフラを提供しています。
Actor Modelの設計は表面的特徴（並列性、状態分離、非同期処理）においてシャーディング（Sharding）とある程度似ていますが、本質的にそれは全く異なる技術路線とシステム哲学を表しています。Actor Modelは「マルチプロセス非同期計算」を強調し、各スマートエージェント（Actor）が独立して動作し、独立して状態を維持し、メッセージ駆動方式で相互作用します。一方、シャーディングは「状態とコンセンサスの水平分割」メカニズムであり、ブロックチェーン全体を複数の独立したトランザクション処理サブシステム（シャード）に分割します。Actor ModelはWeb3世界における「分散型スマートエージェントOS」のようであり、シャーディングはチェーン内トランザクション処理能力の構造的スケーリングソリューションです。両者とも並列性を実現していますが、出発点、目標、実行アーキテクチャは異なります。
4.1 AO (Arweave)、ストレージ層の上に立つスーパー並列コンピュータ
AOはArweaveの永続ストレージ層上で動作する分散型計算プラットフォームであり、大規模非同期スマートエージェントの実行を可能にするオンチェーンOSの構築がその核心目標です。
核アーキテクチャ特性：
-
Processアーキテクチャ： 各スマートエージェントはProcessと呼ばれ、独立した状態、独立したスケジューラ、独立した実行ロジックを持つ。
-
ブロックチェーン構造なし： AOはチェーンではなく、Arweaveの分散ストレージ層＋マルチスマートエージェントメッセージ駆動実行エンジンに基づく。
-
非同期メッセージスケジューリングシステム： Process間はメッセージ（Message）で通信し、ロックフリーの非同期実行モデルを採用しており、自然に並列拡張をサポート。
-
状態永続保存： すべてのスマートエージェント状態、メッセージ記録、命令は永久にArweave上に記録され、完全な監査性と分散透明性を保証。
-
エージェントネイティブ： 複雑な多段階タスク（AIエージェント、DePINプロトコルコントローラ、自動タスクオーケストレーターなど）の配置に適しており、「オンチェーンAIコプロセッサ」を構築可能。
AOは極致の「スマートエージェントネイティブ＋ストレージ駆動＋無チェーンアーキテクチャ」路線を歩んでおり、柔軟性とモジュール分離を強調し、「ストレージ層の上に架設されたオンチェーンマイクロカーネルフレームワーク」です。システム境界を意図的に縮小し、軽量計算＋組み合わせ可能な制御構造を強調しています。
4.2 ICP (Internet Computer)、フルスタックWeb3ホスティングプラットフォーム
ICPはDFINITYがリリースしたWeb3ネイティブフルスタックオンチェーンアプリケーションプラットフォームであり、オンチェーン計算能力をWeb2クラスの体験にまで拡張し、完全なサービスホスティング、ドメインバインディング、サーバーレスアーキテクチャをサポートすることを目指しています。
核アーキテクチャ特性：
-
Canisterアーキテクチャ（コンテナ即ちスマートエージェント）： 各CanisterはWasm VM上で動作するスマートエージェントであり、独立した状態、コード、非同期スケジューリング能力を持つ。
-
サブネット分散コンセンサスシステム（Subnet）： 全ネットワークは複数のSubnetで構成され、各Subnetが一連のCanisterを管理し、BLS署名メカニズムでコンセンサスを達成。
-
非同期呼び出しモデル： Canister間は非同期メッセージ通信で接続され、ノンブロッキング実行をサポートし、天然の並列性を持つ。
-
オンチェーンWebホスティング： スマートコントラクトが直接フロントエンドページをホスト可能で、ネイティブDNSマッピングをサポート。ブラウザから直接dAppにアクセスできる最初のブロックチェーンプラットフォーム。
-
システム機能充実： オンチェーンホットアップグレード、認証身分、分散乱数、タイマーなどのシステムAPIを備え、複雑なオンチェーンサービスの展開に適している。
ICPは重厚なプラットフォーム、一体型パッケージ、強いプラットフォーム制御を特徴とするOSパラダイムを選択しており、コンセンサス、実行、ストレージ、接続が一体化した「ブロックチェーンOS」であり、完全なサービスホスティング能力を強調し、システム境界をフルスタックWeb3ホスティングプラットフォームまで拡大しています。
その他、Actor Modelパラダイムの並列計算プロジェクトは下表を参照してください。
五、まとめと展望
仮想マシンアーキテクチャと言語システムの違いに基づき、ブロックチェーン並列計算ソリューションは大別して二種類に分けられます：EVM系並列強化チェーンとネイティブ並列アーキテクチャチェーン（非EVM）です。
前者はEVM／Solidityエコシステム互換性を維持しつつ、実行レイヤーを深く最適化することで、より高いスループットと並列処理能力を実現し、イーサリアム資産と開発ツールを継承しつつも性能を突破したいシナリオに適しています。代表プロジェクトは以下の通りです。
-
Monad： 遅延書き込みと実行時衝突検出により、EVM互換の楽観的並列実行モデルを実現。コンセンサス完了後に依存グラフを構築し、マルチスレッドでスケジューリング実行。
-
MegaETH： 各アカウント／コントラクトを独立したマイクロ仮想マシン（Micro-VM）として抽象化し、非同期メッセージ伝達と状態依存グラフに基づき、高度に分離されたアカウントレベル並列スケジューリングを実現。
-
Pharos： Rollup Meshアーキテクチャを構築し、非同期パイプラインとSPNモジュールの協働により、跨プロセスのシステムレベル並列処理を実現。
-
Reddio： zkRollup＋GPUアーキテクチャを採用し、バッチSNARK生成によるzkEVMのチェーン外検証プロセスを加速し、検証スループットを向上。
後者はイーサリアム互換性の制約を完全に離れ、仮想マシン、状態モデル、スケジューリングメカニズムから実行パラダイムを再設計し、ネイティブな高性能並列能力を実現します。代表的サブカテゴリは以下の通りです。
-
Solana（SVM系）： アカウントアクセス宣言と静的衝突グラフスケジューリングに基づく、アカウントレベル並列の実行モデルを代表。
-
Sui／Aptos（MoveVM系）： リソースオブジェクトモデルと型システムを基盤とし、コンパイル時静的分析をサポートし、オブジェクトレベル並列を実現。
-
Sei V2（Cosmos SDK路線）： Cosmosアーキテクチャにマルチスレッドマッチングエンジンと仮想マシン並列最適化を導入し、取引型高頻度アプリケーションに適している。
-
Fuel（UTXO＋Swayアーキテクチャ）： UTXO入力セットの静的分析によりトランザクションレベル並列を実現し、モジュラー実行層とカスタムスマートコントラクト言語Swayを組み合わせ。
さらに、Actor Modelはより広義の並列体系として、WasmまたはカスタムVMに基づく非同期プロセススケジューリングメカニズムにより、「複数スマートエージェントの独立実行＋メッセージ駆動協働」のオンチェーン実行パラダイムを構築します。代表プロジェクトは以下の通りです。
-
AO（Arweave AO）： 永続ストレージ駆動のスマートエージェントランタイムに基づき、オンチェーン非同期マイクロカーネルシステムを構築。
-
ICP（Internet Computer）： コンテナ化スマートエージェント（Canister）を最小単位とし、サブネット協調により非同期高スケーラブル実行を実現。
-
Cartesi： Linux OSをチェーン外計算環境として導入し、信頼できる計算結果のオンチェーン検証パスを提供。複雑またはリソース集約型アプリケーションに適している。
上記の論理に基づき、現在主流の並列計算パブリックチェーンソリューションを以下のような分類構造に整理できます。
より広義のスケーリング視点から見ると、シャーディング（Sharding）とRollup（L2）は状態分割またはチェーン外実行によりシステムの水平拡張を実現するのに対し、並列計算チェーン（Monad、Sui、Solanaなど）とActor指向システム（AO、ICPなど）は実行モデル自体を再構築し、チェーン内またはシステム層でネイティブ並列を実現します。前者はマルチスレッド仮想マシン、オブジェクトモデル、トランザクション衝突分析などを通じてチェーン内スループットを向上させ、後者はプロセス／スマートエージェントを基本単位とし、メッセージ駆動と非同期実行方式で複数スマートエージェントの並列実行を実現します。比較すると、シャーディングとRollupは「負荷を複数チェーンに分割」または「チェーン外に外注」するようなものであり、並列チェーンとActorモデルは「実行エンジン自体から性能可能性を解放」するもので、より徹底したアーキテクチャ進化の方向を示しています。
並列計算 vs シャーディングアーキテクチャ vs Rollupスケーリング vs Actor指向拡張パスの比較
特に指摘すべきは、現在多くのネイティブ並列アーキテクチャチェーンはすでにメインネット上陸段階に入っているものの、全体的な開発者エコシステムは依然としてEVM系のSolidity体系と同等とは言い難いということです。しかし、SolanaやSuiを代表とするプロジェクトは、その高性能実行アーキテクチャとエコシステムアプリの徐々な繁栄により、市場の注目を集める核心パブリックチェーンとなっています。
一方、イーサリアムRollup（L2）エコシステムはすでに「万チェーン発展」どころか「供給過剰」の段階に達しているにもかかわらず、主流のEVM系並列強化チェーンは依然としてテストネット段階に留まっており、メインネット環境での実際の検証を受けておらず、そのスケーリング能力とシステム安定性はさらなる検証が必要です。これらのプロジェクトが互換性を犠牲にせずにEVM性能を著しく向上させ、エコシステムの飛躍を促進できるのか、あるいは逆にイーサリアムの流動性と開発リソースのさらなる分化を助長するのかは、今後の時間の中で明らかになるでしょう。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
