CN112381649B

CN112381649B - Transaction consensus method, device and equipment based on blockchain

Info

Publication number: CN112381649B
Application number: CN202011289163.8A
Authority: CN
Inventors: 毛嘉宇; 范瑞彬; 张开翔; 张龙; 储雨知; 王越
Original assignee: WeBank Co Ltd
Current assignee: WeBank Co Ltd
Priority date: 2020-11-17
Filing date: 2020-11-17
Publication date: 2024-06-18
Anticipated expiration: 2040-11-17
Also published as: CN112381649A

Abstract

The embodiment of the disclosure provides a transaction consensus method, device and equipment based on a blockchain, wherein the method comprises the following steps: the leading node of the blockchain acquires all transaction information to be executed from the transaction pool and executes the transaction; storing the first type transaction information and the first execution result into a serial execution queue, and storing the second type transaction information and the second execution result into a parallel execution queue; the duplicate node of the block chain unpacks the block, performs serial transaction execution and verification on the first type transaction information of the serial execution queue, performs parallel transaction execution and verification on the second type transaction information of the parallel execution queue, obtains a verification result of the block, and completes consensus on the transaction information of the block according to the verification result. Because the transaction information irrelevant to the transaction execution sequence is executed in parallel, the execution efficiency of the block transaction can be greatly improved, the throughput and the execution speed of the consensus algorithm are improved, and the processing efficiency of the block chain transaction is further improved.

Description

Transaction consensus method, device and equipment based on blockchain

Technical Field

The embodiment of the disclosure relates to the technical field of financial science and technology (Fintech), in particular to a transaction consensus method, device and equipment based on a blockchain.

Background

With the development of computer technology, more and more technologies are applied in the financial field, the traditional financial industry is gradually changed to the financial technology (Finteh), and the transaction technology based on blockchain is not exceptional, but because of the requirements of safety and instantaneity of the financial industry, the technology is also required to be higher.

In the existing transaction consensus process based on the blockchain, all nodes participating in consensus in the blockchain need to execute all transactions in the block in sequence according to the sequence so as to ensure that the execution results of all nodes are consistent.

However, the inventors found that the prior art has at least the following technical problems: all transactions in the block are executed in a serial mode, so that the transaction execution efficiency is very low, and the processing efficiency of the block chain transaction is affected.

Disclosure of Invention

The embodiment of the disclosure provides a transaction consensus method, device and equipment based on a blockchain, which are used for solving the problems that the transaction execution efficiency is very low and the processing efficiency of the blockchain transaction is affected because all transactions in a block are executed in a serial mode in the prior art.

In a first aspect, an embodiment of the present disclosure provides a blockchain-based transaction consensus method, including:

Responding to the transaction information uploaded by the client, storing the transaction information into a transaction pool by any node of the blockchain, and broadcasting the transaction information to other nodes;

The leader node of the blockchain acquires all transaction information to be executed from the transaction pool, performs virtual transaction execution, and divides the transaction information into first-class transaction information and second-class transaction information according to a virtual execution result; wherein the first type of transaction information is transaction information which is successfully executed and transaction information which is failed to be executed but is related to the execution sequence of the transaction is stored in a serial execution queue, and the second type of transaction information is transaction information which is failed to be executed and is unrelated to the execution sequence of the transaction is stored in a parallel execution queue;

The leader node of the blockchain carries out serial transaction execution on the first type transaction information of the serial execution queue to obtain a first execution result, and carries out parallel transaction execution on the second type transaction information of the parallel execution queue to obtain a second execution result;

the leading node of the blockchain packages the first type transaction information and the first execution result of the serial execution queue, and the second type transaction information and the second execution result of the parallel execution queue into blocks, and sends the blocks to the replica node of the blockchain;

Unpacking the block by a duplicate node of a block chain, performing serial transaction execution on first-class transaction information of the serial execution queue, checking the first execution result, performing parallel transaction execution on second-class transaction information of the parallel execution queue, checking the second execution result, obtaining a verification result of the block, and broadcasting a message of the verification result to all nodes;

And starting a consensus process based on a preset consensus algorithm, and storing transaction information in the block chain if the number of messages of the same verification result received by other nodes of the block chain reaches a preset threshold value.

In one possible design, the parallel transaction execution of the second type of transaction information of the parallel execution queue by the replica node of the blockchain includes:

starting a thread pool to store second-class transaction information of the parallel execution queue, and setting a plurality of threads;

And executing transaction of the second type of transaction information in the thread pool according to the plurality of threads in parallel.

In one possible design, the storing the transaction information in the block in the blockchain plate includes:

deleting the second type transaction information of the parallel execution queue in the block;

And storing the first kind of transaction information of the serial execution queue in the block chain drop disc.

In one possible design, after the parallel transaction execution is performed on the second type of transaction information of the parallel execution queue by the replica node of the blockchain, the method further includes:

If the result of parallel transaction execution of any second type transaction information of the parallel execution queue by the copy node is that the execution is successful, judging whether the second type transaction information is added into the parallel execution queue;

If the second type transaction information is added into the parallel execution queue, judging the number of times of transaction execution of the execution failure of the second type transaction information;

If the execution times of the transaction with the execution failure exceeds a set threshold, deleting the second type transaction information;

if the second type transaction information is not added into a parallel execution queue or the execution failure transaction execution times of the second type transaction information do not exceed the set threshold, updating the transaction execution times into the second type transaction information, re-storing the updated second type transaction information into the transaction pool, and broadcasting the second type transaction information to other nodes.

In one possible design, if the number of times of execution of the second type of transaction information is not greater than the set threshold, updating the number of times of execution of the transaction into the second type of transaction information, and re-storing the updated second type of transaction information into the transaction pool, and broadcasting the second type of transaction information to other nodes, the method further includes:

The block chain forcedly triggers view switching based on a preset consensus algorithm to replace consensus nodes participating in consensus in the block chain, wherein the consensus nodes comprise a leader node and a duplicate node.

In one possible design, the transaction information carries the number of times the transaction is executed;

after any node of the blockchain stores the transaction information in a transaction pool, the method further includes:

And if the transaction execution times of the transaction information exceeds a set threshold, deleting the transaction information.

In one possible design, the leader node of the blockchain obtains all transaction information to be executed from the transaction pool and performs virtual transaction execution, and divides the transaction information into first type transaction information and second type transaction information according to a virtual execution result, including:

the leader node of the blockchain invokes a virtual machine to perform transaction execution on the transaction information to obtain an execution result, wherein the execution result comprises a transaction return response code of the transaction execution;

If the transaction return response code is an execution success response code or the response code is a response code which fails to execute but is related to the transaction execution sequence, determining the transaction information as first type transaction information;

if the transaction return response code is a response code which fails to execute and is irrelevant to the execution order of the transaction, the transaction information is determined to be the second type of transaction information.

In one possible design, the response code that fails execution and is independent of the order of execution of the transactions includes:

Message analysis type errors and response codes corresponding to intelligent contract binary coding parameter checking errors or intelligent contract function parameter abnormality type errors;

a response code that fails execution but is related to the order of execution of the transactions, comprising:

and (3) response codes corresponding to the insufficient resources errors during execution, abnormal control errors during execution or other unknown errors.

In one possible design, the preset consensus algorithm includes one of the following:

Work proof Pow algorithm, stock proof Pos algorithm, commission proof DPos algorithm, verification Pool algorithm and practical Bayesian fault tolerance PBFT algorithm.

In a second aspect, embodiments of the present disclosure provide a blockchain-based transaction consensus device comprising:

The transaction uploading module is used for responding to the transaction information uploaded by the client, storing the transaction information into a transaction pool by any node of the blockchain, and broadcasting the transaction information to other nodes;

The transaction classification module is used for acquiring all transaction information to be executed from the transaction pool by a leader node of the blockchain, performing virtual transaction execution, and classifying the transaction information into first-type transaction information and second-type transaction information according to a virtual execution result; wherein the first type of transaction information is transaction information which is successfully executed and transaction information which is failed to be executed but is related to the execution sequence of the transaction is stored in a serial execution queue, and the second type of transaction information is transaction information which is failed to be executed and is unrelated to the execution sequence of the transaction is stored in a parallel execution queue;

The transaction execution module is used for performing serial transaction execution on the first type transaction information of the serial execution queue by the leading node of the blockchain to obtain a first execution result, and performing parallel transaction execution on the second type transaction information of the parallel execution queue to obtain a second execution result;

The block sending module is used for packaging the first type transaction information and the first execution result of the serial execution queue, the second type transaction information and the second execution result of the parallel execution queue into blocks by the leading node of the block chain and sending the blocks to the copy node of the block chain;

the block verification module is used for unpacking the block by a duplicate node of a block chain, performing serial transaction execution on the first transaction information of the serial execution queue, checking the first execution result, performing parallel transaction execution on the second transaction information of the parallel execution queue, checking the second execution result, obtaining a verification result of the block, and broadcasting a message of the verification result to all nodes;

And the block tray dropping module is used for starting a consensus flow based on a preset consensus algorithm, and storing transaction information in the block chain tray if the number of messages of the same verification result received by other nodes of the block chain reaches a preset threshold value.

In one possible design, the transaction execution module is specifically configured to start a thread pool to store the second type of transaction information in the parallel execution queue, and set a plurality of threads; and executing transaction of the second type of transaction information in the thread pool according to the plurality of threads in parallel.

In one possible design, the block drop module is specifically configured to delete the second type transaction information of the parallel execution queue in the block; and storing the first kind of transaction information of the serial execution queue in the block chain drop disc.

In a third aspect, an embodiment of the present disclosure provides a service device, including: a processor and a memory;

the memory stores computer-executable instructions;

The processor executes the computer-executable instructions stored by the memory, causing the processor to perform the blockchain-based transaction consensus method as described above in the first aspect and the various possible designs of the first aspect.

In a fourth aspect, embodiments of the present disclosure provide a computer readable storage medium having stored therein computer executable instructions that when executed by a processor implement the blockchain-based transaction consensus method as described above in the first aspect and the various possible designs of the first aspect.

The embodiment of the disclosure provides a transaction consensus method, device and equipment based on a blockchain, wherein in the method, a leading node of the blockchain acquires all transaction information to be executed from a transaction pool, performs transaction execution, and divides the transaction information into first type transaction information and second type transaction information according to an execution result; the first type of transaction information is transaction information which is successfully executed, and transaction information which fails to be executed but is related to the execution sequence of the transaction, and the second type of transaction information is transaction information which fails to be executed and is unrelated to the execution sequence of the transaction; storing the first type transaction information and the first execution result into a serial execution queue, and storing the second type transaction information and the second execution result into a parallel execution queue; the duplicate node of the block chain unpacks the block, performs serial transaction execution and verification on the first type transaction information of the serial execution queue, performs parallel transaction execution and verification on the second type transaction information of the parallel execution queue, obtains a verification result of the block, and completes consensus on the transaction information of the block according to the verification result. Because the transaction information irrelevant to the transaction execution sequence is executed in parallel, the execution efficiency of the block transaction can be greatly improved, the throughput and the execution speed of the consensus algorithm are improved, and the processing efficiency of the block chain transaction is further improved.

Drawings

In order to more clearly illustrate the embodiments of the present disclosure or the solutions in the prior art, a brief description will be given below of the drawings that are needed in the embodiments or the description of the prior art, it being obvious that the drawings in the following description are some embodiments of the present disclosure, and that other drawings may be obtained from these drawings without inventive effort to a person of ordinary skill in the art.

FIG. 1 is a schematic diagram of a prior art block transaction information list;

FIG. 2 is a schematic diagram of a prior art blockchain transaction consensus principle;

FIG. 3 is a flow chart of a blockchain-based transaction consensus method provided by an embodiment of the present disclosure;

FIG. 4 is a schematic diagram of a list of transaction information in a block according to an embodiment of the disclosure;

FIG. 5 is a schematic diagram of a block chain based transaction consensus device according to an embodiment of the present disclosure;

