A blockchain consensus process optimization method

Abstract

The present invention discloses a method for optimizing the consensus process of blockchain, including: the master node pre-packs a pre-block; the pre-block indicates that the transaction in the block has not been executed, and the pre-block contains a transaction list and complete block header information; after the slave node verifies the pre-block, a consensus vote is performed on the pre-block; after the consensus vote is completed, the block submission phase is entered, and the master and slave nodes execute the transactions in the block. In this process, in order to ensure the consistency of the execution results of the master and slave nodes, a deterministic transaction scheduling algorithm is required. In order to prevent nodes from doing evil and causing inconsistent states between nodes, the block will be triggered to fall into the warehouse only after the consensus is reached on the block of the next height. The method optimizes and transforms the blockchain consensus process, realizes a parallel transaction solution between nodes on the premise of ensuring the consistency of the account book and the activity of the system, and improves the processing performance of the blockchain.

Description

Technical Field

[0001] The present invention relates to the field of blockchain consensus technology, and more specifically to a blockchain consensus process optimization method. Background Art

[0002] At present, in the blockchain world, due to its decentralized blockchain design, nodes are scattered and parallel everywhere, so a system must be designed to maintain the operating order and fairness of the system, unify the blockchain version, and reward users who provide resources to maintain the blockchain, and punish malicious harm. Such a system must rely on some way to prove who has obtained the packaging right (or accounting right) of a blockchain and can obtain the reward for packaging this block; or whoever intends to harm will receive a certain punishment, which is the consensus mechanism. Therefore, the consensus mechanism solves the following problems: maintaining the operating order and fairness of the system; maintaining the stable operation of the system through rewards and punishments.

[0003] Related document CN112118321A discloses a practical Byzantine fault-tolerant consensus mechanism optimization system for industrial blockchain. A node screening strategy is proposed to select high-performance consensus nodes to participate in the consensus, solving the performance degradation problem caused by too many nodes under the Byzantine consensus of industrial blockchain. However, this solution cannot detect node malicious behavior in time, and if a node malicious behavior or a smart contract random number attack occurs, the node cannot recover by itself, affecting the activity of the blockchain and making it difficult to use in an actual production environment.

[0004] The common practice at present is that when the master node packs the block, it completes the execution of the transactions in the block and calculates the relevant hashes, including but not limited to the transaction hashes, transaction Merkle trees, etc., and then broadcasts them to the slave nodes. The slave nodes re-execute the transactions in the block locally and perform hash calculations. Then they compare the hashes broadcast by the master node to see if they are consistent, and broadcast their own voting results. Figure 1 As shown. However, transactions between the master and slave nodes are executed serially. Before the master node broadcasts the block, the slave node is in the idle stage; after the master node broadcasts the block, the master node is in the idle stage. The time of the consensus stage is not fully utilized, resulting in a certain waste of resources.

[0005] Therefore, how to optimize the blockchain consensus process and improve the processing performance of the blockchain is an urgent problem that technical personnel in this field need to solve. Summary of the invention

[0006] In view of this, the present invention provides a blockchain consensus process optimization method, which can solve the problems of optimization and low processing performance of the above-mentioned blockchain consensus process. The method optimizes and transforms the blockchain consensus process, and realizes a parallel transaction solution between nodes while ensuring the consistency of the ledger and the activity of the system, thereby improving the processing performance of the blockchain.

[0007] In order to achieve the above object, the present invention adopts the following technical solution:

[0008] The present invention provides a blockchain consensus process optimization method, comprising the following steps:

[0009] S10, the master node pre-packs a pre-block; the pre-block indicates that the transaction in the block has not been executed, and the pre-block contains a transaction list and complete block header information;

[0010] S20, after the slave node verifies the pre-block, a consensus vote is performed on the pre-block;

[0011] S30: After the consensus vote is completed, the block submission phase begins, and the master and slave nodes execute the transactions in the block.

[0012] Furthermore, the step S10 includes:

[0013] S101, the master node obtains valid transactions to be packaged;

[0014] S102, the master node packages the acquired transactions, generates a pre-block, and processes the pre-block; the pre-block indicates that the transactions in the block have not been executed, and the pre-block contains a transaction list and complete block header information;

[0015] S103: The master node broadcasts the pre-block to all slave nodes.

[0016] Furthermore, the pre-block is processed, including: pre-block hash calculation, candidate block hash calculation, pre-block hash signature and candidate block signature.

[0017] Furthermore, the pre-block hash calculation includes:

