CN112381649A

CN112381649A - Transaction consensus method, device and equipment based on block chain

Info

Publication number: CN112381649A
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: 2021-02-19

Abstract

The embodiment of the disclosure provides a transaction consensus method, a device and equipment based on a block chain, wherein the method comprises the following steps: a leader node of the block chain acquires all transaction information to be executed from the transaction pool and executes the transaction; storing the first type of transaction information and the first execution result into a serial execution queue, and storing the second type of transaction information and the second execution result into a parallel execution queue; and unpacking the block by a copy node of the block chain, performing serial transaction execution on the first type transaction information of the serial execution queue and checking, performing parallel transaction execution on the second type transaction information of the parallel execution queue and checking to obtain a verification result of the block, and completing 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 block chain

Technical Field

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

Background

With the development of computer technology, more and more technologies are applied in the financial field, the traditional financial industry is gradually changing to financial technology (finth), and block chain-based transaction technology is no exception, but higher requirements are also put forward on the technology due to the requirements of security and real-time performance of the financial industry.

In the existing transaction consensus process based on the block chain, in all nodes participating in consensus in the block chain, all transactions in the block need to be executed 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 influenced.

Disclosure of Invention

The embodiment of the disclosure provides a block chain-based transaction consensus method, a block chain-based transaction consensus device and a block chain-based transaction consensus equipment, so as to solve the problems that in the prior art, all transactions in a block are executed in a serial manner, so that the transaction execution efficiency is very low, and the block chain transaction processing efficiency is influenced.

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

in response to the transaction information uploaded by the client, any node of the block chain stores the transaction information into a transaction pool and broadcasts the transaction information to other nodes;

a leader node of the block chain 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 a virtual execution result; the first type of transaction information is transaction information which is successfully executed and transaction information which is failed to execute and is related to a transaction execution sequence are stored in a serial execution queue, and the second type of transaction information is transaction information which is failed to execute and is unrelated to the transaction execution sequence is stored in a parallel execution queue;

a leader node of the block chain 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;

a leader node of the block chain packs the first type of transaction information and the first execution result of the serial execution queue and the second type of transaction information and the second execution result of the parallel execution queue into a block, and sends the block to a copy node of the block chain;

the copy node of the block chain unpacks the block, performs serial transaction execution on the first type transaction information of the serial execution queue and checks the first execution result, performs parallel transaction execution on the second type transaction information of the parallel execution queue and checks the second execution result to obtain a verification result of the block, and broadcasts a message of the verification result to all nodes;

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

In one possible design, the parallel 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 the second type of transaction information of the parallel execution queue, and setting a plurality of threads;

and executing transaction execution on the second type of transaction information in the thread pool according to a plurality of threads respectively in parallel.

In one possible design, the storing the transaction information in the tiles on the tile chain storage disc includes:

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

and storing the first type of transaction information of the serial execution queue in the block in a storage area of the block chain.

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

if the result of the parallel transaction execution of any second type transaction information of the parallel execution queue by the copy node 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, the transaction execution times of the execution failure of the second type transaction information are judged;

if the transaction execution times of the execution failure exceed a set threshold, deleting the second type of transaction information;

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

In a possible design, after the updating the transaction execution times into the second type of transaction information, and storing the updated second type of transaction information into the transaction pool, and broadcasting the second type of transaction information to other nodes, if the second type of transaction information is not added into the parallel execution queue or the transaction execution times of the execution failure of the second type of transaction information does not exceed the set threshold, the method further includes:

the blockchain forcibly triggers view switching based on a preset consensus algorithm so as to replace consensus nodes participating in consensus in the blockchain, wherein the consensus nodes comprise a leader node and a replica node.

In one possible design, the transaction information carries transaction execution times;

after any node of the block chain stores the transaction information into a transaction pool, the method further comprises the following steps:

and if the transaction execution times of the transaction information exceed a set threshold, deleting the transaction information.

In one possible design, the step of acquiring all the transaction information to be executed from the transaction pool by the leader node of the block chain, performing virtual transaction execution, and dividing the transaction information into first-type transaction information and second-type transaction information according to a virtual execution result includes:

