Parallel transaction processing method, system and computer storage medium for blockchain

Abstract

The present application relates to a parallel transaction processing method, system and computer storage medium of blockchain, one aspect is to set X consensus nodes as master nodes, and distribute the additional workload bound to the master nodes to X copies instead of one copy, and to reduce the workload of the master nodes by shunting; another aspect is to divide the transaction request into Y partitions, and distribute them to Z master nodes to realize parallelism in the request transaction stage; both combine workflow consensus -> execution and workflow execution -> consensus -> verification, partition the request, and perform the workflow in parallel, the nodes call the consensus protocol for part of the partitioned transaction request to agree on the order of the transaction, and the normal nodes perform speculative execution of the client transaction in parallel, when there is inconsistency, only the transaction request guided by one master node restarts the execution of the consensus protocol and the normal nodes simultaneously perform speculative transactions, which greatly improves the workflow speed and response speed, and reduces the task amount of a single master node.

Description

Technical Field

[0001] This invention relates to the field of blockchain, and in particular to a parallel transaction processing technology for blockchain. Background Technology

[0002] Cross-enterprise transaction applications (e.g., stock trading) facilitate the instant recording and clearing of transactions between mutually distrustful participants (e.g., customers and merchants). These applications are typically deployed across one or more data centers connected via dedicated network cables to handle large volumes of transactions with real-time commit latency. Blockchain, capable of handling distributed transactions, is widely used by numerous applications and has also attracted academia to develop various permissioned blockchain frameworks for transaction applications. Permissioned blockchains, maintained collaboratively by a large number of identifiable participants, can rapidly commit transactions using Byzantine Fault-Tolerant (BFT) consensus protocols.

[0003] Existing BFT systems use a single replica as the master node leader (whether for fully ordering requests or performing preparation), which effectively slows down application processing. To some extent, this problem can be mitigated by rotating the leader role among replicas. However, since these methods are based on a fully ordered sequence of requests and merely distribute the responsibility for establishing that sequence, their effectiveness is limited.

[0004] To enable the BFT system to process multiple transaction requests concurrently, the additional workload bound to the leader role is distributed across all replicas, achieving parallelism during the transaction request phase. However, this is implemented by managing each partition within a separate BFT protocol instance and predicting the workflow. Nodes verify the results, submit valid results, and abort invalid results. The workflow is execution → consensus → verification, but this approach has a high abort rate.

[0005] Therefore, how to reduce the load on the master node while improving workflow efficiency is a technical problem that urgently needs to be solved in blockchain transaction processing. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a parallel transaction processing method for blockchain, comprising:

[0007] S1: Divide the blockchain nodes into normal nodes and consensus nodes, and select X consensus nodes as master nodes;

[0008] S2: Upload the transaction request and divide the transaction request into Y partitions;

[0009] S3: Among the X master nodes, select Z master nodes to guide the transaction requests of Y partitions;

[0010] S4: Z master nodes, which sort and identify the transaction requests they initiate, and broadcast them to consensus nodes and normal nodes;

[0011] S5: Sort and number the Z master nodes, and let n = 1;

[0012] S6: Consensus nodes and normal nodes sort the transaction requests initiated by the nth master node respectively;

[0013] S7: Determine whether the sorting results of the consensus node and the normal node for the transaction requests guided by the nth master node are consistent;

[0014] S8: If inconsistent, return to step S6;

[0015] S9: If they match, the transaction request initiated by the nth master node is successful. Let n = n + 1.

[0016] S10: Determine whether n > Z is true;

[0017] S11, if not, return to step S6, if yes, end;

[0018] Where X, Y, and Z are positive integers, and X > 1; Y > 1; 1 < Z ≤ X.

[0019] Further, step S2 includes,

[0020] S21: Extract the characteristics of the transaction request;

[0021] S22: Divide the transaction request into Y partitions based on the characteristics of the transaction request.

[0022] Further, step S3 includes:

[0023] S31: Get the number of transaction requests for each partition;

[0024] S32: Get the current capacity threshold for each master node;

[0025] S33: Based on the number of transaction requests for each partition and the current capacity threshold of each master node, select Z master nodes from X master nodes to guide the transaction requests for Y partitions, so that the number of transaction requests guided by each master node does not exceed its current capacity threshold.

