Distributed scalable deterministic transaction execution method for a sharded license chain system

Abstract

The application discloses a kind of distributed scalable deterministic transaction execution methods for fragmented license chain system, its characteristics are using distributed multiple version tentative deterministic concurrency control and batch transaction submission mechanism strategy, realize the deterministic transaction concurrent execution of multi-node scalability under conflict load, the distributed multiple version tentative deterministic concurrency control is through pre-consensus ordering block in a batch of transactions and distributes globally unique and automatically increasing transaction serial number, guarantee the result of transaction concurrent execution is equivalent to serial execution result according to transaction serial number;The batch transaction submission mechanism strategy adopts batch processing and merges the submission of multiple cross-fragment transactions, apportioning the network overhead required for submission.The application compared with prior art has in distributed scene, realize the multi-node scalability under conflict load, while guaranteeing the strict determinacy of execution scheme, improve the overall performance and transaction processing performance of system, with good use 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] Blockchain technology, a decentralized distributed ledger, has been widely adopted in various fields, including finance, supply chain management, and the Internet of Things. Its core characteristics include decentralization, immutability, and transparency. However, as blockchain applications become increasingly complex, its limitations in transaction processing and execution efficiency have become increasingly significant, necessitating effective solutions. Traditional blockchain systems often rely on a fully replicated model, where each node stores and verifies all data across the entire network. While this model improves system security, it also significantly limits blockchain scalability, becoming a bottleneck for large-scale applications. Therefore, to address this issue, system design often incorporates sharding technology, leveraging data locality to partition data for processing and improve the system's parallel processing capabilities.

[0003] In recent years, sharding technology has been widely researched and implemented as a horizontal scaling solution. Specifically, researchers have borrowed sharding techniques from the database field to partition the entire blockchain network into multiple shards to support parallel processing and improve performance. Deploying a Byzantine fault-tolerant consensus protocol within each shard ensures security while allowing each shard to process transactions, generate blocks, and reach consensus in parallel. This sharding architecture also supports state sharding, meaning each shard only needs to store a portion of the global state data, thus avoiding the high cost of data redundancy in traditional blockchains. However, data sharding also presents new technical challenges, particularly cross-shard transactions. When a transaction involves reading and writing state across different shards, coordination must be performed across these shards. In the database field, this scenario is known as a "distributed transaction." Cross-shard transactions typically rely on distributed commit protocols to ensure atomicity and consistency of transaction execution, but the multi-shard coordinated processing process is complex and increases system coordination costs.

[0004] Existing research has proposed two common cross-shard transaction processing schemes: 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 shard commit decisions. However, multiple rounds of network communication incur high network overhead and impose strong trust assumptions, impacting system performance. The latter relies on precise prior transaction information (such as read-write sets) to ensure consistency. However, this heavy reliance on prior information limits its support for complex smart contracts, making it less versatile. Furthermore, the trustless nature of blockchains and the Turing-completeness of smart contracts make these schemes difficult to fully apply. Summary of the Invention

[0005] The present invention addresses the shortcomings of the prior art by providing a distributed, scalable, deterministic transaction execution method for sharded permissioned blockchain systems. This method employs a tentative multi-version concurrency control method and designs a commit protocol (FairCross) for intra- and cross-shard transactions. This method achieves multi-node scalability under conflicting loads and ensures eventual consistency and strict determinism in transaction execution in sharded scenarios, assuming no global read / write set. This method effectively addresses the efficiency and fairness issues faced by traditional blockchain systems in sharded and cross-shard transaction processing. This method achieves multi-node scalability under conflicting loads while ensuring strict determinism in the execution scheme in a distributed scenario, improving the overall performance and reliability of the system. This method provides fair and efficient, strictly deterministic concurrent transaction execution, ensuring the preservation of a fair serialization order established by consensus in sharded permissioned blockchain scenarios and exhibiting high execution performance. Through a distributed, tentative transaction execution protocol, FairCross allows each shard to tentatively execute transactions without prior knowledge of the read / write set, aborting and re-executing any erroneous attempts when necessary to ensure the intended serialization order is achieved. FairCross adopts a batch transaction submission strategy, effectively reducing the processing overhead of cross-shard transactions. Through these optimizations, FairCross not only prioritizes ordering fairness but also significantly improves transaction processing performance, resolving performance bottlenecks in cross-shard transaction processing and meeting growing application needs, demonstrating promising application prospects.

