可扩展性的未来：Web3并行计算的全景图

作者：0xjacobzhao 来源：mirror 翻译：善欧巴，金色财经

众所周知的区块链不可能三角——安全性、去中心化与可扩展性——揭示了区块链系统设计中的一个基本权衡：一个区块链系统要同时实现最大程度的安全性、完全去中心化以及高吞吐量处理，几乎是不可能的。

为了应对始终存在的可扩展性挑战，当今的区块链生态系统提出了多种多样的扩展解决方案。这些方案可以归为以下几种不同的范式：

• 执行增强型扩展：直接提升执行性能（例如，通过并行处理、GPU加速、多线程等）。

• 状态隔离型扩展：对状态进行横向拆分（例如，分片、UTXO 模型、多子网系统等）。

• 链下委托型扩展：将执行外包至链下（例如，Rollup、协处理器、数据可用性层等）。

• 结构解耦型扩展：架构模块化，并实现协作式执行（例如，模块化区块链、共享排序器、Rollup 网状网络等）。

• 异步并发型扩展：利用 Actor 模型，实现进程隔离和消息驱动执行（例如，智能代理、多线程异步区块链等）。

区块链的可扩展性解决方案涵盖了广泛的技术路径，包括链内并行、Rollup、分片、数据可用性模块（DA）、模块化架构、基于 Actor 的系统、零知识压缩以及无状态架构。这些方案跨越了多个技术层面，包括执行层、状态层、数据层以及结构层，构建出一个多层次、模块化、可组合的扩展体系。

本报告将特别聚焦于以链内并行计算为核心的扩展范式。

链内并行

链内并行旨在实现单个区块内事务或指令的并发执行。根据其底层机制，链内扩展可以分为五种主要模型，每种模型在性能、开发者体验、架构理念以及调度复杂性方面都有不同的权衡。随着并行粒度的提升，系统性能潜力增加，但同时实现难度和编程模型的复杂性也随之提高：

• 账户级并行 – 例如：Solana

• 对象级并行 – 例如：Sui

• 交易级并行 – 例如：Monad、Aptos

• 调用级 / 微虚拟机级并行 – 例如：MegaETH

• 指令级并行 – 例如：GatlingX

异步 Actor 模型并行

与上述模型不同，Actor 模型（如 AO、ICP、Cartesi）代表了一种根本不同的并行计算形式。这些系统以异步、事件驱动的智能代理网络形式运行，其中每个 Agent（进程）都是独立的执行单元。与同步区块计算不同，这些代理之间通过异步消息传递进行通信，不再依赖全局共识或同步调度。

这种模型构成了跨链和去中心化人工智能架构的基础，而非传统的“块对块”执行模型。

与 Rollup 和分片的区别

虽然 Rollup 和分片等成熟方案也能提升系统可扩展性，但它们属于系统级并发，而非链内并行。这些方案通过并行运行多个独立的执行环境（如多个链或 Rollup）来实现扩展，而非提升单个区块或虚拟机内的执行并发性。因此，它们并不是本报告的重点，尽管我们会在架构对比中提及它们，以凸显不同设计理念之间的对比。

Web3 执行中的并行类型

2. 兼容 EVM 的并行链：在保持兼容性的前提下突破性能边界

以串行处理为特征的以太坊架构，已经历了多个可扩展性演进阶段，包括分片、Rollup 和模块化架构。然而，执行层的吞吐瓶颈始终未被根本解决。与此同时，EVM 和 Solidity 仍然是最广泛采用的智能合约平台。因此，兼容 EVM 的并行执行链——在不牺牲生态兼容性的前提下提升性能——成为区块链可扩展性演进中的一个有前景的方向。其中，Monad 和 MegaETH 是两个代表性项目，分别通过延迟执行和状态拆解等方式，推动高吞吐量执行能力的发展。

Monad 的并行执行架构

Monad 是一个高性能、兼容 EVM 的 Layer 1 区块链，围绕流水线式并行执行进行了全面重构。其设计引入了共识层的异步执行与执行层的乐观并行处理，同时实现了专用的高性能共识协议（MonadBFT）和数据库（MonadDB），实现端到端的系统优化。

