擴容的未來：Web3 並行計算賽道全景圖譜

撰文：0xjacobzhao 及 ChatGPT 4o

區塊鏈的「不可能三角」（Blockchain Trilemma）「安全性」、「去中心化」、「可擴充性」揭示了區塊鏈系統設計中的本質權衡，即區塊鏈專案很難同時實現「極致安全、人人可參與、高速處理」。 針對「可擴充性」這一永恆話題，目前市場上的主流區塊鏈擴容方案按照範式區分，包括：

• 執行增強型擴容：原地提升執行能力，例如並行、GPU、多核

• 狀態隔離型擴容：水準拆分狀態 / Shard，例如分片、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） 。 此外在共識和存儲層，Monad 分別引入了高性能 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 單線程狀態機模型，以帳戶為單位實現微虛擬機封裝，通過狀態依賴圖進行交易調度，並用異步消息機制替代同步調用棧。 它是一種從「賬戶結構 → 調度架構 → 執行流程」全維度重新設計的並行計算平臺，為構建下一代高性能鏈上系統提供了範式級的新思路。

MegaETH 選擇了重構路徑：徹底把帳戶和合約抽象成獨立 VM，通過異步執行調度來釋放極致的並行潛力。 理論上，MegaETH 的並行上限更高，但也更難控制複雜度，更像是乙太坊理念下的超級分散式操作系統。

Monad 和 MegaETH 二者的設計理念都和分片（Sharding）有著較大不同：分片把區塊鏈橫向切分成多個獨立子鏈（分片 Shards），每個子鏈負責部分交易和狀態，打破單鏈限制在網路層擴展; 而 Monad 和 MegaETH 都保持了單鏈完整性，僅在執行層橫向擴展，在單鏈內部極限並行執行優化突破性能。 兩者代表區塊鏈擴展路徑中的縱向強化與橫向擴展兩種方向。

Monad 和 MegaETH 等並行計算專案主要集中在吞吐優化路徑，以提升鏈內 TPS 為核心目標，通過延遲執行（Deferred Execution）和微虛擬機（Micro-VM）架構實現交易級或帳戶級的並行處理。 而 Pharos Network 作為是一個模組化、全棧並行的 L1 區塊鏈網路，其核心並行電腦制被稱為「Rollup Mesh」。 這一架構通過主網與特殊處理網路（SPNs）的協同工作，支援多虛擬機環境（EVM 和 Wasm），並集成了零知識證明（ZK）、可信執行環境（TEE）等先進技術。

Rollup Mesh 並行計算機制解析：

1. 全生命週期異步流水線處理（Full Lifecycle Asynchronous Pipelining）： Pharos 將交易的各個階段（如共識、執行、存儲）解耦，並採用異步處理方式，使得每個階段可以獨立並行地進行，從而提高整體處理效率。

2. 雙虛擬機並行執行（Dual VM Parallel Execution）： Pharos 支援 EVM 和 WASM 兩種虛擬機環境，允許開發者根據需求選擇合適的執行環境。 這種雙 VM 架構不僅提高了系統的靈活性，還通過並行執行提升了交易處理能力。

3. 特殊處理網路（SPNs）： SPNs 是 Pharos 架構中的關鍵元件，類似於模組化的子網路，專門用於處理特定類型的任務或應用。 通過SPNs，Pharos可以實現資源的動態分配和任務的並行處理，進一步增強了系統的可擴展性和性能。

4. 模組化共識和重質押機制（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 的並行執行架構外，我們也觀察到市場存在一些探索 GPU 加速在 EVM 並行計算中的應用路徑 的專案，作為對 EVM 並行生態的重要補充與前沿實驗。 其中，Reddio 和 GatlingX 是兩個具有代表性的方向：

• Reddio 是一個結合 zkRollup 與 GPU 並行執行架構的高性能平臺，其核心在於重構 EVM 執行流程，通過多線程調度、異步狀態存儲以及 GPU 加速執行交易批次，實現執行層的原生並行化。 屬於交易級 + 操作級（多線程執行 opcode）的並行顆粒度。 其設計引入多線程批處理執行、異步狀態載入與 GPU 並行處理交易邏輯（CUDA-Compatible Parallel 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 執行模型是一種帳戶並行調度機制，是 Solana 用於實現鏈內並行交易執行的核心引擎，通過「帳戶聲明 + 靜態調度 + 多線程執行」機制，實現智慧合約級別的高性能併發。 Sealevel 是區塊鏈領域第一個在生產環境中成功實現鏈內併發調度的執行模型，其架構思想影響了後來的諸多並行計算專案，是高性能 Layer1 並行設計的參考範式。

核心機制：

1、顯式帳戶訪問聲明（Account Access Lists）： 每筆交易在提交時必須聲明其涉及的帳戶（讀 / 寫），系統據此判斷交易間是否存在狀態衝突。

