區塊鏈擴容軍備賽：EVM並行增強、原生並行架構與蘇花公路瓶頸突破

區塊鏈擴容的軍備競賽：EVM 並行增強與原生並行架構的深度剖析

區塊鏈「不可能三角」與擴容的永恆挑戰

區塊鏈技術自誕生以來，便面臨著一個 фундаментальний（根本的）挑戰，也就是所謂的「不可能三角」（Blockchain Trilemma）：安全性、去中心化、可擴展性。這個概念精準地捕捉了區塊鏈系統設計中的核心權衡——很難，甚至可以說幾乎不可能，同時達到「極致安全、人人可參與、高速處理」這三個目標。犧牲任何一個特性，都將直接影響區塊鏈的應用場景和發展潛力。

安全性是區塊鏈的基石，若缺乏穩固的安全機制，整個系統將不堪一擊。去中心化則賦予區塊鏈抗審查、無需許可的特性，讓權力不集中於單一實體手中。然而，隨著區塊鏈應用的普及，交易量的爆發式增長對其可擴展性提出了嚴峻考驗。試想一下，如果每次交易都要耗費大量的時間和能源，那區塊鏈的應用前景將大打折扣。

因此，「可擴展性」一直是區塊鏈領域的永恆話題。為了突破性能瓶頸，無數的開發者和研究者投入了大量的時間和精力，試圖找到完美的擴容方案。然而，就像蘇花公路的改善工程一樣，每一步都充滿了挑戰與妥協，難以一蹴而就。尤其是在以太坊上，每当Gas Fee 飙升，就會讓我想到 路怒症 发作的司机，焦躁不安，恨不得一脚油门踩到底。這也點出了擴容的迫切性，沒有效率，再美好的願景也難以實現。

鏈內並行計算：區塊鏈擴容的多元範式

為了應對「可擴展性」的挑戰，市場上湧現了各式各樣的區塊鏈擴容方案。如果將這些方案按照範式區分，大致可以歸納為以下幾種類型：

• 執行增強型擴容：顧名思義，這類方案旨在直接提升區塊鏈的執行能力，就像是給引擎加裝渦輪增壓器一樣。常見的手段包括並行計算、利用 GPU 加速、以及多核處理等技術。
• 狀態隔離型擴容：這類方案的核心思想是將區塊鏈的狀態進行水平拆分，如同將一個大型商場分割成多個獨立的店鋪。分片（Sharding）、UTXO 模型、以及多子網等技術都屬於此類。
• 鏈下外包型擴容：這類方案則選擇將執行放到鏈外進行，相當於將一部分工作外包給更專業的團隊。Rollup、Coprocessor、以及 DA (Data Availability) 等技術都屬於這種範式。
• 結構解耦型擴容：這類方案則著重於架構的模塊化和協同運行，就像是將一個複雜的機器拆解成多個獨立的模塊，然後再將它們組裝起來。模塊鏈、共享排序器、以及 Rollup Mesh 等技術都屬於此類。
• 異步並發型擴容：這類方案則借鑒了 Actor 模型，利用進程隔離和消息驅動的方式來實現並發處理。智能體（Agent）、多线程異步鏈等技術都屬於這種範式。

區塊鏈擴容方案涵蓋了執行、狀態、數據、結構等多個層級，是一個「多層協同、模塊組合」的完整體系。而本文的重點，將聚焦於以並行計算為主流的擴容方式，深入探討其背後的原理和實踐。

EVM 系並行增強鏈：在兼容中尋求性能突破

以太坊的串行處理架構，發展至今，雖然經歷了分片、Rollup、模塊化架構等多輪擴容嘗試，但執行層的吞吐瓶頸依然未能獲得根本性的突破。這就像 蘇花公路 永遠有瓶頸路段，怎麼改都還是會塞車一樣。但與此同時，EVM (Ethereum Virtual Machine) 與 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 都保持了單鏈完整性，僅在執行層橫向擴展，在單鏈內部極限並行執行優化突破性能。兩者代表區塊鏈擴展路徑中的縱向強化與橫向擴展兩種方向。

Pharos Network：Rollup Mesh 的異構並行

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 承載異構定制執行任務。

EVM 並行計算的 GPU 加速探索：Reddio 與 GatlingX

除了 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++ 的模塊化並行架構