关键机制：

• 流水线处理

  Monad 将交易生命周期分解为多个流水线阶段（提议 → 共识 → 执行 → 提交），各阶段可在不同线程或核心中独立并发处理。这种多层流水线显著提升吞吐能力并降低延迟。

• 异步执行：

  在传统区块链中，共识与执行耦合紧密。而 Monad 将其解耦：

  这一方式提高了系统弹性，降低了区块时间与确认延迟，并提升了资源利用率。

• 共识层仅负责交易排序；

• 执行在共识完成后异步触发；

• 系统可在上一块尚未执行完毕时，就启动下一块的共识流程。

• 乐观并行执行（Optimistic Parallel Execution）：

  Monad 假设大多数交易不会发生冲突，采用乐观并行：

• 冲突检测器监控状态访问冲突（如读写重叠）；

• 有冲突的交易将被串行重执行，以确保状态正确性。

Monad 遵循“最小干扰”原则，在保留 EVM 语义的前提下实现高性能执行。它可以被视为以太坊的“并行加速器”，兼容性高，生态迁移成本低。

MegaETH 的并行执行架构

与定位为 Layer 1 的 Monad 不同，MegaETH 被设计为模块化、高性能、兼容 EVM 的并行执行层。它既可以作为独立的 L1 链运行，也可以作为以太坊的可插拔执行模块。其核心目标是将账户逻辑、执行环境与状态解构为最小化、可独立调度的单元，以实现高并发与低延迟。

关键创新：

• 微虚拟机架构：

  MegaETH 采用“一账户 = 一微虚拟机”的模型。每个账户在独立的执行线程中运行，拥有自身的存储与逻辑。各个微虚拟机通过异步消息传递进行通信，而非同步函数调用。此设计天然支持并行性与模块化调度。

状态依赖有向无环图：

MegaETH 实时维护一个账户状态依赖的有向无环图（DAG）：

这一机制确保并发执行下的确定性与状态一致性，防止重复写入或冲突错误。

• 每笔交易的读写依赖会被建模进 DAG；

• 无冲突交易可并行执行；

• 有依赖关系的交易则根据 DAG 拓扑顺序串行或重新调度。

异步执行模型：

MegaETH 使用一种类似 Actor 模型的编程范式，以异步消息传递取代传统调用栈。当合约 A 调用 B，而 B 又调用 C 时，这些调用将被转化为异步调用图，交易执行流程为：遍历调用图 → 解析依赖 → 并行执行

总结

MegaETH 通过将账户封装为微虚拟机、使用依赖图进行调度，并通过异步消息进行通信，彻底摆脱了以太坊单线程状态机的限制。它是为下一代高性能区块链系统而设计的完整并行执行平台。

相较而言，Monad 采取“兼容优先、优化 EVM”的路径，在不破坏以太坊模型的前提下增强执行能力；而 MegaETH 则进行深层架构重塑，将以太坊执行模型演化为高度并发、类线程化的运行时环境。虽然 MegaETH 的并行性理论上限更高，但其复杂度也相应提升。

MegaETH 更像是一个构建在以太坊理念之上的分布式操作系统。

Monad 与 MegaETH 对比表

设计理念对比：Monad 与 MegaETH vs. 分片

尽管 Monad 和 MegaETH 都致力于实现高吞吐量的并行执行，但它们的方法与“分片”本质上存在根本差异。

分片通过将区块链网络水平划分为多个独立分片来扩展性能，每个分片负责部分状态和交易负载。这种方式通过并行运行多个子链，打破了单链的限制，从网络层进行横向扩展。

而 Monad 和 MegaETH 则保留单链结构的完整性，选择在执行层内部进行横向扩展，目标是在同一链上实现最大化的并行执行，而非将链拆分。

因此，它们代表了区块链可扩展性的两种互补方向：

• 分片 = 网络层的水平划分

