A method and apparatus for parallel execution of transactions based on dynamic analysis in the Tendermint system

Abstract

The application provides a transaction parallel execution method and device based on dynamic analysis in a Tendermint system, and relates to the technical field of blockchains.The application proposes that, after receiving a batch of transactions, a leader node marks a unique serial number for each transaction and sorts the received transactions, executes the transactions through a multi-version timestamp sorting algorithm, generates a concurrent schedule that can be serialized in conflict, and generates read-write sets of the transactions according to the execution result to construct transaction dependency triples and broadcast to a verification node.After receiving the transaction dependency triples, the verification node parses and reconstructs a scheduling graph of the transactions, updates the transaction execution state according to the transaction execution result, and determines transactions that can be executed in parallel.If a problem occurs in the verification execution process, an honest verification node will mark an error and broadcast the error of the execution result to oppose the block from entering the blockchain.The application ensures the consistency and atomicity of the transaction parallel execution result and improves the transaction execution efficiency of the blockchain system.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method and apparatus for parallel execution of transactions based on dynamic analysis in the Tendermint system. Background Technology

[0002] Tendermint is a distributed ledger platform based on a consensus algorithm, designed to provide secure, scalable, and high-performance blockchain solutions. Tendermint employs a mechanism called Byzantine Fault Tolerant (BFT) consensus algorithm, which ensures consensus among nodes even if some nodes malfunction or engage in malicious behavior. This guarantees that transactions and state transitions in the Tendermint system are correctly verified and confirmed. Furthermore, this consensus algorithm features high throughput and fast confirmation, capable of handling large volumes of transactions and achieving near real-time transaction finality.

[0003] The Tendermint system manages and maintains its blockchain network using a set of validators responsible for proposing and confirming blocks, ensuring consensus among all nodes. In Tendermint, applications run independently, interacting with the Tendermint core engine through the Application Blockchain Interface (ABCI). Tendermint also provides a secure P2P network layer for communication and data transmission between nodes, supporting encrypted connections and Byzantine fault prevention mechanisms to ensure data confidentiality and integrity. Overall, with its powerful consensus algorithm, high-performance transaction processing capabilities, and flexible application programming interface, the Tendermint system offers developers and enterprises a solution for building secure, scalable distributed applications. It has broad application prospects in finance, supply chain, and digital assets.

[0004] In traditional blockchain systems, each block contains multiple transactions. To ensure consistency in the execution results of transactions across different nodes, a serial execution method is commonly used to execute transactions within a block. Transaction serial execution technology is a crucial blockchain technology. Its core idea is to arrange all transactions in a specific order, ensuring that previous transactions complete before the current transaction can be executed. Specifically: First, transactions on the blockchain are arranged chronologically, with each transaction having a timestamp indicating when it occurred. When a new transaction is added to the blockchain, it is placed at the end of the current list of transactions and must wait for previous transactions to complete before it can be executed. Second, transactions on the blockchain have a sequential order; each transaction has a unique identifier called a transaction hash. When a new transaction is added to the blockchain, its transaction hash is recorded in the block, and the transaction must be executed according to its transaction hash order. Transaction serial execution technology ensures that transactions on the blockchain are executed and recorded in a specific order, avoiding conflicts and competition between transactions, thus guaranteeing the correctness and consistency of the blockchain and ultimately ensuring the correct execution of transactions. However, with the continuous development and improvement of blockchain technology, the transaction serial execution technology cannot make full use of the high performance advantages of multi-core processors, making it difficult to further improve the efficiency of consensus algorithms, thus becoming the performance bottleneck of permissioned blockchain consensus.

[0005] Many characteristics of transaction execution in blockchain systems are similar to those in traditional distributed databases. Therefore, optimization of blockchain transaction execution can largely be based on optimization theories for traditional databases. Theoretically, during block packaging and execution, transactions within a block can be executed in parallel. However, in blockchain systems, malicious nodes exist, and each node is independent, receiving blocks in different orders. Parallel execution of transactions can lead to competition and conflicts between transactions, affecting the correctness and consistency of transaction processing. For example, if one transaction modifies data, and another transaction modifies the same data, inconsistency will occur, requiring measures to ensure consistency. Therefore, when implementing parallel transaction execution, it's crucial to consider how to avoid competition, conflicts, and consistency issues. Furthermore, since transactions are executed in parallel, some transactions have dependencies, such as order transactions needing to execute before payment transactions. If these transactions are not executed in the correct order, they may fail, affecting the correctness and consistency of the blockchain system. Therefore, it's necessary to consider dependencies between transactions and take appropriate measures to ensure they are executed in the correct order.

[0006] In summary, when introducing parallel transaction execution technology into a blockchain system, key considerations include competition and conflict between transactions, dependencies between transactions, atomicity of transactions, data consistency, and performance issues. Summary of the Invention

[0007] To address the shortcomings of the existing technologies, this invention proposes a method and apparatus for parallel execution of transactions based on dynamic analysis in the Tendermint system. The aim is to enable parallel execution of transactions within a block and ensure the consistency and atomicity of transaction execution.

[0008] To address the aforementioned technical problems, the first aspect of this invention proposes a method for parallel transaction execution based on dynamic analysis in the Tendermint system, comprising:

[0009] Step 1: The leader node acquires the transactions to be executed;

[0010] The transaction to be executed is a predefined string containing specific fields. The leader node continuously processes transaction broadcast requests from clients until the number of local transactions exceeds a certain threshold.

[0011] Step 2: The leader node constructs a transaction dependency triple based on the transaction to be executed and broadcasts it to the validator nodes;

[0012] The execution of step 2 includes the following data structures:

[0013] Item in multi-version storage: Stores a data version, containing the following three fields: (1) value field of type string, used to store data; (2) tid field of type int32, used to store the version number of the data, that is, the sequence number of the transaction that wrote this data; (3) state field of type int8, used to store the status information of the data item, which has three states: waiting, commit and abort, respectively, indicating that the execution status of the transaction that wrote this data is in progress, committed and aborted.

[0014] The MultiVersionLine data column stores multi-version data on a certain key and contains the following three fields: (1) a string type key field, used to store the key of multi-version data; (2) an int32 type RTS field, used to store the maximum sequence number of the transaction that reads the data in the key; (3) an array of Item data, denoted as []Item, used to store multi-version data, and all data items in the field are arranged in ascending order according to the size of their tid field.

[0015] MultiVersionStore: A mapping from string keys to multiversion data columns of type MultiVersionLine, denoted as map[string]MultiVersionLine;

[0016] The transaction's dependency DepSet is a mapping from string to *Item, denoted as map[string]*Item, used to record the address pointers of the Item data items in the multi-version storage corresponding to the primary key of type string;

[0017] The transaction execution result resultMsg contains two fields: (1) the transaction sequence number tid of type int32, which is used to indicate the transaction being executed; (2) the transaction execution result state of type string. When the value of state is error, it indicates that the transaction was aborted due to an error. When the value of state is abort, it indicates that the transaction was aborted due to a conflict. When the value of state is commit, it indicates that the transaction was successfully executed and committed.