calling a virtual machine by a leader node of the block chain to perform trade execution on the trade information to obtain an execution result, wherein the execution result comprises a trade return response code of the trade execution;

if the transaction return response code is a response code which is executed successfully or the response code is a response code which is executed unsuccessfully but related to the transaction execution sequence, determining the transaction information as first-class transaction information;

and if the transaction return response code is a response code which fails to execute and is irrelevant to the transaction execution sequence, determining the transaction information as second type transaction information.

In one possible design, the response code that fails to execute and is independent of the order in which the transactions are executed includes:

a response code corresponding to a message analysis type error, an intelligent contract binary coding parameter check error or an intelligent contract function parameter abnormal type error;

the response code that fails execution but is associated with an order of execution of the transactions, comprising:

and response codes corresponding to execution time resource deficiency errors, control exception errors in the execution process or other unknown errors.

In one possible design, the predetermined consensus algorithm includes one of:

proof of work Pow algorithm, proof of stock Pos algorithm, proof of commission rights DPos algorithm, validation Pool algorithm, and practical byzantine fault-tolerant PBFT algorithm.

In a second aspect, an embodiment of the present disclosure provides a block chain-based transaction consensus apparatus, including:

the system comprises a transaction uploading module, a transaction processing module and a transaction processing module, wherein the transaction uploading module is used for responding to transaction information uploaded by a client, storing the transaction information into a transaction pool by any node of a block chain, 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 block chain, executing virtual transaction, and classifying the transaction information into first-class transaction information and second-class transaction information according to a virtual execution result; the first type of transaction information is transaction information which is successfully executed and transaction information which is failed to execute and is related to a transaction execution sequence are stored in a serial execution queue, and the second type of transaction information is transaction information which is failed to execute and is unrelated to the transaction execution sequence is stored in a parallel execution queue;

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

the block sending module is used for packing the first type of transaction information and the first execution result of the serial execution queue and the second type of transaction information and the second execution result of the parallel execution queue into a block by a leader node of a block chain and sending the block to a copy node of the block chain;

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

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

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

In a possible design, the block destaging module is specifically configured to delete the second type transaction information of the parallel execution queue in the block; and storing the first type of transaction information of the serial execution queue in the block in a storage area of the block chain.

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 computer-executable instructions stored by the memory to cause the processor to perform the blockchain based transaction consensus method as described above in the first aspect and various possible designs of the first aspect.

In a fourth aspect, the embodiments of the present disclosure provide a computer-readable storage medium, in which computer-executable instructions are stored, and when a processor executes the computer-executable instructions, the block chain based transaction consensus method as described in the first aspect and various possible designs of the first aspect is implemented.

In the method, a leader node of the block chain acquires all transaction information to be executed from a transaction pool and executes the transaction, 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 executed successfully and transaction information which is executed unsuccessfully but related to a transaction execution sequence, and the second type of transaction information is transaction information which is executed unsuccessfully and unrelated to the transaction execution sequence; storing the first type of transaction information and the first execution result into a serial execution queue, and storing the second type of transaction information and the second execution result into a parallel execution queue; and unpacking the block by a copy node of the block chain, performing serial transaction execution on the first type transaction information of the serial execution queue and checking, performing parallel transaction execution on the second type transaction information of the parallel execution queue and checking to obtain a verification result of the block, and completing 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 technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present disclosure, and for those skilled in the art, other drawings can be obtained according to the drawings without inventive exercise.

FIG. 1 is a diagram illustrating a list of transaction information in a block according to the prior art;

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

fig. 3 is a schematic flowchart of a block chain-based transaction consensus method according to an embodiment of the present disclosure;

FIG. 4 is a table illustrating transaction information in a block according to an embodiment of the disclosure;

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

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

Detailed Description

To make the objects, technical solutions and advantages of the embodiments of the present disclosure more clear, the technical solutions of the embodiments of the present disclosure will be described clearly and completely with reference to the drawings in the embodiments of the present disclosure, and it is obvious that the described embodiments are some, but not all embodiments of the present disclosure. All other embodiments, which can be derived by a person skilled in the art from the embodiments disclosed herein without making any creative effort, shall fall within the protection scope of the present disclosure.

