A Cross-Slice Transaction Concurrency Processing Method

Abstract

The present invention discloses a method for concurrent processing of cross-shard transactions. The method can process cross-shard transactions through one-way communication without the help of a "coordinator". Through one-way communication between nodes, cross-region transactions are processed with the minimum communication overhead. While ensuring transaction consistency, this method avoids the problem of excessive delay in cross-shard transactions caused by multiple rounds of communication required by the traditional two-phase commit protocol. This method utilizes a fine-grained transaction rearrangement mechanism to optimize the execution efficiency of cross-shard transactions under transaction conflicts. By changing the order in which transactions obtain locks, the concurrency of in-block transaction execution is increased. At the same time, it can utilize the advantage of bandwidth to transmit data in parallel, ensuring that cross-shard transactions can obtain execution data preferentially as much as possible and reducing their blocking time.

Description

Technical Field

[0001] The present invention belongs to the technical field of distributed transactions and relates to a method for concurrent processing of cross-shard transactions. Background Art

[0002] The sharding technology was initially proposed to solve the problem of hardware performance bottlenecks in a single database. In the database, data is divided into multiple independent and unrelated parts according to certain principles, and then these independent data are placed on different servers, thereby alleviating the performance bottleneck problem of a single database.

[0003] The blockchain sharding technology improves the parallelism of the system by dividing the entire network into committees (hereinafter collectively referred to as shards). Transactions are processed in parallel by each shard, solving the problem of low scalability of traditional blockchains; small-scale independent consensus within the shard solves the problem of large overhead of the consensus network for large-scale clusters. In short, the blockchain sharding technology improves the performance of the blockchain and effectively expands the scale of the system. In an ideal situation, each transaction only accesses one shard to achieve the maximum parallelism of the system. However, in reality, due to the existence of cross-shard transactions that manipulate data in multiple shards, this poses challenges to system design.

[0004] In a blockchain system based on an account model, these cross-shard transactions are mainly processed through a base coordinator or communication protocol consensus. Some research uses two-phase locking and two-phase commit to solve the problem of communication between shards. In this method, the "coordinator" role in the two-phase commit protocol is assumed by a shard composed of many nodes, and the final decision is made using Byzantine fault-tolerant consensus; some other research ensures the consistency of transactions through cross-shard consensus. When processing a cross-shard transaction, only the primary node receives and verifies the 2f + 1 messages of each shard before transmitting the commit result to the relevant shard nodes, and the relevant nodes execute and commit the transaction. [1-3] 。

[0005] However, these two traditional cross-shard transaction processing methods still have some deficiencies. Currently, the execution of cross-shard transactions based on two-phase commit requires multiple rounds of communication between all participating shards. The time and network overhead brought by multiple rounds of communication not only cause high latency of cross-shard transactions but also block the execution of subsequent other transactions. In addition, to maintain data consistency, this method also introduces additional overhead for writing logs, further reducing the system's ability to process transactions. Especially in an actual shard system based on a Byzantine environment, the execution of cross-shard transactions will cause the throughput of the blockchain to collapse due to its poor performance. In addition, although the blockchain can effectively process low-conflict workloads, data contention under high-conflict workloads blocks cross-shard transactions, further degrading its performance in concurrent processing of cross-shard transactions. Summary of the Invention

[0006] To address the deficiencies of the prior art, the present invention proposes a method for concurrent execution of cross-shard transactions. This method can process cross-shard transactions through one-way communication without the help of a "coordinator". Specifically, all relevant shards of a cross-shard transaction will send their local states to other relevant shards to prepare for the execution of the cross-shard transaction. Then, based on the global order and the state transfer mechanism, the execution results of all shards are consistent and serializable. To make the method resilient to conflicts, the present invention also introduces a reordering mechanism, which refers to sorting the order in which transactions obtain lock permissions, that is, the reordering mechanism improves the concurrency of transaction execution and state transfer by changing the order in which transactions obtain lock permissions, further improving the performance of cross-shard transaction processing.

[0007] The global order means that all nodes in a system execute and commit transactions in a certain and consistent order.