• Monad/MegaETH = 执行层的垂直优化

作为并行执行类项目的代表，Monad 与 MegaETH 主要关注吞吐量优化，通过延迟执行（Deferred Execution）、微虚拟机（Micro-VM）等机制，在交易级或账户级实现并行性，提升链上 TPS。

与 Monad 和 MegaETH 专注于单链并行执行不同，Pharos Network 是一个模块化、全栈式并行 Layer 1 区块链，其核心并行计算架构称为 Rollup Mesh。该架构通过协调主网与一组专用处理网络（SPNs），实现多虚拟机环境（如 EVM 和 WASM）的并发执行，并融合零知识证明（ZK）、可信执行环境（TEE）等先进技术。

Rollup Mesh 并行执行架构：核心机制

• 全生命周期异步流水线：

  Pharos 将交易生命周期（共识、执行、存储等）解耦为多个阶段，异步并行处理，从而大幅提升整体吞吐能力。

• 双虚拟机并行执行：

  同时支持 EVM 与 WASM，开发者可按需选择执行环境，双 VM 架构既增强了灵活性，也支持并行合约运行。

• 专用处理网络 SPNs：

  SPN 是面向特定任务或应用场景的模块化子网络，Pharos 可将工作负载分布到多个 SPN 上，实现动态资源调度与并行化负载，显著增强系统性能与扩展性。

• 模块化共识与再质押机制：

  支持多种共识机制（PBFT、PoS、PoA），并引入再质押协议，实现主网与 SPNs 之间的安全协同和经济统一。

此外，Pharos 从底层存储引擎架构重构执行模型，集成多版本 Merkle 树、增量编码（delta encoding）、版本化地址（versioned addressing）、ADS pushdown 等技术，推出 Pharos Store —— 一个高吞吐、低延迟、强验证性的原生区块链存储引擎，为链上计算提供强大支撑。

Pharos 的 Rollup Mesh 架构通过模块化设计与异步任务调度，构建出高性能并行计算平台。与 Monad 和 MegaETH 专注于链内执行优化不同，Pharos 更像是一个跨 Rollup 调度器与协调器，通过 SPNs 实现定制化、并行化的执行环境。

GPU 加速的 EVM 执行：Reddio 与 GatlingX

除了 Monad、MegaETH 与 Pharos 所代表的执行层并行架构外，生态中还在探索一种新的性能突破路径：基于 GPU 的 EVM 并行执行。两个具有代表性的项目是 Reddio 和 GatlingX。

Reddio

Reddio 是一个结合了 zkRollup 与 GPU 并行执行架构的高性能平台。其核心创新在于通过多线程调度、异步状态存储、GPU 加速的批量交易执行等方式，重构了 EVM 执行流程，实现执行层的原生并行性。

• 同时支持交易级与操作级（opcode 多线程）并行执行；

• 引入了多线程批量执行、异步状态加载、CUDA 并行化交易逻辑（即“GPU 兼容 EVM”）；

• 类似 Monad 与 MegaETH，Reddio 关注执行层并行，但区别在于其完全围绕 GPU 架构进行设计，尤其适用于 AI 推理等计算密集型场景。

目前 Reddio 已推出 SDK，可集成至其他系统作为执行模块。

GatlingX

GatlingX 被称为“GPU-EVM”，提出一种更激进的架构：将传统 EVM 的指令级串行执行迁移到 GPU 原生并行环境。

• 核心机制是将 EVM 字节码动态编译为 CUDA 并行任务；

• 在 GPU 核心上并行执行指令流，从底层彻底突破 EVM 串行瓶颈；

• 与 Monad/MegaETH 的交易级或账户级并行不同，GatlingX 采取的是指令级优化路径，更类似对虚拟机执行引擎的深度重构。

目前仍处于概念阶段，已发布白皮书和架构草图，但尚无 SDK 或主网产品。

3. 原生并行执行链：重构虚拟机的执行基础

