A parallel optimization method, device and storage medium for block zero-knowledge proof

Abstract

The present invention belongs to the field of computer technology, and in particular relates to a parallel optimization method, device and storage medium for block zero-knowledge proof. The parallel optimization method for block zero-knowledge proof provided by the present invention proposes generating corresponding Merkle account trees for different heights, and then combining state information with the Merkle account tree to quickly generate input information in authentication information calculation, thereby parallelizing the calculation of authentication information and effectively improving the calculation efficiency of witness information. At the same time, witness information calculation is performed off-chain and does not occupy blockchain Tps. After witness information is generated, the amount of calculation required for uploading to the chain and calculating zero-knowledge proof is small, effectively improving the processing throughput of the blockchain.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, and in particular relates to a parallel optimization method, device, and storage medium for block zero-knowledge proof. Background Art

[0002] A second-layer blockchain solution based on zero-knowledge proofs (ZKPs) can achieve performance improvements of more than 10 times compared to first-layer blockchains, while maintaining the same security. However, the overall performance of current solutions is less than ideal. This is because, in second-layer blockchain solutions based on ZKPs, while executing transactions, relevant proof materials must be calculated to form the ZKP proof input information. If this is placed during the transaction execution process, it will extend the execution processing time of each transaction, thereby affecting the processing time of the entire block. As a result, the high transaction throughput (TPS) of the second-layer blockchain system cannot be guaranteed.

[0003] Although the applicant has a related patent that separates the calculation of authentication information from the blockchain process to improve processing throughput, the calculation of the subsequent zero-knowledge proof and the calculation of the authentication information as preparatory materials is much slower than the growth rate of the blocks. If the calculation of the authentication information cannot be parallelized and accelerated, this will further affect the parallel calculation of the final zero-knowledge proof. Summary of the Invention

[0004] In order to solve the above problems, the present invention provides a block zero-knowledge proof parallel optimization method, device and storage medium, which can realize the parallelization of authentication information calculation and significantly improve computing efficiency.

[0005] The present invention adopts the following technical solutions:

[0006] In a first aspect, the present invention provides a parallel optimization method for block zero-knowledge proof, which is applicable to a two-layer blockchain network, wherein the two-layer blockchain network includes a first-layer blockchain network and a second-layer blockchain network, wherein the first-layer blockchain network and the second-layer blockchain network independently package and execute blocks, and the two-layer blockchain network is deployed with multiple witness information generators, wherein the witness information generators are used to generate witness information required for zero-knowledge proof by off-chain calculation. The method includes:

[0007] The block producer nodes of the second-layer blockchain network package transactions from the second-layer blockchain network to generate blocks and execute transactions within the blocks;

[0008] When executing a block, the second-layer blockchain network retains the state update information of the block;

[0009] Multiple witness information generators generate witness information corresponding to multiple blocks in parallel;

[0010] The generated witness information is written into the database in sequence;

[0011] Specifically, multiple witness information generators concurrently generate witness information corresponding to multiple blocks, including:

[0012] Each witness information generator loads the completed block information and obtains the block and status information for which it needs to calculate the witness information;

[0013] Each witness generator performs the following steps:

[0014] Determine whether the obtained block is the first block of the second-layer blockchain network. If so, create a new Merkle account tree for the second-layer blockchain network; otherwise, load the latest Merkle account tree of the second-layer blockchain network in the database, reversely obtain the previous block and its status update information, and update the loaded Merkle account tree according to the obtained previous block and corresponding status update information; the previous block is all blocks with a block height between the block corresponding to the loaded Merkle account tree and the block for which the witness information generator needs to calculate witness information. The Merkle account tree is a two-layer Merkle tree architecture, wherein the first layer is the user tree layer and the second layer is the asset tree layer. The leaf nodes of the user tree correspond one-to-one to each account of the second-layer blockchain network. The leaf nodes of the user tree are all configured with corresponding asset trees. The leaf nodes of the asset tree correspond to various types of asset information of the corresponding account. The root hash of the user tree is generated according to the root hash of each account of the second-layer blockchain network, and the root hash of each account of the second-layer blockchain network is calculated and generated according to the root hash of the corresponding asset tree.

