State shard-based blockchain cross-shard transaction atomicity guarantee method and system

Abstract

The application provides a state shard-based blockchain cross-shard transaction atomicity guarantee method and system, relates to the technical field of blockchain, and comprises the following steps: dividing a blockchain network into N shards, selecting one smart contract node for each shard, and constructing a bridge shard with the N smart contract nodes; when cross-shard transactions occur between any two shards, generating an original transaction in a first shard, including transaction content and a payee account, locking the assets corresponding to the payee account according to the transaction content by the smart contract node of the first shard, and broadcasting the original transaction to the bridge shard to generate a first-half transaction; verifying the first-half transaction by the smart contract nodes of each shard; generating a second-half transaction according to the first-half transaction by the smart contract node of a second shard, and broadcasting the second-half transaction in the second shard; adding the corresponding assets to the payee account by the smart contract node of the second shard, and deducting the locked assets of the payee account by the smart contract node of the first shard. The application guarantees the atomicity and security of cross-shard transactions.

Description

Technical Field

[0001] This invention relates to the field of blockchain performance optimization technology, and in particular to a method and system for ensuring the atomicity of cross-shard transactions in blockchain based on state sharding. Background Technology

[0002] Blockchain, a decentralized distributed ledger technology, has attracted widespread attention and application across various fields. However, traditional blockchain technology faces challenges in achieving high throughput and scalability. To address these issues, researchers have begun exploring state sharding techniques.

[0003] Blockchain account state sharding is a technique that divides the entire blockchain network into multiple smaller segments (or shards). Each shard can independently process a portion of transactions and data, thereby improving the throughput and performance of the entire system. State sharding technology enables parallel processing, reduces transaction latency, and has good scalability.

[0004] In the field of blockchain state sharding, a common approach is to divide a shard into a group of verification nodes, with each node responsible for verifying and maintaining one or more shards. While sharding enables parallel processing of blockchain transactions, the resulting increase in the number of cross-shard transactions raises the urgent issue of ensuring the security and atomicity of cross-shard transactions, guaranteeing timely restoration of account state after transaction failures, and preventing hacker attacks. Summary of the Invention

[0005] To address the issue that existing state sharding technologies cannot effectively achieve atomicity and security of cross-shard transactions while meeting the high throughput performance requirements of blockchain, this invention provides a method and system for ensuring the atomicity of cross-shard transactions in blockchain based on state sharding. Given the large number of transactions generated per second in the blockchain, state sharding is used to shard the account states of the blockchain. Simultaneously, the processing method for cross-shard transactions is designed and improved to satisfy both atomicity and security requirements while maintaining high throughput, ensuring that cross-shard transactions are processed and packaged onto the blockchain.

[0006] To achieve the above objectives, this invention provides a method for ensuring the atomicity of cross-shard transactions in a blockchain based on state sharding, comprising:

[0007] The entire blockchain network is divided into N shards, and a node is selected in each shard as a smart contract node;

[0008] Connect the smart contract nodes within N shards into a bridge shard;

[0009] When a cross-shard transaction occurs between any two shards in a blockchain, the payment account in the first shard generates the original transaction, which includes the transaction content and the receiving account. The first shard verifies the account balance of the payment account based on the transaction content. If the verification is successful, the smart contract node of the first shard locks the monetary assets corresponding to the payment account based on the transaction content and puts the original transaction into the transaction pool.

[0010] The smart contract node of the first shard packages the original transaction from the transaction pool and generates a first half of the transaction, including the original transaction, and broadcasts the first half of the transaction to the bridging shard. The smart contract nodes of each shard verify the first half of the transaction.

[0011] The smart contract nodes in the second shard generate the second half of the transaction based on the first half of the transaction, including the original transaction, and broadcast it in the second shard.

[0012] The smart contract node of the second shard adds corresponding monetary assets to the receiving account based on the receiving account and transaction content in the original transaction. At the same time, the smart contract node of the first shard deducts the monetary assets from the locked payment account.

[0013] As a further improvement of the present invention, the original transaction also includes a monetary asset lock-up period;

[0014] When the monetary assets in the payment account are locked for the specified period, the operation is rolled back.

[0015] As a further improvement of the present invention, the original transaction also includes the current Nonce value of the payment account, used to confirm the order of the transactions.

[0016] As a further improvement of the present invention, the original transaction also includes a signature of the payment account;