[0026] Further, step S33 includes:

[0027] S331: Number the Y partitions as Y i Number the Z master nodes as Z j , 1≤i≤Y, 1≤j≤Z;

[0028] S332: Initialize i = 1, j = 1;

[0029] S333: Determine the number of transaction requests y in the i-th partition. i Does it exceed the current capacity threshold z of the j-th master node? j ;

[0030] S334: If not, then allocate the transaction request of the i-th partition to the j-th master node; let i = i + 1; determine whether i > Y or j > Z is true. If yes, end; otherwise, return to step S333.

[0031] S335: If so, then the first z of the i-th partition... j A transaction request is assigned to the j-th master node, and the number of transaction requests in the i-th partition is y. i =y i -z j Let j = j + 1; return to step S332.

[0032] Further, step S33 includes:

[0033] S331': Number the Y partitions as Y i Number the Z master nodes as Z j , 1≤i≤Y, 1≤j≤Z;

[0034] S332': Initialize i = 1, j = 1;

[0035] S333': Determine the number of transaction requests y in the i-th partition. i Does it exceed the current capacity threshold x of the j-th master node? j ;

[0036] S334': If not, then allocate the transaction request of the i-th partition to the j-th master node; let i = i + 1, j = j + 1; determine whether i > Y or j > X is true, if yes, end, otherwise return to step S333';

[0037] S335': If so, then the first z of the i-th partition... j A transaction request is assigned to the j-th master node, and the number of transaction requests in the i-th partition is y. i =y i -z j Let j = j + 1; return to step S332'.

[0038] Furthermore, step S2 also includes:

[0039] S23: Prioritize the Y partitions based on the characteristics of the transaction requests.

[0040] Further, step S2 includes:

[0041] S21': Sort the master nodes by number and extract the current capacity threshold for each master node;

[0042] S22': Divide the transaction requests into Y partitions according to the current capacity threshold of each master node;

[0043] Step S3 includes:

[0044] S31': Distribute the transaction requests of Y partitions to Z master nodes in sequence, where Z = Y.

[0045] On the other hand, the present invention also provides a parallel transaction processing system for blockchain, comprising:

[0046] A node partitioning device is used to divide blockchain nodes into normal nodes and consensus nodes, and select X consensus nodes as master nodes.

[0047] A request partitioning device is used to upload transaction requests and divide the transaction requests into Y partitions;

[0048] A node selection device is used to select Z master nodes from X master nodes to guide transaction requests for Y partitions;

[0049] The sorting consistency determination device is used for:

[0050] Z master nodes sort and identify the transaction requests they initiate, and broadcast them to consensus nodes and normal nodes;

[0051] Sort and number the Z master nodes, and let n = 1;

[0052] Consensus nodes and normal nodes respectively sort the transaction requests initiated by the nth master node;

[0053] Determine whether the sorting results of the consensus node and the normal nodes for the transaction requests initiated by the nth master node are consistent.

[0054] If inconsistent, reorder;

[0055] If they match, the transaction request initiated by the nth master node is successful, until all master nodes have been traversed.

[0056] Where X, Y, and Z are positive integers, and X > 1; Y > 1; 1 < Z ≤ X.

[0057] Furthermore, a parallel transaction processing system is used to execute any of the above-mentioned parallel transaction processing methods.

[0058] On the other hand, the present invention also provides a computer storage medium storing a computer program; the computer program is used to execute any of the above-described parallel transaction processing methods.

[0059] The parallel transaction processing method, system, and computer storage medium of this invention, compared to the existing technology which uses only one master node, sets X consensus nodes as master nodes and distributes the additional workload bound to the master node to X replicas instead of a single replica, thus reducing the workload of the master node. Furthermore, it divides transaction requests into Y partitions and distributes them to Z master nodes, achieving parallelism in the transaction request phase. Both methods combine workflow consensus → execution with workflow execution → consensus → verification, partitioning requests and performing workflows in parallel. Nodes invoke consensus protocols (such as Byzantine fault tolerance) to agree on the order of transactions for some partitions, and normal nodes perform speculative execution of client transactions in parallel. When inconsistencies occur, only the transaction request guided by one master node restarts the consensus protocol execution while normal nodes simultaneously perform speculative transactions, significantly improving workflow speed and reducing the workload of a single master node. For example, in traditional methods, if there are 100 transaction requests guided by a single master node, not only do these 100 requests need to be sorted, but if an error occurs, both the consensus node and the normal node need to reorder and execute these 100 transaction requests. This results in a large workload and slow response time. The parallel transaction processing method of this invention not only uses consensus nodes and normal nodes to perform workflow sorting and verification in parallel to exclude malicious nodes, but also partitions the transaction requests and assigns them to multiple master nodes. Each time, only the transaction requests guided by one master node are sorted and executed. If an error occurs, only the transaction requests guided by that master node need to be reordered and executed, greatly reducing the workload and improving the response speed. Attached Figure Description