[0015] Calculate the corresponding witness information based on the newly created or updated Merkle account tree.

[0016] Preferably, updating the loaded Merkle account tree according to the obtained preceding block and the corresponding status update information specifically includes: decoding the loaded Merkle account tree according to the obtained preceding block and updating the user tree sub-nodes and the asset tree sub-nodes, and simultaneously updating the user tree sub-nodes indexed by the address to complete the update of the loaded Merkle account tree.

[0017] Preferably, each witness information generator is provided with a step interval based on the block height.

[0018] Preferably, the database is preset with an automatic deletion mechanism, which specifically includes setting a deletion height interval for the Merkel account tree in the database, and automatically deleting the Merkel account tree every time the block height corresponding to the Merkel account tree reaches the deletion height interval, deleting the Merkel account tree corresponding to the block before the latest confirmed block height.

[0019] In a second aspect, a computer device is provided, comprising one or more processors;

[0020] a memory for storing one or more programs,

[0021] When the one or more programs are executed by the one or more processors, the one or more processors are caused to perform the method as described in the first aspect above.

[0022] In a third aspect, a storage medium storing a computer program is provided, which, when executed by a processor, implements the method described in the first aspect above.

[0023] The beneficial effect of the present invention lies in the parallel optimization method for block zero-knowledge proof provided by the present invention, which proposes to generate corresponding Merkle account trees for different heights, and then quickly generate input information in the authentication information calculation by combining state information with the Merkle account tree, so that the calculation of the authentication information can be parallelized, effectively improving the calculation efficiency of the witness information. At the same time, the witness information is calculated off-chain and will not occupy the blockchain Tps. After the witness information is generated, the amount of calculation required to upload it to the chain and calculate the zero-knowledge proof is small, which effectively improves the processing throughput of the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 This is a flowchart of a parallel optimization method for block zero-knowledge proof provided by one embodiment of the present invention.

[0025] Figure 2 A schematic diagram of the structure of a computer device provided in one embodiment of the present invention. DETAILED DESCRIPTION

[0026] The present invention will be further described in detail below in conjunction with specific embodiments and the accompanying drawings. Those of ordinary skill in the art will be able to implement the present invention based on these descriptions. In addition, the embodiments of the present invention involved in the following description are generally only embodiments of a part of the present invention, rather than all embodiments. Therefore, based on the embodiments in the present invention, all other embodiments obtained by those of ordinary skill in the art without making creative work should fall within the scope of protection of the present invention. It should be noted that, unless there is a conflict, the embodiments in this application and the features in the embodiments can be combined with each other. Unless otherwise specified, the methods briefly described in the embodiments of the present invention are methods mastered by those skilled in the art.

[0027] As an embodiment of the present invention, Figure 1As shown, a parallel optimization method for block zero-knowledge proof is provided. The method is applicable to a two-layer blockchain network, wherein the two-layer blockchain network includes a first-layer blockchain network and a second-layer blockchain network. The first-layer blockchain network and the second-layer blockchain network independently package and execute blocks. The two-layer blockchain network is deployed with multiple witness information generators, which are used to generate witness information required for zero-knowledge proof by off-chain calculation. The method includes:

[0028] The block producer nodes of the second-layer blockchain network package transactions from the second-layer blockchain network to generate blocks and execute transactions within the blocks;

[0029] When executing a block, the second-layer blockchain network retains the state update information of the block;

[0030] Multiple witness information generators generate witness information corresponding to multiple blocks in parallel;

[0031] The generated witness information is written into the database in sequence;

[0032] Specifically, multiple witness information generators concurrently generate witness information corresponding to multiple blocks, including:

[0033] Each witness information generator loads the completed block information and obtains the block and status information for which it needs to calculate the witness information;

[0034] Each witness generator performs the following steps:

[0035] Determine whether the obtained block is the first block of the second-layer blockchain network. If so, create a new Merkle account tree for the second-layer blockchain network; otherwise, load the latest Merkle account tree of the second-layer blockchain network in the database, reversely obtain the previous block and its status update information, and update the loaded Merkle account tree according to the obtained previous block and corresponding status update information; the previous block is all blocks with a block height between the block corresponding to the loaded Merkle account tree and the block for which the witness information generator needs to calculate witness information. The Merkle account tree is a two-layer Merkle tree architecture, wherein the first layer is the user tree layer and the second layer is the asset tree layer. The leaf nodes of the user tree correspond one-to-one to each account of the second-layer blockchain network. The leaf nodes of the user tree are all configured with corresponding asset trees. The leaf nodes of the asset tree correspond to various types of asset information of the corresponding account. The root hash of the user tree is generated according to the root hash of each account of the second-layer blockchain network, and the root hash of each account of the second-layer blockchain network is calculated and generated according to the root hash of the corresponding asset tree.

[0036] Calculate the corresponding witness information based on the newly created or updated Merkle account tree.

[0037] Furthermore, updating the loaded Merkle account tree according to the obtained preceding block and the corresponding status update information specifically includes: decoding the loaded Merkle account tree according to the obtained preceding block and updating the user tree sub-nodes and the asset tree sub-nodes, and simultaneously updating the user tree sub-nodes indexed by the address, thereby completing the update of the loaded Merkle account tree.

[0038] Furthermore, each witness information generator is provided with a step interval based on the block height.

[0039] Furthermore, the database is preset with an automatic deletion mechanism, which specifically includes setting a deletion height interval for the Merkel account tree in the database. Every time the block height corresponding to the Merkel account tree reaches the deletion height interval, it is automatically deleted, and the Merkel account tree corresponding to the block before the latest confirmed block height is deleted.

[0040] Previously, block and transaction execution had to be sequential. However, since block execution is now significantly faster than authentication information generation, we can retain the update information for each block, providing input for authentication information generation for different blocks without affecting block execution, maintaining the high performance and throughput of the second-layer blockchain.

[0041] The specific instructions are as follows:

[0042] If five witness generators need to be started simultaneously, and if witness generator_0 generates evidence for block_0, a Merkle account tree needs to be generated for the block and saved to the database for caching, recorded as accountTree_cache_0. Then, the witness information for block_0 is calculated, recorded as witness information zero. The zero-knowledge proof for block_0 can be calculated using witness information zero.

[0043] Assume that witness information generator_1 generates witness information for block_1. At this time, witness information generator_1 will load accountTree_cache_0, update accountTree_cache_0 according to the status update information of block_1, and directly generate accountTree_cache_1. In this way, the authentication information of block_1 can be calculated quickly. This is because the calculation of authentication information is time-consuming. After the block is packaged and executed, it takes a certain amount of time to calculate the corresponding witness information, and then calculate the zero-knowledge proof based on the witness information. The zero-knowledge proof is used to verify the block during consensus. At this time, if you wait for the block to pass the consensus before generating subsequent blocks, the efficiency of obtaining blocks will be greatly reduced. Therefore, This application adopts a parallel execution method to calculate witness information, which can greatly improve the efficiency of block generation. Because the blockchain has a rollback mechanism, the main reason for the decline in block generation efficiency is the large amount of time spent calculating authentication information. Therefore, when calculating authentication information, there is no need for the block to pass consensus. It is only necessary to obtain the Merkle account tree of the previous block and the previous block and its status update information. It is possible to achieve that multiple witness information generators can calculate the witness information of multiple blocks in parallel at the same time. Assuming that the current block _0 has been consensus-updated and put on the chain, block _1, block _2, and block _3 have been packaged and executed. The corresponding witness information is calculated by witness information generator _1, witness information generator _2, and witness information generator _3 respectively, with witness information generator _3 as For example, first obtain the Merkle account tree of the confirmed block_0 from the database in the second-layer blockchain network, that is, accountTree_cache_0, and then reversely obtain the previous blocks and their status update information, that is, block_1, block_2 and their corresponding status update information. According to the status update information of block_1, accountTree_cache_0 is updated to generate accountTree_cache_1. Then, according to the status update information of block_2, accountTree_cache_1 is updated to generate accountTree_cache_2. With accountTree_cache_2, witness information generator_3 can According to the obtained status update information of block_3, accountTree_cache_2 is updated to obtain the updated accountTree_cache_3, and the witness information of block_3 is calculated based on this. This process does not involve the witness information calculation of block_1 and block_2. It only updates the Merkle account tree based on the status update information. The calculation time is short, and the witness information generator_3 does not need to wait for the zero-knowledge proof calculation of block_1 and block_2. The parallel calculation of the witness information of block_1, block_2, and block_3 is realized, which effectively improves the calculation efficiency of the witness information. At the same time, the witness information calculation is calculated off-chain and does not occupy the blockchain Tps. After the witness information is generated, the computation required for uploading to the chain and calculating the zero-knowledge proof is small.Effectively improve the processing throughput of blockchain.

