A batch block parallel consensus method and system supporting high concurrency

Abstract

This invention belongs to the field of blockchain technology and provides a batch block parallel consensus method and system that supports high concurrency, solving the problem of slow consensus speed caused by serial consensus. The solution includes: acquiring all transactions and assembling them into blocks, ensuring that there are no dependencies between transactions in different blocks; pre-executing the assembled blocks to construct complete blocks; starting consensus for the complete blocks after construction, with the consensus process of each block proceeding in parallel; after consensus is passed, the consensus node executes the block and verifies its correctness, and pre-writing the block information after successful verification; determining whether the parent block should be added to the chain, and verifying the hash of the parent block after it is added to the chain, and writing the execution status and result information of the block to the chain if the verification is successful; and ending the batch of blocks after all blocks in the batch have completed consensus and verification. This greatly improves the consensus speed and the speed of adding blocks to the chain.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, and in particular relates to a batch block parallel consensus method and system that supports high concurrency. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] In existing technologies, traditional blockchains adopt a chain ledger structure. The consensus and on-chain process of blocks is carried out in the order of block number increment. The construction of the current block and the consensus on-chain process depend on the information of the previous block. Only after the previous block is confirmed to be on-chain can the consensus and on-chain process of the next block be carried out.

[0004] Currently, all mainstream BFT consensus algorithms applied to blockchain follow the block consensus in block order. For a chain ledger, only one block consensus and on-chain process can exist at the same time.

[0005] As blockchain business scenarios continue to expand, many blockchain applications now require high transaction throughput. Sequential consensus and on-chain data collection are among the main performance bottlenecks of traditional chain-based ledger structures. Current performance optimizations for consensus algorithms primarily focus on communication optimization, increasing consensus speed and performance to some extent by reducing message communication volume. However, excessively large messages can lead to slow message parsing and communication. Therefore, limited by transaction and message size constraints, simply increasing the number of transactions within a block cannot solely improve consensus speed. Summary of the Invention

[0006] To address at least one of the technical problems mentioned above, this invention provides a batch block parallel consensus method and system that supports high concurrency. It implements a batch block parallel consensus method, which can simultaneously perform parallel consensus on multiple blocks. For the batch consensus blocks, concurrent execution and pre-writing can also be performed, which greatly improves the consensus speed and the block on-chain speed.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] The first aspect of this invention provides a batch block parallel consensus method that supports high concurrency, comprising the following steps:

[0009] Get all transactions;

[0010] The transactions are assembled by dividing all transactions into different transaction queues according to the transaction objects, analyzing the dependencies between the transaction queues, putting the transactions into empty blocks, and removing the dependencies between transactions in each block.

[0011] Pre-execute the assembled transaction blocks to build complete blocks;

[0012] After a complete block is constructed, consensus for that block begins, and the consensus process for each block proceeds in parallel.

[0013] After consensus is reached, the consensus node will execute the block and verify its correctness. After the block verification is successful, the block information will be pre-written.

[0014] Determine whether the parent block has been added to the chain. After it has been added to the chain, verify the hash of the parent block. If the verification is successful, write the execution status and result information of the block to the chain, and complete the addition of the block to the chain.

[0015] The parallel consensus process for this batch of blocks ends once all blocks in the batch have reached consensus and been successfully verified.

[0016] Furthermore, the analysis of dependencies among transaction queues, placing transactions into empty blocks, and removing dependencies between transactions in each block includes:

[0017] Transactions in queues that are interdependent are classified as the first type of transaction set, and transactions in queues that are not interdependent are classified as the second type of transaction set. Transactions in each transaction set are placed in the same block, and transactions are placed in ascending order of block number until the block is full or can no longer accommodate the entire transaction set. Then, the transactions are placed in the next block.

[0018] Furthermore, after retrieving all transactions, an empty block is constructed based on the number of transactions retrieved;

[0019] Initialize all empty blocks. The block height of empty blocks is sequentially increased from the current block height plus one.

[0020] Furthermore, the number of empty blocks is the number of transactions obtained divided by the maximum number of transactions contained in a block.

