An efficient cross-shard blockchain atomic commit method based on staking transactions

Abstract

This invention proposes an efficient cross-shard blockchain atomic commit method based on staking transactions. First, it introduces a staking transaction mechanism using an empty recipient address and synchronizes staking transactions from each shard to the auxiliary chain through global consensus. Second, it proposes a cross-shard transaction protocol based on staking transactions, which ensures the security of the recipient's funds through staking transactions in global consensus. Furthermore, it designs a batch staking transaction on-chain and batch settlement protocol suitable for sharded chains, and conducts feasibility verification and performance testing. Experimental results show that this invention can reduce the user-perceived latency of cross-shard transactions to a single consensus cycle, providing a new solution for achieving high-throughput and highly scalable blockchain systems.

Description

Technical Field

[0001] This invention relates to the field of cryptocurrency systems, and more specifically to an efficient cross-shard blockchain atomic submission method based on staking transactions. Background Technology

[0002] With the rapid development of blockchain technology, more and more industries are adopting this decentralized distributed ledger technology, driving changes in finance, supply chain, digital identity, and other fields. However, current blockchain networks face some bottlenecks. Specifically, each node in the blockchain network needs to process and verify all transactions, leading to excessive network load, increased transaction confirmation time, and a significant decrease in system efficiency. To address this issue, sharded blockchain technology has emerged as an important solution.

[0003] Sharded blockchain technology divides the entire blockchain network into multiple smaller "shards," each of which independently processes a portion of the transactions or smart contracts, thereby enabling parallel processing and improving the network's processing capacity. This approach significantly enhances blockchain performance, enabling it to handle greater transaction demands.

[0004] On the one hand, sharded blockchains can significantly improve transaction throughput. In traditional blockchain networks, all nodes need to process all transaction records, while sharded blockchains distribute the transaction load across different shards, with each shard independently verifying and storing data. This not only improves the processing efficiency of each node but also increases the overall throughput of the entire blockchain, meeting the needs of large-scale transactions.

[0005] On the other hand, sharded blockchains effectively reduce network congestion. In traditional blockchain networks, all nodes need to share the same data, and each transaction needs to be broadcast across the entire network, which easily leads to network congestion. Sharding technology distributes transaction data across multiple shards, reducing the amount of data and verification workload in each shard, lowering the overall network load, and avoiding network congestion problems in high-concurrency scenarios. Therefore, designing an efficient cross-shard transaction method is extremely important.

[0006] Currently, existing cross-sharding solutions for auxiliary sharding blockchains, both domestically and internationally, mainly fall into three categories: those based on multi-phase commit protocols, those based on transaction splitting protocols, and those based on dual-chain protocols. Multi-phase commit protocols ensure consistent state updates across different shards during cross-sharding transactions through atomic locking. Transaction splitting protocols effectively reduce the cost of cross-sharding transactions by splitting the original transaction into multiple sub-transactions or relay transactions. Dual-chain protocols improve the throughput and security of the main chain by introducing an auxiliary chain to handle specific business logic and functions. However, in practical implementation, these methods do not fully consider the trust differences between shards, and transaction timeliness and throughput still need improvement.

[0007] To address current issues related to cross-shard transactions, this invention proposes an efficient cross-shard blockchain atomic submission method based on staking transactions. This method shifts the focus of fund security for the recipient from global runtime consensus on input UTXOs to pre-global consensus on staking transactions. By introducing staking transactions, the original cross-shard transaction is split into multiple intra-shard transactions, significantly improving the security, timeliness, and throughput of the sharding system. Summary of the Invention

[0008] This invention provides an efficient cross-shard blockchain atomic submission method for staking transactions, which solves the problems of low inter-shard security and low throughput in traditional cross-shard transactions.

[0009] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0010] An efficient cross-shard blockchain atomic commit method based on staking transactions is achieved by combining an auxiliary chain with a special transaction structure. It includes four stages: staking transaction commit, staking transaction usage, staking transaction settlement, and unstaking. Specifically, it includes the following steps:

[0011] Step S1, Submit the staking transaction:

[0012] An idle node generates an in-shard transaction with an empty recipient using its wallet balance or a portion of its balance, submits it as a staking transaction PTX, and waits for the transaction to reach consensus in its shard. The main chain consensus nodes periodically read and verify staking transactions from each shard. The hash of the verified staking transaction is stored in the main chain ledger, and the staking transaction submission is complete.

[0013] Step S2, Use of staking transaction:

[0014] The sender queries all unused staking transactions PTX on the main chain, selects a staking transaction PTX that meets the criteria, and sends a collection transaction CTX to its submitter. The collection transaction CTX contains the hash of the staking transaction PTX and the original recipient information. After the collection transaction CTX achieves consensus within the chip, the sender obtains the right to use all or part of the staking transaction PTX. Subsequently, the sender submits the staking transaction and the collection transaction to the recipient to prove that the payment has been completed.

