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

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种区块链共识方法、系统、电子设备及存储介质。

背景技术

在现有区块链使用的共识流程中，通常需要经过多个阶段的投票处理，区块链中的节点才能对一项待共识内容达成一致，进而生成区块并存储到区块链中。以pbft(Practical Byzantine Fault Tolerance，实用拜占庭容错)共识算法为例，需要经过proposal(提案)、sign(签名)、commit(同意)三个阶段后才能达成共识，进而生成一个区块，而每个阶段都需要经历全网广播、验签、投票、统计结果等，在完成上述三个阶段后，才能针对下一个区块发起共识。

所以，采用现有的处理方式，处理效率低。

发明内容

本发明的目的在于，针对上述现有技术中的不足，提供一种区块链共识方法、装置、电子设备及存储介质，对包含多个阶段的共识算法进行了改进，在完成对当前共识内容的第一个共识阶段的共识后，立即开始对下一个共识内容进行第一个共识阶段的共识处理，实现了对多个共识内容并行进行共识处理，提高了区块链共识处理效率。

为实现上述目的，本发明实施例采用的技术方案如下：

第一方面，本申请实施例提供了一种区块链共识方法，应用于区块链中的任一节点，包括：

当确定当前共识内容的第一个共识阶段已完成时，根据预设规则确定本节点是否为下一个共识内容的提案节点，其中每个共识内容需要经过至少两个共识阶段；

若确定所述本节点为所述下一个共识内容的提案节点，则向所述区块链中的各节点发送针对所述下一个共识内容的共识请求，所述共识请求用于指示共识内容所处的共识阶段。

可选地，所述当确定当前共识内容的第一个共识阶段已完成时，根据预设规则确定本节点是否为下一共识内容的提案节点，包括：

若收到所述区块链中超过预设比例的节点发送的针对所述当前共识内容的第一个共识阶段的投票消息，且收到所述当前共识内容的提案节点发送的针对所述当前共识内容的共识请求，则确定所述当前共识内容的第一个共识阶段已完成；

根据预设规则确定所述本节点是否为下一共识内容的提案节点。

可选地，所述方法还包括：

接收所述当前共识内容的提案节点发送的共识请求链表，所述共识请求链表中包括：未生成区块的每个共识内容所对应的共识请求，每个共识请求包括状态参数，所述状态参数表示共识内容所处的共识阶段；

按照所述共识请求链表中各个共识请求的排列顺序，依次对各个共识请求进行共识投票处理，以得到每个共识请求的投票结果；

所述向所述区块链中的各节点发送针对所述下一个共识内容的共识请求，具体包括：

根据每个共识请求的投票结果，更新所述共识请求链表中的每个共识请求中的状态参数，获取更新后的共识请求链表；

将针对所述下一个共识内容的共识请求，添加到所述共识请求链表的队尾，获得新的共识请求链表；

向所述区块链中的各节点发送所述新的共识请求链表。

可选地，所述根据每个共识请求的投票结果，更新所述共识请求链表中的每个共识请求中的状态参数，具体包括：

针对所述共识请求链表中的任一共识请求，若确定存在目标共识请求的投票结果为达成共识，则基于所述目标共识请求中的状态参数，确定所述目标共识请求对应的共识内容当前所处的共识阶段，并将所述目标共识请求中的状态参数，更新为所述当前所处的共识阶段之后的共识阶段对应的状态参数。

可选地，所述共识请求链表中的各个共识请求的排列顺序根据各所述共识请求的生成顺序确定。

可选地，所述根据预设规则确定本节点是否为下一个共识内容的提案节点之前，所述方法还包括：

若确定当前共识内容的第一个共识阶段已完成，则视图参数增加1，其中，所述视图参数的初始值为1；

所述根据预设规则确定本节点是否为下一个共识内容的提案节点，包括：

采用所述视图参数除以所述区块链的节点数量进行取余运算，获取余数；

若所述本节点的节点序号等于所述余数，则确定所述本节点为下一个共识内容的提案节点。

可选地，所述当前共识内容的共识请求还包括：生成所述当前共识内容的共识请求时的视图参数；

所述根据预设规则确定所述本节点是否为下一个共识内容的提案节点，包括：

确定所述当前共识内容的共识请求中的视图参数与当前的视图参数一致；

若一致，根据所述预设规则确定所述本节点是否为下一个共识内容的提案节点。

可选地，所述方法还包括：

若所述视图参数增加1之后的指定时长内所述视图参数未增加1，则重新确定提案节点。

第二方面，本申请实施例提供了一种区块链共识装置，应用于区块链中的任一节点，包括：

提案节点确定模块，用于当确定当前共识内容的第一个共识阶段已完成时，根据预设规则确定本节点是否为下一个共识内容的提案节点，其中每个共识内容需要经过至少两个共识阶段；

共识请求模块，用于若确定所述本节点为所述下一个共识内容的提案节点，则向所述区块链中的各节点发送针对所述下一个共识内容的共识请求，所述共识请求用于指示共识内容所处的共识阶段。

可选地，所述提案节点确定模块，还用于：若收到所述区块链中超过预设比例的节点发送的针对所述当前共识内容的第一个共识阶段的投票消息，且收到所述当前共识内容的提案节点发送的针对所述当前共识内容的共识请求，则确定所述当前共识内容的第一个共识阶段已完成，根据预设规则确定所述本节点是否为下一共识内容的提案节点。

可选地，所述装置还包括投票模块，所述投票模块用于：接收所述当前共识内容的提案节点发送的共识请求链表，所述共识请求链表中包括：未生成区块的每个共识内容所对应的共识请求，每个共识请求包括状态参数，所述状态参数表示共识内容所处的共识阶段；按照所述共识请求链表中各个共识请求的排列顺序，依次对各个共识请求进行共识投票处理，以得到每个共识请求的投票结果；

