Parallel control method, device and related equipment based on alliance chain transaction conflicts

Abstract

The present application provides a parallel control method, apparatus, and related equipment based on consortium chain transaction conflicts. The method includes: obtaining t transactions from a target consensus node on a target consortium chain; packaging the t transactions using a consensus algorithm to obtain a first block, and broadcasting the first block to other consensus nodes; performing static analysis on the first block, and calculating the conflict rate of the transactions based on the results of the static analysis; when the transaction conflict rate is greater than a preset threshold, executing t transactions in parallel on the target consensus node using a consistent concurrency control algorithm to obtain a first execution result; using the first execution result to fill the first block to obtain a target first block, and broadcasting the target first block to other consensus nodes; when the consensus requirements are met, submitting the target first block to the target consortium chain; otherwise, discarding the target first block. By adopting the method of the embodiment of the present application, the performance of the concurrency control algorithm can be improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a parallel control method, apparatus, and related equipment based on alliance chain transaction conflicts. Background Art

[0002] In the blockchain field, performance has always been a challenge hindering its application in more scenarios, especially in the consortium blockchain sector. The number of transactions processed per second and transaction latency are of widespread concern. A blockchain is a chained data structure composed of continuously appended blocks, each of which is composed of transactions. In consortium chains, blockchain performance can be improved by optimizing components such as consensus algorithms, transaction parallelism, networking, and storage. Parallel transaction execution is a crucial aspect. Existing technologies improve consortium chain performance by increasing transaction parallelism. However, when transaction conflicts are high on consortium chains, existing concurrency control algorithms perform poorly.

[0003] Therefore, how to improve the performance of the concurrency control algorithm in scenarios with high transaction conflict rates on consortium chains is an urgent issue to be solved. Summary of the Invention

[0004] The embodiments of the present application provide a parallel control method, apparatus, and related equipment based on alliance chain transaction conflicts. On the alliance chain, based on the transaction conflict rate in the block, a consistent concurrent scheduling algorithm can be used to concurrently execute transactions in a high-conflict transaction rate scenario, thereby improving the performance of the concurrency control algorithm.

[0005] In a first aspect, an embodiment of the present application provides a parallel control method based on consortium chain transaction conflicts, the method comprising:

[0006] Obtain t transactions of a target consensus node on a target consortium chain, where the target consortium chain includes f consensus nodes, where t and f are both integers greater than 1; the target consensus node is any consensus node among the f consensus nodes;

[0007] Packing the t transactions through a consensus algorithm to obtain a first block, and broadcasting the first block to f-1 consensus nodes among the f consensus nodes excluding the target consensus node;

[0008] Performing static analysis on the first block to obtain a static analysis result;

[0009] Calculating the transaction conflict rate based on the static analysis result to obtain a transaction conflict rate;

[0010] When the transaction conflict rate is greater than a preset threshold, executing the t transactions in parallel on the target consensus node using a consistency concurrency control algorithm to obtain a first execution result;

[0011] Filling the first block with the first execution result based on the consensus algorithm to obtain a target first block, and broadcasting the target first block to the f-1 consensus nodes; after any consensus node among the f-1 consensus nodes receives the target first block, executing the transaction in parallel on the consensus node using the consistency concurrency control algorithm to obtain a second execution result;

[0012] Collect the second execution results corresponding to the f-1 consensus nodes to obtain f-1 second execution results, and package the f-1 second execution results to obtain a first execution result message package;

[0013] Detecting whether the first execution result message packet meets a first preset condition through the consensus algorithm;

[0014] When the first execution result message packet meets the first preset condition, the target first block is submitted to the target alliance chain; when the first execution result message packet does not meet the first preset condition, the target first block is discarded.

[0015] In a second aspect, an embodiment of the present application provides a parallel control device based on alliance chain transaction conflicts, the device comprising:

[0016] An acquisition module is used to obtain t transactions of a target consensus node on a target alliance chain, where the target alliance chain includes f consensus nodes, and t and f are both integers greater than 1; the target consensus node is any consensus node among the f consensus nodes;

[0017] a determination module, configured to package the t transactions using a consensus algorithm to obtain a first block, and broadcast the first block to f-1 consensus nodes among the f consensus nodes excluding the target consensus node; perform static analysis on the first block to obtain a static analysis result; and calculate a conflict rate for the transactions based on the static analysis result to obtain a transaction conflict rate;

[0018] a judgment module, configured to execute the t transactions in parallel on the target consensus node using a consistency concurrency control algorithm to obtain a first execution result when the transaction conflict rate is greater than a preset threshold;

[0019] The determination module is further configured to fill the first block with the first execution result based on the consensus algorithm to obtain a target first block, and broadcast the target first block to the f-1 consensus nodes; after any consensus node among the f-1 consensus nodes receives the target first block, execute the transaction in parallel on the consensus node using the consistency concurrency control algorithm to obtain a second execution result;

[0020] The acquisition module is further used to collect the second execution results corresponding to the f-1 consensus nodes, obtain f-1 second execution results, and package the f-1 second execution results to obtain a first execution result message package;

[0021] The judgment module is further configured to detect whether the first execution result message packet meets a first preset condition through the consensus algorithm;

[0022] The determination module is also used to submit the target first block to the target alliance chain when the first execution result message packet meets the first preset condition; and discard the target first block when the first execution result message packet does not meet the first preset condition.

[0023] In a third aspect, an embodiment of the present application provides an electronic device comprising a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the program comprises instructions for executing the steps of any method of the first aspect of the embodiment of the present application.

[0024] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the above-mentioned computer-readable storage medium stores a computer program for electronic data exchange, wherein the above-mentioned computer program enables a computer to execute part or all of the steps described in any method of the first aspect of the embodiment of the present application.

[0025] In a fifth aspect, embodiments of the present application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program, wherein the computer program is operable to cause a computer to execute some or all of the steps described in any method of the first aspect of the embodiments of the present application. The computer program product may be a software installation package.

[0026] By implementing the embodiments of the present application, in a scenario where the block transaction conflict rate on the alliance chain is high, a consistent concurrent scheduling algorithm is adopted to improve the performance of the concurrency control algorithm. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the description of the embodiments. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0028] Figure 1 This is a flow chart of a parallel control method based on alliance chain transaction conflicts provided by an embodiment of the present application;

[0029] Figure 2 Flowchart of the execution of the consistency concurrency control algorithm provided in the embodiment of the present application;

[0030] Figure 3 A flowchart of a directed acyclic graph construction provided in an embodiment of the application;

[0031] Figure 4 A flowchart of a scheduling algorithm for executing a transaction conflict scenario on a consortium chain provided in an embodiment of the application;

[0032] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0033] Figure 6 The application embodiment provides a functional module composition block diagram of a parallel control device based on alliance chain transaction conflicts. DETAILED DESCRIPTION

[0034] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0035] The terms "first," "second," and the like in the specification and claims of this application and the accompanying drawings are used to distinguish between different objects, not to describe a particular order. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements but may optionally include steps or elements not listed, or may optionally include other steps or elements inherent to the process, method, product, or apparatus.

[0036] It should be understood that the term "and / or" in this document is merely a description of the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this document indicates that the associated objects are in an "or" relationship. The "plurality" appearing in the embodiments of this application refers to two or more.

[0037] In the embodiments of the present application, "at least one item" or similar expressions refers to any combination of these items, including any combination of single items or plural items, and refers to one or more, and multiple refers to two or more. For example, at least one item (item) of a, b, or c can represent the following seven situations: a, b, c, a and b, a and c, b and c, a, b, and c. Among them, each of a, b, and c can be an element or a set containing one or more elements.

[0038] The "connection" appearing in the embodiments of the present application refers to various connection methods such as direct connection or indirect connection to achieve communication between devices, and the embodiments of the present application do not impose any limitations on this.

[0039] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0040] The following are the explanations of the relevant terms involved in this application:

[0041] Consortium Chain: A consortium chain is a blockchain network that allows for both public and private data and transactions to a certain degree. A consortium chain is jointly maintained and managed by multiple pre-selected organizations or institutions, and only these members can join the network. In a consortium chain, the generation of each block is jointly decided by all pre-selected nodes. Other nodes connected to the network can participate in transactions but are not involved in the bookkeeping process.

[0042] Consensus Node: A node is a computer that has installed the necessary software and hardware for a blockchain system and joined the blockchain network. A node participates in network communications, logical operations, and data validation. It is responsible for verifying and storing data such as blocks, transactions, and status, while also providing transaction processing and data query interfaces for clients. Nodes can be divided into consensus nodes and observation nodes. Consensus nodes participate in the entire consensus process, acting as bookkeepers responsible for packaging blocks and validators to verify blocks to complete the consensus process.

[0043] Block: A block is a data structure constructed in chronological order. The first block in a blockchain is called the "genesis block." Subsequent blocks are identified by their "height," with each block's height increasing one by one. Each new block incorporates the hash information of the previous block and, through a hash algorithm, generates a unique data fingerprint with the data of the current block, thus forming an interconnected blockchain structure. The basic data structure of a block consists of a block header and a block body. The block header contains basic information such as the block height, hash value, block producer signature, and state tree root, while the block body contains a list of transaction data and related receipt information. The size of the entire block will vary depending on the size of the transaction list.

[0044] Transaction: A transaction represents a piece of request data sent to the blockchain system. It is used to deploy contracts, call contract interfaces, maintain contract lifecycles, manage assets, and exchange value. The basic transaction data structure includes the sender, recipient, and transaction data. Users construct transactions, sign them with their private keys, and submit them to the blockchain. The transaction is then processed through a consensus mechanism across multiple nodes, executing the associated smart contract code and generating the state data specified by the transaction. Finally, the transaction is packaged into a block and stored alongside the state data.

[0045] FISCO BCOS (Be Credible, Open & Secure) is a secure, controllable, stable, easy-to-use, and high-performance financial-grade blockchain underlying platform launched by the FISCO Open Source Working Group in 2017.