The technical noun explains:

trading: the intelligent contract calling system is used for calling the intelligent contract and contains necessary information of the intelligent contract, including called contracts, calling input parameters and the like. Wherein the input parameter is encoded binary data. After the intelligent contract is called in the transaction, transaction result information is obtained, including whether the calling is successful or not and a contract return value. Wherein the contract return value is also encoded binary data.

And (3) consensus nodes: the nodes participating in the consensus process in the blockchain comprise a leader node and a replica node.

Leader node (Leader/Primary): the system is responsible for packaging the transaction into blocks and initiating block consensus, and each round of consensus has one leader node.

Copy node (Replica): the system is responsible for completing block consensus, a plurality of replica nodes exist in each round of consensus, and the processing process of each replica node is similar.

View (View): and recording the consensus state of each node, and maintaining a node list of the same leader node and the same replica node by the same view node. When the leader node fails, a view switch can occur.

The transaction processing modules of the blockchain may be abstracted as a transaction-based state machine. The state refers to the state of all accounts in the blockchain, and the blockchain takes the transaction as a state transition function and updates the old state to the new state according to the transaction content. And starting the blockchain from the creation blockstate, continuously collecting trades occurring on the blockchain network, sequencing and packaging the trades into blocks by the leader node, and executing trades in the blocks among all the consensus nodes participating in consensus. When the transaction in a block is completed and the status is consistent at a plurality of common nodes, it is said that common identification is achieved on the block, and the block is permanently recorded in the blockchain, completing the blockchain.

As can be appreciated from the packing → consensus → storage process of the blockchain, all transactions in a block are performed as a must-go route for the chain of blocks. The conventional block chain transaction consensus process at present is as follows: taking out a certain amount of transactions from the transaction pool by a leader node of the block chain, sequencing the transactions, and packaging the transactions into a block of a transaction list, as shown in fig. 1, wherein each block m comprises transactions sequenced according to a transaction sequence, including transaction 1, transaction 2 and transaction 3. And then the leader node main node broadcasts and sends the broadcast to all the replica nodes participating in the consensus to perform the consensus. As shown in fig. 2, the replica node reads out the transactions from the transaction list of the block one by one, and after each transaction is executed, the state machine will transition to the next state until all transactions are executed serially.

However, in the prior art, all transactions in the block are executed in a serial manner, which results in very low transaction execution efficiency and affects the processing efficiency of the blockchain transaction.

In order to solve the above technical problem, an embodiment of the present disclosure provides the following technical solutions: a leader node of the block chain 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 a virtual execution result; the first type of transaction information is transaction information which is executed successfully and transaction information which is executed unsuccessfully but related to a transaction execution sequence, and the second type of transaction information is transaction information which is executed unsuccessfully and unrelated to the transaction execution sequence; a leader node of the block chain 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 packs the second type of transaction information and the second execution result into a block; the block chain copy node 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 block verification result.

Referring to fig. 3, fig. 3 is a schematic flowchart of a block chain-based transaction consensus method according to an embodiment of the present disclosure. The present embodiment is applied to a blockchain of a server, where the blockchain includes a consensus node, where the consensus node includes a leader node and a plurality of replica nodes, and the method is detailed as follows:

s301: and responding to the transaction information uploaded by the client, storing the transaction information into the transaction pool by any node of the block chain, and broadcasting the transaction information to other nodes.

In this embodiment, the client may be any client that has a transaction behavior, and the client generates transaction information according to the transaction behavior and sends the transaction information to any node of the block chain. For example, a user purchases a commodity in an online shopping mall, a transaction is completed through a client, and the client sends transaction information of the purchased commodity to any node of the block chain.

In this embodiment, any node of the blockchain is any node of the common nodes in the blockchain. The leader node is elected from the consensus nodes of the blockchain. Any consensus node can be either a leader node or a replica node.

