Distributed extensible deterministic transaction execution method for fragmented license chain system

Abstract

The invention discloses a distributed extensible deterministic transaction execution method for a fragment permission chain system, which is characterized in that distributed multi-version tentative deterministic concurrency control and batch transaction submission mechanism strategies are adopted to realize multi-node extensible deterministic transaction concurrency execution under a conflict load. According to the distributed multi-version tentative deterministic concurrency control, a batch of transactions in a block are sorted in advance in a consensus manner, and a globally unique and automatically increasing transaction sequence number is allocated, so that a result of concurrent execution of the transactions is equal to a result of serial execution according to the transaction sequence number; according to the batch transaction submission mechanism strategy, submission of a plurality of cross-piece transactions is combined and processed by adopting batch processing, and network overhead required by submission is uniformly shared. Compared with the prior art, the method has the advantages that multi-node expandability under conflict loads is realized in a distributed scene, strict certainty of an execution scheme is guaranteed, the overall performance and transaction processing performance of the system are improved, and the method has a good application prospect.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a distributed and scalable deterministic transaction execution method for a sharded permission chain system. Background Art

[0002] As a decentralized distributed ledger, blockchain technology has been widely used in many fields such as finance, supply chain management and the Internet of Things. Its core features include decentralization, immutability and transparency. However, as the application scenarios of blockchain become increasingly complex, its limitations in transaction processing capabilities and execution efficiency have become more and more significant, and effective improvement solutions are urgently needed. Traditional blockchain systems mostly rely on a full replication mode, that is, each node saves and verifies all data in the entire network. Although this mode helps to improve the security of the system, it also greatly limits the scalability of the blockchain and becomes a bottleneck for large-scale applications. Therefore, in order to solve this problem, system design often introduces sharding technology by utilizing the local characteristics of data, partitioning data for processing to improve the system's parallel processing capabilities.

[0003] In recent years, sharding technology has been widely studied and practiced as a horizontal expansion solution. Specifically, researchers have borrowed sharding technology from the database field to divide the entire blockchain network into multiple shards to support parallel processing and performance improvement. Deploying the Byzantine Fault Tolerant consensus protocol in each shard not only ensures the security of the shard, but also allows each shard to process transactions, generate blocks and reach consensus in parallel. This sharding structure also supports state sharding, that is, each shard only needs to store a part of the global state data, thereby avoiding the high cost of data redundancy in traditional blockchains. However, data sharding also brings new technical challenges, especially the cross-shard transaction problem. When the read and write states of a transaction involve different shards, coordination must be carried out among multiple shards. In the database field, similar situations are called "distributed transactions." Cross-shard transactions usually rely on distributed commit protocols to ensure the atomicity and consistency of transaction execution, but the process of multi-shard collaborative processing is relatively complicated, which increases the coordination cost of the system.

[0004] Two common cross-shard transaction processing schemes have been proposed in the research of existing technologies: designs based on the "two-phase commit protocol" and the "deterministic execution" mechanism. The former ensures the atomicity of cross-shard transactions by introducing a trusted third party to coordinate the submission decisions of the shards, but multiple rounds of network communication bring high network overhead and strong trust assumptions, which affects the performance of the system. The latter relies on precise prior transaction information (such as read-write sets) to ensure consistency, but the high reliance on prior information limits its support for complex smart contracts, making it less versatile. In addition, the trustless assumption of blockchain and the Turing completeness of smart contracts also make these schemes difficult to fully apply. Summary of the invention