以太坊虚拟机（EVM）采用基于全序交易 + 顺序执行的单线程架构设计，旨在确保网络节点之间的状态转换一致性和确定性。然而，这种架构天生存在性能瓶颈，限制了吞吐量与可扩展性。

相比之下，新一代原生并行链（如 Solana 的 SVM，基于 MoveVM 的 Sui 和 Aptos，以及构建于 Cosmos SDK 的 Sei v2）自底层起就为并行执行而设计，具备以下关键优势：

天然分离的状态模型：Solana：通过账户级访问声明实现状态隔离；MoveVM：引入对象所有权模型（Object Ownership Model）；Sei v2：按交易类型分类，实现静态冲突检测与交易级并发执行。

针对并发优化的虚拟机设计：Solana 的 Sealevel 引擎：支持原生多线程执行；MoveVM：支持静态并发图分析；Sei v2：集成多线程撮合引擎与并行虚拟机模块。

尽管如此，原生并行链也面临生态兼容性挑战。非 EVM 架构往往需要全新语言（如 Move 或 Rust）与开发工具链，带来迁移成本。同时，开发者需掌握如状态访问模型、并发约束、对象生命周期等新概念，提高了认知与开发复杂度。

3.1 Solana 与 SVM 生态：Sealevel 并行引擎

Solana 的 Sealevel 执行模型 是一个面向账户级并行的交易调度器。其通过 账户声明 + 静态调度 + 多线程执行，支撑起 Solana 链上高性能并发处理。Sealevel 是第一个实现块内并行执行的量产引擎，并深刻影响了后续并行虚拟机的设计。

核心机制：

• 账户访问显式声明：

  每笔交易必须声明其读/写账户，运行时据此检测是否存在冲突。

• 冲突检测与多线程调度：

• 如果两笔交易访问的账户集合无交集 → 并行执行；

• 如果存在冲突 → 按依赖关系顺序串行执行；

• 调度器会基于依赖图将交易分配到不同线程执行。

• 隔离的程序调用上下文：每个合约调用运行在独立的上下文中，避免共享堆栈或跨调用干扰。

Sealevel 是 Solana 的并行执行引擎，而其上层虚拟机 SVM 使用的是 BPF 虚拟机。两者结合构成了 Solana 并行运行时的技术核心。

• Eclipse 项目将 Solana 的 VM 移植到模块化区块链（如以太坊 L2 或 Celestia）上，使用 Sealevel 作为 Rollup 的执行层。它是首个将 Solana 执行堆栈模块化的项目，开启了“执行层即服务”新范式。

• Neon 则反向操作，将 EVM 引入 Solana 的 Sealevel 环境中，使 Solidity 合约可在 SVM + Sealevel 组合中运行。其更偏向模块化区块链架构，而非并行计算创新。

简而言之，Solana 与其 SVM 核心依赖 Sealevel 的并行调度机制。其调度哲学近似操作系统内核，专注于极致执行速度，但灵活性相对较低，代表了一种高性能、原生并行的 Layer 1 区块链路径。

3.2 MoveVM 架构：以对象为中心的并行执行

MoveVM 是一款为资源安全与并发而设计的智能合约虚拟机。其核心语言 Move 由 Meta（原 Facebook）为 Libra 项目开发，引入了“资源即对象”的理念：链上状态以对象形式存在，具备明确的所有权与生命周期。

这一面向对象的状态模型使得编译时即可分析交易冲突，从而实现确定性的、对象级的并行调度。Sui 与 Aptos 等原生并行链正是基于该机制构建。

Sui 的对象所有权模型

Sui 的并行执行能力源于其独特的状态结构与语言层的静态分析机制。

与传统区块链使用“全局状态树”不同，Sui 将状态表示为离散的“对象”，每个对象具备以下特性：

• 唯一的 ID

• 明确的所有者（用户或合约）

• 严格的类型定义

这种对象天然彼此隔离。智能合约需显式声明所访问的对象，消除了对全局状态的依赖，是实现安全并发的基础条件。

静态所有权分析：Move 的线性类型系统允许编译器在交易执行前，通过分析对象所有权来判断是否存在冲突。

