CN113612618B - 一种联盟链共识方法及装置 - Google Patents

Abstract

本发明提供了一种联盟链共识方法及装置，涉及区块链技术领域，本发明提出的VRaft算法，对Raft算法在领导者选举阶段存在的空任期问题提供了解决方案，VRaft算法通过引入可验证随机函数使得候选者在发出投票请求时会附带VRF算法的哈希输出，其他候选者在收到候选者的投票请求时不再是直接拒绝，而是通过VRF算法验证和比较哈希输出，来确定是否要将自己的选票转给该提出投票请求的候选者，进而避免领导者选举阶段空任期的问题，加速了整个领导者的选举过程，避免了延后进入日志复制阶段的时间。

Description

一种联盟链共识方法及装置

技术领域

本发明涉及区块链技术领域，特别是涉及一种联盟链共识方法及装置。

背景技术

随着信息技术的发展，区块链技术由于其具有的开放性、不可篡改性、去中心化等优点，成为人们重点关注的技术。由于现有区块链技术的去中心化的特点，使得在该区块链中执行的业务在存储在区块链(即，上链)之前，还需要由该区块链中的各节点对该业务对应的业务数据(如，对业务进行处理后的结果)进行共识。

目前，国内外对于区块链共识算法的研究都投注了大量的资源和精力。总的来说现阶段的共识算法主要分为两类：拜占庭容错类的共识算法和非拜占庭容错类的共识算法。非拜占庭类的容错算法大多应用于联盟链中，因为联盟链由于其网络节点的许可机制使得联盟链中基本不会出现恶意节点，因此联盟链可以更多关注其在性能方面上的提升，这有利于区块链在初期阶段的研究发展。

Raft算法是非拜占庭容错类易于理解和相对高效的共识算法，Raft将其共识归为领导者选举和日志提交两阶段。在Raft算法中每个节点只可能有三种状态，分别为跟随者(Follower)、候选者(Candidate)、和领导者(Leader)。

Raft算法中，在领导者选举阶段，首先所有节点都是跟随者身份，每个跟随者节点会伴随一个随机的选举定时器，在Raft算法中其时间为150ms～300ms之间的随机值。如果在选举定时器超时内收到了领导者发出的心跳包，那么就重置定时器维持跟随者状态。如果选举定时器超时后还没有收到领导者的心跳包，那么跟随者会晋升为候选者身份进而向其他节点发出投票请求。候选者节点依旧伴随着一个随机的选举定时器，如果在选举定时器超时内收到了超过系统半数节点以上的投票，那么他就会晋升为领导者，如果它在晋升为领导者之前收到了其他领导者的心跳包，那么就会退回为跟随者状态。如果在这一任期的选举过程中候选者没有晋升为领导者，系统中也没有产生新的领导者，那么该任期为空任期，进而候选者身份不变，重新开始新一任期的选举。

然而，在上述Raft算法的领导者选举阶段，由于跟随者选举定时器的不确定性会产生多个候选者，而候选者不会投票给其他候选者，进而导致了选举阶段空任期的可能，延后了进入日志复制阶段的时间。

发明内容

有鉴于此，本发明通过对Raft算法进行改进，提出了一种联盟链共识方法和装置，以减少选举阶段空任期的产生，加速整个领导者的选举过程，避免延后进入日志复制阶段的时间。

为此，本发明提供了以下技术方案：

一方面，本发明提供了一种联盟链共识方法，所述联盟链中包含预先设置的共识节点，所述共识节点的状态包括：领导者、跟随者以及候选者，所述方法包括：

当各个共识节点的选举定时器均超时时，各个共识节点由跟随者状态转换为候选者状态，进入领导者选举阶段；

第一候选者共识节点给自己投一票，然后向其他共识节点发起投票请求，所述投票请求中至少包括：所述第一候选者共识节点本地生成的校验码；

当第二候选者共识节点接收到所述第一候选者共识节点发出的投票请求时，所述第二候选者共识节点检查所述第一候选者共识节点的任期号以及日志，并验证投票请求中的校验码是否有效；如果验证通过且校验码有效，则在投票请求中的校验码大于所述第二候选者节点本地生成的校验码时，将所述第二候选者节点获得的所有票数转票给所述第一候选者共识节点；

若所述第一候选者共识节点获得半数票以上，则所述第一候选者共识节点晋升为领导者，进而进入后续的日志复制阶段。

