长安链在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 | 拆分出独立模块（ConsistentEngine），TBFT可以不依赖新模块（理想情况）独立运行，如果出现网络问题（如丢包），会出现共识过程卡住的问题。 |
| 2 | ConsistentEngine辅助同步TBFT共识状态，避免出现共识过程卡住的问题。 |
| 3 | 监测其他节点状态，如果状态落后，推送新状态； 自己状态落后不做处理（等其他节点推送新状态）。 |
| 4 | ConsistentEngine可用于辅助同步MaxBFT共识状态。 |
| 5 | ConsistentEngine支持注册、回调的方式与tbft模块交互。 |
表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%，具体信息如下：
| PeerState方案 | ConsistentEngine方案 | |
| 测试方法 | 共识模块测试床 | 共识模块测试床 |
| 环境 | 系统：macOS 12.5.1 处理器：2.6 GHz 6核 Intel Core i7 内存：16 GB | 系统：macOS 12.5.1 处理器：2.6 GHz 6核 Intel Core i7 内存：16 GB |
| 存储 | 不启用 | 不启用 |
| 网络 | 启用 | 启用 |
| 虚拟机 | 不启用 | 不启用 |
| 验证 | 不启用 | 不启用 |
| WAL | 不启用 | 不启用 |
| CTPS | 17W | 23W（提升35.3%） |
表2
注：上图性能数据是共识模块独立测试的性能数据，不同于区块链性能数据。