所述共识请求模块，还用于：根据每个共识请求的投票结果，更新所述共识请求链表中的每个共识请求中的状态参数，以得到更新后的共识请求链表；将针对所述下一个共识内容的共识请求，添加到所述共识请求链表的队尾，获得新的共识请求链表；向所述区块链中的各节点发送所述新的共识请求链表。

可选地，所述共识请求模块，还用于：针对所述共识请求链表中的任一共识请求，若确定存在目标共识请求的投票结果为达成共识，则基于所述目标共识请求中的状态参数，确定所述目标共识请求对应的共识内容当前所处的共识阶段，并将所述目标共识请求中的状态参数，更新为所述当前所处的共识阶段之后的共识阶段对应的状态参数。

可选地，所述共识请求链表中的各个共识请求的排列顺序根据各所述共识请求生成顺序确定。

可选地，所述提案节点确定模块还用于：在根据预设规则确定所述任一节点是否为下一个共识内容的提案节点之前，若确定当前共识内容的第一个共识阶段已完成，则视图参数增加1，其中，所述视图参数的初始值为1；

所述提案节点确定模块，还用于：采用所述视图参数除以所述区块链的节点数量进行取余运算，获取余数；若所述本节点的节点序号等于所述余数，则确定所述本节点为下一个共识内容的提案节点。

可选地，所述当前共识内容的共识请求还包括：生成所述当前共识内容的共识请求时的视图参数；

所述提案节点确定模块，具体用于确定所述当前共识内容的共识请求中的视图参数与当前的视图参数一致，若一致，根据所述预设规则确定所述本节点是否为下一个共识内容的提案节点。

可选地，所述提案节点确定模块，还用于若所述视图参数增加1之后的指定时长内所述视图参数未增加1，则重新确定提案节点。

第三方面，本申请实施例提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行计算机程序时实现上述第一方面任一项所述的方法步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序指令，该计算机程序指令被处理器执行时实现上述第一方面任一项所述的方法步骤。

本申请实施例提供的区块链共识方法、装置、电子设备及存储介质，当确定当前共识内容的第一个共识阶段已完成时，根据预设规则确定本节点是否为下一个共识内容的提案节点，其中每个共识内容需要经过至少两个共识阶段；若确定本节点为下一个共识内容的提案节点，则向区块链中的各节点发送针对下一个共识内容的共识请求，共识请求用于指示共识内容所处的共识阶段。在完成对当前区块的第一个共识阶段的共识后，立即确定出针对下一个区块的提案节点，由该提案节点发起对下一个区块进行共识的共识请求，实现了对多个区块并行进行共识处理，提高了区块链共识处理效率。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为pbft共识算法的处理流程示意图；

图2A为本申请实施例提供的区块链共识方法的应用场景示意图；

图2B为区块链中的区块的结构示意图；

图3为本申请一实施例提供的区块链共识方法的流程示意图；

图4为本申请一实施例提供的区块链共识方法与现有的区块链共识方法的效果比对图；

图5为本申请一实施例提供的区块链共识方法的流程示意图；

图6为本申请一实施例提供的共识请求链表的状态变更的示意图；

图7为本申请一实施例提供的区块链共识装置的结构示意图；

图8为本申请一实施例提供的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了方便理解，下面对本申请实施例中涉及的名词进行解释：

Bft(Byzantine Fault Tolerance)：拜占庭容错技术是一类分布式计算领域的容错技术。拜占庭假设是对现实世界的模型化，由于硬件错误、网络拥塞或中断以及遭到恶意攻击等原因，计算机和网络可能出现不可预料的行为。拜占庭容错技术被设计用来处理这些异常行为，并满足所要解决的问题的规范要求。

联盟链：本质上仍然是一种私有链，只不过它比单个小组织开发的私有链更大，却又没有公有链这么大的规模，可以理解为它是介于私有链和公有链之间的一种区块链。

View：即视图，在pbft(Practical Byzantine Fault Tolerance，实用拜占庭容错)正常流程中，通过view确定出块节点(master节点)，view为一个long类型的变量参数，正常情况下，view的值从0开始递增。

提案节点：即在一轮共识过程中，从区块链中各个节点中选举出来的发起投票并进行投票归档的节点。

下面参考本申请的若干代表性实施方式，详细阐释本申请的原理和精神。

在现有区块链使用的共识流程中，通常需要经过多个阶段的投票处理，区块链中的节点才能对一项待共识内容达成一致，进而生成区块并存储到区块链中。以pbft共识算法为例，需要经过proposal、sign、commit三个阶段后才能达成共识，进而生成一个区块，图1为pbft共识算法的处理流程示意图，如图1所示，pbft共识算法的处理流程包括：

第一步：先通过(block_number+view_nunber)％node_number，确定出提案节点，然后通过提案节点发起并广播第一共识阶段(proposal阶段)的请求。其中，block_number为块高，即当前待达成共识的区块在区块链中的序位，view_nunber为共识失败的次数，％代表取余运算，node_number为区块链中的节点数量。

第二步：全网节点收到proposal请求后，执行handle_proposal(H-P)第一共识阶段处理，即行对proposal请求进行验签、校验等一系列处理，通过验签以及校验后，通过P2P(Peer to Peer，对等网络)全网广播第二共识阶段(sign阶段)的请求(B-S)。

第三步：当全网节点收到来自P2P网络中的sign请求后，执行handle_sign(H-S)第二共识阶段处理，继续对sign请求进行验签、校验等一系列处理，并对sign请求进行投票以及票数归档，如果通过票数超过全网节点的2/3后，继续通过P2P网络发起并广播第三共识阶段(Commit阶段)的请求(B-C)；

