可扩展性的未来：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 遵循运行时乐观并发 冲突回滚策略，非常适合复杂的相互依赖事务。

三个执行阶段：

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

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

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

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 引入了“