[0046] In the blockchain field, performance has always been a challenge hindering its application in more scenarios, especially in the consortium blockchain sector. The number of transactions processed per second and transaction latency are of widespread concern. A blockchain is a chain-like data structure composed of continuously appended blocks, each of which is composed of transactions. In a consortium blockchain, blockchain performance can be improved by optimizing components such as consensus algorithms, transaction parallelism, networking, and storage. Transaction parallelism is a crucial aspect. Existing technologies improve consortium chain performance by increasing the parallelism of transaction execution. Current concurrency control algorithms in blockchains can be categorized as optimistic or pessimistic. Optimistic concurrency control assumes a low probability of transaction conflicts, while pessimistic concurrency control assumes a high probability of transaction conflicts. A high transaction conflict rate may be due to complex contracts with multiple resource accesses, or it may be due to static analysis misclassifying transactions that could be parallelized as incompatible. If pessimistic concurrency control is used, some transactions that could be parallelized will be reduced to serial execution, resulting in lower performance. Optimistic concurrency control can lead to excessive rollbacks or re-executions, resulting in wasted resources and poor performance. In scenarios where the conflict rate of transactions on blockchains is high, the performance of existing concurrency control algorithms on blockchains is poor. Therefore, there is an urgent need to solve the problem of how to control concurrency during transaction execution, prevent transactions from conflicting over the same resources, and improve the performance of concurrency control algorithms.

[0047] To solve the above problems, an embodiment of the present application provides a parallel control method based on alliance chain transaction conflicts, which is applied to the alliance chain platform. First, t transactions of the target consensus node on the target alliance chain are obtained, and the target alliance chain includes f consensus nodes, and t and f are both integers greater than 1; then, the t transactions are packaged through the consensus algorithm to obtain a first block, and the first block is broadcast to f-1 consensus nodes among the f consensus nodes except the target consensus node; static analysis is performed on the first block to obtain a static analysis result; based on the static analysis result, a conflict rate is calculated for the transaction to obtain a transaction conflict rate; when the transaction conflict rate is greater than a preset threshold, the t transactions are executed in parallel on the target consensus node through the consistency concurrency control algorithm to obtain a first execution result; based on the consensus algorithm, the first execution is used to execute the t transactions in parallel The result is filled into the first block to obtain the target first block, and the target first block is broadcast to the f-1 consensus nodes. After any consensus node among the f-1 consensus nodes receives the target first block, the transaction is executed in parallel on the consensus node using the consistency concurrency control algorithm to obtain a second execution result. The second execution results corresponding to the f-1 consensus nodes are collected to obtain f-1 second execution results, and the f-1 second execution results are packaged to obtain a first execution result message packet. The consensus algorithm is used to detect whether the first execution result message packet meets a first preset condition. If the first execution result message packet meets the first preset condition, the target first block is submitted to the target consortium chain. If the first execution result message packet does not meet the first preset condition, the target first block is discarded. This improves the performance of the concurrency control algorithm in scenarios where transactions conflict with the same resource.

[0048] The following combination Figure 1 A parallel control method based on alliance chain transaction conflicts in an embodiment of the present application is described. Figure 1 This is a flow chart of a parallel control method based on consortium chain transaction conflicts provided by an embodiment of the present application, which specifically includes the following steps:

[0049] Step S110: Obtain t transactions of the target consensus node on the target alliance chain, where the target alliance chain includes f consensus nodes, and t and f are both integers greater than 1; the target consensus node is any consensus node among the f consensus nodes.

[0050] The consortium chain consists of multiple consensus nodes, which are independent nodes running on different devices. Each node can process on-chain transactions and conduct consensus voting. These consensus nodes coordinate and communicate through a pre-set consensus algorithm to ensure the security and consistency of data on the consortium chain. The t transactions on the target consortium chain refer to transactions selected from the transaction pool managed by the current target consensus node based on the existing transaction records in the transaction pool it manages, according to preset rules and conditions. The transaction pool of the target consensus node usually stores multiple transactions on the chain waiting to be executed or processed, ensuring that these transactions comply with the preset order and can participate in the block construction and consensus process in sequence according to the specified priority.

[0051] Consensus nodes on the target consortium chain are distributed across different network or physical nodes. Each consensus node is capable of verifying on-chain transactions and is responsible for maintaining transaction integrity and data consistency. The consortium chain consensus algorithm typically requires each consensus node to process and confirm a specific number of transactions. Each transaction includes information such as the initiator, recipient, transaction amount or data, and timestamp. The target consensus node selects transactions that meet the current block construction criteria from among t transactions and includes them in the block to be generated. It also generates a transaction hash for subsequent verification. After receiving these transactions, the target consortium chain selects appropriate transaction types, such as account transfers and smart contract calls, based on the consortium chain's business requirements, ensuring that these transactions are fully recorded on the chain. Before each transaction is finally confirmed and entered into the chain, it undergoes multiple confirmations, execution, and data storage by consensus nodes to ensure immutability and data consistency.

[0052] Step S120: Pack the t transactions using a consensus algorithm to obtain a first block, and broadcast the first block to f-1 consensus nodes among the f consensus nodes excluding the target consensus node.

[0053] Among them, the blocks in the consortium chain are generated by the nodes participating in the consensus. In the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm used by FISCO BCOS, the consensus nodes in each round are divided into leading consensus nodes and ordinary consensus nodes. In each round of consensus, the leading consensus node is responsible for the generation of new blocks, and all consensus nodes verify the new blocks together. When more than 2f+1 nodes reach a consensus on the new block, the new block will be added to the blockchain. In each round of consensus, the leader node obtains transactions from its own transaction pool and uses the obtained transactions to construct a new block. The block consists of a block header and a block body. The block header contains information about the parent block, a list of consensus node signatures for this block, a transaction root, a receipt root, and a status root. When the leader node just constructs a new block, the transaction root and status root in the block header are both zero values, and the corresponding receipt-related fields in the block body are also empty, because the block has not been executed at this time. The leader node sends the block to other consensus nodes first rather than sending it to other nodes for verification after execution.

[0054] After receiving a message packet containing a new block from the leader consensus node, a consensus node first verifies the legitimacy of the consensus message according to the rules of the consensus algorithm. This includes verifying whether the signer of the message is a consensus node and whether the signature is valid. To reduce network overhead, the block message packet sent by the leader consensus node contains only the transaction hash. After verification, the consensus node performs some preparatory work before executing the transaction, including obtaining complete transaction information from its own transaction pool or other consensus nodes based on the transaction hash, analyzing transaction conflict dependencies, calculating the conflict rate, and selecting a transaction execution algorithm. Each consensus node executes the transactions in the block and, based on its execution results, fills in any fields left unfilled by the leader node when constructing the block. Each consensus node then broadcasts its execution results and, based on the conditions required by the consensus algorithm (for example, PBFT requires collecting at least 2f signatures with the same result, excluding its own), checks whether consensus can be reached on the block. If consensus is reached, a new block is generated. Otherwise, the current block is discarded after a timeout, and the next round of consensus begins.

[0055] Step S130: Perform static analysis on the first block to obtain a static analysis result.

[0056] Blocks are composed of transactions. Transactions on consortium chains can be divided into two types: contract deployment transactions and contract call transactions. Contract deployment transactions do not conflict with other transactions. Contract call transactions provide the call interface and parameters, which can lead to conflicts if multiple transactions access the same contract. Static analysis is performed during contract deployment. During contract deployment, static analysis analyzes the behavior of each contract interface based on the contract's bytecode. Based on whether the interface contains bytecode for storage, read and write, bytecode for accessing globally shared environment variables, and bytecode for contract calls, it determines whether each contract interface can be executed in parallel. If so, it determines the keys that compete for access within each interface. After obtaining the static analysis results, they are stored in the contract's interface description file during contract deployment. During execution, the interface description file of the contract being called is retrieved and, combined with the actual interface parameters in the transaction, the keys actually accessed in the transaction are parsed.