[0017] The first segment confirms whether the original transaction was successful based on the signature of the payment account.

[0018] As a further improvement of the present invention, the first part of the transaction also includes a preset value of the current cross-shard transaction source chain height;

[0019] Each transaction during the transaction process generates a new block, and the number of blocks in the block determines the current cross-shard transaction source chain height.

[0020] If the current cross-shard transaction source chain height exceeds the preset value, the transaction is considered to have a problem and will be rolled back.

[0021] As a further improvement of the present invention, the first half of the transaction also includes the signature of the smart contract node in the first shard and the signature of the payment account;

[0022] The smart contract nodes in each shard verify the first half of the transaction based on the signatures of the smart contract nodes in the first shard and the signatures of the payment accounts.

[0023] As a further improvement of the present invention, the latter part of the transaction also includes the signatures of the smart contract nodes in the first shard and the smart contract nodes in the second shard, indicating that it has been verified and can be further processed by the second shard.

[0024] As a further improvement of the present invention, event listeners are registered in each shard of the blockchain through smart contracts;

[0025] The event listener monitors changes in the transaction status within a shard and decides whether to continue or roll back the transaction based on the event triggering.

[0026] As a further improvement of the present invention, the smart contract is configured to include a timeout mechanism and a timestamp;

[0027] The event listener listens for and records the timestamp of the start of the transaction. The timeout mechanism sets a timeout period based on the timestamp of the start of the transaction. When the transaction time exceeds the timeout period, the smart contract controls the rollback operation.

[0028] The present invention also provides a blockchain cross-shard transaction atomicity guarantee system based on state sharding, comprising: a bridging sharding construction module, an original transaction generation module, a first half transaction generation module, a second half transaction generation module, and a transaction completion module;

[0029] The bridging sharding construction module is used for:

[0030] The entire blockchain network is divided into N shards, and a node is selected in each shard as a smart contract node;

[0031] Connect the smart contract nodes within N shards into a bridge shard;

[0032] The original transaction generation module is used for:

[0033] When a cross-shard transaction occurs between any two shards in a blockchain, the payment account in the first shard generates the original transaction, which includes the transaction content and the receiving account. The first shard verifies the account balance of the payment account based on the transaction content. If the verification is successful, the smart contract node of the first shard locks the monetary assets corresponding to the payment account based on the transaction content and puts the original transaction into the transaction pool.

[0034] The first part of the transaction generation module is used for:

[0035] The smart contract node of the first shard packages the original transaction from the transaction pool and generates a first half of the transaction, including the original transaction, and broadcasts the first half of the transaction to the bridging shard. The smart contract nodes of each shard verify the first half of the transaction.

[0036] The latter part of the transaction generation module is used for:

[0037] The smart contract nodes in the second shard generate the second half of the transaction based on the first half of the transaction, including the original transaction, and broadcast it in the second shard.

[0038] The transaction completion module is used for:

[0039] The smart contract node of the second shard adds corresponding monetary assets to the receiving account based on the receiving account and transaction content in the original transaction. At the same time, the smart contract node of the first shard deducts the monetary assets from the locked payment account.

[0040] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0041] This invention employs a redesigned sharding approach using smart contracts. Based on satisfying state sharding conditions, a new cross-shard transaction protocol is rationally designed to ensure the security and atomicity of cross-shard transactions. Specifically, smart contracts are used as a bridge chain to realize cross-shard transactions, solving the problem of security vulnerabilities and malicious attacks from dishonest nodes that arise from traditional intermediary accounts acting as currency transfer agents. Simultaneously, a series of contractual operations are designed to ensure the atomicity of cross-shard transactions. After both parties transfer funds to the contract, the recipient can only call the transfer function on the smart contract to complete the transaction and transfer the funds to themselves when the funds in the contract reach the expected amount. This ensures that the entire transaction either succeeds completely or fails completely, avoiding partial execution of the transaction.

[0042] This invention ensures the safety of funds. Both parties to the transaction transfer funds to the contract, and the funds are temporarily locked in the contract until the transaction is completed. This prevents either party from retrieving the funds during the transaction process and ensures the security of the transaction. Attached Figure Description

[0043] Figure 1 This is a flowchart of a blockchain cross-shard transaction based on state sharding, as disclosed in one embodiment of the present invention.

[0044] Figure 2 This is a schematic diagram of a bridge chain model consisting of shards and bridging shards in a blockchain network disclosed in one embodiment of the present invention. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0046] The present invention will now be described in further detail with reference to the accompanying drawings:

[0047] like Figure 1 As shown, this invention provides a method for ensuring the atomicity of cross-shard transactions in blockchain based on state sharding, aiming to solve the cross-shard transaction problem. Even if the number of cross-shard transactions is significantly reduced through a partitioning algorithm, some cross-shard transactions will still occur. Therefore, it is necessary to address the latency and security issues caused by cross-shard transactions. The specific steps include:

[0048] S1. Divide the entire blockchain network into N shards, and select a node in each shard as a smart contract node;

[0049] in,

[0050] In each shard after state sharding, there will be a smart contract node to enable cross-shard transactions. Choosing to use smart contract nodes can enhance security, improve efficiency, and reduce costs.

[0051] S2. Connect the smart contract nodes within N shards into a bridge shard;

[0052] in,

[0053] Select a Soc (Soc1, Soc2, ..., Sock-1, Sock), and connect the smart contract nodes in the Soc set to form a Bridge-Shared structure, such as... Figure 2 As shown.

[0054] Furthermore, transactions occur within the same shard under this blockchain structure:

[0055] When transactions occur within the same shard, transactions between two accounts only need to be placed in the transaction pool of the current shard, where the shard will verify and package the transaction. There is no need to go through the cross-shard transaction process.

[0056] S3. When a cross-shard transaction occurs between any two shards in the blockchain, the flowchart is as follows: Figure 1As shown, the payment account in the first shard generates the original transaction, including the transaction content and the receiving account. The first shard verifies the account balance of the payment account according to the transaction content. If the verification is successful, the smart contract node of the first shard locks the currency assets corresponding to the payment account according to the transaction content and puts the original transaction into the transaction pool.

[0057] in,

[0058] When transactions occur between different shards, such as Figure 2 As shown, accounts A, B, C, and D are located in the first shard, and A's information is stored in Shared1. Accounts E, F, G, and H are located in the second shard, and H's information is stored in Shared2. They cannot directly transact with each other. In this case, a smart contract account can be used as an intermediary to complete the transaction between A and H through the smart contract account.

[0059] Furthermore,

[0060] The original transaction also includes a monetary asset lock-up period. When the monetary assets in the payment account are locked for the specified period, the operation is rolled back.

[0061] The original transaction also includes the current Nonce value of the payment account, used to confirm the order of transactions.

[0062] The original transaction also includes the signature of the payment account; the first shard confirms the success of the original transaction based on the signature of the payment account.

[0063] Specifically,

[0064] Original transaction θ p The definition of is:

[0065]

[0066] A represents the payment account, v represents the transaction details, and H represents the receiving account. Let T be the current Nonce value of A. This Nonce value is primarily used to confirm transaction order, prevent double-spending attacks, and subsequently revert pending transactions. lock The lock-up period for monetary assets is primarily used for atomic transactions, σ A The signature of payment account A generates the original transaction θ in payment account A. p Signatures are automatically generated at that time.

[0067] S4. The smart contract node of the first shard packages the original transaction from the transaction pool and generates the first half of the transaction, including the original transaction. The first half of the transaction is broadcast to the bridge shard, and the smart contract node of each shard verifies the first half of the transaction.

[0068] in,

[0069] The first part of the transaction also includes the preset value of the current cross-shard transaction source chain height;

[0070] Each transaction during the transaction process generates a new block, and the number of blocks in the block determines the current cross-shard transaction source chain height.

[0071] If the current cross-shard transaction source chain height exceeds the preset value, the transaction is considered to have a problem and will be rolled back.

[0072] Furthermore,

[0073] The first part of the transaction also includes the signatures of the smart contract nodes in the first shard and the signatures of the payment account;

[0074] The smart contract nodes in each shard verify the first half of the transaction based on the signatures of the smart contract nodes in the first shard and the signatures of the payment accounts.

[0075] Specifically,

[0076] Once the original transaction is confirmed to be successful, the first half of the transaction θ1 will be generated. The definition of θ1 is:

[0077] θ1=< <Flag1,θ p BH current >σ A , σ soc1 >

