FISCO-BCOS平台共识

FISCO-BCOS 应用于区块链的多节点并行拜占庭容错共识算法

看了下微众平台的wiki共识知识学习下（）内是自己的思考参考： https://github.com/FISCO-BCOS/Wiki/tree/master/

问题与动机：PBFT是一种可用的拜占庭容错算法，但是由于该算法的三个阶段是串行执行，存在共识效率低的问题

提出的算法内容：

区块链节点的角色有两种，分别是“领导节点”和“随从节点”。

领导节点：负责对交易进行打包成块，把块广播给其他节点，通过共识过程对块中所有交易进行确认，从而使得区块链的区块高度不断增加。
随从节点：负责接收从领导节点发送来的区块，对区块中的交易进行确认，所有交易都确认完毕就对该块进行签名验证，从而使共识达成。

（其实这里和主备节点一样）

角色变迁

在本算法中，节点的角色不是固定不变的，随着时间迁移节点角色也会进行变迁。区块链网络由一个个节点组成，假设一共有N个节点，对节点从0,1,2...N-1进行编号，每个节点对应一个唯一的Idx(i)。一个节点的角色判断通过公式 （h+v）%N 来决定，其中h是区块链当前块高度，v是当前视图

（这里关注2点：引入区块高度做考虑，随时间迁移会变）

共识过程

共识过程就是区块链网络对一批交易进行确认，并达到全网一致的过程。共识过程分为以下几个阶段：

选举领导：通过3.2描述的算法推选出一个领导，有别于其他基于投票选举领导的算法，在本专利中是通过共识计算选出合适的领导，这种方式具有更高的效率。
打包验证交易：选举出的领导节点，将会一批交易进行打包验证，组成一个区块，区块的产生也就由领导节点负责。
签名投票：随从节点对领导节点发送来的区块，进行每一笔交易确认验证，全部通过之后发送对该块的一个投票签名。
落盘投票：所有节点在收到2/3以上节点的签名投票之后，广播落盘投票。
落盘提交：所有节点在收到2/3以上节点额落盘投票之后，把该块进行落盘存储。

（看到这里其实和PBFT没有差别，流程没有改变）

异常处理机制

在3.3的描述的共识过程几个阶段，每个阶段都有可能因为出现错误、超时或者故意作恶等各种原因致使无法顺利进入下一个阶段，从而使共识无法达成。本专利引入异常处理机制解决这种问题。
把一次共识共识的全过程定义为一个视图，所有阶段需要在同一个视图下完成。
当一个节点完成块h的落盘存储之后，意味着它就需要开始块h+1的共识过程，此时会对块h+1的共识设置一个超时器，当到达超时还未完成共识过程就会引起视图切换过程。视图切换的过程首先是将自己的视图v++，然后把v全网广播告知所有节点，如果收到2/3以上节点都有相同的视图v切换请求，就顺利切换到下一个视图。

（这里描述的与下图有区别，视图切换v++的顺序位置不同？）

并行机制

在3.3介绍的共识过程中，打包验证交易和验证交易分别是领导节点和随从节点对交易进行确认的操作，这是整个共识过程中最耗时的环节（即多轮全广播）。从图中可以看出，打包验证交易和验证交易是串行执行的，首先要由领导节点完成打包验证交易，随从节点的验证交易才能开始进行，假设交易确认耗时为T，其他过程总耗时为T’，那么整个共识的耗时就为2*T+T’。本专利对交易确认机制提出并行化的改进设计，整体共识耗时降为T+T’，大大提高了共识效率。

（并行设计细节很少，其实讲的和变的就只是主节点验证交易的时机，将其放在从节点验证交易的时间段，实施并行）

（改动很少，全文讲了这么多，其实和PBFT没多少差别，只是最后改了下主节点验证交易的时机，让该步并行了）

（开始提出的问题是PBFT三个阶段是串行的，然而本方法针对于这个问题实质还是没有解决）

------------------------------------------------------------------------------

又看了该wiki下的漫谈共识机制内容：

　　PBFT的记账者在初始阶段就是相对固定的，联盟链里可以根据不同的场景来选择记账者，如机构之间线下协商、线上配置，也可以引入DPoS的思想，先通过一些选举策略选出一批记账者，但这样在联盟链里可能带来额外的复杂性，如果商业场景需要，可以在既有基础上开发PBFT-dPos。

（这个其实自己也早就考虑过，不过是考虑协议层，怎么通过环节来实施投票选举，这里说的是可以靠线下解决投票问题，线上直接配置。因此动态性支持也很重要）

　　所以我们的实现是可动态配置式的记账者列表，在具备共同利益的的联盟链网络里，所有或大部分机构都参与记账，大家一起维护商业利益，如果某个机构在记账过程中犯错、作弊、或者不工作，都可以通过少数服从多数容错，然后进行事后追责，保护大家的利益。

　　BFT算法的过程是一次提案，几步提交，在这个过程中有复杂的状态机维护的细节。起始时可按一些简单的规则，如轮次机制，让某一个机构的某一个节点在某个区块高度上，成为议长，得到记账权，然后进行记账提案，其他节点对提案进行数据验证（验证签名，验证交易数据，验证合约计算结果等），觉得都ok之后，返回一个签名确认，议长收集大家的签名，达到一定的数量后，认为达成少数服从多数的效果，则将记账结果广播出去，大家在将记账结果存下来之前，还可以再进行一次投票和计票，确认大多数人都收妥了记账数据并无异议，再将记账数据存下来，开始下一轮。

