Block or transaction existence proof method, device and storage medium

Abstract

A method, device and storage medium for proving the existence of a block or transaction of the present invention include a block proof service and a block verification service; wherein the block proof service is provided by a recording node in a blockchain, the recording node stores the determined blocks on the chain, reconstructs the storage in a proof tree manner, and provides a hierarchical accumulator for proving existence; the block proof service shown includes a block storage module, a proof tree generation module, and a verification data query module; the block verification service is provided by a verification node, which is responsible for obtaining verification data, generating an evidence chain and verifying the validity of the block or transaction; the block verification service includes a hierarchical accumulator proof module, an evidence chain generation module, and a verification module. The present invention can solve the problems of high computational overhead and high storage overhead in the traditional Merkle Tree or accumulator method for proving blocks or transactions, and while reducing storage overhead, the verification efficiency is higher.

Description

Technical Field

[0001] The present invention relates to the field of blockchain verification technology, and in particular to a method, device and storage medium for proving the existence of a block or transaction. Background Art

[0002] Proof of Block Existence is a concept usually associated with blockchain technology, which aims to ensure that the existence of a specific block in the blockchain is proven. Blockchain is a distributed database consisting of a series of blocks, each of which contains a batch of transaction records. The security and transparency of blockchain depends on ensuring the existence and integrity of blocks.

[0003] The goal of block existence proof is to prove that a specific block does exist in the blockchain and has not been tampered with. This helps prevent data from being tampered with or deleted, thereby maintaining the integrity of the blockchain. Currently, in blockchain systems, the following methods are commonly used to implement block existence proof:

[0004] (1) Merkle tree: A Merkle tree is a data structure used to organize transaction records so that they are easy to verify and ensure integrity. By verifying the root hash of the Merkle tree, it is possible to verify that the transaction records contained in a specific block exist and have not been tampered with. To verify the integrity of a data block, it is necessary to obtain the verification path of the data block in the Merkle tree. The verification path includes the hash values ​​of all the nodes passed from the leaf node to the root node. The hash values ​​in the verification path are verified layer by layer from the bottom according to the structure of the tree. Specifically, starting from the leaf node, the hash value of each node is merged with the hash value of the adjacent node, and then the merged hash value is calculated. This process is repeated until the root node is reached. Finally, the calculated hash value of the root node is compared with the hash value of the root node of the Merkle tree. If the last calculated root node hash value matches the root node hash value of the Merkle tree, then the integrity of the data block is verified, proving that the data block does belong to the Merkle tree. This existence proof method has high computational overhead, and if the data set needs to be dynamically updated, that is, adding or deleting data blocks to the data set, then the entire Merkle tree may need to be rebuilt. The previous intermediate nodes can no longer be used in subsequent verification, and such operations may result in high overhead.

[0005] (2) Accumulator. First, you need to obtain the membership proof related to the element to be verified. The membership proof is usually a set of information related to the nodes in the accumulator to prove that a specific element belongs to the member set of the accumulator. However, for the dynamically increasing data such as blocks, the accumulator needs to support dynamic updates, that is, adding elements to the accumulator, so the membership proof may need to be updated frequently. This may lead to performance overhead, especially when multiple copies need to be synchronized in a distributed system. For large-scale accumulators, the overhead required is even greater.

[0006] Merkle Mountain Range (MMR): A MerkleTree proposed by Peter Todd, which looks like a group of continuous peaks. It is designed so that nodes cannot be modified after being inserted, and supports dynamic insertion. The advantage of MMR over the binary Merkle tree is that when new data arrives (new data refers to leaf nodes), the value of the intermediate node does not need to be changed, and the data is always appended. That is, when new transaction data is added, the MMR structure adds it to the end of the evidence array and rebuilds the Merkle Tree based on the new evidence array. Due to the immutability of the MMR structure, adding new data will not affect existing nodes, and it also avoids the frequent calculation and combination of hash values ​​of child nodes in traditional methods, reducing the consumption of computing resources.

