CN114298842A

CN114298842A - Method and device for managing state data of DAPP (digital addressable Polypropylene) applied to block chain

Info

Publication number: CN114298842A
Application number: CN202111660383.1A
Authority: CN
Inventors: 冼祥斌; 周禄; 张开翔; 范瑞彬
Original assignee: WeBank Co Ltd
Current assignee: WeBank Co Ltd
Priority date: 2021-12-31
Filing date: 2021-12-31
Publication date: 2022-04-08

Abstract

The invention discloses a method and a device for managing DAPP state data applied to a block chain, wherein the method comprises the following steps: obtaining zero knowledge proofs for a plurality of transactions and a 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 Mercker state tree under the chain to a second Mercker state tree according to the plurality of transactions; processing a plurality of transactions into one aggregated transaction; generating an aggregated zero knowledge proof according to the zero knowledge proofs of the multiple transactions; when the method can be applied to financial technology (Fintech), a plurality of transactions can be executed in advance in EVM service under the chain, and the obtained aggregated transactions, the aggregated zero knowledge proof and the root node are sent to the block chain for state data management, so that the separation of state data management and business logic is realized.

Description

Method and device for managing state data of DAPP (digital addressable Polypropylene) applied to block chain

Technical Field

The invention relates to the field of block chains (Blockchain) in the field of financial technology (Fintech), in particular to a method and a device for managing state data of DAPP (digital addressable polypropylene) applied to the block chains.

Background

With the development of computer technology, more and more technologies are applied in the financial field, and the traditional financial industry is gradually changing to financial technology (Fintech), but due to the requirements of the financial industry on safety and real-time performance, higher requirements are also put forward on the technologies. At present, based on the non-tamper property of the block chain, transactions in the field of financial technology are often recorded through the block chain, and the transactions can be linked up only after the validity is proved.

In the prior art, state data of a user, such as balance of the user, transaction times and the like, is often maintained on a block chain through a mercker tree. After each transaction is executed, the state data of some users are changed, and the Mercker tree is required to be changed accordingly. In the prior art, after the transaction is completed, the change of the state data of the user is proved and recorded through zero knowledge proof, and the Mercker tree is updated after the verification is successful.

However, since the state data of the user is stored in the blockchain at present, as the number of users and transactions increases, the state data of the user becomes very huge, a zero knowledge proof needs to be generated after each transaction is executed to prove the validity of the transaction, and the computation overhead caused by verifying the zero knowledge proof increases as the mercker tree becomes larger. Therefore, how to reduce the management overhead of the status data of DAPP applied to the block chain is a problem to be solved.

Disclosure of Invention

The invention provides a method and a device for managing state data of a DAPP (digital Audio Page protocol) applied to a block chain, which solve the problem of reducing the management overhead of the state data of the DAPP applied to the block chain in the prior art.

In a first aspect, the present invention provides a method for managing status data of a DAPP applied to a block chain, including:

obtaining a plurality of transactions and zero knowledge proofs of the transactions, wherein the zero knowledge proof of any transaction is used for proving the legality of the transaction;

sending the plurality of transactions to an Ethernet shop virtual machine (EVM) service; after determining that the plurality of transactions are successfully executed on the EVM service, updating a first Mercker state tree under a chain into a second Mercker state tree according to the plurality of transactions, wherein the first Mercker state tree is the Mercker state tree before the plurality of transactions are successfully executed, and the second Mercker state tree is the Mercker state tree after the plurality of transactions are successfully executed;

processing the plurality of transactions into an aggregated transaction; generating an aggregate zero knowledge proof according to the zero knowledge proofs of the transactions, wherein the proof content of the aggregate zero knowledge proof is equivalent to the total proof content of the zero knowledge proofs of the transactions;

and sending the aggregated transaction, the aggregated zero knowledge proof and the root node of the second Mercker state tree to a block chain, so that the block chain executes the aggregated transaction, and storing the root node after the intelligent contract of the block chain verifies that the aggregated zero knowledge proof passes.

In the above manner, the plurality of transactions are sent to the EVM service of the ethernet virtual machine, the execution on the EVM service is successful in advance, since the aggregate zero knowledge proof is derived from zero knowledge proofs for a plurality of transactions, and the proof content of the aggregate zero knowledge proof is equivalent to the total proof content of the zero knowledge proofs for the plurality of transactions, therefore, the verification of the aggregated zero knowledge proof can indicate that the transactions are legal transactions, and the blockchain can also verify that the transactions are legal by only one aggregated zero knowledge proof and only one time, and complex operation for generating zero knowledge proof is not involved on the chain, the second Mercker state tree of the whole update does not need to be stored on the chain, and only the root node of each Mercker state tree update needs to be stored on the chain, so that the management overhead of the state data of the DAPP applied to the block chain is reduced.

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

generating a first aggregation zero knowledge proof according to the zero knowledge proofs of the plurality of transactions corresponding to the first Mercker state tree;

generating a second aggregate zero knowledge proof according to the zero knowledge proofs of the plurality of transactions corresponding to the second Mercker state tree;

generating the aggregated zero knowledge proof from the first aggregated zero knowledge proof and the second aggregated zero knowledge proof.

In the method, the zero knowledge proofs of each transaction Mercker state tree in the transactions are aggregated respectively, so that the zero knowledge proofs before and after the execution of the transactions can be determined at one time.

Optionally, the generating a first aggregated zero knowledge proof according to the zero knowledge proofs corresponding to the multiple transactions in the first merkel state tree includes:

iteratively generating a zero knowledge proof based on path information from a leaf node corresponding to the first Mercker state tree to a root node of the first Mercker state tree of a user corresponding to the transactions according to a zero knowledge proof corresponding to the first Mercker state tree of the transactions until the first aggregate zero knowledge proof is generated;

generating a second aggregate zero knowledge proof according to the zero knowledge proofs corresponding to the plurality of transactions in the second Mercker state tree, comprising:

and iteratively generating a zero knowledge proof based on path information from the leaf nodes corresponding to the plurality of transactions in the second Mercker state tree to the root node of the second Mercker state tree according to the zero knowledge proof corresponding to the user corresponding to the plurality of transactions in the second Mercker state tree until the second aggregate zero knowledge proof is generated.

Optionally, according to the leaf nodes corresponding to the multiple transactions in the first tacle state tree, generating first state commitments corresponding to the multiple transactions in the first tacle state tree, where the first state commitments are used to prove that: zero knowledge proof of each transaction in the plurality of transactions corresponding to the first Mercker state tree is bound with a leaf node of the transaction corresponding to the first Mercker state tree;

generating a second state commitment corresponding to the plurality of transactions in the second Mercker state tree according to the leaf nodes corresponding to the plurality of transactions in the second Mercker state tree, wherein the second state commitment is used for proving that: zero knowledge proof of each transaction in the plurality of transactions corresponding to the second Mercker state tree is bound to a leaf node of the transaction corresponding to the second Mercker state tree.

In the above manner, the first state commitment can trace back the binding relationship between the transaction and the leaf node corresponding to the first tacher state tree, and the second state commitment can trace back the binding relationship between the transaction and the leaf node corresponding to the second tacher state tree, thereby improving the traceability of the transactions.

Optionally, the generating, according to the leaf node corresponding to the multiple transactions in the first merkel state tree, a first state commitment corresponding to the multiple transactions in the first merkel state tree includes:

generating the first state commitment according to leaf nodes corresponding to the multiple transactions in the first Mercker state tree, transaction execution states of the multiple transactions, transaction sequence numbers of the multiple transactions and a first root node of the first Mercker state tree;

generating a second state commitment corresponding to the plurality of transactions in the second Mercker state tree according to the leaf nodes corresponding to the plurality of transactions in the second Mercker state tree, wherein the generating comprises:

and generating the second state commitment according to leaf nodes corresponding to the plurality of transactions in the second Mercker state tree, transaction execution states of the plurality of transactions, transaction sequence numbers of the plurality of transactions and a second root node of the second Mercker state tree.

Optionally, for a first transaction and a second transaction, the first transaction and the second transaction are any two transactions in the plurality of transactions, the zero knowledge proof of the first transaction includes a first zero knowledge proof corresponding to the first mercker state tree, and the zero knowledge proof of the second transaction includes a second zero knowledge proof corresponding to the first mercker state tree;

the first zero knowledge proof and the second zero knowledge proof are generated as follows:

generating a first Mercker proof of a corresponding first leaf node of the first transaction in the first Mercker state tree, wherein the first Mercker proof is used for proving position information of the first leaf node in the first Mercker state tree;

generating a first zero knowledge proof of the first transaction from the first transaction, the first leaf node, the first Mercker proof, and a first root node of the first Mercker state tree;

generating a second Mercker proof of a second leaf node corresponding to the second transaction in the first Mercker state tree, wherein the second Mercker proof is used for proving position information of the second leaf node in the first Mercker state tree;

generating a second zero knowledge proof of the second transaction according to the second transaction, the second leaf node, the second Mercker proof, and a second root node of the first Mercker state tree.

Optionally, for a first transaction and a second transaction, the first transaction and the second transaction are any two transactions in the plurality of transactions, the zero knowledge proof of the first transaction includes a third zero knowledge proof corresponding to the second merkel state tree, and the zero knowledge proof of the second transaction includes a fourth zero knowledge proof corresponding to the second merkel state tree;

the third zero knowledge proof and the fourth zero knowledge proof are generated as follows:

generating a third Mercker proof of a third leaf sub-node corresponding to the first transaction in the second Mercker state tree, wherein the third Mercker proof is used for proving position information of the third leaf sub-node in the second Mercker state tree;

generating the third zero knowledge proof according to the first transaction, the third leaf child node, the third Mercker proof, and a second root node of the second Mercker state tree;

generating a fourth Mercker proof of a fourth leaf node corresponding to the second transaction in the second Mercker state tree, wherein the fourth Mercker proof is used for proving position information of the fourth leaf node in the second Mercker state tree;

generating the fourth zero knowledge proof according to the second transaction, the fourth leaf node, the fourth Mercker proof, and a second root node of the second Mercker state tree.

In a second aspect, the present invention provides a method for managing status data of a DAPP applied to a block chain, including:

the block chain node acquires an aggregation zero knowledge proof and a root node of a second Mercker state tree; the aggregated zero knowledge proof is obtained 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; the second Mercker state tree is obtained by updating the first Mercker state tree of the block chain after the plurality of transactions are successfully executed on the block chain;

and the block chain node verifies the aggregation zero knowledge proof by calling an intelligent contract of the block chain, and stores the root node after the verification is successful.

In a third aspect, the present invention provides a device for managing status data of DAPP applied to a block chain, including:

the acquisition module is used for acquiring a plurality of transactions and zero knowledge proofs of the transactions, and the zero knowledge proof of any transaction is used for proving the legality of the transaction;

a processing module to send the plurality of transactions to an Ethernet shop virtual machine (EVM) service; after determining that the plurality of transactions are successfully executed on the EVM service, updating a first Mercker state tree under a chain into a second Mercker state tree according to the plurality of transactions, wherein the first Mercker state tree is the Mercker state tree before the plurality of transactions are successfully executed, and the second Mercker state tree is the Mercker state tree after the plurality of transactions are successfully executed; and

for processing said plurality of transactions into an aggregated transaction; generating an aggregate zero knowledge proof according to the zero knowledge proofs of the transactions, wherein the proof content of the aggregate zero knowledge proof is equivalent to the total proof content of the zero knowledge proofs of the transactions;

and the sending module is used for sending the aggregated transaction, the aggregated zero knowledge proof and the root node of the second Mercker state tree to a block chain, so that the block chain executes the aggregated transaction, and after the intelligent contract of the block chain verifies that the aggregated zero knowledge proof passes, the root node is stored.

Optionally, the processing module is specifically configured to:

iteratively generating a zero knowledge proof based on path information from leaf nodes corresponding to the multiple transactions in the first Mercker state tree to a root node of the first Mercker state tree according to the zero knowledge proof corresponding to the multiple transactions in the first Mercker state tree until the first aggregate zero knowledge proof is generated;

