接口说明
TBFT 实现了长安链的ConsensusEngine接口。
Start 方法用来初始化TBFT内部状态及启动TBFT实例。
Stop 方法用来停止TBFT实例。
type ConsensusEngine interface {
// Init starts the consensus engine.
Start() error
// Stop stops the consensus engine.
Stop() error
}
6.4.5. 数据结构
// TBFTMsgType defines different type message in tbft
enum TBFTMsgType {
propose = 0;
prevote = 1;
precommit = 2;
state = 3;
}
message TBFTMsg {
TBFTMsgType type = 1;
bytes msg = 2;
}
// Proposal defined a consesensus proposal which can
// be gossiped to other node and can be serilized
// for persistent store.
message Proposal {
string voter = 1;
int64 height = 2;
int32 round = 3;
int32 pol_round = 4;
Block block = 5;
EndorsementEntry endorsement = 6;
}
// VoteType represents the type of vote
enum VoteType {
VotePrevote = 0;
VotePrecommit = 1;
}
// Vote represents a tbft vote
message Vote {
VoteType type = 1;
string voter = 2;
int64 height = 3;
int32 round = 4;
bytes hash = 5;
EndorsementEntry endorsement = 6;
}
// Step represents the step in a round
enum Step {
NewHeight = 0;
NewRound = 1;
Propose = 2;
Prevote = 3;
PrevoteWait = 4;
Precommit = 5;
PrecommitWait = 6;
Commit = 7;
}
6.4.6. 配置参数
TBFT 可以通过在配置块中的ext_config字段配置相关参数：
“TBFT_propose_timeout”: 提案的超时时间，如10s, 1m；
“TBFT_propose_delta_timeout”: 每轮提案超时增加的时间，如10s, 1m；
“TBFT_blocks_per_proposer”: 每个节点连续出块数，如 "3"。
6.5. Maxbft
consensus-maxbft模块实现了hotstuff流水线共识，是一种优化后的三阶段BFT算法，当拜占庭节点数小于共识节点数的1/3时，可以保证系统的安全、高效运行、并提供状态的最终性保证；相较于其它BFT算法在如下方面进行了优化：
优化投票流程，使用星型网络减少网络通信量至O(n)
使用流水线模式简化三阶段共识消息类型：提案消息、投票消息
活性(liveness)规则与安全性(safetyRules)规则解耦
hotstuff是一种基于view的共识算法，每个view又称为level，每次进行view切换时，更新下一个view的proposer、触发新提案的生成，具有如下特性；
共识算法运转过程中，存在两个全局累加的变量：区块高度、共识view，指定的区块高度可能经历多轮共识才达成一致，当节点生成有效区块或当前共识view超时未达成一致，共识view递增但区块高度不变
hotstuff流水线共识算法中，当前共识view提案的投票发送下一个共识view的proposer节点，由下一个view的proposer收集投票信息组成QC，包含在下一个view生成的提案中
hotstuff共识算法为三阶段协议：prepareQC、precommitQC、commitQC
由于每一阶段都是对特定类型的消息收集投票，因此在流水线模式实现中，对投票流程和消息类型进行了优化
prepareQC：当共识节点接收视图为view的提案验证通过后，对view提案进行投票并发送给view+1的Leader，共识view+1的Leader基于view生成新提案时，将视图view投票聚合的QC包含在view+1的提案中，广播给其它共识节点，当其它共识节点收到view+1提案消息验证通过后，则表示网络中（n-f）个共识节点对视图view的提案达成第一轮共识（prepareQC）
precommitQC/lockedQC：视图view提案的precommitQC是由视图view+1提案的prepareQC间接确认的，即view+2的Leader将验证者集合对view+1提案的共识投票作为QC包含在view+2的提案中，其它共识节点收到view+2提案并验证通过时，表示对视图view+1提案的prepareQC阶段达成，对视图view提案的precommitQC阶段达成
commitQC：与precommitQC阶段达成类似，视图view提案的commitQC是通过对视图view+2提案的prepareQC间接达成的；共识节点收到视图view+2的提案、验证通过后进行投票，视图view+3的Leader接收投票聚合为QC、将其包含在view+3生成的提案中，广播给其它共识节点。当其它共识节点收到view+3的提案并验证通过时，表示链上验证集合对视图view提案的commitQC达成，此时会将view的提案提交上链、达成状态最终性
因此在上述三阶段中，网络中的共识消息类型被简化为2种：提案消息ProposalData，投票消息VoteData；且将precommitQC、commitQC阶段通过下一个视图的prepareQC阶段间接达成，减少了共识的交互流程
因此hotstuff流水线共识中，节点最少会缓存三个视图(view、view+1、view+2)的待提交提案信息，直至接受视图view+3提案时，将view的提案进行提交、并标识视图view+3的提案为待提交.
Maxbft 当前仅支持共识节点数 >= 4的场景，1）当创世节点数小于4时，节点无法成功启动；2）当链上共识节点数量动态减少时，导致链上节点数小于4的交易，执行失败
