Method and apparatus for managing state data of DAPP applied to blockchain

Abstract

The present invention discloses a method and apparatus for managing state data of a DAPP applied to a blockchain. The method includes: obtaining a plurality of transactions and zero-knowledge proofs of the plurality of transactions; sending the plurality of transactions to an EVM service; after determining that the plurality of transactions are successfully executed on the EVM service, updating a first Merkle state tree off-chain to a second Merkle state tree according to the plurality of transactions; processing the plurality of transactions into an aggregated transaction; generating an aggregated zero-knowledge proof according to the zero-knowledge proofs of the plurality of transactions; storing a root node after the aggregated zero-knowledge proof is verified and passed by a smart contract on the blockchain. When the above method is applied to financial technology (Fintech), the plurality of transactions can be first executed in an off-chain EVM service, and the obtained aggregated transaction, aggregated zero-knowledge proof, and root node are sent to the blockchain for state data management, thereby realizing the separation of state data management and business logic.

Description

Technical Field

[0001] The present invention relates to the field of blockchain in the field of financial technology (Fintech), and in particular to a method and device for managing the state data of a DAPP applied to a blockchain. Background Art

[0002] With the development of computer technology, more and more technologies are applied in the financial field. The traditional financial industry is gradually transforming into financial technology (Fintech). However, due to the security and real-time requirements of the financial industry, higher requirements are also put forward for technologies. Currently, based on the immutability of the blockchain, transactions in the field of financial technology are often recorded through the blockchain, and transactions need to be proven legal before being uploaded to the blockchain.

[0003] In the prior art, the state data of users, such as the balance and transaction times of users, are often maintained through a Merkle tree on the blockchain. When each transaction is executed, some changes in the state data of users will be involved, and then the Merkle tree also needs to change accordingly. In the prior art, after the transaction is executed, zero-knowledge proofs are used to prove and record the changes in the state data of users, and the Merkle tree is updated after the verification is successful.

[0004] However, since the current state data of users are all stored on the blockchain, with the increase in users and transactions, the state data of users will become very large. After each transaction is executed, a zero-knowledge proof needs to be generated to prove its legality, and the zero-knowledge proof needs to be verified. The computational overhead brought will increase as the Merkle tree becomes larger. Therefore, how to reduce the management overhead of the state data of a DAPP applied to a blockchain is an urgent problem to be solved. Summary of the Invention

[0005] The present invention provides a method and device for managing the state data of a DAPP applied to a blockchain, which solves the problem of reducing the management overhead of the state data of a DAPP applied to a blockchain in the prior art.

[0006] In a first aspect, the present invention provides a method for managing the state data of a DAPP applied to a blockchain, including:

[0007] Obtaining a plurality of transactions and zero-knowledge proofs of the plurality of transactions, and the zero-knowledge proof of any transaction is used to prove the legality of the transaction;

[0008] Send the multiple transactions to the Ethereum Virtual Machine (EVM) service; after determining that the multiple transactions are successfully executed on the EVM service, update the off-chain first Merkle state tree to a second Merkle state tree according to the multiple transactions, where the first Merkle state tree is the Merkle state tree before the successful execution of the multiple transactions, and the second Merkle state tree is the Merkle state tree after the successful execution of the multiple transactions;

[0009] Process the multiple transactions into an aggregated transaction; generate an aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions, where the proof content of the aggregated zero-knowledge proof is equivalent to the total proof content of the zero-knowledge proofs of the multiple transactions;

[0010] Send the aggregated transaction, the aggregated zero-knowledge proof, and the root node of the second Merkle state tree to the blockchain, so that the blockchain executes the aggregated transaction, and after the smart contract of the blockchain verifies that the aggregated zero-knowledge proof passes, store the root node.

[0011] In the above manner, the multiple transactions are sent to the Ethereum Virtual Machine (EVM) service and are pre-executed successfully on the EVM service. Since the aggregated zero-knowledge proof is obtained from the zero-knowledge proofs of the multiple transactions, and the proof content of the aggregated zero-knowledge proof is equivalent to the total proof content of the zero-knowledge proofs of the multiple transactions, the verification passing of the aggregated zero-knowledge proof can indicate that these multiple transactions are all legal transactions. Moreover, the blockchain can perform only one-time verification through only one aggregated zero-knowledge proof to verify the legality of multiple transactions. Also, there is no complex operation of generating zero-knowledge proofs on the chain, and it is not necessary to store the entire updated second Merkle state tree on the chain. Only the root node of each Merkle state tree update needs to be stored on the chain, thereby reducing the management overhead of the state data of the DAPP applied to the blockchain.

[0012] Optionally, the generating an aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions includes:

[0013] Generate a first aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions corresponding to the first Merkle state tree;

[0014] Generate a second aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions corresponding to the second Merkle state tree;

[0015] Generate the aggregated zero-knowledge proof according to the first aggregated zero-knowledge proof and the second aggregated zero-knowledge proof.

[0016] In the above method, by aggregating the zero-knowledge proofs of each transaction's Merkle state tree in multiple transactions respectively, the zero-knowledge proofs before and after the execution of multiple transactions can be determined at one time.

[0017] Optionally, generating a first aggregated zero-knowledge proof based on the zero-knowledge proofs corresponding to the multiple transactions in the first Merkle state tree includes:

[0018] Based on the zero-knowledge proofs corresponding to the multiple transactions in the first Merkle state tree, iteratively generate zero-knowledge proofs based on the path information from the leaf nodes corresponding to the users of the multiple transactions in the first Merkle state tree to the root node of the first Merkle state tree until the first aggregated zero-knowledge proof is generated;

[0019] Generating a second aggregated zero-knowledge proof based on the zero-knowledge proofs corresponding to the multiple transactions in the second Merkle state tree includes:

[0020] Based on the zero-knowledge proofs corresponding to the users of the multiple transactions in the second Merkle state tree, iteratively generate zero-knowledge proofs based on the path information from the leaf nodes corresponding to the multiple transactions in the second Merkle state tree to the root node of the second Merkle state tree until the second aggregated zero-knowledge proof is generated.

[0021] Optionally, generating a first state commitment corresponding to the multiple transactions in the first Merkle state tree based on the leaf nodes corresponding to the multiple transactions in the first Merkle state tree, where the first state commitment is used to prove that the zero-knowledge proof corresponding to each transaction in the multiple transactions is bound to the leaf node corresponding to the transaction in the first Merkle state tree;

[0022] Generating a second state commitment corresponding to the multiple transactions in the second Merkle state tree based on the leaf nodes corresponding to the multiple transactions in the second Merkle state tree, where the second state commitment is used to prove that the zero-knowledge proof corresponding to each transaction in the multiple transactions is bound to the leaf node corresponding to the transaction in the second Merkle state tree.

[0023] In the above manner, the first state commitment can trace the binding relationship between the transaction and the leaf node corresponding to the first Merkle state tree, and the second state commitment can trace the binding relationship between the transaction and the leaf node corresponding to the second Merkle state tree, thereby improving the traceability of the multiple transactions.

[0024] Optionally, generating the first state commitment corresponding to the multiple transactions in the first Merkle state tree based on the leaf nodes corresponding to the multiple transactions in the first Merkle state tree includes:

[0025] Generate the first state commitment based on the leaf nodes corresponding to the multiple transactions in the first Merkle state tree, the transaction execution status of the multiple transactions, the transaction sequence numbers of the multiple transactions, and the first root node of the first Merkle state tree;

[0026] The generating the second state commitment corresponding to the multiple transactions in the second Merkle state tree based on the leaf nodes corresponding to the multiple transactions in the second Merkle state tree includes:

[0027] Generate the second state commitment based on the leaf nodes corresponding to the multiple transactions in the second Merkle state tree, the transaction execution status of the multiple transactions, the transaction sequence numbers of the multiple transactions, and the second root node of the second Merkle state tree.

[0028] Optionally, for a first transaction and a second transaction, where the first transaction and the second transaction are any two transactions among the multiple transactions, the zero-knowledge proof of the first transaction includes a first zero-knowledge proof corresponding to the first Merkle state tree, and the zero-knowledge proof of the second transaction includes a second zero-knowledge proof corresponding to the first Merkle state tree;

[0029] The first zero-knowledge proof and the second zero-knowledge proof are generated in the following manner:

[0030] Generate a first Merkle proof for the first leaf node corresponding to the first transaction in the first Merkle state tree, where the first Merkle proof is used to prove the position information of the first leaf node in the first Merkle state tree;

[0031] Generate the first zero-knowledge proof of the first transaction based on the first transaction, the first leaf node, the first Merkle proof, and the first root node of the first Merkle state tree;

[0032] Generate a second Merkle proof for the second leaf node corresponding to the second transaction in the first Merkle state tree, where the second Merkle proof is used to prove the position information of the second leaf node in the first Merkle state tree;

[0033] Generate the second zero-knowledge proof of the second transaction based on the second transaction, the second leaf node, the second Merkle proof, and the second root node of the first Merkle state tree.

[0034] Optionally, for a first transaction and a second transaction, where the first transaction and the second transaction are any two transactions among the multiple transactions, the zero-knowledge proof of the first transaction includes a third zero-knowledge proof corresponding to the second Merkle state tree, and the zero-knowledge proof of the second transaction includes a fourth zero-knowledge proof corresponding to the second Merkle state tree;

[0035] The third zero-knowledge proof and the fourth zero-knowledge proof are generated in the following manner:

[0036] Generate a third Merkle proof for the third leaf node corresponding to the first transaction in the second Merkle state tree, where the third Merkle proof is used to prove the position information of the third leaf node in the second Merkle state tree;

[0037] Generate the third zero-knowledge proof based on the first transaction, the third leaf node, the third Merkle proof, and the second root node of the second Merkle state tree;

[0038] Generate a fourth Merkle proof for the fourth leaf node corresponding to the second transaction in the second Merkle state tree, where the fourth Merkle proof is used to prove the position information of the fourth leaf node in the second Merkle state tree;

[0039] Generate the fourth zero-knowledge proof based on the second transaction, the fourth leaf node, the fourth Merkle proof, and the second root node of the second Merkle state tree.

[0040] In a second aspect, the present invention provides a method for managing state data of a DAPP applied to a blockchain, including:

[0041] A blockchain node obtains an aggregated zero-knowledge proof and the root node of a second Merkle state tree; the aggregated zero-knowledge proof is obtained based on the zero-knowledge proofs of the multiple transactions, and the proof content of the aggregated zero-knowledge proof is equivalent to the total proof content of the zero-knowledge proofs of the multiple transactions; the second Merkle state tree is updated from the first Merkle state tree of the blockchain after the multiple transactions are successfully executed on the blockchain;

[0042] The blockchain node verifies the aggregated zero-knowledge proof by invoking the smart contract of the blockchain, and stores the root node after successful verification.

[0043] In a third aspect, the present invention provides a device for managing state data of a DAPP applied to a blockchain, including:

[0044] An acquisition module, configured to acquire multiple transactions and the zero-knowledge proofs of the multiple transactions, where the zero-knowledge proof of any transaction is used to prove the legality of the transaction;

[0045] A processing module, configured to send the multiple transactions to an Ethereum Virtual Machine (EVM) service; after determining that the multiple transactions are successfully executed on the EVM service, update the off-chain first Merkle state tree to a second Merkle state tree according to the multiple transactions, where the first Merkle state tree is the Merkle state tree before the successful execution of the multiple transactions, and the second Merkle state tree is the Merkle state tree after the successful execution of the multiple transactions; and

[0046] configured to process the multiple transactions into an aggregated transaction; generate an aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions, where the proof content of the aggregated zero-knowledge proof is equivalent to the total proof content of the zero-knowledge proofs of the multiple transactions;

[0047] A sending module, configured to send the aggregated transaction, the aggregated zero-knowledge proof, and the root node of the second Merkle state tree to a blockchain, so that the blockchain executes the aggregated transaction, and store the root node after the aggregated zero-knowledge proof is verified to pass by a smart contract of the blockchain.

[0048] Optionally, the processing module is specifically configured to:

[0049] generate a first aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions corresponding to the first Merkle state tree;

[0050] generate a second aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions corresponding to the second Merkle state tree;

[0051] generate the aggregated zero-knowledge proof according to the first aggregated zero-knowledge proof and the second aggregated zero-knowledge proof.

[0052] Optionally, the processing module is specifically configured to:

[0053] generate zero-knowledge proofs iteratively according to the zero-knowledge proofs of the multiple transactions corresponding to the first Merkle state tree, based on the path information from the leaf nodes corresponding to the multiple transactions in the first Merkle state tree to the root node of the first Merkle state tree, until the first aggregated zero-knowledge proof is generated;

[0054] generate zero-knowledge proofs iteratively according to the zero-knowledge proofs of the multiple transactions corresponding to the second Merkle state tree, based on the path information from the leaf nodes corresponding to the multiple transactions in the second Merkle state tree to the root node of the second Merkle state tree, until the second aggregated zero-knowledge proof is generated.

[0055] Optionally, the processing module is further configured to:

[0056] Generate a first state commitment corresponding to the multiple transactions at the leaf nodes of the first Merkle state tree, where the first state commitment is used to prove that the zero-knowledge proof corresponding to each transaction in the multiple transactions is bound to the leaf node corresponding to the transaction in the first Merkle state tree;

[0057] Generate a second state commitment corresponding to the multiple transactions at the leaf nodes of the second Merkle state tree, where the second state commitment is used to prove that the zero-knowledge proof corresponding to each transaction in the multiple transactions is bound to the leaf node corresponding to the transaction in the second Merkle state tree.

[0058] Optionally, the processing module is specifically configured to:

[0059] Generate the first state commitment according to the leaf nodes corresponding to the multiple transactions in the first Merkle state tree, the transaction execution status of the multiple transactions, the transaction sequence numbers of the multiple transactions, and the first root node of the first Merkle state tree;

[0060] Generate the second state commitment according to the leaf nodes corresponding to the multiple transactions in the second Merkle state tree, the transaction execution status of the multiple transactions, the transaction sequence numbers of the multiple transactions, and the second root node of the second Merkle state tree.

[0061] Optionally, for a first transaction and a second transaction, where the first transaction and the second transaction are any two transactions in the multiple transactions, the zero-knowledge proof of the first transaction includes a first zero-knowledge proof corresponding to the first Merkle state tree, and the zero-knowledge proof of the second transaction includes a second zero-knowledge proof corresponding to the first Merkle state tree;

[0062] The first zero-knowledge proof and the second zero-knowledge proof are generated in the following manner:

[0063] Generate a first Merkle proof corresponding to the first leaf node of the first transaction in the first Merkle state tree, where the first Merkle proof is used to prove the position information of the first leaf node in the first Merkle state tree;

[0064] Generate a first zero-knowledge proof of the first transaction according to the first transaction, the first leaf node, the first Merkle proof, and the first root node of the first Merkle state tree;

[0065] Generate a second Merkle proof for the second leaf node corresponding to the second transaction in the first Merkle state tree, where the second Merkle proof is used to prove the position information of the second leaf node in the first Merkle state tree;

[0066] Generate a second zero-knowledge proof for the second transaction based on the second transaction, the second leaf node, the second Merkle proof, and the second root node of the first Merkle state tree.

[0067] Optionally, for the first transaction and the second transaction, where the first transaction and the second transaction are any two transactions among the multiple transactions, the zero-knowledge proof of the first transaction includes a third zero-knowledge proof corresponding to the second Merkle state tree, and the zero-knowledge proof of the second transaction includes a fourth zero-knowledge proof corresponding to the second Merkle state tree;

[0068] The third zero-knowledge proof and the fourth zero-knowledge proof are generated in the following manner:

[0069] Generate a third Merkle proof for the third leaf node corresponding to the first transaction in the second Merkle state tree, where the third Merkle proof is used to prove the position information of the third leaf node in the second Merkle state tree;

[0070] Generate the third zero-knowledge proof based on the first transaction, the third leaf node, the third Merkle proof, and the second root node of the second Merkle state tree;

[0071] Generate a fourth Merkle proof for the fourth leaf node corresponding to the second transaction in the second Merkle state tree, where the fourth Merkle proof is used to prove the position information of the fourth leaf node in the second Merkle state tree;

[0072] Generate the fourth zero-knowledge proof based on the second transaction, the fourth leaf node, the fourth Merkle proof, and the second root node of the second Merkle state tree.