[0018] Transaction dependency triple TxTuple: Used to record the content, sequence number and dependency relationship of a transaction, containing three fields: (1) string type transaction content Tx, used to record the content of the transaction; (2) int32 type transaction sequence number tid, used to record the sequence number of the transaction; (3) int32 type transaction maximum read dependency maxDep, used to record the dependency relationship of the transaction.

[0019] Step 2.1: Initialize an empty multi-version storage, denoted as S, assign a unique sequence number to each transaction to be executed, and sort the transactions to be executed according to the sequence number order to build a task queue;

[0020] Step 2.2: The worker thread cyclically retrieves the transactions to be executed and their sequence numbers from the task queue, executes the transactions in parallel, writes the transaction execution results into the multi-version storage, and generates the transaction read set R and the transaction write set W based on the transaction execution results;

[0021] The transaction to be executed retrieved in step 2.2 is denoted as T, and its sequence number is denoted as id. The execution process of step 2.2 includes the following three stages:

[0022] (1) Read-write set generation phase: The worker thread initializes the transaction read set R and transaction write set W of type DepSet;

[0023] Whenever a transaction reads key A, if the key exists in R, then the item belonging to that key in R is read. Otherwise, a suitable data item is searched in the multi-version store. The method is as follows: if the mapping S[A] does not exist, S is locked, and the value vA of key A is read from the key-value database. S[A] is set to an empty MultiVersionLine, and then the data item {value:vA,tid:-1,state:commit} is inserted into S[A]. The RTS field of S[A], i.e., S[A].RTS, is set to id. Release the lock on S; if mapping S[A] exists and S[A].RTS is less than id, then set S[A].RTS to id; after completing the above operations, select the data item in S[A] with the largest version number that is not greater than id and read it, and add it to R; whenever a transaction writes data v to key A, insert Item{value:v,tid:id,state:waiting} into W; if the transaction is aborted due to an error, return a resultMsg message with the state field set to error, and end the transaction execution;

[0024] (2) Conflict resolution phase: Insert all items in W into S. If S[A].RTS is greater than tid when writing a certain key A, it is considered that the transaction has been outdated. Set the state field of all items in W to abort, return a resultMsg message with the state field abort, and end the transaction execution. Otherwise, after all items in W have been written, wait for the state field of all items in R to become commit. If the state field of a certain item in R is abort, set the state field of all items in W to abort, return a resultMsg message with the state field abort, and end the transaction execution.

[0025] (3) Transaction commit phase: Set the state field of all Items in W to commit, and then return a resultMsg message with the state field set to commit;

[0026] Furthermore, the method for constructing the transaction dependency triplet is as follows: the leader node initializes the transaction dependency triplet set D as an empty TxTuple array; the leader node traverses all resultMsg transactions whose state field is committed, including the sequence number id and transaction content tx, in ascending order of sequence number. If the transaction read set R is not empty, the sequence number of the data item with the largest sequence number in R is recorded as d; otherwise, d = -1, and the data TxTuple{Tx:tx,tid:id,maxDep:d} is added to D.

[0027] Step 2.3: Reassign new, incrementing sequence numbers to transactions that were aborted due to conflicts in the execution results, add the task back to the task queue, and update the task queue;

[0028] Step 2.4: Repeat steps 2.2 and 2.3 on the updated task queue to obtain a new task queue;

[0029] Step 2.5: Execute the transactions in the updated task queue in Step 2.4 serially, generate transaction execution results, and update the transaction read set and transaction write set of the transaction according to the transaction execution results to complete the execution process of the transaction to be executed;

[0030] Step 2.6: The leader node constructs the transaction scheduling graph based on the transaction read set and the transaction write set, constructs transaction dependency triples to store the dependencies between transactions, and constructs the transaction dependency triple set D based on the transaction dependency triples;

[0031] Step 2.7: The leader node packages the transaction dependency triple set D into byte encoding and broadcasts the byte encoding to the validator nodes;

[0032] Step 3: The verification node receives the transaction dependency triples, completes the verification execution, and commits the block;

[0033] The execution of step 3 includes the following data structures:

[0034] Transaction label txLabel: Used to represent a transaction and its sequence number, containing two fields: (1) the transaction content Tx of type string, and (2) the transaction sequence number tid of type int32;

[0035] Serial number label tidLabel: Used to indicate whether the transaction corresponding to a certain serial number has been committed. It contains three fields: (1) int32 type serial number tid field, (2) bool type done field: a value of done true indicates that the transaction has been committed, and a value of false indicates that the transaction has not been committed, (3) []txLabel type depList field: that is, the unordered list of transaction labels, used to represent all transaction serial numbers and their contents in the transaction dependency triplet, the largest dependency serial number of which is the tid field of this data structure, and used as the scheduling basis for parallel execution of transactions;

[0036] []tidList: An ordered list of tidLabel type serial number labels: Used to sort all tidLabel serial number labels in ascending order based on the size of the tid field;

[0037] The `tidMap` is a mapping from `int32` to `*tidLabel` using the `map[int32]*tidLabel` method. It is used to quickly retrieve the position of the sequence number label in `tidList` based on the transaction sequence number.

[0038] Step 3.1: The verification node converts the received byte encoding into a transaction dependency triple set and parses the transaction dependency triple set;

[0039] Step 3.2: Reconstruct the concurrent scheduling process of the leader node based on the parsing results of Step 3.1;

[0040] Step 3.3: Based on the concurrent scheduling process of the reconstructed leader node, execute transactions in the transaction dependency triple set in parallel;

[0041] Step 3.3.1: Update the transaction execution status based on the transaction execution result;

[0042] Step 3.3.2: Determine the transactions that can be executed in parallel based on the concurrent scheduling process of the leader node;

[0043] Step 3.4: Synchronize the block execution results among the verification nodes and decide whether to commit the block, thus completing the state update for consistency among the verification nodes.

[0044] A second aspect of this invention provides a transaction parallel execution device based on dynamic analysis in the Tendermint system, the device comprising:

[0045] The transaction acquisition module is used to acquire transactions to be executed.

[0046] The multi-version timestamp sorting module is used to sort the acquired transactions to be executed and simulate their execution.

[0047] The multi-version timestamp sorting module further includes:

[0048] The first multi-version storage module stores multi-version data written by the parallel execution module, the secondary parallel execution module, and the serial execution module;

[0049] The sequence number allocation module is used to assign sequence numbers to transactions to be executed and sort the transactions to be executed according to the sequence number order to generate a task queue;

[0050] The parallel execution module is used to extract transactions and their sequence numbers from the task queue, execute the transactions in parallel, and write the transaction execution results into the first multi-version storage module to complete the parallel execution of transactions.

