CN116938951A - 区块链共识方法和系统、电子设备及存储介质 - Google Patents

Abstract

本申请提供了区块链共识方法和系统、电子设备及存储介质，属于区块链技术领域。该方法包括：主节点对数据进行封装打包，得到第一区块，第一区块包括第一数据包；主节点对第一数据包进行编码处理，得到编码结果；主节点根据编码结果生成提案消息，提案消息包括第一数据包的哈希值；主节点将提案消息分发给副本节点；副本节点将提案消息转发至其他副本节点；若副本节点接收到包含第一数据包的哈希值的不少于第一阈值的提案消息，对提案消息进行解码处理，得到第一数据包；副本节点和主节点中的任一节点对第一数据包进行投票处理，得到投票结果；节点将自身的投票结果广播；节点对第一区块进行确认。本申请能够降低通信复杂度从而提高共识的吞吐率。

Description

区块链共识方法和系统、电子设备及存储介质

技术领域

本申请涉及区块链技术领域，尤其涉及一种区块链共识方法和系统、电子设备及存储介质。

背景技术

目前，根据网络环境的不同，可以将拜占庭共识机制分为同步拜占庭共识、半同步拜占庭共识、和异步拜占庭共识。相关技术中，这三者相比，虽然同步拜占庭共识具有更高的容错能力，但同步拜占庭共识的吞吐量通常比其他两者低。

发明内容

本申请实施例的主要目的在于提出一种区块链共识方法和系统、电子设备及存储介质，旨在通过降低通信复杂度从而提高共识的吞吐率。

为实现上述目的，本申请实施例的第一方面提出了一种区块链共识方法，所述方法包括：

主节点对数据池中的数据进行封装打包处理，得到第一区块，其中，所述第一区块包括第一数据包和所述第一区块的前驱区块的哈希值；

所述主节点对所述第一数据包进行编码处理，得到编码结果，其中，所述编码结果包括至少一个编码块；

所述主节点根据所述编码结果生成提案消息，其中，所述提案消息包括第一数据包的哈希值；

所述主节点将所述提案消息分发给对应的副本节点，其中，各个所述副本节点收到的所述提案消息都不相同；

在所述副本节点接收到所述提案消息后，所述副本节点将所述提案消息转发至其他副本节点；

针对每一个所述副本节点，若所述副本节点接收到包含所述第一数据包的哈希值的不少于第一预设阈值的所述提案消息，对所述提案消息进行解码处理，得到所述第一数据包；

所述副本节点和主节点中的任一节点对所述第一数据包进行投票处理，得到自身对第一数据包的投票结果；

所述副本节点和主节点中的任一节点将所述自身对第一数据包的投票结果广播至其他所有节点；

所述副本节点和主节点中的任一节点对所述第一区块进行确认。

在一些实施例，所述方法包括主节点的视图切换，所述视图切换由以下方式实现：

针对每一个所述副本节点，当确定所述主节点为恶意主节点时，所述副本节点生成退出第一视图消息并广播至其他所有节点；

经过第一预设时间，所述副本节点将已知的最高认证区块发送至更新后的主节点，同时进入第二视图；

所述更新后的主节点进入所述第二视图后经过第二预设时间生成新视图消息，将所述新视图消息广播至其他所有节点；

所述副本节点接收到所述新视图消息，若所述已知的最高认证区块的区块高度不小于所述副本节点锁定的区块的区块高度，则副本节点转发所述新视图消息，并广播对所述已知的最高认证区块的投票结果。

在一些实施例，所述主节点由以下方式更新：

确定所述第一视图的视图编号和总节点数，其中，所述总节点数根据所述主节点的主节点数和所述副本节点的副本节点数计算得到；

将所述视图编号与所述总节点数进行求余计算，得到余数；

将多个所述节点中编号与所述余数数值相同的节点作为更新后的主节点。

在一些实施例，所述主节点对所述第一数据包进行编码处理，得到编码结果，包括：

获取故障节点数和总节点数；

根据所述故障节点数确定第一数量；

根据所述第一数量对所述第一数据包进行等分处理，得到第一字符序列；

根据预先构建的生成矩阵对第一字符序列进行编码处理，得到第二字符序列，其中，所述第二字符序列中的每个字符代表一个编码块，所述编码块的数量与所述总节点数相同；

将所述第二字符序列作为编码结果。

在一些实施例，在所述副本节点和主节点中的任一节点对所述第一区块进行确认之前，所述方法还包括：

若所述副本节点未接收到包含所述第一数据包的哈希值的不少于第一预设阈值的所述提案消息，则判断所述节点是否接收到不少于第二预设阈值的包含所述第一数据包的哈希值的投票结果；

当所述副本节点接收到不少于第二预设阈值的包含所述第一数据包的哈希值的投票结果时，所述副本节点生成跟随请求并将所述跟随请求广播至其他所有节点；

当所述副本节点接收到不少于第三预设阈值的由所述第一数据包编码成的编码块时，对编码块进行解码，得到所述第一数据包。

在一些实施例，所述方法还包括流动迟滞模型，所述副本节点和主节点中的任一节点对所述第一区块进行确认，包括：

在当前视图中，若所述主节点收到不少于第四预设阈值的对第一数据包的投票结果时，则所述主节点对所述第一区块进行聚合签名的构造，得到第一认证区块，以对所述第一区块进行确认；

根据所述第一认证区块，所述主节点生成第二区块的提案消息；

当所述副本节点接收到不少于第五预设阈值的第二区块提案消息时，开启针对第一区块的计时器；

当所述计时器的数值降为0，并且没有发生视图切换，所述副本节点广播确认消息以对所述第一区块进行确认。

在一些实施例，所述主节点的视图包括普通模式和快速响应模式，在所述主节点对数据池中的数据进行封装打包处理，得到第一区块之前，所述方法包括：

将视图编号为奇数的视图设置为普通模式，将视图编号为偶数的视图设置为快速响应模式；

所述方法还包括对当前视图的模式进行视图切换，具体包括：

若当前视图的视图编号为奇数，则将所述当前视图的视图编号与1进行相加，以将当前视图由普通模式切换为快速响应模式；

若当前视图的视图编号为偶数，则将所述当前视图的视图编号与2进行相加，以将当前视图的下一个视图保持为快速响应模式。

为实现上述目的，本申请实施例的第二方面提出了一种区块链共识系统，所述系统包括：

数据封装打包模块，用于主节点对数据池中的数据进行封装打包处理，得到第一区块，其中，所述第一区块包括第一数据包和所述第一区块的前驱区块的哈希值；

编码模块，用于所述主节点对所述第一数据包进行编码处理，得到编码结果，其中，所述编码结果包括至少一个编码块；

提案生成模块，用于所述主节点根据所述编码结果生成提案消息，其中，所述提案消息包括第一数据包的哈希值；

分发模块，用于所述主节点将所述提案消息分发给对应的副本节点，其中，各个所述副本节点收到的所述提案消息都不相同；

转发模块，用于在所述副本节点接收到所述提案消息后，所述副本节点将所述提案消息转发至其他副本节点；

解码模块，用于针对每一个所述副本节点，若所述副本节点接收到包含所述第一数据包的哈希值的不少于第一预设阈值的所述提案消息，对所述提案消息进行解码处理，得到所述第一数据包；

投票模块，用于所述副本节点和主节点中的任一节点对所述第一数据包进行投票处理，得到自身对第一数据包的投票结果；

广播模块，用于所述副本节点和主节点中的任一节点将所述自身对第一数据包的投票结果广播至其他所有节点；

确认模块，用于所述副本节点和主节点中的任一节点对所述第一区块进行确认。

为实现上述目的，本申请实施例的第三方面提出了一种电子设备，所述电子设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述第一方面所述的方法。

为实现上述目的，本申请实施例的第四方面提出了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的方法。

