HotStuff共识算法总结
接上一篇HotStuff共识协议详解，继续总结一下HotStuff这个共识算法，上一篇有点太技术了，所以这次总结一下HotStuff的创新点
今年Facebook公布了Libra区块链的计划，Libra中的共识算法是LibraBFT，该算法是基于HotStuff共识算法改进而来的。
我们首先聊一下HotStuff共识算法，该算法总结了PBFT、Tendermint等共识算法的特点，实现了一个既有安全性（safety）、活性(liveness)，又有响应性(responsiveness)的共识算法。
为了更好的理解HotStuff的创新点，我们先简要回顾一下PBFT和Tendermint的短板。
PBFT是最早的可以实用的拜占庭容错共识算法，该算法最大的短板是ViewChange时的消息复杂性，每当需要在共识节点中切换Leader时，都需要大量的消息O(n^3)，这是很复杂的。
Tendermint是17年提出的共识算法，该算法采用了锁定、解锁机制，简化了Leader切换过程。但是该算法却损失了响应性，在该算法中即使某个节点集齐了各个共识节点的投票消息，依然需要等待一段时间，以保证大多数节点都能集齐消息。这会带来什么影响呢？在网络情况很好的时候，依然需要等待固定时间，才能出块。比如说，在目前的Cosmos主网中，出块间隔相当稳定，大约是6秒左右。
如何才能让区块的确认只与网络的实际延迟有关呢，也就是说网络状况好的时候，区块更快确认；网络状态差的时候，可以多等点时间确认。这样的特性就是所谓的响应性，Responsiveness。
HotStuff给出了这样一个算法，Leader切换只需要线性复杂度，同时保证了响应性。那么它是怎么做到的呢？
首先，HotStuff引入了门限签名，每一轮的共识投票消息，都是各个共识节点发送给Leader节点，由Leader将这些消息签名组合成一个，再广播给大家。这样极大的较少了系统中消息量，从O(n^2)减到了O(n)。
然后，相比于PBFT和Tendermint的两轮投票，HotStuff采用了三轮投票，多了一轮投票，各个节点集齐投票就可以进入下一个共识，而不需要等待固定的时间。
除了响应性，HotStuff还采用了链式确认，我们认可一个区块，实际上也是对于该区块父区块的认可。在链式的HotStuff中，可以将区块的确认放在下一个区块中，只要一个区块后面产生了三个连续区块，那么就说明该区块经过了三轮投票确认，就可以最终敲定了。
还有一个比较大的创新是，HotStuff提出了安全性和活性的解耦，安全性和活性可以分开独立的设计。共识算法的安全性经过严格的数学证明，同时其活性可以更加灵活，可以定制。比如说，一个系统想要采用HotStuff，安全性的部分不用担心，对于活性的部分，比如Leader怎么切换、超时时间如何定义等等可以灵活的留给使用者定义。
总结一下HotStuff的特点:
- 消息复杂度是线性的，O(n)， Leader切换时也是线性的；
- 具备响应性，Responsiveness
- 链式的确认规则，出块更快；
- 安全性规则和活性规则解耦，更加灵活。