Block proposal method and apparatus, electronic device, and readable medium

Abstract

A block proposal method, executed by a blockchain node in a blockchain, and comprising: acquiring multiple voting results generated by multiple blockchain nodes for a first block proposal within a first consensus round in a blockchain, each voting result comprising the number of proposed transactions, and the number of proposed transactions being determined on the basis of the number of first proposal transactions in the first block proposal and the execution durations of the first block proposal by the blockchain nodes generating the voting results (S510); on the basis of the number of proposed transactions comprised in each of the multiple voting results, generating a transaction quantity limit for a second consensus round, the second consensus round being a consensus round following the first consensus round (S520); on the basis of the transaction quantity limit, packaging blockchain transactions in a local transaction pool to generate a second block proposal for voting by multiple blockchain nodes within the second consensus round in the blockchain (S530); and broadcasting the second block proposal in the blockchain (S540).

Description

Block proposal method and device, electronic equipment and readable medium

[0001] Related application

[0002] The present application claims priority to the Chinese patent application No. 202410418430.9, filed on April 8, 2024, and entitled "Block proposal method and device, electronic equipment and readable medium", the contents of which are hereby incorporated by reference in its entirety. TECHNICAL FIELD

[0003] The present application relates to the field of computer technology, in particular to the field of blockchain technology, and more particularly to a block proposal method and device, electronic equipment and readable medium. BACKGROUND

[0004] With the development of blockchain technology, more and more business systems begin to use blockchain. In the blockchain, the blockchain nodes will package multiple blockchain transactions into a proposal to reach consensus among the blockchain nodes, and only after the consensus is reached, a block will be generated in the blockchain.

[0005] In the related art, the blockchain nodes will package the blockchain according to the preset upper limit of the block transaction quantity and the upper limit of the block execution time to make a proposal.

[0006] However, in such technology, the proposal process will try to package as many transactions as possible according to the upper limit of the block execution time, so that the execution time of the proposal block tends to approach the upper limit of the execution time, which may cause the execution time of other nodes to exceed the upper limit of the block execution time when verifying the proposal, thereby opposing the consensus and causing the proposal to fail, affecting the operation efficiency of the blockchain. SUMMARY

[0007] The present application provides a block proposal method and device, electronic equipment and readable medium.

[0008] According to an aspect of an embodiment of the present application, a block proposal method is provided, which is executed by a blockchain node in a blockchain, comprising:

[0009] Obtaining a plurality of voting results generated by a plurality of blockchain nodes in the blockchain for a first block proposal in a first consensus round, each voting result containing a recommended transaction quantity, which is determined according to a first proposal transaction quantity in the first block proposal and an execution time of the first block proposal executed by the blockchain node generating the voting result;

[0010] Generating a transaction quantity limit for a second consensus round according to the recommended transaction quantity contained in each of the plurality of voting results, the second consensus round being the next consensus round of the first consensus round;

[0011] packaging the blockchain transactions in a local transaction pool according to the transaction quantity limit to generate a second block proposal for voting by the plurality of blockchain nodes in a second consensus round in the blockchain; and

[0012] broadcasting the second block proposal in the blockchain.

[0013] According to an aspect of an embodiment of the present application, a block proposal device is provided, comprising:

[0014] a obtaining module configured to obtain a plurality of voting results generated by a plurality of blockchain nodes in a first consensus round in a blockchain for a first block proposal, each voting result containing a recommended transaction quantity, the recommended transaction quantity being determined according to a first proposal transaction quantity in the first block proposal and an execution duration of the first block proposal executed by the blockchain node generating the voting result;

[0015] a generating module configured to generate a transaction quantity limit for a second consensus round according to the recommended transaction quantities contained in the plurality of voting results, the second consensus round being a next consensus round of the first consensus round;

[0016] a packaging module configured to package blockchain transactions in a local transaction pool according to the transaction quantity limit to generate a second block proposal for voting by the plurality of blockchain nodes in a second consensus round in the blockchain; and

[0017] a broadcasting module configured to broadcast the second block proposal in the blockchain.

[0018] According to an aspect of an embodiment of the present application, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the block proposal method as in the above technical solutions via execution of the executable instructions.

[0019] According to an aspect of an embodiment of the present application, a computer readable storage medium having a computer program stored thereon is provided, when the computer program is executed by a processor, the block proposal method as in the above technical solutions is implemented.

[0020] According to an aspect of an embodiment of the present application, a computer program product or computer program is provided, the computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the electronic device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the block proposal method provided in the various optional implementation manners described above.

[0021] The details of one or more embodiments of the application are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the application will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF DRAWINGS

[0022] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and serve to explain the principles of the application. It is readily apparent to one skilled in the art that the following description in the drawings only illustrate some embodiments of the application, and other drawings can be obtained by one of ordinary skill in the art without any creative effort based on these drawings.

[0023] FIG. 1 is an exemplary system architecture diagram of an application scenario of the technical solution of the present application.

[0024] FIG. 2 is a schematic diagram of the overall situation of a block proposal in an embodiment of the present application.

[0025] FIG. 3 is a schematic diagram of a blockchain network in an embodiment of the present application.

[0026] FIG. 4 is a schematic diagram of a block in a blockchain network in an embodiment of the present application.

[0027] FIG. 5 shows a flowchart of a block proposal method according to an embodiment of the present application.

[0028] FIG. 6 shows a flowchart of a block proposal method according to an embodiment of the present application.

[0029] FIG. 7 is a logic diagram for generating a transaction quantity limit for a second consensus round in an embodiment of the present application.

[0030] FIG. 8 is another logic diagram for generating a transaction quantity limit for a second consensus round in an embodiment of the present application.

[0031] FIG. 9 is another logic diagram for generating a transaction quantity limit for a second consensus round in an embodiment of the present application.

[0032] FIG. 10 shows a flowchart of a block proposal method according to an embodiment of the present application.

[0033] FIG. 11 is a schematic diagram of a node voting result in an embodiment of the present application.

[0034] FIG. 12 is a schematic diagram of a specific structure of a node voting result in an embodiment of the present application.

[0035] FIG. 13 is a schematic flowchart of the overall process of a block proposal in an embodiment of the present application.

[0036] FIG. 14 schematically shows a block diagram of the composition of a block proposal device in an embodiment of the present application.

[0037] FIG. 15 shows a structural schematic diagram of a computer system of an electronic device suitable for implementing the embodiments of the present application. DETAILED DESCRIPTION

[0038] The technical solutions in the embodiments of the present application will be clearly and completely described in combination with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0039] In addition, the described features, structures or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a sufficient understanding of the embodiments of the present application. However, those skilled in the art will realize that the technical solutions of the present application can be practiced without one or more of the specific details, or can employ other methods, components, devices, steps, etc. In other cases, well-known methods, devices, implementations or operations are not shown or described in detail to avoid obscuring the aspects of the present application.

[0040] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined target, and can be implemented entirely or partially by using software, hardware (such as a processing circuit or a memory) or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an integral module or unit that includes the functions of the module or unit.

[0041] The block diagrams shown in the accompanying drawings are only functional entities, and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0042] The flowcharts shown in the accompanying drawings are only exemplary illustrations, and do not necessarily include all contents and operations / steps, nor do they necessarily have to be executed in the described order. For example, some operations / steps can be further divided, and some operations / steps can be combined or partially combined, so the actual execution order can be changed according to the actual situation.

[0043] It should be understood that the scheme of the present application is applied in the process of proposal by the consensus nodes of the blockchain, and is particularly applied in the scene of packaging the blockchain transactions into a proposal. The blockchain system is actually a distributed system, but it is different from ordinary distributed systems. In the blockchain system, each consensus node will reach a consensus on the block that it agrees to, and only after the consensus is reached, it will be recognized by the entire blockchain system, that is, the blockchain consensus. A block often contains many transactions. Generally speaking, within the allowed range, the larger the transaction volume, the better, because in addition to storing transactions, a block also stores block headers, node voting and other information, and the size of the block header and node voting is basically fixed. Therefore, the more transactions stored in the block, the more space saved. This allowed range generally includes two parts, the maximum number of blockchain transactions and the maximum execution time of transactions in the entire block.

[0044] The block header is part of each block in the blockchain, which contains input information characteristic values, version numbers, timestamps, difficulty values, and parent block header characteristic values, etc. information, used to ensure that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, and to ensure the security of the input information in the block.

[0045] The blockchain transaction is an operation unit for a series of interactive activities such as data transmission, processing, and verification between blockchain nodes in the blockchain system. The blockchain nodes will package multiple such transactions into a proposal, reach a consensus among the blockchain nodes, and generate a block containing the transaction information in the blockchain after the consensus. This operation has a number limit and an execution time limit, and in the consensus process of the blockchain, the blockchain nodes will make recommendations on the number of transactions to be included in the next round of consensus proposal based on the execution of the transactions in the proposal, so as to dynamically adjust the number of transactions in each block and improve the efficiency of the blockchain.

[0046] Maximum quantity: a number limit calculated based on the recommended number of transactions in each node vote when determining the next packaged transaction. The next master node will obtain the transaction to be packaged from the transaction pool according to the number limit.

[0047] If the number of transactions in a blockchain is very large and not controlled, because transactions need to be executed, it will cause the node computing resources to be too large, and the performance of the entire blockchain will be affected. Similarly, if the execution time of a block is not controlled, it will also cause the entire blockchain to be unable to reach a consensus for a long time, thereby affecting the performance of the blockchain.

[0048] So the current industry solution is to set an upper limit for these two parameters. The upper limit of the number of transactions is generally set according to the number of transactions per second and business needs, while the time is often fixed, for example, 10 seconds. Transaction volume: refers to the number of transactions (or transactions) in a unit of time in a blockchain system, which is usually used to measure the processing capacity and business of the blockchain system. The upper limit of the number of transactions is generally set according to the number of transactions per second and business needs.