[0044] Generally, different witness information generators can set a certain step size based on the calculation time of the authentication information. For example, each witness information generator generates authentication information of different heights every 2 blocks. Then, witness information generator_0 calculates the witness information of block_0 and block_1, witness information generator_1 calculates the witness information of block_2 and block_3, and so on.

[0045] If the Merkle account tree of each block is always cached in the database, it will occupy a lot of blockchain storage space. Therefore, it is necessary to set up an automatic deletion mechanism and set a deletion height interval for the Merkle account tree in the database. The Merkle account tree will be automatically deleted every time the block height corresponding to the Merkle account tree reaches the deletion height interval, and the Merkle account tree corresponding to the block before the latest confirmed block height will be deleted. For example, if the deletion height interval is 10, in the witness information generator 5, accountTree_cache_10 has been generated and saved in the database, and block_10 has been confirmed, then the Merkle account tree with a height less than 10 will be deleted to save database storage space.

[0046] This application proposes to use the method of generating corresponding Merkle account trees for different heights, and then combining state information with the Merkle account tree to quickly generate input information in the authentication information calculation, so that the calculation of the authentication information can be parallelized, effectively improving the calculation efficiency of the witness information. At the same time, the witness information is calculated off-chain and will not occupy the blockchain Tps. After the witness information is generated, the amount of calculation required to upload it to the chain and calculate the zero-knowledge proof is small, which effectively improves the processing throughput of the blockchain.

[0047] Figure 2 A schematic structural diagram of a device provided in one embodiment of the present invention.

[0048] like Figure 2 As shown, as another aspect, the present application also provides a computer device 100, including one or more central processing units (CPUs) 101, which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 102 or programs loaded from a storage portion 108 into a random access memory (RAM) 103. Various programs and data required for the operation of the device 100 are also stored in the RAM 103. The CPU 101, ROM 102, and RAM 103 are connected to each other via a bus 104. An input / output (I / O) interface 105 is also connected to the bus 104.

[0049] The following components are connected to the I / O interface 105: an input section 106 including a keyboard, a mouse, and the like; an output section 107 including components such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 108 including components such as a hard disk; and a communication section 109 including a network interface card such as a LAN card or a modem. The communication section 109 performs communication processing via a network such as the Internet. A driver 110 is also connected to the I / O interface 105 as needed. A removable medium 111, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is mounted on the driver 110 as needed, so that a computer program read therefrom can be installed into the storage section 108 as needed.

[0050] In particular, according to the embodiments disclosed herein, the method described in Embodiment 1 above can be implemented as a computer software program. For example, the embodiments disclosed herein include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program comprising program code for executing the method described in any of the embodiments above. In such embodiments, the computer program can be downloaded and installed from a network via communication section 109 and / or installed from removable media 111.