本申请提出的区块链共识方法和系统、电子设备及存储介质,其通过主节点对数据池中的数据进行封装打包处理，得到第一区块，其中，第一区块包括第一数据包和第一区块的前驱区块的哈希值；主节点对第一数据包进行编码处理，得到编码结果，其中，编码结果包括至少一个编码块；主节点根据编码结果生成提案消息，其中，提案消息包括第一数据包的哈希值，能够通过对数据进行编码，再根据编码结果生成提案消息，相比于直接根据数据生成提案消息，缩小了提案消息的占用空间大小，从而降低了通信的复杂度。进一步地，主节点将提案消息分发给对应的副本节点，其中，各个副本节点收到的提案消息都不相同，通过将对不同的提案消息只进行一次分发给不同的副本节点，降低了主节点与副本节点之间通信的资源占用，从而降低了通信的复杂度。进一步地，在副本节点接收到提案消息后，副本节点将提案消息转发至其他副本节点，通过副本节点与副本节点之间的转发使副本节点能够接收到不同的提案消息。进一步地，针对每一个副本节点，若副本节点接收到包含第一数据包的哈希值的不少于第一预设阈值的提案消息，对提案消息进行解码处理，得到第一数据包；副本节点和主节点中的任一节点对第一数据包进行投票处理，得到自身对第一数据包的投票结果；副本节点和主节点中的任一节点将自身对第一数据包的投票结果广播至其他所有节点；副本节点和主节点中的任一节点对第一区块进行确认，通过得到部分而非所有的提案消息解码得到第一数据包，提高了共识的速度，再对第一数据包进行投票处理，最后对区块进行确认，实现对区块的共识。这一方式能够通过降低通信复杂度，即降低每次通信的资源占用率从而提高每次通信能处理的任务量，以提高共识的吞吐率。

附图说明

图1是本申请实施例提供的区块链共识方法的流程图；

图2是本申请实施例提供的区块链共识方法中当前视图的模式切换的流程图；

图3是本申请实施例提供的区块链共识方法中当前视图切换的流程图；

图4是本申请实施例提供的区块链共识方法中主节点更新的流程图；

图5是图1中的步骤S102的流程图；

图6是本申请实施例提供的区块链共识方法的另一流程图；

图7是本申请实施例提供的区块链共识方法在流动迟滞模型的对第一区块进行确认的流程图；

图8是本申请实施例提供的区块链共识方法的标准同步模型的实现过程示意图；

图9是本申请实施例提供的区块链共识系统的结构示意图；

图10是本申请实施例提供的电子设备的硬件结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

需要说明的是，虽然在系统示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于系统中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

首先，对本申请中涉及的若干名词进行解析：

哈希函数：哈希函数是一类压缩函数，可以将任意长度的比特串映射到固定长度的比特串上，该长度为哈希函数的输出。如SHA-256哈希算法的输出长度为256比特。在使用抗碰撞的哈希函数时，依据一个区块去构造另一个具有相同哈希值的区块是不可行的。

数字签名：数字签名是只有消息的发送者才能产生的其他对象无法伪造的一段数字串，这段数字串同时也是对消息的发送者发送消息的真实性的有效证明。在区块链中引入数字签名，任意一个诚实节点发出的消息都不能被仿冒，任意一个节点也不能抵赖已签名的消息。本申请通过用表示节点r对消息/>的签名。

继承关系：区块或者片段之间存在继承关系。假设为一个区块或者片段，/>为一个区块，继承关系由以下规则定义：/>继承/>自身；若/>包含/>的哈希值，则称/>继承自/>；若/>继承自/>，则/>继承自/>的前驱区块；若/>继承自/>，则/>继承自/>的所有片段。

认证区块：认证区块顾名思义为认证的区块，通过对区块进行聚合签名的构造，得到认证区块。

区块高度：区块高度顾名思义为区块的高度，准确来说是连接在区块链上的块数。同一条链上，区块高度与区块上链的顺序有关，顺序越后，区块的高度越高。

其次，对本申请涉及的背景技术进行描述。

目前，根据网络环境的不同，可以将拜占庭共识机制分为同步拜占庭共识、半同步拜占庭共识、和异步拜占庭共识。相关技术中，这三者相比，虽然同步拜占庭共识具有更高的容错能力，但同步拜占庭共识的吞吐量通常比其他两者低。

基于此，本申请实施例提出一种区块链共识方法和系统、电子设备及存储介质，旨在通过降低通信复杂度从而提高共识的吞吐率。

本申请实施例提供的区块链共识方法和系统、电子设备及存储介质，具体通过如下实施例进行说明，首先描述本申请实施例中的区块链共识方法。

本申请实施例提供的区块链共识方法，涉及区块链技术领域。本申请实施例提供的区块链共识方法可应用于终端中，也可应用于服务器端中，还可以是运行于终端或服务器端中的软件。在一些实施例中，终端可以是智能手机、平板电脑、笔记本电脑、台式计算机等；服务器端可以配置成独立的物理服务器，也可以配置成多个物理服务器构成的服务器集群或者分布式系统，还可以配置成提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN以及大数据和人工智能平台等基础云计算服务的云服务器；软件可以是实现区块链共识方法的应用等，但并不局限于以上形式。

本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

需要说明的是，在本申请的各个具体实施方式中，当涉及到需要根据对象信息、对象行为数据，对象历史数据以及对象位置信息等与对象身份或特性相关的数据进行相关处理时，都会先获得对象的许可或者同意，而且，对这些数据的收集、使用和处理等，都会遵守相关法律法规和标准。此外，当本申请实施例需要获取对象的敏感个人信息时，会通过弹窗或者跳转到确认页面等方式获得对象的单独许可或者单独同意，在明确获得对象的单独许可或者单独同意之后，再获取用于使本申请实施例能够正常运行的必要的对象相关数据。

图1是本申请实施例提供的区块链共识方法的一个可选的流程图，图1中的方法可以包括但不限于包括步骤S101至步骤S109：

步骤S101，主节点对数据池中的数据进行封装打包处理，得到第一区块，其中，第一区块包括第一数据包和第一区块的前驱区块的哈希值；

步骤S102，主节点对第一数据包进行编码处理，得到编码结果，其中，编码结果包括至少一个编码块；

步骤S103，主节点根据编码结果生成提案消息，其中，提案消息包括第一数据包的哈希值；

步骤S104，主节点将提案消息分发给对应的副本节点，其中，各个副本节点收到的提案消息都不相同；

步骤S105，在副本节点接收到提案消息后，副本节点将提案消息转发至其他副本节点；

步骤S106，针对每一个副本节点，若副本节点接收到包含第一数据包的哈希值的不少于第一预设阈值的提案消息，对提案消息进行解码处理，得到第一数据包；

步骤S107，副本节点和主节点中的任一节点对第一数据包进行投票处理，得到自身对第一数据包的投票结果；

步骤S108，副本节点和主节点中的任一节点将自身对第一数据包的投票结果广播至其他所有节点；

步骤S109，副本节点和主节点中的任一节点对第一区块进行确认。

本申请实施例所示意的步骤S101至步骤S109，通过主节点对数据池中的数据进行封装打包处理，得到第一区块，其中，第一区块包括第一数据包和第一区块的前驱区块的哈希值；主节点对第一数据包进行编码处理，得到编码结果，其中，编码结果包括至少一个编码块；主节点根据编码结果生成提案消息，其中，提案消息包括第一数据包的哈希值，能够通过对数据进行编码，再根据编码结果生成提案消息，相比于直接根据数据生成提案消息，缩小了提案消息的占用空间大小，从而降低了通信的复杂度。进一步地，主节点将提案消息分发给对应的副本节点，其中，各个副本节点收到的提案消息都不相同，通过将对不同的提案消息只进行一次分发给不同的副本节点，降低了主节点与副本节点之间通信的资源占用，从而降低了通信的复杂度。进一步地，在副本节点接收到提案消息后，副本节点将提案消息转发至其他副本节点，通过副本节点与副本节点之间的转发使副本节点能够接收到不同的提案消息。进一步地，针对每一个副本节点，若副本节点接收到包含第一数据包的哈希值的不少于第一预设阈值的提案消息，对提案消息进行解码处理，得到第一数据包；副本节点和主节点中的任一节点对第一数据包进行投票处理，得到自身对第一数据包的投票结果；副本节点和主节点中的任一节点将自身对第一数据包的投票结果广播至其他所有节点；副本节点和主节点中的任一节点对第一区块进行确认，通过得到部分而非所有的提案消息解码得到第一数据包，提高了共识的速度，再对第一数据包进行投票处理，最后对区块进行确认，实现对区块的共识。这一方式能够通过降低通信复杂度，即降低通信的资源占用率从而提高共识的吞吐率。