[0073] Fourthly, the present invention provides a management device for the state data of a DAPP applied to a blockchain. The device is a blockchain node and includes:

[0074] An acquisition module, configured to acquire an aggregated transaction, an aggregated zero-knowledge proof, and the root node of the second Merkle state tree; the aggregated transaction is obtained based on multiple transactions, the aggregated zero-knowledge proof is obtained based on the zero-knowledge proofs of the multiple transactions, and the proof content of the aggregated zero-knowledge proof is equivalent to the total proof content of the zero-knowledge proofs of the multiple transactions; the second Merkle state tree is updated from the first Merkle state tree of the blockchain after the multiple transactions are successfully executed on the blockchain;

[0075] A storage module for executing the aggregation transaction, verifying the aggregation zero-knowledge proof by invoking the smart contract of the blockchain, and storing the root node after successful verification.

[0076] For the beneficial effects of each optional device in the second and fourth aspects above, reference may be made to the beneficial effects of each optional method in the first aspect and the first aspect above, which will not be elaborated here.

[0077] In a fifth aspect, the present invention provides a computer device including a program or instruction, which when executed, is used to execute the methods in the first aspect, the second aspect, and each optional method above.

[0078] In a sixth aspect, the present invention provides a storage medium including a program or instruction, which when executed, is used to execute the methods in the first aspect, the second aspect, and each optional method above.

[0079] These aspects or other aspects of the present invention will be more clearly understood in the following description of the embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0080] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention, and those of ordinary skill in the art can obtain other drawings based on these drawings without creative efforts.

[0081] Figure 1 A schematic flowchart corresponding to a method for managing the status data of a DAPP applied to a blockchain provided by an embodiment of the present invention;

[0082] Figure 2 A schematic diagram of the change of the Merkle status tree in a method for managing the status data of a DAPP applied to a blockchain provided by an embodiment of the present invention;

[0083] Figure 3 A schematic structural diagram of a device for managing the status data of a DAPP applied to a blockchain provided by an embodiment of the present invention;

[0084] Figure 4 A schematic structural diagram of a device for managing the status data of a DAPP applied to a blockchain provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0085] To make the objectives, technical solutions and advantages of the present invention more clear, the present invention will be further described in detail below with reference to the accompanying drawings. Apparently, the described embodiments are only a part rather than all of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the scope of protection of the present invention.

[0086] For the convenience of description, the definitions of the terms in this application are listed first.

[0087] Zero-knowledge proof and recursive proof: The zero-knowledge proof algorithm can be used to prove and verify the following statement: Given a result verification algorithm F corresponding to a public function and a public input x, and knowing a secret input w, it can satisfy F(x, w) = true. The zero-knowledge proof generally includes three sub-algorithms:

[0088] ZK.Setup: Taking the function F and the security parameter λ as inputs, it outputs a set of invariant parameters crs and a backdoor td, where crs contains two parts. The part used for proof is called the proof key crs p , and the part used for verification is called the verification key crs v ;

[0089] ZK.Prover: The prover takes the proof key crs p , the public input x of the function F and the secret input w as inputs, and outputs a proof π;

[0090] ZK.Verifier: The verifier takes the verification key crs v , the public input x of the function F and the proof π as inputs, and outputs 0 or 1 to indicate rejection or acceptance. Anyone can execute this algorithm.

[0091] The zero-knowledge proof algorithm satisfies four properties:

[0092] Completeness: If an honest prover makes a proof π based on the proof key crs p , the public input x of the function F and the secret input w, then the result of the verifier executing the ZK.Verifier algorithm must be acceptance.

[0093] Knowledge concealment: For a proof π and a public input x, no one can deduce the prover's secret input w from these two.

[0094] Zero-knowledge property: For any two proofs π and π′, no adversary can distinguish which two secret inputs these two proofs are calculated from. Or rather, as long as the secret inputs are different, the calculated zero-knowledge proofs are also different.

[0095] Simplicity: Prove that the size of π should be sublinear with respect to the sizes of the public input x and the secret input w.

[0096] For an algorithm or program that satisfies NP, such as the Merkle proof algorithm, the way to construct a zero - knowledge proof for this algorithm is usually to represent the verification algorithm of the Merkle proof using specialized arithmetic circuits, which is essentially also a program. However, in this arithmetic circuit, the dependency relationships of each variable in the verification algorithm are added, including the dependencies of the input and output. Then, all the dependency relationships are transformed into a set of polynomial expressions, and then polynomial commitments are made to this set of polynomials. Finally, the verifier verifies the commitment. Currently, the algorithm toolchains for various zero - knowledge proofs are very mature. One only needs to represent the algorithm or program to be proven using arithmetic circuits, and the subsequent steps can be used by relevant tool algorithms to generate zero - knowledge proofs based on the arithmetic circuits and the input.

[0097] Recursive zero - knowledge proof is the recursive aggregation of zero - knowledge proofs themselves. Since the verification calculation of zero - knowledge proofs is itself a program that satisfies NP, it is also possible to construct a circuit for this calculation to make a further proof. By taking multiple zero - knowledge proofs as public inputs (not aggregating the proofs themselves, but making zero - knowledge proofs for the verification calculations of multiple proofs), a recursive zero - knowledge proof is obtained. Recursively proving the zero - knowledge proofs of two identical circuits, after successive recursions, a root zero - knowledge proof is obtained. The meanings of the symbols and the execution process are given in detail in the subsequent scheme description.

[0098] Ethereum Virtual Machine (EVM): The role of the EVM is to compile smart contract code into machine code that can be executed on Ethereum and provide a running environment for smart contracts. It is a completely isolated sandbox environment that cannot access the network or files during operation, even with limited access permissions between different contracts. To maintain a high degree of determinism in the running results of smart contracts, the running environment of smart contracts is crucial. Let Ethereum node participants download the Ethereum client and run it on their own machines through the "Ethereum Virtual Machine" operating system, which better shields the underlying differences of each computer node and better realizes the same results of contract execution on different nodes, that is, determinism.

[0099] Decentralized Application (Dapp): A Dapp generally refers to an application that runs on a blockchain and uses smart contracts to implement relevant business logic. Such an application has the decentralized characteristics of the blockchain, ensuring that the operation of the application is open and transparent. For example, a Dapp like decentralized finance (Defi) often needs to store all user data, such as user balances, in the smart contract on the chain, as well as the basic state of the entire business, such as current pricing information. All variables that require storage space belong to the state of the smart contract, while other code in the smart contract, such as functions, is the business logic. From the perspective of how smart contracts operate, users each send transactions to call functions in the smart contract on the chain. Then, blockchain nodes verify the basic information of each transaction, such as signatures, and then run the EVM to load the corresponding smart contract code and execute the functions called by the users (this also includes the verification of user states, such as balance verification). Finally, the state of the smart contract is changed.

[0100] Rollup: Rollup is an off-chain scaling solution proposed for the transaction rate limit of Ethereum. Since many Dapps run on Ethereum, but users can only use Dapps by sending transactions. Rollup "aggregates / summarizes" a large number of transactions of a certain Dapp into one transaction off-chain. There are mainly two implementation schemes for Rollup, namely Optimistic Rollup (Optimistic Aggregation) and zk-Rollup (Aggregation Based on Zero-Knowledge Proof). Both collect transactions off-chain, then execute the transactions, and finally update the new state after the batch transactions to the smart contract on the chain, that is, the smart contracts on the chain do not need to execute specific business logic. The former mainly uses fraud proofs, while the latter is based on zero-knowledge proofs. Optimistic Rollup uses ovm (a virtual machine similar to EVM that supports more opcodes than EVM) to execute smart contracts off-chain. Optimistic Rollup tends to default that all participants are good people and believes that nodes will not do bad things. If fraud occurs, users will construct fraud proofs and submit them to the smart contract on the chain to prove that the nodes have done something wrong. zk-Rollup, on the other hand, uses zero-knowledge proofs to prove that each transaction has been correctly executed off-chain. It tends to default that all participants may be bad people and does not need to trust any node.