[0005] The purpose of the present invention is to provide a distributed scalable deterministic transaction execution method for a sharded permission chain system in view of the deficiencies of the prior art. A tentative multi-version concurrency control method is adopted, and a submission protocol (FairCross) for intra-chip and cross-chip transactions is designed to achieve multi-node scalability under conflict loads, ensure the final consistency and strict determinism of transaction execution under the assumption that there is no global read-write set in the sharding scenario, and better solve the efficiency and fairness problems of traditional blockchain systems in sharding and cross-chip transaction processing. In a distributed scenario, it is possible to achieve multi-node scalability under conflict loads while ensuring the strict determinism of the execution scheme, thereby improving the overall performance and reliability of the system. The method is fair and efficient in strictly deterministic transaction concurrent execution, ensuring that the fair serialization order established by consensus is retained in the sharded permission chain scenario, and having high execution performance. Through a distributed tentative transaction execution protocol, FairCross allows each shard to tentatively execute transactions without knowing the read-write set in advance, and aborts and re-executes any erroneous attempts when necessary to ensure that the established serialization order is achieved. FairCross adopts a batch transaction submission strategy, which effectively reduces the processing overhead of cross-shard transactions. Through these optimizations, FairCross not only prioritizes the fairness of sorting, but also significantly improves transaction processing performance, solves the performance bottleneck of cross-shard transaction processing, meets the growing application needs, and has a good application prospect.

[0006] The specific technical scheme for achieving the purpose of the present invention is: a distributed scalable deterministic transaction execution method for a sharded permission chain system, which is characterized by adopting a distributed multi-version tentative deterministic concurrency control and a batch transaction submission mechanism strategy to achieve multi-node scalable deterministic transaction concurrent execution under conflict load, wherein the distributed multi-version tentative deterministic concurrency control adopts a batch of transactions in a block sorted by a pre-consensus and assigns a globally unique and automatically increasing transaction sequence number to ensure that the result of concurrent transaction execution is equivalent to the result of serial execution by transaction sequence number; the batch transaction submission mechanism strategy adopts batch processing to merge the submission of multiple cross-shard transactions, amortizes the network overhead required for submission, avoids blocking processing, and reduces the overhead of redundant cross-shard redo execution;

[0007] The distributed multi-version tentative deterministic concurrency control specifically includes:

[0008] Step A1: Transaction execution phase

[0009] During the execution of a transaction T, the contract code logic instructions will be executed, and multiple read and write operation instructions will be performed on different states. When transaction T performs a read operation, there are different execution mechanisms for intra-chip transactions and cross-chip transactions. When performing a write operation, only the local write set of transaction T is updated.

[0010] Step A2: Exploratory submission phase

[0011] After transaction T executes logic and read and write operations, it enters the tentative commit phase. Transaction T writes the write set to the local shared storage and checks whether there are transactions that need to be aborted. For intra-shard transactions, all states are written; for cross-shard transactions, only the state of the local shard is written. Transaction T inserts a new version into the version chain and checks the read dependency. If a dependency with a sequence number larger than the transaction ID is found, the relevant transaction needs to be aborted.

[0012] Step A3: Final submission stage

[0013] After transaction T completes the tentative submission, check whether it can be finally submitted. In general, if the previous transaction T_i-1 has been finally submitted and T_i has not been aborted, then T_i can be finally submitted. Since data is sharded, FairCross designs different final submission mechanisms for intra-shard transactions and cross-shard transactions.

[0014] The batch transaction submission mechanism strategy specifically includes:

[0015] Step B1: Synchronization phase

[0016] Each shard node confirms that all K transactions in the batch it processes have been tentatively submitted. The node sends a batch synchronization message to the trusted domain leader, which contains the set of local transaction IDs that have been tentatively submitted and the tentative submission information of cross-shard transactions.

[0017] Step B2: Detection phase

[0018] After the leader collects tentative submission messages from all shards, it enters the detection phase, starting from the next transaction number of the largest submitted transaction number, and checks whether the transactions in the batch can be finally submitted. FairCross has designed different detection mechanisms for intra-shard transactions and cross-shard transactions.

[0019] Step B3: Submission phase

[0020] Based on the decision made in the detection phase, the leader sends a batch submission message to each shard node, and each shard node executes the final submission or aborts the transaction based on the decision received.

[0021] The step A1 specifically includes:

[0022] Step A11: During the execution of a transaction T, the contract code logic instructions are executed multiple times, and the logic instructions include state reading and state writing.

[0023] Step A12: When executing a state read operation, transaction T first attempts to read from the local read set and write set; if not, determine whether the state belongs to an on-chip transaction; if it does, scan the state version list from the local shared storage and retrieve the state version that satisfies the maximum sequence number less than the sequence number of transaction T as the state version read by T, obtain the value and record the transaction ID, and send the read set to the remote shard; if it belongs to a remote shard, T will block until the remote read set is received and then continue to execute.