需要说明的是，本申请实施例主要针对同步网络场景，即从一个节点到另一个节点的消息都可以在同步时延上界时间内到达。本申请实施例将每个状态机作为一个节点，而节点包括一个主节点和多个副本节点，根据主节点数和副本节点数得到总节点数，总节点数记为/>。其中，节点分为恶意节点和诚实节点，诚实节点指的是区块链中能够严格遵守协议的内容进行工作的节点，恶意节点指的是区块链中不受任何约束的节点。基于此，由于约束条件仅能够限制诚实节点，而无法限制恶意节点，在本申请实施例中将恶意节点归为故障节点，将故障节点数记为/>。进一步地，本申请实施例的共识方法是面向诚实节点的，应当理解的是，本申请实施例中所描述的节点为诚实节点。在某些情况下，恶意节点会作出与诚实节点相同的操作；在另一些情况下，恶意节点会作出与诚实节点不同的操作。

需要说明的是，由于同步拜占庭共识算法可以解决存在不多于个恶意节点的场景，因此，当/>只包含恶意节点时，总存在/>。

进一步地，本申请实施例的区块链共识过程包括两个阶段：稳定阶段和视图切换阶段。具体地，在稳定阶段中，由主节点将数据池中的数据进行打包封装至区块，并将区块进行分发，各个节点遵循协议达成共识，并持续确认区块。在视图切换阶段中，一个主节点可以持续主持多轮共识，直到该主节点被观察到存在恶意行为后，进入视图切换阶段。其中，每个主节点的任期称为一个视图，从一个视图进入下一个视图的过程叫视图切换。

本申请实施例首先对视图切换阶段进行详细描述。

在区块链中，恶意主节点的表现包括三种恶意行为：矛盾、错误、和沉默。其中，矛盾是指两个区块或片段不存在继承关系，此时两个由主节点签名的矛盾的区块或片段可以作为主节点恶意行为的证据。错误是指一个可解码的片段集合所解码出的共识内容与片段集的哈希值不匹配，此时一个错误的可解码片段集可以作为主节点恶意行为的证据。沉默是指主节点没能在一定的时间内提供足够的可解码片段集，例如，如果一个副本节点在时间内没能成功解码/>个区块的数据包，则会广播惩罚信息，此时收集/>个惩罚信息可作为主节点恶意行为的证据，其中，/>的取值范围为/>，每个区块都有一个数据包。恶意行为会导致诚实节点不能达成一致，当主节点存在恶意行为被检测出并形成证据后，会进入视图切换阶段，更换主节点。

在本申请实施例中会将主节点的视图设置为普通模式、或者快速响应模式。下面分别对普通模式和快速响应模式进行描述：

在普通模式下，一个认证区块由个投票结果组成，即一个认证区块需要不少于/>个投票结果来构造，且确认区块的延迟依赖于所设置的计时器，也就是同步时延上界/>。

但是，当主节点对于同一个区块收到多余个节点的投票结果之后，其余的恶意节点就无法与诚实节点串谋来提供另外/>个投票结果来生成另一个认证区块。因此，当收到一个超过/>个节点投票过的认证区块时，节点就可以直接确认区块，不需要计时器计时进行等待，这种情况被称为快速响应模式。因此，在快速响应模式下，一个认证区块由/>个投票结果组成。

为了区分不同的视图，本申请实施例中的视图均设置有一个视图编号，视图编号用于区分不同的视图，即各个视图的视图编号具有唯一性。需要说明的是，本申请实施例中的各个视图的视图编号方式根据实际需求确定，不做限制。

在一些实施例的步骤S101之前，区块链共识方法还包括将视图编号为奇数的视图设置为普通模式，将视图编号为偶数的视图设置为快速响应模式。

进一步地，请参阅图2，区块链共识方法还包括对当前视图的模式进行切换，具体包括但不限于包括步骤S201至步骤S202：

步骤S201，若当前视图的视图编号为奇数，则将当前视图的视图编号与1进行相加，以将当前视图由普通模式切换为快速响应模式；

步骤S202，若当前视图的视图编号为偶数，则将当前视图的视图编号与2进行相加，以将当前视图的下一个视图保持为快速响应模式。

下面对步骤S201至步骤S202进行详细描述。

在一些实施例的步骤S201中，如果当前视图的视图编号为奇数，表示当前视图的主节点模式为普通模式，则将当前视图的视图编号与1进行相加，能够将当前视图由普通模式切换为快速响应模式。假设当前视图的视图编号为，当前视图的下一个视图的视图编号为/>，则通过/>将普通模式切换为快速响应模式。相应地，将当前视图的视图编号与2进行相加，能够将当前视图的下一个视图保持为普通模式，即通过/>能够将视图保持为普通模式。

在一些实施例的步骤S202中，如果当前视图的视图编号为偶数，表示当前视图的主节点模式为快速响应模式，则将当前视图的视图编号与1进行相加，能够将当前视图由快速响应模式切换为普通模式，即通过将快速响应模式切换为普通模式。相应地，将当前视图的视图编号与2进行相加，能够将当前视图的下一个视图保持为快速响应模式，即通过/>能够将视图保持为快速响应模式。

通过上述步骤S201至步骤S202能够实现普通模式和快速响应模式的灵活切换，能够提高确认区块的效率。

下面对主节点的视图模式为普通模式时的视图切换过程进行详细描述。

请参照图3，在一些实施例中，主节点的视图模式为普通模式时的视图切换过程可以包括但不限于包括步骤S301至步骤S304：

步骤S301，针对每一个副本节点，当确定主节点为恶意主节点时，副本节点生成退出第一视图消息并广播至其他所有节点；

步骤S302，经过第一预设时间，副本节点将已知的最高认证区块发送至更新后的主节点，同时进入第二视图；

步骤S303，更新后的主节点进入第二视图后经过第二预设时间生成新视图消息，将新视图消息广播至其他所有节点；

步骤S304，副本节点接收到新视图消息，若已知的最高认证区块的区块高度不小于副本节点锁定的区块的区块高度，则副本节点转发新视图消息，并广播对已知的最高认证区块的投票结果。

下面对步骤S301至步骤S304进行详细描述。

首先对步骤S301进行描述，步骤S301为退出视图步骤。

在一些实施例的步骤S301中，第一视图表示当前视图，第一视图的视图编号可以表示为。退出第一视图消息常常由四个部分构成，即退出视图消息标识、主节点恶意的证据、当前视图的视图编号、以及一个哈希值的签名，其中，哈希值是副本节点对视图消息标识、主节点恶意的证据、和当前视图的视图编号进行哈希的结果。具体地，针对每一个副本节点，在副本节点/>发现主节点的恶意的证据/>时，副本节点/>会生成退出第一视图消息，退出第一视图消息可以表示为/>，其中，/>为退出视图消息标识。在生成退出第一视图消息后，副本节点/>会将退出第一视图消息/>广播给其他节点，并且退出第一视图/>。

进一步地，当其他节点收到一个退出第一视图消息后，会将收到的退出第一视图消息进行转发，并退出第一视图。

进一步地，当其他节点在接收、以及转发退出第一视图消息时，常常需要判断退出第一视图消息是否有效。具体地，判断退出第一视图消息是否有效的方式包括但不限于以下方式：

若退出第一视图消息中的视图编号与当前视图的编号不同，则确定这个退出第一视图消息无效；

若退出第一视图消息中不存在签名或者签名的副本节点不存在，则确定这个退出第一视图消息无效。

由于当主节点为恶意节点时，常常会影响共识的准确性和安全性，因此，在执行步骤S302之前，常常需要选举更新后的主节点。

请参阅图4，在一些实施例中，主节点更新的过程可以包括但不限于包括步骤S401至步骤S403：

步骤S401，确定第一视图的视图编号和总节点数，其中，总节点数根据主节点的主节点数和副本节点的副本节点数计算得到；

步骤S402，将视图编号与总节点数进行求余计算，得到余数；

步骤S403，将多个节点中编号与余数数值相同的节点作为更新后的主节点。

下面对步骤S401至步骤S403进行详细描述。

在一些实施例的步骤S401中，第一视图的视图编号可以从退出第一视图消息中获取。总节点数根据主节点的主节点数和副本节点的副本节点数计算得到。其中，主节点数指的是主节点的总数目，副本节点数指的是副本节点的总数目。