[0007] Accumulator: In cryptography, an accumulator generally refers to a data structure or algorithm that accumulates and verifies the membership of a set of values. Such accumulators are often used to support membership proofs in anonymous or distributed systems. A typical cryptographic accumulator allows users to add values ​​to the accumulator, while other users can verify that a specific value has been added to the accumulator. This property is useful in some scenarios, such as decentralized identity authentication systems, anonymous credential systems, etc. Summary of the invention

[0008] The present invention provides a method, device and storage medium for proving the existence of a block or transaction, which can solve at least one of the technical problems in the background technology.

[0009] To achieve the above object, the present invention adopts the following technical solutions:

[0010] A method for proving the existence of a block or transaction, including a block proof service and a block verification service;

[0011] Among them, the block proof service is provided by the recording node in the blockchain. The recording node stores the confirmed blocks on the chain, reconstructs the storage in the form of a proof tree, and provides a hierarchical accumulator for proving existence;

[0012] The block proof service shown includes a block storage module, a proof tree generation module, and a verification data query module;

[0013] The block verification service is provided by the verification node, which is responsible for obtaining verification data, generating evidence chains and verifying the validity of blocks or transactions;

[0014] The block verification service includes the hierarchical accumulator proof module, the evidence chain generation module, and the verification module.

[0015] On the other hand, the present invention further discloses a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the processor executes the steps of the above method.

[0016] On the other hand, the present invention further discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the above method.

[0017] It can be seen from the above technical solutions that the block or transaction existence proof method of the present invention can solve the problems of high computational overhead and high storage overhead in the traditional block or transaction proof based on Merkle Tree or accumulator method, and proposes a block or transaction existence proof mechanism based on accumulator compression MMR technology.

[0018] The beneficial effects of the present invention are as follows:

[0019] (1) There is no need to recalculate the merkle root. Block addition is an append method, which will not cause the existing hierarchical accumulator data to become invalid. By reusing it, the number of queries can be reduced.

[0020] (2) Combining MMR with accumulator technology, the MMR is further compressed to obtain a proof tree for providing verification proof data, which reduces storage overhead and improves verification efficiency.

[0021] (3) The level accumulators obtained from multiple recording nodes can prove the existence of each other. The level accumulators obtained in the past have been proven, and can also be proven with the newly obtained level accumulators, which ensures the validity of the verification data and further guarantees the credibility of the proof results.

[0022] (4) The verification node can detect malicious nodes based on whether the obtained layer accumulator is valid. In other words, it constrains the malicious behavior of providing false data and ensures the credibility of proof and verification.

[0023] (5) The traditional bottom-up computational proof is transformed into a top-down query proof, which improves the efficiency of block or transaction existence verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 It is the overall architecture diagram of the present invention;

[0025] Figure 2 A proof tree diagram of an embodiment of the present invention;

[0026] Figure 3 This is an auxiliary illustration of the proof chain generation module of an embodiment of the present invention. DETAILED DESCRIPTION

[0027] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all of the embodiments.

[0028] like Figure 1 As shown, the block or transaction existence proof method described in this embodiment mainly includes a block proof service and a block verification service. Among them, the block proof service is provided by the recording node in the blockchain. The recording node stores the confirmed blocks on the chain. The service mainly consists of a block storage module, a proof tree generation module, and a verification data query module; the block verification service is provided by a verification node. The service mainly consists of a hierarchical accumulator proof module, an evidence chain generation module, and a verification module.

[0029] The following are detailed descriptions:

[0030] This is provided by the record node in the blockchain. It is mainly responsible for storing the confirmed blocks on the chain, reconstructing the storage in the form of a proof tree, and providing a hierarchical accumulator to prove existence.

