Cross-fragment transaction and fragment migration method and system

Abstract

The invention discloses a cross-fragmentation transaction and fragmentation migration method and system, and relates to the technical field of transaction methods, and the method comprises the following steps: for a transaction input into a network, if accounts of a payer and a payee are in one fragmentation, carrying out an on-chip transaction; if the account of the payer and the account of the payee do not belong to the same fragment, cross-fragment transaction processing is carried out, and the cross-fragment transaction processing comprises the steps of main fragment transaction distribution; verifying transactions in the fragments; carrying out cross-fragment transaction verification; and submitting the cross-fragment transaction. According to the invention, the introduction of the block chain fragmentation technology can enable the block chain network to maintain the decentration characteristic, and achieve higher throughput and lower transaction delay at the same time.

Description

Technical Field

[0001] The present invention relates to the technical field of transaction methods, and in particular to a method and system for cross-shard transaction and shard migration. Background Art

[0002] At present, the main solutions to the scalability problem of blockchain include Lightning Network and State Channels, sharding technology, DAG distributed ledger, etc. Among them, Lightning Network and State Channel adopt centralized off-chain execution solutions, which cause poor security and user experience, resulting in their inability to be widely used on blockchain. At present, mainstream blockchains such as EOS, Ethereum, Cosmo, etc. mainly adopt sharding and multi-chain methods to improve performance.

[0003] The basic idea of ​​sharding technology is to divide a large-scale blockchain network into multiple smaller sub-networks, or "shards," through a divide-and-conquer strategy. Each shard is responsible for processing a portion of transactions and smart contracts, so that different transactions can be processed in parallel, significantly improving the throughput and efficiency of the entire system.

[0004] EOS uses the IBC (InterBlockchain Communication) protocol for cross-chain communication through multi-chain technology, which simplifies the generation of proof of message existence and proof of message sequence to achieve cross-chain communication. Developers run their own Dapps by deploying a side chain separately outside the main chain and use their own tokens for transactions. Its multi-chain architecture is achieved through the side chain solution, through the two-way peg technology, rather than improving the scalability of the main chain itself. Ethereum uses sharding technology and the UTXO model for cross-shard communication. It creates a receipt with a receipt ID to enable users to trade on the main chain. UTXO is suitable for trading scenarios. The communication protocol implemented by Cosmos can support inter-chain interconnection and realize asset transfer. The central chain Hub records the transactions of all other Zones. Each Zone keeps the status synchronized with the Hub. Different Zones complete message transmission by publishing message packets on the Hub. If a single point failure occurs in its core chain Hub, the entire blockchain will fail.

[0005] This study was supported by the National Key R&D Program of China (No. 2022YFB2703500) and the Key R&D Program of Yunnan Province (No. 202303AC100003). Summary of the invention

[0006] In view of the problems existing in the existing cross-shard transactions and shard migration systems, the present invention is proposed.

[0007] In order to solve the above technical problems, the present invention provides the following technical solutions:

[0008] In a first aspect, an embodiment of the present invention provides a method for cross-shard transactions and shard migration, which includes the following steps:

[0009] For transactions entering the network:

[0010] If the payer and payee accounts are both in the same shard, an intra-shard transaction is performed;

[0011] If the payer and payee accounts do not belong to the same shard, a cross-shard transaction is processed.

[0012] As a preferred solution of the method for cross-shard transaction and shard migration of the present invention, the processing steps of cross-shard transaction include:

[0013] Primary shard transaction allocation;

[0014] Intra-shard transaction verification;

[0015] Cross-shard transaction verification;

[0016] Cross-shard transaction submission.

[0017] As a preferred solution of the cross-shard transaction and shard migration method of the present invention, wherein: the primary shard transaction allocation includes:

[0018] The main shard distributes transactions in the network to the corresponding shards according to transaction input and output. Each account has a public key and a private key.

[0019] The primary shard packages the transactions and injects them into the transaction pool corresponding to the shard. During this process, the primary shard packages the transactions into blocks and waits for verification.