[0021] Furthermore, after the pre-execution is completed, the key verification information of the block is written into the block header, and after the pre-execution of its parent block is completed, the hash of the parent block is written into the block header.

[0022] Furthermore, if consensus fails for a certain block, the consensus and writing of that block and all subsequent blocks are cancelled, and the pre-written data and cached data are deleted until all blocks before that block are successfully uploaded to the chain, at which point the parallel consensus of that batch of blocks ends.

[0023] Furthermore, the on-chain verification of the parent block also includes verifying whether the block number of the current block is strictly incremental compared to the parent block, and verifying the state execution result of the current block based on the verification information of the parent block.

[0024] A second aspect of the present invention provides a batch block parallel consensus system supporting high concurrency, comprising:

[0025] The transaction assembly module is configured to: retrieve all transactions; assemble the transactions by dividing all transactions into different transaction queues according to transaction objects, analyze the dependencies between transaction queues, put the transactions into empty blocks, and remove the dependencies between transactions in each block;

[0026] The block building module is configured to pre-execute the assembled transaction blocks to build complete blocks;

[0027] The block parallel consensus module is configured to: start the consensus process for a block after a complete block is constructed, and the consensus process for each block is carried out in parallel;

[0028] After consensus is reached, the consensus node will execute the block and verify its correctness. After the block verification is successful, the block information will be pre-written.

[0029] Determine whether the parent block has been added to the chain. After it has been added to the chain, verify the hash of the parent block. If the verification is successful, write the execution status and result information of the block to the chain, and complete the addition of the block to the chain.

[0030] The parallel consensus process for this batch of blocks ends once all blocks in the batch have reached consensus and been successfully verified.

[0031] Furthermore, in the transaction assembly module, the step of analyzing the dependencies between transaction queues, placing transactions into empty blocks, and removing dependencies between transactions in each block includes:

[0032] Transactions in queues that are interdependent are classified as the first type of transaction set, and transactions in queues that are not interdependent are classified as the second type of transaction set. Transactions in each transaction set are placed in the same block, in ascending order of block number, until the block is full or can no longer accommodate the entire transaction set. Then, the transactions are placed in the next block.

[0033] Furthermore, in the block parallel consensus module, if the consensus of a certain block fails, the consensus and writing of that block and subsequent blocks are cancelled, and the pre-written data and cached data are deleted until all blocks before that block are successfully put on the chain, at which point the block parallel consensus of that batch ends.

[0034] Compared with the prior art, the beneficial effects of the present invention are:

[0035] 1. This invention addresses the slow consensus problem caused by the serial consensus of traditional consensus algorithms by assembling transactions into blocks to ensure that there are no dependencies between transactions in different blocks; pre-executing the blocks after the transactions are assembled to build complete blocks; after the complete blocks are built, the consensus of the blocks begins, and the consensus process of each block is carried out in parallel; a batch block parallel consensus method is implemented, which can perform parallel consensus of multiple blocks at the same time. For batch consensus blocks, concurrent execution and pre-writing can also be performed, which greatly improves the consensus speed and the speed of block on-chaining.

[0036] 2. The present invention can make full use of the resources of multi-core servers by performing block consensus and on-chain in batches and in parallel, breaking the consensus speed bottleneck, improving consensus performance, and significantly increasing the transaction throughput of the chain ledger blockchain.

[0037] 3. This invention combines the conventional BFT consensus algorithm, adapting to scenarios with low transaction response latency, low throughput and high success rate, and can also be applied to scenarios with high throughput requirements.

[0038] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0039] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0040] Figure 1 This is a schematic diagram illustrating an example of parallel consensus using three blocks, provided by an embodiment of the present invention.

[0041] Figure 2 This is a schematic diagram of the batch block parallel consensus process provided in an embodiment of the present invention;

[0042] Figure 3 This is a schematic diagram of assembling transactions into blocks according to an embodiment of the present invention. Detailed Implementation

