过去几年，几乎每一条公链的官网首页都会出现"扩容"两个字，但说的往往不是同一件事。Rollup 团队说自己在扩容，做数据可用性的团队说自己在扩容，做并行执行的 L1 也说自己在扩容。放在一起看，这些项目的技术路线、安全假设、性能上限完全不同，却共用一套模糊的营销语言。结果是，行业外的人很难分清 Arbitrum 和 Solana 解决的是不是同一个问题，连不少从业者也会把"分片"和"并行执行"混为一谈。
这篇文章想做的事情很直接：把扩容问题拆成几个互不重叠的层，说清楚 L2 Rollup、以太坊分片路线、独立数据可用性层、L1 并行执行各自站在哪一层、解决哪种瓶颈，再回答一个更实际的问题：并行 EVM 这条路线，在整张地图里处于什么位置，它和其他路线是竞争关系还是互补关系。
扩容问题不是一个问题，而是四个
一条公链要正常运转，至少要完成四件事：排定交易顺序并对外承诺不可篡改（共识），把交易数据发布出去让任何人都能验证（数据可用性），真正跑完这些交易逻辑并算出新的状态（执行），以及把最终结果作为可信来源提供给外部世界（结算）。以太坊在 2015 年上线时把这四件事捆在同一套节点软件里完成，这也是行业里说的"一体化"架构，好处是简单、安全假设统一，代价是任何一层遇到瓶颈，整条链都会被拖慢。
这套捆绑架构最先暴露问题的是执行层：以太坊主网的实际吞吐长期停留在个位数到十几笔每秒的量级，一旦出现热门应用，Gas 费用会迅速抬升。但以太坊团队并没有选择在执行层本身做文章，而是从 2020 年前后开始转向"以 Rollup 为中心"的路线图，把执行搬到链下，自己专心做数据可用性和结算的裁判。这个决定，是理解后面所有分支的起点。
L2 Rollup：把执行搬走，安全留在主网
Rollup 的思路是把交易执行放到一条独立的链上完成，只把交易数据和执行结果的证明发回以太坊主网。以太坊不需要重新执行这些交易，只需要验证证明是否成立（ZK Rollup）或者在争议期内允许任何人提出欺诈证明（Optimistic Rollup）。这样一来，执行层的算力瓶颈被转移到了 Rollup 自己的排序器上，而最终结算的安全性依然锚定在以太坊的验证者集合上。
根据 L2BEAT 的公开统计，截至 2026 年 4 月，该平台追踪的 73 条 Rollup 总锁仓价值约为 480 亿美元。Arbitrum One 以约 169 亿美元锁仓量领跑，占整个 L2 市场的 40% 以上；Base 紧随其后，约 128 亿美元；OP Mainnet 约 56 亿美元。以 Optimistic Rollup 为代表的乐观路线，加上 Arbitrum、Base、OP Mainnet 三家，合计占据了 L2 总锁仓量的约八成，ZK Rollup 阵营中的 Starknet、Linea、zkSync Era 体量则小得多，分别在数亿美元级别。这组数据说明一件事：目前市场里跑得最重的资金，依然更信任"先执行、留欺诈证明窗口"的乐观路线，而不是理论上更简洁的零知识证明路线，后者在证明生成成本和电路复杂度上仍有工程门槛没有完全跨过。
Rollup 解决的是执行层的水平扩展问题，但它继承了以太坊主网的两个约束：每笔交易最终仍要把数据发布上链（哪怕只是压缩后的 calldata 或 blob），且用户体验上多了一层从 L2 到 L1 的信任跳转。这也是为什么 Rollup 从来不是孤立存在的方案，它必须依赖一个足够便宜、足够安全的数据可用性层。
以太坊自己的转向：从执行分片到数据分片
熟悉以太坊历史的人应该记得，分片（sharding）这个词最早指的是执行分片：把以太坊状态切成多个分片，每个分片独立执行交易，理论上分片数量越多吞吐越高，这条路线在 2018 到 2020 年之间被反复讨论和设计。但随着 Rollup 技术的成熟，以太坊核心开发者判断，与其自己重构一套复杂的跨分片执行协议，不如把执行完全交给 Rollup，自己只保证数据发布和可验证性，这就是所谓的以 Rollup 为中心的路线图。
这个转向的落地成果是 Danksharding，以及作为其第一步的 Proto-Danksharding，也就是 EIP-4844。这项提案在 2024 年 3 月的 Dencun 升级中正式上线，引入了一种新的交易类型：blob 交易。每个 blob 大小约 128 KB，一个区块最多可以携带 6 个 blob，且这部分数据只在共识层保留 18 天后即被清理，不再永久占用全节点存储。根据多方统计，Dencun 升级上线后，L2 的数据发布成本相比此前的 calldata 方式下降了 90% 左右，直接带动了 Rollup 交易费用的大幅回落。全 Danksharding 的下一步，是通过数据可用性采样（Data Availability Sampling）让节点只需存储数据的一小部分分片就能确认整体数据可用，从而把 blob 容量再扩大一个数量级。
这里需要澄清一个常见的误解：今天以太坊语境下的分片，解决的已经不是执行层的吞吐问题，而是数据可用性层的容量问题。执行本身完全交给了 Rollup 生态。这也解释了为什么以太坊分片和 Solana、Bitroot 这类做并行执行的项目，虽然都挂着扩容的名号，实际解决的却是完全不同的瓶颈。
独立的数据可用性层：模块化的第三条腿
以太坊自身的 blob 容量提升需要时间，也不是所有 Rollup 都愿意把数据可用性绑定在以太坊主网上，由此催生了一批独立的数据可用性项目，典型代表是 Celestia、EigenDA 和 Avail。
Celestia 是最早把数据可用性单独拆出来做成一条独立链的项目，核心创新是数据可用性采样，让轻节点只需下载数据的一小部分就能以极高概率确认整块数据确实可用。据公开资料，截至 2025 年年中，已有超过 56 条 Rollup 接入 Celestia，其中 37 条部署在主网；2026 年 1 月的 Matcha 升级将区块容量提升至 128 MB，同时把节点存储需求降低了约 77%。EigenDA 走的是另一条路，依托以太坊的再质押（restaking）机制复用以太坊验证者集合的经济安全性，而不是新建一条独立公链，官方公布的吞吐目标为每秒 15 MB 量级。Avail 则由 Polygon Labs 主导，除了数据可用性本身，还在同步建设跨链互操作层 Nexus 与安全层 Fusion。
这三家共同代表了模块化区块链设计里的一层专业分工：数据可用性不再是主链的副产品，而是可以被任何一条 Rollup 或应用链按需采购的独立服务。这套逻辑的前提假设是，把执行、结算、数据可用性拆成独立组件分别做到极致，总体效果会优于一条链什么都自己扛的一体化设计，但代价是跨层信任假设变得更复杂，用户和开发者需要理解的组件也更多。
L1 并行执行：不搬家，直接换引擎
与 Rollup、分片、独立 DA 层这几条路线不同，L1 并行执行选择了另一个方向：不把执行搬走，而是重新设计执行引擎本身，让同一条主链能够并发处理互不冲突的交易。这条路线的逻辑起点是，以太坊 EVM 的性能瓶颈本质上是单线程顺序执行造成的，只要能在保持状态一致性的前提下让多核硬件真正跑满，就没有必要把执行外包给第二层。
这条赛道内部又分成几种技术路径。Solana 的 Sealevel 要求交易在执行前明确声明将要读写的账户，运行时据此构建依赖图，把互不冲突的交易调度到不同核心并行执行，根据公开数据，Solana 总锁仓量在 2026 年 4 月已达到约 83 亿美元，是仅次于以太坊主网及其 L2 生态的第三大公链，官方宣称的峰值吞吐能力在 6.5 万笔每秒量级。Sui 和 Aptos 走的是资源导向的对象模型：Sui 把链上资产建模为独立对象，互不共享状态的交易可以完全并行甚至跳过共识；Aptos 的 Block-STM 引擎则采用乐观并发控制，在执行过程中动态检测冲突并选择性回滚，而不是提前声明依赖。Sui 的总锁仓量从 2025 年 1 月的约 3.8 亿美元增长到 2026 年 4 月的约 18 亿美元，增幅接近 4.7 倍，显示出对象模型路线在过去一年获得了明显的资金和应用认可。
而在保持 EVM 完全兼容的前提下做并行执行，是另一条更贴近以太坊生态存量的路径，代表项目包括 Monad、Sei 和 Bitroot。Monad 于 2025 年 11 月 24 日上线主网，官方宣称吞吐目标为每秒万笔交易量级，采用乐观并行执行字节码兼容的 EVM，同时将共识与执行解耦以缩短最终确认所需的通信轮次，上线后总锁仓量迅速攀升至约 4.1 亿美元。Sei V2 同样采用乐观并行化路线，已有三条主网在运行，据行业分析，其真实 dApp 负载下的吞吐维持在每秒 2500 到 3500 笔的区间，与官方宣传数字之间存在一定差距，这也提醒读者在评估任何并行 EVM 项目时，都要区分实验室基准和真实负载下的持续吞吐。Bitroot 属于同一条赛道：乐观并行 EVM 的 Layer 1，通过动态交易分组、多引擎并行执行与多阶段冲突检测，在保持完整 EVM 兼容的前提下提升单链吞吐，并叠加状态分片作为进一步水平扩展的路径，这条技术路线会在系列后续文章中逐层拆解。
一张表看清楚谁解决什么
| 路线 | 代表项目 | 解决的层 | 核心手段 | 安全假设来源 |
|---|---|---|---|---|
| L2 Rollup | Arbitrum、Base、Optimism、zkSync、Starknet | 执行 | 链下执行 + 链上验证/欺诈证明 | 以太坊主网 |
| 以太坊分片（Danksharding） | 以太坊主网 | 数据可用性 | Blob 交易 + 数据可用性采样 | 以太坊自身验证者集合 |
| 独立 DA 层 | Celestia、EigenDA、Avail | 数据可用性 | 独立共识 / 再质押复用以太坊安全 | 各自验证者或再质押集合 |
| L1 并行执行 | Solana、Sui、Aptos、Monad、Sei、Bitroot | 执行 | 依赖分析或乐观并发，吃满多核硬件 | 自身验证者集合 |
互补，而不是互斥
把这张表摊开就会发现，四条路线其实分布在两个不同的坐标轴上。一个轴是"执行放在哪"：Rollup 选择搬到链下，L1 并行选择原地优化；另一个轴是"数据可用性由谁提供"：可以是以太坊主网自己，也可以是独立的 DA 层。这意味着现实中的组合远比二选一复杂：一条 Rollup 完全可以把执行留在自己的排序器上，同时把数据可用性外包给 Celestia，而不是以太坊主网；一条像 Bitroot 这样的并行执行 L1，也不排斥未来把自己的一部分数据可用性需求接入某个独立 DA 层，或者反过来，成为 Rollup 生态里资金和资产的结算终点。
因此，把并行 EVM 简单理解为"Solana 的竞争对手"或者"以太坊分片的替代品"都不够准确。它真正对标的，是执行层这一个具体环节里的瓶颈：当交易量上升、合约逻辑变复杂时，单线程执行模型撑不住，而 Rollup 虽然能横向扩展执行实例的数量，却没有解决单个执行实例本身的效率问题。并行 EVM 要做的，是在单条链、单个执行实例内部，把这件事情做得更快。
理解这张地图之后再去看后续每一篇技术文章，会更容易分辨哪些数字之间可以直接比较，哪些数字其实描述的是完全不同的系统组件。比如把 Bitroot 的单链吞吐和某条 Rollup 的吞吐直接放在一张表里对比，就需要先说清楚双方的数据可用性成本是否被计入，这类细节将在后续系列里逐一展开。