[0006] The specific technical solution for achieving the objectives of the present invention is: a distributed, scalable, deterministic transaction execution method for a sharded permissioned chain system, characterized by employing a distributed multi-version tentative deterministic concurrency control and a batch transaction submission mechanism strategy to achieve scalable, deterministic concurrent transaction execution on multiple nodes under conflicting loads. The distributed multi-version tentative deterministic concurrency control employs a pre-consensus sorting mechanism to sort a batch of transactions within a block and assign globally unique, automatically incrementing transaction numbers, ensuring that the results of concurrent transaction execution are equivalent to those of serial execution by transaction sequence number. The batch transaction submission mechanism strategy employs batch processing to merge the submissions of multiple cross-shard transactions, evenly amortizing the network overhead required for submission, avoiding blocking processing, and reducing 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 executing a read operation, there are different execution mechanisms for intra-shard transactions and cross-shard transactions. When executing a write operation, only the local write set of transaction T is updated.

[0010] Step A2: tentative commit phase

[0011] After the transaction T finishes the logic and read-write operations, it enters the tentative commit phase. The transaction T writes the write set into the local shared storage and checks if there is any transaction that needs to be aborted. For intra-shard transactions, the entire state is written; for cross-shard transactions, only the state of the local shard is written. The transaction T inserts a new version in the version chain and checks the read dependencies. If a dependency with a sequence number greater than the transaction ID is found, the related transaction needs to be aborted.

[0012] Step A3: final commit phase

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

[0014] The batch transaction commit 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 committed, and the node sends a batch synchronization message to the trusted domain leader, which contains the set of local transaction IDs that have been tentatively committed and the tentative commit information of cross-shard transactions.

[0017] Step B2: detection phase

[0018] After the leader collects all the tentative commit messages of the shards, it enters the detection phase, starting from the next transaction sequence number of the maximum committed transaction sequence number to check if the transactions in the batch can be finally committed. FairCross designs different detection mechanisms for intra-shard transactions and cross-shard transactions.

[0019] Step B3: commit phase

[0020] The leader sends a batch commit message to each shard node according to the decision of the detection phase, and each shard node executes the final commit or aborts the transaction according to the received decision.

[0021] The step A1 specifically includes:

[0022] Step A11: During the execution of a transaction T, multiple contract code logic instructions are executed, including 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-shard transaction; if so, 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 at the same time; if it belongs to a remote shard, T will block until the remote read set is received and then continue execution.

