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

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

区域用户的写请求均能发往本地节点处理 [58] , 端到端延迟较低. 其次, 多主共识具有读可扩展性. 由于节点副本间
保证了强一致同步, 对任意副本的读请求均能返回最新数据. 最后, 所有节点同时发送不同的交易, 可以同时利用
所有节点的上传带宽, 避免了主从架构的区块复制的单点瓶颈问题.
以 GeoBFT [31] 为代表的大多数多主共识算法使用按轮同步的排序方式协调多个节点 (或分组) 打包的区块. 每
个分组独立收集本地用户的交易, 在打包生成区块后与其他分组交换 (见第 1.1.1 节). 如图 5 所示, 在交换结束后,
每个节点都会拥有所有分组提议的所有区块, 其中每个分组都提议了一条子链. 为了保证所有节点都会以相同的
顺序执行这些区块, 区块执行以轮的方式进行. 在一轮中, 节点必须收到每条子链的下一个区块后才会按照分组
ID 的顺序执行这些区块.

Group 1 b 1 b 4 b 7 b 10
Group 2 b 2 b 5 b 8 b 11
Group 3 b 3 b 6 b 9 b 12
Global order b 1 b 2 b 3 b 4 b 5 b 6 b 7 b 8 b 9
图 5 多主共识算法按轮同步确定全局顺序

NeuChain 使用绝对时间 epoch (约为 20 ms) 划分区块, 节点接收交易后会首先确定当前的 epoch. 在 epoch 结
束后, 所有节点会交换它们收到的交易. 具体来说, 每个节点使用一个 Raft 实例保证广播的原子性. NeuChain 使用
交易 ID 确定性地为同一轮内的交易排序, 交易 ID 使用交易签名和 epoch 号的哈希生成, 确保任意两个交易均有
不同的 ID. 在执行时, NeuChain 采用了 Aria [68] 确定性并发控制算法, 节点在收到属于当前 epoch 的一批交易后即
可立即执行, 无需像 GeoBFT 一样需要按照节点 ID 的顺序来按序执行 (见第 2.3 节).
Canopus 和 RCanopus 同样采用了按轮执行的策略, 分组内每个节点在一个 epoch 内均可提议一个交易, 交易
通过 Raft 在分组内进行原子广播, 并按照 LOT 树形拓扑结构进行分组间交换. Canopus 使用 Proposal 号对同一轮
内的区块排序, 每个节点提议的区块都拥有随机 Proposal 号, 当收到一轮内所有的区块后, 可以根据 Proposal 号对
日志进行确定性排序.
按轮同步简单易于实现, 但是当某些节点因为拜占庭等原因发送区块的速率较慢, 此时节点需要等待直到收
到这些缓慢的节点的区块后才能开始执行, 极大地影响了系统性能. Density [69] 缓解了缓慢者会影响系统吞吐率的
问题. 因为按轮同步的排序规则假设了各个组复制日志的速率相同, 多主共识更容易受到拜占庭节点的影响, 由于
要求所有副本均保证同步, 任意拜占庭节点均可以通过在共识前插入一定的延迟拖慢共识 [69] , 增加同步开销来降
低系统性能. 若拜占庭节点以较慢速率复制日志会导致该轮不能按时结束, 进而阻塞排序. 因此, Density 将区块复
制和排序解耦, 选出一个全局的节点 (O-instance) 负责为区块排序, 此时虽然节点间区块复制实例 (D-instance) 的
速率不同, 但由于区块的执行顺序是由该全局节点收到这些区块的顺序决定, 复制缓慢的区块会被放在后面执行,
而不会阻塞已经完成复制的区块.
表 3 总结了多主共识算法和系统. 多主共识协议与分层共识协议和容错机制正交, 这是因为大多数多主共识
仅仅使用现有主从共识协议作为模块, 多个主从共识协议同时提出区块, 并使用一个确定性规则确定不同共识协
议提议的区块间的全局顺序.

表 3 多主共识算法和系统

系统 年份 是否为分层共识 容错 全局排序
GeoBFT [31] 2020 两层共识 BFT 按轮同步
NeuChain [38] 2022 非分层 BFT 按轮同步
Canopus [58] 2017 树形共识 CFT 按轮同步
RCanopus [59] 2018 树形共识 BFT 按轮同步
Density [69] 2022 非分层 BFT 动态确定