CN118013589A

CN118013589A - Block chain consensus method, device, computer equipment and storage medium

Info

Publication number: CN118013589A
Application number: CN202211403433.2A
Authority: CN
Inventors: 邵珠光
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-11-10
Filing date: 2022-11-10
Publication date: 2024-05-10

Abstract

The present application relates to a blockchain consensus method, apparatus, computer device, storage medium and computer program product. The method comprises the following steps: acquiring a first transaction task which is not agreed and is of a non-rejection type from a cache; grabbing a second transaction task from a transaction pool based on the preset number and the number when the number of the first transaction tasks is smaller than the preset number; packaging the first transaction task and the second transaction task into proposal information of a block to be consensus; the proposal message is broadcast to a first node in a blockchain, so that the first node performs consensus on the block to be consensus based on the first transaction task and the second transaction task. The method can effectively reduce the execution time of the transaction, and effectively reduce the resource consumption while improving the consensus efficiency.

Description

Block chain consensus method, device, computer equipment and storage medium

Technical Field

The present application relates to the field of computer technology, and in particular, to a blockchain consensus method, apparatus, computer device, storage medium, and computer program product.

Background

The blockchain is a novel decentralized distributed account book technology, can safely store transactions or other data, and is characterized in that information stored on the blockchain cannot be forged or tampered, and a blockchain consensus algorithm drives each node on the blockchain to participate in the verification process of the transactions, so that the transactions on the blockchain are ensured to be confirmed and trusted.

However, in the current blockchain consensus mode, the states of all nodes in the blockchain are required to be consistent, and only the blockchain can reach consensus, otherwise, the whole blockchain cannot normally operate, but in actual business, because uncertain results such as random numbers, time stamps and the like are carried in intelligent contracts, different nodes can generate different results when the contracts of the type are executed, so that the consensus cannot be reached, and the consensus efficiency of the blockchain is lower.

Disclosure of Invention

In view of the foregoing, it is desirable to provide a blockchain consensus method, apparatus, computer device, computer readable storage medium, and computer program product that can effectively improve the blockchain consensus efficiency while reducing the resource consumption.

In a first aspect, the present application provides a blockchain consensus method. The method comprises the following steps: acquiring a first transaction task which is not agreed and is of a non-rejection type from a cache; grabbing a second transaction task from a transaction pool based on the preset number and the number when the number of the first transaction tasks is smaller than the preset number; packaging the first transaction task and the second transaction task into proposal information of a block to be consensus; the proposal message is broadcast to a first node in a blockchain, so that the first node performs consensus on the block to be consensus based on the first transaction task and the second transaction task.

In a second aspect, the application also provides a block chain consensus device. The device comprises: the acquisition module is used for acquiring a first transaction task which is not agreed and is of a non-rejection type from the cache; the grabbing module is used for grabbing a second transaction task from the transaction pool based on the preset number and the number when the number of the first transaction tasks is smaller than the preset number; the packaging module is used for packaging the first transaction task and the second transaction task into proposal messages of the blocks to be identified; and the broadcasting module is used for broadcasting the proposal message to a first node in a blockchain so that the first node can carry out consensus on the block to be consensus based on the first transaction task and the second transaction task.

In a third aspect, the present application also provides a computer device. The computer device comprises a memory storing a computer program and a processor which when executing the computer program performs the steps of: acquiring a first transaction task which is not agreed and is of a non-rejection type from a cache; grabbing a second transaction task from a transaction pool based on the preset number and the number when the number of the first transaction tasks is smaller than the preset number; packaging the first transaction task and the second transaction task into proposal information of a block to be consensus; the proposal message is broadcast to a first node in a blockchain, so that the first node performs consensus on the block to be consensus based on the first transaction task and the second transaction task.

In a fourth aspect, the present application also provides a computer-readable storage medium. The computer readable storage medium having stored thereon a computer program which when executed by a processor performs the steps of: acquiring a first transaction task which is not agreed and is of a non-rejection type from a cache; grabbing a second transaction task from a transaction pool based on the preset number and the number when the number of the first transaction tasks is smaller than the preset number; packaging the first transaction task and the second transaction task into proposal information of a block to be consensus; the proposal message is broadcast to a first node in a blockchain, so that the first node performs consensus on the block to be consensus based on the first transaction task and the second transaction task.

In a fifth aspect, the present application also provides a computer program product. The computer program product comprises a computer program which, when executed by a processor, implements the steps of: acquiring a first transaction task which is not agreed and is of a non-rejection type from a cache; grabbing a second transaction task from a transaction pool based on the preset number and the number when the number of the first transaction tasks is smaller than the preset number; packaging the first transaction task and the second transaction task into proposal information of a block to be consensus; the proposal message is broadcast to a first node in a blockchain, so that the first node performs consensus on the block to be consensus based on the first transaction task and the second transaction task.

The block chain consensus method, the block chain consensus device, the computer equipment, the storage medium and the computer program product acquire a first transaction task which is not agreed and is of a non-elimination type from a cache; grabbing a second transaction task from a transaction pool based on the preset number and the number when the number of the first transaction tasks is smaller than the preset number; packaging the first transaction task and the second transaction task into proposal information of a block to be consensus; the proposal message is broadcast to a first node in a blockchain, so that the first node performs consensus on the block to be consensus based on the first transaction task and the second transaction task. The first transaction task is the transaction task which is executed in the previous round, so in the round consensus process, the transaction tasks which are executed in the previous round can be preferentially obtained from a cache, and are not needed to be executed again in the round consensus, so that the execution efficiency of the transaction tasks can be effectively improved.

Drawings

FIG. 1 is a schematic diagram of an alternative architecture of a distributed system 100 for use in a blockchain system in one embodiment;

FIG. 2 is an alternative schematic diagram of a block structure in one embodiment;

FIG. 3 is a flow diagram of a block chain consensus method in one embodiment;

FIG. 4 is a diagram of a set of low priority contract groups maintained in a block chain system in one embodiment;

FIG. 5 is a flow diagram of a transaction culling scheme in a conventional manner in one embodiment;

FIG. 6 is a flow diagram of a process for eliminating transactions in a conventional manner, in one embodiment;

FIG. 7 is a schematic diagram of an overall optimization flow for block chain transaction culling in one embodiment;

FIG. 8 is a schematic diagram of a process flow of a node model in one embodiment;

FIG. 9 is a flow diagram of a node traversing a transaction in one embodiment;

FIG. 10 is a flow diagram of adjusting contract priorities for a culling transaction in one embodiment;

FIG. 11 is a schematic overall flow diagram of an optimization scheme for transaction capture in one embodiment;

FIG. 12 is a block diagram of a block chain consensus device in an embodiment;

fig. 13 is an internal structural view of a computer device in one embodiment.

Detailed Description

The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.

The system according to the embodiment of the present invention may be a distributed system formed by connecting a client and a plurality of nodes (any form of computing device in an access network, such as a server and a user terminal) through a network communication.

Taking a distributed system as an example of a blockchain system, referring To fig. 1, fig. 1 is a schematic diagram of an alternative architecture of a distributed system 100 applied To a blockchain system according To an embodiment of the present invention, where the architecture is formed by a plurality of nodes (arbitrary computing devices in an access network, such as servers and user terminals) and clients, and a Peer-To-Peer (P2P, peer To Peer) network is formed between the nodes, where the P2P protocol is an application layer protocol running on top of a transmission control protocol (TCP, transmission Control Protocol) protocol. In a distributed system, any machine, such as a server, a terminal, may join to become a node, including a hardware layer, an intermediate layer, an operating system layer, and an application layer.

Referring to the functionality of each node in the blockchain system shown in fig.1, the functions involved include:

1) The routing, the node has basic functions for supporting communication between nodes.

Besides the routing function, the node can also have the following functions:

2) The application is used for being deployed in a block chain to realize specific service according to actual service requirements, recording data related to the realization function to form recorded data, carrying a digital signature in the recorded data to represent the source of task data, sending the recorded data to other nodes in the block chain system, and adding the recorded data into a temporary block when the source and the integrity of the recorded data are verified by the other nodes.

For example, the services implemented by the application include:

2.1 Wallet for providing electronic money transactions, including initiating a transaction (i.e., sending a transaction record of the current transaction to other nodes in the blockchain system, the other nodes, after verification, storing record data of the transaction in a temporary block of the blockchain in response to acknowledging that the transaction is valid; of course, the wallet also supports inquiry of remaining electronic money in the electronic money address;

2.2 The shared account book is used for providing the functions of storing, inquiring, modifying and the like of account data, sending record data of the operation on the account data to other nodes in the blockchain system, and after the other nodes verify to be effective, storing the record data into a temporary block as a response for acknowledging that the account data is effective, and also sending confirmation to the node initiating the operation.

2.3 A computerized agreement that can execute the terms of a contract, implemented by code deployed on a shared ledger for execution when certain conditions are met, for completing automated transactions based on actual business demand codes, such as querying the physical distribution status of the goods purchased by the buyer, transferring the electronic money of the buyer to the merchant's address after the buyer signs for the goods; of course, the smart contract is not limited to executing the contract for the transaction, and may execute a contract that processes the received information.

3) The blockchain comprises a series of blocks (blocks) which are connected with each other according to the generated sequence time, the new blocks are not removed once being added into the blockchain, and record data submitted by nodes in the blockchain system are recorded in the blocks.

Referring to fig. 2, fig. 2 is an optional Block Structure (Block Structure) provided in an embodiment of the present invention, where each Block includes a hash value of a transaction record stored in the Block (hash value of the Block) and a hash value of a previous Block, and each Block is connected by the hash value to form a Block chain. In addition, the block may include information such as a time stamp at the time of block generation. The blockchain (Blockchain), essentially a de-centralized database, is a string of data blocks that are generated in association using cryptographic methods, each of which contains associated information for verifying the validity of its information (anti-counterfeiting) and generating the next block.

In one embodiment, as shown in fig. 3, a blockchain consensus method is provided, and the method is applied to the node cluster in the blockchain system in fig. 1 for illustration, and includes the following steps:

Step 302, a first transaction task that is not agreed upon and is a non-culling class is obtained from the cache.

The block chain is a chain formed by one block. Each block holds certain information which is linked in a chain according to the time sequence of their respective generation. This chain is kept in all servers, and the entire blockchain is secure as long as one server in the entire system can work. These servers, referred to as nodes in the blockchain system, provide storage space and computational support for the entire blockchain system. If the information in the blockchain is to be modified, it is necessary to sign consent of more than half of the nodes and modify the information in all the nodes, which are usually held in different subject hands, so it is an extremely difficult thing to tamper with the information in the blockchain. Compared with the traditional network, the blockchain has two main core characteristics: firstly, the data is difficult to tamper, and secondly, the data is decentralised. Based on the two characteristics, the information recorded by the blockchain is more real and reliable, and can help solve the problem that people are not trusted each other. The blockchain types include public chains, federated chains, private chains, etc., and the blockchain system in the present application may be a federated chain system.

The blockchain, i.e., the blockchain system, is a distributed system in which it is most important for the business party to be a smart contract, which is the carrier for its business needs to be fulfilled.

The smart contract (Smart Contract), which is not smart itself, is a piece of code that implements user business logic that is executed by the node virtual machines of the blockchain. For a blockchain system, it requires that the states of all nodes must be consistent, that is, it is a deterministic state machine, only so that the blockchain system can reach consensus, otherwise the entire blockchain cannot function properly. However, in actual business, due to carelessness of a developer or other factors, uncertain results such as random numbers, time stamps and the like are carried in intelligent contracts written by the developer, and when the contracts are executed, different nodes generate different results, and for the situation, a strategy is generally adopted, and the transaction tasks are removed through the strategy, so that the activity of a blockchain is maintained.

The cache refers to a cache local to each node in the blockchain, for example, the current node is node 1 in the blockchain, and then node 1 may obtain the cached transaction task from the local cache.

The first transaction task refers to a transaction task stored in a local cache, in some cases, the transaction task in the present application may also be referred to as a transaction, where the first transaction task in the present application may be a transaction task that has been executed when the previous round of consensus is performed, for example, when the preamble block is consensus-processed, the current node has executed the transaction task a, and determines that the execution result of the transaction task a is consistent with the execution result of the task a carried in the preamble block, but the preamble block does not reach consensus, so the transaction task a does not reach consensus.

The fact that the consensus is not reached means that when the preamble block is consensus, all transaction tasks in the preamble block are not consensus, and here, the fact that the execution results of the transaction tasks are not consistent does not mean that the execution results of the transaction tasks are not consistent, and in fact, the execution results of most of the transaction tasks are highly probable to be consistent.

The transaction tasks of the non-reject class refer to transaction tasks that do not need to be rejected, for example, the transaction tasks of the non-reject class in the present application may be: and verifying the transaction task as a legal transaction task, namely, the transaction task of which the execution result is consistent with the execution result carried in the preamble block.

The first transaction task that is not agreed upon and is of the non-culling class refers to a transaction task that belongs to the class that is not agreed upon and does not need to be culled. For example, when the preamble block is consensus-processed, all transaction tasks in the preamble block are not consensus-processed, and the execution result of the transaction task is consistent with the execution result carried in the preamble block, so that the transaction task is not required to be rejected, and the transaction task belonging to the non-reject class, i.e. the first transaction task in the application may be the transaction task of the non-reject class which has already been executed.