Artela 則提出了一種差異化的並行設計理念。通過引入 EVM++ 架構 WebAssembly（WASM）虛擬機，允許開發者在保持 EVM 兼容性的同時，利用 Aspect 編程模型在鏈上動態添加和執行擴展程序。其以合約調用粒度（Function / Extension）為最小並行單元，支持在 EVM 合約運行時注入 Extension 模塊（類似「可插拔中間件」），實現邏輯解耦、異步調用與模塊級並行執行。更加關注執行層的可組合性與模塊化架構。其理念為未來複雜多模塊應用提供了新的思路。

原生並行架構鏈：重塑虛擬機的執行本體

以太坊的 EVM 執行模型自設計之初便採用了「交易全序 + 串行執行」的單線程架構，旨在確保網絡中所有節點對狀態變更的確定性與一致性。然而，這種架構在性能上存在天然瓶頸，限制了系統吞吐和擴展性。想象一下，所有交易都必須排隊等待處理，就像在 總統府 前等待接見一樣，效率自然不高。

相較之下，Solana（SVM）、MoveVM（Sui、Aptos）以及基於 Cosmos SDK 構建的 Sei v2 等原生並行計算架構鏈，從底層設計起就為並行執行量身打造，具備如下優勢：

• 狀態模型天然分離：Solana 採用賬戶鎖聲明機制、MoveVM 引入對象所有權模型、Sei v2 則以交易類型分類為基礎，實現靜態衝突判定，支持交易級別並發調度；
• 虛擬機針對並發優化：Solana 的 Sealevel 引擎原生支持多線程執行；MoveVM 能進行靜態並發圖分析；Sei v2 則集成多線程撮合引擎與並行 VM 模塊。

當然，這類原生並行鏈也面臨生態兼容性的挑戰。非 EVM 架構通常需要配套全新的開發語言（如 Move、Rust）與工具鏈，對開發者而言存在一定的遷移成本；此外，開發者還需掌握如狀態訪問模型、並發限制、對象生命週期等一系列新概念，對理解門檻和開發範式均提出更高要求。這就像學習一門全新的語言，需要投入大量的時間和精力，才能熟練掌握。

Solana 及 SVM 系的 Sealevel 並行引擎：賬戶並行調度的先驅

Solana 的 Sealevel 執行模型是一種賬戶並行調度機制，是 Solana 用於實現鏈內並行交易執行的核心引擎。它通過「賬戶聲明 + 靜態調度 + 多線程執行」機制，實現智能合約級別的高性能並發。Sealevel 是區塊鏈領域第一個在生產環境中成功實現鏈內並發調度的執行模型，其架構思想影響了後來的諸多並行計算項目，是高性能 Layer1 並行設計的參考範式。

核心機制：

1. 顯式賬戶訪問聲明（Account Access Lists）：每筆交易在提交時必須聲明其涉及的賬戶（讀 / 寫），系統據此判斷交易間是否存在狀態衝突。
2. 衝突檢測與多線程調度
   • 若兩筆交易訪問的賬戶集合無交集 → 可並行執行；
   • 存在衝突 → 按依賴順序串行執行；
   • 調度器基於依賴圖將交易分配給不同線程。
3. 獨立執行上下文（Program Invocation Context）：每個合約調用在隔離的上下文中運行，無共享堆疊，避免跨調用干擾。

Sealevel 是 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 + Sealevel。 Neon 更加傾向於模塊化區塊鏈（Modular Blockchain）範疇而並不強調並行計算創新。

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

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 並行計算在不同哲學下的技術落地路徑。

Cosmos SDK 並行擴展：Sei V2 的交易優化

Sei V2 是基於 Cosmos SDK 構建的高性能交易型公鏈，其並行能力主要體現在兩個方面：多線程撮合引擎（Parallel Matching Engine）與虛擬機層的並行執行優化，旨在服務高頻、低延遲的鏈上交易場景，如訂單簿 DEX、鏈上交易所基礎設施等。

核心並行機制：

1. 並行撮合引擎：Sei V2 在訂單撮合邏輯中引入多線程執行路徑，將掛單簿與撮合邏輯進行線程級拆分，使多個市場（trading pairs）之間的撮合任務可以並行處理，避免單線程瓶頸。
2. 虛擬機級並發優化：Sei V2 構建了一個具備並發執行能力的 CosmWasm 運行環境，允許部分合約調用在狀態無衝突的前提下並行運行，並配合交易類型分類機制實現更高的吞吐控制。
3. 並行共識配合執行層調度: 引入所謂 「Twin-Turbo」 共識機制，強化共識層與執行層之間的吞吐解耦，提升整體區塊處理效率。