[0008] In the scenario of state sharding, no single shard can obtain all state data, which results in the inability to read the corresponding state data when processing certain cross-shard transactions, thus preventing successful execution. The state transfer mechanism satisfies the execution conditions required by transactions through state data transmission between shards.

[0009] Since transactions are executed in parallel between shards, the execution results of each shard and even each node within a shard are independent of each other. The consistency of shard execution results means that for all nodes within a shard, their results need to be guaranteed to be consistent; for different shards, the order in which they commit transactions needs to be guaranteed to be consistent. Serializable means that the result of its concurrent execution needs to be equivalent to a certain transactional schedule, and in the present invention, this serializable schedule is the order in which each shard commits transactions.

[0010] The object of the present invention is achieved as follows: A method for concurrent execution / processing of cross-shard transactions is provided. When processing cross-shard transactions, only one-way communication is required to ensure transaction consistency, which is guaranteed by deterministic execution; the guarantee of transaction consistency with only one-way communication is reflected in steps 6, 7, and 8 of the present invention. At the same time, the concurrency of transaction execution and data transmission is improved through fine-grained reordering, while also enhancing the system's fault tolerance and recovery ability. The specific execution process of the method of the present invention includes the following specific steps:

[0011] Step 1: Construct a P2P cluster network, configure node identity information, and start the cluster machines.

[0012] The cluster is a set of server nodes in the network that undertake the same responsibilities; the node identity information includes node role, node IP, node ID, and public-private key; the node roles include consensus nodes and execution nodes; the node IP is used to represent the IP address of the server node; the node ID is used to uniquely identify the server node, and the public-private key is used for message encryption and authentication;

[0013] Step 2: Divide a single cluster into multiple shards (including consensus shards and execution shards) according to the organizational structure. Since the blockchain system receives transactions in inconsistent order, the consensus shard uses a consensus algorithm, such as PBFT, to determine the order of transactions received within a certain period of time, and packs these transactions into blocks and sends them to each execution shard. Each execution shard stores different state data; each consensus shard and / or execution shard respectively includes several nodes; each organization has at least one node participating in consensus in all consensus shards and at least one node participating in execution and storage in all execution shards, and each organization has a full copy of the data.

[0014] Step 3: The consensus shard receives transactions sent by the client and generates blocks to be executed through the Byzantine fault tolerance consensus protocol;

[0015] In the present invention, the consensus shard can adopt consensus algorithms such as PBFT, Raft, or Paxos. The consensus algorithm is only related to the trust assumption of the network and there is no obvious difference in the transaction execution stage; taking the PBFT consensus algorithm as an example, this algorithm first selects a certain node as the primary node through a rotation or random algorithm. Among them, each node records the consensus state of each node through a view, and the consensus state includes a list of primary nodes and secondary nodes. The client sends the request to the corresponding primary node, and the primary node is responsible for broadcasting the request to all other replica nodes. After all nodes complete processing the request, they return the processing results to the client. The client checks whether it has received at least f + 1 identical results from different nodes as the final result.

[0016] Step 4: Each node within the consensus shard sends the generated block to be executed to other execution nodes in the same organization as the consensus node;

[0017] After receiving and verifying the block obtained through consensus, the execution node analyzes whether the transaction is relevant to this node, which often needs to be judged according to the read-write set of the transaction, locks the transactions one by one using the sorting lock mechanism, and then performs a deterministic reordering on the lock request queue.

[0018] Before transaction execution, the execution node obtains the read / write set of all transactions through means such as static analysis and / or speculative execution of the transaction.

[0019] For simple transfer transactions, it is easy to use the sender's account address and the recipient's account address as the read-write set of the transaction, without the need to additionally execute the confirmation of the read-write set based on the transfer address. However, for more complex smart contracts, preprocessing of the read-write set is required. When the client sends a transaction, it first performs pre-execution, that is, by executing the transaction in advance to obtain the state address in the contract account address accessed by this transaction as the key value of the read-write set of this transaction. The state address is the storage path of the state data in the blockchain storage structure. The contract internally stores the mapping of the state and the state address, and the transaction can easily obtain the address corresponding to any state. According to the state address, the transaction can find the corresponding state data in the data managed by the contract. It should be noted that the blockchain storage structure stores the state data in the form of "state address - state data" which is a "key-value pair". At the same time, the determination of the read-write set here only needs to know the key value, that is, the state address of the transaction accessing the contract account, and it is not necessary to determine the state data stored or to be written at this state address, that is, the value, because only through the key value can the shard storing this state be determined, so as to further judge the relationship between this transaction and each execution shard.