and iteratively generating a zero knowledge proof based on path information from the leaf nodes corresponding to the plurality of transactions in the second Mercker state tree to the root node of the second Mercker state tree until the second aggregate zero knowledge proof is generated according to the zero knowledge proof corresponding to the plurality of transactions in the second Mercker state tree.

Optionally, the processing module is further configured to:

generating a first state commitment corresponding to the plurality of transactions in the first Mercker state tree according to leaf nodes corresponding to the plurality of transactions in the first Mercker state tree, wherein the first state commitment is used for proving that: zero knowledge proof of each transaction in the plurality of transactions corresponding to the first Mercker state tree is bound with a leaf node of the transaction corresponding to the first Mercker state tree;

Optionally, the processing module is specifically configured to:

In a fourth aspect, the present invention provides an apparatus for managing status data of a DAPP applied to a blockchain, where the apparatus is a blockchain node, and the apparatus includes:

the acquisition module is used for acquiring the aggregation transaction, the aggregation zero-knowledge proof and the root node of the second Mercker state tree; the aggregated transaction is obtained according to a plurality of transactions, the aggregated zero knowledge proof is obtained according to zero knowledge proofs of the plurality of 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 plurality of transactions; the second Mercker state tree is obtained by updating the first Mercker state tree of the block chain after the plurality of transactions are successfully executed on the block chain;

and the storage module is used for executing the aggregation transaction, verifying the aggregation zero-knowledge proof by calling the intelligent contract of the block chain, and storing the root node after the verification is successful.

The advantageous effects of the optional apparatuses in the second aspect and the fourth aspect may refer to the advantageous effects of the optional methods in the first aspect and the first aspect, and are not described herein again.

In a fifth aspect, the present invention provides a computer apparatus comprising a program or instructions which, when executed, is operable to carry out the first, second and various alternative methods described above.

In a sixth aspect, the present invention provides a storage medium comprising a program or instructions which, when executed, is operable to carry out the first, second and various alternative methods described above.

These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.

Fig. 1 is a flowchart illustrating a corresponding method for managing status data of a DAPP applied to a block chain according to an embodiment of the present invention;

FIG. 2 is a diagram illustrating a change of a Mercker status tree in a method for managing status data of DAPP applied to a block chain according to an embodiment of the present invention;

fig. 3 is a schematic structural diagram of a management apparatus for status data of a DAPP applied to a block chain according to an embodiment of the present invention;

fig. 4 is a schematic structural diagram of a management apparatus for status data of DAPP applied to a block chain according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be described in further detail with reference to the accompanying drawings, and it is apparent that the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

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

Zero knowledge proof and recursive proof: a zero knowledge proof algorithm may be used to proof and verify such a statement: given a result verification algorithm F and a public input x corresponding to a public function, knowing a secret input w, F (x, w) can satisfy F (x, w) true. Zero knowledge proof generally contains three sub-algorithms:

setup: taking the function F and the safety parameter lambda as input and outputting oneA set of invariant parameters crs and a back door td, where crs comprises two parts, the part used for the certification being called the certification key crs_pThe part used for authentication is called the authentication key crs_v；

River: the prover will prove the secret key crs_pPublic input x and secret input w of the function F are used as input, and proof pi is output;

ZK. Verifier: the verifier will verify the secret key crs_vCommon input x and proof of function F as inputs, and output 0 or 1 indicates rejection or acceptance. Anyone can perform this algorithm.

The zero knowledge proof algorithm satisfies four characteristics:

integrity: if the truthful prover is based on the proving key crs_pPublic input x and secret input w of function F make proof pi, then the result of verifier performing zk.

The concealment of knowledge: for one proof pi and a public input x, anyone cannot deduce the prover's secret input w from both.

Zero knowledge: for any two proofs pi and pi', any adversary cannot tell which of the two secret inputs the two proofs were computed from, respectively. Alternatively, the computed zero knowledge proof is different as long as the secret input is different.

The simplicity is as follows: it is demonstrated that the magnitude of pi should be sub-linear with the magnitude of the public input x and the secret input w.

For an algorithm or program that satisfies NP, such as the mercker certification algorithm, the way to construct the zero-knowledge proof for this algorithm is usually to represent the mercker certification verification algorithm by a special arithmetic gate circuit, which is also a program in nature, but to add the dependency of each variable in the verification algorithm, including the input and output dependencies, in this arithmetic gate circuit, then convert all dependencies into a set of polynomial expressions, then make a polynomial commitment to this set of polynomials, and finally verify the commitment by the verifier. At present, various algorithm tool chains for zero knowledge proof are mature, and only the algorithm or program to be proved is represented by an arithmetic gate circuit, and the subsequent steps can generate the zero knowledge proof by the related tool algorithm according to the arithmetic gate circuit and the input.

The recursive zero knowledge proof is a recursive aggregation of the zero knowledge proof itself, and since the verification calculation of the zero knowledge proof is also a program satisfying NP, a further proof can be made to the calculation building circuit, and a plurality of zero knowledge proofs are used as common input (the zero knowledge proofs are made to the verification calculation of the plurality of proofs instead of the aggregation of the proofs themselves), so as to obtain a recursive zero knowledge proof. And recursion is carried out on the zero knowledge proofs of two same circuits, a root zero knowledge proof is obtained after layer-by-layer recursion, and the meaning and the execution process of the symbol are given in detail in the scheme description later.

Ethernet virtual machine (EVM for short): the EVM is used to compile intelligent contract code into machine code that can be executed on the ethernet workshop and provide the running environment of the intelligent contract. The method is a sandbox environment which is completely isolated from the outside, and the network and the files cannot be accessed during operation, even if limited access rights exist among different contracts. In order to keep high certainty of the running result of the intelligent contract, the running environment of the intelligent contract is important, and the Ethernet room node participants download the Ethernet room clients and run the Ethernet room clients on their own machines through the operating system of the Ethernet room virtual machine, so that the bottom layer difference of each computer node is better shielded, and the same result, namely certainty of executing the contract by different nodes is better realized.