一般，主节点的主节点数为1个，副本节点的副本节点数为多个。假设主节点数为1个，副本节点数为n个，则总节点数为n+1个。

在一些实施例的步骤S402中，通过求余公式对视图编号与总节点数进行计算。其中，求余公式为mod函数。具体地，在求余计算时，视图编号为被除数，总节点数/>为除数，通过mod函数进行计算得到余数/>，记为/>。

为了提高主节点的选举效率，在一些实施例的步骤S403之前，常常需要对所有节点进行编号，得到节点编号。其中，每个节点编号是唯一的，也是固定的。在编号时，可以是通过随机分配进行节点编号的分配，也可以通过指定的方式进行节点编号的分配，编号从0至n-1共计n个节点。

在一些实施例的步骤S403中，在所有节点中，找到节点编号与余数数值相同的节点，将该节点作为更新后的主节点。

通过上述步骤S401至步骤S403能够通过求余函数选举出更新后的主节点，避免更新后的主节点与上一个主节点重复。

接着，对步骤S302进行描述，步骤S302为更新状态步骤。

在一些实施例的步骤S302中，第一预设时间可以是，也可以是/>，根据实际需求设置。认证区块为构造了聚合签名的区块，最高认证区块则是区块高度最高的认证区块，最高认证区块记为/>，意味着在视图/>中对区块/>进行认证得到的认证区块。第二视图区别于第一视图，第二视图是第一视图的下一个视图，第二视图的视图编号可以是第一视图的视图编号与1相加得到的。具体地，在经过第一预设时间，副本节点/>将自身的已知的最高认证区块/>发送至更新后的主节点/>，并将自身锁定在/>，同时副本节点/>进入第二视图/>。

需要注意的是，多个副本节点将自身的已知的最高认证区块发送至更新后的主节点，而主节点在多个认证区块中选取一个最高的认证区块作为已知的最高认证区块。

接着，对步骤S303进行描述，步骤S303为新视图步骤。

在一些实施例的步骤S303中，第二预设时间可以是，也可以是/>，根据实际需求设置。为了接收副本节点发送的最高认证区块，第二预设时间需要比第一预设时间更长。新视图消息包括四个部分，即视图更新消息标识、新视图的视图编号、最高认证区块、以及一个哈希值的签名，其中，哈希值是更新后的主节点对视图更新消息标识、新视图的视图编号、和最高认证区块进行哈希的结果。具体地，更新后的主节点/>在进入第二视图/>后，等待/>的时间，生成新视图消息，新视图消息可以表示为，其中，/>为视图更新消息标识；/>为新视图的视图编号。在生成新视图消息后，更新后的主节点将新视图消息广播至其他所有节点。

进一步地，对步骤S304进行描述，步骤S304为视图开始步骤。

在一些实施例的步骤S304中，投票结果包括投票消息标识、数据包的哈希值、当前视图的视图编号、以及一个哈希值的签名，其中，哈希值是副本节点对投票消息标识、数据包的哈希值、和当前视图的视图编号进行哈希的结果。认证区块的投票消息包括投票消息标识、认证区块的哈希值、当前视图的视图编号、以及一个哈希值的签名，其中，哈希值是副本节点对投票消息标识、认证区块的哈希值、和当前视图的视图编号进行哈希的结果。

具体地，副本节点首先接收到新视图消息，从新视图消息中获取已知的最高认证区块的区块高度。接着，将已知的最高认证区块的区块高度与副本节点本身锁定的区块的区块高度进行比较。若已知的最高认证区块的区块高度不小于副本节点锁定的区块的区块高度，则副本节点生成对已知的最高认证区块的投票结果/>。其中，/>为投票消息标识，/>为最高认证区块的哈希值。进一步地，副本节点在生成投票结果时，还会转发新视图消息/>，并将投票结果广播给其他所有节点。进一步地，更新后的主节点在收集到/>个不同的投票结果之后，会转到稳定阶段。

通过上述步骤S301至步骤S304能够在更新主节点的同时切换视图，能够提高区块链共识的处理效率。

需要说明的是，主节点的视图为快速响应模式时的视图切换流程也包括但不限于包括退出视图、更新状态、新视图、视图开始这四个步骤。其中，新视图与视图开始这两个步骤与普通模式的一致，而退出视图与更新状态这两个步骤与普通模式的存在差异。下面对主节点的视图为快速响应模式时的视图切换流程的退出视图步骤和更新状态步骤进行描述：

在退出视图步骤中，针对每一个副本节点，当确定主节点为恶意主节点时，副本节点生成退出第一视图消息并广播至其他所有节点。其中，当一个诚实的副本节点收到退出第一视图消息，则会转发退出第一视图消息并退出当前视图。恶意节点的行为不可预估，可以做出任何遵守协议或者违反协议的动作。

在更新状态步骤中，首先节点需要收集退出第一视图消息，在收集到个退出第一视图消息后，经过第一预设时间，副本节点将已知的最高认证区块发送至更新后的主节点，同时进入第二视图。

以上是对本申请实施例的视图切换阶段的详细描述。接下来，对本申请实施例的普通模式下的稳定阶段（即标准同步模型的稳定阶段）进行详细描述。

首先，对步骤S101进行描述，步骤S101为数据封装打包步骤。

在一些实施例的步骤S101中，主节点响应于对象的共识请求，对数据池中的数据进行封装打包处理，得到第一数据包，继而得到对应的第一区块。第一区块表示为，其中，/>表示区块的高度；/>表示前驱区块/>的哈希值。具体地，若/>=1，则/>为创世区块，创世区块的前驱区块为空。

接着，对步骤S102进行描述，步骤S102为编码步骤。

请参阅图5，在一些实施例中，步骤S102可以包括但不限于包括步骤S501至步骤S505：

步骤S501，获取故障节点数和总节点数；

步骤S502，根据故障节点数确定第一数量；

步骤S503，根据第一数量对第一数据包进行等分处理，得到第一字符序列；

步骤S504，根据预先构建的生成矩阵对第一字符序列进行编码处理，得到第二字符序列，其中，第二字符序列中的每个字符代表一个编码块，编码块的数量与总节点数相同；

步骤S505，将第二字符序列作为编码结果。

下面对步骤S501至步骤S505进行详细描述。

在一些实施例的步骤S501中，在标准同步模型中，故障节点即为恶意节点。故障节点数就是恶意节点的数量，总节点数就是所有节点的数量。故障节点数和总节点数都是预先设置的，协议在部署之后不可更改。

在一些实施例的步骤S502中，根据故障节点数得到第一数量。具体地，故障节点数为，第一数量为/>。在标准同步模型中，故障节点都为恶意节点，如果第一数量低于，那么只要所有的恶意节点之间相互通信，就能够成功解码得到第一数据包，而诚实节点发现不了恶意节点的解码操作。同时，由于诚实节点至少有/>个，在第一数量高于诚实节点的数量的情况下，若所有恶意节点沉默或者做违反协议的操作时，所有的诚实节点也不能成功解码。因此，通过将第一数量设置为/>，既保证了恶意节点即使串通也不能绕过诚实节点进行解码操作，又保证了在所有恶意节点不提供编码块的情况下能进行解码操作。

在一些实施例的步骤S503中，第一字符序列用于存储数据块。根据第一数量将第一数据包进行等分处理，得到第一字符序列。具体地，将第一数据包等分为/>个数据块，将第一个数据块表示为/>，第二个数据块表示为/>，以此类推，第/>个数据块表示为/>，继而得到第一字符序列/>，第一字符序列即为数据块序列。

在一些实施例的步骤S504中，预先构建的生成矩阵是根据总节点数和第一数量构建的；第二字符序列用于存储编码块。

在步骤S504具体实现时，可以根据生成矩阵对第一字符序列进行编码，得到第二字符序列。具体地，生成矩阵表示为，生成矩阵具体可采用MDS编码方式构建，接着通过编码公式得到第二字符序列/>，即数据块的编码块，其中，/>表示第1个编码块，以此类推，/>表示第/>个编码块。其中，编码公式如公式（1）所示：

，公式（1）

其中，是长度为/>的编码前序列，/>是长度为/>的编码后序列。只要部分数量的编码后的编码块，可以解码得到原先的/>个数据块从而恢复成第一数据包。