[0020] As a preferred solution of the cross-shard transaction and shard migration method of the present invention, wherein: the intra-shard transaction verification includes:

[0021] The shard node reads the transaction from the transaction pool. For cross-shard transactions, it checks whether the amount in the account is greater than or equal to the transaction amount:

[0022] If the account balance is insufficient, the node considers the transaction failed and sends a message to the leader in the shard;

[0023] If the account balance is sufficient, the amount in the account will be locked and a success message will be sent back to the leader node;

[0024] When the number of successful transaction messages received by the leader node is greater than 2f+1, the transaction verification in shard 1 is completed;

[0025] At this time, Shard 2 also performs account verification and runs the consensus protocol within the shard.

[0026] As a preferred solution of the cross-shard transaction and shard migration method of the present invention, the cross-shard transaction verification includes:

[0027] When Shard 1 and Shard 2 complete the transaction verification within the shard, they communicate with the main shard and send a preTx message to the main shard;

[0028] Among them, the preTx message contains the signature information of the nodes in the shard;

[0029] The master node verifies the signature information. When the verification succeeds, the master shard sends a commit message to shard 1 and shard 2 respectively, and the two shards complete the cross-shard transaction verification.

[0030] As a preferred solution of the cross-shard transaction and shard migration method of the present invention, wherein: the cross-shard transaction submission includes:

[0031] When Shard 1 and Shard 2 receive the commit message from the primary shard, they submit the transaction respectively to complete the account status update;

[0032] If no commit message is received, the transaction is considered failed and both parties roll back the retained status information.

[0033] As a preferred solution of the method for cross-shard transaction and shard migration of the present invention, when receiving preTx, the nodes in the shard execute the steps including:

[0034] Extract the input address in the preTx transaction, obtain the public key of the input account, perform digital signature identity verification, and continue to execute the transaction if the signature verification is successful. Otherwise, the transaction is considered to have failed and discarded.

[0035] Add the preTx transaction that has passed identity authentication to the local transaction pool and wait for the transaction to be packaged into a block;

[0036] After receiving preTx, the shard will reach internal consensus and confirm the transaction;

[0037] After completing the preTx confirmation, enter the account to complete the account update and update the fields in the local MPT.

[0038] In a second aspect, an embodiment of the present invention provides a system for cross-shard transactions and shard migration, which includes a transaction processing module, a digital signature identity authentication module, a shard internal consensus module, and an account status update module;

[0039] The transaction processing module is used to determine whether the transaction is an intra-shard transaction or a cross-shard transaction, and perform corresponding processing;

[0040] The digital signature identity authentication module is used to extract the input address in the preTx transaction and obtain the public key of the input account for digital signature identity authentication;

[0041] The shard internal consensus module is used to reach consensus and confirm transactions within the shard;

[0042] The account status update module is used to complete the account update after preTx confirmation and update the fields in the local MPT.

[0043] In a third aspect, an embodiment of the present invention provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, wherein: when the processor executes the computer program, it implements any step of the above-mentioned cross-shard transaction and shard migration method.

[0044] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, any step of the above-mentioned cross-shard transaction and shard migration method is implemented.

[0045] The beneficial effects of the present invention are as follows: the introduction of blockchain sharding technology can enable the blockchain network to achieve higher throughput and lower transaction latency while maintaining the decentralized characteristics. However, sharding technology also faces a series of challenges, such as cross-shard communication, data validity, and data availability. This paper proposes a cross-shard transaction protocol and shard migration strategy to address the atomicity and latency issues of cross-shard transactions. This paper introduces state node sharding to save the global state, verify cross-shard transactions, and migrate node states. According to the protocol, the existing state storage structure is expanded, combined with transaction locking and rollback mechanisms to ensure transaction atomicity, and dynamic sharding and node migration are performed through global state sharding. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. Among them:

[0047] Figure 1 A cross-shard transaction block for cross-shard transactions and shard migration methods.