fig. 6 is a schematic hardware structure of a service device according to an embodiment of the present disclosure.

Detailed Description

For the purposes of making the objects, technical solutions and advantages of the embodiments of the present disclosure more apparent, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present disclosure, and it is apparent that the described embodiments are some embodiments of the present disclosure, but not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without inventive effort, based on the embodiments in this disclosure are intended to be within the scope of this disclosure.

Technical noun interpretation:

Transaction: for invoking a smart contract that contains the necessary information for the smart contract, including invoked contracts, invoke input parameters, etc. Wherein the input parameter is encoded binary data. After the intelligent contract is called by the transaction, transaction result information is obtained, including whether the call is successful or not and a contract return value. Wherein the contract return value is also encoded binary data.

Consensus node: nodes in the blockchain participating in the consensus process comprise a leader node and a duplicate node.

Leader/Primary: is responsible for packaging transactions into blocks and initiating block consensus, with one and only one leader node in each round of consensus.

Duplicate node (duplicate): and the block consensus is completed, a plurality of duplicate nodes are arranged in each round of consensus process, and the processing process of each duplicate node is similar.

View (View): the consensus state of each node is recorded, and the same view node maintains node lists of the same leading node and the duplicate nodes. When the leader node fails, a view switch occurs.

The transaction processing module of the blockchain may be abstracted as a transaction-based state machine. The state refers to the state of all accounts in the blockchain, which takes the transaction as a state transfer function and updates from the old state to the new state according to the transaction content. The blockchain starts from creating blocks, continuously collecting transactions occurring on the blockchain network, ordering and packaging the transactions into blocks by a leader node, and executing the transactions in the blocks among all consensus nodes participating in the consensus. When transactions within a block are performed on multiple consensus nodes and are consistent, then it is said that a consensus is achieved on the block and the block is permanently recorded in the blockchain, completing the blockchain.

From the packaging, consensus and storage process of the blockchain, it can be understood that all transactions in the execution block are necessary paths for the blockchain. The current conventional transaction consensus process for blockchains is: the leader node of the blockchain takes out a certain amount of transactions from the transaction pool, sorts the transactions, and packages the transactions into a block of a transaction list, as shown in fig. 1, wherein each transaction in the block m is sorted according to the transaction sequence, and the block comprises a transaction 1, a transaction 2 and a transaction 3. The master node of the leader node then broadcasts and sends the data to all the duplicate nodes participating in the consensus for consensus. As shown in fig. 2, the replica node reads out transactions one by one from the transaction list of the block, and after each transaction is executed, the state machine is migrated to the next state until all transactions are executed serially.

However, in the prior art, all transactions in a block are performed in a serial manner, resulting in very low transaction performance efficiency and affecting the blockchain transaction processing efficiency.

In order to solve the above technical problems, the embodiments of the present disclosure provide the following technical solutions: the leader node of the blockchain acquires all transaction information to be executed from the transaction pool, performs virtual transaction execution, and divides the transaction information into first-type transaction information and second-type transaction information according to virtual execution results; the first type of transaction information is transaction information which is successfully executed, and transaction information which fails to be executed but is related to the execution sequence of the transaction, and the second type of transaction information is transaction information which fails to be executed and is unrelated to the execution sequence of the transaction; the leader node of the blockchain carries out serial transaction execution on the first type of transaction information of the serial execution queue to obtain a first execution result, carries out parallel transaction execution on the second type of transaction information of the parallel execution queue to obtain a second execution result, stores the first type of transaction information and the first execution result into the serial execution queue, stores the second type of transaction information and the second execution result into the parallel execution queue, and packages the blocks; the duplicate node of the blockchain unpacks the block, performs serial transaction execution on the first type transaction information of the serial execution queue, performs parallel transaction execution on the second type transaction information of the parallel execution queue, and obtains a verification result of the block, so that the execution efficiency of the block transaction can be greatly improved, the throughput and the execution speed of a consensus algorithm are improved, and the processing efficiency of the blockchain transaction is further improved.

Referring to fig. 3, fig. 3 is a flowchart illustrating a blockchain-based transaction consensus method according to an embodiment of the present disclosure. The embodiment is applied to a blockchain of a server, and the blockchain comprises a common node, wherein the common node comprises a leader node and a plurality of replica nodes, and the method is described in detail as follows:

S301: in response to the transaction information uploaded by the client, any node of the blockchain stores the transaction information in a transaction pool and broadcasts the transaction information to other nodes.

In this embodiment, the client may be any client that generates a transaction, and the client generates transaction information according to the transaction, and sends the transaction information to any node of the blockchain. For example, a user purchases a commodity at an online mall, and the transaction is completed through a client, which transmits transaction information of the purchased commodity to any node of the blockchain.

In this embodiment, any node of the blockchain is any node of the consensus nodes in the blockchain. The leader node is generated by election among the consensus nodes of the blockchain. Either consensus node may be either the leader node or the replica node.

S302: the leader node of the blockchain acquires all transaction information to be executed from the transaction pool, performs virtual transaction execution, and divides the transaction information into first-type transaction information and second-type transaction information according to virtual execution results; the first type of transaction information is transaction information which is successfully executed and transaction information which fails to be executed but is related to the execution sequence of the transaction is stored in a serial execution queue, and the second type of transaction information is transaction information which fails to be executed and is unrelated to the execution sequence of the transaction is stored in a parallel execution queue.

In this embodiment, the leader node acquires all transaction information to be executed. Specifically, the leader node first generates a new empty block, then acquires all transaction information to be executed from the transaction pool, and inserts the transaction information into the new empty block.

In one embodiment of the disclosure, a leader node of a blockchain invokes a virtual machine to perform transaction execution on transaction information to obtain a virtual execution result of the virtual machine, wherein the execution result comprises a transaction return response code of the transaction execution; if the transaction return response code is an execution success response code or the response code is a response code which fails to execute but is related to the transaction execution sequence, determining the transaction information as first type transaction information; if the transaction return response code is a response code which fails to execute and is irrelevant to the execution order of the transaction, the transaction information is determined to be the second type of transaction information.

