超级账本1.0基于kafka的共识

96
Yin舍予
0.1 2017.02.22 11:47* 字数 1143

概述

超级账本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架构解读

区块链
Web note ad 1