[0057] The interface description file describes the behavior of each contract interface, documenting whether it involves operations such as storage, global variables, and contract calls, and proactively analyzing potential concurrency issues. The actual interface parameters refer to the specific input parameters in the contract interface when executing a contract transaction. Smart contract calls typically require parameters. For example, in a transfer transaction, the interface parameters may include the sender's address, the recipient's address, and the transfer amount. These parameters determine the data the transaction will access (e.g., the account's balance, the key-value pair, etc.). By combining the information in the interface description file, the system can analyze the actual keys accessed in the transaction using the actual interface parameters. For example, in a transfer operation, by parsing the transaction parameters, it is possible to determine which account balances will be accessed, thereby determining whether there are concurrency conflicts. By combining the static analysis results of the user's program when deploying the contract with the input parameters of the contract interface in the transaction, it is possible to obtain the key-value pairs stored on the consortium chain that each transaction will access. Based on the key-value pairs stored on the consortium chain accessed by each transaction, the contract call behavior of the block transaction can be analyzed.

[0058] To more clearly illustrate static analysis, let's take an example: there's a transfer contract with a transfer(string memory from, string memory to, uint256 amount) interface. The transfer interface has three parameters: from, to, and amount. It's used to transfer amount from the from account to the to account. The logic of this interface is to deduct amount from the from account and add amount to the to account. So, when two transactions calling this contract interface have the same from or to, for example, transaction 1: A->B and transaction 2: A->C, the two transactions cannot be executed in parallel because modifying the same key at the same time will result in uncertain results.

[0059] Step S140 , calculating the transaction conflict rate based on the static analysis result to obtain a transaction conflict rate.

[0060] Among them, transaction conflict refers to the conflict between reading and writing contracts called by different transactions in a block. A contract refers to a program or protocol deployed on the consortium chain. The contract is called by the transaction to perform corresponding operations or state changes. Among them, transaction conflict occurs when contracts with the same key operation are divided into the same block when constructing the block. There are many ways to calculate the transaction conflict rate. For example, based on the percentage of non-parallel transactions in the block to the total transactions in the block; construct a directed acyclic graph based on the results of transaction conflict analysis, calculate the longest path of the directed acyclic graph, and divide the longest path by the total number of transactions to obtain the percentage.

[0061] In a possible embodiment, calculating a conflict rate of the transaction based on the static analysis result to obtain the transaction conflict rate specifically includes: determining a number p of non-parallelizable transactions among the t transactions based on the static analysis result; p is an integer greater than 1 and less than or equal to t; and determining the transaction conflict rate based on the t transactions and the number p of non-parallelizable transactions.

[0062] The transaction conflict rate can be calculated based on the percentage of non-parallel transactions in the block to the total transactions in the block. If the number of non-parallel transactions in t transactions is p, the transaction conflict rate is calculated as follows:

[0063] c=(p / t)*100%

[0064] Where c is the transaction conflict rate, p is the number of non-parallel transactions among t transactions, and p is an integer greater than 1 and less than or equal to t.

[0065] As can be seen, in the embodiments of this application, by calculating the transaction conflict rate of a block, the possibility of parallel execution of transactions within the block can be effectively assessed. Adjusting the block parallel execution strategy based on the conflict rate results and dynamically selecting the directed acyclic graph parallel execution mode or the consistent concurrency control algorithm parallel execution mode can improve block processing efficiency while maintaining transaction consistency. This ensures consistent execution results across consensus nodes while efficiently utilizing system computing resources, which helps improve the overall performance of the consortium chain and reduce transaction confirmation delays.

[0066] Step S150: When the transaction conflict rate is greater than a preset threshold, the t transactions are executed in parallel on the target consensus node through a consistency concurrency control algorithm to obtain a first execution result.

[0067] If the transaction conflict rate is less than or equal to the preset threshold, the transactions are executed in parallel using a directed acyclic graph (DAG) algorithm. If the transaction conflict rate is greater than the preset threshold, the transactions are processed in parallel using a consistent concurrency control algorithm. For example, assuming the conflict rate = non-parallelizable transactions / total number of block transactions * 100%, there are 8 transactions, none of which can be statically analyzed to determine the keys they will access during execution. Using the formula "Number of non-parallelizable transactions = 8 / total number of transactions = 8", we can conclude that the proportion of non-parallelizable transactions is 100%. Assuming the DAG conflict rate requirement is less than 80%, since 100% > 80%, the consistent concurrency control algorithm is used for execution.

[0068] In a possible embodiment, executing the t transactions in parallel on the target consensus node using a consistency concurrency control algorithm to obtain a first execution result specifically includes:

[0069] 51. Obtain the number of logical cores M of the target consensus node, where M is an integer greater than 1. The number of logical cores M indicates that the target consensus node can process M tasks in parallel.

[0070] 52. Sequentially select transactions 1 to M in the first block to obtain a first group of M transactions;

[0071] 53. Execute the first group of M transactions in parallel on the target consensus node using the consistency concurrency control algorithm to obtain the first execution result.

[0072] In high-concurrency transaction processing scenarios, transaction tasks are appropriately allocated by determining the logical core count M of the target consensus node. The logical core count M represents the maximum number of tasks the target consensus node can handle simultaneously. By grouping transactions, the consensus node can maximize computing resource utilization and improve the efficiency of parallel transaction execution. Next, from the first block, transactions are sequentially selected as groups, one to M in order, to ensure consistent order during transaction processing. This grouping ensures that the execution of each group of transactions is not affected by other unprocessed transactions. Dynamic adjustments can be made based on each transaction's priority, data dependencies, and other characteristics, ensuring that dependencies between transactions do not disrupt transaction consistency during concurrent execution. Then, during the parallel execution of the first group of M transactions, each transaction implements a distributed locking mechanism using a consistent concurrency control algorithm. Specifically, each transaction acquires a lock based on its operation type (e.g., read lock or write lock) during execution, ensuring that operations on critical resources are not affected by other transactions. Furthermore, during transaction processing, all locks are released only after the transaction is completed, preventing deadlocks during execution. If there are conflicting transactions in the first group of M transactions (i.e., write-write conflicts, write-before-read conflicts, or read-before-write conflicts involving the same resource), the consistency concurrency control algorithm prioritizes the conflicting transactions based on their indexes. Typically, transactions with smaller indexes are prioritized, meaning that tasks with higher priority are executed first, while other conflicting transactions may be rolled back or await further processing. Finally, during transaction execution, if a rollback due to a conflict is detected, the rolled back transaction is reassigned to the next group of transactions for re-execution. Upon re-execution, the rolled back transaction is re-locked based on the latest resource status to ensure that the re-executed transaction no longer conflicts with other transactions, thus preventing the rollback transaction from failing or being lost. After all transactions are completed, all consensus nodes on the consortium chain perform a consistency check on the first execution result. Specifically, the target consensus node compares the execution results and data status of each transaction to ensure consistency across different nodes. If any inconsistencies are detected, the system triggers a retry mechanism to re-execute the transaction with the discrepancy until all nodes achieve a consistent execution result, ultimately achieving network consensus.

[0073] As can be seen, in the embodiment of the present application, by dynamically detecting the number of logical cores M, the system can make real-time task scheduling adjustments based on the current load of the target consensus node, thereby optimizing the efficiency of multi-task parallel processing. Under high load conditions, the system can flexibly adjust the number of transactions in each group, dynamically adapting to the state of computing resources, thereby avoiding reduced execution efficiency or delays caused by overload or insufficient resources.

[0074] In a possible embodiment, executing the first group of M transactions in parallel on the target consensus node using the consistency concurrency control algorithm to obtain the first execution result specifically includes:

[0075] 531. Determine the read-write key-value pairs of the first group of M transactions, and lock the read-write keys to obtain M transaction locks.

[0076] 532. Determine the state of the target transaction lock, where the state of the target transaction lock includes a read lock and / or a write lock. The target transaction lock is any one of the M transaction locks.

[0077] 533. Determine whether the target transaction lock has a mutual exclusion phenomenon according to the state of the target transaction lock;

[0078] 534. When mutual exclusion exists in the target transaction lock, the first group of M transactions is executed in parallel on the conflicting transactions corresponding to the target transaction lock using the consistency concurrency control algorithm on the target consensus node to obtain the first execution result.

[0079] During the parallel execution of the first group of M transactions using a consistent concurrency control algorithm, a multi-layered control mechanism is specifically implemented to rationally handle transaction lock acquisition, mutual exclusion detection, and conflict resolution. First, by determining the read and write key-value pairs involved in each transaction, the system assigns a corresponding read lock or write lock to each transaction, thereby forming M transaction locks. This locking mechanism allows the system to lock the resources required by each transaction before execution, ensuring that the transaction is not affected by other transactions during execution. Read locks allow multiple transactions to read the same data simultaneously, while write locks monopolize the corresponding resources, preventing write conflicts from other transactions. Next, during parallel processing, the system checks the status of each transaction lock in the first group of M transactions to determine the specific status of the target transaction lock. The target transaction lock can be in the read lock, write lock, or a combination of the two. A read lock indicates that the transaction only needs to read data and does not involve data modification; a write lock indicates that the transaction will modify data. After the transaction lock status is determined, the system performs mutual exclusion checks on each target transaction lock to identify conflicts that may affect parallel execution. Mutual exclusion can be divided into the following situations: write-write conflict. When multiple transactions attempt to write to the same contract at the same time, the algorithm will detect a write-write conflict, which will lead to a resource exclusive conflict. To avoid deadlocks caused by write-write conflicts, the system will prioritize write locks or implement a rollback strategy to ensure that transactions are executed in sequence; read-write conflict. When one transaction holds a write lock and another transaction only holds a read lock, a read-write conflict will occur. The algorithm will prioritize write-lock transactions and make read-lock transactions wait to ensure data consistency.

[0080] Among them, when mutual exclusion is detected in the target transaction lock, the conflicting transactions are processed through the consistency concurrency control algorithm. Specifically, for the conflicting transactions in the first group of M transactions, the system reorders and executes them step by step according to their lock type and priority. After all transactions are executed in parallel, the system will perform a consistency check on the first execution result. In the above-mentioned locking and mutual exclusion processing mechanism, the algorithm also adopts a resource optimization strategy to prevent deadlock. By adopting a phased processing strategy of locking first and then unlocking, as well as rolling back high-index transaction lock resources, the possibility of deadlock is effectively reduced. In addition, the system also dynamically detects the availability of resources to reasonably allocate the parallel number of transactions and lock resources under high load, further improving the processing capacity and response speed of the target consensus node.

[0081] In a possible embodiment, determining whether the target transaction lock has a mutual exclusion phenomenon according to the state of the target transaction lock specifically includes:

[0082] 5331. Determine the target transaction corresponding to the target transaction lock;

[0083] S332. Lock the target transaction and the first transaction to obtain a locked target transaction and a locked first transaction; the first transaction is a transaction corresponding to any one of the M transaction locks.

[0084] S333. Perform mutual exclusion analysis on the target transaction in the locked state and the first transaction in the locked state to obtain a mutual exclusion analysis result.

[0085] S334. When the mutual exclusion analysis result meets the preset requirement, it is determined that the mutual exclusion phenomenon exists between the target transaction lock and the first transaction; the preset requirement is that there is at least one of the following conflicts between the target transaction lock and the first transaction: read-before-write conflict, write-before-read conflict, and write-write conflict.

[0086] Before determining mutual exclusion, the specific transaction corresponding to the target transaction lock, i.e., the target transaction, must be determined. After the target transaction is identified, the system performs lock operations on the target transaction and its potentially conflicting first transaction, respectively, to ensure that the transaction will not be interfered with by other concurrent transactions during the conflict detection process. The lock status settings include read locks and write locks, depending on the transaction operation type. The first transaction can be the transaction corresponding to any of the M transaction locks, and its lock status assignment must ensure that it matches the lock status of the target transaction to achieve accurate judgment during mutual exclusion detection. After the transaction lock is completed, the system performs a mutual exclusion analysis on the locked target transaction and the locked first transaction. The mutual exclusion analysis is based on checking the read and write status and order relationship of the transaction locks to determine whether there is a conflict in resource usage between the two transactions. Mutual exclusion analysis is typically performed based on the following three conflict types: A read-before-write conflict occurs when the target transaction lock is a read lock and the first transaction intends to write to the same resource. To ensure data consistency, the algorithm may prioritize completing the write transaction after detecting this conflict and allow the read-lock transaction to reacquire the resource. A write-before-read conflict occurs when the target transaction lock is a write lock, while the first transaction only has a read lock. This means that the write operation is performed on the transaction first to prevent subsequent read operations from reading incomplete transactions. When encountering a write-before-read conflict, the algorithm typically prioritizes the write-lock transaction to avoid data reading bias. A write-write conflict occurs when both the target transaction lock and the first transaction have write locks. At this time, the algorithm determines which transaction to execute first based on the order or priority of the transactions, and the other transaction must wait or roll back to ensure eventual consistency.

[0087] It can be seen that in the embodiment of the present application, accurate judgment and efficient processing of transaction conflicts are achieved, ensuring the integrity and consistency of data during parallel execution, while also improving the resource utilization efficiency and response speed of the multi-node system.

[0088] In a possible embodiment, executing the first group of M transactions in parallel on the conflicting transactions corresponding to the target transaction lock using the consistency concurrency control algorithm on the target consensus node to obtain the first execution result specifically includes:

[0089] A1. Obtain a first transaction index corresponding to the first transaction, where the first transaction index represents the serial number corresponding to the first transaction in the sequence numbering of the M transactions in the first block;

[0090] A2. Determine the lock-holding transactions corresponding to the target transaction. The lock-holding transactions include transactions holding write locks and transactions holding read locks. The write-locking transactions correspond to the write-locking transaction index, and the read-locking transactions correspond to the read-locking transaction index.

[0091] A3. If the conflict between the target transaction lock and the first transaction is a write-write conflict, compare the index of the transaction holding the write lock with the index of the first transaction.

[0092] A4. When the index of the transaction holding the write lock is greater than the index of the first transaction, roll back the transaction holding the write lock.

[0093] A5. When the index of the write-locked transaction is less than or equal to the index of the first transaction, wait for the write-locked transaction to complete, and execute the first group of M transactions in parallel on the target consensus node using the consistency concurrency control algorithm to obtain the first execution result.

[0094] A6. If the conflict between the target transaction lock and the first transaction is a write-before-read conflict, compare the index of the transaction holding the write lock with the index of the first transaction.

[0095] A7. If the index of the transaction holding the write lock is greater than the index of the first transaction, roll back the transaction holding the write lock and the transaction holding the previous write lock and having an index greater than the first transaction.

[0096] A8. When the index of the write-locked transaction is less than or equal to the index of the first transaction, wait for the write-locked transaction to complete, and execute the first group of M transactions in parallel on the target consensus node using the consistency concurrency control algorithm to obtain the first execution result.

[0097] A9. If the conflict between the target transaction lock and the first transaction is a read-before-write conflict, compare the index of the transaction holding the read lock with the index of the first transaction.

[0098] A10. When the index of the transaction holding the read lock is greater than the index of the first transaction, roll back the transaction holding the read lock.

[0099] A11. When the index of the transaction holding the read lock is less than or equal to the index of the first transaction, wait for the transaction holding the read lock to be completed, and execute the first group of M transactions in parallel on the first transaction through the consistency concurrency control algorithm on the target consensus node to obtain the first execution result.

[0100] Among them, when each transaction is executed, the execution of the transaction is divided into two stages: locking and unlocking. During the execution process, only locks are added and not released. After the execution is completed, all locks are released uniformly. In this way, deadlock can be avoided. Among them, the locking and rollback method of transaction execution can be used to ensure the consistency of the execution results of multiple consensus nodes (through the analysis and processing of different situations, it can be ensured that conflicts in the transaction execution process are handled in a predetermined order. Only in this way can the final execution results of the consensus nodes on different logical core machines be the same. Otherwise, the execution results of different nodes will be different, resulting in the inability of the consensus nodes to reach a consensus).

[0101] Among them, when a write-write conflict occurs, there is a transaction holding a write lock, and the conflicting transaction requests a write lock. At this time, the index of the conflicting transaction is compared with the index of the transaction holding a write lock. If the index of the transaction holding a write lock is greater than the index of the conflicting transaction, the transaction holding the write lock is rolled back. The transaction that has held a write lock in the past and whose index is larger than the conflicting transaction also needs to be rolled back. If the index of the write lock transaction is smaller than the index of the conflicting transaction, wait for the transaction holding the write lock to complete before executing the transaction. When a write-first-read-later conflict occurs, there is a transaction holding a write lock, and the conflicting transaction requests a read lock. At this time, the index of the conflicting transaction is compared with the index of the transaction holding a write lock. If the index of the transaction holding a write lock is greater than the index of the conflicting transaction, the transaction holding the write lock is rolled back. The transaction that has held a write lock in the past and whose index is larger than the conflicting transaction also needs to be rolled back. If the write lock If the transaction index is smaller than the conflicting transaction index, the transaction will be executed after waiting for the transaction holding the write lock to complete. If the write lock index is equal to the conflicting transaction index, it will be accessed directly. When a read-before-write conflict occurs, some transactions hold read locks, and the conflicting transaction requests a write lock. At this time, the index of the write lock transaction is compared with the index of the transaction holding the read lock. The read lock transaction with a larger index than the write lock index needs to be rolled back. Transactions that have held read locks in the past and whose index is larger than the write lock also need to be rolled back. At this time, the index of the transaction holding the read lock is less than or equal to the index of the reread transaction. For the case where the read lock is held and the index is smaller than the conflicting transaction index, the conflicting transaction needs to wait for the transaction holding the read lock to complete. After the transaction with an index smaller than the conflicting transaction index is completed, the conflicting transaction obtains the write lock and completes the transaction execution.

[0102] To more clearly illustrate how the consistency control algorithm rolls back and waits for conflicting transactions, let's take an example to illustrate: for example, there are four transactions executing, and there are many possible situations. This example selects one possible situation to illustrate. Transactions 1, 2, 3, and 4 are executed in parallel, and the timing is exactly 1, 2, 4, and 3. Then: transaction 1 attempts to obtain the read lock of key1 and the write lock of key3. At this time, no other transaction holds the lock. Transaction 1 obtains the read lock of key1 and the write lock of key3 and continues to execute; transaction 2 attempts to obtain the read lock of key2 and the write lock of key5. At this time, no other transaction holds the lock. Transaction 2 obtains the read lock of key2 and the write lock of key5 and continues to execute; transaction 4 attempts to obtain the write lock of key2 and the write lock of key1. At this time, transaction 2 holds the read lock of key2. Transaction 4 continues to wait for transaction 2 to complete, obtains the write lock of key2, and tries to obtain the write lock of key1. At this time, transaction 1 holds k ey1's read lock, transaction 4 waits for transaction 1 to complete; transaction 3 attempts to obtain the write lock of key1 and key2. At this time, transaction 1 holds the read lock of key1, resulting in a conflict. For key1, transaction 3's Index = 3 is greater than the Index = 1 of transaction 1 holding the read lock. Therefore, transaction 3 waits for transaction 1 to complete. After transaction 1 completes, transaction 3 obtains the write lock of key1 and attempts to obtain the write lock of key2. At this time, transaction 2 holds the read lock of key2. Transaction 3 continues to wait for transaction 2 to complete and obtain the write lock of key2. After transactions 1 and 2 are completed, transaction 3 obtains the write lock of key1 and transaction 4 obtains the write lock of key2. Transaction 3 attempts to obtain the write lock of key2 and finds that transaction 4 holds the write lock of key2. Transaction 3's Index = 3 is less than the Index = 4 of transaction 4. At this time, transaction 4 is rolled back, and transaction 3 obtains the write lock of key2 and completes execution.

[0103] Among them, see Figure 2 , Figure 2 It is a flowchart of the execution of the consistency and concurrency control algorithm, such as Figure 2First, based on the target consensus node's core count (M), transactions numbered 1-M are sequentially retrieved from t transactions and executed. If the number of retrieved transactions is 0, the block is executed. If the number of retrieved transactions is greater than or equal to 1, execution proceeds according to the rule-based consistency parallel control algorithm. Key-value pairs for read and write operations must be locked before reading or writing. Locks are divided into read locks and write locks. The lock records the transaction index (this index can be understood as the sequential number of the transaction in the block). Read locks and read locks are not mutually exclusive, while write-write and read-write are mutually exclusive. Mutually exclusive locks cannot exist simultaneously (if the lock is not first acquired, the final result of key contention is uncertain). Next, write-write conflicts, write-then-read conflicts, and write-then-read conflicts are rolled back or waited for execution to avoid conflicts in contract calls and enable parallel execution of transactions. The above execution operation is then repeated for the remaining transactions until p conflicting transactions are executed. Finally, the results of the consistency and concurrency control algorithm are filled into the block header, and consensus analysis is performed through all consensus nodes to verify the consistency of the execution results.

[0104] As can be seen, in the embodiments of this application, locking and unlocking are divided into two phases during each transaction execution. During the execution process, only locks are locked and not released. All locks are released uniformly after the execution is completed, thereby effectively avoiding the occurrence of deadlock. Through the locking and rollback strategy, it is possible to ensure that the execution results of each consensus node are consistent in various conflict scenarios. That is, the execution order of different nodes can still be consistent, ensuring the reliability and effectiveness of consistency control.

[0105] Step S160: Fill the first block with the first execution result based on the consensus algorithm to obtain a target first block, and broadcast the target first block to the f-1 consensus nodes; after any consensus node among the f-1 consensus nodes receives the target first block, execute the transaction in parallel on the consensus node through the consistency concurrency control algorithm to obtain a second execution result.

[0106] First, the consensus algorithm is used to process the first execution result. Specifically, the consensus algorithm analyzes the transaction execution results obtained after the consistency and concurrency control algorithm is processed, and integrates these results into the block header, so that some bytes in the previously generated block are filled with values. This target first block not only contains the core data of the execution result, but also includes relevant information about the transaction, such as the transaction hash value, initiator and recipient information, and timestamp, etc., to facilitate subsequent integrity verification and traceability. After the target first block is filled, the system will broadcast the first block to f-1 consensus nodes on the alliance chain other than its own node through the network protocol. This broadcast process ensures that each consensus node can receive the information of the new block in real time and perform corresponding processing.

[0107] When any consensus node receives the target first block, it will use the consistent concurrency control algorithm to process the transactions contained therein in parallel. This algorithm is designed to improve the efficiency of concurrent processing while ensuring transaction execution consistency. The results of the parallel execution of the consistent concurrency control algorithm will form a second execution result, which will be used in the further consensus process to ensure that transactions across the entire alliance chain can be processed efficiently and accurately.

[0108] Step S170: collect the second execution results corresponding to the f-1 consensus nodes to obtain f-1 second execution results, and package the f-1 second execution results to obtain a first execution result message package.

[0109] The second execution result is the result of the consensus node processing conflicting transactions in the block using a consistent parallel control algorithm. First, the target consortium chain collects the corresponding second execution results from each consensus node through the network protocol. Each consensus node generates an execution result based on the same set of transactions during parallel execution. In theory, these results should be identical. If there are discrepancies, the system uses a consistency check mechanism to verify that the execution results of all nodes comply with the pre-set business logic and technical standards. Next, the target consortium chain formats the collected f-1 second execution results for subsequent processing. This formatting process may include organizing relevant data for each result (such as node ID, timestamp, and execution status) into a unified data structure. The target consortium chain then packages these organized second execution results into a first execution result message packet. During this packaging process, the system aggregates all valid execution results and attaches a corresponding hash value to ensure data integrity and security during transmission. This hash value not only verifies the integrity of the message packet but also provides a fast verification method for subsequent consensus processes. Finally, when the first execution result message package is generated, the target consensus node will broadcast it to other consensus nodes in the target alliance chain so that other nodes can verify and make decisions. The broadcast mechanism ensures that all consensus nodes can obtain the execution result information in a timely manner and participate in the subsequent consensus process. At the same time, it also improves the transparency of the system, allowing all participants to clearly understand the status and results of transaction execution, thereby enhancing trust in the overall security of the alliance chain.

[0110] Step S180: Detecting whether the first execution result message packet meets a first preset condition through the consensus algorithm.

[0111] The first precondition includes, but is not limited to, the number of collected execution result message packets reaching a required threshold. For example, in the PBFT consensus algorithm, a node must collect execution result message packets from at least 2f nodes other than its own. Furthermore, the execution results in the execution result message packets must be consistent with the current node's own execution results to ensure the validity and consistency of the block. The consensus algorithm detection process involves verifying received message packets, including checking transaction hashes, block header information, and signatures, to ensure that each message packet originates from a legitimate consensus node and that the data has not been tampered with.

[0112] In a possible embodiment, when the first execution result message package satisfies the first preset condition, the method further includes: obtaining a transaction root, a receipt root, and a status root in the first execution result message; determining whether a third preset condition is satisfied between the first execution result and the f-1 second execution results; when the third preset condition is satisfied between the first execution result and the f-1 second execution results, filling the transaction root, the receipt root, and the status root into the first block through the consensus algorithm to obtain the filled first block; and updating the status root in the filled first block to obtain the target first block.

[0113] When the first execution result message packet meets the first preset condition, the transaction root, receipt root, and status root in the first execution result message are first retrieved to ensure the integrity and traceability of the block. The transaction root, receipt root, and status root are important components of the block header and are typically represented using a Merkle tree to ensure the integrity and consistency of the data in the block. Simply put, the transaction root is used to verify the integrity of transactions in the block, the receipt root is used to verify the integrity of transaction receipts, and the status root is used to verify changes in account status after executing transactions in the block. A block contains many transactions, each of which generates a hash value. All hash values ​​are calculated using a Merkle tree method, ultimately resulting in a unique root hash value, the transaction root. The receipt root is a summary of the hash values ​​of all transaction receipts. After each transaction is completed, a corresponding transaction receipt is generated. The receipt root is the transaction receipt hash value calculated using the Merkle tree. The state root is a summary of the hash values ​​of all account states in the block. The state of each account (such as balance, storage, etc.) will be updated after the blockchain executes the transaction. The state root is the account state hash value calculated by the Merkle tree.

[0114] Next, the transaction roots, receipt roots, and status roots of these execution results are compared to verify their consistency. The second execution result is the execution result obtained by other consensus nodes through the same parallel processing. When the first execution result and the f-1 second execution results meet the third preset condition, the execution results of each node are consistent. At this point, the transaction root, receipt root, and status root are added to the first block using the consensus algorithm to form the filled first block. The third preset condition is that the execution results submitted by all consensus nodes must have the same transaction root, receipt root, and status root, thereby ensuring that the operation results of each node remain consistent during the block generation and execution process.

[0115] Finally, the state root in the populated first block is updated to reflect the latest state of the current block, resulting in the target first block. This update process ensures that the blockchain state accurately reflects the execution status and results of all transactions, thereby maintaining the stability and consistency of the entire consortium chain system.

[0116] As can be seen, in this embodiment of the present application, by implementing the steps to obtain the transaction root, receipt root, and status root when the first execution result message packet meets the first preset condition, the integrity and consistency of transactions within the block can be effectively ensured. Subsequently, a determination is made as to whether the first execution result and the f-1 second execution results meet the third preset condition. Through this verification process, it is ensured that all participating consensus nodes obtain consistent results when executing transactions. After the third preset condition is met, the transaction root, receipt root, and status root are populated into the first block through the consensus algorithm. The status root of the populated block is updated, ultimately obtaining the target first block, ensuring that the blockchain state reflects the latest transaction execution status.

[0117] In a possible embodiment, each of the t transactions corresponds to a piece of transaction access information, and the method further includes: when the transaction conflict rate is less than or equal to the preset threshold, obtaining first transaction access information, the first transaction access information being the transaction access information of any one of the t transactions; determining a corresponding transaction access key-value pair based on the first access information to obtain a first transaction key-value pair; judging whether the first transaction can be processed in parallel based on the first transaction key-value pair and the first transaction access information; when the first transaction can be processed in parallel, obtaining conflict domain information of the t transactions; determining conflict information corresponding to the first transaction access information based on the conflict domain information; determining a first directed acyclic graph of transaction execution based on the t transactions; constructing a dependency edge in the first directed acyclic graph based on the conflict information to obtain a second directed acyclic graph; executing the t transactions based on the second directed acyclic graph to obtain The third execution result; based on the consensus algorithm, the first block is filled with the third execution result to obtain the target second block, and the target second block is broadcast to the f-1 consensus nodes; after any consensus node among the f-1 consensus nodes receives the target second block, the t transactions are executed in parallel on the consensus node through the second directed acyclic graph to obtain a fourth execution result; the fourth execution results corresponding to the f-1 consensus nodes are collected to obtain f-1 fourth execution results, and the f-1 fourth execution results are packaged to obtain a second execution result message packet; the second execution result message packet is detected by the consensus algorithm to determine whether it meets the second preset condition; when the second execution result message packet meets the second preset condition, the target second block is submitted to the target alliance chain; when the second execution result message packet does not meet the second preset condition, the target second block is discarded.

[0118] When each consensus node executes a transaction, it first parses the transaction parameters. Based on the called contract, method, parameters, and read-write access information pre-registered on the chain, it analyzes the list of contract data that each transaction will access. Combined with the order of transactions in the block, it constructs a directed acyclic graph (DAG). This DAG constructed based on transaction calls can be used to parallelize transactions within the block. Because the information used to construct the DAG is consistent across all consensus nodes, and the DAG construction algorithm is the same across all nodes, the DAGs constructed by different consensus nodes are identical.

[0119] Among them, see Figure 3 , Figure 3 It is a flow chart constructed from a directed acyclic graph, such as Figure 3As shown in the figure, first, the transaction parameters are parsed to identify the contract called by each transaction and its corresponding methods and parameters. Based on this information and combined with the pre-registered read and write access information, a list of access data for each transaction is constructed. Then, after obtaining the access information of t transactions, the dependencies of each transaction are analyzed one by one according to the order of transactions in the block to ensure that the order between transactions does not cause conflicts. This is to determine which transactions can be executed in parallel and which transactions need to be processed serially. By organizing the access keys of the transactions into nodes and adding directed edges to the graph based on the dependencies between transactions, the execution order from one transaction to another is represented. This construction process ensures that transactions can only be executed in parallel when there are no conflicts, thereby optimizing the efficiency of transaction processing.

[0120] Furthermore, by constructing a directed acyclic graph (DAG) for transaction execution to process transactions in parallel within a block, the system's processing efficiency can be significantly improved by analyzing the dependencies between transactions. Specifically, using the DAG, consensus nodes can identify which transactions can be executed simultaneously, thereby optimizing resource utilization. Each node in the DAG represents a transaction, while directed edges indicate the order of transactions. Through this structure, consensus nodes can ensure that transactions can be executed in parallel without violating transaction dependencies.

[0121] Based on the constructed directed acyclic graph, consensus nodes execute t transactions in parallel, obtaining a third execution result. Then, using the consensus algorithm, the consensus nodes use the execution results to populate the block header with information, forming the target second block and broadcasting it to all f-1 consensus nodes. Upon receiving the target second block, any consensus node executes t transactions in parallel through the second directed acyclic graph to obtain the execution result. Each consensus node then collects its own execution results and packages them into a result message packet. Finally, consensus nodes verify the validity of the block using the consensus algorithm and submit it to the target consortium chain. Blocks that do not meet the consensus algorithm's validity criteria are discarded. During execution, consensus nodes can process transactions in parallel within the same directed acyclic graph, leveraging the advantages of multi-core processors to accelerate transaction processing. Furthermore, leveraging the parallel processing mechanism of the directed acyclic graph, the system can dynamically adjust the execution order and strategy of transactions. When the conflict rate for certain transactions is low, the system will select parallel processing. However, when the conflict rate increases, it may automatically switch to serial execution mode to ensure transaction consistency and correctness. This flexible processing method enables the consortium chain to operate efficiently and stably when faced with changing transaction requests.

[0122] As can be seen, in this embodiment of the application, by processing transactions in parallel on a directed acyclic graph, not only does it improve overall system performance, but it also provides users with a faster transaction confirmation experience. This mechanism not only improves transaction efficiency but also ensures consistency in execution results across consensus nodes, further enhancing the reliability and usability of the consortium chain.

[0123] Step S190: When the first execution result message packet meets the first preset condition, the target first block is submitted to the target alliance chain; when the first execution result message packet does not meet the first preset condition, the target first block is discarded.

[0124] When the first execution result message packet meets the first pre-set condition, the process of submitting the target first block to the target consortium chain includes broadcasting the verified block information to all participating consensus nodes, ensuring that each node synchronously updates its local blockchain state. Furthermore, the submitted block is marked as valid, allowing subsequent transactions to be processed and executed based on it, thereby ensuring the efficiency and consistency of the entire consortium chain. Conversely, if the first execution result message packet does not meet the first pre-set condition, the target first block is discarded, ensuring the integrity and security of the blockchain. This mechanism prevents any potential errors or inconsistencies from being introduced into the chain, preventing data contamination and subsequent operational confusion. This strategy strengthens the consensus nodes' strict review of block validity, ensuring that blocks are officially accepted and added to the consortium chain only when all verification conditions are met, thereby maintaining the stability and reliability of the entire system.

[0125] See also Figure 4 , Figure 4 It is a flowchart of the scheduling algorithm executed in the transaction conflict scenario on the alliance chain, such as Figure 4As shown in the example, the leading consensus node constructs a block from transactions in the transaction pool and broadcasts it to other consensus nodes. Upon receiving a new block, a consensus node verifies its validity to ensure it meets the consensus algorithm's requirements. Next, it retrieves the corresponding transactions from its respective transaction pools one by one, following the order in which they occurred. If a transaction is missing from the transaction pool, it can retrieve it from other consensus nodes via the network. Before preparing for transaction execution, the consensus node analyzes all key-value pairs that may be accessed during transaction execution based on the static analysis results provided during deployment. Subsequently, based on the conflict rate between transactions, the consensus node determines whether to use a consistent concurrency control algorithm or a directed acyclic graph parallel algorithm. Finally, the consensus node signs the block header according to the consensus algorithm's workflow and broadcasts the signed message packet to other consensus nodes. Within a set timeout, each consensus node collects the execution result message packets from other nodes to ensure that the execution results contained in these packets are consistent with its own. For example, under the PBFT algorithm, a consensus node needs to collect message packets from 2f nodes other than itself and verify their consistency (if the total number of nodes is 4, then f = 1). Once the conditions are met, it can enter the subsequent consensus process and finally complete the block submission. Otherwise, the block is discarded and the consensus state is restarted, thereby re-executing the block generation process.

[0126] It can be seen that through the above method flow, based on the transaction conflict rate and the preset threshold, the directed acyclic graph parallel processing or the consistent concurrency control algorithm parallel processing can be adaptively selected to obtain better execution scheduling performance. Especially in scenarios with a high transaction conflict rate, a higher degree of concurrency can be obtained, and concurrency control during transaction execution is realized, thereby preventing transactions from conflicting on the same resource and improving the performance of the concurrency control algorithm.

[0127] The following combination Figure 5 The electronic device in the embodiment of the present application is described. Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application is shown in FIG. Figure 5 As shown, the electronic device 500 includes a processor 510, a memory 520, a communication interface 530, and one or more programs 521. The processor 510 is communicatively connected to the memory 520 and the communication interface 530 via an internal communication bus. The one or more programs 521 are stored in the memory 520 and are configured to be executed by the processor 510. The one or more programs include instructions for executing any step in the above method embodiment.

[0128] The processor 510 may be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, units, and circuits described in conjunction with the disclosure of this application. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like. The communication unit may be a communication interface, a transceiver, a transceiver circuit, and the like, and the storage unit may be a memory.

[0129] The memory 520 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0130] Among them, the electronic device 500 may include smart phones (such as Android phones, iOS phones, Windows Phone phones, etc.), tablet computers, PDAs, driving recorders, vehicle-mounted electronic devices, servers, laptops, mobile Internet electronic devices (MID, Mobile Internet Devices) or wearable electronic devices (such as smart watches, Bluetooth headsets), etc. The above are only examples and not exhaustive, including but not limited to the above electronic devices.

