CN109660601A - 一种区块链共识方法及区块链共识装置 - Google Patents

Abstract

本发明涉及区块链技术领域，尤其涉及一种区块链共识方法及区块链共识装置。该方法包括以下步骤：接收多个交易请求；将多个交易请求的部分或全部进行打包，获得打包后的交易信息；将打包后的交易信息进行共识处理。本发明将一定数量的交易请求打包后，得到打包后的交易信息，再将打包后的交易信息进行共识处理，减少了交易数据的网络传输量和次数，可以缩短共识时间和减少共识次数，从而整体提升共识效率和系统的业务吞吐量。

Description

一种区块链共识方法及区块链共识装置

技术领域

本发明涉及区块链技术领域，尤其涉及一种区块链共识方法及区块链共识装置。

背景技术

区块链是一种分布式账本技术，也可以看作是一种按时间顺序存储数据的数据结构。共识机制作为区块链的核心技术，是指通过区块链网络中特殊节点的投票，在很短时间内完成对交易的验证和确认；对一笔交易，如果利益不相干的若干个节点能够达成共识，就可以认为全网对此也能够达成共识。共识机制的目的是使所有的诚实节点保存一致的区块链视图，需要同时满足两个性质：1)一致性。所有诚实节点保存的区块链的前缀部分完全相同。2)有效性。由某诚实节点发布的信息终将被其他所有诚实节点记录在自己的区块中。

PBFT(Practical Byzantine Falut Tolerance，实用拜占庭容错)算法是一种共识算法。如图1所示，在理想的局域网情况下，对PBFT共识算法进行实际测试，具有4个节点的区块链网络，每次共识仅处理一笔交易，最高只能达到3000tps(Transaction PerSecond，一个表达系统处理能力的性能指标，每秒处理的消息数)左右。如果在普通生产环境下运行，考虑不稳定的网络状况和必需的节点数量，PBFT共识算法的处理能力只能达到四五百tps左右，共识处理效率差，远不能满足实际业务的需要。

发明内容

本发明提供了一种区块链共识方法及区块链共识装置，以解决现有技术中共识算法共识处理效率差，不能满足实际业务需要的问题。

本发明的一个方面，提供了一种区块链共识方法，包括以下步骤：

接收多个交易请求；

将多个交易请求的部分或全部进行打包，获得打包后的交易信息；

将打包后的交易信息进行共识处理。

进一步地，将多个交易请求的部分或全部进行打包的步骤具体包括以下步骤：

根据历史共识处理时长、交易请求效率和当前网络状况中的一项或多项，确定本轮共识处理的打包参数；

根据所述打包参数将多个交易请求的部分或全部进行打包。

进一步地，所述根据所述打包参数将多个交易请求的部分或全部进行打包的步骤包括：

根据所述打包参数以及各交易请求的接收先后顺序，将多个交易请求的部分或全部进行打包。

进一步地，所述打包参数包括打包数量；所述接收多个交易请求之后，还包括：

将接收到的交易请求放到预先建立的交易池中；

所述根据所述打包参数以及各交易请求的接收先后顺序，将多个交易请求的部分或全部进行打包的步骤包括：

根据所述交易池中各交易请求的接收先后顺序，对交易请求进行排序，并将排序后的交易请求从所述交易池中移除；

当排序后的交易请求数量达到所述打包数量时，将排序后的交易请求进行打包。

进一步地，所述根据历史共识处理时长、交易请求效率和当前网络状况中的一项或多项，确定本轮共识处理的打包参数之前，还包括：

获取各节点网络的带宽；

根据各节点网络的带宽以及各节点网络带宽所占的权重，确定当前最小网络带宽；

所述根据历史共识处理时长、交易请求效率和当前网络状况中的一项或多项，确定本轮共识处理的打包参数的步骤包括：

根据历史共识处理时长、交易请求频率以及所述当前最小网络带宽中的一项或多项，确定本轮共识处理的打包参数。

本发明的另一个方面，提供了一种实现上述中所述的区块链共识方法的区块链共识装置，包括：

第一接收模块，用于接收多个交易请求，并发送至打包模块；

打包模块，用于将多个交易请求的部分或全部进行打包，获得打包后的交易信息，并发送至共识处理模块；

共识处理模块，用于将打包后的交易信息进行共识处理。