[0043] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0044] It should be noted that the following detailed description is illustrative and intended to provide further explanation of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0045] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0046] As mentioned in the background section, current mainstream BFT consensus algorithms perform consensus on blocks sequentially in ascending block number order, which severely impacts consensus speed and consequently slows down transaction throughput. This invention proposes a consensus method that supports high concurrency and batch block parallel consensus. This batch block parallel consensus refers to the simultaneous consensus of multiple blocks, with the main consensus process and some on-chain processes of each block operating in parallel without interference.

[0047] Example 1

[0048] This embodiment provides a batch block parallel consensus method that supports high concurrency, including the following steps:

[0049] Step 101: The master node retrieves transactions from the transaction pool and calculates the number of blocks to be built by dividing the retrieved transaction count TxNum by the maximum number of transactions a block can contain, MaxNum. First, initialize n empty blocks, with the block height increasing sequentially from the current block height plus one.

[0050] All transactions are divided into different transaction queues according to the transaction object, the dependencies between the transaction queues are analyzed, the transactions are put into empty blocks, and it is ensured that there are no dependencies between the blocks.

[0051] Transactions in queues with dependencies are classified as the first type of transaction set, while transactions in queues without dependencies are classified as the second type of transaction set.

[0052] It should be noted that in this embodiment, the first type of transaction set may have one or more transaction sets; the second type of transaction queues that do not have any dependencies form their own set.

[0053] Transactions in each transaction set need to be placed in the same block. When placing transactions, they are placed in the block in ascending order of block number until the block is full or can no longer accommodate the entire transaction set. Then, the transaction set is placed in the next block.

[0054] It should be noted that the aforementioned dependency relationship refers to the fact that the execution of a transaction depends on the execution result of one or more other transactions. For example, a transaction may read the status of an account related to another transaction. The final execution result of two or more transactions with a dependency relationship will be different depending on the execution order.

[0055] Step 102: Once the transactions in a block are assembled, consensus for that block can proceed. The timeline for the parallel consensus process of batch blocks is as follows: Figure 1 As shown, Figure 1 The example shown is a parallel consensus of three blocks, but it does not mean that the present invention is limited to parallel consensus of three blocks.

[0056] Specifically, the steps include the following:

[0057] (1) First, the master node pre-executes the assembled transaction blocks to generate verification information for the block execution results. The pre-execution process of each block is carried out in parallel and does not interfere with each other. After the pre-execution is completed, the key verification information of the block is written into the block header. After the parent block is pre-executed, the hash of the parent block is written into the block header.

[0058] (2) Once a complete block is constructed, the consensus process for this block can begin. The consensus processes for each block proceed in parallel without interfering with each other. During the consensus process, there is no verification of the parent block or strict incremental verification of the block height.

[0059] (3) After consensus is reached, the consensus node will execute the block and verify the correctness of the block. After the block verification is passed, the block information can be prewritten. Prewriting refers to the persistent writing of data such as blocks and transactions that do not affect consensus verification. The prewriting process of each block is also carried out in parallel and does not interfere with each other.

[0060] (4) After the parent block is verified and uploaded to the chain, the hash verification of the parent block of this block can be performed. If the verification is successful, the status and result information of the block execution will be written to complete the upload of the block to the chain. This process is carried out in the order of increasing block height.

[0061] Step 103: Once all blocks in this batch have reached consensus and been successfully verified, the parallel consensus for this batch of blocks is considered complete. If consensus for a block fails, the consensus and writing for this block and all subsequent blocks are cancelled, and pre-written data and cached data are deleted. The parallel consensus for this batch of blocks ends once all blocks before this block have been successfully uploaded to the chain.

[0062] The advantage of the above solution is that the present invention realizes a batch block parallel consensus method, which can perform parallel consensus of multiple blocks at the same time. For batch consensus blocks, concurrent execution and pre-writing can also be performed, which greatly improves the consensus speed and the block on-chain speed.

[0063] Batch parallel block consensus and on-chain processing can make full use of the resources of multi-core servers, break the consensus speed bottleneck, improve consensus performance, and significantly increase the transaction throughput of chain ledger blockchains.