[0031] Block storage module. The record node organizes blocks in the MMR structure. When there is a new block, the record node updates the MMR in an appended manner, and the latest MMR root hash is also stored in the new block header. This module adjusts the storage data as the proof tree generation module.

[0032] Proof tree generation module. Assume that the upper limit of the number of accumulator elements is N ( , ), note: N should not be set too large. When the number of leaf nodes in MMR reaches N, the N leaf nodes are used to generate a first-level accumulator A1,0{block0,block1,…, blockN-1}. When the number of first-level accumulators reaches N, the N first-level accumulators are used to generate a second-level accumulator, such as the second-level accumulator A2,1{A1,0,A1,1,…,A1,N-1}. By analogy, a proof tree can be obtained, such as Figure 2 As shown, Figure 2 The upper middle picture is a normal MMR, and the lower picture is the proof tree generated after compression and the supplementary MMR. Figure 2 In the , the bottom leaf nodes are represented by block hashes. A1,0 is the accumulator generated by the block hashes corresponding to block0~block3; A1,1 is the accumulator generated by the block hashes corresponding to block4~block7.

[0033] The proof tree is an MMR compressed by an accumulator, which has the advantage that the value of the MMR intermediate node does not need to be changed and the data is always appended. In the proof service, the recording node only needs to store the proof tree and supplement the MMR.

[0034] Verification data query module. The block proof service needs to provide an interface for querying the specified level accumulator data and supplementing MMR data to provide the verification node with block existence verification data.

[0035] This service is provided by the verification node, which is mainly responsible for obtaining verification data, generating evidence chains and verifying the validity of blocks or transactions.

[0036] Hierarchical accumulator proof module. The verification node does not obtain verification data from a single record node, but obtains hierarchical accumulators from multiple record nodes. A distribution strategy that combines fixed allocation and random allocation can be used to allocate query nodes. Strategy of combining fixed allocation and random allocation: If there are M elements to be allocated and N slots to be allocated, and the redundancy factor is m. When M > N, then N of the M elements are evenly allocated to N slots, and the remaining M - N elements to be allocated are extended as evenly as possible to no less than m * N and no more than (m + 1) * N elements, and then randomly and evenly allocated to N slots; when M < N, then M elements are randomly assigned to M of the N slots, and then the M elements are extended as evenly as possible to no less than m * (N - M) and no more than (m + 1) * (N - M), and then randomly and evenly allocated to N slots. Note that the same element is not allowed to be allocated to each slot. For example, the verification node needs to verify the existence verification data of a block with a height of 48. Assuming that the upper limit of the number of accumulator elements is set to 4 and the redundancy factor of the allocation strategy is 2, then according to the characteristics of the proof tree, the hierarchical accumulators that the verification node needs to obtain, that is, the elements to be allocated are {A3,0; A2,3; A1,12}. The currently available record nodes for query, that is, the slots to be allocated are 5, which is the case of M < N. Therefore, one case where the verification node may request from 5 nodes respectively is {A3,0; A2,3}, {A2,3; A1,12}, {A1,12; A3,0}, {A3,0}, {A2,3}. Due to the characteristics of the accumulators designed in the proof tree generation module, the same-level or different-level accumulators obtained by the verification node from different record nodes can be mutually verified, ensuring the correctness of the verification data. On the other hand, this design can also, to a certain extent, determine whether there are malicious nodes in the record nodes.