第四步：当全网节点收到来自P2P网络中的commit请求后，执行handle_commit(H-C)第三共识阶段处理继续执行commit处理流程，该流程主要是对commit请求进行验签以及校验等一系列，再进行针对commit请求的投票以及票数归档处理，如果通过票数超过全网节点的2/3后，则可以进行区块达成共识，然后落盘(do-commit)。

上述为pbft的处理流程需要通过三个公式阶段来保证消息的防篡改以及强一致性，即必须经过上述四个步骤后才能生成一个区块，然后才能对下一个区块发起共识。因此，现有的多阶段共识算法的处理效率较低。

为了解决上述问题，本申请提供了一种区块链共识方法，具体包括：当确定当前共识内容的第一个共识阶段已完成时，根据预设规则确定本节点是否为下一个共识内容的提案节点，其中每个共识内容需要经过至少两个共识阶段；若确定本节点为下一个共识内容的提案节点，则向区块链中的各节点发送针对下一个共识内容的共识请求，共识请求用于指示共识内容所处的共识阶段。本申请提供的区块链共识方法是在多阶段共识算法的基础上提出的，在完成对当前区块的第一个共识阶段的共识后，立即确定出针对下一个区块的提案节点，由该提案节点发起对下一个区块进行共识的共识请求，实现了对多个区块并行进行共识处理，提高了区块链共识处理效率。

本申请实施例中，将现有技术中阶段式处理改进为状态式处理。

在介绍了本申请的基本原理之后，下面具体介绍本申请的各种非限制性实施方式。

图2A为本申请实施例提供的区块链共识方法的应用场景示意图，如图2A所示，区块链201是指用于进行节点与节点之间数据共享的系统，区块链201中可以包括多个节点202，多个节点202可以是指区块链201中各个服务器。每个节点202在进行正常工作可以接收到输入信息，并基于接收到的输入信息维护该区块链201内的共享数据。为了保证区块链201内的信息互通，区块链201中的每个节点之间可以存在信息连接，节点之间可以通过上述信息连接进行信息传输。例如，当区块链201中的任意节点接收到输入信息时，区块链201中的其他节点便根据共识算法获取该输入信息，将该输入信息作为共享数据中的数据进行存储，使得区块链201中全部节点上存储的数据均一致。

对于区块链201中的每个节点，均具有与其对应的节点标识，而且区块链201中的每个节点均可以存储有区块链201中其他节点的节点标识，以便后续根据其他节点的节点标识，将生成的区块广播至区块链201中的其他节点。每个节点中可维护一个节点标识列表，将节点名称和节点标识对应存储至该节点标识列表中。其中，节点标识可为IP(Internet Protocol，网络之间互联的协议)地址以及其他任一种能够用于标识该节点的信息。

数据共享系统中的每个节点均存储一条相同的区块链。图2B为区块链中的区块的结构示意图，参见图2B，区块链由多个区块组成，区块链由多个区块组成，创始块中包括区块头和区块主体，区块头中存储有输入信息特征值、版本号、时间戳和难度值，区块主体中存储有输入信息；创始块的下一区块以创始块为父区块，下一区块中同样包括区块头和区块主体，区块头中存储有当前区块的输入信息特征值、父区块的区块头特征值、版本号、时间戳和难度值，并以此类推，使得区块链中每个区块中存储的区块数据均与父区块中存储的区块数据存在关联，保证了区块中输入信息的安全性。

在生成区块链中的各个区块时，区块链所在的节点在接收到输入信息时，对输入信息进行校验，完成校验后，将输入信息存储至内存池中，并更新其用于记录输入信息的哈希树；之后，将更新时间戳更新为接收到输入信息的时间，并尝试不同的随机数，多次进行特征值计算，使得计算得到的特征值可以满足下述公式：

SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))

其中，SHA256为计算特征值所用的特征值算法；version(版本号)为区块链中相关区块协议的版本信息；prev_hash为当前区块的父区块的区块头特征值；merkle_root为输入信息的特征值；ntime为更新时间戳的更新时间；nbits为当前难度，在一段时间内为定值，并在超出固定时间段后再次进行确定；x为随机数；TARGET为特征值阈值，该特征值阈值可以根据nbits确定得到。

这样，当计算得到满足上述公式的随机数时，便可将信息对应存储，生成区块头和区块主体，得到当前区块。随后，区块链所在节点根据数据共享系统中其他节点的节点标识，将新生成的区块分别发送给其所在的数据共享系统中的其他节点，由其他节点对新生成的区块进行校验，并在完成校验后将新生成的区块添加至其存储的区块链中。

下面结合图2A和图2B的应用场景，来描述根据本申请示例性实施方式的区块链共识系统以及区块链共识方法。需要注意的是，上述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。相反，本申请的实施方式可以应用于适用的任何场景。

参考图3，本申请实施例提供了一种区块链共识方法，可应用于区块链中的任一节点，本实施例中，执行主体称为“本节点”，即以区块链中一个节点为例进行说明，其他节点具备同样的功能，执行的动作也都类似。该方法包括如下步骤：

S301、当确定当前共识内容的第一个共识阶段已完成时，根据预设规则确定本节点是否为下一个共识内容的提案节点，其中每个共识内容需要经过至少两个共识阶段。

可选地，可通过如下方式判断当前共识内容的第一个共识阶段是否已完成：若收到区块链中超过预设比例的节点发送的针对当前共识内容的第一个共识阶段的投票消息，则确定当前共识内容的第一个共识阶段已完成；否则，确定当前共识内容的第一个共识阶段未完成。