After a newly created blockchain is started, when a new block is generated in the blockchain, a master node in the node cluster is responsible for generating a proposal message for the new block, broadcasting the proposal message so that each slave node verifies the proposal message and confirms whether the new block in the proposal message can reach consensus. When the new block reaches consensus, each node may add the new block to the local ledger. The block chain consensus environment in the application can be a block chain bottom layer model based on BFT type consensus, under the block chain bottom layer model based on BFT type consensus, a master node and a slave node are generally arranged, the master node is responsible for generating a proposal aiming at a new block, and the slave node is used for verifying to confirm whether the block in the proposal can reach consensus. BFT (Byzantine Fault Tolerance), bayesian fault tolerance, is a consensus mechanism.

Specifically, after a newly created blockchain is started, when a new block is generated in the blockchain and consensus is needed, a master node in the node cluster can preferentially acquire a first transaction task which is not agreed and is of a non-rejection type from a local cache; if no transaction task is stored in the local cache, namely when the master node in the node cluster does not acquire any transaction task from the cache, the master node in the node cluster grabs the transaction task from the transaction pool.

For example, under the block chain bottom layer model based on BFT type consensus, after a newly created block chain is started, when a new block is generated in the newly created block chain, each node in the node cluster can judge whether the node is a master node or not, for example, each node in the node cluster can judge whether a block-out condition is met or not according to parameters in a block maintained by the node cluster; when a certain node determines that the node meets the block-out condition, the node is the master node. The out-of-block condition refers to a condition for touching out an out-of-block, for example, the out-of-block condition in the present application may be set such that the height value is greater than a preset threshold, and the preset threshold may be 1. The node that goes out the piece qualifies to encapsulate the transaction task into a proposal message for the block to be agreed upon.

Further, after a certain node in the node cluster determines itself to be the master node, the master node goes out of the block and starts a new round of consensus, that is, the master node is responsible for generating a proposal for the new block, and the master node can obtain a first transaction task which is not consensus and is of a non-rejection type from the cache.

And step 304, grabbing a second transaction task from the transaction pool based on the preset quantity and the quantity when the quantity of the first transaction task is smaller than the preset quantity.

The preset number refers to the number of transaction tasks to be packaged in the block to be consensus, for example, the preset number may be 100.

The second transaction task refers to a transaction task obtained from a transaction pool, and the first transaction task and the second transaction task in the present application are just different in obtaining sources for distinguishing the transaction tasks, for example, the second transaction task in the present application may be a second transaction task screened from the transaction pool according to the order of processing priorities corresponding to contracts of the transaction tasks from high to low.

Specifically, when a master node in the node cluster goes out of a block and starts a new round of consensus, the master node can acquire a first transaction task which does not reach consensus and is of a non-rejection class from a cache; when the number of the first transaction tasks acquired from the cache by the master node is smaller than the preset number, the master node can determine the grabbing number of the transaction tasks to be grabbed based on the preset number and the number of the first transaction tasks, and grab the second transaction tasks from the transaction pool according to the grabbing number. When the main node in the application gets out of the block, the main node preferentially acquires the transaction tasks of non-rejection class from the local cache, and if the transaction tasks are not stored in the local cache or the number of the transaction tasks stored in the local cache is smaller than the preset number, the main node can grasp the second transaction tasks from the transaction pool again so as to ensure that the total number of the first transaction tasks and the second transaction tasks accords with the preset number appointed by the block to be shared.

For example, assuming that the blockchain 1 includes 3 nodes, namely, node 1, node 2 and node 3, after a newly created blockchain 1 is started, each node in the blockchain 1 can determine whether the block-out condition is satisfied based on the self-maintained block height value; assuming that the block height values of the node 1 and the node 3 at the current moment are 0 and the block height value of the node 2 is 1, the node 2 in the node cluster can determine that the block-out condition is met based on the block height value 1 maintained by the node 2, and the node 2 is blocked out and becomes a master node. After the node 2 meets the block out condition, the node 2 may start a new round of consensus, that is, the node 2 may obtain the first transaction tasks which are not agreed and are of the non-reject type from the local cache, assuming that the preset number is 10, if the node 2 obtains the first transaction tasks which are not agreed and are of the non-reject type from the local cache as 6, because 6 is smaller than 10, the node 2 may determine that the number of second transaction tasks still needed to be captured from the transaction pool is 4 based on the preset number 10 and the number 6 of the first transaction tasks, that is, the node 2 may capture 4 second transaction tasks from the transaction pool according to the processing priority of contracts of the transaction tasks.

Step 306, packaging the first transaction task and the second transaction task into a proposal message of the block to be consensus.

The proposed message is a communication message when the nodes in the blockchain communicate with each other, for example, the communication message may also include a consensus message, a voting message, etc., and the proposed message in the present application refers to a message carrying a proposed, for example, a proposed 1 is carried in a certain proposed message, and the proposed 1 is generated for a newly generated block 1 to be consensus.

The block to be consensus refers to a block that is not consensus by the blockchain network, for example, a block is newly produced after the creation of the blockchain 1, and the newly produced block is the block to be consensus before the newly produced block is verified by the slave node and consensus is achieved.

Step 308, broadcasting the proposal message to the first node in the blockchain, so that the first node performs consensus on the block to be consensus based on the first transaction task and the second transaction task.

Wherein the first node refers to other nodes in the blockchain, for example, the first node in the present application may be each slave node in the blockchain.

The consensus refers to the consensus of a newly generated block, and only after the newly generated block is verified by a slave node and the consensus is achieved, the newly generated block can be uplink to a block chain, and each node can store the agreed block in a local ledger.

Specifically, when a master node in the node cluster goes out of a block and starts a new consensus, if the number of first transaction tasks acquired from the cache by the master node is smaller than a preset number, after the master node grabs a second transaction task from the transaction pool based on the preset number and the number of the first transaction tasks, the master node can package the first transaction task and the second transaction task into a proposal message of a block to be consensus, and broadcast the proposal message to a first node in a block chain, so that the first node can consensus the block to be consensus based on the first transaction task and the second transaction task. The master node in the application can pack the first transaction task and the second transaction task into a proposal, and broadcast the proposal to all slave nodes in the blockchain in a message mode, and when each slave node receives the proposal message, each slave node verifies all transaction tasks in the proposal message to obtain a verification result; when the verification result shows that at least one transaction task in all transaction tasks in the proposal message is illegal, the slave node generates a voting message which is not in favor of the consensus of the block to be consensus, the slave node can receive the voting messages broadcast by other nodes, and when the number of the voting messages which are in favor of the consensus of the block to be consensus in the voting messages meets the preset condition, the block to be consensus can reach consensus, namely the block to be consensus can be added into the block chain, and each node can also add the block to be consensus into a local account book.

In addition, when the number of voting messages in the voting messages for approving the consensus of the block to be consensus does not meet the preset condition, the block to be consensus can not reach consensus, namely when the block to be consensus is not reached, each slave node can store the legal transaction task and the execution result of the transaction task in the cache in the process of the round of consensus.

Meanwhile, each slave node can traverse the received voting message, and selects a disapproved voting message, wherein the disapproved voting message refers to a voting message which is disapproved for the block to be consensus; further, each slave node can traverse each disfavored transaction task corresponding to the disfavored voting message, judge whether each disfavored transaction task meets the rejection condition one by one, select the transaction task meeting the rejection condition, and adjust the contract priority corresponding to the transaction task meeting the rejection condition, so that the probability of acquiring the transaction task is reduced as much as possible when the master node generates the proposal next time, and the success rate of meeting consensus for the proposal next time is improved. When the block to be consensus is not consensus, each node can reject the transaction task meeting the rejection condition in the round of consensus process.

The rejection condition may be f+1, where f represents the maximum allowable number of disqualified nodes, for example, if there are 4 nodes in the blockchain, 1 disqualified node is allowed at maximum, and the rejection condition satisfies f+1 disapproved votes, which indicates that the transaction task may be deleted, and f+1>f, which indicates that at least one honest node selects to reject the transaction task.

In this embodiment, a first transaction task which is not agreed and is of a non-reject type is obtained from a cache, and when the number of the first transaction tasks is smaller than a preset number, a second transaction task is grabbed from a transaction pool based on the preset number and the number of the first transaction tasks, the first transaction task and the second transaction task are packaged into proposal messages of a block to be agreed, and the proposal messages are broadcast to a first node in a blockchain, so that the first node agrees with the block to be agreed based on the first transaction task and the second transaction task. The first transaction task is the transaction task which is executed in the previous round, so in the round consensus process, the transaction tasks which are executed in the previous round can be preferentially obtained from a cache, and are not needed to be executed again in the round consensus, so that the execution efficiency of the transaction tasks can be effectively improved.

In one embodiment, the method further comprises:

under the condition that the preamble block of the block to be identified is identified and the preamble block is not identified, acquiring the transaction task which is executed in the preamble block and is of a non-rejection type;

Storing the executed transaction tasks which are non-reject classes in a cache;

The obtaining the first transaction task which is not agreed and not rejected from the cache comprises the following steps:

Screening first transaction tasks which are not agreed and are non-reject according to contract priority from cached transaction tasks; the contract priority is a priority corresponding to the contract of each transaction task.

The preamble block refers to the last block of the current block, for example, the first block constructed earliest is called the creation block, and has a unique ID identification number. Each subsequently created block contains, in addition to the created block, two ID numbers, one being the ID number of the block itself and the other being the ID number of the preceding block. All blocks are connected in sequence through the front-back pointing relation among the ID numbers to form a block chain.

The contract priority refers to the priority corresponding to the contract of each transaction task, for example, a low-priority contract group set can be maintained in the blockchain system, the contract priority corresponding to each contract is included in the group, for example, the contract priority corresponding to the contract C is 11, the contract priority with a certain range of values can be preset to be low, for example, when the value of the contract priority is in the range of 1-20, the contract priority with the low priority is included in the group.

Specifically, in the previous round of consensus, that is, under the condition that the node cluster performs consensus on the preamble block of the current block to be consensus, and the preamble block does not reach the consensus, each node in the node cluster can acquire the executed transaction task which is a non-rejection class in the process of performing the consensus on the preamble block, and store the executed transaction task which is a non-rejection class in a local cache, that is, when each node in the node cluster performs the consensus on the preamble block, each node in the node cluster needs to verify all the transaction tasks in the preamble block, and obtain a verification result corresponding to each transaction task; when the verification result of the transaction task indicates that the transaction task belongs to a legal transaction task, the legal transaction task and the execution result of the transaction task can be stored in a local cache, namely, the transaction task verified to be legal can be used as a transaction task of a non-rejection class. Even if finally the preamble block cannot reach consensus, the executed transaction tasks which are non-reject classes are already stored in the local caches of the nodes in the node cluster.

Further, when the new master node in the node cluster starts the new round of consensus after the last round of consensus process is finished, the executed transaction tasks which are not in the class of rejection in the previous round of the local cache of each node in the node cluster are stored, so that the new master node in the node cluster can screen the first transaction tasks which are not in the class of rejection and are not in the consensus from the transaction tasks in the local cache according to contract priority, wherein the contract priority is the priority corresponding to the contract of each transaction task, for example, in the consensus process of the present round of the contract priority, the new master node in the node cluster can screen the preset number of the first transaction tasks which are not in the class of rejection from the transaction tasks in the local cache according to the order of the contract priority from high to low.

For example, assuming that the blockchain 1 includes 3 nodes, namely, node 1, node 2 and node 3, after a newly created blockchain 1 is started, each node in the blockchain 1 can determine a block height value maintained by itself, and determine whether the blockchain itself meets a block-out condition according to the determined block height value; when a certain node in the node cluster determines that the block-out condition is met based on the self-maintained block height value, the node is blocked out and becomes a master node. Assuming that after node 2 in blockchain 1 determines that the block-out condition is met, node 2 is the master node, starting a new round of consensus, in this round of consensus, because the first block generated in blockchain 1 is consensus, any transaction task may not be cached in the local cache of node 2, that is, node 2 may acquire the first transaction task which is not consensus and is not a rejection class from the local cache, if the first transaction task is not acquired, node 2 may grasp the second transaction task from the transaction pool based on a preset number, node 2 packages the second transaction task into a proposal message of block 1 to be consensus, and broadcasts the proposal message to each node in blockchain 1, so that other nodes in blockchain 1 consensus the block 1 to be consensus based on the second transaction task; when the number of voting messages in the voting messages of all the nodes, which agree with the block 1 to be agreed, does not meet the preset condition, the block 1 to be agreed cannot agree, and each node in the node cluster can store the transaction tasks which are executed in the above-mentioned consensus process and are of non-rejection type in a local cache.

Further, it is assumed that, at the current moment, the second block, i.e. the block to be consensus 2, is generated in the blockchain 1, i.e. after the block is generated in the blockchain 1, a new block to be consensus 1 is generated, but in the previous round of consensus, the block to be consensus 1 is the preamble block of the current block to be consensus 2, i.e. when the node cluster performs consensus on the preamble block of the current block to be consensus 2 and the preamble block is not consensus, when a new master node, i.e. the node 1, in the blockchain 1 starts a new round of consensus, since the transaction tasks that have been executed in the previous round and are of non-rejection type are already stored in the local caches of each node in the node cluster, in the consensus process of the present round, the new master node, i.e. the node 1, in the node cluster, can screen out a preset number of the first transaction tasks that are not consensus and are of non-rejection type according to the order from high to low in the contract priority. Therefore, the execution time of the transaction task is reduced, the consensus efficiency is improved, and the resource consumption is reduced through optimizing and caching the flow of the grabbing transaction task.