[0131] It is understandable that the electronic device may include more or fewer structural elements than those in the above structural block diagram, for example, a power module, physical buttons, Wi-Fi module, speaker, Bluetooth module, sensor, display module, etc., which are not limited here.

[0132] The above mainly introduces the scheme of the embodiment of the present application from the perspective of the execution process of the method side. In order to realize the above functions, the electronic device includes a hardware structure and / or software module corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiment provided in this article, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software driven hardware manner depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0133] The embodiment of the present application can divide the functional units of the electronic device according to the above method example. For example, each functional unit can be divided according to each function, or two or more functions can be integrated into one processing unit. The above integrated unit can be implemented in the form of hardware or in the form of software functional units. It should be noted that the division of units in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0134] In the case of dividing each functional module into corresponding functional modules, Figure 6 This is a block diagram of the functional modules of a parallel control device based on alliance chain transaction conflicts provided in an embodiment of the present application. The parallel control device 600 based on alliance chain transaction conflicts includes:

[0135] An acquisition module 610 is configured to acquire t transactions of a target consensus node on a target consortium chain, where the target consortium chain includes f consensus nodes, where t and f are both integers greater than 1; and the target consensus node is any consensus node among the f consensus nodes.

[0136] Determination module 620 is configured to package the t transactions using a consensus algorithm to obtain a first block, and broadcast the first block to f-1 consensus nodes among the f consensus nodes excluding the target consensus node; perform static analysis on the first block to obtain a static analysis result; and calculate a conflict rate for the transactions based on the static analysis result to obtain a transaction conflict rate;