[0051] Sequence number reallocation module: The scheduling thread reallocates a new, incrementing sequence number to transactions that are aborted due to conflicts in the transaction execution results, and adds the transaction and its new sequence number back to the task queue;

[0052] Secondary parallel execution module: used to extract transactions and their sequence numbers from the task sequence generated by the sequence number reallocation module, execute the transactions in parallel, and write the transaction execution results into the first multi-version storage module to complete the secondary parallel execution of transactions;

[0053] Serial execution module: The scheduling thread reassigns a new, incrementing sequence number to transactions that were aborted due to conflicts in the transaction execution results of all secondary parallel execution modules, and executes these transactions serially in the same way as the parallel execution modules;

[0054] The transaction dependency triple broadcast module is used to broadcast the transaction order and dependencies generated by the multi-version timestamp sorting module to the verification nodes;

[0055] The transaction-dependent triple broadcast module further includes:

[0056] The generation module is used to construct transaction dependency triples based on the transaction read set and transaction write set, and to construct a transaction dependency triple set based on the transaction dependency triples.

[0057] In the broadcast module, the leader node packages the transaction dependency triples into byte encoding and then encodes the bytes to the validator nodes.

[0058] The transaction dependency triplet receiving and parsing module is used to parse the transaction dependency triplets obtained from the leader node and reconstruct the scheduling graph generated during the leader node's concurrent scheduling process.

[0059] The transaction-dependent triplet acceptance and resolution module further includes:

[0060] The sequence number label building submodule is used to parse the transaction dependency triples obtained from the leader node and obtain the parsing results;

[0061] The dependency label build submodule is used to reconstruct the scheduling graph of leader node transmission based on the parsing results of the sequence number label build submodule;

[0062] The verification execution module is used to execute transactions in the scheduling graph generated by the transaction dependency triplet acceptance and parsing module in parallel.

[0063] The verification execution module further includes:

[0064] The second multi-version storage module stores multi-version data written by the parallel verification execution module.

[0065] The parallel verification and execution module is used to extract transactions and their sequence numbers from the task queue, execute the transactions in parallel, and write the transaction execution results into the second multi-version storage module to complete the parallel execution of transactions.

[0066] The message processing submodule is used to process the execution results of transactions in the scheduling graph generated by the transaction dependency triplet receiving and parsing module.

[0067] Task scheduling submodule: used to generate the parallel execution order of transactions based on the verification of the scheduling graph generated by the transaction dependency triplet accepting and parsing module;

[0068] The consensus voting module is used to synchronize block execution results among validator nodes and decide whether to submit a block.

[0069] The beneficial effects of adopting the above technical solution are as follows:

[0070] Compared with existing technologies, the method and apparatus of this invention perform concurrent pre-execution sorting of transactions based on multi-version timestamps, are compatible with various user-defined transactions, and ensure the consistency of parallel execution results of transactions by broadcasting transaction dependency triples and re-verifying stages, thereby improving the transaction execution efficiency of the blockchain system.

[0071] Since user transactions in the Tendermint system can be defined by the relevant transaction interface, which is unpredictable, the multi-version timestamp sorting in the method and apparatus of this invention can pre-execute user-defined transactions and obtain read and write results, generating a conflict-free serializable concurrent schedule, which provides a basis for dependency analysis of concurrent transaction execution.

[0072] Due to the decentralized nature of blockchain systems, the transaction execution results of all member nodes must be consistent to ensure that transactions are recorded on the chain normally. To this end, the transaction-dependent triplet in the method and device of this invention can broadcast the transaction sorting results without affecting the block size as much as possible, allowing verifiers to quickly sort locally and verify the results.

[0073] The method and apparatus of this invention are designed for a concurrent transaction execution architecture. In traditional blockchain systems, transactions are executed serially without additional sorting and verification operations. To introduce concurrent execution, the method of this invention modifies the sorting and verification stages of the blockchain system by adding a multi-version timestamp sorting module for the leader node, a transaction dependency triple broadcast module, a verification execution module for the verification node, and a consensus voting module, ensuring that the method of this invention can be executed sequentially.

[0074] The method and apparatus of this invention obtain transaction read-write dependencies through dynamic analysis, which is universally applicable. At the same time, a corresponding parallel execution architecture for transactions is designed, which improves the transaction processing efficiency of the blockchain system and enhances blockchain performance while ensuring the correctness and consistency of transaction processing. Attached Figure Description

[0075] Figure 1 This is a basic schematic diagram illustrating the blockchain system used in this embodiment to process transaction execution.

[0076] Figure 2 This is a schematic diagram illustrating the principle of parallel transaction execution based on dynamic analysis in the Tendermint system of this embodiment;

[0077] Figure 3 This is a flowchart of the transaction parallel execution method based on dynamic analysis in the Tendermint system in this embodiment;

[0078] Figure 4 This is a schematic diagram of the pre-execution process of the multi-version timestamp of the 7 transactions preset in this embodiment; where (a) is the timing diagram of the transaction operation executed in parallel for the first time; (b) is the timing diagram of the transaction operation executed in parallel for the second time; (c) is the timing diagram of the transaction operation executed serially by the scheduling thread; and (d) is the final state of the multi-version storage.

[0079] Figure 5 This is a schematic diagram of the sorting result verification process in this embodiment; where (a) is the initial state of the verification process; (b) is the state after the transaction with transaction sequence number 3 is committed during the verification process; (c) is the state after the transaction with transaction sequence number 1 is committed during the verification process; and (d) is the state after all transactions are committed during the verification process.

[0080] Figure 6 This is a structural diagram of the transaction parallel execution device based on dynamic analysis in the Tendermint system of this embodiment. Detailed Implementation

[0081] To facilitate understanding of this application, specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and embodiments. The following embodiments are illustrative of the invention but are not intended to limit its scope. Rather, these embodiments are provided to provide a more thorough and complete understanding of the disclosure of this application.

[0082] The core idea of ​​this invention is as follows: After the leader node receives a batch of transactions, it first assigns a unique sequence number to each transaction and sorts the received transactions. Then, it tentatively executes the transactions using a multi-version timestamp sorting algorithm to generate a conflict-serializable concurrent schedule. Based on the execution results, it generates a read-write set of the transactions and constructs transaction dependency triples, which are then broadcast to the verification nodes. After each verification node receives the transaction dependency triples, it reconstructs the transaction schedule graph using these triples. Any transaction has a dependency edge on any transaction with a sequence number smaller than its maximum read dependency. During execution, transactions at the outgoing end of a directed edge must wait for the incoming transaction to commit before they can begin execution. At the same time, to prevent the Byzantine leader node from adding incorrect schedule graphs to the block, if a problem occurs during the verification execution process, honest verification nodes will mark the error and broadcast an error message about the execution result to oppose the block entering the blockchain.

[0083] In this embodiment, the existing Tendermint system's linear transaction execution process is as follows: Figure 1 As shown; the principle diagram of transaction parallelism based on dynamic analysis in the Tendermint system proposed in this invention is as follows. Figure 2 As shown.

