Transaction parallel processing method and system based on block chain

Abstract

The embodiment of the invention discloses a transaction parallel processing method and system based on a block chain, and the method comprises the steps: S1, obtaining a transaction, calculating the transaction hash, putting the transaction into a target fragmentation container according to the transaction hash, and initializing the transaction state into an unpackaged state; s2, all transactions in the transaction pool are traversed, and transactions in an unpacked state are modified into transactions in a to-be-packed state through comparison and exchange; s3, the transaction in the to-be-packaged state is packaged and put into a block, a consensus request is initiated, and the to-be-packaged state of the transaction is modified into a packaged state through comparison and exchange; s4, when the block consensus fails, modifying the transaction in the packed state in the block with the consensus failure to be in an unpacked state; wherein the steps S2-S4 are processed in parallel through different threads; and S5, when the block consensus is successful, removing the successfully uplink transaction in the block with the successful consensus from the target fragment container to which the transaction belongs. And the data processing efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of blockchains, and in particular to a transaction parallel processing method and system based on a blockchain. BACKGROUND

[0002] The processing of transactions by a blockchain system mainly includes three processes: new transactions are put into a transaction pool, transactions in the transaction pool are packaged and consensus is reached, and transactions that have been chained are removed from the transaction pool. The processing of transactions by a blockchain system directly affects the overall performance of the blockchain system. Among them, the putting of new transactions into the transaction pool and the removal of transactions that have been chained from the transaction pool are modifications to the transaction pool container, and the packaging and consensus of transactions in the transaction pool are modifications to the transaction state. During the entire process of the packaging and consensus of transactions in the transaction pool, there are three situations that require modification of the transaction state:

[0003] 1) A packaging node obtains unpackaged transactions from the transaction pool while setting the transaction state to be packaged;

[0004] 2) A node receives a block consensus request and sets the state of all transactions included in the block to be packaged;

[0005] 3) The block consensus request is unsuccessful, and the state of all transactions included in the block is set to be unpackaged.

[0006] The above three state change operations are usually executed in a serial manner, and there is a lack of effective concurrency control mechanism, making it difficult to meet the requirements of high-performance blockchain systems for throughput and response speed.

[0007] There is currently no effective solution to the above problems in the prior art. SUMMARY

[0008] To solve the above problems, the present application provides a transaction parallel processing method and system based on a blockchain, which divides the transaction pool into multiple shard containers and modifies the transaction state in parallel through a compare-and-swap method, achieving efficient processing of unpackaged, to-be-packaged, packaged, and state-modified transactions, to solve the problems of serial transaction state updating and low transaction processing efficiency in the prior art.

[0009] To achieve the above object, the application provides a transaction parallel processing method based on a block chain, comprising the following steps: S1, obtaining a transaction and calculating a transaction hash of the transaction, putting the corresponding transaction into a target shard container according to the transaction hash, and initializing a transaction state as an unpacked state; S2, traversing all transactions in all shard containers, modifying the state of the transaction in the unpacked state through compare-and-swap, and obtaining a transaction in a packed state; S3, packing the transaction in the packed state into a block and initiating a consensus request, modifying the packed state of the transaction to the packed state through compare-and-swap, and setting a transaction packing block number and a transaction packing block hash for the transaction in the packed state according to the block; S4, when the block consensus fails, modifying the transaction state of the transaction in the packed state in the consensus failure block to the unpacked state according to the transaction packing block number and the transaction packing block hash through compare-and-swap; wherein steps S2-S4 are processed in parallel through different threads; S5, when the block consensus succeeds, removing the transaction in the consensus success block from the target shard container.

[0010] Further optionally, the step of putting the corresponding transaction into the target shard container according to the transaction hash and initializing the transaction state as the unpacked state comprises the following steps: S101, calculating a remainder of the transaction hash divided by a total number of shard containers; S102, taking the remainder as a shard container index number of the corresponding transaction, and adding an exclusive lock to the target shard container corresponding to the shard container index number; wherein all shard containers are provided with index numbers in advance; S103, putting the transaction into the target shard container corresponding to the shard container index number, and releasing the exclusive lock.

[0011] Further optionally, the step of traversing all transactions in all shard containers, modifying the state of the transaction in the unpacked state through compare-and-swap, and obtaining a transaction in a packed state comprises the following steps: S201, traversing all shard containers, adding a shared lock to any shard container as a current shard container when accessing the any shard container; S202, traversing all transactions in the current shard container, modifying the state of the transaction in the unpacked state through compare-and-swap, and obtaining a transaction in a packed state, and releasing the shared lock.

[0012] Further optionally, the step of modifying the packed state of the transaction to the packed state through compare-and-swap, and setting a transaction packing block number and a transaction packing block hash for the transaction in the packed state according to the block comprises the following steps: S301, when a consensus request is received, determining a target shard container according to a transaction hash corresponding to the transaction in the packed state, and adding a shared lock to the target shard container; S302, for any transaction in the packed state, modifying the packed state of the current transaction to the packed state through compare-and-swap, and assigning the transaction packing block number and the transaction packing block hash of the block to the current transaction, and releasing the shared lock.