[0024] Step A13: When a state write operation is performed, the update is first inserted into the local write set of transaction T, ensuring that the update is temporarily stored locally before the final commit.

[0025] The step A2 specifically includes:

[0026] Step A21: Write each state update operation in the local write set of transaction T as a new state version to the shared storage one by one. For intra-shard transactions, write all states; for cross-shard transactions, only write the state of the local shard. Specifically, according to the sequence number of transaction T, insert each state to be written into the corresponding position of the state version list to ensure that each state update in the local write set is reflected in the global state in order.

[0027] Step A22: Transaction T performs conflict detection with other transactions; specifically, check whether other transactions have missed reading the status of transaction T, including checking the read dependency tracked by the previous status version of other transactions, finding transactions with a larger sequence number than transaction T in their read dependencies and terminating them.

[0028] Step A23: After transaction T writes all state updates in its local write set to shared storage, it indicates that all state updates of transaction T have been committed to the global state, and transaction T is considered to have been tentatively committed.

[0029] The step A3 specifically includes:

[0030] Step A31: In-chip transaction submission mechanism

[0031] Check whether T_S(i) meets the following conditions: 1) T_S(i-1) has been finally submitted, 2) T_S(i) has not been aborted; if so, T_S(i) can be finally submitted.

[0032] Step A32: Cross-shard transaction submission mechanism

[0033] Check whether all remote read sets of T_S(i) are read on the locally consistent snapshot; if they are consistent, T_S(i) can be finally committed; otherwise, it will be remotely aborted and need to be re-executed.

[0034] Step A33: Final submission

[0035] If T_S(i) confirms that the transaction can be finally submitted, the counter is set to the transaction ID, and no longer needed read dependencies and redundant write versions are cleaned up. After the final submission, if a remote abort message is received, it is ignored.

[0036] The step B2 specifically includes the following steps:

[0037] Step B21: The leader receives tentative commit messages from all shards and starts checking from the next sequence number of the largest committed transaction sequence number.

[0038] Step B22: For intra-chip transactions, check whether the previous transaction has been finally submitted. If the conditions are met, it can be finally submitted.

[0039] Step B23: For cross-shard transactions, check the consistency of all remote read set versions in the tentative submission information with the corresponding shards. If they are inconsistent, the cross-shard transaction needs to be aborted and redone; if they are consistent, it can be finally submitted.

[0040] The step B3 specifically includes:

[0041] Step B31: Based on the decision made in the detection phase, the leader sends a batch commit message to each shard node, which contains the commit message for each transaction, the tentative commit or abort decision, and the remote read set required for redo.

[0042] Step B32: Each shard node executes the final submission or aborts the transaction based on the received decision. If there are still transactions that have not been finally submitted, the leader will re-initiate the batch submission process until all transactions in the batch are finally submitted.

[0043] Compared with the prior art, the present invention has the following beneficial technical effects and significant technical progress:

[0044] 1) It solves the problem of efficient and concurrent execution of smart contract transactions in sharded permissioned chain systems, ensuring both strict determinism and high performance. FairCross proposes a distributed tentative transaction execution protocol that not only ensures the strict determinism of transaction execution results, but also retains the fairness of consensus sorting, ensuring the consistency and reliability of transaction results for all participants during the execution process.

[0045] 2) In order to improve system performance, FairCross significantly reduces the processing overhead of cross-shard transactions through batch transaction submission optimization strategy, making the system more efficient when processing a large number of transactions and avoiding the performance bottleneck caused by cross-shard transactions in traditional methods.

[0046] 3) FairCross allows each shard to perform tentative execution without knowing the read-write set in advance, ensuring that the results are consistent with the global serialization order.

[0047] 4) FairCross’ cross-shard transaction optimization not only improves transaction processing efficiency, but also enhances the overall scalability of the system, enabling sharded permission chains to better cope with growing transaction needs and complex application scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 This is the overall architecture diagram of the present invention;