[0084] The first aspect of this implementation proposes a method for parallel execution of transactions based on dynamic analysis in the Tendermint system, such as... Figure 3 As shown, it includes:

[0085] Step 1: The leader node acquires the transactions to be executed;

[0086] Furthermore, the transaction to be executed is a predefined string containing specific fields. The leader node continuously processes transaction broadcast requests from clients until the number of local transactions exceeds a certain threshold;

[0087] In this implementation, taking a bank transfer transaction as an example, the predefined transactions include a `type` field to indicate the type of transaction. There are two types of predefined transactions: a write-only transaction of type "insert" and a read-write transaction of type "transfer". The "insert" transaction simulates the creation of bank accounts. Transactions T1, T2, T3, and T4 create accounts with addresses "A", "B", "C", and "D" respectively, and add 100 units of currency to each account. The "transfer" transaction simulates transfers between bank accounts. First, it checks whether the balance of the sending account (from field) is sufficient to complete the transaction. Then, it deducts a certain amount from the balance of each sending account and transfers the corresponding amount of currency to the balance of the corresponding receiving account (to field). For example, transaction T5 indicates that account "A" transfers 10 units of currency to account "B", transaction T6 indicates that account "B" transfers 10 units of currency to account "C", and transaction T7 indicates that account "B" transfers 10 units of currency to account "C". The seven predefined transactions are represented as follows:

[0088] T1: {type: "insert", account: "A", amount: 100};

[0089] T2: {type: "insert", account: "B", amount: 100};

[0090] T3: {type: "insert", account: "C", amount: 100};

[0091] T4: {type: "insert", account: "D", amount: 100};

[0092] T5: {type: "transfer", from: ["A"], to: ["B"], amount: 10};

[0093] T6: {type: "transfer", from: ["B"], to: ["C"], amount: 10};

[0094] T7: {type: "transfer", from: ["A"], to: ["D"], amount: 10};

[0095] Step 2: The leader node constructs a transaction dependency triple based on the transaction to be executed and broadcasts it to the validator nodes;

[0096] Furthermore, the execution of step 2 includes the following data structures:

[0097] Item in multi-version storage: Stores a data version, containing the following three fields: (1) value field of type string, used to store data; (2) tid field of type int32, used to store the version number of the data, that is, the sequence number of the transaction that wrote this data; (3) state field of type int8, used to store the status information of the data item, which has three states: waiting, commit and abort, respectively, indicating that the execution status of the transaction that wrote this data is in progress, committed and aborted.

[0098] The MultiVersionLine data column stores multi-version data on a certain key and contains the following three fields: (1) a string type key field, used to store the key of multi-version data; (2) an int32 type RTS field, used to store the maximum sequence number of the transaction that reads the data in the key; (3) an array of Item data, denoted as []Item, used to store multi-version data, and all data items in the field are arranged in ascending order according to the size of their tid field.

[0099] MultiVersionStore: A mapping from string keys to multiversion data columns of type MultiVersionLine, denoted as map[string]MultiVersionLine;

[0100] The transaction's dependency DepSet is a mapping from string to *Item, denoted as map[string]*Item, used to record the address pointers of the Item data items in the multi-version storage corresponding to the primary key of type string;

[0101] The transaction execution result resultMsg contains two fields: (1) the transaction sequence number tid of type int32, which is used to indicate the transaction being executed; (2) the transaction execution result state of type string. When the value of state is error, it indicates that the transaction was aborted due to an error. When the value of state is abort, it indicates that the transaction was aborted due to a conflict. When the value of state is commit, it indicates that the transaction was successfully executed and committed.

[0102] Transaction dependency triple TxTuple: Used to record the content, sequence number and dependency relationship of a transaction, containing three fields: (1) string type transaction content Tx, used to record the content of the transaction; (2) int32 type transaction sequence number tid, used to record the sequence number of the transaction; (3) int32 type transaction maximum read dependency maxDep, used to record the dependency relationship of the transaction.

[0103] Step 2.1: Initialize an empty multi-version storage, denoted as S, assign a unique sequence number to each transaction to be executed, and sort the transactions to be executed according to the sequence number order to build a task queue;

[0104] Specifically, the scheduling thread first creates several worker threads based on the number of CPU cores, then assigns an incrementing sequence number to each transaction to be executed, then initializes an empty MultiVersionStore type multi-version store, denoted as S, and finally adds all the transactions to be executed in sequence according to their sequence numbers to a queue called the task queue.

[0105] In this embodiment, such as Figure 4 As shown in (a), the timing logic of transaction execution is illustrated. Before a transaction enters the worker thread pool, it obtains an incrementing sequence number based on its order in the transaction set. Transaction T1 obtains sequence number 1, and transaction T2 obtains sequence number 2.

[0106] Step 2.2: The worker thread cyclically retrieves the transactions to be executed and their sequence numbers from the task queue, executes the transactions in parallel, writes the transaction execution results into the multi-version storage, and generates the transaction read set R and the transaction write set W based on the transaction execution results;

[0107] Furthermore, in step 2.2, the retrieved transaction to be executed is denoted as T, and the sequence number of the transaction is denoted as id; this includes the following three stages:

[0108] (1) Read-write set generation phase: The worker thread initializes the transaction read set R and transaction write set W of type DepSet;

[0109] Whenever a transaction reads key A, if the key exists in R, it reads the item belonging to that key in R; otherwise, it searches for a suitable data item in the multi-version storage. The method is as follows: if the mapping S[A] does not exist, it locks S, reads the value vA of key A from the key-value database, sets S[A] to an empty MultiVersionLine, inserts the data Item{value:vA,tid:-1,state:commit} into S[A], sets the RTS field of S[A], i.e., S[A].RTS, to id, and then releases the lock on S; if the mapping S[A] exists and S[A].RTS is less than id, it sets S[A].RTS to id; after completing the above operations, it selects the data item in S[A] whose version number is not greater than id and has the largest version number, reads it, and adds it to R; whenever a transaction writes data v to key A, it inserts Item{value:v,tid:id,state:waiting} into W; if the transaction is aborted due to an error, it returns a resultMsg message with the state field set to error and ends the transaction execution.

[0110] (2) Conflict resolution phase: Insert all items in W into S. If S[A].RTS is greater than tid when writing a certain key A, it is considered that the transaction has been outdated. Set the state field of all items in W to abort, return a resultMsg message with the state field abort, and end the transaction execution. Otherwise, after all items in W have been written, wait for the state field of all items in R to become commit. If the state field of a certain item in R is abort, set the state field of all items in W to abort, return a resultMsg message with the state field abort, and end the transaction execution.

[0111] (3) Transaction commit phase: Set the state field of all Items in W to commit, and then return a resultMsg message with the state field set to commit;