进一步地，打包模块包括：

打包参数确定单元，用于根据历史共识处理时长、交易请求效率和当前网络状况中的一项或多项，确定本轮共识处理的打包参数，并发送至交易请求打包单元；

交易请求打包单元，用于根据接收的打包参数将多个交易请求的部分或全部进行打包，并发送至共识处理模块。

进一步地，交易请求打包单元具体用于根据接收的打包参数以及各交易请求的接收先后顺序，将多个交易请求的部分或全部进行打包。

进一步地，打包模块还包括：

存放单元，用于将接收到的交易请求放到预先建立的交易池中；

交易请求打包单元，用于根据所述交易池中各交易请求的接收先后顺序，对交易请求进行排序，并将排序后的交易请求从所述交易池中移除；当排序后的交易请求数量达到打包数量时，将排序后的交易请求进行打包，并发送至共识处理模块；

其中，打包参数包括打包数量。

进一步地，打包模块还包括最小带宽计算单元，用于获取各节点网络的带宽；根据各节点网络的带宽以及各节点网络带宽所占的权重，确定当前最小网络带宽，并将当前最小网络带宽发送至打包参数确定单元；

打包参数确定单元具体用于根据历史共识处理时长、交易请求频率以及所述当前最小网络带宽中的一项或多项，确定本轮共识处理的打包参数，并发送至共识处理模块。

本发明提供的区块链共识方法及区块链共识装置，与现有技术相比具有以下进步：本发明将一定数量的交易请求打包后，得到打包后的交易信息，再将打包后的交易信息进行共识处理，减少了交易数据的网络传输量和次数，可以缩短共识时间和减少共识次数，从而整体提升共识效率和系统的业务吞吐量。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为现有技术中共识处理过程的示意图；

图2为本发明实施例一中区块链共识方法的流程图；

图3为步骤S2具体实施时的流程图；

图4为本发明实施例中区块链共识装置的结构示意图；

图5为本发明实施例中共识处理过程的示意图；

图6为本发明实施例二中区块链共识方法的流程图；

图7为本发明实施例二中区块链共识方法具体工作时的流程图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非被特定定义，否则不会用理想化或过于正式的含义来解释。

本实施例提供了一种区块链共识方法及区块链共识装置。

实施例一

如图2，本实施例提供了一种区块链共识方法，包括以下步骤：

S1、接收多个交易请求；

S2、将多个交易请求的部分或全部进行打包，获得打包后的交易信息；

S3、将打包后的交易信息进行共识处理。

本实施例的区块链共识方法，将一定数量的交易请求打包后，得到打包后的交易信息，再将打包后的交易信息进行共识处理，减少了交易数据的网络传输量和次数，可以缩短共识时间和减少共识次数，从而整体提升共识效率和系统的业务吞吐量。

如图3，具体实施时，步骤S2具体包括以下步骤：

S21、根据历史共识处理时长、交易请求效率和当前网络状况中的一项或多项，确定本轮共识处理的打包参数；

S22、根据所述打包参数将多个交易请求的部分或全部进行打包。

其中打包参数可以是需要打包的交易请求的个数或者打包频率等参数，具体可以是使用智能调节算法，计算出具体的打包参数如交易请求的个数或者打包频率等。计算出的打包参数可以为下一轮共识处理提供参考数据。本实施例中共识处理的优化过程的关键点是交易请求打包的数量。这个数值并非是固定不变的，因为客户端发送交易请求的时间和数量是不确定的，有可能因为交易请求较少造成打包等待和延迟；反之，如果打包交易数量过多，在网络状况不佳的情况下同样会造成网络传输时间较长，导致共识效率降低。每轮共识前，系统会综合历史共识处理时长(如上次共识处理时长)、客户端交易请求效率和当前网络状况这三方面的数据，根据内置的智能调节算法，计算出本轮共识最优的交易打包参数。共识结束后的系统数据又可以为下轮共识提供参考。

具体实施时，步骤S22包括：

根据所述打包参数以及各交易请求的接收先后顺序，将多个交易请求的部分或全部进行打包。

由于接收各交易请求的时间不同，可以依据交易请求的接收时间对交易请求进行排序，如打包参数为打包数量，则按该顺序选取与打包数量一致的多个交易请求进行打包，有利于提高用户体验和提高工作效率。