在一些实施例的步骤S505中，可以将第二字符序列作为编码结果。其中，编码结果包括个编码块，编码结果具体可以表示为/>。

通过上述步骤S501至步骤S505能够通过对数据进行编码，再根据编码结果生成提案消息，相比于直接根据数据生成提案消息，缩小了提案消息的占用空间大小，从而降低了通信的复杂度。同时，通过采用编码技术使节点能够通过获取部分编码块解码出原数据包，从而提高了共识的效率。

为了校验第一数据包的编解码过程中的数据完整性，在获取到编码结果后，将编码结果中每一个编码块的哈希值作为叶节点生成默克尔树，得到默克尔根，以便在后续的解码过程中根据默克尔根验证数据包的数据完整性。其中，第一数据包对应的默克尔根表示为/>。

接着，对步骤S103进行描述，步骤S103为提案生成步骤。

在一些实施例的步骤S103中，提案消息包括提案消息标识、副本节点关于当前区块的编码块、前驱区块的哈希值、第一数据包的哈希值、当前视图的视图编号、前驱认证区块、第一数据包的默克尔根、以及一个哈希值的签名，其中，哈希值是主节点对提案消息标识、副本节点关于当前区块的编码块、前驱区块的哈希值、第一数据包的哈希值、当前视图的视图编号、前驱认证区块、和第一数据包的默克尔根进行哈希的结果,提案消息记为，其中，/>为节点编号，。提案消息由主节点根据编码结果生成。

具体地，主节点将编码结果/>编码成对应的提案消息，即根据编码结果中的第一个编码块/>生成第一个提案消息，以此类推，根据编码结果中的第n个编码块/>生成第n个提案消息。通过对消息内容的哈希值进行签名，与对消息内容本身进行签名相比，提高了签名速度和签名安全性。

需要注意的是，记为区块/>属于节点/>的片段。因此，当一个片段的集合包含了不少于/>个不同的片段并且所有片段拥有相同的哈希值时，则称这个片段集合是可以解码的。解码意味着能够通过片段集合中的片段得到原始的数据包，即当获取了/>个不同的/>，并且/>中的第一数据包的哈希值和前驱区块的哈希值都一样时，则可以通过该个不同的/>获得第一数据包。

接着，对步骤S104进行描述，步骤S104为分发步骤。

在一些实施例的步骤S104中，主节点将提案消息分发给对应的副本节点。具体地，主节点将提案消息分发给节点编号为/>的副本节点，此时，主节点会将与主节点的节点编号对应的提案消息广播给其他节点。因此，在同一视图中，各个副本节点收到的由主节点分发的提案消息都不相同，各个提案消息都包含着不同的编码块。相比于将所有的提案消息的集合分发给每一个副本节点，本申请实施例通过将不同的提案消息分发给不同的副本节点能够减少通信开销。

接着，对步骤S105进行描述，步骤S105为转发步骤。

在一些实施例的步骤S105中，当副本节点接收到提案消息之后，副本节点会将提案消息转发至其他的副本节点。具体地，首先，副本节点需要判断收到的提案消息是否是由主节点发出的提案消息，其通过获取提案消息中的编码块中的副本节点编号，与副本节点自身的编号进行比对，若比对结果表示编号一致，则提案消息为主节点发出的。其次，若第一条提案消息为主节点发出的，则副本节点转发并存储此提案消息，此后收到的提案消息都只存储在本地不再转发；若第一条提案消息为非主节点发出的，则副本节点转发并存储此提案消息，随后在接收到第一条由主节点发出的提案消息时，转发并存储第一条由主节点发出的提案消息，随后收到的提案消息都只存储在本地不再转发。通过副本节点将由主节点发出的提案消息进行一次转发，且对在收到由主节点发出的第一条提案消息后收到的其他提案消息都不再进行转发，减少了转发的通信开销。

接着，对步骤S106进行描述，步骤S106为解码步骤。

在一些实施例的步骤S106中,第一预设阈值根据总节点数和故障节点数进行获取，具体为总节点数减去故障节点数得到第一预设阈值。针对每一个副本节点，若副本节点接收到包含第一数据包的哈希值的不少于第一预设阈值的提案消息，副本节点对提案消息进行解码处理，能够得到第一数据包。具体地，副本节点接收到不少于第一预设阈值针对同一哈希值的不同的提案消息，即接收到不少于第一预设阈值的不同的片段的集合，就能对片段集合进行解码处理，得到片段集合对应的数据包。

接着，对步骤S107进行描述，步骤S107为投票步骤。

在一些实施例的步骤S107中，副本节点和主节点中任一节点对第一数据包进行投票处理，得到节点自身对第一数据包的投票结果。具体地，主节点在投票阶段生成投票结果；而副本节点需要解码得到第一数据包之后才对第一数据包进行投票处理，生成投票结果。

接着，对步骤S108进行描述，步骤S108为广播步骤。

在一些实施例的步骤S108中，在生成投票结果后，副本节点和主节点中的任一节点将自身对第一数据包的投票结果广播至其他所有节点，其中，其他所有节点指总节点中除自身之外的所有节点。

请参照图6，在一些实施例的步骤S109之前，区块链共识方法还包括跟随步骤，跟随步骤可以包括但不限于包括步骤S601至步骤S603：

步骤S601，若副本节点未接收到包含第一数据包的哈希值的不少于第一预设阈值的提案消息，则判断节点是否接收到不少于第二预设阈值的包含第一数据包的哈希值的投票结果；

步骤S602，当副本节点接收到不少于第二预设阈值的包含第一数据包的哈希值的投票结果时，副本节点生成跟随请求并将跟随请求广播至其他所有节点；

步骤S603，当副本节点接收到不少于第三预设阈值的由第一数据包编码成的编码块时，对编码块进行解码，得到第一数据包。

下面对步骤S601至步骤S603进行详细描述。

在一些实施例的步骤S601中，第二预设阈值根据总节点数和故障节点数计算得到，具体为。若副本节点未接收到包含第一数据包的哈希值的不少于第一预设阈值的提案消息，此时，副本节点并不能解码出第一数据包，则可以判断是否接收到不少于第二预设阈值的包含第一数据包的哈希值的投票结果。

在一些实施例的步骤S602中，跟随请求包括跟随请求标识、第一数据包的哈希值、第一数据包的默克尔根、以及一个哈希值的签名，其中，哈希值是副本节点对跟随请求标识、第一数据包的哈希值、和第一数据包的默克尔根进行哈希的结果，跟随请求表示为，其中，/>为跟随请求标识。当副本节点接收到不少于n-f个包含第一数据包的哈希值的投票结果时，副本节点会生成跟随请求并将跟随请求消息广播至其他所有节点，其中，投票结果需要是不同的副本节点的投票结果。具体地，如果副本节点/>没有收集到可解码的片段集合，但收到了/>个针对第一数据包的哈希值的投票结果，则副本节点/>广播跟随请求。

在一些实施例的步骤S603之前，当其他所有节点收到跟随请求时，针对其他所有节点的每一个节点，若节点有完整的第一数据包，并且在此之前没有响应过来自任何节点的跟随请求，则该节点会将第一数据包编码为编码块，并将每个编码块的哈希值作为一个叶节点构造默克尔树。随后，该节点根据编码块和默克尔树生成跟随响应消息，并将跟随响应消息分发给相应的节点。跟随响应消息包括跟随响应消息标识、第一数据包的哈希值、副本节点关于当前区块的编码块、第一数据包的默克尔根、默克尔树证明、以及一个哈希值的签名。其中，哈希值是节点对跟随响应消息标识、第一数据包的哈希值、副本节点关于当前区块的编码块、第一数据包的默克尔根、和默克尔树证明进行哈希的结果。跟随响应消息表示为，其中，是跟随响应消息标识，/>是/>的默克尔树证明。具体地，节点在收到跟随请求时，如果节点/>有完整的第一数据包，并且收到节点/>的跟随请求之前没有响应过来自其他任何节点的跟随请求，则节点/>将第一数据包编码为/>个编码块，编码块包括/>。随后节点/>针对每一编码块，根据编码块和默克尔树生成一个跟随响应消息，即第一个编码块/>生成的跟随响应消息为，以此类推，第/>个编码块生成的跟随响应消息为。在生成跟随响应消息之后，节点/>将第一个编码块/>对应的跟随响应消息分发给节点编号为0的节点，以此类推，节点/>将第一个编码块/>对应的跟随响应消息分发给节点编号为/>的节点。其中，编码的具体实现过程与步骤S102的具体实现过程类似，在此不做赘述。

