Blockchain transaction execution method based on conflict detection
By detecting transaction conflicts and constructing a transaction conflict graph in the blockchain system, the problem of inconsistent results when executing transactions in parallel is solved, thus improving system performance.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING LIANDAO TECH CO LTD
- Filing Date
- 2022-06-23
- Publication Date
- 2026-06-19
Smart Images
Figure CN115170125B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of blockchain technology, and more specifically, relates to a blockchain transaction execution method with conflict detection. Background Technology
[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, P2P networks, consensus mechanisms, encryption algorithms, and smart contracts. It possesses characteristics such as decentralization, collective maintenance, programmability, immutability, security, trustworthiness, and traceability. Based on these characteristics, blockchain constructs a new trust mechanism that not only solves the trust problems inherent in traditional centralized systems and facilitates transactions between distrustful individuals, but also effectively helps businesses simplify business processes and reduce costs.
[0003] Blockchain adapts to various business scenarios through smart contracts, which endow the blockchain with programmability. Due to the unique nature of the blockchain mechanism, each node in the blockchain network needs to execute transactions locally while ensuring the consistency of transaction results. To ensure data consistency across nodes, most blockchain systems use serial transaction execution to prevent inconsistent results. However, serial execution is inefficient and fails to fully utilize the computing power of modern multi-core CPUs, resulting in wasted system resources. This is one of the performance bottlenecks of traditional blockchain systems. Therefore, it is necessary to consider parallel contract execution to fully utilize system resources and improve system performance.
[0004] The problem with parallel execution is that it cannot guarantee the deterministic nature of the results of related transactions. For example, Fabric, a consortium blockchain under Hyperledger, adopts an execution-sorting-commit architecture that supports parallel transaction execution. However, during the commit phase, it performs version checks on the read and write sets generated by each transaction execution to determine which transactions can be committed and which are marked as invalid. Although this approach allows transactions to execute in parallel, in scenarios with high transaction correlation, a large number of transactions will be marked as invalid due to version checks, and handling invalid transactions will incur significant additional overhead. Summary of the Invention
[0005] The purpose of this invention is to overcome the shortcomings of the prior art and provide a blockchain transaction execution method based on conflict detection. Before executing a transaction, the blockchain node obtains the conflict items of each transaction and constructs a transaction conflict graph. The blockchain node schedules the execution of transactions according to this graph, selects some transactions for concurrent execution, and makes full use of system resources while avoiding transaction execution conflicts, thereby improving the performance of the blockchain system.
[0006] To achieve the above-mentioned objectives, the blockchain transaction execution method based on conflict detection of the present invention includes the following steps:
[0007] S1: For all smart contracts deployed in the current blockchain node, mark their conflict types according to the actual situation of each contract method. The specific method is as follows:
[0008] When the conflict terms of a smart contract's contract method can be extracted from the function's input parameters, the contract method is marked as a static conflict type.
[0009] When the conflict items of a smart contract's contract method cannot be extracted from the function input parameters and the method's time complexity is less than a preset threshold, the contract method is marked as a dynamic conflict type.
[0010] When the conflict terms of a smart contract's contract method cannot be extracted from the function's input parameters and the method's time complexity exceeds a preset threshold, the contract method is marked as a fully conflicted type.
[0011] S2: Blockchain nodes perform conflict detection on all pending transactions, using the following method:
[0012] If the smart contract method corresponding to a transaction is of the static conflict type, then the conflict items of the transaction are extracted according to the contract function call parameters of the transaction, and the transaction is marked as a regular transaction.
[0013] When the smart contract method corresponding to a transaction is a dynamic conflict type, dynamic conflict detection is achieved by pre-executing the transaction and marking the transaction as a regular transaction. The specific method for dynamic conflict detection is as follows: a private context space is created for the transaction and pre-executed. The data read or written during the transaction pre-execution process is recorded in the transaction's private context space in the form of key-value pairs to form a read-write set. Finally, all the key values recorded in the read-write set are the conflict items of the transaction.
[0014] If the smart contract method corresponding to a transaction is of the fully conflict type, then the transaction is marked as a fully conflict transaction;
[0015] S3: For all transactions to be executed in the current block, first obtain their serial execution order and sort the transactions according to this order to obtain the transaction sequence {Tx1, Tx2, ..., Tx...} N}, Tx n This represents the nth transaction executed in a serial execution, where n = 1, 2, ..., N, and N represents the number of transactions to be executed. Then, the transaction conflict graph is generated using the following method:
[0016] 1) Treat each transaction as a node in the transaction conflict graph, and let the serial execution sequence number n = 1;
[0017] 2) For trading Tx n First, determine if n = 1. If yes, proceed to step 3; otherwise, first determine the transaction Tx.n Is it a fully conflicting transaction? If so, add the first n-1 transactions (Tx). m Pointing to transaction Tx n There are directed edges, m = 1, 2, ..., n-1. If not, then sequentially check transaction Tx. n Conflicting terms and the first n-1 transactions Tx m Does the conflicting term have an intersection? If it does, then it means that transaction Tx... n and trading Tx m There is a conflict; add transaction Tx. m Pointing to transaction Tx n If a directed edge does not exist, then further examine the first n-1 transactions Tx. m Is it a full-conflict transaction? If so, add a transaction Tx. m Pointing to transaction Tx n If there is a directed edge, then no operation is performed; otherwise, no operation is performed.
[0018] 3) Determine if n < N. If yes, let n = n + 1 and return to step 2). Otherwise, the transaction conflict graph has been generated.
[0019] S4: Blockchain nodes schedule and execute transactions according to the transaction conflict graph. The specific method is as follows: Select transactions with an in-degree of 0 from the transaction conflict graph for concurrent execution. After execution, these transactions are deleted from the transaction conflict graph. Then, select transactions with an in-degree of 0 again from the new transaction conflict graph for concurrent execution. After execution, these transactions are deleted from the current transaction conflict graph. This process continues until all transactions are executed.
[0020] This invention provides a blockchain transaction execution method based on conflict detection. For all smart contracts deployed in the current blockchain node, the conflict types of the smart contract methods are marked as static conflict types, dynamic conflict types, or full conflict types according to the actual situation of each smart contract. Then, for all transactions to be executed, the blockchain node performs conflict detection according to the conflict type of the corresponding smart contract method, and then generates a transaction conflict graph of all transactions to be executed. The transaction is then scheduled and executed according to the transaction conflict graph.
[0021] This invention obtains the correlation between transactions by detecting conflict items before transaction execution, constructs a transaction conflict graph, and can reasonably select some transactions for concurrent execution, allowing related transactions to be executed serially and unrelated transactions to be executed concurrently, avoiding transaction conflicts, ensuring the consistency of transaction execution results of each node, and making full use of system resources, thereby improving the performance of the blockchain system. Attached Figure Description
[0022] Figure 1 This is a flowchart illustrating a specific implementation of the blockchain transaction execution method based on conflict detection according to the present invention.
[0023] Figure 2 This is a transaction information diagram in this embodiment;
[0024] Figure 3 This is the transaction conflict graph generated in this embodiment;
[0025] Figure 4 This is a diagram showing the changes in the transaction conflict graph during the scheduling and execution of transactions in this embodiment. Detailed Implementation
[0026] The specific embodiments of the present invention will now be described with reference to the accompanying drawings to enable those skilled in the art to better understand the invention. It should be particularly noted that in the following description, detailed descriptions of known functions and designs that might obscure the main content of the invention will be omitted here.
[0027] Example
[0028] Figure 1 This is a flowchart illustrating a specific implementation of the blockchain transaction execution method based on conflict detection according to the present invention. Figure 1 As shown, the specific steps of the blockchain transaction execution method based on conflict detection of the present invention include:
[0029] S101: Smart Contract Conflict Type Flag:
[0030] Conflicts between blockchain transactions arise from modifications to identical data. Given the key-value data model used by most blockchain systems, where the key is a unique identifier, conflicts between transactions stem from modifications to the same key. When the contract methods corresponding to the transaction are relatively simple, such as not involving inter-contract calls, static conflict detection can be directly employed. Leveraging the fact that the data read and written within a function or method is generally related to its input parameters, contract developers can specify which parameters are related to the read and write operations within the function. For example, the transfer function `Transfer(from string, to string, amount int)`, semantically, first reads the user balances corresponding to the `from` and `to` accounts, then completes the transfer of the corresponding amount between the `from` and `to` accounts, and finally updates the balances of the `from` and `to` accounts. In this case, the first and second parameters of the `Transfer` function determine the keys to be read and written within the function, which are the conflict items of the `Transfer` function. Through this configuration, conflict items of the transaction can be statically obtained before transaction execution.
[0031] Static conflict detection can easily identify conflicts in simple contract methods, but it struggles to capture all conflicts in complex methods. Inter-contract calls are one such scenario. Within a blockchain network, multiple smart contract instances run simultaneously. In some scenarios, it's necessary to call methods of other contract instances from within the current contract instance—for example, method A in contract instance A might call method B in contract instance B. This creates a connection between contracts, and in this case, a transaction call request corresponds to a contract call chain. A contract call chain is similar to calling another function within another function. For instance, function A might call function B, with function A as the entry point. In this case, the key data to be manipulated in functions A and B might not be directly reflected in function A's input parameters. The key that function A needs to read or write might be the return value generated after passing the input parameters to function B, and the key that function B needs to read or write might be the result of querying the input parameters in function A. Therefore, transactions involving inter-contract calls with a complexity below a preset threshold require dynamic conflict detection.
[0032] However, when contract methods involve inter-contract calls and their complexity exceeds a preset threshold—for example, transactions with relatively complex logic that are computationally intensive—the complexity makes it difficult to obtain conflicting information from the input parameters, thus rendering static conflict detection unusable. Furthermore, computationally intensive tasks are extremely time-consuming, making dynamic conflict detection prohibitively expensive. Therefore, this invention directly sets such transactions as fully conflicting transactions, meaning these transactions will conflict with both preceding and subsequent transactions. During block execution, fully conflicting transactions must wait for all preceding transactions to complete before execution, and all subsequent transactions must wait for the fully conflicting transaction to complete before execution. This ensures that, under concurrent scheduling, the logical position of fully conflicting transactions on the timeline is consistent with serial execution, avoiding errors.
[0033] In summary, this invention proposes a conflict detection type marking method for smart contracts. Specifically, for all smart contract methods deployed in the current blockchain node, the conflict type of each contract method is marked according to its actual situation. The specific method is as follows:
[0034] When the conflict terms of a smart contract's contract method can be extracted from the function's input parameters, the contract method is marked as a static conflict type.
[0035] When the conflict items of a smart contract's contract method cannot be extracted from the function input parameters and the method's time complexity is less than a preset threshold, the contract method is marked as a dynamic conflict type.
[0036] When the conflict terms of a smart contract's contract method cannot be extracted from the function's input parameters and the method's time complexity exceeds a preset threshold, the contract method is marked as a fully conflicted type.
[0037] S102: Collision Detection
[0038] Blockchain nodes perform conflict detection on all pending transactions, using the following method:
[0039] If the contract method corresponding to a transaction is of static conflict type, then the conflict items of the transaction are extracted according to the contract function call parameters of the transaction, and the transaction is marked as a regular transaction.
[0040] When the contract method corresponding to a transaction is a dynamic conflict type, dynamic conflict detection is achieved by pre-executing the transaction and marking the transaction as a regular transaction. The specific method for dynamic conflict detection is as follows: a private context space is created for the transaction and pre-executed. Data read or written during the transaction pre-execution process is recorded in the transaction's private context space in the form of key-value pairs to form a read-write set. Finally, all the key values recorded in the read-write set are the conflict items of the transaction.
[0041] Since the reading and writing of data during the pre-execution of a transaction takes place in a private space, it does not affect the persistent ledger data of the blockchain nodes. Therefore, all transactions configured with dynamic conflict detection within a block can be executed concurrently, and the overhead is relatively small.
[0042] If the contract method corresponding to a transaction is of the full conflict type, then the transaction is marked as a full conflict transaction.
[0043] S103: Generate a transaction conflict graph:
[0044] For all transactions to be executed in the current block, first obtain their serial execution order and sort the transactions according to this order to obtain the transaction sequence {Tx1, Tx2, ..., Tx}. N}, Tx n This represents the nth transaction executed in a serial execution, where n = 1, 2, ..., N, and N represents the number of transactions to be executed. The transaction conflict graph is then generated using the following method:
[0045] 1) Treat each transaction as a node in the transaction conflict graph. For each subsequent transaction, check the intersection of its conflict items with the preceding transactions to generate directed edges, thus obtaining the transaction conflict graph. Let the serial execution sequence number n = 1.
[0046] 2) For trading Tx n First, determine if n = 1. If yes, proceed to step 3; otherwise, first determine the transaction Tx. nIs it a fully conflicting transaction? If so, add the first n-1 transactions (Tx). m Pointing to transaction Tx n There are directed edges, m = 1, 2, ..., n-1. If not, then sequentially check transaction Tx. n Conflicting terms and the first n-1 transactions Tx m Does the conflicting term have an intersection? If it does, then it means that transaction Tx... n and trading Tx m There is a conflict; add transaction Tx. m Pointing to transaction Tx n If a directed edge does not exist, then further examine the first n-1 transactions Tx. m Is it a full-conflict transaction? If so, add a transaction Tx. m Pointing to transaction Tx n If there is a directed edge, then no operation is performed; otherwise, no operation is performed.
[0047] 3) Determine if n < N. If yes, let n = n + 1 and return to step 2). Otherwise, the transaction conflict graph has been generated.
[0048] S104: Schedule and execute transactions:
[0049] Blockchain nodes schedule and execute transactions according to the transaction conflict graph. The specific method is as follows: Select transactions with an in-degree of 0 from the transaction conflict graph for concurrent execution. After execution, these transactions are deleted from the transaction conflict graph. Then, select transactions with an in-degree of 0 again from the new transaction conflict graph for concurrent execution. After execution, these transactions are deleted from the current transaction conflict graph. This process is repeated until all transactions are executed.
[0050] To better illustrate the technical solution of this invention, a token contract is used as an example for explanation. The token contract in this embodiment includes three contract methods: Transfer1, Transfer2, and ReCharge. Transfer1 and Transfer2 are both based on the Transfer(from string, to string, amount int) method. For ease of description, in this embodiment, Transfer1 is marked as a static conflict type, meaning the first and second parameters of the input are specified as conflicting items in the transaction. Transfer2 is marked as a dynamic conflict type, meaning it requires pre-execution to obtain the conflicting items of the transaction. ReCharge is marked as a full conflict type, meaning it will generate full conflicts with all transactions.
[0051] Figure 2 This is a transaction information diagram in this embodiment. For example... Figure 2As shown, this embodiment contains seven transactions within a block: Transfer1(A, B, 10), Transfer2(B, C, 20), Transfer1(D, E), ReCharge(X, 100), Transfer2(F, G, 50), Transfer2(F, H, 100), and Transfer1(D, I, 100). Before the transactions within the block are executed, transactions Tx1, Tx3, and Tx7 can have their conflict items extracted from the call parameters using static conflict detection, as follows: Tx1: A, B; Tx3: D, E; Tx7: D, I. Transactions Tx2, Tx5, and Tx6 have their conflict items extracted through pre-execution and recording of read / write sets, as follows: Tx2: B, C; Tx5: F, G; Tx6: F, H. Tx4 is directly marked as fully conflicted. After completing the conflict detection, a transaction conflict graph can be constructed, as follows:
[0052] Each transaction is treated as a node in the transaction conflict graph.
[0053] For transaction Tx2, which is not a fully conflicting type, we read its conflict items B and C. At this point, the conflict items of transaction Tx2 and transaction Tx1 have an intersection B. Therefore, we add a directed edge from transaction Tx1 to transaction Tx2.
[0054] For transaction Tx3, it is not a fully conflicting type. Reading its conflict items D and E, there is no intersection between the conflict items of transaction Tx3 and the preceding transactions Tx1 and Tx2. Furthermore, transactions Tx1 and Tx2 are not fully conflicting types, so there is no need to add directed edges.
[0055] For transaction Tx4, since it is a full conflict, it conflicts with all preceding transactions, namely transactions Tx1, Tx2, and Tx3. Therefore, a directed edge is added from transactions Tx1, Tx2, and Tx3 to Tx4.
[0056] For transaction Tx5, it is not a fully conflicting type. Read its conflict items F and G. Transaction Tx5 has no intersection with the conflict items of the preceding transaction, but transaction Tx4 is marked as fully conflicting. Fully conflicting transactions conflict with all subsequent transactions. Therefore, add a directed edge from transaction Tx4 to transaction Tx5.
[0057] For transaction Tx6, which is not a fully conflicting type, its conflict terms F and H are read. At this point, the conflict terms of transactions Tx6 and Tx5 intersect at F, so a directed edge is added from transaction Tx5 to transaction Tx6. Meanwhile, since transaction Tx4 is marked as fully conflicting, a directed edge is added from transaction Tx4 to transaction Tx6.
[0058] For transaction Tx7, which is not a fully conflicting type, its conflict terms D and I are read. At this point, the conflict terms of transaction Tx7 and transaction Tx3 intersect at D, so a directed edge is added from transaction Tx3 to transaction Tx7. At the same time, since transaction Tx4 is marked as fully conflicting, a directed edge is added from transaction Tx4 to transaction Tx7.
[0059] Figure 3 This is the transaction conflict graph generated in this embodiment. For example... Figure 3 As shown, the transaction conflict diagram visually illustrates the conflict relationships between transactions, thus allowing for the scheduling and execution of transactions based on the transaction conflict diagram. Figure 4 This is a diagram showing the changes in the transaction conflict graph during the scheduling and execution of transactions in this embodiment. For example... Figure 4 As shown, the process of scheduling and executing transactions in this embodiment is as follows:
[0060] In the initial transaction conflict graph (a), the transactions with an in-degree of 0 are Tx1 and Tx3. Therefore, transactions Tx1 and Tx3 are executed concurrently first. After execution, transactions Tx1 and Tx3 are removed from the transaction conflict graph, resulting in transaction conflict graph (b).
[0061] In the transaction conflict graph (b), the transaction with an in-degree of 0 is Tx2. Therefore, transaction Tx2 is executed. After execution, transaction Tx2 is deleted from the transaction conflict graph, resulting in transaction conflict graph (c).
[0062] In the transaction conflict graph (c), the transaction with an in-degree of 0 is Tx4. Therefore, transaction Tx4 is executed. After execution, transaction Tx4 is deleted from the transaction conflict graph, resulting in the transaction conflict graph (d).
[0063] In the transaction conflict graph (d), the transactions with an in-degree of 0 are Tx5 and Tx7. Therefore, transactions Tx5 and Tx7 are executed. After execution, transactions Tx5 and Tx7 are removed from the transaction conflict graph, resulting in the transaction conflict graph (e).
[0064] In the transaction conflict graph (e), the transaction with an in-degree of 0 is Tx6. Therefore, transaction Tx6 is executed. After execution, transaction Tx6 is deleted from the transaction conflict graph, the transaction conflict graph is empty, and all transactions have been executed.
[0065] Although the illustrative specific embodiments of the present invention have been described above to enable those skilled in the art to understand the invention, it should be understood that the invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes are obvious as long as they are within the spirit and scope of the invention as defined and determined by the appended claims, and all inventions utilizing the concept of the present invention are protected.
Claims
1. A blockchain transaction execution method based on conflict detection, characterized in that, Includes the following steps: S1: For all smart contracts deployed in the current blockchain node, mark their conflict types according to the actual situation of each contract method. The specific method is as follows: When the conflict terms of a smart contract's contract method can be extracted from the function's input parameters, the contract method is marked as a static conflict type. When the conflict items of a smart contract's contract method cannot be extracted from the function input parameters and the method's time complexity is less than a preset threshold, the contract method is marked as a dynamic conflict type. When the conflict terms of a smart contract's contract method cannot be extracted from the function input parameters and the method's time complexity exceeds a preset threshold, the contract method is marked as a fully conflicted type. S2: Blockchain nodes perform conflict detection on all pending transactions, using the following method: If the smart contract method corresponding to a transaction is of the static conflict type, then the conflict items of the transaction are extracted according to the contract function call parameters of the transaction, and the transaction is marked as a regular transaction. When the smart contract method corresponding to a transaction is a dynamic conflict type, dynamic conflict detection is achieved by pre-executing the transaction and marking the transaction as a regular transaction. The specific method for dynamic conflict detection is as follows: a private context space is created for the transaction and pre-executed. The data read or written during the transaction pre-execution process is recorded in the transaction's private context space in the form of key-value pairs to form a read-write set. Finally, all the key values recorded in the read-write set are the conflict items of the transaction. If the smart contract method corresponding to a transaction is of the fully conflict type, then the transaction is marked as a fully conflict transaction; S3: For all transactions to be executed in the current block, first obtain their serial execution order and sort the transactions according to this order to obtain the transaction sequence. , Indicates the first step in serial execution An executed transaction, , This indicates the number of transactions to be executed; then, the transaction conflict graph is generated using the following method: 1) Treat each transaction as a node in a transaction conflict graph, and assign a sequential execution sequence number. ; 2) Regarding transactions Determine whether If yes, proceed to step 3; otherwise, first determine the transaction. Is it a full-conflict transaction? If so, add it before... One transaction Pointing to transactions The directed edge, If not, then proceed with the transaction checks sequentially. Conflicting items and previous One transaction Does the conflicting item have an intersection? If so, it indicates a transaction. and transactions There is a conflict; add a transaction. Pointing to transactions If a directed edge does not exist, then further determine the preceding edge. One transaction Is it a full-conflict transaction? If so, is it an added transaction? Pointing to transactions If there is a directed edge, then no operation is performed; otherwise, no operation is performed. 3) Determine whether If so, let (Return to step 2), otherwise the transaction conflict diagram has been generated; S4: Blockchain nodes schedule and execute transactions according to the transaction conflict graph. The specific method is as follows: Select transactions with an in-degree of 0 from the transaction conflict graph for concurrent execution. After execution, these transactions are deleted from the transaction conflict graph. Then, select transactions with an in-degree of 0 again from the new transaction conflict graph for concurrent execution. After execution, these transactions are deleted from the current transaction conflict graph. This process continues until all transactions are executed.