Alliance chain transaction parallel processing method based on graph structure

Abstract

The invention discloses an alliance chain transaction parallel processing method based on a graph structure, which comprises the following steps of: starting from conflicts caused when transactions access the same account, analyzing a dependency relationship between the transactions on execution results of each other, endowing a layer of graph attributes for the transactions on the basis of a linear arrangement structure, and realizing parallel execution of transactions by utilizing topological attributes of the graph in a transaction execution stage.

Description

Technical Field

[0001] This invention relates to a parallel transaction processing method for consortium blockchains based on graph structures, belonging to the field of consortium blockchain technology. Background Technology

[0002] Blockchain can be mainly divided into three categories: public blockchains, private blockchains, and consortium blockchains. Public blockchains are open to all users, allowing participation in transaction verification, block generation, and data retrieval without special permission. Bitcoin and Ethereum are typical public blockchains, characterized by high decentralization, transparent and immutable data. Private blockchains, on the other hand, are blockchains limited to internal use by individuals or organizations. Their access and operational permissions are strictly restricted, the number of nodes is limited, and the consensus process is generally efficient and fast, improving processing speed while ensuring security. Consortium blockchains are an important branch of blockchain, employing the core principles and technical architecture of blockchain. A consortium blockchain is a permissioned blockchain, allowing only pre-selected or authorized members to participate. These members jointly maintain and share the blockchain network. Compared to public blockchains, consortium blockchains have limited participating members and a more efficient consensus mechanism, resulting in higher consensus speeds, lower costs, and stronger data privacy protection. Traditional blockchain systems, such as Bitcoin and Ethereum, are limited by their consensus algorithms, resulting in slow transaction processing speeds that struggle to meet the ever-increasing demand for transactions. While consortium blockchains have improved consensus speeds, their nodes still need to process and verify all transactions linearly, meaning their transaction execution efficiency remains constrained by the transaction processing method. Therefore, researching how to optimize consortium blockchain transaction execution has become a hot topic in both research and industry.

[0003] Throughput refers to the number of transactions that can be processed per unit of time, and it is one of the key indicators for measuring the performance of a blockchain system. Traditional blockchain systems generally adopt the Proof-of-Work (PoW) consensus mechanism, which requires a large amount of computing resources for mining rather than for faster transaction processing. This aggressive consensus mechanism leads to slow transaction processing speeds. For example, Bitcoin can only process dozens of transactions per second, which limits the application of blockchain in high-frequency, intensive transaction scenarios such as daily payments in the financial industry. Therefore, improving throughput is the main means of optimizing transaction processing. Hyperledger Fabric, a representative of consortium blockchains, supports multiple consensus algorithms, such as Kafka and Raft. These consensus mechanisms are more efficient than PoW, reducing transaction confirmation time and increasing throughput. In practical applications, Hyperledger's throughput typically ranges from hundreds to thousands of tps. Existing research usually accelerates the confirmation speed of blockchain transactions and improves overall performance by optimizing consensus algorithms, introducing new consensus mechanisms, and adopting sharding technology. With the massive increase in blockchain users and transaction volume, traditional blockchain systems also face scalability challenges. Scalability enables blockchain systems to effectively handle and adapt to the ever-growing scale of users and transactions. Therefore, many current studies are also promoting the better performance of blockchain systems in practical applications by improving their scalability.