[0020] The method of the present invention uses a sorting lock mechanism to deterministically execute transactions concurrently. In the blockchain scenario, the present invention takes the order of transactions within a block as the global order. The sorting lock mechanism sets up a lock manager to manage the requests of transactions for lock permissions on the state. The lock manager puts the access requests of each transaction into the corresponding request queue according to the global order, and grants the access rights to the transactions according to the request queue. The transaction can execute after obtaining all the locks. Finally, the relevant locks are released after the transaction is completed.

[0021] This method can not only enable parallel execution of transactions between multiple execution shards, but also allow concurrent execution of transactions within a shard. The sorting lock adds locks one by one according to the ascending order of the labels of the transactions in the consensus block, so that in case of conflicts, the transaction with a smaller subscript will definitely obtain the lock before the transaction with a larger subscript, ensuring that the results of concurrent execution of all nodes within the same shard are equivalent to the serial execution results determined according to the consensus shard order. A transaction can only execute after obtaining all the lock permissions; after the execution ends, the transaction will also release all the locks it occupies.

[0022] To achieve lower cross-shard transaction latency, the method of the present invention utilizes a fine-grained reordering mechanism to further optimize the cross-shard transaction execution method, increasing the concurrency of execution and transmission by prioritizing or delaying the lock requests of cross-shard transactions. After receiving a new block, the system scans all transactions within the block in ascending order of the transaction numbers within the transaction block. During each round of scanning, the system maintains a subset of transactions. If the traversed transaction has no conflict with any transaction in the transaction subset, the transaction is placed in the subset. After a round of traversal is completed, all transactions in the transaction subset are granted locks in parallel, and then the subset is cleared and the next round of traversal begins. This reordering mechanism locks non-conflicting transactions in parallel, so there will be no deadlock situation. This deterministic reordering strategy does not affect the consistency of the state.

[0023] The transaction reordering strategy introduces the concept of cross-shard transaction priority to reduce cross-shard transaction latency and improve the concurrency of processing cross-shard transaction data transmission.

[0024] Step 6: The execution node analyzes and executes the transaction. According to the read-write set of the transaction and the data partitioning of the shard, the execution node analyzes the transaction and divides it into three categories, namely:

[0025] (1) The key values of the transaction read-write set are not stored locally.

[0026] (2) The key values of the transaction read set are stored locally, and the key values of the write set are not stored locally.

[0027] (3) At least one key value data of the transaction write set is stored locally.

[0028] In the present invention, the third transaction characteristic, that is, "at least one key value data of the transaction write set is stored locally", involves the modification of the local state. The write set exactly reflects the state modification operation, so it only needs to be related to the write set.

[0029] Corresponding to the above different transaction types, this method also provides different processing methods

[0030] (a) For type (1), the execution node determines that the transaction does not belong to this node and discards the transaction.

[0031] (b) For type (2), the execution node transfers the local data corresponding to the key values of its own read set to other execution nodes belonging to the same organization according to the shard state distribution. Since there is no write operation locally for this transaction, the transaction is discarded.

[0032] (c) For type (3), in addition to transferring the local data corresponding to the key values of its own read set to other execution nodes belonging to the same organization according to the shard status distribution, the execution node also needs to wait for the remote data transferred from other shards, and then execute cross-shard transactions to modify the relevant status of the transaction write set.

[0033] The above data transfer methods all use P2P data transfer between nodes in the same organization to avoid the huge network overhead when broadcasting status data during cross-shard transaction processing. Nodes do not need to verify each piece of data one by one, improving the efficiency of data transfer.