In this embodiment, the response code that fails to execute and is independent of the execution order of the transaction includes:

Referring to fig. 4, fig. 4 is a schematic diagram of a list of transaction information in a block according to an embodiment of the disclosure. The block m includes a first type transaction information of a serial execution queue and a second type transaction information of a parallel execution queue.

S303: and the leader node of the blockchain carries out serial transaction execution on the first type of transaction information of the serial execution queue to obtain a first execution result, and carries out parallel transaction execution on the second type of transaction information of the parallel execution queue to obtain a second execution result.

S304: and the leading node of the blockchain packages the first type transaction information and the first execution result of the serial execution queue, and the second type transaction information and the second execution result of the parallel execution queue into blocks, and sends the blocks to the replica node of the blockchain.

In this embodiment, the leader node of the blockchain sets the packing node as the leader node itself, and packs the first type transaction information and the first execution result of the serial execution queue, the second type transaction information and the second execution result of the parallel execution queue into a new block.

The transaction information and the execution result carry the queue type identifier. The first type transaction information and the first execution result of the serial execution queue carry serial execution identification; the second type transaction information and the second execution result of the parallel execution queue carry parallel execution identification.

S305: the duplicate nodes of the block chain unpack the blocks, perform serial transaction execution on the first type transaction information of the serial execution queue and check the first execution result, perform parallel transaction execution on the second type transaction information of the parallel execution queue and check the second execution result, obtain the verification result of the blocks, and broadcast the message of the verification result to all the nodes.

In this embodiment, the duplicate node unpacks the block to obtain the transaction information and the execution result carrying the queue type identifier, and respectively obtain the first type transaction information and the first execution result of the serial execution queue, and the second type transaction information and the second execution result of the parallel execution queue.

In this embodiment, the process of starting a thread single thread and performing serial transaction execution on the first type of transaction information in the serial execution queue is as follows: and performing serial transaction execution on the first type of transaction information of the serial execution queue according to the transaction sequence of the transaction information in the serial execution queue to obtain a new execution result, and comparing and verifying the new execution result with the first execution result of the serial execution queue to obtain a first verification result.

In one embodiment of the present disclosure, the parallel transaction execution of the second type of transaction information of the parallel execution queue by the replica node of the blockchain includes: starting a thread pool to store second-class transaction information of a parallel execution queue, and setting a plurality of threads; and carrying out transaction execution on the second type of transaction information in the thread pool according to the plurality of threads in parallel to obtain a new execution result, and comparing and verifying the new execution result with the second execution result of the parallel execution queue to obtain a second verification result.

In this embodiment, the block verification result is obtained according to the first verification result and/or the second verification result. Specifically, the first verification result of the serial execution queue may be used as the verification result of the block, or the combined result of the first verification result and the second verification result may be used as the verification result of the block.

S306: and starting a consensus process based on a preset consensus algorithm, and storing transaction information in the block chain if the number of messages of the same verification result received by other nodes of the block chain reaches a preset threshold value.

In this embodiment, the preset consensus algorithm includes one of the following: work proof Pow algorithm, stock proof Pos algorithm, commission proof DPos algorithm, verification Pool algorithm and practical Bayesian fault tolerance PBFT algorithm.

In this embodiment, the number of messages reaching the preset threshold is different in different algorithms, and the requirements are different. The number of the common nodes may be half of the number of the common nodes plus one (2×f+1), or one third of the number of the common nodes plus one (3×f+1).

As can be seen from the description of the above embodiments, the leader node of the blockchain obtains all the transaction information to be executed from the transaction pool, performs transaction execution, and divides the transaction information into a first type of transaction information and a second type of transaction information according to the execution result; the first type of transaction information is transaction information which is successfully executed, and transaction information which fails to be executed but is related to the execution sequence of the transaction, and the second type of transaction information is transaction information which fails to be executed and is unrelated to the execution sequence of the transaction; storing the first type transaction information and the first execution result into a serial execution queue, and storing the second type transaction information and the second execution result into a parallel execution queue; the duplicate node of the block chain unpacks the block, performs serial transaction execution and verification on the first type transaction information of the serial execution queue, performs parallel transaction execution and verification on the second type transaction information of the parallel execution queue, obtains a verification result of the block, and completes consensus on the transaction information of the block according to the verification result. Because the transaction information irrelevant to the transaction execution sequence is executed in parallel, the execution efficiency of the block transaction can be greatly improved, the throughput and the execution speed of the consensus algorithm are improved, and the processing efficiency of the block chain transaction is further improved.

In one embodiment of the disclosure, the transaction information in the block may delete the second type of transaction information of the parallel execution queue in the block during the block chain drop storage process; and storing the first kind of transaction information of the serial execution queue in the block chain drop disc.

In this embodiment, in the conventional consensus transaction method, successful transactions and failed transactions in the block are distinguished, and all transactions are uniformly placed and stored in the blockchain node. According to the technical scheme, when the transaction is dropped, the node discards all transactions which fail to be executed in the parallel execution queue, and only the transactions in the serial queue are dropped, so that the storage resources of the blockchain node are greatly saved. Meanwhile, the transaction quantity stored in the block chain is reduced, the data quantity stored in the block chain is reduced, the performance attenuation caused by the improvement of the data quantity of the block chain is delayed, and the execution efficiency of the block chain link point can be improved in turn.

In one embodiment of the present disclosure, after performing parallel transaction execution on the second type of transaction information of the parallel execution queue by the replica node of the blockchain in the step S304, the method further includes:

s306: if the result of parallel transaction execution of any second type transaction information in the parallel execution queue by the copy node is that the execution is successful, judging whether the transaction information is added into the parallel execution queue.

In this embodiment, the second type transaction information in the parallel execution queue is transaction information with execution failure as an execution result after the transaction is executed by the leader node, and the result of parallel transaction execution by the duplicate node on the second type transaction information in the parallel execution queue is execution success, which indicates that the transaction information has a possibility of misjudgment.