[0004] Currently, the most common methods to improve transaction processing throughput include concurrent transaction processing, sharding technology, and the application of emerging consensus mechanisms. In 2020, Tien Tuan Anh Dinh et al., to explore the available transaction concurrency in blockchain workloads to accelerate blockchains, defined a transaction dependency graph based on the flow of UTXOs (based on the UTXO model) and the send-and-receive relationship between transacting parties (based on the account model). Transactions on a connected component were defined as conflicting transactions. They examined historical data from seven public blockchains and proposed a two-phase analysis model to achieve concurrent transaction execution and accelerate the blockchain: the first phase concurrently executes all transactions, detects conflicts, rolls back conflicting transactions, and adds them to the bin container. The second phase sequentially executes transactions in the bin container. This model estimates that Ethereum can achieve up to a 6x speedup using 8 cores. In 2021, Ji Qi et al. proposed BIDL, the first permissioned blockchain framework highly optimized for data center networks, which utilizes network ordering in the network to create a supervised parallel workflow. This workflow carries an orderer to speculatively parallelize the consensus protocol and transaction execution. To prevent malicious participants from disrupting the parallel workflow and achieve stable high performance, BIDL effectively guides all participants by detecting their improper behavior and performs view changes based on a rejection list to replace or reject malicious participants. Compared to three fast permissioned blockchain frameworks, BIDL's parallel workflow reduces application latency by 72.7% and increases throughput by 4.3 times when malicious participants are present. Therefore, BIDL is suitable for integration with traditional securities trading systems. In 2022, Jiang Xiao et al. proposed a DAG-based blockchain concurrency control scheme, NEZHA. NEZHA intelligently constructs an address-based conflict graph and uses address dependencies as edges to construct a directed graph called the conflict graph to capture all conflicting transactions. To generate a total order among transactions, Jiang Xiao et al. also proposed a hierarchical sorting (HS) algorithm to derive the ordering rank of addresses based on the address conflict graph and sort transactions at each address. NEZHA can improve throughput by 8 times and reduce transaction processing latency by 10 times under high data contention conditions compared to traditional conflict graphs.

[0005] Consortium blockchain systems generally adopt the OEV execution architecture, which divides a consensus process into transaction sorting, transaction execution, and block verification. Existing technologies have already accelerated the consensus level of block verification, but the linear arrangement of transactions on consortium blockchain nodes determines that transactions can only be processed serially during the transaction execution phase of the system, which limits further improvement in system throughput. Summary of the Invention

[0006] To address the aforementioned issues and further improve the throughput of consortium blockchain systems, this invention proposes a graph-based parallel transaction processing method for consortium blockchains. Starting with the conflicts caused by transactions accessing the same account, the method analyzes the dependencies between transactions on each other's execution results. Based on the linear arrangement structure, a graph attribute is assigned to the transactions, and the topological attributes of the graph are used to achieve parallel execution of transactions during the transaction execution phase.

[0007] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0008] A parallel transaction processing method for consortium blockchains based on graph structure, the method comprising the following specific steps:

[0009] Static analysis of consortium blockchain transactions is performed to establish an account access table.

[0010] Construct a transaction dependency graph based on the account access table;

[0011] By leveraging the topological properties of the transaction dependency graph, transactions can be topologically sorted to achieve parallel execution.

[0012] As a further technical solution of the present invention, the static analysis of consortium blockchain transactions and the establishment of an account access table include:

[0013] The operation type and accessed data object of each operation in a transaction are parsed out and packaged together with the transaction number into a memTx structure. There is a one-to-one correspondence between the operation type, the data object involved in the operation, and the operation type and the data object involved in the operation are array types, representing the operation type and the corresponding access account of each operation in the transaction.

[0014] As a further technical solution of the present invention, the account access table (TxsConflictMap) uses a specific account as the key and a list of historical transactions that read and write to that account (conflictMapValue) as the value. The list of transactions that read and write to that account includes a read list (ReadList) and a write list (WriteList). During the traversal process, a transaction access table is created for each transaction in the transaction pool, with the specific account accessed by the transaction operation (TxObAndAttr) as the key and the operation access type (TxOp) as the value, and a transaction dependency table (depMap) representing the dependency relationship between the transaction and other transactions.

[0015] As a further technical solution of the present invention, an initial state is set for the transaction access table, specifically: traversing all the access accounts of its operations, obtaining the access type of the transaction to the account from the correspondence between the two arrays of accounts and operation types involved in the operation in memTx; querying the transaction access table according to the account to obtain whether the transaction has previously accessed this account; if the access type of the previous operation to the account is read and the access type of this operation to the account is write, then updating the transaction access table and changing the access type corresponding to this account to write;

[0016] After completing the traversal of all operations within the transaction and setting the initial state of the transaction access table, the transaction dependency analysis process begins. The transaction access table is traversed again, and the account accessed by this transaction is used to query the account access table to obtain the access information of other previous transactions to this account:

[0017] If the previously traversed transactions have also accessed the account, the access type needs to be analyzed. If the current transaction's access type is read, then the current transaction has a dependency relationship with all transactions in the write list corresponding to the account in the account access table. Add all transactions in the write list to the current transaction's transaction dependency table, update the account access table, and add the current transaction to the account's read list. If the current transaction's access type is write, then the current transaction has a dependency relationship with all transactions in the read and write lists corresponding to the account in the account access table. Add all transactions in both the read and write lists to the current transaction's transaction dependency table, update the account access table, so that the write list corresponding to this account only contains the current transaction, and clear the read list.

