# 扩容的未来：Web3 并行计算赛道全景图谱 By [0xjacobzhao](https://paragraph.com/@0xjacobzhao) · 2025-05-19 并行计算, monad, megaeth, solana, sui, aptos, ao, icp, pharos --- 作者：0xjacobzhao 及 ChatGPT 4o 区块链的“不可能三角”（Blockchain Trilemma）“**安全性”、“去中心化”、“可扩展性**”揭示了区块链系统设计中的本质权衡，即区块链项目很难同时实现“极致安全、人人可参与、高速处理”。针对“可扩展性”这一永恒话题，目前市场上的主流区块链扩容方案按照范式区分，包括： * **执行增强型扩容**：原地提升执行能力，例如并行、GPU、多核 * **状态隔离型扩容**：水平拆分状态 / Shard，例如分片、UTXO、多子网 * **链下外包型扩容**：把执行放到链外，例如Rollup、Coprocessor、DA * **结构解耦型扩容**：架构模块化、协同运行，例如模块链、共享排序器、Rollup Mesh * **异步并发型扩容**：Actor 模型，进程隔离、消息驱动，例如智能体、多线程异步链 **扩容层级（目标）** **扩容路径（技术方式）** **本质范式** **代表项目 / 技术关键词** 🧠 执行层 链处理太慢，提高交易/合约执行能力（TPS） **链内并行计算** 原地执行增强（多核/并行） Solana（Sealevel）、Monad（延迟写+冲突检测）、Sui（对象并行）、MegaETH、Aptos（Block-STM） **Rollup（L2执行）** 链下执行 → 链上提交 zkSync、StarkNet、Arbitrum、Scroll **Actor模型** 异步消息驱动并发执行 AO（Process）、Cartesi、ICP（Canister） **模块化执行架构** 插件式 VM + 组合执行 Artela（Extension）、Eclipse（可插VM） 🧾 状态层 状态太大、同步慢，扩展状态容量、账户数、读写速率 **分片（Sharding）** 状态空间切割并发处理 Ethereum 2.0、Near **Stateless架构** 节点不持状态，仅做验证 Stateless Ethereum（规划中） **Volition / 状态压缩** 状态链上链下自由切换 zkPorter、Aztec、Celestia Volition 📦 数据可用性层（DA） L1写入成本高，扩展交易数据广播与存储能力 **模块化DA层** 独立的数据广播与存储网络 Celestia、EigenDA、Avail **Blobspace扩容** 为Rollup提供低成本DA通道 Ethereum EIP-4844（Proto-Danksharding） ⚖ 结算与验证层 **递归 zk 证明 / Coprocessor** 多证明压缩 + 计算外包验证 zkSync Hyperchains、Succinct、RiscZero、Axiom 🧩 架构结构层 单链设计僵化、不灵活，构建组合式区块链、异构链协同 **模块化区块链结构** 解耦执行/共识/DA/结算层 Dymension、Eclipse、Rollkit **Rollup聚合与调度层** 多Rollup统一排序与状态聚合 Espresso、Astria、AltLayer 区块链扩容方案包括：**链内并行计算、Rollup、分片、DA模块、模块化结构、Actor系统、zk证明压缩、Stateless架构**等，涵盖执行、状态、数据、结构多个层级，是一个“多层协同、模块组合”的完整扩容体系。而本文重点介绍以并行计算为主流的扩容方式。 链内并行计算(intra-chain parallelism)，关注区块内部交易/指令的并行执行。按并行机制划分，其扩容方式可以分为五大类，每类代表了不同的性能追求、开发模型和架构哲学，依次并行颗粒度越来越细，并行强度越来越高，调度复杂度也越来越高，编程复杂性和实现难度也越来越高。 1. **账户级并行（Account-level）**： 代表项目Solana 2. **对象级并行（Object-level）**：代表项目Sui 3. **交易级并行（Transaction-level）**: 代表项目Monad, Aptos 4. **调用级 / 微VM并行（Call-level / MicroVM）**: 代表项目MegaETH 5. **指令级并行（Instruction-level）**: 代表项目GatlingX 链外异步并发模型，以 Actor智能体系统（Agent / Actor Model）为代表，它们属于另一种并行计算范式，作为跨链/异步消息系统（非区块同步模型），每个 Agent 作为独立运行的“智能体进程”，并行方式异步消息、事件驱动、无需同步调度，代表项目有AO, ICP, Cartesi等。 而我们耳熟能详的Rollup或分片扩容方案，属于系统级并发机制，并不属于链内并行计算。它们通过“并行运行多个链/执行域”来实现扩容，而不是提升单个区块/虚拟机内部的并行度。此类扩容方案并不是本文讨论的重点但我们依然会将其用于架构理念的异同比较。 **并行类型** **并行粒度** **是否链内** **并行机制** **技术特征** **代表项目** **1\. 账户级并行** 账户（Account） ✅ 是 根据交易读写账户 → 并发执行无冲突交易 动态账户锁、交易调度器 **Solana**, Sei **2\. 对象级并行** 对象（Object） ✅ 是 资源所有权静态分析 → 并行执行独立对象 面向对象资源模型（Move） **Sui** **3\. 交易级并行** 交易（TX） ✅ 是 批量收集交易 → 冲突检测 → 并行执行 Deferred writes、事务快照 **Monad**, Aptos (Block-STM), Fuel **4\. 调用级 / 微VM并行** 合约调用 / VM实例 ✅ 是 合约调用异步拆解，运行于独立 VM / 模块 微服务式执行 / 插件逻辑 **MegaETH** **5\. 指令级并行** EVM字节码指令 ✅ 是 将字节码拆分 → GPU线程并行执行 GPU 原生调度 / CUDA / zk加速 **GatlingX** **6\. 智能体级并行**(Actor Model) Actor / Process / Canister ❌ 否(异步系统) 每个智能体拥有状态 → 通过消息驱动执行 异步、多进程、消息通信、可组合 **AO**, **Cartesi**, **ICP**, Linera **二、EVM 系并行增强链：在兼容中突破性能边界** --------------------------- 以太坊的串行处理架构发展至今，经历分片、Rollup、模块化架构等多轮扩容尝试，但执行层的吞吐瓶颈依然未获根本性突破。但与此同时，EVM 与 Solidity 依旧是当前最具开发者基础与生态势能的智能合约平台。因此，**EVM 系并行增强链**作为兼顾生态兼容性与执行性能提升的关键路径，正在成为新一轮扩容演进的重要方向。**Monad 与 MegaETH** 则是这一方向上最具代表性的项目，分别从延迟执行与状态分解出发，构建面向高并发、高吞吐场景的 EVM 并行处理架构。 ### **Monad 的并行计算机制解析** **Monad** 是一个为以太坊虚拟机（EVM）重新设计的高性能 Layer1 区块链，基于**流水线处理（Pipelining）**这一基本并行理念，在共识层**异步执行（Asynchronous Execution）**、在执行层**乐观并发（Optimistic Parallel Execution）** 。此外在共识和存储层，Monad 分别引入了高性能 BFT 协议（**MonadBFT**）与专用数据库系统（**MonadDB**），实现端到端优化。 1. **Pipelining：多阶段流水线并行执行机制** Pipelining 是 Monad 并行执行的基本理念，其核心思想是将区块链的执行流程拆分为多个**独立的阶段**，并将这些阶段**并行化处理**，形成立体的流水线架构，各阶段运行在独立线程或核上，实现跨区块的并发处理，最终达到**提升吞吐量和降低延迟的效果**。这些阶段包括：交易提议（Propose）共识达成（Consensus）交易执行（Execution）和区块提交（Commit）。 2. **Asynchronous Execution：共识-执行异步解耦** 在传统链上，交易共识和执行通常是同步流程，这种串行模型严重限制了性能扩展。Monad 通过“异步执行”实现了共识层异步、执行层异步和存储异步。显著降低区块时间（block time）和确认延迟，使系统更具弹性、处理流程更细分、资源利用率更高。 ### **核心设计：** 1. 共识过程（共识层）只负责排序交易，不执行合约逻辑。 2. 执行过程（执行层）在共识完成后异步触发。 3. 共识完成后立即进入下一区块共识流程，无需等待执行完成。 3. **Optimistic Parallel Execution：乐观并行执行** 传统以太坊对交易执行采用严格串行模型，以避免状态冲突。而 Monad 则采用“乐观并行执行”策略，大幅提升交易处理速率。 ### **执行机制：** 1. Monad 会**乐观地并行执行所有交易**，假设大部分交易之间**无状态冲突**。 2. 同时运行一个“冲突检测器（Conflict Detector)”来监控交易之间是否访问了相同的状态（如读/写冲突）。 3. 如果检测到冲突，则会将冲突交易串行化重执行，确保状态正确性。 **Monad** 选择了**兼容路径**：尽可能少动EVM规则，在执行过程中通过**推迟写状态**、**动态检测冲突**来实现并行，更像是**性能版以太坊**，成熟度好容易实现EVM生态迁移，是EVM世界的并行加速器。 ### **MegaETH的并行计算机制解析** 区别于Monad的L1定位，MegaETH 定位为EVM兼容的模块化高性能并行执行层，既可以作为**独立L1公链**，也可以作为**以太坊上的执行增强层（Execution Layer）或模块化组件**。其核心设计目标是将账户逻辑、执行环境与状态隔离解构为可独立调度的最小单元，以实现链内高并发执行和低延迟响应能力。MegaETH 提出的关键创新在于：**Micro-VM 架构** + **State Dependency DAG（有向无环状态依赖图）**及**模块化同步机制**，共同构建出面向“链内线程化”的并行执行体系。 1. **Micro-VM（微虚拟机）架构：账户即线程** MegaETH 引入了“每个账户一个微型虚拟机（Micro-VM）”的执行模型，将执行环境“线程化”，为并行调度提供最小隔离单元。这些VM之间通过异步消息通信（Asynchronous Messaging），而不是同步调用，大量VM可以独立执行、独立存储，天然并行。 2. **State Dependency DAG：依赖图驱动的调度机制** MegaETH 构建了一套基于账户状态访问关系的 DAG 调度系统，系统实时维护一个全局依赖图（Dependency Graph），每次交易修改哪些账户，读取哪些账户，全部建模成依赖关系。无冲突的交易可以直接并行执行，有依赖关系的交易将按拓扑序串行或延后进行调度排序。依赖图确保并行执行过程中的状态一致性与非重复写入。 3. **异步执行与回调机制** MegaETH 构建在异步编程范式之上，类似 Actor Model 的异步消息传递，解决传统 EVM 串行调用问题。合约调用是异步的（非递归执行），调用合约A -> B -> C时，每次调用都被异步化，无需阻塞等待；调用栈被展开为**异步调用图（Call Graph）**；交易处理=遍历异步图 + 依赖分辨 + 并行调度。 总而言之，MegaETH 打破传统 EVM 单线程状态机模型，以账户为单位实现**微虚拟机封装**，通过**状态依赖图**进行交易调度，并用**异步消息机制**替代同步调用栈。它是一种从“**账户结构 → 调度架构 → 执行流程**”全维度重新设计的并行计算平台，为构建下一代高性能链上系统提供了范式级的新思路。 **MegaETH** 选择了**重构路径**：彻底把账户和合约抽象成独立VM，通过**异步执行调度**来释放极致的并行潜力。理论上，MegaETH的并行上限更高，但也更难控制复杂度，更像是**以太坊理念下的超级分布式操作系统**。 **项目** **Monad** **MegaETH** **基本定位** 高性能、并行执行的**以太坊兼容L1公链**，主要提升TPS，兼容现有应用 极致并行化的**新型执行环境**，重新定义EVM执行逻辑，适配未来大规模链上应用 **并行策略** **Deferred Execution**：先执行、后统一处理状态冲突（Deferred Writes + Conflict Resolution） **Micro-VMs**：每个账户/合约是独立小型虚拟机（VM），天然异步并行，依赖异步调用图执行 **状态管理** 单一全局状态，Snapshot+冲突检测 分布式微状态，动态生成全局状态依赖图（State Dependency DAG） **EVM兼容性** 极高（Solidity开发者无感迁移） 基本兼容，但异步执行语义下复杂合约可能需要适配 **合约组合性（Composability）** 完美保留传统以太坊风格组合性 高度保留，但跨VM异步组合引入新的开发复杂度 **TPS目标** 10,000+ TPS（优化单链处理能力） 50,000+ TPS以上（理论上不限，受限于硬件和依赖图复杂度） **开发者体验** 几乎无学习曲线（兼容现有EVM开发范式） 有一定学习曲线（理解异步调用模式更好发挥性能） **架构哲学** **增强单链吞吐**，最小破坏式演进（Minimal Disruption） **重构执行层逻辑**，最大化并行潜力（Maximum Parallelism） **技术风险点** Deferred冲突处理复杂度上升 冲突率控制，合理分组交易，硬件并行优化 异步执行下开发和调试复杂度显著增加 全局依赖图优化，动态异步重排执行顺序 **成熟度（短期落地性）** 兼容性好，EVM生态直接搬 中等，需重新设计复杂合约 **潜力（长期扩展性）** 中等，硬件约束存在 理论上无限扩展，只受限于硬件 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 将一个区块的交易执行划分为三个阶段： 1. **乐观并发执行（Speculative Execution） **所有交易在执行前默认无冲突，系统将交易并行调度至多个线程并发尝试执行，并记录下其访问的账户状态（读集 / 写集）。 2. **冲突检测与验证（Validation Phase） **系统对执行结果进行验证：若两笔交易存在读写冲突（如 Tx1 读了被 Tx2 写的状态），则回退其中之一。 3. **冲突交易回滚重试（Retry Phase） **冲突交易将被重新安排执行，直到其依赖关系被解决，最终所有交易形成一个有效、确定的状态提交序列。 Block-STM 是一种“乐观并行 + 回滚重试”的动态执行模型，适合状态密集型、逻辑复杂的链上交易批处理场景，是 Aptos 构建高通用性、高吞吐公链的并行计算核心。 **维度** **Solana** **Sui** **Aptos** **并行架构核心** Sealevel：账户锁 + 静态冲突检测 MoveVM + 对象模型 + 静态所有权分析 MoveVM + Block-STM 并发事务调度 **执行单位** 交易（按账户读写） 对象（Object） 交易（动态依赖） **调度方式** 显式声明账户 → 调度器静态调度 编译期静态分析对象访问关系 → 并行 运行时尝试并行 → 冲突回滚重试 **冲突检测机制** 显式账户锁避免冲突（交易被拒或重排） 无冲突可静态识别（对象不共享） 冲突动态记录 → 回滚失败交易 **虚拟机模型** BPF VM（非 EVM，使用 Rust） MoveVM（以对象和资源为基础） MoveVM + 并发执行器（Block-STM） **并行粒度** 账户级 对象级 交易级（基于执行时依赖） **开发模式** Rust + Anchor 框架 Move（资源导向语言） Move（偏通用合约开发） **目标优化点** 高频交易、小额并发任务（金融/链游） 可组合资产、链上状态碎片化 状态密集型、交易冲突频繁场景 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范式的并行计算项目可参考下表： **项目** **类型** **是否原生 Actor Model** **技术机制** **应用定位** **AO (Arweave AO)** 去中心化多智能体执行网络 ✅ 原生 Process = Actor，异步消息通信，状态上链 AI Agent、链上OS、Agent Runtime **Cartesi** 可验证链下计算平台 ✅ 结构上相似 每个 DApp 节点是独立计算单元，通过异步任务调度 游戏逻辑、AI推理、链下重计算 **ICP (Internet Computer)** 全栈 Layer1 公链 ✅ 类Actor Model Canister = 有状态Actor，支持异步调用 + 调度器 Web3服务、复杂DApp、AI系统 **Linera** 并发链上账户系统 ✅ 简化版 Actor Model 每个用户 = 一条线性链（进程），异步跨用户调用 轻量级高并发交易，Web2→Web3桥梁 **RedStone Warp Contracts** Arweave上的合约系统 ⚠ 类似设计 每个合约 = 状态机实例，支持消息触发、离线执行 去中心计算合约平台 **五、总结与展望** ----------- 基于虚拟机架构与语言系统的差异，区块链并行计算方案大致可分为两类：**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 操作系统作为链下计算环境，提供可信计算结果的链上验证路径，适合复杂或资源密集型应用场景。 基于上述逻辑，我们可以将当前主流的并行计算公链方案，归纳为如下图表所示的分类结构： ![](https://storage.googleapis.com/papyrus_images/c9bbdf044d43d851208936c0d5a8ac0c.png) 从更加广义的扩容视角来看，**分片（Sharding）**和**Rollup（L2）**侧重通过状态切分或链下执行实现系统水平扩展不同，而**并行计算链（如 Monad、Sui、Solana）**和**Actor Oriented 系统（如 AO、ICP）**则直接重构执行模型，在链内或系统层实现原生并行。前者通过**多线程虚拟机、对象模型、交易冲突分析**等方式提升链内吞吐；后者则以进程/智能体为基本单元，**采用消息驱动与异步执行方式，实现多智能体并发运行**。相比之下，分片和 Rollup 更像“**将负载拆给多条链**”或“**外包给链下**”，而并行链与 Actor 模型则是“**从执行引擎本身释放性能潜力**”，体现出更彻底的架构演进方向。 ###  **并行计算 vs 分片架构 vs Rollup 扩容 vs Actor Oriented 扩展路径比较** **维度** **并行计算链(Parallel Execution)** **分片架构(Sharding)** **Rollup 扩容** **(Layer 2)** **Actor Oriented 系统(智能体并行)** **核心追求** 提升链内吞吐量 状态空间水平扩展 链下执行 + 链上验证 异步智能体并发模型 **架构哲学** 重构或优化执行层（Execution Layer） 拆分为多个子链 / Shard，每个独立运行 将执行层搬到 L2，仅在主链做数据提交和状态确认 基于进程 / Agent，每个进程拥有状态与行为 **代表项目** Solana, Monad, Sui, MegaETH Ethereum 2.0, Near Arbitrum, zkSync, Scroll, Starknet AO, Cartesi, Linera（部分） **并行性来源** 同一区块中多个交易/指令并发执行 每个分片独立执行自己的交易集 并行依赖多个 Rollup 实例独立运行 独立 Process 异步运行 + 消息通信 **状态一致性** 强同步或最终一致（如 STM, DAG） 分片内同步，跨分片需协议 基于证明（zk）或欺诈（OP） 最终一致性（Eventual Consistency） **应用适配性** DeFi、链游、AI 合约 海量账户系统、支付、合规场景 高频 DApp、L3 构建、低 gas 游戏 多智能体系统、AI Agent、异步服务型应用 **扩展路径** 垂直扩展（提升单链吞吐） 水平扩展（多链并行） 外包执行、中心化验证 应用级系统内并行扩展 **状态模型** 一致的全局状态或事务快照 每个 Shard 管理自己状态 每个 Rollup 单独处理状态提交 每个 Actor 拥有本地状态，弱耦合 **执行方式** 多线程 / 批处理同步执行 多链独立执行，统一协调提交 链下执行 → 生成证明上链 消息驱动、事件触发异步执行 **并行机制** VM 层并行、CPU / GPU 并发 子链并行 多 Rollup 并发运行 智能体独立运行并发调度 **交易建模** 函数调用 / 合约执行 Shard 本地 TX / 跨分片 TX Rollup 批处理 → 主链提交 消息传递、异步交互 **一致性哲学** 强同步 / 可预测回滚 分片内强同步，跨 Shard 最终一致 提交即结算（zk）或挑战期后结算（OP） 最终一致性 + 无中心调度 需要特别指出的是，目前多数**原生并行架构链**已进入主网上线阶段，尽管整体开发者生态尚难与 EVM 系的 Solidity 体系相提并论，但以 **Solana** 与 **Sui** 为代表的项目，凭借其高性能执行架构，以及生态应用的逐步繁荣，已成为市场高度关注的核心公链。 相比之下，尽管以太坊 Rollup（L2）生态已进入“万链齐发”甚至“产能过剩”的阶段，当前主流的 **EVM 系并行增强链**仍普遍停留在测试网阶段，尚未经过主网环境的实际验证，其扩容能力与系统稳定性仍需进一步检验。至于这些项目能否在不牺牲兼容性的前提下显著提升 EVM 性能，推动生态跃迁，抑或反而加剧对以太坊流动性与开发资源的进一步分化，仍有待时间检验。 --- *Originally published on [0xjacobzhao](https://paragraph.com/@0xjacobzhao/%E6%89%A9%E5%AE%B9%E7%9A%84%E6%9C%AA%E6%9D%A5%EF%BC%9Aweb3-%E5%B9%B6%E8%A1%8C%E8%AE%A1%E7%AE%97%E8%B5%9B%E9%81%93%E5%85%A8%E6%99%AF%E5%9B%BE%E8%B0%B1)*