2、衝突檢測與多線程調度

• 若兩筆交易訪問的帳戶集合無交集 → 可並行執行;

• 存在衝突 → 按依賴順序串行執行;

• 調度器基於依賴圖將交易分配給不同線程。

3、獨立執行上下文（Program Invocation Context）： 每個合約調用在隔離的上下文中運行，無共用堆疊，避免跨調用干擾。

SealevelSealevel 是 Solana 的並行執行調度引擎，而 SVM 是構建在 Sealevel 之上的智慧合約執行環境（使用 BPF 虛擬機）。 兩者共同構成了 Solana 高性能並行執行體系的技術基礎。

Eclipse 是一個將 Solana VM 部署到模組化鏈（如 Ethereum L2 或 Celestia）上的專案，利用 Solana 的並行執行引擎作為 Rollup 執行層。 Eclipse 是最早提出將 Solana 執行層（Sealevel + SVM）脫離 Solana 主網，遷移到模組化架構中的專案之一，將 Solana 的「超強併發執行模型」模組化輸出為 Execution Layer-as-a-Service，因此 Eclipse 也屬於並行計算大類。

Neon 的路線不同，它將 EVM 引入 SVM / Sealevel 環境中運行。 構建一個相容 EVM 的運行層，開發者可使用 Solidity 開發合約並運行在 SVM 環境下，但調度執行使用的是 SVM + Sealeve。 Neon 更加傾向於模組化區塊鏈（Modular Blockchain）範疇而並不強調並行計算創新。

總而言之，Solana 及 SVM 依賴 Sealevel 執行引擎，Solana 操作系統式調度哲學類似內核調度器，執行快速，但靈活性相對較低。 是原生高性能、並行計算型公鏈。

3.2 MoveVM 架構：資源與物件驅動

MoveVM 是為鏈上資源安全與並行執行而設計的智慧合約虛擬機，其核心語言Move最初由Meta（前 Facebook）為 Libra 專案開發，強調「資源即物件」的理念，所有鏈上狀態都以物件存在，擁有明確的擁有權與生命週期。 這使得MoveVM能在編譯期分析交易間是否存在狀態衝突，實現物件級靜態並行調度，廣泛應用於Sui和Aptos等原生並行公鏈。

Sui 的物件擁有權模型

Sui 的並行計算能力源於其獨特的的狀態建模方式與語言級別的靜態分析機制。 與傳統區塊鏈採用全域狀態樹不同，Sui 構建了一套基於「物件」的狀態模型（Object-centric model），配合 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 將一個區塊的交易執行劃分為三個階段：

• 樂觀併發執行（Speculative Execution）：所有交易在執行前預設無衝突，系統將交易並行調度至多個線程併發嘗試執行，並記錄下其訪問的賬戶狀態（讀集 / 寫集）。

• 衝突檢測與驗證（Validation Phase）：系統對執行結果進行驗證：若兩筆交易存在讀寫衝突（如 Tx1 讀了被 Tx2 寫的狀態），則回退其中之一。

• 衝突交易回滾重試（Retry Phase）： 衝突交易將被重新安排執行，直到其依賴關係被解決，最終所有交易形成一個有效、確定的狀態提交序列。

Block-STM 是一種「樂觀並行 + 回滾重試」的動態執行模型，適合狀態密集型、邏輯複雜的鏈上交易批處理場景，是 Aptos 構建高通用性、高吞吐公鏈的並行計算核心。

Solana 是工程調度派，更像「操作系統內核」，適合明確狀態邊界、可控型高頻交易，是硬體工程師風格，要像硬體一樣運行鏈（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、鏈上交易所基礎設施等。

核心並行機制：

1. 並行撮合引擎： Sei V2 在訂單撮合邏輯中引入多線程執行路徑，將掛單簿與撮合邏輯進行線程級拆分，使多個市場（trading pairs）之間的撮合任務可以並行處理，避免單線程瓶頸。

2. 虛擬機級併發優化： Sei V2 構建了一個具備併發執行能力的 CosmWasm 運行環境，允許部分合約調用在狀態無衝突的前提下並行運行，並配合交易類型分類機制實現更高的吞吐控制。

3. 並行共識配合執行層調度： 引入所謂 「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，它們正推動區塊鏈從執行引擎向「鏈上操作系統」演化，為 AI Agent、多任務交互與複雜邏輯編排提供原生基礎設施。

雖然 Actor Model 的設計在表層特徵上（如並行性、狀態隔離、異步處理）與 分片（Sharding） 有一定相似之處，但本質上二者代表的是完全不同的技術路徑和系統哲學。 Actor Model 強調「多進程異步計算」，每個智慧體（Actor）獨立運行、獨立維護狀態，通過消息驅動的方式進行交互; 而分片則是一種「狀態與共識的水準切分」機制，將整個區塊鏈劃分為多個獨立處理交易的子系統（Shard）。 Actor Model 更像是 Web3 世界中的「分散式智慧體操作系統」，而分片則是對鏈內事務處理能力的結構性擴容方案。 兩者都實現了並行性，但出發點、目標與執行架構不同。

