CN106060036A - 去中心化共识方法及装置 - Google Patents

Abstract

本发明涉及一种去中心化共识方法及装置。该方法可以包括多个验证节点中的第一验证节点接收待共识的数据。第一验证节点进行投票，以在所述多个验证节点中选举出具有领导者身份的验证节点。如果被选举为领导者，则第一验证节点向系统中的其他验证节点要求确认其合法。如果未被选举为领导者，则第一验证节点确认所选举的领导者是否合法。以及第一验证节点执行状态更新。本发明还公开了一种中心化共识的装置。

Description

去中心化共识方法及装置

技术领域

本发明属于互联网技术领域，更具体地涉及一种去中心化共识方法及装置。

背景技术

去中心化共识指的是在没有中心控制节点的分布式系统中，所有参与节点对交易、数字记录、电子证据等系统数据的正确性进行验证并达成一致共识的机制。而区块链由于自有的去中心化属性，能够让节点与节点之间的交互比传统中心化的方式更快、更经济的进行。目前，主流的去中心化共识方法包括：工作量证明PoW(Proof of Work)、权益证明PoS(Proof of Stake)、瑞波共识协议RCP(Ripple Consensus Protocol)等。

发明内容

PoW交易确认时间长，区块产生速度在10分钟左右，交易确认时间更是长达1小时；存在51％的攻击漏洞，即当攻击者掌握超过51％计算能力时，可恶意更改区块链信息；用户需要下载整个区块链信息，充当矿工进行“挖矿”，浪费计算资源。PoS易遭受“零成本”攻击，即之前提供抵押之后兑换并花掉的各方可以回来重写他们拥有权益那时开始的历史。RCP方法中，用户实践中并不愿意编辑信任列表，于是巨大的权力最终集中到少数列表维护者手中，造成一定程度的中心化。

鉴于以上情况，有必要提供新的去中心化共识方法及装置。

根据本发明的一方面，提供了一种用于在具有多个验证节点的系统中实现去中心化共识的方法。该方法包括：多个验证节点中的第一验证节点接收待共识的数据；第一验证节点进行投票，以在多个验证节点中选举出具有领导者身份的验证节点；如果被选举为领导者，则第一验证节点向系统中的其他验证节点要求确认其合法；如果未被选举为领导者，则第一验证节点确认所选举的领导者是否合法；以及第一验证节点执行状态更新。

根据本发明的另一方面，提供了一种用于在具有多个验证节点的系统中实现去中心化共识的装置。该装置包括：用于多个验证节点中的第一验证节点接收待共识的数据的模块；用于第一验证节点进行投票，以在多个验证节点中选举出具有领导者身份的验证节点的模块；用于如果被选举为领导者，则第一验证节点向系统中的其他验证节点要求确认其合法的模块；用于如果未被选举为领导者，则第一验证节点确认所选举的领导者是否合法的模块；以及用于第一验证节点执行状态更新的模块。

根据本发明的另一方面，提供了一种用于在具有多个验证节点的系统中实现去中心化共识的方法。该方法包括：验证节点接收待共识的数据；验证节点投票选举出具有领导者身份的验证节点同时产生跟随者身份的验证节点；领导者向跟随者发送确认消息，并等待确认回复消息；领导者接收跟随者返回的确认消息，并将返回的确认消息与设定的门限值进行比较；以及收到返回的确认消息达到门限值后，结束确认阶段，让跟随者更新自己的状态。

本发明提供了基于投票的去中心化共识方法及装置。利用投票的方式，选出系统验证过程中的领导者，经过领导者确认和接受阶段后，由领导者发布并扩散领导者自身的数据状态，系统中所有节点进而完成数据状态更新，达成全系统的一致共识。由于该方法中网络节点达到共识之后，大部分网络节点状态会与某些验证节点的初始状态一致，通过该方法提前将这样的网络节点选举出来，由他们来扩散自身的状态到整个网络中，可加速共识的进行，利用该方法具有消息简单、数据量少、灵活度高、数据传输快、低延迟等优点。由于该方法在确认阶段需要全网验证节点对选举出的领导者身份进行验证，使得该去中心化共识方法及装置具有抗攻击的优点。

附图说明

通过参考附图会更加清楚地理解本发明的特征和优点，附图是示意性的而不应理解为对本发明进行任何限制，在附图中：

图1示出根据本发明的具有多个验证节点的系统的一个实施例的示意图；

图2示出根据本发明的用于在具有多个验证节点的系统中实现去中心化共识的方法的一个实施例的流程图；

图3示出根据本发明的一个实施例的去中心化共识方法的流程图；

图4示出根据本发明的一个实施例的去中心化共识方法中选举阶段验证节点角色变换的示意图；

图5示出根据本发明的一个实施例的去中心化共识方法中投票发送者在选举阶段的流程图；

图6示出根据本发明的一个实施例的去中心化共识方法中投票接收者在选举阶段的流程图；

图7示出根据本发明的一个实施例的去中心化共识方法中确认阶段的流程图；

图8示出根据本发明的另一实施例的去中心化共识方法中确认阶段的流程图；

图9示出根据本发明的一个实施例的用于在具有多个验证节点的系统中实现去中心化共识的装置的结构示意图。

图10示出根据本发明的另一个实施例的去中心化共识装置的结构示意图。

具体实施方式

下面将详细描述本发明的各个方面的特征和示例性实施例。在下面的详细描述中，提出了许多具体细节，以便提供对本发明的全面理解。但是，对于本领域技术人员来说很明显的是，本发明可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本发明的示例来提供对本发明的更好的理解。本发明决不限于下面所提出的任何具体配置和方法，而是在不脱离本发明的精神的前提下覆盖了元素、部件和算法的任何修改、替换和改进。在附图和下面的描述中，没有示出公知的结构和技术，以便避免对本发明造成不必要的模糊。

下面结合附图，详细描述根据本发明实施例的去中心化共识方法、装置。

