WO2025214030A1

WO2025214030A1 - 区块提案方法、装置、电子设备和可读介质

Info

Publication number: WO2025214030A1
Application number: PCT/CN2025/081601
Authority: WO
Inventors: 邵珠光
Original assignee: Tencent Technology (Shenzhen) Co Ltd
Current assignee: Tencent Technology (Shenzhen) Co Ltd
Priority date: 2024-04-08
Filing date: 2025-03-10
Publication date: 2025-10-16
Anticipated expiration: 2026-10-08
Also published as: CN120780713A

Abstract

一种区块提案方法，由区块链中的区块链节点执行，包括：获取区块链中第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，每个投票结果包含建议事务数量，建议事务数量根据第一区块提案中的第一提案事务数量、及产生投票结果的区块链节点执行第一区块提案的执行时长确定(S510)；根据多个投票结果各自包含的建议事务数量，生成第二共识轮次的事务数量限额，第二共识轮次是第一共识轮次的下一共识轮次(S520)；按照事务数量限额，将本地事务池中的区块链事务打包，生成供区块链中第二共识轮次内多个区块链节点投票的第二区块提案(S530)；及在区块链中广播第二区块提案(S540)。

Description

区块提案方法、装置、电子设备和可读介质

相关申请

本申请要求2024年04月08日申请的，申请号为202410418430.9，名称为“区块提案方法、装置、电子设备和可读介质”的中国专利申请的优先权，在此将其全文引入作为参考。

技术领域

本申请涉及计算机技术领域，尤其涉及区块链技术领域，特别涉及一种区块提案方法、装置、电子设备和可读介质。

背景技术

随着区块链技术的发展，越来越多的业务系统开始使用区块链。在区块链中，区块链节点会将多笔区块链事务打包成一个提案来在区块链节点之间进行共识，共识通过后才会在区块链中生成区块。

在相关技术中，区块链节点会按照预设的区块事务数量上限和区块执行时长上限来打包区块链以进行提案。

然而，在此类技术中，提案过程会按照区块执行时长上限尽量多打包事务，使得提案区块的执行时长趋近于执行时长上限，而这可能会导致其他节点在验证提案时的执行时长超过区块执行时长上限而反对共识，进而造成提案失败，影响区块链的运行效率。

发明内容

本申请提供一种区块提案方法、装置、电子设备和可读介质。

根据本申请实施例的一个方面，提供一种区块提案方法，由区块链中的区块链节点执行，包括：

获取区块链中第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，每个投票结果包含建议事务数量，所述建议事务数量根据所述第一区块提案中的第一提案事务数量、及产生所述投票结果的区块链节点执行所述第一区块提案的执行时长确定；

根据所述多个投票结果各自包含的建议事务数量，生成第二共识轮次的事务数量限额，所述第二共识轮次是所述第一共识轮次的下一共识轮次；

按照所述事务数量限额，将本地事务池中的区块链事务打包，生成供所述区块链中第二共识轮次内多个区块链节点投票的第二区块提案；及

在所述区块链中广播所述第二区块提案。

根据本申请实施例的一个方面，提供一种区块提案装置，包括：

获取模块，配置成获取区块链中第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，每个投票结果包含建议事务数量，所述建议事务数量根据所述第一区块提案中的第一提案事务数量、及产生所述投票结果的区块链节点执行所述第一区块提案的执行时长确定；

生成模块，配置成根据所述多个投票结果各自包含的建议事务数量，生成第二共识轮次的事务数量限额，所述第二共识轮次是所述第一共识轮次的下一共识轮次；

打包模块，配置成按照所述事务数量限额，将本地事务池中的区块链事务打包，生成供所述区块链中第二共识轮次内多个区块链节点投票的第二区块提案；及

广播模块，配置成在所述区块链中广播所述第二区块提案。

根据本申请实施例的一个方面，提供一种电子设备，该电子设备包括：处理器；以及存储器，用于存储处理器的可执行指令；其中，该处理器配置为经由执行可执行指令来执行如以上技术方案中的区块提案方法。

根据本申请实施例的一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，当该计算机程序被处理器执行时实现如以上技术方案中的区块提案方法。

根据本申请实施例的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该电子设备执行上述各种可选实现方式中提供的区块提案方法。

本申请的一个或多个实施例的细节在下面的附图和描述中提出。本申请的其它特征、目的和优点将从说明书、附图以及权利要求书变得明显。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请技术方案在一个应用场景中的示例性系统构架示意图。

图2为本申请实施例中区块提案的总体情况示意图。

图3为本申请实施例中区块链网络的示意图。

图4为本申请实施例中区块链网络中区块的示意图。

图5示出了根据本申请的一个实施例的区块提案方法的流程图。

图6示出了根据本申请的一个实施例的区块提案方法的流程图。

图7为本申请实施例中生成第二共识轮次的事务数量限额的逻辑示意图。

图8为本申请实施例中生成第二共识轮次的事务数量限额另一逻辑示意图。

图9为本申请实施例中生成第二共识轮次的事务数量限额的另一逻辑示意图。

图10示出了根据本申请的一个实施例的区块提案方法的流程图。

图11为本申请实施例中节点投票结果的示意图。

图12为本申请实施例中节点投票结果具体结构的示意图。

图13为本申请实施例中区块提案处理整体流程的示意性流程图。

图14示意性地示出了本申请实施例中区块提案装置的组成框图。

图15示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

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

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

本申请实施例中，术语“模块”或“单元”是指有预定功能的计算机程序或计算机程序的一部分，并与其他相关部分一起工作以实现预定目标，并且可以通过使用软件、硬件(如处理电路或存储器)或其组合来全部或部分实现。同样的，一个处理器(或多个处理器或存储器)可以用来实现一个或多个模块或单元。此外，每个模块或单元都可以是包含该模块或单元功能的整体模块或单元的一部分。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

应理解，本申请的方案应用在区块链的共识节点进行提案的过程中，并且具体应用在将区块链事务打包成提案的场景。区块链系统实际上是一个分布式系统，但它又与普通的分布式系统不同，在区块链系统中，每个共识节点会对它都要达成一致的区块进行共识，只有共识一致后，才会得到整个区块链系统的认可，也就是区块链共识。在一个区块中往往会包含很多笔事务，一般而言，在允许的范围内，事务量越大其实越好，这是因为区块除了存储事务外，还会存储区块头、节点投票等信息，而区块头和节点投票等信息往往大小基本是固定的，那么这个区块中存储的事务数量越多，对应的存储就越省空间。这个允许范围一般包括两部分，一个区块链事务的最大数量和整个区块中事务的最长执行时间。

区块头(Block header)是区块链中每个区块的一部分，包含输入信息特征值、版本号、时间戳、难度值以及父区块的区块头特征值等信息，用于保证区块链中每个区块中存储的区块数据均与父区块中存储的区块数据存在关联，确保区块中输入信息的安全性。

区块链事务(Blockchain transaction)是在区块链系统中区块链节点之间进行数据的传输、处理、验证等一系列交互活动的操作单元，区块链节点会将多笔这样的事务打包成一个提案，在区块链节点间进行共识，共识通过后在区块链中生成包含这些事务信息的区块。该操作存在数量上限和执行时长上限等限制，并且在区块链的共识过程中，区块链节点会根据提案中事务的执行情况，对下一轮共识提案中所要包含的事务数量提出建议，以动态调整每个区块中事务的数量，从而提高区块链的运行效率。

最大数量(Maximum quantity)：在确定下次打包事务时，根据各个节点投票中的建议事务数量计算得出的一个数量上限值，下一轮主节点会按照该数量上限从事务池中获取要打包的事务。

如果一个区块链中事务数量非常大，且不做控制，因为事务是需要执行的，那么会导致节点计算资源过大，整个区块链性能受影响；类似的，如果一个区块的执行时间不做控制，也会导致整个区块链很长时间无法达成共识，从而使得区块链性能受影响。

那么目前业内通常的解决方案，就是为这两个参数设置一个上限，数量上限一般会根据每秒事务数和业务需求来设置，而时间往往会采用固定的方式，例如10秒。事务数(Transaction volume)：指在区块链系统中，单位时间内发生的事务(或交易)的数量，通常用于衡量区块链系统的处理能力和业务繁忙程度，数量上限一般会根据每秒事务数和业务需求来设置。