In one embodiment, when the number of first transaction tasks is less than the preset number, the step of grabbing the second transaction task from the transaction pool based on the preset number and the number includes:

when the number of the first transaction tasks is smaller than the preset number, determining the first task grabbing number based on the preset number and the number;

Grabbing second transaction tasks from the transaction pool according to the first task grabbing quantity and the contract priority; the contract priority is the priority corresponding to the contract of each transaction task in the transaction pool.

The first task grabbing number refers to the number of transaction tasks needing to be grabbed from the transaction pool, for example, the preset number is 100, and if 50 first transaction tasks have been acquired from the cache, the number of second transaction tasks needing to be grabbed from the transaction pool is 50.

Specifically, when a master node in the node cluster goes out of a block and starts a new round of consensus, the master node can acquire a first transaction task which does not reach consensus and is of a non-rejection class from a cache; when the number of the first transaction tasks is smaller than the preset number, the master node may determine the first task grabbing number based on the preset number and the number of the first transaction tasks, for example, the master node may perform a difference operation on the preset number and the number of the first transaction tasks to obtain a corresponding difference result, and determine the first task grabbing number based on the difference result. Further, the master node may grasp the second transaction task from the transaction pool according to the determined order of the first task grasping number and the contract priority from high to low, where the contract priority is a priority corresponding to a contract of each transaction task in the transaction pool.

For example, assuming that the preset number of transaction tasks in the block to be consensus in the blockchain 1 is 10, when the node 1 in the blockchain 1 goes out of the block and starts a new round of consensus, the node 1, namely the master node, can acquire 5 first transaction tasks which are not consensus and are of non-rejection type from the local cache, because 5 is less than 10, namely when the number 5 of the first transaction tasks is less than the preset number 10, the master node can perform difference operation on the preset number 10 and the number 5 of the first transaction tasks, the obtained difference result is 10-5=5, and the master node can determine that the task grabbing number is 5 based on the difference result 5; further, the master node may grab the second transaction task from the transaction pool in the determined order of the task grabbing number 5 and the contract priority from high to low, for example, the master node may grab the first 5 transaction tasks ordered from high to low in contract priority from the transaction pool, and take the grabbed 5 transaction tasks as the second transaction task. Therefore, the transaction tasks which are executed in the previous round are preferentially acquired from the cache, and the transaction tasks do not need to be executed in the round of consensus, so that the execution efficiency of the transaction tasks can be effectively improved.

In one embodiment, the step of crawling the second transaction task from the pool according to the first crawling quantity and the contract priority comprises:

acquiring a transaction task set from a transaction pool according to the first grabbing quantity;

sequentially acquiring contracts of all transaction tasks in a transaction task set;

When contracts of the transaction tasks belong to a priority contract group, the transaction tasks are removed from the transaction task set, and the removed transaction tasks are added into a random function transaction set;

And when the contract of the transaction task does not belong to the priority contract group, the transaction task is taken as a second transaction task.

The transaction task set is a set for storing transaction tasks captured according to the first capturing amount, for example, the first capturing amount is 5, and the transaction task set acquired according to the first capturing amount includes 5 transaction tasks.

The contract of the transaction task refers to the contract corresponding to each transaction task, and one contract can correspond to a plurality of transaction tasks in the application, and one transaction task can only correspond to one contract under the normal condition.

The contract in the application can be referred to as an intelligent contract, the intelligent contract (Smart Contract) is not intelligent per se, and is a piece of code capable of realizing user business logic, and the code can be executed through a node virtual machine of a blockchain. For a blockchain system, it requires that the states of all nodes must be consistent, that is, it is a deterministic state machine, only so that the blockchain system can reach consensus, otherwise the entire blockchain cannot function properly.

The priority contract group refers to a contract group with a preset certain range of priority, for example, a priority contract group set is preset, the priority contract group set includes a plurality of contract groups, each contract group includes a plurality of contracts, each contract has a corresponding priority, that is, each contract group includes a contract with a certain range of priority. For example, the priority contract group in the present application may be a low priority contract group, that is, a low priority contract group set is maintained in the blockchain system, where the low priority contract group set includes contract groups with different priorities, as shown in fig. 4, which is a schematic diagram of the low priority contract group set maintained in the blockchain system, where the low priority contract group set includes a plurality of low priority contract groups such as a low priority contract group 1 and a low priority contract group 2.

The random function transaction set is used for storing a set of random function transaction tasks, the random function transaction is that different nodes can generate different results when the transaction tasks are executed, so that the execution results of the transaction tasks are uncertain, for example, a transaction task A is a random function transaction, and the node 1 executes the transaction task A to obtain an execution result A; the node 2 executes the transaction task a, and the execution result obtained is B, that is, the execution result obtained by each node executing the transaction task a is uncertain.

Specifically, when a master node in the node cluster goes out of a block and starts a new round of consensus, the master node can acquire a first transaction task which does not reach consensus and is of a non-rejection class from a cache; when the number of the first transaction tasks is smaller than the preset number, the master node can acquire a transaction task set from the transaction pool according to the determined first grabbing number, and sequentially acquire contracts of all the transaction tasks in the transaction task set; when contracts of the transaction tasks belong to a low-priority contract group maintained in the blockchain system, the transaction tasks are removed from the transaction task set, and the removed transaction tasks are added into a random function transaction set; when the contract of the trading task does not belong to the low priority contract group maintained in the blockchain system, the trading task is regarded as a second trading task.

For example, assuming that the preset number is 8, when the node 1 in the node cluster goes out of the block and starts a new round of consensus, the node 1, i.e. the master node, can obtain 5 first transaction tasks which do not reach consensus and are of non-rejection type from the cache; when the number 5 of the first transaction tasks is smaller than the preset number 8, the node 1 can determine that the grabbing number of the second transaction tasks needing to be grabbed from the transaction pool is 3, and the node 1 acquires a transaction task set from the transaction pool according to the determined grabbing number 3, namely the transaction task set comprises 3 transaction tasks which are respectively a transaction task A, a transaction task B and a transaction task C; further, the node 1 may sequentially obtain contracts of each transaction task in the transaction task set, and determine whether the contracts of each transaction task belong to a low-priority contract group maintained in the blockchain system; when the node 1 determines that the contract of the transaction task A belongs to a low-priority contract group maintained in the blockchain system, the node 1 can reject the transaction task A from the transaction task set and add the rejected transaction task A into the random function transaction set RTs; when node 1 determines that the contracts for transaction task B and transaction task C do not belong to the low priority contract group maintained in the blockchain system, then node 1 may take transaction task B and transaction task C as the second transaction tasks for the final output. Therefore, the success rate of the next proposal to agree is improved through the optimization of the fetch transaction, meanwhile, the contract of the transaction is degraded, so that the demand of the fetch transaction is met on one hand, the result of rejecting more transactions at one time is achieved on the other hand, and the rejection efficiency of the transaction can be effectively improved.

In one embodiment, the method further comprises:

adding the second transaction task to the target output transaction set;

If the number of the transaction tasks in the target output transaction set meets the preset threshold condition, taking the random function transaction set as the target output transaction set so as to eliminate the transaction tasks in the target output transaction set;

if the number of the transaction tasks in the target output transaction set does not meet the preset threshold condition, determining a second grabbing number based on the first grabbing number and the number of the transaction tasks in the target output transaction set;

and acquiring a transaction task set from the transaction pool according to the second grabbing quantity.

The target output transaction set refers to a final output second transaction task set, namely, all transaction tasks in the target output transaction set are taken as final packaged second transaction tasks.

The threshold condition refers to a threshold condition of the number of transaction tasks, for example, the threshold condition of the number of transaction tasks may be set as: equal to 0, i.e. the threshold condition is met when the number of transaction tasks is equal to 0.

Specifically, when a master node in the node cluster goes out of a block and starts a new round of consensus, the master node can acquire a first transaction task which does not reach consensus and is of a non-rejection class from a cache; when the number of the first transaction tasks is smaller than the preset number, the master node can acquire a transaction task set from the transaction pool according to the determined first grabbing number, and sequentially acquire contracts of all the transaction tasks in the transaction task set; when contracts of the transaction tasks belong to a low-priority contract group maintained in the blockchain system, the transaction tasks are removed from the transaction task set, and the removed transaction tasks are added into a random function transaction set; when the contract of the transaction task does not belong to the low-priority contract group maintained in the blockchain system, taking the transaction task as a second transaction task, and adding the second transaction task into the target output transaction set; after traversing each transaction task in the transaction task set, the master node can detect whether the number of transaction tasks in the target output transaction set reaches the determined first grabbing number, if so, the master node indicates that the number of second transaction tasks in the target output transaction set meets the first grabbing number, and the process is ended; if the number of the transaction tasks in the target output transaction set does not reach the determined first grabbing number, namely, if the number of the transaction tasks in the target output transaction set is smaller than the determined first grabbing number, the master node can further judge whether the number of the transaction tasks in the target output transaction set meets a preset threshold condition, and if the number of the transaction tasks in the target output transaction set meets the preset threshold condition, the master node takes the random function type transaction set as the target output transaction set so as to eliminate the transaction tasks in the target output transaction set; if the number of the transaction tasks in the target output transaction set does not meet the preset threshold condition, the master node may determine a second grabbing number based on the first grabbing number and the number of the transaction tasks in the target output transaction set, acquire the transaction task set from the transaction pool according to the second grabbing number, and execute the above process of screening the finally output second transaction tasks from the transaction task set until the number of the finally obtained second transaction tasks reaches the determined first grabbing number, and end the process.

In addition, in some cases, if the number of the transaction tasks in the target output transaction set does not meet the preset threshold condition, the master node may also directly end the flow.

For example, assuming that the preset number is 8, when the node 1 in the node cluster goes out of the block and starts a new round of consensus, the node 1, i.e. the master node, can obtain 5 first transaction tasks which do not reach consensus and are of non-rejection type from the cache; when the number 5 of the first transaction tasks is smaller than the preset number 8, the node 1 can determine that the grabbing number of the second transaction tasks needing to be grabbed from the transaction pool is 3, and the node 1 acquires a transaction task set from the transaction pool according to the determined grabbing number 3, namely the transaction task set comprises 3 transaction tasks which are respectively a transaction task A, a transaction task B and a transaction task C; further, the node 1 may sequentially obtain contracts of each transaction task in the transaction task set, and determine whether the contracts of each transaction task belong to a low-priority contract group maintained in the blockchain system; when the node 1 determines that the contract of the transaction task A belongs to a low-priority contract group maintained in the blockchain system, the node 1 can reject the transaction task A from the transaction task set and add the rejected transaction task A into the random function transaction set RTs; when the node 1 determines that the contracts of the transaction task B and the transaction task C do not belong to the low-priority contract group maintained in the blockchain system, the node 1 may take the transaction task B and the transaction task C as a second transaction task to be finally output, and add the second transaction task, i.e., the transaction task B and the transaction task C, to the target output transaction set ATs; after node 1 traverses each transaction task in the transaction task set, node 1 may determine whether the number of transaction tasks len (ATs) =2 in the target output transaction set ATs reaches the determined first grabbing number 3, and if 2 is smaller than 3, that is, if node 1 determines that the number of transaction tasks len (ATs) =2 in the target output transaction set does not reach the determined first grabbing number 3, node 1 may further determine whether the number of transaction tasks len (ATs) =2 in the target output transaction set satisfies a preset threshold condition, where the preset threshold condition is assumed to be: equal to 0, since 2 is greater than 0, that is, node 1 determines that the number of transaction tasks in the target output transaction set len (ATs) =2 does not satisfy the threshold condition equal to 0, node 1 may determine that the second grasping number is 3-len (ATs) =3-2=1 based on the first grasping number 3 and the number of transaction tasks in the target output transaction set len (ATs) =2, and re-acquire the transaction task set from the transaction pool according to the second grasping number 1, and repeatedly execute the above-described process of screening out the finally output second transaction tasks from the transaction task set until the finally obtained number of second transaction tasks reaches the determined first grasping number 3, and end the process.

Or when the node 1 determines that the number len (ATs) =2 of the transaction tasks in the target output transaction set does not meet the preset threshold condition, the node 1 may directly end the flow.

In addition, after the node 1 traverses each transaction task in the transaction task set, assuming that the node 1 determines that the number of transaction tasks len (ATs) =0 in the target output transaction set ATs does not reach the determined first grabbing number 3, the node 1 may further determine whether the number of transaction tasks len (ATs) =0 in the target output transaction set meets a preset threshold condition, and assuming that the preset threshold condition is: equal to 0, since len (ATs) =0, i.e. node 1 determines that the number of transaction tasks len (ATs) =0 in the target output transaction set meets the threshold condition equal to 0, node 1 may use the random function class transaction set RTs as the target output transaction set ATs, so that all the random function class transaction tasks in the target output transaction set ATs may be rejected at once in the present round of consensus. Therefore, the success rate of the next proposal agreement can be effectively improved through the optimization of the fetch transaction, meanwhile, the transaction contract is degraded, so that the demand of the fetch transaction is met, the result of eliminating more transactions at one time is achieved, and the elimination efficiency of the transactions can be effectively improved.

In one embodiment, a first node includes a first slave node and at least one second slave node; broadcasting a proposal message to a first node in the blockchain to cause the first node to consensus the block to be consensus based on the first transaction task and the second transaction task, comprising:

Broadcasting the proposal message to a first slave node and a second slave node in the blockchain, and when the first slave node receives the proposal message, verifying the legitimacy of a first transaction task and a second transaction task through the first slave node to obtain a verification result;

when the verification result shows that at least one transaction task in the first transaction task or the second transaction task is illegal, generating a first voting message which is not in favor of the block to be agreed through the first slave node, receiving second voting messages broadcast by each second slave node, and determining that the block to be agreed is agreed when the number of the voting messages in favor of the block to be agreed in the first voting message and each second voting message meets a preset condition.

Wherein the first slave node and the second slave node are used for distinguishing different slave nodes, for example, the first slave node may be node 1 in the blockchain, and the second slave node may be other slave nodes except for node 1 in the blockchain 1.

Validity verification refers to verifying the validity of all transaction tasks in a block to be identified carried by a proposal message, for example, when verifying whether the transaction tasks are legal or not in the application: the method of comparing the execution results can be adopted, for example, the execution result a of the current slave node on the transaction task 1 can be compared with the execution result B of the master node executing the transaction task 1 carried in the proposal, if the two execution results are consistent, namely when the execution result a and the execution result B are consistent, the current slave node can determine that the transaction task 1 is a legal transaction task, and the verification result is used for indicating that the transaction task 1 is a legal transaction task; if the two execution results are inconsistent, that is, when the execution result a and the execution result B are inconsistent, the current slave node can determine that the transaction task 1 is an illegal transaction task, and the verification result is used for indicating that the transaction task 1 is an illegal transaction task. That is, the validity of the transaction task is determined by whether the execution results of the transaction task are consistent or not.

The verification result is a result of verifying the legitimacy of all transaction tasks in the block to be identified carried by the proposal message, and the verification result in the application is a verification result for indicating whether the transaction tasks are legal or not. For example, the authentication result in the present application may include two types of authentication results: one is to verify that the transaction task is legal, and the verification result is used for indicating that the transaction task is legal; and the other is to verify that the transaction task is illegal, and the verification result is used for indicating that the transaction task is illegal.

The first voting message and the second voting message are used for distinguishing voting messages of different nodes, for example, the first voting message may be a voting message corresponding to a current node, namely, a node 1, in the blockchain, and the second voting message may be a voting message corresponding to other nodes except the node 1 in the blockchain 1.

The preset condition refers to a preset condition that the blocks reach the consensus, for example, the preset condition can be set to 2f+1, f refers to the number of the highest tolerant malignant nodes in the environment, and is a 3f+1 model in the Bayesian consensus, for example, 4 nodes in the whole environment, f=1 nodes are permitted to be the malignant nodes, and 2f+1 is the number of correct nodes, namely, when the number of voting messages in the voting message agreeing to the consensus of the blocks to be consensus satisfies the number 2f+1, the block to be consensus can reach the consensus.

Specifically, when a master node in a node cluster goes out of a block and starts a new round of consensus, if the number of first transaction tasks acquired by the master node from a cache is smaller than a preset number, after the master node grabs a second transaction task from a transaction pool based on the preset number and the number of the first transaction tasks, the master node can encapsulate the first transaction task and the second transaction task into proposal messages of a block to be consensus, and broadcast the proposal messages to a first slave node and a second slave node in a block chain, and when the first slave node receives the proposal messages, the first slave node can perform validity verification on the first transaction task and the second transaction task in the proposal messages to obtain verification results; when the verification result indicates that at least one transaction task in the first transaction task or the second transaction task is illegal, the first slave node can generate a first voting message which does not agree with the block to be agreed; meanwhile, the first slave node can also receive second voting messages broadcast by other nodes, namely each second slave node, when each node in the node cluster traverses all voting messages, and when the number of voting messages which agree with the block to be agreed in the voting messages is determined to meet a preset condition, the block to be agreed is determined to agree, namely when the number of voting messages which agree with the block to be agreed in the first voting message and each second voting message meets the preset condition, the block to be agreed can agree, namely the block to be agreed can be added into a block chain. In addition, if the number of voting messages in the first voting message and the second voting message, which agree with the block to be agreed, does not meet the preset condition, the block to be agreed cannot agree, i.e. the block to be agreed cannot be added into the blockchain.

For example, assuming that the blockchain 1 includes 4 nodes, namely, node 1, node 2, node 3 and node 4, after a newly created blockchain 1 is started, each node in the blockchain 1 can determine whether the block-out condition is met based on the self-maintained block height value; when the node 1 in the node cluster of the block chain 1 goes out of the block, and a new round of consensus is started, the node 1 is the master node. If the number of the first transaction tasks acquired by the node 1 from the cache is smaller than the preset number, after the node 1 captures a second transaction task from the transaction pool based on the preset number and the number of the first transaction tasks, the node 1 can package the first transaction task and the second transaction task into a proposal message 2 of a block 2 to be agreed, and broadcast the proposal message 2 to nodes 2,3 and 4 in a block chain, and when the proposal message 2 is received by the node 2, the node 2 can perform validity verification on the first transaction task and the second transaction task in the proposal message 2 to obtain a verification result; when the verification result indicates that at least one transaction task of the first transaction task or the second transaction task is illegal, the node 2 may generate a first voting message which does not agree with the block 2 to be agreed; meanwhile, the node 2 can also receive second voting messages broadcast by other nodes, namely the node 3 and the node 4, and when all the voting messages are traversed by all the nodes in the node cluster, determining that the number of the voting messages which agree with the block to be agreed in the voting messages meets the preset condition, the block to be agreed is agreed. For example, assuming that the preset condition is 2f+1, f refers to the number of the most tolerant bad nodes in the present environment, the model is 3f+1 in the bayer and b/c consensus, and there are 4 nodes in the whole environment of the blockchain 1, f=1 nodes are allowed to be bad nodes, and no more 2f+1 is the number of correct nodes, that is, when the number of voting messages in the first voting message and each second voting message, which agree on the block to be agreed, satisfies 2f+1=3, the block to be agreed may agree, that is, the block to be agreed may be added to the blockchain. In addition, if the number of voting messages in the first voting message and each second voting message, which agree with the block to be agreed, does not satisfy 2f+1=3, the block to be agreed cannot agree, i.e. the block to be agreed cannot be added into the block chain. Therefore, through the optimization and the cache utilization of the fetch transaction, the execution time of the transaction can be effectively reduced, the consensus efficiency is improved, and the resource consumption is reduced.

In one embodiment, the method further comprises:

selecting a disapproved voting message from the first voting message and each second voting message; the disapproved voting message is a voting message disapproved for consensus of the consensus block;

selecting a transaction task which meets the rejection condition from at least one transaction task corresponding to the disapproved voting message;

and adjusting the contract priority corresponding to the transaction task meeting the rejection condition.

The rejection condition is a condition set for judging whether the transaction task can be rejected, for example, the blockchain system in the application mainly aims at BFT (Bytalin) type consensus, in which a concept of a disuse node exists, the BFT model is 3f+1 model, wherein f is the maximum permitted number of disuse nodes, for example, 4 nodes in the blockchain system are allowed, 1 disuse node is allowed at maximum, and the rejection condition can be set as follows: f+1, i.e. the number of disapproved voting messages satisfying f+1, indicates that the transaction task meets the rejection condition may be deleted, wherein f+1>f, which indicates that at least one honest node chooses to reject the transaction task.

Specifically, a master node in a node cluster can encapsulate a first transaction task and a second transaction task into proposal messages of a block to be identified, and broadcast the proposal messages to a first slave node and a second slave node in a block chain, when the first slave node receives the proposal messages, the first slave node can perform validity verification on the first transaction task and the second transaction task in the proposal messages, and a verification result is obtained; when the verification result indicates that at least one transaction task in the first transaction task or the second transaction task is illegal, the first slave node can generate a first voting message which does not agree with the block to be agreed; meanwhile, the first slave node may also receive the second voting messages broadcasted by other nodes, that is, each second slave node, and the first slave node may select the disapproved voting message from the first voting message and each second voting message, and because the disapproved voting message includes a transaction task that is verified to be illegal by the node, the first slave node may select a transaction task that meets the rejection condition from at least one transaction task that is illegal and corresponds to the disapproved voting message, and adjust a contract priority corresponding to the transaction task that meets the rejection condition, for example, the first slave node may select the transaction task that meets the rejection condition from three transaction tasks that are illegal and correspond to the disapproved voting message as a transaction task a, and downgrade a contract priority corresponding to the transaction task a that meets the rejection condition, for example, the first slave node may reduce the contract priority corresponding to the transaction task a by one level.

It can be understood that after each node in the blockchain receives the voting message broadcast by other nodes, the above processing steps can be executed, that is, each node can select a transaction task meeting the rejection condition from at least one illegal transaction task corresponding to the voting message, and adjust the contract priority corresponding to the transaction task meeting the rejection condition.

For example, assuming that the blockchain 1 includes 4 nodes, namely, node 1, node 2, node 3 and node 4, after a newly created blockchain 1 is started, each node in the blockchain 1 can determine whether the block-out condition is met based on the self-maintained block height value; when the node 1 in the node cluster of the block chain 1 goes out of the block, and a new round of consensus is started, the node 1 is the master node. The node 1 can package the first transaction task and the second transaction task into a proposal message 2 of the block 2 to be recognized, and broadcast the proposal message 2 to the node 2, the node 3 and the node 4 in the block chain 1, when the proposal message 2 is received by the node 2, the node 2 can perform validity verification on the first transaction task and the second transaction task in the proposal message 2, so as to obtain a verification result; when the verification result indicates that at least one transaction task of the first transaction task or the second transaction task is illegal, the node 2 may generate a first voting message which does not agree with the block 2 to be agreed; meanwhile, the node 2 may also receive the second voting message broadcast by other nodes, namely, the node 3 and the node 4, and if the second voting message broadcast by the node 3 is the disapproved voting message 3 and the second voting message broadcast by the node 4 is the approved voting message 4, the node 2 may select the disapproved voting message 2 and the disapproved voting message 3 from the first voting message and each second voting message, and since the disapproved voting message 2 generated by the node 2 includes the transaction task a verified as being illegal by the node 2 and the disapproved voting message 3 generated by the node 3 also includes the transaction task a verified as being illegal by the node 3, the node 2 may determine whether the transaction task a meets the rejection condition in at least one of the disapproved transaction tasks a corresponding to the disapproved voting message, and if the rejection condition is f+1, f represents the maximum allowable number of the disapproved nodes, and the maximum allowable 1 nodes are included in the block chain system, and the rejection condition is f+1=1=2: the transaction tasks are contained in the 2 disapproved voting messages, and can be removed; because the disapproved voting message 2 and the disapproved voting message 3 both include the transaction task a which is verified as illegal by the node, that is, the node 2 judges that the transaction task a meets the rejection condition f+1, the node 2 can downgrade the contract priority of the contract C corresponding to the transaction task a, for example, the node 2 can adjust the contract priority of the contract C corresponding to the transaction task a from 11 to 12, and the priority of 11 is higher than 12. Therefore, the transaction contract is degraded, so that the demand of the fetch transaction is met, and the result of removing more transactions at one time is achieved, and the removing efficiency of the transactions can be effectively improved.

In one embodiment, the step of verifying validity of the first transaction task and the second transaction task to obtain a verification result includes:

When verifying the proposal message, traversing and executing each transaction task in the proposal message to obtain a verification result for indicating whether each transaction task is legal or not;

the method further comprises the steps of: and storing the transaction task which is indicated to be legal in the verification result in a cache.

Specifically, when the first slave node receives the proposal message broadcast by the master node, the first slave node can perform validity verification on the first transaction task and the second transaction task in the proposal message to obtain a verification result. When the first slave node verifies the proposal message, the first slave node can traverse and execute each transaction task in the proposal message to obtain a verification result for indicating whether each transaction task is legal or not, for example, the first slave node can compare the execution result of each transaction task with the execution result in the proposal message, and if the comparison results are consistent, the verification result for indicating that the transaction task is legal can be obtained; if the comparison results are inconsistent, a verification result for indicating that the transaction task is illegal is obtained, and the first slave node can store the verification result, which indicates that the transaction task is legal and the execution result of the transaction task is legal, in the local cache.

For example, assuming that the proposal message 1 includes 2 transaction tasks, namely a transaction task a and a transaction task B, respectively, when each slave node in the node cluster receives the proposal message 1 broadcasted by the master node, each slave node can perform validity verification on the first transaction task and the second transaction task in the proposal message 1, and a verification result is obtained. The following description will take as an example authentication of the proposal message 1 by the slave node 1. When the slave node 1 verifies the proposal message 1, the slave node 1 can traverse and execute the transaction task A and the transaction task B in the proposal message to obtain a verification result for indicating whether each transaction task is legal or not, and if the comparison result obtained by comparing the execution result of the transaction task A with the execution result of the transaction task A in the proposal message 1 by the slave node 1 is consistent, the slave node 1 can obtain the verification result for indicating that the transaction task A is legal; the slave node 1 compares the execution result of the transaction task B with the execution result of the transaction task B in the proposal message 1, and if the obtained comparison result is inconsistent, the slave node 1 can obtain a verification result for indicating that the transaction task B is illegal; further, the slave node 1 may store the legal transaction task a and the execution result of the transaction task a in the verification result in the local cache, so that in the next round of consensus, the transaction task a may not need to be executed again, and the node may directly obtain the execution result of the transaction task a from the cache, so as to effectively improve the consensus efficiency.