进一步地，还包括：

当跟随者共识节点接收到所述第一候选者共识节点发出的投票请求时，所述跟随者共识节点检查所述第一候选者共识节点的任期号以及日志，检查通过之后，将票投给所述第一候选者共识节点。

进一步地，如果验证通过且校验码有效，则在投票请求中的校验码小于所述第二候选者节点本地生成的校验码时，拒绝投票。

进一步地，初始状态下，各个共识节点本地用可验证随机函数算法生成公私钥对pk和sk。

进一步地，所述第一候选者共识节点发出的投票请求中还包括：所述第一候选者共识节点在本地生成的证明pi，并在第一发起投票请求时附带所述第一候选者共识节点的公钥pk。

进一步地，验证投票请求中的校验码是否有效，包括：通过可验证随机函数算法根据所述第一候选者共识节点的公钥pk、证明pi以及字符串消息alpha验证投票请求中的校验码是否有效。

进一步地，所述第一候选者共识节点在本地基于私钥sk和字符串消息alpha生成证明pi。

进一步地，所述第一候选者共识节点在本地基于私钥sk和字符串消息alpha生成校验码。

又一方面，本发明提供了一种联盟链共识装置，所述联盟链中包含预先设置的共识节点，所述共识节点的状态包括：领导者、跟随者以及候选者，当各个共识节点的选举定时器均超时时，各个共识节点由跟随者状态转换为候选者状态，进入领导者选举阶段；其特征在于，所述装置包括：

请求投票单元，用于第一候选者共识节点给自己投一票，然后向其他共识节点发起投票请求，所述投票请求中至少包括：所述第一候选者共识节点本地生成的校验码；

转票单元，用于当第二候选者共识节点接收到所述第一候选者共识节点发出的投票请求时，所述第二候选者共识节点检查所述第一候选者共识节点的任期号以及日志，并验证投票请求中的校验码是否有效；如果验证通过且校验码有效，则在投票请求中的校验码大于所述第二候选者节点本地生成的校验码时，将所述第二候选者节点获得的所有票数转票给所述第一候选者共识节点；

晋升单元，用于若所述第一候选者共识节点获得半数票以上，则所述第一候选者共识节点晋升为领导者，进而进入后续的日志复制阶段。

进一步地，所述转票单元验证投票请求中的校验码是否有效，包括：通过可验证随机函数算法根据所述第一候选者共识节点的公钥pk、证明pi以及字符串消息alpha验证投票请求中的校验码是否有效。

本发明的优点和积极效果：本发明提出的VRaft算法，对Raft算法在领导者选举阶段存在的空任期问题提供了解决方案，VRaft算法通过引入可验证随机函数(VerifiableRandom Function，VRF)使得候选者在发出投票请求时会附带VRF算法的哈希输出，其他候选者在收到候选者的投票请求时不再是直接拒绝，而是通过VRF算法验证和比较哈希输出，来确定是否要将自己的选票转给该提出投票请求的候选者，进而避免领导者选举阶段空任期的问题。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图做以简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例中VRaft算法的领导者选举；

图2为本发明实施例中VRaft算法中4个候选者的情况(无宕机)；

图3为本发明实施例中VRaft算法中4个候选者的情况(有宕机)；

图4为本发明实施例中性能测试的网络拓扑图；

图5为本发明实施例中空合约的事务流程图；

图6为本发明实施例中空合约在2-of-any背书策略下的吞吐量条形图；

图7为本发明实施例中空合约下各节点的CPU占比雷达图；

图8为本发明实施例中空合约下各节点的网络I/O雷达图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

本发明提供了基于Raft算法的一种改进算法，原始的Raft算法，在领导者选举阶段，存在空任期，造成了性能瓶颈。本发明提出了VRaft算法，在领导者选举阶段进行了改进和优化，通过引入VRF来提高领导者选举的稳定性，减少了领导者选举阶段空任期的产生，并通过加入候选者可以给其他候选者进行转票的机制，使得VRaft算法的领导者选举阶段在不失其随机性的前提下变得更加稳定，进而减少了空任期的产生，加速了整个领导者的选举过程，提高了进入到日志复制阶段的速度。

VRF算法可以使得私钥持有者根据其私钥和一个字符串消息(该消息是事先定义好的，任意长度的一个字符串消息，对应generateBeta函数中的alpha变量)来计算一个哈希输出和一个证明，然后任何人都可以在不知道其私钥的情况下，根据私钥持有者的公钥和其产生的证明以及当初的字符串消息来验证其哈希输出的正确性，进而验证了输出此哈希的身份的有效性。

