A Survey of Blockchain Consensus Algorithms: Mechanism, Design and Applications (Science China Information Science ’20)
前两段介绍区块链背景和共识算法背景，没有太多新东西。
提出了一种区块链共识算法流程模型，通过确定模型的流程阶段并了解核心，可以用该模型分析不同的区块链共识算法。
分为三个过程，会计选举，区块添加和交易确认。
会计选举有三种，使用PoW等可验证随机函数VRF在每个回合中选择一个会计；按照预订顺序每轮选择一个会计（随机函数同种子）；每个节点都是会计，一个节点只负责自己的交易，主要出现在DAG中。
第二个阶段是块添加。对块进行验证，如果会计和块都是有效的则添加区块。这个阶段中输入是当前区块链和新区块，输出新区块链。
第三个阶段是交易确认。在前两个阶段之后，每个节点从自己的角度来看都是一个区块链的本地副本。交易确认根据每个节点所观测到的区块链（也就是自己所有的副本）来进行区块链交易的确认。存在两种可能的情况：
（1）块添加阶段需要大多数节点的实时投票。（例如PBFT）在这种情况下，每个区块在添加到区块链之前都得到了大多数节点的实时投票，所有交易会直接被确认。
（2）区块在验证后将块添加到区块链，不需要来自大多数节点的实时投票。在这种情况下由于网络延迟等原因，不同的节点可能有不同的区块链数据。所以区块链上的区块不意味着已经被确认。交易的确认取决于区块链的数据结构，最显著的比特币，要六个区块后才确认一个区块。
随后介绍了区块链共识算法的分类。首先是基于领导者的模式，包括PoW，PoS等算法。还包括Bitcoin-NG和conflux等后续的算法。还有其他的基于领导者的共识算法，比如运气证明，燃烧证明等。运气证明使用了TEE可信环境，燃烧证明中矿工将硬币发送到不花费的地址嘞燃烧硬币，燃烧最大数量硬币的矿工被选为负责人。
第二是基于投票的模式。传统的Paxos和Raft，以及PBFT。在区块添加阶段，区块需要经过以下三个阶段才能被添加到区块链中。第一个预备阶段，会计向其他节点发送一个块以共他们验证。第二个准备阶段，每个副本将验证结果发送给所有其他节点，然后所有结点根据每个副本发送的消息重新确认这个块。第三个阶段，每个节点再次将准备阶段的验证结果发送给所有其他节点，每个节点根据收到的消息对块进行最终确认。
可以关注一下Hotstuff和MirBFT算法。HoneyBadgerBFT的核心是二值共识，也可以关注一下。
第三种是基于委员会+投票的方式。比如DBFT,PoPT和algorand。在DBFT中有两种类型的节点，记账和普通节点。普通节点根据所持有估分的比例投票选择会计节点。委员会由会计节点组成。会计节点中的共识类似PBFT.委员会+投票模式的核心思想是缩小参加共识的节点范围，从而降低通讯复杂度。
第四种是公平会计模式，在会计选择阶段，每个节点都是会计。这意味着一个节点只打包自己生成的交易。在块添加阶段，总存在连接规则让块选择父块。一个块始终有多个父块。最后在交易确认阶段根据交易者的位置，使用复杂的规则来确定某个块是否已经达成共识。
Tangle中由于网络延迟，节点不可能拥有所有tips，意味着通常很难获得完整的确认。因此使用了需要一定比例进行的部分确认。Byteball和IOTA在添加阶段类似，区别是来自生成器的所有历史交易均应通过新交易进行验证。Byteball中存在见证人，维护权掌握在见证人手中。Hashgraph中交易确认的规则很复杂，本质是在确认事件之前必须由所有节点的三分之二以上对其进行多次验证。
不同共识算法比较：
不同共识算法的比较。
共识算法设计的安全性原则。在这一部分主要介绍了DoS，Sybil，Eclipse和自私挖矿攻击等等。共识算法在安全性上通常要在三个维度的不同方向进行权衡。设计共识算法时应该遵循以下两个原则：第一，攻击者无法预测哪个节点是记账节点。二，设计一种高效的机制来处理记账节点的故障。
最后作者给出了共识算法选择的建议：
不同的应用场景需要不同类型的区块链。例如，公共区块链更适合开放环境，而财团区块链更适合企业合作。 在分析了最常见的区块链应用场景之后，我们将它们分为五类，它们具有不同的节点大小，交易频率和区块链类型。表4提供了为这些应用类别中的每一个选择共识算法的建议。
- 当应用场景是少数公司之间的合作时，可以使用区块链记录其中的业务交易。节点总数通常少于20个，因此不需要区块链的高可伸缩性。 而且，没有轻型节点，交易数量也不是很多。同时，由于少量的完整节点，可以轻松实现系统的同步要求。因此，在这种情况下，基于PBFT或基于哈希图的共识算法可能是不错的选择。
- 当多个公司合作为客户提供服务时，通常使用区块链记录客户与公司之间的业务交易。在这种情况下，有许多受客户控制的轻型节点，而完整节点的总数仍少于20个。因此，区块链的可扩展性要求低，并且系统的同步易于实现。然而，可能存在大量交易，从而导致对高交易吞吐量和低确认延迟的需求。 在这种情况下，建议使用基于PBFT的和Byteball共识算法。 使用Byteball时，公司始终扮演见证人的角色。
- 当数十家企业合作并为其客户提供服务时，这些企业控制的完整区块链节点总数通常会超过20个，而少于100个，此外还有代表客户的大量轻量节点。 例如，在Jointcloud计算[59]中，有许多云服务提供商和客户。 在这种情况下，要确保这么多完整节点的同步并不是很容易。因此，PBFT算法不合适。但是，哈希图-。在这种情况下，基于Hashgraph的通信模型是基于八卦协议的，而该协议不需要系统同步，因此，基于共识的共识算法将是这种情况下的合适选择。也可以使用基于委员会+投票模式的共识算法，例如PoPT和Algorand。委员会成员人数不得超过20；否则，由于投票阶段所需的高网络开销，吞吐量可能会降低。
- 当区块链用于物联网设备之间的信息共享和设备协作或类似于[60]中所述的场景时，完整节点的数量不是固定的。 基于委员会+投票模式的共识算法仍然有用。此外，如果不需要高吞吐量，也可以使用基于PoS的共识算法。
- 对于部署最广泛的加密货币应用程序，例如比特币，Peercoin和[61]中提出的数字货币，完整节点的总数是巨大的，节点动态变化。这些应用程序中部署的公共区块链是去中心化的。为了确保公共区块链的安全性，不可避免地会牺牲其有效性。在这种情况下，基于PoW或PoS的共识算法是更好的选择。此外，不建议使用基于委员会+投票模式的算法，因为每个节点的身份都隐藏在公共区块链中。此外，在委员会成员不诚实的情况下处理案件也是具有挑战性的。
这篇文章的主要贡献是提出了一种通用的共识算法过程模型，然后针对模型中不同的几个阶段对区块链进行了分类。文中还介绍了DAG区块链。最后给出了选择共识算法的建议。提出TEE已经被更多人关注。