具体实施时，实施步骤S21之前还包括：

获取各节点网络的带宽；

根据各节点网络的带宽以及各节点网络带宽所占的权重，确定当前最小网络带宽；

根据历史共识处理时长、交易请求频率以及所述当前最小网络带宽中的一项或多项，确定本轮共识处理的打包参数。

以网络因素为例，多个节点间的网络状况差异，尤其是在异构网络中的网络波动，都会导致共识过程中由于打包后的交易信息的大小导致个别节点间网络出现拥塞，影响到整个系统的共识效率。因此，本实施例动态检测节点间的带宽情况，每个节点收集到其它节点的带宽统计，依据最小的原则，来动态调整打包的交易请求的数量。其中，动态调整的原则是：每个节点在规定时间内(例如5秒)统计和节点相关的带宽情况；各节点将统计的结果发送给主节点，作为自身节点带宽情况数据参考；主节点根据各节点带宽实时数据和权重，计算出多节点间的最小带宽，再结合其他数据计算和调整打包的交易请求的数量。

如图4，本实施例的实现上述实施例中所述的区块链共识方法的区块链共识装置，包括：

第一接收模块，用于接收多个交易请求，并发送至打包模块；

打包模块，用于将多个交易请求的部分或全部进行打包，获得打包后的交易信息，并发送至共识处理模块；

共识处理模块，用于将打包后的交易信息进行共识处理。

本实施例的区块链共识装置，将一定数量的交易请求打包后，得到打包后的交易信息，再将打包后的交易信息进行共识处理，减少了交易数据的网络传输量和次数，可以缩短共识时间和减少共识次数，从而整体提升共识效率和系统的业务吞吐量。

如图4，打包模块包括：

打包参数确定单元，用于根据历史共识处理时长、交易请求效率和当前网络状况中的一项或多项，确定本轮共识处理的打包参数，并发送至交易请求打包单元；

交易请求打包单元，用于根据接收的打包参数将多个交易请求的部分或全部进行打包，并发送至共识处理模块。

在单笔交易数据大小不大于1k的情况下，网络传输时间占单笔交易共识时间49％；单笔交易数据大于1k的情况下，网络传输时间占单笔交易共识时间58～65％。因此，减少交易数据的网络传输量和次数，可以缩短共识时间和减少共识次数，从而整体提升共识效率。本实施例在深入了解PBFT共识算法原理的基础上，对每次共识能够批量打包处理的交易数量自动进行优化。通过动态调整交易打包数量，减少共识次数，提升区块链网络的业务处理能力。

本实施例共识处理的优化过程的关键点是打包的交易请求的数量。这个数值并非是固定不变的，因为客户端发送交易请求的时间和数量是不确定的，有可能因为交易请求较少造成打包等待和延迟；反之，如果打包的交易请求数量过多，在网络状况不佳的情况下同样会造成网络传输时间较长，导致共识效率降低。每轮共识前，系统会综合上次共识时长、客户端请求效率和当前网络状况三方面的数据，根据内置的智能调节算法，计算出本轮共识最优的打包参数。共识结束后的系统数据又可以为下轮共识提供参考。

具体实施时，交易请求打包单元具体用于根据接收的打包参数以及各交易请求的接收先后顺序，将多个交易请求的部分或全部进行打包。由于接收各交易请求的时间不同，可以依据交易请求的接收时间对交易请求进行排序，如打包参数为打包数量，则按该顺序选取与打包数量一致的多个交易请求进行打包，有利于提高用户体验和提高工作效率。

如图4，打包模块还包括最小带宽计算单元，用于获取各节点网络的带宽；根据各节点网络的带宽以及各节点网络带宽所占的权重，确定当前最小网络带宽，并将当前最小网络带宽发送至打包参数确定单元；

打包参数确定单元具体用于根据历史共识处理时长、交易请求频率以及所述当前最小网络带宽中的一项或多项，确定本轮共识处理的打包参数，并发送至共识处理模块。

