A transaction concurrent conflict optimization method based on a fabric consortium chain

Abstract

The present application relates to the technical field of blockchain data processing, and more particularly to a transaction concurrent conflict optimization method based on a Fabric consortium chain, which comprises the following steps: a client performs a proposal initiation operation and generates a transaction and sends it to a sorting node; the sorting node receives transactions sent by different clients, divides all received transactions into four sets according to a preprocessing operation; each transaction in the reordering transaction set is taken as a node, and a transaction conflict dependency graph is constructed through read-write dependency relationship; all transactions in the reordering transaction set are reordered according to the transaction conflict dependency graph; all transactions in the to-be-merged transaction set are grouped and modified; a transaction scheduling sequence is generated according to the read-only transaction set, the reordering result and the grouping modification result, and the transaction scheduling sequence is packed to form a block; the present application guarantees data consistency, reduces the transaction failure rate in the block through the methods of caching, reordering and merging, and improves the overall performance and resource utilization of the system.

Description

Technical Field

[0001] This invention relates to the field of blockchain data processing technology, and in particular to a method for optimizing transaction concurrency conflicts based on Fabric consortium blockchain. Background Technology

[0002] Hyperledger Fabric (hereinafter referred to as Fabric) is an enterprise-grade open-source consortium blockchain platform managed by the Linux Foundation. It offers a modular design 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 an Execute-Order-Validate transaction processing model. In Fabric, each transaction only needs to be executed on a subset of the endorsing nodes required to satisfy the transaction endorsement policy. This allows for a degree of parallel execution of transactions, thereby improving the overall performance and scalability of the system.

[0003] However, the Fabric consortium blockchain employs a Multi-Version Concurrency Control (MVCC) mechanism. When applied to high-frequency trading 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 modifying the same dataset. These transaction requests are sent to the blockchain network for consensus and then stored in the ledger, resulting in conflicting transactions within a single block. Since conflicting transactions often complete almost the entire transaction process, only being marked as invalid during the transaction verification phase, this leads to performance degradation and resource waste in the consortium blockchain. Furthermore, the more conflicting transactions there are, the less conducive it is to parallel verification and writing of transactions. Specifically, transaction processing involves a simulation phase, sorting nodes, and a verification and submission phase. The transaction read / write set is generated in the simulation phase and verified in the verification and submission phase, a significant time span. This makes it possible for multiple transactions to concurrently modify the same data, potentially leading to concurrency conflicts and a large number of transaction failures. Concurrency conflicts mainly fall into two categories: First, before the previous block is committed, the current transaction endorses and generates a read-write set. Due to the previous block's commit, the read-write set becomes outdated by the time the current transaction reaches the verification and commit phase, resulting in an inter-block conflict and being marked as invalid. Second, within the same block, conflicting transactions endorse and generate read-write sets with the same version number during the simulation phase. However, because the first transaction's commit updates the version, subsequent transactions' versions become outdated, causing an intra-block conflict, and the transaction is marked as invalid during the verification and commit phase. Invalid transactions consume system computing and network resources, simultaneously reducing system performance and user experience.

[0004] Existing methods for resolving Fabric concurrency conflicts mainly fall into two categories: one is to detect conflicts in advance through caching mechanisms during the transaction processing flow, and the other is to reduce the number of conflicting transactions by reordering transactions. Caching-based methods typically store key-value pairs in a cache during the execution or sorting phase. Subsequent transactions check the cached information to detect potential conflicts and abort them early. However, caching-based methods cannot reduce or eliminate conflicting transactions, resulting in a very high average latency due to the continuous backlog of conflicting transactions. Reordering-based methods adjust the order of transactions in the block to be processed during the sorting phase, preventing version conflicts in some transactions during the verification phase and increasing the number of valid transactions. However, some conflicting transactions that can be semantically transformed into valid transactions are still aborted early by the reordering mechanism, leaving a large number of transactions marked as invalid in the block. Summary of the Invention

[0005] To address the aforementioned issues, reduce the number of invalid Fabric transactions in conflict scenarios, and improve system throughput, this invention provides a transaction concurrency conflict optimization method based on a Fabric consortium blockchain, comprising the following steps:

[0006] S1. The client executes the proposal initiation operation and generates a transaction, which is then sent 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 the preprocessing operation; the four sets include read-only transaction set, early termination set, transaction set to be merged 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 dependencies;

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

[0010] S5. Modify the groups of 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 grouping modification results, and package the transaction scheduling sequence into a block.