• 若无冲突 → 并行调度执行

• 无需依赖运行时回滚或交易重排（区别于乐观执行模式）

通过将状态划分为对象并静态分析依赖关系，Sui 实现了低开销、高确定性的并行性，显著提升性能、系统可预测性及资源利用效率。

Aptos 和 Block-STM 执行模型

Aptos是另一个基于 Move 的高性能 Layer 1 实现，它实现了Block-STM（块级软件事务内存）以实现并行性。与 Sui 的编译时静态调度不同，Block-STM 遵循运行时乐观并发 + 冲突回滚策略，非常适合复杂的相互依赖事务。

三个执行阶段：

1. 推测执行：乐观地认为所有事务都是无冲突的，并且跨线程并行执行，并记录读/写集。

2. 验证阶段：系统检查是否存在冲突 - 例如，如果 Tx1 读取了 Tx2 写入的值 - 则使其中一个无效。

3. 重试阶段：冲突的事务将被重新安排，直到依赖关系得到解决。最终输出是一个有效的、确定性有序的状态转换。

Block-STM 是一种基于“乐观并行 + 回滚”的动态执行模型，非常适合状态密集型、逻辑复杂的事务集的批处理，构成了 Aptos 可扩展架构的并行计算主干。

原生并行执行架构比较

Solana代表了工程驱动的调度理念——更类似于操作系统内核。它最适合高频、范围紧密的交易，其中状态边界定义明确且可控。Solana 体现了硬件工程师的思维模式，旨在像硬件一样运行区块链：硬件级并行执行。

相比之下，Aptos遵循容错系统方法，类似于并发数据库引擎。它非常适合具有深度交织状态和长依赖链的复杂智能合约系统。

Sui体现了编译时安全范式，类似于一个面向资源的智能语言平台。它在具有明确资产分离和可组合性的应用程序方面表现出色。

Aptos 和 Sui共同代表了软件工程师的思维方式——致力于智能合约执行中的软件级资源安全性和正确性。

Solana、Aptos 和 Sui这三个项目代表了Web3 并行计算的不同理念和工程方法，每个项目都提供了实现可扩展执行的独特途径。

3.3 基于 Cosmos SDK 的并行扩展

Sei V2是基于Cosmos SDK构建的高性能、专注于交易的区块链。其并行执行能力主要围绕两大核心创新：多线程撮合引擎和虚拟机层的并行执行优化。Sei 旨在服务于高频、低延迟的链上交易用例，例如基于订单簿的 DEX和链上交易基础设施。

核心并行机制：

• 并行撮合引擎：Sei V2 通过将订单簿和撮合算法拆分到多个线程中，将多线程执行引入订单撮合逻辑。这使得独立的撮合任务（例如跨交易对）可以并发处理，从而避免单线程瓶颈。

• 虚拟机级并发：Sei V2 增强了CosmWasm VM 的并行执行功能，允许不冲突的合约调用并发运行。结合交易类型分类，这提高了吞吐量和系统响应速度。

• 共识-执行解耦（Twin-Turbo）：Sei V2 引入了“ Twin-Turbo ”共识机制，将共识吞吐量与执行调度解耦，从而实现更高的整体区块处理效率。

3.4 Fuel：基于 UTXO 的并行执行改革器

Fuel是一个高性能执行层，在构建时充分考虑了以太坊的模块化特性。其并行性源于重新架构的 UTXO（未使用交易输出）模型。与以太坊基于账户的模型不同，Fuel 利用 UTXO 来表示资产和状态，提供自然的状态隔离，从而简化了冲突检测并实现了交易的安全并行执行。

Fuel 还介绍了：

• Sway，一种受 Rust 启发的智能合约语言；

• 静态分析工具，在执行之前预先检测潜在的输入冲突。

这种设计使得 Fuel 能够实现高效、安全、交易级并行，使其成为一个引人注目的模块化 EVM 兼容执行层，在性能和灵活性之间取得平衡。

4. Actor模型：并行执行的新范式