[0018] If no transactions have accessed the account before, a key-value pair containing the account and the access type of the transaction to the account needs to be added to the account access table.

[0019] As a further technical solution of the present invention, four graph elements are introduced: in-degree, out-degree, parent node set, and child node set. For a transaction T, the in-degree of T represents the number of transactions that depend on T, the out-degree of T represents the number of transactions that T depends on, the parent node set of T represents the set of transactions that T depends on, and the child node set of T represents the set of transactions that depend on T.

[0020] As a further technical solution of the present invention, the step of constructing a transaction dependency graph based on the account access table includes:

[0021] If a transaction is treated as a node, then the dependency relationship between transactions is represented as a directed edge, pointing from the dependent transaction to the dependent transaction.

[0022] As a further technical solution of the present invention, for a pair of transactions with a dependency relationship, the process of generating a directed edge is to add the dependent transaction to the parent node set of the dependent transaction, then add the dependent transaction to the child node set of the dependent transaction, and pass the pair of transactions as parameters to the edge generation function.

[0023] As a further technical solution of the present invention, the step of using the topological characteristics of the transaction dependency graph to perform topological sorting of transactions and achieve parallel execution includes:

[0024] Find the node with a current out-degree of zero. Multiple transactions that do not depend on other transactions or whose dependent transactions have been completed are executed in parallel by multiple threads.

[0025] An access array is created to record whether each transaction has been added to the sorting queue. Only transactions with an out-degree of zero and that have not been visited can be selected and added to the output queue. In each round, nodes with an out-degree of zero are searched out, and the transaction nodes that depend on them are found through the child node attributes of the transactions in the transaction pool. The out-degree of these nodes is then decremented by one.

[0026] As a further technical solution of the present invention, after constructing the transaction dependency graph and before performing topological sorting of transactions using the topological characteristics of the transaction dependency graph, the method further includes transaction weight prediction and transaction dependency graph partitioning, specifically:

[0027] Transaction weight prediction is achieved based on a deep learning model, which is a three-layer fully connected neural network model. Its input features are selected as the total number of single transaction operations, the proportion of read operations, and the access rate of hot accounts. The output feature is the time cost of transaction execution. The execution time of transactions under different conditions in LevelDB is used as training data to complete the training of the neural network model.

[0028] Using transaction weights as the identifier of workload, the transaction dependency graph is divided into n subgraphs. Transactions in different subgraphs are executed concurrently by different threads. Transactions that do not conflict within a subgraph can also be executed concurrently by idle threads.

[0029] As a further technical solution of the present invention, according to the breadth-first search approach, before starting the partitioning process, the total weight of the transaction in the transaction dependency graph is calculated first, and then divided by the number of subgraphs to be partitioned as a threshold for the end of subgraph partitioning.

[0030] Iterate through all transactions in the transaction pool until a transaction that has not been added to any subgraph is found. Add the transaction to a subgraph, then iterate through the parent and child nodes of the transaction node and add the neighbor nodes that have not yet been added to the subgraph to the neighbor node list.

[0031] Next, other nodes are selected to be added to the subgraph using the breadth-first search algorithm: traverse the list of neighboring nodes, add any unused transactions to the subgraph, and add any unused transactions in the parent and child nodes to the list of neighboring nodes.

[0032] Each time a transaction node is added to the subgraph, a breadth-first search operation is performed, and the subgraph chart, subgraph weight table, access array, and transaction node location table are updated. The generation of the subgraph ends only when the total weight of the transaction nodes in the subgraph exceeds the threshold.

[0033] The remaining transactions in the neighbor node list are retained until the generation of the next subgraph;

[0034] At the beginning of subgraph generation, if the length of the neighbor node list is greater than zero, a transaction node in the list is selected and added to the subgraph; if the neighbor node list is empty, the transaction pool is traversed to select an unvisited transaction node and add it to the subgraph, and the above process is repeated.

[0035] Compared with the prior art, the present invention, employing the above technical solution, has the following technical effects:

[0036] This invention constructs an account access table and generates a transaction dependency graph using static analysis of transactions, and further assigns weights to transactions to provide a better selection scheme for scheduling in topology sorting. Attached Figure Description

[0037] Figure 1 The process for handling transaction execution in a blockchain system.

[0038] Figure 2a The process executed for a high-concurrency transaction graph model.

[0039] Figure 2b This describes the execution process of a high-concurrency weighted transaction graph model.

[0040] Figure 3 The process of constructing an account access table to analyze three transactions.

[0041] Figure 4 The process of determining the parallel execution order for topological sorting. Detailed Implementation

[0042] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention. Furthermore, it will be understood by those skilled in the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have a meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless defined as herein.

[0043] The following example illustrates how a submarine encountered an isolated wave in a certain sea area:

[0044] To further improve the throughput of consortium blockchain systems, this invention provides two parallel transaction execution models on the Tendermint system. These models can leverage the parallelism of transactions while maintaining transaction correctness and data consistency, achieving parallel processing of transactions during the execution phase. This technology is comprised of two parallel execution models: a high-concurrency transaction graph model and a high-concurrency weighted transaction graph model. The high-concurrency transaction graph model consists of three steps: static analysis of consortium blockchain transactions to establish an account access table, construction of a transaction dependency graph based on the account access table, and topological sorting of transactions using the topological characteristics of the transaction dependency graph to achieve parallel execution. The high-concurrency weighted transaction graph model consists of five steps, including the three steps of the high-concurrency transaction graph model, plus two additional steps: transaction weight prediction and transaction dependency graph partitioning. The execution architecture of the original consortium blockchain system and the processes of the two models proposed in this technology during the transaction execution phase are as follows: Figure 1 , Figure 2a and Figure 2b As shown.

[0045] Figure 3The static analysis module for transactions and the establishment of an account access table are shown. Existing transaction model structures are insufficient to uncover access conflict relationships between transactions. The original transactions are byte arrays with weak semantics. Therefore, this invention resolves this by parsing the original transactions into a new data structure, `memTx`. A transaction may contain several operations, each with an operation type (read or write) and the data object it accesses. Access conflicts between transactions can be analyzed using the operation type and accessed object attributes. Therefore, these two items are parsed from the original transaction and packaged into the `memTx` structure along with the transaction number (a unique identifier for each transaction). There is a one-to-one correspondence between the operation type, the data object involved in the operation, and the data object itself. The operation type and the data object are arrays, representing the operation type and corresponding access account for each operation within the transaction. The data object accessed by the operation contains the specific object and attributes accessed by the operation. The values ​​of this field will be compared to determine if conflicts exist between transactions. Because of the subsequent need to construct a transaction graph, this technology introduces graph elements such as in-degree, out-degree, parent node set, and child node set on top of the original transaction pool structure to find each transaction in the transaction pool and other transactions related to it. Assuming there is a transaction T, the in-degree of T represents the number of transactions that depend on T, the out-degree of T represents the number of transactions that T depends on, the parent node set of T represents the set of transactions that T depends on, and the child node set of T represents the set of transactions that depend on T.

[0046] Consortium blockchain transaction conflicts can be categorized into read-write conflicts and write-write conflicts based on their type. This study defines a read-write conflict as two concurrently executing transactions accessing the same account, one as a read access and the other as a write access. A write-write conflict is defined as two concurrently executing transactions both containing write accesses of the same type. If a transaction contains both read and write operations on the same account, the conflict relationship between this transaction and other transactions should be analyzed based on the write operations. This conflict relationship is essentially a dependency relationship; that is, conflicting transactions cannot be executed in parallel, and the execution of subsequent transactions depends on the execution results of preceding transactions. Violating the execution order will affect the execution result of at least one transaction, compromising data consistency. To meet the needs of graphing transactions, this paper defines graph elements representing transaction dependencies. If a transaction is considered a node, then the dependency relationship can be represented as a directed edge, pointing from the dependent transaction to the dependent transaction. Even if two transactions may have dependencies on multiple accounts, this paper stipulates that more than one dependency relationship can only be transformed into a single edge. Since transactions have a certain arrival and verification order on the consortium blockchain network nodes, a later-arriving transaction needs to continue execution based on the execution result of an earlier-arriving transaction. Therefore, it is only possible for a later-arriving transaction to depend on an earlier-arriving transaction. Two transactions cannot depend on each other, so there is at most one directed edge between two transaction nodes.