[0013] Further optionally, the method further comprises: S401, for any transaction in the packed state, determining whether the transaction packing block number of the transaction is consistent with the transaction packing block number of the consensus failure block, and whether the transaction packing block hash of the transaction is consistent with the transaction packing block hash of the consensus failure block; S402, when the transaction packing block number is consistent and the transaction packing block hash is consistent, determining a target shard container according to the transaction hash of the transaction, adding a shared lock to the target shard container, modifying the transaction state of the transaction to the unpacked state through compare-and-swap, and releasing the shared lock.

[0014] In another aspect, the application provides a blockchain-based transaction parallel processing system, comprising: a bucketing module configured to obtain a transaction and calculate a transaction hash of the transaction, put the corresponding transaction into a target shard container according to the transaction hash, and initialize the transaction state to an unpacked state; a first state modification module configured to traverse all transactions in all shard containers, modify the state of the transaction in the unpacked state through compare-and-swap, and obtain a transaction in a packed state; a second state modification module configured to pack the transaction in the packed state into a block and initiate a consensus request, modify the transaction in the packed state to a transaction in a packed state through compare-and-swap, and set a transaction packing block number and a transaction packing block hash for the transaction in the packed state according to the block; a third state modification module configured to, when the block consensus fails, modify the transaction state of the transaction in the packed state in the consensus failure block to an unpacked state through compare-and-swap according to the transaction packing block number and the transaction packing block hash; and a deletion module configured to, when the block consensus succeeds, remove the transaction successfully uploaded to the chain in the consensus success block from the target shard container.

[0015] Further optionally, the bucketing module comprises: a remainder calculation submodule configured to calculate the remainder of the transaction hash divided by the total number of shard containers; a shard container determination submodule configured to take the remainder as a shard container index number of the corresponding transaction, and add an exclusive lock to the target shard container corresponding to the shard container index number; wherein all shard containers are pre-provided with index numbers; and a transaction storage submodule configured to put the transaction into the target shard container corresponding to the shard container index number, and release the exclusive lock.

[0016] Further optionally, the first state modification module comprises: a container traversal submodule, configured to traverse all shard containers, and add a shared lock to any shard container as a current shard container when the any shard container is accessed; and a transaction traversal submodule, configured to traverse all transactions in the current shard container, modify the state of a transaction in an unpacked state through compare-and-swap to obtain a transaction in a to-be-packed state, and release the shared lock.

[0017] Further optionally, the second state modification module comprises: a positioning submodule, configured to determine a target shard container according to a transaction hash corresponding to the transaction in the to-be-packed state when a consensus request is received, and add a shared lock to the target shard container; and a first state update submodule, configured to modify the state of the current transaction in the to-be-packed state to an already-packed state through compare-and-swap for any transaction in the to-be-packed state, assign a transaction packed block number and a transaction packed block hash of a block to the current transaction, and release the shared lock.

[0018] Further optionally, the third state modification module comprises: a judging submodule, configured to judge whether a transaction packed block number of any transaction in the already-packed state is consistent with a transaction packed block number of a consensus failure block, and whether a transaction packed block hash of the any transaction in the already-packed state is consistent with a transaction packed block hash of the consensus failure block; and a second state update submodule, configured to determine a target shard container according to a transaction hash of the transaction when the transaction packed block number is judged to be consistent and the transaction packed block hash is judged to be consistent, add a shared lock to the target shard container, modify the state of the transaction to an unpacked state through compare-and-swap, and release the shared lock.

[0019] The above technical solution has the following beneficial effects: the shard container mechanism based on the transaction hash is introduced to realize distributed storage and access of transactions, and competition and conflict of the same data structure among threads are reduced; the shared lock and the exclusive lock are combined to control the access permission of the container at the shard granularity, and the concurrent security of the system is further improved; meanwhile, the state of the transaction is updated by using the atomic operation of compare-and-swap, parallel modification of states such as unpacked, to-be-packed, already-packed, and failure rollback is realized, efficient execution is realized, and the transaction processing throughput and the overall performance of the system are significantly improved. BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative labor on the basis of these drawings.

[0021] Figure 1is a flow chart of the transaction parallel processing method based on the blockchain provided by the embodiment of the present application;

[0022] Figure 2 is a flow chart of the transaction bucketing method provided by the embodiment of the present application;

[0023] Figure 3 is a flow chart of the unpacked state updating method provided by the embodiment of the present application;

[0024] Figure 4 is a flow chart of the to-be-packed state updating method provided by the embodiment of the present application;

[0025] Figure 5 is a flow chart of the packed state updating method provided by the embodiment of the present application;

[0026] Figure 6 is a structural schematic diagram of the transaction parallel processing system based on the blockchain provided by the embodiment of the present application;

[0027] Figure 7 is a structural schematic diagram of the bucketing module provided by the embodiment of the present application;