In one embodiment, the step of traversing each transaction task in the proposal message to obtain a verification result for indicating whether each transaction task is legal, includes:

sequentially acquiring each transaction task and a corresponding execution result in the proposal message;

When the execution results corresponding to the sequentially acquired transaction tasks exist in the cache and the execution results in the cache are consistent with the execution results in the proposal message, a verification result for indicating that the sequentially acquired transaction tasks are legal is obtained;

When the execution results of the transaction tasks acquired in sequence do not exist in the cache, executing the transaction tasks acquired in sequence to obtain corresponding execution results; and when the obtained execution result is consistent with the execution result in the proposal message, obtaining a verification result for indicating that the transaction tasks acquired in sequence are legal.

Specifically, when the first slave node verifies the proposal message, the first slave node can sequentially acquire each transaction task and a corresponding execution result in the proposal message; when the first slave node determines that the local cache has an execution result corresponding to the sequentially acquired transaction tasks and the execution result in the cache is consistent with the execution result in the proposal message, the first slave node can obtain a verification result for indicating that the sequentially acquired transaction tasks are legal; when the first slave node determines that the execution result of the transaction task which is acquired in sequence does not exist in the cache, the first slave node executes the transaction task which is acquired in sequence to obtain a corresponding execution result; when the first slave node determines that the obtained execution result is consistent with the execution result in the proposal message, the first slave node obtains a verification result for indicating that the sequentially acquired transaction tasks are legal.

In the embodiment of the application, when each slave node in the node cluster verifies the proposal message, the slave node can firstly judge whether the execution result corresponding to the transaction task exists in the local cache, if so, the slave node can compare the execution result corresponding to the transaction task stored in the local cache with the execution result corresponding to the transaction task in the proposal message, and if the execution result corresponding to the transaction task stored in the local cache is consistent with the execution result corresponding to the transaction task in the proposal message, the slave node can determine that the transaction task is a legal transaction task, namely, the slave node can obtain the verification result for indicating that the transaction task is legal.

For example, assuming that the proposal message 1 includes 2 transaction tasks, namely a transaction task a and a transaction task B, when the slave node 1 verifies the proposal message 1, the slave node 1 can sequentially acquire each transaction task and a corresponding execution result in the proposal message; when the slave node 1 determines that the execution result A corresponding to the transaction task A exists in the local cache and the execution result A of the transaction task A in the cache is consistent with the execution result A of the transaction task A in the proposal message, the slave node 1 can obtain a verification result for indicating that the transaction task A is legal; when the slave node 1 determines that the execution result corresponding to the transaction task B does not exist in the local cache, the slave node 1 can execute the transaction task B to obtain the execution result B corresponding to the transaction task B; when the slave node 1 determines that the execution result B of the obtained transaction task B is identical to the execution result B of the transaction task B in the proposal message, a verification result indicating that the transaction task B is legal is obtained from the slave node 1. Therefore, through the optimization and the cache utilization of the fetch transaction, the execution time of the transaction can be effectively reduced, the consensus efficiency is improved, and the resource consumption is reduced.

In one embodiment, the method further comprises:

When the execution results of the transaction tasks acquired in sequence are in the cache and are inconsistent with the execution results in the proposal message, a verification result for indicating that the transaction tasks acquired in sequence are illegal is obtained.

Specifically, when the first slave node verifies the proposal message, the first slave node can sequentially acquire each transaction task and a corresponding execution result in the proposal message; when the execution results of the transaction tasks acquired in sequence exist in the cache and are inconsistent with the execution results in the proposal message, the first slave node obtains a verification result for indicating that the transaction tasks acquired in sequence are illegal.

Or when the first slave node verifies the proposal message, the first slave node can sequentially acquire each transaction task and a corresponding execution result in the proposal message, and when the first slave node determines that the execution result of the transaction task which is sequentially acquired does not exist in the cache, the first slave node executes the transaction task which is sequentially acquired to obtain the corresponding execution result; when the first slave node determines that the obtained execution result is inconsistent with the execution result in the proposal message, the first slave node obtains a verification result for indicating that the sequentially acquired transaction tasks are illegal.

In the embodiment of the application, when each slave node in the node cluster verifies the proposal message, the slave node can firstly judge whether the execution result corresponding to the transaction task exists in the local cache, if so, the slave node can compare the execution result corresponding to the transaction task stored in the local cache with the execution result corresponding to the transaction task in the proposal message, and if not, the slave node can determine that the transaction task is an illegal transaction task, namely, the slave node can obtain a verification result for indicating that the transaction task is illegal.

For example, assuming that the proposal message 1 includes 2 transaction tasks, namely a transaction task a and a transaction task B, when the slave node 1 verifies the proposal message 1, the slave node 1 can sequentially acquire each transaction task and a corresponding execution result in the proposal message; when the slave node 1 determines that the execution result A corresponding to the transaction task A exists in the local cache and the execution result A of the transaction task A in the cache is inconsistent with the execution result A1 of the transaction task A in the proposal message, the slave node 1 can obtain a verification result for indicating that the transaction task A is illegal; when the slave node 1 determines that the execution result corresponding to the transaction task B does not exist in the local cache, the slave node 1 can execute the transaction task B to obtain the execution result B corresponding to the transaction task B; when the slave node 1 determines that the obtained execution result B of the transaction task B is inconsistent with the execution result B1 of the transaction task B in the proposal message, a verification result for indicating that the transaction task B is illegal is obtained from the node 1. Therefore, through the optimization and the cache utilization of the fetch transaction, the execution time of the transaction can be effectively reduced, the consensus efficiency is improved, and the resource consumption is reduced.

In one embodiment, the step of adjusting the contract priority corresponding to the transaction task meeting the rejection condition includes:

saving the transaction tasks meeting the rejection conditions in a transaction task set to be rejected;

acquiring contracts corresponding to each transaction task in a transaction set to be removed;

When the contract group contains the contract, the contract priority corresponding to the contract is obtained, and degradation treatment is carried out on the contract priority.

The transaction task set to be removed is a set for storing transaction tasks to be removed, for example, there are 4 nodes in the blockchain system, and 1 malignant node is allowed at maximum, that is, f=1, and the removal condition may be set as follows: f+1=2, if at least 2 disapproved voting messages include a transaction task a, which indicates that the transaction task a meets the rejection condition and can be deleted, and indicates that at least one honest node selects to reject the transaction task a, the transaction task a can be stored in the transaction task set to be rejected.

The degradation processing refers to performing degradation processing on the level of the contract priority corresponding to the contract, for example, degrading the contract priority 11 corresponding to the contract C to 12, wherein the priority of 11 is higher than 12.

Specifically, when the first slave node receives the proposal message broadcast by the master node, the first slave node can perform validity verification on the first transaction task and the second transaction task in the proposal message to obtain a verification result; when the verification result indicates that at least one transaction task in the first transaction task or the second transaction task is illegal, the first slave node can generate a first voting message which does not agree with the block to be agreed; meanwhile, the first slave node can also receive second voting messages broadcast by other nodes, namely each second slave node, and the first slave node can select a disapproved voting message from the first voting message and each second voting message, and the disapproved voting message comprises a transaction task which is verified to be illegal by the node, so that the first slave node can select a transaction task which meets the rejection condition from at least one illegal transaction task corresponding to the disapproved voting message, and store the transaction task which meets the rejection condition in a transaction task set to be rejected; further, the first slave node may acquire contracts corresponding to each transaction task in the transaction set to be removed; when the first slave node determines that the low-priority contract group maintained in the blockchain system contains the contract, acquiring the contract priority corresponding to the contract, and carrying out degradation processing on the contract priority.

For example, assuming that the blockchain 1 includes 4 nodes, namely, node 1, node 2, node 3 and node 4, when the node 2 receives a proposal message 2 broadcasted by a master node, namely, node 1, the node 2 can perform validity verification on a first transaction task and a second transaction task in the proposal message 2, so as to obtain a verification result; when the verification result indicates that at least one transaction task of the first transaction task or the second transaction task is illegal, the node 2 may generate a first voting message which does not agree with the block 2 to be agreed; meanwhile, the node 2 may also receive the second voting message broadcast by other nodes, namely, the node 3 and the node 4, and if the second voting message broadcast by the node 3 is a disapproved voting message 3, and the second voting message broadcast by the node 4 is a disapproved voting message 4, then the node 2 may select the disapproved voting message 2 and the disapproved voting message 3 from the first voting message and each second voting message, and since the disapproved voting message 2 generated by the node 2 includes a transaction task a and a transaction task B which are verified to be illegal by the node 2, and the disapproved voting message 3 generated by the node 3 also includes a transaction task a and a transaction task B which are verified to be illegal by the node 3, the node 2 may determine whether the transaction task a and the transaction task B meet the rejection condition, and if the rejection condition is f+1, f represents the maximum allowable number of the disapproved nodes, and if the maximum allowable number of the block system is 4 nodes, and if the rejection condition is 1+1=1=1: the transaction tasks are contained in the 2 disapproved voting messages, and can be removed; because the disapproved voting message 2 and the disapproved voting message 3 both contain the transaction task A and the transaction task B which are verified to be illegal by the node, namely the node 2 judges that the transaction task A and the transaction task B meet the rejection condition f+1, the node 2 can store the transaction task A and the transaction task B in the transaction task set R to be rejected, and further, the node 2 acquires contracts corresponding to all the transaction tasks in the transaction set R to be rejected; when the node 2 determines that the low-priority contract group includes the contract a corresponding to the transaction task a, the node 2 may obtain the contract priority corresponding to the contract a as 11, and perform the degradation processing on the contract priority 11 of the contract a, for example, the node 2 may perform the degradation processing on the contract priority 11 of the contract a, to obtain the contract priority of the contract a after the degradation processing as 12, where the priority of 11 is higher than 12. Therefore, the transaction contract is degraded, so that the demand of the fetch transaction is met, and the result of removing more transactions at one time is achieved, and the removing efficiency of the transactions can be effectively improved.

In one embodiment, the method further comprises:

When the contract group does not contain the contract, inquiring the contract priority corresponding to the contract from the contract index set;

and when the contract priority of the query is the target priority, carrying out degradation treatment on the contract priority of the query.

The contract index set refers to a contract index map, that is, a data structure of the contract index set stores data in the form of key value pairs, for example, an identifier of a contract, that is, a contract name is used as a key, and a priority corresponding to the contract is used as a value and written into the contract index set. It is to be appreciated that the data in the priority contract group in the present application may also be stored in the contract index set.

Specifically, the first slave node may select a vote disapproved message from the first vote message and each second vote message, and since the vote disapproved message includes a transaction task verified as being illegal by the node, the first slave node may select a transaction task meeting a rejection condition from at least one illegal transaction task corresponding to the vote disapproved message, and save the transaction task meeting the rejection condition in a set of transaction tasks to be rejected; further, the first slave node may acquire contracts corresponding to each transaction task in the transaction set to be removed; when the first slave node determines that the low-priority contract group maintained in the blockchain system does not contain the contract, the first slave node can inquire the contract priority corresponding to the contract from the contract index set; when the first slave node inquires the contract priority of the contract, the inquired contract priority is subjected to degradation processing.

For example, assuming that 4 nodes are respectively included in the blockchain 1 as node 1, node 2, node 3 and node 4, assuming that the first voting information generated by node 2 is an unlawful voting message 2, the second voting information broadcast by node 3 is an unlawful voting message 3, and the second voting information broadcast by node 4 is an unlawful voting message 4, then node 2 can select an unlawful voting message 2 and an unlawful voting message 3 from the first voting message and each second voting message, since the unlawful voting message 2 generated by node 2 includes a transaction task A and a transaction task B which are verified as unlawful by node 2, and the unlawful voting message 3 also includes a transaction task A and a transaction task B which are verified as unlawful by node 3, the node 2 can judge whether the transaction task A and the transaction task B meet the rejection condition in the unlawful transaction task A and the transaction task B corresponding to the unlawful voting message, and the transaction task B can be rejected in a further set of the node 2, and the transaction task B can be rejected as the unlawful voting message 2 and the transaction task B corresponding to be further judged to be accepted by node 2; when the node 2 determines that the low-priority contract group maintained in the blockchain 1 does not include the contract a corresponding to the transaction task a, the node 2 may query the contract index set Cs for the contract priority corresponding to the contract a, and when the node 2 queries that the contract priority corresponding to the contract a is 11, the node 2 may perform degradation processing on the contract priority 11 of the contract a, for example, the node 2 may perform degradation processing on the contract priority 11 of the contract a, to obtain the contract priority 12 of the contract a after the degradation processing, where the priority of 11 is higher than 12. Therefore, the transaction contract is degraded, so that the demand of the fetch transaction is met, and the result of removing more transactions at one time is achieved, and the removing efficiency of the transactions can be effectively improved.

In one embodiment, the method further comprises:

When the contract is not included in the priority contract group and does not exist in the contract index set, creating a contract priority object corresponding to the contract;

Assigning the contract priority object to obtain contract priority;

and determining the contract group to which the obtained contract priority belongs.

The contract priority object refers to creating an internal object of the program, that is, creating a data structure suitable for processing in the program, and the contract priority object in the present application may be a contract priority object created for a certain contract and corresponding to the contract.

