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

彭泽顺 等: 面向跨地理区域联盟链的事务处理技术综述                                                       247


                 UTXO  交易. GeoChain  中的客户端首先向每个输入分片发送转账交易, 输入分片共识后得到对应的交易证明并返
                 回给客户端, 客户端可以在任何时间将附带证明的原始输入信息交易发给目标分片. 本质上是将                               UTXO  交易从输
                 入分片移动到输入分片. 其中客户端仅仅用来组合和发起交易, 如果客户端发生崩溃, 与                            Atomix  锁定输入相比,
                 GeoChain  中分片的证明仍然是有效的, 可在客户端恢复后继续使用. 如果某个输入分片发生终止, 则终止跨分片
                 交易, 但客户端仍保存成功的输入分片证明, 并可以在需要时发送给目标分片.
                    公有链系统采用中心化         2PC  会导致高额的跨域通信开销. 协调者在发起             Prepare 和  Commit 时需要进行分片
                 内共识. 同时, 参与分片回复       Prepare 消息时也需要进行分片内共识. 由于公有链中, 每个分片内节点跨地域分布,
                 3  次分片内共识每次会导致        3  次分片内跨地域通信      (以  PBFT  为例), 而  2PC  本身还需要  3  次跨分片跨地域通信.
                 因此, 在最差情况下, 中心化       2PC  会导致  12  次跨地域通信, 显著降低系统性能.
                    因此, 可以将分片部署在数个数据中心             (而不是全部数据中心), 降低跨数据中心通信开销              [20] , 但这会牺牲分片
                 的可用性. 因此, 在分片副本分布范围较广时, 分布式              2PC  通过减少了跨地域通信次数提升性能.
                    分布式   2PC  的典型代表系统为      CAPER [28] 、SharPer [42] 、Qanaat [134] . 如图  12  所示, 分片  A  的主节点在收到交
                 易后将交易广播到所有相关分片, 分片             B  的主节点在上一轮共识完成后在分片内广播交易开始共识. 随后, 分片
                 A  和  B  的节点进行两次全连接广播通信完成对跨分片交易的提交.

                                            T 1
                                           L 1,1
                                          F 1,2
                                    Shard A
                                          F 1,3
                                                               All to all  All to all
                                          F 1,4
                                                               commu-      commu-
                                                               nication    nication
                                           L 2,1
                                          F 2,2
                                    Shard B
                                          F 2,3
                                          F 2,4
                                                 图 12 分布式两阶段提交协议

                    CAPER [28] 为针对跨应用协作的区块链系统, 由于每个应用仅维护涉及它自己的交易, 并且存在跨多个应用的
                 分布式事务, 因此本文将其分类为分片区块链. CAPER              提出  3  种跨应用的交易处理办法. 1) 采用分布式          2PC  扁平
                 共识协议, 如图    12  所示. 2) 将扁平共识替换为两层共识, 底层即可根据安全模型采用                 BFT  或  CFT  的共识协议, 上
                 层采用类似    PBFT  的  3  次分组间通信达成共识. 3) 使用一组中心化的         Orderers 对所有跨分片交易做中心化排序.
                    SharPer [42] 针对  CFT  和  BFT  模型提出了对应的跨分片共识协议. 1) 在   CFT  模型下, 当主节点收到交易请求后
                 会向涉及交易分片的所有节点广播             Propose 消息, 分片的其他节点接收并验证消息, 如果当前节点正在等待另一
                 个跨分片交易的      Commit 的消息, 节点将当前消息存入缓存, 否则节点会向主节点发送                 Accept 消息. 由于只存在崩
                 溃故障情况, 因此当主节点收到每个分片的              f +1  个消息并验证后, 将所有涉及交易的分片广播带有签名的               Commit
                 消息. 2) 在  BFT  模型下, Propose 与  CFT  环境下类似, 由于存在主节点潜在的恶意行为, 所以          Accept 和  Commit 过
                 程需要涉及交易分片的所有节点间相互通信                Accept 消息和  Commit 消息. 如图  12  所示, 每个节点需要收到     2f +1
                 个消息并验证后才能提交交易.
                    Qanaat [134] 针对多企业多分片的情况, 在跨分片交易情景下           [134] 同时支持企业内 (跨分片) 和跨企业 (同分片内
                 不同副本) 的中心化      2PC  和分布式  2PC  协议. 例如, 当只有企业    e 1 拥有分片  A  和  B  的副本时, 跨分片  A  和  B  的交
                 易可以按照图     11  的中心化  2PC  或分布式   2PC  执行; 但是当企业   e 1 和  e 2 均拥有分片  A  和  B  的副本时, 对于中心
                 化  2PC  协议, 同一分片内仅有一个副本 (例如企业          e 1 分片  A) 负责决策, 其他副本 (例如企业      e 2 分片  A) 仅负责接
                 收并执行决策后的消息; 分布式          2PC  协议则将企业    e 1 和  e 2 的同分片内所有副本 (例如企业      e 1 和企业  e 2 分片  A
                 的所有副本) 看作一组, 由其中一个分片内的             leader 节点负责协调.
                  3.1.2    其他跨分片提交协议
                    当分片部署在不同的数据中心上时, 2PC            等提交协议会产生数次跨域通信, 影响系统性能 (见第                 3.1.1  节). 为
   245   246   247   248   249   250   251   252   253   254   255