Cross-fragment transaction method based on state commitment, terminal, medium and program product

Abstract

The invention discloses a state commitment-based cross-fragment transaction method, a terminal, a medium and a program product in the field of information security, and the method comprises the steps: setting an asynchronous prepayment account in a target fragment, distributing a certain amount for the prepayment account in advance, and converting a cross-fragment transaction into a transaction in the target fragment; transactions are executed in the target fragment, whether transactions in all related fragments conform to rules and conform to the rules is verified through a batch transaction verification mechanism, and the correctness and integrity of the transactions are ensured; a hierarchical state storage structure is adopted to optimize data storage and reading involved in transaction execution, and an account state variable quantity involved in recent transactions is stored through a variable quantity partial state tree in chain storage; and the under-chain storage is used for storing a complete state tree and related proof. According to the state commitment-based cross-fragment transaction method provided by the invention, the transaction execution efficiency is remarkably improved, and the calculation amount and the storage overhead in the verification process are reduced.

Description

Technical Field

[0001] The present invention belongs to the field of information security and relates to a cross-shard transaction method, terminal, medium, and program product based on state commitment. Background Art

[0002] In recent years, cryptocurrencies such as Bitcoin and Ethereum have made significant progress in fields such as payment systems, supply chain management, and the Internet of Things. However, blockchain technology requires each node to maintain a complete transaction record and the current ledger state to ensure a high level of security in a decentralized environment. As the number of accounts and transaction activities continues to grow, the data volume of the blockchain gradually becomes huge, facing the risk of state explosion. This brings a heavy storage and computing burden to the nodes, resulting in limited transaction throughput and increased latency.

[0003] To address the problem of state data explosion, sharding technology has emerged as a potential solution, covering network sharding, transaction sharding, and state sharding. Among them, state sharding is the most complex. It reduces the burden on nodes to store the entire ledger by having each shard hold a partial copy of the ledger state. Existing state sharding protocols aim to reduce the occurrence of cross-shard transactions and balance the transaction load. The former is achieved by allocating user states with frequent transactions to the same shard, while the latter alleviates the hot shard problem by splitting a cross-shard transaction into two intra-shard transactions.

[0004] Another approach to alleviating data explosion is stateless blockchain, especially suitable for cryptocurrencies. It can transfer the account state to off-chain storage nodes. This off-chain expansion method greatly reduces the on-chain load and minimizes the amount of state data stored on each node. In a stateless blockchain, verifiers only maintain the compact commitments in the latest block and the corresponding account balance proofs, without the need to store the entire state. The node initiating the transaction needs to broadcast the state proof to demonstrate the validity of the transaction relative to the current state. This mechanism enables verifiers to verify transactions without a comprehensive understanding of the entire system state.

[0005] Existing sharding mechanisms mainly focus on improving transaction throughput but lack a secure and reliable transaction verification mechanism. Although stateless blockchains do provide such a verification mechanism, they cannot efficiently process transactions in parallel. The present invention attempts to implement a secure and efficient sharding technology in a stateless blockchain system, aiming to improve system performance while ensuring data security. However, this integration also brings some challenges, and the specific content of the challenges is described as follows.

[0006] Although sharding improves the performance of the blockchain to some extent, it inevitably introduces cross-shard transactions. With the increase in the volume of transactions, a large number of cross-partition transactions will be generated. Statistical data shows that in a sharding system, more than 96% of the transactions are cross-shard transactions. Cross-shard transactions require communication between multiple shards. Frequent cross-shard communication may weaken the performance advantages of blockchain sharding. Existing account-based state sharding schemes can greatly reduce the number of cross-shard transactions, such as split account technology and overlapping account technology. However, processing cross-shard transactions in these schemes involves complex sequential processing, which weakens the parallel processing efficiency of sharding technology.

[0007] The transaction verification mechanism is a core component of the blockchain system, which can ensure the legality of transactions and maintain the security and immutability of state data. However, existing state sharding schemes lack a corresponding proof mechanism to support the verification of account balances. They only consider achieving the consistency of state data through complex consensus protocols (such as Proof of Work - PoW) or Byzantine Fault Tolerance (BFT). This only verifies the validity of each transaction in the block, such as preventing double-spending attacks, but ignores protecting the privacy of transaction data. In addition, these schemes blindly trust the given account balance and cannot verify whether the sender has sufficient funds without directly accessing the state balance of the source shard. This requires a mechanism that can quickly prove that the sender's account indeed has sufficient balance to execute the transaction without directly accessing the original data in the shard.

[0008] Most blockchain data storage adopts the MPT (Merkle Patricia Trie) structure or the LMPT (Layer Merkle Patricia Trie) structure. In MPT or LMPT, verifying each transaction requires traversing all nodes on the path from the leaf node to the root node, which involves frequent read proof operations. When the state value changes, the hash values of all nodes on the path also need to be updated. The time complexity of both verification and update is , which seriously affects the performance of transaction processing. In addition, with the increase in data volume, the height of MPT also increases, thus extending the length of the path. This greatly increases the maintenance cost of proofs and results in longer transaction delays. Currently, how to design an efficient parallel cross-shard transaction processing mechanism that can securely and quickly perform cross-shard batch transaction verification while supporting efficient storage reading, updating, and verification has become a key problem to be solved urgently. Summary of the Invention