需要说明的是，其他节点在收到跟随响应消息时，对默克尔树证明进行正确性检查。如果检查结果为正确，节点再满足从未转发过该跟随响应消息并且没有转发过包含跟随响应消息对应的编码块的消息这两个条件，则节点转发该跟随响应消息。如果检查结果为不正确，则忽略该跟随响应消息。

在一些实施例的步骤S603中，第三预设阈值为，第三预设阈值与第一数量相同，这是因为收集到/>个不同的编码块就能解码出第一数据包。其中，副本节点收到的编码块可能存在相同的，但不同的编码块的数量需要不少于第三预设阈值。副本节点接收到不少于第三预设阈值的包含由第一数据包编码成的编码块时，对编码块进行解码，得到第一数据包。具体地，副本节点/>收到包含第一数据包的默克尔根的跟随响应消息，能够从跟随响应消息中获取编码块，同时，副本节点还可能会继续接收到提案消息，并从提案消息中获取编码块，当副本节点/>收集到/>个不同的编码块时，对编码块进行解码，能够得到第一数据包。

通过上述步骤S601至步骤S603能够在持有部分编码块但未能解码出原数据包的情况下，通过收集预设数量的投票结果唤起跟随机制，即主动触发副本节点广播跟随请求事件，副本节点再通过其他节点生成并分发或者收到并转发地跟随响应消息得到缺少的编码块，从而解码出第一数据包，再对第一数据包进行投票，基于此，能够使副本节点主动地获取编码块，加快投票的速度，从而提高共识的速度。

最后，对步骤S109进行描述，步骤S109为确定步骤。

在一些实施例的步骤S109中，副本节点和主节点中的任一节点会对第一区块进行确认。

需要说明的是，步骤S109具体包括认证区块生成步骤、提案步骤、预确认步骤、和确认步骤。其中，提案步骤是前文的数据封装打包步骤、编码步骤、提案生成步骤、和分发步骤构成的总步骤的简称。

在步骤S109具体实现时，首先执行认证区块生成步骤。

在该步骤具体实现时，在当前视图中，若主节点收到不少于第四预设阈值的对第一数据包的投票结果时，主节点对第一区块进行聚合签名的构造，得到第一认证区块，以对第一区块进行确认。其中，第四预设阈值设置为；投票结果需要是不同的节点的投票结果；聚合签名通过门限签名技术构造，门限签名技术的参数为/>,具体是所有节点共享同一个公钥，每个节点有属于自身的私钥，每个私钥可以对消息/>进行签名，得到，/>为节点编号，当拿到/>个签名后，可以计算得到聚合签名，其中/>为签名节点集合；第一认证区块指的是经过认证的第一区块，第一认证区块记为/>。主节点构造聚合签名并生成第一认证区块即意味着主节点对第一区块进行了确认。同时，非主节点在收到不少于第四预设阈值的对第一数据包的投票结果时，非主节点也会对第一区块进行聚合签名的构造，得到聚合签名，但非主节点不会将自身构造的聚合签名发给其他节点。

需要注意的是，在快速响应模式中，第四预设阈值设置为。

接着，执行提案步骤。

在该步骤具体实现时，根据第一认证区块，主节点生成第二区块的提案消息。其中，由对象发起共识请求，主节点对第二数据包进行封装打包，得到第二区块/>，第二区块包括第二数据包和第二区块的前驱区块的哈希值，而第二区块的前驱区块的哈希值就是第一区块的哈希值/>，主节点再对第二数据包进行编码处理，得到编码结果，即这n个编码块，接着主节点根据第二数据包的编码结果生成第二区块的提案消息/>，其中，第二区块的提案消息包括提案消息标识/>、节点/>关于当前区块/>的编码块、前驱区块的哈希值/>、第二数据包的哈希值/>、当前视图的视图编号/>、前驱认证区块/>、第二数据包的默克尔根/>、以及一个哈希值的签名，其中，哈希值是主节点/>对提案消息标识/>、节点/>关于当前区块/>的编码块/>、前驱区块的哈希值/>、第二数据包的哈希值/>、当前视图的视图编号/>、前驱认证区块/>、和第二数据包的默克尔根/>进行哈希的结果。

接着，执行预确认步骤。

在该步骤具体实现时，若副本节点接收到包含第一认证区块的提案消息后，开启针对第一区块的计时器。其中，包含第一认证区块的提案消息也就是第二区块的提案消息。每个副本节点对每个区块都会设置一个计时器，计时器通常设置为，根据同步时延确定。

最后，执行确认步骤。

在该步骤具体实现时，当计时器的数值降为0，并且没有发生视图切换，副本节点确认第一区块及第一区块的所有前驱区块以对第一区块进行确认。

通过认证区块生成步骤、提案步骤、预确认步骤和确认步骤实现对区块的确认，完成对区块的共识。

由于，在标准同步模型下，由诚实节点发出的消息将会在同步时延上界内到达。然而，在实际网络情况中这样的假设可能无法被满足。因此，本申请考虑一个更弱的同步假设模型，即流动迟滞模型。

下面对流动迟滞模型下的共识方法进行详细描述。

在流动迟滞模型下，诚实节点被分为敏捷节点与迟滞节点。敏捷节点依旧遵循同步时延假设，而发往迟滞节点或由迟滞节点发出的消息则可能不会遵循这样的假设。值得注意的是，在本申请的流动迟滞模型下，任何敏捷节点可能会在任意时刻变为迟滞节点，反之亦然。

在流动迟滞模型下，故障节点既包括恶意节点，也包括迟滞节点。本申请中，要求任意时刻故障节点数量最多为，否则系统的安全性无法保障。值得注意的是，一个迟滞的节点仍然是诚实的，应当保证所有的诚实节点不会对矛盾的区块进行确认，而不是把迟滞节点当成沉默的恶意节点对待。

与标准同步模型的共识方法相比，流动迟滞模型中的共识方法在稳定阶段仅在预确认步骤和确认步骤有所区别，为节省篇幅，其余相同的步骤这里不再赘述。同时，流动迟滞模型中的共识方法在视图切换阶段的步骤和标准同步模型的共识方法的视图切换阶段的步骤完全一致，为节省篇幅，在此不做赘述。

请参考图7，在流动迟滞模型中，步骤S109包括但不限于包括步骤S701至步骤S704：

步骤S701，在当前视图中，若主节点收到不少于第四预设阈值的对第一数据包的投票结果时，则主节点对第一区块进行聚合签名的构造，得到第一认证区块，以对第一区块进行确认；

步骤S702，根据第一认证区块，主节点生成第二区块的提案消息；

步骤S703，当副本节点接收到不少于第五预设阈值的第二区块提案消息时，开启针对第一区块的计时器；

步骤S704，当计时器的数值降为0，并且没有发生视图切换，副本节点广播确认消息以对第一区块进行确认。

下面对步骤S701至步骤S704进行详细描述。

在一些实施例的步骤S701中，这一步骤的具体实现过程与标准同步模型的认证区块生成步骤一致。为节省篇幅，在此不做赘述。

在一些实施例的步骤S702中，这一步骤的具体实现过程与标准同步模型的提案步骤一致。为节省篇幅，在此不做赘述。

在一些实施例的步骤S703中，第五预设阈值设置为。若副本节点接收到不少于第五预设阈值的第二区块的提案消息后，开启针对第一区块的计时器。其中，第二区块的提案消息也就是包含第一认证区块的提案消息。计时器的设置与标准同步模型的计时器一致。为节省篇幅，在此不做赘述。

需要说明的是，标准同步模型和流动迟滞模型中都存在第四预设阈值和第五预设阈值。其中，第四预设阈值在不同的模型中取值可相同可不同，根据实际情况设置。第五预设阈值在不同的模型中取值可相同可不同，根据实际情况设置

在一些实施例的步骤S704中，确认消息包括确认消息标识、第一区块的哈希值、当前视图的视图编号，以及副本节点对确认消息标识、第一区块的哈希值、当前视图的视图编号这整个消息内容的哈希值的签名。将副本节点对第一区块/>的确认消息记为，其中，/>为确认消息标识。在副本节点收到/>个不同的节点针对第一区块的确认消息时，副本节点确认第一区块以及第一区块的所有前驱区块。