[0060] Figure 1 A flowchart illustrating one embodiment of the parallel transaction processing method for blockchain according to the present invention;

[0061] Figure 2 This is a diagram illustrating a transaction request. Detailed Implementation

[0062] like Figure 1 As shown, a parallel transaction processing method for blockchain is provided, including:

[0063] S1: Divide the blockchain nodes into normal nodes and consensus nodes, and select X consensus nodes as master nodes; where X is a positive integer, and X > 1. Specifically, normal nodes are nodes that do not participate in the consensus protocol ordering process; consensus nodes are nodes that participate in the consensus protocol ordering process. More specifically, each consensus node can be randomly promoted to a master node (leader), and clients assign transaction requests to master nodes (the responsible consensus nodes). More specifically, consensus nodes can, but are not limited to, using the Byzantine Fault Tolerance (BFT) consensus mechanism.

[0064] S2: Upload transaction requests and divide them into Y partitions; where Y is a positive integer and Y > 1. Specifically, the partitioning can be optional but not limited to based on the characteristics of the transaction requests and / or the characteristics of the master node. More specifically, the characteristics of the transaction requests can be optional but not limited to the type of the transaction request; the characteristics of the master node can be optional but not limited to the master node's load (capacity threshold, i.e., the maximum number of transaction requests it can handle), runtime status (current processing volume), etc. More specifically, the client can optional but not limited to uploading transaction requests to the consensus node and configuring a predictor component for the consensus node to analyze and extract the characteristics of the transaction requests and / or the characteristics of the master node, dividing the transaction request partitions into Y partitions. More specifically, the predictor component can be optional but not limited to being set to a predictor with the same structure, carrying the application's PREDICT() function to analyze the characteristics of each transaction request and the master node.

[0065] S3: Among X master nodes, select Z master nodes to guide transaction requests for Y partitions; Z is a positive integer, and 1 < Z ≤ X. Specifically, each master node (leader) can, but is not limited to, guide transaction requests for one or more partitions, and perform subsequent execution phases in parallel. That is, for transaction requests for Y partitions, the total number of master nodes X and the number of selected master nodes Z can, but is not limited to, be equal to, less than, or greater than Y. For example, assuming the transaction requests are divided into 5 partitions (Y), the number of master nodes can be any integer greater than 1. If the total number of master nodes (X) is 3, then the transaction requests for 5 partitions can, but is not limited to, be assigned to 2 (Z) master nodes or 3 (Z) master nodes, one of which may guide one or more partitions; if the total number of master nodes (X) is 6, then the transaction requests for 5 partitions can, but is not limited to, be assigned to 2, 3, 4, or 5 (Z) partitions, one of which may guide one or more partitions, and there may also be spare master nodes that have not been assigned any partitions.

[0066] S4: Z master nodes, which sort and identify the transaction requests they initiate, and broadcast them to consensus nodes and normal nodes; specifically, the master node leader can be selected, but is not limited to, acting as a sequencer, using consecutive sequence numbers to sort the transaction requests it initiates, and attaching a signature identifier to each transaction request to facilitate subsequent one-to-one correspondence.

[0067] S5: Sort and number the Z master nodes, and let n = 1;

[0068] S6: Consensus nodes and normal nodes respectively sort the transaction requests initiated by the nth master node. Specifically, the consensus node runs a consensus algorithm, such as the Byzantine Fault Tolerance (BFT) protocol, to sort the transaction requests within a single master node's initiation. Preferably, consensus is reached according to the hash sequence of each transaction request, running only one request at a time, with the others serving as placeholders. Specifically, execution can optionally, but is not limited to, starting with the transaction request with the smallest ID number. Specifically, normal nodes use a scheduler within a single master node's initiation to obtain the sequence number of the transaction requests and then speculatively execute the transaction requests (client physical objects) sequentially. More specifically, to ensure system state consistency during non-deterministic transactions, the system employs a multi-write protocol to ensure that normal nodes follow the same execution results.