可选地，还可通过如下方式判断当前共识内容的第一个共识阶段是否已完成：若收到区块链中节点超过预设比例的发送的针对当前共识内容的第一个共识阶段的投票消息，且收到当前共识内容的提案节点发送的针对当前共识内容的共识请求，则确定当前共识内容的第一个共识阶段已完成；否则，确定当前共识内容的第一个共识阶段未完成。将收到当前共识内容的提案节点发送的针对当前共识内容的共识请求，作为判断第一个共识阶段是否已完成的判断条件，可以确保各个节点轮流作为提案节点，因为新一轮的提案需要基于当前论提案作为父(parent)提案。

其中，预设比例可根据实际应用场景进行设置，例如，预设比例可以是1/2或者2/3等数值。

可选地，每个共识内容需要经过至少两个共识阶段后，才会生成对应的区块并存储到区块链中。经过的共识阶段的数量由采用的共识算法确定，例如，pbft共识算法包括proposal、sign、commit三个共识阶段。

可选地，可通过如下方式确定本节点是否为下一个共识内容的提案节点：采用视图参数除以区块链的节点数量进行取余运算，获取余数，其中；若本节点的节点序号等于余数，则确定本节点为下一个共识内容的提案节点。其中，视图参数的初始值为1，若确定当前共识内容的第一个共识阶段已完成，则每个节点中的视图参数都会增加1。即在对区块链中的第一个共识内容进行共识之前，视图参数为1，当确定第一个共识内容的第一个共识阶段已完成时，视图参数增加1，即视图参数等于2，此时可发起对第二共识内容的共识请求；当确定第二个共识内容的第一个共识阶段已完成时，视图参数增加1，即视图参数等于3，此时可发起对第三共识内容的共识请求，以此类推。

具体地，每个节点可通过如下公式确定自身是否为下一个共识内容的提案节点：view％node_num，若view％node_num等于自身的节点编号，则该节点为下一个共识内容的提案节点，否则不是下一个共识内容的提案节点，其中，view为视图参数，node_num为区块链中的节点数量，区块链中的每个节点都有唯一的节点编号，且节点编号的取值从1～node_num。通过视图参数View在完成第一个共识阶段时自增1的方式，从区块链的节点中轮流确定出提案节点。

S302、若确定本节点为下一个共识内容的提案节点，则向区块链中的各节点发送针对下一个共识内容的共识请求。

其中，共识请求用于指示共识内容所处的共识阶段。

具体实施时，若本节点不是下一个共识内容的提案节点，则本节点只需等待下一个共识内容的提案节点发送针对下一个共识内容的共识请求。

具体实施时，本节点向区块链中的各个节点广播针对下一个共识内容的共识请求，各个节点在收到针对下一个共识内容的共识请求后，进行验签、校验等一系列处理，通过验签以及校验后，对下一个共识内容进行投票处理，在确定投票结果满足条件后，完成第一个共识阶段，进入针对下一个共识内容的第二共识阶段的处理。

具体实施时，每个共识内容的共识请求还包括：生成该共识内容的共识请求时的视图参数。例如，第一个共识内容的共识请求中的视图参数为1，第二个共识内容的共识请求中的视图参数为2。

例如，共识请求的格式可参考如下：

综上所述，本申请实施例提供的区块链共识方法，当确定当前共识内容的第一个共识阶段已完成时，根据预设规则确定本节点是否为下一个共识内容的提案节点，其中每个共识内容需要经过至少两个共识阶段；若确定本节点为下一个共识内容的提案节点，则向区块链中的各节点发送针对下一个共识内容的共识请求，共识请求用于指示共识内容所处的共识阶段。在完成对当前区块的第一个共识阶段的共识后，立即确定出针对下一个区块的提案节点，由该提案节点发起对下一个区块进行共识的共识请求，实现了对多个区块并行进行共识处理，提高了区块链共识处理效率。

进一步地，本申请实施例的区块链共识方法还包括：本节点判断当前共识内容的共识请求中的视图参数与当前的视图参数是否一致，若一致，则本节点进行对第一个共识阶段的投票处理，当基于投票结果确定当前共识内容的第一个共识阶段已完成时，本节点根据预设规则下一个共识内容的提案节点；若不一致，本节点会直接丢弃该共识请求，即不进行投票处理。通过验证共识请求中的视图参数与节点存储的视图参数是否一致，来确定该共识请求是当前共识内容对应的提案节点生成的请求，保证出块的连续性，即保证各个节点按序生成区块。

假设生成一个区块需要经过3个共识阶段，区块链包括n个节点，节点编号依次为1～n。图4为本申请一实施例提供的区块链共识方法与现有的区块链共识方法的效果比对图，如图4所示，区块链中的共识流程如下：

第一步，针对第一个共识内容B1，根据公式view％node_num，确定节点1(即节点编号为1的节点)为提案节点，此时view＝1，由节点1向区块链的各节点广播针对共识内容B1的第一共识请求，该第一共识请求中包括共识内容信息、视图参数view＝1、以及根据共识内容信息和视图参数生成的消息签名，共识内容信息包括：共识内容B1和共识内容B1所处的共识阶段P1(P1表示第一个共识阶段)。

第二步，各个节点在收到节点1发送的针对共识内容B1的第一共识请求后，基于第一共识请求中的消息签名进行验签，如果验签没有通过，直接丢弃该共识请求；如果验签通过，则继续判断该第一共识请求中的视图参数是否与节点本地存储的视图参数一致，如果不一致，则直接丢弃该第一共识请求；如果一致，则进行针对共识内容B1的第一个共识阶段的投票处理以及归档统计处理；若收到区块链中超过2/3的节点发送的针对共识内容B1的第一共识请求的投票消息，且收到的投票消息中包括节点1发送的投票消息，则确定共识内容B1的第一个共识阶段已完成，否则，确定共识内容B1的第一个共识阶段未完成。各个节点在确定共识内容B1的第一个共识阶段已完成后，本地存储的视图参数增加1，即各个节点本地存储的view＝2，此时根据公式view％node_num，确定节点2(即节点编号为2的节点)为新的提案节点。

