超级账本1.0基于kafka的共识

概述

超级账本1.0的架构，将节点进行了拆分，分为endorser、orderer和committer三类节点，节点各司其职。其中orderer节点负责共识，目前从官方文档看，支持Solo（单节点共识）、kafka（分布式队列）和SBFT（简单拜占庭容错）三种共识方式。本文主要介绍基于kafka实现的共识机制。

设计思路

kafka是一个分布式高可用消息队列，可以有序的管理消息并在多个冗余副本间保证数据一致性。kafka集群的状态由zookeeper管理，选举leader节点。

orderer服务从kafka集群里获取相应topic（kafka的分区，用于在队列里隔离出多个数据域）的数据，以保证交易数据有序，借助了kafka的分布式一致机制。如下图：

这样的设计有一系列的问题需要考虑。

问题1

orderer服务（OSN）为每一笔交易进行验证和出块，效率不高。

改进

kafka里的交易数据按批次出块，减少验证次数，设置batchSize。

问题2

出块是异步且批量的，如果交易到达速度不平均，batchSize可能很久未到达，影响出块时间。

改进

为了降低批次的等待，设置出块的时间batchTimeout，超时或达到批次上限，均会触发出块操作。

问题3

不同的OSN-n的时间很难同步，导致各OSN出块所包含的交易会不一致。

改进

各OSN增加出块协熵消息（TTC-n，TimeToCut），并将该消息上送至kafka，以第一个TTC-n为准出块，后续重复的TTC-n将被忽略，以达到一致。

问题4

OSN根据块高度同步数据，但块高度和kafka的offset没有关联上，无法识别kafka的断点位置。

改进4-a

使用块的metadata域存储offset，如：“offsets:63-64”。

不足1）：与Deliver接口不一致，需要增加块高度参数。

不足2）：OSN丢失了若干块，如果从一个随机块或最新块开始同步，它将无法识别正确的offset。

改进4-b

每个OSN针对每条链都要维护一个检索表，记录了块高度和offset的对应关系，而不需要使用块的metadata数据。

问题5

每个OSN在收到分发请求后，都要从当前的节点进行追数，每个节点都要进行相同的操作，而且该操作的代价比较昂贵。

改进5-a

再创建一个分区，用于记录OSN提交的块，可以冗余且无序。但会引发问题6。

改进5-b

持久化已生成的块数据，每个OSN本地存储一个日志记录。同时解决了问题6。

问题六

kafka中存在冗余的消息；检索表会被请求，分发请求处理逻辑相对复杂，检索表操作会增加等待时间。

改进6-a

如果OSN收到唯一的消息，并且自己即将处理相同的消息，则立刻终止自己的提交操作。这样可以大量减少冗余数据提交，但不能完全消除。

改进6-b

选举一个OSN的leader （ZK或谁产生TTC-x谁是主） ，由它负责分区1上下一个块数据的产生。但是仍然可能出现冗余数据：主节点提交块X后宕掉，此时选举出新的主节点，它判断块X仍未提交，所以将自己的块X提交，此时原主节点的数据也提交至kafka上，出现冗余数据。

改进6-c

kafka记录压缩，用kv结构存储。可以完全消除数据冗余问题，但由于kv数据以最后提交的为准，会导致检索表数据过时。

改进6-d

因为改进5b方案，本地账本解决了冗余块消息的问题。

---

引用

《A Kafka-based Ordering Service for Fabric》 by Kostas Christidis

（季宙栋）Blockchain区块链架构设计之四：Fabric多通道和下一代账本设计

（庄鹏）超级账本Hyperledger Fabric 1.0架构解读