VRF算法的实现基于非对称加密，需要公私钥对的支持。目前VRF算法的设计可以基于RSA和ECC椭圆曲线两种生成公私钥对的生成方式进行实现。从自底向上的方式来看，VRF算法由三个部分逐步实现，分别为类型转换函数、辅助函数和核心函数。首先需要实现一些基本的底层类型转换函数，因为这类函数在辅助函数和核心函数中都大量使用，其次需要实现辅助函数来作为核心函数的子函数，最后实现具有直接功能的核心函数。

VRaft算法在领导者选举阶段的总体思想是允许候选者节点把自己获得的票数都转投给其他候选者节点，进而导致在一个任期的选举中如果没有节点宕机那么必然产生领导者，提高了领导者选举的稳定性，减少了进入日志复制的延迟，VRaft算法中领导者选举的具体流程图如图1所示，节点中的数字依旧代表其获得的投票数量。

下面对VRaft算法中领导者选举的具体流程做详细说明：

(1)初始状态下，所有节点依旧初始化为跟随者状态，并本地用VRF算法生成公私钥对pk和sk。

(2)假设跟随者节点的选举定时器均超时，那么它们会进入到候选者状态。

(3)由于系统中存有候选者，所以进入领导者选举阶段。候选者首先会给自己投一票，然后向其他节点发起RequestVote RPC投票请求。

跟Raft算法不同的是，这里的候选者会本地通过generateBeta(sk，alpha)生成证明pi和校验码beta，并且在投票请求中附带自己生成的pi和beta，并在第一次发起投票请求时附带自己的公钥pk。alpha为字符串类型，是VRF算法的消息输入。

(4)如果一个跟随者收到了一个RequestVote RPC投票请求，那么会检查候选者的任期号以及他的日志情况，检查通过会把票投给该候选者。

(5)如果一个候选者收到了一个RequestVote RPC投票请求，在Raft算法中是拒绝投票，在VRaft算法中该候选者首先也会验证其任期号和日志情况，然后再通过VRF算法计算verify(pk，alpha，pi)来验证投票请求中的beta是否有效。如果有效那么比较该beta与自己本地生成的beta，如果前者更大那么会将自己获得的所有票数转票给该候选者，如果后者更大，则拒绝投票(VRF的理论基础，保证了不会有等于的情况出现)。

函数verify(pk，alpha，pi)是用来验证beta是否有效的核心函数，首先是对pi解码生成Gamma、c和s三部分，如果Gamma无效则函数结束，输出无效，然后再生成三个ec点H、U、V，通过辅助函数hashPoints生成一个c1，如果c和c1不等则函数结束，输出无效，否则允许调用核心函数proofToBeta生成一个beta2，返回即可。

因此VRF算法的验证过程是通过生产者的公钥pk、产生的证明pi以及消息alpha同样生成一个哈希输出beta2，如果beta2和生产者用其私钥sk和同一消息alpha生成的beta1相同，那么则证明了beta1一定是用其私钥sk和消息alpha生成的。如果不相同则生产者的身份可能不真实或者伪造了证明pi和消息alpha。(6)通过转票阶段，获得半数票以上的候选者会晋升为领导者，进而进入后续的日志复制阶段。

在VRaft算法中的领导者选举阶段由于候选者的转票机制，使得在一个任期的选举期间一定会产生一个唯一的领导者，避免了空任期。这种领导者的确定性无论是在有几个候选者都不会改变。

下面讨论了拥有n/2+2个以上的候选者在宕机和不宕机的两种情况，分别对应图2和图3，其中的箭头方向依旧是投票方向，节点中的数字依旧是此时候选者的票数，候选者1、2、3、4的beta大小按1、2、3、4的顺序排列。