从时间角度来看，则会存在一定的风险，为了更高的性能，对于提案的主节点而言，其肯定会尽量打包更多的事务进提案，这样执行时间就较长，但肯定会低于10秒(例如9.8秒)，然而从节点则不一样，它也会执行这个区块中的所有事务，一旦受到服务器性能和资源占用等原因的影响而造成执行时间超过10秒，从节点会认为主节点的提案有问题投反对票，进而有可能会导致本轮共识达不成一致而需要重新进行共识，影响了区块链的整体性能。

基于此，本申请实施例的技术方案提出了一种区块提案方案。具体地，如图1所示，根据本申请实施例的应用于区块提案方案的系统架构可以包括四个区块链节点构成的区块链网络。实现区块链节点的电子设备可以包括智能手机、平板电脑、笔记本电脑、智能语音交互设备、智能家电、车载终端、飞行器等等。实现区块链节点的电子设备还可以是提供各种服务的服务器，其可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)以及大数据和人工智能平台等基础云计算服务的云服务器。区块链节点之间可以存在通信链路的各种连接类型的通信介质，例如可以是有线通信链路或者无线通信链路。

根据实现需要，本申请实施例中的系统架构可以具有任意数目的终端设备和服务器。例如，实现区块链节点的电子设备可以是由多个服务器设备组成的服务器群组。另外，本申请实施例提供的技术方案可以应用于任意的区块链节点，或者可以由多个区块链节点共同实施，本申请对此不做特殊限定。

如图1所示，一个区块链节点作为区块链中的主节点110进行提案。可以理解的是，主节点可以是区块链的任意一个共识节点，并且区块链中的共识节点通常会按照预定的规则轮流成为主节点来进行提案，主节点之外的其他共识节点则成为从节点，从节点根据主节点的提案进行投票来进行共识，主节点确认在达成共识后通知各个从节点将新区块上链。在本申请的一个实施例中，区块链中的主节点110会向从节点120发送区块提案。而从节点在向主节点110发送对区块提案的投票时，从节点120也会关于下一轮提案中打包事务数量提供建议数量。所有从节点120都会进行投票以及提供建议数量。主节点110在会根据从节点120提供的建议来确定下一轮要打包的事务数量。并且在下一轮提案时按照确定的数量进行打包。

请参阅图2，图2为本申请实施例中区块提案的总体情况示意图。如图2所示，主节点会打包一笔事务(10000笔)并执行，形成区块提案。假定主节点执行该区块提案中所有事务的时间为9.8秒。区块提案会被广播到区块链中的从节点。节点2、节点3和节点4会验证接收到的提案。每个节点都会执行所接收到的区块提案中的所有事务，并基于执行结果确定投票内容，例如根据所有事务执行成功或者失败来对区块进行赞同或者反对的投票，同时，节点还会统计执行提案中所有事务的执行时长以及执行的超时情况，假定一个从节点的总执行时间为10.2秒，则由于事务超时，该节点的投票内容会是反对票。节点还会根据执行时长与提案中所包含的事务的数量来生成一个自己建议的事务数量。例如，由于执行超时，从节点会建议将事务数量设置为5000笔)，从节点会在对提案的投票信息中附加自己建议的事务数量。从节点的投票信息会被广播给其他节点。区块链中的所有节点都会收集其他节点关于该提案的投票信息，并根据所收集到的投票信息判断第二轮投票中是否赞成区块上链。在第二轮投票中，如果是大多数节点都不赞成区块上链的情况下，各个节点也会投票不赞成提交区块。随后，各个节点会收集其他节点对第二轮投票的投票信息，从未最终判断是否提交区块，同时也会根据各个从节点建议的事务数量，确定新的提案事务数量限制。在下一轮共识中，成为主节点的节点会按照其所确定的提案事务数量限制来打包事务进行提案，例如，多数节点建议将事务数量设置为5000笔，则在下一轮的提案中，主节点会将5000笔事务打包成提案来进行提案流程。可以理解，大多数区块在执行5000笔事务的提案时仍然超时，则经过上述的投票和重新确定事务数量过程，提案中的事务数量会进一步减少，而如果大多数节点在执行5000笔事务时有较多的处理能力空闲，则可能会通过上述过程提高事务数量。

区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块(即区块)，每一个数据块包含了一批次网络事务的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链是由区块链网络中的节点共同维护的。比如，在图3所示的区块链网络中，可以包括多个节点301，多个节点301可以是形成区块链网络的各个客户端。每个节点301在进行正常工作可以接收到输入信息，并基于接收到的输入信息维护该区块链网络内的共享数据。为了保证区块链网络内的信息互通，区块链网络中的每个节点之间可以存在信息连接，节点之间可以通过上述信息连接进行信息传输。例如，当区块链网络中的任意节点接收到输入信息时，区块链网络中的其它节点便根据共识算法获取该输入信息，将该输入信息作为共享数据进行存储，使得区块链网络中全部节点上存储的数据均一致。共识算法(Consensus algorithm)是指在区块链网络中，多个节点之间针对区块提案达成共识的算法，通过该算法，节点可以获取输入信息并将其作为共享数据进行存储，使得区块链网络中全部节点上存储的数据均一致。

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

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

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

创始块(Genesis block)是区块链中的第一个区块，包含区块头和区块主体，区块头中存储有输入信息特征值、版本号、时间戳和难度值等，区块主体中存储有输入信息，是后续区块的基础，后续区块以此为父区块依次生成。

父区块(Parent block)：在区块链中，每个区块都有一个前序区块，该前序区块即为当前区块的父区块。每个区块的区块头中会存储父区块的区块头特征值，使得区块链中每个区块中存储的区块数据均与父区块中存储的区块数据存在关联，保证了区块中输入信息的安全性。

主节点110和从节点120所获得的区块链数据是可以如图4所示的区块结构。可以理解的是，虽然示出了3个区块，但主节点110和从节点120可以一次获得更多或者更少的区块，或者一次性获得区块链中的所有区块。

在本申请的实施例中，建议事务数量的相关信息可以以区块链事务的形式保存在图4中所示出的区块链结构的区块主体中，并且随着区块一起在节点之间进行共识以及在区块链中上链。

图5示出了根据本申请的一个实施例的区块提案方法的流程图，该区块提案方法可以由具有计算处理功能的设备来执行，比如可以是区块链节点的计算设备。参照图5所示，该区块提案方法至少包括步骤S510至步骤S540，详细介绍如下：

步骤S510，获取区块链中第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，每个投票结果包含建议事务数量，建议事务数量根据第一区块提案中的第一提案事务数量、及产生投票结果的区块链节点执行第一区块提案的执行时长确定。

第一共识轮次(First consensus round)，是在区块链的共识过程中针对第一区块提案进行投票和达成共识的轮次。在执行步骤S510时，第一共识轮次为当前共识轮次。

第二共识轮次(Second consensus round)是第一共识轮次的下一共识轮次，在该轮次中，主节点会按照上一轮确定的第二共识轮次的事务数量限额来打包区块链事务进行提案。

第一区块提案(First block proposal)是当前共识轮次(第一共识轮次)的主节点将区块链事务打包生成的区块提案，用于在区块链节点之间进行共识。

事务(Transaction)在区块链场景下，是区块链节点之间进行数据的传输、处理、验证等一系列交互活动的操作单元，区块链节点会将多笔这样的事务(或交易)打包成一个提案，在区块链节点间进行共识，共识通过后在区块链中生成包含这些事务(或交易)信息的区块。

建议事务数量(Suggested transaction quantity)是指根据第一区块提案中的第一提案事务数量、及产生投票结果的区块链节点执行第一区块提案的执行时长确定的一个数量值，该数量值表示投票节点根据其对第一区块提案执行情况对下一轮共识提案中所要包含的事务数量提出的建议。

第一提案事务数量(First proposed transaction quantity)是指第一区块提案打包时所采用的事务数量。