[0009] The purpose of the present invention is to overcome the deficiencies in the prior art and provide a cross-shard transaction method, terminal, medium, and program product based on state commitment, which can perform efficient parallel cross-shard transactions, and can perform cross-shard batch transaction verification safely and quickly, while supporting efficient storage reading, updating, and verification.

[0010] To achieve the above object, the present invention is implemented by the following technical solutions:

[0011] In a first aspect, the present invention provides a cross-shard transaction method based on state commitment, including:

[0012] In a blockchain sharding system, by setting an asynchronous prepaid account in the target shard, allocating a certain amount to the prepaid account in advance, and converting the cross-shard transaction into a transaction within the target shard;

[0013] Execute the transaction within the target shard, and verify whether all the involved intra-shard transactions comply with the rules and reach an agreement through a batch transaction verification mechanism to ensure the correctness and integrity of the transaction;

[0014] Optimize the data storage and reading involved in transaction execution by adopting a hierarchical state storage structure, where the hierarchical state storage structure includes on-chain storage and off-chain storage. The on-chain storage stores the account state change amounts involved in recent transactions through a variable part state tree; the off-chain storage is used to store the complete state tree and related proofs.

[0015] Further, the step of setting an asynchronous prepaid account in the target shard and allocating a certain amount to the prepaid account in advance includes:

[0016] At the beginning of each epoch, based on the transaction frequency between the transaction account and the target shard, set an asynchronous prepaid account for the account with high-frequency cross-shard transactions, and calculate the account-to-shard A2S score through the Page Rank method to allocate the prepaid amount; the calculation formula for the A2S score of each transaction is as follows:

[0017] ;

[0018] In the formula: represents the A2S score of transaction ; represents the damping coefficient; represents the set of all transactions pointing to transaction ; represents transaction 's out-degree;

[0019] When a cross-shard transaction occurs, the balance of the prepaid account is directly deducted to complete the transaction within the target shard.

[0020] Furthermore, verify whether all involved intra-shard transactions comply with the rules and reach an agreement through the batch transaction verification mechanism to ensure the correctness and integrity of the transactions, including:

[0021] Use function to input the security parameter into the bilinear mapping generator to generate bilinear mapping parameters for each shard , randomly select a secret value , combine the group generator and to output the public parameter ;

[0022] In the formula: represents the total number of accounts in the shard; represents the bilinear mapping generator; represents the bilinear mapping parameter; represents the bilinear mapping function; and respectively represent the generators of group and group ; represents the cyclic group generated by exponentiating ; represents the cyclic group generated by exponentiating ; represents the order of the group; and are elements in group , representing the -th power and -th power of the generator respectively; and are elements in group , representing the -th power and -th power of the generator respectively;

[0023] Based on the public parameter, generate the commitment corresponding to each shard, which is used to represent the authenticity of the account status. The calculation formula of the commitment is shown as follows:

[0024] C i = C o m m i t p p ( a , M [ i , : ] , i ) = g 1 ∑ j = 1 n m i j α j ;

[0025] In the formula: represents the commitment of the -th shard; represents the function to generate the commitment; , Denote the group as the set of all elements in ; denote the index of the shard ; denote the index of the account status in the -th shard is a matrix, and each row in the matrix represents the account status in a shard M [ i ,:] ; denote the -th shard as the set of account statuses ; denote the -th account status in the -th shard ; denote the exponential commitment to the account status within the shard , encrypting the account status as an element in the group ;

[0026] Generate a proof for each account status based on the account status and the fast number theory transform for verifying the legitimacy of the account status. The calculation formula of the status proof is shown as follows

[0027] π j S i = P r o v e p p ( a , M [ i , : ] , j , i ) = g 1 ( α n * M [ i , : ] ) [ j ] ;

[0028] In the formula denotes the -th shard ; denotes the function for generating the proof ;

[0029] Each transaction within the shard is accompanied by the account status and the proof corresponding to the account status. Define the single transaction within the shard as

[0030] ;

[0031] In the formula , denotes the number of transactions within the shard denotes the sender's account denotes the receiver's account denotes the change in account status, used to record the transfer amount denotes the account status of the transaction initiator, used to record the current account balance of the transaction initiator denotes the proof of the account status of the transaction initiator

[0032] Compress the proofs of multiple account statuses involved in the transaction within the shard to generate an aggregated proof . The calculation formula of the aggregated proof is shown as follows

[0033] ;

[0034] Wherein: represents the generated random value; represents the index set of the proofs to aggregate the account status; the proof of the account status to be aggregated in the

[0035] After obtaining the aggregated proof, which is denoted as within the shard, the transactions are defined as:

[0036] ;

[0037] Each shard forms its own block and sends the block to other nodes in the network. Other nodes perform a one-time verification of the transactions within the block based on the aggregated proof ; Only the aggregated status proof and the status commitment corresponding to the shard need to be verified during the verification process, as shown in the following formula:

[0038] ∏ ( i , j ) ∈ I ( e ( C i / c j , g 2 α 1 − j ) e ( c i , g 2 α n − j + 1 ) ) r i , j = e ( π ^ I , g 2 ) g T α ∑ ( i , j ) ∈ I M [ I ] r i , j

[0039] Wherein: M [ I ] represents the set of proofs to aggregate the account status; represents the intermediate result saved when calculating the commitment; represents the generated random value; g T α ∑ ( i , j ) ∈ I M [ I ] r i , j represents an element in the group ; The group is obtained by performing a bilinear pairing of the group and the group ; represents the generator of the group ;

[0040] When the verification passes and other nodes in the network reach a consensus on the block, the transaction is completed. The block is officially added to the blockchain, and all nodes in the network will receive a copy of this block and update their ledgers to the latest state;

[0041] After the transaction is completed, the account status within the target shard changes to . Based on the change in the account status, the commitment and proof corresponding to the account status within the target shard are updated using the function and the function respectively, to obtain the updated commitment and proof , the formula for updating the commitment is shown as follows:

[0042] .

[0043] Furthermore, before the transaction is completed, the sender's account status is locked and cannot be used to initiate other transactions; after the transaction is completed, the previously locked sender's account status is unlocked for other transactions.

[0044] Furthermore, the leaf nodes stored on-chain store the account status change amount and the proof for updating based on the account status change amount; the leaf nodes stored off-chain store the account status and the corresponding proof of the account status; the root nodes stored on-chain and off-chain store the aggregated proof.

[0045] In a second aspect, the present invention provides an electronic terminal, which is characterized by including a processor and a memory connected to the processor. A computer program is stored in the memory. When the computer program is executed by the processor, the steps of the above-mentioned cross-shard transaction method based on state commitment are executed.

[0046] In a third aspect, the present invention provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, the steps of the above-mentioned cross-shard transaction method based on state commitment are implemented.

[0047] In a fourth aspect, the present invention provides a computer program product, including a computer program / instructions. When the computer program / instructions are executed by a processor, the steps of the above-mentioned cross-shard transaction method based on state commitment are implemented.

[0048] Compared with the prior art, the beneficial effects achieved by the present invention:

[0049] The cross-shard transaction method based on state commitment provided by the present invention effectively avoids the complexity of cross-shard communication by setting up an asynchronous prepaid account mechanism, converts cross-shard transactions into local transactions within the target shard, and significantly improves the efficiency of transaction execution. At the same time, a batch transaction verification mechanism is adopted to batch verify multiple transactions, greatly reducing the computational amount and storage overhead during the verification process and enhancing the verification efficiency of the overall system. In addition, combined with a hierarchical state storage structure, the present invention stores the account status change amount involved in recent transactions through a differential partial state tree on-chain, reducing the on-chain storage burden, and ensures the integrity and efficient reading of data by storing the complete state tree and related proofs off-chain. This method not only optimizes data storage and reading during the transaction execution process but also guarantees the correctness and integrity of transactions, improving the scalability and security of the system. Description of the Drawings

[0050] Figure 1 It is the structural block diagram of the cross-shard transaction method based on state commitment provided by the first embodiment of the present invention;

[0051] Figure 2 It is the schematic diagram of the hierarchical state storage structure provided by the first embodiment of the present invention. Detailed implementation manners

[0052] The technical solution of the present invention will be described in detail below through the accompanying drawings and specific embodiments. It should be understood that the specific features in the embodiments of the present application and the embodiments are detailed descriptions of the technical solution of the present application, rather than limitations on the technical solution of the present application. Without conflict, the technical features in the embodiments of the present application and the embodiments can be combined with each other.

[0053] Embodiment 1:

[0054] Figure 1 It is the structural block diagram of a cross-shard transaction method based on state commitment in the first embodiment of the present invention. This structural block diagram only shows the logical sequence of the method described in this embodiment. On the premise of not conflicting with each other, in other possible embodiments of the present invention, the steps shown or described can be completed in a different Figure 1 sequence from that shown.

[0055] Refer to Figure 1 , the method of this embodiment specifically includes the following steps:

[0056] In the blockchain sharding system, by setting an asynchronous prepayment account in the target shard, allocating a certain amount to the prepayment account in advance, and converting the cross-shard transaction into a transaction within the target shard;

[0057] Execute the transaction within the target shard, and verify whether all the intra-shard transactions involved comply with the rules and reach an agreement through the batch transaction verification mechanism to ensure the correctness and integrity of the transaction.

[0058] As Figure 1 shown, this embodiment has 3 shards. Shard 1 contains accounts A and B; Shard 2 contains account C; Shard 3 contains account D. There are 3 transactions in the block, which are respectively:

[0059] (1) A to C: This transaction is a transfer from account A in shard 1 to account C in shard 2.

[0060] (2) B to C: This transaction is a transfer from account B in shard 1 to account C in shard 2.

[0061] (3) A to D: This transaction is a transfer from account A in shard 1 to account D in shard 3.

[0062] In a stateless cryptocurrency system, when the sender's account and the receiver's account are in the same shard, the transaction can be processed immediately; while when the two accounts are in different shards, the validator needs to download and verify the state of the target shard. Frequent cross-shard transactions will significantly affect the throughput of the system. To solve this problem, this embodiment introduces an asynchronous prepaid account mechanism to achieve parallel processing of cross-shard transactions. This method allows the same source account to execute multiple cross-shard transactions simultaneously in multiple target shards. By pre-transferring the user's funds to the target shard, most cross-shard transactions can be completed within a single shard, thus reducing the number and complexity of cross-shard transactions and significantly improving the transaction processing speed.

[0063] For the cross-shard transactions in this embodiment, this method sets up an asynchronous prepaid account in the target shard to reduce cross-shard interactions and convert cross-shard transactions into local transactions within the target shard. Specifically, as Figure 1 shown, an asynchronous prepaid account is set up in target shard 2 and , and an asynchronous prepaid account is set up in target shard 3 . After setting up the asynchronous prepaid accounts, the Page Rank method is used to calculate the A2S score to determine the account state values of the asynchronous prepaid accounts and in shard 2, as well as the account state value of the asynchronous prepaid account in shard 3, so as to allocate an appropriate prepaid amount. By allowing the sender's account to prepay a certain amount in the target shard, the number of cross-shard transactions is minimized. The calculation formula for the A2S score of each transaction is shown as follows:

[0064] ;

[0065] In the formula: represents the A2S score of transaction ; represents the damping factor; represents the set of all transactions pointing to transaction , represents the out-degree of transaction ;

[0066] In this model, each account is regarded as a node. When transactions are frequently conducted between two accounts, a directed edge is created between these two accounts, and the weight of the edge represents the number of transactions. In this way, the transaction frequency between accounts can be effectively calculated, providing a basis for the fund allocation of prepaid accounts. When a cross-shard transaction occurs, the balance of the prepaid account will be directly deducted to complete the transaction within the target shard, thereby improving the transaction processing efficiency and reducing the overhead of cross-shard communication.

[0067] After the allocation of the prepaid amount is completed, the system then ensures the correctness and integrity of the transaction through a cross-shard batch transaction verification mechanism. This mechanism consists of seven main steps: initializing and generating common parameters, generating commitments, generating proofs, aggregating proofs, batch verification, updating the commitment with the change amount, and updating the proof with the change amount. First, in the initialization phase, the system generates the necessary common parameters. Subsequently, using the fast number theory transform, corresponding proofs are generated for each account state for subsequent verification. The block proposer can aggregate multiple proofs involved in the new block into a concise aggregated proof. In the transaction verification process, the verifier only needs to use this aggregated proof to verify multiple transactions at once, thus significantly improving the transaction verification efficiency and ensuring the security of the account state through this proof.

[0068] The core advantage of this mechanism is that the verifier only needs to maintain the commitments and proofs related to the states in the relevant shards, without storing the actual state information of each account, that is, without accessing the actual balance of each account. Whenever the account state changes, that is, when the account balance is updated, the system updates the change amount on the basis of the original proof without having to recalculate all relevant data, thus improving the efficiency and scalability of the system.

[0069] Specifically, the steps involved in the cross-shard batch transaction verification mechanism are as follows:

[0070] Initializing and generating common parameters: Generate bilinear mapping parameters and common parameters according to system requirements to ensure the security and reliability of transaction verification;

[0071] Using function to input the security parameter into the bilinear mapping generator to generate bilinear mapping parameters for each shard, randomly select a secret value , combine the group generators and , and output the common parameter ;

[0072] Where: represents the total number of accounts in the shard; represents the bilinear mapping generator; represents the bilinear mapping parameter; represents the bilinear mapping function; and respectively represent the group generators of group and group ; represents the cyclic group generated by exponentiating ; represents the cyclic group generated by exponentiating Cyclic group generated by exponentiation; Denotes the order of the group; and are elements of the group representing the -th power and -th power of the generator respectively; and are elements of the group representing the -th power and -th power of the generator respectively;

[0073] As shown in Figure 1 , for shard 1, shard 2, and shard 3, the corresponding common parameters are respectively. Shard 1 selects the secret value , and exponentiates and to generate the corresponding common parameter ; Shard 2 selects the secret value , and exponentiates and to generate the corresponding common parameter ; Shard 3 selects the secret value , and exponentiates and to generate the corresponding common parameter .

[0074] Generate commitment: Based on the common parameters, generate the commitment corresponding to each shard, which is used to represent the authenticity of the account status. The calculation formula for the commitment is shown as follows:

[0075] C i = C o m m i t p p ( a , M [ i , : ] , i ) = g 1 ∑ j = 1 n m i j α j ;

[0076] In the formula: represents the commitment of the -th shard; represents the function for generating the commitment; , represents the set of all elements in the group ; represents the index of the shard; represents the index of the account status in the -th shard; ]>is a matrix, and each row in the matrix represents the account status in a shard; M [ i ,:] represents the set of account statuses in the -th shard; represents the The account status in a shard; Indicates the exponential commitment to the account status within the shard, encrypting the account status as an element in the group ; one element;

[0077] Accordingly, as Figure 1 shown, corresponding status commitments , and are generated for shard 1, shard 2, and shard 3 respectively.

[0078] Generate a proof: Generate a status proof for each account in the shard based on the account status and the fast number-theoretic transform , used to verify the account status, that is, the legitimacy of the account balance; where the status proof corresponds to the current value of the account status within the shard, and the calculation formula of the status proof is as shown in the following formula:

[0079] π j S i = P r o v e p p ( a , M [ i , : ] , j , i ) = g 1 ( α n * M [ i , : ] ) [ j ] ;

[0080] In the formula: represents the th shard; represents the function to generate the status proof; ;

[0081] Accordingly, as Figure 1 shown, for shard 1, the statuses of account A and account B are and respectively, and the status proofs corresponding to each account status are generated using the and functions; for shard 2, the prepaid accounts , and the statuses of account C are , and respectively; the status proofs corresponding to each account status are generated using the , and functions; for shard 3, the prepaid accounts and the statuses of account D are and respectively; the status proofs corresponding to each account status are generated using the and functions.

[0082] In this embodiment, each transaction is accompanied by an account status and a proof of status. A single transaction within a shard is defined as:

[0083] ;

[0084] In the formula: , represents the number of transactions within the shard; represents the sender's account; represents the recipient's account; represents the change in status, used to record the transfer amount; represents the account status of the transaction originator, used to record the current account balance of the transaction originator; represents the proof of the account status of the transaction originator;

[0085] Aggregate proof: Compress the proofs of the statuses of multiple accounts involved in the transactions within the shard to generate an aggregate proof , and the aggregate proof is calculated as shown in the following formula:

[0086] ;

[0087] In the formula: represents the generated random value; represents the index set of the status proofs to be aggregated; The th status proof to be aggregated in the shard;

[0088] As Figure 1 shown, for shard 1, compress the proofs and corresponding to accounts A and B in shard 1 to obtain the aggregate proof ; for shard 2, shard 2 involves two transactions. Compress the proofs and corresponding to the sender's accounts , and the proof corresponding to the recipient's account C to obtain the aggregate proof ; for shard 3, shard 3 involves one transaction. Compress the proofs and and corresponding to the sender's account .

[0089] After obtaining the aggregate proof , the transactions within the shard are defined as:

[0090] ;

[0091] Each shard independently processes its own accounts and transactions to form its own block. Shard 1 generates a block , recording information related to accounts A and B (such as proof of state and , compressed into an aggregated proof representation ).

[0092] Shard 2 generates a block , recording transactions and status updates related to accounts , and C pair (such as proof of state , and , compressed into an aggregated proof representation ).

[0093] Shard 3 generates a block , recording transactions and status updates related to accounts and D (such as proof of state and , compressed into an aggregated proof representation ). The block of each shard is independent of other shards and only involves the accounts, status, and transactions within that shard. This avoids the complex synchronization problems introduced by cross-shard transactions.

[0094] Batch verification: After each shard forms its own block, the block is sent to other nodes in the network, and other nodes perform a one-time verification of the transactions in the block based on the aggregated proof ; during the verification process, only the aggregated state proof and the status commitment corresponding to the shard need to be verified. The verifier is responsible for verifying the correctness of the blocks of multiple shards. In this embodiment, the verifier mainly achieves efficient verification through the following steps:

[0095] 1. Access the status commitment and aggregated proof: The verifier does not need to store the specific balance of each account, that is, it does not need to access the status of each account, and only needs to check the status commitments , and in the blocks of each shard, as well as the aggregated state proof , and ;

[0096] For example, when verifying , it only needs to ensure that it covers all relevant states in shard 2 (accounts , and the update status of C).

[0097] 2. Batch verification: The verifier performs batch verification on all transactions in the new block instead of verifying each transaction individually.

[0098] Use aggregate proofs and to verify the validity of transactions in the corresponding block.

[0099] Aggregate proofs can reduce the verification complexity, especially when the number of shards is large and the transaction volume per shard is large. As Figure 1 shown, there are two transactions involved in Shard 2, A→C: (payment from the prepaid account in Shard 2 ); B→C: (payment from the prepaid account in Shard 2 ). Instead of storing all account states (account balances) in Shard 2, the verifier accesses the state commitment corresponding to Shard 2 and the aggregate state proof to verify whether the transaction is valid.