[0034] Step 7: Each execution shard only stores transactions related to this shard and directly discards irrelevant transactions. Therefore, after each execution shard executes and commits a batch of transactions, it is necessary to separately reconstruct a new block stored within the shard for this batch of transactions, calculate the state of the block and the transaction Merkle root, encapsulate them in the block header, and send them to different nodes in the same shard. It is worth mentioning that this method dynamically adjusts the threshold of the number of transactions in the new block according to the throughput of the current system; when the throughput is high, the threshold is increased, and vice versa. Generally, the number of transactions in the new in-shard block is equal to the number of transactions generated by the consensus shard. The structure of the new in-shard block reconstructed by the execution node is the same as the structure of the block obtained through consensus, still including the block header and the transaction list. Among them, the block header includes information such as the hash value of the previous block, the hash value of the state number, the hash value of the transaction tree, and the timestamp. After the new block reconstruction is completed, the block is sent to different execution nodes in the same shard;

[0035] Step 8: When each node receives the same 2f + 1 messages for the new block from other nodes, it can confirm the new block and write it to local storage. When the blocks of the consensus shard are obtained by all execution shards, the local blocks can be deleted without storing all the block data. At the same time, the execution shards do not need to perform a complete Byzantine consensus on the new block. After the entire shard reaches a consensus on the reconstructed block, the reconstructed block is committed, and the cross-shard transaction processing ends.

[0036] This is similar to the "checkpoint" mechanism in PBFT. Through the "checkpoint" mechanism, nodes can regularly generate stable checkpoints, and the frequency of generating checkpoints can be determined by the system throughput. When a node generates a stable checkpoint, it broadcasts a "checkpoint" message to other nodes. If a node receives the same "checkpoint" message from 2f + 1 different nodes, this indicates that the node has reached a synchronous and consistent state with other majority nodes and successfully generated a stable checkpoint.

[0037] The method of the present invention reuses the on-chip communication of the reconstructed block to verify the correctness of the data received when processing cross-chip transactions. When the execution node detects that its block header information is different from the new block determined by other nodes, it redoes the transactions based on the snapshot of the previous stable checkpoint. In this process, it may be necessary to additionally execute some transactions that have nothing to do with local data to obtain the read value of the next transaction. The execution node restores to the correct state according to the deterministic execution strategy. At the same time, the execution node compares the remote data of other shards with the local data to detect malicious nodes and add them to the blacklist.

[0038] The beneficial effects of the present invention include: by adopting the one-way transmission strategy, the present invention realizes the processing of cross-chip transactions with low communication overhead, and through the fine-grained transaction reordering method, the concurrent performance is maximally improved.

[0039] Compared with the existing methods, taking the "two-phase commit" method as an example. The total throughput of the system adopting the method of "coordinator" is reduced by nearly 67% and 80% respectively under the cross-chip transaction ratios of 30% and 90%. While adopting the method of the present invention, a relatively high throughput can be maintained under any cross-chip transaction ratio. As the number of shards increases, the ratio of cross-chip transactions rises. And the total throughput of the system adopting the method of the present invention shows a linear growth, meeting the scalability of the system. Brief Description of the Drawings

[0040] Figure 1 It is the system architecture diagram of the present invention.

[0041] Figure 2 It is the flow chart of cross-chip transaction processing of the present invention.

[0042] Figure 3 It is the schematic diagram of the sorting lock in the present invention.

[0043] Figure 4 It is the flow chart of block reconstruction of the present invention.

[0044] Figure 5 It is the schematic diagram of data transmission of the present invention.

[0045] Figure 6 It is the schematic diagram of the transaction reordering method in the present invention.

[0046] Figure 7 It is the schematic diagram of the reordering method of the transaction after optimization in the present invention. Detailed Embodiment

[0047] Combined with the following specific embodiments and drawings, the present invention will be further described in detail. The processes, conditions, experimental methods, etc. for implementing the present invention, except for the content specifically mentioned below, are all common knowledge and well-known common sense in the art, and the present invention has no special restrictive content.

[0048] The present invention proposes an optimized cross - shard transaction execution method for sharded permission blockchains. Through one - way communication between nodes, it processes cross - area transactions with minimal communication overhead. While ensuring transaction consistency, this method avoids the problem of excessive cross - shard transaction latency caused by multiple rounds of communication required by the traditional two - phase commit protocol. This method utilizes a fine - grained transaction reordering mechanism to optimize the execution efficiency of cross - shard transactions under transaction conflicts. By changing the order in which transactions obtain locks, it improves the concurrency of in - block transaction execution. At the same time, it can utilize the advantage of bandwidth to transmit data in parallel, ensuring that cross - shard transactions can obtain execution data preferentially as much as possible and reducing their blocking time.