[0049] From the time point of view, there is a certain risk. In order to achieve higher performance, the proposer will try to pack more transactions into the proposal. The execution time is longer, but it will be less than 10 seconds (for example, 9.8 seconds). However, the follower is different. It will also execute all transactions in this block. If the execution time exceeds 10 seconds due to server performance and resource occupation, the follower will think that the proposal of the proposer is wrong and vote against it, which may lead to the failure of the consensus in this round and the need to re-perform the consensus, affecting the overall performance of the blockchain.

[0050] Based on this, the technical scheme of the embodiment of the application proposes a block proposal scheme. Specifically, as shown in FIG. 1, the system architecture applied to the block proposal scheme according to the embodiment of the application can include a blockchain network composed of four blockchain nodes. The electronic device implementing the blockchain node can include a smart phone, a tablet computer, a notebook computer, a smart voice interaction device, a smart home appliance, a vehicle-mounted terminal, an aircraft, and the like. The electronic device implementing the blockchain node can also be a server providing various services, which can be a standalone physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and basic cloud computing services such as big data and artificial intelligence platforms. There can be various connection types of communication media between the blockchain nodes, such as wired communication links or wireless communication links.

[0051] According to the implementation needs, the system architecture in the embodiment of the application can have any number of terminal devices and servers. For example, the electronic device implementing the blockchain node can be a server group composed of multiple server devices. In addition, the technical scheme provided by the embodiment of the application can be applied to any blockchain node, or can be implemented by multiple blockchain nodes, which is not specially limited by the application.

[0052] As shown in FIG. 1, one of the blockchain nodes acts as a proposer 110 in the blockchain. It can be understood that the proposer can be any consensus node of the blockchain, and the consensus nodes in the blockchain usually take turns to be the proposer to make a proposal according to a predetermined rule, and the other consensus nodes except the proposer are slave nodes, the slave nodes vote according to the proposal of the proposer to reach a consensus, and the proposer confirms the consensus and notifies each slave node to chain the new block. In an embodiment of the present application, the proposer 110 in the blockchain sends a block proposal to the slave nodes 120. When the slave nodes send a vote on the block proposal to the proposer 110, the slave nodes 120 also provide a recommended number of the number of transactions to be packaged in the next round of proposal. All slave nodes 120 vote and provide a recommended number. The proposer 110 determines the number of transactions to be packaged in the next round according to the recommendations provided by the slave nodes 120. And in the next round of proposal, the number of transactions to be packaged is determined according to the number of transactions to be packaged in the next round.

[0053] Referring to FIG. 2, FIG. 2 is a schematic diagram of the overall situation of the block proposal in the embodiment of the present application. As shown in FIG. 2, the master node will package a transaction (10000 transactions) and execute it to form a block proposal. It is assumed that the time for the master node to execute all the transactions in the block proposal is 9.8 seconds. The block proposal will be broadcast to the slave nodes in the block chain. Node 2, node 3 and node 4 will verify the received proposal. Each node will execute all the transactions in the received block proposal and determine the voting content based on the execution result, for example, vote for or against the block according to the success or failure of the execution of all the transactions, and at the same time, the node will also count the execution time of all the transactions in the proposal and the timeout condition of the execution. It is assumed that the total execution time of a slave node is 10.2 seconds, so the voting content of the node will be an opposing vote due to the transaction timeout. The node will also generate a recommended transaction quantity according to the execution time and the number of transactions contained in the proposal. For example, due to the execution timeout, the slave node will recommend that the transaction quantity be set to 5000 transactions. The slave node will attach the recommended transaction quantity in the voting information of the proposal. The voting information of the slave node will be broadcast to other nodes. All the nodes in the block chain will collect the voting information of other nodes about the proposal and determine whether to agree to the block on-chain in the second round of voting according to the collected voting information. In the second round of voting, if most of the nodes do not agree to the block on-chain, the nodes will also vote against the submission of the block. Subsequently, the nodes will collect the voting information of other nodes for the second round of voting to finally determine whether to submit the block, and also determine the new proposal transaction quantity limit according to the recommended transaction quantity of each slave node. In the next round of consensus, the node that becomes the master node will package the transactions according to the proposal transaction quantity limit determined by it to make a proposal, for example, most of the nodes recommend that the transaction quantity be set to 5000 transactions, so in the next round of proposal, the master node will package 5000 transactions into a proposal to make the proposal process. It can be understood that most of the blocks still timeout when executing the proposal of 5000 transactions, so through the above voting and re-determination of the transaction quantity process, the number of transactions in the proposal will be further reduced, and if most of the nodes have more processing capacity idle when executing 5000 transactions, the number of transactions can be increased through the above process.

[0054] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. Blockchain is essentially a decentralized database, which is a chain of data blocks (i.e., blocks) associated using cryptographic methods, each of which contains information about a batch of network transactions, for verifying the validity of the information (anti-fake) and generating the next block. The blockchain is maintained by the nodes in the blockchain network. For example, as shown in FIG. 3, the blockchain network can include a plurality of nodes 301, which can be various clients forming the blockchain network. Each node 301 can receive input information when performing normal work and maintain shared data in the blockchain network based on the received input information. To ensure information interconnection in the blockchain network, each node in the blockchain network can have an information connection between nodes, and the nodes can transmit information through the information connection. For example, when any node in the blockchain network receives input information, other nodes in the blockchain network obtain the input information according to a consensus algorithm, store the input information as shared data, so that the data stored on all nodes in the blockchain network is consistent. The consensus algorithm refers to an algorithm for reaching a consensus on a block proposal among multiple nodes in the blockchain network. Through the algorithm, the nodes can obtain input information and store it as shared data, so that the data stored on all nodes in the blockchain network is consistent.

[0055] Each node in the blockchain network has a corresponding node identifier, and each node in the blockchain network can store the node identifiers of other nodes, so as to subsequently broadcast the generated blocks to other nodes in the blockchain network according to the node identifiers of the other nodes. Each node can maintain a node identifier list, and store the node name and node identifier in the node identifier list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node.

[0056] Node identification list: a list maintained by each node in the blockchain network, for storing the node name and node identifier. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node, so that the node can subsequently broadcast the generated blocks to other nodes in the blockchain network according to the node identifiers of the other nodes.

[0057] Each node in the blockchain network stores a same blockchain. The blockchain is composed of multiple blocks, as shown in FIG. 4. The blockchain is composed of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information characteristic values, a version number, a timestamp, and a difficulty value. The block body stores input information. The next block of the genesis block takes the genesis block as a parent block. The next block also includes a block header and a block body. The block header stores input information characteristic values of the current block, a block header characteristic value of the parent block, a version number, a timestamp, and a difficulty value. This is iterated, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0058] The genesis block is the first block in the blockchain. The genesis block includes a block header and a block body. The block header stores input information characteristic values, a version number, a timestamp, and a difficulty value. The block body stores input information. The genesis block is the basis for subsequent blocks, which are generated in sequence with the genesis block as a parent block.

[0059] Parent block: In the blockchain, each block has a previous block, which is the parent block of the current block. The block header of each block stores a block header characteristic value of the parent block. The block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0060] The blockchain data obtained by the master node 110 and the slave node 120 can be in the block structure shown in FIG. 4. It can be understood that although three blocks are shown, the master node 110 and the slave node 120 can obtain more or fewer blocks at a time, or all blocks in the blockchain at a time.

[0061] In an embodiment of the present application, the information related to the number of proposed transactions can be saved in the block body of the blockchain structure shown in FIG. 4 in the form of a blockchain transaction, and consensus between nodes and chaining in the blockchain with the block.

[0062] FIG. 5 shows a flowchart of a block proposal method according to an embodiment of the present application. The block proposal method can be executed by a device with computing processing function, such as a computing device of a blockchain node. Referring to FIG. 5, the block proposal method includes at least steps S510 to S540, which are described in detail as follows.

[0063] Step S510, obtaining a plurality of voting results generated by a plurality of blockchain nodes in the first consensus round for the first block proposal, each voting result containing a suggested transaction quantity determined according to a first proposed transaction quantity in the first block proposal and an execution duration of the first block proposal by the blockchain node generating the voting result.

[0064] The first consensus round is a round in which voting and consensus are performed for the first block proposal in the consensus process of the blockchain. When step S510 is performed, the first consensus round is the current consensus round.

[0065] The second consensus round is the next consensus round of the first consensus round, in which the master node packs blockchain transactions according to the transaction quantity limit determined in the previous round to make a proposal.

[0066] The first block proposal is a block proposal generated by the master node in the current consensus round (the first consensus round) for the blockchain transactions, which is used for consensus among the blockchain nodes.

[0067] In the blockchain scenario, a transaction is an operation unit for a series of interactive activities such as data transmission, processing, and verification among the blockchain nodes. The blockchain nodes pack a plurality of such transactions into a proposal, and the proposal is subjected to consensus among the blockchain nodes. After the consensus, a block containing the information of the transactions is generated in the blockchain.

[0068] The suggested transaction quantity is a quantity value determined according to the first proposed transaction quantity in the first block proposal and the execution duration of the first block proposal by the blockchain node generating the voting result. The quantity value represents a suggestion of the voting node for the transaction quantity to be included in the next round of consensus proposal according to the execution of the first block proposal.

[0069] The first proposed transaction quantity is the transaction quantity used when the first block proposal is packed.

[0070] The current blockchain node (i.e., the blockchain node currently executing the block proposal method) is a follower in the first consensus round, which receives a plurality of voting results generated by a plurality of blockchain nodes in the first consensus round for the first block proposal from each node in the blockchain. The first block proposal is a block packaged by the master node in the current consensus round. It can be understood that the number of transactions used in the first block proposal packaging can also be determined according to the scheme of the present application. The voting result is determined by each node in the blockchain based on the verification and execution result of the first block proposal, which includes the voting content of the node for the first block proposal, usually approval or opposition, and the recommended transaction quantity. The recommended transaction quantity is determined according to the first proposal transaction quantity in the first block proposal and the execution time of the first block proposal by the blockchain node generating the voting result, which represents the recommendation of the voting node for the transaction quantity to be included in the next consensus proposal based on its execution of the first block proposal. It can be understood that if the voting node finds that the execution of the first block proposal is timed out, the recommended transaction quantity determined will be less than the first proposal transaction quantity, and if the voting node finds that the execution time is far away from the preset maximum time after executing the first block proposal, it will recommend a larger recommended transaction quantity than the first proposal transaction quantity. It should be emphasized that the plurality of voting results generated by a plurality of blockchain nodes in the first consensus round for the first block proposal obtained by the local node do not necessarily come from all nodes in the blockchain, but as long as the number of votes obtained meets the condition for determining the consensus result in the consensus strategy of the blockchain. That is, if the consensus condition requires half of the nodes to agree to reach consensus, the local node can determine the consensus result and execute the scheme of the present application as long as it obtains half of the votes or the opposite votes. In the present application, a plurality can be at least two.

