撰文：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 是系统容错派，更像「数据库并发引擎」，适合状态耦合强、调用链复杂的合约体系；Sui 是编译安全派，更像「资源型智能语言平台」，适合资产分离、组合清晰的链上应用，Aptos 和 Sui 要像程序语言工程师，像软件一样安全运行链（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 性能，推动生态跃迁，抑或反而加剧对以太坊流动性与开发资源的进一步分化，仍有待时间检验。