[0100] 3. Broadcast verification results: The verifier broadcasts the verification results to the network to provide a basis for reaching a consensus on the new block.

[0101] When the verification passes and other nodes in the network reach a consensus on the block, the transaction is completed, the block is officially added to the blockchain, and all nodes in the network will receive a copy of this block and update their ledgers to the latest state;

[0102] Commitment and proof of change amount update: After the transaction is completed, the account state in the target shard changes to , based on the change of the account state, use the function and function to update the commitment and proof corresponding to the account state in the target shard respectively, and obtain the updated commitment and proof . The formula for updating the commitment is shown as follows:

[0103] .

[0104] As Figure 1 shown, the last updated shards are Shard 2 and Shard 3, and they will each update the account balance and state proof.

[0105] See Figure 2, this embodiment adopts a hierarchical state storage structure to optimize the data storage and reading involved in transaction execution. The hierarchical state storage structure includes on-chain storage and off-chain storage. The on-chain storage stores the account state changes involved in recent transactions through the change part state tree; the off-chain storage is used to store the complete state tree and related proofs.

[0106] Figure 2 The block in represents the th block in the blockchain, where (Hash of the previous block) represents the hash value of the previous block, which is used to maintain the chain structure of the blockchain and ensure the immutability of the block. (Hash of the transaction root) represents the root hash value of the transaction tree. This transaction tree is used to store all transactions within the block. Instead of directly storing the specific content of the transactions, the transaction data is hashed and organized according to the structure of the Merkle Tree. The root hash value at the top of the tree is the final hash value of the transaction tree, which is the unique summary of all transactions in the entire block and can be used to quickly verify the integrity and consistency of the transactions. (Hash of the state root) represents the root hash value of the off-chain complete state tree, which records the current states of all accounts within the block. The root hash value of the complete state tree is the aggregated proof stored in the root node, ensuring the verifiability and integrity of the account states. Nonce is a random number in the Proof of Work (PoW) mechanism, ensuring that the mining of the block complies with the consensus rules. Others represent other fields or additional information that may be included in the block.

[0107] The optimization of on-chain storage adopts the change part state tree. The present invention observes that most leaf nodes are not accessed for a long time and are in a dormant state. Therefore, it is not necessary to store the entire state tree on-chain. Based on this observation, this embodiment only stores a partial state tree on-chain, thereby minimizing the auxiliary information stored on-chain. This optimization method significantly reduces the storage burden while retaining the data required for efficient state update and verification. In addition, the present invention further discovers that the proof can be updated with changes in the commitment. This means that the leaf nodes in the on-chain partial state tree only need to store the changes in the account state instead of the complete account state.

[0108] Initially, the state tree on-chain is empty. As transactions occur, the system generates a prefix tree based on the involved account addresses, and the leaf nodes record the change values of the states. For example, when a transfer transaction occurs, the system generates a new proof that includes the change in the account balance. AsFigure 2 As shown, the leaf nodes of the change amount partial state tree store the account state change amount and the updated proof. This proof is derived from the previous proof and the change amount value, and subsequent transactions follow the same processing flow.

[0109] In addition, the aggregated proofs stored on-chain are consistent with those stored off-chain. As Figure 2 shown, the aggregated proofs stored in the root nodes on-chain and off-chain are consistent. This consistency ensures the efficiency of state verification and update. The change amount update mechanism enables the system to efficiently manage new transactions and maintain the state tree without having to recalculate the entire proof from scratch, and the performance is maintained even as the number of transactions increases over time.

[0110] By implementing this series of strategies, the present invention achieves a balance between storage efficiency and data security. The combination of the on-chain partial state tree and the change amount proof ensures that the system can remain lightweight and high-performance while maintaining the information required for state verification.

[0111] The core of off-chain storage optimization lies in eliminating intermediate hash values. In a traditional MPT (Merkle Patricia Trie), the process of generating intermediate hash values involves the aggregation of a series of hash values. Specifically, the hash values of nodes at the same level are combined to generate the hash value of the parent node, and this process recurses along the tree structure until the root node. For example, if there are four leaf nodes A, B, C, and D, the hash values of A and B will be merged to generate the hash value of the parent node, and the hash values of C and D will also be merged to generate the hash value of their parent node. Finally, the hash values of these two parent nodes will be merged to form the hash value of the root node. As the tree structure expands, this hash aggregation will lead to a sharp increase in storage overhead.

[0112] The optimized design of the present invention adopts an optimized version of Patricia Trie with proof. In this design, off-chain storage only retains the proofs of leaf nodes and the aggregated proof of the root node, avoiding the generation and storage of the hash values of all intermediate nodes. As Figure 2 shown, the hash values of leaf nodes and root nodes are replaced by corresponding proofs, which have aggregation properties similar to those of hash values. The proofs of any two or more states can be directly aggregated, and even the proofs of all leaf nodes can be directly aggregated into the aggregated proof of the root node.