与此同时，节点1在确定共识内容B1的第一个共识阶段已完成后，向各个节点广播针对共识内容B1的第二共识请求，该第二共识请求中包括共识内容信息、视图参数view＝1、以及根据共识内容信息和视图参数生成的消息签名，共识内容信息包括：共识内容B1和共识内容B1所处的共识阶段P2(P2表示第二共识阶段)。各个节点在收到节点1发送的第二共识请求后，进行验签、校验等一系列处理，通过验签以及校验后，对共识内容B1进行投票处理，基于投票结果确定共识内容B1的第二个共识阶段已完成后，节点1向各个节点广播针对共识内容B1的第三共识请求，该第三共识请求中包括共识内容信息、视图参数view＝1、以及根据共识内容信息和视图参数生成的消息签名，共识内容信息包括：共识内容B1和共识内容B1所处的共识阶段P3(P3表示第二共识阶段)。各个节点在收到节点1发送的第三共识请求后，进行验签、校验等一系列处理，通过验签以及校验后，对共识内容B1进行投票处理，基于投票结果确定共识内容B3的第三个共识阶段已完成后，生成共识内容B1对应的区块，并存储到区块链中。至此完成了针对共识内容B1的共识流程。上述过程与第三步同步进行，互不影响。

第三步，节点2生成针对第二个共识内容B2的第一共识请求，并广播给区块链中的所有节点，同样共识内容B2的第一共识请求中包括共识内容信息、视图参数view＝2、以及根据共识内容信息和视图参数生成的消息签名，共识内容信息包括：共识内容B2和共识内容B2所处的共识阶段。

第四步，各个节点在收到节点2发送的第一共识请求后，进行验签、校验等一系列处理，通过验签以及校验后，对共识内容B2进行投票处理，基于投票结果确定共识内容B2的第一个共识阶段已完成后，本地存储的视图参数增加1，即各个节点本地存储的view＝3，此时根据公式view％node_num，确定节点3(即节点编号为3的节点)为新的提案节点。具体过程参考第二步，不再赘述。

与此同时，节点2在确定共识内容B2的第一个共识阶段已完成后，向各个节点广播针对共识内容B2的第二共识请求，在确定共识内容B2的第二个共识阶段已完成后，向各个节点广播针对共识内容B2的第三共识请求，在确定共识内容B2的第三个共识阶段已完成后，生成共识内容B2对应的区块，并存储到区块链中。至此完成了针对共识内容B2的共识流程。上述过程与第五步同步进行，互不影响。

第五步，节点3生成针对共识内容B3的第一共识请求，并广播给区块链中的所有节点。具体过程参考第一步和第三步。

第六步，各个节点在收到节点3发送的第一共识请求后，进行验签、校验等一系列处理，通过验签以及校验后，对共识内容B3进行投票处理，基于投票结果确定共识内容B3的第一个共识阶段已完成后，本地存储的视图参数增加1，即各个节点本地存储的view＝4，此时根据公式view％node_num，确定节点4(即节点编号为3的节点)为新的提案节点。具体过程参考第二步，不再赘述。

与此同时，节点3在确定共识内容B3的第一个共识阶段已完成后，向各个节点广播针对共识内容B3的第二共识请求，在确定共识内容B3的第二个共识阶段已完成后，向各个节点广播针对共识内容B3的第三共识请求，在确定共识内容B3的第三个共识阶段已完成后，生成共识内容B3对应的区块，并存储到区块链中。至此完成了针对共识内容B3的共识流程。

参考图4，现有的区块链共识算法需要在完成共识内容B1的三个共识阶段后，才会开始对共识内容B2进行共识；而本申请实施例提供的区块链共识方法，在完成共识内容B1的第一个共识阶段后，立即开始对共识内容B2进行共识，在完成共识内容B2的第一个共识阶段后，立即开始对共识内容B3进行共识，共识速度可提升至原来的3倍左右。因此本申请实施例的区块链共识方法，可同时对多个共识内容进行共识处理，提高了区块链共识处理效率。

基于上述任一实施方式，可对多个共识内容并行进行共识处理，为避免同时对多个共识内容并行进行共识时的消息混乱，可通过共识请求链表存储所有还未生成区块的共识内容所对应的共识请求，由最新确定出的提案节点统一将共识消息列表广播给各个节点。通过提案节点广播共识请求链表的方式，还可以减少节点间发送消息的次数和数量，提高区块链运行效率。

基于此，参考图5，本申请实施例提供的区块链共识方法，可应用于区块链中的本节点，包括如下步骤：

S501、接收当前共识内容的提案节点发送的共识请求链表。

其中，共识请求链表中包括：未生成区块的每个共识内容所对应的共识请求，每个共识请求包括状态参数，状态参数表示共识内容所处的共识阶段。共识请求链表中，每个共识内容对应一个共识请求，通过状态参数标识共识内容所处的共识阶段。例如，当共识内容B1处于第一个共识阶段时，共识内容B1的共识请求中的状态参数为P1，当共识内容B1处于第二个共识阶段时，共识内容B1的共识请求中的状态参数为P2。共识请求链表中还包括视图参数和基于视图参数和共识请求链表中的共识请求生成的消息签名。

具体实施时，共识请求链表中的各个共识请求的排列顺序是共识请求生成的先后顺序确定的。例如第一个共识内容B1的共识请求位于共识请求链表中的第一位，第二个共识内容B2的共识请求位于共识请求链表中的第二位，新增的共识内容的共识请求添加到共识请求链表的队尾。当共识内容已生成了对应的区块时，需要删除共识请求链表中该共识内容对应的共识请求。

S502、按照共识请求链表中各个共识请求的排列顺序，依次对各个共识请求进行共识投票处理，以得到每个共识请求的投票结果。