[0071] In step S520, the transaction quantity limit of the second consensus round is generated according to the recommended transaction quantity contained in each of the plurality of voting results, and the second consensus round is the next consensus round of the first consensus round.

[0072] The transaction quantity limit (Transaction quantity limit) refers to the limitation value of the number of transactions used by the master node when making a proposal in a certain consensus round, which is generated from the recommended transaction quantity in the voting result generated by a plurality of blockchain nodes for the last block proposal in the last consensus round.

[0073] The local node generates a transaction quantity limit of the second consensus round according to the number of recommended transactions in the plurality of voting results generated by the plurality of blockchain nodes for the first block proposal in the first consensus round, the second consensus round being a next consensus round of the first consensus round. The transaction quantity limit of the second consensus round is used as a transaction quantity limit when the primary node makes a proposal in the next round of consensus. When determining the transaction quantity limit of the second consensus round, a part of the number of recommended transactions can be selected from the plurality of voting results generated by the plurality of blockchain nodes for the first block proposal in the first consensus round according to a preset generation strategy, for example, more recommended transaction quantities than the first proposal transaction quantity are selected when the execution duration is shorter than the preset duration, and fewer recommended transaction quantities than the first proposal transaction quantity are selected when the execution duration exceeds the preset duration. Then, the transaction quantity limit of the second consensus round is determined based on the selected recommended transaction quantity, for example, the mean, maximum, median, or one of them is selected as the result.

[0074] In step S530, the blockchain transactions in the local transaction pool are packaged according to the transaction quantity limit to generate a second block proposal for voting by the plurality of blockchain nodes in the second consensus round of the blockchain.

[0075] The local transaction pool (Local transaction pool) is a collection of blockchain transactions stored locally by the blockchain node, and the primary node obtains transactions from the pool to package and generate a block proposal.

[0076] In this embodiment, the local node becomes the primary node in the next round of consensus. After the local node becomes the primary node, it determines whether to package the transactions according to the first block proposal and package them on the chain according to the voting results of the last round. However, whether the first block proposal is consensus or not. When the primary node needs to make a proposal in the next round of consensus, it will use the transaction quantity limit of the second consensus round determined in the last round of consensus as the transaction quantity limit when making a proposal. That is, the local node will package the blockchain transactions in the local transaction pool with the transaction quantity limit to generate a second block proposal for voting by the plurality of blockchain nodes in the second consensus round of the blockchain; and broadcast the second block proposal in the blockchain. Depending on whether the first block proposal consensus is successful or not, the specific transactions included in the second block proposal can be the same as or different from the first block proposal. Specifically, the local node will execute the transactions to be packaged and count the execution duration when packaging the second block proposal. The local node will ensure that the number of transactions in the second block proposal is less than or equal to the transaction quantity limit, and the total execution duration of all transactions in the second block proposal does not exceed the preset execution duration threshold in the blockchain.

[0077] Total execution time: the total time spent by the blockchain node in executing all the blockchain transactions in the block proposal, the node generates the suggested quantity of transactions according to the total execution time and the number of completed transactions. The suggested quantity of transactions has the same meaning as the suggested number of transactions, which is a number value generated by the node according to the total execution time and the number of completed transactions in executing all the transactions in the block proposal. The number value represents the suggestion of the node on the number of transactions to be included in the next round of consensus proposal according to the execution of the block proposal, which will be attached in the voting result.

[0078] Step S540, broadcast the second block proposal in the blockchain.

[0079] The second block proposal is a block proposal generated by the master node in the next round of consensus (the second consensus round) according to the transaction quantity limit of the second consensus round, which is used to indicate the voting of multiple blockchain nodes in the second consensus round in the blockchain.

[0080] After the packaging is completed, the local node as the master node of the current consensus round (the last consensus round after the completion of the first block proposal) will broadcast the second block proposal in the blockchain. The slave nodes in the blockchain will perform the consensus process according to the second block proposal, and generate the block submitted by the second block proposal in the blockchain after the consensus is reached. It can be understood that in the consensus process of the second block proposal, each slave node will also make a suggestion on the number of transactions based on the number of transactions and the execution time of the second block proposal, so as to continue to adjust the number of transactions packaged in the block proposal of the next round of consensus. Therefore, the transaction quantity limit in the block proposal will be dynamically adjusted according to the suggested number of transactions proposed by each slave node in the consensus process. This can solve the problem of too many transactions causing timeout or too few transactions causing resource waste in the running process without manual intervention and configuration, so that the running efficiency of the blockchain is higher.

[0081] In the embodiments of the present application, after obtaining the multiple voting results generated by the multiple blockchain nodes for the first block proposal in the first consensus round for the first block proposal, the blockchain node generates a transaction quantity limit for the second consensus round according to the number of proposed transactions in each voting result, the second consensus round is the next consensus round of the first consensus round, and when becoming a proposal node, the blockchain transaction is packaged into a new block proposal according to the determined transaction quantity limit of the second consensus round, and is broadcast in the blockchain, so as to generate a new block in the blockchain. In this way, the number of transactions packaged in the next proposal is adjusted according to the proposals of each node in the consensus process, so that the transactions contained in the block proposal can be automatically adjusted during the execution result and execution time of the proposal, avoiding too many transactions in the block proposal causing execution timeout during the verification of the proposal, thereby preventing the failure of the proposal caused by the verification of the proposal execution timeout, and improving the operation efficiency of the blockchain.

[0082] In the embodiments of the present application, other embodiments are proposed to refine the technical solutions of the embodiment shown in Figure 5, as shown in Figure 6, in the block proposal method of an embodiment of the present application, the following steps can be included:

[0083] Step S610, obtaining multiple voting results generated by the multiple blockchain nodes for the first block proposal in the first consensus round in the blockchain, each voting result containing a proposed transaction quantity, the proposed transaction quantity being determined according to the first proposal transaction quantity in the first block proposal and the execution time of the first block proposal by the blockchain node generating the voting result.

[0084] Optionally, the implementation details of step S610 are consistent with step S510 shown in Figure 5, and will not be described again.

[0085] Step S620, determining a proposal consensus result for the first block proposal according to the multiple voting results generated by the multiple blockchain nodes for the first block proposal in the first consensus round;

[0086] The proposal consensus result (Proposal consensus result) refers to the result of whether the first block proposal reaches consensus after judging the multiple voting results generated by the multiple blockchain nodes for the first block proposal in the first consensus round according to the consensus strategy of the blockchain, which is usually divided into proposal success and proposal failure.

[0087] Step S630, according to the proposal consensus result, obtaining the voting result corresponding to the proposal consensus result from the multiple voting results generated by the multiple blockchain nodes for the first block proposal in the first consensus round as a candidate voting result;

[0088] The candidate voting result refers to a voting result corresponding to the proposal consensus result obtained from a plurality of voting results generated by a plurality of blockchain nodes for the first block proposal in the first consensus round according to the proposal consensus result, and is used to generate the transaction quantity limit of the second consensus round.

[0089] In step S640, the transaction quantity limit of the second consensus round is generated according to the number of recommended transactions in the candidate voting result, and the second consensus round is the next consensus round of the first consensus round.

[0090] In this embodiment, when generating the transaction quantity limit of the second consensus round, the local node will obtain the voting result corresponding to the proposal consensus result from a plurality of voting results generated by a plurality of blockchain nodes for the first block proposal in the first consensus round according to the proposal consensus result. Specifically, the local node will first determine the proposal consensus result for the first block proposal according to a plurality of voting results generated by a plurality of blockchain nodes for the first block proposal in the first consensus round. The determination process is usually determined according to the consensus strategy of the blockchain.

[0091] For example, in a 3f+1 consensus network, for each round of voting, each node only needs to collect 2f+1 voting results to determine that the consensus is successful, or collect f+1 voting results to determine that the consensus fails, but the voting results collected by each node may be different. Consensus network: a network composed of a plurality of blockchain nodes, and the nodes vote and reach consensus for block proposals in the network. Different consensus networks have different consensus strategies, for example, in a 3f+1 consensus network, for each round of voting, each node only needs to collect 2f+1 voting results to determine that the consensus is successful, or collect f+1 voting results to determine that the consensus fails.

[0092] After determining the proposal consensus result, the local node obtains a voting result corresponding to the proposal consensus result from the multiple voting results generated by the multiple blockchain nodes in the first consensus round for the first block proposal as a candidate voting result. Specifically, the multiple voting results generated by the multiple blockchain nodes in the first consensus round for the first block proposal have different influence degrees and effects on the proposal consensus result, and the local node selects the voting results based on the influence degrees, correlation degrees and effects of the voting results on the proposal consensus result. Generally, the local node selects the voting results that have positive effects on the proposal consensus result as the candidate voting results. The effects of the voting results are generally divided into positive effects, negative effects and no effects, the positive effects indicate that the voting results are consistent with the direction of the consensus result, the negative effects indicate that the voting results are opposite to the direction of the consensus result, and the no effects indicate that the voting results have no correlation with the consensus result. For the case where the consensus result is failure, the opposing votes are positive effects, the supporting votes are negative effects, and the abstention votes are no effects. For example, the consensus result is failure, but the failure reason is that a certain consensus node starts a veto mechanism, and the veto vote has the greatest influence and effect on the consensus result, so the voting result is obtained as the candidate voting result. In some embodiments, the local node selects a part of the voting results with positive effects and a part of the voting results with negative effects as the candidate voting results according to a preset proportion. Finally, the local node generates the transaction quantity limit of the second consensus round according to the number of proposed transactions in the candidate voting result, and the second consensus round is the next consensus round of the first consensus round. By generating the transaction quantity limit of the second consensus round according to the number of proposed transactions in the voting result corresponding to the proposal consensus result, the second consensus round is the next consensus round of the first consensus round, so that the influence degree of the correct voting result in the determining factors of the transaction quantity limit of the second consensus round is higher, which is beneficial to improve the accuracy of the determined transaction quantity limit of the second consensus round.