图1示出根据一种实施例，具有多个验证节点的系统的示意图，该系统可以包括由多个验证节点组成的对等计算机网络(P2P)。该系统可以是一种在对等者(Peer)之间分配任务和工作负载的分布式应用架构，是对等计算模型在应用层形成的一种组网或网络形式。“Peer”在英语里有“对等者、伙伴、对端”的意义。该系统也可以定义为：网络的参与者共享他们所拥有的一部分硬件资源(处理能力、存储能力、网络连接能力、打印机等)，这些共享资源通过网络提供服务和内容，能被其它对等节点(Peer)直接访问而无需经过中间实体。在此网络中的参与者既是资源、服务和内容的提供者(Server)，又是资源、服务和内容的获取者(Client)。

在P2P网络环境中，彼此连接的多台计算机之间都处于对等的地位，各台计算机有相同的功能，无主从之分，一台计算机既可作为服务器，设定共享资源供网络中其他计算机所使用，又可以作为工作站，整个网络一般来说不依赖专用的集中服务器，也没有专用的工作站。网络中的每一台计算机既能充当网络服务的请求者，又对其它计算机的请求做出响应，提供资源、服务和内容。通常这些资源和服务包括：信息的共享和交换、计算资源(如CPU计算能力共享)、存储共享(如缓存和磁盘空间的使用)、网络共享、打印机共享等；以及本实施例示出的所有网络参与节点可以对交易、数字记录、电子证据等系统数据的正确性进行验证并达成一致共识。

图2示出根据一种实施例，用于在具有多个验证节点的系统中实现去中心化共识的方法的流程图，在步骤S100，多个验证节点中的第一验证节点接收待共识的数据。系统中还可以存在多个非验证节点，非验证节点负责产生待共识数据。在步骤S200，第一验证节点进行投票，以在多个验证节点中选举出具有领导者身份的验证节点。在步骤S300，如果被选举为领导者，则第一验证节点向系统中的其他验证节点要求确认其合法；如果未被选举为领导者，则第一验证节点确认所选举的领导者是否合法。在步骤S400，第一验证节点执行状态更新。图2示出根据一种实施例，去中心化共识方法的流程图，在步骤S100中，验证节点接收待共识的数据，这里需要确认的待共识的数据可以是交易、电子证据、数字记录等任何形式的电子数据。验证节点尽可能多地收集并存放本轮共识过程需要确认的所有数据，完成一些初始化操作，例如将身份初始为跟随者等，准备开始共识，在步骤S100中，系统将需要确认的数据发送给验证节点的过程，可以包括在步骤S101中，第一验证节点接收待共识的数据，根据既定规则对接收到的每条数据做校验，如果通过校验，则将数据存储到本地，供之后共识用，否则丢弃该数据。在步骤S102中，第一验证节点在开始共识前，完成本地初始化工作，如身份初始化为跟随者，时隙号重置为0等，并在准备开始共识时，将所有待共识的数据锁定，与共识过程中接到的新数据分开。

在步骤S200，进入选举阶段，第一验证节点投票选举具有领导者身份的验证节点。在步骤S200中，第一验证节点被选举为领导者后，将具有如分发扩散自身数据等功能。这里如图4示出的一个实施例，选举阶段验证节点角色变换的示意图。选举过程中节点身份分为三种：跟随者，候选者和领导者。初始化时所有节点角色均为跟随者，且时隙号设定为0，这里的时隙可以理解为虚拟时间，时隙号越大表示时间越靠后。共识开始后，第一验证节点转为候选者，时隙号增加，比如加1，并投自己一票，同时向其他验证节点发起投票请求。系统中每个时隙获得多数投票的候选者变成领导者，这里的多数可以是一个门限值，具体代表多大比例可通过例如配置文件等方式来指定，进而增加系统的灵活性。领导者只可能有一个，一旦领导者选出，该选举阶段结束。如果当前时隙系统没有选出领导者，所有候选者进入睡眠状态，随机睡眠一段时间后将在新的时隙号重新发起投票。第一验证节点在接到来自其他验证节点中的第二验证节点发来的投票请求之后，如果第一验证节点当前时隙号没有投票给其他节点或者小于请求者的时隙号，均需给作为请求者的第二验证节点投一票，并用第二验证节点的是洗好更新第一验证节点的时隙号，且第一验证节点转化为跟随者。在步骤S200中，验证节点角色转换后不同身份进入不同步骤，在步骤S210中，验证节点进行投票，进入选举阶段，选举领导者。在步骤S221中，领导者进入确认阶段S300中的步骤S310，其他验证节点进入步骤S220。在步骤S210中，验证节点将自己身份切换为领导者。在步骤S220中，验证节点将自己身份切换为跟随者，等待领导者的确认消息跟随者验证节点可以初始化随机定时器，并注册超时事件一旦定时器超时，触发该超时事件处理器，跟随者向系统其它节点报告当前领导者是恶意。在步骤S221中，判断是否定时器超时未收到确认消息，超时返回S210，否则进入步骤S300中的步骤S320。在这里由于选举阶段的选举是没有校验的，选出来的领导者可能是恶意的，为了确保系统的安全，需要每个跟随者对当前领导者的合法性做出验证。当多数跟随者都认为当前领导者是恶意的时候，系统重新退回到选举阶段，避免由于领导者恶意不发确认消息或者网络环境恶劣等因素导致系统无法正常达成共识。在步骤S300中的步骤S310，领导者进入领导者身份确认阶段，领导者将向其他验证节点发送确认消息。在步骤S311中，如果领导者能够接收到多数确认回复，则说明其身份被确认，否则其身份将被取消。这里的多数可以是一个门限值具体代表多大比例可通过例如配置文件等方式来指定。这里的确认回复可以是一个确认字符，例如可以是ACK(Acknowledgement)在数据通信中，接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。该阶段是保证大部分节点都对领导者的合法性做了验证且返回领导者合法，才去执行状态更新，从而确保系统中大部分的节点处于一致。在步骤S410中，领导者进入领导者状态接受阶段，领导者扩散自身待共识数据及状态，让其他验证节点更新自己的状态，进入步骤S500。在步骤S300的S320中，跟随者进入领导者身份确认阶段。在步骤S321中，验证领导者身份是否合法，合法则进入接收阶段S400中的步骤S420，否则返回步骤S210。在收到领导者的确认消息后，首先可以检查是否之前已经收到过该领导者的确认消息，如果已经收到过，则需要检查两次确认消息是否一致，一致则丢弃该消息，不一致则向系统报告当前领导者是恶意的；跟随者可以根据本地已存储的状态信息校验领导者是否合法，如果合法，则给出确认回复，不合法则向系统报告当前领导者是恶意的，当多数跟随者都认为当前领导者是恶意的时候，系统重新退回到选举阶段；在步骤S420中，跟随者进入领导者状态接受阶段，跟随者根据领导者的状态信息更新自己的状态，这里如果跟随者本地没有领导者的状态信息，则需要先向领导者请求状态信息，然后再更新自己的状态，并进入步骤S500。在步骤S500，共识完成，所有验证节点根据更新后的状态做本地执行动作，例如执行交易列表，持久化结果信息等。