当前的区块链节点(即当前执行区块提案方法的区块链节点)在第一共识轮次中是从节点，其会从区块链中的各个节点接收第一区块提案的第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果。第一区块提案是当前共识轮次的主节点打包生成的区块。可以理解，第一区块提案打包是时所采用的事务数量限制也可以是按照本申请的方案确定的。投票结果是区块链中的各个节点基于对第一区块提案的校验和执行结果所确定的，其中会包含节点对第一区块提案的投票内容，通常为赞成或者反对，以及建议事务数量。建议事务数量根据第一区块提案中的第一提案事务数量、及产生投票结果的区块链节点执行第一区块提案的执行时长确定，其表示投票节点根据其对第一区块提案执行情况对下一轮共识提案中所要包含的事务数量提出的建议。可以理解，投票节点如果发现第一区块提案执行超时，则所确定的建议事务数量会比第一提案事务数量更少，而如果投票节点在执行第一区块提案后发现执行时长距离预设的最大时长较远，则会提出相较于第一提案事务数量更多的建议事务数量。需要强调的是，本地节点所获得的第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果不一定来自于区块链中的所有节点，而是只要获得的投票数量满足区块链的共识策略中确定共识结果的条件即可。即，如果共识条件要求有一半的节点赞成就可以达成共识，则本地节点只要获得一半的赞成票或者反对票就可以确定共识结果，并执行本申请的方案。本申请中多个可以是至少两个。

步骤S520，根据多个投票结果各自包含的建议事务数量，生成第二共识轮次的事务数量限额，第二共识轮次是第一共识轮次的下一共识轮次。

事务数量限额(Transaction quantity limit)是指在某个共识轮次中，主节点进行提案时所采用的事务数量的限制值，该值由上一轮共识中多个区块链节点针对上一区块提案产生的投票结果中的建议事务数量生成。

本地节点会根据第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中的建议事务数量生成第二共识轮次的事务数量限额，第二共识轮次是第一共识轮次的下一共识轮次。第二共识轮次的事务数量限额会被用作下一轮共识中的主节点进行提案时的事务数量限制。在确定第二共识轮次的事务数量限额时，可以先根据预设的生成策略从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中选择出一部分建议事务数量，例如在执行时长比预设时长短时选择比第一提案事务数量更多的建议事务数量，而在执行时长超时则选择比第一提案事务数量更少的建议事务数量。然后，再基于所选择的建议事务数量进行确定第二共识轮次的事务数量限额，例如可以是均值、最大值、中位数或者选择其中一个作为结果等。

步骤S530，按照事务数量限额，将本地事务池中的区块链事务打包，生成供区块链中第二共识轮次内多个区块链节点投票的第二区块提案。

本地事务池(Local transaction pool)是区块链节点本地存储区块链事务的一个集合，主节点会从该池中获取事务进行打包生成区块提案。

在本实施例中，本地节点在下一轮的共识轮次中成为主节点。本地节点成为主节点后，会根据上一轮的投票结果来确定是否按照第一区块提案将事务打包上链。但无论第一区块提案是否达成共识。主节点在下一轮共识中，在需要进行提案时，会将上一轮共识中确定的第二共识轮次的事务数量限额作为提案时的事务数量限制。即，本地节点会将本地事务池中事务数量限额的区块链事务打包，生成供区块链中第二共识轮次内多个区块链节点投票的第二区块提案；及在区块链中广播第二区块提案。取决于第一区块提案共识的结果成功与否，第二区块提案中所包含的具体事务可以与第一区块提案相同或者不同。具体地，本地节点在打包第二区块提案时，会执行要打包的事务并且统计执行时长。本地节点会确保第二区块提案中的事务数量小于或者等于事务数量限额，并且第二区块提案中所有事务的总执行时长不超过区块链中的预设执行时长阈值。

总执行时长(Total execution time)：区块链节点执行区块提案中所有区块链事务所花费的总时间，节点会根据该时长和事务完成数量生成事务建议数量。事务建议数量(Suggested quantity of transactions)与建议事务数量含义相同，是指节点根据执行区块提案中所有事务的总执行时长和完成事务数量生成的一个数量值，该数量值表示节点根据其对区块提案执行情况对下一轮共识提案中所要包含的事务数量提出的建议，会附加在投票结果中。

步骤S540，在区块链中广播第二区块提案。

第二区块提案(Second block proposal)是主节点在下一轮共识(第二共识轮次)中，按照第二共识轮次的事务数量限额，将本地事务池中的区块链事务打包生成的区块提案，用于指示区块链中第二共识轮次内多个区块链节点进行投票。

在打包完成后，本地节点作为当前共识轮次(第一区块提案完成后成为了上一轮共识)的主节点，会在区块链中广播第二区块提案。区块链中的从节点则会根据第二区块提案进行共识过程，并且在达成共识后在区块链中生成第二区块提案所提交的区块。可以理解的是，在第二区块提案的共识过程中，各个从节点也会基于第二区块提案的事务数量和执行时长进行事务数量的建议，从而继续对再下一轮共识轮次的区块提案中打包的事务数量进行调整。因此，区块提案中的事务数量限制会随着共识过程中各个从节点所提出建议事务数量而进行动态的调整。这能够运行过程中及时解决事务过多而导致超时或者事务过少而浪费资源的问题，而不需要人工进行干预和配置，使得区块链的运行效率更高。

在本申请的实施例中，区块链节点在获取到针对第一区块提案的第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果后，会根据各个投票结果中的建议事务数量来生成第二共识轮次的事务数量限额，第二共识轮次是第一共识轮次的下一共识轮次，并且在成为提案节点的时候，按照所确定的第二共识轮次的事务数量限额来打包区块链事务成为新的区块提案，并在区块链中广播，以根据在区块链中生成新区块。通过这样的方式，在进行共识的过程中根据各个节点的建议来调整下一次进行提案时打包的事务数量，从而能够在提案的执行结果和执行时长过程时自动对区块提案中所包含的事务进行调整，避免区块提案中事务过多而造成在验证提案时执行超时，进而防止验证提案执行超时而造成提案失败，有利于提高区块链的运行效率。

在本申请的实施例中，还提出了对图5所示实施例的技术方案进行细化的其它实施例，具体如图6所示，在本申请的一个实施例的区块提案方法中，可以包括如下步骤：

步骤S610，获取区块链中第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，每个投票结果包含建议事务数量，建议事务数量根据第一区块提案中的第一提案事务数量、及产生投票结果的区块链节点执行第一区块提案的执行时长确定。

可选地，步骤S610的实现细节与图5中所示的步骤S510一致，不再赘述。

步骤S620，根据第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，确定针对第一区块提案的提案共识结果；

提案共识结果(Proposal consensus result)是指根据区块链的共识策略，对第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果进行判断后，得出的关于第一区块提案是否达成共识的结果，通常分为提案成功和提案失败。

步骤S630，根据提案共识结果，从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中获取与提案共识结果相对应的投票结果，作为候选投票结果；

候选投票结果(Candidate voting result)是指根据提案共识结果，从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中获取的与提案共识结果相对应的投票结果，用于生成第二共识轮次的事务数量限额。

步骤S640，根据候选投票结果中的建议事务数量，生成第二共识轮次的事务数量限额，第二共识轮次是第一共识轮次的下一共识轮次。

在本实施例中，本地节点在生成第二共识轮次的事务数量限额时，会根据提案共识结果来从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中获取与提案共识结果相对应的投票结果。具体地，本地节点会先根据第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，确定针对第一区块提案的提案共识结果。确定过程通常会根据区块链的共识策略来确定。

例如，在3f+1的共识网络中，对于每轮投票，每个节点都只需要收集2f+1张投票结果即可确定共识成功，或者收集到f+1张投票结果就可以确定共识失败，但每个节点收集到的投票结果可能是不同的。共识网络(Consensus network)：由多个区块链节点组成的网络，节点在该网络中针对区块提案进行投票和达成共识的过程。不同的共识网络有不同的共识策略，例如在3f+1的共识网络中，对于每轮投票，每个节点都只需要收集2f+1张投票结果即可确定共识成功，或者收集到f+1张投票结果就可以确定共识失败。