在图2中，首先每个候选者一定会有自己的一票，然后剩下的跟随者会把一票投给其中一个候选者(这里是候选者1)，此时系统由于没有候选者节点获得半数以上的票数(3)，从而还没有产生领导者，接下来会出现两类转票情况。假设候选者1的投票请求优先到达其他节点，那么会进入到转票情况1，其他候选者在优先接收到候选者1的投票请求后会把自己的票数转给候选者1，候选者1获得半数以上的票数晋升为领导者。当然由于网络延迟的不确定性，可能候选者1的投票请求最后到达到其他节点，那么会进入到转票情况2，在这种情况下候选者3、4的票数会转到候选者2上，导致即使候选者2的beta小于候选者1的beta，但是它依旧因为已经获得超过半数的投票而优先晋升为领导者，进而系统进入到日志复制阶段，领导者2会优先发送AppendEntries RPC日志复制请求给其他接节点。如果在候选者2已经晋升为领导者后，再接到候选者1的投票请求时，由于候选者的任期号并不大于此时领导者的任期号，因此会被领导者拒绝。所以在VRaft算法中不一定beta最大的候选者最后一定会晋升为领导者，如果强制让beta最大的候选者成为领导者会导致不必要的转票延迟，选举领导者的意义在于随机的确定唯一一个领导者即可，所以VRaft算法依旧维持了Raft算法中超过半数票数就能成为领导者的规则。

下面对VRaft算法的测试结果进行具体说明：

1.测试环境

实验环境的配置细节如表1所示。

表1

2.测试指标

使用Hyperledger的官方测试工具Caliper对VRaft算法和Raft算法进行测试和对比实验。

使用Caliper测试VRaft算法性能的网络拓扑如图4所示，caliper测试工具主要包含两个部分，分别是用于产生负载的负载客户端和用于观察各节点性能的观察客户端。负载客户端通过模拟负载产生器向Fabric系统发送各种合约交易，这些交易被Fabric中的组织所接收后通过背书策略进行背书返回客户端，客户端再将附带背书节点签名的交易发送给Fabric的共识模块，共识模块会使用本文实现的VRaft算法对交易进行共识排序，然后将排好序的区块发送到各组织的peer节点，peer节点对交易进行验证通过后会在本地的世界状态数据库即LevelDB或CouchDB进行存储。整个交易过程中，Caliper的观察客户端会对Fabric的各个节点包括每个order节点和各组织的peer节点进行性能观察，最后得出性能结果。

Caliper目前支持的区块链性能指标有四个，分别是成功率、吞吐量、时延和资源消耗率，这些指标同时也是区块链系统中非常重要的性能指标，下面将对这些指标进行一一介绍。

(1)成功率

成功率是指，在一个测试周期内Caliper的负载客户端向Fabric系统输入事务的成功率，这个指标是考虑到Caliper的负载客户端输入的事务可能会因为网络原因而导致失败，但是本文在测试时成功率都为100％，而且这个指标也并不是性能相关的重点，所以本文没有对这个指标进行实验展示。

(2)吞吐量

吞吐量又称TPS(Transactions Per Second)，是区块链系统测试事务流量的重要指标，其表示在一个测试周期内系统每秒处理事务的数量，单位为交易/秒(tx/s)，其中CountTX为测试周期内成功处理的事务总数，TotalSecond为测试周期的总秒数。

(3)时延

交易时延也是评估区块链系统性能的重要指标，它表示用户从向区块链系统发起一笔交易到这笔交易被提交的时间差，单位为秒(s)，其中Latency代表时延，ConfirmationTime和submitTime分别代表交易确认时间和交易提交时间。如果是一笔查询交易，那么时延应该是用户从向区块链系统发起的一笔查询交易到返回用户响应的时间差。

Latency＝ConfirmationTime-submitTime；

(4)资源消耗率

资源消耗率主要表示区块链网络中各节点对硬件资源的消耗情况和网络流量情况。Caliper测试支持的资源消耗率有CPU占用率(％)、内存开销(MB)、网络I/O开销(MB)、磁盘读写开销(MB)，其中网络I/O开销包括网络流量的输入和输出，在后续对网络I/O指标的测试中，会将其看作是网络流量的输入输出之和。由于磁盘读写开销对于固定的合约数据而言不应该有变化，因此磁盘读写开销并不会在Raft算法和VRaft算法中产生明显的对比差异，固在本实验结果中不展示磁盘读写开销的对比。

3.测试结果

通过Caliper的负载客户端提交空合约的事务流程图如图5所示，首先由负载客户端不断的产生提交类型的测试空合约输送到Fabric系统，然后经过Fabric的事务处理流程，最终该交易会上链，但是由于空合约没有存储或更新任何数据，所以空合约不会在Fabric的节点产生任何持久化的操作，也就没有涉及到世界状态数据库的写入操作，最终Fabric系统各节点的性能信息会反馈到Caliper的观察客户端中。

