Transaction concurrency conflict optimization method based on Fabric alliance chain

Abstract

The invention relates to the technical field of block chain data processing, in particular to a transaction concurrency conflict optimization method based on a Fabric alliance chain, and the method comprises the steps: a client executes a proposal initiation operation, generates a transaction, and sends the transaction to a sorting node; the sorting node receives transactions sent by different clients, and divides all the received transactions into four types of sets according to preprocessing operation; taking each transaction in the reordered transaction set as a node, and constructing a transaction conflict dependency graph through a read-write dependency relationship; reordering all transactions in the reordering transaction set according to the transaction conflict dependency graph; performing grouping modification on all transactions in the to-be-merged transaction set; generating a transaction scheduling sequence according to the read-only transaction set, the reordering result and the grouping modification result, and packaging the transaction scheduling sequence to form a block; according to the method, the data consistency is ensured, the transaction failure rate in the block is reduced through caching, reordering and merging methods, and the overall performance and the resource utilization rate of the system are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain data processing, and in particular to a transaction concurrency conflict optimization method based on Fabric alliance chain. Background Art

[0002] Hyperledger Fabric (hereafter referred to as Fabric) is an enterprise-level open source consortium blockchain platform managed by the Linux Foundation. It provides some modular designs and pluggable components to meet a wide range of industry needs. Unlike other existing consortium blockchains (such as FISCO BCOS), the Fabric consortium blockchain adopts the Execute-Order-Validate transaction processing mode. In the Fabric consortium blockchain, each transaction only needs to be executed on a subset of the endorsement nodes required to meet the transaction endorsement policy. This allows transactions to be executed in parallel to a certain extent, thereby improving the overall performance and scale of the system.

[0003] However, the Fabric consortium blockchain adopts the multi-version concurrency control (MVCC) mechanism. When the consortium blockchain is applied to high-frequency transaction scenarios such as real-time stock trading systems, e-commerce systems, and real-time information publishing systems, multiple users may concurrently submit multiple transaction requests to modify the same data set. These transaction requests are sent to the blockchain network for consensus and then stored in the ledger, resulting in conflicting transactions in a block. Since conflicting transactions will almost go through the entire transaction process and are not marked as invalid until the transaction verification stage, the performance of the consortium blockchain will be degraded and resources will be wasted. At the same time, the more conflicting transactions there are, the more unfavorable it is for parallel verification and writing of transactions. Specifically, transaction processing must go through the simulation stage, sorting node, and verification and submission stage in sequence. The read-write set of the transaction is generated in the simulation stage and verified in the verification and submission stage, with a large time span. This makes it possible for concurrent conflicts to occur when multiple transactions modify the same data concurrently, resulting in a large number of transaction failures. Concurrency conflicts mainly include two situations: the first situation is that before the previous block is submitted, the current transaction endorses and generates a read-write set. Due to the submission of the previous block, the read-write set of the current transaction is outdated when it reaches the verification submission stage, resulting in a conflict between blocks and being marked as invalid; the second situation is that in the same block, the conflicting transactions endorse and generate a read-write set with the same version number in the simulation stage, but because the submission of the first transaction will update the version, the subsequent transaction versions are outdated, resulting in a conflict within the block, and are marked as invalid in the verification submission stage. Invalid transactions occupy the system's computing resources and network resources, while reducing system performance and user experience.

[0004] The existing methods for solving the concurrency conflict problem of Fabric can be divided into two categories. One is to detect conflicts in advance through the cache mechanism in the transaction processing process, and the other is to reduce the number of conflicting transactions by reordering transactions. The method based on the cache mechanism usually stores the key-value pairs in the cache during the execution phase or the sorting phase. Subsequent transactions detect whether there is a potential conflict and terminate in advance by querying and comparing the cached information. However, the method based on the cache mechanism cannot reduce or eliminate conflicting transactions. There is a problem of very large average delay caused by the continuous backlog of conflicting transactions. The method based on the reordering mechanism adjusts the transaction order in the pending block in the sorting phase, so that it can avoid version conflicts in some transactions in the verification phase and increase the number of valid transactions. However, there are still some conflicting transactions that can be converted into legal from a semantic point of view, which are terminated in advance in the reordering mechanism, so that a large number of transactions in the block are still marked as invalid. Summary of the invention

[0005] In order to solve the above problems, reduce the number of invalid Fabric transactions in conflict scenarios, and improve system throughput, the present invention provides a transaction concurrency conflict optimization method based on Fabric alliance chain, comprising the following steps:

[0006] S1. The client executes the proposal initiation operation and generates a transaction and sends it to the sorting node;

[0007] S2. The sorting node receives transactions sent by different clients and divides all received transactions into four sets according to preprocessing operations; the four sets include read-only transaction set, early termination set, pending merge transaction set, and reordered transaction set;

[0008] S3. Treat each transaction in the reordered transaction set as a node and construct a transaction conflict dependency graph through read-write dependency relationships;

[0009] S4. reorder all transactions in the reordered transaction set according to the transaction conflict dependency graph;

[0010] S5. Group and modify all transactions in the transaction set to be merged;

[0011] S6. Generate a transaction scheduling sequence based on the read-only transaction set, reordering results, and group modification results, and package the transaction scheduling sequence into a block.

[0012] Beneficial effects of the present invention:

[0013] The present invention combines the characteristics of the transaction processing architecture of execution-order-verification (EOV) adopted by Fabric, and proposes an optimization method for the problem of transaction concurrency conflict. The present invention analyzes the causes of the conflict and classifies and processes the conflicting transactions according to the conflict type. By caching the read-write set key-value pairs and versions, filtering old transactions, and resolving conflicts between different transactions between blocks. Then, for transactions with read-write dependencies, a reordering strategy is adopted to regenerate a serializable scheduling sequence to reduce the number of conflicting transactions. Finally, based on the reordering results, the self-increment and self-decrement transactions that only read and write a single key value are further merged to maximize the number of valid transactions. In the sorting stage, for transactions that cannot avoid conflicts, they are terminated in advance and the client is notified to reduce the consumption of network resources and computing resources by invalid transactions. On the basis of ensuring data consistency, the present invention reduces the transaction failure rate within the block and improves the overall system performance and resource utilization by caching, reordering, and merging methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 This is a schematic diagram of the transaction concurrency conflict optimization process based on the Fabric alliance chain of the present invention;

[0015] Figure 2 A transaction conflict dependency graph constructed according to an example of the present invention;

[0016] Figure 3 A directed acyclic graph generated based on a transaction conflict dependency graph according to an example of the present invention;

[0017] Figure 4 This is a schematic diagram of the transaction set processing flow and structure of the sorting node of the present invention. DETAILED DESCRIPTION

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

[0019] The present invention provides a transaction concurrency conflict optimization method based on Fabric alliance chain, such as Figure 1 , Figure 4 As shown, the following steps are included:

[0020] S1. The client executes the proposal initiation operation and generates a transaction to be sent to the sorting node.

[0021] Specifically, in step S1, the client performs a proposal initiation operation and generates a transaction including:

[0022] S11. The client initiates a transaction proposal based on business needs. The transaction proposal is sent to endorsement nodes of multiple different organizations according to the predetermined endorsement policy.

[0023] S12. Each endorsement node receives the transaction proposal and simulates the execution of the transaction proposal to generate a transaction endorsement result, and feeds the transaction endorsement result back to the client; the transaction endorsement result includes a read-write set and a signature;

[0024] S13. The client receives the transaction endorsement result. If all transaction endorsement results are consistent and meet the endorsement policy requirements, a transaction is generated based on the transaction proposal and the transaction endorsement result, and the transaction is sent to the sorting node.

[0025] Specifically, within the same time period, that is, within the life cycle of a block generation, one or more clients may concurrently initiate transaction proposals.

[0026] Specifically, the client will set an event listener to continuously monitor the processing status of the transaction; when the sorting node sorts and packages all the transactions it receives into blocks, the event listener will monitor whether the transaction issued by the client is terminated prematurely due to conflicts; when the block arrives at the Peer node, the event listener will listen to the verification submission result and obtain the submission success message or failure reason.

[0027] S2. The sorting node receives transactions sent by different clients and divides all received transactions into four sets according to preprocessing operations; the four sets include read-only transaction set, early termination set, transaction set to be merged, and reordered transaction set.

[0028] Specifically, in step S2, the sorting node parses the read-write set of each transaction in the order in which the transactions are received; for each transaction, a preprocessing operation is performed based on its read-write set, including:

[0029] S21. Determine whether the transaction contains only a read set. If so, add the transaction to the read-only transaction set; if not, execute step S22;