In this embodiment, the determination of whether the transaction information is added to the parallel execution queue may be: and acquiring a history execution result in the transaction information, and if the history execution result shows that the transaction information has a record of execution failure, determining that the transaction information is added into a parallel execution queue.

S307: if the second type transaction information is added into the parallel execution queue, judging the execution times of the transaction with failure execution of the second type transaction information.

In this embodiment, the number of execution times of the transaction for judging the execution failure of the transaction information may be: and acquiring the number of times that the execution result of the transaction information is the execution failure according to the historical execution result in the transaction information.

S308: and if the execution times of the transactions with the failure execution exceeds the set threshold, deleting the second type of transaction information.

In this embodiment, the set threshold may be dynamically set according to the application transaction process.

S309: if the second type transaction information is not added into the parallel execution queue or the execution failure transaction execution times of the second type transaction information do not exceed the set threshold, updating the transaction execution times into the second type transaction information, re-storing the updated second type transaction information into a transaction pool, and broadcasting the transaction information to other nodes.

In this embodiment, the updated transaction information is restored in the transaction pool, and the transaction information is broadcast to other nodes, so that the updated transaction information becomes new transaction information to be executed, and the leader node which continuously participates in the blockchain acquires all the transaction information to be executed from the transaction pool and performs transaction execution.

From the description of the above embodiment, it can be known that by verifying whether there is a transaction misjudged by the consensus node in the parallel transaction queue, the misjudged transaction information is resent to the transaction pool so as to be re-executed by the master node again, thereby avoiding misjudgment of the node on the transaction information; and meanwhile, the transaction information of the transaction execution times exceeding a certain execution failure is deleted, so that the data volume stored in the storage block chain is further saved.

In one embodiment of the present disclosure, after the step S309, the method further includes:

S310: the block chain forcedly triggers view switching based on a preset consensus algorithm to replace consensus nodes participating in consensus in the block chain, wherein the consensus nodes comprise a leader node and a duplicate node.

In this embodiment, for the transaction information with erroneous judgment, the new consensus node packages and executes the transaction information with erroneous judgment in the next round of consensus, so as to avoid the situation that the transaction information with erroneous judgment is continuously misjudged by the old consensus node.

In one embodiment of the present disclosure, the transaction information carries the number of times of executing the transaction; after any node of the blockchain stores the transaction information in the transaction pool in step S301, the method further includes:

s311: and if the transaction execution times of the transaction information exceeds a set threshold, deleting the transaction information.

In this embodiment, the transaction information that has failed to be executed for more than a certain number of times in the transaction pool is deleted, so that the repeatedly executed transaction is avoided, and the processing efficiency of the blockchain is reduced.

The blockchain-based transaction consensus method provided by embodiments of the present disclosure is described in detail below by way of a specific example. In this example, PBFT algorithm is taken as an example, and is described in detail below.

The first stage: and submitting transaction information by the client, storing the transaction information into a transaction pool by any node of the blockchain, and broadcasting the transaction information to other nodes.

In the transaction pool of the node, a transaction root (a hash value calculated on transaction binary data) and the number of times of executing the transaction when the transaction has been executed are cached. For the transaction information to be executed, if the failed queue (parallel execution queue) has been added before, the number of times that the failed queue is added to the block and executed is calculated, and when a certain threshold value is exceeded, the transaction information is deleted from the transaction pool. If the transaction information is newly submitted, the transaction execution number is 0.

And a second stage: the leader node performs new block packing.

In the PBFT algorithm, the consensus nodes wrap out blocks, and each round of consensus only has one leader node wrap block, creating a new empty block. The main steps of the leader node are as follows:

Step1, generating a new empty block: the current highest chunk (highest-height chunk) is obtained, and a new empty chunk is generated based on the highest chunk (the new chunk parent hash is set to the highest chunk hash, the timestamp is set to the current time, and the transaction is cleared).

Step 2, packing transaction information from a transaction pool: after the new empty block is generated, transaction information is acquired from the transaction pool, and the acquired transaction information is inserted into the generated new block.

In this embodiment, the transaction pool includes all transaction information to be executed, and the transaction information is divided into: the transaction information submitted initially and the transaction information to be executed which fails in the secondary consensus flow.

Step 3, assembling a new block: and setting the packing node of the new block as the leading node, and calling the virtual module to execute the transaction according to the packed transaction information to obtain the execution result of the transaction information.

In this embodiment, the execution result of the transaction information includes the following key data:

transactionHash: transaction hash;

index, transaction serial number;

gasUsed: hash of transaction execution consumption;

from: an address of the transaction caller;

to: a target address of the transaction call;

input: an input binary code for transaction execution;

output: a binary code for transaction execution output;

logs: logging in the transaction execution process;

logsBloom: recording topic retrieval information of a transaction log;

status: the transaction returns a response code, and the detailed reason of the failure of executing the transaction can be obtained according to the response code.

The execution result includes a transaction return response code including both a successful execution response code (the execution result is a transaction return response code of transaction information of successful execution) and a transaction return response code of transaction information of unsuccessful execution. The transaction return response code for the transaction information that failed to be executed can be divided into the following:

1) The message parses the response code for the class error. Such as failure of block RLP resolution, invalid transaction formats, transaction format error exceptions.

2) The smart contract binary coded parameter checks for erroneous response codes. Such as deployment contract length exceeding gas limits, calling contract interface parameters exceeding gas limits, calling contract parameters being too long, deployment contract length exceeding longest limits, transaction format errors, etc.

3) Parameter anomaly response code. Such as an invalid signature, an invalid nonce, a false instruction, a false exception jump, an invalid chain ID exception, the absence of a called contract address, etc.

4) Response code for the resource-deficient error when executed. Such as insufficient balance of transfer, gasLimit shortage, gas deployment during contract execution, stack overflow abnormality, etc

5) And executing response codes of the control exception in the process. Such as revert exceptions, no rights exceptions, illegally deploying contracts, illegitimate transactions, contracts being frozen, accounts being frozen, etc.

6) Other response codes for unknown errors. Such as unknown anomalies.