以网络因素为例，多个节点间的网络状况差异，尤其是在异构网络中的网络波动，都会导致共识过程中由于打包后的交易信息的大小导致个别节点间网络出现拥塞，影响到整个系统的共识效率。因此，本实施例动态检测节点间的带宽情况，每个节点收集到其它节点的带宽统计，依据最小的原则，来动态调整打包的交易请求的数量。其中，动态调整的原则是：每个节点在规定时间内(例如5秒)统计和节点相关的带宽情况；各节点将统计的结果发送给主节点，作为自身节点带宽情况数据参考；主节点根据各节点带宽实时数据和权重，计算出多节点间的最小带宽，再结合其他数据计算和调整打包的交易请求的数量。有利于优化打包过程，提高共识效率。

本实施例中，共识处理模块可以使用PBFT共识算法对打包后的交易信息进行共识处理。本实施例的区块链共识方法与现有使用PBFT共识算法的一般处理过程的区别在于，一般处理过程的每次共识仅对一笔交易进行共识，本实施例的处理过程是将一定数量的交易请求打包后再进行共识处理，减少了共识的次数，提升了系统的整体业务吞吐量。

如图5，本实施例的区块链共识方法和区块链共识装置在具体工作时，客户端C1、C2和C3分别向主节点发送需要共识的交易请求，主节点接收3笔交易请求后将所有交易请求打包，主节点每次打包交易请求的数量由本轮共识前系统自动计算的参数确定。共识处理的具体流程如下：主节点将打包后的交易消息广播给所有副本节点；所有正常副本节点向所有节点(包括主节点)发送请求信息；所有准备阶段的节点向所有节点发送打包后的交易确认信息；所有确认阶段的节点向客户端发送回复信息。

实施例二

本实施例是在实施例一基础上的改进，实施例一的公开内容也包括在本实施例中。

本实施例中，可选的，所述打包参数包括打包数量；所述接收多个交易请求之后，还包括：

将接收到的交易请求放到预先建立的交易池中；

所述根据所述打包参数以及各交易请求的接收先后顺序，将多个交易请求的部分或全部进行打包的步骤包括：

根据所述交易池中各交易请求的接收先后顺序，对交易请求进行排序，并将排序后的交易请求从所述交易池中移除；

当排序后的交易请求数量达到所述打包数量时，将排序后的交易请求进行打包。

本实施中的打包参数包括打包数量，即需要进行打包的交易请求的个数；另外，通过设置存放单元将接收到的交易请求放到预先建立的交易池中，有利于对客户端发送的交易请求起到缓冲作用，避免交易堆叠造成网络拥挤。

如图6，本实施例的区块链共识方法，包括以下步骤：

S100、接收多个交易请求；

S200、将接收到的交易请求放到预先建立的交易池中；

S300、根据所述交易池中各交易请求的接收先后顺序，对交易请求进行排序，并将排序后的交易请求从所述交易池中移除；

S400、当排序后的交易请求数量达到打包数量时，将排序后的交易请求进行打包；

S500、将打包后的交易信息进行共识处理。

其中，打包参数包括打包数量。

设置交易池存放接收到的交易请求，供后续打包时选取交易请求，可以起到缓冲客户端交易请求的作用，有利于提高用户体验和共识效率。

如图7，本实施例的区块链共识方法的工作流程是：(1)系统设置定时器，用于周期检测交易池中的交易请求。如果交易池没有任何交易，系统计时10ms后自动开始一轮共识过程。(2)共识开始后，首先判断交易池中的交易请求的数量，如果存在交易请求，按交易请求的接收时间先后顺序获取交易请求，并按照时间进行序列化，序列化完成后从交易池移除该交易请求，进行步骤(3)；如果不存在交易请求，则重复步骤(1)。(3)直到从交易池中获取的交易请求数量达到打包参数，打包参数可以是本轮共识需要打包的交易请求数量值，主节点根据打包后的交易信息发送交易通知信息到所有副本节点，开始本次共识过程。(4)本次共识过程完成后，再重复步骤(2)。

相应的，如图4，本实施例的实现上述实施例中所述的区块链共识方法的区块链共识装置，打包模块还包括存放单元，用于将接收到的交易请求放到预先建立的交易池中；

交易请求打包单元，用于根据所述交易池中各交易请求的接收先后顺序，对交易请求进行排序，并将排序后的交易请求从所述交易池中移除；当排序后的交易请求数量达到打包数量时，将排序后的交易请求进行打包，并发送至共识处理模块；

其中，打包参数包括打包数量。