[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: Each state update in the local write set of transaction T is treated as a new state version and written to shared storage one by one. For intra-shard transactions, the entire state is written; for cross-shard transactions, only the state of the local shard is written. Specifically, according to the sequence number of transaction T, each state to be written is inserted into the corresponding position in the state version list, ensuring that each state update in the local write set is reflected in the global state in order.

[0027] Step A22: Transaction T is conflicted with other transactions. Specifically, it is checked whether other transactions have missed reading the status of transaction T. This includes checking the read dependencies tracked by the previous status version of other transactions, finding transactions with a larger sequence number than transaction T in the read dependencies, and terminating the transaction.

[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 a 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 commit message 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 committed.

[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 decision to maintain a tentative commit or abort, and the remote read set required for redo.

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

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

[0044] 1) It solves the challenge of efficient concurrent execution of smart contract transactions in sharded permissioned blockchain systems, ensuring both strict determinism and high performance. FairCross proposes a distributed heuristic transaction execution protocol that guarantees both strict determinism and fairness in consensus ordering, ensuring consistency and reliability of transaction results across all participants during execution.

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

[0046] 3) FairCross allows each shard to perform tentative execution without knowing the read and write sets 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 demands 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 will be further described in detail with reference to the following specific examples and accompanying drawings. The processes, conditions, experimental methods, etc. for implementing the present invention, except for those specifically mentioned below, are common knowledge and common common sense in the art and are not particularly limited by the present invention.

[0052] This paper proposes a distributed, scalable, strictly deterministic concurrent transaction execution method for sharded permissioned blockchain systems, namely the FairCross protocol. FairCross aims to address the efficiency and fairness issues of traditional blockchain systems in sharding and cross-shard transaction processing, especially in the face of high concurrency and complex transaction scenarios.

[0053] See Figure 1 The FairCross protocol employs a tentative multi-version concurrency control method, allowing transactions to be tentatively executed without prior knowledge of the global read / write set. Combined with intra-shard and cross-shard transaction commit protocols, this ensures eventual consistency and strict determinism in transaction execution within a sharded environment. This mechanism enables efficient transaction processing on each shard while ensuring fair ordering. Secondly, FairCross proposes a batched transaction submission mechanism and a differentiated execution reuse strategy, significantly reducing the communication and processing overhead associated with cross-shard transactions. These optimizations not only improve system performance when handling large numbers of concurrent transactions, but also avoid potential bottlenecks caused by cross-shard transactions. Furthermore, through dynamic scheduling and intelligent load balancing, FairCross further enhances the system's adaptability in distributed scenarios, enabling multi-node scalability under conflicting loads. Overall, FairCross improves transaction processing performance and system reliability while providing a solid technical foundation for the widespread application of sharded permissioned blockchains.

[0054] See Figure 2The present invention comprises two parts: distributed multi-version tentative deterministic concurrency control and a batch transaction submission mechanism with a differentiated execution reuse strategy. In deterministic concurrency control, transactions undergo three phases: execution, tentative submission, and final submission. During the final submission process, a batch transaction submission mechanism is employed, significantly reducing the communication and processing overhead associated with cross-shard transactions. Furthermore, to address the differentiated behavior of cross-shard transaction submissions, the overhead of redundant cross-shard redo execution is reduced by converting state machine-replicated transaction execution to master-slave asynchronous replication.

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

[0056] Definition 2: A transaction that accesses state belonging to multiple shards during execution is considered a cross-shard transaction, collectively referred to as an MPT (Multi-Partition Transaction). Furthermore, for a cross-shard transaction T, the set of shards whose state it accesses is P. For each accessed shard X∈P, the execution instance of the cross-shard transaction on that shard is T^X.

[0057] Data Structure: To support remote aborts of cross-shard transactions, shards maintain a list of remote read dependencies, remote_rlist, for each state write version. Each record is a triplet r_ver: <shard ID, transaction ID, local abort count lan (local_abort_num)>, which records that the cross-shard instance sent this state version to the remote MPT instance. The transaction local abort count uniquely identifies the number of local aborts after which the read set was generated. When an error attempt occurs, a remote abort message can be sent using 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 transaction lifecycle 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, it first checks T's local read / write set to see if the state has been read or written before. If so, it simply reads the value stored in its local read / write set and returns it. Otherwise, when the state is first read, it determines whether the state belongs to the shard executing T. (i) If the state belongs to the local shard, T obtains its value from local shared storage by scanning the state's version chain to find the largest version smaller than the transaction ID. The transaction ID is recorded in the local read dependency of that version to support local rollback. Furthermore, if T belongs to an MPT, the read set must be sent to all required remote shards. Based on the transaction metadata, a local_read message is sent to all involved remote shards. This message carries the transaction ID, source shard ID, read set, and a transaction abort count, and is recorded in the remote read dependency of the read version to support remote rollback. In the event of a possible re-execution, if the local_fc message for the transaction has already been sent to other shards, no local_read message is sent 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 one with the largest number of transaction aborts is used), 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 logical and read and write operations, it enters the tentative commit phase. T writes the write set to the local shared storage and checks whether any transaction has missed the update and needs to be aborted. Specifically, if T is SPT, all states in the write set will be 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, violated 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 to 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 manner, avoiding the huge overhead caused by frequent remote aborts due to frequent local conflicts. After all states are written, T is considered tentatively committed.

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