[0112] In this embodiment, such as Figure 4As shown in (a), all seven transactions are executed in parallel. Due to limited thread resources, transactions T1, T2, and T3 are executed first, while the other transactions begin execution only after these transactions are committed. Transactions T1, T2, T3, and T4 do not have read-write conflicts with each other. Before transaction T5 (sequence number 5) writes to key B, transaction T6 (sequence number 6) reads key B and updates the RTS field of key B's MultiVersionLine to 6. Therefore, during the conflict resolution phase of transaction T5, the outdated write behavior to key B is detected, and T5 is aborted due to the conflict. At this point, in Figure 4 In (d), the state field of all Item data items with serial number 5 is set to abort; for example... Figure 4 As shown in (a), transaction T7, with sequence number 7, reads the write operation of key A by transaction T5 before transaction T5 is aborted. During the conflict resolution phase, after completing all write operations, transaction T7 discovers that the state field of the Item data item written to key A by transaction T5 has been updated to abort. Therefore, transaction T7 is cascaded aborted. Figure 4 In (d), the state field of all Item data items with serial number 7 is set to abort;

[0113] Step 2.3: Reassign new, incrementing sequence numbers to transactions that were aborted due to conflicts in the execution results, add the task back to the task queue, and update the task queue;

[0114] In this embodiment, such as Figure 4 As shown in (b), transaction T5, which was terminated due to a conflict during the first parallel execution, was reassigned to sequence number 8, and transaction T7, which was terminated due to a conflict during the first parallel execution, was reassigned to sequence number 9.

[0115] Step 2.4: Repeat steps 2.2 and 2.3 on the updated task queue to obtain a new task queue;

[0116] In this embodiment, such as Figure 4 As shown in (b), transaction T5 with sequence number 8 and transaction T7 with sequence number 9 are executed in parallel; T7 first reads key A and updates the RTS field of MultiVersionLine of key A to 9, after which T5 writes Item data to key A; during the conflict resolution phase of T5, it is detected that the write to key A is an outdated write, so T5 is aborted due to the conflict; during the conflict resolution phase of T7, no errors are detected, and T7 is successfully committed; Figure 4 In (d), the state field of all Item data with serial number 8 is updated to abort, while the state field of all Item data with serial number 9 is updated to commit.

[0117] Step 2.5: Execute the transactions in the updated task queue in Step 2.4 serially, generate transaction execution results, and update the transaction read set and transaction write set of the transaction according to the transaction execution results to complete the execution process of the transaction to be executed;

[0118] In this embodiment, such as Figure 4 As shown in (c), transaction T5 was also aborted due to a conflict during the second parallel execution. The scheduling thread assigned it a new sequence number 10 and executed it serially after all transactions had been completed. Since data conflicts are impossible during serial execution, transaction T5 was ultimately successfully committed. Figure 4 In (d), the state field of all Item data with serial number 10 is updated to commit.

[0119] In this embodiment, such as Figure 4 As shown in (d), transaction reads and writes are performed in multi-version storage, which creates a data storage space in memory for each data write, and multiple data writes do not overwrite each other, thereby improving the concurrency of transaction execution. Each column in the figure is a multi-version data column of type MultiVersionLine. The primary key of the first column is A, and the maximum read timestamp (RTS) is 10, indicating that the maximum sequence number of transactions that have read data with primary key A is 10. The multi-version data column with primary key A stores an Item array. In the first row of the array, the value field of the Item type data is 100, and the state field of the Item type data is commit, indicating that the data modification has been successfully committed, and its tid field is 1, indicating that the version number of the data is 1. In the second row, the state field of the data item is abort, indicating that the write was invalidated due to the transaction being aborted.

[0120] Step 2.6: The leader node constructs the transaction scheduling graph based on the transaction read set and the transaction write set, constructs transaction dependency triples to store the dependencies between transactions, and constructs the transaction dependency triple set D based on the transaction dependency triples;

[0121] Furthermore, the method for constructing the transaction dependency triplet is as follows: the leader node initializes the transaction dependency triplet set D as an empty TxTuple array; the leader node traverses all resultMsg transactions whose state field is committed, including the sequence number id and transaction content tx, in ascending order of sequence number. If the transaction read set R is not empty, the sequence number of the data item with the largest sequence number in R is recorded as d; otherwise, d = -1, and the data TxTuple{Tx:tx,tid:id,maxDep:d} is added to D.

[0122] In this implementation, in the transaction dependency triplet, the sequence number tid of transaction T1 is 1. It is a write-only transaction, and its read set is empty. Therefore, the maxDep field of the transaction dependency triplet for T1 is -1. In the transaction dependency triplet of the first row, the Tx field is transaction T1; the tid field is the sequence number 1 of T1; and the maxDep field is -1. Transaction T6 is a transfer transaction from B to C. The transaction read set R contains the write of T2 with version number 2 and the write of T3 with version number 3. Therefore, the maxDep field of the transaction dependency triplet for transaction T6 is 3. The transaction dependency triplets of the 7 transactions are denoted as follows:

[0123] T X :T1, tid: 1, maxDep: -1;

[0124] T X :T2, tid: 2, maxDep: -1;

[0125] T X :T3, tid: 3, maxDep: -1;

[0126] T X :T4, tid: 4, maxDep: -1;

[0127] T X :T5, tid: 5, maxDep: 3;

[0128] T X :T6, tid: 6, maxDep: 1;

[0129] T X :T7, tid: 7, maxDep: 9;

[0130] Step 2.7: The leader node packages the transaction dependency triple set D into byte encoding and broadcasts the byte encoding to the validator nodes;

[0131] Step 3: The verification node receives the transaction dependency triples, completes the verification execution, and commits the block;

[0132] Furthermore, the execution of step 3 includes the following data structures:

[0133] Transaction label txLabel: Used to represent a transaction and its sequence number, containing two fields: (1) the transaction content Tx of type string, and (2) the transaction sequence number tid of type int32;

[0134] Serial number label tidLabel: Used to indicate whether the transaction corresponding to a certain serial number has been committed. It contains three fields: (1) int32 type serial number tid field, (2) bool type done field: a value of done true indicates that the transaction has been committed, and a value of false indicates that the transaction has not been committed, (3) []txLabel type depList field: that is, the unordered list of transaction labels, used to represent all transaction serial numbers and their contents in the transaction dependency triplet, the largest dependency serial number of which is the tid field of this data structure, and used as the scheduling basis for parallel execution of transactions;

[0135] []tidList: An ordered list of tidLabel type serial number labels: Used to sort all tidLabel serial number labels in ascending order based on the size of the tid field;

[0136] The `tidMap` is a mapping from `int32` to `*tidLabel` using the `map[int32]*tidLabel` method. It is used to quickly retrieve the position of the sequence number label in `tidList` based on the transaction sequence number.