图3示出根据一种实施例，去中心化共识方法的流程图。在步骤S31中，验证节点接收待共识的数据；在步骤S32中，验证节点投票选举出具有领导者身份的验证节点同时产生跟随者身份的验证节点；在步骤S33中领导者向跟随者发送确认消息，并等待确认回复消息；在步骤S34中，领导者接收跟随者返回的确认消息，并将返回的确认消息与设定的门限值进行比较；在步骤S35中，收到返回的确认消息达到门限值后，结束确认阶段，让跟随者更新自己的状态。

在步骤S200中，验证节点投票选举领导者，处在选举阶段，每个验证节点会同时担任这两个角色，可以按照投票发送者和投票接收者两个角色对该步骤进行说明，图5示出根据一种实施例，去中心化共识方法在选举阶段的流程图。在步骤S2101，共识开始后，验证节点进入选举阶段，清理上次的投票信息，如初始化投票榜，重置当前领导者等。在步骤S21011中将自己的身份从跟随者切换为候选者，准备发起投票，所述的投票榜可以用来记录谁给谁投过票。在步骤S2102中，验证节点将当前时隙号递增，可以往前递增1，并给自己投一票，表示自己认同自己成为当前领导者。同时向其他节点发起投票请求，希望其他节点也认可自己成为当前领导者。为了避免无限制地等待其他节点的投票请求回复而导致系统停滞不前，可以在发起投票请求的同时设置一个随机定时器，并注册超时事件。这里时隙号可以是一个整数值，可以理解为虚拟时间，其值越大表明其所代表的时间越靠后，候选者每次重新发起一轮新的投票时本地时隙号都会递增，例如每次可以加1，然后进行后续投票请求发起动作，表示虚拟时间向前走了一步。在步骤S2103中，投票请求发出者等待其他验证节点的投票请求回复，定时器超时进入步骤S2104，接到其他验证节点投票请求回复进入步骤S2105。在步骤S2104中，一旦定时器超时，触发超时事件处理器，超时事件处理器可以处理包括检查验证节点当前身份是否为候选者及当前阶段是否处于选举阶段，如果两者均为是，则验证节点转向步骤S21011，其他情况下可以直接忽略本次超时事件。在步骤S2105中，接到其他验证节点的投票请求回复，首先检查投票对象是否为自己，如果是投票给其他验证节点，则进入步骤S2106在投票榜上记录，返回步骤S2103；如果投票对象是自己，接着可以检查验证节点当前是否处于选举阶段，如果不是，则丢弃该投票请求回复，直接跳过选举阶段的其他操作，此时如果自己是领导者，则还需向该为自己投票的验证节点发送确认消息，让该节点进入确认阶段；如果投票对象是自己，且当前处于选举阶段，则进入步骤S2107。在步骤S2107中，检测投票请求回复是否符合系统的业务规定，如果相符则进入步骤S2108，如果不符，并做相应处理。在一个示例中，检测投票请求回复是否符合系统的业务规定，可以包括检测应用在分布式总账时投票请求回复中的账单号和本地账单号是否相符。可以让账单号落后的节点做同步操作。在步骤S2108中，检查投票请求回复中是否为已授权，也就是说其他验证节点回复投票请求的时候是否同意给自己投一票，如果是则进入步骤S2110，否则进入步骤S2109。在步骤S2109中，根据投票请求回复中的错误类型做相应处理，例如回复中的时隙号大于本地的时隙号，则需要更新本地的时隙号，将自己的身份切换为跟随者，同时给回复者发送一个投票回复，表示愿意投他一票，原因是回复者比自己所处的时间更靠后，自己应该以他为准。在步骤S2110中，检查投票请求回复中的时隙号与本地时隙号是否相符，如果不相符，则进入步骤S2111，否则进入步骤S2112，这里检测时隙号是否相符的目的是过滤掉对旧的时隙号的投票，这些投票已经过时了，是无效的，需要丢弃这样的投票请求回复。在步骤S2111中，丢弃本次投票请求回复，返回步骤S2103。在步骤S2012中，在投票榜上记录自己获得一票，并修改本地投票计数器。在步骤S2113中，检测自己是否已经获得多数投票，如果是，则进入步骤S2114，否则返回步骤S2103；这里的多数可以是一个门限值具体代表多大比例可通过例如配置文件等方式来指定，增加系统的灵活性。在步骤S2114中，将身份切换为领导者，所处阶段切换为确认阶段，同时向其他验证节点发送确认消息，表明选举阶段已经结束。