本地节点在确定提案共识结果后，会从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中获取与提案共识结果相对应的投票结果，作为候选投票结果。具体地，第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果对于提案共识结果的影响程度和作用是不同的，而本地节点则基于各个投票结果对于提案共识结果的影响程度、关联程度和作用来选择投票结果。通常，本地节点会选择对提案共识结果起到正向作用的投票结果作为候选投票结果。投票结果的作用总体分为正向作用、负向作用和无作用，正向作用标识其与共识结果的方向一致，负向作用则是与共识结果的方向相反，无作用则是与共识结果没有关联。针对共识结果是失败的情况，则反对票是正向作用，赞成票是负向作用，而弃权票则是无作用。例如，共识结果是失败，但失败原因是某一个共识节点启动了一票否决的机制，则该否决票对共识结果的影响和作用是最大的，则获取该投票结果，作为候选投票结果。在一些实施例中，本地节点会按照预设的比例，从正向作用的投票结果和负向作用的投票结果中分别选择一部分来作为候选投票结果。最后，本地节点会根据候选投票结果中的建议事务数量，生成第二共识轮次的事务数量限额，第二共识轮次是第一共识轮次的下一共识轮次。通过根据与提案共识结果相对应的投票结果中的建议事务数量，生成第二共识轮次的事务数量限额，第二共识轮次是第一共识轮次的下一共识轮次，从而能够使得第二共识轮次的事务数量限额的确定因素中投票正确的结果的影响程度更高，有利于提高所确定的第二共识轮次的事务数量限额的准确性。

步骤S650，按照事务数量限额，将本地事务池中的区块链事务打包，生成供区块链中第二共识轮次内多个区块链节点投票的第二区块提案。

可选地，步骤S650的实现细节与图5中所示的步骤S530一致，不再赘述。

步骤S660，在区块链中广播第二区块提案。

可选地，步骤S660的实现细节与图5中所示的步骤S540一致，不再赘述。

在本申请的实施例中，区块链节点在获取到针对第一区块提案的第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果后，会根据各个投票结果中的建议事务数量来生成第二共识轮次的事务数量限额，并且在成为提案节点的时候，按照所确定的第二共识轮次的事务数量限额来打包区块链事务成为新的区块提案，并在区块链中广播，以根据在区块链中生成新区块。通过这样的方式，在进行共识的过程中根据各个节点的建议来调整下一次进行提案时打包的事务数量，从而能够在提案的执行结果和执行时长过程时自动对区块提案中所包含的事务进行调整，避免区块提案中事务过多而造成在验证提案时执行超时，进而防止验证提案执行超时而造成提案失败，有利于提高区块链的运行效率。

在本申请一些可选的实施例中，基于上述的技术方案，在根据提案共识结果，从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中获取与提案共识结果相对应的投票结果，作为候选投票结果过程中，如果提案共识结果为提案成功，则节点从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中投赞成票的投票结果，作为候选投票结果。如果提案共识结果为提案失败，则节点从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中投反对票的投票结果，作为候选投票结果。在本实施例中，本地节点会选择投票内容符合提案共识结果的投票结果作为候选投票结果，从而能够避免对共识节点判断错误的节点所提出的建议数量影响所确定的指定数量，有利于降低确定事务数量的过程受到作恶数据影响的概率，提高区块链系统的安全性。

在本申请一些可选的实施例中，基于上述的技术方案，在根据候选投票结果中的建议事务数量，生成第二共识轮次的事务数量限额的过程中，如果提案共识结果为提案成功，则获取第一区块提案中的第一提案事务数量。如果第一提案事务数量大于或等于候选投票结果中的建议事务数量，则节点将第一提案事务数量作为第二共识轮次的事务数量限额。如果第一提案事务数量小于候选投票结果中的建议事务数量，则节点根据第一提案事务数量与所选择的建议事务数量的均值，生成第二共识轮次的事务数量限额。

具体地，在共识结果为提案共识成功时，存在两种情况，即从节点对主节点在第一区块提案中打包的第一提案事务数量认可或者不认可。具体地，如果第一提案事务数量大于或等于候选投票结果中的建议事务数量，则表示从节点对主节点打包的数量认可，可以直接第一提案事务数量作为第二共识轮次的事务数量限额。请参阅图7，图7为本申请实施例中生成第二共识轮次的事务数量限额的逻辑示意图。如图7所示，节点2提出的建议事务数量与主节点打包的数量是一致的，因此如果节点2在下一轮成为主节点，则直接将主节点打包的数量作为下一轮共识中的打包数量。需要注意的是，节点4由于投了反对票，因此其所提供的建议事务数量不用考虑，如果节点4在下一轮成为主节点，也会直接将主节点打包的数量(即10000笔)作为下一轮共识中的打包数量。如果第一提案事务数量小于候选投票结果中的建议事务数量，则表示从节点对主节点打包的事务数量不认可，节点可以根据第一提案事务数量与所选择的建议事务数量的均值，生成第二共识轮次的事务数量限额。请参阅图8，图8为本申请实施例中生成第二共识轮次的事务数量限额的另一逻辑示意图。如图8所示，节点2提出的建议事务数量为10000笔，而主节点只打包了5000笔，此时，节点2对主节点的打包数量不认可，则节点2在成为主节点时，会根据二者数量的均值来确定第二共识轮次的事务数量限额，即7500笔。节点4也是类似，其所提出的建议事务数量为6000笔，也高于主节点的打包数量，因此，在节点4成为主节点时，在提案中打包事务数量会是7000笔。在此需要注意的是，节点2与节点4所接收到的投票结果不同，由于节点2没有接收到节点4的投票结果，因此，在节点2确定第二共识轮次的事务数量限额时，只考虑节点1和节点2所提出的数量，而节点3则由于数量超限而本舍弃。在本实施例中，根据从节点的建议事务数量与主节点所打包的事务数量的比对结果来对应确定第二共识轮次的事务数量限额，从而能够对于主节点打包数量较少时及时提高区块提案的事务数量限制，从而避免区块中事务数量过少而导致共识过程中的处理资源浪费，有利于提高方案的资源利用率。

在本申请一些可选的实施例中，基于上述的技术方案，候选投票结果包含第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果。在如果第一提案事务数量小于候选投票结果中的建议事务数量，则根据第一提案事务数量与所选择的建议事务数量的均值，生成第二共识轮次的事务数量限额的过程中，如果第一提案事务数量小于候选投票结果中的建议事务数量，则节点获取区块链的区块事务数量阈值。如果候选投票结果中任一投票结果的建议事务数量大于区块事务数量阈值，则将投票结果从候选投票结果中删除。然后，节点根据第一提案事务数量与候选投票结果中各个投票结果的建议事务数量的均值，生成第二共识轮次的事务数量限额。在本申请方案中，如果从节点所确定的建议事务数量高于区块链配置的最大数量限制，则会将该建议事务数量舍弃，从而能够避免区块提案中事务数量过多导致提案执行超时而引起共识失败，有利于提高方案的稳定性。区块事务数量阈值(Block transaction quantity threshold)是区块链配置的一个最大数量限制，用于限制区块提案中事务的数量，若从节点所确定的建议事务数量高于该阈值，则该建议事务数量会被舍弃。

在本申请一些可选的实施例中，基于上述的技术方案，在根据候选投票结果中的建议事务数量，生成第二共识轮次的事务数量限额的过程中，如果提案共识结果为提案失败，则节点获取候选投票结果中的建议事务数量，然后根据候选投票结果中建议事务数量的总和以及候选投票结果的数量，确定第二共识轮次的事务数量限额。在本实施例中，如果提案共识失败，则只会选择投反对票的投票结果中的建议事务数量来确定第二共识轮次的事务数量限额。

请参阅图9，图9为本申请实施例中生成第二共识轮次的事务数量限额的另一逻辑示意图。如图9所示，由于共识结果失败，本地节点只会选择包含反对票的节点3和节点4的投票结果作为候选投票结果，而所确定的第二共识轮次的事务数量限额也是二者建议数量的均值。第二共识轮次的事务数量限额可以按照其他的方式确定，例如最大值或者最小值，或者先基于建议事务数量进行聚类后再进行分类计算等。通过在提案失败时是只按照失败的候选投票结果中的建议事务数量来确定第二共识轮次的事务数量限额，能够对过高的事务数量或者过长的执行时间进行及时的缩减，有利于避免后续共识过程再次失败，提高共识成功率。