[0137] In this embodiment, such as Figure 5 As shown in (a), in the tidList data structure, all tidLabels are arranged in ascending order of their tid field size, and their done field is all false, indicating that the transactions corresponding to the above sequence numbers have not been committed. The depList field is listed separately. The depList field of the tidLabel data with tid field 1 contains a txLabel data, whose Tx field is T7 and tid field is 9, indicating that the maximum read dependency maxDep value of transaction T7 with sequence number 9 in the transaction dependency triplet is 1; tidMap maintains the address mapping from the sequence number tid to the corresponding element in txList; as Figure 5 As shown in (b), the transaction with sequence number tid 3 is committed and returns the resultMsg message. The scheduling thread retrieves the corresponding tidLabel data in tidList according to tidMap and updates its done field to true.

[0138] Step 3.1: The verification node converts the received byte encoding into a transaction dependency triple set and parses the transaction dependency triple set;

[0139] Furthermore, the execution method of step 3.1 is as follows: the verification node first converts the byte encoding broadcast by the leader node into a transaction dependency triple set D, initializes the mapping of type tidMap to empty, the list of type tidList to empty, and then iterates through each transaction dependency triple t in D;

[0140] During the traversal, if the list tidList is not empty and t.tid is not greater than the tid field of the last tidLabel in tidList, an error is returned; otherwise, a tidLabel is inserted at the end of tidList with the tid field value of t.tid, the done field value of false, and the depList field of an empty list of txLabels, and tidMap is mapped to the address pointer of the tidLabel with t.tid.

[0141] In this embodiment, such as Figure 5 As shown in (a), tidMap is a table that maps the sequence number tid to the corresponding tidList entries. The entries in tidList are arranged in ascending order of the size of the tid field, and the done field is initially false.

[0142] Step 3.2: Reconstruct the concurrent scheduling process of the leader node based on the parsing results of Step 3.1;

[0143] If the mapping tidMap to t.maxDep does not exist, return an error; otherwise, create a txLabel with a Tx field of t.Tx and a tid field of t.tid, and add it to the depList field of the tidLabel data pointed to by the mapping tidMap to t.maxDep.

[0144] In this implementation, the transaction dependency triple containing transaction T7 has a maxDep field of 1 and a tid field of 9; therefore, as Figure 5 As shown in (a), a transaction containing transaction T7 and sequence number 9 is added to the depList field of the tidLabel data with tid field 1.

[0145] Step 3.3: Based on the concurrent scheduling process of the reconstructed leader node, execute transactions in the transaction dependency triple set in parallel;

[0146] The verification node initializes the int32 type data watermark, which means that the done field of all tidLabel data items in tidList with a sequence number not greater than the watermark is set to true. First, the verification node sets the watermark to -1. Then, the verification node adds all transactions in D with a maxDep field of -1 and their sequence numbers to the task queue, and executes the above transactions on the multi-version storage using the same method as the parallel execution module in the multi-version timestamp sorting module. It waits for the worker thread to return a resultMsg message and processes the message using the following sub-steps until the task queue is cleared or step 3.3.1 returns an error:

[0147] Step 3.3.1: Update the transaction execution status based on the transaction execution result;

[0148] If the state field value of the resultMsg message is not commit, an error is returned and the execution of all transactions is aborted; otherwise, the tid field of the resultMsg message is t, and the done field of the tidLabel pointed to by the tidMap to t is set to true.

[0149] In this embodiment, such as Figure 5 As shown in (b), thread 1 returns a resultMsg message with a tid field of 3 and a state field value of commit, indicating that the transaction with sequence number 3 was successfully committed; the scheduling thread queries the position of the corresponding data table item in tidList through tidMap and sets its done field to true, that is, the done field of the table item with tid field 3 in tidList is set to true.

[0150] Step 3.3.2: Determine the transactions that can be executed in parallel based on the concurrent scheduling process of the leader node;

[0151] Iterate through tidList starting from the table entry in tidList where the tid field value is equal to watermark. If the watermark value is -1, start iterating from the first data item in tidList. For each tidLabel type data in the retrieval process, record it as l and perform the following process: (1) If the done field value of l is false, end the iteration; (2) If the depList field of l is not empty, add all transactions and their sequence numbers in depList to the task queue, and then clear the depList field; (3) Update the watermark value to l.tid.

[0152] In this embodiment, such as Figure 5As shown in (a), in the initial state, the maxDep field of the transaction dependency triples of transactions T1, T2, T3, and T4 is -1, so they are directly added to the task queue; Figure 5 As shown in (b), thread 1 returns the resultMsg message for transaction with sequence number 3. Its state field is "commit," indicating successful transaction execution. The scheduling thread begins traversing from the first item in tidList; however, the state field of the first item in tidList is false, so the traversal ends directly, and the watermark is not updated. Figure 5 As shown in (c), thread 2 returns the resultMsg message for transaction with sequence number 1, updates the done field of the corresponding entry in tidList to true through tidMap, and the scheduling thread traverses from the first item in tidList. Since the done field of the entry with tid 1 is true, transaction T3 in the depList of that entry is added to the task queue and the depList field is cleared. Then, the watermark is updated to 1. The done field of the second entry is false, so the traversal stops. Figure 5 As shown in (d), the watermark is eventually updated to 10, and one possible commit order of the transactions is T3, T1, T2, T4, T7, T6, T5.

[0153] Step 3.4: Synchronize the block execution results among the verification nodes and decide whether to commit the block, thus completing the state update for consistency among the verification nodes;

[0154] Furthermore, the method for deciding whether to submit a block is as follows: if step 3.3 returns an error, the validator node votes against adding the block containing the transaction dependency triplet set broadcast by the leader node to the blockchain, and records the message as evidence of the leader node's Byzantine behavior; otherwise, provided that there are no other errors, the validator node votes in favor of adding the block containing the transaction dependency triplet set broadcast by the leader node to the blockchain.

[0155] The second aspect of this embodiment proposes a transaction parallel execution device based on dynamic analysis in the Tendermint system, such as... Figure 6 As shown, the device includes:

[0156] The transaction acquisition module is used to acquire transactions to be executed.

[0157] The multi-version timestamp sorting module is used to sort the acquired transactions to be executed and simulate their execution, including:

[0158] The first multi-version storage module stores multi-version data written by the parallel execution module, the secondary parallel execution module, and the serial execution module;

[0159] The sequence number allocation module is used to assign sequence numbers to transactions to be executed and sort the transactions to be executed according to the sequence number order to generate a task queue;

[0160] The parallel execution module is used to extract transactions and their sequence numbers from the task queue, execute the transactions in parallel, and write the transaction execution results into the first multi-version storage module to complete the parallel execution of transactions.

[0161] The sequence number reallocation module, the scheduling thread, reallocates a new incrementing sequence number to the transaction whose execution result was terminated due to a conflict, and adds the transaction and its new sequence number back to the task queue;

[0162] The secondary parallel execution module is used to extract transactions and their sequence numbers from the task sequence generated by the sequence number reallocation module, execute the transactions in parallel, and write the transaction execution results into the first multi-version storage module to complete the secondary parallel execution of the transactions.