[0093] In step S650, the blockchain transactions in the local transaction pool are packaged according to the transaction quantity limit to generate a second block proposal for voting by the multiple blockchain nodes in the second consensus round in the blockchain.

[0094] Optionally, the implementation details of step S650 are consistent with those of step S530 shown in FIG. 5, and will not be described again.

[0095] In step S660, the second block proposal is broadcast in the blockchain.

[0096] Optionally, the implementation details of step S660 are consistent with those of step S540 shown in FIG. 5, and will not be described again.

[0097] In the embodiments of the present application, after obtaining the multiple voting results generated by the multiple blockchain nodes for the first block proposal in the first consensus round for the first block proposal, the blockchain node generates the transaction quantity limit of the second consensus round according to the number of proposed transactions in each voting result, and when becoming a proposal node, packs the blockchain transactions into a new block proposal according to the determined transaction quantity limit of the second consensus round, and broadcasts in the blockchain, so as to generate a new block in the blockchain. In this way, the number of transactions packed in the next proposal is adjusted according to the proposals of each node in the consensus process, so that the transactions contained in the block proposal can be automatically adjusted during the execution result and execution time of the proposal, avoiding too many transactions in the block proposal causing execution timeout during the verification of the proposal, thereby preventing the failure of the proposal caused by the verification of the proposal execution timeout, and being beneficial to improve the operation efficiency of the blockchain.

[0098] In some optional embodiments of the present application, based on the above technical solutions, in the process of obtaining the voting result corresponding to the proposal consensus result from the multiple voting results generated by the multiple blockchain nodes for the first block proposal in the first consensus round as the candidate voting result according to the proposal consensus result, if the proposal consensus result is proposal success, the node selects the voting result of voting for from the multiple voting results generated by the multiple blockchain nodes for the first block proposal in the first consensus round as the candidate voting result. If the proposal consensus result is proposal failure, the node selects the voting result of voting against from the multiple voting results generated by the multiple blockchain nodes for the first block proposal in the first consensus round as the candidate voting result. In this embodiment, the local node selects the voting result whose voting content conforms to the proposal consensus result as the candidate voting result, so as to avoid the influence of the number of proposals of the node with incorrect consensus node judgment on the determined specified number, which is beneficial to reduce the probability that the process of determining the number of transactions is affected by malicious data, and improve the security of the blockchain system.

[0099] In some optional embodiments of the present application, based on the above technical solutions, in the process of generating the transaction quantity limit of the second consensus round according to the number of proposed transactions in the candidate voting result, if the proposal consensus result is proposal success, the first proposal transaction quantity in the first block proposal is obtained. If the first proposal transaction quantity is greater than or equal to the number of proposed transactions in the candidate voting result, the node takes the first proposal transaction quantity as the transaction quantity limit of the second consensus round. If the first proposal transaction quantity is less than the number of proposed transactions in the candidate voting result, the node generates the transaction quantity limit of the second consensus round according to the mean value of the first proposal transaction quantity and the selected number of proposed transactions.

[0100] Specifically, when the consensus result is that the proposal consensus is successful, there are two cases, that is, the slave node approves or does not approve the first proposal transaction quantity packaged by the master node in the first block proposal. Specifically, if the first proposal transaction quantity is greater than or equal to the recommended transaction quantity in the candidate voting result, it means that the slave node approves the quantity packaged by the master node, and the first proposal transaction quantity can be directly used as the transaction quantity limit of the second consensus round. Please refer to FIG. 7, which is a logic diagram for generating the transaction quantity limit of the second consensus round in the embodiment of the application. As shown in FIG. 7, the recommended transaction quantity proposed by node 2 is consistent with the quantity packaged by the master node, so if node 2 becomes the master node in the next round, the quantity packaged by the master node is directly used as the packaging quantity in the next round of consensus. It should be noted that node 4 does not provide a recommended transaction quantity because it voted against, so if node 4 becomes the master node in the next round, the quantity packaged by the master node (that is, 10000) is directly used as the packaging quantity in the next round of consensus. If the first proposal transaction quantity is less than the recommended transaction quantity in the candidate voting result, it means that the slave node does not approve the transaction quantity packaged by the master node, and the node can generate the transaction quantity limit of the second consensus round according to the average of the first proposal transaction quantity and the selected recommended transaction quantity. Please refer to FIG. 8, which is another logic diagram for generating the transaction quantity limit of the second consensus round in the embodiment of the application. As shown in FIG. 8, the recommended transaction quantity proposed by node 2 is 10000, while the master node only packaged 5000, at this time, node 2 does not approve the packaging quantity of the master node, so when node 2 becomes the master node, it will determine the transaction quantity limit of the second consensus round according to the average of the two quantities, that is, 7500. Node 4 is similar, and the recommended transaction quantity proposed by node 4 is 6000, which is also higher than the packaging quantity of the master node, so when node 4 becomes the master node, the packaging transaction quantity in the proposal will be 7000. It should be noted here that the voting results received by node 2 and node 4 are different, because node 2 does not receive the voting result of node 4, so when node 2 determines the transaction quantity limit of the second consensus round, only the quantities proposed by node 1 and node 2 are considered, and node 3 is discarded because the quantity is over the limit. In this embodiment, the transaction quantity limit of the second consensus round is determined according to the comparison result of the recommended transaction quantity of the slave node and the transaction quantity packaged by the master node, so that the transaction quantity limit of the block proposal can be increased in time when the packaging quantity of the master node is small, thereby avoiding the waste of processing resources in the consensus process caused by too few transactions in the block, and improving the resource utilization of the scheme.

[0101] In some optional embodiments of the present application, based on the technical scheme above, the candidate voting results include a plurality of voting results generated by a plurality of blockchain nodes for the first block proposal in the first consensus round. In the process of generating the transaction quantity limit of the second consensus round according to the average of the first proposal transaction quantity and the selected proposal transaction quantity if the first proposal transaction quantity is less than the proposal transaction quantity in the candidate voting results, the node obtains a block transaction quantity threshold of the blockchain. If the proposal transaction quantity of any voting result in the candidate voting results is greater than the block transaction quantity threshold, the voting result is deleted from the candidate voting results. Then, the node generates the transaction quantity limit of the second consensus round according to the average of the first proposal transaction quantity and the proposal transaction quantity of each voting result in the candidate voting results. In the present application, if the proposal transaction quantity determined by the node is higher than the maximum quantity limit configured by the blockchain, the proposal transaction quantity will be discarded, so as to avoid the consensus failure caused by the proposal execution timeout due to too many transactions in the block proposal, and to improve the stability of the scheme. The block transaction quantity threshold is a maximum quantity limit configured by the blockchain, which is used to limit the number of transactions in the block proposal. If the proposal transaction quantity determined by the node is higher than the threshold, the proposal transaction quantity will be discarded.

[0102] In some optional embodiments of the present application, based on the technical scheme above, in the process of generating the transaction quantity limit of the second consensus round according to the proposal transaction quantity in the candidate voting results, if the proposal consensus result is proposal failure, the node obtains the proposal transaction quantity in the candidate voting results, and then determines the transaction quantity limit of the second consensus round according to the sum of the proposal transaction quantity in the candidate voting results and the number of candidate voting results. In the present embodiment, if the proposal consensus fails, only the proposal transaction quantity in the voting result of voting against will be selected to determine the transaction quantity limit of the second consensus round.

[0103] Referring to FIG. 9, FIG. 9 is another logic diagram for generating the transaction quantity limit of the second consensus round according to an embodiment of the present application. As shown in FIG. 9, since the consensus result fails, the local node will only select the voting results of the node 3 and the node 4 containing the opposing votes as the candidate voting results, and the determined transaction quantity limit of the second consensus round is the average of the suggested quantities of the two. The transaction quantity limit of the second consensus round can be determined in other manners, such as the maximum value or the minimum value, or first clustering based on the suggested transaction quantity and then classification calculation. By determining the transaction quantity limit of the second consensus round only according to the suggested transaction quantity in the failed candidate voting result when the proposal fails, the excessively high transaction quantity or excessively long execution time can be reduced in time, which is beneficial to avoid the subsequent consensus process from failing again and improve the consensus success rate.

[0104] Clustering: In the determination of the transaction quantity limit of the second consensus round, if the proposal consensus fails, the data can be first grouped based on the suggested transaction quantity, so that the data in the same group has higher similarity, and the data in different groups has greater difference, and then the different groups are classified and calculated to determine the limit, which is a data processing method.

[0105] In the embodiments of the present application, other embodiments for refining the technical solutions of the embodiment shown in FIG. 5 are also proposed, as shown in FIG. 10. In the block proposal method of an embodiment of the present application, the following steps can be included:

[0106] In step S1010, a plurality of voting results generated by a plurality of blockchain nodes in the first consensus round for the first block proposal are obtained, and each voting result contains a suggested transaction quantity, which is determined according to the first proposal transaction quantity in the first block proposal and the execution time of the blockchain node executing the first block proposal.

[0107] Optionally, the implementation details of step S1010 are consistent with those of step S510 shown in FIG. 5, and will not be described herein again.

[0108] In step S1020, a transaction quantity limit of a second consensus round is generated according to the suggested transaction quantities contained in the plurality of voting results, and the second consensus round is the next consensus round of the first consensus round.

[0109] Optionally, the implementation details of step S1020 are consistent with those of step S520 shown in FIG. 5, and will not be described herein again.