本实施中的打包参数包括打包数量，即需要进行打包的交易请求的个数；另外，通过设置存放单元将接收到的交易请求放到预先建立的交易池中，有利于对客户端发送的交易请求起到缓冲作用，避免交易堆叠造成网络拥挤。

本实施例的区块链共识方法和区块链共识装置经过实际测试，在局域网络和相同硬件环境下，优化后的PBFT共识算法能够提升共识效率达到20000TPS，可以满足大多数业务对处理能力的需求。

对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

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

Claims (10)

1.一种区块链共识方法，其特征在于，包括以下步骤：

接收多个交易请求；

将多个交易请求的部分或全部进行打包，获得打包后的交易信息；

将打包后的交易信息进行共识处理。

2.根据权利要求1所述的区块链共识方法，其特征在于，将多个交易请求的部分或全部进行打包的步骤具体包括以下步骤：

根据历史共识处理时长、交易请求效率和当前网络状况中的一项或多项，确定本轮共识处理的打包参数；

根据所述打包参数将多个交易请求的部分或全部进行打包。

3.根据权利要求2所述的区块链共识方法，其特征在于，所述根据所述打包参数将多个交易请求的部分或全部进行打包的步骤包括：

根据所述打包参数以及各交易请求的接收先后顺序，将多个交易请求的部分或全部进行打包。

4.根据权利要求3所述的区块链共识方法，其特征在于，所述打包参数包括打包数量；所述接收多个交易请求之后，还包括：

将接收到的交易请求放到预先建立的交易池中；

所述根据所述打包参数以及各交易请求的接收先后顺序，将多个交易请求的部分或全部进行打包的步骤包括：

根据所述交易池中各交易请求的接收先后顺序，对交易请求进行排序，并将排序后的交易请求从所述交易池中移除；

当排序后的交易请求数量达到所述打包数量时，将排序后的交易请求进行打包。

5.根据权利要求2所述的区块链共识方法，其特征在于，所述根据历史共识处理时长、交易请求效率和当前网络状况中的一项或多项，确定本轮共识处理的打包参数之前，还包括：

获取各节点网络的带宽；

根据各节点网络的带宽以及各节点网络带宽所占的权重，确定当前最小网络带宽；

所述根据历史共识处理时长、交易请求效率和当前网络状况中的一项或多项，确定本轮共识处理的打包参数的步骤包括：

根据历史共识处理时长、交易请求频率以及所述当前最小网络带宽中的一项或多项，确定本轮共识处理的打包参数。

6.一种实现权利要求1所述的区块链共识方法的区块链共识装置，其特征在于，包括：

第一接收模块，用于接收多个交易请求，并发送至打包模块；

打包模块，用于将多个交易请求的部分或全部进行打包，获得打包后的交易信息，并发送至共识处理模块；

共识处理模块，用于将打包后的交易信息进行共识处理。

7.根据权利要求6所述的区块链共识装置，其特征在于，打包模块包括：

打包参数确定单元，用于根据历史共识处理时长、交易请求效率和当前网络状况中的一项或多项，确定本轮共识处理的打包参数，并发送至交易请求打包单元；

交易请求打包单元，用于根据接收的打包参数将多个交易请求的部分或全部进行打包，并发送至共识处理模块。

8.根据权利要求7所述的区块链共识装置，其特征在于，交易请求打包单元具体用于根据接收的打包参数以及各交易请求的接收先后顺序，将多个交易请求的部分或全部进行打包。

9.根据权利要求8所述的区块链共识装置，其特征在于，打包模块还包括：

存放单元，用于将接收到的交易请求放到预先建立的交易池中；

交易请求打包单元，用于根据所述交易池中各交易请求的接收先后顺序，对交易请求进行排序，并将排序后的交易请求从所述交易池中移除；当排序后的交易请求数量达到打包数量时，将排序后的交易请求进行打包，并发送至共识处理模块；

其中，打包参数包括打包数量。

10.根据权利要求7所述的区块链共识装置，其特征在于，打包模块还包括最小带宽计算单元，用于获取各节点网络的带宽；根据各节点网络的带宽以及各节点网络带宽所占的权重，确定当前最小网络带宽，并将当前最小网络带宽发送至打包参数确定单元；

打包参数确定单元具体用于根据历史共识处理时长、交易请求频率以及所述当前最小网络带宽中的一项或多项，确定本轮共识处理的打包参数，并发送至共识处理模块。