[0047] This invention designs an algorithm for dynamically updating the account access table and transaction adjacency relationships to explain in detail the process of generating transaction dependencies. In the algorithm initialization phase, an account access table (TxsConflictMap) needs to be created. It uses the specific account as the key and the list of transactions that have recently read or written to that account (conflictMapValue) as the value. The list of transactions that read or write to that account includes a read list (ReadList) and a write list (WriteList). During the traversal process, a transaction access table (TxObAndAttr) is created for each transaction in the transaction pool, using the specific account accessed by the transaction operation (TxObAndAttr) as the key and the operation access type (TxOp) as the value. A transaction dependency table (depMap) representing the dependencies between that transaction and other transactions is also created.

[0048] All transactions in the transaction pool are preprocessed, and an initial state is set for the transaction access table. Specifically, this involves iterating through all the access accounts of each operation and using the mapping between the accounts and operation types in the `memTx` array to determine the transaction's access type for that account. Then, the transaction access table is queried based on the account to check if the transaction's previous operations have accessed that account. If a previous operation's access type for that account was read, and this operation's access type is write, the transaction access table is updated to change the access type for that account to write. After completing the iteration of all operations within the transaction and setting the initial state of the transaction access table, the transaction dependency analysis process begins, with the specific steps shown in Algorithm 1 in Table 1. The transaction access table is iterated again, and the account access table is queried using the account accessed by this transaction to obtain the access information of other previous transactions for that account. This can be divided into two cases: whether the preceding transaction also allowed access to that account. If previously traversed transactions have also accessed the account, the access type needs to be analyzed: If the current transaction's access type is read, then the current transaction has a dependency on all transactions in the write list corresponding to that account in the account access table. Add all transactions in the write list to the current transaction's transaction dependency table, update the account access table, and add the current transaction to the account's read list. If the current transaction's access type is write, then the current transaction has a dependency on all transactions in both the read and write lists corresponding to that account in the account access table. Add all transactions in both the read and write lists to the current transaction's transaction dependency table, update the account access table, ensuring that the write list corresponding to this account contains only the current transaction, and clear the read list.

[0049] If no transactions have previously accessed this account, a key-value pair containing the account and the transaction's access type to the account needs to be added to the account access table. When constructing the transaction dependency graph, this article only needs to find direct dependencies between transactions. Indirect dependencies can be obtained through multiple direct dependencies. Therefore, when a write operation occurs, the read / write list corresponding to the current account should be cleared. If subsequent transactions perform read / write access operations on this account, only the direct dependency between the subsequent transaction and the current transaction will be considered.

[0050] Table 1

[0051]

[0052]

[0053]

[0054] Figure 4 The diagram illustrates the construction of a transaction dependency graph. After analyzing the dependencies of all transactions in the transaction pool, a transaction dependency graph can be constructed based on these dependencies. Constructing a dependency graph essentially transforms these dependencies into directed edges pointing from the dependent transaction to the dependent transaction. This invention represents these edges as adjacency relationships between nodes in the graph. The parent node set (parentTxs) stores other transactions that the transaction depends on, and the child node set (childTxs) stores other transactions that depend on this transaction. For a pair of transactions with a dependency relationship, the process of generating a dependency edge involves adding the dependent transaction to the parent node set of the dependent transaction, and then adding the dependent transaction to the child node set of the dependent transaction. Algorithm 2 in Table 2 describes the dependency edge generation and invocation process. The edge generation function (GENEDGE) needs to be called within the transaction dependency generation function (PROCTXDEPENDENCY). After finding all the dependencies of a certain transaction and its previous transactions, it is necessary to traverse the transaction dependency table (depMap), pass this transaction and the transactions it depends on as parameters to the edge generation function, and add the two transactions with dependencies to each other's parent node set and child node set.

[0055] Table 2

[0056]

