区块链技术逐渐从小众的极客圈子走向规模化商用。
从整体来看，区块链技术的规模化商用还处在相对初期的阶段，企业对区块链技术性能、易用程度的较高需求，与区块链技术本身的可拓展性瓶颈及较低的运行效率构成了当前限制行业发展的主要矛盾。
基于自身大量的商业实践和对区块链商用的探索与创新，布比打造了完全自主知识产权、高性能可扩展、产品化成熟的商用级区块链底层平台BubiChain。
商用级区块链底层平台BubiChain取得底层技术关键突破：应用开发友好的智能合约、安全高效的共识算法、可靠的隐私保护、并行快速的多链，以及可扩展的跨链技术等创新；实现了产品化重要突破：应用可快速构建、可视化运维、技术合规及资金账户体系等，形成完整的产品服务能力。
本文为商用区块链BubiChain详解系列文章的第二篇——安全高效的共识算法，以下为正文内容。
安全高效的共识算法
布比区块链共识算法具备可插拔属性，支持高效的Bubi-BFT（改进创新的拜占庭容错算法）和支撑大规模用户的Validating Pool+BFT等多种共识算法。基于拜占庭容错算法的共识算法Bubi-BFT，是一种不会产生链分叉且强一致性的算法，用户交易可在秒级时间确认。基于Validating Pool+BFT算法，普通用户也可参与投票，并选举产生记账节点，记账节点再通过BFT算法轮流产生区块。
1. 系统模型
布比区块链系统是一种分布式系统，共识算法运行的环境类似于分布式系统的执行环境，要保证共识算法的安全性和可靠性，不可避免的要解决“拜占庭将军”问题。Bubi-BFT是一种拜占庭容错算法，在拜占庭容错系统模型下实现，拥有N个节点的拜占庭容错系统模型可以定义为：
所有诚实的参与者使用相同的输入信息，产生一致的结果。
如果输入的信息正确，那么所有诚实的参与者必须接受这个信息，并计算相应的结果。
在拜占庭容错系统的实际运行过程中，一般假设整个系统中发生故障的服务器不超过f台，并且每个请求还需满足两个指标：
· 安全性(Safety)：任何已经完成的请求不会被更改；
· 活性(Liveness)：可以接受并执行诚实的用户请求，不会被任何因素影响而导致请求不能执行。
系统假设条件包括：
· 节点的行为是任意的；
· 节点错误是不相关的，节点可以安装不同操作系统，部署不同的软件版本；
· 节点之间通过异步网络连接，消息可能丢失、乱序到达、延时到达；
· 节点之间传递的消息，第三方可以知晓，但不能更改、伪造消息的内容或从摘要中计算原始信息。
2. 状态机副本
在布比区块链分布式系统中，实现可容错服务的方法通常是实现一个状态机副本（State Machine Replication）协议，通过复制单机状态下的服务到多个副本节点，并协调多个副本为用户提供统一请求响应，主要包含：
· 一致性协议（Agreement）
· 检查点协议（Checkpoint）
· 视图变更协议（View-change）
Bubi-BFT实现了一个状态机副本协议，正常情况下执行一致性协议，在Leader节点故障或者Leader正常轮换的时候执行视图变更协议。Bubi-BFT中并无Checkpoint机制，因为每轮共识后节点的状态是稳定状态，也没有数据库或存储系统中快速恢复的需求，没有必要再加入专门针对于稳定状的Checkpoint流程。
3. 一致性协议
布比区块链一致性协议的目标是使来自普通用户的请求在每个服务器上都按照一个确定的顺序执行。一致性协议通常至少包含三个阶段：提案阶段（Propose）、确认阶段（Confirm）、提交阶段（Commit）。区别于其他分布式系统中的一致性协议，拜占庭容错算法中加入了二次确认的Commit阶段，确保每个节点操作一致，不会出现只有部分节点提交造成整体不一致的情况。
实现一致性的方法是节点之间通过协议传播自己获得的信息，并根据自己收集的信息判断是否发送确认或者提交信息。系统状态将在三个阶段迁移，节点只需判断收到的消息是否足够就可以自动进入下一个阶段，三个阶段完成代表着共识成功。
区块链系统中的共识一般涉及到四种角色：
· 区块链的使用者即普通用户
· 共识过程中打包区块的Leader节点
· 参与共识过程的Replica节点
· 共识过程中出现故障或作恶的Fault节点。
普通用户提交交易后，这些节点通过三个阶段即Propose、Confirm、Commit会话对交易集合达成一致，如果在共识过程中，Replica节点发现Leader不作为或作恶，则发起视图变更流程选举下一个Leader，当有大多数节点投票选举了下一个Leader，则视图变更成功。假设区块链系统中节点总数为N，那么Bubi-BFT能容忍的Fault节点个数为f=(N-1)/3，大多数节点的个数为N-f=2f+1。
4. 视图变更协议
在布比区块链中，当Leader节点故障的情况下，区块可能并没有在规定的时间内生成，此时需要更换Leader节点以继续共识，更换Leader节点的协议即视图变更协议。视图变更协议与一致性协议执行流程类似，新的Leader按照预定的规则接管提案权，如果存在已经确认好而未提交的提案，将该提案继续执行提交流程（Commit）；否则构造新的提案，在新的视图下执行一致性协议。
在Bubi-BFT中，为避免某个节点长期占有出块权利，除Leader节点故障情况下会执行视图变更协议，正常情况下也会进行视图变更以平均分配打包权利。
Leader故障时的VIEW-CHANGE流程属于故障处理流程，共识将暂时停止，为提高可用性，在正常VIEW-CHANGE流程中加入多个超时重发机制，以提高网络层面的消息传达率。
正常情况下的视图变更不涉及故障，无需执行视图变更的投票和确认流程，只需在区块打包完成时自动增加视图号，进入v+1，Leader角色将会自动轮转到新的共识节点。
5. Quorum机制