[0062] The final submission mechanism of the SPT is that if T_S(i) belongs to SPT, after T_S(i) completes the tentative submission, if T_S(i-1) has been finally submitted and T_S(i) has not been aborted, then T_S(i) can be finally submitted. This is because for SPT transactions, it can only be aborted due to local state conflicts, so T_S(i) can only be aborted by T_S(k) (S(1)≤S(k) <S(i))中止,而T_S(i-1)最终提交前保证了所有T_S(k)中止T_i的消息被T_i获取。因此若T_S(i-1)已经最终提交且T_S(i)没有被中止,说明T_S(i)一定不会被中止,则T_S(i)可以最终提交。

[0063] See Figure 3, the final commit mechanism of the MPT may destroy the consistency of cross-shard transactions if T_S(i) belongs to MPT and the final commit detection rules of SPT are still used. 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 determining the final commit, causing T_s(i) to mistakenly commit in advance. This 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. This message contains the local state and version currently being read by T_S(i), indicating that the local state read by T_S(i) will no longer be locally aborted and its local read set is based on the locally consistent snapshot. When the cross-shard instance T_S(i) itself has 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, T_S(i) can finally commit. If T_S(i) finds that any remote read set version is inconsistent with the version in the local_fc message of the corresponding shard, it means that the incorrect 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 the LAN).

[0064] If T_S(i) fails to commit, it will be suspended until it is aborted and redone or retested for final submission. When T_S(i) is confirmed to be final, since its write version has been exposed during the tentative commit phase, it is only necessary to set the local counter tracking transaction submissions 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 related to T_S(i) are cleared. 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 aforementioned distributed, scalable, strictly deterministic concurrent transaction execution method to ensure eventual consistency and strict determinism of data across shards, cross-shard transaction submission requires collecting local_fc messages from all instances, significantly increasing network overhead and processing latency, limiting the system's horizontal scalability. The specific issue is that the network communication complexity of cross-shard transactions is as high as O(n^2), and due to blocking communication semantics, the local_fc message for each transaction must be sent after the previous transaction is committed, resulting in high latency for serial broadcasts. To address these bottlenecks, FairCross proposes a batch-based cross-shard transaction submission mechanism. By selecting a master node to coordinate batch submissions and employing lightweight inter-shard synchronization, it significantly reduces communication times and processing blockages. Furthermore, if different instances of the same cross-shard are found to have different commit behaviors, the system improves performance and scalability by reusing the finalized cross-shard transaction execution results for those cross-shard instances that still need to be aborted and redone. The batch transaction submission mechanism strategy is detailed in Algorithm 1 below:

[0066]

