区块链因其去中心化的设计而牺牲了效率，因此提升执行速度一直是急需解决的问题之一。区块链的「执行层」是处理每一笔交易并将其加入链中的关键部分。为了加速处理能力，在执行层进行提升成为核心策略之一，而并行执行正是这一方面的重要突破。

传统的区块链通常采用串行方式逐笔处理交易，这使得交易速度受到很大限制，尤其在交易密集的网络中会引发拥堵。然而，通过并行执行，多个交易可以同时处理，从而大幅提高执行效率并减轻链上压力。

为了更好地了解什么是并行，我们将先从执行开始介绍，并以 Merge 后 PBS 模式下的以太坊为例，来解释一下什么是执行，同时展示执行在整个交易生命周期中所处的位置。

交易执行的具体环节

1. 交易进入内存池并被筛选和排序：这是交易被提交后的预处理阶段，包含了 Mempool、Searcher 和 Builder 的交互，完成对交易的筛选和排序。

2. Builder 构建区块（但不执行）：Builder 将有利可图的交易排列成一个区块，以完成对交易的打包和排序。

3. Proposer 验证并提交区块：区块构建完成后，Builder 会将区块的提案发送给 Proposer。Proposer 对区块的结构和交易内容进行验证，然后正式将区块提交到网络上，以开始执行。

4. 执行交易：区块提交后，节点逐笔执行区块内的交易。这是状态更新的关键阶段，每笔交易都会触发智能合约调用、账户余额变化或状态变更。

5. 见证者见证：验证者对区块的执行结果和状态根进行见证，并将其作为最终确认。这确保了区块在执行层的真实性和有效性，并防止不一致性。

6. 状态同步：每个节点会将区块的执行结果（如账户余额、合约状态更新等）同步到自己的本地状态，执行每笔交易后，节点计算并存储一个新的状态根，用以在下一个区块中作为初始状态。

当然，这只是以区块为单位的交易的状态同步，为了保持最新的链上状态，通常情况下，节点会逐个区块同步数据，并持续验证区块和状态。但如果要达到 POS 机制下的最终性，还需要聚合者将每个 Slot 中的见证者签名聚合成一个完整的签名，并将其传递到下一个 Slot 的提议者处，并且验证者需要在经过一个 Epoch 后，基于投票数量确认该 Epoch 内的所有区块的状态，形成临时的共识状态检查点。当连续两个 Epoch 获得大多数验证者的见证支持后，区块和交易才会达成最终性。#p#分页标题#e#

从交易的整个生命周期来看，执行发生在 Proposer 对 Builder 发送来的区块的结构和交易内容进行验证后。实际执行过程需要对交易逐笔处理，并对相应的账户或合约状态进行更新。所有交易执行完毕后，Proposer 会计算出一个新的状态根（默克尔根），这是对当前区块所有交易的执行结果和最终全局状态的总结。通俗来说，完整的区块执行过程包括把以太坊从前一个状态变成下一个状态的过程中需要完成的一系列计算，从每个交易的执行到默克尔根的计算。

顺序执行

与并行相对的是顺序执行，也就是目前区块链较为通用的执行方式。通常，交易会按照顺序逐步执行。当一笔交易完成执行后，以太坊会将账户状态及相关信息（例如余额、合约存储数据）更新至账户状态树中，新的账户状态哈希被生成。所有账户状态树完成更新后，就会形成被称为状态默克尔根的状态树的根节点哈希。在完成状态默克尔根、交易默克尔根和收据默克尔根后，区块头就会进行哈希计算，生成该区块的区块哈希。

而在这其中，交易的执行顺序至关重要。由于默克尔树是哈希值的二叉树，不同顺序下形成的默克尔根值会不同。

并行执行

在并行执行的环境下，节点会尝试对区块中的交易进行并行处理。并不是按照顺序一笔一笔地执行交易，而是将交易分配到不同的「执行路径」上，使它们能同时执行。通过并行执行，系统能够更高效地处理区块中的交易，提高吞吐量。

所有交易执行完成后，节点会将执行结果（即交易影响的状态更新）汇总，形成一个新的区块状态。这个状态会被