The response code is returned for the transaction information of the execution failure, and the response code irrelevant to the execution order of the transaction comprises: message analysis type errors and response codes corresponding to intelligent contract binary coding parameter checking errors or intelligent contract function parameter abnormality type errors; the response code associated with the order of execution of the transactions includes: and (3) response codes corresponding to the insufficient resources errors during execution, abnormal control errors during execution or other unknown errors. The response code associated with the order of execution of the transaction corresponds to transaction information associated with the order of execution of the transaction, such as: there are two transfer transactions, A to B and B to C. Assuming that the two transfers are the same and the balance of the primary account B is 0, the primary account A has a sufficient primary balance; then if the transfer a is performed to B and then B is performed to C, the transaction is successful, otherwise the transaction fails.

Therefore, the leader node can distinguish the failure types according to the response codes returned by the transactions of the execution results for all the transaction information which fails to execute after the execution of the transaction information is completed. Based on the type of transaction return response code, it is determined whether the failure of the transaction is related to the ordering of the transactions.

The execution result of the transaction information also comprises a queue type identifier (queueType) for identifying that the transaction information belongs to a serial execution queue or a parallel execution queue. In the serial execution queue or the parallel execution queue, the transaction information is reordered according to the transaction sequence number.

Transaction information which is successfully executed and transaction information which fails to be executed but is related to the execution sequence of the transaction are stored in a serial execution queue, and transaction information which fails to be executed and is not related to the execution sequence of the transaction is stored in a parallel execution queue.

The leading node carries out transaction execution on the transaction information in the serial execution queue according to the serial, and a first state root (state root) of the serial execution queue is obtained; and the leader node performs transaction execution on the transaction information in the parallel execution queue according to the parallel execution to obtain a second state root (state root) of the parallel execution queue. The calculation rule of the state root is to export the executed transaction receipt into an array, and calculate the hash value of the transaction receipt.

The first state root of the serial execution queue has two results, one is an all state root (all state root) containing the failed transaction, and the other is a valid state root (VALID STATE root) not containing the failed transaction. It should be noted that: if the serial transaction queue does not contain a failed transaction, then all state roots are equal to the valid state roots.

Step 4, generating a preparation packet (preparation packet): and encoding the assembled new block into a preparation packet, broadcasting the preparation packet to all consensus nodes in the group, and starting three-stage consensus after other consensus nodes receive the preparation packet.

In this embodiment, the new block includes a list of transaction information of the execution serial execution queue and an execution result thereof, and a list of transaction information of the parallel execution queue and an execution result thereof in a packet.

And a third stage: the duplicate node pre-preparation stage (pre-prepair stage).

After receiving the preparation packet, the replica node enters a preparation stage, and the main workflow of the stage comprises:

Step 1, judging the validity of the preparation package: whether the repeated preparation packet is generated, whether the parent hash of the block contained in the preparation request is the highest block hash (preventing bifurcation) of the current node is judged, and whether the block height of the block contained in the preparation request is equal to the highest block height plus one is judged.

Step 2, empty block judgment: and if the transaction number in the block contained in the preparation request is 0, triggering the empty block view switching and broadcasting a view switching request to all other nodes.

Step 3, executing the transaction information in the block and caching the execution result: if the transaction number in the block contained in the preparation request is greater than 0, a block executor is called to execute the block, and the executed block is cached.

In this embodiment, the transaction information in the execution block is as follows: the replica node parses out the serial execution transaction queue and the parallel execution queue in the block based on the queue type identification (queueType) in the transaction information list, for which serial execution is performed using threads. And for the parallel execution queue, simultaneously starting the thread pool, setting a plurality of threads, and executing the transactions in the thread pool in parallel.

For example, in FIG. 4, transaction 2 is a transaction that fails to execute in the consensus node, but its failure type belongs to a transaction that is strongly related to the order of transactions. While all transactions in the parallel queue belong to transactions that fail and the type of failure is independent of the order of the transactions. Thus, transactions in the serial queue are performed sequentially in the order of the serial queues in the block. While transactions in the parallel queue may be executed concurrently in parallel, the order in which they are executed is not certain, and may be executed in any order.

After execution is completed, the consensus node assembles a signature packet. In addition to the original block content, the block also additionally comprises a serial execution queue and a parallel execution queue of the block. The calculation rule of the state root is to export the executed transaction receipt into an array, and calculate the hash value of the transaction receipt. The serial execution queue has two state root results, one is that the serial execution queue contains all state root after the failed transaction, and the other is that the serial execution queue does not contain VALID STATE root of the failed transaction. If the serial transaction queue execution result does not contain the transaction which fails to be executed, all state root is equal to VALID STATE root.

Step 4, generating and broadcasting signature packets: based on the executed block hash, a signature packet is generated and broadcast indicating that the present node has completed block execution and verification.

Fourth stage: and a consensus node preparation stage.

After receiving the signature packet, the consensus node enters a preparation stage, and the main working flow of the stage comprises the following steps:

step 1, signature inclusion validity judgment: the hash of the signature packet is mainly judged to be the same as the block hash after the execution of the pre-preparation stage cache, if the hash is not the same, the signature packet is an illegal signature request, and the node directly refuses the signature request.

Step 2, signature packet result judgment: after receiving the signature packet, the consensus node compares and caches the content of the signature packet with other received signature packets.

In this embodiment, it is determined whether the signature packets corresponding to the blocks cached in the pre-preparation stage are 2×f+1, and if the signature packets are collected, the commit packet is broadcasted, where VALID STATE root of the serial execution queue corresponding to the signature packets is equal: if the number of signature packets corresponding to the block hash of the pre-preparation stage buffer exceeds 2×f+1, it indicates that most nodes execute the block, and the execution results are consistent, which indicates that the node has reached a state in which the block can be submitted, and starts broadcasting the commit packet.