[0110] In step S1030, the blockchain transactions in the local transaction pool are packed according to the transaction quantity limit to generate a second block proposal for voting by a plurality of blockchain nodes in the second consensus round in the blockchain.

[0111] Optionally, the implementation details of step S1030 are consistent with step S530 shown in FIG. 5, and will not be repeated here.

[0112] Step S1040, broadcast the second block proposal in the blockchain.

[0113] Optionally, the implementation details of step S1040 are consistent with step S540 shown in FIG. 5, and will not be repeated here.

[0114] Step S1050, obtain the third block proposal generated by the master node;

[0115] The third block proposal is a block proposal generated by the master node after the second block proposal, but it is not necessarily the next round of proposal of the second block proposal.

[0116] Step S1060, execute the blockchain transaction in the third block proposal to obtain the execution result and execution time of the third block proposal;

[0117] Step S1070, determine the number of recommended transactions of the local node according to the execution result and the execution time;

[0118] Step S1080, generate a node voting result for the third block proposal according to the execution result of the third block proposal and the number of recommended transactions of the local node;

[0119] The node voting result is the result generated by the local node according to the execution result of the third block proposal and the number of recommended transactions of the local node, including voting information, voting signature, recommended transaction number, current block height, consensus round number and information signature, etc. Content, used to broadcast in the blockchain, participate in the consensus of the third block proposal.

[0120] Step S1090, broadcast the node voting result in the blockchain.

[0121] In this embodiment, after the local node broadcasts the second block proposal, the identity of the local node is switched from the master node to the slave node, and another node becomes the master node. The master node packages the third block proposal. It should be noted that the third block proposal is a proposal after the second block proposal, but not necessarily the next proposal after the second block proposal. As a slave node, the local node executes the blockchain transaction in the third block proposal, and obtains the execution result and the execution duration of the third block proposal. Then, according to the execution result and the execution duration, the number of recommended transactions of the local node is determined. Specifically, if the execution result is success but the execution duration is short, the number of transactions can be increased in the number of recommended transactions, and if the execution result is failure or the execution duration is long, the number of transactions can be reduced in the number of recommended transactions. Then, the local node generates a node voting result for the third block proposal according to the execution result of the third block proposal and the number of recommended transactions of the local node. Please refer to FIG. 11, which is a schematic diagram of a node voting result in an embodiment of the present application. As shown in FIG. 11, the node voting result is generally divided into two categories, namely, the approval vote and the opposition vote. Both of the two results have corresponding identifiers, and both of the two results are accompanied by the number of recommended transactions of the local node. Finally, the local node broadcasts the node voting result in the blockchain. When there is a malicious node, due to the limitation of the upper limit of the number of transactions in the block, the malicious node generally sends some relatively low values, which will cause the number of transaction data in the block to continue to decrease in several rounds of consensus, but the consensus can be reached, only the number of transactions in each block is relatively small. By increasing the number of recommended transactions when voting for approval, the excessively low number of transactions can be corrected in time, thereby avoiding the decrease of the blockchain transaction processing efficiency caused by the malicious node and improving the security of the scheme.

[0122] In an embodiment of the present application, after the blockchain node obtains the plurality of voting results generated by the plurality of blockchain nodes for the first block proposal in the first consensus round, the blockchain node generates a transaction quantity limit of the second consensus round according to the number of recommended transactions in each voting result, the second consensus round is the next consensus round of the first consensus round, and when becoming a proposal node, the blockchain node packages the blockchain transaction into a new block proposal according to the determined transaction quantity limit of the second consensus round, and broadcasts in the blockchain, so as to generate a new block in the blockchain. In this way, the number of transactions packaged in the next proposal is adjusted according to the suggestions of each node in the consensus process, so that the transactions contained in the block proposal can be automatically adjusted during the execution result and the execution duration of the proposal, thereby avoiding the execution timeout when verifying the proposal due to too many transactions in the block proposal, and preventing the proposal from failing due to the verification execution timeout, which is beneficial to improve the operation efficiency of the blockchain.

[0123] In some optional embodiments of the present application, based on the technical solutions described above, in the process of generating the node voting result for the third block proposal according to the execution result of the third block proposal and the number of proposed transactions of the local node, the node determines the voting information for the third block proposal according to the matching result between the execution result of the blockchain transaction in the third block proposal and the proposal result in the third block proposal. Then, the node signs the voting information according to the blockchain key of the local node to obtain a voting signature, and signs the number of proposed transactions according to the blockchain key of the local node to obtain an information signature. Finally, the node generates the node voting result for the third block proposal according to the voting information and the voting signature and the number of proposed transactions and the information signature.

[0124] The blockchain key is a key possessed by a blockchain node, which is used to sign important information such as voting information and the number of proposed transactions, to ensure the security, authenticity and integrity of the information in the transmission and storage process, and to prevent the information from being tampered with or forged.

[0125] The voting signature is the result obtained by signing the voting information for the third block proposal according to the blockchain key of the local node, which is used to ensure the authenticity and integrity of the voting information. The voting information is determined according to the matching result between the execution result of the blockchain transaction in the third block proposal and the proposal result in the third block proposal, and is usually in favor or against, which is used to express the attitude of the node towards the third block proposal and is an important part of the node voting result.

[0126] The information signature is the result obtained by signing the number of proposed transactions, the current block height in the blockchain and the consensus round number of the third block proposal according to the blockchain key of the local node, which is used to prevent the false sending of the voting result and ensure the authenticity and validity of the information such as the number of proposed transactions.

[0127] The current block height refers to the position identifier of the current block in the blockchain, which represents the number of blocks passed from the genesis block of the blockchain to the current block. Adding this information when generating the node voting result can be used to determine whether the voting result is sent for the current consensus round, preventing the false sending of the voting result.

[0128] In the embodiment, in the node voting result, the voting information and the number of proposal transactions are respectively signed, so that the node without the ability to provide the number of proposal transactions can still perform consensus based on the voting information and the corresponding signature, thereby improving the compatibility of the scheme.

[0129] In some optional embodiments of the present application, based on the above technical solutions, in the process of signing the number of proposal transactions according to the local node's blockchain key to obtain the information signature, the node obtains the current block height in the blockchain and the consensus round number of the third block proposal; and signs the number of proposal transactions, the current block height and the consensus round number according to the local node's blockchain key to obtain the information signature. When generating the node voting result, the node generates the node voting result for the third block proposal according to the voting information and the voting signature, and the number of proposal transactions, the current block height, the consensus round number and the information signature. The consensus round number refers to the round number of voting and consensus for different block proposals in the consensus process of the blockchain, which is used to identify which round of consensus is currently in. Adding this information when generating the node voting result helps the node to judge the timeliness of the voting result and avoid the influence of the fake sent voting result.

[0130] Please refer to FIG. 12, which is a schematic diagram of the specific structure of the node voting result in the embodiment of the present application. As shown in FIG. 12, in the embodiment, the current block height and the consensus round number are further added to the node voting result, which are mainly used to prevent the fake sending of the voting result. Specifically, the malicious node may collect the voting results of other nodes in the previous round, and then send the voting results of other nodes in the previous round in the next consensus round, which may cause other nodes to mistakenly think that the results are sent by the original node in the current round, thereby causing the confirmation error of the number of transactions. The current block height and the consensus round number in the node voting result can be used by the node to judge whether the voting result is sent for the current consensus round, thereby avoiding the influence of the fake sent voting result and improving the security of the scheme.

[0131] In some optional embodiments of the present application, based on the technical solutions described above, in the process of determining the number of recommended transactions of the local node according to the execution result and the execution duration, the node determines the candidate recommended quantity of the local node according to the first proposed transaction quantity, the node capability parameter and the execution duration, wherein the node capability parameter is determined according to the historical transaction execution result of the local node. If the execution result matches the proposal result in the third block proposal, the node takes the greater quantity between the candidate recommended quantity and the first proposed transaction quantity as the number of recommended transactions of the local node. If the execution result does not match the proposal result in the third block proposal, the node takes the smaller quantity between the candidate recommended quantity and the first proposed transaction quantity as the number of recommended transactions of the local node.

[0132] The node capability parameter is a parameter determined according to the historical transaction execution result of the local node, which is used to determine the candidate recommended quantity of the local node and can be updated according to the number of recommended transactions of other blockchain nodes. The candidate recommended quantity is a quantity value determined by the local node according to the first proposed transaction quantity, the node capability parameter and the execution duration, which is used to determine the number of recommended transactions of the local node.

[0133] In the present embodiment, the local node determines the candidate recommended quantity according to the node capability parameter determined according to the historical transaction. Specifically, the candidate recommended quantity can be (current quantity * X) / current time, wherein X is the node capability parameter. The node capability parameter is determined according to the historical transaction execution result of the local node, for example, according to the difference between the historical transaction execution and the quantity proposed by other nodes. After determining the candidate recommended quantity of the local node, if the execution result matches the proposal result in the third block proposal, the greater quantity between the candidate recommended quantity and the first proposed transaction quantity is selected as the number of recommended transactions, otherwise, if the execution result does not match the proposal result in the third block proposal, the smaller quantity is selected as the number of recommended transactions. In the present embodiment, the candidate recommended quantity is determined according to the node capability parameter determined according to the historical transaction execution result, and the number of recommended transactions is selected according to the matching of the execution result and the proposal result, which can make the matching degree of the determined number of recommended transactions and the execution result higher, and is beneficial to the accuracy of the determined number of recommended transactions, compared with directly determining the number of recommended transactions according to the computing capability of the local node.

[0134] In some optional embodiments of the present application, based on the technical solutions described above, the node further determines a baseline quantity according to the number of suggested transactions of other blockchain nodes in the plurality of voting results generated by the plurality of blockchain nodes for the first block proposal in the first consensus round, and then updates the node capability parameter of the local node according to the baseline quantity, the number of suggested transactions of the local node in the plurality of voting results generated by the plurality of blockchain nodes for the first block proposal in the first consensus round, and a proposal execution time threshold in the blockchain.

