Page 245 - 《软件学报》2026年第1期

242 软件学报 2026 年第 37 卷第 1 期

量增多时, 构建依赖图所需的处理时间也随之增加, 造成系统性能的降低. 除此之外, 由于 Fabric++和 Fabric#均继
承了 Fabric 的执行-排序-验证架构, 它们的终止率存在热点的工作负载下也较高.
如图 8 所示, 文献 [104] 提出一种将排序与执行阶段并发进行的架构, 用户将交易发往 Peer 做预执行的同时
将交易转发给其他节点和排序服务, 排序服务在执行交易的同时排序交易, 共识生成区块. 在区块生成后, Peer 按
照区块内交易的顺序运行 SSI 并发控制, 为了保证并发执行排序过程中所有节点以相同的状态提交, 使用了一种
基于区块高度的 SSI 方法, 这种方法根据当前块的高度和操作来决定是否终止交易, 以此保证可串行化, 并得到确
定性的执行结果.

T 1 T 2 T 3 T 4
Ordering service (Orderer)
Blocks
T 1 |Commit
T 2 |Abort
T 4 T 1
T 3 |Abort
User T 2 T 3 T 4 |Commit
Execution with SSI (Peer)
图 8 使用 SSI 并行进行排序和执行阶段

FISCO-BCOS [27] 在事务执行前确定性地构建依赖图. 为了增加事务执行并发度, FISCO-BCOS 将事务按照其
调用合约划分为多个分区 (shard). 和分片区块链不同, FISCO-BCOS 的每个节点执行全部事务并保存完整账本状
态, 这样可以避免执行跨分片事务造成的跨域网络协调开销. 为了保证不同节点上跨分区事务执行的确定性,
FISCO-BCOS 使用屏障 (round) 来同步节点内这些分区的执行. 在每一轮中, 每个分区使用其执行器分析分配给该
分片的事务, 根据事务之间的依赖关系构建有向无环图 (directed acyclic graph, DAG) 用于并发执行. 由于执行器
只有当前 round 该分区内事务的 DAG, 当其他分区的事务调用该分区的智能合约时, 事务会挂起直到下个 round
开始, 确保执行器生成包含这个事务的 DAG. FISCO-BCOS 还使用了检查点来验证执行结果的一致性, 若无法在
一定时间内完成验证, 该区块会被重新执行.
2.3 确定性并发控制
在执行同样一组交易时, 由于交易对锁的竞争、操作系统对线程的调度, 网络延迟等原因, 非确定性并发控制
无法保证这组交易的每次执行的结果都一致. 上述采用非确定性并发控制的区块链系统中, 主节点必须在执行交
易后共识区块, 验证者按照执行顺序验证区块. 非确定性并发控制缺点如下: 共识前需要先执行交易, 确认延迟较
高; 按照给定顺序验证区块限制了验证者的并发度; 除了包含原始交易外, 区块还必须包含执行结果用于验证, 共
识时传输执行结果会产生额外开销.
在分布式数据库中, Calvin 最早提出了基于有序锁 [46] 的悲观协议. 其存在一个全局的锁管理和多个 scheduler,
其中 scheduler 通过顺序扫描经过共识的日志为交易获取锁, 交易当获取所有锁后才能执行. 但协议的锁管理必须
已知交易的读写集, 读写集可通过预执行等方式获取 (与第 2.2 节为读写集未知的事务构建依赖图类似);
Sparkle [113] 采用试探性执行的乐观并发控制协议, 在提交阶段判断交易是否满足确定性和可串行化; PWV [114] 通过
让交易的更新尽可能早地被其他交易可见来减少 stale read 的发生, 进而提高成功率. Aira [68] 利用依赖图 [107,114] 实
现确定性并发控制, 并提出了一种确定性重新排序机制, 进一步减少交易终止率.
图 9 展示了确定性并发控制的流程. 在收集到一个区块内的所有交易后, 全节点 Peer 1 和 Peer 2 并发执行这
组交易而无需进一步协调. 虽然由于操作系统调度等原因, 这些节点执行交易的顺序不一定完全相同 (例如, 当使
用 Aria 并发控制时, Peer 1 先执行 T 1 后执行 T 2 , Peer 2 则并发执行这两个交易, 而无需考虑先后顺序), 但是当执
行完成后, 每个节点的状态都从相同的初始状态确定性地转换为相同的最终状态.
确定性并发控制的代表系统为 NeuChain [38] 、HarmonyDB [115] 和 SChain [116] . 这些系统先对未执行的交易做全
局排序, 随后复制到节点执行. NeuChain [38] 在区块链场景下利用 Aria 确定性并发控制方法, 消除了排序服务导致