[0048] Figure 2 Common blockchain data structures that provide a method for cross-shard transactions and shard migration.

[0049] Figure 3 State block data structure for cross-shard transactions and shard migration methods.

[0050] Figure 4 Inter-node transaction graph for cross-shard transactions and shard migration methods.

[0051] Figure 5 A cross-shard transaction flow chart for cross-shard transactions and shard migration methods.

[0052] Figure 6 Schematic diagram of transaction locking for cross-shard transactions and shard migration methods.

[0053] Figure 7 The block structure containing the preshardlist is a method for cross-shard transactions and shard migration. DETAILED DESCRIPTION

[0054] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the drawings of the specification. Obviously, the described embodiments are part of the embodiments of the present invention, but not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary persons in the art without creative work should fall within the scope of protection of the present invention.

[0055] In the following description, many specific details are set forth to facilitate a full understanding of the present invention, but the present invention may also be implemented in other ways different from those described herein, and those skilled in the art may make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0056] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The term "in one embodiment" that appears in different places in this specification does not necessarily refer to the same embodiment, nor does it refer to a separate or selective embodiment that is mutually exclusive with other embodiments.

[0057] The present invention is described in detail with reference to schematic diagrams. When describing the embodiments of the present invention, for the sake of convenience, the cross-sectional diagrams showing the device structure will not be partially enlarged according to the general scale, and the schematic diagrams are only examples, which should not limit the scope of protection of the present invention. In addition, in actual production, the three-dimensional dimensions of length, width and depth should be included.

[0058] At the same time, in the description of the present invention, it should be noted that the directions or positional relationships indicated by the terms "upper, lower, inner and outer" are based on the directions or positional relationships shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific direction, be constructed and operated in a specific direction, and therefore cannot be understood as limiting the present invention. In addition, the terms "first, second or third" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0059] In the present invention, unless otherwise clearly specified and limited, the terms "install, connect, connect" should be understood in a broad sense, for example: it can be a fixed connection, a detachable connection or an integral connection; it can also be a mechanical connection, an electrical connection or a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0060] Example 1

[0061] First of all, it should be stated that the sharding protocol in this article is based on the account / balance model. The account-based sharding system maps accounts to the network. The scheme takes the payer's address, the payee's address, and the transaction amount as input. The sharding based on the account balance can find the corresponding payer shard NetworkA and payee shard NetworkB. If the payer and the payee are in the same network, the network can quickly update the ledger. However, if the two accounts are in different network shards, they must both communicate and perform cross-shard transactions.

[0062] For each round of consensus, the leader of a normal shard can package internal transactions and propose a new block called an internal block. The internal block can then be committed through a BFT protocol (such as PBFT), similar to the intra-shard consensus in traditional sharding. In contrast, the leader of the primary shard can package cross-shard transactions and propose a new cross-shard block associated with the states of multiple normal shards. If the block is directly submitted by a node in the primary shard through a BFT protocol and transferred to the relevant normal shard, then the block may conflict with other blocks submitted in the associated shard in the same consensus round.

[0063] Reference Figure 1 to Figure 7 , which is the first embodiment of the present invention, and provides a method for cross-shard transaction and shard migration, comprising the following steps:

[0064] For transactions entering the network:

[0065] If the payer and payee accounts are both in the same shard, an intra-shard transaction is performed;

[0066] If the payer and payee accounts do not belong to the same shard, a cross-shard transaction is processed.

