作者: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 平行電腦程式解析:
- 全生命週期非同步管線處理(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 的平行執行架構外,我們也觀察到市場存在一些探索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 是系統容錯派,更像「資料庫並發引擎」,適合狀態耦合強、調用鏈複雜的合約體系;要像程式語言工程師,像軟體一樣安全運行鏈(Software-grade resource security)三者代表了Web3 並行計算在不同哲學下的技術落地路徑。
3.3 Cosmos SDK 平行擴充型
Sei V2 是基於Cosmos SDK 構建的高效能交易型公鏈,其平行能力主要體現在兩個方面:多執行緒撮合引擎(Parallel Matching Engine)與虛擬機層的並行執行優化,旨在服務高頻、低延遲的鏈上交易場景,如訂單簿DEX、鏈上交易所基礎設施等。
核心並行機制:
- 並行撮合引擎: Sei V2 在訂單撮合邏輯中引入多線程執行路徑,將掛單簿與撮合邏輯進行線程級拆分,使多個市場(trading pairs)之間的撮合任務可以並行處理,避免單線程瓶頸。
- 虛擬機級並發優化: 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,它們正推動區塊鏈從執行引擎向「鏈上作業系統」演化,為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 效能,推動生態躍遷,抑或反而加劇對以太坊流動性與開發資源的進一步分化,仍有待時間檢驗。