4.1 AO （Arweave），存儲層之上超級並行電腦

AO 是一個運行在Arweave永久存儲層上的去中心化計算平臺，其核心目標是構建一個支持大規模異步智慧體運行的鏈上操作系統。

核心架構特性：

• Process 架構：每個智慧體被稱為一個 Process，擁有獨立狀態、獨立調度器與執行邏輯;

• 無區塊鏈結構：AO 並不是一條鏈，而是基於Arweave的去中心化存儲層 + 多智慧體消息驅動執行引擎;

• 異步消息調度系統：Process之間通過消息（Message）進行通信，採用無鎖異步運行模型，天然支援併發擴展;

• 狀態永久存儲：所有智慧體狀態、消息記錄、指令都永久記錄在Arweave上，保證了完全審計性與去中心化透明性;

• Agent-native：適合部署複雜多步任務（如 AI 代理、DePIN 協定控制器、自動任務編排器等），可構建「鏈上 AI Coprocessor」。

AO 走的是極致「智慧體原生 + 存儲驅動 + 無鏈架構」路線，強調靈活性與模組解耦，是「架設在存儲層之上的鏈上微內核框架」，系統邊界刻意收縮，強調 輕量計算 + 可組合控制結構。

4.2 ICP （Internet Computer），全棧 Web3 託管平臺

ICP 是由 DFINITY 推出的 Web3 原生全棧鏈上應用平臺，目標是將鏈上計算能力擴展到類 Web2 的體驗，並支援完整的服務託管、功能變數名稱綁定與無伺服器架構。

核心架構特性：

• Canister 架構（容器即智慧體）：每個 Canister 是運行在 Wasm VM 上的智慧體，擁有獨立狀態、代碼與異步調度能力;

• 子網分散式共識系統（Subnet）：整個網路由多個 Subnet 組成，每個子網維護一組 Canister，通過 BLS 簽名機制達成共識;

• 異步調用模型：Canister 與 Canister 間通過異步消息通信，支援非阻塞式執行，具備天然並行性;

• 鏈上 Web 託管：支援智慧合約直接託管前端頁面，原生 DNS 映射，是首個支持瀏覽器直接訪問 dApp 的區塊鏈平臺;

• 系統功能齊全：具備鏈上熱升級、認證身份、分散式隨機性、計時器等系統 API，適合複雜鏈上服務部署。

ICP 選擇重平臺、一體封裝、強平臺控制的操作系統範式，具備共識、執行、存儲、接入一體化的「區塊鏈操作系統」，強調 完整服務託管能力，系統邊界擴展為全棧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 作業系統作為鏈下計算環境，提供可信計算結果的鏈上驗證路徑，適合複雜或資源密集型應用場景。

基於上述邏輯，我們可以將當前主流的並行計算公鏈方案，歸納為如下圖表所示的分類結構：

從更加廣義的擴容視角來看，分片（Sharding）和 Rollup（L2）側重通過狀態切分或鏈下執行實現系統水平擴展不同，而並行計算鏈（如 Monad、Sui、Solana）和 Actor Oriented 系統（如 AO、ICP）則直接重構執行模型，在鏈內或系統層實現原生並行。 前者通過多線程虛擬機、物件模型、交易衝突分析等方式提升鏈內吞吐; 後者則以進程 / 智慧體為基本單元，採用消息驅動與異步執行方式，實現多智慧體併發運行。 相比之下，分片和 Rollup 更像「將負載拆給多條鏈」或「外包給鏈下」，而並行鏈與 Actor 模型則是「從執行引擎本身釋放性能潛力」，體現出更徹底的架構演進方向。

並行計算 vs 分片架構 vs Rollup 擴容 vs Actor Oriented 擴展路徑比較

需要特別指出的是，目前多數原生並行架構鏈已進入主網上線階段，儘管整體開發者生態尚難與 EVM 系的 Solidity 體系相提並論，但以 Solana 與 Sui 為代表的專案，憑藉其高性能執行架構，以及生態應用的逐步繁榮，已成為市場高度關注的核心公鏈。

相比之下，儘管乙太坊 Rollup（L2）生態已進入「萬鏈齊發」甚至「產能過剩」的階段，當前主流的 EVM 系並行增強鏈仍普遍停留在測試網階段，尚未經過主網環境的實際驗證，其擴容能力與系統穩定性仍需進一步檢驗。 至於這些專案能否在不犧牲相容性的前提下顯著提升 EVM 性能，推動生態躍遷，抑或反而加劇對乙太坊流動性與開發資源的進一步分化，仍有待時間檢驗。