由于空合约没有实际数据写入到世界状态数据库，进而VRaft算法在日志复制阶段的优化不能明显的展示出来，并且无论是Raft算法还是VRaft算法它们在领导者选举阶段都存在随机性较强的选举定时器，所以为了避免单一的测试会出现偶然情况，本实验对于空合约的情况重复进行了5次测试，背书规则是2-of-any，即：需要组织1和组织2的两个peer节点均背书。表2所示的是空合约在2-of-any背书策略下的具体吞吐量数据，图6所示的是空合约在2-of-any背书策略下的吞吐量条形图。

表2

表2显示的是空合约在2-of-any背书策略下的吞吐量数据，图6显示的是空合约在2-of-any背书策略下的吞吐量条形图。由表2和图6中可以看出，在2-of-any背书策略下的VRaft算法的吞吐量普遍高于Raft算法的吞吐量，且VRaft算法比Raft算法更加稳定，这是因为2-of-any背书策略下的背书时间更长，导致Raft算法的领导者选举阶段有更多的时间产生空任期，这就凸显出VRaft算法在领导者选举阶段的优势。

表3

表3所示的是空合约在2-of-any背书策略下Raft算法和VRaft算法的时延对比表，不出意外，它们的平均时延都略高于在1-of-any背书策略下的平均时延。通过表中可以看出再改变背书策略后，Raft算法的最大时延有着近0.3个点的上升，但是VRaft算法只有0.05个点的上升，这正是说明了VRaft算法在领导者选举阶段的稳定性。Raft算法由于背书策略的改变导致背书时间延长，进而增加了其可能产生空任期的可能性，从而加大了最大时延，而VRaft算法由于其领导者选举阶段的稳定性导致其在背书时间延长后，并没有增加太多的最大时延。

表4

表4显示的是空合约在2-of-any背书策略下的CPU使用情况，图7则相应显示的是空合约在2-of-any背书策略下的CPU占比雷达图，这里主要给出跟共识算法相关的order节点的CPU占比情况。从雷达图中可以直观的看出VRaft算法的CPU占比普遍高于Raft算法的CPU占比，这是因为VRaft算法中的加密验证函数所产生的额外计算消耗，使VRaft算法中的order节点占用了更多的CPU。

表5

表5显示的是空合约在2-of-any背书策略下order节点的网络I/O情况，单位为MB，图8则相应显示的是空合约在2-of-any背书策略下order节点的网络I/O雷达图。从表5中可以看出Raft算法各节点的网络I/O并不均匀，VRaft算法各节点的网络I/O数据相对均匀，这是因为在Raft算法中只有领导者进行广播日志复制RPC给其他跟随者节点，跟随者节点只需要单一的回应领导者即可，而VRaft算法由于引入了跟随者转发领导者RPC请求的机制，使得VRaft算法的跟随者节点不仅要回复领导者节点的RPC响应，还要转发领导者的日志复制RPC给其他跟随者节点，进而增加了跟随者节点的网络I/O，使得整个共识模块的网络I/O变得均匀。从雷达图8中可以看出Fabric在使用VRaft算法时order节点的网络I/O都普遍大于使用Raft算法时order节点的网络I/O，这也是因为VRaft算法的跟随者节点会转发领导者节点的RPC所导致，同时VRaft算法的节点也会发送跟VRF验证算法相关的beta、pi、pk等额外数据增加了VRaft算法中各节点的网络I/O。

对应本发明中的联盟链共识方法，本发明还提供了一种联盟链共识装置，所述联盟链中包含预先设置的共识节点，所述共识节点的状态包括：领导者、跟随者以及候选者，当各个共识节点的选举定时器均超时时，各个共识节点由跟随者状态转换为候选者状态，进入领导者选举阶段；所述装置包括：

请求投票单元，用于第一候选者共识节点给自己投一票，然后向其他共识节点发起投票请求，所述投票请求中至少包括：所述第一候选者共识节点本地生成的beta；

转票单元，用于当第二候选者共识节点接收到所述第一候选者共识节点发出的投票请求时，所述第二候选者共识节点检查所述第一候选者共识节点的任期号以及日志，并通过VRF算法验证投票请求中的beta是否有效；如果验证通过且beta有效，则在投票请求中的beta大于所述第二候选者节点本地生成的beta时，将所述第二候选者节点获得的所有票数转票给所述第一候选者共识节点；