[0015] Step S3, Settlement of Pledged Transactions:

[0016] After the recipient obtains the payment proof submitted by the sender, it verifies whether the staking transaction PTX is included in the main chain ledger and whether the collection transaction CTX is in the sending shard ledger. If the verification is successful, the recipient will submit a settlement transaction RTX in the current shard. This is a transaction that transfers funds to the recipient, with the sender being the hash of the staking transaction PTX. The payment proof submitted by the sending shard will be submitted to the consensus node of the receiving shard. When the consensus node of the receiving shard adds the settlement transaction to the ledger, the cross-shard transfer process is completed.

[0017] Step S4, Release the collateral:

[0018] Once a staking transaction is submitted to the main chain, the staking transaction PTX cannot be used to secure cross-shard transactions. After the staking transaction gains consensus on the main chain, the staker submits a settlement transaction RTX in the current shard.

[0019] Furthermore, step S1 specifically includes the following steps:

[0020] Step S11: An idle node uploads a staking transaction to this shard. A system event, namely a staking transaction, is represented by PTX(a1,x+&,Hash,NULL). This transaction includes details of the sender (a1), the transfer amount (x), the null receiver (NULL), and details of the commission paid by the sender.

[0021] Step S12: PTX staking transactions are periodically read and verified by the main chain. The transfer amount is cut and stored in the main chain. Different amounts are used as leaf nodes and generate different hash identifiers, which are stored in the root hash of the main chain block.

[0022] Furthermore, step S2 specifically includes the following steps:

[0023] Step S21: The sender queries all unused staking transactions on the main chain for this shard and submits a collection transaction CTX(a1,x+&,Hash,b1) that meets the conditions to represent a system event. This transaction includes details of the sender (a1), the transfer amount (x), an empty receiver (NULL), details of the commission paid by the sender, the receiving account information of the receiver (b1), and the hash of the staking transaction PTX.

[0024] Step S22: The CTX transaction is verified by the consensus nodes of the shards and uploaded to the chain.

[0025] Furthermore, step S3 specifically includes the following steps:

[0026] Step S31: After the collection transaction CTX obtains the main chain consensus, the sender submits a settlement transaction RTX. RTX(a1,x+&,Hash,b1) represents a system event, which includes the sender's (a1) details, the hash of the staking transaction PTX, the transfer amount (y), and the receiver's (b1) receiving account information.

[0027] Step S32: The settlement transaction RTX is verified by the consensus nodes of the shards and uploaded to the chain.

[0028] Furthermore, step S4 specifically includes the following steps:

[0029] Step S41: The unstaking transaction JTX(Hash,a1,y) represents a system event, which includes the hash information of the staking transaction PTX on the main chain, the relevant amount (y), the receiving address of the staker (a1) of this shard, and the relevant unstaking operation.

[0030] Step S42: After the unstaking transaction obtains consensus on the main chain, the staker submits a settlement transaction in the current shard.

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

[0032] 1) This invention proposes a highly efficient cross-shard blockchain atomic commit method based on staking transactions, a fast atomic commit protocol where users utilize their idle assets to assist in completing cross-shard transactions. First, an auxiliary chain, called the main chain, is introduced and maintained by all shards. By achieving global consensus on staking transactions within the main chain, the atomicity of cross-shard staking transactions is guaranteed. Second, a cross-shard transaction protocol based on staking transactions is designed, where the security of the recipient's funds is guaranteed by the staking transactions on the main chain. Staking transactions are verified through the main chain consensus nodes, and the hash of the verified staking transaction is stored in the main chain block. Payment proofs are submitted to the consensus nodes of the receiving shard to verify the legality of the cross-shard transfer.

[0033] 2) The efficient cross-shard blockchain atomic submission method based on staking transactions proposed in this invention ensures the atomicity of cross-shard transactions through on-chain verification of staking transactions, verification of collection transactions, submission of settlement transactions, and processing of unstaking transactions. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of an overall scheme model provided by an embodiment of the present invention, which describes the interaction steps between entities and between entities during cross-shard transactions.

[0035] Figure 2 This is a blockchain diagram of a staking transaction provided according to the implementation method of this application.

[0036] Figure 3 The experimental results show the comparison of the perceived latency of the present invention with other similar solutions in an asynchronous blockchain environment.

[0037] Figure 4 The results of a comparative experiment on the perceived latency of the present invention and other similar solutions in a synchronous blockchain environment are shown. Detailed Implementation

[0038] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of this application.

[0039] This invention provides an efficient cross-shard blockchain atomic commit method based on staking transactions. The core of this method includes three elements: staking transaction on-chain processing, the cross-shard transaction process, and the unstaking and settlement of staking transactions. This embodiment focuses on describing these three parts, such as... Figure 1 As shown, the process can be briefly described as follows:

[0040] User A1 in shard A needs to pay user B1 in shard B X yuan. First, user A0 in shard A submits a staking transaction PTX with an empty receiving address during an idle period. Then, the main chain consensus nodes retrieve and verify the staking transactions from different shards. The verified staking transaction hash is recorded in the next block of the main chain to lock the staking transaction. Finally, user A1 submits a collection transaction CTX in shard A. After user B1 sees that the collection CTX is effective, user B1 submits a settlement transaction RTX in shard B, with the input address being the staking transaction hash of the main chain.

[0041] Specifically, A1 changes its transfer to user B to a transfer of X to A0, and marks this transfer in a new field as predicated on the use of X yuan in PTX. Since the staking transaction submitted by A0 can only be used by collection transactions in shard A, the consensus nodes of shard A can quickly verify whether the staking transaction has conflicts or has been exhausted.

[0042] This embodiment provides an efficient cross-shard blockchain atomic commit method based on staking transactions, with the following steps:

[0043] Step S1: Staking and On-Chain Phase: During idle time, any node user can act as a staker, and their wallet balance V (or a portion thereof) generates an on-chip transaction PTX with an amount of X and an empty recipient. 质押者-空 Then, the transaction waits for consensus (block formation) in this shard. Main chain consensus nodes periodically read and verify staking transactions (PTX) from each shard. The verified PTX hash is stored in the main chain's ledger, and the staking node's balance V... (V—X) At this point, the PTX staking transaction has been completed.

[0044] The amount in the PTX staking transaction is divided by the main chain consensus nodes, with different amounts generated as leaf nodes and stored in the root node as different hashes. Detailed staking transactions are recorded on-chain as follows: Figure 2 As shown.

[0045] Step S2: Cross-shard transaction process: The source shard sender queries all unused staking transactions (PTX) on the main chain for this shard, selects a staking transaction (PTX) that meets the conditions, and sends a collection transaction (CTX) of amount [amount] to its submitter. 发送方-接收方Collection transactions are similar to regular transactions, except that a unique hash of the staking transaction and information about the original recipient need to be added to the extended fields. This indicates the recipient's desire to use the staked amount. After the collection transaction (CTX) achieves consensus within the shard, the sender gains the right to use all or part of the staked transaction (PTX). Subsequently, the sender submits the staked transaction (PTX) and collection transaction (CTX) to the recipient to prove that the payment has been completed. After receiving the payment proof submitted by the sender, the recipient first verifies whether the staked transaction (PTX) is included in the main chain ledger through the block header information, and then verifies whether the collection transaction is already in the sending shard's ledger through the block header information of the shard chain. When the verification is successful, the recipient submits a settlement transaction (RTX) in the current shard. This is a transaction that transfers funds to the recipient, with the sender being the hash of the staking transaction. The payment proof submitted by the sending shard is then submitted to the consensus node of the receiving shard. When the receiving transaction (CTX) appears in the sender's shard's ledger, the receiving shard's consensus node then adds the settlement transaction (RTX) to its ledger. The extended fields in the staking transaction (RTX) still need to include information such as the unique hash of the staking transaction. In this way, the cross-shard transfer process is completed. A detailed flowchart is shown below. Figure 2 As shown.

[0046] Step S3: Unstaking and Settlement of Staking Transactions: The unstaking operation of a staking transaction requires first submitting an unstaking transaction to the main chain. After submission, the staking transaction can no longer be used to secure cross-shard transactions. Once the unstaking transaction gains consensus on the main chain, the staker submits a settlement transaction in the current shard. This invention uses an unstaking transaction JTX(Hash, a1, y) to represent a system event, which includes the staked PTX on the main chain, the transfer amount (y), and the receiving account information of the user (a1) in this shard. The consensus node within the shard can accurately calculate the remaining amount of the staking transaction by checking the ledger and transfer it to the staker. At this point, a complete staking and unstaking process is complete.

[0047] Comparative experiment:

[0048] This invention is compared with the RapidChain, Monoxide, and Fine-tuned Lock methods in terms of user-perceived latency. Specifically, it is compared with Mahdi Zamanii et al.'s "Rapidchain: Scaling blockchain via fullsharding," Jiaping Wang et al.'s "Monoxide: Scale out blockchains with asynchronous consensus zones," and Huawei Huang et al.'s "Account migration across blockchain shards using fine-tuned lock mechanism."

[0049] A web server containing typical blockchain interfaces was developed using Python code to simulate the normal operation of a blockchain. Multiple instances were controlled by scripts to simulate asynchronous and synchronous multi-sharded blockchains. Each instance implemented interfaces including adding transactions, generating blocks, querying block height, and querying the ledger. To simulate one main chain and ten shard chains, this invention differentiated ledger data and block production frequency. The block production frequency for shard chains was 5 seconds per block, while the main chain's block production frequency was 15 seconds per block.