Decentralized application (Dapp): dapp generally refers to an application running on a blockchain that implements relevant business logic using intelligent contracts, which possess the decentralized nature of blockchains to ensure that the application runs transparently. A Dapp such as decentralized finance (Defi) often needs to store data of all users, such as balance of the user, and basic states of the whole service, such as current pricing information, in an intelligent contract on a chain, all variables needing to occupy storage space belong to the state of the intelligent contract, and other codes in the intelligent contract, such as functions, are service logic. From the aspect of the intelligent contract operation mode, users respectively send transactions to call functions in the intelligent contracts on the chain, then block chain nodes check basic information such as signatures of each transaction, then the EVM is operated to load corresponding intelligent contract codes, the functions called by the users (the functions also comprise user state check such as balance check) are executed, and finally the state of the intelligent contracts is changed.

Polymerization (Rollup): rollup is a proposed downlink extension to the trading rate limit of the etherhouse, since many Dapp are running on the etherhouse, but users can only use Dapp in a way to send transactions. Rollup is the packing of a large number of transactions "together/summary" for a Dapp down a chain into one transaction. There are two main implementations of Rollup, respectively, optimal Rollup (Optimistic aggregation) and zk-Rollup (aggregation based on zero knowledge proof). In both cases, transactions are collected under the chain, then executed, and finally the new state after batch transaction is updated to the intelligent contracts on the chain, namely the intelligent contracts on the chain do not need to execute specific business logic. The former uses mainly fraud proofs, the latter based on zero knowledge proofs. The Optimic Rollup executes the Smart contracts off-chain using ovm (a virtual machine like EVM that supports more opcodes than EVM). Optisisticrolllup tends to default to all participants being good, believing that the node will not be bad, and if fraud occurs, the user constructs a fraud proof that is submitted to the chain intelligence contract, proving that the node is bad. zk-Rollup uses zero knowledge proof to prove that each transaction is performed correctly under the chain, which tends to default to all participants being likely to be bad without trusting any node.

During the operation of a financial institution (banking, insurance or security institution) in a business (e.g. loan, deposit, etc. of a bank), status data of a user is often maintained on a block chain by means of the mercker tree. In the prior art, after each transaction is executed, a zero knowledge proof needs to be generated to prove the validity of the transaction, and the zero knowledge proof needs to be verified, so that the calculation overhead is increased as the Mercker tree is larger. This situation does not meet the requirements of financial institutions such as banks, and the efficient operation of various services of the financial institutions cannot be ensured.

To this end, referring to fig. 1, an embodiment of the present invention provides a method for managing status data of a DAPP applied to a block chain.

Step 101: a plurality of transactions and a zero knowledge proof of the plurality of transactions are obtained.

Wherein zero knowledge proof of any transaction is used to prove the legitimacy of the transaction.

Step 102: sending the plurality of transactions to an Ethernet shop virtual machine (EVM) service; after determining that the plurality of transactions are successfully performed on the EVM service, updating a first Mercker state tree under a chain to a second Mercker state tree according to the plurality of transactions.

The first Mercker state tree is a Mercker state tree before the execution of the multiple transactions is successful, and the second Mercker state tree is a Mercker state tree after the execution of the multiple transactions is successful.

Step 103: processing the plurality of transactions into an aggregated transaction; and generating an aggregated zero knowledge proof according to the zero knowledge proofs of the plurality of transactions.

The attestation content of the aggregated zero knowledge attestation is equivalent to the total attestation content of the zero knowledge attestation of the plurality of transactions.

Step 104: the aggregate transaction, the aggregate zero knowledge proof, and the root node of the second Mercker state tree are sent to a blockchain.

Step 104 may cause the blockchain to perform the aggregated transaction and store the root node after the intelligent contract of the blockchain verifies that the aggregated zero knowledge proof passes.

It should be noted that, steps 101 to 104 may be implemented as follows:

the participants of steps 101-104 may include a user, an intelligent contract on the blockchain, and three services, a transaction processing service, an EVM service, and a zero knowledge proof service, respectively. These three services run off-chain, either on the same machine or on different machines. The intelligent contract and the three services may be deployed as follows:

compiling a complete intelligent contract A according to the service requirement, wherein the contract A comprises state management and service processing logics, namely various functions; extracting a service processing logic part of the intelligent contract A into another independent intelligent contract B, changing the direct use of a state variable in a function into a parameter to be transmitted, wherein only one root state variable is arranged in the intelligent contract B, and then deploying a chain on the intelligent contract B; abstracting all states into a Mercker state tree, namely, each minimum granularity variable is a leaf node of the Mercker tree (the step can be realized by any programming language), and integrating functions of analyzing, creating, monitoring and the like of the Etheng transaction into a transaction processing service; zero knowledge proof service can be established based on the zero knowledge proof framework provided by the invention, and comprises zero knowledge proof generation and verification of state and signature correctness and recursion of the zero knowledge proof; and (4) establishing an EVM service by using any EVM independent environment software, and only operating the intelligent contract B.

Specifically, the zero-knowledge proof framework may be a state management and business logic combination framework, and may be specifically divided into three stages: the verification of the old state (namely, the verification of the state data before the execution of a plurality of transactions, including the verification of the basic information of the transactions), the business logic execution and the verification of the new state (namely, the verification of the state data after the execution of a plurality of transactions, including the verification of the basic information of the transactions). The state data of each user on the blockchain can be stored, managed and proven to be correct under the chain. The old states and parameters required by the business logic can be bulk packaged by a transaction into a chain of blocks of intelligent contracts, and the new states generated are also managed down the chain. State management can be performed in many ways, and etherhouses use a pascal-merck tree, a classical merck tree (a complete binary tree, abbreviated as a merck tree), a wacker tree, and the like, each minimum-granularity variable is a leaf node of the tree (representing a value of a state variable of a user), and the intelligent contract on the chain only needs to store the root of the state tree to ensure that the whole application is executed in a consistent state.