[0018] When packaging the Nth block, the master node reads the block hash of the N-1th block from the local cache; the block hash of the N-1th block contains the execution result of the transaction;

[0019] Assigning the block hash of the N-1th block to the pre-block hash field of the pre-block;

[0020] A hash calculation is performed on the pre-block to obtain a pre-block hash.

[0021] Furthermore, the candidate block hash calculation includes:

[0022] When all transactions in the N-1th block are set to fail, the master node recalculates the block hash of the N-1th block, and the block hash will be used in the pre-block hash field of the Nth block;

[0023] Assigning the recalculated pre-block hash to the pre-block hash field of the pre-block;

[0024] A hash calculation is performed on the pre-block to obtain a hash of the candidate block.

[0025] Furthermore, the step S20 includes:

[0026] S201, the slave node checks whether the pre-block hash field in the pre-block is consistent with the local one. If it is inconsistent, the slave node uses the alternative block hash;

[0027] S202, the slave node verifies the remaining important information in the pre-block, including: pre-block hash, transaction Merkle tree;

[0028] S203. When the slave node uses the candidate block hash, the slave node needs to obtain the previous block hash based on the local, recalculate the hash of the current block, and put it into the block;

[0029] S204: After the slave node passes the verification, it will sign the block and broadcast the voting signature to other consensus nodes.

[0030] Furthermore, the step S30 includes:

[0031] S301: After the consensus vote is completed, the master node and the slave node collect voting signatures for the final block. After collecting enough votes, they enter the block submission phase.

[0032] S302: During the block submission phase, the persistence processing logic for the previous block will be triggered, and the data of the previous block will be processed according to the consensus result and stored in the database.

[0033] Furthermore, the step S302 further includes:

[0034] In the block submission phase, if the hash of the previous block in the Nth block to be submitted is inconsistent with the block hash of the N-1th previous block in the local cache, the N-1th block in the local cache is discarded; the discarding process includes: setting the transaction execution result in the N-1th block to empty and marking the N-1th block as invalid.

[0035] Furthermore, it also includes:

[0036] S40. If the collected voting signatures do not meet the consensus requirements, then this round of consensus has not reached a consensus, the master node is re-selected, a new round of proposals is started, and steps S10 to S40 are repeated.

[0037] It can be known from the above technical solution that compared with the prior art, the present invention discloses a method for optimizing the consensus process of blockchain, including: the master node pre-packs a pre-block; the pre-block indicates that the transaction in the block has not been executed, and the pre-block contains a transaction list and complete block header information; after the slave node verifies the pre-block, a consensus vote is performed on the pre-block; after the consensus vote is completed, the block submission phase is entered, and the master and slave nodes execute the transactions in the block. In this process, in order to ensure the consistency of the execution results of the master and slave nodes, a deterministic transaction scheduling algorithm is required. In order to prevent nodes from doing evil and causing inconsistent states between nodes, the block will be triggered to fall into the warehouse only after the consensus is reached on the next high block. This method optimizes and transforms the blockchain consensus process, and realizes a parallel transaction solution between nodes on the premise of ensuring the consistency of the ledger and the activity of the system, thereby improving the processing performance of the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0039] Figure 1 This is a timing diagram of the blockchain consensus process in the prior art.

[0040] Figure 2 Flowchart of the blockchain consensus process optimization method provided by an embodiment of the present invention.

[0041] Figure 3 This is a timing diagram of the blockchain consensus process optimization provided by an embodiment of the present invention.

[0042] Figure 4 A block process optimization swim lane diagram provided for an embodiment of the present invention. DETAILED DESCRIPTION

[0043] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0044] In order to clearly explain the technical solution of the present invention, the technical terms involved are first listed as follows:

[0045] Master node: A node responsible for proposing blocks in a round of blockchain consensus.

[0046] Slave node: A node responsible for verifying the proposal of the master node in a round of blockchain consensus.

[0047] Consensus node: A node that participates in consensus in the blockchain, including master nodes and slave nodes.

[0048] Pre-block: The block packaged and broadcasted by the master node in the technical solution of the present invention is essentially different from a normal block in that the transactions in the block have not been executed.

[0049] Abandoned blocks: After the next block (N) is submitted, if the hash of its previous block (N-1) is found to be inconsistent with the hash of the previous block (N-1) in the cache, the block (N-1) is considered to be abandoned. That is, the transaction execution results in the block (N-1) are set to empty, and the transactions in the block (N-1) will not affect the world state of the blockchain.

[0050] Alternative block hash: A concept proposed in the technical solution of the present invention, which is essentially a block hash, except that the preceding block hash in the block is calculated using the preceding block hash calculated by the abandoned block.