[0069] S7: Determine whether the sorting results of the consensus node and normal nodes for the transaction requests guided by the nth master node are consistent; specifically, start judging from the first transaction request guided by this master node until the last transaction request. If there is no inconsistency in the sorting, it is judged as consistent; if there is one inconsistency in the sorting, it is judged as inconsistent, and no further judgment is needed for the subsequent ones.

[0070] S8: If inconsistent, return to step S6. Specifically, if inconsistent, it indicates the presence of an adversary, i.e., a malicious node (which could be a consensus node or a normal node), transaction errors, etc., causing the transaction order to be inconsistent, and consequently the results will also be inconsistent. In this case, the transaction needs to be stopped, and step S6 needs to be returned. A new consensus node is then used to perform consensus ordering on the requested workflow. For example, in the Byzantine Fault Tolerance (BFT) protocol consensus, there is a node attempting to change the protocol to guide other consensus nodes into a permissioned blockchain. At the same time, normal nodes also reorder the request flow according to the agreed order.

[0071] S9: If they match, the transaction request initiated by the nth master node is successful. Let n = n + 1. Specifically, if they match, it means that there is no counterparty, i.e., malicious nodes, transaction errors, etc., which would cause the transaction order of the two to be inconsistent, and thus the results would also be inconsistent. In this case, the transaction request can be submitted to ensure that the transaction request initiated by the master node is successful.

[0072] S10: Determine if n > Z is true; specifically, after executing step S9, that is, after completing the traversal of the transaction request guided by a master node (the nth master node), it is necessary to enter the next master node (the n = n+1th master node). At this time, it is necessary to determine whether all master nodes have been traversed and the selected number of master nodes has been reached.

[0073] S11. If not, return to step S6; if yes, end.

[0074] The parallel transaction processing method for blockchain of this invention, on the one hand, compared with the existing technology which has only one master node, sets X consensus nodes as master nodes and distributes the additional workload bound to the master node to X replicas instead of a single replica, thus reducing the workload of the master node; on the other hand, it divides transaction requests into Y partitions and distributes them to Z master nodes, achieving parallelism in the request transaction stage; both combine workflow consensus → execution and workflow execution → consensus → verification, partitioning requests and performing workflow in parallel. Nodes call consensus protocols (such as Byzantine fault tolerance) for transaction requests in some partitions to agree on the order of transactions, and perform normal node speculative execution of client transactions in parallel. When inconsistencies occur, only the transaction request guided by one master node restarts the execution of the consensus protocol while normal nodes simultaneously perform speculative transactions, greatly improving workflow speed and reducing the workload of a single master node. For example, in traditional methods, if there are 100 transaction requests guided by a single master node, not only do these 100 requests need to be sorted, but if an error occurs, both the consensus node and the normal node need to reorder and execute these 100 transaction requests. This results in a large workload and slow response time. The parallel transaction processing method of this invention not only uses consensus nodes and normal nodes to perform workflow sorting and verification in parallel to exclude malicious nodes, but also partitions the transaction requests and assigns them to multiple master nodes. Each time, only the transaction requests guided by one master node are sorted and executed. If an error occurs, only the transaction requests guided by that master node need to be reordered and executed, greatly reducing the workload and improving the response speed.

[0075] Preferably, in one embodiment, step S2 may optionally include, but is not limited to:

