共识算法
基础概念
门限签名(Threshold signatures): 一个(k, n)门限签名方案指由n个成员组成的签名群体，所有成员共同拥有一个公共密钥，每个成员拥有各自的私钥。只要收集到k个成员的签名，且生成一个完整的签名，该签名可以通过公钥进行验证。
证书(Quorum Certificate，QC): 主节点收到至少quorum个节点对同一个提案的投票消息(代签名)后，利用门限签名将其合成一个QC，这个QC可以理解为门限签名生成的完整签名，表示对该次提案达成一次共识
视图(View): 视图是共识的基本单元，一个视图最多达成一次共识，并且单调递增，每个视图逐渐轮换推进共识。
共识状态树: 每个共识区块可以看作是一个树节点，每个树节点内包含对应的提案内容(前文的操作指令)和相对应的QC，每个树节点包含一个父亲树节点的hash，形成一棵树状结构，主节点基于本地最长的分支生成新的树节点。落后节点根据其他节点的最长分支上的最新树节点来同步中间缺失的树节点。
HotStuff共识流程
HotStuff的核心围绕着三轮共识投票展开，原文提出了三种形式：简易版HotStuff，链状HotStuff，事件驱动的HotStuff。
简易版HotStuff
Basic HotStuff是共识的基本过程。视图跟随着共识的达成不断地单调递增。每个视图都有一个唯一的主节点负提案，收集和转发消息并生成QC。整个过程包含四个阶段：准备阶段(PREPARE)，预提交阶段(PRE-COMMIT)，提交阶段(COMMIT)，决定阶段(DECIDE)。主节点提交(达成共识)某个分支，在PERREPARE，PRE-COMMIT，COMMIT三个阶段收集quorum个共识节点带签名的投票消息，利用门限签名合成一个QC，然后广播给其他节点
HotStuff结合门限签名可以将之前互相广播共识消息的方式，转为由主节点处理，合并以及转发。通信的复杂度可以降到O(n)。这种通信方式很像是Raft里面的通信方式，但Raft是建立在主节点一定可靠的基础上的。
对比PBFT算法，共识开启于主节点将请求附带在pre-prepare中发送给其他节点，主节点即履行完了概论共识的职责，接下来和其它节点一样。整个共识过程包括一个广播提案阶段(PRE-PREPARE)，两个共识阶段(PREPARE,COMMIT)。
HotStuff中的四个阶段具备怎样的流程和作用呢？
-
PREPARE阶段：
主节点：
- 根据收到的quorum条NEW-VIEW消息，该消息中包含了发送方的状态树中高度最高的prepareQC，主节点在收到的prepareQC中计算出高度最高的QC，记为highQC
- 根据这个highQC的节点所指向的分支，打包区块创建新的树节点，其父节点为highQC指向的节点。
- 将生成的提案附带在PREPARE消息中发送给其他节点，且当前提案中包含highQC。
从节点：
- 收到该prepare消息之后，对prepare中的消息进行验证，包括qc中的签名是否合法以及是否是当前视图的提案。
- prepare消息中的节点是否扩展自lockedQC的分支（即孩子节点）或者prepare消息中的highQC的视图号大于lockedQC（前者为安全性条件，后者为活性条件保证节点落后时及时同步）
- 生成prepare-vote消息并附带一个签名发送给主节点
-
PRE-COMMIT阶段：
主节点：
- 收到quorum个当前提案的prepare-vote消息时，通过聚合quorum个部分签名得到prepareQC；然后主节点广播pre-commit消息附带聚合得到的prepareQC。
从节点：
- 收到pre-commit消息，验证之后，发送pre-commit vote消息给主节点。
-
COMMIT阶段：
主节点： 与pre-commit阶段类似。
- 主节点先收集quorum个pre-commit vote消息，然后聚合出这一阶段的pre-commitQC，附带在commit消息中发送给其他节点。
- 从节点：收到commit消息时，消息验证通过同样更新本地的lockedQC为commit消息中的pre-commitQC，对齐签名并生成commit vote发送给主节点。
-
DECIDE阶段：
主节点：
- 收集到quorum个commit vote消息是，聚合得到commitQC，并且附带了decide消息中发送给其他节点
- 当其他系欸但收到decide消息时，其中commitQC指向的提案中的交易就会被执行
- 之后增加视图号view number，开启下一轮共识，根据prepareQC构建New-View消息。
从节点：
- 验证消息后，执行decide消息中的commitQC指向的树节点的交易。
NexView interrupt阶段
在共识中任何其他阶段发生了超时事件，发送新视图的new- view消息，都会直接开启下一轮的共识。
三阶段确认
之前的PBFT共识协议中有提到它使用了两段式共识的方式去保障视图切换发生时，节点的状态一致性。但是他有一个很致命的缺点，那就是消息复杂度过高达到了O(n^3)的程度。