Actor 模型是一种以自主计算单元（代理或进程）为中心的并行执行范式。与依赖同步全局状态的传统链上系统（如 Solana、Sui、Monad 等）不同，Actor 模型强调每个代理的独立状态和行为，并以异步消息传递作为通信和协调的基础。

这种架构使区块链系统能够支持大规模并行、解耦的进程，提供卓越的可扩展性和异步容错能力。代表性项目包括AO (Arweave AO)、ICP (Internet Computer)和Cartesi ，它们正在推动区块链系统从执行引擎向“链上操作系统”的演进，为人工智能代理、多任务工作流和复杂逻辑编排提供基础架构。

尽管 Actor 模型与分片有一些共同的表面特征（例如并行性、状态隔离和异步执行），但它们在技术设计和系统理念上有着根本的不同。

• Actor 模型强调异步多进程计算，其中每个Actor维护自己的状态并通过消息传递进行交互。

• 相比之下，分片是一种状态和共识的水平划分形式，将区块链分成多个子系统（分片），每个子系统处理部分网络交易。

本质上，Actor 模型充当了Web3 世界的“分布式代理操作系统” ，而分片则仍然是针对链内交易吞吐量的结构性扩展解决方案。两者都实现了并行性，但起点、目标和架构策略有所不同。

4.1 AO（Arweave）：基于存储构建的超并行计算机

AO是一个建立在Arweave 永久存储层上的去中心化计算平台，其核心目标是创建一个用于大规模异步代理执行的链上操作系统。

主要特色：

• 基于流程的架构：每个代理都是一个具有自己的状态、调度程序和执行逻辑的流程。

• 没有区块链结构：AO不是区块链；它在 Arweave 之上使用分散存储 + 多代理、消息驱动的执行引擎运行。

• 异步消息系统：进程之间的通信完全异步且无锁，从而实现可扩展的并发性。

• 永久状态存储：所有流程状态、消息和指令都不变地存储在 Arweave 上，确保可审计性和去中心化。

• 代理原生设计：AO 专为复杂、多步骤的工作流程（例如AI 代理、DePIN 控制器或自动编排系统）量身定制，可作为链上 AI 协处理器框架。

AO 遵循激进的“代理原生 + 存储驱动 + 非链式架构”模型。它注重灵活性和模块化分解，充当轻量级的链上微内核，旨在最小化系统边界，以实现可组合控制和精益执行。

4.2 ICP（互联网计算机）：全栈 Web3 托管平台

ICP是由DFINITY开发的Web3原生全栈链上应用平台，其目标是提供具有Web2级可用性的区块链级计算能力，包括全服务托管、域名绑定和无服务器架构。

主要特色：

• 容器架构（容器即代理）：每个容器都是在Wasm VM中运行的代理，具有独立的状态、代码和异步调度程序。

• 基于子网的分布式共识：网络由多个子网组成，每个子网管理一组罐，并通过BLS 阈值签名达成共识。

• 异步调用模型：容器通过异步消息进行通信，从而实现跨网络的非阻塞、并行执行。

• 链上 Web 托管：ICP 支持将前端代码直接托管在链上，并集成原生 DNS。它是第一个支持浏览器访问 dApp 的区块链。

• 全面的系统 API ：包括热升级、身份验证、分布式随机性、计时器等内置功能- 非常适合复杂的链上服务。

ICP 采用“重量级平台”模型，包含单体集成和全栈控制。通过将执行、共识、存储和访问紧密耦合，ICP 可充当真正的区块链操作系统，并将其边界扩展到完整的Web3 托管堆栈。

其他基于Actor模型的并行计算项目总结如下表：

基于 Actor 模型的项目比较

5.总结与展望

根据虚拟机架构和编程模型的不同，区块链并行计算方案大致可以分为两类：兼容EVM的并行增强链和原生并行架构的链（非EVM）。

EVM 兼容的并行链

这些链与EVM/Solidity 生态系统完全兼容，同时实施深度执行层优化，以实现更高的吞吐量和并行性。对于希望利用以太坊开发者生态系统并突破性能限制的项目而言，它们是理想之选。代表性项目包括：