[0076] S21: Extract the characteristics of the transaction request; S22: Divide the transaction request into Y partitions {D1……D2} based on the characteristics of the transaction request. Y D stands for Deal. Specifically, to explain the process of classifying transaction requests in detail, stock trading is used as an example. It is worth noting that this stock trading, its type, and specific quantity are merely illustrative examples and do not limit the application scope of the parallel trading processing method of this invention. Assuming... Figure 2As shown, if 10 stock trading requests ①-⑩ are uploaded sequentially (it's worth noting that the number in this case, such as the 10 trading requests here, and the capacity threshold of the subsequent master node, are only an adaptive example; in reality, the number should be in the tens of thousands), then their characteristics (such as transaction type) can be extracted, and the 10 trading requests can be divided into 4 partitions, specifically including: Partition 1 – 2 buy order requests ①⑦ (buyers broadcast how many shares they want to buy and at what price), Partition 2 – 3 sell order requests ⑤⑥⑩ (sellers broadcast how many shares they want to sell and at what price), Partition 3 – 3 order completion requests ②④⑧ (buyers and sellers reach a transaction and broadcast requests for stock transfer and fund transfer), and Partition 4 – 2 order cancellation requests ③⑨ (buyers or sellers place orders but receive no response and need to cancel the orders and rebroadcast the transaction). It is worth noting that using transaction type as a characteristic of trading requests is only an adaptive example. Those skilled in the art can also choose, but are not limited to, extracting the time node, importance, priority order, client type, etc., of trading requests as characteristics of trading requests, and use this as a standard for classifying trading requests.

[0077] This embodiment provides a specific example of step S2, which involves dividing transaction requests into Y partitions based on their characteristics, such as transaction type, time period, importance, priority, and client type. The subsequent execution can be sorted according to the specific characteristics of each partition. Taking the aforementioned stock trading as an example, order completion and cancellation requests can be processed first, followed by buy and sell orders.

[0078] Preferably, in one embodiment, step S3 may optionally include, but is not limited to:

[0079] S31: Get the number of transaction requests for each partition; specifically, optional but not limited to counting the number of transaction requests for each partition one by one;

[0080] S32: Get the current capacity threshold of each master node; specifically, the current capacity threshold of a master node refers to the current available transaction request processing space of the master node, which is equal to its own capacity threshold (the load of the master node) minus the number of transaction requests currently being processed (the running state of the master node).

[0081] S33: Based on the number of transaction requests for each partition and the current capacity threshold of each master node, select Z master nodes from X master nodes to guide the transaction requests for Y partitions, so that the number of transaction requests guided by each master node does not exceed its current capacity threshold.

[0082] This embodiment provides a specific implementation method for how step S3 selects Z master nodes to guide Y partition transaction requests. Based on the number of transaction requests for a partition, if the number is small (the sum of the transaction requests for several partitions does not exceed the current capacity threshold of a master node), then one master node is selected to guide multiple partitions; if the number is large (the number of transaction requests for a partition is close to the current capacity threshold of a master node), then one master node is selected to guide one partition; if the number is huge (the number of transaction requests for a partition exceeds the current capacity threshold of a master node), then multiple master nodes can be selected to guide one partition, that is, the transaction requests for one partition are distributed to multiple master nodes. The general principle is that the number of transaction requests guided by a master node (whether for one partition or multiple partitions) does not exceed its current capacity threshold. Specifically, as in the example above, 10 transaction requests are divided into 4 partitions: Partition 1 – 2 buy orders ①⑦, Partition 2 – 3 sell orders ⑤⑥⑩, Partition 3 – 3 order completion requests ②④⑧, and Partition 4 – 2 order cancellation requests ③⑨. If the current capacity threshold of the master node is only 2 transaction requests (this capacity threshold example is only for adaptability; in reality, it should be on the order of tens of thousands), then the number of transaction requests allocated to Partition 2 and Partition 3 has exceeded their capacity threshold, and the transaction requests in these partitions need to be further divided.

[0083] Preferably, in one embodiment, step S33 may optionally include, but is not limited to:

[0084] S331: Number the Y partitions as Y i Number the Z master nodes as Z j , 1≤i≤Y, 1≤j≤Z;

[0085] S332: Initialize i = 1, j = 1;

[0086] S333: Determine the number of transaction requests y in the i-th partition. i Does it exceed the current capacity threshold z of the j-th master node? j ;

[0087] S334: If not, then allocate the transaction request of the i-th partition to the j-th master node; let i = i + 1; determine whether i > Y or j > Z is true. If yes, end; otherwise, return to step S333.

[0088] S335: If so, then the first z of the i-th partition... j A transaction request is assigned to the j-th master node, and the number of transaction requests in the i-th partition is y. i =y i -z j Let j = j + 1; return to step S332.

[0089] In this embodiment, a specific example of step S33, which involves selecting Z master nodes to guide the transaction requests of Y partitions, is provided. This is based on the number of transaction requests in each partition and the current capacity threshold of each master node, selecting a reasonable number of master nodes to guide a reasonable number of partitions. For example, if the aforementioned 10 transaction requests are divided into 4 partitions: Partition 1 – 2 buy order requests ①⑦, Partition 2 – 3 sell order requests ⑤⑥⑩, Partition 3 – 3 completed order requests ②④⑧, and Partition 4 – 2 cancelled order requests ③⑨, and the current capacity threshold of the master nodes is only 2 transaction requests, then according to steps S331-S335, 5 master nodes will guide these 4 partitions, respectively: ①⑦, ⑤⑥, ⑩②, ④⑧, and ③⑨. The advantage of this specific embodiment is that it can allocate transaction requests according to the capacity threshold of the master node to avoid congestion, and achieve the most efficient use of resources, thus balancing efficiency and resource utilization. The disadvantage is that it may split transaction requests in the same partition to different master nodes, which may have an adverse effect on subsequent priority ranking.

[0090] Preferably, in another embodiment, step S33 may optionally include, but is not limited to:

[0091] S331': Number the Y partitions as Y i Number the Z master nodes as Z j , 1≤i≤Y, 1≤j≤Z;

[0092] S332': Initialize i = 1, j = 1;

[0093] S333': Determine the number of transaction requests y in the i-th partition. i Does it exceed the current capacity threshold x of the j-th master node? j ;

[0094] S334': If not, then allocate the transaction request of the i-th partition to the j-th master node; let i = i + 1, j = j + 1; determine whether i > Y or j > X is true, if yes, end, otherwise return to step S333';

[0095] S335': If so, then the first z of the i-th partition... j A transaction request is assigned to the j-th master node, and the number of transaction requests in the i-th partition is y. i =y i -z j Let j = j + 1; return to step S332'.

[0096] In this embodiment, another specific implementation of step S3, which involves selecting Z master nodes to guide the transaction requests of Y partitions, is provided. This not only selects a reasonable number of master nodes to guide a reasonable number of partitions based on the number of transaction requests in each partition and the current capacity threshold of each master node, but also, in step S334', after allocating the transaction requests of the i-th partition to the j-th master node, directly sets j = j + 1 to allocate the transaction requests of the new partition to the new master node. This avoids the situation where the number of transaction requests in a partition is small, but it is still fragmented and allocated to different master nodes. For example, for the above 10 transaction requests divided into 4 partitions: partition 1 – 2 buy order requests ①⑦, partition 2 – 3 sell order requests ⑤⑥⑩, partition 3 – 3 completed order requests ②④⑧, and partition 4 – 2 cancelled order requests ③⑨, if the current capacity threshold of the master node is only 2 transaction requests... Following steps S331'-S335', ​​the four partitions are guided by six master nodes, namely: ①⑦, ⑤⑥, ⑩, ②④, ⑧, and ③⑨. The advantage of this specific embodiment is that it can allocate transaction requests based on the capacity threshold of the master nodes, and can select Z master nodes from X master nodes to guide the transaction requests of Y partitions, depending on which master node handles which type of transaction request. This minimizes the possibility of transaction requests for the same partition being assigned to different master nodes (unless the number of transaction requests for the same partition is very large and thus assigned to different master nodes). However, it inevitably requires more master nodes than the embodiment of steps S331-S335 (each partition's transaction request requires at least one master node), resulting in slightly lower resource utilization. The specific choice between the embodiment of steps S331-S335 or the embodiment of steps S331'-S335' can be made freely by those skilled in the art based on the specific number and urgency of the transaction requests.