If the number of signature packets of all state root of the collected equal parallel execution queues exceeds 2×f+1, it indicates that most nodes execute all queues in the block, and the execution results are consistent. At this time, if there is transaction information in the parallel queue that is executed successfully, it is determined whether the transaction information has been added to the parallel execution queue before. If the parallel execution queue has been added before, the number of failures is calculated. When a certain threshold value is exceeded, discarding the transaction information whether successful or not; otherwise, put it into the transaction pool and broadcast to all other nodes. Meanwhile, if the failed transaction is rebroadcast to other nodes, the view switching is forcefully triggered, and the consensus node is replaced. ( The step is mainly used for finding and verifying whether transaction information misjudged by the consensus node exists in the parallel transaction queue. If the misjudgment exists, the new consensus node is used for packaging and executing the misjudged transaction in the next consensus stage. At the same time, the number of times the transaction is executed in a packaging consensus is recorded, and when a certain set threshold value is exceeded, the transaction information is forcedly discarded. )

Step 3, if the full signature packet is collected, backing up the pre packet disk of the pre-pre stage cache: in order to prevent the blocks in the commit phase from exceeding 2×f+1 nodes to be down before being submitted to the database, the nodes restart to re-block the blocks, resulting in the bifurcation of the blockchain (the latest block of the remaining nodes is different from the highest block of the nodes), and the pre-stage cache of the pre-pre packet needs to be backed up to the database, and the backup pre packet is preferentially processed after the node restarts.

Fifth stage: commit phase (commit phase).

After receiving the commit packet, the consensus node enters into a commit phase, and the workflow of the phase comprises:

Judging the validity of the commit packet: mainly judging that the hash of the commit packet is the same as the block hash after the execution of the pre-preparation stage cache, if the hash is different, the block hash is an illegal commit request, and directly rejecting the request by the node; judging whether a limit packet buffer corresponding to a block of the pre-preparation stage buffer reaches 2 x f+1, and if the limit packet is collected, landing a new block: if the number of commit requests corresponding to the block hash of the pre-preparation stage cache exceeds 2 xf+1, indicating that most nodes reach the state capable of submitting the block, and the execution results are consistent, writing the block of the pre-preparation stage cache into a database; when the node is dropped, the node discards the transaction information of which the execution fails in all the parallel execution queues, and only the transaction information in the serial queue is dropped.

Referring to fig. 5, fig. 5 is a schematic structural diagram of a transaction consensus device based on blockchain according to an embodiment of the present disclosure. As shown in fig. 5, the blockchain-based transaction consensus device 50 includes: a transaction uploading module 501, a transaction sorting module 502, a transaction executing module 503, a block transmitting module 504, a block verifying module 505 and a block landing module 506.

A transaction uploading module 501, configured to respond to the transaction information uploaded by the client, store the transaction information into a transaction pool by any node of the blockchain, and broadcast the transaction information to other nodes;

the transaction classification module 502 is configured to obtain all transaction information to be executed from the transaction pool by using a leader node of a blockchain, perform virtual transaction execution, and divide the transaction information into first type transaction information and second type transaction information according to a virtual execution result; wherein the first type of transaction information is transaction information which is successfully executed and transaction information which is failed to be executed but is related to the execution sequence of the transaction is stored in a serial execution queue, and the second type of transaction information is transaction information which is failed to be executed and is unrelated to the execution sequence of the transaction is stored in a parallel execution queue;

The transaction execution module 503 is configured to perform serial transaction execution on the first type of transaction information in the serial execution queue by using a leader node of the blockchain to obtain a first execution result, and perform parallel transaction execution on the second type of transaction information in the parallel execution queue to obtain a second execution result;

The block sending module 504 is configured to package, by a leader node of the blockchain, the first type transaction information and the first execution result of the serial execution queue, and the second type transaction information and the second execution result of the parallel execution queue into a block, and send the block to a duplicate node of the blockchain;

the block verification module 505 is configured to unpack the block by using a duplicate node of a block chain, perform serial transaction execution on the first type transaction information of the serial execution queue and verify the first execution result, perform parallel transaction execution on the second type transaction information of the parallel execution queue and verify the second execution result, obtain a verification result of the block, and broadcast a message of the verification result to all nodes;

The block drop module 506 is configured to start a consensus process based on a preset consensus algorithm, and store transaction information in the block chain if the number of messages of the same verification result received by other nodes of the block chain reaches a preset threshold.

The device provided in this embodiment may be used to implement the technical solution of the foregoing method embodiment, and its implementation principle and technical effects are similar, and this embodiment will not be described herein again.

In one embodiment of the present disclosure, the transaction execution module 503 is specifically configured to start a thread pool to store the second type of transaction information in the parallel execution queue, and set a plurality of threads; and executing transaction of the second type of transaction information in the thread pool according to the plurality of threads in parallel.

In one embodiment of the present disclosure, the block drop module 506 is specifically configured to delete the second type transaction information of the parallel execution queue in the block;

In one embodiment of the present disclosure, the apparatus further comprises: the misjudgment verification module 507 is configured to judge whether the second type transaction information is added to the parallel execution queue if the result of parallel transaction execution performed on any second type transaction information in the parallel execution queue by the duplicate node is that the execution is successful; if the second type transaction information is added into the parallel execution queue, judging the number of times of transaction execution of the execution failure of the second type transaction information; if the execution times of the transaction with the execution failure exceeds a set threshold, deleting the second type transaction information; if the second type transaction information is not added into a parallel execution queue or the execution failure transaction execution times of the second type transaction information do not exceed the set threshold, updating the transaction execution times into the second type transaction information, re-storing the updated second type transaction information into the transaction pool, and broadcasting the second type transaction information to other nodes.

In one embodiment of the present disclosure, the apparatus further comprises: the view switching module 508 is configured to force the blockchain to trigger view switching based on a preset consensus algorithm to replace a consensus node participating in consensus in the blockchain, where the consensus node includes a leader node and a duplicate node.

In one embodiment of the present disclosure, the transaction information carries the number of times of executing the transaction; the transaction uploading module 501 is further configured to delete the transaction information if the number of times of executing the transaction of the transaction information exceeds a set threshold.