[0051] As another aspect, the present application further provides a computer-readable storage medium, which may be the computer-readable storage medium included in the apparatus of the above-described embodiment, or a standalone computer-readable storage medium not incorporated into the apparatus. The computer-readable storage medium stores one or more programs, which are used by one or more processors to execute the method described in the present application.

[0052] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the prescribed logical functions. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the prescribed function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0053] The units or modules involved in the embodiments described in this application may be implemented in software or hardware. The units or modules described may also be provided in a processor. For example, each of the units may be a software program provided in a computer or mobile smart device, or a separately configured hardware device. The names of these units or modules do not, in certain circumstances, constitute limitations on the units or modules themselves.

[0054] The above description is merely a preferred embodiment of the present application and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to the technical solutions formed by the specific combination of the above-mentioned technical features, but also encompasses other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the concept of this application. For example, a technical solution formed by replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A parallel optimization method for block zero-knowledge proof, characterized in that: The method is applicable to a two-layer blockchain network, wherein the two-layer blockchain network includes a first-layer blockchain network and a second-layer blockchain network, wherein the first-layer blockchain network and the second-layer blockchain network independently package and execute blocks, and the two-layer blockchain network is deployed with multiple witness information generators, wherein the witness information generators are used to generate witness information required for zero-knowledge proof by off-chain calculation. The method includes: The block producer nodes of the second-layer blockchain network package transactions from the second-layer blockchain network to generate blocks and execute transactions within the blocks; When executing a block, the second-layer blockchain network retains the state update information of the block; Multiple witness information generators generate witness information corresponding to multiple blocks in parallel; The generated witness information is written into the database in sequence; Specifically, multiple witness information generators concurrently generate witness information corresponding to multiple blocks, including: Each witness information generator loads the completed block information and obtains the block and status information for which it needs to calculate the witness information; Each witness generator performs the following steps: Determine whether the obtained block is the first block of the second-layer blockchain network. If so, create a new Merkle account tree for the second-layer blockchain network; otherwise, load the latest Merkle account tree of the second-layer blockchain network in the database, reversely obtain the previous block and its status update information, and update the loaded Merkle account tree according to the obtained previous block and corresponding status update information; the previous block is all blocks with a block height between the block corresponding to the loaded Merkle account tree and the block for which the witness information generator needs to calculate witness information. The Merkle account tree is a two-layer Merkle tree architecture, wherein the first layer is the user tree layer and the second layer is the asset tree layer. The leaf nodes of the user tree correspond one-to-one to each account of the second-layer blockchain network. The leaf nodes of the user tree are all configured with corresponding asset trees. The leaf nodes of the asset tree correspond to various types of asset information of the corresponding account. The root hash of the user tree is generated according to the root hash of each account of the second-layer blockchain network, and the root hash of each account of the second-layer blockchain network is calculated and generated according to the root hash of the corresponding asset tree. Calculate the corresponding witness information based on the newly created or updated Merkle account tree.

2. A parallel optimization method for block zero-knowledge proof according to claim 1, characterized in that: Updating the loaded Merkle account tree according to the obtained previous block and the corresponding status update information specifically includes: decoding the loaded Merkle account tree according to the obtained previous block and updating the user tree sub-nodes and the asset tree sub-nodes, and at the same time updating the user tree sub-nodes indexed by the address to complete the update of the loaded Merkle account tree.

3. A parallel optimization method for block zero-knowledge proof according to claim 1, characterized in that: Each witness information generator is set with a step interval based on the block height.

4. A parallel optimization method for block zero-knowledge proof according to claim 1, characterized in that: The database is preset with an automatic deletion mechanism, which specifically includes setting a deletion height interval for the Merkle account tree in the database. Every time the block height corresponding to the Merkle account tree reaches the deletion height interval, the Merkle account tree corresponding to the block before the latest confirmed block height is deleted.

5. A computer device, characterized in that: one or more processors; a memory for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors are caused to perform the method according to any one of claims 1 to 4.

6. A storage medium storing a computer program, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 4 is implemented.

Images