[0028] Figure 8 is a structural schematic diagram of the first state modification module provided by the embodiment of the present application;

[0029] Figure 9 is a structural schematic diagram of the second state modification module provided by the embodiment of the present application;

[0030] Figure 10 is a structural schematic diagram of the third state modification module provided by the embodiment of the present application.

[0031] Reference signs: 100-bucketing module; 1001-remainder calculation submodule; 1002-fragment container determination submodule; 1003-transaction storage submodule; 200-first state modification module; 2001-container traversal submodule; 2002-transaction traversal submodule; 300-second state modification module; 3001-positioning submodule; 3002-first state updating submodule; 400-third state modification module; 4001-judgment submodule; 4002-second state updating submodule; 500-deletion module. DETAILED DESCRIPTION

[0032] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0033] To solve the problem of low processing efficiency of the blockchain system in the prior art, the present application provides a parallel processing method for transactions based on a blockchain, Figure 1 is a flowchart of the parallel processing method for transactions based on a blockchain provided by an embodiment of the present application, as Figure 1 shown, the method comprises:

[0034] S1, obtaining a transaction and calculating the transaction hash of the transaction, putting the corresponding transaction into a target shard container according to the transaction hash, and initializing the transaction state to an unpacked state;

[0035] After the blockchain system receives a new transaction, it calculates the transaction hash of the received transaction, which is used to uniquely identify the transaction. The transaction hash is usually calculated by a hash function and is the basis for subsequent shard positioning.

[0036] The transaction pool is divided into multiple shard containers, the transaction hash is taken as the input, and according to the preset number of shard containers, the target shard container is determined through the mapping relationship between the transaction hash and the number of containers, and the transaction is written into the target shard container for storage.

[0037] At the same time when the transaction is written into the shard container, the initial state of the transaction is set, and the state value is "unpacked", which is used to identify that the transaction has not been processed or packed by any node.

[0038] S2, traverse all transactions in all shard containers, modify the state of the transaction in the unpacked state by comparison and exchange, and obtain the transaction in the packed state;

[0039] The packing node needs to obtain the transaction in the unpacked state from the transaction pool, and in this process, the packing node accesses each set shard container in turn and accesses all transactions contained in each shard container one by one. This process is a comprehensive check of all transactions, which is used for subsequent state judgment.

[0040] During the traversal process, state judgment is performed on each transaction; if the state of the transaction is "unpacked", the state is modified to "packed" by using the comparison and exchange (CAS) operation. The meaning of the comparison and exchange operation is: only when the current state value is consistent with the expected value (i.e. "unpacked"), the state is modified to the target value (i.e. "packed"); otherwise, no modification operation is performed.

[0041] Through the above comparison and exchange operation, the transaction whose state is successfully modified to "packed" is the output result of this step, which can be used for subsequent packing.

[0042] S3, package the transaction in the to-be-packed state into a block and initiate a consensus request, modify the transaction in the to-be-packed state to the packed state by comparison and exchange, and set the transaction packing block number and transaction packing block hash for the transaction in the packed state according to the block to which the transaction belongs;

[0043] The packing node packages the transaction in the to-be-packed state obtained from the transaction pool into a block to initiate a consensus request, that is, broadcasts the block to other nodes in the blockchain network, starts the consensus process of the block, and determines whether the block can be accepted and finally written into the blockchain.

[0044] After initiating the consensus, for the transaction packed into the block, it is judged whether the current state is “to-be-packed” by using the comparison and exchange operation, and if so, the state is updated to “packed”. After the transaction state is updated to “packed”, the transaction packing block number and transaction packing block hash of the transaction are written into the corresponding fields of the transaction respectively to record the block information. Among them, the state updating operation can be asynchronous with the consensus operation.

[0045] S4, when the block consensus fails, for the transaction in the packed state in the consensus failed block, the transaction state is modified to the unpacked state according to the transaction packing block number and transaction packing block hash by comparison and exchange; wherein steps S2-S4 are processed in parallel by different threads;

[0046] After initiating the consensus request of a certain block, the consensus condition set by the blockchain system cannot be met, resulting in that the block cannot be confirmed or written into the blockchain, which is regarded as a block consensus failure at this time.

[0047] Among all the transactions packed into the failed block, there are transactions whose current state is “packed” but have not been written into the chain because the block has not been successfully consensus, in order to judge these transactions, it is necessary to judge whether they are transactions in the current failed block, according to the matching of the packing block number and block hash value recorded in each transaction with the identifier of the current failed block. When it is confirmed that the transaction indeed belongs to the current failed block, the state is still “packed” by using the comparison and exchange operation, if matched, the state is modified to “unpacked” so as to participate in the subsequent packing process again.

[0048] The above steps S2 (modify to-be-packed to packed), step S3 (modify to-be-packed to packed and record block information) and step S4 (rollback after consensus failure) can be performed by different threads at the same time, and do not block each other, realizing parallel processing. To improve the processing efficiency.