In one embodiment of the present disclosure, the transaction classification module 502 is specifically configured to invoke the virtual machine by the leader node of the blockchain to perform transaction execution on the transaction information to obtain an execution result, where the execution result includes a transaction return response code of the transaction execution; if the transaction return response code is an execution success response code or the response code is a response code which fails to execute but is related to the transaction execution sequence, determining the transaction information as first type transaction information; if the transaction return response code is a response code which fails to execute and is irrelevant to the execution order of the transaction, the transaction information is determined to be the second type of transaction information.

Referring to fig. 6, fig. 6 is a schematic hardware structure of a service device according to an embodiment of the present disclosure. As shown in fig. 6, the service apparatus 60 of the present embodiment includes: a processor 601 and a memory 602; wherein the method comprises the steps of

A memory 602 for storing computer-executable instructions;

The processor 601 is configured to execute computer-executable instructions stored in the memory to implement the steps performed by the client or the server in the above embodiments. Reference may be made in particular to the relevant description of the embodiments of the method described above.

Alternatively, the memory 602 may be separate or integrated with the processor 601.

When the memory 602 is provided separately, the service based device further comprises a bus 603 for connecting said memory 602 and the processor 601.

Embodiments of the present disclosure also provide a computer-readable storage medium having stored therein computer-executable instructions that, when executed by a processor, implement a blockchain-based transaction consensus method as described above.

In the several embodiments provided in the present disclosure, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described embodiments of the apparatus are merely illustrative, and for example, the division of the modules is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple modules may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or modules, which may be in electrical, mechanical, or other forms.

The modules described as separate components may or may not be physically separate, and components shown as modules may or may not be physical units, may be located in one place, or may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to implement the solution of this embodiment.

In addition, each functional module in the embodiments of the present disclosure may be integrated in one processing unit, or each module may exist alone physically, or two or more modules may be integrated in one unit. The units formed by the modules can be realized in a form of hardware or a form of hardware and software functional units.

The integrated modules, which are implemented in the form of software functional modules, may be stored in a computer readable storage medium. The software functional modules described above are stored in a storage medium and include instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or processor to perform some of the steps of the methods described in the various embodiments of the disclosure.

It should be appreciated that the Processor may be a central processing unit (Central Processing Unit, abbreviated as CPU), or may be other general purpose Processor, digital signal Processor (DIGITAL SIGNAL Processor, abbreviated as DSP), application SPECIFIC INTEGRATED Circuit (ASIC), or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the present invention may be embodied directly in a hardware processor for execution, or in a combination of hardware and software modules in a processor for execution.

The memory may comprise a high-speed RAM memory, and may further comprise a non-volatile memory NVM, such as at least one magnetic disk memory, and may also be a U-disk, a removable hard disk, a read-only memory, a magnetic disk or optical disk, etc.

The bus may be an industry standard architecture (Industry Standard Architecture, ISA) bus, an external device interconnect (PERIPHERAL COMPONENT INTERCONNECT, PCI) bus, or an extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus, among others. The buses may be divided into address buses, data buses, control buses, etc. For ease of illustration, the buses in the drawings of the present disclosure are not limited to only one bus or to one type of bus.

The storage medium may be implemented by any type or combination of volatile or nonvolatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an Application SPECIFIC INTEGRATED Circuits (ASIC). It is also possible that the processor and the storage medium reside as discrete components in an electronic device or a master device.

Those of ordinary skill in the art will appreciate that: all or part of the steps for implementing the method embodiments described above may be performed by hardware associated with program instructions. The foregoing program may be stored in a computer readable storage medium. The program, when executed, performs steps including the method embodiments described above; and the aforementioned storage medium includes: various media that can store program code, such as ROM, RAM, magnetic or optical disks.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present disclosure, and not for limiting the same; although the present disclosure has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some or all of the technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present disclosure.

Claims

1. A blockchain-based transaction consensus method, comprising:

2. The method of claim 1, wherein the parallel transaction execution of the second type of transaction information of the parallel execution queue by the replica node of the blockchain includes:

3. The method of claim 1, wherein storing transaction information in the block at the blockchain landing tray comprises:

4. A method according to any one of claims 1 to 3, wherein after parallel transaction execution of the second type of transaction information of the parallel execution queue by the replica node of the blockchain, further comprising:

5. The method of claim 4, wherein if the number of times of execution of the transaction of the second type is not exceeded by the number of times of execution of the transaction of the parallel execution queue being added to the second type transaction information or the execution failure of the transaction of the second type information being not exceeded by the set threshold, updating the number of times of execution of the transaction into the transaction of the second type information, and re-storing the updated transaction of the second type information into the transaction pool, and broadcasting the transaction of the second type information to other nodes, further comprising:

6. A method according to any one of claims 1 to 3, wherein the transaction information carries the number of transactions performed;

7. A method according to any one of claims 1 to 3, wherein the leader node of the blockchain obtains all transaction information to be executed from the transaction pool and performs virtual transaction execution, and classifies the transaction information into first type transaction information and second type transaction information according to virtual execution results, including:

8. The method of claim 7, wherein the response code that fails execution and is independent of the order of execution of the transactions comprises:

Message analysis type errors and response codes corresponding to intelligent contract binary coding parameter checking errors or parameter abnormality type errors;

9. A method according to any one of claims 1 to 3, wherein the predetermined consensus algorithm comprises one of:

10. A blockchain-based transaction consensus device, comprising:

11. The apparatus of claim 10, wherein the transaction execution module is configured to initiate a thread pool to store the second type of transaction information in the parallel execution queue and to set a plurality of threads; and executing transaction of the second type of transaction information in the thread pool according to the plurality of threads in parallel.

12. The apparatus of claim 10, wherein the block drop module is configured to delete the second type of transaction information of the parallel execution queue in the block; and storing the first kind of transaction information of the serial execution queue in the block chain drop disc.

13. A service apparatus, comprising:

A processor and a memory;

the memory stores computer-executable instructions;

The processor executing computer-executable instructions stored in the memory, causing the processor to perform the blockchain-based transaction consensus method according to any of claims 1 to 9.

14. A computer readable storage medium having stored therein computer executable instructions which when executed by a processor implement the blockchain-based transaction consensus method according to any of claims 1 to 9.