聚类(Clustering)：在确定第二共识轮次的事务数量限额时，如果提案共识失败，可先基于建议事务数量将数据进行分组，使得同一组内的数据具有较高的相似性，不同组的数据具有较大的差异性，然后再对不同组进行分类计算以确定限额的一种数据处理方法。

在本申请的实施例中，还提出了对图5所示实施例的技术方案进行细化的其它实施例，具体如图10所示，在本申请的一个实施例的区块提案方法中，可以包括如下步骤：

步骤S1010，获取区块链中第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，每个投票结果包含建议事务数量，建议事务数量根据第一区块提案中的第一提案事务数量、及产生投票结果的区块链节点执行第一区块提案的执行时长确定。

可选地，步骤S1010的实现细节与图5中所示的步骤S510一致，不再赘述。

步骤S1020，根据多个投票结果各自包含的建议事务数量，生成第二共识轮次的事务数量限额，第二共识轮次是第一共识轮次的下一共识轮次。

可选地，步骤S1020的实现细节与图5中所示的步骤S520一致，不再赘述。

步骤S1030，按照事务数量限额，将本地事务池中的区块链事务打包，生成供区块链中第二共识轮次内多个区块链节点投票的第二区块提案。

可选地，步骤S1030的实现细节与图5中所示的步骤S530一致，不再赘述。

步骤S1040，在区块链中广播第二区块提案。

可选地，步骤S1040的实现细节与图5中所示的步骤S540一致，不再赘述。

步骤S1050，获取主节点生成的第三区块提案；

第三区块提案(Third block proposal)是在第二区块提案之后，由主节点打包生成的区块提案，但不一定是第二区块提案的下一轮提案。

步骤S1060，执行第三区块提案中的区块链事务，得到第三区块提案的执行结果和执行时长；

步骤S1070，根据执行结果和执行时长，确定本地节点的建议事务数量；

步骤S1080，根据第三区块提案的执行结果和本地节点的建议事务数量，生成针对第三区块提案的节点投票结果；

节点投票结果(Node voting result)是本地节点根据第三区块提案的执行结果和本地节点的建议事务数量生成的结果，包括投票信息、投票签名、建议事务数量、当前区块高度、共识轮数以及信息签名等内容，用于在区块链中广播，参与对第三区块提案的共识。

步骤S1090，在区块链中广播节点投票结果。

在本实施例中，本地节点在广播第二区块提案后，身份从主节点切换成从节点，而一个其他节点成为主节点。该主节点会打包生成第三区块提案。需要注意的是，第三区块提案是第二区块提案之后的提案，但不一定是第二区块提案的下一轮提案。本地节点作为从节点，会执行第三区块提案中的区块链事务，得到第三区块提案的执行结果和执行时长。随后，根据执行结果和执行时长，确定本地节点的建议事务数量。具体地，如果执行结果为成功，但执行时长较短，则可以在建议事务数量中提高事务数量，而如执行结果为失败或者执行时长较长，则可以在建议事务数量中降低事务数量。随后，本地节点根据第三区块提案的执行结果和本地节点的建议事务数量，生成针对第三区块提案的节点投票结果。请参阅图11，图11为本申请实施例中节点投票结果的示意图。如图11所示，节点投票结果总体分为两类，赞成票和反对票。这两种结果都有对应的标识，并且都会附带本地节点的建议事务数量。最后，本地节点在区块链中广播节点投票结果。当存在作恶节点时，由于区块中事务数量上限的限制，一般作恶节点会发送一些比较低的值，这样就会导致持续的几轮区块中的事务数据量都持续的下降，但可以达成共识，只是每个区块中的事务量比较少。通过在投赞成票时也增加建议事务数量，从而能够及时对过低的事务数量进行修正，从而避免作恶节点造成区块链事务处理效率下降，提高方案的安全性。

在本申请一些可选的实施例中，基于上述的技术方案，在根据第三区块提案的执行结果和本地节点的建议事务数量，生成针对第三区块提案的节点投票结果的过程中，节点会根据第三区块提案中区块链事务的执行结果和第三区块提案中的提案结果之间的匹配结果，确定针对第三区块提案的投票信息。然后，节点根据本地节点的区块链密钥，对投票信息进行签名，得到投票签名，并且根据本地节点的区块链密钥，对建议事务数量进行签名，得到信息签名。最后，节点根据投票信息和投票签名以及建议事务数量和信息签名，生成针对第三区块提案的节点投票结果。

区块链密钥(Blockchain key)是区块链节点所拥有的一种密钥，用于对投票信息、建议事务数量等重要信息进行签名，以保证信息在传输和存储过程中的安全性、真实性和完整性，防止信息被篡改或伪造。

投票签名(Voting signature)是指本地节点根据自身的区块链密钥，对针对第三区块提案的投票信息进行签名后得到的结果，用于确保投票信息的真实性和完整性。投票信息(Voting information)是根据第三区块提案中区块链事务的执行结果和第三区块提案中的提案结果之间的匹配结果确定的信息，通常为赞成或者反对，用于表达节点对第三区块提案的态度，是节点投票结果的重要组成部分。

信息签名(Information signature)是本地节点根据自身的区块链密钥，对建议事务数量、区块链中的当前区块高度以及第三区块提案的共识轮数进行签名后得到的结果，用于防止投票结果的伪造发送，确保建议事务数量等信息的真实性和有效性。

当前区块高度(Current block height)是指区块链中当前所在区块的位置标识，代表从区块链的创始块开始到当前区块所经过的区块数量，在生成节点投票结果时添加该信息，可用于判断投票结果是否是针对当前共识轮次发出，防止投票结果的伪造发送。

在本实施例中，在节点投票结果中，分别对投票信息和建议事务数量级进行签名，从而使得对不具备提供建议事务数量能力的节点仍可以只基于投票信息和对应签名来进行共识，从而提高方案的兼容能力。

在本申请一些可选的实施例中，基于上述的技术方案，在根据本地节点的区块链密钥，对建议事务数量进行签名，得到信息签名的过程中，节点会获取区块链中的当前区块高度以及第三区块提案的共识轮数；根据本地节点的区块链密钥，对建议事务数量、当前区块高度和共识轮数进行签名，得到信息签名。在生成节点投票结果时，节点会根据投票信息和投票签名以及建议事务数量、当前区块高度和共识轮数和信息签名，生成针对第三区块提案的节点投票结果。共识轮数(Consensus round number)是指在区块链的共识过程中，针对不同区块提案进行投票和达成共识的轮次编号，用于标识当前处于哪一轮共识，在生成节点投票结果时添加该信息，有助于节点判断投票结果的时效性，避免受到伪造发送的投票结果的影响。

请参阅图12，图12为本申请实施例中节点投票结果具体结构的示意图。如图12所示，在本实施例中，在节点投票结果还进一步添加了当前区块高度和共识轮数，主要用于防止投票结果的伪造发送。具体地，作恶节点可能会收集其他节点在之前轮次的投票结果，然后在下一轮共识时将之前轮次中其他节点的投票结果发出，而造成其他节点将其误认为是原节点在当前轮次发出的结果而造成事务数量的确认错误。而节点投票结果中的当前区块高度和共识轮数可以供节点判断投票结果是否是针对当前共识轮次发出，从而避免受到伪造发送的投票结果的影响，提高方案的安全性。

在本申请一些可选的实施例中，基于上述的技术方案，在根据执行结果和执行时长，确定本地节点的建议事务数量的过程中，节点根据第一提案事务数量、节点能力参数和执行时长，确定本地节点的候选建议数量，其中，节点能力参数是根据本地节点的历史事务执行结果确定的。如果执行结果与第三区块提案中的提案结果相匹配，则节点将候选建议数量和第一提案事务数量中更大的数量作为本地节点的建议事务数量。如果执行结果与第三区块提案中的提案结果不匹配，则节点将候选建议数量和第一提案事务数量中更小的数量作为本地节点的建议事务数量。

节点能力参数(Node capability parameter)是根据本地节点的历史事务执行结果确定的一个参数，用于确定本地节点的候选建议数量，并可根据其他区块链节点的建议事务数量进行更新。候选建议数量(Candidate suggested quantity)是本地节点根据第一提案事务数量、节点能力参数和执行时长确定的一个数量值，用于确定本地节点的建议事务数量。