[0030] Transactions that only contain read sets do not modify the final blockchain ledger and state database, so they can be moved to the front of the final block transaction sequence (i.e., the last generated transaction scheduling sequence) to prevent them from being marked as read-write conflicts in the subsequent verification phase and becoming invalid transactions.

[0031] S22. Determine whether the read set version number of the transaction is outdated. If so, add the transaction to the early termination set; if not, execute step S23;

[0032] The specific operation to determine whether the read set version number of a transaction is outdated is:

[0033] S221. The sorting node maintains a cache that stores the key, the highest read set version number corresponding to the key, and the transaction corresponding to the key;

[0034] S222. When parsing the read set of transaction i that is not a read-only transaction, extract the key key i and read set version number V i , execute step S223;

[0035] S223. Determine the key stored in the cache i Whether the corresponding highest read set version number is greater than the read set version number V i If so, the read set version number of transaction i is outdated, which means that the read-write set of transaction i is generated based on outdated old data and cannot pass transaction verification. Transaction i is added to the early termination set.

[0036] Specifically, the sorting node maintains a cache that stores the highest read set version number and transaction corresponding to each key. The stored content is updated based on the submission of the previous block, and then the key and read set version number in the database are modified.

[0037] S23. Determine whether the key read by the transaction (the key in the read set) is the same as the key written by the transaction (the key in the write set). If so, add the transaction to the set of transactions to be merged; otherwise, add the transaction to the set of reordered transactions.

[0038] In one embodiment, different clients concurrently initiate 12 transaction proposals in the same time period. After each transaction proposal is simulated and executed by the corresponding endorsement node, a transaction result is generated and returned to the client. The client generates a transaction based on the transaction result and sends it to the sorting node for processing. In this embodiment, the sorting node receives 12 transactions from different clients, and all transactions are arranged in the order of receipt to obtain a sequence of T0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19, T20, T21, T22, T23, T24, T25, T26, T27, T28, T29, T30, T31, T32, T33, T34, T35, T36, T37, T38, T39, T40, T41, T42, T43, T44, T45, T46, T47, T48, T49, T50, T51, T52, T5 10 , T 11 The read set corresponding to each transaction is Table 1, the write set is Table 2, and the corresponding value of the state database primary key is shown in Table 3. These 12 transactions will be packaged into a block.

[0039] Table 1

[0040]

[0041] Table 2

[0042]

[0043] Table 3

[0044] Writing Collection <![CDATA[Key0]]> <![CDATA[Key1]]> <![CDATA[Key2]]> <![CDATA[Key3]]> <![CDATA[Key4]]> <![CDATA[Key5]]> <![CDATA[Key6]]> <![CDATA[Key7]]> <![CDATA[Key8]]> <![CDATA[Key9]]> InitVal 3 12 6 4 5 9 2 4 8 7

[0045] After the above preprocessing operations, the read and write sets of all transactions are parsed and extracted and stored in memory. Among them, transaction T8 only contains read sets, so it is added to the read-only transaction set; transactions T9 and T 10 , T 11 Only read, write and modify data items with key key6, and add these three transactions to the set of transactions to be merged; transactions T0, T1, T2, T3, T4, T5, T6 and T7 read and modify different keys, so they are added to the reordering transaction set.

[0046] S3. Treat each transaction in the reordered transaction set as a node and construct a transaction conflict dependency graph through read-write dependency relationships.

[0047] Taking the above embodiment as an example, the sorting node defaults to sorting in the order of the timestamps of the received transactions. For transactions T6 and T7, T6 reads key7 and writes key6, and T7 reads key6 and writes key8. In the verification phase, since T6 updates the value of key6 first, the read set version of T7 is outdated and marked as an MVCC conflict, and transaction T7 is invalid. According to the transaction serializability theory, if the order of transactions T6 and T7 is swapped, T7 reads key6 and T6 writes key6 again, there will be no version conflict and both transactions are valid. Therefore, in order to reduce the probability of conflict between legal transactions, the transactions in the block need to be reordered. By identifying the conflicts between transactions in the same block and using graph theory knowledge, the transactions are converted into nodes of a directed graph, and directed edges are established based on the read-write dependency of the transactions to obtain a directed graph. According to the directed graph, a serializable transaction execution sequence is obtained by terminating some transactions to maximize the number of transactions.

[0048] Specifically, step S3 constructing a transaction conflict dependency graph includes:

[0049] S31. Determine the conflict dependency between nodes:

[0050] For any two different transactions in the reordered transaction set, if there is a conflict between the two, it means that the condition is met:

[0051] and i≠j,

[0052] Among them, i and j represent the order coordinates of the transaction, T i , T j represents the i-th transaction and the j-th transaction,

[0053] T i .ReadSets represents the read set of the i-th transaction, T i .WriteSets represents the write set of the i-th transaction,

[0054] T j. ReadSets represents the read set of the j-th transaction, T j . WriteSets represents the write set of the j-th transaction;

[0055] According to the order of read and write key values, conflicting transactions have read-write dependency relationships and write-read dependency relationships. When two transactions conflict, further determine the dependency relationship between the two transactions:

[0056] If and i < j, then T j reads and writes depending on T i ;

[0057] If and i < j, then T j writes and reads depending on T i ;

[0058] S32. Construct edges according to the conflict dependency relationship:

[0059] If the i-th transaction reads and writes depending on the j-th transaction, add a directed edge from node i to node j. If the i-th transaction writes and reads depending on the j-th transaction, add a directed edge from node j to node i.

[0060] Continuing the processing results of the previous embodiment, after conflict identification and dependency relationship construction for the transactions T0, T1, T2, T3, T4, T5, T6, T7 in the re-ordered transaction set, a transaction conflict dependency graph as shown in Figure 2 can be generated. This graph is a directed graph.

[0061] S4. Re-order all transactions in the re-ordered transaction set according to the transaction conflict dependency graph.

[0062] Specifically, step S4 re-orders all transactions in the re-ordered transaction set according to the transaction conflict dependency graph, including:

[0063] S41. Traverse all nodes of the transaction conflict dependency graph, record the out-degree and in-degree of each node, and use the sum of the out-degree and in-degree as the array weight of the node;

[0064]

[0065] trade Weight value <![CDATA[T0]]> 3 <![CDATA[T1]]> 2 <![CDATA[T2]]> 4 <![CDATA[T3]]> 2 <![CDATA[T4]]> 3 <![CDATA[T5]]> 3 <![CDATA[T6]]> 2 <![CDATA[T7]]> 1

[0066] Figure 2There are two cyclic subgraphs in the directed graph shown, namely T0->T1->T0 and T2->T4->T3->T2. In the cyclic subgraph T0->T1->T0, the array weight value of node T0 is greater than the array weight value of T1, so T0 is deleted first; in the cyclic subgraph T2->T4->T3->T2, the array weight value of node T2 is the largest, so T2 is deleted first. Finally, transactions T0 and T2 are deleted, and the remaining transactions T1, T3, T4, T5, T6, and T7 form the final directed acyclic graph, as shown in Figure 3 shown.

[0067] according to Figure 3 Reorder the directed acyclic graph. For two nodes connected by a directed edge, the starting node must be placed before the ending node. For example, transactions T5 and T7 must be placed before T6, and transaction T5 must be placed before T4.

[0068] Starting from the node with in-degree 0, a serializable transaction scheduling sequence is obtained along the directed edges as the reordering result. After topological sorting of the directed acyclic graph, one of the generated sequence results is T1->T5->T7->T6->T4->T3.

[0069] S5. Group and modify all transactions in the transaction set to be merged.

[0070] Specifically, step S5 groups and modifies all transactions in the transaction set to be merged, including:

[0071] S51. Group all transactions in the transaction set to be merged according to the key, that is, group the transactions with the same key into one group;

[0072] S52. For each group, obtain the initial value initValue of the target key corresponding to the group, and calculate the updated value of the target key according to the reordering result;

[0073] S53. Calculate the transaction increment deltaValue according to the transactions in the group, that is, add the key values ​​to be written by all transactions in the group to obtain the transaction increment deltaValue;

[0074] S54. Add the update value to the transaction increment value. If the added result is less than 0, discard the transaction with the smallest key value to be written in the group, and then return to step S53; if the added result is not less than 0, execute step S55;

[0075] S55. If the number of transactions in the current group is 1, retain the transaction and mark it for identification in the verification phase; if the number of transactions in the current group is greater than 1, create a new merge transaction; let the sum of the update value and the transaction increment value be the new key value to be written, generate a new write set based on the target key and the new key value to be written; add the new write set to the new merge transaction;

[0076] S56. Create a new transaction T m , add the processing results of all groups to the new transaction T m In the new transaction T m In the case that there are only one transaction left in multiple groups, the remaining transactions are sorted according to the order in which they were received by the original sorting nodes, and all the created merged transactions are placed after all the remaining transactions. m The write set updates the database.