[0067] like Figure 2 The following figure shows the common block structure and account status. A block usually consists of two parts: a block header and a block body. The account state tree (MPT, Merkle Patricia Tree) is maintained locally by the node and is not directly included in the block. In the block header, the parent block hash points to the hash value of the previous block, ensuring the immutability and chain structure of the blockchain. The timestamp records the time when the block was created. The Merkle root of the transaction tree (Transactions Merkle Root) constructs all transactions in the block body into a Merkle tree, and saves the root hash value of the tree in the block header to verify whether the transactions in the block body are complete and have not been tampered with. The Merkle root of the state tree (State Merkle Root or State Root) is the root hash value of the account state tree (MPT). When all transactions are executed, the node will update its local state tree and calculate the new state root hash value as the checksum of the global account state. In the Block Body, the TransactionsList contains all transactions executed in the block. The Account Status Tree (MPT) is a data structure maintained locally by the node, which is used to store the status information of all accounts (such as balance, stored data, contract code, etc.). When the node synchronizes to a new block, it will try to execute the transactions in the block body and update its local MPT according to the results of the transactions. After executing all transactions, the node will calculate the root hash value of the new MPT (i.e., the new stateroot), and the node will compare this new stateroot with the stateroot in the new block header. If the two are the same, it means that the local account status is consistent with the global account status; if they are different, it means that an error or inconsistency occurred during the transaction execution or status update process.

[0068] The data structure shown in the figure is used to save confirmed transactions, unfinished cross-shard state migration transactions, and unfinished inter-user transactions. In the blockchain under the sharding scenario, it is indeed necessary to expand the traditional MPT structure to adapt to the needs of the sharding architecture. The introduction of the Shard field, the Hash of Shard field, and the crossRoot field solves the problem of cross-shard transaction and state synchronization. In the sharding scenario, each node only needs to synchronize the data of the shard in which it is located. When a new block is confirmed, the node executes the transactions in the block and updates the account status in its local MPT. The node then calculates the new MPT root hash and compares it with the stateroot in the new block header to ensure the consistency of the global state. For cross-shard transactions, nodes need to coordinate communication between multiple shards. In the prepare phase, the initiator shard sends the transaction information and lock information to the target shard. In the commit phase, if all shards confirm the validity of the transaction, the transaction will be formally submitted and the MPT status of the relevant shards will be updated.

[0069] The processing steps of cross-shard transactions include:

[0070] Primary shard transaction allocation;

[0071] The main shard transaction allocation includes:

[0072] The main shard distributes transactions in the network to the corresponding shards according to transaction input and output. Each account has a public key and a private key.

[0073] The primary shard packages the transactions and injects them into the transaction pool corresponding to the shard. During this process, the primary shard packages the transactions into blocks and waits for verification.

[0074] Intra-shard transaction verification;

[0075] The intra-shard transaction verification includes:

[0076] The shard node reads the transaction from the transaction pool. For cross-shard transactions, it checks whether the amount in the account is greater than or equal to the transaction amount:

[0077] If the account balance is insufficient, the node considers the transaction failed and sends a message to the leader in the shard;

[0078] If the account balance is sufficient, the amount in the account will be locked and a success message will be sent back to the leader node;

[0079] When the number of successful transaction messages received by the leader node is greater than 2f+1, the transaction verification in shard 1 is completed;

[0080] At this time, Shard 2 also performs account verification and runs the consensus protocol within the shard.

[0081] Cross-shard transaction verification;

[0082] The cross-shard transaction verification includes:

[0083] When Shard 1 and Shard 2 complete the transaction verification within the shard, they communicate with the main shard and send a preTx message to the main shard;

[0084] Among them, the preTx message contains the signature information of the nodes in the shard;

[0085] The master node verifies the signature information. When the verification succeeds, the master shard sends a commit message to shard 1 and shard 2 respectively, and the two shards complete the cross-shard transaction verification.

[0086] Cross-shard transaction submission;

[0087] The cross-shard transaction submission includes:

[0088] When Shard 1 and Shard 2 receive the commit message from the primary shard, they submit the transaction respectively to complete the account status update;

[0089] If no commit message is received, the transaction is considered failed and both parties roll back the retained status information.

[0090] Unlike other cross-shard transaction solutions, this paper implements parallel execution of sub-transactions. In traditional solutions, sub-transactions are executed in shard 2 only after they are successfully verified in shard 1, which increases transaction latency. The parallel execution solution can shorten this process, but a rollback operation is required when transaction verification fails.