[0050] This invention simulates real blockchain data by sharding real blockchain and Ethereum data based on address hashes and populating the sharded chain ledgers with scripts. Building upon this, the invention randomly generates cross-shard transactions and measures the time delay from transaction commit to final confirmation.

[0051] Experimental results are as follows Figure 3 and Figure 4 As shown, in asynchronous blockchains, PledgeACS reduces the average user-perceived latency by 38.6%, 57.65%, and 50.8% compared to the comparison methods, with the shortest cross-shard transaction time being 0.6 seconds. In synchronous blockchains, PledgeACS reduces the average user-perceived latency by 24.1%, 39.2%, and 34.2% compared to the comparison methods, with the shortest cross-shard transaction time being 5.07 seconds.

[0052] The above assessment shows that, compared with typical cross-shard atomic commit protocols, PledgeACS can significantly reduce the user-perceived latency of cross-shard transactions, reducing it to a single consensus cycle.

Claims

1. A highly efficient cross-shard blockchain atomic commit method based on staking transactions, characterized in that, Specifically, the following steps are included: Step S1, Submit the staking transaction: An idle node generates an in-shard transaction with an empty recipient using its wallet balance or a portion of its balance, submits it as a staking transaction PTX, and waits for the transaction to reach consensus in its shard. The main chain consensus nodes periodically read and verify staking transactions from each shard. The hash of the verified staking transaction is stored in the main chain ledger, and the staking transaction submission is complete. Step S2, Use of staking transaction: The sender queries all unused staking transactions PTX on the main chain, selects a staking transaction PTX that meets the criteria, and sends a collection transaction CTX to its submitter. The collection transaction CTX contains the hash of the staking transaction PTX and the original recipient information. After the collection transaction CTX achieves consensus within the chip, the sender obtains the right to use all or part of the staking transaction PTX amount. Subsequently, the sender submits the pledge and collection documents to the recipient to prove that the payment has been completed; Step S3, Settlement of Pledged Transactions: After the recipient obtains the payment proof submitted by the sender, it verifies whether the staking transaction PTX is included in the main chain ledger and whether the collection transaction CTX is in the sending shard ledger. If the verification is successful, the recipient will submit a settlement transaction RTX in the current shard. This is a transaction that transfers funds to the recipient, with the sender being the hash of the staking transaction PTX. The payment proof submitted by the sending shard will be submitted to the consensus node of the receiving shard. When the consensus node of the receiving shard adds the settlement transaction to the ledger, the cross-shard transfer process is completed. Step S4, Release the collateral: Submitting an unstaking transaction: After submitting the unstaking transaction to the main chain, the submitted staking transaction PTX (a1, x+&, Hash, NULL) can no longer be used to secure cross-shard transactions. Here, a1 represents the sender's details, x represents the transfer amount, & represents the sender's commission details, Hash represents the hash of the staking transaction PTX, and NULL represents an empty receiver. Once the unstaking transaction achieves consensus on the main chain, the staker submits a settlement transaction (RTX) on the current shard.

2. The method according to claim 1, characterized in that, The collection transaction CTX(a1,x+&,Hash,b1) in step S2 includes the following information: detailed information of sender a1, transfer amount x, null receiver NULL, commission & paid by sender detailed information, receiving account information of receiver b1, and hash of staking transaction PTX.

3. The method according to claim 1, characterized in that, The settlement transaction RTX (a1, x+&, Hash, b1) in step S3 includes the following information: detailed information of the sender a1, hash of the staking transaction PTX, transfer amount x, and receiving account information of the receiver b1.

4. The method according to claim 1, characterized in that, The unstaking transaction JTX(Hash, a1, y) in step S4 includes the following information: the hash information of the staking transaction PTX, the relevant amount y, the receiving address of the staker a1 in this shard, and the relevant unstaking operation.

5. A system for implementing the method of any one of claims 1 to 4, characterized in that, The system includes: A secondary chain module is used to store and verify the hashes of staking transactions, ensuring the atomicity of transactions across shards; A sender node is used to submit collection transactions and verify staking transactions; A receiving node is used to verify payment proofs and submit settlement transactions; A main chain consensus node is used to periodically verify staking transactions and update the main chain ledger; A shard consensus node is used to verify the legality of staking transactions and collection transactions, and to complete cross-shard transactions.

6. The system according to claim 5, characterized in that, The auxiliary chain module is the main chain in the cross-shard blockchain, used to manage and coordinate the transaction process of each shard.

7. The system according to claim 5, characterized in that, The sending node and the receiving node are located in different shards, and cross-shard transactions are coordinated through the auxiliary chain module.

Images