[0051] Block Hash: (Block Hash) refers to a fixed-length string generated by a block header through a hash algorithm. In blockchain technology, each block contains some transaction information and a block header, and the block header contains some important information, such as the hash value of the previous block, transaction timestamp, target difficulty value, etc. When a new block is created, its block header will be hashed to generate a fixed-length hash value, which can uniquely identify the block and is also used to verify whether the block has been tampered with. If any transaction or block header in the block is modified, its hash value will also be changed, making the block invalid.

[0052] Final block hash: The concept in the technical solution of the present invention refers to the hash of the block recalculated after consensus is reached and transactions are executed in the submission phase. This hash is the final block hash that needs to be persisted.

[0053] Transaction Merkle Tree: (Merkle Tree) is a data structure used to verify the integrity of transactions in the blockchain. Its essence is a binary tree, whose leaf nodes are the hash values ​​of each transaction, and each non-leaf node is the hash value of the concatenation of the hash values ​​of its left and right child nodes. In this way, the root node of the entire transaction Merkle tree is the hash value of the concatenation of all transaction hash values, called the Merkle Root. When a node wants to verify whether a transaction is included in a block, it only needs to verify whether the hash value of the transaction and all the hash values ​​calculated layer by layer from the leaf node where the transaction is located are consistent with the Merkle root in the block header. By using the transaction Merkle tree, the blockchain can greatly improve the efficiency of transaction verification and reduce the waste of computing resources while ensuring security. At the same time, if any transaction in the block is tampered with, its corresponding hash value will also change, resulting in changes in the structure and Merkle root of the entire transaction Merkle tree, so that the block is rejected by other nodes, ensuring the security of the blockchain.

[0054] Reference Figure 2 As shown, the embodiment of the present invention discloses a blockchain consensus process optimization method, comprising the following steps:

[0055] S10, the master node pre-packs a pre-block; the pre-block indicates that the transaction in the block has not been executed, and the pre-block contains a transaction list and complete block header information;

[0056] S20, after the slave node verifies the pre-block, a consensus vote is performed on the pre-block;

[0057] S30: After the consensus vote is completed, the block submission phase begins, and the master and slave nodes execute the transactions in the block;

[0058] S40. If the collected voting signatures do not meet the consensus requirements, then this round of consensus has not reached a consensus, the master node is re-selected, a new round of proposals is started, and steps S10 to S40 are repeated.

[0059] In this embodiment, the master node first packages the pre-block, which contains a transaction list and complete block header information for the slave node to verify the legitimacy of the pre-block. After the slave node verifies the pre-block, it performs a consensus vote on the pre-block. After the consensus vote is completed, it enters the block submission phase, and the master and slave nodes execute the transactions in the block. In this process, in order to ensure the consistency of the execution results of the master and slave nodes, a deterministic transaction scheduling algorithm is required. In order to prevent nodes from doing evil and causing inconsistent states between nodes, the storage of this block will be triggered only after the consensus of the block at the next height is reached.

[0060] Reference Figure 3As shown in FIG. 1 , it is a timing diagram of the blockchain consensus process optimization provided by the present invention, and the specific steps are as follows:

[0061] 1) The master node obtains a batch of valid transactions to be packaged. In the embodiment of the present invention, the consensus node is a node with the right to propose blocks and vote on blocks; valid transactions refer to transactions that have not expired, have not been repeated, and have passed signature verification. Specifically, the master node will obtain a batch of valid transactions from the transaction pool module of this node (the master node itself) (the transaction pool is mainly responsible for caching transactions sent by the client to the blockchain node) (these transactions will be subject to signature verification, duplicate verification, validity period verification, etc. before entering the transaction pool), and these valid transactions are the data to be packaged. The process of transaction packaging is to put the transactions obtained from the transaction pool into the block at the new height, and finally obtain the transaction Merkle root by performing pairwise hash calculations on each transaction.

[0062] The meaning of the proposal block is: a new round of proposals initiated by the master node. The content of the proposal is: whether a consensus has been reached on the proposal block. If a consensus is reached, the proposal block will become a consensus block and will eventually be stored in the database and become a valid block.

[0063] 2) The master node packages the acquired transactions, generates a pre-block, and processes the pre-block, including but not limited to pre-block hash calculation, candidate block hash calculation, pre-block hash signature, candidate block signature, etc.

[0064] Among them, the pre-block hash calculation rules are:

[0065] a. Get the first previous block hash (this previous block hash contains the execution result of the transaction);