[0049] Table 1 shows the state field change rules and modification restriction conditions when using comparison and exchange (CAS) to modify three different states.

[0050]

[0051]

[0052] Table 1

[0053] S5, when the block consensus is successful, the transaction in the consensus successful block is removed from the target shard container.

[0054] A certain candidate block is verified and confirmed by each node in the blockchain network, meets the preset consensus condition, and is officially recorded on the blockchain, which is considered to be a consensus success. When the consensus is successful, the transaction contained in the consensus successful block has been written into the blockchain together with the block. Then according to the shard mapping relationship of the transaction, find the target shard container where the transaction originally stores, delete the corresponding transaction record in the container to release the storage resource, and prevent the chained transaction from being processed repeatedly.

[0055] As an optional implementation, when the transaction is successfully deleted, the target shard container of the transaction is determined by the transaction hash, and the transaction is removed from the target shard container after the exclusive lock is added to the shard container.

[0056] As an optional implementation, Figure 2 is a flowchart of the transaction bucketing method provided by the embodiment of the application, as shown in Figure 2 According to the transaction hash, the corresponding transaction is put into the target shard container, and the transaction state is initialized to the unpacked state, including:

[0057] S101, calculate the remainder of the transaction hash divided by the total number of shard containers;

[0058] After obtaining the transaction, perform a modulo operation based on the transaction hash of the transaction, the calculation formula is "transaction hash value ÷ total number of shard containers", and according to the remainder in the result, determine which shard container the transaction should be allocated to. The remainder ensures that the transaction is distributed among multiple shards according to the rules.

[0059] S102, the remainder is used as the shard container index number of the corresponding transaction, and an exclusive lock is added to the target shard container corresponding to the shard container index number; wherein all shard containers are pre-configured with index numbers;

[0060] The remainder obtained in the previous step is directly used as the shard container index number of the transaction, which is used to locate the target shard container; before accessing the target shard container, an exclusive lock is added to ensure that the current thread has exclusive access to the shard container during writing, preventing other threads from writing or modifying at the same time.

[0061] For example, the transaction hash is converted to decimal and is 20, and the total number of shard containers is 16, so 20 / 16=1 remainder 4, and the transaction corresponding to the transaction hash should be placed in the shard container with index number 4.

[0062] In addition, it is explained here that all shard containers are allocated index numbers at system initialization, ensuring that the hash modulo result can be directly used for index matching.

[0063] S103, place the transaction in the target shard container corresponding to the index number of the shard container, and release the exclusive lock.

[0064] Under the condition of holding the exclusive lock, write the transaction data into the shard container corresponding to the index number, and immediately release the exclusive lock after writing is completed to allow other threads to access the shard container.

[0065] As an optional implementation, Figure 3 is a flowchart of the unpacked state updating method provided by the embodiment of the application, as shown in Figure 3 all transactions in all shard containers are traversed, and the transactions in the unpacked state are modified in state through compare-and-swap to obtain transactions in the to-be-packed state, including:

[0066] S201, traverse all shard containers, and when any shard container is accessed, add a shared lock to the any shard container as the current shard container;

[0067] All shard containers are accessed in turn, and when a specific shard container is accessed, the shard container is taken as the current shard container, and a shared lock is added to the current shard container before a read operation is performed on the current shard container. The shared lock allows multiple threads to read the container content at the same time, but prohibits write operation, so as to ensure that the data structure is not modified during traversal.

[0068] S202, traverse all transactions in the current shard container, modify the transactions in the unpacked state in state through compare-and-swap to obtain transactions in the to-be-packed state, and release the shared lock.

[0069] After the shared lock is added to the current shard container, all transactions in the container are accessed and checked one by one, if a transaction is in the unpacked state, a compare-and-swap (CAS) operation is used to judge and attempt to modify the state of the transaction to the to-be-packed state; when the state modification is successful, the transaction can be regarded as a selected to-be-packed transaction; after all traversal and state modification operations are completed, the shared lock of the shard container is released.

[0070] As an optional implementation, Figure 4 is a flowchart of the to-be-packed state updating method provided by the embodiment of the application, as shown in Figure 4As shown, the pending packaged state of the transaction is modified to the packaged state by comparison and exchange, and the transaction packaged block number and transaction packaged block hash are set according to the transaction in the packaged state in the block to which it belongs, including:

[0071] S301. When a consensus request is received, the target shard container is determined based on the transaction hash corresponding to the transaction to be packaged, and a shared lock is added to the target shard container.

[0072] After receiving a consensus request for a block, a node obtains each pending transaction in the block and calculates the shard container index corresponding to the transaction by reading the transaction hash and combining it with a sharding strategy (such as hash modulo). This determines the target shard container for the transaction. A shared lock is then placed on the target shard container to allow secure reading and modification of the transaction status without blocking other read threads.

[0073] S302: For any transaction in the pending packaging state, modify the pending packaging state of the current transaction to the packaged state through comparison and exchange, assign the transaction packaging block number and transaction packaging block hash of the block to which it belongs to the current transaction, and release the shared lock.