通过上述步骤S701至步骤S704能够对第一区块进行确认，达到共识的目的。

以上是对流动迟滞模型的具体描述。接下来，对快速响应模式下的稳定阶段进行详细描述。

快速响应模式的稳定阶段在数据封装打包步骤、编码步骤、提案生成步骤、分发步骤、转发步骤、解码步骤、投票步骤、广播步骤与普通模式的具体实现过程完全一致，这里不再赘述。其次，在确认步骤中，仅预确认步骤和确认步骤与普通模式不同。

快速响应模式的预确认步骤包括但不限于包括：当副本节点接收到不少于第五预设阈值的第二区块的提案消息时，生成确认消息并将确认消息广播至其他节点。

快速响应模式的确认步骤包括但不限于包括：副本节点在接收到不少于第六预设阈值的包含第一区块的确认消息时，确认第一区块及第一区块的所有前驱区块。其中，第六预设阈值设置为。

下面结合图8对本申请实施例提供的区块链共识方法的标准同步模型的实现过程进行详细描述。

图8中例举3个节点的情况，节点编号为0,1,2，其中，主节点的节点编号为0，副本节点的节点编号为1，副本节点/>的节点编号为2。

在视图开始步骤中，每个副本节点都会把自身的已知的最高认证区块发送至主节点，如图8所示，副本节点会将自身的已知的最高认证区块（如图8中①）发送至主节点，并且锁定在自身的已知的最高认证区块；相应地，副本节点/>会将自身的已知的最高认证区块（如图8中②）发送至主节点，并且锁定在自身的已知的最高认证区块。而主节点在收到多个副本节点发送的自身的已知的最高认证区块，会在多个区块（如图8中①和②）中根据区块的高度选取最高的区块作为最高认证区块。

在提案步骤中，提案步骤包括数据封装打包步骤、编码步骤、提案生成步骤、和分发步骤。具体地，在分发步骤之前，先依次执行数据封装打包步骤、编码步骤、和提案生成步骤。其中，在数据封装打包步骤中，主节点响应于对象的共识请求，将第一数据包进行封装打包处理，得到第一数据包对应的第一区块。在编码步骤中，主节点将数据包分为份数据块，再将/>数据块编码为/>个编码块。在提案生成步骤中，主节点根据/>个编码块得到/>个提案消息，其中，每个编码块对应一个提案消息，每个提案消息中包括对应的节点编号。在分发步骤中，主节点根据提案消息中对应的节点编号将提案消息分发给对应的副本节点。图8中的提案步骤具体指分发步骤，当/>=3，则生成3个对应的提案消息，包括提案消息、提案消息/>、和提案消息/>，其中，提案消息/>中包含节点编号0，提案消息中包含节点编号1，提案消息/>中包含节点编号2。如图8所示，主节点将提案消息不分发给其他节点，将提案消息/>（如图8中③）分发给副本节点/>，将提案消息（如图8中④）分发给副本节点/>。

在转发步骤中，副本节点将提案消息中节点编号与自身节点相同的第一条提案消息转发给其他副本节点，其后收到的提案消息都保存至本地，不再进行转发。而这个过程中，主节点会将属于自身对应的提案消息（图中未展示）广播给所有副本节点。如图8所示，副本节点将属于自身的提案消息（如图8中③）转发给副本节点/>，而副本节点/>将属于自身的提案消息（如图8中④）转发给副本节点/>。

在投票步骤中，主节点对第一数据包进行投票，得到投票结果（如图8中⑤）并将投票结果广播给副本节点/>和副本节点/>。副本节点也会进行投票，具体地，如果副本节点接收到的提案消息中包含的编码块能够解码出第一数据包，则副本节点对第一数据包进行投票，得到投票结果，并将投票结果广播给其他所有节点。如图8所示，副本节点/>生成投票结果/>（如图8中⑥），副本节点/>将投票结果/>广播给主节点和副本节点/>，副本节点/>生成投票结果/>2（如图8中⑦），副本节点/>将投票结果/>2广播给主节点和副本节点/>。

接着进入非阻塞步骤，非阻塞步骤能够与下一轮共识同步进行。非阻塞步骤包括跟随步骤、预确认步骤、和确认步骤。

在跟随步骤中，如果节点未收到能解码的编码块但收到了预设数量的投票结果，则节点生成跟随请求并将跟随请求广播，以此更快地获取缺少的编码块，从而快速地解码出第一数据包。

在预确认步骤中，如果节点收到了包含第一数据包对应的第一认证区块的新提案消息，则将第一区块对应的计时器设置为，开启计时器。

在确认步骤中，当计时器的时间降为0，并且没有发生视图切换时，确认第一区块。

在反馈步骤中，获取节点关于确认第一数据包的信息，即确认第一区块的信息，得到第一数据包的共识状态，共识状态表示第一区块完成了共识。接着将共识状态反馈给对象。如图8所示，从主节点处获取确认信息（如图8中⑧），从副本节点/>处获取确认信息/>（如图8中⑨），从副本节点/>2处获取确认信息/>2（如图8中⑩）。在获取确认信息之后将结果反馈给对象。

通过上述步骤实现对数据包的共识，能够通过降低通信复杂度，从而提高共识的吞吐率。

请参阅图9，本申请实施例还提供一种区块链共识系统，可以实现上述区块链共识方法，该系统包括：

数据封装打包模块901，用于主节点对数据池中的数据进行封装打包处理，得到第一区块，其中，第一区块包括第一数据包和第一区块的前驱区块的哈希值；

编码模块902，用于主节点对第一数据包进行编码处理，得到编码结果，其中，编码结果包括至少一个编码块；

提案生成模块903，用于主节点根据编码结果生成提案消息，其中，提案消息包括第一数据包的哈希值；

分发模块904，用于主节点将提案消息分发给对应的副本节点，其中，各个副本节点收到的提案消息都不相同；

转发模块905，用于在副本节点接收到提案消息后，副本节点将提案消息转发至其他副本节点；

解码模块906，用于针对每一个副本节点，若副本节点接收到包含第一数据包的哈希值的不少于第一预设阈值的提案消息，对提案消息进行解码处理，得到第一数据包；

投票模块907，用于副本节点和主节点中的任一节点对第一数据包进行投票处理，得到自身对第一数据包的投票结果；

广播模块908，用于副本节点和主节点中的任一节点将自身对第一数据包的投票结果广播至其他所有节点；

确认模块909，用于副本节点和主节点中的任一节点对第一区块进行确认。

该区块链共识系统的具体实施方式与上述区块链共识方法的具体实施例基本相同，在此不再赘述。

本申请实施例还提供了一种电子设备，电子设备包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现上述区块链共识方法。该电子设备可以为包括平板电脑、车载电脑等任意智能终端。

请参阅图10，图10示意了另一实施例的电子设备的硬件结构，电子设备包括：

处理器1001，可以采用通用的CPU（Central Processing Unit，中央处理器）、微处理器、应用专用集成电路（Application Specific Integrated Circuit，ASIC）、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请实施例所提供的技术方案；

存储器1002，可以采用只读存储器（Read Only Memory，ROM）、静态存储设备、动态存储设备或者随机存取存储器（Random Access Memory，RAM）等形式实现。存储器1002可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1002中，并由处理器1001来调用执行本申请实施例的区块链共识方法；

输入/输出接口1003，用于实现信息输入及输出；

通信接口1004，用于实现本设备与其他设备的通信交互，可以通过有线方式（例如USB、网线等）实现通信，也可以通过无线方式（例如移动网络、WIFI、蓝牙等）实现通信；

总线1005，在设备的各个组件（例如处理器1001、存储器1002、输入/输出接口1003和通信接口1004）之间传输信息；

其中处理器1001、存储器1002、输入/输出接口1003和通信接口1004通过总线1005实现彼此之间在设备内部的通信连接。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述区块链共识方法。