[0057] The topology sorting module implements parallel execution. In actual execution, multiple threads can be enabled to execute non-conflicting transactions in parallel. Parallel execution requires finding nodes with an out-degree of zero. Multiple transactions that do not depend on other transactions or whose dependent transactions have already completed can be executed by multiple threads in parallel, as described in Algorithm 3 in Table 3. An access array is created to record whether each transaction has been added to the sorting queue. Only transactions with an out-degree of zero and that have not been visited can be selected and added to the output queue. In actual calls, each round searches for nodes with an out-degree of zero. The dependent transaction nodes should be found through the child node attributes of the transactions in the transaction pool, and the out-degree of these nodes should be decremented by one. This ensures that transaction nodes with an out-degree of zero may reappear in the next round of searching.

[0058] Table 3

[0059]

[0060] Transaction Weight Prediction Module. This invention employs a deep learning model to obtain a fitting function to aid in the prediction of transaction weights. The Sequential model from the Keras library is used to construct the deep learning model, building a three-layer fully connected neural network model organized in a Sequential manner. The model begins with an input layer containing 64 neurons, using ReLU activation to threshold the neuron outputs, thus addressing the vanishing gradient problem during deep neural network training. The input data dimension is defined as 3, corresponding to 3 variables affecting the output. A hidden layer of 32 neurons is further added, also using ReLU activation to enhance the model's ability to learn complex patterns. Finally, the model architecture ends with an output layer containing a single node for performing a regression task to predict a single continuous value. No specific activation function is specified for this layer; the predicted value is directly output. The `compile()` method is then used to configure training parameters, specifying the optimizer as `adam` and the loss function as `MSE`. The input features are selected as the total number of single transaction operations, the proportion of read operations, and the access rate of hot accounts. The output feature is the time cost of transaction execution. The final model is obtained by using the transaction execution time under different combinations of conditions in LevelDB as training data.

[0061] In this study, the deep learning model was trained in an Anaconda virtual environment using Python 3.7.11 as the interpreter. However, the process of assigning weights to transactions needed to be completed in a Go environment. Therefore, the trained model was saved first and then loaded when needed to participate in transaction weight prediction. The overall process of assigning weights to transactions is as follows: In the weight retrieval function of the Go project, all transactions in the transaction pool are traversed, and their internal operations are analyzed one by one. The number of operations, the percentage of operations read, and the access rate of hot accounts are collected and combined into a string as three-dimensional input data for a transaction. A `strings.Reader` instance is defined, and multi-line text data containing all transaction input data is passed as standard input to the Python script. Then, an `exec.Command` instance is constructed, passing the absolute paths of the Python interpreter and the Python script as command-line arguments. Standard output and standard error output buffers are set to capture the standard output content and any error messages generated after command execution, respectively. The command is executed using `cmd.Run()`. The Python script predicts an output for each line of input data and writes all predicted values ​​to a text file. If the command execution does not return any error information, the function flow will continue to read the text file that saves the predicted values ​​line by line, and assign the weight attribute of the transaction pool transaction with the rounded predicted values.

[0062] Transaction Dependency Graph Partitioning Module. In real-world applications or test suites, a batch of transactions may be very large. Even though the topological characteristics of the graph can bring a certain degree of concurrency, it is still quite limited. To further explore transaction concurrency, this study divides the large graph into several subgraphs. Transactions in different subgraphs are executed concurrently by different threads, and non-conflicting transactions within a subgraph can also be executed concurrently by idle threads. Weights are used as workload identifiers to guide the partitioning of the transaction dependency graph. The goal of partitioning is to divide the transaction dependency graph into n subgraphs with approximate weights. This study follows a breadth-first search approach. Before starting the partitioning process, the total weight of transactions in the transaction dependency graph is calculated and then divided by the number of subgraphs to be divided into, serving as a threshold for ending the subgraph partitioning. All transactions in the transaction pool are traversed until a transaction that has not been added to any subgraph is found, and then added to a subgraph. Next, the parent and child nodes of the transaction node are traversed, and neighboring nodes that have not yet been added to a subgraph are added to the neighbor node list. Next, a breadth-first search algorithm is used to select other nodes to add to the subgraph: The neighbor node list is traversed, and any unused transactions are added to the subgraph. Unused transactions in the parent and child nodes of each unused transaction are then added to the neighbor node list. Each time a transaction node is added to the subgraph, a breadth-first search operation is performed, and the subgraph graph, subgraph weight table, access array, and transaction node location table are updated. The generation of the subgraph ends only when the total weight of the transaction nodes exceeds a threshold. The remaining transactions in the neighbor node list are carried over to the next subgraph generation stage. At the beginning of subgraph generation, if the length of the neighbor node list is greater than zero, a transaction node from the list is selected to add to the subgraph; if the neighbor node list is empty, the transaction pool is traversed to select a new unvisited transaction node to add to the subgraph, and the above process is repeated. The specific partitioning process is shown in Algorithm 4 in Table 4.