[0074] Under the condition of holding a shared lock, the transaction in the target shard container with the status of "to be packaged" is processed: through the compare and exchange (CAS) operation, it is determined whether its status is still "to be packaged". If it is consistent, the status is changed to "packaged", and the transaction packaging block number and transaction packaging block hash of the current block are written to the corresponding fields of the transaction; after the modification is completed, the shared lock of the shard container is released, allowing other threads to continue to access the container.

[0075] As an optional implementation, Figure 5 is a flow chart of a packaged status update method provided by an embodiment of the present invention, such as Figure 5 As shown, for transactions in the packaged state in the consensus failure block, the transaction status is modified to the unpackaged state by comparing and exchanging the transaction package block number and the transaction package block hash, including:

[0076] S401. For any packaged transaction, determine whether its transaction package block number is consistent with the transaction package block number of the consensus failure block, and whether its transaction package block hash is consistent with the transaction package block hash of the consensus failure block;

[0077] In the scenario of processing block consensus failure, all current state is "packed" transaction judgment operation, in turn compare each transaction in the transaction packing block number and transaction packing block hash whether respectively with the current consensus failure block transaction packing block number and transaction packing block hash consistent. The judgment is used to confirm that the transaction indeed belongs to this consensus failure block, so as to decide whether to need to carry out state rollback processing.

[0078] S402, when the transaction packing block number judgment is consistent and the transaction packing block hash judgment is consistent, the target shard container is determined according to the transaction hash of the transaction, and the target shard container is shared locked, and the transaction state of the transaction is modified to an unpacked state by comparing and exchanging, and the shared lock is released.

[0079] When it is confirmed that the transaction packing block number and the transaction packing block hash of a certain transaction are consistent with the current consensus failure block, the transaction is read to calculate the shard container index number it is in, so as to locate the target shard container corresponding to the transaction; then the target shard container is shared locked, and the compare-and-swap operation is executed on the transaction in the locked state, if the current state is "packed", the state is modified to "unpacked", so that the transaction participates in packing again; after the transaction state modification is completed, the shared lock is released.

[0080] The embodiment of the application also provides a transaction parallel processing system based on a block chain, Figure 6 is a structural schematic diagram of the transaction parallel processing system based on the block chain provided by the embodiment of the application, as Figure 6 shown, the system comprises:

[0081] The bucketing module 100 is used for obtaining a transaction and calculating the transaction hash of the transaction, putting the corresponding transaction into a target shard container according to the transaction hash, and initializing the transaction state to an unpacked state.

[0082] After the block chain system receives a new transaction, the transaction hash of the received transaction is calculated, which is used for uniquely identifying the transaction. The transaction hash is usually calculated by a hash function, which is the basis for subsequent positioning of shards.

[0083] The transaction pool is divided into a plurality of shard containers, the transaction hash is taken as input, the target shard container is determined according to the preset number of shard containers through the mapping relationship between the transaction hash and the number of containers, and the transaction is written into the target shard container for storage.

[0084] At the same time when the transaction is written into the shard container, the initial state of the transaction is set, and the state value is "unpacked", which is used for identifying that the transaction has not been processed or packed by any node.

[0085] The first state modification module 200 is configured to traverse all transactions in all shard containers, modify the state of the transaction in the unpacked state by using the compare-and-swap operation, and obtain the transaction in the to-be-packed state.

[0086] The packing node needs to obtain the transaction in the unpacked state from the transaction pool. In this process, the packing node accesses each set shard container in turn and accesses all transactions contained in each shard container one by one. This process is a comprehensive check of all transactions, which is used for subsequent state judgment.

[0087] In the traversal process, the state of each transaction is judged. If the state of the transaction is "unpacked", the state of the transaction is modified to "to-be-packed" by using the compare-and-swap operation. The meaning of the compare-and-swap operation is that only when the current state value is consistent with the expected value (i.e., "unpacked"), the state is modified to the target value (i.e., "to-be-packed"). Otherwise, the modification operation is not performed.

[0088] Through the above compare-and-swap operation, the transaction whose state is successfully modified to "to-be-packed" is the output result of this step, which can be used for subsequent packing.

[0089] The second state modification module 300 is configured to pack the transaction in the to-be-packed state into a block and initiate a consensus request, modify the to-be-packed state of the transaction to the packed state by using the compare-and-swap operation, and set the transaction packing block number and the transaction packing block hash for the transaction in the packed state according to the block.

[0090] The packing node packs the transaction in the to-be-packed state obtained from the transaction pool into a block to initiate a consensus request, that is, broadcasts the block to other nodes in the blockchain network, starts the consensus process of the block, and determines whether the block can be accepted and finally written into the blockchain.

[0091] After initiating the consensus, the state of the transaction packed into the block is updated to "packed" by using the compare-and-swap operation if the current state of the transaction is "to-be-packed". After the state of the transaction is updated to "packed", the transaction packing block number and the transaction packing block hash of the transaction are written into the corresponding fields of the transaction to record the block information of the transaction. The state update operation can be performed asynchronously with the consensus operation.