例如，共识请求链表为：【commit(B1)->sign(B2)->proposal(B3)】，commit(B1)表示共识内容B1处于commit阶段，sign(B2)表示共识内容B2处于sign阶段，proposal(B3)表示共识内容B3处于proposa阶段，针对上述共识请求链表，先对commit(B1)进行投票，然后对sign(B2)进行投票，最后对proposal(B3)进行投票。具体投票的过程为现有技术，不再赘述。

S503、当确定当前共识内容的第一个共识阶段已完成时，根据预设规则确定本节点是否为下一个共识内容的提案节点，若本节点为下一个共识内容的提案节点，则执行步骤S504～S506。

步骤S503的具体实施方式可参考步骤S301的具体实施方式，不再赘述。若本节点不是下一个共识内容的提案节点，则步骤S504～S506由下一个共识内容的提案节点执行。

S504、根据每个共识请求的投票结果，更新共识请求链表中的每个共识请求中的状态参数，获取更新后的共识请求链表。

具体实施时，若收到区块链中超过预设比例的节点发送的针对当前共识内容的共识请求的投票消息，则该共识请求的投票结果为达成共识时。其中预设比例可根据实际应用需求确定，例如可以是1/2、2/3、4/5等。

具体实施时，针对消息队列中的任一共识请求，若确定存在目标共识请求的投票结果为达成共识，则基于该目标共识请求中的状态参数，确定该目标共识请求对应的共识内容当前所处的共识阶段，并将该目标共识请求中的状态参数，更新为该共识内容当前所处的共识阶段之后的共识阶段对应的状态参数。例如，共识内容B1的目标共识请求的状态参数为P1，P1表示共识内容B1当前处在第一个共识阶段，当确定该目标共识请求的投票结果为达成共识时，将该目标共识请求的状态参数更新为P2，P2表示第二个共识阶段，更新后的状态参数表示共识内容B1已处于第二个共识阶段。

S505、将针对下一个共识内容的共识请求，添加到共识请求链表的队尾，获得新的共识请求链表。

当共识内容已生成了对应的区块时，需要删除共识请求链表中该共识内容对应的共识请求。例如，共识请求链表为：【commit(B1)->sign(B2)->proposal(B3)】，根据投票结果更新后的共识请求链表为【commit(B2)->sign(B3)】，其中，共识内容为B1已经完成最后一个共识阶段commit，因此，需要删除共识请求链表中的commit(B1)。下一个共识内容为B4，生成B4对应的共识请求，并添加到共识请求链表【commit(B2)->sign(B3)】中，获得新的共识请求链表为：【commit(B2)->sign(B3)->proposal(B4)】，然后，将新的共识请求链表为：【commit(B2)->sign(B3)->proposal(B4)】发送给区块链中的各个节点。

S506、向区块链中的各节点发送新的共识请求链表。

各个节点按照新的共识请求链表中各个共识请求的排列顺序，依次对各个共识请求进行共识投票处理，以得到每个共识请求的投票结果。当确定当前共识内容的第一个共识阶段已完成时，根据预设规则确定本节点是否为下一个共识内容的提案节点，由下一个共识内容的提案节点根据每个共识请求的投票结果，更新共识请求链表中的每个共识请求中的状态参数，以得到更新后的共识请求链表，将新的共识请求链表发送给区块链中的各节点。

图6为本申请一实施例提供的共识请求链表的状态变更的示意图，如图6所示，以pbft共识算法为例，生成一个区块需要经过3个共识阶段：proposal、sign、commit。在共识过程中，各个节点需要分别执行第一处理流程(pre_handle)和第二处理流程(handle)，此外每一轮的提案节点还需要执行广播流程(broadcast)，第一处理流程(pre_handle)对应图5中的步骤S501和S502，第二处理流程(handle)对应图5中的步骤S503～505，广播流程(broadcast)对应图5中的步骤S506。具体的共识流程如下：

第一步，针对第一个共识内容B1，根据公式view％node_num，确定节点1(即节点编号为1的节点)为提案节点，此时view＝1，由节点1生成针对共识内容B1的共识请求，该共识请求中包括共识内容B1和状态参数proposal，将共识内容B1的共识请求、视图参数view＝1、以及根据共识请求和视图参数生成的消息签名，添加到共识请求链表中，此时共识请求链表可简单表示为：【第一共识阶段(B1)】，即【proposal(B1)】向区块链的各节点广播(broadcast)共识请求链表。

第二步，各个节点在收到节点1发送的共识请求链表后，各个节点分别执行第一处理流程(pre_handle)：基于共识请求链表中的消息签名进行验签，如果验签没有通过，直接丢弃该共识请求链表；如果验签通过，则继续判断该共识请求链表中的视图参数是否与节点本地存储的视图参数一致，如果不一致，则直接丢弃该共识请求链表；如果一致，则判断共识请求链表中排在第一个的共识请求对应的共识内容的父区块是否为区块链中最新加入的区块，以保证区块链的连续性，其中，初始的区块链中包含一个初始区块，该初始区块为第一个区块的父区块，若否，则丢弃该共识请求链表，若是，则针对共识请求链表中的第一个共识请求，即共识内容B1，进行第一个共识阶段的投票处理以及归档统计处理；若收到区块链中超过2/3的节点发送的针对共识内容B1的共识请求的投票消息，且收到的投票消息中包括节点1发送的投票消息，则确定共识内容B1的第一个共识阶段已完成，否则，确定共识内容B1的第一个共识阶段未完成；在确定共识内容B1的第一个共识阶段已完成后，将本地存储的视图参数增加1，即各个节点本地存储的view＝2。各个节点执行完第一处理流程后，执行第二处理流程(handle)：将共识请求链表中共识内容B1对应的状态参数更新为sign；根据公式view％node_num，确定节点2(即节点编号为2的节点)为新的提案节点。节点2生成下一个共识内容B2的共识请求，并添加到共识请求链表的队尾，获得新的共识请求链表，新的共识请求链表可简单表示为：【第二共识阶段(B1)->第一共识阶段(B2)】，即【sign(B1)->proposal(B2)】，将新的共识请求链表广播给区块链中的各节点。