[0137] A judgment module 630 is configured to execute the t transactions in parallel on the target consensus node using a consistency concurrency control algorithm to obtain a first execution result when the transaction conflict rate is greater than a preset threshold;

[0138] a control module 640 configured to fill the first block with the first execution result based on the consensus algorithm to obtain a target first block, and broadcast the target first block to the f-1 consensus nodes; after any consensus node among the f-1 consensus nodes receives the target first block, execute the transaction in parallel on the consensus node using the consistency concurrency control algorithm to obtain a second execution result;

[0139] The acquisition module 610 is further configured to collect the second execution results corresponding to the f-1 consensus nodes, obtain f-1 second execution results, and package the f-1 second execution results to obtain a first execution result message packet;

[0140] The judgment module 630 is further configured to detect whether the first execution result message packet meets a first preset condition through the consensus algorithm;

[0141] The control module 640 is also used to submit the target first block to the target alliance chain when the first execution result message packet meets the first preset condition; and discard the target first block when the first execution result message packet does not meet the first preset condition.

[0142] In a possible embodiment, the determination module 620, in calculating the conflict rate of the transaction based on the static analysis result to obtain the transaction conflict rate, is specifically configured to:

[0143] Determine, based on the static analysis result, the number p of transactions that cannot be run in parallel among the t transactions; p is an integer greater than 1 and less than or equal to t;