[0049] Figure 2 This is the overall architecture diagram of cross-shard transactions;

[0050] Figure 3 This is a cross-shard transaction flow chart. DETAILED DESCRIPTION

[0051] The present invention is further described in detail with reference to the following specific examples and drawings. The process, conditions, experimental methods, etc. for implementing the present invention, except for the contents specifically mentioned below, are all common knowledge and common common sense in the art and are not particularly limited by the present invention.

[0052] The present invention proposes a distributed, scalable, strictly deterministic transaction concurrent execution method for sharded permissioned chain systems, namely the FairCross protocol. FairCross aims to solve the efficiency and fairness problems of traditional blockchain systems in sharding and cross-shard transaction processing, especially in the face of challenges in high concurrency and complex transaction scenarios.

[0053] See also Figure 1 , the FairCross protocol adopts a tentative multi-version concurrency control method, allowing transactions to be tentatively executed without knowing the global read-write set in advance, and combines the submission protocol of intra-shard and cross-shard transactions to ensure the final consistency and strict determinism of transaction execution in the sharding environment. This mechanism enables each shard to achieve efficient transaction processing while ensuring sorting fairness. Secondly, FairCross proposes a batch transaction submission mechanism and a differentiated execution reuse strategy, which significantly reduces the communication and processing overhead brought by cross-shard transactions. These optimizations not only improve the performance of the system when processing a large number of concurrent transactions, but also avoid potential bottlenecks caused by cross-shard transactions. In addition, FairCross further enhances the system's adaptability in distributed scenarios through dynamic scheduling and intelligent load balancing, enabling it to achieve multi-node scalability under conflicting loads. Overall, FairCross provides a solid technical foundation for the widespread application of sharded permission chains while improving transaction processing performance and system reliability.

[0054] See also Figure 2The present invention includes two parts: distributed multi-version tentative deterministic concurrency control and batch transaction submission mechanism and differential execution reuse strategy. In deterministic concurrency control, transactions go through three stages: execution, tentative submission and final submission. In the final submission process, the batch transaction submission mechanism is adopted to significantly reduce the communication and processing overhead caused by cross-shard transactions. At the same time, in view of the differentiated behavior of cross-shard transaction submission, the transaction execution replicated by the state machine is converted into master-slave asynchronous replication, which reduces the overhead of redundant cross-shard redo execution.

[0055] Definition 1: If all states accessed by a transaction during its execution belong to one shard, then this type of transaction is an intra-shard transaction, collectively referred to as SPT (Single-Partition Transaction).

[0056] Definition 2: If a transaction accesses the states of multiple shards during execution, then this type of transaction is a cross-shard transaction, collectively referred to as MPT (Multi-Partition Transaction). Furthermore, for a cross-shard transaction T, the set of shards to which its state access belongs is P, and for each accessed shard X∈P, the execution instance of the cross-shard transaction on the shard is T^X.

[0057] Data structure: In order to support remote abort of cross-shard transactions, the shards additionally maintain a list of remote read dependencies, remote_rlist, on the write version of each state. Each record is a triple r_ver: <shard ID, transaction ID, local abort number of transaction ID lan (local_abort_num)>, which is used to record that the cross-shard instance sent this state version to the remote MPT instance, and uniquely identifies the read set after the execution of the local abort of the transaction by the transaction local abort number. When an error attempt occurs, a remote abort message can be sent through the information in the remote read dependency to abort and redo the remote MPT instance.

[0058] In the distributed and scalable strictly deterministic execution method, the life cycle of a transaction will go through three stages: 1) transaction execution; 2) tentative submission; 3) final submission.