[0135] The baseline quantity is a quantity value determined according to the number of suggested transactions of other blockchain nodes in the plurality of voting results generated by the plurality of blockchain nodes for the first block proposal in the first consensus round, and is used to update the node capability parameter of the local node. The proposal execution time threshold is a preset time limit in the blockchain, which is used to limit the total execution time of all transactions in a block proposal. If the execution time exceeds the threshold, the proposal may fail.

[0136] In the present embodiment, the blockchain node adjusts the node capability parameter of the local node according to the number of suggested transactions proposed by other nodes. Specifically, the local node determines a baseline quantity according to the number of suggested transactions of other blockchain nodes in the plurality of voting results generated by the plurality of blockchain nodes for the first block proposal in the first consensus round. For example, if the number of suggested transactions of other nodes is 5000 and the number of suggested transactions of the local node is 4000 based on the same number (e.g., 10000) of transactions, then 5000 can be taken as the baseline quantity. It can be understood that the baseline quantity can be the number that appears most frequently among the number of suggested transactions of other blockchain nodes, but it can also be determined according to other ways, such as the mean or median value, etc. Subsequently, the local node adjusts its node capability parameter according to the baseline quantity. For example, the local node can expand the current node capability parameter according to the ratio between the difference between the baseline quantity and the number of suggested transactions and the proposal execution time threshold. Specifically, in one embodiment, the node capability parameter can = 4000 * 10 * 0.8 / 5000, where 10 is the proposal execution time threshold, i.e., 10 seconds, and 0.8 is a preset adjustment threshold. It can be understood that the process of updating the node capability parameter of the local node is usually performed after the consensus is completed. In the present embodiment, the local node updates the node capability parameter of the local node according to the number of suggested transactions of other nodes, so as to timely adjust the number of suggested transactions generated by the local node, avoid the number of suggested transactions being too high or too low to affect the number of transactions packed in the block, and improve the rationality of the number of transactions in the block.

[0137] The specific implementation process of the technical scheme of the application will be introduced below in combination with specific embodiments. Please refer to FIG. 13, which is a schematic flowchart of the overall process of block proposal processing in an embodiment of the application. As shown in FIG. 13, the current consensus node obtains the transactions to be packaged from the transaction pool, executes the obtained transactions, and thus generates the block proposal of the current round of consensus. Then the current master node broadcasts the proposal to other nodes in the blockchain. Other nodes are mainly divided into ordinary nodes and next-round master nodes, but the processing processes of these two types of nodes in the current round of consensus process are the same. Taking an ordinary node as an example, it parses the broadcast network information and thus obtains the broadcast block proposal. Network information: information transmitted between nodes in the blockchain network when they communicate, including block proposals, voting results and other data. An ordinary node can obtain the broadcast block proposal and other contents by parsing the broadcast network information.

[0138] Then, the node checks the proposal object itself. If the check fails, it directly generates an opposing vote. If the check passes, the node executes all the transactions in the proposal and records the number of completed transactions. Then, the number of recommended transactions is generated according to the total execution time and the number of completed transactions. The node checks the transaction execution result against the proposal result. If the check passes, it generates a favorable vote, and if it fails, it generates an opposing vote. At this time, both types of votes are attached with the number of recommended transactions. Then, the node broadcasts the voting result to other nodes in the blockchain. Each node in the blockchain calculates the maximum number of transactions to be packaged next time according to the number of recommended transactions in the voting. After the completion of the current round of consensus, the next-round master node obtains the transactions to be packaged from the transaction pool according to the number determined in the last round, executes the obtained transactions, and thus generates the block proposal of the next round of consensus.

[0139] Proposal object: a block proposal, which is an object generated by the master node by packaging blockchain transactions, used for consensus among blockchain nodes. An ordinary node checks the proposal object itself to determine whether it meets the requirements.

[0140] Ordinary node: in the consensus process of the blockchain, in addition to the master node and the next-round master node, the node receives the block proposal broadcast by the master node, checks and executes the proposal, generates a voting result according to the execution result and broadcasts it, and at the same time generates a transaction recommendation number according to the total execution time and the number of completed transactions.

[0141] Number of completed transactions: the number of successfully completed transactions when a node executes the blockchain transactions in a block proposal. The node generates a transaction recommendation number according to this number and the total execution time.

[0142] It should be noted that although the various steps of the methods of the present application are described in a particular order in the drawings, this is not required or implied that the steps must be performed in that particular order, or that all of the steps shown must be performed to achieve the desired result. Additionally or alternatively, certain steps can be omitted, multiple steps can be combined into a single step, a single step can be broken into multiple steps, etc.

[0143] The device embodiments of the present application are introduced below, which can be used to perform the block proposal method in the above embodiments of the present application. FIG. 14 schematically shows a composition block diagram of a block proposal device in the embodiments of the present application. As shown in FIG. 14, the block proposal device 1400 can mainly include:

[0144] The obtaining module 1410 is configured to obtain a plurality of voting results generated by a plurality of blockchain nodes in a first consensus round for a first block proposal, each voting result containing a number of recommended transactions, the number of recommended transactions being determined according to a number of first proposal transactions in the first block proposal and an execution duration of the first block proposal performed by the blockchain node generating the voting result;

[0145] The generating module 1420 is configured to generate a transaction quantity limit for a second consensus round according to the number of recommended transactions contained in each of the plurality of voting results, the second consensus round being a next consensus round of the first consensus round;

[0146] The packaging module 1430 is configured to package blockchain transactions in a local transaction pool according to the transaction quantity limit, to generate a second block proposal for voting by a plurality of blockchain nodes in a second consensus round in the blockchain;

[0147] The broadcasting module 1440 is configured to broadcast the second block proposal in the blockchain.

[0148] In some embodiments of the present application, based on the above technical solutions, the generating module 1420 is specifically configured to: determine a proposal consensus result for the first block proposal according to the plurality of voting results generated by the plurality of blockchain nodes in the first consensus round for the first block proposal; obtain, as a candidate voting result, a voting result corresponding to the proposal consensus result from the plurality of voting results generated by the plurality of blockchain nodes in the first consensus round for the first block proposal according to the proposal consensus result; and generate a transaction quantity limit for the second consensus round according to the number of recommended transactions in the candidate voting result, the second consensus round being a next consensus round of the first consensus round.

[0149] In some embodiments of the present application, based on the above technical solutions, the generation module 1420 is specifically configured to: if the proposal consensus result is proposal success, take the voting result of voting for in the plurality of voting results generated by the plurality of blockchain nodes for the first block proposal in the first consensus round as the candidate voting result; and if the proposal consensus result is proposal failure, take the voting result of voting against in the plurality of voting results generated by the plurality of blockchain nodes for the first block proposal in the first consensus round as the candidate voting result.

[0150] In some embodiments of the present application, based on the above technical solutions, the generation module 1420 is specifically configured to: if the proposal consensus result is proposal success, obtain the first proposal transaction quantity in the first block proposal; if the first proposal transaction quantity is greater than or equal to the recommended transaction quantity in the candidate voting result, take the first proposal transaction quantity as the transaction quantity limit of the second consensus round; and if the first proposal transaction quantity is less than the recommended transaction quantity in the candidate voting result, generate the transaction quantity limit of the second consensus round according to the mean value of the first proposal transaction quantity and the selected recommended transaction quantity.

[0151] In some embodiments of the present application, based on the above technical solutions, the candidate voting result contains the plurality of voting results generated by the plurality of blockchain nodes for the first block proposal in the first consensus round; and the generation module 1420 is specifically configured to: if the first proposal transaction quantity is less than the recommended transaction quantity in the candidate voting result, obtain the block transaction quantity threshold of the blockchain; if the recommended transaction quantity of any voting result in the candidate voting result is greater than the block transaction quantity threshold, delete the voting result from the candidate voting result; and generate the transaction quantity limit of the second consensus round according to the mean value of the first proposal transaction quantity and the recommended transaction quantity of each voting result in the candidate voting result.

[0152] In some embodiments of the present application, based on the above technical solutions, the generation module 1420 is specifically configured to: if the proposal consensus result is proposal failure, obtain the recommended transaction quantity in the candidate voting result; and determine the transaction quantity limit of the second consensus round according to the sum of the recommended transaction quantities in the candidate voting result and the number of the candidate voting results.

[0153] In some embodiments of the present application, based on the above technical solutions, the broadcast module 1440 is further configured to: obtain the third block proposal generated by the master node; execute the blockchain transactions in the third block proposal to obtain the execution result and the execution time length of the third block proposal; determine the recommended transaction quantity of the local node according to the execution result and the execution time length; generate the node voting result for the third block proposal according to the execution result of the third block proposal and the recommended transaction quantity of the local node; and broadcast the node voting result in the blockchain.

[0154] In some embodiments of the present application, based on the above technical solutions, the broadcast module 1440 is specifically configured to: determine the voting information for the third block proposal according to a matching result between an execution result of the block chain transaction in the third block proposal and the proposal result in the third block proposal; sign the voting information according to the block chain key of the local node to obtain a voting signature; sign the number of proposed transactions according to the block chain key of the local node to obtain an information signature; and generate the node voting result for the third block proposal according to the voting information and the voting signature and the number of proposed transactions and the information signature.

[0155] In some embodiments of the present application, based on the above technical solutions, the broadcast module 1440 is specifically configured to: obtain the current block height in the block chain and the consensus round number of the third block proposal; sign the number of proposed transactions, the current block height and the consensus round number according to the block chain key of the local node to obtain an information signature; and generate the node voting result for the third block proposal according to the voting information and the voting signature and the number of proposed transactions, the current block height and the consensus round number and the information signature.

[0156] In some embodiments of the present application, based on the above technical solutions, the broadcast module 1440 is specifically configured to: determine the number of candidate proposals of the local node according to the first number of proposal transactions, the node capability parameter and the execution duration, wherein the node capability parameter is determined according to the historical transaction execution result of the local node; if the execution result matches the proposal result in the third block proposal, take the greater of the number of candidate proposals and the first number of proposal transactions as the number of proposed transactions of the local node; and if the execution result does not match the proposal result in the third block proposal, take the smaller of the number of candidate proposals and the first number of proposal transactions as the number of proposed transactions of the local node.