[0097] Preferably, step S2 may also optionally include, but is not limited to:

[0098] S23: Prioritize the Y partitions based on the characteristics of the transaction requests. Specifically, this can be optional, but not limited to, prioritizing the transaction requests in the Y partitions based on transaction type, time sequence, urgency, etc. For example, in stock trading, the requests could be arranged in the order of order placement, order cancellation, buy order, and sell order to process the transaction requests in each partition in order of priority.

[0099] In this embodiment, the step of sorting Y partition transaction requests by priority is added, which can prioritize the processing of urgent and important transaction requests, and further improve the response speed and efficiency of important transaction requests.

[0100] In another embodiment, step S2 may optionally include, but is not limited to, the following:

[0101] S21': Sort the master nodes by number and extract the current capacity threshold of each master node; S22': Divide the transaction requests into Y partitions according to the current capacity threshold of each master node;

[0102] Step S3, optional but not limited to S31': Distribute the transaction requests from the Y partitions sequentially to the Z master nodes, where Z = Y. Specifically, taking the aforementioned 10 transaction requests as an example, first extract the current capacity threshold of each master node (assuming: the current capacity threshold of the first master node is 2, the current capacity threshold of the second master node is 5, the current capacity threshold of the third master node is 1, and the current capacity threshold of the fourth master node is 4). Then, based on the current capacity threshold of each master node, divide the 10 transaction requests into 2 + 5 + 1 + 2 (e.g., ...). Figure 2 The numbers ①②+③④⑤⑥⑦+⑧+⑨⑩) shown are assigned to the first through fourth master nodes in sequence. The first through third master nodes are full, while the fourth master node has two vacancies.