[0113] The proofs of leaf nodes provide the information needed to verify the existence and correctness of account balances, while the aggregated proofs of root nodes ensure the overall verifiability of the tree structure. Through this optimization, the storage requirement for intermediate hash values is eliminated, significantly reducing the storage overhead. Since the number of data points to be managed is reduced, the process of verifying and updating the tree becomes more concise, thus accelerating the query speed and reducing the computational cost. This optimization achieves a more efficient and lightweight storage while maintaining the security and verifiability of the data.

[0114] Specifically, in combination with Figure 2 , taking the storage of some accounts in Shard 1 and Shard 2 as an example, the off-chain storage structure is described in detail. Figure 2 The state tree structures before and after optimization are shown.

[0115] In the conventional storage structure (i.e., the state tree before optimization), the node structure of each layer is as follows:

[0116] The first layer: The root node is an extended node, which is used to store some address prefixes (e.g., ab, ac) and the corresponding hash values (such as ).

[0117] The second layer: This layer contains an extended node and a leaf node.

[0118] The extended node is used to store some address prefixes (such as abce, abcd) and hash values (such as ). The leaf node stores the account state (such as

[0119] and hash values (such as ) corresponding to the account address (such as acd3f72).

[0120] The third layer: This layer contains a leaf node and an extended node.

[0121] The leaf node stores the state (such as ) and hash value (such as ) of account A corresponding to the account address abce153. The extended node stores some address prefixes (such as abcd16, abcd18) and the corresponding hash values (such as ).

[0122] The fourth layer: This layer contains two leaf nodes.

[0123] The leaf nodes store the state (such as ) and hash value (such as ) of account B corresponding to the account address abcd167, and the state (such as ) and hash value (such as ) of account C corresponding to the account address abcd185.

[0124] In the optimized off-chain storage structure, the following improvements have been made:

[0125] Root node: The hash value in the root node is replaced by an Aggregated proof, which not only reduces the storage volume but also improves the verification efficiency.

[0126] Leaf node: In the optimized structure, the leaf node stores the proof corresponding to the account state (instead of the hash value). These proofs can verify the correctness of the account state without the need to store the complete hash value of each account.

[0127] Extension node: The extension node no longer stores the hash value but stores the address prefix, further reducing the storage burden.

[0128] Through this optimization, the storage redundancy is reduced, and the storage of unnecessary intermediate hash values (such as the hash values of the intermediate layer nodes in the original tree structure) is avoided. And the query and verification efficiency are improved because only the necessary account state proofs are stored, and the computational amount in the verification process is reduced through the aggregated proof.

[0129] Combined with the hierarchical state storage structure, the present invention stores the change amount of the account state involved in recent transactions through the variable part state tree on the chain, reducing the on-chain storage burden, and ensuring the integrity and efficient reading of data by storing the complete state tree and related proofs off the chain. This method not only optimizes the data storage and reading during the transaction execution process but also guarantees the correctness and integrity of the transaction, improving the scalability and security of the system.

[0130] Embodiment 2:

[0131] The embodiment of the present invention also provides an electronic terminal, including a processor and a memory connected to the processor. A computer program is stored in the memory. When the computer program is executed by the processor, the steps of the cross-shard transaction method based on state commitment described in Embodiment 1 above are executed.

[0132] Embodiment 3:

[0133] The embodiment of the present invention also provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, the steps of the cross-shard transaction method based on state commitment described in Embodiment 1 above are first implemented.

[0134] The computer-readable storage medium includes various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs.

[0135] Example 4:

[0136] The embodiment of the present invention also provides a computer program product, including computer programs / instructions, which, when executed by a processor, implement the steps of the cross-shard transaction method based on state commitment described in Embodiment 1.

[0137] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program codes.

[0138] The present application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram can be implemented by computer program instructions, and the combination of processes and / or blocks in the flowchart and / or block diagram can also be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for implementing the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0139] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured product including an instruction device, and the instruction device implements the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0140] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0141] The above are only the preferred embodiments of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the technical principle of the present invention, several improvements and modifications can be made, and these improvements and modifications should also be regarded as the protection scope of the present invention.

Claims

1. A cross-shard transaction method based on state commitment, characterized in that, Including: In a blockchain sharding system, by setting an asynchronous prepaid account in a target shard, allocating a certain amount to the prepaid account in advance, and converting cross-shard transactions into transactions within the target shard; Executing transactions within the target shard, and verifying whether all involved intra-shard transactions comply with the rules and reach an agreement through a batch transaction verification mechanism to ensure the correctness and integrity of the transactions; Adopting a hierarchical state storage structure to optimize the data storage and reading involved in transaction execution, where the hierarchical state storage structure includes on-chain storage and off-chain storage. The on-chain storage stores the account state change amounts involved in recent transactions through a partial state tree of change amounts; the off-chain storage is used to store the complete state tree and related proofs.