[0012] The beneficial effects of this invention are:

[0013] This invention, combining the features of Fabric's Execution-Ordering-Verification (EOV) transaction processing architecture, proposes an optimization method to address transaction concurrency conflicts. This invention analyzes the causes of conflicts and categorizes conflicting transactions according to their conflict type. By caching read / write key-value pairs and versions, older transactions are filtered out to resolve conflicts arising from different transactions between blocks. Then, for transactions with read / write dependencies, a reordering strategy is used to regenerate a serializable scheduling sequence to reduce the number of conflicting transactions. Finally, based on the reordering results, auto-incrementing and auto-decrementing transactions that only read / write single keys are merged to maximize the number of effective transactions. During the sorting phase, transactions that cannot avoid conflicts are prematurely aborted and the client is notified, reducing the consumption of network and computing resources by invalid transactions. This invention, while ensuring data consistency, reduces the transaction failure rate within blocks and improves overall system performance and resource utilization through caching, reordering, and merging methods. Attached Figure Description

[0014] Figure 1 This is a schematic diagram of the transaction concurrency conflict optimization process based on the Fabric consortium blockchain of this invention;

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

[0016] Figure 3 This invention provides an example of a directed acyclic graph generated based on a transaction conflict dependency graph.

[0017] Figure 4 This is a schematic diagram of the transaction set processing flow and structure of the sorting node in this invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] This invention provides a method for optimizing transaction concurrency conflicts based on Fabric consortium blockchains, such as... Figure 1 , Figure 4 As shown, it includes the following steps:

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

[0021] Specifically, in step S1, the client's execution of the proposal initiation operation and generation of the transaction includes:

[0022] S11. The client initiates a transaction proposal according to business needs, and the transaction proposal is sent to endorsement nodes of multiple different organizations according to the predetermined endorsement strategy;

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

[0024] S13. The client receives the transaction endorsement results. 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 results, and the transaction is sent to the sorting node.

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

[0026] Specifically, the client sets up an event listener to continuously monitor the processing status of transactions; when the sorting node sorts and packages all the transactions it has received into a block, the event listener will listen to whether the transaction sent by the client is terminated early due to a conflict; when the block reaches the peer node, the event listener will listen to verify the commit result and obtain the commit success message or the reason for failure.

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

[0028] Specifically, in step S2, the sorting node parses the read / write set of each transaction sequentially according to the transaction reception order; for each transaction, preprocessing operations are performed based on its read / write set, including:

[0029] S21. Determine if a transaction contains only a read set. If yes, add the transaction to the read-only transaction set; otherwise, proceed to step S22.

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

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

[0032] The specific steps for determining whether the read set version number of a transaction is outdated are as follows:

[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 does not belong to read-only transactions, extract the key. i Reading set version number V i Execute step S223;

[0035] S223. Determine the key stored in the cache. i Is the corresponding highest read set version number greater than the read set version number V? i If so, then the version number of the read set of transaction i is outdated, which means that the read set of transaction i is generated based on outdated old data and cannot pass transaction verification. Transaction i will then be 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 commit of the previous block, which modifies the key and read set version number in the database.

[0037] S23. Determine whether the key read by the transaction (the key in the read set) is the same as the key written (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 transactions to be reordered.

[0038] In one embodiment, different clients concurrently initiate 12 transaction proposals within the same time period. Each proposal is simulated and executed by its corresponding endorsing node, generating a transaction result which is returned to the client. The client then generates a transaction based on the result and sends it to the sorting node for processing. In this embodiment, the sorting node receives the 12 transactions from different clients, and all transactions are arranged in the order of receipt to form the sequence T0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T... 10 T 11 The read set for each transaction is Table 1, the write set is Table 2, and the primary key value of the state database 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] Collection of Writings <![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 / write sets of all transactions are parsed and extracted, and stored in memory. Transaction T8 contains only a read set, so it is added to the read-only transaction set; transactions T9 and T... 10 T 11 The data items that are read-only and modified with the key 'key6' will be added to the transaction set to be merged. Transactions T0, T1, T2, T3, T4, T5, T6, and T7 read and modify different keys, so they will be added to the reordered 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 dependencies.

[0047] In the above embodiment, the sorting nodes are sorted by default according to the timestamps of the received transactions. For transactions T6 and T7, T6 reads key7 and writes key6, while T7 reads key6 and writes key8. During the verification phase, because T6 updates the value of key6 first, the read set version of T7 becomes outdated and is marked as an MVCC conflict, rendering transaction T7 invalid. According to the transaction serializability theory, if the order of transactions T6 and T7 is reversed, T7 reads key6 and then T6 writes key6, thus avoiding a version conflict, and both transactions become valid. Therefore, to reduce the probability of conflicts among legitimate transactions, the transactions in the block need to be reordered. By identifying conflicts between transactions within the same block and using graph theory, transactions are converted into nodes in a directed graph, and directed edges are established based on the read-write dependencies of the transactions, resulting in a directed graph. Based on the directed graph, a serializable transaction execution sequence is obtained by maximizing the number of transactions by suspending some transactions.

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

[0049] S31. Determine conflict dependencies between nodes:

[0050] For any two distinct transactions in the reordered transaction set, if they conflict, then the condition is satisfied:

[0051] And i≠j,

[0052] Where i and j represent the sequence coordinates of the transactions, and T i T j This represents the i-th transaction and the j-th transaction.

[0053] T i .ReadSets represents the read set for 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 reading and writing 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 result of the previous embodiment, after reordering the transactions T0, T1, T2, T3, T4, T5, T6, T7 in the transaction set through conflict recognition and dependency relationship construction, a transaction conflict dependency graph as shown in Figure 2 can be generated. This graph is a directed graph.

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

[0062] Specifically, step S4 reorders 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 2The directed graph shown contains two cyclic subgraphs: T0->T1->T0 and T2->T4->T3->T2. In the cyclic subgraph T0->T1->T0, the array weight of node T0 is greater than that of T1, so T0 is deleted first. In the cyclic subgraph T2->T4->T3->T2, the array weight 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 below. Figure 3 As shown.

[0067] according to Figure 3 This involves reordering a directed acyclic graph. For any two nodes connected by a directed edge, the starting node must precede the ending node. For example, transactions T5 and T7 must precede T6, and transaction T5 must precede T4.

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

[0069] S5. Modify the groups of all transactions in the transaction set to be merged.

[0070] Specifically, step S5 involves grouping and modifying all transactions in the transaction set to be merged, including:

[0071] S51. Group all transactions in the transaction set to be merged according to their keys, that is, group transactions with the same read 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 based on the reordering result;

[0073] S53. Calculate the transaction increment value deltaValue based on the transactions within the group, that is, add up the key values ​​to be written by all transactions within the group to obtain the transaction increment value deltaValue;

[0074] S54. Add the update value to the transaction increment value. If the sum 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 sum is not less than 0, proceed to step S55.

[0075] S55. If the number of transactions in the current group is 1, retain the transaction and mark it for verification phase identification; if the number of transactions in the current group is greater than 1, create a new merge transaction; let the sum of the updated value and the transaction increment value be used as 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 a block commit, if multiple blocks each have only one transaction remaining, these remaining transactions are sorted according to the original order in which they were received by the sorting nodes. All newly created merged transactions are then placed after these remaining transactions. During block commit, this is done by pressing T. m The write set updates the database.

[0077] In this embodiment, T9, T 10 T 11 Simultaneous reading and writing of the same key will cause version conflicts during the verification phase, resulting in all transactions except T9 being marked as invalid. Furthermore, reordering cannot reduce the number of invalid transactions. From a semantic perspective, such transactions can be merged to reduce conflicts and ensure consistency between the state database and the ledger. Using this method, for primary key Key6, the initial value initValue is 2. After reordering, the updated key-value pair should be 6. If transactions T9 and T... are merged simultaneously... 10 T 11 If the transaction increment value deltaValue is -7, the final sum is -1 (less than 0). At this point, it is necessary to further discard 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 WriteSet1 to T m Therefore, trading T9 and T... 11 The merger yields a final, valid result, transforming it from a conflicting transaction into a valid one.

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

[0079] Specifically, step S6 generates a transaction scheduling sequence based on the read-only transaction set, the reordering result, and the grouping modification result, including:

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

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

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

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

[0084] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "setting," "connection," "fixing," "rotation," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal connection of two components or the interaction between two components. Unless otherwise explicitly limited, those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

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

Claims

1. A method for optimizing transaction concurrency conflicts based on Fabric consortium blockchain, characterized in that, Includes the following steps: S1. The client executes the proposal initiation operation and generates a transaction, which is then sent to the sorting node; S2. The sorting node receives transactions sent by different clients and divides all received transactions into four sets according to the preprocessing operation; the four sets include read-only transaction set, early termination set, transaction set to be merged 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 dependencies; 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, including: S51. Group all transactions in the transaction set to be merged according to their keys, that is, group transactions with the same read 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 based on the reordering result; S53. Calculate the transaction increment value deltaValue based on the transactions within the group, that is, add up the key values ​​to be written by all transactions within the group to obtain the transaction increment value deltaValue; S54. Add the update value to the transaction increment value. If the sum 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 sum is not less than 0, proceed to step S55. S55. If the number of transactions in the current group is 1, then retain the transaction; if the number of transactions in the current group is greater than 1, then create a new merge transaction; let the sum of the updated value and the transaction increment value be used as 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; S56. Create a new transaction T m Add the processing results of all groups to the new transaction T m middle; S6. Generate a transaction scheduling sequence based on the read-only transaction set, reordering results, and grouping modification results, and package the transaction scheduling sequence into a block.

2. The method for optimizing transaction concurrency conflicts based on Fabric consortium blockchain according to claim 1, characterized in that, Step S1, in which the client performs the proposal initiation operation and generates a transaction, includes: S11. The client initiates a transaction proposal according to business needs, and the transaction proposal is sent to multiple endorsement nodes according to the endorsement policy; S12. Each endorsing node receives a transaction proposal and simulates the execution of the transaction proposal to generate a transaction endorsement result, and feeds back the transaction endorsement result to the client; the transaction endorsement result includes a read-write set; S13. The client receives the transaction endorsement results. 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 results, and the transaction is sent to the sorting node.

3. The transaction concurrency conflict optimization method based on Fabric consortium blockchain according to claim 1, characterized in that, In step S2, the sorting node parses the read / write set of each transaction sequentially according to the transaction reception order; for each transaction, preprocessing operations are performed based on its read / write set, including: S21. Determine if a transaction contains only a read set. If yes, add the transaction to the read-only transaction set; otherwise, proceed to step S22. S22. Determine if the read set version number of the transaction is outdated. If so, add the transaction to the early termination set; otherwise, proceed to step S23. S23. Determine whether the keys in the transaction read set are the same as the keys in the write set. If they are the same, add the transaction to the transaction set to be merged; otherwise, add the transaction to the transaction set to be reordered.

4. The transaction concurrency conflict optimization method based on Fabric consortium blockchain according to claim 3, characterized in that, The specific steps to determine whether the read set version number of a transaction is outdated are as follows: 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 does not belong to read-only transactions, extract the key. i Reading set version number V i Execute step S223; S223. Determine the key stored in the cache. i Is the corresponding highest read set version number greater than the read set version number V? i If so, the version number of the read set for transaction i is outdated, and transaction i is added to the early termination set.

5. The method for optimizing transaction concurrency conflicts based on Fabric consortium blockchain according to claim 1, characterized in that, Step S3, constructing the transaction conflict dependency graph, includes: S31. Determine conflict dependencies between nodes: For any two distinct transactions in the reordered transaction set, if they conflict, then the condition is satisfied: T i .ReadSets∩T j .WriteSets∪T j .ReadSets∩T i . And i≠j, Where i and j represent the sequence coordinates of the transactions, and T i T j Let T represent the i-th transaction and the j-th transaction. i .ReadSets represents the read set for the i-th transaction, T i .WriteSets represents the write set of the i-th transaction. T j .ReadSets represents the read set for the j-th transaction, T j .WriteSets represents the write set of the j-th transaction; When two transactions conflict, further determine the dependency relationship between them: If T i .ReadSets ∩ T j . and i < j, then T j reads and writes depend on T i ; If T i .WriteSets ∩ T j . and i < j, then T j Write-read depends on T i ; S32. Construct edges based on conflicting dependencies: If the read / write operation of the i-th transaction depends on the j-th transaction, then add a directed edge from node i to node j; if the read / write operation of the i-th transaction depends on the j-th transaction, then add a directed edge from node j to node i.

6. The method for optimizing transaction concurrency conflicts based on Fabric consortium blockchain according to claim 1, 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 in 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 traversal transaction conflict dependency graph. If yes, proceed to step S43; otherwise, proceed to 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 a topological sort according to the reordering rules, which include: S441. Calculate transaction conflicts based on the in-degree values ​​of all nodes in the graph and initialize the reordering queue; S442. Add nodes with an in-degree of 0 to the reordering queue; S442. Delete the node with an in-degree value of 0, check if there are any unvisited nodes. If so, update the in-degree value of the unvisited nodes and return to step S442; otherwise, the sorting is complete.

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

Images