[0103] In this embodiment, step S2, another specific embodiment of how to divide transaction requests, is given. Here, the division is no longer based on the characteristics of the transaction requests, but directly based on the current capacity threshold of the master node. This can allocate master nodes on demand according to the number of transaction requests. Its advantage is that there will be no situation where the capacity threshold of the master node is exceeded and reallocation is required, which can further improve the response effect of transaction requests. However, it does not divide the partitions according to the characteristics of the transaction requests, and cannot perform subsequent processing according to the characteristics of the transaction requests (type, urgency, etc.). It can only perform subsequent processing according to the time order of the transaction requests uploaded.

[0104] On the other hand, the present invention also provides a blockchain transaction processing system, comprising:

[0105] A node partitioning device is used to divide blockchain nodes into normal nodes and consensus nodes, and select X consensus nodes as master nodes.

[0106] A request partitioning device is used to upload transaction requests and divide the transaction requests into Y partitions;

[0107] A node selection device is used to select Z master nodes from X master nodes to guide transaction requests for Y partitions;

[0108] The sorting consistency determination device is used for:

[0109] Z master nodes sort and identify the transaction requests they initiate, and broadcast them to consensus nodes and normal nodes;

[0110] Sort and number the Z master nodes, and let n = 1;

[0111] Consensus nodes and normal nodes respectively sort the transaction requests initiated by the nth master node;

[0112] Determine whether the sorting results of the consensus node and the normal nodes for the transaction requests initiated by the nth master node are consistent.

[0113] If they are inconsistent, reorder them.

[0114] If they match, the transaction request initiated by the nth master node is successful, until all master nodes have been traversed.

[0115] Where X, Y, and Z are positive integers, and X > 1; Y > 1; 1 < Z ≤ X.

[0116] Furthermore, a parallel transaction processing system is used to execute any of the above-mentioned parallel transaction processing methods.

[0117] It is worth noting that the above-mentioned device is divided only in terms of function, and does not divide its physical concept. As those skilled in the art can understand, multiple devices are combined and packaged to form a combined structure.

[0118] On the other hand, the present invention also provides a computer storage medium storing a computer program; the computer program is used to execute any of the above-described parallel transaction processing methods.

[0119] The above-described parallel transaction processing system is based on the above-described parallel transaction processing method. Its technical functions and beneficial effects will not be elaborated here. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0120] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention patent should be determined by the appended claims.

Claims

1. A method for parallel transaction processing of a blockchain, the method comprising: include: S1: Divide the blockchain nodes into normal nodes and consensus nodes, and select X consensus nodes as master nodes; S2: Upload the transaction request and divide the transaction request into Y partitions; S3: Among the X master nodes, select Z master nodes to guide the transaction requests of Y partitions; S4: Z master nodes, which sort and identify the transaction requests they initiate, and broadcast them to consensus nodes and normal nodes; S5: Sort and number the Z master nodes, and let n = 1; S6: Consensus nodes and normal nodes sort the transaction requests initiated by the nth master node respectively; S7: Determine whether the sorting results of the consensus node and the normal node for the transaction requests guided by the nth master node are consistent; S8: If inconsistent, return to step S6; S9: If they match, the transaction request initiated by the nth master node is successful. Let n = n + 1. S10: Determine whether n > Z is true; S11, if not, return to step S6, if yes, end; Where X, Y, and Z are positive integers, and X > 1; Y > 1; 1 < Z ≤ X.