[0092] The third state modification module 400 is configured to modify the state of the transaction in the packed state in the consensus-failed block to the unpacked state by using the compare-and-swap operation according to the transaction packing block number and the transaction packing block hash when the block consensus fails.

[0093] After initiating a consensus request for a certain block, the consensus condition set by the blockchain system is not met, resulting in the block failing to be confirmed or written into the blockchain, which is regarded as a block consensus failure.

[0094] Among all the transactions packed into the failed block, there are transactions whose current state is "packed" but have not been written into the chain due to the unsuccessful consensus of the block. To determine these transactions, the packed block number and block hash recorded in each transaction are matched with the identifier of the current failed block. When it is confirmed that the transaction indeed belongs to the current failed block, the state is still "packed" by using the compare-and-swap operation, and if it matches, the state is modified to "unpacked" so as to participate in subsequent packing processing again.

[0095] The first state modification module (unpacked modification to be packed), the second state modification module (to be packed modification to be packed and record block information), and the third state modification module (consensus failure rollback) can be performed simultaneously by different threads, and do not block each other, achieving parallel processing. The processing efficiency is improved.

[0096] Table 1 shows the state field change rules and modification limitation conditions when using compare-and-swap (CAS) to modify three different states.

[0097] The deletion module 500 is used to remove the successfully uploaded transactions in the consensus successful block from the target shard container when the block consensus is successful.

[0098] A certain candidate block is verified and confirmed by each node in the blockchain network, meets the preset consensus condition, and is officially recorded on the blockchain, which is regarded as a consensus success. When the consensus is successful, the transactions contained in the consensus successful block are written into the blockchain together with the block. Then, according to the shard mapping relationship of the transaction, the target shard container where the transaction is originally stored is found, and the corresponding transaction record is deleted in the container to release the storage resource and prevent the already uploaded transaction from being processed repeatedly.

[0099] As an optional implementation, when the successfully uploaded transaction is deleted, the target shard container of the transaction is determined by the transaction hash, and the transaction is removed from the target shard container after the exclusive lock is added to the shard container.

[0100] As an optional implementation, Figure 7 is a structural schematic diagram of the bucketing module provided by the embodiment of the present application, as Figure 7 shown, the bucketing module 100 includes:

[0101] The remainder calculation submodule 1001 is used to calculate the remainder of the transaction hash divided by the total number of shard containers.

[0102] After obtaining the transaction, a modulo operation is performed based on the transaction hash of the transaction, with the formula being "transaction hash ÷ total number of shard containers", and according to the remainder in the result, it is determined to which shard container the transaction should be allocated. The remainder ensures that the transactions are regularly distributed among multiple shards.

[0103] The shard container determination submodule 1002 is configured to take the remainder as the shard container index number of the corresponding transaction, and add an exclusive lock to the target shard container corresponding to the shard container index number; wherein all shard containers are pre-configured with index numbers;

[0104] The remainder obtained in the previous step is directly taken as the shard container index number of the transaction, which is used to locate the target shard container; before accessing the target shard container, an exclusive lock is added to ensure that the current thread has exclusive access to the shard container during writing, preventing other threads from simultaneously writing or modifying.

[0105] For example, the transaction hash is converted to decimal as 20, and the total number of shard containers is 16, so 20 / 16=1 remainder 4, and the transaction corresponding to the transaction hash should be placed in the shard container with index number 4.

[0106] In addition, it is stated here that all shard containers have been allocated index numbers at system initialization, ensuring that the hash modulo result can be directly used for index matching.

[0107] The transaction storage submodule 1003 is configured to place the transaction in the target shard container corresponding to the shard container index number, and release the exclusive lock.

[0108] Under the condition of holding the exclusive lock, the transaction data is written into the shard container corresponding to the index number, and after the writing is completed, the exclusive lock is immediately released to allow other threads to access the shard container.

[0109] As an optional implementation, Figure 8 is a structural diagram of the first state modification module provided by the embodiment of the application, as Figure 8 shown, the first state modification module 200 includes:

[0110] The container traversal submodule 2001 is configured to traverse all shard containers, and when any shard container is accessed, the any shard container is taken as the current shard container and a shared lock is added to the current shard container;

[0111] All shard containers are accessed in turn, and when a specific shard container is accessed, the shard container is taken as the current shard container, and a shared lock is added to the current shard container before a read operation is performed on the current shard container. The shared lock allows multiple threads to read the container content at the same time, but prohibits write operation, so as to ensure that the data structure is not modified during traversal.

[0112] The transaction traversal submodule 2002 is used for traversing all transactions in the current shard container, modifying the state of the unpacked transaction through compare-and-swap, obtaining the transaction in the to-be-packed state, and releasing the shared lock.