[0077] In this embodiment, T9, T 10 , T 11 When reading and writing the same key at the same time, all transactions except T9 will be marked as invalid transactions due to version conflicts during the verification phase, and the number of invalid transactions cannot be reduced by reordering. From a semantic perspective, such transactions can be merged to reduce conflicts while making the modification results of the state database and the ledger consistent. Using the above method, for the primary key Key6, the initial value initValue is 2, and the updated value key-value should be 6 after reordering. If transactions T9 and T 10 , T 11 , then the transaction deltaValue is -7, and the final addition result is -1 (less than 0). At this point, it is necessary to further discard the transaction T 10 , the sum is 9 (greater than 0). Then, a new merge transaction T is created. m , and generate a write set WriteSet1 =<Key6,9> , add write set WriteSet1 to T m Therefore, transactions T9, T 11 After the merger, the final valid result is obtained, turning it from a conflicting transaction into a valid transaction.

[0078] S6. Generate a transaction scheduling sequence based on the read-only transaction set, reordering results, and group modification results, and package the transaction scheduling sequence into a block.

[0079] Specifically, step S6 generates a transaction scheduling sequence according to the read-only transaction set, the reordering result and the group modification result, including:

[0080] Arrange all transactions in the read-only transaction set in the order in which they are received by the sorting node to form the first sequence;

[0081] The reordered result is placed after the first sequence to obtain a second sequence;

[0082] The group modification result is placed after the second sequence to obtain the transaction scheduling sequence.

[0083] In this example, the batch of transactions T0~T 11 After preprocessing, reordering and merging by the sorting node, the final transaction sequence is: T8->T1->T5->T7->T6->T4->T3->T9->T 11 ->T m .

[0084] In the present invention, unless otherwise clearly stipulated and limited, the terms such as "installation", "setting", "connection", "fixation" and "rotation" should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral one; it can be a mechanical connection or an electrical connection; it can be directly connected or indirectly connected through an intermediate medium; it can be the internal connection of two elements or the interaction relationship between two elements. Unless otherwise clearly defined, ordinary technicians in this field can understand the specific meanings of the above terms in the present invention according to the specific circumstances.

[0085] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A transaction concurrency conflict optimization method based on Fabric alliance chain, characterized in that: The following steps are involved: S1. The client executes the proposal initiation operation and generates a transaction and sends it to the sorting node; S2. The sorting node receives transactions sent by different clients and divides all received transactions into four sets according to preprocessing operations; the four sets include read-only transaction set, early termination set, pending merge transaction set, and reordered transaction set; S3. Treat each transaction in the reordered transaction set as a node and construct a transaction conflict dependency graph through read-write dependency relationships; S4. reorder all transactions in the reordered transaction set according to the transaction conflict dependency graph; S5. Group and modify all transactions in the transaction set to be merged; S6. Generate a transaction scheduling sequence based on the read-only transaction set, reordering results, and group modification results, and package the transaction scheduling sequence into a block.

2. According to a method for optimizing transaction concurrency conflicts based on Fabric alliance chain according to claim 1, it is characterized in that: In step S1, the client performs a proposal initiation operation and generates a transaction including: S11. The client initiates a transaction proposal based on business needs, and the transaction proposal is sent to multiple endorsement nodes according to the endorsement strategy; S12. Each endorsement node receives the transaction proposal and simulates the execution of the transaction proposal to generate a transaction endorsement result, and feeds the transaction endorsement result back to the client; the transaction endorsement result includes a read-write set; S13. The client receives the transaction endorsement result. If all transaction endorsement results are consistent and meet the endorsement policy requirements, a transaction is generated based on the transaction proposal and the transaction endorsement result, and the transaction is sent to the sorting node.

3. According to a method for optimizing transaction concurrency conflicts based on Fabric alliance chain according to claim 1, it is characterized in that: In step S2, the sorting node parses the read-write set of each transaction in the order in which the transactions are received. For each transaction, a preprocessing operation is performed based on its read-write set, including: S21. Determine whether the transaction contains only a read set. If so, add the transaction to the read-only transaction set; if not, execute step S22; S22. Determine whether the read set version number of the transaction is outdated. If so, add the transaction to the early termination set; if not, execute step S23; S23. Determine whether the key in the transaction read set is the same as the key in the write set. If so, add the transaction to the transaction set to be merged; otherwise, add the transaction to the reordered transaction set.