在本实施例中，本地节点根据历史事务所确定的节点能力参数来确定候选建议数量。具体地，候选建议数量可以是(当前数量*X)/当前时间，其中X是节点能力参数。节点能力参数是根据本地节点的历史事务执行结果确定的，例如，根据历史事务执行与当前数量和其他节点提议的数量之间的差值确定。在确定本地节点的候选建议数量后，如果执行结果与第三区块提案中的提案结果相匹配，则选择候选建议数量和第一提案事务数量中更大的数量作为建议事务数量，反之，如果执行结果与第三区块提案中的提案结果不匹配，则选择二者中更小的作为建议事务数量。本实施例中，根据历史事务执行结果确定的节点能力参数来确定候选建议数量，再根据执行结果与提案结果的匹配情况来选择建议事务数量，相较于直接根据本地节点的计算能力来确定建议事务数量，能够使得所确定的建议事务数量与执行结果的匹配程度更高，有利于所确定的建议事务数量的准确性。

在本申请一些可选的实施例中，基于上述的技术方案，节点还会根据第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中其他区块链节点的建议事务数量，确定基线数量，然后根据基线数量、第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中本地节点的建议事务数量以及区块链中提案执行时间阈值，更新本地节点的节点能力参数。

基线数量(Baseline quantity)是根据第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中其他区块链节点的建议事务数量确定的一个数量值，用于更新本地节点的节点能力参数。提案执行时间阈值(Proposal execution time threshold)是区块链中预设的一个时间限制，用于限制区块提案中所有事务的总执行时长，若执行时长超过该阈值，可能会导致提案失败。

在本实施例中，区块链节点会根据其他节点所提出的建议事务数量，来调整本地节点的节点能力参数。具体地，本地节点会根据第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中其他区块链节点的建议事务数量，确定基线数量。例如，对于基于相同数量(例如10000)的事务，其他节点的建议事务数量都是5000，而本节点的建议事务数量是4000的话，则可以将5000作为基线数量。可以理解，基线处理可以是其他区块链节点的建议事务数量中出现次数最多的数量，但也可以根据其他方式确定，例如均值或者中位值等。随后，本地节点会根据基线数量调整自己的节点能力参数。例如，本地节点可以根据基线数量与建议事务数量之间的差值和提案执行时间阈值之间的比率来扩大当前的节点能力参数。具体地，在一个实施例中，节点能力参数可以＝4000*10*0.8/5000，其中，10为提案执行时间阈值，即10秒，而0.8则是预设的调整阈值。可以理解的是，更新本地节点的节点能力参数的过程通常在共识完成之后进行。在本实施例中，本地节点会根据其他节点的建议事务数量来更新本地节点的节点能力参数，从而能够对本地节点生成的建议事务数量进行及时调整，避免建议事务数量过高或者过低而影响区块中打包的事务数量，提高区块中事务数量的合理性。

下面结合具体实施例介绍本申请技术方案的具体实施流程。请参阅13，图13为本申请实施例中区块提案处理整体流程的示意性流程图。如图13所示，当前的共识节点会从事务池中获取要打包的事务，执行所获取的事务，从而生成本轮共识的区块提案。随后当前主节点将提案广播到区块链中的其他节点。其他节点主要分为普通节点和下一轮主节点，但这两种节点在当前轮次的共识过程中的处理过程相同。以普通节点为例，其会解析广播的网络信息，从而获取到广播的区块提案。网络信息(Network information)：在区块链网络中，节点之间进行通信时所传输的信息，包括区块提案、投票结果等数据，普通节点可以通过解析广播的网络信息来获取广播的区块提案等内容。

随后，节点对提案对象本身进行校验。如果校验不通过，则直接生成反对票。如果校验通过，则节点会执行提案中的所有事务，并记录事务完成数量。随后，根据总执行时长和完成事务数量生成事务建议数量。节点会校验事务执行结果与提案结果，如果校验通过，则生成赞成票，不通过则生成反对票。此时，这两种票都会附加建议事务数量。随后，节点将投票结果广播给区块链中的其他节点。区块链中的各个节点都会根据投票中的建议事务数量，计算下次打包事务时的最大数量。在本轮共识完成后，下一轮主节点会按照上一轮确定的数量，从事务池中获取要打包的事务，执行所获取的事务，从而生成下一轮共识的区块提案。

提案对象(Proposal object)：即区块提案，是主节点将区块链事务打包生成的对象，用于在区块链节点之间进行共识，普通节点会对提案对象本身进行校验，以判断其是否符合要求。

普通节点(Ordinary node)：在区块链的共识过程中，除主节点和下一轮主节点之外的节点，其在当前轮次的共识过程中，会接收主节点广播的区块提案，对提案进行校验和执行，根据执行结果生成投票结果并广播，同时根据总执行时长和完成事务数量生成事务建议数量。

事务完成数量(Number of completed transactions)：节点在执行区块提案中的区块链事务时，成功完成的事务的数量，节点会根据该数量和总执行时长生成事务建议数量。

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

以下介绍本申请的装置实施，可以用于执行本申请上述实施例中的区块提案方法。图14示意性地示出了本申请实施例中区块提案装置的组成框图。如图14所示，区块提案装置1400主要可以包括：

获取模块1410，配置成获取区块链中第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，每个投票结果包含建议事务数量，建议事务数量根据第一区块提案中的第一提案事务数量、及产生投票结果的区块链节点执行第一区块提案的执行时长确定；

生成模块1420，配置成根据多个投票结果各自包含的建议事务数量，生成第二共识轮次的事务数量限额，第二共识轮次是第一共识轮次的下一共识轮次；

打包模块1430，配置成按照事务数量限额，将本地事务池中的区块链事务打包，生成供区块链中第二共识轮次内多个区块链节点投票的第二区块提案；

广播模块1440，配置成在区块链中广播第二区块提案。

在本申请的一些实施例中，基于以上技术方案，生成模块1420具体配置成：根据第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，确定针对第一区块提案的提案共识结果；根据提案共识结果，从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中获取与提案共识结果相对应的投票结果，作为候选投票结果；根据候选投票结果中的建议事务数量，生成第二共识轮次的事务数量限额，第二共识轮次是第一共识轮次的下一共识轮次。

在本申请的一些实施例中，基于以上技术方案，生成模块1420具体配置成：若提案共识结果为提案成功，则从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中投赞成票的投票结果，作为候选投票结果；若提案共识结果为提案失败，则从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中投反对票的投票结果，作为候选投票结果。

在本申请的一些实施例中，基于以上技术方案，生成模块1420具体配置成：若提案共识结果为提案成功，则获取第一区块提案中的第一提案事务数量；若第一提案事务数量大于或等于候选投票结果中的建议事务数量，则将第一提案事务数量作为第二共识轮次的事务数量限额；若第一提案事务数量小于候选投票结果中的建议事务数量，则根据第一提案事务数量与所选择的建议事务数量的均值，生成第二共识轮次的事务数量限额。

在本申请的一些实施例中，基于以上技术方案，候选投票结果包含第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果；生成模块1420具体配置成：若第一提案事务数量小于候选投票结果中的建议事务数量，则获取区块链的区块事务数量阈值；若候选投票结果中任一投票结果的建议事务数量大于区块事务数量阈值，则将投票结果从候选投票结果中删除；根据第一提案事务数量与候选投票结果中各个投票结果的建议事务数量的均值，生成第二共识轮次的事务数量限额。

在本申请的一些实施例中，基于以上技术方案，生成模块1420具体配置成：若提案共识结果为提案失败，则获取候选投票结果中的建议事务数量；根据候选投票结果中建议事务数量的总和以及候选投票结果的数量，确定第二共识轮次的事务数量限额。

在本申请的一些实施例中，基于以上技术方案，广播模块1440还配置成：获取主节点生成的第三区块提案；执行第三区块提案中的区块链事务，得到第三区块提案的执行结果和执行时长；根据执行结果和执行时长，确定本地节点的建议事务数量；根据第三区块提案的执行结果和本地节点的建议事务数量，生成针对第三区块提案的节点投票结果；在区块链中广播节点投票结果。