（这里其实就是两阶段提交）

　　每次投票都有数字签名，可以抗抵赖，不会投了票不认。

（这里使用的是签名机制，场景下能否使用MAC优化？）

　　所以，PBFT相对公链的各种共识，可以理解成特定的已知身份的团队内的快速达成一致的一种高效算法，特定团队的形成也是至关重要的，所以会有PBFT-Auth(经过验证的记账人), PBFT-PoS,PBFT-DPoS等多种变化。是否需要在投票和容错的部分进行常场景性的优化（如带加权系数的投票，容错由1/3改为1/2或者改为0容错等等），要看场景需求，目前来看，保证有一个相对简单，运行稳定的PBFT算法是首要的。

（这里讲到PBFT与公链算法的变种，还有权重思想，和场景下的不同容错需求，其实是对其模型做改变）

　　联盟链还可以采用一种共识算法Raft，简单的说可以理解成大家选出一个记账者，如果它稳定运行没有挂掉，就由他记账，大家无条件接受他的记账结果，相信他是诚实的，如果他挂掉了，那么大家是可以通过超时或网络探测感知，然后快速启动一轮投票，来选出一个新的记账者，然后继续无条件的等它记账，这样就达成了容错性。

　　Raft适合用于专注解决可用性（保持系统稳定运行），追求相对较高效率（比优化后的PBFT大致高20~50%的效率）的场景，基本忽略欺诈可能，且对交易延时要求可以放宽（等待多次确认）。

　　为了在速度和抗欺诈之间获得平衡，也有出现PBFT-Raft混用的共识，比如让一个记账者固定出块，其他人极少轮次的投票，或者进行快速的后置检测，如果发现Raft的记账者在作恶，立刻回滚冲正，并踢掉并惩罚作恶的记账者等等，这就有一些场景化的需求需要考虑了。

（混用是怎么用？可以自适应切换从Raft到PBFT吗？要增加错误检测识别能力，增加回滚机制，增加动态剔除机制）

　　共识算法的研究是很有意思的课题，我们也看到共识算法的选择和演进，隐约和人类社会的不同阶段是对应得上的。算法其实是社会里人和财产的关系在计算机世界的一种映射，研究共识算法，不仅是需要研究计算机理论（图灵机时代，其实计算机也能体现人性），也要去深刻的理解社会学，经济学，心理学，博弈论。

（共识是区块链底层项目的一个灵魂与创新点，尤其是公链那种，联盟链可以适用BFT，BFT的优化其实从PBFT下来做了快20年了，当然现在区块链场景是新的。这些其它的考虑很重要，尤其是在没有准入机制的开放场景。为什么需要共识，因为相互之间不可信，需要协议来规范，不管基于投票还是算力还是经济利益，容错总是存在上界的。权衡是设计特性场景下共识所需要考虑的，容错能力与性能，CAP中的CA。另外，共识中的激励其实很重要也很有效，区块链助力了所有参与者贡献者得到应有的分配和权益，激励引导节点遵守协议，虽然公链上需要更多考虑，联盟链也不能忽视）

-------------------------------------------------------------------------------------------------

看了下白皮书共识部分：

　　然后，我们对耗时较高，有次数冗余的计算过程进行了精简，通过关键路径优化，重复计算结果进行缓存等方式减少了共识过程中的每一步的耗时。

　　同时，我们对网络健康度、节点存活等因素进行检测，当发现有的记账节点无法服务时，快速切换到下一个记账节点，避免出现全体节点出现空等待的状况。

　　最后，我们考虑到金融交易的场景常常有高峰期和空闲期的特点，在空闲期系统没有交易流量的时候，共识机制进入心跳状态，只维护网络的健康状态，不产生包含交易数为0的空区块数据，避免不必要的存储浪费，以及避免空区块的同步流量和时间消耗。

（考虑高峰和低谷，这里是根据时间窗口出块吗？然后自适应变化窗口？）

　　相比RAFT论文提及的算法，我们还针对网络抖动、网络延迟以及网络分区孤岛异常情况进行一系列优化，使RAFT共识算法能够满足更极端的网络环境。该RAFT算法具有N/2的容错能力，只要一半以上节点就可以正常服务。

　　为了使联盟链网络具有更高的扩展性，RAFT共识算法结合智能合约支持节点动态增加和退出网络，这也是该RAFT算法的一大亮点。

（结合智能合约的细节？）

国密算法改造

动机：国密算法自主可控

计划采用SM（公私钥密码算法，可实现数字签名），SM3（摘要算法），SM4（对称密码算法）等几个国密算法，对区块链平台里牵涉到密码的模块全面进行改造升级

同时，我们也将引入基于国密的硬件加密机制，包括USBkey、加密机、智能卡等，以满足各种金融场景需求。

（这里提到2点，国密改造，因为是国内的平台，基于国密硬件，国外是TPM可信平台模块，国内也有自己的可信计算芯片和标准TCM可信密码模块）

另外还有多CA用于多中心认证