[0037] Evidence chain generation module. The hierarchical accumulators obtained by the proof module form an evidence chain. If the block to be verified is the current relatively new block and it is possible that the block has not yet been in any accumulator. At this time, additional proof needs to be obtained. The additional proof refers to the supplementary MMR. The data volume of the supplementary MMR is very small. In addition, when the height of the current latest block on the chain is not high, a complete evidence chain can be generated. When the height of the current latest block on the chain is very high, based on the mutual verification of different-level accumulators and the design of obtaining verification data from multiple record nodes, without generating a complete evidence chain on the premise of ensuring the reliability of the verification data. For example: The current latest block height is 66, indicating that the highest level of the current accumulator is exactly 3 layers, and there is only one accumulator A3,0 in the 3rd layer, which can be traced back to block0 to block63. And the height of the block whose existence needs to be proved is 48. At this time, the generated evidence chain is {A3,0—>A2,3—>A1,12}. If the height of the block whose existence needs to be proved is 65, then supplementary MMR is needed. The current supplementary MMR is as Figure 3 As shown in the figure, the evidence chain generated at this time is {A3,0—>A2,3—>A1,12; Addition66}. Figure 3 In the example, A3,0 is the accumulator generated by {A2,0; A2,1; A2,2; A2,3}; A2,0 is the accumulator generated by {A1,0; A1,1; A1,2; A1,3}; A2,1 is the accumulator generated by {A1,4; A1,5; A1,6; A1,7}; A2,2 is the accumulator generated by {A1,8; A1,9; A1,10; A1,11}; A2,3 is the accumulator generated by {A1,12; A1,13; A1,14; A1,15}; A1,0 is the accumulator generated by the block hash corresponding to block0~block3; and so on, A1,15 is the accumulator generated by the block hash corresponding to block60~block63.

[0038] Verification module. In the first case, the block to be verified is an earlier block, which is most likely in the compressed MMR. Then recursively query downward from the MMR root hash of the latest block until the block is found or the block does not exist. For example: the above evidence chain {A3,0—>A2,3—>A1,12}, first query whether A2,3 exists according to the A3,0 accumulator. If it exists, query whether A1,12 exists from the A2,3 accumulator. If it still exists, continue to query whether the block hash to be queried exists in the A1,12 accumulator. In the second case, the block to be verified is a newer block and it may appear that the block is not in any accumulator. Then first calculate the root hash of all peaks in the highest level accumulator and the supplementary MMR. If the verification root hash is the MMR root hash in the current latest block header, continue to prove the existence or non-existence of the block in a bottom-up calculation proof manner according to the supplementary MMR. Since the supplementary MMR height is small, the calculation overhead is small. In special cases, it is necessary to prove the existence of the transaction. First, query the block where the transaction is located, and then prove the existence of the block according to the above mechanism. If the block exists, the transaction exists, otherwise, it does not exist.

[0039] On the other hand, the present invention further discloses a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the processor executes the steps of the above method.

[0040] On the other hand, the present invention further discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the above method.

[0041] In another embodiment provided by the present application, a computer program product including instructions is also provided, which, when executed on a computer, enables the computer to execute any block or transaction existence proof method in the above embodiments.

[0042] It is understandable that the system provided by the embodiment of the present invention corresponds to the method provided by the embodiment of the present invention, and the explanation, examples and beneficial effects of the relevant contents can refer to the corresponding parts in the above method.

[0043] The embodiment of the present application also provides an electronic device, including a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus.

[0044] Memory, used to store computer programs;

[0045] The processor is used to implement the above-mentioned block or transaction existence proof method when executing the program stored in the memory.

[0046] The communication bus mentioned in the above electronic device may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus may be divided into an address bus, a data bus, a control bus, etc.

[0047] The communication interface is used for communication between the above electronic device and other devices.

[0048] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0049] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.

[0050] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or a data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive Solid State Disk (SSD)), etc.