图6示出根据一种实施例，去中心化共识方法中在选举阶段的流程图。在步骤S2201中，共识开始后，验证节点进入选举阶段，清理上次的投票信息，例如初始化投票榜，重置当前领导者等，并将自己的身份从跟随者切换为候选者，准备接收投票；这里的投票榜可以用来记录谁给谁投过票。在步骤S2202中，验证节点等待投票请求的到来，接到投票请求之后进入步骤S22021根据系统待共识的业务相关规定检测不符情况，并做相应处理。例如可以检测应用在分布式总账时投票回复中的账单号和本地账单号是否相符，如果不符，则需要让账单号落后的节点做同步操作，并发送错误回复，如果相符则进入步骤S2203；在一个示例中，检测投票请求是否符合系统的业务规定，可以包括检测应用在分布式总账时投票请求中的账单号和本地账单号是否相符。在步骤S2203中，判断节点当前所处阶段是否合适。首先判断是否处于确认阶段，如果处于确认阶段，则看自身是否标记了当前领导者为恶意，主观上是否认为当前领导者为恶意节点，如果是，则将当前领导者添加到黑名单，转向步骤S22031，否则丢弃当前投票请求。在步骤S22031中，检测是否处于选举阶段，如果是选举阶段且待共识的数据已锁定，则进入步骤S2204，其他情况均丢弃当前投票请求。在步骤S2204中，判断本地当前时隙号是否大于投票请求中所包含的时隙号，如果大于，则进入步骤S2205，否则进入步骤S2206。在步骤S2205中，构造投票请求，发送给当前处理的投票请求发送方，请求对方给自己投一票，理由是自己比对方的时隙号大，所处的时间更靠后。在步骤S2206中，如果投票请求者的时隙号大于本地时隙号，那么需要用投票请求者的时隙号更新本地时隙号，并重置已投票标志，表示之前没有投过票，其他情况不做处理，进入步骤S2207。在步骤S2207中，判断已投票标志是否为已投票，如果是，表明自己不能再给其他验证节点投票了，进入步骤S2208，否则进入步骤S2209。在步骤S2208中，向投票请求者发送错误回复，类型为已投票。在步骤S2209中，将自己身份切换为跟随者，在投票榜上给投票请求者记上一票，将已投票标志置为已投票，并初始化一个随机定时器，并注册超时事件，这里的超时事件处理器是为了防止验证节点在投票完后，一直得不到其他消息，停滞在选举阶段，转向步骤S2210。在步骤S2210中，判断当前定时器是否超时，如果是，则转向步骤S2211，否则返回步骤S2202。在步骤S2211中，触发已经注册的定时器超时处理器，重新发起投票动作。

在步骤S300中，验证节点处在确认阶段，每个验证节点会同时担任这两个角色，可以按照跟随者和领导者两个角色对该步骤进行说明，图7示出根据一种实施例，去中心化共识方法中确认阶段的流程图。在步骤S3101中，等待确认的领导者验证节点可以根据本地所收集的待共识数据生成状态信息，并发送给所有的跟随者。可以根据待共识数据生成哈希结果的集合，对哈希集合生成总体哈希值。一种示例中，可以为每条待共识的数据生成其对应的哈希值，形成一个哈希值列表，然后列表整体做哈希，生成总体哈希值，并用该哈希值来表征本地数据的状态，构造确认消息发送给所有跟随者。这里可以理解为，系统中大部分节点所收集到的待共识数据列表会是一致的，因此只需要检查所有数据的整体哈希值是否一致即可知道两个节点的原始数据是否一致，数据量小，效率高。在步骤S3102中，等待跟随者的回复消息。在步骤S3103中，当收到回复消息之后，查看消息中的类型，如果是对领导者身份的确认消息，进入步骤S3107，否则进入步骤S3104。在步骤S3104中，查看消息中的类型，如果是请求所有待共识数据的哈希列表，进入步骤S3106，否则进入步骤S3105；所述的列表中可以包含每条待共识数据的哈希值。在步骤S3105中，发送跟随者需要的待共识原始数据；进入这一步表明领导者收集到的某几条待共识数据未被回复消息的跟随者收集到，这是允许的，因为系统中扩散的待共识数据，某些节点会由于网络等原因错过了。因此需要根据跟随者发过来的哈希值列表从领导者本地取出对应的原始共识数据，并发送给跟随者。为了性能上的考虑，领导者可以将每一次待共识的原始数据按照一定格式存储到内存，例如使用每次共识的唯一标号来标识。在步骤S3106中，发送跟随者需待共识数据的哈希列表，进入步骤S3102。进入这一步表明领导者和回复消息的跟随者所收集的待共识数据列表不一致，跟随者需要进一步校验领导者的身份合法性。这里发送哈希值而不是原始数据，同样是出于性能的考虑，可以减小数据量，提高运行速度。在步骤S3107中，可以将回复确认计数器加1，进入步骤S3108。在步骤S3108总，检查回复确认计数器是否满足门限值，如果不满足，返回步骤S3102，否则进入步骤S3109。这里的门限值具体代表多大比例可通过例如配置文件等方式来指定，增加系统的灵活性。在步骤S3109，清理确认阶段的临时数据，例如回复确认计数器等，结束确认阶段，并将自己的阶段切换到接受阶段。