[0144] The transaction conflict rate is determined according to the t transactions and the number p of non-parallelizable transactions.

[0145] In a possible embodiment, the judgment module 630 executes the t transactions in parallel on the target consensus node using a consistency concurrency control algorithm to obtain a first execution result, specifically for:

[0146] Obtain the number of logical cores M of the target consensus node, where M is an integer greater than 1; the number of logical cores M indicates that the target consensus node can process M tasks in parallel at the same time;

[0147] Sequentially select transactions 1 to M in the first block to obtain a first group of M transactions;

[0148] The first group of M transactions is executed in parallel on the target consensus node using the consistency concurrency control algorithm to obtain the first execution result.

[0149] In a possible embodiment, the control module 640 executes the first group of M transactions in parallel on the target consensus node using the consistency concurrency control algorithm to obtain the first execution result, specifically for:

[0150] Determine the read-write key-value pairs of the first group of M transactions, and lock the read-write keys to obtain M transaction locks;

[0151] Determine a state of a target transaction lock, where the state of the target transaction lock includes a read lock and / or a write lock, and the target transaction lock is any one of the M transaction locks;

[0152] Determine whether the target transaction lock has a mutual exclusion phenomenon according to the state of the target transaction lock;

[0153] When mutual exclusion exists in the target transaction lock, the first group of M transactions is executed in parallel on the conflicting transactions corresponding to the target transaction lock on the target consensus node through the consistency concurrency control algorithm to obtain the first execution result.

[0154] In a possible embodiment, in determining whether the target transaction lock has a mutual exclusion phenomenon according to the state of the target transaction lock, the determination module 630 is further configured to:

[0155] Determining a target transaction corresponding to the target transaction lock;

[0156] The target transaction and the first transaction are locked to obtain a locked target transaction and a locked first transaction; the first transaction is a transaction corresponding to any one of the M transaction locks;

[0157] Performing a mutual exclusion analysis on the target transaction in the locked state and the first transaction in the locked state to obtain a mutual exclusion analysis result;

[0158] When the mutual exclusion analysis result meets a preset requirement, it is determined that the mutual exclusion phenomenon exists between the target transaction lock and the first transaction; the preset requirement is that there is at least one of the following conflicts between the target transaction lock and the first transaction: a read-before-write conflict, a write-before-read conflict, and a write-write conflict.

[0159] In a possible embodiment, the control module 640 executes the first group of M transactions in parallel on the conflicting transactions corresponding to the target transaction lock using the consistency concurrency control algorithm on the target consensus node to obtain the first execution result, specifically for:

[0160] Obtaining a first transaction index corresponding to the first transaction, where the first transaction index represents the number corresponding to the first transaction in the sequential numbers of the M transactions in the first block;

[0161] Determine the lock-holding transaction corresponding to the target transaction, where the lock-holding transaction includes a transaction holding a write lock and a transaction holding a read lock; the write-lock-holding transaction corresponds to the write-lock-holding transaction index, and the read-lock-holding transaction corresponds to the read-lock-holding transaction index;

[0162] If the conflict between the target transaction lock and the first transaction is the write-write conflict, compare the index of the transaction holding the write lock with the index of the first transaction;

[0163] When the index of the transaction holding the write lock is greater than the index of the first transaction, the transaction holding the write lock is rolled back;

[0164] When the index of the write-locked transaction is less than or equal to the index of the first transaction, wait for the write-locked transaction to be completed, and execute the first group of M transactions in parallel on the target consensus node using the consistency concurrency control algorithm for the first transaction to obtain the first execution result;

[0165] If the conflict between the target transaction lock and the first transaction is a write-before-read conflict, compare the index of the transaction holding the write lock with the index of the first transaction;

[0166] When the index of the transaction holding the write lock is greater than the index of the first transaction, the transaction holding the write lock and the transaction holding the write lock and having an index greater than the first transaction are rolled back;

[0167] When the index of the write-locked transaction is less than or equal to the index of the first transaction, wait for the write-locked transaction to be completed, and execute the first group of M transactions in parallel on the target consensus node using the consistency concurrency control algorithm for the first transaction to obtain the first execution result;

[0168] If the conflict between the target transaction lock and the first transaction is a read-before-write conflict, compare the index of the transaction holding the read lock with the index of the first transaction;