[0067] The batch transaction submission mechanism strategy in Algorithm 1 above is divided into three phases: 1) synchronization phase; 2) detection phase; and 3) submission phase. For each shard node, the synchronization phase begins when all K transactions in the batch B_h it is processing have been tentatively submitted. To support this design, transactions within a batch postpone the final submission check, and cross-shard transactions no longer block by sending local_fc messages. Instead, they send the tentatively submitted local_sp information during the synchronization phase. When a shard node confirms the start of its synchronization phase, it sends 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 during the tentative submission of each cross-shard transaction instance and their 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 in the batch B_h 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 T_i's decision is that it can be finally submitted, and lastFC_TID will be increased by one. Otherwise, it is still a tentative submission, and the leader only needs to include the final decision in the batch_commit message (lines 9 to 13). For a cross-shard transaction T_i, the leader sequentially checks all involved cross-shard instances. For each cross-shard instance, it checks whether all remote read set versions in its local_sp are consistent with the local read set versions in the local_sp of the cross-shard transaction instance for the corresponding shard. If there is any inconsistency, the cross-shard instance has read the wrong remote version and must be aborted and redone. Otherwise, the cross-shard instance can be finally committed. The leader also includes the cross-shard instance decision in the batch_commit message. If all cross-shard instances of a cross-shard transaction can be finally committed, the leader increments the lastFC_TID by one (lines 14 to 22). This check phase exploits the following property: the implicit semantics of the local_sp of the first cross-shard transaction involved in each shard within a batch are consistent with the local_fc, because the preceding local transactions can all be finally committed, ensuring that the local state read by the cross-shard transaction is correct. After completing the transaction check within the batch, the leader makes the transaction decision for each shard, which is sent during the commit 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] This invention (FairCross protocol) solves the efficiency and fairness issues 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 eventual consistency and strict determinism of transaction execution under the assumption of no global read-write set in sharding scenarios. FairCross proposes a batch transaction submission mechanism strategy to reduce the communication and processing overhead brought by cross-shard transactions. This invention can achieve multi-node scalability under conflicting loads in distributed scenarios, while ensuring the strict determinism of the execution plan, 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 appended claims.

Claims

1. A distributed and scalable deterministic transaction execution method for a sharded permissioned blockchain system, characterized in that: This method uses distributed multi-version tentative deterministic concurrency control and a batch transaction submission mechanism strategy to achieve multi-node scalable deterministic concurrent transaction execution under conflicting loads. The distributed multi-version tentative deterministic concurrency control sorts a batch of transactions within a block by pre-consensus and assigns a globally unique and automatically incrementing transaction sequence number, ensuring that the results of concurrent transaction execution are equivalent to those of serial execution by transaction sequence number. The batch transaction submission mechanism strategy uses batch processing to merge the submissions of multiple cross-shard transactions, evenly amortizing 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 are executed, and multiple read and write operations are performed on different states. When executing a read operation on transaction T, different execution mechanisms are used for intra-shard transactions and cross-shard 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 local shared storage and checks whether any transactions need to be aborted. For intra-shard transactions, the entire state is 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 for read dependencies. If a dependency with a sequence number greater than the transaction ID is found, the related 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. The message 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 after the largest submitted transaction number, check 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 received decision.

2. The distributed, scalable, deterministic transaction execution method for a sharded permissioned 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. The logic instructions include state reading and state writing. Step A12: When executing a state read operation, transaction T reads from the local read set and write set. If not, it determines whether the state belongs to an on-shard transaction. If so, it scans the state version list from the local shared storage and retrieves the state version that satisfies the maximum sequence number less than the sequence number of transaction T. The state version read by T is obtained and the transaction ID is recorded. At the same time, the read set is sent to the remote shard. If it belongs to a remote shard, T will block until the remote read set is received before continuing execution. 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, scalable, deterministic transaction execution method for a sharded permissioned 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 shared storage one by one. For intra-shard transactions, the entire state is written; for cross-shard transactions, only the state of the local shard is written. Step A22: Transaction T performs conflict detection on other transactions to check whether other transactions have missed reading the status of transaction T. This includes checking the read dependencies tracked by the previous state version of other transactions, finding transactions with a higher sequence number than transaction T in their read dependencies, and aborting the transaction. 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, scalable, deterministic transaction execution method for a sharded permissioned chain system according to claim 1, wherein: 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, 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 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 commit message 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 committed.

6. The distributed, scalable, deterministic transaction execution method for a sharded permissioned chain system according to claim 1, wherein: 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 of each transaction, the decision to hold a 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, scalable, deterministic transaction execution method for a sharded permissioned 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