[0091] The process of processing intra-shard and cross-shard transactions in this article is as follows Figure 4 As shown in Figure 2. Since the primary shards store all the meta files of each shard, they know which shard the transaction should be sent to for processing. Figure 5 As shown in the figure, when the main shard receives a transaction message from a user, it generates a block with the transaction and forwards it to the corresponding responsible shard. The internal consensus algorithm of the shard reaches a consensus on the transaction block, including the result of the shard member signature, which is returned to the main shard through the res message. The main committee then checks the res message and confirms the transaction and responds to the user based on the consensus result.

[0092] When a cross-shard transaction is conducted, when the primary shard receives the user's cross-shard transaction message, the primary shard divides it into two intra-shard transactions according to the two-phase commit principle - prepare transactions (Prepare_Tx) and confirm transactions (Commit_Tx) to ensure the consistency of the distributed ledger. In the first preparation phase, the primary shard sends a Prepare_Tx message to all shards involved in the cross-shard transaction and receives a res message from the shard, which includes the results of the Prepare_Tx execution from each shard. In the second commit phase, the reference peer sends a Commit_Tx message to complete the commit using the results of the first phase, and then receives a res message indicating whether the commit is complete. When the data block containing the cross-shard transaction is committed, a notification is sent to the user. When processing cross-shard transactions, the relevant data is locked and cannot be accessed by other transactions. This approach ensures the consistency of the distributed ledger at the expense of system availability.

[0093] After receiving preTx, the nodes in the shard execute the following steps:

[0094] Extract the input address in the preTx transaction, obtain the public key of the input account, perform digital signature identity verification, and continue to execute the transaction if the signature verification is successful. Otherwise, the transaction is considered to have failed and discarded.

[0095] Add the preTx transaction that has passed identity authentication to the local transaction pool and wait for the transaction to be packaged into a block;

[0096] After receiving preTx, the shard will reach internal consensus and confirm the transaction;

[0097] After completing the preTx confirmation, enter the account to complete the account update and update the fields in the local MPT.

[0098] When the amount in the input account is locked, execute the transfer operation of the transaction amount:

[0099] After the internal consensus of the shard where the input account node is located is completed, a transaction confirmation message is sent to the main shard, which contains the transaction confirmation signature. The main shard verifies the internal signature set of the shard in the confirmation message. When the number of legitimate signatures is greater than half of the number of nodes, the authentication is successful to avoid double-spending attacks.

[0100] The primary shard packages Commit_Tx into the transaction pool, waiting to obtain transactions to be packaged into blocks.

[0101] After receiving Commit_Tx, the shard will reach internal consensus and confirm the transaction.

[0102] After completing Commit_Tx confirmation, the input and output accounts complete the account update and update the fields in the local MPT:

[0103] After the shard where the output account is located executes the account update, it sends the confirmation signature to the primary shard. The primary shard verifies the signature set and the authentication is completed when the number of confirmation signatures is greater than half of the number of shard nodes.

[0104] When an authentication failure occurs during the authentication signature process, that is, the number of legal signatures cannot meet the requirement of being greater than half of the number of nodes, the transaction is considered to have failed and a rollback operation is performed on the transaction.

[0105] In the dynamic sharding process, when the allocation of nodes needs to change (for example, due to node failure, network changes, or load balancing needs), it becomes particularly important to ensure the security and efficiency of the system. In this process, the overhead of node configuration and data migration and downloading shard historical block data can be huge. To solve this problem, the solution is to update the latest global account status through the state block. Compared with the transaction block that stores transaction data, the state block of the shard records the latest information in the shard's ledger, including account addresses and account status (including data structures such as balances and nonce). At the beginning of the reconfiguration, the leader of the shard will traverse all transaction blocks in the last state block and establish a mapping between user account status and addresses.