[0064] This invention is an optimization of the basic consensus process, which is used in an adaptive manner in combination with other consensus algorithms. To illustrate the solution of this invention more clearly, the PBFT (Practical Byzantine Fault Tolerance) consensus algorithm is used as an example, but this does not mean that this invention is limited to use in combination with the PBFT consensus algorithm.

[0065] like Figure 2 As shown, the steps of the batch block parallel consensus method supporting high concurrency specifically include:

[0066] Step 201: The master node retrieves transactions from the transaction pool and constructs an empty block based on the number of retrieved transactions;

[0067] Assuming the number of transactions retrieved is TxNum, and the maximum number of transactions a block can contain is MaxNum, the number of blocks to be built is obtained by dividing the retrieved transaction count TxNum by the maximum number of transactions a block can contain, MaxNum. Calculate n, and pre-allocate n empty blocks.

[0068] The block heights of these n empty blocks increase sequentially from the current block height plus one. The maximum value of n needs to be configured and adjusted according to the physical environment and usage scenario of the blockchain.

[0069] Step 202: The master node broadcasts a message to the slave nodes to notify them of the initial height and block range of the batch block parallel consensus;

[0070] The master node needs to broadcast a message to the slave nodes to start batch block consensus. The message needs to include the starting block height of this batch consensus and notify other nodes that the consensus processing of the next n blocks from this block onwards is batch block parallel consensus, where n is the number of empty blocks pre-allocated in step 1.

[0071] Step 203: Distribute transactions into empty blocks to ensure that there are no dependencies between transactions in different blocks;

[0072] The retrieved transactions are categorized, transaction queues are constructed according to the transaction object IDs, and transaction dependencies are sorted out. The dependencies between each queue are recorded. Two or more queues with dependencies are combined into one transaction set, and transaction queues without dependencies are combined into their own sets.

[0073] A set of transactions needs to be placed in the same block. Transactions are placed in ascending order of block number until the block is full or cannot accommodate the entire transaction set, then they are placed in the next block.

[0074] If there are transaction sets that cannot be included in an empty block, consensus on these transactions will not be pursued in this block and will be reserved for the next batch of consensus.

[0075] like Figure 3 As shown, assume the maximum block height in the current blockchain is b. n-1 The maximum number of transactions per block, MaxNum, is 10, and the number of transactions taken from the transaction pool, TxNum, is 21. Therefore, according to... Given n=3, three empty blocks b are constructed in advance. n b n+1 b n+2 .

[0076] All transactions are divided into multiple queues based on the ID of the transaction object. Transactions from each transaction object form one queue. Transactions from queues OID1, OID2, and OID3 that have dependencies are placed as a set in block bn. Transactions from queues OID4, OID5, and OID6 that have dependencies are placed as a set in block b. n+1 Then, the sets of transactions that have no dependencies are filled into the empty block.

[0077] Step 204: Pre-execute the constructed blocks to build a complete block;

[0078] When the number of transactions in an empty block reaches the maximum number of transactions in the block or there is not enough space to add new transactions, the block can be pre-executed to generate the block's verification information and block hash value. The block hash of the previous block is written into the block header as the parent block information. Once the block is fully constructed, consensus for this block can be initiated.

[0079] Step 205: Initiate consensus. During the consensus process, this block will no longer verify the parent block or perform strict checks on block height increment. If consensus passes successfully, proceed to Step 6; if consensus fails, proceed to Step 212.

[0080] Step 206: After the consensus of this block is completed, the execution and pre-writing of the block will begin. Only some data that does not affect the consensus verification will be written, such as transactions and block bodies.

[0081] Step 207: Determine whether the parent block has been successfully executed and uploaded to the chain. If the parent block has been uploaded to the chain, obtain the hash value of the parent block and directly verify the parent block.

[0082] Step 208: If the parent block has not been fully uploaded to the chain, pause the uploading process of this block, temporarily cache the execution result and state change result of this block, and do not write them to the database. Wait for the parent block to be written before proceeding to step 209.