[0078] Flag1 indicates that the first part of the cross-shard transaction has occurred, signifying that transaction A has initiated the transaction process and passed verification, BH current Represents the current height of the source chain for cross-shard transactions; σ soc1 The signature for smart contract node Soc1 is automatically generated when smart contract node Soc1 generates the first part of transaction θ1; subsequently, θ1 is broadcast to the bridge shard chain, and other smart contract accounts, upon receiving it, will use σ soc1 σ A Confirm θ1 (the transaction θ1 contains θ) p Therefore, this transaction also requires σ. A (Go to verify), after confirmation, Soc2 will initiate transaction θ2 in Shared2.

[0079] S5. The smart contract nodes in the second shard generate the second half of the transaction based on the first half of the transaction, including the original transaction, and broadcast it in the second shard.

[0080] in,

[0081] Since the first part of the transaction, Soc1, is a smart contract account, it can be assumed to be safe and reliable. Therefore, after the first part of the transaction is verified in the bridging shard, Soc2 will generate the second part of the transaction.

[0082] Furthermore,

[0083] The latter part of the transaction also includes the signatures of the smart contract nodes in the first shard and the smart contract nodes in the second shard, indicating that it has been verified and can be processed by the second shard.

[0084] Specifically, the second half of the transaction θ2 is generated.

[0085] θ2=< <Flag2,θ p >σ soc1 , σ soc2 >

[0086] The components of θ2 are similar to those of θ1, with Flag2 serving as a marker for the latter half of the transaction, σ soc1 σ soc2 The signatures are for smart contract nodes Soc1 and Soc2, respectively. When smart contract node Soc2 generates the second half of the transaction θ2, it is automatically signed. Since this transaction was verified by Soc1, it is also signed by Soc1. The transaction is signed by smart contracts Soc1 and Soc2, which means that it has been verified and can be processed by the second shard.

[0087] S6. The smart contract node of the second shard adds the corresponding monetary assets to the receiving account based on the receiving account and transaction content in the original transaction. At the same time, the smart contract node of the first shard deducts the monetary assets from the locked payment account.

[0088] in,

[0089] After Soc2 generates the θ2 transaction, it is broadcast on the Shared2 chain. Since θ2 is signed with the private keys of Soc1 and Soc2, it can be considered a trusted transaction. Shared2 verifies the transaction, packages it onto the chain, and Soc2 adds v units of currency to the recipient H. At the same time, Soc1 deducts v units of currency from the locked account A.

[0090] This invention registers event listeners in each shard of the blockchain through smart contracts; the event listeners monitor changes in the transaction status within the shard and decide whether to continue or roll back the transaction based on the triggering of the event.

[0091] The present invention sets up a smart contract that includes a timeout mechanism and a timestamp; an event listener listens for and records the timestamp at which a transaction begins; the timeout mechanism sets a timeout period based on the timestamp at which the transaction begins; when the transaction time exceeds the timeout period, the smart contract controls a rollback operation.

[0092] This invention also provides a system for ensuring the atomicity of cross-shard transactions in a blockchain based on state sharding, comprising: a bridging sharding construction module, an original transaction generation module, a first-half transaction generation module, a second-half transaction generation module, and a transaction completion module;

[0093] The bridging sharding module is used for:

[0094] The entire blockchain network is divided into N shards, and a node is selected in each shard as a smart contract node;

[0095] Connect the smart contract nodes within N shards into a bridge shard;

[0096] The original transaction generation module is used for:

[0097] When a cross-shard transaction occurs between any two shards in a blockchain, the payment account in the first shard generates the original transaction, including the transaction content and the receiving account. The first shard verifies the account balance of the payment account based on the transaction content. If the verification is successful, the smart contract node of the first shard locks the currency assets corresponding to the payment account based on the transaction content and puts the original transaction into the transaction pool.

[0098] The first part of the transaction generation module is used for:

[0099] The smart contract node of the first shard packages the original transaction from the transaction pool and generates the first half of the transaction, including the original transaction. The first half of the transaction is then broadcast to the bridge shard, and the smart contract nodes of each shard verify the first half of the transaction.

[0100] The latter part of the transaction generation module is used for:

[0101] The smart contract nodes in the second shard generate the second half of the transaction based on the first half of the transaction, including the original transaction, and broadcast it in the second shard.

[0102] The transaction completion module is used for:

[0103] The smart contract nodes in the second shard add corresponding monetary assets to the receiving account based on the receiving account and transaction content in the original transaction. At the same time, the smart contract nodes in the first shard deduct the monetary assets from the locked payment account.

[0104] Example:

[0105] When account A in the first shard of the blockchain network makes a payment to account H in the second shard, a cross-shard transaction occurs. The specific operation is as follows:

[0106] Operation 1: Payment account A generates the original transaction θ. p .

[0107]

[0108] A represents the payment account, v represents the transaction details, and H represents the receiving account. Let T be the current Nonce value of A. This Nonce value is primarily used to confirm transaction order, prevent double-spending attacks, and subsequently revert pending transactions. lock This refers to the time the currency is locked, primarily used for atomic transactions.

[0109] Step 2: Confirm the original transaction.

[0110] When A generates an original transaction, A's account balance and key information will be verified within shard 1. After successful verification, Soc1 will lock A's v assets and place the transaction in the transaction pool to await packaging and uploading.

[0111] Operation 3 generates the first half of the transaction θ1.

[0112] Once the original transaction is confirmed to be successful, the first half of the transaction θ1 will be generated. The definition of θ1 is as follows:

[0113] θ1=< <Flag1,θ p BH current >σ A , σ soc1 >

[0114] Flag1 indicates that the first part of the cross-shard transaction has occurred, signifying that transaction A has initiated the transaction process.

[0115] And the verification passed, BH current This represents the current height of the source chain for the cross-shard transaction. θ1 is then broadcast to the bridging shard chain, and other smart contract accounts, upon receiving it, will use σ... soc1 σ A Once θ1 is confirmed, Soc2 will initiate transaction θ2 in Shared2.

[0116] Operation 4: Confirm the first half of the transaction θ1.

[0117] Since the first part of the transaction, Soc1, is a smart contract account, it can be assumed to be safe and reliable. Therefore, after the first part of the transaction is verified in the bridging shard, Soc2 will generate the second part of the transaction.

[0118] Operation 5 generates the second half of the transaction θ2.

[0119] θ2=< <Flag2,θ p >σ soc1 , σ soc2 >

[0120] The components of θ2 are similar to those of θ1. Flag2 is a marker for the latter half of the transaction, and the transaction is signed by smart contracts Soc1 and Soc2, indicating that it has been verified and can be further processed by shard 2.

[0121] Operation 6: Confirm the second half of the transaction θ2.

[0122] After Soc2 generates the θ2 transaction, it is broadcast on the Shared2 chain. Since θ2 is signed with the private keys of Soc1 and Soc2, it can be considered a trusted transaction. Shared2 verifies the transaction, packages it onto the chain, and Soc2 adds v units of currency to the recipient H. At the same time, Soc1 deducts v units of currency from the locked account A.

[0123] Advantages of this invention:

[0124] This invention employs a redesigned sharding approach using smart contracts. Based on satisfying state sharding conditions, a new cross-shard transaction protocol is rationally designed to ensure the security and atomicity of cross-shard transactions. Specifically, smart contracts are used as a bridge chain to realize cross-shard transactions, solving the problem of security vulnerabilities and malicious attacks from dishonest nodes that arise from traditional intermediary accounts acting as currency transfer agents. Simultaneously, a series of contractual operations are designed to ensure the atomicity of cross-shard transactions. After both parties transfer funds to the contract, the recipient can only call the transfer function on the smart contract to complete the transaction and transfer the funds to themselves when the funds in the contract reach the expected amount. This ensures that the entire transaction either succeeds completely or fails completely, avoiding partial execution, effectively preventing attacks from malicious nodes, protecting user privacy, and enabling timely rollback in abnormal situations to restore the account to its original state, thus ensuring the atomicity of blockchain cross-shard transactions.

[0125] This invention ensures the safety of funds. Both parties to the transaction transfer funds to the contract, and the funds are temporarily locked in the contract until the transaction is completed. This prevents either party from retrieving the funds during the transaction process and ensures the security of the transaction.

[0126] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A blockchain cross-shard transaction atomicity guarantee method based on state sharding, characterized in that, include: The entire blockchain network is divided into N shards, and a node is selected in each shard as a smart contract node; Connect the smart contract nodes within N shards into a bridge shard; When a cross-shard transaction occurs between any two shards in a blockchain, the payment account in the first shard generates the original transaction, which includes the transaction content and the receiving account. The first shard verifies the account balance of the payment account based on the transaction content. If the verification is successful, the smart contract node of the first shard locks the monetary assets corresponding to the payment account based on the transaction content and puts the original transaction into the transaction pool. The smart contract node of the first shard packages the original transaction from the transaction pool and generates a first half of the transaction, including the original transaction, and broadcasts the first half of the transaction to the bridging shard. The smart contract nodes of each shard verify the first half of the transaction. The smart contract nodes in the second shard generate the second half of the transaction based on the first half of the transaction, including the original transaction, and broadcast it in the second shard. The smart contract node of the second shard adds corresponding monetary assets to the receiving account based on the receiving account and transaction content in the original transaction. At the same time, the smart contract node of the first shard deducts the monetary assets from the locked payment account.