[0059] 1) Transaction execution phase: For a transaction T, when T performs a read operation, first check in T's local read-write set whether the state has been read or written. If so, only the value stored in its local read-write set needs to be read and returned. Otherwise, when the state is read for the first time, determine whether the state belongs to the shard executing T. (i) If the state belongs to the local shard, T will obtain its value from the local shared storage: by scanning the version chain of the state, find the largest version smaller than the transaction ID, and record the transaction ID in the local read dependency of the version to support local rollback. At the same time, if T belongs to MPT, the read set needs to be sent to all required remote shards: according to the transaction meta information, send a local_read message to all involved remote shards, the message is accompanied by the transaction ID, source shard ID, read set and the number of transaction aborts used to identify it, and record this information in the remote read dependency of the read version to support remote rollback. In the case of possible re-execution, if the local_fc message of the transaction has been sent to other shards, there is no need to send the local_read message again. (ii) If the state belongs to a remote shard, T will be blocked until it receives the remote read set (if there are multiple remote read set messages, the message with the largest number of transaction aborts is taken) and then continue to execute T's subsequent operations. When T performs a write operation, T inserts the state update into its write set.

[0060] 2) Tentative commit phase: After the transaction has executed all logic and read and write operations, it enters the tentative commit phase. T writes the write set to the local shared storage and checks whether there are any transactions that have missed the update and need to be aborted. Specifically, if T is SPT, all states in the write set are written; if T is MPT, only the states belonging to the local shard need to be written. For each state to be written, T inserts a new version at the corresponding position of the version chain of the state according to its sequence number, and checks the local read dependency and remote read dependency on the previous version. If there are transactions with a sequence greater than the transaction ID in the dependency, it means that these transactions have read the wrong version, violating the strictly deterministic serialization order and need to be aborted. If it is a local abort, T will directly abort the corresponding transaction. If it is a remote abort, FairCross adopts a postponed abort strategy, records the remote abort message, and postpones the notification of the message until the final commit phase of the corresponding transaction and sends it implicitly with a local_fc message. The core idea of ​​this delayed notification strategy is to handle cross-shard transactions in a more pessimistic way, avoiding the huge overhead caused by frequent remote aborts due to frequent local conflicts. After all states are written, T is considered to be tentatively committed.

[0061] 3) Final Commit Phase: After transaction \(T_i\) completes tentative commit, it will be checked whether it can be finally committed. In centralized tentative execution, if \(T_{i - 1}\) has been finally committed and \(T_i\) has not been aborted, then \(T_i\) can be finally committed. However, after data sharding, each shard only executes transactions related to its own shard, and the centralized final commit criterion can no longer be used. In the data sharding scenario, FairCross designs a final commit mechanism for SPT and MPT. Given globally ordered transactions \(T_1, T_2, \ldots, T_j\), the transactions related to shard \(S\) are \(T_{S(1)}, T_{S(2)}, \ldots, T_{S(i)}\) (\(1\leq S(1)\leq S(2)\leq\ldots\leq S(i)\leq j\)).

[0062] For the final commit mechanism of SPT, if \(T_{S(i)}\) belongs to SPT, after \(T_{S(i)}\) completes tentative commit, if it satisfies that \(T_{S(i - 1)}\) has been finally committed and \(T_{S(i)}\) has not been aborted, then \(T_{S(i)}\) can be finally committed. This is because for SPT transactions, they may only be aborted due to local state conflicts. Therefore, \(T_{S(i)}\) may only be aborted by \(T_{S(k)}\) (\(S(1)\leq S(k)<S(i)\)), and before \(T_{S(i - 1)}\) is finally committed, it is guaranteed that all messages of \(T_{S(k)}\) aborting \(T_i\) are obtained by \(T_i\). Therefore, if \(T_{S(i - 1)}\) has been finally committed and \(T_{S(i)}\) has not been aborted, it means that \(T_{S(i)}\) will definitely not be aborted, so \(T_{S(i)}\) can be finally committed.

[0063] Refer to Figure 3, the final commit mechanism of the MPT, if T_S(i) belongs to MPT and the final commit detection rule of SPT is still used, may destroy the consistency of cross-shard transactions. This is because there is a network delay in the remote abort message. T_S(i) may not have received the remote abort message when judging the final commit, causing T_s(i) to mistakenly commit in advance. The commit omits the locally consistent snapshot, which results in data consistency being destroyed. Therefore, in the design of FairCross, it is necessary to detect whether all remote read sets of T_S(i) are read on its locally consistent snapshot. When the cross-shard instance T_S(i) detects that T_S(i-1) has finally committed, it will broadcast a local attempt to commit message local_fc to other cross-shard instances. The message contains the local state and version of the current read executed by T_S(i), indicating that the local state read by T_S(i) will no longer be locally aborted at this time, and its local read set is based on the locally consistent snapshot. When the cross-shard instance T_S(i) itself has been tentatively committed locally, and all remote read set versions of T_S(i) are consistent with the versions contained in the local_fc message of the corresponding shard, then T_S(i) can be finally committed. If T_S(i) finds that there is a remote read set version that is inconsistent with the version in the local_fc message of the corresponding shard, it means that the wrong state version has been read and needs to be remotely aborted and re-executed with the latest version of the state received (the largest version in lan).

