Page 243 - 《软件学报》2026年第1期
P. 243

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


                  1.4.5    流水线技术
                    在传统   PBFT  共识中 (如  BFT-SMART [99] 实现) , 下一轮共识只会在上一轮共识完成后开始. 流水线技术可以
                 让协议的多轮共识并发进行, 下一轮共识不必等到上一轮结束, 极大地提升系统性能. 几乎所有共识协议均采用了
                 流水线技术, 例如     RCC  [100] 、Kauri [60] 、GeoBFT、SBFT [95] 、PoE [97] 等. Parallel-Raft [101] 是 PolarDB  的  Multi-Raft 实
                 现, 它提出了乱序日志复制技术 (即日志的乱序确认、提交和应用) 来提高性能; NeuChain、FastFabric                 [102] 、BIDL [103] 、
                 Density  等系统将区块的共识与复制分离来提高性能. 共识协议仅共识区块的哈希值, 即仅对区块哈希排序, 而真
                 正区块会异步并行地使用         ZeroMQ  等高速消息队列完成复制.
                    流水线技术已经被广泛应用到跨域联盟链系统中, 如                  Canopus 和  FISCO-BCOS [27] , 并极大地提升了这些系统
                 的性能. 但是, 如何在跨域联盟链中高效地使用流水线技术仍然面临挑战: 1) 流水线化某些流程可能需要复杂的错
                 误处理和回滚机制. 例如, PoE      [97] 提出了推测执行 (speculative execution) 技术, 其将乱序处理和流水线相结合, 交易
                 可以在达成共识前执行. 但是, PoE        需要在共识未达成时回滚已执行的交易, 这不仅增加了处理复杂性, 还可能影
                 响系统的整体性能和响应时间. 2) 增加的并行和乱序处理可能引入新的安全漏洞. 例如, BIDL                         等系统在流水线化
                 的同时也提出了异常处理方法并详细讨论了正确性.

                  2   并发执行技术

                    联盟链普遍采用并发控制算法执行交易, 来应对共识效率提升带来的交易执行瓶颈                            [104] . 现阶段联盟链主要包
                 括  4  类并发控制技术: 乐观并发控制        (OCC)、基于依赖图的并发控制、确定性并发控制和无协调一致性. 上述并
                 发控制算法在跨域部署时性能会随着域间延迟、热点数据、工作负载等变化而变化, 需要根据具体需求进行选
                 择. 接下来将分别介绍上述并发控制技术和它们的优缺点.
                  2.1   乐观并发控制
                    传统基于锁的并发控制, 如两阶段锁            (2PL), 在交易对记录进行读写操作前需要获取锁. 这会限制对记录的并
                 发访问, 进而影响吞吐率. 除此之外, 锁的获取与释放也会产生额外开销. 相比而言, 乐观并发控制 (OCC) 假设交
                 易读写冲突较少, 即大多数交易均能提交. 因此, OCC             算法在执行过程中不会对交易上锁, 读写冲突会在交易准备
                 提交时验证.
                    乐观并发控制的系统代表是           Fabric, 它在执行交易时不检测读写冲突, 直到验证阶段提交时才会串行验证是
                 否产生读旧版本      (stale read) 异常. Fabric 将节点分为排序节点  Orderer 和普通节点   Peer. 系统由多个组织参与, 每
                 个节点都属于某个组织. 如图         7  所示, Fabric 的交易执行流程由执行, 排序, 验证这       3  个阶段构成. 交易执行需要满
                 足特定背书条件, 并需要保证执行结果            (即交易的读写集) 在节点间一致.

                                                                                      Blocks
                                                                                     T 1 |Commit
                                                                                     T 2 |Abort
                                       T 1   T 2
                                                                                     T 3 |Abort
                             Peer 1    T 3   T 4                                     T 4 |Commit
                                                           T 1  T 2  T 3  T 4
                                                                                      Blocks
                                                              Ordering service
                                       T 4   T 1                                     T 1 |Commit
                                                                                     T 2 |Abort
                             Peer 2    T 2   T 3                                     T 3 |Abort
                                 Execution                                           T 4 |Commit
                                                 图 7 Fabric 的  OCC  执行流程

                    在执行阶段, 用户将交易发往满足背书条件的               Peer 执行. Peer 在执行交易时, 在交易内记录读操作的版本, 用
                 于稍后的验证, 写操作也缓存在交易中. 交易执行并不会修改账本状态, 因此                       Peer 可以并发执行数个交易. 随后,
                 用户比对所有     Peer 返回的执行结果是否相同, 并将结果打包发往排序节点用来生成区块.
   238   239   240   241   242   243   244   245   246   247   248