2. The method for ensuring the atomicity of cross-shard transactions in a blockchain based on state sharding according to claim 1, characterized in that: The original transaction also includes a monetary asset lock-up period; When the monetary assets in the payment account are locked for the specified period, the operation is rolled back.

3. The method for ensuring the atomicity of cross-shard transactions in a blockchain based on state sharding according to claim 1, characterized in that: The original transaction also includes the current Nonce value of the payment account, used to confirm the order of transactions.

4. The method for ensuring the atomicity of cross-shard transactions in a blockchain based on state sharding according to claim 1, characterized in that: The original transaction also includes the signature of the payment account; The first segment confirms whether the original transaction was successful based on the signature of the payment account.

5. The method for ensuring the atomicity of cross-shard transactions in a blockchain based on state sharding according to claim 1, characterized in that: The first part of the transaction also includes a preset value for the current cross-shard transaction source chain height; Each transaction during the transaction process generates a new block, and the number of blocks in the block determines the current cross-shard transaction source chain height. If the current cross-shard transaction source chain height exceeds the preset value, the transaction is considered to have a problem and will be rolled back.

6. The method for ensuring the atomicity of cross-shard transactions in a blockchain based on state sharding according to claim 1, characterized in that: The first part of the transaction also includes the signatures of the smart contract nodes in the first shard and the signatures of the payment accounts; The smart contract nodes in each shard verify the first half of the transaction based on the signatures of the smart contract nodes in the first shard and the signatures of the payment accounts.

7. The method for ensuring the atomicity of cross-shard transactions in a blockchain based on state sharding according to claim 1, characterized in that: The latter part of the transaction also includes the signatures of the smart contract nodes in the first shard and the smart contract nodes in the second shard, indicating that it has been verified and can be processed by the second shard.

8. The method for ensuring the atomicity of cross-shard transactions in a blockchain based on state sharding according to claim 1, characterized in that: Register event listeners in each shard of the blockchain using smart contracts; The event listener monitors changes in the transaction status within a shard and decides whether to continue or roll back the transaction based on the event triggering.

9. The method for ensuring the atomicity of cross-shard transactions in a blockchain based on state sharding according to claim 8, characterized in that: The smart contract settings include a timeout mechanism and a timestamp. The event listener listens for and records the timestamp of the start of the transaction. The timeout mechanism sets a timeout period based on the timestamp of the start of the transaction. When the transaction time exceeds the timeout period, the smart contract controls the rollback operation.

10. A system for implementing the state-sharded blockchain cross-shard transaction atomicity guarantee method as described in any one of claims 1 to 9, characterized in that, include: The module includes a bridging sharding construction module, a raw transaction generation module, a first-half transaction generation module, a second-half transaction generation module, and a transaction completion module. The bridging sharding construction module is used for: The entire blockchain network is divided into N shards, and a node is selected in each shard as a smart contract node; Connect the smart contract nodes within N shards into a bridge shard; The original transaction generation module is used for: When a cross-shard transaction occurs between any two shards in a blockchain, the payment account in the first shard generates the original transaction, which includes the transaction content and the receiving account. The first shard verifies the account balance of the payment account based on the transaction content. If the verification is successful, the smart contract node of the first shard locks the monetary assets corresponding to the payment account based on the transaction content and puts the original transaction into the transaction pool. The first part of the transaction generation module is used for: The smart contract node of the first shard packages the original transaction from the transaction pool and generates a first half of the transaction, including the original transaction, and broadcasts the first half of the transaction to the bridging shard. The smart contract nodes of each shard verify the first half of the transaction. The latter part of the transaction generation module is used for: The smart contract nodes in the second shard generate the second half of the transaction based on the first half of the transaction, including the original transaction, and broadcast it in the second shard. The transaction completion module is used for: The smart contract node of the second shard adds corresponding monetary assets to the receiving account based on the receiving account and transaction content in the original transaction. At the same time, the smart contract node of the first shard deducts the monetary assets from the locked payment account.

Images