图8示出根据一种实施例，去中心化共识方法中确认阶段的流程图。在步骤S3201中，跟随者验证节点可以将本地所收集的每条待共识数据生成哈希结果，形成一个哈希集，等待领导者发送确认消息。在步骤S3202中，进行消息筛选，可以根据消息中的类型判断是何种消息，例如如果是状态信息，则转向步骤S3203，如果是哈希列表信息，则转向步骤S3207，如果是原始数据列表信息，则转向步骤S3212。在步骤S3203中，判断节点之前是否已收到过状态确认消息，如果收到过，则转向步骤S3204，否则转向步骤S3205。在步骤S3204中，检测节点两次收到的状态确认消息是否一致，如果一致则转向步骤S3205，否则转向步骤S3208，原因是当前领导者发出的状态消息不一致会导致系统无法最终达成相同的一致。同样，在收到哈希列表信息和原始数据列表信息之后也需要检查之前是否已经收到过同一领导者相同类型的消息，如果收到过也是需要去检测一致性，防止领导者向不同节点扩散不同数据集信息，从而破坏系统的一致性。在步骤S3205中，可以比较接收到的领导者的状态信息和本地是否一致，如果一致，则转向步骤S3211，否则转向步骤S3206。在步骤S506中，请求当前领导者发送其本地所存储的待共识数据的哈希值列表的集合，并转向步骤S3201。进入这一步的原因是领导者的状态和本地状态不一致，也就是说两个节点所收集到的待共识数据集不相同，需要做进一步验证。在步骤S3207，可以判断所收到的数据哈希值列表长度是否满足阈值，如果满足则转向步骤S3209，否则转向步骤S3208。这里是为了防止恶意领导者只发送其本地的部分有效待共识数据，拖慢整个系统的效率，需要根据业务经验，设定阈值，假定在系统中的所有节点在最坏情况下至少可以收集到多少待共识的数据，一旦领导者发过来的数据量少于这个门限值，就认定当前领导者是恶意，需要重新选举领导者。即使当前领导者不是恶意的，少于阈值表明该节点的网络状况等不足以支撑系统正常运行，同样也是要认为他是恶意的节点。在步骤S3208中，首先在本地将当前领导者置为恶意，然后向系统中其他节点报告该消息。在步骤S3209中，可以检查领导者发过来的哈希值列表集合中的所有哈希值是否都在本地哈希集中，如果都在，表明领导者所收集的数据本节点都有，应该通过领导者的身份验证，转向步骤S3211，否则指向步骤S3210。在步骤S3210中，请求当前领导者发送其本地所存储的待共识原始数据列表，并转向步骤S3201。进入这一步的原因是领导者发送的数据哈希值列表中有某些哈希值本节点没有，也就是说某些数据本节点未收集到，需要向领导者请求原始数据，做进一步验证。在步骤S3211中，向当前领导者回复身份验证通过消息，表示同意以当前领导者的状态信息作为系统一致性的结果。在步骤S3212，判断所收到的原始数据列表中每条数据是否都合法，如果合法则转向步骤S3211，否则转向步骤S3208。

根据一种实施例，用于在具有多个验证节点的系统中实现去中心化共识的装置，可以包括用于多个验证节点中的第一验证节点接收待共识的数据。用于第一验证节点进行投票，以在多个验证节点中选举出具有领导者身份的验证节点。用于如果被选举为领导者，则第一验证节点向系统中的其他验证节点要求确认其合法。用于如果未被选举为领导者，则第一验证节点确认所选举的领导者是否合法。用于第一验证节点执行状态更新。一种示例中，用于多个验证节点中的第一验证节点接收待共识的数据的部分可以设置在消息处理模块中。用于如果被选举为领导者，则第一验证节点向系统中的其他验证节点要求确认其合法；用于如果未被选举为领导者，则第一验证节点确认所选举的领导者是否合法；以及用于第一验证节点执行状态更新的部分可以设置在共识核心模块中，所述的共识核心模块可以包括选举模块、确认模块以及接受模块，该选举模块，用于第一验证节点进行投票，以在多个验证节点中选举出具有领导者身份的验证节点；确认模块，用于如果被选举为领导者，则第一验证节点向系统中的其他验证节点要求确认其合法。用于如果未被选举为领导者，则第一验证节点确认所选举的领导者是否合法。接受模块，可以用于第一验证节点执行状态更新。该共识核心模块主要负责执行验证节点内的共识核心处理机制。消息处理模块主要负责与其他验证节点进行消息交互，可以包括消息发送，接收，过滤及分发三个子模块。

消息发送子模块可以负责将验证节点要发送给其他验证节点的消息按照既定格式封装，在实现中可以参考HTTP协议，将消息分为消息头和消息体，消息头格式固定且与消息体分离，同时采用protobuf等工具对消息序列化，便于消息接收方底层知道如何解释接收到的字节信息，封装之后再通过P2P方式发送出去。

消息接收子模块可以负责监听其他验证节点发过来的消息，并从中解析出消息内容，在实现中可采用epoll来实现监听，当有消息到来时，消息接收子模块被唤醒，按照既定消息格式去处理消息接收和解释已收到的字节信息，并将解释后的内容传送给消息过滤及分发子模块。

消息过滤及分发子模块可以负责按照既定规则对消息做过滤处理，并将符合条件的消息封装成事件，分发给特定的事件处理器处理。所述的既定规则例如可以是消息发送者是否是自己需要的、消息是否已经接收过了等等。

图9示出根据一个实施例的用于在具有多个验证节点的系统中实现去中心化共识的装置的结构示意图。该去中心化共识装置还可以包括配置管理模块，可以负责为验证节点的运行提供配置信息，并在接收到配置更改消息后，做出更改处理，让节点相关模块重启，保证节点的运行按照既定配置进行，例如：利用配置文件等方式来设置选举阶段和确认阶段的阈值，作为执行条件，在返回结果大于或等于阈值后执行相应操作。还可以配置验证节点的标识。在实现中可采用多种方式，例如web方式：通过浏览器展示节点当前的配置信息，使用者可根据需要改变配置信息，并提交到外部通信模块，由外部通信模块转给配置模块进行处理。

根据一个实施例，去中心化共识装置还可以包括辅助处理模块。该模块主要包括一些各个模块共用的组件和工具，如日志处理，加密解密，缓存处理等。其中日志处理负责按照既定格式记录节点的运行信息，可采用文件或者数据库等形式存储；加密解密负责消息的签名及验证，节点身份验证等；缓存处理负责缓存节点的状态等有关信息，可采用分布式存储系统即key-value内存数据库实现。该系统查询速度快、存放数据量大、支持高并发，非常适合通过主键进行查询，但不能进行复杂的条件查询。