S302: a leader node of the block chain 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 a virtual execution result; the first type of transaction information is transaction information which is successfully executed and transaction information which is failed to execute and is related to the transaction execution sequence are stored in the serial execution queue, and the second type of transaction information is transaction information which is failed to execute and is unrelated to the transaction execution sequence is stored in the parallel execution queue.

In this embodiment, the leader node obtains all the transaction information to be executed. Specifically, the leader node first generates a new empty block, then acquires all the 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 block chain calls a virtual machine to perform trade execution on trade information to obtain a virtual execution result of the virtual machine, wherein the execution result includes a trade return response code of the trade execution; if the transaction return response code is a response code which is executed successfully or the response code is a response code which is executed unsuccessfully but related to the transaction execution sequence, determining the transaction information as first-class transaction information; and if the transaction return response code is a response code which fails to execute and is irrelevant to the transaction execution sequence, determining the transaction information as second type transaction information.

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

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

S303: and the leader node of the block chain 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 a leader node of the block chain packs the first type of transaction information and the first execution result of the serial execution queue and the second type of transaction information and the second execution result of the parallel execution queue into a block, and sends the block to a copy node of the block chain.

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

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

S305: and the duplicate node of the block chain unpacks the block, performs serial transaction execution on the first type of transaction information of the serial execution queue and checks the first execution result, performs parallel transaction execution on the second type of transaction information of the parallel execution queue and checks the second execution result to obtain a verification result of the block, and broadcasts a message of the verification result to all nodes.

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

In this embodiment, a thread single thread is started, and the process of performing serial transaction execution on the first type transaction information of 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 transaction information of the parallel execution queue by the replica node of the blockchain includes: starting a thread pool, storing second-class transaction information of a parallel execution queue, and setting a plurality of threads; and executing transaction execution on the second type of transaction information in the thread pool in parallel according to the plurality of threads respectively 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 verification result of the block 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: starting a consensus process based on a preset consensus algorithm, and if the number of messages with the same verification result received by other nodes of the block chain reaches a preset threshold value, storing the transaction information in the block chain in a storage manner.

In this embodiment, the predetermined consensus algorithm includes one of the following: proof of work Pow algorithm, proof of stock Pos algorithm, proof of commission rights DPos algorithm, validation Pool algorithm, and practical byzantine fault-tolerant PBFT algorithm.

In this embodiment, the requirements of different algorithms are different when the number of messages reaches the preset threshold. The number of the common nodes can be half plus one (2 x f +1) or one third plus one (3 x f + 1).

As can be seen from the description of the above embodiment, the leader node of the block chain acquires all the transaction information to be executed from the transaction pool, executes the transaction, and divides the transaction information into the first type transaction information and the second type transaction information according to the execution result; the first type of transaction information is transaction information which is executed successfully and transaction information which is executed unsuccessfully but related to a transaction execution sequence, and the second type of transaction information is transaction information which is executed unsuccessfully and unrelated to the transaction execution sequence; storing the first type of transaction information and the first execution result into a serial execution queue, and storing the second type of transaction information and the second execution result into a parallel execution queue; and unpacking the block by a copy node of the block chain, performing serial transaction execution on the first type transaction information of the serial execution queue and checking, performing parallel transaction execution on the second type transaction information of the parallel execution queue and checking to obtain a verification result of the block, and completing 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 an embodiment of the present disclosure, in the process of dropping disk storage in the blockchain, the transaction information in the block may delete the second type of transaction information in the parallel execution queue in the block; and storing the first type of transaction information of the serial execution queue in the block in a storage area of the block chain.

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

In an embodiment of the present disclosure, in step S304, after the parallel transaction execution is performed on the second type transaction information of the parallel execution queue by the replica node of the block chain, the method further includes:

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

In this embodiment, the second type of transaction information of the parallel execution queue is transaction information of which the execution result is execution failure after the leader node performs the transaction execution, and the result of performing the parallel transaction execution on the second type of transaction information of the parallel execution queue by the replica node is execution success, which indicates that the transaction information may be misjudged.

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

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

In this embodiment, the number of times of executing the transaction for determining that the execution of the transaction information fails may be: and acquiring the times that the execution result of the transaction information is the execution failure through the historical execution result in the transaction information.