[0064] If T_S(i) fails to be submitted, it will be suspended until it is aborted and redone or it is re-tested to see if it can be submitted. When T_S(i) is confirmed to be submitted, since its write version has been exposed in the tentative submission phase, it is only necessary to set the local counter for tracking transaction submission to the transaction ID of T_S(i) to indicate that the transaction has been submitted. At the same time, the redundant write versions that are no longer needed and that precede T_S(i) are cleaned up. If a remote abort message is still received after the final submission, the outdated message will be directly discarded and not processed.

[0065] Due to the design of the above-mentioned distributed scalable strictly deterministic concurrent transaction execution method in ensuring the final consistency and strict determinism of each shard data, the submission of cross-shard transactions requires the collection of local_fc messages of all instances, resulting in a significant increase in network overhead and processing delay, limiting the horizontal expansion capability of the system. The specific problem is that the network communication complexity of cross-shard transactions is as high as O(n^2), and due to the semantics of blocking communication, the local_fc message of each transaction must be sent after the previous transaction is submitted, resulting in high latency of serial broadcast. In order to solve these bottlenecks, FairCross proposes a batch-based cross-shard transaction submission mechanism, which significantly reduces the number of communications and processing blockages by selecting a master node to coordinate batch submission and adopting lightweight inter-shard synchronization. At the same time, if different submission behaviors are found between different instances of the same cross-shard, the system performance and scalability are improved by reusing the cross-shard transaction execution results that can be finally submitted to those cross-shard instances that still need to be aborted and redone. The batch transaction submission mechanism strategy is detailed in the following algorithm 1:

[0066]

[0067] The batch transaction submission mechanism strategy of the above algorithm 1 is divided into three stages: 1) synchronization stage; 2) detection stage; 3) submission stage. For each shard node, the synchronization stage is marked by the fact that all K transactions contained in the batch B_h it is processing have been tentatively submitted. In order to support this design, the transaction in the batch postpones the final submission detection, and the cross-shard transaction no longer sends the local_fc message in a blocking manner, but sends the tentatively submitted local_sp information in the synchronization stage. When a shard node confirms that its synchronization stage has started, it will send a batch synchronization message batch_sync to the leader in the trusted domain. The batch_sync message contains the set of all tentatively submitted local transaction IDs in the batch and the local_sp of the cross-shard transaction instance. The local_sp message contains the local and remote read set versions read when each cross-shard transaction instance is tentatively submitted and its corresponding lan identifier (lines 1 to 5).

[0068] After the leader receives batch_sync messages from all shards, the detection phase enters the detection phase (lines 6 to 22). The leader will detect whether the transaction B_h in the batch can be finally submitted. The detection will start from tracking the next transaction number lastFC_TID+1 of the largest submitted transaction number. If transaction T_i is the X(k)th intra-shard transaction of shard X, and the X(k-1)th transaction T_X(k-1) in the batch has been finally submitted, or does not exist (that is, T_i is the first intra-shard transaction of shard X in the batch), then the decision of T_i is that it can be finally submitted, and lastFC_TID is increased by one. Otherwise, it is still a tentative submission, and the leader only needs to include the decision of the final decision in the batch_commit message (lines 9 to 13). For a cross-shard transaction T_i, the leader will check all the cross-shard instances involved one by one in order. For a cross-shard instance, it is necessary to check whether all remote read set versions in its local_sp are consistent with the local read set version of local_sp in the cross-shard transaction instance of its corresponding shard. If there is inconsistency, it means that the cross-shard instance has read the wrong remote version and needs to be aborted and redone. Otherwise, the cross-shard instance can be finally submitted. The leader also adds the decision of the cross-shard instance to the batch_commit message. If all cross-shard instances of a cross-shard transaction can be finally submitted, the leader will increase the lastFC_TID by one (lines 14 to 22). This detection phase utilizes the following property: the implicit semantics of local_sp of the first cross-shard transaction involved in each shard in the batch are consistent with local_fc, because its previous local transactions can be finally submitted, ensuring that the local state read by the cross-shard transaction is correct. After the transaction detection in the batch is completed, the leader will make the transaction decision belonging to each shard to send in the submission phase.