[0106] When the members in the primary shard finish the first phase, the system will enter the process of generating the signature list of the status block for the next period. After receiving the status block from the leader node of the common shard, the primary shard node will broadcast it to other members in the primary shard. All nodes in the primary shard will verify the collected status blocks of each shard and verify their signature sets. After the verification is completed, the status of each shard is merged, and each node in the primary shard signs it and broadcasts it to other nodes. Each shard reads the status block of the primary shard, and writes the local ledger status after checking the signature set of the synthesized complete block. After successful verification, switch to the next phase by starting to execute a new transaction shard.

[0107] The primary shard node broadcasts the current state of the system and the latest shard adjustment results calculated based on the dynamic sharding algorithm to other primary shard nodes. After verifying the correctness of the shard state, other members sign and return the signature to the leader. When the leader collects signatures from more than a certain number of primary shard members, it generates a valid shard state, which includes a new round of shard results and a signature set from most primary shard members. The leader then broadcasts the block to all nodes in the system, and after receiving the block, the nodes in the adjusted shard are dynamically adjusted according to the latest shard state.

[0108] To switch to a new era, member nodes need to submit their identity information (including public keys, IP addresses, etc.) to the primary shard node for information synchronization. The primary shard node checks the information and runs the PBFT algorithm to reach consensus on the block. When the node identity information is verified by consensus on the primary shard node, the node identity authentication is completed.

[0109] When transactions in the system are concentrated in a few shards, while most of the other shards have few transactions. Without the redistribution of shards, the throughput of the system will decrease under this unbalanced load. Nodes in the shards with more transactions process a higher number of transactions, while nodes in the remaining shards can only process a lower number of transactions. Therefore, dynamic sharding in the system helps to rebalance the transaction load and improve system performance.

[0110] In order to record the information of each shard in the previous epoch in the status block, a hash list is needed to record it. The field preShardList is added to the block header to record the hash value of each shard. Its block structure is as follows: Figure 7 shown.

[0111] In summary, the introduction of blockchain sharding technology can enable blockchain networks to achieve higher throughput and lower transaction latency while maintaining decentralized characteristics. However, sharding technology also faces a series of challenges, such as cross-shard communication, data validity, and data availability. This paper proposes a cross-shard transaction protocol and shard migration strategy to address the atomicity and latency issues of cross-shard transactions. This paper introduces state node sharding to save the global state, verify cross-shard transactions, and migrate node states. According to the protocol, the existing state storage structure is expanded, combined with transaction locking and rollback mechanisms to ensure transaction atomicity, and dynamic sharding and node migration are performed through global state sharding.

[0112] Example 2

[0113] Based on the first embodiment, this embodiment further provides a system for cross-shard transactions and shard migration, including a transaction processing module, a digital signature identity authentication module, a shard internal consensus module, and an account status update module;

[0114] The transaction processing module is used to determine whether the transaction is an intra-shard transaction or a cross-shard transaction, and perform corresponding processing;

[0115] The digital signature identity authentication module is used to extract the input address in the preTx transaction and obtain the public key of the input account for digital signature identity authentication;

[0116] The shard internal consensus module is used to reach consensus and confirm transactions within the shard;

[0117] The account status update module is used to complete the account update after preTx confirmation and update the fields in the local MPT.

[0118] This embodiment also provides a computer device, which is suitable for the method of cross-shard transactions and shard migration, including a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute computer-executable instructions to implement the method of cross-shard transactions and shard migration proposed in the above embodiment.

[0119] The computer device may be a terminal, and the computer device includes a processor, a memory, a communication interface, a display screen and an input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be achieved through WIFI, an operator network, NFC (near field communication) or other technologies. The display screen of the computer device may be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device may be a touch layer covering the display screen, or a key, trackball or touchpad provided on the housing of the computer device, or an external keyboard, touchpad or mouse, etc.

[0120] This embodiment also provides a storage medium on which a computer program is stored. When the program is executed by a processor, the method for realizing cross-shard transactions and shard migration as proposed in the above embodiment is implemented.