[0101] During the operation of financial institutions (banking institutions, insurance institutions, or securities institutions) in conducting business (such as loan business, deposit business, etc. of banks), the status data of users is often maintained on the blockchain through a Merkle tree. In the prior art, after each transaction is executed, a zero-knowledge proof needs to be generated to prove its legality, and the zero-knowledge proof needs to be verified. The computational overhead will increase as the Merkle tree grows. This situation does not meet the requirements of financial institutions such as banks and cannot ensure the efficient operation of various businesses of financial institutions.

[0102] For this reason, referring to Figure 1 , an embodiment of the present invention provides a method for managing the status data of a DAPP applied to a blockchain.

[0103] Step 101: Obtain a plurality of transactions and the zero-knowledge proofs of the plurality of transactions.

[0104] Among them, the zero-knowledge proof of any transaction is used to prove the legality of the transaction.

[0105] Step 102: Send the plurality of transactions to the Ethereum Virtual Machine (EVM) service; after determining that the plurality of transactions are successfully executed on the EVM service, update the off-chain first Merkle state tree to a second Merkle state tree according to the plurality of transactions.

[0106] The first Merkle state tree is the Merkle state tree before the successful execution of the plurality of transactions, and the second Merkle state tree is the Merkle state tree after the successful execution of the plurality of transactions.

[0107] Step 103: Process the plurality of transactions into an aggregated transaction; generate an aggregated zero-knowledge proof according to the zero-knowledge proofs of the plurality of transactions.

[0108] The proof content of the aggregated zero-knowledge proof is equivalent to the total proof content of the zero-knowledge proofs of the plurality of transactions.

[0109] Step 104: Send the aggregated transaction, the aggregated zero-knowledge proof, and the root node of the second Merkle state tree to the blockchain.

[0110] Step 104 can enable the blockchain to execute the aggregated transaction, and after the smart contract of the blockchain verifies that the aggregated zero-knowledge proof passes, store the root node.

[0111] It should be noted that steps 101 to 104 can be implemented in the following manner:

[0112] The participants in Steps 101 to 104 may include users, smart contracts on the blockchain, and three services, namely, a transaction processing service, an EVM service, and a zero-knowledge proof service. These three services run off-chain and can be on the same machine or on different machines. The smart contract and the three services can be deployed according to the following steps:

[0113] Write a complete smart contract A according to business requirements, including state management and business processing logic, namely various functions; extract the business processing logic part of smart contract A into another separate smart contract B, change the direct use of state variables in the function to parameter passing, and there is only one root state variable in smart contract B, and then deploy smart contract B onto the chain; abstract all states into a Merkle state tree, that is, each smallest granularity variable is a leaf node of the Merkle tree (this step can be implemented in any programming language), and integrate it with functions such as Ethereum transaction parsing, creation, and listening into a transaction processing service; a zero-knowledge proof service can be built based on the zero-knowledge proof framework provided by the present invention, including the generation and verification of zero-knowledge proofs for the correctness of states and signatures, and the recursion of zero-knowledge proofs; use any EVM independent environment software to build an EVM service and only run smart contract B.

[0114] Specifically, the zero-knowledge proof framework can be a state management and business logic combination framework, which can be specifically divided into three stages: old state verification (i.e., verification of state data before multiple transactions are executed, including verification of basic transaction information), business logic execution, and new state verification (i.e., verification of state data after multiple transactions are executed, including verification of basic transaction information). The state data of each user on the blockchain can be stored, managed, and proven to be correct off-chain. The old states and parameters required for business logic can be batch-packed into a transaction by a smart contract on the blockchain, and the new states generated are also managed off-chain. State management can be carried out in many ways. Ethereum uses a Patricia-Merkle tree, as well as a classic Merkle tree (a complete binary tree, hereinafter simply referred to as a Merkle tree) and a Verkle tree, etc. Each smallest granularity variable is a leaf node of the tree (representing the value of a state variable of a user), and the smart contract on the chain only needs to save the root of the state tree to ensure that the entire application is executed in a consistent state.

[0115] The zero-knowledge proof framework can be based on the UltraPlonk zero-knowledge proof program syntax and provides two basic circuits: a state management circuit based on a Merkle tree and a signature verification circuit based on an elliptic curve.

[0116] State Management Circuit: State management based on the Merkle tree involves the insertion and update of leaf nodes. Any change to all leaf nodes will result in a change to the root node. These insertions, updates, and operations can be implemented with ordinary code, but zero-knowledge proofs are required to ensure that a certain leaf node corresponds to the root node of the state tree at a certain time, that is, to verify the Merkle proof of the path from this node to the root, which also means verifying that the user's state is correct and conforms to the overall ledger. The private parameters required for this circuit are the path information address_bits of the node corresponding to the state data and the sibling node values path on the path. The only public parameter required is the known depth depth of the tree, the Merkle root root, and the leaf value leaf.

[0117] Signature Verification Circuit: Since the user's transactions are processed off-chain, the transaction processing service needs to verify the correctness of each transaction, mainly verifying the signature of the transaction. The check of the user's state, such as the balance, is controlled by the state management circuit. Therefore, providing a signature verification based on the elliptic curve can meet the usage requirements of most blockchains and Dapps, and the elliptic curve itself is configurable and replaceable. The private parameters required for this circuit are the content of the signature in_msg and the user's public key in_params. The only public parameter required is the signature itself in_S = {in_base, in_A, in_R, in_s}.

[0118] The zero-knowledge proof service is built on these two circuits. For each transaction, a zero-knowledge proof needs to be generated according to the above two circuits. Anyone only needs to verify this zero-knowledge proof to be convinced that the transaction is legal. In order to improve the verification efficiency of smart contracts for zero-knowledge proofs, this solution uses recursive zero-knowledge proofs (supported by UltraPlonk). The smart contract on the chain does not need to verify the zero-knowledge proofs generated by each transaction. Through the recursive processing of the zero-knowledge proofs, only the root zero-knowledge proof obtained after recursion needs to be verified. The specific algorithm can be as follows:

[0119] ZK.Setup(λ,T) → pp: Initialization of the zero-knowledge proof framework, including the initialization of the zero-knowledge proof algorithm and the initialization of recursive proofs. Taking the security parameter λ and the response delay parameter T as inputs, it outputs the global public parameter pp, where pp = (crs, G, g, l), G represents the elliptic curve group, g is the generator, and l is the length of the random sequence.

[0120] ZK.Prove(pp,depth,address_bits,path,root,leaf,in_msg,in_params,in_S) → π, in_S is the signature. The zero-knowledge proof service generates the aggregated zero-knowledge proof π according to the state management circuit and the signature verification circuit, passing in the required public parameters and private parameters.

[0121] ZK.Verify(pp, depth, root, leaf, in_S, π) → {0, 1}. Anyone can use this verification algorithm to verify the aggregated zero - knowledge proof. Output 0 indicates verification failure, and 1 indicates verification success. If the smart contract on the blockchain verifies the aggregated zero - knowledge proof successfully, it will store the root node of the second Merkle state tree on the blockchain.

[0122] The zero - knowledge proof service recursively verifies the state transformation of two zero - knowledge proofs. The state mainly includes the root of the Merkle state tree, the number of transactions, and the transaction process state. The transaction process state can be one of the following: Z1 represents the state and signature of the input of the verified transaction, i.e., the initiating user; Z2 represents that a zero - knowledge proof has been generated for the input of the transaction; Z3 represents that the execution off - chain of the transaction and the update of the state tree have been completed; Z4 represents that a zero - knowledge proof has been generated for the output of the transaction; Z5 represents the depth of the completion of the zero - knowledge proof recursion; and Z6 represents the completion of the final recursive proof. The transaction process state identifies the values of various system variables when the zero - knowledge proof service generates the zero - knowledge proof of a transaction or the recursive proof. The role of the state transformation function is to link the entire recursive process together.

[0123] The zero - knowledge proof service performs a recursive proof on any two zero - knowledge proofs, including verifying π 1 and π 2 for correctness and state transformation, and generates a recursive proof This algorithm mainly transforms the zero - knowledge proof verification algorithm as follows:

[0124] ZK.Verify(pp, root, leaf, in_base, in_A, in_R, in_s, π) → {0, 1} is transformed into an arithmetic circuit. With any two zero - knowledge proofs (π 1 , π 2 ), the common inputs (x 1 , x 2 ) = {root, leaf, in_base, in_A, in_R, in_s} required to verify these two proofs and the states (st 1 , st 2 ) when generating these two proofs as the secret input w, and the state after recursion as the common input x.