The zero knowledge proof framework may be based on the UltraPlonk zero knowledge proof program syntax, providing two basic circuits: a state management circuit based on a Merck tree and a signature verification circuit based on an elliptic curve.

A state management circuit: the state management based on the Mercker tree comprises insertion and update of leaf nodes, the change of all the leaf nodes can cause the change of a root node, the insertion, update and operation can be realized by common codes, but zero knowledge proof is needed to ensure that a certain leaf node corresponds to the root node of the state tree at a certain time, namely, the Mercker proof of a path from the node to the root is verified, namely, the state of a verified user is correct and conforms to the whole account book. The private parameters required by the circuit are path information address _ bits of a node corresponding to the state data and a sibling node value path on the path, and the required public parameters are only the depth, the root and the leaf value leaf of the known tree.

A signature verification circuit: since the user's transactions are processed down the chain, a transaction processing service is required to verify the correctness of each transaction, where mainly the signature of the transaction is verified and the checking of the user's status, such as the balance, is controlled by the status management circuit. Thus, the provision of an elliptic curve based signature verification that satisfies most blockchains and Dapp requirements, and the elliptic curve itself is configurable and replaceable. The private parameters required by this circuit are the signed content in _ msg and the user' S public key in _ params, and the only public parameters required are the signature itself in _ S ═ in _ base, in _ a, in _ R, in _ S }.

The zero knowledge proof service is built on the basis of these two circuits. Each transaction is based on the two circuits described above to generate a zero knowledge proof that anyone can be confident that the transaction is legitimate by merely verifying the zero knowledge proof. In order to improve the verification efficiency of the zero knowledge proof of the intelligent contract, the scheme uses the recursive zero knowledge proof (supported by UltraPlunk), the zero knowledge proof generated by each transaction does not need to be verified and processed by the intelligent contract on the chain, and only the root zero knowledge proof obtained after recursion needs to be verified through the recursion processing of the zero knowledge proof. The specific algorithm may be as follows:

setup (λ, T) → pp: and initializing a zero-knowledge proof framework, wherein the initialization comprises initialization of a zero-knowledge proof algorithm and initialization of recursive proof, a global common parameter pp is output by taking a safety parameter lambda and a response delay parameter T as input, wherein pp is (crs, G, G and l), G represents an elliptic curve group, G is a generator, and l is the length of a random sequence.

Pro (pp, depth, address _ bits, path, root, leaf, in _ msg, in _ params, in _ S) → pi, in _ S being a signature, and transmitting required public parameters and private parameters by the zero knowledge proof service according to the state management circuit and the signature verification circuit to generate an aggregated zero knowledge proof pi.

Verify (pp, depth, root, leaf, in _ S, pi) → {0,1}, and anyone can verify the aggregate zero knowledge proof using this verification algorithm, with an output of 0 indicating verification failure and 1 indicating verification pass, and if the intelligent contract on the blockchain verifies the aggregate zero knowledge proof pass, the root node of the second mercker state tree will be stored on the blockchain.

The zero knowledge proof service recursively verifies the state transformation of two zero knowledge proofs, wherein the state mainly comprises the root of the Mercker state tree, the transaction times and the transaction process state. The transaction process state may be as follows: z1 represents the input of a verified transaction, i.e., the initiating user's state and signature, Z2 represents that a zero knowledge proof has been generated for the input of the transaction, Z3 represents that the execution and updating of the state tree for the completed transaction under the chain, Z4 represents that a zero knowledge proof has been generated for the output of the transaction, Z5 represents the depth at which the zero knowledge proof recursion was completed, and Z6 represents that the final recursion proof was completed, the transaction process state identifies the values of various system variables of the zero knowledge proof service in generating the zero knowledge proof or recursion proof of the transaction, and the role of the state transformation function is to link the entire recursion process together.

The zero knowledge proof service recursively proofs any two zero knowledge proofs, including verifying pi₁And pi₂To generate recursive proof

This algorithm mainly certifies zero knowledge as the following verification algorithm:

verify (pi, root, leaf, in _ base, in _ a, in _ R, in _ s, pi) → {0,1} into an arithmetic circuit, with any two zero knowledge proofs₁,π₂) Common input (x) required to verify the two proofs₁,x₂) { root, leaf, in _ base, in _ a, in _ R, in _ s } and the state at which these two proofs were generated (st)₁,st₂) For secret input w, in a recursive state

Is the common input x.

RZK.Verify(π_root,st_root) → 0,1 }: and the final verification function takes the root recursive proof and the corresponding state as input to verify the correctness of the root proof. The root certificate can represent the zero knowledge certificate made by the zero knowledge certificate service for each transaction, and the intelligent contract on the chain only needs to verify the root certificate, which is equivalent to verify the zero knowledge certificates of all transactions and is equivalent to verify all transactions, so that the transactions are aggregated.

Business logic and state management are separated. The invention is also a two-layer extension scheme, designs a framework of state management and service logic decoupling, and stores data related to Dapp users, namely all state data under the chain, so that operations such as state management, transaction signature verification and the like can be executed under the chain, the burden of state data storage and management of intelligent contracts on the chain is reduced, and even if the state data is continuously increased, the calculation consumption of the intelligent contracts on the chain is not influenced.

Due to the fact that state management and business logic are decoupled, developers of transaction aggregation application do not need to build a zero-knowledge proof circuit for business logic, the universal and efficient state maintenance and signature verification zero-knowledge proof circuit provided by the scheme is directly adopted, and zero-knowledge proofs are respectively made for the legality of new and old states. The business logic (related functions) is still implemented on the intelligent contracts, so the correctness of the state change can be checked and guaranteed by the intelligent contracts on the chain.