S308: and if the execution times of the transaction which fails to be executed exceed the set threshold value, deleting the second type of transaction information.

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

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

In this embodiment, the updated trading information is stored in the trading pool again, the trading information is broadcasted to other nodes, the updated trading information becomes new to-be-executed trading information, and the leader node participating in the blockchain continuously acquires all the to-be-executed trading information from the trading pool and executes the trading.

As can be seen from the description of the above embodiment, by verifying whether there is a transaction misjudged by the common node in the parallel transaction queue, the transaction information having the misjudgment is re-sent to the transaction pool to be re-executed again by the master node, thereby avoiding the misjudgment of the node on the transaction information; meanwhile, the transaction information which exceeds a certain number of transaction execution times of execution failure is deleted, so that the data amount stored in the memory block chain is further saved.

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

s310: the blockchain forcibly triggers view switching based on a preset consensus algorithm so as to replace consensus nodes participating in consensus in the blockchain, wherein the consensus nodes comprise a leader node and a replica node.

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

In one embodiment of the present disclosure, the transaction information carries transaction execution times; after any node of the block chain of the step S301 stores the transaction information into the transaction pool, the method further includes:

s311: and if the transaction execution times of the transaction information exceed 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 repeated executed transactions are avoided, and the processing efficiency of the block chain is reduced.

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

The first stage is as follows: the client submits the transaction information, any node of the block chain stores the transaction information into a transaction pool, and the transaction information is broadcasted to other nodes.

In the transaction pool of the node, a transaction root (a hash value calculated for transaction binary data) and transaction execution times for which a transaction has been executed are cached. For the transaction information to be executed, if a failure queue (parallel execution queue) is added before, the times of adding the transaction information into the block and executing the transaction information are 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 times is 0.

And a second stage: and the leader node packs the new blocks.

In the PBFT algorithm, the nodes are identified in a round of outflow blocks, each round of identification only has one leader node packaging block, and a new empty block is generated. The leader node mainly comprises the following steps:

step 1, generating a new empty block: the current highest chunk (the 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, packaging transaction information from the transaction pool: and after the new empty block is generated, acquiring the transaction information from the transaction pool, and inserting the acquired transaction information into the generated new block.

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

Step 3, assembling a new block: and setting the packaging node of the new block as a leader node, and calling the virtual module to execute the transaction according to the packaged transaction information to obtain an execution result of the transaction information.

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

transfactionhash: a transaction hash;

index is the transaction sequence number;

gasUsed: a hash of transaction execution consumption;

from: the address of the transaction caller;

to: a destination address of the transaction call;

input: input binary code for transaction execution;

output: a binary code of the transaction execution output;

logs: logging during transaction execution;

logsBloom: recording topic retrieval information of a transaction log;

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

The execution result includes the transaction return response code, which includes both the execution success response code (the transaction return response code of the transaction information whose execution result is successful), and the transaction return response code of the transaction information whose execution result is failed. The transaction return response codes for transaction information that fails to execute can be classified into the following types:

1) and analyzing the response code of the type error by the message. Such as block RLP parsing failure, invalid transaction formats, transaction format error exceptions.

2) The smart contract binary encodes a response code whose parameters are checked for errors. Such as deployment contract length exceeding the gas limit, invocation contract interface parameters exceeding the gas limit, invocation contract parameters being too long, deployment contract length exceeding the longest limit, transaction format errors, etc.

3) A parameter exception response code. Such as invalid signatures, invalid nonces, faulty instructions, faulty exception jumps, invalid chain ID exceptions, absence of called contract addresses, etc.

4) Response code that performs an execution resource insufficiency error. Such as insufficient transfer balance, insufficient GasLimit, gas deployment during contract execution, stack overflow exceptions, etc

5) And executing the response code of the control exception in the process. Such as a reverse exception, an unauthorized exception, an illegal deployment contract, an illegal transaction, a contract being frozen, an account being frozen, etc.

6) Other unknown error response codes. Such as unknown anomalies.

