本系列分上下两篇，对链化未来共识协议进行详细介绍。文章首先介绍了常见共识协议的PoW，PoS，DPoS，从而引出了链化未来基于BFT的随机PoS共识算法（RPoS），随后详细介绍了链化未来共识协议的架构、消息类型、详细流程以及节点状态图等内容。文章最后对链化未来共识协议用到的关键技术进行了总结说明。
2.4.分阶段详解
2.4.1.ba0阶段
提块验证并第一次投票阶段
1. 系统根据随机数合约提供的真随机数，在所有committee中选择主备2个proposer节点负责本轮提块。主、备proposer节点提的块有优先级区分，主节点优先级高。这里之所以选择主备2个节点提块而不是1个，是为了防止被选中的节点出现异常无法发送propose提块消息，从而导致本轮无法正常出块的情况。
2. 2个proposer节点分别发送各自的propose消息广播到全网voter节点，voter节点执行propose消息块中的交易进行验证，并通过消息中的签名对proposer的身份进行验证，验证通过后，voter发送携带自己签名的echo消息（第一次投票）广播到全网。
3. ba0阶段5秒结束后，每个节点统计在此期间收到的第一轮投票情况（echo消息），有以下几种情况：
只有一个propose消息的voter签名数超过2/3委员会成员，则将该propose消息中的块作为候选块，即ba1阶段的投票目标
2个propose消息的voter签名均超过2/3委员会成员，选择优先级高（主proposer节点发出的）的propose消息中的块作为候选块，即ba1阶段的投票目标
没有任何一个propose消息的voter签名超过2/3委员会成员，则在ba1阶段投票产生空块，即本轮出空块。
图2 ba0流程图
2.4.2.ba1阶段
第二次投票确认阶段
1. 每个commiittee成员根据ba0结束阶段的选择，进行2次投票，将带有自己签名的echo消息广播到全网。
2. 5秒结束时，ba1阶段结束，每个节点各自统计收到的第二轮票数，有以下2种情况
对某个块（包括空块）的voter签名票数超过2/3 commiittee成员，则节点以该块作为本轮最终确认块上链并更新世界状态。
未有任何块的voter签名票数超过2/3 commiittee成员，系统未能10秒正常出块，进入bax轮次。
图3 ba1流程图
2.4.3.bax阶段
各种异常情况会导致共识系统进入bax阶段，例如超过1/3commiittee成员故障、网络不可达等。
1. 节点以5秒为一个轮次重复ba1阶段的操作，每隔5秒发送一次echo消息，进行投票，投票不允许变更。
2. 每个5秒轮次结束统计voter票数，如果有对某个块的voter签名票数超过2/3 commiittee成员，则结束bax阶段，节点以该块作为本轮确认块上链并更新世界状态。
3. 在投票间隙，本节点询问周围邻居节点，是否已经有比本节点的更高的块。如果有邻居节点比本节点块高，认为本节点已经落后于整个共识网络，放弃共识，启动块同步流程，通过拉块结束bax阶段，进入下一轮共识。如果没有邻居节点比本节点块高，则只能通过持续共识结束bax阶段。
4. 当总轮次达到20轮后，节点仍然无法结束bax阶段，则认为commiittee所有成员在ba1阶段的投票是分裂的（典型情况是一半支持主proposer节点，另一半支持备proposer节点），即按照当前投票情况永远无法达成2/3共识，则所有节点不论在ba1阶段投的是什么票，从第21轮次开始，统一投空块票，本轮只能出空块。
图4 bax流程图
如上几个阶段和步骤，可确保只要有超过2/3 commiittee委员会成员在线且通讯可达，系统总能持续出块。
2.5.节点状态介绍
共识节点有5种状态：
Init 节点处于创世前的初始态
ba0 节点处于共识ba0阶段
ba1 节点处于共识ba1阶段
bax 节点处于共识bax阶段
sync 节点处于块同步状态
图5 节点状态迁移图
状态迁移路径
1. 创世后启动共识，init—>ba0
2. ba0 5秒结束，ba0—>ba1
3. ba1 5秒结束，有超过2/3 commiittee成员达成一致，正常出块后进入下一块共识，ba1—>ba0
4. ba1 5秒结束，commiittee成员未达成一致，ba1—>bax
5. bax 5秒结束，commiittee成员达成一致，bax—>ba0
6. bax 5秒结束，commiittee成员未达成一致，节点继续停留在bax阶段，轮次++
7. bax 5秒结束，commiittee成员未达成一致，有邻居可以提供块同步服务 bax—>sync
8. 同步完成后，再次进入共识，sync—>ba0
2.6.链化未来共识协议关键技术
2.6.1.块同步
当有新节点想要加入共识网络，或有节点因故障（重启、网络不可达等）一段时间内无法正常出块，本节点的最高块已经比整个网络的最高块落后很多，此时进入块同步流程。目的是让新节点或者故障节点通过从邻居节点拉块，快速追平当前最新块高，尽早加入到共识体系中。
以节点A为例简述流
1. A加入网络后，启动定时器timer1，向所有邻居节点询问最新块高，等待回复
2. 邻居节点通过身份认证后，向节点A返回各自当前最新块高
3. timer1超时后，A统计周边邻居的最新块高，并从中选择拉块源，有以下几种情况：
无邻居响应，重置定时器timer1，返回步骤1继续尝试
有邻居响应，最新块高均小于等于本节点块高，结束快同步流程，启动共识
有邻居响应，且多个节点的最新块高大于本节点块高，则选择块高最高的节点作为拉块源节点，进入步骤4
4. 启动定时器timer2，发消息给源节点请求同步本机当前块至最新块
5. 源节点按照顺序发送块给节点A，直至最高块
6. 如果在传输过程中消息中断，且中断时间超过定时器timer2，则本次块同步流程结束，本次同步到已经确认的块不用回退，返回步骤1继续尝试块同步。
2.6.2.时序同步机制
在现网运行环境中，各节点性能参差不齐，运行一段时间后，性能差的慢速节点会逐渐落后，当时间累积，出现慢速节点落后快速节点一个轮次甚至更多时，整网节点的同步性会逐步裂化。
当落后的节点越来越多，超过1/3commiittee成员时，保持同步并能参与共识的节点不足2/3 commiittee成员，无法达到共识的投票门槛，整个网络会被迫全部进入bax阶段，等待慢速节点追赶。当有足够多的节点追赶上后，参与共识的节点又会超过2/3 commiittee，整个网络会恢复并继续正常出块。
当然在现实环境中，我们并不希望上述整个网络进入bax等待的情况出现，出块效率和用户使用。链化未来共识采用同步机制，避免上述极端情况发生，使整个网络的节点能够自治的趋于轮次同步。
慢速节点通过缓存比自己当前轮次高的消息，当慢速节点落后整网节点时，这个机制非常有用。当节点检测到已经落后，并且缓存中收集到的下个轮次的消息超过2/3 commiittee成员（确保安全），则节点可以快速结束本轮次进入下一轮，而不必等待本轮5秒的固定结束时间。
这个机制可以使得网络中那些慢速节点，追赶至少一个轮次（5s）的落后。链化未来最多可以缓存200个轮次的消息，使得理论上可以在一个轮次中追赶上100个块高的差距。
通过上述机制，可以有效避免整个网络无法正常出块的情况。
2.6.3.聚合签名
对于轻客户端，PoW通过nonce值计算hash验证块的正确性，而链化未来是基于BFT的共识算法，需要2/3Voter的Echo消息确认块。
聚合签名能够把这些Voter的Echo消息的签名聚合成一个最终的签名，大小只有原来的1/100。减少主侧链互投的网络带宽。假设节点的BLS私钥sk[i],公钥pk[i],对相同的摘要h(m)进行签名，sk[i] + h(m) => sign[i], 通过聚合签名算法生成最后的签名sign[1] + sign[2] + ... + sign[n] => signX，对聚合签名的验证，(pk[1], pk[2], ... pk[n]) + signX => true/false。所以，聚合签名的块头里面只需要保存参加聚合的账号和signX。在100个委员会成员的情况下，内存只需要原来的1/100。
链化未来对聚合签名的使用如下：
1. 节点在N块时，收到足够的Echo消息，并生成第N块
2. 进入N+1块共识，如果节点被选成proposer，那么它对第N块时的Echo进行聚合，并把聚合后的信息放到N+1的块头扩展字段，那么在轻客户端在收到N+1块之后就可以通过验证聚合签名确认第N块的真实性。
2.6.4.随机数
区块链中的随机数，不仅运用在开发DAPP的智能合约中，还运用在PoS共识协议的角色抽签，直接涉及到DAPP和区块链网络的安全，挖矿的公平性。目前链上随机数获取主要有3种：
1. 通过链上信息，如块hash。
2. 通过Oracle去获取中心化的真随机数。
3. 分布式的随机数协议，如RANDOM。
但是，这些协议那么存在可预测，中心化或串谋操控的问题。基于目前现实，我们采用VRF(可验证随机函数)，双层随机数架构，并用经济手段鼓励用户参与，设计了一种新的随机数生成器。流程如下：
1. 矿工通过抵押代币成为main角色，普通用户通过抵押代币成为waiter角色
2. 在一个投票周期中，main和waiter通过计算vrf值分别投到随机数合约中main和waiter pool，投票周期是重叠的也就是流水线投票
3. 合约根据权重用main和waiter pool中vrf随机数生成最终的随机数，投票者可以获得奖励，而不投票这将被扣除一定数量的抵押代币。
链化未来随机数方案的优点:
有效解决“成员拒绝提交”，“setup过程复杂”，“成员串谋操纵”等多种困扰随机数生成的问题。
解决了proposer数量不确定导致的网络风暴问题，极大的增强了共识的安全性，公平性和性能。
2.6.5.共识安全
在无需认证即可加入(permissionless)的网络中，很难只用技术手段做到网络的安全。链化未来通讯层在节点接入时要做身份认证，只有符合认证规则的节点可以接入网络。
在区块链的世界，通过经济激励机制，对诚实节点进行激励，对作恶节点进行处罚，保证网络中大多数节点是诚实节点，维护网络的安全。
基于BFT的RPOS算法，通过投票机制来确认块，并不消耗算力，对于作恶节点需要被显示的踢出committee，甚至要扣除挖矿押金。
若干典型攻击的防护策略：
1. 长程攻击：
链化未来共识把BLS签名固化到块头，攻击者无法伪造一条链。
2. 贿赂攻击：
链的委员会是变化的，攻击者可以贿赂已经退出委员会的节点，然后伪造一条链。通过在配置文件中固化块hash发现贿赂攻击。
3. 离线攻击：
对于长时间不出块的节点，我们假定已经离线了，因为会影响网络的安全，所以被踢出委员会。
4. DDoS攻击：
系统检测到被DDOS攻击后，不传播DDOS消息，确保只影响单节点而不会影响整个网络。
3.参考文献
[1] L. Lamport, R. Shostak, and M. Pease. The Byzantine Generals Problem. ACM Transactions on Programming Languages andvSystems, 4(3), 1982
[2] Miguel Castro and Barbara Liskov. Practical Byzantine Fault Tolerance. http://pmg.csail.mit.edu/papers/osdi99.pdf，1999
[3] Bitcoin: A Peer-to-Peer Electronic Cash System(2008). URL https://bitcoin.org/ bitcoin.pdf.
[4] https://www.chainnews.com/articles/637745801429.htm
[5] Ethereum, https://github.com/ethereum/
[6] https://en.bitcoin.it/wiki/ASIC
[7] https://www.theverge.com/2019/7/4/20682109/bitcoin-energy-consumption-annual-calculation-cambridge-index-cbeci-country-comparison
[8] https://www.buybitcoinworldwide.com/mining/pools/
[9] Kwon, J. Tendermint: Consensus without mining (2014). URL https://tendermint.com/static/ docs/tendermint.pdf
[10]Chen,J.&Micali,S.ALGORAND:theefficientanddemocraticledger.CoRRabs/1607.01341(2016). URL http://arxiv.org/abs/1607.01341.
[11] Vitalik Buterin and Virgil Griffith. Casper the friendly finality gadget. CoRR, abs/1710.09437, 2017.
[12] Andrew Miller, Yu Xia, Kyle Croman, etc. The honey badger of BFT protocols. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24-28, 2016, pages 31–42, 2016.
•[13] Introducing dfinity crypto techniques (2017). URL https://dfinity.org/static/dfinity-consensus-0325c35128c72b42df7dd30c22c41208.pdf
•[14] https://docs.bitshares.org/en/master/technology/dpos.html
[15] https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md
[16] https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work
[17] https://thenextweb.com/hardfork/2018/11/01/eos-blockchain-benchmark/
[18] Buterin, V. Minimal slashing conditions (2017). URL https://medium.com/@VitalikButerin/ minimal-slashing-conditions-20f0b500fc6c.