2. The parallel transaction processing method of claim 1, wherein, Step S2 includes, S21: Extract the characteristics of the transaction request; S22: Divide the transaction request into Y partitions based on the characteristics of the transaction request.

3. The parallel transaction processing method of claim 1, wherein, Step S3 includes: S31: Get the number of transaction requests for each partition; S32: Get the current capacity threshold for each master node; S33: Based on the number of transaction requests for each partition and the current capacity threshold of each master node, select Z master nodes from X master nodes to guide the transaction requests for Y partitions, so that the number of transaction requests guided by each master node does not exceed its current capacity threshold.

4. The parallel transaction processing method of claim 3, wherein, Step S33 includes: S331: number Y partitions as Y i number Z master nodes as Z j 1≤i≤Y, 1≤j≤Z; S332: Initialize i = 1, j = 1; S333: Determine the number y of transaction requests of the i-th partition i whether the current capacity threshold z of the j-th master node is exceeded j ; S334: If not, then allocate the transaction request of the i-th partition to the j-th master node; let i = i + 1; determine whether i > Y or j > Z is true. If yes, end; otherwise, return to step S333. S335: If yes, the first z transaction requests of the i-th partition are allocated to the j-th master node, and the current number of transaction requests y of the i-th partition is set to y = y - z; j is set to j = j + 1; and the step S332 is returned. j i i j ; j is set to j = j + 1; and the step S332 is returned.​​​ 5. The parallel transaction processing method according to claim 3, characterized in that, Step S33 includes: S331’ : Number Y partitions as Y i Number Z master nodes as Z j 1≤i≤Y, 1≤j≤Z; S332': Initialize i = 1, j = 1; S333’ : judging the number y of transaction requests of the i-th partition i whether the current capacity threshold x of the j-th master node is exceeded j ; S334': If not, then allocate the transaction request of the i-th partition to the j-th master node; let i = i + 1, j = j + 1; determine whether i > Y or j > X is true, if yes, end, otherwise return to step S333'; S335': if yes, assign the first z transaction requests of the ith partition to the jth master node, let the current number of transaction requests of the ith partition y j = y i -z i ; let j = j + 1; return to step S332'. j ; let j = j + 1; return to step S332'.

6. The parallel transaction processing method according to claim 2, characterized in that, Step S2 also includes: S23: Prioritize the Y partitions based on the characteristics of the transaction requests.

7. The parallel transaction processing method according to claim 1, characterized in that, Step S2 includes: S21': Sort the master nodes by number and extract the current capacity threshold for each master node; S22': Divide the transaction requests into Y partitions according to the current capacity threshold of each master node; Step S3 includes: S31': Distribute the transaction requests of Y partitions to Z master nodes in sequence, where Z = Y.

8. A parallel transaction processing system for blockchain, characterized in that, include: A node partitioning device is used to divide blockchain nodes into normal nodes and consensus nodes, and select X consensus nodes as master nodes. A request partitioning device is used to upload transaction requests and divide the transaction requests into Y partitions; A node selection device is used to select Z master nodes from X master nodes to guide transaction requests for Y partitions; The sorting consistency determination device is used for: Z master nodes sort and identify the transaction requests they initiate, and broadcast them to consensus nodes and normal nodes; Sort and number the Z master nodes, and let n = 1; Consensus nodes and normal nodes respectively sort the transaction requests initiated by the nth master node; Determine whether the sorting results of the consensus node and the normal nodes for the transaction requests initiated by the nth master node are consistent. If they are inconsistent, reorder them. If they match, the transaction request initiated by the nth master node is successful, until all master nodes have been traversed. Where X, Y, and Z are positive integers, and X > 1; Y > 1; 1 < Z ≤ X.

9. The parallel transaction processing system according to claim 8, characterized in that, Used to perform the parallel transaction processing method according to any one of claims 1-7.

10. A computer storage medium, characterized in that, The computer program is stored thereon; the computer program is used to execute the parallel transaction processing method according to any one of claims 1-7.

Images