[0125] RZK.Verify(π root , st root) → {0, 1}: The final verification function takes the root recursive proof and the corresponding state as input to verify the correctness of the root proof. This root proof can represent the zero-knowledge proof made by the zero-knowledge proof service for each transaction. The smart contract on the chain only needs to verify this root proof, which is equivalent to verifying the zero-knowledge proofs of all transactions and also equivalent to verifying all transactions. Therefore, the transactions are aggregated.

[0126] Separate the business logic and state management. The present invention is also a two-layer expansion solution, which designs a framework for decoupling state management and business logic, stores all state data related to Dapp users, i.e., all state data, off-chain, enabling operations such as state management and transaction signature verification to be executed off-chain, reducing the burden of state data storage and management on the smart contract on the chain. Even if the state data continues to increase, the computational consumption of the smart contract on the chain is not affected.

[0127] Due to the decoupling of state management and business logic, developers of transaction aggregation applications do not need to construct a zero-knowledge proof circuit for the business logic. Instead, they directly adopt the general and efficient state maintenance and signature verification zero-knowledge proof circuits provided by this solution to make zero-knowledge proofs for the legality of the old and new states respectively. The business logic (related functions) is still implemented on the smart contract, so the correctness of state changes can be verified and guaranteed by the smart contract on the chain.

[0128] The following details a method for managing the state data of a DAPP applied to a blockchain. It should be noted that when applying this method, Dapp developers can set the number of transactions for one-time aggregation according to business requirements and the zero-knowledge proof algorithm used. Since the two circuits provided by the present invention both use the UltraPlonk zero-knowledge proof, which is suitable for directly aggregating two zero-knowledge proofs, the following takes the aggregation of two transactions in a decentralized ledger as an example (but multiple aggregations can also be performed to achieve the purpose of aggregating multiple transactions). This ledger application uses a three-layer Merkle tree to manage the balance data of users, which is stored in the off-chain transaction processing service, and the three off-chain services are deployed on different machines. At a certain moment, the balance of user A is K1 old , and the balance of user B is K2 old . User A wants to withdraw n1 Tokens from the ledger, while user B wants to store n2 Tokens in the ledger. For a transaction of a user interacting with smart contract B, it will not be directly submitted to the blockchain but will be first handed over to off-chain processing. The changes in the state tree before and after the two transactions are as Figure 2 shown. The specific process is as follows:

[0129] Step (1): User A calls a smart contract through the client to create a transaction A for calling the smart contract, such as calling a balance deduction function to subtract n1 from their balance; at the same time, User B creates a transaction B for calling the smart contract through the client, such as calling a balance increase function to add n2 to their balance; both users send the transactions to the transaction processing service of the Dapp.

[0130] In the above Step 101 to Step 104, for the first transaction (Transaction A in this example) and the second transaction (Transaction B in this example), the first transaction and the second transaction are any two transactions among the multiple transactions. The zero-knowledge proof of the first transaction includes a first zero-knowledge proof corresponding to the first Merkle state tree and a third zero-knowledge proof corresponding to the second Merkle state tree; the zero-knowledge proof of the second transaction includes a second zero-knowledge proof corresponding to the first Merkle state tree and a fourth zero-knowledge proof corresponding to the second Merkle state tree; the first zero-knowledge proof (P1) and the second zero-knowledge proof (P2) are generated in the following manner:

[0131] Generate a first Merkle proof for the first leaf node corresponding to the first transaction in the first Merkle state tree, where the first Merkle proof is used to prove the position information of the first leaf node in the first Merkle state tree; generate the first zero-knowledge proof of the first transaction based on the first transaction, the first leaf node, the first Merkle proof, and the first root node of the first Merkle state tree; generate a second Merkle proof for the second leaf node corresponding to the second transaction in the first Merkle state tree, where the second Merkle proof is used to prove the position information of the second leaf node in the first Merkle state tree; generate the second zero-knowledge proof of the second transaction based on the second transaction, the second leaf node, the second Merkle proof, and the second root node of the first Merkle state tree.

[0132] Specifically, it can be as Steps (2) to (3):