[0157] In some embodiments of the present application, based on the above technical solutions, the broadcast module 1440 is specifically configured to: determine the baseline number according to the number of proposed transactions of other block chain nodes in the plurality of voting results generated by the plurality of block chain nodes for the first block proposal in the first consensus round; and update the node capability parameter of the local node according to the baseline number, the number of proposed transactions of the local node in the plurality of voting results generated by the plurality of block chain nodes for the first block proposal in the first consensus round and the proposal execution time threshold in the block chain.

[0158] It should be noted that the apparatus provided in the above embodiments and the method provided in the above embodiments belong to the same concept, and the specific manner in which each module performs operations has been described in detail in the method embodiments, which will not be described here.

[0159] The block proposal method, device, electronic device, computer readable medium and computer program product provided in the application, a block chain node in a block chain obtains a plurality of voting results generated by a plurality of block chain nodes in the block chain for a first block proposal in a first consensus round, each voting result containing a number of recommended transactions, which is determined according to a number of first proposal transactions in the first block proposal and an execution duration of the block chain node generating the voting result for executing the first block proposal. Then, according to the number of recommended transactions contained in each of the plurality of voting results, a transaction quantity limit for a second consensus round is generated, the second consensus round being a next consensus round of the first consensus round. Next, according to the transaction quantity limit, the block chain transactions in the local transaction pool are packaged to generate a second block proposal. Finally, the second block proposal is broadcast in the block chain, and the second block proposal is used to indicate that a plurality of block chain nodes in the block chain vote in the second consensus round. In this way, the number of transactions packaged in the next proposal can be adjusted according to the suggestions of each node in the consensus process, the transactions contained in the block proposal are automatically adjusted, the verification of the proposal is prevented from being timed out due to too many transactions, the proposal is prevented from failing, and the efficiency of the block chain is improved.

[0160] Further, the block chain node determines a proposal consensus result for the first block proposal according to a plurality of voting results generated by a plurality of block chain nodes in the block chain for the first block proposal in the first consensus round, and then obtains a voting result corresponding to the proposal consensus result from the plurality of voting results generated by the plurality of block chain nodes for the first block proposal in the first consensus round as a candidate voting result according to the proposal consensus result, and further generates a transaction quantity limit for the second consensus round according to the number of recommended transactions in the candidate voting result. In this way, the influence of the correct voting result on the determination of the transaction quantity limit for the second consensus round is higher, and the accuracy of the determined transaction quantity limit is improved.

[0161] When the proposal consensus result is proposal success, the block chain node obtains, as the candidate voting result, a voting result in which a vote of approval is cast from the plurality of voting results generated by the plurality of block chain nodes for the first block proposal in the first consensus round; when the proposal consensus result is proposal failure, the block chain node obtains, as the candidate voting result, a voting result in which a vote of disapproval is cast from the plurality of voting results generated by the plurality of block chain nodes for the first block proposal in the first consensus round. This can avoid the influence of the number of suggestions from a node that incorrectly judges the consensus node on the specified number, reduce the probability of the determination of the transaction quantity being affected by malicious data, and improve the security of the block chain system.

[0162] If the proposal consensus result is proposal success, the blockchain node obtains the first proposal transaction quantity in the first block proposal, and if the first proposal transaction quantity is greater than or equal to the recommended transaction quantity in the candidate voting result, the first proposal transaction quantity is taken as the transaction quantity limit of the second consensus round. In this way, when the node recognizes the packaging quantity of the main node, the first proposal transaction quantity can be directly used as the transaction quantity limit of the next round.

[0163] If the first proposal transaction quantity is less than the recommended transaction quantity in the candidate voting result, the blockchain node generates the transaction quantity limit of the second consensus round according to the average of the first proposal transaction quantity and the selected recommended transaction quantity. This can timely increase the transaction quantity limit of the block proposal when the main node packaging quantity is small, avoid wasting processing resources in the consensus process due to too few transactions in the block, and improve the resource utilization rate of the scheme.

[0164] The candidate voting result contains a plurality of voting results generated by a plurality of blockchain nodes in the first consensus round for the first block proposal. If the first proposal transaction quantity is less than the recommended transaction quantity in the candidate voting result, the blockchain node obtains the block transaction quantity threshold of the blockchain, and if the recommended transaction quantity of any voting result in the candidate voting result is greater than the block transaction quantity threshold, the voting result is deleted from the candidate voting result. Then, the transaction quantity limit of the second consensus round is generated according to the average of the first proposal transaction quantity and the recommended transaction quantity of each voting result in the candidate voting result. In this way, it can avoid consensus failure caused by proposal execution timeout due to too many transactions in the block proposal, and improve the stability of the scheme.

[0165] If the proposal consensus result is proposal failure, the blockchain node obtains the recommended transaction quantity in the candidate voting result, and determines the transaction quantity limit of the second consensus round according to the sum of the recommended transaction quantities in the candidate voting result and the number of candidate voting results. This can timely reduce the excessively high transaction quantity or excessively long execution time when the proposal fails, avoid subsequent consensus process failure again, and improve the consensus success rate.

[0166] After broadcasting the second block proposal in the blockchain, the blockchain node obtains the third block proposal generated by the main node, executes the blockchain transaction in the third block proposal, obtains the execution result and execution time of the third block proposal, determines the recommended transaction quantity of the local node according to the execution result and execution time, generates a node voting result for the third block proposal according to the execution result of the third block proposal and the recommended transaction quantity of the local node, and broadcasts the node voting result in the blockchain. By increasing the recommended transaction quantity when voting, the excessively low transaction quantity can be corrected in time, the decline of the blockchain transaction processing efficiency caused by malicious nodes can be avoided, and the security of the scheme can be improved.

[0167] The blockchain node determines voting information for the third block proposal according to a matching result between an execution result of a blockchain transaction in the third block proposal and a proposal result in the third block proposal, signs the voting information according to a blockchain key of the local node to obtain a voting signature, signs the number of proposed transactions according to the blockchain key of the local node to obtain an information signature, and generates a node voting result for the third block proposal according to the voting information and the voting signature and the number of proposed transactions and the information signature. The voting information and the number of proposed transactions are signed in the node voting result, so that a node without the ability to provide the number of proposed transactions can still reach consensus based on the voting information and the corresponding signature, and the compatibility of the scheme is improved.

[0168] The blockchain node obtains a current block height in the blockchain and a consensus round number of the third block proposal, signs the number of proposed transactions, the current block height and the consensus round number according to a blockchain key of the local node to obtain an information signature, and generates a node voting result for the third block proposal according to the voting information and the voting signature and the number of proposed transactions, the current block height and the consensus round number and the information signature. The current block height and the consensus round number are added in the node voting result, so that the voting result cannot be forged and sent, the number of transactions cannot be confirmed incorrectly due to the forged voting result, and the security of the scheme is improved.

[0169] The blockchain node determines a candidate proposal number of the local node according to the first proposal transaction number, a node capability parameter and an execution duration, wherein the node capability parameter is determined according to a historical transaction execution result of the local node, and if the execution result matches the proposal result in the third block proposal, the larger of the candidate proposal number and the first proposal transaction number is taken as the number of proposed transactions of the local node. Compared with directly determining the number of proposed transactions according to the computing capability of the local node, the number of proposed transactions determined in this way is more matched with the execution result, and the accuracy of the number of proposed transactions is improved.

[0170] If the execution result does not match the proposal result in the third block proposal, the smaller of the candidate proposal number and the first proposal transaction number is taken as the number of proposed transactions of the local node. This further improves the way of determining the number of proposed transactions according to the execution result, and makes the number of proposed transactions more suitable for the actual execution.

[0171] The blockchain node determines a baseline number according to the number of recommended transactions of other blockchain nodes in the plurality of voting results generated by the plurality of blockchain nodes for the first block proposal in the first consensus round, and updates the node capability parameter of the local node according to the baseline number, the number of recommended transactions of the local node in the plurality of voting results generated by the plurality of blockchain nodes for the first block proposal in the first consensus round, and the threshold of the proposal execution time in the blockchain. By updating the node capability parameter of the local node according to the number of recommended transactions of other nodes, the number of recommended transactions generated by the local node can be adjusted in time, so as to avoid that the number of recommended transactions is too high or too low to affect the number of transactions packaged in the block, and improve the rationality of the number of transactions in the block.

[0172] FIG. 15 shows a structural schematic diagram of a computer system of an electronic device suitable for implementing the embodiments of the present application.

[0173] It should be noted that the computer system 1500 of the electronic device shown in FIG. 15 is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0174] As shown in FIG. 15, the computer system 1500 includes a central processing unit (CPU) 1501, which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 1502 or loaded from a storage portion 1508 to a random access memory (RAM) 1503. In the RAM 1503, various programs and data required for system operation are also stored. The CPU 1501, the ROM 1502, and the RAM 1503 are connected to each other through a bus 1504. An input / output (I / O) interface 1505 is also connected to the bus 1504.

[0175] The following components are connected to the I / O interface 1505: an input part 1506 including a keyboard, a mouse, etc.; an output part 1507 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), etc., and a speaker, etc.; a storage part 1508 including a hard disk, etc.; and a communication part 1509 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication part 1509 performs communication processing via a network such as the Internet. A drive 1510 is also connected to the I / O interface 1505 as necessary. A removable media 1511 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 1510 as necessary, so that a computer program read therefrom is installed in the storage part 1508 as necessary.

[0176] In particular, according to embodiments of the present application, the processes described in the various method flowcharts can be implemented as a computer software program. For example, embodiments of the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program code for executing the methods illustrated by the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via the communication part 1509, and / or installed from the removable media 1511. When the computer program is executed by the central processing unit (CPU) 1501, various functions defined in the system of the present application are performed.