• Monad：使用延迟写入和运行时冲突检测实现与 EVM 兼容的乐观并行执行模型，在达成共识后构建依赖图以实现多线程执行。

• MegaETH：将每个账户/合约视为一个独立的微型虚拟机，使用异步消息传递和状态依赖 DAG 来实现解耦的账户级并行调度。

• Pharos：通过异步流水线和 SPN（专用处理网络）模块构建Rollup Mesh架构，实现跨执行阶段的系统级并行协调。

• Reddio：采用基于zkRollup+GPU的架构，专注于通过批量SNARK处理加速链下zkEVM证明生成，以增强验证吞吐量。

原生并行链（非 EVM）

这些架构完全放弃了与以太坊的兼容性，从头开始重新设计执行机制——虚拟机、状态模型和调度——以实现原生的高性能并行性。主要子类型包括：

• Solana（基于 SVM）：使用帐户访问声明和静态冲突图在事务调度程序级别实现帐户级并行性。

• Sui / Aptos（基于 MoveVM）：建立在资源对象模型和类型系统上，支持编译时静态分析和对象级并行执行。

• Sei V2（基于 Cosmos SDK）：将多线程匹配引擎和 VM 级并行性集成到 Cosmos 堆栈中，适用于高频交易应用程序。

• Fuel（UTXO+Sway）：采用静态UTXO输入分析模型，实现交易级并发，并结合模块化执行层和自定义智能合约语言Sway。

Actor 模型链：基于代理的异步并行

Actor 模型作为一种更广泛的并发范式，通过 Wasm 或自定义虚拟机构建了一个基于异步进程调度的全新链上执行框架。它强调代理级自治和消息驱动的协调，从而实现大规模可扩展性和异步组合。代表性项目包括：

• AO（Arweave AO）：基于永久存储（Arweave）构建的代理运行时，形成异步链上微内核系统。

• ICP（互联网计算机）：使用Canisters作为容器代理，通过子网进行协调，实现跨网络的可扩展、异步执行。

• Cartesi：引入基于 Linux 的链下执行层，其中复杂或计算密集型逻辑通过可证明的结果在链上进行验证。

基于这些框架，我们可以使用以下分类图来总结和分类当前主流并行执行区块链平台的格局：

从更广泛的可扩展性角度来看，分片和Rollups（L2）专注于通过状态分区或链下执行实现系统的横向扩展。相比之下，并行执行链（例如Monad、Sui、Solana）和面向 Actor 的系统（例如AO、ICP）从根本上重建了执行模型，从而实现了链内或系统级别的原生并行性。

前者通过多线程虚拟机、基于对象的状态模型、交易冲突分析等技术提升链上吞吐量；后者将每个流程或代理视为独立单元，采用消息驱动和异步执行的方式，实现跨代理的海量并发。

相比之下，分片和 Rollups更类似于“在多条链上分配负载”或“将执行外包到链下”，而并行链和基于参与者的系统则旨在“从执行引擎内部释放性能”——代表着更根本的架构演变。

并行执行、分片、汇总、面向 Actor：可扩展性路径比较

值得一提的是，大多数原生并行架构的区块链已在主网上线。尽管它们的整体开发者生态系统与基于 Solidity 的 EVM 堆栈相比仍有差距，但像Solana和Sui这样的项目凭借其高性能的执行架构和蓬勃发展的链上生态系统，已成为备受瞩目的 Layer 1 层。

相比之下，尽管以太坊 Rollup（L2）生态系统已进入“大规模扩散”阶段，甚至面临容量过剩的担忧，但大多数兼容 EVM 的并行增强链仍处于测试网阶段，尚未在真实的主网条件下进行验证。其真正的可扩展性和系统稳定性仍有待进一步验证。

这些链是否能够在不牺牲兼容性的情况下显著提高 EVM 性能，从而催化新一波生态系统演进——或者进一步分散以太坊的流动性和开发者资源——还有待观察。