Specifically, the first slave node may select a vote disapproved message from the first vote message and each second vote message, and since the vote disapproved message includes a transaction task verified as being illegal by the node, the first slave node may select a transaction task meeting a rejection condition from at least one illegal transaction task corresponding to the vote disapproved message, and save the transaction task meeting the rejection condition in a set of transaction tasks to be rejected; further, the first slave node may acquire a contract corresponding to each transaction task in the transaction set to be removed, determine whether the contract is included in the low priority contract group, if the first slave node determines that the contract is not included in the low priority contract group, the first slave node may further determine whether the contract is included in the low contract index set, if the first slave node determines that the contract is not included in the contract index set, the first slave node may create a contract priority object corresponding to the contract, and assign a value to the contract priority object to obtain a contract priority; after the first slave node obtains the contract priority corresponding to the contract, the first slave node may determine a contract group to which the obtained contract priority belongs, and add the contract to the contract group to which the obtained contract priority belongs.

For example, assuming that the node 2 determines that the transaction task a and the transaction task B meet the rejection condition f+1, the node 2 may store the transaction task a and the transaction task B in the transaction task set R to be rejected, and further, the node 2 obtains contracts corresponding to each transaction task in the transaction set R to be rejected; when node 2 determines that the low priority contract group maintained in blockchain 1 does not include the contract a corresponding to the transaction task a, node 2 may query the contract index set Cs for the contract priority corresponding to the contract a, when node 2 also does not query the contract index set Cs for the contract priority corresponding to the contract a, node 2 may create a contract priority object corresponding to the contract a, assign the contract priority object to the contract a, assume that the contract priority of the contract a is 1, determine that the contract group to which the contract priority 1 belongs is obtained, and add the contract a to the contract group to which the contract group belongs, for example, according to the schematic diagram of the low priority contract group set maintained in the blockchain system as shown in fig. 4, node 2 may determine that the contract group to which the obtained contract priority 1 belongs is the low priority contract group 1, and add the contract a to the low priority contract group 1 to which the contract group belongs. Therefore, the transaction contract is degraded, so that the demand of the fetch transaction is met, and the result of removing more transactions at one time is achieved, and the removing efficiency of the transactions can be effectively improved.

In one embodiment, the method further comprises:

after adjusting the contract priority corresponding to the contract, traversing the contract index set to obtain the contract priority corresponding to the contract;

Determining a contract group to which a contract priority corresponding to the contract belongs;

Adding contracts to a contract group;

Contracts are deleted from the priority contract group.

Specifically, the first slave node may select a vote disapproved message from the first vote message and each second vote message, and since the vote disapproved message includes a transaction task verified as being illegal by the node, the first slave node may select a transaction task meeting a rejection condition from at least one illegal transaction task corresponding to the vote disapproved message, and save the transaction task meeting the rejection condition in a set of transaction tasks to be rejected; further, the first slave node may acquire contracts corresponding to each transaction task in the transaction set to be removed; when the first slave node determines that the low-priority contract group maintained in the blockchain system contains the contract, acquiring the contract priority corresponding to the contract, and carrying out degradation processing on the contract priority. When the first slave node adjusts the contract priority corresponding to the contract, the first slave node can traverse the contract index set again to obtain the contract priority corresponding to the contract, determine the contract group to which the contract priority corresponding to the contract belongs, add the contract into the new contract group, and delete the contract from the priority contract group in which the contract is originally located.

For example, assuming that the first slave node performs degradation processing on the contract priority 10 of the contract a to obtain the contract priority 11 of the contract a after the degradation processing, when the first slave node adjusts the contract priority corresponding to the contract a, traversing the contract index set to obtain the contract priority 11 corresponding to the contract a, for example, according to the schematic diagram of the low-priority contract group set maintained in the blockchain system as shown in fig. 4, the first slave node may determine that the contract group to which the contract priority 11 corresponding to the contract a belongs is the contract group; a low priority contract group 2, the first slave node may add the contract a to the low priority contract group 2, where the contract group is as follows, since the contract priority of the contract a before adjustment is 10; low priority contract group 1, therefore, the first slave node deletes contract a from the original low priority contract group 1. Therefore, the transaction contract is degraded, so that the demand of the fetch transaction is met, and the result of removing more transactions at one time is achieved, and the removing efficiency of the transactions can be effectively improved.

In one embodiment, the present application further provides an application scenario, where the application scenario applies the blockchain consensus method described above. Specifically, the application of the blockchain consensus method in the application scenario is as follows:

When a user wants to improve the overall consensus efficiency of the blockchain system, the blockchain consensus method can be adopted, namely in the blockchain system, when a main node in a node cluster goes out of a block and starts a new round of consensus, the main node can acquire a first transaction task which is not consensus and is of a non-rejection type from a cache; when the number of the first transaction tasks acquired from the cache by the master node is smaller than the preset number, the master node can grasp the second transaction tasks from the transaction pool based on the preset number and the number of the first transaction tasks, and encapsulate the first transaction tasks and the second transaction tasks into proposal messages of the blocks to be consensus; furthermore, the master node can broadcast the proposal message to all slave nodes in the blockchain, so that each slave node can carry out consensus on a block to be consensus based on a first transaction task and a second transaction task in the proposal message, and the first transaction task is a transaction task which is already executed in the last round of consensus process and is of a non-rejection type, and the transaction tasks do not need to be executed in the current round of consensus process, so that the consensus efficiency can be effectively improved, namely the execution result of the existing transaction task is utilized as much as possible, the overall execution time of the transaction task is reduced, and the consensus efficiency of the blockchain is effectively improved, and meanwhile, the resource consumption is reduced.

The method provided by the embodiment of the application can be applied to the consensus scene of various block chains. The block chain consensus method provided by the embodiment of the application is described below by taking a block chain consensus scene in a BFT type consensus environment as an example.

A blockchain system is a distributed system in which it is the smart contract that is the most important for a business party to be a carrier of its business needs realization.

The smart contract (Smart Contract), which is not smart itself, is a piece of code that implements user business logic, otherwise known as logic, that is executed by the node virtual machines of the blockchain. For a blockchain system, it requires that the states of all nodes must be consistent, that is, it is a deterministic state machine, only so that the blockchain system can reach consensus, otherwise the entire blockchain cannot function properly.

However, in actual business, due to carelessness or negligence of a developer, uncertain results such as random numbers, time stamps and the like are carried in intelligent contracts written by the developer, and when the contracts are executed, different nodes generate different results, so that consensus cannot be achieved, and the consensus efficiency of a blockchain is lower. Some solutions to the above-mentioned problem of failing to reach consensus have been adopted, which generally uses a strategy by which such transactions are eliminated, thereby preserving blockchain activity.

However, the above scheme still faces a problem that when the number of such transactions (random function type transactions) is relatively large, the transactions can be continuously processed for a period of time, but each time of rejection can only process one or a small number of multiple transactions, if the number of the transactions is relatively large and the transactions are scattered in the transaction pool, the whole blockchain can be continuously in the process of rejecting the transactions, so that consensus cannot be really achieved, and the consensus efficiency of the blockchain is low.

Therefore, in order to solve the above-mentioned problem, the present application provides a solution, that is, the present application provides an optimization method for removing a blockchain transaction, where the solution prioritizes contracts corresponding to transactions to be removed, so that other transactions are preferentially processed when a master node leaves a block next time, that is, the master node opens the next round of consensus, by this way, the number of the transactions in a block can be effectively reduced, so as to improve the consensus efficiency, and due to the existence of the solution, the transactions can be greatly packaged together, so that the removal efficiency of the transactions can also be effectively improved.

As shown in fig. 5, a flow chart of a transaction culling scheme in a conventional manner is shown. That is, the scheme of transaction culling in the conventional manner is shown in fig. 5, whose core logic is to delete a transaction from the pool when its disapproval ticket reaches a specified threshold. The method comprises the steps that a master node in a blockchain generates a proposal message aiming at a block to be recognized and broadcasts the proposal message to each slave node in the blockchain, so that the slave node verifies the block to be recognized in the proposal message, and if a transaction to be removed exists in the verification of the slave node, the slave node throws a disapproved ticket, and the disapproved ticket carries a transaction ID corresponding to the transaction to be removed; the slave node processes each transaction, and if the transaction disapproval ticket reaches more than f+1, the transaction is rejected. Where f represents the maximum number of permitted malignant nodes in the blockchain environment, e.g., if there are a total of 4 nodes in the blockchain, then a maximum of 1 permitted malignant nodes, i.e., f=1.

As shown in fig. 6, a flow chart of a conventional process for eliminating transactions is shown. The process of eliminating transaction in the traditional scheme is seen in a more visual way, and the method is as follows:

In fig. 6, A, B, C, D represents four nodes, respectively, the master node is sequentially rotated among the nodes, tx (0) is a normal transaction, and other is a random function type transaction, namely Tx (1), tx (2), tx (3) and Tx (4) are random function type transactions. Each time a node wraps, only 2 transactions are wrapped, the situation of Tx0-Tx1, tx0-Tx2 … will be formed.

Corresponding to the process flow shown in fig. 6, it can be seen clearly that there are two problems in the conventional manner:

1. each time the transaction is removed, the transaction which still needs to be removed is packed with a high probability when the proposal is packed next time, and the whole consensus process is not achieved continuously, as shown in fig. 6, and the agreement is achieved after one round;

2. The normal transaction Tx (0) is repeated every time, so that serious resource waste and time consumption are formed, and the phenomenon is more obvious when normal transactions are more and rejecting transactions are less in one proposal.

Therefore, in view of the above problems, the key problems to be solved by the present application include:

1. The success rate of consensus can be achieved by the next proposal as much as possible, that is, the transaction needing to be removed is not added in the next proposal as much as possible;

2. The execution result of the existing transaction is utilized as much as possible, the execution time of the transaction is reduced, and the consensus efficiency and the resource consumption are improved;

3. More transactions are eliminated as one time as possible, and the elimination efficiency of the transactions is improved.

On the product side, the method provided by the embodiment of the application can be used as an optimization scheme of a typical functional point to conduct proper propaganda to the outside, and can be used for implementing code level according to the scheme of the application to optimize the corresponding blockchain bottom code.

On the technical side, as shown in fig. 7, an overall optimization flow diagram of blockchain transaction culling is shown.

1.1 Overall optimization flow:

for the transaction culling scheme in the conventional manner, the adjustment as shown in fig. 7 can be made as a whole:

I.e. substantially all of the optimization objectives of the present application have been included in the flow shown in fig. 7:

1. When the main node forms a proposal, the transaction which is not agreed but not rejected in the process of the block consensus is preferentially selected, and the transaction is not required to be executed in the round of consensus, so that the consensus efficiency is improved;

2. When the main node forms a proposal, the transaction corresponding to the transaction contract to be removed is not contained as much as possible, so that the probability of removing the transaction in the next consensus can be effectively reduced;

3. For the transaction which needs to be removed in the round of consensus, the processing priority of the corresponding contract of the transaction is reduced, so that the transaction is convenient to be not selected when the proposal is formed next time.

It will be appreciated that in the method provided by the present application, transactions that are not agreed but not rejected in the previous block consensus process are preferably selected, because these transactions have already been executed in the previous block consensus process, so that re-execution is not required in the present round of consensus, and thus efficiency can be improved;

the non-agreed but non-rejected transactions mentioned in the scheme of the application are not inconsistent, the actual execution result of the transaction is inconsistent with a high probability, the non-agreed is merely that the transactions are not agreed due to the fact that the last block is not agreed, and most business transactions belong to the transactions;

In the scheme of the application, the trade needing to be rejected can refer to random function trade, the trade of the rejection class in the application can comprise random function trade, trade with uncertain results such as time stamp, and the like, and also can comprise some trade with random results, for example, some trade with secret key generation algorithm, and the like can be involved.

When the priority of the contract is degraded, a list is actually set in the blockchain system, the priority condition of the contract corresponding to each transaction is maintained in the list, the priority of the contract corresponding to the transaction is reduced when the fact that the transaction needing to be removed exists in the contract is found in the consensus, for example, the priority of the contract A corresponding to the transaction A needing to be removed is 10, the priority 10 of the contract A corresponding to the transaction A can be degraded, and the adjusted contract A has the priority of 11, wherein the priority of 10 is higher than 11. Assuming that the transaction corresponding to contract a includes transaction a and transaction B, then the transaction B will not be selected by the master node on the next round of master node forming a proposal.

The nodes are taken as a model, and as shown in fig. 8, a process flow diagram of the node model is shown.

The node model in the application is mainly a model aiming at BFT type consensus, in BFT type consensus, there is a concept of a disqualified node, the BFT model is 3f+1 model, wherein f represents the maximum permitted number of disqualified nodes, for example, if 4 nodes are shared in a block chain system, 1 disqualified node is permitted at maximum. The condition for rejection, i.e., f+1 votes, indicates that the transaction may be deleted, f+1>f, which indicates that at least one honest node chooses to reject the transaction.