For the transaction return response code of the transaction information with execution failure, the response code which is irrelevant to the transaction execution sequence comprises the following components: a response code corresponding to a message analysis type error, an intelligent contract binary coding parameter check error or an intelligent contract function parameter abnormal type error; the response codes associated with the transaction execution order include: and response codes corresponding to execution time resource deficiency errors, control exception errors in the execution process or other unknown errors. The response codes associated with the transaction execution order correspond to transaction information associated with the transaction execution order, such as: there are two transfer transactions, A to B and B to C. Assuming that the amount of the two transfers is the same, the balance of the primary account B is 0, and the account A has sufficient primary balance; then if the transfer of a to B is performed first and then the transfer of B to C is performed, the transaction is successful, otherwise, the transaction fails.

Therefore, after the execution of the transaction information is completed, the leader node distinguishes failure types for all transaction information which fails to be executed according to the transaction return response codes of the execution result. And determining whether the failure of the transaction is related to the transaction sequence according to the type of the transaction return response code.

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

The transaction information which is executed successfully and the transaction information which is executed unsuccessfully but related to the transaction execution sequence are stored in the serial execution queue, and the transaction information which is executed unsuccessfully and unrelated to the transaction execution sequence is stored in the parallel execution queue.

The leader node carries out transaction execution on the transaction information in the serial execution queue according to the serial to obtain a first state root (state root) of the serial execution queue; and the leader node carries out transaction execution on the transaction information in the parallel execution queue according to the parallel 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 execution result of the serial transaction queue does not contain the transaction which fails to be executed, all the state roots are equal to the valid state root.

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

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

And a third stage: replica node pre-preparation phase (pre-prepair phase).

After receiving the prefix package, the replica node enters a pre-prefix stage, and the main work flow of the stage comprises the following steps:

step 1, determining the validity of the prefix package: it is determined whether the packet is a duplicate prepare packet, whether the parent hash of the block contained in the prepare request is the current node highest block hash (prevent forking), and whether the block height of the block contained in the prepare request is equal to the highest block height plus one.

Step 2, judging empty blocks: the prefix request contains a block with a transaction number of 0, triggering an empty block view switch and broadcasting a view switch 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 prefix request is larger than 0, calling a block executor to execute the block, and caching the executed block.

In this embodiment, the transaction information in the block is executed as follows: the copy node resolves a serial execution transaction queue and a parallel execution queue in the block based on a queue type identifier (queueType) in the transaction information list, and for the serial execution queue, serial execution is performed by using a thread. And for the parallel execution queue, simultaneously starting a thread pool, setting a plurality of threads, and executing the transaction in the thread pool in parallel.

For example, in fig. 4, transaction 2 is a transaction in which execution has failed in the consensus node, but the failure type belongs to transactions that are strongly related to the transaction order. While all transactions in the parallel queue are of the type that failed and the failure type is independent of the transaction order. Thus, transactions in the serial queue are executed in sequence according to the ordering of the serial queue in the block. The transactions in the parallel queue can be executed simultaneously and in parallel, and the execution order is uncertain, and the transactions can be executed in any order.

After the execution is completed, the consensus node assembles the signature packet. Besides the original block content, the block also comprises a serial execution queue and a state root of 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 results of the state roots of the serial execution queue are two, one is an all state root containing the failed transaction, and the other is a valid state root not containing the failed transaction. If the result of the serial transaction queue execution does not contain the transaction with execution failure, the all state root is equal to the valid state root.

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

A fourth stage: and a common node preparation phase.

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

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

Step 2, judging the signature packet result: after the consensus node receives the signature packet, the content of the signature packet is compared with other received signature packets and cached.

In this embodiment, it is determined whether the signature packets corresponding to the blocks of the pre-prepare stage cache are equal to valid state root of the serial execution queue corresponding to the signature packets, and if the cache reaches 2 × f +1, the commit packet is broadcasted: if the number of signature packets corresponding to the block hash of the pre-prepare stage cache exceeds 2 f +1, it indicates that most nodes execute the block, and the execution result is consistent, which indicates that the node has reached the state of being able to submit the block, and starts to broadcast the commit packet.