根据一个实施例，去中心化共识装置还可以包括外部通信模块，用于提供通信接口来与外部进行通信，外部通信模块可以是应用程序编程接口模块例如负责提供API接口，通过更新接口与浏览器相连接，供系统内外交互，系统外操作者可通过该模块与系统内通信。实现时可采用多种方式，例如标准的web方式：设计RESTful API，操作者可在浏览器端获取系统当前状态信息，也可向系统发送特定指令，让系统执行某些特定操作。

根据一种实施例，去中心化共识系统包括多个前述的去中心化共识装置。在去中心化共识系统可以包括由多个中心化共识装置组成的验证池，每个中心化共识装置可以理解为一个验证节点，这里的验证池可以理解为专门负责校验需确认的数据并达成共识的验证节点构成的验证池，去中心化共识系统，将需要确认的数据例如交易、电子证据、数字记录等任何形式的电子数据发送给验证池中的所有验证节点，验证节点尽可能多地收集并存放本轮共识过程需要确认的所有数据，然后开始执行共识过程。

图10示出根据本发明一个实施例的去中心化共识的装置的结构示意图。处理设备可以采用通用计算机系统结构，计算机系统可具体是基于处理器的计算机。所述处理设备实体包括输入输出I/O接口101、存储器102、至少一个处理器103和至少一个通信接口104。其中，输入输出I/O接口101、存储器102、至少一个处理器103和至少一个通信接口104之间通过通信总线105连接。所述I/O接口101，用于接收来自用户设备的文本数据，并将所述文本数据传输给所述处理器103，其中，所述文本数据使用结构化查询语言SQL形式表示。处理器103可以是一个通用中央处理器(CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本发明方案程序执行的集成电路。其中，所述通信总线105可包括一通路，在上述组件之间传送信息。所述通信接口104，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线接入网(RAN)，无线局域网(Wireless Local Area Networks，WLAN)等。计算机系统包括一个或多个存储器102，可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(ElectricallyErasable Programmable Read-Only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。这些存储器102通过通信总线105与处理器103相连接。其中，所述存储器102用于存储执行本发明方案的应用程序代码，执行本发明方案的应用程序代码保存在存储器中，并由处理器103来控制执行。所述处理器103用于执行所述存储器102中存储的应用程序。

根据一种实施例，用于在具有多个验证节点的系统中实现去中心化共识的方法，可以假设系统中有5个节点(A，B，C，D，E)，其中C节点是恶意节点，其构造了一个恶意交易6。在共识开始前系统中提交了5个交易(1，2，3，4，5)，每个节点都只收到了其中4个(A：1，2，3，4，B：1，2，3，4，C：1，2，4，6，D：2，3，4，5，E：1，2，4，5)。现在进入选举阶段，A，B，C率先成为候选者，他们各自投自己一票，并向其他节点发起投票请求，A得到D的投票，C获得E的投票，其中，D，E在未成为候选者之前已经给其他节点投票了，所以不会再将自己身份切换为候选者。此轮选举没有节点胜出，所有候选者进入随机睡眠。由于C节点是恶意节点，它会不按既定规则行动，提前从睡眠中醒来，并在新的时隙号向其他节点发起投票请求，其他节点接到投票请求后发现时隙号比本地时隙号大，则均给C节点投票，C节点成为领导者，进入确认阶段。C节点将交易集整体做哈希运算，并将哈希值发送给其他节点，其他节点由于和C节点收集的交易集不一致，且其他节点均没有收集交易6，所以其他节点将会向C节点请求交易原始数据，那么恶意交易6将会被其他节点验证为非法，从而其他节点均会向系统发送当前领导者恶意的报告，并且每个节点会去计数，看有多少节点认为当前领导者是恶意的。假设A节点最先收到了除A、C以外的两个节点的报告，满足重新选举的阈值条件，这里的阈值具体代表多大比例可通过例如配置文件等方式来指定，增加系统的灵活性。于是A节点退回到选举阶段，重新发起选举，其他节点接到选举投票请求时发现自己也认为当前领导者是恶意的，于是B，D，E会给A投票，A节点成为新的领导者，进入确认阶段，并向其他节点发送其交易集的哈希运算结果。B节点接到A发来的状态信息，发现和自己本地状态结果一样，则直接回复身份验证通过，D和E会向A请求交易数据集中每条交易数据分别做哈希运算得到的哈希列表，并最终会请求交易原始数据(D没有交易1，E没有交易3)，然后做验证，并回复身份验证通过。当A收到超过阈值的身份验证通过的回复之后，会进入接受阶段，向其他节点发送接受消息，并执行交易集(1，2，3，4)，其他节点接到接受消息后也会执行交易集(1，2，3，4)，从而使得系统中大部分节点的状态达成一个正确的一致性结果。

应当注意，在权利要求中，单词“包含”或“包括”并不排除存在未列在权利要求中的元件或组件。位于元件或组件之前的冠词“一”或“一个”也并不排除存在多个这样的元件或组件的情况。

此外，还应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。关于本发明的范围，说明书中所做的描述都是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。

Claims (37)

1.一种用于在具有多个验证节点的系统中实现去中心化共识的方法，包括：

所述多个验证节点中的第一验证节点接收待共识的数据；

第一验证节点进行投票，以在所述多个验证节点中选举出具有领导者身份的验证节点；

如果被选举为领导者，则第一验证节点向系统中的其他验证节点要求确认其合法；

如果未被选举为领导者，则第一验证节点确认所选举的领导者是否合法；以及

第一验证节点执行状态更新。

2.如权利要求1所述的方法，其中，每个验证节点被配置有时隙号。

3.如权利要求2所述的方法，还包括：第一验证节点在投票之前执行初始化操作，

其中，所述初始化操作包括以下至少一项：将第一验证节点的身份设置为跟随者；将第一验证节点的时隙号设定为0；将所述待共识数据锁定。

4.如权利要求2所述的方法，其中，第一验证节点进行投票的步骤包括：

将第一验证节点的身份设置为候选者；

将第一验证节点的时隙号递增；

投自己一票；

向系统中的其他验证节点发起投票请求，该投票请求表明请求各个其他验证节点认可将第一验证节点选举为领导者；

接收其他验证节点中的第二验证节点对所述投票请求的投票请求回复；

如果投票请求回复表明第二验证节点认可将第一验证节点选举为领导者，则递增本地投票计数器；以及

检测本地投票计数器的计数值以确定第一验证节点是否被选举为领导者。

5.如权利要求4所述的方法，其中，第一验证节点进行投票的步骤还包括以下至少一项操作：

在发起投票请求的同时设置定时器，用于监视投票请求回复的超时；

检测投票请求回复是否符合所述系统的业务规定；

如果第二验证节点的时隙号大于第一验证节点的时隙号，则丢弃该投票请求回复，并向第二验证节点投一票；

如果投票请求回复针对的是较小时隙号的投票，则丢弃该投票请求回复。

6.如权利要求2所述的方法，其中，第一验证节点进行投票的步骤包括：

将第一验证节点的身份设置为候选者；

接收来自其他验证节点中的第二验证节点的投票请求；

如果第一验证节点的时隙号大于第二验证节点的时隙号，则向第二验证节点发起投票请求，该投票请求表明请求第二验证节点认可将第一验证节点选举为领导者；

如果第一验证节点的时隙号不大于第二验证节点的时隙号，则用第二验证节点的时隙号更新第一验证节点的时隙号，并向第二验证节点投一票。

7.如权利要求6所述的方法，其中，第一验证节点被配置有已投票标志，以避免第一验证节点重复投票。

8.如权利要求6所述的方法，其中，第一验证节点进行投票的步骤还包括以下至少一项操作：

检测所接收的投票请求是否符合所述系统的业务规定；

在投票的同时设置定时器，以监视投票回复的超时。

9.如权利要求6所述的方法，其中，第一验证节点进行投票的步骤还包括：

在对第一验证节点的时隙号和第二验证节点的时隙号进行比较之前，检测当前是否处于选举阶段以及所述待共识的数据是否处于锁定状态。

10.如权利要求6所述的方法，其中，第一验证节点进行投票的步骤还包括：

判断第一验证节点是否将当前领导者标记为恶意节点。

11.如权利要求1所述的方法，其中，第一验证节点确认所选举的领导者是否合法的步骤包括：

根据所述待共识数据生成哈希结果的集合；

从领导者接收确认消息；

确定所接收的确认消息的类型；

根据所述类型判定所选举的领导者是否合法。

12.如权利要求11所述的方法，其中，如果所述类型是状态信息，则第一验证节点执行以下操作：

如果第一验证节点此前收到过状态确认消息，并且所述状态信息与所述状态确认消息不一致，则报告所选举的领导者为恶意节点；

如果第一验证节点此前未收到过状态确认消息，并且所述状态信息与第一验证节点本地的状态信息不一致，则请求所选举的领导者发送其存储的待共识数据的哈希结果；否则

判定所选举的领导者合法。

13.如权利要求11所述的方法，其中，如果所述类型是数据的哈希列表，则第一验证节点执行以下操作：

如果哈希列表的长度不满足阈值，则报告所选举的领导者为恶意节点；

如果哈希列表的长度满足所述阈值，但包含不在所述哈希结果的集合中的元素，则请求所选举的领导者发送其存储的待共识数据的哈希结果；否则

判定所选举的领导者合法。

14.如权利要求11所述的方法，其中，如果所述类型是数据列表，则第一验证节点执行以下操作：

如果所述数据列表中的每条数据都合法，则判定所选举的领导者合法；否则

报告所选举的领导者为恶意节点。

15.如权利要求1所述的方法，其中，第一验证节点向系统中的其他验证节点要求确认其合法的步骤包括：

根据所述待共识数据生成哈希结果的集合；

对所述集合生成总体哈希值；

向所述其他验证节点发送状态信息，所述状态信息包括所述总体哈希值；

接收所述其他验证节点各自的回复消息；

当所述回复消息中对第一验证节点的确认消息的数目满足阈值时，判定为第一验证节点合法。

16.如权利要求15所述的方法，还包括：

如果所述其他验证节点中的第二验证节点的回复消息请求待共识数据的哈希列表，则向第二验证节点发送所述哈希结果的集合。

17.如权利要求15所述的方法，还包括：

如果所述其他验证节点中的第二验证节点的回复消息请求待共识数据的原始数据，则向第二验证节点发送所述待共识数据。

18.如权利要求4所述的方法，其中，第一验证节点进行投票的步骤还包括：

如果某一时隙没有选出领导者，则使第一验证节点进入睡眠状态；

第一验证节点在新的时隙号重新发起投票。

19.一种用于在具有多个验证节点的系统中实现去中心化共识的装置，包括：

用于由所述多个验证节点中的第一验证节点接收待共识的数据的模块；

用于所述第一验证节点进行投票，以在所述多个验证节点中选举出具有领导者身份的验证节点的模块；

用于如果被选举为领导者，则第一验证节点向系统中的其他验证节点要求确认其合法的模块；

用于如果未被选举为领导者，则第一验证节点确认所选举的领导者是否合法的模块；以及

用于第一验证节点执行状态更新的模块。

20.如权利要求19所述的装置，还包括配置管理模块，用于为每个验证节点配置时隙号。

21.如权利要求20所述的装置，其中，所述配置管理模块还包括用于第一验证节点在投票之前执行初始化操作的初始化模块，

其中，所述初始化模块包括以下至少一项：用于将第一验证节点的身份设置为跟随者的模块；用于将第一验证节点的时隙号设定为0的模块；用于将所述待共识数据锁定的模块。

22.如权利要求20所述的装置，其中，用于第一验证节点进行投票的模块包括：

用于将第一验证节点的身份设置为候选者的模块；

用于将第一验证节点的时隙号递增的模块；

用于投自己一票的模块；

用于向系统中的其他验证节点发起投票请求的模块，该投票请求表明请求各个其他验证节点认可将第一验证节点选举为领导者；

用于接收其他验证节点中的第二验证节点对所述投票请求的投票请求回复的模块；

用于如果投票请求回复表明第二验证节点认可将第一验证节点选举为领导者，则递增本地投票计数器的模块；以及

用于检测本地投票计数器的计数值以确定第一验证节点是否被选举为领导者的模块。

23.如权利要求22所述的装置，其中，用于第一验证节点进行投票的模块还包括以下至少一项：

用于在发起投票请求的同时设置定时器，用于监视投票请求回复的超时的模块；

用于检测投票请求回复是否符合所述系统的业务规定的模块；

用于如果第二验证节点的时隙号大于第一验证节点的时隙号，则丢弃该投票请求回复，并向第二验证节点投一票的模块；

用于如果投票请求回复针对的是较小时隙号的投票，则丢弃该投票请求回复的模块。

24.如权利要求20所述的装置，其中，用于第一验证节点进行投票的模块包括：

用于将第一验证节点的身份设置为候选者的模块；

用于接收来自其他验证节点中的第二验证节点的投票请求的模块；

用于如果第一验证节点的时隙号大于第二验证节点的时隙号，则向第二验证节点发起投票请求的模块，该投票请求表明请求第二验证节点认可将第一验证节点选举为领导者；

用于如果第一验证节点的时隙号不大于第二验证节点的时隙号，则用第二验证节点的时隙号更新第一验证节点的时隙号，并向第二验证节点投一票的模块。

25.如权利要求24所述的装置，其中，用于第一验证节点进行投票的模块还包括：用于将第一验证节点配置有已投票标志，以避免第一验证节点重复投票的模块。

26.如权利要求24所述的装置，其中，用于第一验证节点进行投票的模块还包括以下至少一项：

用于检测所接收的投票请求是否符合所述系统的业务规定的模块；

用于在投票的同时设置定时器，以监视投票回复的超时的模块。

27.如权利要求24所述的装置，其中，用于第一验证节点进行投票的模块还包括：

用于在对第一验证节点的时隙号和第二验证节点的时隙号进行比较之前，检测当前是否处于选举阶段以及所述待共识的数据是否处于锁定状态的模块。

28.如权利要求24所述的装置，其中，用于第一验证节点进行投票的模块还包括：

用于判断第一验证节点是否将当前领导者标记为恶意节点的模块。

29.如权利要求19所述的装置，其中，用于第一验证节点确认所选举的领导者是否合法的模块包括：

用于根据所述待共识数据生成哈希结果的集合的模块；

用于从领导者接收确认消息的模块；

用于确定所接收的确认消息的类型的模块；

用于根据所述类型判定所选举的领导者是否合法的模块。

30.如权利要求29所述的装置，其中，如果所述类型是状态信息，则所述装置还包括：

用于如果第一验证节点此前收到过状态确认消息，并且所述状态信息与所述状态确认消息不一致，则报告所选举的领导者为恶意节点的模块；

用于如果第一验证节点此前未收到过状态确认消息，并且所述状态信息与第一验证节点本地的状态信息不一致，则请求所选举的领导者发送其存储的待共识数据的哈希结果的模块；

用于当第一验证节点此前收到过状态确认消息，并且所述状态信息与所述状态确认消息不一致和第一验证节点此前未收到过状态确认消息，并且所述状态信息与第一验证节点本地的状态信息不一致的两种情况均未发生时判定所选举的领导者合法的模块。

31.如权利要求29所述的装置，其中，如果所述类型是数据的哈希列表，则所述装置还包括：

用于如果哈希列表的长度不满足阈值，则报告所选举的领导者为恶意节点的模块；

用于如果哈希列表的长度满足所述阈值，但包含不在所述哈希结果的集合中的元素，则请求所选举的领导者发送其存储的待共识数据的哈希结果的模块；

用于否则判定所选举的领导者合法的模块。

32.如权利要求29所述的装置，其中，如果所述类型是数据列表，则所述装置还包括：

用于如果所述数据列表中的每条数据都合法，则判定所选举的领导者合法的模块；

用于否则

报告所选举的领导者为恶意节点的模块。

33.如权利要求19所述的装置，其中，用于第一验证节点向系统中的其他验证节点要求确认其合法的模块包括：

用于根据所述待共识数据生成哈希结果的集合的模块；

用于对所述集合生成总体哈希值的模块；

用于向所述其他验证节点发送状态信息的模块，所述状态信息包括所述总体哈希值；

用于接收所述其他验证节点各自的回复消息的模块；

用于当所述回复消息中对第一验证节点的确认消息的数目满足阈值时，判定为第一验证节点合法的模块。

34.如权利要求33所述的装置，用于第一验证节点向系统中的其他验证节点要求确认其合法的模块还包括：

用于如果所述其他验证节点中的第二验证节点的回复消息请求待共识数据的哈希列表，则向第二验证节点发送所述哈希结果的集合的模块。

35.如权利要求33所述的装置，用于第一验证节点向系统中的其他验证节点要求确认其合法的模块还包括：

用于如果所述其他验证节点中的第二验证节点的回复消息请求待共识数据的原始数据，则向第二验证节点发送所述待共识数据的模块。

36.如权利要求22所述的装置，其中，用于第一验证节点进行投票的模块还包括：

用于如果某一时隙没有选出领导者，则使第一验证节点进入睡眠状态的模块；

用于第一验证节点在新的时隙号重新发起投票的模块。

37.一种用于在具有多个验证节点的系统中实现去中心化共识的方法，包括：

验证节点接收待共识的数据；

验证节点投票选举出具有领导者身份的验证节点同时产生跟随者身份的验证节点；

领导者向跟随者发送确认消息，并等待确认回复消息；

领导者接收跟随者返回的确认回复消息，并将返回的确认回复消息与设定的门限值进行比较；以及

收到返回的确认回复消息达到门限值后，结束确认阶段，让跟随者更新自己的状态。