[0049] Figure 1 It is the system architecture diagram of the present invention based on cross - shard transaction concurrent processing technology. Except for modules with relatively low relevance to the present invention such as the transaction pool and consensus shards, the core content of this system is mainly the execution shards, specifically including a reordering module, a transaction processing module, and a storage module. The reordering module mainly optimizes transaction execution and state transmission by reordering transactions, and then passes the sorting result to the transaction processing module; the transaction processing module is responsible for transaction execution and transaction redo through a state recovery mechanism, especially for the processing of cross - shard transactions. The state recovery mechanism is mainly responsible for restoring the data of faulty nodes to be consistent with normal nodes, and finally submits the processing result to the storage module; the storage module is mainly responsible for block reconstruction and the detection of Byzantine nodes, and returns the transaction submission result to the transaction processing module.

[0050] Figure 2 It shows the process of the present invention for processing cross - shard transactions. For a transaction Ti, its read set is Ri and its write set is Wi. The determination of the transaction read - write set will be described later. After each execution shard obtains a batch of transactions, it will execute the transactions in the order determined by the consensus shard. If the read - write sets of a transaction both belong to the same execution shard, the present invention calls it a local transaction; if the read - write sets of a transaction belong to multiple different execution shards, the present invention calls it a cross - shard transaction. For local transactions, each execution shard only needs to execute them separately without interacting with other execution shards. For cross - shard transactions, the execution shard needs to interact with other shards to complete the corresponding operations. The relationship between a cross - shard transaction Ti and an execution shard ESj is divided into three categories: 1) Neither Ri nor Wi belongs to the execution shard ESj; 2) There is a state in Ri that belongs to the execution shard ESj, and there is no state in Wi that belongs to ESj; 3) There is a state in Wi that belongs to ESj, and it doesn't matter whether there is a state in Ri that belongs to ESj or not.

[0051] In case 1), when the execution shard processes the transaction Ti, it can directly discard it without any processing.

[0052] In case 2), transaction Ti needs to read data from shard ESj but will not write any data. The present invention refers to ESj as a transfer shard of transaction Ti because executing shard ESj only needs to be responsible for transferring part of the data. Of course, a transaction may have multiple transfer shards.

[0053] In case 3), transaction Ti needs to write part of the data to executing shard ESj. Therefore, the present invention refers to executing shard ESj as an update shard of transaction Ti. The relationship between a transaction and a shard can be easily determined according to the key of the read-write set. The processing flow of a cross-shard transaction Ti is as follows:

[0054] (1) Each transfer shard reads the local data and sends it to all the update shards. If there is a read set belonging to an update shard, the update shard also needs to transfer the data to other update shards;

[0055] (2) Each update shard waits for the read sets sent by the transfer shards;

[0056] (3) After each update shard collects all the data, it executes the transaction and writes the data to the local storage;

[0057] (4) Each update shard only writes the status data belonging to this shard and discards the update operations for other shards.

[0058] Since the consensus shard does not execute transactions, it is aborted when executing transactions. If a cross-shard transaction is aborted in a certain update shard, then this transaction will be aborted in all the update shards. This is because each update shard will obtain the same read set and the processing logic is the same, so the results obtained must also be the same.

[0059] As shown in the figure, T1, T2 and T3 are Figure 2 the three types of transactions mentioned above. The executing shard has the status data of Alice, and the update shard has the status data of Bob. First, T1 adds 10 to Bob. Since this transaction is only related to the update shard, the executing shard naturally discards T1. Secondly, T2 needs to read the status data of Alice and modify the status data of Bob. At this time, the original executing shard becomes a transfer shard and only needs to transfer the data <Alice, 100> to the update shard. Finally, both the executing shard and the update shard shown in the figure need to execute T3 because it will modify the statuses of both Alice and Bob. During the execution process, while the executing shard sends the status data <Alice, 100> to the update shard, the update shard will also send the status data <Bob, 120> to the executing shard. After the two shards obtain all the status data, they can execute T3 and finally write the transaction execution result to the storage module.