[0069] In the submission phase, the leader sends a batch submission message batch_commit to each shard node based on the submission decision made for each shard in the synchronization detection phase. The batch_commit message contains the submission of K transactions in the received shard B_h, the decision to maintain a tentative submission or abort, and the remote read set required for redoing. After receiving the message, each shard node finally submits or aborts the transaction according to the decision attached to the message (lines 23 to 26). If after a batch transaction submission, there are still cross-shard and intra-shard transactions that have not been finally submitted, the leader will initiate the batch submission process again, and try to submit the transaction through repeated synchronization, detection and submission processes until all transactions in the batch are finally submitted. The batch processing is completed and enters the submission process of the next batch.

[0070] The present invention (FairCross protocol) solves the efficiency and fairness problems of traditional blockchain systems in sharding and cross-shard transaction processing. The protocol adopts a tentative multi-version concurrency control method and designs a submission protocol for intra-shard and cross-shard transactions, ensuring the final consistency and strict determinism of transaction execution under the assumption that there is no global read-write set in the sharding scenario. FairCross proposes a batch transaction submission mechanism strategy to reduce the communication and processing overhead brought by cross-shard transactions. The present invention can achieve multi-node scalability under conflicting loads in a distributed scenario, while ensuring the strict determinism of the execution plan and improving the overall performance and reliability of the system.

[0071] The protection content of the present invention is not limited to the above embodiments. Without departing from the spirit and scope of the inventive concept, changes and advantages that can be thought of by those skilled in the art are included in the present invention and are protected by the attached claims.

Claims

1. A distributed and scalable deterministic transaction execution method for a sharded permissioned chain system, characterized in that: The method adopts distributed multi-version tentative deterministic concurrency control and batch transaction submission mechanism strategy to achieve multi-node scalable deterministic transaction concurrent execution under conflict load. The distributed multi-version tentative deterministic concurrency control sorts a batch of transactions in a block by pre-consensus and assigns a globally unique and automatically increasing transaction sequence number to ensure that the result of concurrent transaction execution is equivalent to the result of serial execution by transaction sequence number; the batch transaction submission mechanism strategy adopts batch processing to merge the submission of multiple cross-shard transactions and evenly amortize the network overhead required for submission; The distributed multi-version tentative deterministic concurrency control specifically includes: Step A1: Transaction execution phase During the execution of a transaction T, the contract code logic instructions will be executed, and multiple read and write operation instructions will be performed on different states. When executing a read operation on transaction T, there are different execution mechanisms for intra-chip transactions and cross-chip transactions. When executing a write operation, only the local write set of transaction T is updated. Step A2: Exploratory submission phase Transaction T writes the write set to the local shared storage and checks whether there are any transactions that need to be aborted. For intra-shard transactions, all states are written; for cross-shard transactions, only the state of the local shard is written. Transaction T inserts a new version into the version chain and checks the read dependency. If a dependency with a sequence number larger than the transaction ID is found, the relevant transaction needs to be aborted. Step A3: Final submission stage If the previous transaction T_i-1 has been finally submitted and T_i has not been aborted, then T_i can be finally submitted; The batch transaction submission mechanism strategy specifically includes: Step B1: Synchronization phase Each shard node confirms that all K transactions in the batch it processes have been tentatively submitted. The node sends a batch synchronization message to the trusted domain leader, which contains the set of local transaction IDs that have been tentatively submitted and the tentative submission information of cross-shard transactions; Step B2: Detection phase Starting from the next transaction number of the largest submitted transaction number, check in sequence whether the transactions in the batch can be finally submitted; Step B3: Submission phase Based on the decision made in the detection phase, the leader sends a batch commit message to each shard node, and each shard node executes the final commit or aborts the transaction based on the decision received.