4. According to a method for optimizing transaction concurrency conflicts based on Fabric alliance chain according to claim 3, it is characterized in that: The specific operations to determine whether the read set version number of a transaction is outdated are: S221. The sorting node maintains a cache that stores the key, the highest read set version number corresponding to the key, and the transaction corresponding to the key; S222. When parsing the read set of transaction i that is not a read-only transaction, extract the key key i and read set version number V i , execute step S223; S223. Determine the key stored in the cache i Whether the corresponding highest read set version number is greater than the read set version number V i , if so, the read set version number of transaction i is outdated, and transaction i is added to the early termination set.

5. According to a method for optimizing transaction concurrency conflicts based on Fabric alliance chain according to claim 1, it is characterized in that: Step S3 constructs a transaction conflict dependency graph including: S31. Determine the conflict dependency between nodes: For any two different transactions in the reordered transaction set, if there is a conflict between the two, it means that the condition is met: and i≠j, Among them, i and j represent the order coordinates of the transaction, T i , T j represents the i-th transaction and the j-th transaction, T i .ReadSets represents the read set of the i-th transaction, T i .WriteSets represents the write set of the i-th transaction, T j .ReadSets represents the read set of the jth transaction, T j .WriteSets represents the write set of the jth transaction; When there is a conflict between two transactions, further determine the dependency between the two transactions: If and i < j, then T j read / write depends on T i ; If and i < j, then T j write-read depends on T i ; S32. Build edges based on conflicting dependencies: If the read and write of the i-th transaction depends on the j-th transaction, add a directed edge from node i to node j. If the read and write of the i-th transaction depends on the j-th transaction, add a directed edge from node j to node i.

6. According to a method for optimizing transaction concurrency conflicts based on Fabric alliance chain according to claim 1, it is characterized in that: Step S4 reorders all transactions in the reordered transaction set according to the transaction conflict dependency graph, including: S41. traverse all nodes of the transaction conflict dependency graph, record the out-degree and in-degree of each node, and use the sum of the out-degree and in-degree as the array weight of the node; S42. Determine whether there is a cyclic subgraph in the traversed transaction conflict dependency graph. If yes, execute step S43; if no, execute step S44; S43. For each cyclic subgraph, delete the node with the largest array weight, update the transaction conflict dependency graph, and then return to step S41; S44. Perform topological sorting according to the reordering rules, where the reordering rules include: S441. Count the in-degree values ​​of all nodes in the transaction conflict dependency graph and initialize the reordering queue; S442. Add the node with in-degree value 0 to the reordering queue; S442. Delete the nodes with in-degree value 0, and determine whether there are any unvisited nodes. If so, update the in-degree values ​​of the unvisited nodes and return to step S442. Otherwise, the sorting is completed.

7. According to a method for optimizing transaction concurrency conflicts based on Fabric alliance chain according to claim 1, it is characterized in that: Step S5 groups and modifies all transactions in the transaction set to be merged, including: S51. Group all transactions in the transaction set to be merged according to the key, that is, group the transactions with the same key into one group; S52. For each group, obtain the initial value initValue of the target key corresponding to the group, and calculate the updated value of the target key according to the reordering result; S53. Calculate the transaction increment deltaValue according to the transactions in the group, that is, add the key values ​​to be written by all transactions in the group to obtain the transaction increment deltaValue; S54. Add the update value to the transaction increment value. If the added result is less than 0, discard the transaction with the smallest key value to be written in the group, and then return to step S53; if the added result is not less than 0, execute step S55; S55. If the number of transactions in the current group is 1, keep the transaction; if the number of transactions in the current group is greater than 1, create a new merge transaction; let the sum of the update value and the transaction increment value be the new key value to be written, generate a new write set according to the target key and the new key value to be written; add the new write set to the new merge transaction; S56. Create a new transaction T m , add the processing results of all groups to the new transaction T m middle.

8. According to a method for optimizing transaction concurrency conflicts based on Fabric alliance chain according to claim 1, it is characterized in that: Step S6 generates a transaction scheduling sequence according to the read-only transaction set, the reordering result and the group modification result, including: Arrange all transactions in the read-only transaction set in the order in which they are received by the sorting node to form the first sequence; The reordered result is placed after the first sequence to obtain a second sequence; The group modification result is placed after the second sequence to obtain the transaction scheduling sequence.

Images