[0113] After the shared lock is added to the current shard container, all transactions in the container are accessed and checked one by one, if a transaction is in the unpacked state, the state is modified to the to-be-packed state using the compare-and-swap (CAS) operation; when the state modification is successful, the transaction is considered as a selected to-be-packed transaction; after all the traversal and state modification operations are completed, the shared lock of the shard container is released.

[0114] As an optional implementation, Figure 9 is a structural diagram of the second state modification module provided by the embodiment of the application, as shown in Figure 9 The second state modification module 300 includes:

[0115] The positioning submodule 3001 is used for, when receiving a consensus request, determining a target shard container according to the transaction hash corresponding to the transaction in the to-be-packed state, and adding a shared lock to the target shard container;

[0116] After the node receives the consensus request of the block, each transaction in the to-be-packed state included in the block is obtained, the transaction hash of the transaction is read, and the shard container index number corresponding to the transaction is calculated by combining the shard strategy (such as hash modulo), so as to determine the target shard container where the transaction is located. Then, a shared lock is added to the target shard container, so as to safely read and modify the transaction state without blocking other reading threads.

[0117] The first state update submodule 3002 is used for, for any transaction in the to-be-packed state, modifying the to-be-packed state of the current transaction to the packed state through compare-and-swap, and assigning the transaction packed block number and transaction packed block hash of the block to the current transaction, and releasing the shared lock.

[0118] Under the condition of holding the shared lock, the transaction in the target shard container in the to-be-packed state is processed: whether the state is still in the to-be-packed state is determined through the compare-and-swap (CAS) operation, if consistent, the state is modified to the packed state, and the transaction packed block number and transaction packed block hash of the current block are written into the corresponding field of the transaction; after the modification is completed, the shared lock of the shard container is released, and other threads are allowed to continue to access the container.

[0119] As an optional implementation, Figure 10 is a structural diagram of the third state modification module provided by the embodiment of the application, as shown in Figure 10 The third state modification module 400 includes:

[0120] A judgment submodule 4001 is configured to judge, for any transaction in a packaged state, whether the transaction packaging block number of the transaction is consistent with the transaction packaging block number of the consensus failure block and whether the transaction packaging block hash of the transaction is consistent with the transaction packaging block hash of the consensus failure block.

[0121] In the case of processing block consensus failure, all transactions in a current state of "packaged" are subjected to a judgment operation, and the transaction packaging block number and the transaction packaging block hash recorded in each transaction are compared in turn to determine whether they are consistent with the transaction packaging block number and the transaction packaging block hash of the current consensus failure block, respectively. The judgment is used to confirm that the transaction indeed belongs to the block of the current consensus failure, so as to determine whether state rollback processing is needed.

[0122] A second state update submodule 4002 is configured to, when the transaction packaging block number is consistent and the transaction packaging block hash is consistent, determine a target shard container according to the transaction hash of the transaction, add a shared lock to the target shard container, modify the transaction state of the transaction to an unpackaged state through a compare-and-swap operation, and then release the shared lock.

[0123] When it is confirmed that the transaction packaging block number and the transaction packaging block hash of a certain transaction are consistent with the current consensus failure block, the transaction container index number where the transaction is located is calculated by reading the transaction, so as to locate the target shard container corresponding to the transaction. Then, a shared lock is added to the target shard container, and a compare-and-swap operation is performed on the transaction in the locked state. If the current state of the transaction is "packaged", the state of the transaction is modified to "unpackaged" so that the transaction can participate in packaging again. After the transaction state is modified, the shared lock is released.

[0124] The above technical solution has the following beneficial effects: By introducing a shard container mechanism based on transaction hash, distributed storage and access of transactions are realized, and competition and conflict among threads for the same data structure are reduced. By combining shared locks and exclusive locks to control container access permissions at the shard granularity, the concurrent safety of the system is further improved. At the same time, the transaction state is updated using the atomic operation of compare-and-swap, the states of unpackaged, to-be-packaged, packaged, and failure rollback are modified in parallel, efficient execution is realized, and the transaction processing throughput and overall system performance are significantly improved.

[0125] The specific embodiments of the above invention further illustrate the purposes, technical solutions, and beneficial effects of the invention. It should be understood that the above content is only a specific embodiment of the invention and is not used to limit the protection scope of the invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the invention shall be included in the protection scope of the invention.

Claims