[0060] Figure 3 It shows the principle of the sorting lock used in the present invention. The sorting lock mechanism locks the state data accessed by transactions in advance according to the global transaction order, ensuring that only one transaction can access the data at the same time. A transaction can only be executed after obtaining the access rights to all state data. For details, see the figure. When a batch of transactions that have been sorted in advance according to the sorting lock mechanism are executed concurrently, if the order of transaction Ti appears before that of Tj, then for a certain conflicting state, transaction Ti will definitely obtain the lock before transaction Tj. Compared with optimistic concurrency control, although the use of the sorting lock will sacrifice a certain degree of concurrency, it ensures determinism.

[0061] As shown in the figure, T1 to T5 are 5 transactions. Locks are added to these transactions in sequence to obtain the lock request queues for execution shard 1 and execution shard 2. During execution, each state can only respond to the requests of one transaction. Therefore, when the system grants locks for the first time, only T1, T2, and T5 obtain all the locks. And T3 cannot obtain the read lock for state data c, and T4 cannot obtain the write lock for state data a. After T1 and T2 are executed, the system grants locks for the second time. At this time, T3 and T4 successfully obtain all the locks.

[0062] Figure 4 It shows the flow chart of the block reconstruction of the present invention. Whenever a certain number of transactions are executed (for example, every 1000 transactions are executed), the execution nodes in the execution shard repackage these transactions into a new block, sign it, and broadcast the block to other nodes. When each execution node receives the information of 2f + 1 new blocks and checks their block headers to confirm the hash values of their transaction roots and state roots. If they are the same as those of f + 1 pieces of information, it confirms the block and writes it into local storage. The confirmation of the reconstructed block does not require a complete PBFT consensus for the new block. When the consensus shard detects that the transactions in a certain block have been successfully submitted in all shards, it can delete the block. Therefore, it is not necessary to store all the block data. Once any execution node does not receive enough messages or detects that the information of the new block is different from that of other f + 1 nodes, it means that there are inconsistent results among the execution nodes in this shard, which may be caused by malicious attacks sending incorrect read sets or any software or hardware failures. At this time, the execution node independently redoes the transactions based on the snapshot of the previous stable checkpoint, and finally achieves data consistency among the nodes. It should be noted that the reconstructed block is endorsed by f + 1 honest nodes, ensuring data correctness; at the same time, because data cannot be obtained from other shards, redoing transactions requires executing some transactions that do not belong to itself to meet the cross-shard transaction execution conditions.

[0063] As shown in the figure, there is a sharding execution with four execution nodes. After each node executes k transactions from Tn to Tn+k, it performs block reconstruction. First, the k transactions are packaged as the transaction list of the new block. Subsequently, data such as the transaction root hash value and the state root hash value of this batch of transactions are calculated as the block header of the new block. After generating the new block, the block information is attached with its own signature and broadcast to different nodes within the same shard to confirm the new block. After receiving the information of f+1 identical blocks, the block is written into local storage.

[0064] Conversely, it requests the snapshot of the previous stable checkpoint from other shards. According to the snapshot information (the data correctness is guaranteed by f+1 honest nodes), cross-shard transactions and in-shard transactions that depend on the write set of cross-shard transactions are redone. After the execution is completed, the block is written into local storage.

[0065] Figure 5 The data transmission principle of the present invention is shown. When processing cross-shard transactions, the transmitting shard needs to transmit the current latest state data to the updating shard. Each organization deploys corresponding nodes in each shard. When the transmitting shard needs to send the state data to the updating shard, each node only needs to send its own data to the nodes in the updating shard that belong to the same organization. For possible malicious situations, verification only needs to be performed once when reconstructing the block. This not only avoids a large amount of data broadcasting but also avoids additional data verification, improving the efficiency of data transmission.

[0066] When processing cross-shard transactions, for example Figure 1 T3, T4, and T5 in Figure 5 , the state transmission principle between shards is as shown in