[0063] The transaction dependency graph partitioning function takes the total weight of the transaction nodes in the graph and the number of subgraphs to be partitioned as input, and outputs a subgraph table (recording the node IDs of each subgraph), a subgraph weight table (recording the weight of each subgraph), and a transaction node location table (recording which subgraph each transaction node belongs to). Starting with the first subgraph, transaction nodes are sequentially added to the subgraph. When the first subgraph is generated or the neighbor node list is empty, all transaction nodes are traversed until a transaction not yet added to a subgraph is found. The transaction node ID is added to the subgraph, and the node weight is added to the subgraph weight. The node's access array and location table are then modified. The node's parent and child nodes are found through its internal attributes and added to the neighbor node list. This completes the process of adding a node to a subgraph.

[0064] Table 4

[0065]

[0066]

[0067] Before the total weight of a subgraph reaches a threshold, continuously select transaction nodes from the neighbor node list to add to the subgraph, update the subgraph table, subgraph weight table, transaction node access table, and transaction node location table, and add the transaction nodes that have not yet been added to any subgraph from the parent and child nodes of the selected node to the neighbor node list. Repeat the above process until the weight of the subgraph exceeds the threshold. If there are still unprocessed transaction nodes in the neighbor node list at this point, truncate the list at the end of the traversal and keep the remaining transaction nodes in the generation process of the next subgraph.

[0068] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0069] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0070] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0071] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0072] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any transformations or substitutions that can be conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A parallel transaction processing method for consortium blockchains based on graph structure, characterized in that, The method includes the following specific steps: Static analysis of consortium blockchain transactions is performed to establish an account access table. Construct a transaction dependency graph based on the account access table; By leveraging the topological properties of the transaction dependency graph, transactions can be topologically sorted to achieve parallel execution.

2. The parallel transaction processing method for consortium blockchains based on graph structure according to claim 1, characterized in that, The static analysis of consortium blockchain transactions, and the establishment of an account access table, include: The operation type and accessed data object of each operation in a transaction are parsed out and packaged together with the transaction number into a memTx structure. There is a one-to-one correspondence between the operation type, the data object involved in the operation, and the operation type and the data object involved in the operation are array types, representing the operation type and the corresponding access account of each operation in the transaction.

3. The parallel transaction processing method for consortium blockchains based on graph structure according to claim 2, characterized in that, The account access table (TxsConflictMap) uses the specific account as the key and the list of transactions that have read and written to that account in the past (conflictMapValue) as the value. The list of transactions that have read and written to that account includes a read list (ReadList) and a write list (WriteList). During the traversal, a transaction access table (TxObAndAttr) is created for each transaction in the transaction pool, with the specific account accessed by the transaction operation (TxObAndAttr) as the key and the operation access type (TxOp) as the value, and a transaction dependency table (depMap) representing the dependency relationship between the transaction and other transactions.

4. The parallel transaction processing method for consortium blockchains based on graph structure according to claim 3, characterized in that, The initial state of the transaction access table is set as follows: Iterate through all the access accounts of its operations, and obtain the access type of the transaction for the account by the correspondence between the two arrays of accounts and operation types involved in the operation in memTx; query the transaction access table according to the account to find out whether the transaction has accessed the account in the past. If the access type of the previous operation for the account is read and the access type of the current operation for the account is write, then update the transaction access table and change the access type of the account to write. After completing the traversal of all operations within the transaction and setting the initial state of the transaction access table, the transaction dependency analysis process begins. The transaction access table is traversed again, and the account accessed by this transaction is used to query the account access table to obtain the access information of other previous transactions to this account: If the previously traversed transactions have also accessed the account, then the access type needs to be analyzed. If the access type of the current transaction is read, then the current transaction has a dependency relationship with all transactions in the write list corresponding to the account in the account access table. Add all transactions in the write list to the transaction dependency table of the current transaction, update the account access table, and add the current transaction to the read list of the account. If the access type of the current transaction is write, then the current transaction has a dependency relationship with the transactions in the read and write lists corresponding to the account in the account access table. Add all transactions in the read and write lists to the transaction dependency table of the current transaction and update the account access table so that the write list corresponding to this account contains only the current transaction, and clear the read list. If no transactions have accessed the account before, a key-value pair containing the account and the access type of the transaction to the account needs to be added to the account access table.