[0083] Step 209: If the parent block has already been uploaded to the chain, obtain the hash value of the parent block for parent block verification, and verify whether the block number of this block is strictly increasing compared with the parent block. Verify the state execution result of this block based on the verification information of the parent block, etc., to ensure the order and consistency of the uploaded blocks.

[0084] Step 210: If the parent block has been added to the chain and all verifications of this block have passed, write the cached state change results, execution results, and related index information into the state database to complete the subsequent on-chain process of this block.

[0085] Step 211: Once all blocks in this batch have been successfully uploaded to the blockchain, the batch block parallel consensus process for this batch is considered complete.

[0086] Step 212: If the consensus fails or does not pass, cancel the consensus and on-chaining of this block and subsequent blocks, delete the cached consensus information, and delete any pre-written data.

[0087] Step 213: Consensus for this batch is interrupted. Blocks preceding this block are considered to have passed the work time and been successfully uploaded to the chain, and subsequent blocks are not processed. A re-election of the master node is triggered, and consensus is re-established.

[0088] This invention combines the conventional BFT consensus algorithm, adapting to scenarios with low transaction response latency, low throughput and high success rate, and can also be applied to scenarios with high throughput requirements.

[0089] Example 2

[0090] This embodiment provides a batch block parallel consensus system that supports high concurrency, including:

[0091] The transaction assembly module is configured to: retrieve all transactions, assemble the transactions, divide all transactions into different transaction queues according to transaction objects, analyze the dependencies between transaction queues, put the transactions into empty blocks, and remove the dependencies between transactions in each block.

[0092] The block building module is configured to pre-execute the assembled transaction blocks to build complete blocks;

[0093] The block parallel consensus module is configured to: start the consensus process for a block after a complete block is constructed, and the consensus process for each block is carried out in parallel;

[0094] After consensus is reached, the consensus node will execute the block and verify its correctness. After the block verification is successful, the block information will be pre-written.

[0095] Determine whether the parent block has been added to the chain. After it has been added to the chain, verify the hash of the parent block. If the verification is successful, write the execution status and result information of the block to the chain, and complete the addition of the block to the chain.

[0096] The parallel consensus process for this batch of blocks ends once all blocks in the batch have reached consensus and been successfully verified.

[0097] In the transaction assembly module, the step of analyzing the dependencies between transaction queues, placing transactions into empty blocks, and removing dependencies between transactions in each block includes:

[0098] Transactions in queues that are interdependent are classified as the first type of transaction set, which may include multiple such sets. Transaction queues that are not interdependent are each classified as the second type of transaction set.

[0099] In this process, transactions from each transaction set are placed in the same block, arranged in ascending order of block number, until the block is full or can no longer accommodate the entire transaction set. Only then are the transactions placed in the next block.

[0100] In the block parallel consensus module, if a block consensus fails, the consensus and writing of that block and all subsequent blocks are cancelled, and the pre-written data and cached data are deleted. The block parallel consensus for that batch ends after all the blocks before that block have been successfully put on the chain.

[0101] The advantages of the above technical solution are that it assembles transactions into blocks, ensuring that there are no dependencies between transactions in different blocks; it pre-executes the blocks after the transactions are assembled to build complete blocks; after the complete blocks are built, the consensus of the blocks begins, and the consensus process of each block is carried out in parallel; it realizes a batch block parallel consensus method, which can perform parallel consensus of multiple blocks at the same time. For batch consensus blocks, concurrent execution and pre-writing can also be performed, which greatly improves the consensus speed and the speed of block on-chaining.