In the processing flow of the node model shown in fig. 8, when a master node in a node cluster goes out of a block and starts a new round of consensus, the master node can acquire a transaction set which is not agreed in the previous round but is of a non-rejection type from a cache, if the number of transactions in the transaction set is smaller than a preset number, the master node can also determine the number of transactions needing to be grabbed based on the preset number and the number of transactions in the transaction set, and after grabbing a specified number of transactions from a transaction pool, the master node can package the transactions in the transaction set and the transactions grabbed from the transaction pool into a proposal of a block to be consensus and broadcast the proposal to slave nodes in a block chain in a message mode, and when each slave node receives the proposal message, the slave node can perform validity verification on all the transactions in the proposal to obtain a verification result; when the verification result indicates that at least one transaction in the transactions is illegal, the slave node can generate a disapproved vote which disapproves the block to be consensus; meanwhile, the slave node can also receive votes broadcasted by other nodes, each node in the node cluster can traverse all votes, count the disapproved voting information of the transaction, traverse the disapproved transaction, judge whether each disapproved transaction meets the rejection condition one by one, if yes, the node can carry out degradation treatment on the priority of the contract corresponding to the transaction meeting the rejection condition; in addition, when each node in the node cluster traverses all the votes, and the number of the disapproved votes in the votes is judged to not meet the preset condition, the node can determine that the block to be consensus cannot reach consensus, and when the block to be consensus does not reach consensus, the node can reject the transaction meeting the rejection condition in the round of consensus.

The disapproved votes contain transaction information disapproved by the current node, and each node generates disapproved votes so as to inform other nodes of knowing which transactions are disapproved by the current node, so that the subsequent transaction rejection can be facilitated.

In addition, in the embodiment of the application, the flow of the broadcast voting is to traverse the voting in the master node and the slave node, and the traverse voting can gather the disapproved information, and the disapproved transactions carried in the disapproved voting of each node can be the same or different. That is, in the processing flow shown in fig. 8, the broken line box portion represents the optimization processing performed in the scheme of the present application.

In the node verification proposal, the processing flow is also adjusted when the node traverses to execute the transaction, as shown in fig. 9, which is a schematic flow diagram of the node traversing to execute the transaction.

In the flow shown in fig. 9, when the slave node verifies the proposal message, the slave node may traverse and execute each transaction task in the proposal message, that is, the slave node may traverse and execute the transaction set in the proposal message, and initialize the transaction set Txs, i=0, further, the slave node may sequentially acquire each transaction in the transaction set Txs, that is, the slave node acquires the transaction t= Txs [ i ], and determine whether the execution result of the transaction T is stored in the local cache, if so, the slave node may determine whether the execution result of the transaction T stored in the local cache is consistent with the execution result of the transaction T in the proposal message, and if so, the slave node may determine that the transaction T is a legal transaction task, and re-cache the execution result of the transaction T, that is, cover the previous cache information. I.e. the slave node may obtain a verification result indicating that the transaction T is legal; the slave node may continue to obtain the next transaction in the transaction set Txs until i > = len (Txs) is met. Where i shown in fig. 9 indicates what number of transactions, len (Txs) indicates the number of transactions in the transaction set.

If the execution result corresponding to the transaction T stored in the local cache is inconsistent with the execution result corresponding to the transaction T in the proposal message, the slave node can determine that the transaction T is an illegal transaction task and obtain a verification result for indicating that the transaction T is illegal; the slave node may continue to obtain the next transaction in the transaction set Txs until i > = len (Txs) is met.

In addition, when the slave node verifies the proposal message, the slave node obtains the transaction t= Txs [ i ], judges the transaction T, obtains the execution result corresponding to the transaction T, judges whether the execution result obtained by executing the transaction T is consistent with the execution result corresponding to the transaction T in the proposal message, and if so, the slave node can determine that the transaction T is a legal transaction task and rebuffer the execution result corresponding to the transaction T, namely the buffer information before coverage. I.e. the slave node may obtain a verification result indicating that the transaction T is legal.

If the execution results are inconsistent, the slave node can determine that the transaction T is an illegal transaction task and obtain a verification result for indicating that the transaction T is illegal; the slave node may continue to obtain the next transaction in the transaction set Txs until i > = len (Txs) is met. In the embodiment of the application, when each slave node in the node cluster verifies the proposal message, the slave node can firstly judge whether the execution result corresponding to the transaction exists in the local cache, and if so, the slave node can compare the execution result corresponding to the transaction stored in the local cache with the execution result corresponding to the transaction in the proposal message; if the execution result corresponding to the transaction is not stored in the local cache, the slave node needs to execute the transaction to obtain the corresponding execution result.

In the process flow shown in fig. 9, the core point of the optimization is the execution stage, not all transactions are executed, but more cache information local to the node is utilized, so that the execution efficiency of the transaction tasks can be effectively improved.

That is, the execution result in the proposal represents the execution result of the master node, and in the BFT type consensus, the principle to be followed is that only the correct proposal can be agreed between the nodes, and if the execution of the slave node and the master node are not even agreed, the consensus cannot be definitely agreed.

In the method provided by the application, the rejection condition of the transaction must meet f+1 sheets of disfavored tickets to be rejected. Because the master node may be bad, the information sent to the individual may be different, and thus the information judged by the individual may be different.

1.2 Contract priority adjustment

For transactions needing to be removed, the method provided by the application can adjust contracts represented by the transactions, so that the acquisition of the transactions is reduced as much as possible when the master node generates a proposal next time.

Internally, the blockchain system needs to maintain a low priority contract group set, as shown in fig. 4, which is a schematic diagram of the low priority contract group set maintained in the blockchain system. As shown in fig. 4, there are a plurality of contracts in each contract group, each contract having a corresponding priority, that is, each contract group includes a range of priority contracts. In actual fetch transactions, when the number of common transactions cannot be satisfied, fetch transactions are performed in a priority-from-high-low manner. In actual implementation, for the sake of simplification, a method of directly setting a contract group may be adopted.

As shown in fig. 10, a flow chart of adjusting contract priorities for a culling transaction is shown. The node adjusts the contract priority of the rejection transaction as follows:

The node can traverse all votes and select the votes which are not endorsed, and the votes which are not endorsed comprise transaction tasks which are verified as illegal by the node, so the node can select the transaction which accords with the rejection condition from at least one illegal transaction which corresponds to the votes which are not endorsed, and store the transaction which accords with the rejection condition in a transaction set to be rejected; the node may initialize a culled transaction set Txs, i=0, contract set Cs; further, the node may sequentially obtain each transaction in the transaction set Txs, that is, the node obtains the transaction t= Txs [ i ], obtains the contract C corresponding to the transaction T, determines whether the contract C corresponding to the transaction T is stored in the low-priority contract group maintained by the system, and if the contract C corresponding to the transaction T is stored in the low-priority contract group maintained by the system, obtains the priority P of the contract C from the low-priority contract group; if the contract C corresponding to the transaction T is not stored in the low-priority contract group maintained by the system, the node may further determine whether the contract C exists in the contract set Cs, and if so, acquire the priority p=cs < C > of the contract C from the contract set Cs; if the contract C does not exist in the contract set Cs, the node may create a priority object of the contract C and assign a priority p=0; further, the node may adjust the obtained priority P of the contract C, that is, set the priority p=p+1 of the contract C, and put it into the contract index map, that is, cs < C > =p; the node may continue to acquire the next transaction in the transaction set Txs until i > = len (Txs) is satisfied, where i shown in fig. 10 represents what number of transactions, len (Txs) represents the number of transactions in the transaction set, and len (Cs) represents the number of transactions.

Further, when the node judges that i > =len (Txs) is met, the node may initialize i=0 and traverse the contract set Cs, the node traverses the contract set Cs to obtain a contract C and its priority P, calculates a contract group met by the priority P of the contract C, and the node may add the contract C to the corresponding contract group and delete the contract group from the original contract group, further, the node may continue to judge whether the number condition of i > =len (Cs) is met, and if so, the flow is ended; if not, the node may traverse contract set Cs to retrieve contract C and its priority P until stopping when i > = len (Cs) is satisfied.

It will be appreciated that this manner of priority adjustment shown in fig. 10 is merely an example, and the core is not a rule of priority, but rather the policy of priority to improve the accuracy of quickly confirming that a transaction needs to be removed and that a transaction does not need to be removed.

1.3 Transaction fetch optimization

In order to achieve the aim, the application provides an optimization scheme of the transaction fetch, wherein the core of the scheme is that the priority fetch has consistent consensus but non-reject type transactions, as shown in fig. 11, the overall flow diagram of the optimization scheme of the transaction fetch is shown. Where i shown in fig. 11 indicates what number of transactions, len (Txs) indicates the number of transactions, and len (ATs) indicates the number of transactions in the final output transaction set ATs.

The overall fetch flow is as follows:

When a main node in the node cluster goes out of a block and starts a new round of consensus, the main node can acquire transactions which are not agreed and are of non-rejection type from the cache; when the number of the transactions acquired from the cache is smaller than the preset number, the master node can grasp the corresponding transactions from the transaction pool according to the determined number of the transactions to be grasped, namely when the master node handles the transactions from the transaction pool, the master node handles the transaction signals, the number of the transactions to be grasped is N, the master node can judge whether the current transaction pool is empty or not, if not, the master node can initialize the final output transaction set ATs and the random function type transaction set RTs, a timer T1 is started, and when the timer is detected, the master node finishes the grasping flow.

After the master node initializes the final output transaction set ATs and the random function transaction set RTs and starts the timer T1, the master node may obtain N transactions Txs from the transaction pool, and determine whether the number len (Txs) of the obtained transactions is greater than 0, and if greater than 0, initialize the cursor: i=0, sequentially acquiring a transaction t= Txs [ i ], and acquiring a contract C of the transaction T; further, the master node may determine whether the contract C of the transaction is in a low priority processing contract group, and if the contract C of the transaction belongs to the low priority processing contract group maintained in the blockchain system, the master node may reject the transaction T from the transaction task set, and add the rejected transaction T to the random function type transaction set RTs; if the contract C of the transaction does not belong to the low priority processing contract group maintained in the blockchain system, the master node can add the transaction T to the final output transaction set ATs; after the master node traverses each transaction task in the transaction task set, the master node may determine whether the condition of i > =len (Txs) is satisfied, if so, the master node may further determine that len (ATs) > =n, that is, the master node needs to determine whether the number of transactions in the output transaction set ATs is greater than or equal to N, if not, the master node may further determine whether len (ATs) =0 is satisfied, that is, the master node needs to determine whether the number of transactions in the output transaction set ATs is equal to 0, and if len (ATs) =0, the master node may set ats=rts so as to reject all transactions in the ATs set at one time; if len (ATs) is not equal to 0, the master node recalculates the number of transactions n=n-len (ATs) to be grasped, and retrieves n=n-len (ATs) pen transactions Txs from the transaction pool, and executes the above-mentioned processing flow until the number of finally obtained transactions reaches the determined N, and ends the flow. In addition, in some cases, if len (ATs) is not equal to 0, the master node may also directly end the flow.

That is, when the number of transactions in the final output transaction set ATs is 0, there are two cases:

1. If all transactions are not, indicating that each round of transactions do not have fetch any transaction, and exiting;

2. transactions exist in the Rts set, and at the moment, ats is set as Rts, so that a plurality of random function transactions can be eliminated at one time.

The technical scheme of the application has the beneficial effects that:

an optimization scheme is provided for solving the problems existing in the transaction eliminating process in the traditional mode, and the three effects can be achieved through the scheme:

1. through the fetch transaction optimization, the success rate of the next proposal agreement is improved;

2. through the fetch transaction optimization and the cache utilization, the execution time of the transaction is reduced, and the consensus efficiency and the resource consumption are improved;

3. by degrading the transaction contract, the demand of the fetch transaction is met, and the result of eliminating more transactions at one time is achieved, so that the eliminating efficiency of the transactions can be effectively improved.

It should be understood that, although the steps in the flowcharts related to the embodiments described above are sequentially shown as indicated by arrows, these steps are not necessarily sequentially performed in the order indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in the flowcharts described in the above embodiments may include a plurality of steps or a plurality of stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of the steps or stages is not necessarily performed sequentially, but may be performed alternately or alternately with at least some of the other steps or stages.

Based on the same inventive concept, the embodiment of the application also provides a block chain consensus device for realizing the block chain consensus method. The implementation of the solution provided by the apparatus is similar to that described in the above method, so specific limitations in one or more blockchain consensus apparatus embodiments provided below may be referred to above as limitations on blockchain consensus methods, and are not repeated herein.

In one embodiment, as shown in FIG. 12, there is provided a blockchain consensus device comprising: an acquisition module 1202, a grabbing module 1204, an encapsulation module 1206, and a broadcasting module 1208, wherein:

An obtaining module 1202 is configured to obtain, from the cache, a first transaction task that is not agreed and is of a non-reject type.

And the grabbing module 1204 is configured to grab a second transaction task from the transaction pool based on the preset number and the number when the number of the first transaction tasks is smaller than the preset number.

The encapsulation module 1206 is configured to encapsulate the first transaction task and the second transaction task into a proposal message of the block to be agreed upon.

A broadcasting module 1208 is configured to broadcast the proposal message to a first node in the blockchain, so that the first node performs consensus on the to-be-consensus block based on the first transaction task and the second transaction task.

In one embodiment, the apparatus further comprises: a storage module and a screening module. The acquisition module is further used for acquiring the transaction task which is executed in the preamble block and is the non-rejection class under the condition that the preamble block of the block to be consensus is consensus and the preamble block is not consensus; the storage module is used for storing the executed transaction tasks which are the non-rejection classes in a cache; the screening module is used for screening first transaction tasks which are not agreed and are of non-rejection type from the cached transaction tasks according to contract priority; the contract priority is the priority corresponding to the contract of each transaction task.