[0177] It should be noted that the computer-readable medium in the embodiments of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination thereof. The computer-readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination thereof. More specific examples of the computer-readable storage medium can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (Compact Disc Read-Only Memory, CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus or device. In this application, the computer-readable signal medium can include a data signal carried in a baseband or as a part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take many forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium, which can send, transmit, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, or the like, or any suitable combination thereof.

[0178] The flowcharts and block diagrams in the drawings illustrate the possible implementation architectures, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowcharts or block diagrams can represent a module, a program segment, or a portion of code that contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur in different orders than that shown in the figures. For example, two blocks noted in succession can actually be executed substantially concurrently, or they can sometimes be executed in reverse order, depending on the functionality involved. It should also be noted that each block in the flowcharts or block diagrams, and combinations of blocks in the flowcharts or block diagrams, can be implemented by special-purpose hardware-based systems that perform the specified functions or operations, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0179] It should be noted that, although several modules or units for a device for action execution are mentioned in the foregoing detailed description, such division into modules or units is not mandatory. Indeed, according to an embodiment of the application, the features and functionalities of two or more of the above-described modules or units can be embodied in one module or unit. Conversely, the features and functionalities of one of the above-described modules or units can be further divided into several modules or units.

[0180] From the above description of the embodiments, it is easy for those skilled in the art to understand that the example embodiments described herein can be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solutions according to the embodiments of the present application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash disk, a mobile hard disk, or the like) or on a network, and includes a number of instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to perform the methods according to the embodiments of the present application.

[0181] Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. It is intended that the present application cover any and all variations of the application that come within the scope of the basic underlying principles and features described. It is intended that the application encompass all alternatives, modifications and equivalents falling within the scope of the following claims.

[0182] Each of the technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described, however, as long as the combinations of the technical features do not exist contradictions, it should be considered that they are within the scope of the present disclosure.

[0183] The above-described embodiments are merely representative of several embodiments of the present application, and the description is relatively specific and detailed, but it should not be understood as limiting the scope of the patent. It should be noted that, for those skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are within the scope of the present application. Therefore, the scope of the patent of the present application should be subject to the appended claims.

Claims

1. A block proposal method, executed by a blockchain node in a blockchain, comprising: Obtaining multiple voting results generated by multiple blockchain nodes for a first block proposal in a first consensus round in a blockchain, each voting result including a number of suggested transactions, where the number of suggested transactions is determined based on the number of first proposal transactions in the first block proposal and an execution time of the first block proposal by the blockchain node that generated the voting result; generating a transaction quantity limit for a second consensus round based on the number of recommended transactions included in each of the plurality of voting results, where the second consensus round is a subsequent consensus round to the first consensus round; According to the transaction limit, the blockchain transactions in the local transaction pool are packaged to generate a second block proposal for voting by multiple blockchain nodes in the second consensus round of the blockchain; and The second block proposal is broadcasted in the blockchain.

2. The block proposal method according to claim 1, wherein generating a transaction limit for the second consensus round based on the number of proposed transactions included in each of the multiple voting results comprises: Determining a proposal consensus result for the first block proposal based on multiple voting results generated by multiple blockchain nodes for the first block proposal in the first consensus round; According to the proposal consensus result, obtaining a voting result corresponding to the proposal consensus result from multiple voting results generated by multiple blockchain nodes for the first block proposal in the first consensus round as a candidate voting result; A transaction limit for the second consensus round is generated based on the number of recommended transactions in the candidate voting results.

3. The block proposal method according to claim 2, wherein, based on the proposal consensus result, obtaining, from multiple voting results generated by multiple blockchain nodes for the first block proposal in the first consensus round, a voting result corresponding to the proposal consensus result as a candidate voting result, comprises: If the consensus result of the proposal is that the proposal is successful, the voting result of voting in favor of the first block proposal from the multiple voting results generated by the multiple blockchain nodes in the first consensus round is used as the candidate voting result; If the consensus result of the proposal is that the proposal fails, the voting result of the opposing vote from the multiple voting results generated by the multiple blockchain nodes for the first block proposal in the first consensus round shall be used as the candidate voting result.

4. The block proposal method according to claim 2, wherein generating a transaction limit for the second consensus round based on the number of proposed transactions in the candidate voting results comprises: If the consensus result of the proposal is that the proposal is successful, the number of first proposal transactions in the first block proposal is obtained; If the number of transactions in the first proposal is greater than or equal to the number of transactions recommended in the candidate voting result, the number of transactions in the first proposal will be used as the transaction limit for the second consensus round.

5. According to the block proposal method of claim 4, generating a transaction limit for the second consensus round based on the number of proposed transactions in the candidate voting results further comprises: If the number of the first proposed transactions is less than the number of suggested transactions in the candidate voting result, the transaction limit for the second consensus round is generated according to the average of the number of the first proposed transactions and the number of selected suggested transactions.

6. The block proposal method according to claim 5, wherein the candidate voting results include multiple voting results generated by multiple blockchain nodes for the first block proposal in the first consensus round; if the number of transactions in the first proposal is less than the number of suggested transactions in the candidate voting results, generating a transaction limit for the second consensus round based on the average of the number of transactions in the first proposal and the number of selected suggested transactions, comprising: If the number of transactions in the first proposal is less than the number of suggested transactions in the candidate voting result, obtaining the block transaction number threshold of the blockchain; If the number of suggested transactions for any of the candidate voting results is greater than the block transaction number threshold, the voting result will be deleted from the candidate voting results; A transaction limit for the second consensus round is generated based on the average of the number of transactions in the first proposal and the number of recommended transactions for each voting result in the candidate voting results.

7. The block proposal method according to any one of claims 2 to 6, wherein generating a transaction limit for the second consensus round based on the number of proposed transactions in the candidate voting results comprises: If the consensus result of the proposal is that the proposal fails, the number of recommended transactions in the candidate voting results is obtained; The transaction quantity limit for the second consensus round is determined based on the total number of recommended transactions in the candidate voting results and the number of candidate voting results.

8. The block proposal method according to any one of claims 1 to 7, wherein after broadcasting the second block proposal in the blockchain, the method further comprises: Get the third block proposal generated by the master node; Execute the blockchain transaction in the third block proposal to obtain the execution result and execution duration of the third block proposal; Determining the number of recommended transactions for the local node based on the execution result and the execution duration; Generating a node voting result for the third block proposal based on the execution result of the third block proposal and the number of proposed transactions of the local node; Broadcast the node voting results in the blockchain.

9. The block proposal method according to claim 8, wherein generating a node voting result for the third block proposal based on the execution result of the third block proposal and the number of proposed transactions of the local node comprises: Determining voting information for the third block proposal based on a match between an execution result of the blockchain transaction in the third block proposal and a proposal result in the third block proposal; Sign the voting information according to the blockchain key of the local node to obtain a voting signature; Sign the proposed transaction quantity according to the blockchain key of the local node to obtain a message signature; Generate a node voting result for the third block proposal based on the voting information and the voting signature, the proposed transaction quantity, and the information signature.

10. The block proposal method according to claim 9, wherein the step of signing the proposed transaction quantity according to the blockchain key of the local node to obtain the information signature comprises: Obtaining the current block height in the blockchain and the number of consensus rounds for the third block proposal; Signing the proposed transaction quantity, the current block height, and the number of consensus rounds according to the blockchain key of the local node to obtain a message signature; Generating a node voting result for the third block proposal based on the voting information and the voting signature, the number of proposed transactions, and the information signature includes: Generate a node voting result for the third block proposal based on the voting information, the voting signature, the number of proposed transactions, the current block height, the number of consensus rounds, and the information signature.

11. The block proposal method according to any one of claims 8 to 10, wherein determining the number of proposed transactions for the local node based on the execution result and the execution duration comprises: Determining the number of candidate proposals for the local node based on the number of the first proposal transactions, a node capability parameter, and the execution duration, wherein the node capability parameter is determined based on historical transaction execution results of the local node; If the execution result matches the proposal result in the third block proposal, the larger number between the candidate proposal number and the first proposal transaction number is used as the proposed transaction number of the local node.

12. The block proposal method according to claim 11, wherein determining the number of proposed transactions for the local node based on the execution result and the execution duration further comprises: If the execution result does not match the proposal result in the third block proposal, the smaller number between the candidate proposal number and the first proposal transaction number is used as the proposed transaction number of the local node.

13. The block proposal method according to claim 11 or 12, further comprising: Determining a baseline quantity based on the number of proposed transactions of other blockchain nodes in multiple voting results generated by multiple blockchain nodes for the first block proposal in the first consensus round; Update the node capability parameter of the local node according to the baseline number, the number of proposed transactions of the local node in multiple voting results generated by multiple blockchain nodes for the first block proposal in the first consensus round, and the proposal execution time threshold in the blockchain.

14. A block proposal device, comprising: an acquisition module configured to acquire a plurality of voting results generated by a plurality of blockchain nodes in a first consensus round in a blockchain for a first block proposal, each voting result comprising a number of suggested transactions, the number of suggested transactions being determined based on the number of first proposal transactions in the first block proposal and an execution time of the first block proposal by the blockchain node generating the voting result; a generating module configured to generate a transaction quantity limit for a second consensus round based on the number of recommended transactions included in each of the plurality of voting results, where the second consensus round is a subsequent consensus round of the first consensus round; a packaging module configured to package the blockchain transactions in the local transaction pool according to the transaction quantity limit and generate a second block proposal for voting by multiple blockchain nodes in a second consensus round in the blockchain; and A broadcasting module is configured to broadcast the second block proposal in the blockchain.

15. An electronic device comprising: processor; a memory for storing executable instructions of the processor; The processor is configured to perform the block proposal method according to any one of claims 1 to 13 by executing the executable instructions.

16. A computer-readable medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the block proposal method according to any one of claims 1 to 13 is implemented.

17. A computer program product, comprising a computer program, wherein the computer program is stored in a computer-readable storage medium, and a processor of an electronic device reads and executes the computer program from the computer-readable storage medium, so that the electronic device performs the block proposal method according to any one of claims 1 to 13.

Images