[0163] The serial execution module, whose scheduling thread reassigns a new, incrementing sequence number to transactions that were aborted due to conflicts in the transaction execution results of all secondary parallel execution modules, and executes these transactions serially in the same way as the parallel execution modules;

[0164] The transaction dependency triple broadcast module is used to broadcast the transaction order and dependencies generated by the multi-version timestamp sorting module to the verification nodes, including:

[0165] The generation module is used to construct transaction dependency triples based on the transaction read set and transaction write set, and to construct a transaction dependency triple set based on the transaction dependency triples.

[0166] In the broadcast module, the leader node packages the transaction dependency triples into byte encoding and then encodes the bytes to the validator nodes.

[0167] The transaction dependency triple receiving and parsing module is used to parse the transaction dependency triples obtained from the leader node and reconstruct the scheduling graph generated during the leader node's concurrent scheduling process, including:

[0168] The sequence number label building submodule is used to parse the transaction dependency triples obtained from the leader node and obtain the parsing results;

[0169] The dependency label build submodule is used to reconstruct the scheduling graph of leader node transmission based on the parsing results of the sequence number label build submodule;

[0170] The verification execution module is used to execute transactions in the scheduling graph generated by the transaction dependency triplet acceptance and parsing module in parallel, including:

[0171] The second multi-version storage module stores multi-version data written by the parallel verification execution module.

[0172] In this embodiment, the second multi-version storage module and the first multi-version storage module are sub-modules in different modules used to store multi-version data. The first and second are only used to distinguish the names and do not affect the function of the modules.

[0173] The parallel verification and execution module is used to extract transactions and their sequence numbers from the task queue, execute the transactions in parallel, and write the transaction execution results into the second multi-version storage module to complete the parallel execution of transactions.

[0174] The message processing submodule is used to process the execution results of transactions in the scheduling graph generated by the transaction dependency triplet receiving and parsing module;

[0175] The task scheduling submodule is used to generate the parallel execution order of transactions based on the verification of the scheduling graph generated by the transaction dependency triplet accepting and parsing module;

[0176] The consensus voting module is used to synchronize block execution results among verification nodes and decide whether to submit a block.

[0177] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope defined by the claims of the present invention.

Claims

1. A method for transaction parallel execution based on dynamic analysis in a Tendermint system, characterized in that, The application relates to a method for constructing a transaction dependency triple set D, and a method for reconstructing a concurrent scheduling process of a leader node. Step 1: a leader node acquires a to-be-executed transaction; The to-be-executed transaction is a predefined string containing specific fields, and the leader node continuously processes transaction broadcast requests from a client until the number of local transactions exceeds a certain threshold; Step 2: the leader node constructs a transaction dependency triple according to the to-be-executed transaction and broadcasts the transaction dependency triple to a verification node; The transaction dependency triple TxTuple is used for recording the content, sequence number and dependency relationship of a transaction and contains three fields: (1) the content Tx of the transaction in the string type, which is used for recording the content of the transaction; (2) the sequence number tid of the transaction in the int32 type, which is used for recording the sequence number of the transaction; (3) the maximum read dependency maxDep of the transaction in the int32 type, which is used for recording the dependency relationship of the transaction; The method for constructing the transaction dependency triple is as follows: the leader node initializes a transaction dependency triple set D as an empty TxTuple array; the leader node traverses all transaction execution results resultMsg in the sequence number from small to large, and records the sequence number id and the transaction content tx of the transaction whose state field is commit; if the read set R of the transaction is not empty, the sequence number of the data item with the largest sequence number in R is recorded as d, otherwise d=-1; and the data TxTuple{Tx:tx, tid:id, maxDep:d} is added to D. Step 2.1: an empty multi-version storage is initialized and recorded as S, a unique sequence number is allocated to each to-be-executed transaction, and the to-be-executed transactions are sorted according to the sequence number to construct a task queue; Step 2.2: a worker thread cyclically takes the to-be-executed transaction and its sequence number from the task queue, executes the transaction in parallel, writes the transaction execution result into the multi-version storage, and generates the transaction read set R and the transaction write set W according to the transaction execution result; Step 2.3: a new increasing sequence number is allocated to the transaction which is aborted due to conflict in the execution result, and the transaction is re-added to the task queue, and the task queue is updated; Step 2.4: steps 2.2 and 2.3 are repeated for the updated task queue to obtain a new task queue; Step 2.5: the transactions in the updated task queue in step 2.4 are serially executed to generate the transaction execution result, and the transaction read set and the transaction write set are updated according to the transaction execution result, and the execution process of the to-be-executed transaction is completed; Step 2.6: the leader node constructs a scheduling graph of the transaction according to the transaction read set and the transaction write set, constructs a transaction dependency triple to store the dependency relationship between transactions, and constructs a transaction dependency triple set D according to the transaction dependency triple; Step 2.7: the leader node packs the transaction dependency triple set D into a byte code, and broadcasts the byte code to the verification node; Step 3: the verification node receives the transaction dependency triple to reconstruct the concurrent scheduling process of the leader node, completes the verification execution, and performs block submission.

2. The method for parallel execution of transactions based on dynamic analysis in a Tendermint system according to claim 1, wherein, The execution process of step 2 includes the following data structures: Data Item Item in Multi-Version Storage: stores a data version, including the following three fields: (1) a value field of string type, used to store data; (2) a tid field of int32 type, used to store the version number of data, i.e., the sequence number of the transaction writing the data; (3) a state field of int8 type, used to store data item state information, which has three states, i.e., waiting, commit and abort, respectively indicating the execution state of the transaction writing the data as being in execution, having been committed and having been aborted; Data column MultiVersionLine storing multi-version data on a certain key: including the following three fields: (1) a key field of string type, used to store the key of multi-version data; (2) an RTS field of int32 type, used to store the maximum sequence number of the transaction reading the data in the key; (3) an array values field of Item data, denoted as []Item, used to store multi-version data, and all data items in the field are arranged in ascending order according to the size of their tid fields; Multi-Version Storage MultiVersionStore: a mapping of a key of string type to a multi-version data column of MultiVersionLine type, denoted as map[string]MultiVersionLine; DepSet: a mapping from string to , denoted as , is used to record the address pointer of the Item data item in the multi-version storage corresponding to the primary key of the string type; Transaction execution result resultMsg: including two fields: (1) a transaction sequence number tid of int32 type, used to indicate the executed transaction; (2) a transaction execution result state of string type, when the value of state is error, it indicates that the transaction is aborted due to an error, when the value of state is abort, it indicates that the transaction is aborted due to conflict, and when the value of state is commit, it indicates that the transaction is successfully executed and committed.