存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本申请实施例提供的区块链共识方法和系统、电子设备及存储介质，其通过主节点对数据池中的数据进行封装打包处理，得到第一区块，其中，第一区块包括第一数据包和第一区块的前驱区块的哈希值；主节点对第一数据包进行编码处理，得到编码结果，其中，编码结果包括至少一个编码块；主节点根据编码结果生成提案消息，其中，提案消息包括第一数据包的哈希值，能够通过对数据进行编码，再根据编码结果生成提案消息，相比于直接根据数据生成提案消息，缩小了提案消息的占用空间大小，从而降低了通信的复杂度。进一步地，主节点将提案消息分发给对应的副本节点，其中，各个副本节点收到的提案消息都不相同，通过将对不同的提案消息只进行一次分发给不同的副本节点，降低了主节点与副本节点之间通信的资源占用，从而降低了通信的复杂度。进一步地，在副本节点接收到提案消息后，副本节点将提案消息转发至其他副本节点，通过副本节点与副本节点之间的转发使副本节点能够接收到不同的提案消息。进一步地，针对每一个副本节点，若副本节点接收到包含第一数据包的哈希值的不少于第一预设阈值的提案消息，对提案消息进行解码处理，得到第一数据包；副本节点和主节点中的任一节点对第一数据包进行投票处理，得到自身对第一数据包的投票结果；副本节点和主节点中的任一节点将自身对第一数据包的投票结果广播至其他所有节点；副本节点和主节点中的任一节点对第一区块进行确认，通过得到部分而非所有的提案消息解码得到第一数据包，提高了共识的速度，再对第一数据包进行投票处理，最后对区块进行确认，实现对区块的共识。这一方式能够通过降低通信复杂度，即降低通信的资源占用率从而提高共识的吞吐率。

本申请实施例描述的实施例是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域技术人员可知，随着技术的演变和新应用场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

以上参照附图说明了本申请实施例的优选实施例，并非因此局限本申请实施例的权利范围。本领域技术人员不脱离本申请实施例的范围和实质内所作的任何修改、等同替换和改进，均应在本申请实施例的权利范围之内。

Claims (10)

1.区块链共识方法，其特征在于，所述方法包括：

主节点对数据池中的数据进行封装打包处理，得到第一区块，其中，所述第一区块包括第一数据包和所述第一区块的前驱区块的哈希值；

所述主节点对所述第一数据包进行编码处理，得到编码结果，其中，所述编码结果包括至少一个编码块；

所述主节点根据所述编码结果生成提案消息，其中，所述提案消息包括第一数据包的哈希值；

所述主节点将所述提案消息分发给对应的副本节点，其中，各个所述副本节点收到的所述提案消息都不相同；

在所述副本节点接收到所述提案消息后，所述副本节点将所述提案消息转发至其他副本节点；

针对每一个所述副本节点，若所述副本节点接收到包含所述第一数据包的哈希值的不少于第一预设阈值的所述提案消息，对所述提案消息进行解码处理，得到所述第一数据包；

所述副本节点和主节点中的任一节点对所述第一数据包进行投票处理，得到自身对第一数据包的投票结果；

所述副本节点和主节点中的任一节点将所述自身对第一数据包的投票结果广播至其他所有节点；

所述副本节点和主节点中的任一节点对所述第一区块进行确认。

2.根据权利要求1所述的区块链共识方法，其特征在于，所述方法包括主节点的视图切换，所述视图切换由以下方式实现：

针对每一个所述副本节点，当确定所述主节点为恶意主节点时，所述副本节点生成退出第一视图消息并广播至其他所有节点；

经过第一预设时间，所述副本节点将已知的最高认证区块发送至更新后的主节点，同时进入第二视图；

所述更新后的主节点进入所述第二视图后经过第二预设时间生成新视图消息，将所述新视图消息广播至其他所有节点；

所述副本节点接收到所述新视图消息，若所述已知的最高认证区块的区块高度不小于所述副本节点锁定的区块的区块高度，则副本节点转发所述新视图消息，并广播对所述已知的最高认证区块的投票结果。

3.根据权利要求2所述的区块链共识方法，其特征在于，所述主节点由以下方式更新：

确定所述第一视图的视图编号和总节点数，其中，所述总节点数根据所述主节点的主节点数和所述副本节点的副本节点数计算得到；

将所述视图编号与所述总节点数进行求余计算，得到余数；

将多个所述节点中编号与所述余数数值相同的节点作为所述更新后的主节点。

4.根据权利要求1所述的区块链共识方法，其特征在于，所述主节点对所述第一数据包进行编码处理，得到编码结果，包括：

获取故障节点数和总节点数；

根据所述故障节点数确定第一数量；

根据所述第一数量对所述第一数据包进行等分处理，得到第一字符序列；

根据预先构建的生成矩阵对第一字符序列进行编码处理，得到第二字符序列，其中，所述第二字符序列中的每个字符代表一个编码块，所述编码块的数量与所述总节点数相同；

将所述第二字符序列作为编码结果。

5.根据权利要求1至4任一项所述的区块链共识方法，其特征在于，在所述副本节点和主节点中的任一节点对所述第一区块进行确认之前，所述方法还包括：

若所述副本节点未接收到包含所述第一数据包的哈希值的不少于第一预设阈值的所述提案消息，则判断所述节点是否接收到不少于第二预设阈值的包含所述第一数据包的哈希值的投票结果；

当所述副本节点接收到不少于第二预设阈值的包含所述第一数据包的哈希值的投票结果时，所述副本节点生成跟随请求并将所述跟随请求广播至其他所有节点；

当所述副本节点接收到不少于第三预设阈值的由所述第一数据包编码成的编码块时，对编码块进行解码，得到所述第一数据包。

6.根据权利要求1至4任一项所述的区块链共识方法，其特征在于，所述方法还包括流动迟滞模型，所述副本节点和主节点中的任一节点对所述第一区块进行确认，包括：

在当前视图中，若所述主节点收到不少于第四预设阈值的对第一数据包的投票结果时，则所述主节点对所述第一区块进行聚合签名的构造，得到第一认证区块，以对所述第一区块进行确认；

根据所述第一认证区块，所述主节点生成第二区块的提案消息；

当所述副本节点接收到不少于第五预设阈值的第二区块提案消息时，开启针对第一区块的计时器；

当所述计时器的数值降为0，并且没有发生视图切换，所述副本节点广播确认消息以对所述第一区块进行确认。

7.根据权利要求1至4任一项所述的区块链共识方法，其特征在于，所述主节点的视图包括普通模式和快速响应模式，在所述主节点对数据池中的数据进行封装打包处理，得到第一区块之前，所述方法包括：

将视图编号为奇数的视图设置为普通模式，将视图编号为偶数的视图设置为快速响应模式；

所述方法还包括对当前视图的模式进行视图切换，具体包括：

若当前视图的视图编号为奇数，则将所述当前视图的视图编号与1进行相加，以将当前视图由普通模式切换为快速响应模式；

若当前视图的视图编号为偶数，则将所述当前视图的视图编号与2进行相加，以将当前视图的下一个视图保持为快速响应模式。

8.区块链共识系统，其特征在于，所述系统包括：

数据封装打包模块，用于主节点对数据池中的数据进行封装打包处理，得到第一区块，其中，所述第一区块包括第一数据包和所述第一区块的前驱区块的哈希值；

编码模块，用于所述主节点对所述第一数据包进行编码处理，得到编码结果，其中，所述编码结果包括至少一个编码块；

提案生成模块，用于所述主节点根据所述编码结果生成提案消息，其中，所述提案消息包括第一数据包的哈希值；

分发模块，用于所述主节点将所述提案消息分发给对应的副本节点，其中，各个所述副本节点收到的所述提案消息都不相同；

转发模块，用于在所述副本节点接收到所述提案消息后，所述副本节点将所述提案消息转发至其他副本节点；

解码模块，用于针对每一个所述副本节点，若所述副本节点接收到包含所述第一数据包的哈希值的不少于第一预设阈值的所述提案消息，对所述提案消息进行解码处理，得到所述第一数据包；

投票模块，用于所述副本节点和主节点中的任一节点对所述第一数据包进行投票处理，得到自身对第一数据包的投票结果；

广播模块，用于所述副本节点和主节点中的任一节点将所述自身对第一数据包的投票结果广播至其他所有节点；

确认模块，用于所述副本节点和主节点中的任一节点对所述第一区块进行确认。

9.电子设备，其特征在于，所述电子设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现权利要求1至7任一项所述的区块链共识方法。

10.计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的区块链共识方法。