[0066] b. Assign a value to the pre-block hash field of the pre-block;

[0067] c. Perform hash calculation on the pre-block to obtain the pre-block hash.

[0068] The first preceding block hash is stored in the cache of each node. The first preceding block hash is the final hash of the previous block of the current node, but it is not necessarily the final hash of the database. For example:

[0069] When the current master node is packaging the Nth block, it will read the block hash of the N-1th block from the local cache and use the hash as the pre-hash of the Nth block. When the slave node verifies the pre-block N, it will verify whether the pre-block hash of block N is consistent with that of the current node (this slave node). If not, the verification of pre-block N fails, and consensus cannot be reached on the N-1th block. The alternative block N' should be used.

[0070] Alternative block hash calculation rules:

[0071] a). Get the second previous block hash (this previous block hash does not contain the execution result of the transaction);

[0072] b). Assign a value to the pre-block hash field of the pre-block;

[0073] c). Perform hash calculation on the pre-block to obtain the candidate block hash.

[0074] The second previous block hash is not stored but calculated by the node itself (after all transactions in block N-1 are set to failed, the second previous block hash is recalculated).

[0075] In the subsequent judgment process, whether the first previous block hash or the second previous block hash is used as the final hash depends on whether the first previous block hash is recognized by the majority of nodes (the specific number of nodes depends on the consensus type) (whether the first previous block hash is recognized to be consistent with the first previous block hash calculated by these nodes themselves).

[0076] That is, the final hash is determined by the approval of the majority of consensus nodes. If approved, the first previous block hash is used; otherwise, the second previous block hash is used.

[0077] 2) The master node broadcasts the pre-block to all slave nodes.

[0078] 3) Verify the legitimacy of the pre-block from the node

[0079] a. Check whether the hash of the previous block in the pre-block is consistent with the local one. If the hash of the previous block is inconsistent, use the alternative block hash.

[0080] b. Verify other important information in the pre-block, including but not limited to the pre-block hash, transaction Merkle tree, etc.

[0081] c. If the alternative block hash is used, the slave node needs to obtain the previous block hash based on the local, recalculate the hash of the current block, and put it into the block.

[0082] The slave node saves the first previous block hash (i.e., the N-1 block hash) locally. After reaching consensus on the N-1 block, each node executes the transactions in the block by itself, and then recalculates the block hash based on the transaction execution results and saves it in the local cache. Calculated by the node itself.

[0083] When the nodes of the Nth block cannot reach a consensus on the hash of the first preceding block, the alternative block hash is used. This is to ensure that all nodes reach a consensus on the transaction execution results in the N-1th block, avoiding inconsistent execution results between nodes and resulting in inconsistent states between nodes.

[0084] 4) After the slave node passes the verification, it will sign the block and broadcast the voting signature to other consensus nodes.

[0085] 5) The master and slave nodes collect voting signatures for the final block. After collecting enough votes (the number of votes required to reach a consensus is different under different consensuses, such as: Byzantine consensus requires more than 2 / 3 of the votes, Raft consensus requires more than 1 / 2 of the votes, etc.), they enter the block submission phase.

[0086] 6) In the block submission phase, the persistence processing logic of the previous block will be triggered. According to the consensus result, the data of the previous block will be processed and stored in the database. At the same time, the execution of transactions in this round of blocks and the confirmation of the final block will be completed in the block submission phase, including but not limited to the calculation of the final block hash, transaction Merkle tree root, etc., and applied to the final block. If the previous block hash in the block to be submitted N is inconsistent with the block hash of the previous block (N-1) cached locally, it means that the previous block should be discarded. The discard processing logic is as follows:

[0087] a. Set the transaction execution result in the previous block in the cache to empty. (i.e. roll back to the state before the transaction was executed)

[0088] b. Add a prefix to the block hash of block (N-1), which means marking the block as invalid (invalidation means that all transactions in the current block have failed and will not affect the world state).

[0089] 7) If the collected voting signatures do not meet the consensus requirements, it is considered that this round of consensus has not reached a consensus, and the master node is re-selected to start a new round of proposals. Repeat the above steps 1) to 7).

[0090] like Figure 4 As shown in the figure, after the user constructs a transaction, the blockchain node will first verify the legitimacy of the transaction, and after the verification is passed, the transaction will be placed in the node transaction pool. The master node packs the new block, uses the final hash of the previous block as the previous block hash of the current node, and calculates the block hash and the alternative block hash for the current block and puts them into the block and broadcasts them to the slave node; after the slave node completes the block verification, it votes on the block hash (selecting the header block hash or the alternative block hash according to the verification block) and broadcasts the result; after the consensus is completed, the transaction is executed according to the determined execution method, and the final block is calculated and assembled, and then the block is stored in the database.