[0121] The storage medium proposed in this embodiment and the data storage method proposed in the above embodiment belong to the same inventive concept. The technical details not fully described in this embodiment can be found in the above embodiment, and this embodiment has the same beneficial effects as the above embodiment.

[0122] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present invention, which should all be included in the scope of the claims of the present invention.

Claims

1. A method for cross-shard transactions and shard migration, characterized by: The following steps are included: For transactions entering the network: If the payer and payee accounts are both in the same shard, an intra-shard transaction is performed; If the payer and payee accounts do not belong to the same shard, a cross-shard transaction is processed.

2. The method for cross-shard transactions and shard migration according to claim 1, characterized in that: The processing steps of cross-shard transactions include: Primary shard transaction allocation; Intra-shard transaction verification; Cross-shard transaction verification; Cross-shard transaction submission.

3. The method for cross-shard transactions and shard migration according to claim 2, characterized in that: The main shard transaction allocation includes: The main shard distributes transactions in the network to the corresponding shards according to transaction input and output. Each account has a public key and a private key. The primary shard packages the transactions and injects them into the transaction pool corresponding to the shard. During this process, the primary shard packages the transactions into blocks and waits for verification.

4. The method for cross-shard transactions and shard migration according to claim 3, characterized in that: The intra-shard transaction verification includes: The shard node reads the transaction from the transaction pool. For cross-shard transactions, it checks whether the amount in the account is greater than or equal to the transaction amount: If the account balance is insufficient, the node considers the transaction failed and sends a message to the leader in the shard; If the account balance is sufficient, the amount in the account will be locked and a success message will be sent back to the leader node; When the number of successful transaction messages received by the leader node is greater than 2f+1, the transaction verification in shard 1 is completed; At this time, Shard 2 also performs account verification and runs the consensus protocol within the shard.

5. The method for cross-shard transaction and shard migration according to claim 4, characterized in that: The cross-shard transaction verification includes: When Shard 1 and Shard 2 complete the transaction verification within the shard, they communicate with the main shard and send a preTx message to the main shard; Among them, the preTx message contains the signature information of the nodes in the shard; The master node verifies the signature information. When the verification succeeds, the master shard sends a commit message to shard 1 and shard 2 respectively, and the two shards complete the cross-shard transaction verification.

6. The method for cross-shard transactions and shard migration according to claim 5, characterized in that: The cross-shard transaction submission includes: When Shard 1 and Shard 2 receive the commit message from the primary shard, they submit the transaction respectively to complete the account status update; If no commit message is received, the transaction is considered failed and both parties roll back the retained status information.

7. The method for cross-shard transactions and shard migration according to claim 6, characterized in that: After receiving preTx, the nodes in the shard execute the following steps: Extract the input address in the preTx transaction, obtain the public key of the input account, perform digital signature identity verification, and continue to execute the transaction if the signature verification is successful. Otherwise, the transaction is considered to have failed and discarded. Add the preTx transaction that has passed identity authentication to the local transaction pool and wait for the transaction to be packaged into a block; After receiving preTx, the shard will reach internal consensus and confirm the transaction; After completing the preTx confirmation, enter the account to complete the account update and update the fields in the local MPT.

8. A system for cross-shard transactions and shard migration, based on the method for cross-shard transactions and shard migration according to any one of claims 1 to 7, characterized in that: It includes transaction processing module, digital signature identity authentication module, shard internal consensus module, and account status update module; The transaction processing module is used to determine whether the transaction is an intra-shard transaction or a cross-shard transaction, and perform corresponding processing; The digital signature identity authentication module is used to extract the input address in the preTx transaction and obtain the public key of the input account for digital signature identity authentication; The shard internal consensus module is used to reach consensus and confirm transactions within the shard; The account status update module is used to complete the account update after preTx confirmation and update the fields in the local MPT.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method for cross-shard transactions and shard migration described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method for cross-shard transactions and shard migration described in any one of claims 1 to 7 are implemented.

Images