The following describes in detail a management method of status data of DAPP applied to a block chain according to the present application. It should be noted that, when the method is applied, a developer of Dapp may set transaction quantity aggregated at one time according to business requirements and a used zero knowledge proof algorithm, and since both circuits provided by the present invention use UltraPlonk zero knowledge proof and are suitable for direct aggregation of two zero knowledge proofs, the aggregation of two transactions of one decentralized account is taken as an example below (but the purpose of aggregating multiple transactions may also be achieved by multiple aggregations). The ledger application manages balance data of a user using a three-tier Mercker tree, stored in the transaction processing services under the chain, which are deployed on different machines. At some point, the balance of user A is K1_oldThe balance of the user B is K2_oldUser a wants to extract n1 tokens from the ledger, and user B wants to store n2 tokens into the ledger. For a transaction of a user interacting with the intelligent contract B, the transaction is not directly submitted to a blockchain, but is first submitted to processing under the chain, and the state tree changes before and after the two transactions are shown in fig. 2, and the specific flow is as follows:

step (1): the user A calls the intelligent contract through the client, and creates a transaction A for calling the intelligent contract, such as calling a balance deduction function to subtract n1 from the own balance; meanwhile, the user B creates a transaction B for calling the intelligent contract through the client, such as calling a balance increasing function to increase the balance of the user B by n 2; both users send to the transaction processing service of Dapp.

In the foregoing steps 101 to 104, for a first transaction (in this case, transaction a) and a second transaction (in this case, transaction B), the first transaction and the second transaction are any two transactions in the plurality of transactions, and the zero knowledge proof of the first transaction includes a first zero knowledge proof corresponding to the first mercker state tree and a third zero knowledge proof corresponding to the second mercker state tree; the zero knowledge proof of the second transaction comprises a second zero knowledge proof corresponding to the first Mercker state tree and a fourth zero knowledge proof corresponding to the second Mercker state tree; the first zero knowledge proof (P1) and the second zero knowledge proof (P2) are generated as follows:

generating a first Mercker proof of a corresponding first leaf node of the first transaction in the first Mercker state tree, wherein the first Mercker proof is used for proving position information of the first leaf node in the first Mercker state tree; generating a first zero knowledge proof of the first transaction from the first transaction, the first leaf node, the first Mercker proof, and a first root node of the first Mercker state tree; generating a second Mercker proof of a second leaf node corresponding to the second transaction in the first Mercker state tree, wherein the second Mercker proof is used for proving position information of the second leaf node in the first Mercker state tree; generating a second zero knowledge proof of the second transaction according to the second transaction, the second leaf node, the second Mercker proof, and a second root node of the first Mercker state tree.

Specifically, the method can be as follows in steps (2) to (3):

step (2): the transaction processing service analyzes the transaction, and the value C1 of the leaf node C1 of the Mercker state tree related to the transaction A_old(i.e. balance K1 of user A_oldHash value of) is fetched, and the merkel proof of C1 is made M1_old(depth of tree is 3, path address _ bits is (0, 0) and sibling node value on path is (L2)_oldC3)); the value C2 of the leaf node C2 of the Mercker state tree to which the transaction B relates_old(i.e. balance K2 of user B_oldHash value of) is fetched, and the merkel proof of C2 is made M2_old(depth of tree is 3, path address _ bits is (1, 0) and sibling node value path on path is (L1)_oldC4)); let the root of the state tree at this time be G_old。

And (3): the transaction processing service will C1_old、G_old、M1_oldSignature, content of transaction AAnd the public key of user a is sent to a zero knowledge proof service, which executes the zero knowledge proof algorithm zk_old,C1_oldIn _ msg, in _ params, in _ S) → P1, zero knowledge proof of knowledge P1; mixing C2_old、G_old、M2_oldThe signature, the content of transaction B and the public key of user B are sent to a zero knowledge proof service, which executes the zero knowledge proof algorithm zk_old,C2_oldIn _ msg, in _ params, in _ S) → P2, a zero knowledge proof is made P2.

And (4): the transaction processing service will K1_oldAnd n1 to the EVM service, which executes the balance deduction function of the intelligent contract B, returning the new balance K1 of the user A_new＝K1_old-n 1; the transaction processing service will K2_oldAnd n2 to the EVM service, which executes the balance increase function of the intelligent contract B, returning the new balance K2 of the user B_new＝K2_old+ n 2. That is, after the transaction is executed, the third zero knowledge proof (P3) and the fourth zero knowledge proof (P4) may be generated, specifically, according to the following manner:

generating a third Mercker proof of a third leaf sub-node corresponding to the first transaction in the second Mercker state tree, wherein the third Mercker proof is used for proving position information of the third leaf sub-node in the second Mercker state tree; generating the third zero knowledge proof according to the first transaction, the third leaf child node, the third Mercker proof, and a second root node of the second Mercker state tree; generating a fourth Mercker proof of a fourth leaf node corresponding to the second transaction in the second Mercker state tree, wherein the fourth Mercker proof is used for proving position information of the fourth leaf node in the second Mercker state tree; generating the fourth zero knowledge proof according to the second transaction, the fourth leaf node, the fourth Mercker proof, and a second root node of the second Mercker state tree.

In this case, the steps (5) to (6) may be specifically as follows:

and (5): transaction processing service based on recencyCalculate new value of leaf node C1C 1_newAnd updating the first Mercker state tree, assuming that the root of the Mercker state tree is G_inter(ii) a The transaction processing service calculates a new value C2 for the leaf node C2 based on the new balance_newAnd updating the Merck state tree to a second Merck state tree, assuming that the root of the state tree at this time is G_new(ii) a Finally, the Mercker's proof M1 is made for C1 and C2, respectively, based on the latest state tree_new(depth of tree is 3, path address _ bits is (0, 0) and sibling node value on path is (L2)_newC3)) and M2_new(depth of tree is 3, path address _ bits is (0, 0) and sibling node value on path is (L2)_new，C3))。

And (6): the transaction processing service will C1_new、G_new、M1_newThe signature, content and public key of the transaction are sent to a zero knowledge proof service, which executes the zero knowledge proof algorithm zk_new,C1_newIn _ msg, in _ params, in _ S) → P3, zero knowledge proof of knowledge P3; the transaction processing service will C2_new、G_new、M2_newThe signature, content and public key of the transaction are sent to a zero knowledge proof service, which executes the zero knowledge proof algorithm zk_new,C2_newIn _ msg, in _ params, in _ S) → P4, a zero knowledge proof is made P4.