UTXO 模型重構者：Fuel 的並行之路

Fuel 是一個基於以太坊模塊化架構設計的高性能執行層，其核心並行機制源於改進型 UTXO 模型（Unspent Transaction Output）。與以太坊的賬戶模型不同，Fuel 使用 UTXO 結構來表示資產和狀態，這種模型天然具備狀態隔離性，便於判斷哪些交易可安全並行執行。此外，Fuel 引入了自主開發的智能合約語言 Sway（類似 Rust），並結合靜態分析工具，在交易執行前即可確定輸入衝突，從而實現高效、安全的交易級並行調度。是兼顧性能與模塊化的 EVM 替代執行層。

Actor Model：智能體並發執行的新範式

Actor Model 是一種以智能體進程（Agent 或 Process）為單位的並行執行範式。它不同於傳統鏈上全局狀態的同步計算（如 Solana、Sui、Monad 等「鏈上並行計算」場景）。Actor Model 強調每個智能體擁有獨立狀態與行為，通過異步消息進行通信與調度。在這種架構下，鏈上系統可由大量彼此解耦的進程並發運行，具備極強的可擴展性與異步容錯能力。代表項目包括 AO（Arweave AO）、ICP（Internet Computer） 和 Cartesi，它們正推動區塊鏈從執行引擎向「鏈上操作系統」演化，為 AI Agent、多任務交互與複雜邏輯編排提供原生基礎設施。

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

AO (Arweave)：存儲層之上超級並行計算機

AO 是一個運行在 Arweave 永久存儲層上的去中心化計算平台，其核心目標是構建一個支持大規模異步智能體運行的鏈上操作系統。想象一下，如果區塊鏈可以像一個大型的雲計算平台一樣，讓無數的智能體在上面自由運行，協同完成各種任務，那將會是一個怎樣的景象。

核心架構特性：

• Process 架構：每個智能體被稱為一個 Process，擁有獨立狀態、獨立調度器與執行邏輯；
• 無區塊鏈結構：AO 並不是一條鏈，而是基於 Arweave 的去中心化存儲層 + 多智能體消息驅動執行引擎；
• 異步消息調度系統：Process 之間通過消息（Message）進行通信，採用無鎖異步運行模型，天然支持並發擴展；
• 狀態永久存儲：所有智能體狀態、消息記錄、指令都永久記錄在 Arweave 上，保證了完全審計性與去中心化透明性；
• Agent-native：適合部署複雜多步任務（如 AI 代理、DePIN 協議控制器、自動任務編排器等），可構建「鏈上 AI Coprocessor」。

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

ICP (Internet Computer)：全棧 Web3 託管平台

ICP 是由 DFINITY 推出的 Web3 原生全棧鏈上應用平台，目標是將鏈上計算能力擴展到類 Web2 的體驗，並支持完整的服務託管、域名綁定與無服務器架構。 ICP 的目标是打造一个像 帛琉 一樣美麗且功能完善的Web3世界，讓所有的應用都能在鏈上無縫運行。

核心架構特性：

• Canister 架構（容器即智能體）：每個 Canister 是運行在 Wasm VM 上的智能體，擁有獨立狀態、代碼與異步調度能力；
• 子網分布式共識系統（Subnet）：整個網絡由多個 Subnet 組成，每個子網維護一組 Canister，通過 BLS 簽名機制達成共識；
• 異步調用模型：Canister 與 Canister 間通過異步消息通信，支持非阻塞式執行，具備天然並行性；
• 鏈上 Web 託管：支持智能合約直接託管前端頁面，原生 DNS 映射，是首個支持瀏覽器直接訪問 dApp 的區塊鏈平台；
• 系統功能齊全：具備鏈上熱升級、認證身份、分布式隨機性、計時器等系統 API，適合複雜鏈上服務部署。

ICP 選擇重平台、一體封裝、強平台控制的操作系統範式，具備共識、執行、存儲、接入一體化的「區塊鏈操作系統」，強調 完整服務託管能力，系統邊界擴展為全棧 Web3 託管平台。

多維度比較：並行、分片、Rollup 與 Actor 模型的擴容之路

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

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

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