2. The cross-shard transaction method based on state commitment according to claim 1, wherein The step of setting an asynchronous prepaid account in the target shard and allocating a certain amount to the prepaid account in advance includes: At the beginning of each epoch, based on the transaction frequency between the transaction account and the target shard, setting an asynchronous prepaid account for the accounts with high-frequency cross-shard transactions, and calculating the account-to-shard A2S score through the Page Rank method to allocate the prepaid amount; the calculation formula for the A2S score of each transaction is as follows: ； Wherein: represents the A2S score of the transaction ; represents the damping coefficient; represents all transaction sets pointing to the transaction ; represents the out-degree of the transaction ; When a cross-shard transaction occurs, the balance of the prepaid account is directly deducted to complete the transaction within the target shard.

3. The cross-shard transaction method based on state commitment according to claim 1, wherein The step of verifying whether all involved intra-shard transactions comply with the rules and reach an agreement through a batch transaction verification mechanism to ensure the correctness and integrity of the transactions includes: Utilize the function to input the security parameter into the bilinear mapping generator to generate bilinear mapping parameters for each shard randomly select a secret value and combine the group generator and to output the public parameter ; Wherein: represents the total number of accounts in the shard; represents a bilinear mapping generator; represents bilinear mapping parameters; represents a bilinear mapping function; and respectively represent the generators of the groups and the group ; represents the cyclic group generated by exponentiating ; represents the cyclic group generated by exponentiating ; represents the order of the group; and are elements in the group and respectively represent the -th power and -th power of the generator ; and are elements in the group and respectively represent the -th power and -th power of the generator ; Generate a commitment corresponding to each shard based on the common parameters , which is used to represent the authenticity of the account status. The commitment is calculated as shown in the following formula: ； Wherein: represents the commitment of the th shard; represents the function for generating the commitment; , represents the set of all elements in the group; represents the index of the shard; represents the th index of the account status in the th shard; represents the th set of account statuses in the th shard; represents the th account status in the th shard; represents the exponential commitment to the account status within the shard, encrypting the account status as an element in the group; Generate a proof for each account status based on the account status and fast number-theoretic transform for verifying the legality of the account status, and the status proof has the following calculation formula: ； In the formula: represents the th shard; represents the function for generating the proof; ; Each transaction within a shard is accompanied by an account status and a proof corresponding to the account status. A single transaction within a shard is defined as: ； Where: , represents the number of transactions within a shard; represents the sender's account; represents the recipient's account; represents the change in account status, used to record the transfer amount; represents the account status of the transaction initiator, used to record the current account balance of the transaction initiator; represents the proof of the account status of the transaction initiator; Compress the proofs of the states of multiple accounts involved in the transactions within the shard to generate an aggregated proof , the aggregated proof has the following calculation formula: ； In the formula: represents the generated random value; represents the index set of the proofs for aggregating the account status; The proof of the account status to be aggregated in the shard; Obtain an aggregated proof representation After that, the transactions within the shard are defined as: ； Each shard forms its own block and sends the block to other nodes in the network. Other nodes perform a one-time verification of the transactions within the block; only the aggregated state proof needs to be verified during the verification process and the state commitment corresponding to the shard as shown in the following formula: , as shown below: ； Wherein: Represents the collection of proofs of the account status to be aggregated; Represents the intermediate result saved when calculating the commitment; Represents the generated random value; Represents a group An element in; the group By taking the group And the group Obtained by performing a bilinear pairing; Represents a group Of the generator; When the verification passes and other nodes in the network reach a consensus on the block, the transaction is completed, the block is officially added to the blockchain, and all nodes in the network will receive a copy of this block and update their ledgers to the latest state; After the transaction is completed, the account status in the target shard is changed to , based on the change of the account status, using function and function to update the commitment and proof corresponding to the account status in the target shard respectively, and obtain the updated commitment and proof . The formula for updating the commitment is shown as follows: 。 4. The cross-shard transaction method based on state commitment according to claim 3, wherein Before the transaction is completed, the sender's account state is locked and cannot be used to initiate other transactions; after the transaction is completed, the previously locked sender's account state will be unlocked for other transactions.

5. The cross-shard transaction method based on state commitment according to claim 3, wherein, The leaf nodes of the on-chain storage store the account state change amounts and the proofs updated based on the account state change amounts; the leaf nodes of the off-chain storage store the account state and the corresponding proofs of the account state; the root nodes of the on-chain storage and the off-chain storage store the aggregated proofs.

6. An electronic terminal, characterized in that, Including a processor and a memory connected to the processor, where a computer program is stored in the memory. When the computer program is executed by the processor, the steps of the cross-shard transaction method based on state commitment according to any one of claims 1 to 5 are executed.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, the steps of the cross-shard transaction method based on state commitment according to any one of claims 1 to 5 are implemented.

8. A computer program product comprising computer programs / instructions, characterized in that, When the computer program / instructions are executed by the processor, the steps of the cross-shard transaction method based on state commitment according to any one of claims 1 to 5 are implemented.

Images