So far, in this example, a plurality of transactions (a, B) corresponding to step 101 and a zero knowledge proof of the plurality of transactions (P1, P2, P3, P4) have been generated.

The following is the step of generating the aggregated zero knowledge proof, which zero knowledge proof service executes the recursive proof algorithm rzk. Positive (P1, P2, P3, P4, M1)_old,M2_old,M1_new,M2_new) → pi aggregates proofs P1, P2, P3, and P4 into one proof pi, which is sent to the transaction processing service. The aggregation with zero knowledge proof (step 103) is specifically performed as follows:

generating a first aggregation zero knowledge proof according to the zero knowledge proofs of the plurality of transactions corresponding to the first Mercker state tree; generating a second aggregate zero knowledge proof according to the zero knowledge proofs of the plurality of transactions corresponding to the second Mercker state tree; generating the aggregated zero knowledge proof from the first aggregated zero knowledge proof and the second aggregated zero knowledge proof. Specifically, the following may be mentioned:

step (7-1): aggregating proofs P1 and P2, resulting in a first aggregated zero knowledge proof, extracts from the cache the common parameters needed to verify P1 and P2: depth, C1_old、C2_old、G_oldAnd signatures for two transactions in _ S. Specifically, the above-mentioned first aggregated zero knowledge proof can be obtained as follows:

and iteratively generating a zero knowledge proof based on path information from a leaf node corresponding to the first Mercker state tree to a root node of the first Mercker state tree of a user corresponding to the transactions according to the zero knowledge proof corresponding to the transactions in the first Mercker state tree until the first aggregate zero knowledge proof is generated.

In steps 101 to 104, a commitment for verification may be generated, specifically:

generating second state commitments corresponding to the plurality of transactions in the second Mercker state tree according to leaf nodes corresponding to the users corresponding to the plurality of transactions in the second Mercker state tree, wherein the second state commitments are used for proving that: zero knowledge proof of each transaction in the plurality of transactions corresponding to the second Mercker state tree is bound to a leaf node of the transaction corresponding to the second Mercker state tree.

In one possible implementation, the first status commitment may be generated as follows:

generating the first state commitment (G1) according to the leaf nodes corresponding to the multiple transactions in the first merkel state tree, the transaction execution states of the multiple transactions, the transaction sequence numbers of the multiple transactions, and the first root node of the first merkel state tree, which may be specifically as in steps (7-2) to (7-3):

step (7-2): executing state transition functions

Confirming System State st when proofs P1 and P2 are generated₁,st₂: transaction execution state Z1, transaction sequence number T1, T2, and root G of the state tree_old. Updating transformed system state

Transaction execution status

And a commitment Com1 bound to a contextual status.

Step (7-3): constructing a zero-knowledge proof verification circuit, establishing a constraint relation for two proofs P1 and P2, public verification parameters and front and back system states which need to recur, converting the constraint relation into a polynomial commitment G1, and obtaining a recursion proof pi of a first stage₁. The overall algorithm is described as:

step (7-4): and aggregating the proofs P3 and P4 to obtain a second aggregated zero-knowledge proof, and extracting common parameters required for verifying P3 and P4 from the cache: depth, C1_new、C2_newAnd G_new。

In particular, the second polymerization zero knowledge proof of knowledge may be obtained in particular in the following manner:

In one possible implementation, the second status commitment may be generated as follows:

and generating the second state commitment according to leaf nodes corresponding to the plurality of transactions in the second Mercker state tree, transaction execution states of the plurality of transactions, transaction sequence numbers of the plurality of transactions and a second root node of the second Mercker state tree. The specific steps can be as follows from step (7-5) to step (7-6):

step (7-5): executing state transition functions

Confirming System State st when proofs P3 and P4 are generated₃,st₄: transaction execution state Z4, transaction sequence number T1, T2, and root G of the state tree_new. Updating transformed system state

Transaction execution status

And a commitment Com2 bound to a contextual status.

Step (7-6): constructing a zero-knowledge proof verification circuit, establishing a constraint relation for two proofs P3 and P4, public verification parameters and front and back system states which need to recur, converting the constraint relation into a polynomial commitment G2, and obtaining a recursion proof pi of a first stage₂. The overall algorithm is described as:

step (7-7): pair pi₁And pi₂Polymerization, extracting from the calculation process of the previous two polymerizations to verify pi₁And pi₂Common parameters of (2): polynomial commitment G1 and its challenge point sequence

Sum polynomial commitment G2 and its challenge point sequence

Step (7-8): executing state transition functions

Confirmation of proof of Generation pi₁And pi₂System state of time

Transaction execution status

And

root G of state tree_oldAnd G_new. Updating transformed system state

Transaction execution status

And a commitment Com3 bound to a contextual status.

Step (7-9): constructing zero-knowledge proof verification circuit for two proofs of required recursion₁And pi₂The public verification parameters and the system states before and after establish a constraint relation, then the constraint relation is converted into a polynomial commitment G3, then another commitment G3 'is constructed, a vector inner product proving algorithm is used for proving that G3' and G3 have the same structure, and a final recursive proof pi is obtained. The overall algorithm is described as:

and (8): the transaction processing service will K1_old、n1、K2_old、n2、G_old、G_new、

And pi are assembled into a transaction and sent to the intelligent contracts B on the chain.

Correspondingly, the block chain node also has a management method for running state data of the DAPP applied to the block chain, which may specifically be as follows:

acquiring aggregation transactions, aggregation zero knowledge proofs and root nodes of a second Mercker state tree by using block link points; and the block chain link point executes the aggregation transaction, verifies the aggregation zero knowledge proof by calling an intelligent contract of the block chain, and stores the root node after the verification is successful.

And (9): the intelligent contract B calls a balance deduction function and a balance increase function to obtain K1_newAnd K2_newThen, a verification function of recursive proof is performed:

RZK.Verify(π,Com3,S3,G_old,G_new,M1_old,M1_new) → 0,1 verifies that the aggregation of the two transactions is correct, as follows:

step (9-1): checking the user's new balance K1_newAnd K2_newWhether out of range.

Step (9-2): by performing

The status transition process of the system is checked for correctness, while it can be checked whether the aggregated transactions have been processed under the chain.

Step (9-3): checking whether the state tree under the chain is updated correctly, i.e. verifying separately before and after the first transaction, the merkel proof M1 of the state of the user A he initiated_oldAnd M1_new。

Step (9-4): verify the final recursive proof pi by performing zk.verify (pp, pi, G3 ', G3, S3) → {0,1}, i.e. verify whether both polynomial commitments G3' and G3 have the same value in the challenge sequence S3.

Step (10): if either authentication fails, the transaction processing service will roll back the transaction, i.e., roll back the state before the two transactions are executed; and if the verification is passed, saving the current state.

The invention provides a management method of DAPP state data applied to a block chain, which can separate service logic and state management, can quickly turn to zk-Rollup for a plurality of complex decentralized applications (Dapp) with high-frequency transactions, does not need developers to have high-depth cryptography, particularly zero knowledge proving technology and knowledge, only needs to compile intelligent contracts and expand capacity according to the prior Dapp development mode, can obtain a large block chain gain at present, does not damage the decentralized characteristic, ensures the correct execution of each transaction interacted with the intelligent contracts, and can protect the privacy of transaction users.

As shown in fig. 3, the present invention provides a management apparatus for status data of DAPP applied to a block chain, including:

an obtaining module 301, configured to obtain multiple transactions and zero knowledge proofs of the multiple transactions, where the zero knowledge proof of any transaction is used to prove validity of the transaction;

a processing module 302 to send the plurality of transactions to an etherhouse virtual machine, EVM, service; after determining that the plurality of transactions are successfully executed on the EVM service, updating a first Mercker state tree under a chain into a second Mercker state tree according to the plurality of transactions, wherein the first Mercker state tree is the Mercker state tree before the plurality of transactions are successfully executed, and the second Mercker state tree is the Mercker state tree after the plurality of transactions are successfully executed; and

a sending module 303, configured to send the aggregate transaction, the aggregate zero knowledge proof, and the root node of the second merkel state tree to a blockchain, so that the blockchain executes the aggregate transaction, and after the intelligent contract of the blockchain verifies that the aggregate zero knowledge proof passes, store the root node.

Optionally, the processing module 302 is specifically configured to:

Optionally, the processing module 302 is further configured to:

Optionally, the processing module 302 is specifically configured to:

As shown in fig. 4, the present invention provides a management apparatus for status data of DAPP applied to a blockchain, where the apparatus is a blockchain node, and the management apparatus includes:

an obtaining module 401, configured to obtain an aggregate transaction, an aggregate zero knowledge proof, and a root node of a second merkel state tree; the aggregated transaction is obtained according to a plurality of transactions, the aggregated zero knowledge proof is obtained according to zero knowledge proofs of the plurality of 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 plurality of transactions; the second Mercker state tree is obtained by updating the first Mercker state tree of the block chain after the plurality of transactions are successfully executed on the block chain;

a storage module 402, configured to execute the aggregated transaction, verify the aggregated zero knowledge proof by invoking an intelligent contract of the block chain, and store the root node after the verification is successful.

Based on the same inventive concept, embodiments of the present invention also provide a computer device, including a program or instructions, which when executed, performs the management method applied to the state data of the DAPP of the blockchain and any optional method.

Based on the same inventive concept, embodiments of the present invention also provide a computer-readable storage medium, which includes a program or instructions, and when the program or instructions are executed, the management method applied to the status data of the DAPP of the block chain and any optional method provided by embodiments of the present invention are executed.

It should be apparent to those skilled in the art that embodiments of the present invention may be provided as a method, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the invention.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims

1. A method for managing status data of a DAPP applied to a block chain, comprising:

2. The method of claim 1, wherein generating an aggregate zero knowledge proof from the zero knowledge proofs for the plurality of transactions comprises:

3. The method of claim 2, wherein generating a first aggregated zero knowledge proof based on zero knowledge proofs corresponding to the plurality of transactions in the first Mercker state tree comprises:

and iteratively generating a zero knowledge proof based on path information from a leaf node corresponding to the second Mercker state tree to a root node of the second Mercker state tree of a user corresponding to the transactions according to the zero knowledge proof corresponding to the transactions in the second Mercker state tree until the second aggregate zero knowledge proof is generated.

4. The method of claim 2, further comprising:

5. The method of claim 4, wherein said generating a first state commitment for the plurality of transactions at the first Mercker state tree from leaf nodes for the plurality of transactions at the first Mercker state tree comprises:

6. The method of 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 of the plurality of transactions, the zero knowledge proof for the first transaction comprises a first zero knowledge proof corresponding to the first Mercker state tree, and the zero knowledge proof for the second transaction comprises a second zero knowledge proof corresponding to the first Mercker state tree;

7. The method of 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 of the plurality of transactions, the zero knowledge proof for the first transaction comprises a third zero knowledge proof corresponding to the second Mercker state tree, and the zero knowledge proof for the second transaction comprises a fourth zero knowledge proof corresponding to the second Mercker state tree;

8. A method for managing status data of a DAPP applied to a block chain, comprising:

acquiring aggregation transactions, aggregation zero knowledge proofs and root nodes of a second Mercker state tree by using block link points; the aggregated transaction is obtained according to a plurality of transactions, the aggregated zero knowledge proof is obtained according to zero knowledge proofs of the plurality of 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 plurality of transactions; the second Mercker state tree is obtained by updating the first Mercker state tree of the block chain after the plurality of transactions are successfully executed on the block chain;

and the block chain link point executes the aggregation transaction, verifies the aggregation zero knowledge proof by calling an intelligent contract of the block chain, and stores the root node after the verification is successful.

9. An apparatus for managing status data of a DAPP applied to a block chain, comprising:

10. A computer device comprising a program or instructions which, when executed by a processor, performs the method of any one of claims 1 to 7 and 8.