在本申请的一些实施例中，基于以上技术方案，广播模块1440具体配置成：根据第三区块提案中区块链事务的执行结果和第三区块提案中的提案结果之间的匹配结果，确定针对第三区块提案的投票信息；根据本地节点的区块链密钥，对投票信息进行签名，得到投票签名；根据本地节点的区块链密钥，对建议事务数量进行签名，得到信息签名；根据投票信息和投票签名以及建议事务数量和信息签名，生成针对第三区块提案的节点投票结果。

在本申请的一些实施例中，基于以上技术方案，广播模块1440具体配置成：获取区块链中的当前区块高度以及第三区块提案的共识轮数；根据本地节点的区块链密钥，对建议事务数量、当前区块高度和共识轮数进行签名，得到信息签名；根据投票信息和投票签名以及建议事务数量、当前区块高度和共识轮数和信息签名，生成针对第三区块提案的节点投票结果。

在本申请的一些实施例中，基于以上技术方案，广播模块1440具体配置成：根据第一提案事务数量、节点能力参数和执行时长，确定本地节点的候选建议数量，其中，节点能力参数是根据本地节点的历史事务执行结果确定的；若执行结果与第三区块提案中的提案结果相匹配，则将候选建议数量和第一提案事务数量中更大的数量作为本地节点的建议事务数量；若执行结果与第三区块提案中的提案结果不匹配，则将候选建议数量和第一提案事务数量中更小的数量作为本地节点的建议事务数量。

在本申请的一些实施例中，基于以上技术方案，广播模块1440具体配置成：根据第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中其他区块链节点的建议事务数量，确定基线数量；根据基线数量、第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中本地节点的建议事务数量以及区块链中提案执行时间阈值，更新本地节点的节点能力参数。

需要说明的是，上述实施例所提供的装置与上述实施例所提供的方法属于同一构思，其中各个模块执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。

本申请提供的区块提案方法、装置、电子设备、计算机可读介质和计算机程序产品，区块链中的区块链节点获取区块链中第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，每个投票结果包含建议事务数量，该建议事务数量依据第一区块提案中的第一提案事务数量、及产生投票结果的区块链节点执行第一区块提案的执行时长确定。然后，根据多个投票结果各自包含的建议事务数量，生成第二共识轮次的事务数量限额，第二共识轮次是第一共识轮次的下一共识轮次。接着，按照事务数量限额，将本地事务池中的区块链事务打包，生成第二区块提案。最后，在区块链中广播第二区块提案，第二区块提案用于指示区块链中第二共识轮次内多个区块链节点进行投票。通过这种方式，能在共识过程中依据各节点建议调整下一次提案时打包的事务数量，自动对区块提案所包含事务进行调整，避免事务过多导致验证提案时执行超时，防止提案失败，提高区块链运行效率。

进一步地，区块链节点根据第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，确定针对第一区块提案的提案共识结果，再根据提案共识结果，从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中获取与提案共识结果相对应的投票结果，作为候选投票结果，进而根据候选投票结果中的建议事务数量，生成第二共识轮次的事务数量限额。这样做可使第二共识轮次事务数量限额的确定因素中，投票正确结果的影响程度更高，提高所确定事务数量限额的准确性。

当提案共识结果为提案成功时，区块链节点从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中投赞成票的投票结果，作为候选投票结果；当提案共识结果为提案失败时，从第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中投反对票的投票结果，作为候选投票结果。这能避免对共识节点判断错误的节点所提建议数量影响指定数量，降低确定事务数量过程受作恶数据影响的概率，提高区块链系统安全性。

若提案共识结果为提案成功，区块链节点获取第一区块提案中的第一提案事务数量，若第一提案事务数量大于或等于候选投票结果中的建议事务数量，则将第一提案事务数量作为第二共识轮次的事务数量限额。如此可在从节点认可主节点打包数量时，直接沿用第一提案事务数量作为下一轮事务数量限额。

若第一提案事务数量小于候选投票结果中的建议事务数量，区块链节点根据第一提案事务数量与所选择的建议事务数量的均值，生成第二共识轮次的事务数量限额。这能在主节点打包数量较少时，及时提高区块提案的事务数量限制，避免区块中事务数量过少导致共识过程处理资源浪费，提高方案资源利用率。

候选投票结果包含第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，若第一提案事务数量小于候选投票结果中的建议事务数量，区块链节点获取区块链的区块事务数量阈值，若候选投票结果中任一投票结果的建议事务数量大于区块事务数量阈值，则将该投票结果从候选投票结果中删除，再根据第一提案事务数量与候选投票结果中各个投票结果的建议事务数量的均值，生成第二共识轮次的事务数量限额。这样能避免区块提案中事务数量过多导致提案执行超时而引起共识失败，提高方案稳定性。

若提案共识结果为提案失败，区块链节点获取候选投票结果中的建议事务数量，根据候选投票结果中建议事务数量的总和以及候选投票结果的数量，确定第二共识轮次的事务数量限额。这可在提案失败时，通过只按失败的候选投票结果中的建议事务数量确定限额，及时缩减过高事务数量或过长执行时间，避免后续共识过程再次失败，提高共识成功率。

在区块链中广播第二区块提案之后，区块链节点获取主节点生成的第三区块提案，执行第三区块提案中的区块链事务，得到第三区块提案的执行结果和执行时长，根据执行结果和执行时长，确定本地节点的建议事务数量，根据第三区块提案的执行结果和本地节点的建议事务数量，生成针对第三区块提案的节点投票结果，在区块链中广播节点投票结果。通过在投赞成票时也增加建议事务数量，可及时修正过低事务数量，避免作恶节点造成区块链事务处理效率下降，提高方案安全性。

区块链节点根据第三区块提案中区块链事务的执行结果和第三区块提案中的提案结果之间的匹配结果，确定针对第三区块提案的投票信息，根据本地节点的区块链密钥，对投票信息进行签名，得到投票签名，根据本地节点的区块链密钥，对建议事务数量进行签名，得到信息签名，根据投票信息和投票签名以及建议事务数量和信息签名，生成针对第三区块提案的节点投票结果。在节点投票结果中分别对投票信息和建议事务数量进行签名，可使不具备提供建议事务数量能力的节点仍能基于投票信息和对应签名进行共识，提高方案兼容能力。

区块链节点获取区块链中的当前区块高度以及第三区块提案的共识轮数，根据本地节点的区块链密钥，对建议事务数量、当前区块高度和共识轮数进行签名，得到信息签名，根据投票信息和投票签名以及建议事务数量、当前区块高度和共识轮数和信息签名，生成针对第三区块提案的节点投票结果。在节点投票结果中添加当前区块高度和共识轮数，可防止投票结果被伪造发送，避免节点受伪造投票结果影响而造成事务数量确认错误，提高方案安全性。

区块链节点根据第一提案事务数量、节点能力参数和执行时长，确定本地节点的候选建议数量，其中，节点能力参数根据本地节点的历史事务执行结果确定，若执行结果与第三区块提案中的提案结果相匹配，则将候选建议数量和第一提案事务数量中更大的数量作为本地节点的建议事务数量。相较于直接根据本地节点计算能力确定建议事务数量，这样能使确定的建议事务数量与执行结果匹配程度更高，提高建议事务数量的准确性。

若执行结果与第三区块提案中的提案结果不匹配，区块链节点将候选建议数量和第一提案事务数量中更小的数量作为本地节点的建议事务数量。这进一步完善了根据执行结果确定建议事务数量的方式，使建议事务数量更贴合实际执行情况。

区块链节点根据第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中其他区块链节点的建议事务数量，确定基线数量，根据基线数量、第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中本地节点的建议事务数量以及区块链中提案执行时间阈值，更新本地节点的节点能力参数。通过根据其他节点建议事务数量更新本地节点的节点能力参数，可及时调整本地节点生成的建议事务数量，避免建议事务数量过高或过低影响区块中打包的事务数量，提高区块中事务数量的合理性。

需要说明的是，图15示出的电子设备的计算机系统1500仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图15所示，计算机系统1500包括中央处理单元(Central Processing Unit，CPU)1501，其可以根据存储在只读存储器(Read-Only Memory，ROM)1502中的程序或者从储存部分1508加载到随机访问存储器(Random Access Memory，RAM)1503中的程序而执行各种适当的动作和处理。在RAM 1503中，还存储有系统操作所需的各种程序和数据。CPU 1501、ROM 1502以及RAM 1503通过总线1504彼此相连。输入/输出(Input/Output，I/O)接口1505也连接至总线1504。