1. A transaction parallel processing method based on blockchain, characterized in that: The method comprises the following steps: S1, obtaining a transaction and calculating a transaction hash of the transaction, putting the corresponding transaction into a target shard container according to the transaction hash, and initializing the transaction state as an unpacked state; S2, traversing all transactions in all shard containers, modifying the state of the transaction in the unpacked state through compare-and-swap, and obtaining the transaction in the packed state; S3, packing the transaction in the packed state into a block and initiating a consensus request, modifying the transaction in the packed state to the packed state through compare-and-swap, and setting the transaction packing block number and the transaction packing block hash of the transaction according to the block; S4, when the block consensus fails, modifying the transaction state of the transaction in the packed state in the consensus failed block to the unpacked state according to the transaction packing block number and the transaction packing block hash through compare-and-swap; wherein steps S2-S4 are processed in parallel by different threads; S5, when the block consensus succeeds, removing the transaction in the consensus successful block from the target shard container. 2.The method of claim 1, wherein, The method comprises the following steps: S101, calculating the remainder of the transaction hash divided by the total number of shard containers; S102, taking the remainder as the shard container index number of the corresponding transaction, and adding an exclusive lock to the target shard container corresponding to the shard container index number; wherein all shard containers are pre-configured with index numbers; S103, putting the transaction into the target shard container corresponding to the shard container index number, and releasing the exclusive lock. 3.The method of claim 1, wherein, The method comprises the following steps: S201, traversing all shard containers, and adding a shared lock to any shard container as a current shard container when accessing the any shard container; S202, traversing all transactions in the current shard container, modifying the state of the transaction in the unpacked state through compare-and-swap to obtain the transaction in the packed state, and releasing the shared lock. 4.The method of claim 1, wherein, The method comprises the following steps: S301, when receiving a consensus request, determining a target shard container according to the transaction hash corresponding to the transaction in the packed state, and adding a shared lock to the target shard container; S302, for any transaction in the packed state, modifying the state of the current transaction in the packed state to the packed state through compare-and-swap, and assigning the transaction packing block number and the transaction packing block hash of the block to the current transaction, and releasing the shared lock. 5.The method of claim 1, wherein, The method comprises the following steps: S401, for any transaction in a packed state, judge whether the transaction packing block number is consistent with the transaction packing block number of the consensus failure block, and whether the transaction packing block hash is consistent with the transaction packing block hash of the consensus failure block; S402, when the transaction packing block number judgment is consistent and the transaction packing block hash judgment is consistent, determine the target shard container according to the transaction hash of the transaction, and add a shared lock to the target shard container, modify the transaction state of the transaction to an unpacked state by compare-and-swap, and release the shared lock. 6.A blockchain-based transaction parallel processing system, characterized by, It comprises: a bucketing module configured to obtain a transaction and calculate a transaction hash of the transaction, place the corresponding transaction into a target shard container according to the transaction hash, and initialize a transaction state to an unpacked state; a first state modification module configured to traverse all transactions in all shard containers, modify the state of a transaction in an unpacked state by compare-and-swap, and obtain a transaction in a to-be-packed state; a second state modification module configured to pack the transaction in the to-be-packed state into a block and initiate a consensus request, modify the to-be-packed state of the transaction to a packed state by compare-and-swap, and set a transaction packing block number and a transaction packing block hash for the transaction in the packed state according to the block; a third state modification module configured to, when the block consensus fails, modify the transaction state of a transaction in a packed state in the consensus failure block to an unpacked state according to the transaction packing block number and the transaction packing block hash by compare-and-swap; a deletion module configured to, when the block consensus succeeds, remove a transaction successfully uploaded onto a chain in a consensus success block from a target shard container. 7.The blockchain-based transaction parallel processing system of claim 6, wherein, The bucketing module comprises: a remainder calculation submodule configured to calculate a remainder of the transaction hash divided by a total number of shard containers; a shard container determination submodule configured to take the remainder as a shard container index number of the corresponding transaction, and add an exclusive lock to a target shard container corresponding to the shard container index number; wherein all shard containers are pre-provided with index numbers; a transaction storage submodule configured to place the transaction into the target shard container corresponding to the shard container index number, and release the exclusive lock. 8.The blockchain-based transaction parallel processing system of claim 6, wherein, The first state modification module comprises: a container traversal submodule configured to traverse all shard containers, and add a shared lock to any shard container as a current shard container when the any shard container is accessed; a transaction traversal submodule configured to traverse all transactions in the current shard container, modify the state of a transaction in an unpacked state by compare-and-swap, and obtain a transaction in a to-be-packed state, and release the shared lock. 9.The blockchain-based transaction parallel processing system according to claim 6, wherein, The second state modification module comprises: a positioning submodule configured to, when a consensus request is received, determine a target shard container according to a transaction hash corresponding to a transaction in a to-be-packed state, and add a shared lock to the target shard container; a first state update submodule configured to, for any transaction in a to-be-packed state, modify the to-be-packed state of the current transaction to a packed state by compare-and-swap, and assign a transaction packing block number and a transaction packing block hash of the block to the current transaction, and release the shared lock. 10.The blockchain-based transaction parallel processing system of claim 6, wherein, The third state modification module comprises: A judgment submodule is configured to judge, for any transaction in a packaged state, whether the transaction packaging block number of the transaction is consistent with the transaction packaging block number of the consensus failure block and whether the transaction packaging block hash of the transaction is consistent with the transaction packaging block hash of the consensus failure block. A second state updating submodule is configured to, when the transaction packaging block number is consistent and the transaction packaging block hash is consistent, determine a target shard container according to the transaction hash of the transaction, add a shared lock to the target shard container, modify the transaction state of the transaction to an unpackaged state through compare-and-swap, and release the shared lock.

Images