[0169] When the index of the transaction holding the read lock is greater than the index of the first transaction, rolling back the transaction holding the read lock;

[0170] When the index of the transaction holding the read lock is less than or equal to the index of the first transaction, wait for the transaction holding the read lock to be completed, and execute the first group of M transactions in parallel on the first transaction through the consistency concurrency control algorithm on the target consensus node to obtain the first execution result.

[0171] In a possible embodiment, the control module 640 corresponds to one transaction access information for each of the t transactions. The method is further configured to:

[0172] When the transaction conflict rate is less than or equal to the preset threshold, obtaining first transaction access information, where the first transaction access information is transaction access information of any one of the t transactions;

[0173] determining a corresponding transaction access key-value pair based on the first access information to obtain a first transaction key-value pair;

[0174] determining whether the first transaction can be processed in parallel according to the first transaction key-value pair and the first transaction access information;

[0175] When the first transaction can be processed in parallel, obtaining conflict domain information of the t transactions;

[0176] determining conflict information corresponding to the first transaction access information according to the conflict domain information;

[0177] Determining a first directed acyclic graph of transaction execution based on the t transactions;

[0178] Constructing dependency edges in the first directed acyclic graph according to the conflict information to obtain a second directed acyclic graph;

[0179] executing the t transactions based on the second directed acyclic graph to obtain a third execution result;

[0180] Filling the first block with the third execution result based on the consensus algorithm to obtain a target second block, and broadcasting the target second block to the f-1 consensus nodes; after any consensus node among the f-1 consensus nodes receives the target second block, executing the t transactions in parallel on the consensus node through the second directed acyclic graph to obtain a fourth execution result;

[0181] Collect the fourth execution results corresponding to the f-1 consensus nodes to obtain f-1 fourth execution results, and package the f-1 fourth execution results to obtain a second execution result message package;

[0182] Detecting whether the second execution result message packet meets a second preset condition by the consensus algorithm;

[0183] When the second execution result message packet meets the second preset condition, the target second block is submitted to the target alliance chain; when the second execution result message packet does not meet the second preset condition, the target second block is discarded.

[0184] In a possible embodiment, when the first execution result message packet satisfies the first preset condition, the determining module 620 is further configured to:

[0185] Obtaining the transaction root, receipt root, and status root in the first execution result message;

[0186] Determining whether the first execution result and the f-1 second execution results satisfy a third preset condition;

[0187] When the first execution result and the f-1 second execution results satisfy the third preset condition, filling the transaction root, the receipt root, and the status root into the first block using the consensus algorithm to obtain the filled first block;

[0188] The state root in the filled first block is updated to obtain the target first block.

[0189] It is worth noting that the specific functional implementation of the parallel control device 600 based on the alliance chain transaction conflict can be found in the above Figure 1The description of the parallel control method based on alliance chain transaction conflicts shown in the figure, for example, the acquisition module 610 is used to implement the relevant content of executing S110 and S170, and the control module 640 is used to implement the relevant content of executing S160. The various units or modules in the parallel control device 600 based on alliance chain transaction conflicts can be merged into one or several other units or modules separately or in full, or some (some) of the units or modules can be further divided into multiple functionally smaller units or modules to form a structure, which can achieve the same operation without affecting the realization of the technical effects of the embodiments of the present invention. The above-mentioned units or modules are divided based on logical functions. In actual applications, the functions of one unit (or module) are implemented by multiple units (or modules), or the functions of multiple units (or modules) are implemented by one unit (or module).

[0190] It can be seen that the parallel control device based on alliance chain transaction conflicts described in the embodiment of the present application first obtains t transactions of the target consensus node on the target alliance chain, where the target alliance chain includes f consensus nodes, and t and f are both integers greater than 1; then, the t transactions are packaged through a consensus algorithm to obtain a first block, and the first block is broadcast to f-1 consensus nodes among the f consensus nodes except the target consensus node; static analysis is performed on the first block to obtain a static analysis result; based on the static analysis result, a conflict rate is calculated for the transaction to obtain a transaction conflict rate; when the transaction conflict rate is greater than a preset threshold, the t transactions are executed in parallel on the target consensus node through a consistency concurrency control algorithm to obtain a first execution result; based on the consensus algorithm, the first execution result is used to fill in the first block. The algorithm performs a block-based transaction, obtains a target first block, and broadcasts the target first block to the f-1 consensus nodes. After any consensus node among the f-1 consensus nodes receives the target first block, the consensus node executes the transaction in parallel using the consistency concurrency control algorithm to obtain a second execution result. The second execution results corresponding to the f-1 consensus nodes are collected to obtain f-1 second execution results, and the f-1 second execution results are packaged to obtain a first execution result message packet. The consensus algorithm is used to detect whether the first execution result message packet meets a first preset condition. If the first execution result message packet meets the first preset condition, the target first block is submitted to the target consortium chain. If the first execution result message packet does not meet the first preset condition, the target first block is discarded. This improves the performance of the concurrency control algorithm in scenarios where transactions conflict with the same resource.

[0191] It should be noted that the specific implementation of each operation can adopt the corresponding description of the method embodiment shown above. The parallel control device 600 based on alliance chain transaction conflicts can be used to execute the above method embodiment of this application, which will not be repeated here.

[0192] An embodiment of the present application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program for electronic data exchange, and the computer program enables a computer to execute part or all of the steps of any method described in the above method embodiments, and the above computer includes an electronic device.

[0193] The present application also provides a computer program product comprising a non-transitory computer-readable storage medium storing a computer program, wherein the computer program is operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may comprise an electronic device.

[0194] It should be noted that, for the above-mentioned various embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations. Those skilled in the art should know that this application is not limited by the order of the actions described, because some steps in the embodiments of the present application can be performed in other orders or simultaneously. In addition, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions, steps, modules or units involved are not necessarily required by the embodiments of the present application.

[0195] In the above embodiments, the embodiments of the present application have different focuses on the description of each embodiment. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0196] Those skilled in the art will appreciate that all or part of the process steps in the above-described method embodiments can be implemented by a computer program instructing the relevant hardware. The program can be stored in a computer-readable storage medium, and when executed, the program can include the process steps in the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0197] The steps of the method or algorithm described in the embodiments of the present application can be implemented in hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and storage medium can be located in an ASIC. In addition, the ASIC can be located in a terminal device or a management device. Of course, the processor and storage medium can also be present in a terminal device or a management device as discrete components.

[0198] Those skilled in the art will appreciate that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, they can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital video disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0199] The modules / units included in the devices and products described in the above embodiments may be software modules / units, hardware modules / units, or partly software modules / units and partly hardware modules / units. For example, for the devices and products applied to or integrated in the chip, the modules / units included therein may all be implemented in the form of hardware such as circuits, or at least part of the modules / units may be implemented in the form of software programs, which run on the processor integrated inside the chip, and the remaining (if any) modules / units may be implemented in the form of hardware such as circuits; for the devices and products applied to or integrated in the chip module, the modules / units included therein may all be implemented in the form of hardware such as circuits, and different modules / units may be located in the same component (such as chip, circuit module, etc.) or different components of the chip module, or at least part of the modules / units may be It is implemented in the form of a software program, which runs on the processor integrated inside the chip module, and the remaining (if any) modules / units can be implemented in the form of hardware such as circuits; for various devices and products applied to or integrated in the terminal equipment, the various modules / units contained therein can be implemented in the form of hardware such as circuits, and different modules / units can be located in the same component (for example, chip, circuit module, etc.) or different components in the terminal equipment, or, at least some modules / units can be implemented in the form of a software program, which runs on the processor integrated inside the terminal equipment, and the remaining (if any) modules / units can be implemented in the form of hardware such as circuits.

[0200] The specific implementation methods described above further illustrate the purpose, technical solutions and beneficial effects of the embodiments of the present application. It should be understood that the above description is only a specific implementation method of the embodiments of the present application and is not intended to limit the scope of protection of the embodiments of the present application. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the embodiments of the present application should be included in the scope of protection of the embodiments of the present application.

Claims

1. A parallel control method based on alliance chain transaction conflicts, characterized in that: The method comprises: Obtain t transactions of a target consensus node on a target consortium chain, where the target consortium chain includes f consensus nodes, where t and f are both integers greater than 1; the target consensus node is any consensus node among the f consensus nodes; Packing the t transactions through a consensus algorithm to obtain a first block, and broadcasting the first block to f-1 consensus nodes among the f consensus nodes excluding the target consensus node; Performing static analysis on the first block to obtain a static analysis result; Calculating the transaction conflict rate based on the static analysis result to obtain a transaction conflict rate; When the transaction conflict rate is greater than a preset threshold, the t transactions are executed in parallel on the target consensus node through a consistency concurrency control algorithm to obtain a first execution result; wherein, the consistency concurrency control algorithm includes: when each transaction is executed, obtaining the transaction lock corresponding to each transaction in the t transactions; during the transaction processing process, releasing all locks after the execution is completed to avoid deadlock problems during the execution process; if there are conflicting transactions in the first group of m transactions; the conflicting transactions include: write-write conflicts, write-first-then-read conflicts, or read-first-then-write conflicts in operations on the same resource; the priority of the conflicting transactions is determined by the index, and transactions with smaller indexes are processed first, while other transactions in the conflict are rolled back or wait for operations. During the transaction execution process, if a rollback due to a conflict is detected, the rolled-back transaction will be reallocated to the next batch of transactions for re-execution. The rolled-back transaction will be re-locked according to the latest resource status when it is re-executed to ensure that the re-executed transaction no longer conflicts with other transactions. After all transactions are completed, all the consensus nodes on the alliance chain will perform a consistency check on the first execution result. The target consensus node will compare the execution results and data status of each transaction to ensure that the execution results obtained by each transaction on different nodes are consistent. If the results are inconsistent, the system will trigger a retry mechanism to re-execute the transaction with the execution deviation until the execution results of all nodes are completely consistent, and finally achieve consensus in the network. Filling the first block with the first execution result based on the consensus algorithm to obtain a target first block, and broadcasting the target first block to the f-1 consensus nodes; after any consensus node among the f-1 consensus nodes receives the target first block, executing the transaction in parallel on the consensus node using the consistency concurrency control algorithm to obtain a second execution result; Collect the second execution results corresponding to the f-1 consensus nodes to obtain f-1 second execution results, and package the f-1 second execution results to obtain a first execution result message package; detecting, by the consensus algorithm, whether the first execution result message packet satisfies a first preset condition; the first preset condition being that the number of the first execution result message packets is less than or equal to a preset first threshold, and that each execution result in the first execution result message packet is consistent with the second execution result; When the first execution result message packet meets the first preset condition, the target first block is submitted to the target alliance chain; when the first execution result message packet does not meet the first preset condition, the target first block is discarded.