[0067] Figure 6 . In organization A, node A in shard 1 only transmits the state data required for executing transactions T3, T4, and T5 to node A in shard 2, and vice versa. The state transmission between nodes in different shards within other organizations is also as described above. This method eliminates unnecessary large amounts of data broadcasting. The schematic diagram of the transaction reordering method of the present invention is shown. In order to further improve the concurrency of transactions, this method dynamically adjusts the order in which transactions obtain access permissions by detecting the conflict relationship between the read-write sets of transactions, so as to obtain higher parallel execution performance.

[0068] As shown in the figure, due to the sorting lock mechanism, when locking in the original order, T3 cannot obtain access to state c before T2 executes, and T5 cannot obtain access to state e before T4 executes. This causes the system to process transactions serially. Therefore, the present invention adopts a transaction reordering scheme with a lock granularity, advancing the lock request queue of T3 for state c and also advancing the lock request queue of T5 for state e. In this way, T1, T3, and T5 can execute in parallel. The lock mechanism ensures the serializability of the execution results; at the same time, processing transactions in a determined order with the same reordering operation process will result in consistent execution results.

[0069] Figure 7 The figure shows the schematic diagram of the optimized reordering method of the present invention. This method introduces the concept of the priority of cross-shard transactions, gives priority to cross-shard transactions for execution, and sends the current data status to other shards. Through this method, not only can cross-shard transactions execute in parallel, but their local data can also be transmitted in parallel.

[0070] As shown in the figure, T1 and T4 are cross-shard transactions, and T2 and T3 are intra-shard transactions. When the execution node processes cross-shard transactions, it needs to transfer multiple states, such as state a and state b in SA, and state data d and state data e in SB. The original sorting scheme locks the transactions in order, making it impossible for the two cross-shard transactions T1 and T4 to be transmitted simultaneously, which significantly increases the frequency of interaction between shards. Starting from this point, the optimized reordering scheme optimizes the state transfer efficiency of the two cross-shard transactions, enabling SA to concurrently transmit state a and b during transmission, while SB can also concurrently transmit state d and e. This method reduces the frequency of state transmission and also takes into account the concurrency of message transmission.

[0071] References

[0072] [1]E.Kokoris-Kogias, P.Jovanovic, L.Gasser, N.Gailly, E.Syta, and B.Ford, “Omniledger: A secure, scale-out, decentralized ledger via sharding,” in IEEE Symposium on Security and Privacy. IEEE Computer Society, 2018, pp.583–598.

[0073] [2]H. Dang, T. T. A. Dinh, D. Loghin, E. Chang, Q. Lin, and B. C. Ooi, “Towards scaling blockchain systems via sharding,” in SIGMOD Conference. ACM, 2019, pp. 123–140.

[0074] [3]M. J. Amiri, D. Agrawal, and A. E. Abbadi, “Sharper: Sharding permissioned blockchains over network clusters,” in SIGMOD Conference. ACM, 2021, pp. 76–88.

[0075] The protection scope of the present invention is not limited to the above embodiments. Without departing from the spirit and scope of the inventive concept, variations and advantages that can be conceived by those skilled in the art are included in the present invention, and the scope of protection is defined by the appended claims.

Claims