5. The parallel transaction processing method for consortium blockchains based on graph structure according to claim 2, characterized in that, Four graph elements are introduced: in-degree, out-degree, parent node set, and child node set. For a transaction T, the in-degree of T represents the number of transactions that depend on T, the out-degree of T represents the number of transactions that T depends on, the parent node set of T represents the set of transactions that T depends on, and the child node set of T represents the set of transactions that depend on T.

6. The parallel transaction processing method for consortium blockchains based on graph structure according to claim 5, characterized in that, The construction of the transaction dependency graph based on the account access table includes: If a transaction is treated as a node, then the dependency relationship between transactions is represented as a directed edge, pointing from the dependent transaction to the dependent transaction.

7. The parallel transaction processing method for consortium blockchains based on graph structure according to claim 6, characterized in that, For a pair of transactions that have a dependency relationship, the process of generating a directed edge is to add the dependent transaction to the parent node set of the dependent transaction, then add the dependent transaction to the child node set of the dependent transaction, and pass the pair of transactions as parameters to the edge generation function.

8. The parallel transaction processing method for consortium blockchains based on graph structure according to claim 5, characterized in that, The method of using the topological properties of the transaction dependency graph to perform topological sorting of transactions and achieve parallel execution includes: Find the node with a current out-degree of zero. Multiple transactions that do not depend on other transactions or whose dependent transactions have been completed are executed in parallel by multiple threads. An access array is created to record whether each transaction has been added to the sorting queue. Only transactions with an out-degree of zero and that have not been visited can be selected and added to the output queue. In each round, nodes with an out-degree of zero are searched out, and the transaction nodes that depend on them are found through the child node attributes of the transactions in the transaction pool. The out-degree of these nodes is then decremented by one.

9. The parallel transaction processing method for consortium blockchains based on graph structure according to claim 1, characterized in that, After constructing the transaction dependency graph, the method before performing topological sorting of transactions using the topological properties of the transaction dependency graph also includes transaction weight prediction and transaction dependency graph partitioning, specifically: Transaction weight prediction is achieved based on a deep learning model, which is a three-layer fully connected neural network model. Its input features are selected as the total number of single transaction operations, the proportion of read operations, and the access rate of hot accounts. The output feature is the time cost of transaction execution. The execution time of transactions under different conditions in LevelDB is used as training data to complete the training of the neural network model. Using transaction weights as the identifier of workload, the transaction dependency graph is divided into n subgraphs. Transactions in different subgraphs are executed concurrently by different threads. Transactions that do not conflict within a subgraph can also be executed concurrently by idle threads.

10. The parallel transaction processing method for consortium blockchains based on graph structure according to claim 9, characterized in that, Following the breadth-first search approach, before starting the partitioning process, the total weight of the transactions in the transaction dependency graph is calculated and then divided by the number of subgraphs to be partitioned, which serves as a threshold for the end of subgraph partitioning. Iterate through all transactions in the transaction pool until a transaction that has not been added to any subgraph is found. Add the transaction to a subgraph, then iterate through the parent and child nodes of the transaction node and add the neighbor nodes that have not yet been added to the subgraph to the neighbor node list. Next, other nodes are selected to be added to the subgraph using the breadth-first search algorithm: traverse the list of neighboring nodes, add any unused transactions to the subgraph, and add any unused transactions in the parent and child nodes to the list of neighboring nodes. Each time a transaction node is added to the subgraph, a breadth-first search operation is performed, and the subgraph chart, subgraph weight table, access array, and transaction node location table are updated. The generation of the subgraph ends only when the total weight of the transaction nodes in the subgraph exceeds the threshold. The remaining transactions in the neighbor node list are retained until the generation of the next subgraph; At the beginning of subgraph generation, if the length of the neighbor node list is greater than zero, select the transaction node in the list to add to the subgraph; If the neighbor node list is empty, iterate through the transaction pool to select an unvisited transaction node to add to the subgraph, and repeat the above process.

Images