2. The distributed and scalable deterministic transaction execution method for a sharded permission chain system according to claim 1, characterized in that: The step A1 specifically includes: Step A11: During the execution of a transaction T, the contract code logic instructions are executed multiple times, and the logic instructions include state reading and state writing; Step A12: When executing the state read operation, transaction T reads from the local read set and write set; if not, determine whether the state belongs to an on-chip transaction; if it does, scan the state version list from the local shared storage and retrieve the state version that satisfies the maximum sequence number less than the sequence number of transaction T as the state version read by T, obtain the value and record the transaction ID, and send the read set to the remote shard; if it belongs to a remote shard, T will block until the remote read set is received before continuing to execute; Step A13: When a state write operation is performed, the update is inserted into the local write set of transaction T, ensuring that the update is temporarily stored locally before the final commit.

3. The distributed and scalable deterministic transaction execution method for a sharded permission chain system according to claim 1, characterized in that: The step A2 specifically includes: Step A21: Write each state update operation in the local write set of transaction T as a new state version to the shared storage one by one. For intra-shard transactions, write the entire state; for cross-shard transactions, only write the state of the local shard; Step A22: Transaction T performs conflict detection with other transactions to check whether other transactions have missed reading the status of transaction T, including checking the read dependency tracked by the previous status version of other transactions, finding transactions with a larger sequence number than transaction T in their read dependencies and aborting them; Step A23: After transaction T writes all state updates in its local write set to shared storage, it indicates that all state updates of transaction T have been committed to the global state, and transaction T is considered to have been tentatively committed.

4. The distributed and scalable deterministic transaction execution method for a sharded permissioned chain system according to claim 1, characterized in that: The step A3 specifically includes: Step A31: In-chip transaction submission mechanism Check whether T_S(i) meets the following conditions: 1) T_S(i-1) has been finally submitted; 2) T_S(i) has not been aborted. If so, T_S(i) is finally submitted. Step A32: Cross-shard transaction submission mechanism Check whether all remote read sets of T_S(i) are read on the locally consistent snapshot. If they are consistent, T_S(i) is finally committed; otherwise, it will be remotely aborted and need to be re-executed; Step A33: Final submission If T_S(i) confirms that the transaction can be finally submitted, the counter is set to the transaction ID, and no longer needed read dependencies and redundant write versions are cleaned up. If a remote abort message is received after the final submission, the message is ignored.

5. The distributed and scalable deterministic transaction execution method for a sharded permissioned chain system according to claim 1, characterized in that: The step B2 specifically includes: Step B21: The leader receives tentative commit messages from all shards and starts checking from the next sequence number of the largest committed transaction sequence number; Step B22: For intra-chip transactions, check whether the previous transaction has been finally submitted. If the conditions are met, it can be finally submitted; Step B23: For cross-shard transactions, check the consistency of all remote read set versions in the tentative submission information with the corresponding shards. If they are inconsistent, the cross-shard transaction needs to be aborted and redone; if they are consistent, it can be finally submitted.

6. The distributed and scalable deterministic transaction execution method for a sharded permissioned chain system according to claim 1, characterized in that: The step B3 specifically includes: Step B31: Based on the decision made in the detection phase, the leader sends a batch commit message to each shard node, which contains the commit message for each transaction, the decision to keep the tentative commit or abort, and the remote read set required for redo; Step B32: Each shard node executes the final submission or aborts the transaction based on the received decision. If there are still transactions that have not been finally submitted, the leader will re-initiate the batch submission process until all transactions in the batch are finally submitted.

7. The distributed and scalable deterministic transaction execution method for a sharded permission chain system according to claim 3, characterized in that: The step A21 inserts each state to be written into the corresponding position of the state version list according to the sequence number of the transaction T, ensuring that each state update of the local write set is reflected in the global state in sequence.

Images