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

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


                 顶层共识. D-Paxos 允许每个分组并发收集并缓存用户交易, 这些组轮流充当全局                     Paxos 的主节点. 当一个分组成
                 为全局主节点时, 该分组将缓存的一批交易使用全局                 Paxos 广播到其他分组. 该方法让用户可以在本地处理交易,
                 而不必跨域将交易发给全局          Paxos 的主节点. C-Raft 采用  Fast Raft [56] 作为顶层和底层的共识协议, Fast Raft 优化
                 了  Raft 的消息传输流程, 可以在没有并发提案的情况下将提交延迟由                  1.5 RTT  缩短到  1 RTT. 在消息丢失或存在
                 并发提案时, Fast Raft 回退到经典    Raft [35] 共识.


                                                                   T 1

                      T 1                                        L 1,1
                    L 1  Local   Prepare        Prepare          F 1,2  Local PBFT            Local
                         PBFT                                                                exchange
                    F 1,1      “Propose”       “Commit”
                        consensus   with         with            F 1,3  consensus on T 1
                    F 1,2
                                 PBFT                            F 1,4
                         on T 1                 PBFT
                    F 1,3                                                           Direct
                                                                   T 2
                            Global Paxos consensus (Omit leader election)          replication
                                                                 L 2,1
                                        Prepare
                    L 2
                    F 2,1               “Accept”                 F 2,2  Local PBFT            Local
                    F 2,2                with                    F 2,3  consensus on T 2     exchange
                                         PBFT
                    F 2,3
                                                                 F 2,4
                          图 1    Steward  的  Paxos 复制流程                   图 2    GeoBFT  共识架构
                  1.1.2    树形共识协议
                    针对网络拓扑大于两层的情况, 树形共识算法可以进一步匹配网络基础设施提升共识性能. 树形共识算法中,
                 分组可以多次聚合形成更大的分组. 区块经过多次分组间的转发到达所有分组. 多次转发的传输方式极大地减轻
                 了发送方分组的带宽压力, 但是由于分组间需要多次跨域通信, 共识的延迟相对较高. 表                          2  给出了树形共识算法和
                 系统对比.

                                                  表 2 树形共识算法和系统

                                  系统       年份     容错模型        底层共识       顶层结构      分组容错
                                     [58]
                                Canopus    2017     CFT      Raft (多主)     LOT        否
                                      [59]
                               RCanopus    2018     BFT    PBFT (分组级别)     LOT        是
                                    [60]
                                 Kauri     2021     BFT       广播网络        多层树         是
                                      [61]
                                ByzCoin    2016     BFT       广播网络        多层树         是
                                      [62]
                               ByzCoinX    2018     BFT       广播网络        两层树         是

                    Canopus  [58] 为  CFT  共识协议, 运行在一个  3  层的网络拓扑结构下. 其假设节点分布在多个数据中心, 一个数据
                 中心内的节点分布在多个机架上. 相同机架内节点间网络优于数据中心内机架间网络, 而数据中心内机架间网络
                 优于数据中心间网络.
                    为了适应这种多层网络拓扑, Canopus 将节点按机架分为               CFT  小组, 将这些小组作为叶子节点构建了一个仅
                 有叶子节点真实存在的树 (leaf-only tree, LOT), 如图    3  所示. 其中,  G 1 、G 2 、G 3 、G 4  为  4  个分组, 每个分组内包含
                 4  个节点, 构成了  LOT  第  1  层的  4  个叶子节点. LOT  的第  2  层将  G 1 、G 2  分为一组,  G 3 、G 4  分为一组, 而第  3  层为
                 LOT  的根节点, 包含所有分组. 对于交易         T 1  而言, 节点  N 1,1  收到交易后先在分组  G 1  内完成  Raft 复制. 随后, 分组
                 G 1  和  G 2  交换交易  T 1 , 确保  T 1  在数据中心内完成复制. 最后, 数据中心间交换  T 1 , 完成全局共识.
                    Canopus 很好地适应了跨域复杂的网络拓扑. 为了减少跨域通信次数和开销, Canopus 同样牺牲了区域容错,
                 仅在分组内使用      Raft 共识, 可以容忍节点宕机. 而分组间采用直接广播交易的方式. 在分组崩溃时, 系统需要等待
                 崩溃分组恢复, 因为其他分组无法确定该分组已经崩溃还是仅由于分组间消息传输缓慢                             (系统运行在部分同步网
                 络模型  [63] 下) 导致的延迟. 总而言之, 分组间需要针对是否等待宕机分组达成一致.
                    RCanopus [59] 为  Canopus 的拜占庭容错版本, 其将位于相同机架的节点分组, 分组内运行              Raft 共识. 而分组间
                 首先使用   PBFT  聚合形成拜占庭分组, 以容忍拜占庭节点. 最后, RCanopus 在这些拜占庭分组上运行                    LOT  传输交
                 易. 值得注意的是, 由于分组使用的         Raft 共识并不能容忍拜占庭错误, 因此当分组内存在拜占庭节点时, 整个分组
                 即被认为是拜占庭分组. 除此之外, 针对           Canopus 不能容忍分组崩溃, RCanopus 在每个拜占庭分组内选出一个主
   232   233   234   235   236   237   238   239   240   241   242