2. The method according to claim 1, wherein Calculating the transaction conflict rate based on the static analysis result to obtain the transaction conflict rate includes: Determine, based on the static analysis result, the number p of transactions that cannot be run in parallel among the t transactions; p is an integer greater than 1 and less than or equal to t; The transaction conflict rate is determined according to the t transactions and the number p of non-parallelizable transactions.

3. The method according to claim 1 or 2, wherein: The t transactions are executed in parallel on the target consensus node using a consistency concurrency control algorithm to obtain a first execution result, including: Obtain the number of logical cores M of the target consensus node, where M is an integer greater than 1; the number of logical cores M indicates that the target consensus node can process M tasks in parallel at the same time; Sequentially select transactions 1 to M in the first block to obtain a first group of M transactions; The first group of M transactions is executed in parallel on the target consensus node using the consistency concurrency control algorithm to obtain the first execution result.

4. The method according to claim 3, wherein The executing the first group of M transactions in parallel on the target consensus node using the consistency concurrency control algorithm to obtain the first execution result includes: Determine the read-write key-value pairs of the first group of M transactions, and lock the read-write keys to obtain M transaction locks; Determine a state of a target transaction lock, where the state of the target transaction lock includes a read lock and / or a write lock, and the target transaction lock is any one of the M transaction locks; Determine whether the target transaction lock has a mutual exclusion phenomenon according to the state of the target transaction lock; When mutual exclusion exists in the target transaction lock, the first group of M transactions is executed in parallel on the conflicting transactions corresponding to the target transaction lock on the target consensus node through the consistency concurrency control algorithm to obtain the first execution result.

5. The method according to claim 4, wherein The determining, according to the state of the target transaction lock, whether the target transaction lock has a mutual exclusion phenomenon includes: Determining a target transaction corresponding to the target transaction lock; The target transaction and the first transaction are locked to obtain a locked target transaction and a locked first transaction; the first transaction is a transaction corresponding to any one of the M transaction locks; Performing a mutual exclusion analysis on the target transaction in the locked state and the first transaction in the locked state to obtain a mutual exclusion analysis result; When the mutual exclusion analysis result meets a preset requirement, it is determined that the mutual exclusion phenomenon exists between the target transaction lock and the first transaction; the preset requirement is that there is at least one of the following conflicts between the target transaction lock and the first transaction: a read-before-write conflict, a write-before-read conflict, and a write-write conflict.

6. The method according to claim 4, wherein The step of executing the first group of M transactions in parallel on the conflicting transactions corresponding to the target transaction lock using the consistency concurrency control algorithm on the target consensus node to obtain the first execution result includes: Obtaining a first transaction index corresponding to the first transaction, where the first transaction index represents the number corresponding to the first transaction in the sequential numbers of the M transactions in the first block; Determine the lock-holding transaction corresponding to the target transaction, where the lock-holding transaction includes a transaction holding a write lock and a transaction holding a read lock; the write-lock-holding transaction corresponds to the write-lock-holding transaction index, and the read-lock-holding transaction corresponds to the read-lock-holding transaction index; If the conflict between the target transaction lock and the first transaction is the write-write conflict, compare the index of the transaction holding the write lock with the index of the first transaction; When the index of the transaction holding the write lock is greater than the index of the first transaction, the transaction holding the write lock is rolled back; When the index of the write-locked transaction is less than or equal to the index of the first transaction, wait for the write-locked transaction to be completed, and execute the first group of M transactions in parallel on the target consensus node using the consistency concurrency control algorithm for the first transaction to obtain the first execution result; If the conflict between the target transaction lock and the first transaction is a write-before-read conflict, compare the index of the transaction holding the write lock with the index of the first transaction; When the index of the transaction holding the write lock is greater than the index of the first transaction, the transaction holding the write lock and the transaction whose index of the transaction holding the write lock is greater than the first transaction are rolled back; When the index of the write-locked transaction is less than or equal to the index of the first transaction, wait for the write-locked transaction to be completed, and execute the first group of M transactions in parallel on the target consensus node using the consistency concurrency control algorithm for the first transaction to obtain the first execution result; If the conflict between the target transaction lock and the first transaction is a read-before-write conflict, compare the index of the transaction holding the read lock with the index of the first transaction; When the index of the transaction holding the read lock is greater than the index of the first transaction, rolling back the transaction holding the read lock; When the index of the transaction holding the read lock is less than or equal to the index of the first transaction, wait for the transaction holding the read lock to be completed, and execute the first group of M transactions in parallel on the first transaction through the consistency concurrency control algorithm on the target consensus node to obtain the first execution result.

7. The method according to claim 1 or 2, wherein: Each of the t transactions corresponds to a piece of transaction access information, and the method further includes: When the transaction conflict rate is less than or equal to the preset threshold, obtaining first transaction access information, where the first transaction access information is transaction access information of any one of the t transactions; determining a corresponding transaction access key-value pair based on the first transaction access information to obtain a first transaction key-value pair; determining whether the first transaction can be processed in parallel according to the first transaction key-value pair and the first transaction access information; When the first transaction can be processed in parallel, obtaining conflict domain information of the t transactions; determining conflict information corresponding to the first transaction access information according to the conflict domain information; Determining a first directed acyclic graph of transaction execution based on the t transactions; Constructing dependency edges in the first directed acyclic graph according to the conflict information to obtain a second directed acyclic graph; executing the t transactions based on the second directed acyclic graph to obtain a third execution result; Filling the first block with the third execution result based on the consensus algorithm to obtain a target second block, and broadcasting the target second block to the f-1 consensus nodes; after any consensus node among the f-1 consensus nodes receives the target second block, executing the t transactions in parallel on the consensus node through the second directed acyclic graph to obtain a fourth execution result; Collect the fourth execution results corresponding to the f-1 consensus nodes to obtain f-1 fourth execution results, and package the f-1 fourth execution results to obtain a second execution result message package; Detecting whether the second execution result message packet meets a second preset condition by the consensus algorithm; When the second execution result message packet meets the second preset condition, the target second block is submitted to the target alliance chain; when the second execution result message packet does not meet the second preset condition, the target second block is discarded.

8. The method according to claim 1 or 2, wherein: When the first execution result message packet meets the first preset condition, the method further includes: Obtaining the transaction root, receipt root, and status root in the first execution result message; Determining whether the first execution result and the f-1 second execution results satisfy a third preset condition; When the first execution result and the f-1 second execution results satisfy the third preset condition, filling the transaction root, the receipt root, and the status root into the first block using the consensus algorithm to obtain the filled first block; The state root in the filled first block is updated to obtain the target first block.

9. A parallel control device based on alliance chain transaction conflicts, characterized in that: The device includes an acquisition module, a determination module, a judgment module, and a control module, wherein: The acquisition module is used to acquire t transactions of a target consensus node on a target alliance chain, where the target alliance chain includes f consensus nodes, and t and f are both integers greater than 1; the target consensus node is any consensus node among the f consensus nodes; The determination module is configured to package the t transactions using a consensus algorithm to obtain a first block, and broadcast the first block to f-1 consensus nodes among the f consensus nodes excluding the target consensus node; perform static analysis on the first block to obtain a static analysis result; and calculate a conflict rate for the transactions based on the static analysis result to obtain a transaction conflict rate; The judgment module is used to execute the t transactions in parallel on the target consensus node through the consistency concurrency control algorithm when the transaction conflict rate is greater than a preset threshold to obtain a first execution result; wherein, the consistency concurrency control algorithm includes: when each transaction is executed, obtaining the transaction lock corresponding to each transaction in the t transactions; during the transaction processing process, releasing all locks after the execution is completed to avoid deadlock problems during the execution process; if there are conflicting transactions in the first group of m transactions; the conflicting transactions include: write-write conflicts, write-first-then-read conflicts, or read-first-then-write conflicts in operations on the same resource; the priority of the conflicting transactions is determined by the index, and the transactions with smaller indexes are processed first, and other transactions in the conflict are rolled back or Waiting operation; during the transaction execution process, if a rollback due to a conflict is detected, the rolled-back transaction will be reallocated to the next batch of transactions for re-execution. The rolled-back transaction will be re-locked according to the latest resource status when it is re-executed to ensure that the re-executed transaction no longer conflicts with other transactions; after all transactions are completed, all the consensus nodes on the alliance chain will perform a consistency check on the first execution result. The target consensus node will compare the execution results and data status of each transaction to ensure that the execution results obtained by each transaction on different nodes are consistent; if the results are inconsistent, the system will trigger a retry mechanism to re-execute the transaction with the execution deviation until the execution results of all nodes are completely consistent, and finally achieve consensus in the network; The control module is configured to fill the first block with the first execution result based on the consensus algorithm to obtain a target first block, and broadcast the target first block to the f-1 consensus nodes; after any consensus node among the f-1 consensus nodes receives the target first block, execute the transaction in parallel on the consensus node using the consistency concurrency control algorithm to obtain a second execution result; The acquisition module is further configured to collect the second execution results corresponding to the f-1 consensus nodes, obtain f-1 second execution results, and package the f-1 second execution results to obtain a first execution result message packet; The judgment module is further configured to detect, through the consensus algorithm, whether the first execution result message packet satisfies a first preset condition; the first preset condition being that the number of the first execution result message packets is less than or equal to a preset first threshold, and that each execution result in the first execution result message packet is consistent with the second execution result; The control module is further configured to submit the target first block to the target alliance chain when the first execution result message packet satisfies the first preset condition; and discard the target first block when the first execution result message packet does not satisfy the first preset condition.

10. An electronic device, characterized in that: include: a processor, a memory, a communication interface, and one or more programs; The one or more programs are stored in the memory and configured to be executed by the processor, wherein the programs include instructions for executing the steps of the method according to any one of claims 1 to 8.

Images