In one embodiment, the apparatus further comprises: the determining module is used for determining a first grabbing quantity based on the preset quantity and the quantity when the quantity of the first transaction tasks is smaller than the preset quantity; the grabbing module is also used for grabbing a second transaction task from the transaction pool according to the first grabbing quantity and the contract priority; the contract priority is the corresponding priority of the contracts of each transaction task in the transaction pool.

In one embodiment, the apparatus further comprises: a rejecting module and a joining module. The acquisition module is also used for acquiring a transaction task set from the transaction pool according to the first grabbing quantity; sequentially acquiring contracts of all transaction tasks in the transaction task set; the rejecting module is used for rejecting the transaction task from the transaction task set when the contract of the transaction task belongs to a priority contract group; the adding module is used for adding the removed transaction tasks into a random function transaction set; and when the contract of the transaction task does not belong to the priority contract group, taking the transaction task as the second transaction task.

In one embodiment, the joining module is further configured to join the second transaction task to a target output transaction set; if the number of the transaction tasks in the target output transaction set meets a preset threshold condition, taking the random function transaction set as the target output transaction set so as to eliminate the transaction tasks in the target output transaction set; the determining module is further configured to determine a second grabbing amount based on the first grabbing amount and the number of the target output transaction centralized transaction tasks if the number of the target output transaction centralized transaction tasks does not meet the preset threshold condition; the acquisition module is also used for acquiring the transaction task set from the transaction pool according to the second grabbing quantity.

In one embodiment, the apparatus further comprises: the device comprises a generating module, a verifying module and a receiving module. The broadcasting module is further used for broadcasting the proposal message to a first slave node and a second slave node in the blockchain; the verification module is used for verifying the validity of the first transaction task and the second transaction task through the first slave node when the first slave node receives the proposal message, so as to obtain a verification result; the generation module is used for generating a first voting message which is not in favor of the block to be consensus when the verification result indicates that at least one transaction task of the first transaction task or the second transaction task is illegal; a receiving module, configured to receive a second voting message broadcast by each second slave node; the determining module is further configured to determine that the blocks to be consensus is reached when the number of voting messages in the first voting message and each second voting message, which agree with the blocks to be consensus, satisfies a preset condition.

In one embodiment, the apparatus further comprises: a selecting module and an adjusting module. The selecting module is used for selecting the disapproved voting message from the first voting message and each second voting message; the disapproved voting message is a voting message disapproved for the consensus of the block to be consensus; selecting a transaction task which meets the rejection condition from at least one transaction task corresponding to the disapproved voting message; and the adjustment module is used for adjusting the contract priority corresponding to the transaction task meeting the rejection condition.

In one embodiment, the apparatus further comprises: the execution module is used for traversing and executing each transaction task in the proposal message to obtain a verification result for indicating whether each transaction task is legal or not when verifying the proposal message; the storage module is also used for storing the transaction task which is indicated to be legal in the verification result in the cache.

In one embodiment, the obtaining module is further configured to sequentially obtain each transaction task and a corresponding execution result in the proposal message; when the execution results corresponding to the transaction tasks sequentially acquired exist in the cache and the execution results in the cache are consistent with the execution results in the proposal message, a verification result for indicating that the transaction tasks sequentially acquired are legal is obtained; the execution module is further used for executing the transaction tasks which are sequentially acquired when the execution results of the transaction tasks which are sequentially acquired do not exist in the cache, so as to obtain corresponding execution results; and when the obtained execution result is consistent with the execution result in the proposal message, obtaining a verification result for indicating that the transaction tasks acquired in sequence are legal.

In one embodiment, the determining module is further configured to obtain a verification result for indicating that the sequentially acquired transaction task is illegal when there is an execution result in the buffer and the execution result in the buffer is inconsistent with the execution result in the proposal message.

In one embodiment, the apparatus further comprises: the storage module is used for storing the transaction tasks meeting the rejection conditions in a transaction task set to be rejected; the acquisition module is also used for acquiring contracts corresponding to each transaction task in the transaction set to be removed; when the contract group contains the contract, acquiring the contract priority corresponding to the contract; the adjustment module is also used for carrying out degradation processing on the contract priority.

In one embodiment, the apparatus further comprises: the inquiring module is used for inquiring the contract priority corresponding to the contract from the contract index set when the contract is not contained in the priority contract group; the adjustment module is further used for carrying out degradation processing on the contract priority of the query when the contract priority of the query is the target priority.

In one embodiment, the apparatus further comprises: a creation module and a valuation module. The creating module is used for creating a contract priority object corresponding to the contract when the contract is not included in the priority contract group and the contract is not existed in the contract index set; and the assignment module is used for assigning the contract priority object to obtain the contract priority. The determination module is further configured to determine a contract group to which the resulting contract priority belongs.

In one embodiment, the apparatus further comprises: and deleting the module. The query module is further configured to traverse the contract index set to obtain a contract priority corresponding to the contract after adjusting the contract priority corresponding to the contract; the determining module is further used for determining a contract group to which the contract priority corresponding to the contract belongs; the joining module is further configured to join the contract to the contract group; and the deleting module is used for deleting the contract from the priority contract group.

The various modules in the blockchain consensus apparatus described above may be implemented in whole or in part by software, hardware, or a combination thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.

In one embodiment, a computer device is provided, which may be a server, and the internal structure of which may be as shown in fig. 13. The computer device includes a processor, a memory, an Input/Output interface (I/O) and a communication interface. The processor, the memory and the input/output interface are connected through a system bus, and the communication interface is connected to the system bus through the input/output interface. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database of the computer device is for storing blockchain consensus data. The input/output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used for communicating with an external terminal through a network connection. The computer program when executed by a processor implements a blockchain consensus method.

It will be appreciated by those skilled in the art that the structure shown in FIG. 13 is merely a block diagram of some of the structures associated with the present inventive arrangements and is not limiting of the computer device to which the present inventive arrangements may be applied, and that a particular computer device may include more or fewer components than shown, or may combine some of the components, or have a different arrangement of components.

In an embodiment, there is also provided a computer device comprising a memory and a processor, the memory having stored therein a computer program, the processor implementing the steps of the method embodiments described above when the computer program is executed.

In one embodiment, a computer-readable storage medium is provided, storing a computer program which, when executed by a processor, implements the steps of the method embodiments described above.

In one embodiment, a computer program product or computer program is provided that includes computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps in the above-described method embodiments.

It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or sufficiently authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards of the related country and region.

Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, database, or other medium used in embodiments provided herein may include at least one of non-volatile and volatile memory. The nonvolatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical Memory, high density embedded nonvolatile Memory, resistive random access Memory (ReRAM), magneto-resistive random access Memory (Magnetoresistive Random Access Memory, MRAM), ferroelectric Memory (Ferroelectric Random Access Memory, FRAM), phase change Memory (PHASE CHANGE Memory, PCM), graphene Memory, and the like. Volatile memory can include random access memory (Random Access Memory, RAM) or external cache memory, and the like. By way of illustration, and not limitation, RAM can be in various forms such as static random access memory (Static Random Access Memory, SRAM) or dynamic random access memory (Dynamic Random Access Memory, DRAM), etc. The databases referred to in the embodiments provided herein may include at least one of a relational database and a non-relational database. The non-relational database may include, but is not limited to, a blockchain-based distributed database, and the like. The processor referred to in the embodiments provided in the present application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, or the like, but is not limited thereto.

The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

The foregoing examples illustrate only a few embodiments of the application and are described in detail herein without thereby limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of the application should be assessed as that of the appended claims.

Claims

1. A method of blockchain consensus, the method comprising:

acquiring a first transaction task which is not agreed and is of a non-rejection type from a cache;

Grabbing a second transaction task from a transaction pool based on the preset number and the number when the number of the first transaction tasks is smaller than the preset number;

Packaging the first transaction task and the second transaction task into proposal information of a block to be consensus;

the proposal message is broadcast to a first node in a blockchain, so that the first node performs consensus on the block to be consensus based on the first transaction task and the second transaction task.

2. The method according to claim 1, wherein the method further comprises:

under the condition that the preamble block of the block to be consensus is consensus and the preamble block does not reach consensus, acquiring the transaction task which is executed in the preamble block and is of the non-rejection type;

storing the executed transaction tasks which are the non-reject classes in a cache;

screening first transaction tasks which are not agreed and are non-reject according to contract priority from cached transaction tasks; the contract priority is the priority corresponding to the contract of each transaction task.

3. The method of claim 1, wherein grabbing a second transaction task from a transaction pool based on the preset number and the number when the number of the first transaction tasks is less than the preset number comprises:

when the number of the first transaction tasks is smaller than a preset number, determining a first grabbing number based on the preset number and the number;

Grabbing a second transaction task from the transaction pool according to the first grabbing quantity and the contract priority; the contract priority is the corresponding priority of the contracts of each transaction task in the transaction pool.

4. A method according to claim 3, wherein said crawling a second transaction task from a pool of transactions according to said first crawling quantity and contract priority, comprises:

acquiring a transaction task set from the transaction pool according to the first grabbing quantity;

Sequentially acquiring contracts of all transaction tasks in the transaction task set;

When the contracts of the transaction tasks belong to a priority contract group, rejecting the transaction tasks from the transaction task set, and adding the rejected transaction tasks into a random function transaction set;

And when the contract of the transaction task does not belong to the priority contract group, taking the transaction task as the second transaction task.

5. The method according to claim 4, wherein the method further comprises:

adding the second transaction task to a target output transaction set;

If the number of the transaction tasks in the target output transaction set meets a preset threshold condition, taking the random function transaction set as the target output transaction set so as to eliminate the transaction tasks in the target output transaction set;

6. The method of claim 1, wherein the first node comprises a first slave node and at least one second slave node;

the broadcasting the proposal message to a first node in a blockchain to cause the first node to consensus the block to be consensus based on the first transaction task and the second transaction task, including:

broadcasting the proposal message to a first slave node and a second slave node in a blockchain, and when the first slave node receives the proposal message, verifying the legitimacy of the first transaction task and the second transaction task through the first slave node to obtain a verification result;

When the verification result shows that at least one transaction task in the first transaction task or the second transaction task is illegal, generating a first voting message which is not in favor of the block to be agreed by the first slave node, receiving second voting messages broadcast by the second slave nodes, and determining that the block to be agreed meets the agreement when the number of the voting messages which are in favor of the block to be agreed in the first voting message and the second voting messages meets a preset condition.

7. The method of claim 6, wherein the method further comprises:

Selecting a disapproved voting message from the first voting message and each second voting message; the disapproved voting message is a voting message disapproved for the consensus of the block to be consensus;

8. The method of claim 6, wherein verifying the legitimacy of the first transaction task and the second transaction task results in a verification result, comprising:

the method further comprises the steps of: and storing the transaction task which is indicated to be legal in the verification result in the cache.

9. The method of claim 8, wherein the traversing execution of each transaction task in the proposal message results in a verification result indicating whether each transaction task is legal, comprising:

When the execution results corresponding to the transaction tasks sequentially acquired exist in the cache and the execution results in the cache are consistent with the execution results in the proposal message, a verification result for indicating that the transaction tasks sequentially acquired are legal is obtained;

when the execution results of the transaction tasks which are acquired in sequence do not exist in the cache, executing the transaction tasks which are acquired in sequence to obtain corresponding execution results; and when the obtained execution result is consistent with the execution result in the proposal message, obtaining a verification result for indicating that the transaction tasks acquired in sequence are legal.

10. The method according to claim 9, wherein the method further comprises:

And when the execution results of the transaction tasks acquired in sequence are inconsistent with the execution results in the proposal message, acquiring a verification result for indicating that the transaction tasks acquired in sequence are illegal.

11. The method of claim 7, wherein adjusting the contract priority corresponding to the transaction task that meets the culling condition comprises:

Storing the transaction tasks meeting the rejection conditions in a transaction task set to be rejected;

acquiring contracts corresponding to each transaction task in the transaction set to be removed;

and when the contract is contained in the priority contract group, acquiring the contract priority corresponding to the contract, and carrying out degradation treatment on the contract priority.

12. The method of claim 11, wherein the method further comprises:

Inquiring the contract priority corresponding to the contract from a contract index set when the contract is not contained in the priority contract group;

And when the contract priority of the query is the target priority, carrying out degradation processing on the contract priority of the query.

13. The method according to claim 12, wherein the method further comprises:

creating a contract priority object corresponding to the contract when the contract is not included in the priority contract group and the contract is not present in the contract index set;

And assigning the contract priority object to obtain the contract priority.

14. The method of claim 11, wherein the method further comprises:

After the contract priority corresponding to the contract is adjusted, traversing the contract index set to obtain the contract priority corresponding to the contract;

determining a contract group to which the contract priority corresponding to the contract belongs;

adding the contract to the contract group;

deleting the contract from the priority contract group.

15. A blockchain consensus device, the device comprising:

the acquisition module is used for acquiring a first transaction task which is not agreed and is of a non-rejection type from the cache;

The grabbing module is used for grabbing a second transaction task from the transaction pool based on the preset number and the number when the number of the first transaction tasks is smaller than the preset number;

The packaging module is used for packaging the first transaction task and the second transaction task into proposal messages of the blocks to be identified;

And the broadcasting module is used for broadcasting the proposal message to a first node in a blockchain so that the first node can carry out consensus on the block to be consensus based on the first transaction task and the second transaction task.

16. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor implements the steps of the method of any one of claims 1 to 14 when the computer program is executed.

17. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any of claims 1 to 14.

18. A computer program product comprising a computer program, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any one of claims 1 to 14.