1. A cross-chip transaction concurrent processing method, characterized in that, When the method processes cross-shard transactions, it achieves transaction consistency through one-way communication and then optimizes the execution efficiency through fine-grained transaction reordering, including the following steps: Step 1: Construct a P2P cluster network, configure node identity information, and start the cluster machines; Step 2: Divide a single cluster into multiple shards including a consensus shard and execution shards according to the organizational structure, and each execution shard stores different state data; Step 3: The consensus shard receives transactions sent by the client and generates blocks to be executed through the Byzantine Fault Tolerance consensus protocol; Step 4: Each node in the consensus shard sends the generated blocks to be executed to other execution nodes in the same organization as the consensus node; Step 5: After receiving and verifying the blocks obtained through consensus, the execution nodes lock each transaction one by one using the sorting lock mechanism according to the read-write sets of the transactions, and then perform deterministic reordering on the lock request queue; Step 6: The execution nodes analyze and execute the transactions. During the execution process, different transaction processing is performed according to the transaction read-write sets and the data division of the shards; In Step 6, the execution nodes analyze the transactions and divide them into three categories, namely: the key-value data of the transaction read-write sets are not stored locally; the key-value data of the transaction read set are stored locally, while the key-value data of the write set are not stored locally; at least one key-value data of the transaction write set is stored locally; The execution nodes process the transactions according to the transaction types; for transactions where the key-value data of the read-write sets are not stored locally, the execution nodes discard the transactions; for transactions where the key-value data of the read set are stored locally while the key-value data of the write set are not stored locally, the execution nodes transmit the states corresponding to the key-values of their own read sets to other execution nodes in the same organization according to the shard state distribution, and finally discard the transactions; for transactions where at least one key-value data of the write set is stored locally, in addition to transmitting their own state data to other execution nodes in the same organization, they also need to wait for the state data of other shards and execute cross-shard transactions; Transaction processing transmits state data through P2P among nodes in the same organization, avoiding the huge network overhead when broadcasting state data during cross-shard transaction processing. Nodes do not need to verify data item by item, improving the efficiency of data transmission; Step 7: After executing and submitting the transactions, the execution nodes reconstruct new blocks within a batch of transaction shards, calculate the state of the blocks and the transaction Merkle root, and encapsulate them in the block header and send them to different nodes in the same shard; Step 8: After the execution nodes receive 2f + 1 identical reconstructed block information, the entire shard reaches a consensus on the reconstructed blocks, and then submits the reconstructed blocks, and the cross-shard transaction processing ends.

2. The cross-chip transaction concurrent processing method according to claim 1, wherein In Step 1, the cluster is a set of server nodes that undertake the same responsibilities in the network; the node identity information includes node roles, node IPs, node IDs, and public-private keys; the node roles include consensus nodes and execution nodes; the node IPs are used to represent the IP addresses of the server nodes; the node IDs are used to uniquely identify the server nodes, and the public-private keys are used for encrypting messages and identity verification.

3. The cross-chip transaction concurrent processing method according to claim 1, wherein, In step 2, the consensus shard determines the order of transactions received within a certain period through a consensus algorithm, and packs these transactions into blocks and sends them to each execution shard; each execution shard stores different state data; each consensus shard and / or execution shard includes several nodes respectively; each organization has at least one node participating in consensus in all consensus shards, at least one node participating in execution and storage in all execution shards, and each organization has a full copy of the data.

4. The cross-chip transaction concurrent processing method according to claim 1, characterized in that, In step 5, before transaction execution, the execution node obtains the read / write sets of all transactions through means including static analysis and / or speculative execution of the transactions; uses a sorting lock mechanism to ensure deterministic concurrent execution of transactions through a global order; in the blockchain scenario, the order of transactions within a block is used as the global order; the sorting lock mechanism sets up a lock manager to manage requests for lock permissions of transactions on the state; the lock manager puts the access requests of each transaction into the corresponding request queue according to the global order, and grants access rights to transactions according to the request queue, and a transaction can execute after obtaining all the locks; finally, the relevant locks are released after the transaction is completed. In step 5, a fine-grained lock reordering mechanism is used to reorder the transaction requests in the lock request queue, and the concurrency of execution is increased by prioritizing or delaying some lock permission requests; by detecting the reordered request queue, the occurrence of deadlocks is prevented; the reordering strategy does not affect the consistency of the state.

5. The cross-chip transaction concurrent processing method according to claim 1, characterized in that, In step 7, after each execution shard finishes executing the transactions, it only stores the transactions related to this shard and directly discards the irrelevant transactions; therefore, each execution shard needs to regenerate the block structure and store the Merkle root stored at the bottom layer in the block header.

6. The cross-chip transaction concurrent processing method according to claim 1, wherein, In step 8, when each node receives messages from 2f + 1 other nodes regarding the new block, it can confirm the block and write it into local storage; when the block of the consensus shard is obtained by all execution shards, the local block can be deleted, the consensus shard does not need to store all the block data, and the execution shard does not need to perform a complete Byzantine consensus on the new block.

7. The cross-chip transaction concurrent processing method according to claim 6, wherein, When the execution node detects that its block header information is different from the new block determined by other nodes, it redoes the transactions based on the snapshot of the previous stable checkpoint, and the execution node restores to the correct state according to the deterministic execution strategy; at the same time, the execution node compares the remote data of other shards with the local data to detect malicious nodes and add them to the blacklist.

Images