[0051] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0052] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0053] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for proving the existence of a block or transaction, characterized in that: It includes a block proof service and a block verification service; Among them, the block proof service is provided by the recording nodes in the blockchain. The recording nodes store the determined blocks on the chain, reconstruct the storage in the form of a proof tree, and provide a hierarchical accumulator for proving existence; The block proof service includes a block storage module, a proof tree generation module, and a verification data query module; The block verification service is provided by verification nodes, responsible for obtaining verification data, generating an evidence chain, and verifying the validity of blocks or transactions; The block verification service includes a hierarchical accumulator proof module, an evidence chain generation module, and a verification module; The method for generating the proof tree module is as follows: Assume that the upper limit of the number of accumulator elements is N, , , when the number of leaf nodes in MMR reaches N, the N leaf nodes generate a first-level accumulator A1,0{block0, block1,…, blockN-1}; When the number of first-level accumulators reaches N each time, N first-level accumulators are used to generate a second-level accumulator A2,1{A1,0, A1,1, …, A1,N-1}; and so on, to obtain a proof tree; The proof tree is an MMR compressed using an accumulator. The values of the intermediate nodes of the MMR do not need to be changed. In the proof service, the recording nodes only need to store the proof tree and the supplementary MMR.

2. The method for proving the existence of a block or transaction according to claim 1, characterized in that: The block storage module is used for the recording nodes to organize blocks in the MMR structure. When there is a new block, the recording nodes update the MMR in an append mode, and the latest MMR root hash is also stored in the new block header; the block storage module will adjust the stored data along with the proof tree generation module.

3. The method for proving the existence of a block or transaction according to claim 1, characterized in that: The verification data query module is used to externally provide an interface for querying the data of the specified hierarchical accumulator and the supplementary MMR data, and provide the existence verification data of the block for the verification nodes.

4. The method for proving the existence of a block or transaction according to claim 1, characterized in that: The method for proving the hierarchical accumulator proof module is as follows: The verification nodes do not obtain verification data solely from the recording nodes, but obtain multi-level accumulators from multiple recording nodes, and adopt an allocation strategy combining fixed allocation and random allocation to allocate query nodes; The strategy combining fixed allocation and random allocation includes: If there are M elements to be allocated and S slots to be allocated, and the redundancy factor is m, when M > S, then S of the M are evenly allocated to S slots, and the remaining M - S elements to be allocated are evenly extended to no less than m*S and no more than (m + 1)*S elements, and then randomly and evenly allocated to S slots; when M < S, then M are randomly assigned to M of the S slots, and the M elements are evenly extended to no less than m*(S - M) and no more than (m + 1)*(S - M) elements, and then randomly and evenly allocated to S slots; The same element is not allowed to be allocated to each slot; Due to the characteristics of the accumulator designed in the proof tree generation module, the same-level or different-level accumulators obtained by the verification nodes from different recording nodes can be mutually verified, ensuring the correctness of the verification data.

5. The method for proving the existence of a block or transaction according to claim 1, characterized in that: The generation method of the evidence chain generation module includes: The hierarchical accumulators obtained by the hierarchical accumulator proof module form a chain of evidence. If the block to be verified is a newer block and it may not be in any accumulator, additional proof is required. The additional proof refers to supplementing the MMR. When the height of the latest block on the chain does not meet the required height, a complete evidence chain can be generated; and when the height of the latest block on the current chain meets the required height, the design of mutual verification based on accumulators at different levels and multiple recording nodes obtaining verification data ensures that the verification data is reliable without the need to generate a complete evidence chain.

6. The method for proving the existence of a block or transaction according to claim 1, characterized in that: The specific steps of the verification module include: In the first case, the block whose existence is to be verified is an earlier block, and the query is recursively performed downward from the MMR root hash of the latest block until a block is found or the block does not exist; In the second case, the block to be verified is a newer block and it may not be in any accumulator yet. In this case, the root hash of all peaks in the highest-level accumulator and the supplementary MMR must be calculated first. If the MMR root hash in the latest block header is verified, the existence or non-existence of the block is proved in a bottom-up calculation method based on the supplementary MMR. In the third case, if the existence of the transaction needs to be proved, first query the block where the transaction is located, and then prove the existence of the block. If the block exists, the transaction exists, otherwise it does not exist.

7. A computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the processor is caused to perform the steps of the method according to any one of claims 1 to 6.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the method according to any one of claims 1 to 6.

Images