以下部件连接至I/O接口1505：包括键盘、鼠标等的输入部分1506；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1507；包括硬盘等的储存部分1508；以及包括诸如LAN(Local Area Network，局域网)卡、调制解调器等的网络接口卡的通信部分1509。通信部分1509经由诸如因特网的网络执行通信处理。驱动器1510也根据需要连接至I/O接口1505。可拆卸介质1511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1510上，以便于从其上读出的计算机程序根据需要被安装入储存部分1508。

特别地，根据本申请的实施例，各个方法流程图中所描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1509从网络上被下载和安装，和/或从可拆卸介质1511被安装。在该计算机程序被中央处理单元(CPU)1501执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

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

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims

一种区块提案方法，由区块链中的区块链节点执行，包括：

获取区块链中第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，每个投票结果包含建议事务数量，所述建议事务数量根据所述第一区块提案中的第一提案事务数量、及产生所述投票结果的区块链节点执行所述第一区块提案的执行时长确定；

根据所述多个投票结果各自包含的建议事务数量，生成第二共识轮次的事务数量限额，所述第二共识轮次是所述第一共识轮次的下一共识轮次；

按照所述事务数量限额，将本地事务池中的区块链事务打包，生成供所述区块链中第二共识轮次内多个区块链节点投票的第二区块提案；及

在所述区块链中广播所述第二区块提案。
根据权利要求1所述的区块提案方法，所述根据所述多个投票结果各自包含的建议事务数量，生成第二共识轮次的事务数量限额，包括：

根据所述第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，确定针对所述第一区块提案的提案共识结果；

根据所述提案共识结果，从所述第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中获取与所述提案共识结果相对应的投票结果，作为候选投票结果；

根据所述候选投票结果中的建议事务数量，生成第二共识轮次的事务数量限额。
根据权利要求2所述的区块提案方法，所述根据所述提案共识结果，从所述第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中获取与所述提案共识结果相对应的投票结果，作为候选投票结果，包括：

若所述提案共识结果为提案成功，则从所述第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中投赞成票的投票结果，作为候选投票结果；

若所述提案共识结果为提案失败，则从所述第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中投反对票的投票结果，作为候选投票结果。
根据权利要求2所述的区块提案方法，所述根据所述候选投票结果中的建议事务数量，生成第二共识轮次的事务数量限额，包括：

若所述提案共识结果为提案成功，则获取所述第一区块提案中的第一提案事务数量；

若所述第一提案事务数量大于或等于所述候选投票结果中的建议事务数量，则将所述第一提案事务数量作为第二共识轮次的事务数量限额。
根据权利要求4所述的区块提案方法，所述根据所述候选投票结果中的建议事务数量，生成第二共识轮次的事务数量限额还包括：

若所述第一提案事务数量小于所述候选投票结果中的建议事务数量，则根据所述第一提案事务数量与所选择的建议事务数量的均值，生成第二共识轮次的事务数量限额。
根据权利要求5所述的区块提案方法，所述候选投票结果包含第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果；所述若所述第一提案事务数量小于所述候选投票结果中的建议事务数量，则根据所述第一提案事务数量与所选择的建议事务数量的均值，生成第二共识轮次的事务数量限额，包括：

若所述第一提案事务数量小于所述候选投票结果中的建议事务数量，则获取所述区块链的区块事务数量阈值；

若所述候选投票结果中任一投票结果的建议事务数量大于所述区块事务数量阈值，则将所述投票结果从所述候选投票结果中删除；

根据所述第一提案事务数量与所述候选投票结果中各个投票结果的建议事务数量的均值，生成第二共识轮次的事务数量限额。
根据权利要求2至6任一项所述的区块提案方法，所述根据所述候选投票结果中的建议事务数量，生成第二共识轮次的事务数量限额，包括：

若所述提案共识结果为提案失败，则获取所述候选投票结果中的建议事务数量；

根据所述候选投票结果中建议事务数量的总和以及所述候选投票结果的数量，确定第二共识轮次的事务数量限额。
根据权利要求1至7任一项所述的区块提案方法，所述在所述区块链中广播所述第二区块提案之后，所述方法还包括：

获取主节点生成的第三区块提案；

执行所述第三区块提案中的区块链事务，得到所述第三区块提案的执行结果和执行时长；

根据所述执行结果和所述执行时长，确定本地节点的建议事务数量；

根据所述第三区块提案的执行结果和所述本地节点的建议事务数量，生成针对所述第三区块提案的节点投票结果；

在所述区块链中广播所述节点投票结果。
根据权利要求8所述的区块提案方法，所述根据所述第三区块提案的执行结果和所述本地节点的建议事务数量，生成针对所述第三区块提案的节点投票结果，包括，

根据所述第三区块提案中区块链事务的执行结果和所述第三区块提案中的提案结果之间的匹配结果，确定针对所述第三区块提案的投票信息；

根据本地节点的区块链密钥，对所述投票信息进行签名，得到投票签名；

根据本地节点的区块链密钥，对所述建议事务数量进行签名，得到信息签名；

根据所述投票信息和所述投票签名以及所述建议事务数量和所述信息签名，生成针对所述第三区块提案的节点投票结果。
根据权利要求9所述的区块提案方法，所述根据本地节点的区块链密钥，对所述建议事务数量进行签名，得到信息签名，包括：

获取所述区块链中的当前区块高度以及所述第三区块提案的共识轮数；

根据本地节点的区块链密钥，对所述建议事务数量、所述当前区块高度和所述共识轮数进行签名，得到信息签名；

所述根据所述投票信息和所述投票签名以及所述建议事务数量和所述信息签名，生成针对所述第三区块提案的节点投票结果，包括：

根据所述投票信息和所述投票签名以及所述建议事务数量、所述当前区块高度和所述共识轮数和所述信息签名，生成针对所述第三区块提案的节点投票结果。
根据权利要求8至10任一项所述的区块提案方法，所述根据所述执行结果和所述执行时长，确定本地节点的建议事务数量，包括：

根据所述第一提案事务数量、节点能力参数和所述执行时长，确定所述本地节点的候选建议数量，其中，所述节点能力参数是根据所述本地节点的历史事务执行结果确定的；

若所述执行结果与所述第三区块提案中的提案结果相匹配，则将所述候选建议数量和所述第一提案事务数量中更大的数量作为本地节点的建议事务数量。
根据权利要求11所述的区块提案方法，所述根据所述执行结果和所述执行时长，确定本地节点的建议事务数量还包括：

若所述执行结果与所述第三区块提案中的提案结果不匹配，则将所述候选建议数量和所述第一提案事务数量中更小的数量作为本地节点的建议事务数量。
根据权利要求11或12所述的区块提案方法，所述方法还包括：

根据所述第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中其他区块链节点的建议事务数量，确定基线数量；

根据所述基线数量、所述第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果中本地节点的建议事务数量以及所述区块链中提案执行时间阈值，更新所述本地节点的节点能力参数。
一种区块提案装置，包括：

获取模块，配置成获取区块链中第一共识轮次内多个区块链节点针对第一区块提案产生的多个投票结果，每个投票结果包含建议事务数量，所述建议事务数量根据所述第一区块提案中的第一提案事务数量、及产生所述投票结果的区块链节点执行所述第一区块提案的执行时长确定；

生成模块，配置成根据所述多个投票结果各自包含的建议事务数量，生成第二共识轮次的事务数量限额，所述第二共识轮次是所述第一共识轮次的下一共识轮次；

打包模块，配置成按照所述事务数量限额，将本地事务池中的区块链事务打包，生成供所述区块链中第二共识轮次内多个区块链节点投票的第二区块提案；及

广播模块，配置成在所述区块链中广播所述第二区块提案。
一种电子设备，包括：

处理器；

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1至13中任一项所述的区块提案方法。
一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至13中任一项所述的区块提案方法。
一种计算机程序产品，计算机程序产品包括计算机程序，计算机程序存储在计算机可读存储介质中，电子设备的处理器从计算机可读存储介质读取并执行计算机程序，使得电子设备执行如权利要求1至13中任一项的区块提案方法。