[0133] Step (2): The transaction processing service parses the transaction and extracts the value C1 of the leaf node C1 of the Merkle state tree involved in this transaction A old (i.e., the hash value of User A's balance K1 old ) and makes a Merkle proof M1 of C1 old (including the depth of the tree depth = 3, the path address_bits = (0, 0), and the values of the sibling nodes on the path path = (L2 old , C3)); extract the value C2 of the leaf node C2 of the Merkle state tree involved in this transaction B old (i.e., User B's balance K2 oldTake out the hash value of C2 and generate the Merkle proof M2 of C2 old (including the depth of the tree depth = 3, the path address_bits = (1, 0) and the values of the sibling nodes on the path path = (L1 old , C4)); Assume that the root of the state tree at this time is G old .

[0134] Step (3): The transaction processing service sends C1 old , G old , M1 old , the signature, content, and public key of user A of transaction A to the zero-knowledge proof service, which executes the zero-knowledge proof algorithm ZK.Prove(pp, depth, address_bits, path, G old , C1 old , in_msg, in_params, in_S) → P1 to generate the zero-knowledge proof P1; send C2 old , G old , M2 old , the signature, content, and public key of user B of transaction B to the zero-knowledge proof service, which executes the zero-knowledge proof algorithm ZK.Prove(pp, depth, address_bits, path, G old , C2 old , in_msg, in_params, in_S) → P2 to generate the zero-knowledge proof P2.

[0135] Step (4): The transaction processing service sends K1 old and n1 to the EVM service, which executes the balance deduction function of smart contract B and returns the new balance K1 new = K1 old - n1; The transaction processing service sends K2 old and n2 to the EVM service, which executes the balance increase function of smart contract B and returns the new balance K2 new = K2 old + n2. That is, after the transaction is executed, the third zero-knowledge proof (P3) and the fourth zero-knowledge proof (P4) can be generated. Specifically, they can be generated in the following way:

[0136] Generate a third Merkle proof for the third leaf node corresponding to the first transaction in the second Merkle state tree, where the third Merkle proof is used to prove the position information of the third leaf node in the second Merkle state tree; generate the third zero-knowledge proof based on the first transaction, the third leaf node, the third Merkle proof, and the second root node of the second Merkle state tree; generate a fourth Merkle proof for the fourth leaf node corresponding to the second transaction in the second Merkle state tree, where the fourth Merkle proof is used to prove the position information of the fourth leaf node in the second Merkle state tree; generate the fourth zero-knowledge proof based on the second transaction, the fourth leaf node, the fourth Merkle proof, and the second root node of the second Merkle state tree.

[0137] In this example, specifically, it can be as in steps (5) to (6):

[0138] Step (5): The transaction processing service calculates the new value C1 of leaf node C1 based on the new balance new , and updates the first Merkle state tree. Assume that the root of the Merkle state tree is G at this time inter ; the transaction processing service calculates the new value C2 of leaf node C2 based on the new balance new , and updates the Merkle state tree to the second Merkle state tree. Assume that the root of the state tree is G at this time new ; finally, generate Merkle proofs M1 new (including the depth of the tree depth = 3, the path address_bits = (0, 0), and the values of the sibling nodes on the path path = (L2 new , C3)) and M2 new (including the depth of the tree depth = 3, the path address_bits = (0, 0), and the values of the sibling nodes on the path path = (L2 new ) for C1 and C2 respectively according to the latest state tree.

[0139] Step (6): The transaction processing service sends C1 new , G new , M1 new , the signature, content, and public key of the transaction to the zero-knowledge proof service, and the latter executes the zero-knowledge proof algorithm ZK.Prove(pp, depth, address_bits, path, G new , C1 new , in_msg, in_params, in_S) → P3 to generate the zero-knowledge proof P3; the transaction processing service sends C2 new , G new , M2 new, the signature, content, and public key of the transaction are sent to the zero - knowledge proof service, which executes the zero - knowledge proof algorithm ZK.Prove(pp,depth,address_bits,path,G new ,C2 new ,in_msg,in_params,in_S)→P4, to produce the zero - knowledge proof P4.

[0140] So far, in this example, multiple transactions (A, B) corresponding to step 101 and zero - knowledge proofs (P1, P2, P3, P4) of multiple transactions have been generated.

[0141] The following are the steps to generate the aggregated zero - knowledge proof. The zero - knowledge proof service executes the recursive proof algorithm RZK.Pove(P1,P2,P3,P4,M1 old ,M2 old ,M1 new ,M2 new )→π to aggregate the proofs P1, P2, P3, and P4 into a proof π and send π to the transaction processing service. The aggregation of zero - knowledge proofs (step 103) is as follows:

[0142] Generate a first aggregated zero - knowledge proof based on the zero - knowledge proofs of the multiple transactions corresponding to the first Merkle state tree; generate a second aggregated zero - knowledge proof based on the zero - knowledge proofs of the multiple transactions corresponding to the second Merkle state tree; generate the aggregated zero - knowledge proof based on the first aggregated zero - knowledge proof and the second aggregated zero - knowledge proof. Specifically, it can be as follows:

[0143] Step (7 - 1): Aggregate proofs P1 and P2 to obtain a first aggregated zero - knowledge proof, and extract the common parameters required to verify P1 and P2 from the cache: depth, C1 old ,C2 old ,G old , and the signatures in_S of the two transactions. Specifically, the above - mentioned first aggregated zero - knowledge proof can be obtained as follows:

[0144] Based on the zero - knowledge proofs of the multiple transactions corresponding to the first Merkle state tree, and based on the path information from the leaf nodes corresponding to the users of the multiple transactions to the root node of the first Merkle state tree in the first Merkle state tree, iteratively generate zero - knowledge proofs until the first aggregated zero - knowledge proof is generated.

[0145] It should be noted that in steps 101 - 104, commitments for verification can also be generated. Specifically:

[0146] Generate a first state commitment corresponding to the multiple transactions in the first Merkle state tree based on the leaf nodes corresponding to the multiple transactions in the first Merkle state tree. The first state commitment is used to prove that the zero-knowledge proof corresponding to each transaction in the multiple transactions is bound to the leaf node corresponding to the transaction in the first Merkle state tree.

[0147] Generate a second state commitment corresponding to the multiple transactions in the second Merkle state tree based on the leaf nodes corresponding to the users of the multiple transactions in the second Merkle state tree. The second state commitment is used to prove that the zero-knowledge proof corresponding to each transaction in the multiple transactions is bound to the leaf node corresponding to the transaction in the second Merkle state tree.

[0148] In a possible implementation, the first state commitment can be generated in the following manner:

[0149] Generate the first state commitment (G1) based on the leaf nodes corresponding to the multiple transactions in the first Merkle state tree, the transaction execution status of the multiple transactions, the transaction sequence numbers of the multiple transactions, and the first root node of the first Merkle state tree. Specifically, it can be as in steps (7-2) to (7-3):

[0150] Step (7-2): Execute the state transformation function Confirm the system state st when generating proofs P1 and P2 1 , st 2 : Transaction execution status Z1, transaction sequence numbers T1, T2, and the root G of the state tree old . Update the transformed system state Transaction execution status and the commitment Com1 that binds the front and back states.

[0151] Step (7-3): Construct a zero-knowledge proof verification circuit, establish constraint relationships for the two required recursive proofs P1 and P2, the public verification parameters, and the front and back system states, and then transform them into a polynomial commitment G1 to obtain the recursive proof π in the first stage 1 . The overall algorithm description is:

[0152]

[0153] Step (7-4): Then aggregate proofs P3 and P4 to obtain a second aggregated zero-knowledge proof, and extract the public parameters required to verify P3 and P4 from the cache: depth, C1 new , C2 new and G new .

[0154] Specifically, the second aggregated zero - knowledge proof can be obtained in the following manner:

[0155] Based on the zero - knowledge proofs corresponding to the multiple transactions in the second Merkle state tree, and based on the path information from the leaf nodes corresponding to the multiple transactions in the second Merkle state tree to the root node of the second Merkle state tree, iteratively generate zero - knowledge proofs until the second aggregated zero - knowledge proof is generated.

[0156] In a possible implementation, the second state commitment can be generated in the following manner:

[0157] Generate the second state commitment according to the leaf nodes corresponding to the multiple transactions in the second Merkle state tree, the transaction execution status of the multiple transactions, the transaction serial numbers of the multiple transactions, and the second root node of the second Merkle state tree. The specific steps can be as in steps (7 - 5) to (7 - 6):

[0158] Step (7 - 5): Execute the state transformation function Confirm the system state st when generating proofs P3 and P4 3 , st 4 : Transaction execution status Z4, transaction serial numbers T1, T2, and the root G of the state tree new . Update the transformed system state Transaction execution status and the commitment Com2 bound to the front and back states.

[0159] Step (7 - 6): Construct a zero - knowledge proof verification circuit, establish constraint relationships for the two required recursive proofs P3 and P4, the common verification parameters, and the front and back system states, and then transform them into a polynomial commitment G2 to obtain the recursive proof π of the first stage 2 . The overall algorithm description is as follows:

[0160]

[0161] Step (7 - 7): Aggregate π 1 and π 2 , extract the common parameters for verifying π 1 and π 2 from the previous two aggregation calculation processes: the polynomial commitment G1 and its challenge point sequence and the polynomial commitment G2 and its challenge point sequence

[0162] Step (7 - 8): Execute the state transformation function Confirm the system state when generating proofs π 1 and π 2 Transaction execution status when generating proofs π and the root G of the status tree old and G new Update the transformed system status Transaction execution status and the commitment Com3 bound to the previous and subsequent statuses.

[0163] Steps (7-9): Construct a zero-knowledge proof verification circuit to establish constraint relationships for the two proofs π 1 and π 2 , the public verification parameters, and the previous and subsequent system statuses, then transform them into a polynomial commitment G3, and then construct another commitment G3′. Use the vector inner product proof algorithm to prove that G3′ and G3 have the same structure to obtain the final recursive proof π. The overall algorithm description is as follows:

[0164]

[0165] Step (8): The transaction processing service assembles K1 old , n1, K2 old , n2, G old , G new , and π into a transaction and sends it to the smart contract B on the chain.

[0166] Correspondingly, the blockchain node also has a management method for the status data of the DAPP applied to the blockchain, which can be specifically as follows:

[0167] The blockchain node obtains the aggregated transaction, the aggregated zero-knowledge proof, and the root node of the second Merkle status tree; the blockchain node executes the aggregated transaction, verifies the aggregated zero-knowledge proof by calling the smart contract of the blockchain, and stores the root node after successful verification.

[0168] Step (9): The smart contract B calls the balance deduction and balance increase functions to obtain K1 new and K2 new , and then executes the verification function of the recursive proof:

[0169] RZK.Verify(π, Com3, S3, G old , G new , M1 old , M1 new ) → {0,1} to verify whether the aggregation of the two transactions is correct. The specific verification is as follows:

[0170] Step (9-1): Verify whether the new balances K1 new and K2 new of the user exceed the range.

[0171] Step (9-2): By executing Check whether the state transition process of the system is correct, and at the same time, it can be checked whether the aggregated transactions have been processed off-chain.

[0172] Step (9-3): Verify whether the off-chain state tree is updated correctly, that is, respectively verify the Merkle proofs M1 old and M1 new .

[0173] Step (9-4): Execute ZK.Verify(pp, π, G3′, G3, S3) → {0, 1} to verify the final recursive proof π, that is, verify whether the two polynomial commitments G3′ and G3 have the same value in the challenge sequence S3.

[0174] Step (10): If any one of the verifications fails, the transaction processing service will roll back the transaction, that is, roll back the state to before the execution of these two transactions; if the verification passes, the current state will be saved.

[0175] In the state data management method of a DAPP applied to a blockchain proposed by the present invention, the business logic and state management can be separated. Many complex decentralized applications (Dapps) with high-frequency transactions can quickly switch to zk-Rollup without developers having profound cryptography, especially zero-knowledge proof technology and knowledge. They only need to write smart contracts in the same way as traditional Dapp development methods, which can achieve a large blockchain expansion gain at present without compromising the decentralized characteristics, ensure the correct execution of each transaction interacting with the smart contract, and at the same time protect the privacy of transaction users.

[0176] As Figure 3 shown, the present invention provides a state data management device for a DAPP applied to a blockchain, including:

[0177] An acquisition module 301, configured to acquire a plurality of transactions and the zero-knowledge proofs of the plurality of transactions. The zero-knowledge proof of any transaction is used to prove the legality of the transaction;

[0178] A processing module 302, configured to send the plurality of transactions to an Ethereum Virtual Machine (EVM) service; after determining that the plurality of transactions are successfully executed on the EVM service, update the off-chain first Merkle state tree to a second Merkle state tree according to the plurality of transactions. The first Merkle state tree is the Merkle state tree before the successful execution of the plurality of transactions, and the second Merkle state tree is the Merkle state tree after the successful execution of the plurality of transactions; and

[0179] for processing the multiple transactions into one aggregated transaction; generating an aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions, where the proof content of the aggregated zero-knowledge proof is equivalent to the total proof content of the zero-knowledge proofs of the multiple transactions;

[0180] A sending module 303, configured to send the aggregated transaction, the aggregated zero-knowledge proof, and the root node of the second Merkle state tree to a blockchain, so that the blockchain executes the aggregated transaction, and stores the root node after the aggregated zero-knowledge proof is verified to pass by a smart contract of the blockchain.

[0181] Optionally, the processing module 302 is specifically configured to:

[0182] generate a first aggregated zero-knowledge proof according to the zero-knowledge proofs corresponding to the multiple transactions in the first Merkle state tree;

[0183] generate a second aggregated zero-knowledge proof according to the zero-knowledge proofs corresponding to the multiple transactions in the second Merkle state tree;

[0184] generate the aggregated zero-knowledge proof according to the first aggregated zero-knowledge proof and the second aggregated zero-knowledge proof.

[0185] Optionally, the processing module 302 is specifically configured to:

[0186] generate zero-knowledge proofs iteratively according to the zero-knowledge proofs corresponding to the multiple transactions in the first Merkle state tree and based on the path information from the leaf nodes corresponding to the multiple transactions in the first Merkle state tree to the root node of the first Merkle state tree until the first aggregated zero-knowledge proof is generated;

[0187] generate zero-knowledge proofs iteratively according to the zero-knowledge proofs corresponding to the multiple transactions in the second Merkle state tree and based on the path information from the leaf nodes corresponding to the multiple transactions in the second Merkle state tree to the root node of the second Merkle state tree until the second aggregated zero-knowledge proof is generated.

[0188] Optionally, the processing module 302 is further configured to:

[0189] generate a first state commitment corresponding to the multiple transactions in the first Merkle state tree according to the leaf nodes corresponding to the multiple transactions in the first Merkle state tree, where the first state commitment is used to prove that the zero-knowledge proof corresponding to each transaction in the multiple transactions in the first Merkle state tree is bound to the leaf node corresponding to the transaction in the first Merkle state tree;

[0190] Generate a second state commitment corresponding to the multiple transactions at the leaf nodes of the second Merkel state tree, where the second state commitment is used to prove that the zero-knowledge proof corresponding to each transaction in the multiple transactions is bound to the leaf node corresponding to the transaction in the second Merkel state tree.

[0191] Optionally, the processing module 302 is specifically configured to:

[0192] Generate the first state commitment according to the leaf nodes corresponding to the multiple transactions in the first Merkel state tree, the transaction execution status of the multiple transactions, the transaction serial numbers of the multiple transactions, and the first root node of the first Merkel state tree;

[0193] Generate the second state commitment according to the leaf nodes corresponding to the multiple transactions in the second Merkel state tree, the transaction execution status of the multiple transactions, the transaction serial numbers of the multiple transactions, and the second root node of the second Merkel state tree.

[0194] Optionally, for a first transaction and a second transaction, where the first transaction and the second transaction are any two transactions in the multiple transactions, the zero-knowledge proof of the first transaction includes a first zero-knowledge proof corresponding to the first Merkel state tree, and the zero-knowledge proof of the second transaction includes a second zero-knowledge proof corresponding to the first Merkel state tree;

[0195] The first zero-knowledge proof and the second zero-knowledge proof are generated in the following manner:

[0196] Generate a first Merkel proof corresponding to the first leaf node of the first transaction in the first Merkel state tree, where the first Merkel proof is used to prove the position information of the first leaf node in the first Merkel state tree;

[0197] Generate the first zero-knowledge proof of the first transaction according to the first transaction, the first leaf node, the first Merkel proof, and the first root node of the first Merkel state tree;

[0198] Generate a second Merkel proof corresponding to the second leaf node of the second transaction in the first Merkel state tree, where the second Merkel proof is used to prove the position information of the second leaf node in the first Merkel state tree;

[0199] Generate the second zero-knowledge proof of the second transaction according to the second transaction, the second leaf node, the second Merkel proof, and the second root node of the first Merkel state tree.

[0200] Optionally, for the first transaction and the second transaction, where the first transaction and the second transaction are any two transactions among the multiple transactions, the zero-knowledge proof of the first transaction includes a third zero-knowledge proof corresponding to the second Merkle state tree, and the zero-knowledge proof of the second transaction includes a fourth zero-knowledge proof corresponding to the second Merkle state tree;

[0201] The third zero-knowledge proof and the fourth zero-knowledge proof are generated in the following manner:

[0202] Generate a third Merkle proof for the third leaf node corresponding to the first transaction in the second Merkle state tree, where the third Merkle proof is used to prove the position information of the third leaf node in the second Merkle state tree;

[0203] Generate the third zero-knowledge proof based on the first transaction, the third leaf node, the third Merkle proof, and the second root node of the second Merkle state tree;

[0204] Generate a fourth Merkle proof for the fourth leaf node corresponding to the second transaction in the second Merkle state tree, where the fourth Merkle proof is used to prove the position information of the fourth leaf node in the second Merkle state tree;

[0205] Generate the fourth zero-knowledge proof based on the second transaction, the fourth leaf node, the fourth Merkle proof, and the second root node of the second Merkle state tree.

[0206] As Figure 4 shown, the present invention provides a management device for the state data of a DAPP applied to a blockchain. The device is a blockchain node and includes:

[0207] An acquisition module 401, configured to acquire an aggregated transaction, an aggregated zero-knowledge proof, and the root node of a second Merkle state tree; the aggregated transaction is obtained based on multiple transactions, the aggregated zero-knowledge proof is obtained based on the zero-knowledge proofs of the multiple transactions, and the proof content of the aggregated zero-knowledge proof is equivalent to the total proof content of the zero-knowledge proofs of the multiple transactions; the second Merkle state tree is updated from the first Merkle state tree of the blockchain after the multiple transactions are successfully executed on the blockchain;

[0208] A storage module 402, configured to execute the aggregated transaction, verify the aggregated zero-knowledge proof by invoking the smart contract of the blockchain, and store the root node after successful verification.

[0209] Based on the same inventive concept, an embodiment of the present invention further provides a computer device, including a program or instruction, when the program or instruction is executed, the method for managing the state data of a DAPP applied to a blockchain provided by the embodiment of the present invention and any optional method are executed.

[0210] Based on the same inventive concept, an embodiment of the present invention further provides a computer-readable storage medium, including a program or instruction, when the program or instruction is executed, the method for managing the state data of a DAPP applied to a blockchain provided by the embodiment of the present invention and any optional method are executed.

[0211] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, or a computer program product. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0212] The present invention is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be realized 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 for realizing in the process Figure 1 a process or multiple processes and / or blocks Figure 1 a block or multiple blocks the device for the specified functions.

[0213] 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 article including an instruction device, and the instruction device realizes in the process Figure 1 a process or multiple processes and / or blocks Figure 1 a block or multiple blocks the specified functions.

[0214] 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 for realizing in the process Figure 1 a process or multiple processes and / or blocksFigure 1 Steps of the functions specified in one or more boxes.

[0215] Although the preferred embodiments of the present invention have been described, those skilled in the art can make additional changes and modifications to these embodiments once they learn the basic creative concepts. Therefore, the appended claims are intended to be construed to include the preferred embodiments as well as all changes and modifications that fall within the scope of the present invention.

[0216] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention is also intended to include these modifications and variations.

Claims

1. A method for managing the state data of a DAPP applied to a blockchain, characterized in that, it includes: Obtain multiple transactions and the zero-knowledge proofs of the multiple transactions, and the zero-knowledge proof of any transaction is used to prove the legality of the transaction; Send the multiple transactions to the Ethereum Virtual Machine (EVM) service; After determining that the multiple transactions are successfully executed on the EVM service, update the off-chain first Merkle state tree to a second Merkle state tree according to the multiple transactions. The first Merkle state tree is the Merkle state tree before the multiple transactions are successfully executed, and the second Merkle state tree is the Merkle state tree after the multiple transactions are successfully executed; each leaf node of the Merkle state tree is the smallest granularity variable of each transaction; Process the multiple transactions into an aggregated transaction; Generate an aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions, and the proof content of the aggregated zero-knowledge proof is equivalent to the total proof content of the zero-knowledge proofs of the multiple transactions; Send the aggregated transaction, the aggregated zero-knowledge proof, and the root node of the second Merkle state tree to the blockchain, so that the blockchain executes the aggregated transaction, and stores the root node after the smart contract on the blockchain verifies that the aggregated zero-knowledge proof passes.

2. The method according to claim 1, characterized in that, the generating an aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions includes: Generating a first aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions corresponding to the first Merkle state tree; Generating a second aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions corresponding to the second Merkle state tree; Generating the aggregated zero-knowledge proof according to the first aggregated zero-knowledge proof and the second aggregated zero-knowledge proof.

3. The method according to claim 2, characterized in that, the generating a first aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions corresponding to the first Merkle state tree includes: Generating a zero-knowledge proof iteratively according to the zero-knowledge proofs of the multiple transactions corresponding to the first Merkle state tree, based on the path information from the leaf nodes corresponding to the multiple transactions to the root node of the first Merkle state tree, until the first aggregated zero-knowledge proof is generated; the generating a second aggregated zero-knowledge proof according to the zero-knowledge proofs of the multiple transactions corresponding to the second Merkle state tree includes: Generating a zero-knowledge proof iteratively according to the zero-knowledge proofs of the multiple transactions corresponding to the second Merkle state tree, based on the path information from the leaf nodes corresponding to the multiple transactions to the root node of the second Merkle state tree, until the second aggregated zero-knowledge proof is generated.

4. The method according to claim 2, characterized in that, it further includes: Generate a first state commitment corresponding to the multiple transactions in the first Merkle state tree according to the leaf nodes corresponding to the multiple transactions in the first Merkle state tree, where the first state commitment is used to prove that the zero-knowledge proof corresponding to each transaction in the multiple transactions is bound to the leaf node corresponding to the transaction in the first Merkle state tree; Generate a second state commitment corresponding to the multiple transactions in the second Merkle state tree according to the leaf nodes corresponding to the multiple transactions in the second Merkle state tree, where the second state commitment is used to prove that the zero-knowledge proof corresponding to each transaction in the multiple transactions is bound to the leaf node corresponding to the transaction in the second Merkle state tree.

5. The method according to claim 4, wherein, the generating of the first state commitment corresponding to the multiple transactions in the first Merkle state tree according to the leaf nodes corresponding to the multiple transactions in the first Merkle state tree includes: generating the first state commitment according to the leaf nodes corresponding to the multiple transactions in the first Merkle state tree, the transaction execution status of the multiple transactions, the transaction serial numbers of the multiple transactions, and the first root node of the first Merkle state tree; the generating of the second state commitment corresponding to the multiple transactions in the second Merkle state tree according to the leaf nodes corresponding to the multiple transactions in the second Merkle state tree includes: generating the second state commitment according to the leaf nodes corresponding to the multiple transactions in the second Merkle state tree, the transaction execution status of the multiple transactions, the transaction serial numbers of the multiple transactions, and the second root node of the second Merkle state tree.

6. The method according to any one of claims 1 to 5, wherein, for a first transaction and a second transaction, the first transaction and the second transaction are any two transactions among the multiple transactions, the zero-knowledge proof of the first transaction includes a first zero-knowledge proof corresponding to the first Merkle state tree, and the zero-knowledge proof of the second transaction includes a second zero-knowledge proof corresponding to the first Merkle state tree; the first zero-knowledge proof and the second zero-knowledge proof are generated in the following manner: generate a first Merkle proof of the first leaf node corresponding to the first transaction in the first Merkle state tree, where the first Merkle proof is used to prove the position information of the first leaf node in the first Merkle state tree; generate the first zero-knowledge proof of the first transaction according to the first transaction, the first leaf node, the first Merkle proof, and the first root node of the first Merkle state tree; generate a second Merkle proof of the second leaf node corresponding to the second transaction in the first Merkle state tree, where the second Merkle proof is used to prove the position information of the second leaf node in the first Merkle state tree; generate the second zero-knowledge proof of the second transaction according to the second transaction, the second leaf node, the second Merkle proof, and the second root node of the first Merkle state tree.

7. The method according to any one of claims 1 to 5, characterized in that, for the first transaction and the second transaction, where the first transaction and the second transaction are any two transactions among the multiple transactions, the zero-knowledge proof of the first transaction includes a third zero-knowledge proof corresponding to the second Merkle state tree, and the zero-knowledge proof of the second transaction includes a fourth zero-knowledge proof corresponding to the second Merkle state tree; The third zero-knowledge proof and the fourth zero-knowledge proof are generated in the following manner: Generate a third Merkle proof of the third leaf node corresponding to the first transaction in the second Merkle state tree, where the third Merkle proof is used to prove the position information of the third leaf node in the second Merkle state tree; Generate the third zero-knowledge proof based on the first transaction, the third leaf node, the third Merkle proof, and the second root node of the second Merkle state tree; Generate a fourth Merkle proof of the fourth leaf node corresponding to the second transaction in the second Merkle state tree, where the fourth Merkle proof is used to prove the position information of the fourth leaf node in the second Merkle state tree; Generate the fourth zero-knowledge proof based on the second transaction, the fourth leaf node, the fourth Merkle proof, and the second root node of the second Merkle state tree.

8. A method for managing state data of a DAPP applied to a blockchain, characterized in that, comprising: A blockchain node obtains an aggregated transaction, an aggregated zero-knowledge proof, and the root node of a second Merkle state tree; The aggregated transaction is obtained based on multiple transactions, the aggregated zero-knowledge proof is obtained based on the zero-knowledge proofs of the multiple transactions, and the proof content of the aggregated zero-knowledge proof is equivalent to the total proof content of the zero-knowledge proofs of the multiple transactions; The second Merkle state tree is updated from an off-chain first Merkle state tree after the multiple transactions are successfully executed on the blockchain; each leaf node of the Merkle state tree is the smallest granularity variable of each transaction; The blockchain node executes the aggregated transaction, verifies the aggregated zero-knowledge proof by calling the smart contract of the blockchain, and stores the root node after successful verification.

9. A device for managing state data of a DAPP applied to a blockchain, characterized in that, comprising: An acquisition module, configured to acquire multiple transactions and the zero-knowledge proofs of the multiple transactions, where the zero-knowledge proof of any transaction is used to prove the legality of the transaction; A processing module, configured to send the multiple transactions to an Ethereum Virtual Machine (EVM) service; After determining that the multiple transactions are successfully executed on the EVM service, update the off-chain first Merkle state tree to a second Merkle state tree according to the multiple transactions, where the first Merkle state tree is the Merkle state tree before the multiple transactions are successfully executed, and the second Merkle state tree is the Merkle state tree after the multiple transactions are successfully executed; each leaf node of the Merkle state tree is the smallest granularity variable of each transaction; and configured to process the multiple transactions into an aggregated transaction; Generate an aggregated zero-knowledge proof based on the zero-knowledge proofs of the multiple transactions, where the proof content of the aggregated zero-knowledge proof is equivalent to the total proof content of the zero-knowledge proofs of the multiple transactions; A sending module, configured to send the aggregated transaction, the aggregated zero-knowledge proof, and the root node of the second Merkle state tree to the blockchain, so that the blockchain executes the aggregated transaction, and stores the root node after the aggregated zero-knowledge proof is verified to pass by the smart contract of the blockchain.

10. A computer device, characterized in that, it includes a program or instruction, and when the program or instruction is executed by a processor, the method according to any one of claims 1 to 7 and 8 is executed.

Images