3. The method of claim 2, wherein the method is based on dynamic analysis in a Tendermint system. The transaction taken out in step 2.2 is denoted as T and the sequence number of the transaction is denoted as id, and the execution process of step 2.2 includes the following three stages: (1) Read-write set generation stage: the working thread initializes the transaction read set R and the transaction write set W of DepSet type; Whenever a transaction reads key A, if the key exists in R, read the Item belonging to the key in R, otherwise, find the appropriate data item in the multi-version storage, the method is: if the mapping S[A] does not exist, lock S, and read the value vA of key A from the key-value database, set S[A] to be an empty MultiVersionLine, then insert the data Item{value:vA, tid:-1, state:commit} into S[A], set the RTS field of S[A], i.e. S[A].RTS to id, and then release the lock of S; if the mapping S[A] exists and S[A].RTS is less than id, set S[A].RTS to id; after the above operations are completed, select the data item with the largest version number in the data items with version numbers not greater than id in S[A] for reading, and add it to R; whenever a transaction writes data v to key A, insert Item{value:v, tid:id, state:waiting} into W; if the transaction aborts due to an error, return a resultMsg message with the state field as error, and end the transaction execution; (2) Conflict resolution phase: insert all Items in W into S, if S[A].RTS is greater than tid when writing to a key A, it is considered that the transaction has written out of time, set the state field of all Items in W to abort, return a resultMsg message with the state field as abort, and end the transaction execution; otherwise, after all Items in W are written, wait for the state field of all Items in R to become commit; if the state field of an Item in R is abort, set the state field of all Items in W to abort, return a resultMsg message with the state field as abort, and end the transaction execution; (3) Transaction commit phase: set the state field of all Items in W to commit, and then return a resultMsg message with the state field as commit.

4. The method of claim 1, wherein the Tendermint system is based on dynamic analysis of transactions for parallel execution. The execution process of step 3 includes the following data structures: Transaction label txLabel: used to represent a certain transaction and its sequence number, including two fields: (1) transaction content Tx of string type, (2) transaction sequence number tid of int32 type; The sequence number label tidLabel is used to indicate whether a certain sequence number corresponds to a committed transaction, and contains three fields: (1) an int32 type sequence number tid field, (2) a bool type done field: the value of done is true, indicating that the transaction has been committed, and the value of false indicates that the transaction has not been committed, (3) a []txLabel type depList field: an unordered list of transaction labels, used to indicate all transaction sequence numbers and their contents in the transaction dependency triple whose maximum dependency sequence number is the tid field of this data structure, and used as the scheduling basis for transaction parallel execution; An ordered list of sequence number labels tidList of the []tidLabel type: used to arrange all sequence number labels tidLabel in ascending order according to the size of the tid field; From int32 to of Mapping tidMap: for fast retrieval of the position of the sequence number tag in tidList according to the transaction sequence number.

5. The method of claim 4, wherein the method is based on dynamic analysis in a Tendermint system. The step 3 includes: Step 3.1: The verification node converts the received byte code into a transaction dependency triple set and parses the transaction dependency triple set; Step 3.2: According to the parsing result of step 3.1, reconstruct the concurrent scheduling process of the leader node; Step 3.3: According to the reconstructed concurrent scheduling process of the leader node, execute the transactions in the transaction dependency triple set in parallel; Step 3.3.1: Update the transaction execution state according to the transaction execution result; Step 3.3.2: Determine the transactions that can be executed in parallel according to the concurrent scheduling process of the leader node; Step 3.4: Synchronize the block execution results among the verification nodes and decide whether to commit the block, and complete the state update of the consistency among the verification nodes.

6. An apparatus for transaction parallelism based on dynamic analysis in a Tendermint system, for implementing the method for transaction parallelism based on dynamic analysis in a Tendermint system according to any one of claims 1-5, characterized in that, The device includes: A transaction acquisition module for acquiring a to-be-executed transaction; A multi-version timestamp sorting module for sorting and simulating the execution of the acquired to-be-executed transaction; A transaction dependency triple broadcasting module for broadcasting the transaction order and dependency relationship generated by the multi-version timestamp sorting module to the verification node; A transaction dependency triple receiving and parsing module for parsing the transaction dependency triple obtained from the leader node and reconstructing the scheduling graph generated in the concurrent scheduling process of the leader node; A verification execution module for executing the transactions in the scheduling graph generated by the transaction dependency triple receiving and parsing module in parallel; A consensus voting module for synchronizing the block execution results among the verification nodes and deciding whether to commit the block; The transaction dependency triple broadcasting module further includes: A generation module for constructing a transaction dependency triple according to the transaction read set and the transaction write set of the transaction, and constructing a transaction dependency triple set according to the transaction dependency triple; A broadcasting module for the leader node to package the transaction dependency triple set into a byte code and transmit the byte code to the verification node; The transaction dependency triple receiving and parsing module further includes: A sequence number label construction submodule for parsing the transaction dependency triple obtained from the leader node to obtain a parsing result; A dependency label construction submodule for reconstructing the scheduling graph transmitted by the leader node according to the parsing result of the sequence number label construction submodule.

7. The Tendermint system based dynamic analysis based transaction parallel execution apparatus according to claim 6, wherein, The multi-version timestamp sorting module further includes: The first multi-version storage module stores multi-version data written by the parallel execution module, the secondary parallel execution module and the serial execution module. The sequence number allocation module allocates a sequence number to each transaction to be executed and sorts the transactions to be executed according to the sequence numbers to generate a task queue. The parallel execution module extracts transactions and their sequence numbers from the task queue, executes the transactions in parallel, writes the transaction execution results into the first multi-version storage module, and completes the parallel execution of the transactions. The sequence number re-allocation module re-allocates a new increasing sequence number to a transaction that is aborted due to a conflict in the transaction execution results, and re-adds the transaction and the new sequence number to the task queue. The secondary parallel execution module extracts transactions and their sequence numbers from the task queue generated by the sequence number re-allocation module, executes the transactions in parallel, writes the transaction execution results into the first multi-version storage module, and completes the secondary parallel execution of the transactions. The serial execution module re-allocates a new increasing sequence number to a transaction that is aborted due to a conflict in the transaction execution results in the secondary parallel execution module, executes the transaction that is aborted due to the conflict in the transaction execution results in the secondary parallel execution module in series, writes the transaction execution results into the first multi-version storage module, and completes the serial execution of the transaction.

8. The parallel transaction execution based on dynamic analysis in a Tendermint system apparatus according to claim 6, wherein, The verification execution module further comprises: The second multi-version storage module stores multi-version data written by the parallel verification execution module. The parallel verification execution module extracts transactions and their sequence numbers from the task queue, executes the transactions in parallel, writes the transaction execution results into the second multi-version storage module, and completes the parallel execution of the transactions. The message processing submodule is configured to process the execution results of the transactions in the scheduling graph generated by the transaction dependency triple accepting and parsing module. The task scheduling submodule is configured to verify the parallel execution order of the transactions according to the scheduling graph generated by the transaction dependency triple accepting and parsing module.

Images