If the number of signature packets of all state roots of the collected equal parallel execution queues exceeds 2 f +1, it means that most nodes execute all queues in the block, and the execution results are consistent. At this time, if the transaction information successfully executed exists in the parallel queue, it is determined whether the transaction information is added to the parallel execution queue before. If the queue has been added previously, the number of failures is counted. When a certain threshold value is exceeded, discarding the transaction information no matter whether the transaction information is successful or not; otherwise it is put into the transaction pool and broadcast to all other nodes. Meanwhile, if the failed transaction is rebroadcast to other nodes, view switching is forcibly triggered, and the consensus node is replaced. (this step is mainly to find and verify whether there is transaction information misjudged by the common node in the parallel transaction queue, if there is misjudgment, the new common node packs the transaction misjudged in the next common stage again, at the same time, records the number of times of the packed common execution of the transaction, when exceeding a certain threshold, the transaction information is forcibly abandoned.)

Step 3, if full signature packages are collected, backing up the prefix package disk cached in the pre-prefix stage: in order to prevent the commit stage blocks from being down by more than 2 f +1 nodes before the commit stage blocks are not submitted to the database, the nodes are restarted and then go out of blocks, so that block chains are forked (the latest blocks of the remaining nodes are different from the highest blocks of the nodes), and the prefix packages cached in the pre-prefix stage are required to be backed up to the database, and the backed-up prefix packages are processed preferentially after the nodes are restarted.

The fifth stage: commit phase (commit phase).

After receiving the commit packet, the consensus node enters a commit stage, and the working process of the commit stage comprises the following steps:

and (3) judging the validity of the commit packet: the method mainly comprises the steps of judging that the hash of a commit packet is the same as the block hash after the execution of pre-prefix stage cache, if the hash of the commit packet is not the same as the block hash after the execution of the pre-prefix stage cache, judging that the commit packet is an illegal commit request, and directly rejecting the request by a node; judging whether the commit packet cache corresponding to the block of the pre-prepare stage cache reaches 2 f +1, if the commit packet is collected, dropping the new block into the disk: if the number of commit requests corresponding to the block hash of the pre-prepare stage cache exceeds 2 f +1, the fact that most nodes can submit the block is shown, and the execution results are consistent, the block of the pre-prepare stage cache is written into a database; when the disk is dropped, the node discards all transaction information which fails to be executed in the parallel execution queue, and only discards the transaction information in the serial queue.

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

The transaction uploading module 501 is configured to, in response to the transaction information uploaded by the client, store the transaction information into a transaction pool by any node of the block chain, and broadcast the transaction information to other nodes;

the trade classification module 502 is used for acquiring all trade information to be executed from the trade pool by a leader node of the block chain, executing virtual trade, and classifying the trade information into first-class trade information and second-class trade information according to a virtual execution result; the first type of transaction information is transaction information which is successfully executed and transaction information which is failed to execute and is related to a transaction execution sequence are stored in a serial execution queue, and the second type of transaction information is transaction information which is failed to execute and is unrelated to the transaction execution sequence is stored in a parallel execution queue;

the trade execution module 503 is configured to perform serial trade execution on the first type of trade information of the serial execution queue by using a leader node of the block chain to obtain a first execution result, and perform parallel trade execution on the second type of trade information of the parallel execution queue to obtain a second execution result;

a block sending module 504, configured to pack, by a leader node of a block chain, the first type of transaction information and the first execution result of the serial execution queue, and the second type of transaction information and the second execution result of the parallel execution queue into a block, and send the block to a copy node of the block chain;

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

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

The apparatus provided in this embodiment may be used to implement the technical solutions of the above method embodiments, and the implementation principles and technical effects are similar, which are not described herein again.

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

In an embodiment of the present disclosure, the block dropping 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: a misjudgment verification module 507, configured to determine whether the second type transaction information is added to the parallel execution queue if the result of performing parallel transaction execution on any second type transaction information of the parallel execution queue by the replica node is that execution is successful; if the second type transaction information is added into the parallel execution queue, the transaction execution times of the execution failure of the second type transaction information are judged; if the transaction execution times of the execution failure exceed a set threshold, deleting the second type of transaction information; if the second type transaction information is not added into the parallel execution queue or the transaction execution times of the execution failure of the second type transaction information do not exceed the set threshold, updating the transaction execution times into the second type transaction information, storing the updated second type transaction information into the transaction pool again, and broadcasting the second type transaction information to other nodes.