第三步，各个节点在收到节点2发送的共识请求链表后，各个节点分别执行第一处理流程(pre_handle)：基于共识请求链表中的消息签名进行验签，如果验签没有通过，直接丢弃该共识请求链表；如果验签通过，则继续判断该共识请求链表中的视图参数是否与节点本地存储的视图参数一致，如果不一致，则直接丢弃该共识请求链表；如果一致，则判断共识请求链表中排在第一个的共识请求对应的共识内容的父区块是否为区块链中最新加入的区块，以保证区块链的连续性，若否，则丢弃该共识请求链表，若是，则按照共识请求链表中共识请求的排列顺序，对每个共识请求进行投票处理以及归档统计处理；若收到区块链中超过2/3的节点发送的针对共识内容B2的共识请求的投票消息，且收到的投票消息中包括节点2发送的投票消息，则确定共识内容B2的第一个共识阶段已完成，否则，确定共识内容B2的第一个共识阶段未完成；在确定共识内容B2的第一个共识阶段已完成后，将本地存储的视图参数增加1，即各个节点本地存储的view＝3。各个节点执行完第一处理流程后，执行第二处理流程(handle)：将共识请求链表中共识内容B1对应的状态参数更新为commit，将共识内容B2对应的状态参数更新为sign；根据公式view％node_num，确定节点3为新的提案节点。节点3生成下一个共识内容B3的共识请求，并添加到共识请求链表的队尾，获得新的共识请求链表，新的共识请求链表可简单表示为：【第三共识阶段(B1)->第二共识阶段(B2)->第一共识阶段(B3)】，即【commit(B1)->sign(B2)->proposal(B3)】，将新的共识请求链表广播给区块链中的所有节点。

第四步，各个节点在收到节点2发送的共识请求链表后，分别执行第一处理流程(pre_handle)：基于共识请求链表中的消息签名进行验签，如果验签没有通过，直接丢弃该共识请求链表；如果验签通过，则继续判断该共识请求链表中的视图参数是否与节点本地存储的视图参数一致，如果不一致，则直接丢弃该共识请求链表；如果一致，则判断共识请求链表中排在第一个的共识请求对应的共识内容的父区块是否为区块链中最新加入的区块，以保证区块链的连续性，若否，则丢弃该共识请求链表，若是，则按照共识请求链表中共识请求的排列顺序，对每个共识请求进行投票处理以及归档统计处理；若收到区块链中超过2/3的节点发送的针对共识内容B3的共识请求的投票消息，且收到的投票消息中包括节点2发送的投票消息，则确定共识内容B3的第一个共识阶段已完成，否则，确定共识内容B3的第一个共识阶段未完成；在确定共识内容B3的第一个共识阶段已完成后，将本地存储的视图参数增加1，即各个节点本地存储的view＝4。各个节点执行完第一处理流程后，执行第二处理流程(handle)：将共识请求链表中共识内容B1对应的状态参数更新为docommit(落盘)，将共识内容B2对应的状态参数更新为commit，将共识内容B3对应的状态参数更新为sign；根据公式view％node_num，确定节点4为新的提案节点。其中，当共识内容B1对应的状态参数被更新为docommit时，即表示共识内容B1已完成所有共识阶段，可生成共识内容B1对应的区块并存储到区块链中，因此，可删除共识请求链表中共识内容B1对应的共识请求，至此完成了针对共识内容B3的共识流程。节点4生成下一个共识内容B4的共识请求，并添加到共识请求链表的队尾，获得新的共识请求链表，新的共识请求链表可简单表示为：【落盘(B1)->第三共识阶段(B2)->第二共识阶段(B3)->第一共识阶段(B4)】，即【do commit(B1)->commit(B2)->sign(B3)->proposal(B4)】，将新的共识请求链表广播给区块链中的所有节点。

上述实施例提供的区块链共识方法，在共识算法的每一轮次中，每个节点只需要执行broadcast＝>pre_handle＝>handle三个流程，并且通过view％node_num的方式来确认新的提案节点，给出了一种并行、高效的共识方式，将现有的需要经过多个阶段的共识算法优化为一阶段，从而将共识速度提升至原来的N倍左右，N为共识算法所需要经过的阶段的数量，以pbft共识算法为例，基于本申请实施例提供的区块链共识方法，可以pbft共识算法的共识速度提升至原来的3倍左右。

在上述任一实施方式的基础上，若视图参数增加1之后的指定时长内视图参数未增加1，则重新确定提案节点。其中，指定时长可根据应用场景的需求进行设置和调整，本申请实施例不作限定。

具体实施时，视图参数增加1之后，会为设置一个定时触发任务，该任务的核心作用是判断当前的视图参数是否超时，具体的判断条件为：视图参数在指定时长内是否有自增一的更新，如果有更新，则说明当前共识内容的第一个共识阶段已按时处理完成，否则按超时处理，发起view-change流程。view-change流程与现有的pbft中的view-change流程类似，即重新确定提案节点，并由有提案节点针对未生成区块(即未完成共识流程)的共识内容重新发起共识流程，例如，未生成区块的有共识内容B2、B3、B4，此时视图参数为4，视图参数增加1后更新为5，重新确定节点5为新的提案节点，然后由节点5发起针对共识内容B2的共识请求，在确定针对共识内容B2的第一个共识阶段已完成时，确定节点6为针对共识内容B3的提案节点，由节点6发起针对共识内容B3的共识请求，在确定针对共识内容B4的第一个共识阶段已完成时，确定节点7为针对共识内容B4的提案节点，依次类推。