晋升单元，用于若所述第一候选者共识节点获得半数票以上，则所述第一候选者共识节点晋升为领导者，进而进入后续的日志复制阶段。

对于本发明实施例的联盟链共识装置而言，由于其与上面实施例中的联盟链共识方法相对应，所以描述的比较简单，相关相似之处请参见上面实施例中联盟链共识方法部分的说明即可，此处不再详述。

在本发明所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (10)

1.一种联盟链共识方法，所述联盟链中包含预先设置的共识节点，所述共识节点的状态包括：领导者、跟随者以及候选者，其特征在于，所述方法包括：

当各个共识节点的选举定时器均超时时，各个共识节点由跟随者状态转换为候选者状态，进入领导者选举阶段；

第一候选者共识节点给自己投一票，然后向其他共识节点发起投票请求，所述投票请求中至少包括：所述第一候选者共识节点本地生成的校验码；

当第二候选者共识节点接收到所述第一候选者共识节点发出的投票请求时，所述第二候选者共识节点检查所述第一候选者共识节点的任期号以及日志，并验证投票请求中的校验码是否有效；如果验证通过且校验码有效，则在投票请求中的校验码大于所述第二候选者节点本地生成的校验码时，将所述第二候选者节点获得的所有票数转票给所述第一候选者共识节点；

若所述第一候选者共识节点获得半数票以上，则所述第一候选者共识节点晋升为领导者，进而进入后续的日志复制阶段。

2.根据权利要求1所述的一种联盟链共识方法，其特征在于，还包括：

当跟随者共识节点接收到所述第一候选者共识节点发出的投票请求时，所述跟随者共识节点检查所述第一候选者共识节点的任期号以及日志，检查通过之后，将票投给所述第一候选者共识节点。

3.根据权利要求1所述的一种联盟链共识方法，其特征在于，如果验证通过且校验码有效，则在投票请求中的校验码小于所述第二候选者节点本地生成的校验码时，拒绝投票。

4.根据权利要求1所述的一种联盟链共识方法，其特征在于，初始状态下，各个共识节点本地用可验证随机函数算法生成公私钥对pk和sk。

5.根据权利要求4所述的一种联盟链共识方法，其特征在于，所述第一候选者共识节点发出的投票请求中还包括：所述第一候选者共识节点在本地生成的证明pi，并在第一次发起投票请求时附带所述第一候选者共识节点的公钥pk。

6.根据权利要求5所述的一种联盟链共识方法，其特征在于，验证投票请求中的校验码是否有效，包括：通过可验证随机函数算法根据所述第一候选者共识节点的公钥pk、证明pi以及字符串消息alpha验证投票请求中的校验码是否有效。

7.根据权利要求5所述的一种联盟链共识方法，其特征在于，所述第一候选者共识节点在本地基于私钥sk和字符串消息alpha生成证明pi。

8.根据权利要求1所述的一种联盟链共识方法，其特征在于，所述第一候选者共识节点在本地基于私钥sk和字符串消息alpha生成校验码。

9.一种联盟链共识装置，其特征在于，所述联盟链中包含预先设置的共识节点，所述共识节点的状态包括：领导者、跟随者以及候选者，当各个共识节点的选举定时器均超时时，各个共识节点由跟随者状态转换为候选者状态，进入领导者选举阶段；其特征在于，所述装置包括：

请求投票单元，用于第一候选者共识节点给自己投一票，然后向其他共识节点发起投票请求，所述投票请求中至少包括：所述第一候选者共识节点本地生成的校验码；

转票单元，用于当第二候选者共识节点接收到所述第一候选者共识节点发出的投票请求时，所述第二候选者共识节点检查所述第一候选者共识节点的任期号以及日志，并验证投票请求中的校验码是否有效；如果验证通过且校验码有效，则在投票请求中的校验码大于所述第二候选者节点本地生成的校验码时，将所述第二候选者节点获得的所有票数转票给所述第一候选者共识节点；

晋升单元，用于若所述第一候选者共识节点获得半数票以上，则所述第一候选者共识节点晋升为领导者，进而进入后续的日志复制阶段。

10.根据权利要求9 所述的一种联盟链共识装置，其特征在于，所述转票单元验证投票请求中的校验码是否有效，包括：通过可验证随机函数算法根据所述第一候选者共识节点的公钥pk、证明pi以及字符串消息alpha验证投票请求中的校验码是否有效。

Images