In one embodiment of the present disclosure, the apparatus further comprises: and a view switching module 508, configured to force, by the blockchain, view switching based on a preset consensus algorithm, so as to replace consensus nodes participating in consensus in the blockchain, where the consensus nodes include a leader node and a replica node.

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

In an embodiment of the present disclosure, the transaction classification module 502 is specifically configured to invoke a virtual machine by a leader node of a block chain to perform transaction execution on 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 a response code which is executed successfully or the response code is a response code which is executed unsuccessfully but related to the transaction execution sequence, determining the transaction information as first-class transaction information; and if the transaction return response code is a response code which fails to execute and is irrelevant to the transaction execution sequence, determining the transaction information as second type transaction information.

Referring to fig. 6, fig. 6 is a schematic diagram of a 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

A memory 602 for storing computer-executable instructions;

the processor 601 is configured to execute the 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 description relating to the method embodiments 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 the memory 602 and the processor 601.

The embodiment of the present disclosure also provides a computer-readable storage medium, in which computer-executable instructions are stored, and when a processor executes the computer-executable instructions, the block chain-based transaction consensus method as described above is implemented.

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 device embodiments are merely illustrative, and for example, the division of the modules is only one logical division, and other divisions may be realized in practice, for example, a plurality of modules may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or modules, and may be in an electrical, mechanical or other form.

The modules described as separate parts may or may not be physically separate, and parts displayed as modules may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to implement the solution of the present embodiment.

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

The integrated module implemented in the form of a software functional module may be stored in a computer-readable storage medium. The software functional module is stored in a storage medium and includes several instructions to enable a computer device (which may be a personal computer, a server, or a network device) or a processor to execute some steps of the methods according to the embodiments of the present disclosure.

It should be understood that the Processor may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), etc. 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, or in a combination of the hardware and software modules within the processor.

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

The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (Extended Industry Standard Architecture) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, the buses in the figures of the present disclosure are not limited to only one bus or one type of bus.

The storage medium may be implemented by any type or combination of volatile or non-volatile 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 disks. 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. Of course, the storage medium may also be integral to the processor. The processor and the storage medium may reside in an Application Specific Integrated Circuits (ASIC). Of course, the processor and the storage medium may reside as discrete components in an electronic device or host device.

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

Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present disclosure, and not for limiting the same; while the present disclosure has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art will understand that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present disclosure.

Claims

1. A block chain based transaction consensus method is characterized by comprising the following steps:

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 comprises:

3. The method of claim 1, wherein storing the transaction information in the tiles on a disk in the tile chain comprises:

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

5. The method according to claim 4, wherein if the number of times of execution of the transaction in which the second type of transaction information is not added to the parallel execution queue or the execution of the second type of transaction information fails does not exceed the set threshold, updating the number of times of execution of the transaction to the second type of transaction information, and storing the updated second type of transaction information into the transaction pool, and after broadcasting the second type of transaction information to other nodes, the method further comprises:

6. The method according to any one of claims 1 to 3, wherein the transaction information carries transaction execution times;

7. The method according to any one of claims 1 to 3, wherein the step of acquiring all the transaction information to be executed from the transaction pool by the leader node of the block chain and performing virtual transaction execution, and dividing the transaction information into first-type transaction information and second-type transaction information according to a virtual execution result comprises:

8. The method of claim 7, wherein the response code that fails to execute and is independent of the order in which the transactions are executed comprises:

a response code corresponding to the message analysis type error, the intelligent contract binary coding parameter check error or the parameter abnormal type error;

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

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

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

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

13. A service device, comprising:

a processor and a memory;

the memory stores computer-executable instructions;

the processor executing the computer-executable instructions stored by the memory causes the processor to perform the blockchain based transaction consensus method of any one of claims 1 to 9.

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