基于与上述区块链共识方法相同的发明构思，图7为本申请一实施例提供的区块链共识装置的结构示意图，如图7所示，本申请实施例还提供了一种区块链共识装置70，可应用于区块链中的任一节点，本实施例中，执行主体称为“本节点”，即以区块链中一个节点为例进行说明，其他节点具备同样的功能，执行的功能也都类似。

该装置包括：提案节点确定模块701和共识请求模块702。

提案节点确定模块701，用于当确定当前共识内容的第一个共识阶段已完成时，根据预设规则确定本节点是否为下一个共识内容的提案节点，其中每个共识内容需要经过至少两个共识阶段；

共识请求模块702，用于若确定本节点为下一个共识内容的提案节点，则向区块链中的各节点发送针对下一个共识内容的共识请求，共识请求用于指示共识内容所处的共识阶段。

可选地，提案节点确定模块701，还用于：

若收到区块链中超过预设比例的节点发送的针对当前共识内容的第一个共识阶段的投票消息，且收到当前共识内容的提案节点发送的针对当前共识内容的共识请求，则确定当前共识内容的第一个共识阶段已完成，根据预设规则确定本节点是否为下一共识内容的提案节点。

可选地，区块链共识装置70还包括投票模块，投票模块用于：接收当前共识内容的提案节点发送的共识请求链表，共识请求链表中包括：未生成区块的每个共识内容所对应的共识请求，每个共识请求包括状态参数，状态参数表示共识内容所处的共识阶段；按照共识请求链表中各个共识请求的排列顺序，依次对各个共识请求进行共识投票处理，以得到每个共识请求的投票结果；

相应地，共识请求模块702，具体用于：根据每个共识请求的投票结果，更新共识请求链表中的每个共识请求中的状态参数，以得到更新后的共识请求链表；将针对下一个共识内容的共识请求，添加到共识请求链表的队尾，获得新的共识请求链表；向区块链还用于：针对共识请求链表中的任一共识请求，若确定存在目标共识请求的投票结果为达成共识，则基于目标共识请求中的状态参数，确定目标共识请求对应的共识内容当前所处的共识阶段，并将目标共识请求中的状态参数，更新为当前所处的共识阶段之后的共识阶段对应的状态参数。

可选地，共识请求链表中的各个共识请求的排列顺序根据各共识请求生成顺序确定。

可选地，提案节点确定模块701还用于：在根据预设规则确定任一节点是否为下一个共识内容的提案节点之前，若确定当前共识内容的第一个共识阶段已完成，则视图参数增加1，其中，视图参数的初始值为1；

相应地，提案节点确定模块702，还用于：采用视图参数除以区块链的节点数量进行取余运算，获取余数；若本节点的节点序号等于余数，则确定本节点为下一个共识内容的提案节点。

可选地，当前共识内容的共识请求还包括：生成当前共识内容的共识请求时的视图参数；

相应地，提案节点确定模块701，用于：确定当前共识内容的共识请求中的视图参数与当前的视图参数一致，若一致，根据预设规则确定本节点是否为下一个共识内容的提案节点。

可选地，提案节点确定模块701，还用于若视图参数增加1之后的指定时长内视图参数未增加1，则重新确定提案节点。

本申请实施例提的区块链共识装置与上述区块链共识方法采用了相同的发明构思，能够取得相同的有益效果，在此不再赘述。

基于与上述区块链共识方法相同的发明构思，本申请实施例还提供了一种电子设备，该电子设备具体可以为单个物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器等。图8为本申请一实施例提供的电子设备的结构示意图，如图8所示，该电子设备80可以包括至少一个处理器801和至少一个存储器802。其中，存储器802存储有程序代码，当程序代码被处理器801执行时，使得处理器801执行本说明书上述“示例性方法”部分中描述的根据本申请各种示例性实施方式的区块链共识方法中的各种步骤。例如，处理器801可以执行如图3中所示的步骤S301、当确定当前共识内容的第一个共识阶段已完成时，根据预设规则确定本节点是否为下一个共识内容的提案节点，其中每个共识内容需要经过至少两个共识阶段；步骤S302、若确定本节点为下一个共识内容的提案节点，则向区块链中的节点发送针对下一个共识内容的共识请求。

处理器801可以是通用处理器，例如中央处理器(CPU)、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器802作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random Access Memory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器802还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

本申请实施例提供了一种计算机可读存储介质，用于储存为上述电子设备所用的计算机程序指令，其包含用于执行本申请任一示例性实施方式中的区块链共识方法的程序。

上述计算机存储介质可以是计算机能够存取的任何可用介质或数据存储设备，包括但不限于磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NAND FLASH)、固态硬盘(SSD))等。

在一些可能的实施方式中，本申请的各个方面还可以实现为一种计算机程序产品，其包括程序代码，当该计算机程序产品在服务器设备上运行时，该计算机程序产品用于使所述服务器设备执行本说明书上述“示例性方法”部分中描述的根据本申请各种示例性实施方式的区块链共识方法中的步骤，例如，所述服务器设备可以执行如图3中所示的步骤S301、当确定当前共识内容的第一个共识阶段已完成时，根据预设规则确定本节点是否为下一个共识内容的提案节点，其中每个共识内容需要经过至少两个共识阶段；步骤S302、若确定本节点为下一个共识内容的提案节点，则向区块链中的节点发送针对下一个共识内容的共识请求。

所述计算机程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

根据本申请的实施方式的用于区块链共识的计算机程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在服务器设备上运行。然而，本申请的程序产品不限于此，在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本申请的精神和原理，但是应该理解，本申请并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本申请旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。