[0091] The present invention proposes a blockchain process optimization method, which improves the processing performance of the blockchain while ensuring the activity of the blockchain. On the basis of realizing the parallel execution of transactions between nodes, it can effectively prevent nodes from doing evil, and there is no need to restart the blockchain node, thereby ensuring the activity of the blockchain. In the consensus stage, there is no need to execute transactions, only the initial transaction needs to be broadcast. After reaching a consensus, each node schedules and executes the transactions in the block according to a deterministic scheduling algorithm, and fills the execution results to obtain the final block. In order to ensure that no node does evil at this time, the block is not persisted in the current stage, but the block (N-1) is put into the cache or wal (pre-write log). After reaching a consensus on the next height block (N), it can be ensured that the block hash of the previous block (N-1) of each node is consistent, that is, the block content of the previous block (N-1) is consistent for each node. At this time, the previous block (N-1) is persisted again to ensure the correctness of its data state.

[0092] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0093] The above description of the disclosed embodiments enables one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A blockchain consensus process optimization method, characterized in that: The following steps are involved: S10, the master node pre-packs a pre-block; the pre-block indicates that the transaction in the block has not been executed, and the pre-block contains a transaction list and complete block header information; S20, after the slave node verifies the pre-block, a consensus vote is performed on the pre-block; S30: After the consensus vote is completed, the block submission phase begins, and the master and slave nodes execute the transactions in the block; Wherein, the step S20 includes: S201, the slave node checks whether the pre-block hash field in the pre-block is consistent with the local one. If it is inconsistent, the slave node uses the alternative block hash; S202, the slave node verifies the remaining important information in the pre-block, including: pre-block hash, transaction Merkle tree; S203. When the slave node uses the candidate block hash, the slave node needs to obtain the previous block hash based on the local, recalculate the hash of the current block, and put it into the block; S204. When the slave node passes the verification, it signs the block with a vote, and broadcasts the voting signature to other consensus nodes; The step S30 comprises: S301: After the consensus vote is completed, the master node and the slave node collect voting signatures for the final block. After collecting enough votes, they enter the block submission phase. S302: During the block submission phase, the persistence processing logic for the previous block will be triggered, and the data of the previous block will be processed according to the consensus result and stored in the database.

2. A blockchain consensus process optimization method according to claim 1, characterized in that: The step S10 comprises: S101, the master node obtains valid transactions to be packaged; S102, the master node packages the acquired transactions, generates a pre-block, and processes the pre-block; the pre-block indicates that the transactions in the block have not been executed, and the pre-block contains a transaction list and complete block header information; S103: The master node broadcasts the pre-block to all slave nodes.

3. A blockchain consensus process optimization method according to claim 2, characterized in that: The pre-block is processed, including: pre-block hash calculation, candidate block hash calculation, pre-block hash signature and candidate block signature.

4. A blockchain consensus process optimization method according to claim 3, characterized in that: The pre-block hash calculation includes: When packaging the Nth block, the master node reads the block hash of the N-1th block from the local cache; the block hash of the N-1th block contains the execution result of the transaction; Assigning the block hash of the N-1th block to the pre-block hash field of the pre-block; A hash calculation is performed on the pre-block to obtain a pre-block hash.

5. A blockchain consensus process optimization method according to claim 3, characterized in that: The candidate block hash calculation includes: When all transactions in the N-1th block are set to fail, the master node recalculates the block hash of the N-1th block, and the block hash will be used in the pre-block hash field of the Nth block; Assigning the recalculated pre-block hash to the pre-block hash field of the pre-block; A hash calculation is performed on the pre-block to obtain a hash of the candidate block.

6. A blockchain consensus process optimization method according to claim 1, characterized in that: The step S302 further includes: In the block submission phase, if the hash of the previous block in the Nth block to be submitted is inconsistent with the block hash of the N-1th previous block in the local cache, the N-1th block in the local cache is discarded; the discarding process includes: setting the transaction execution result in the N-1th block to empty and marking the N-1th block as invalid.

7. A blockchain consensus process optimization method according to claim 1, characterized in that: Also includes: S40: If the collected voting signatures do not meet the consensus requirements, then this round of consensus has not reached a consensus, the master node is re-selected, a new round of proposals is started, and steps S10 to S40 are repeated.

Images