长安链共识模块优化中的“精益求精”

长安链在v2.3.0版本中对共识模块进行了优化，主要包括优化TBFT消息机制并将异步发送信息功能进行了拆分，独立设计了一致性引擎模块。优化后共识模块整体逻辑更清晰、共识更高效。

TBFT消息机制优化背景

在长安链的V2.3.0版本的TBFT共识算法中，我们对TBFT共识算法进行了重构，主要是增加了对TBFT消息的缓存。在V2.3.0之前的版本，当一个TBFT节点收到来自某个节点的消息(主要是proposal提案消息、prevote预投票消息、precommit投票消息)，但是如果这个共识消息的高度比当前节点的状态要高，TBFT会判断当前的共识高度和共识消息的高度不匹配，就会丢弃掉该消息。这么可能导致的后果就是，在节点未来达成这个消息的高度的时候，它需要该共识消息，而由于之前已经丢弃掉了该共识消息，因此它还需要等待其他节点再次把该共识消息重新发送过来，导致占用不必要的网络通信。

具体实现

在长安链在V.2.3.0版本中，TBFT共识增加了一个MsgCache，用来缓存未来的共识消息，目前TBFT是缓存未来10个高度的TBFT消息。当TBFT节点收到来自某个节点的共识消息，判断共识消息的高度是否大于当前共识状态的高度，如果是未来10个高度以内的共识消息，则会放入到MsgCache中。当TBFT共识进入到新的高度的时候，会从MsgCache内获取当前共识高度缓存的proposal和投票(包括prevote投票、precommit投票），然后将提案和投票放入到TBFT共识的消息管道内，以便TBFT共识能够快速获取到当前共识状态所需要的消息。同时在每个新的高度，TBFT会更新MsgCache内的共识高度，每10个高度，会清理一次MsgCache内比当前共识高度低的不再需要的共识消息。

流程图如下：

点击放大查看图片

实现方法如下：

// ConsensusFutureMsgCache 缓存未来的共识消息
type ConsensusFutureMsgCache struct{
logger protocol.Logger
sync.Mutex
size uint64
consensusHeight uint64
cache map[uint64]*ConsensusFutureMsg
}

// updateConsensusHeight 更新共识高度，删除不再需要的共识消息
func(cfc *ConsensusFutureMsgCache)updateConsensusHeight(height uint64);

// addFutureProposal 添加未来的提案到cache
func(cfc *ConsensusFutureMsgCache)addFutureProposal(logger protocol.Logger, validators *validatorSet,
proposal *tbftpb.Proposal);

// addFutureVote 添加未来的投票到cache
func(cfc *ConsensusFutureMsgCache)addFutureVote(logger protocol.Logger, validators *validatorSet,
vote *tbftpb.Vote);

// getConsensusFutureProposal 从cache获取提案
func(cfc *ConsensusFutureMsgCache)getConsensusFutureProposal(height uint64, round int32)*tbftpb.Proposal;

// getConsensusFutureProposal 从cache获取投票
func(cfc *ConsensusFutureMsgCache)getConsensusFutureVote(height uint64, round int32)*roundVoteSet;
 

一致性引擎方案设计及其成效

长安链PeerState模块异步发送共识过程中投票信息，并在其他节点未能成功收到投票造成状态落后时，异步补发投票信息。

我们将异步发送信息功能进行拆分，独立设计一致性引擎模块。共识流程中会直接发送提案/投票等信息，当接收方出现状态落后时，一致性引擎用于补发状态。优化后，逻辑更清晰，并且通过主流程直接发送和消息类型拆分的方式，极大的提高了共识性能。

需求描述

表1

模块关系图

点击放大查看图片

如上图所示，TBFT和ConsistentEngine均为独立模块，两个模块共用相同内存空间存储自身状态。ConsistentEngine中会存储其他节点状态，通过定时器方式，触发状态检测，当发现其他节点状态落后时，发送所需下一状态，推动其他节点状态更新，保证共识正常。

流程图

Tbft-ConsistentEngine 交互流程

点击放大查看图片

如上图所示，一致性引擎的启动随TBFT一起启动，启动时会初始化并完成注册，初始化远端节点信息，开启广播。关闭时，在TBFT关闭前，先关闭全部广播器，然后关闭TBFT共识服务。运行过程中，共识进入新的高度，读取链配置，如果有验证者变更，则触发一致性引擎远端信息的更新。

ConsistentEngine 流程

点击放大查看图片

发送端：运行后会为每个广播器创建定时器（当前仅使用TBFT状态广播器），当定时器到达定时时间（默认500ms），遍历所有远端节点共识状态，通过PreBroadcaster接口返回待发送消息，通过msgBus将待发送消息发送给接收方。全部消息发送后，重置定时器，等待下一轮消息同步。

接收端：收到消息后，遍历消息解析器（当前仅使用TBFT状态解析器），解析消息后，将节点信息进行更新。

接口设计

// ConsistentEngine 一致性引擎，用于节点间（共识状态）信息同步
type ConsistentEngine interface{

// Start 启动一致性引擎
// ctx 后续扩展用，启动失败返回error
Start(ctx context.Context)error

// Stop 停止一致性引擎
// ctx 后续扩展用，，停止失败返回error
Stop(ctx context.Context)error

// AddBroadcaster 添加状态广播器（如一个tbft状态广播器）
// id 广播器标识，需要保证唯一性
// broadcast 广播器，需要用户自己实现（如：tbft广播器、maxbft广播器）
AddBroadcaster(id string, broadcast StatusBroadcaster)error

// UpdateNodeStatus 更新本地状态
// id 节点标识，需要保证唯一性
// node 需要更新的节点信息（包含节点状态，节点状态可以有多种）
UpdateNodeStatus(id string, node Node)error

// PutRemoter 添加节点
// id 节点标识，需要保证唯一性
// node 需要添加的节点信息（包含节点状态，节点状态可以有多种）
PutRemoter(id string, node Node)error

// RemoveRemoter 删除节点
// id 节点标识，当节点不存在时返回错误消息
RemoveRemoter(id string)error

// RegisterStatusCoder 注册状态解析器
// decoderType 解析器标识，需要保证唯一性
// decoder 需要添加的解析器，由用户实现（如：tbft解析器）
RegisterStatusCoder(decoderType int8, decoder Decoder)error

// RegisterStatusInterceptor 注册过滤器
// interceptorType 过滤器标识，需要保证唯一性
// interceptor 需要添加的过滤器，由用户实现（如：tbft过滤器）
RegisterStatusInterceptor(interceptorType int8, interceptor StatusInterceptor)error
}

// StatusBroadcaster 状态广播器
// 由内部定时器触发广播
// 根据LocalNodeStatus和RemoteNodeStatus当前状态，确认是否进行状态广播
type StatusBroadcaster interface{

// ID 广播器标识
ID()string

// TimePattern 状态广播触发模式
// 返回触发间隔
TimePattern()interface{}

// PreBroadcaster 广播器，判断是否要发送消息
// 返回广播器方法
PreBroadcaster() Broadcast

// Start 启动
Start()error

// Stop 停止
Stop()error

// IsRunning 获取运行状态
IsRunning()bool
}

// Decoder 解析器
type Decoder interface{

// MsgType 解析器处理的消息类型
MsgType()int8

// Decode 解析器解析对应类型的消息，返回解析后数据对象
Decode(interface{})interface{}
}

ConsistentEngine方案应用成效

ConsistentEngine方案较PeerState方案在共识模块独立测试中，性能提升35.3%，具体信息如下：

表2

注：上图性能数据是共识模块独立测试的性能数据，不同于区块链性能数据。