[0102] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A batch block parallel consensus method supporting high concurrency, characterized in that, Includes the following steps: Retrieve all transactions and construct an empty block based on the number of transactions retrieved; initialize all empty blocks, with the block height of the empty blocks increasing sequentially from the current block height plus one. The transactions are assembled by dividing all transactions into different transaction queues according to the transaction objects; Analyze the dependencies between transaction queues, place transactions into empty blocks, and remove dependencies between transactions in each block, including: Transactions in queues that are interdependent are classified as the first type of transaction set, and transactions in queues that are not interdependent are classified as the second type of transaction set. The first type of transaction set may contain one or more transaction sets. The second type of transaction set may contain queues that are not interdependent and form their own set. In this process, transactions in each transaction set are placed in the same block, and the transactions are placed in ascending order of block number until the block is full, and then the transactions are placed in the next block. The pre-execution of the assembled transaction blocks generates verification information for the block execution results. The pre-execution process of each block is carried out in parallel. After the pre-execution is completed, the key verification information of the block is written into the block header. After the pre-execution of its parent block is completed, the hash of the parent block is written into the block header to construct a complete block. After a complete block is constructed, consensus for that block begins, and the consensus process for each block proceeds in parallel. During the consensus process, parent block verification and strict incremental block height verification are not performed. After consensus is reached, the consensus node executes and verifies the correctness of the block. After the block verification is passed, the block information is pre-written. Pre-writing is the process of persistently writing data that does not affect the consensus verification of the block and transactions. The pre-writing process of each block is carried out in parallel and does not interfere with each other. Determine if the parent block has been added to the blockchain. Once added, verify the hash of the parent block. If the verification is successful, write the block's execution status and result information to complete the block's addition to the blockchain. This process is performed in ascending order of block height. After all blocks in this batch have reached consensus and been successfully verified, the block parallel consensus ends.

2. The batch block parallel consensus method supporting high concurrency according to claim 1, characterized in that, The number of empty blocks is the number of transactions obtained divided by the maximum number of transactions contained in a block.

3. The batch block parallel consensus method supporting high concurrency according to claim 1, characterized in that, If consensus fails for a block, the consensus and writing of that block and all subsequent blocks are cancelled, and pre-written data and cached data are deleted. The parallel consensus of this batch of blocks ends only after all blocks before that block have been successfully uploaded to the chain.

4. The batch block parallel consensus method supporting high concurrency according to claim 1, characterized in that, The on-chain verification of the block also includes verifying whether the block number of the block is strictly increasing compared to the parent block, whether the hash of the parent block is correct, and verifying the state execution result of the block based on the verification information of the block.

5. A batch block parallel consensus system supporting high concurrency, employing a batch block parallel consensus method supporting high concurrency as described in any one of claims 1-4, characterized in that, include: The transaction assembly module is configured to retrieve all transactions. The transactions are assembled by dividing all transactions into different transaction queues according to the transaction objects, analyzing the dependencies between the transaction queues, putting the transactions into empty blocks, and removing the dependencies between transactions in each block. The block building module is configured to pre-execute the assembled transaction blocks to build complete blocks; The block parallel consensus module is configured to: start the consensus process for a block after a complete block is constructed, and the consensus process for each block is carried out in parallel; After consensus is reached, the consensus node will execute the block and verify its correctness. After the block verification is successful, the block information will be pre-written. Determine whether the parent block has been added to the chain. After it has been added to the chain, verify the hash of the parent block. If the verification is successful, write the execution status and result information of the block to the chain, and the block is added to the chain. After all blocks in this batch have reached consensus and been successfully verified, the block parallel consensus ends.

6. A batch block parallel consensus system supporting high concurrency according to claim 5, characterized in that, In the transaction assembly module, the steps of analyzing the dependencies between transaction queues, placing transactions into empty blocks, and removing dependencies between transactions in different blocks include: Transactions in queues that are interdependent are classified as the first type of transaction set, and transactions in queues that are not interdependent are classified as the second type of transaction set. In this process, transactions in each transaction set are placed in the same block, and the transactions are placed in ascending order of block number until the block is full, and then the transactions are placed in the next block.

7. A batch block parallel consensus system supporting high concurrency according to claim 5, characterized in that, In the block parallel consensus module, if a block consensus fails, the consensus and writing of that block and all subsequent blocks are canceled, and the pre-written data and cached data are deleted. The block parallel consensus for that batch ends after all the blocks before that block have been successfully put on the chain.

Images