Merkle batch proof generation method and device, equipment and storage medium

Abstract

The invention provides a Merkle batch proof generation method and device, equipment and a storage medium, and relates to the technical field of data processing. According to the method, the batch query requests are received and the target leaf nodes are positioned, so that the to-be-verified data items can be accurately focused, and the overhead of full-tree traversal is avoided; a target leaf node is positioned in a pre-constructed Hash Merkle tree, and a witness tree is constructed, so that a complete structured data basis is provided for path analysis. By traversing the witness tree and identifying the shared sub-paths of the sub-fork paths, and combining the shared sub-paths to construct the collision tree, redundant nodes in the verification path can be effectively identified and eliminated, and extreme compression of the verification path is realized. According to the structured batch certification generated based on the witness tree and the collision tree, on the premise of ensuring verification integrity, communication overhead and computing resource consumption are reduced, and generation and verification efficiency of data certification in a financial high-frequency transaction verification or medical batch auditing scene is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a Merkle batch proof generation method, apparatus, computer equipment, and storage medium. Background Technology

[0002] In the fields of fintech and healthcare IT, data integrity and verifiability have become core requirements for system design. With the widespread application of blockchain technology, Merkle trees, as the underlying data structure, play a crucial role in ensuring data immutability and supporting efficient verification.

[0003] In financial transaction systems, Merkle trees are widely used for verifying the integrity of transaction records. For example, in digital asset trading platforms, each transaction record is stored as a leaf node in a Merkle tree, and the root hash enables rapid verification of transaction data. In healthcare information systems, Merkle trees are used to protect the integrity of patients' electronic medical records (EMRs). Each patient's medical records, diagnostic information, and prescription data are stored as leaf nodes, and the Merkle root hash enables rapid auditing and verification of the medical record data.

[0004] However, existing Merkle trees require the independent construction of a complete verification path for each data item when generating batch proofs, resulting in a large number of redundant nodes for storage and computation. In the scenario of batch querying financial transactions, when multiple transaction records need to be verified, the system needs to generate a complete verification path from the leaf node to the root node for each transaction. There are many shared intermediate nodes between these paths, but existing technologies cannot identify and merge these shared nodes, leading to extremely high redundancy in the proof data. In the scenario of batch auditing medical records, auditing institutions need to verify the integrity of medical record data of multiple patients simultaneously. The verification path of each patient may contain a large number of shared nodes such as the same parent node and grandparent node, but existing technologies cannot effectively compress this redundant information, resulting in huge overhead for proof generation and transmission, making it difficult to meet the needs of efficient verification of large-scale data.

[0005] Current technologies lack efficient batch proof generation mechanisms and cannot identify and utilize path-sharing characteristics between data items during batch queries. In scenarios such as high-frequency trading verification in finance or batch auditing in healthcare, low proof generation efficiency becomes a major bottleneck in system performance. Therefore, improving the efficiency of data proof generation has become an urgent technical problem to be solved. Summary of the Invention

[0006] This application provides a Merkle batch proof generation method, apparatus, computer equipment, and storage medium, aiming to address the technical problem of low efficiency in generating batch proofs of data in financial high-frequency trading verification or medical batch audit scenarios.

[0007] Firstly, this application provides a Merkle batch proof generation method, which includes the following steps: Receive a batch query request, wherein the batch query request contains index information of at least one data item to be proved; Locate the target leaf node corresponding to the index information in the pre-built hash Merkle tree, and construct the witness tree; Traverse the witness tree, identify the shared sub-paths of all branching sub-paths, and merge the shared sub-paths to construct a collision tree; Based on the witness tree and the collision tree, a structured batch proof is generated.

[0008] Secondly, this application also provides a Merkle batch proof generation apparatus, the Merkle batch proof generation apparatus comprising: A request receiving module is used to receive batch query requests, wherein the batch query request contains index information of at least one data item to be proved; The witness tree construction module is used to locate the target leaf node corresponding to the index information in the pre-built hash Merkle tree and construct the witness tree; The collision tree construction module is used to traverse the witness tree, identify the shared sub-paths of all branched sub-paths, and merge the shared sub-paths to construct the collision tree; The batch proof generation module is used to generate structured batch proofs based on the witness tree and the collision tree.

[0009] Thirdly, this application also provides a computer device, the computer device including a processor, a memory, and a computer program stored in the memory and executable by the processor, wherein when the computer program is executed by the processor, it implements the steps of the Merkle batch proof generation method as described above.

[0010] Fourthly, this application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the Merkle batch proof generation method described above.

[0011] This application provides a Merkle batch proof generation method, apparatus, computer device, and storage medium. The method receives batch query requests and locates target leaf nodes, enabling precise focus on the data items to be verified and avoiding the overhead of full tree traversal. It locates target leaf nodes in a pre-constructed hash Merkle tree and builds a witness tree, collecting all sibling nodes on the verification path of each data item, providing a complete structured data foundation for subsequent path analysis. By traversing the witness tree and identifying shared sub-paths of branching sub-paths, and merging these shared sub-paths to construct a collision tree, it can intelligently analyze the common parts between multiple verification paths, effectively identifying and eliminating redundant nodes in the verification path, achieving extreme compression of the verification path and eliminating data redundancy. The structured batch proofs generated based on the witness tree and collision tree not only contain the minimum set of nodes required for verification but also retain path reconstruction capabilities through structural information. Therefore, while ensuring verification integrity, it significantly improves the transmission efficiency and computational performance of data verification, reduces communication overhead and computational resource consumption, and enhances the generation and verification efficiency of data proofs. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of an application environment for the Merkle batch proof generation method in one embodiment of the present invention; Figure 2 A flowchart illustrating an embodiment of a Merkle batch proof generation method provided in this application; Figure 3 This is a schematic diagram of the structure of an embodiment of a Merkle batch proof generation device provided in this application. Figure 4 This is a schematic block diagram of the structure of a computer device provided in an embodiment of this application.

[0014] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0015] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0017] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] The Merkle batch proof generation method provided in this embodiment of the invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. When the server receives a data verification request initiated by the client, it can receive a batch query request, wherein the batch query request contains index information of at least one data item to be proved; locate the target leaf node corresponding to the index information in a pre-built hash Merkle tree to construct a witness tree; traverse the witness tree, identify the shared sub-paths of all branching sub-paths, and merge the shared sub-paths to construct a collision tree; and generate a structured batch proof based on the witness tree and the collision tree.

[0020] In this invention, addressing the technical problem of low efficiency in generating batch proofs of data in financial high-frequency trading verification or medical batch auditing scenarios, the invention receives batch query requests and locates target leaf nodes, enabling precise focus on the data items to be verified and avoiding the overhead of full tree traversal. It locates the target leaf nodes in a pre-constructed hash Merkle tree and builds a witness tree, collecting all sibling nodes on the verification path of each data item, providing a complete structured data foundation for subsequent path analysis. By traversing the witness tree and identifying shared sub-paths of branching sub-paths, and merging these shared sub-paths to construct a collision tree, the invention intelligently analyzes the common parts between multiple verification paths, effectively identifying and eliminating redundant nodes in the verification path, achieving extreme compression of the verification path and eliminating data redundancy. The structured batch proofs generated based on the witness tree and collision tree not only contain the minimum set of nodes required for verification but also retain path reconstruction capabilities through structural information. This significantly improves the transmission efficiency and computational performance of data verification while ensuring verification integrity, reducing communication overhead and computational resource consumption, and enhancing the efficiency of data proof generation and verification.

[0021] The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will now be described in detail through specific embodiments.

[0022] Generally, before generating batch proofs, a complete hash Merkle tree needs to be constructed, which is the foundation of the entire proof mechanism. The construction process of the Merkle tree starts from the bottom layer of data, storing the hash value of the data item as a leaf node, and calculating the hash value of the parent node layer by layer upwards until the root node is finally formed. The hash value of the root node serves as a unique identifier for the entire data structure and is used for subsequent data integrity verification.

[0023] The underlying data, which forms the starting point of the Merkle tree, is typically the raw data that needs to be verified. This data is hashed and stored in the leaf nodes of the Merkle tree. For example, in a blockchain, the underlying data is transaction records; in an authentication dictionary, it is key-value pairs; and in distributed storage, it is file shards or the underlying data itself.

[0024] In a Merkle tree, leaf nodes are the lowest-level nodes, directly storing the hash values ​​of the underlying data, and they have no child nodes. The root node is the highest-level node, and its hash value is the unique identifier of the entire Merkle tree. The root node's hash value is used to verify the integrity of the entire data structure. Nodes between the leaf nodes and the root node are called internal nodes, and each internal node's hash value is the hash of its child nodes' hash values. When constructing a Merkle tree, a hash dependency graph also needs to be maintained synchronously. This graph records the hash calculation dependencies between nodes, helping to quickly locate and update node hash values. A hash value is a fixed-length output value calculated using a hash function. In a Merkle tree, each node's hash value is the hash of its content or the hash values ​​of its child nodes.

[0025] In one embodiment, when constructing the Merkle tree, the hash values ​​of the underlying data are stored as leaf nodes, and the hash values ​​are calculated layer by layer upwards until the root node, while maintaining a hash dependency graph. The main steps include: performing hash calculations on the underlying data set and storing the hash value of each data item as a leaf node in the Merkle tree; starting from the leaf node, calculating the hash value layer by layer upwards, with the hash value of each node at each layer obtained from the hash calculation of its child node hash values, until the root node; constructing a hash dependency graph to record the hash calculation dependencies between nodes, providing a foundation for subsequent proof generation and updates; and storing the constructed Merkle tree structure and hash dependency graph in a data storage system for use by the proof layer and update layer.

[0026] First, the underlying data that needs to be stored and verified is collected. This underlying data can take various forms, such as transaction records in a blockchain, file shards in distributed storage, or key-value pairs in an authentication dictionary. Each piece of underlying data will serve as the basis for constructing the Merkle tree.

[0027] For each piece of underlying data Perform hash calculations to generate the corresponding leaf node hash values. These leaf nodes form the bottom layer (level 0) of the Merkle tree.

[0028] Starting from the leaf node level, pair up adjacent nodes. For each pair of nodes, concatenate their hash values ​​and perform a second hash operation to generate the hash value of the parent node; for example, Generate the first internal node of the first level. Use this newly generated internal node as a new leaf node, and repeat the pairing and hashing process to continue building higher-level nodes. If the number of nodes in a certain level is odd, copy the last node and pair it with itself, or directly use its hash value as the parent node.

[0029] The above process is repeated recursively until only one node remains. This unique node at the top level is the root node of the Merkle tree (MerkleRoot). The hash value of the root node represents a unique identifier for the entire dataset and is used to verify the integrity of the entire data structure. Furthermore, any minor modification to the underlying data will cause its hash value to change, and this change will propagate upwards through the tree structure, ultimately leading to a change in the root hash value.

[0030] During the construction of the Merkle tree, a hash dependency graph is maintained synchronously to record how the hash value of each node (leaf node, internal node, and root node) is calculated from its child nodes.

[0031] Once constructed, the complete Merkle tree structure (including all leaf nodes, internal nodes, and the root node) and hash dependency graph can be stored in the data storage system for subsequent proof generation and verification.

[0032] By constructing Merkle trees, large amounts of data can be organized and managed efficiently, and the necessary structural support can be provided for subsequent batch proof generation.

[0033] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of a Merkle batch proof generation method provided in this application.

[0034] like Figure 2 As shown, the Merkle batch proof generation method includes steps S101 to S104.

[0035] S101. Receive a batch query request, wherein the batch query request contains index information of at least one data item to be proved; In one embodiment, the data verification system can receive batch query requests from users through a predefined interface. These requests can be JSON data transmitted over a network, API (Application Programming Interface) calls, or other forms of data transmission. The request header contains metadata information such as version identifier, timestamp, and request source, used for request verification and routing.

[0036] A batch query request contains index information for at least one data item to be verified. This index information is the location identifier of the data item to be verified in the underlying dataset. Generally, the index information can be the position number or other unique identifier of the data item to be verified in the underlying dataset.

[0037] Upon receiving a batch query request, the system first parses the request to extract the index information. The parsing process ensures the request format is correct and converts the index information into a data structure that the system can process.

[0038] Perform request validation on batch query requests, such as format validation, security validation, business validation, parameter optimization, and load control.

[0039] Specifically, format validation is used to check whether the requested data conforms to predefined specifications, verify the integrity of required fields and the correctness of data types; security validation verifies the legitimacy of the request source through digital signatures, checks the validity of API keys, and implements IP whitelist filtering.

[0040] Business validation is used to verify the validity of the index value range, that is, the index value must be greater than or equal to 1 and less than or equal to the total number of leaf nodes n of the pre-built hash Merkle tree. If the index format does not meet the requirements or exceeds the value range, the system will immediately return detailed error information to the requester, prompting it to make corrections.

[0041] The parsed index information is sorted and deduplicated. The indexes are sorted in ascending order, which improves efficiency and reduces unnecessary computation when building the witness tree and search paths later. Simultaneously, the index list is checked for duplicate index entries; if found, these duplicates are removed to avoid processing identical data items repeatedly and wasting system resources.

[0042] Parameter optimization is used to perform deduplication on the index list, merge consecutive numerical ranges, and sort them in ascending order to optimize subsequent processing efficiency; load control is used to implement request queue management, and when the number of concurrent requests exceeds the threshold, priority scheduling or rejection policies are enabled.

[0043] The sorted and deduplicated logical indexes are then converted into their actual physical locations within the underlying Merkle data tree. Since the underlying data may undergo specific storage arrangements or encoding processes during the construction of the Merkle data tree, it is necessary to accurately map the logical indexes to the actual locations of the corresponding leaf nodes in the Merkle data tree according to pre-defined mapping rules. This mapping process must consider factors such as the grouping and storage methods of the underlying data, as well as the structural characteristics of the Merkle data tree.

[0044] This embodiment implements strict request parsing, multi-dimensional verification (format, security, business), parameter optimization (sorting, deduplication, range merging), and load control mechanisms to efficiently and securely receive and preprocess batch query requests, effectively filter invalid or malicious requests, and optimize subsequent processing flows. This significantly improves the overall processing efficiency and stability of the data verification system, laying a solid and reliable foundation for subsequent witness tree construction and batch proof generation.

[0045] S102. Locate the target leaf node corresponding to the index information in the pre-constructed hash Merkle tree and construct the witness tree; After completing the preprocessing and mapping transformation of the index information, the target leaf node is located in the pre-built hash Merkle tree.

[0046] Specifically, precise location is achieved within the Merkle tree based on the converted physical location information. Merkle trees are typically stored as tree data structures in memory or on disk. Depending on the tree's storage structure, a suitable traversal algorithm, such as Depth-First Search (DFS) or Breadth-First Search (BFS), is employed. Starting from the root node, the search proceeds downwards along the path corresponding to the index until the target leaf node is found. During the traversal, the search range is gradually narrowed based on the node hierarchy and index information, ultimately locating the required leaf node.

[0047] To improve the efficiency of locating target leaf nodes, a node caching mechanism can be employed. Frequently queried leaf nodes or those located in popular data areas can be cached in a high-speed cache (such as a memory cache). When a request containing the indexes of these leaf nodes is received, the target leaf node can be retrieved directly from the cache, avoiding the tedious tree traversal process and significantly improving the location speed. Simultaneously, the cache content can be updated periodically to ensure that the node information in the cache remains consistent with the actual state of the Merkle tree.

[0048] After successfully locating the target leaf node, the witness tree can be constructed. In one embodiment, starting from the target leaf node corresponding to the index information, the Merkle tree is traversed upwards layer by layer until the root node is reached, and all sibling nodes on the path from the target leaf node to the root node are determined; each sibling node is organized into a subtree according to the tree structure of the Merkle tree to obtain the witness tree.

[0049] In one embodiment, for a Merkle tree with an array storage structure, a direct addressing method can be used. Based on preprocessed standardized index information (with format verification, range validation, and sorting for deduplication), the physical offset address of the leaf node in memory can be directly calculated. The calculation formula is: Leaf node address = Base offset + Index value × Node size. For a Merkle tree with a linked storage structure, a tree traversal method can be used, performing an optimized depth-first search (DFS) starting from the root node. The hierarchical characteristics of the index (such as binary bit patterns) are utilized to accelerate path location. For example, each bit of the index's binary representation determines the traversal direction to the left / right subtree. Alternatively, a pre-maintained index mapping table can be used to quickly map index information to specific leaf nodes in the Merkle tree. For example, index 1 maps to leaf node H(A), and index 3 maps to leaf node H(C). Based on the index mapping table, all target leaf nodes are retrieved from the Merkle tree and stored in a temporary data structure.

[0050] For each target leaf node, traverse the Merkle tree level by level upwards from the target leaf node until the root node. For example, an improved breadth-first search (BFS) strategy can be used: label the exact level in the Merkle tree for each visited node (level 0 for the target leaf node), maintain a dynamically updated path stack, record the complete traversal from the current node to the root node, and automatically terminate when the root node is reached.

[0051] During the traversal, for each path node (including the target leaf node and its ancestor nodes), a sibling node identification operation is performed: based on the position of the path node in the parent node's child node array (index 0 or 1), the position of its sibling node is determined, and the complete hash value of the sibling node is directly obtained from the parent node's child node reference (to avoid redundant calculation). For edge nodes of the tree structure (such as the rightmost leaf node), its sibling node may not exist, and it is recorded as a virtual empty node.

[0052] In this context, sibling nodes refer to nodes that are adjacent to the node on the same path at the same level. Together, they form the set of child nodes of the parent node of this node. The hash value and position information of each sibling node are recorded for use when constructing the witness tree later.

[0053] Generally, the collected sibling nodes include the direct sibling nodes of the target leaf node (used to verify critical components of the path), all intermediate level adjacent nodes (used to build a complete verification chain), and balanced filler nodes of the root node (such as virtual nodes when the Merkle tree adopts a complete binary tree structure).

[0054] Based on the collected set of sibling nodes, a witness tree is constructed by structurally reorganizing the original Merkle tree hierarchy. Specifically, the root node of the original Merkle tree is used as the logical root node of the witness tree; the depth position of each node in the original tree is strictly maintained, i.e., from leaf node level 0 to root node level h; the connection relationship between nodes is reconstructed through a parent-child pointer array, and each node stores references to its left and right child nodes.

[0055] A witness tree is a subtree containing the target leaf node and all its sibling nodes along its path. It preserves the hierarchical relationship and node topology of a Merkle tree. When organizing the subtree, the target leaf node is treated as a leaf node, and its sibling nodes along its path are treated as internal nodes or adjacent nodes of the leaf node, arranged and connected according to the rules of a Merkle tree. Each node in the witness tree clearly records its parent-child and sibling relationships with other nodes, ensuring that the witness tree accurately reflects the verification path information of the target leaf node in the Merkle tree.

[0056] To improve the storage efficiency and query performance of the witness tree, the constructed witness tree can be optimized. For example, nodes in the witness tree can be compressed and encoded, and consecutive nodes with the same hash value can be merged to reduce the space occupied by node storage. More efficient tree structure representation methods can be adopted, such as using arrays to represent the node relationships in the tree, to improve node access speed. Simultaneously, integrity checks can be performed on the witness tree to ensure that the node information and hierarchical relationships in the witness tree are consistent with the actual situation in the Merkle tree, avoiding data errors or verification failures.

[0057] This embodiment achieves rapid and accurate location of the target leaf node by employing direct addressing, tree traversal, and node caching mechanisms. It constructs a witness tree containing complete verification information through bottom-up path traversal and sibling node collection. Furthermore, it significantly improves the storage efficiency and query performance of the witness tree through node compression encoding, structural optimization, and integrity checks, providing an efficient and reliable data foundation for subsequent collision tree construction and batch proof generation.

[0058] S103. Traverse the witness tree, identify the shared sub-paths of all branched sub-paths, and merge the shared sub-paths to construct a collision tree; In one embodiment, the traversal parameters can be initialized before traversing the witness tree. Specifically, the starting node for traversal is set to the root node of the witness tree, an empty node stack is initialized for depth-first traversal (DFS), and a hash table is prepared to record visited nodes and their related information. Additionally, a dedicated data structure can be created to store identified branch information and shared sub-path information.

[0059] Additional metadata can be attached to each node in the witness tree, including the node's location in the original Merkle tree, the node's depth (the path length from the root node to the node), the node's hash algorithm identifier, etc., in order to accurately identify forked sub-paths and shared sub-paths.

[0060] Furthermore, starting from the leaf node of the witness tree, traverse upwards layer by layer until the root node of the witness tree; for each internal node in the witness tree, check whether the internal node has a branching sub-path; if the internal node has a branching sub-path, analyze the shared sub-paths of each branching sub-path; merge the nodes of the shared sub-paths of each branching sub-path to obtain the collision tree.

[0061] In one embodiment, the traversal process is initialized starting from the leaf node level (bottom layer) of the witness tree. For example, the traversal of the witness tree can employ a strategy combining breadth-first search and level labeling: each leaf node is labeled with a level value (e.g., level 0), and the levels of subsequent internal nodes are incremented by the parent node's level + 1 to achieve level labeling; leaf nodes are managed in a queue, using a double-ended queue (Deque) to store leaf nodes to be processed, and dequeuing them sequentially according to their level order.

[0062] Specifically, starting from the leaf nodes at level 0, each internal node (non-leaf node) is processed upwards layer by layer. For each visited internal node (non-leaf node), the number and characteristics of its child nodes are examined. When an internal node has two or more child nodes, and the subsequent paths of these child nodes show different directions, the node is determined to be a fork node, and its corresponding different child node paths are forked sub-paths. For example, if the left child node path and the right child node path of an internal node have significant differences in the subsequent node sequence, a fork is considered to have occurred.

[0063] For each detected fork node, record its relevant information, including its hash value, its position in the witness tree, and the path characteristics of its child nodes. Store this fork information in a previously prepared hash table, using the node's unique identifier (such as a combination of hash value and location information) as the key for easy and quick lookup and comparison later.

[0064] For each fork node, a detailed comparison of its various forked sub-paths is performed. Starting from the fork node, the hash values, node types (such as ordinary data nodes, special marker nodes, etc.), and hierarchical relationships of the nodes on each sub-path are compared layer by layer downwards. The shared sub-paths are those where, starting from the fork node, nodes are traced back upwards to a specific node, and the nodes on this path share the same hash values ​​and node characteristics.

[0065] By progressively comparing and backtracking downwards, the range of shared sub-paths corresponding to each fork node is determined. The identification of shared sub-paths can be optimized using a dynamic programming algorithm: treat the node sequence of each fork path as a string, calculate the set of nodes corresponding to its LCP (Longest Common Prefix); extract the smallest shared unit, ensuring that the shared sub-path contains at least one internal node and all its necessary sibling nodes. The identified shared sub-paths are marked in a witness tree, and the starting node (i.e., the fork node) and ending node (the node where sharing ends) of the shared sub-path, as well as the set of nodes and hash value information on the shared sub-path, are recorded.

[0066] Based on the identified shared sub-paths, a collision tree is constructed. The root node of the collision tree can be selected as the starting node corresponding to the earliest shared sub-path in the witness tree (usually the root node or a shared starting node close to the root node) to reflect the overall sharing relationship.

[0067] Specifically, nodes on shared sub-paths within each branched sub-path are merged. For each node on a shared sub-path, only one unique node instance is retained, and its hash value and related metadata (such as node depth, hash algorithm identifier, etc.) are stored in the collision tree. During the merging process, the hierarchical structure of shared nodes in the collision tree is reconstructed according to the parent-child relationships in the original Merkle tree (e.g., the parent node of a branched node becomes the next-level node in the collision tree), ensuring that the hierarchical and connection relationships of the nodes remain consistent with the shared sub-paths in the original witness tree. All sibling nodes common to all branched sub-paths on the shared sub-path are merged into a single instance and stored in the corresponding position in the collision tree.

[0068] Based on the merged shared sub-paths, a complete collision tree structure is constructed. Specifically, the starting node of the top-level shared sub-path in the witness tree (usually close to the root node) is set as the logical root node of the collision tree. For the branching nodes themselves, they are retained as special branch nodes in the collision tree, marking their branching attributes and the direction of sub-path divergence. For the parts of the branching sub-paths that are not part of the shared sub-paths (i.e., unique sub-paths), the node information of these unique sub-paths is retained in the collision tree, but stored separately from the shared sub-paths. The nodes of unique sub-paths can be organized below the nodes of the shared sub-paths, representing their association with the shared sub-paths through specific connections, while recording the starting and ending node information of the unique sub-paths.

[0069] This application introduces a collision tree as the core of batch proof compression. By analyzing the branching structure of different Merkle paths, common prefixes and shared sub-paths are automatically aggregated to form a minimal set of necessary nodes. This method achieves a practical, logically clear, and verifiable batch proof compression mechanism, significantly reducing communication volume compared to traditional schemes. Through structured design, this application can be widely applied to fields such as authentication dictionaries, blockchain state verification, and trusted database queries, and can be naturally extended to quantum-resistant security applications. After the collision tree structure is built, it can be further optimized and improved, such as removing redundancy from nodes, adjusting the structure, and updating metadata.

[0070] Specifically, firstly, after merging shared subpaths, the collision tree is checked for duplicate nodes (i.e., nodes with identical hash values ​​and node characteristics). If duplicates exist, only one node instance is retained, and other redundant nodes are deleted to reduce the number of nodes in the collision tree and improve the efficiency of subsequent verification and processing. Secondly, the node connections and hierarchical structure of the collision tree are optimized to ensure a more compact and reasonable structure. For example, adjacent nodes with similar characteristics are merged or reorganized to reduce unnecessary hierarchical branches and improve the query and verification speed of the collision tree. Finally, the metadata of each node in the collision tree is updated, including the node's new position in the collision tree, its mapping relationship with nodes in the original witness tree, and the node's role information in shared and unique subpaths.

[0071] Generally, after the collision tree is constructed, it can be verified, such as through integrity checks, consistency verification, and structural verification.

[0072] In this process, integrity checks can be performed by traversing the collision tree and comparing it with the original witness tree. This verifies whether the collision tree completely contains all the necessary information from the original witness tree, i.e., whether the shared sub-paths of all branched sub-paths have been correctly merged and whether all unique sub-paths have been properly preserved, ensuring that no information is lost or incorrectly merged.

[0073] Consistency verification can be performed by recalculating node hash values ​​and comparing node characteristics. This checks whether the hash values ​​and node characteristics of each node in the collision tree are consistent with the corresponding nodes in the original witness tree. Especially after merging shared subpaths, it ensures that the hash values ​​of the merged nodes are calculated correctly and that they match the logical relationships of the original nodes, thus guaranteeing the consistency and accuracy of the collision tree.

[0074] Structural verification is used to verify whether the tree structure of the collision tree is reasonable and whether the hierarchical and connection relationships of the nodes conform to the expected construction rules. Specifically, it can check for abnormal structures such as circular connections and isolated nodes to ensure the structural integrity of the collision tree so that it can be correctly used for the generation and verification of structured batch proofs in the future.

[0075] This embodiment employs a traversal strategy combining breadth-first search and hierarchical labeling to efficiently identify branching nodes and shared sub-paths in the witness tree. It optimizes the identification of shared sub-paths through dynamic programming, achieving intelligent compression of verification paths. By removing redundancy from nodes, adjusting the structure, and updating metadata, it constructs a compact and efficient collision tree, significantly reducing data redundancy in batch proofs and improving the overall efficiency of proof generation and verification.

[0076] S104. Based on the witness tree and the collision tree, generate structured batch proofs.

[0077] In one embodiment, the structured batch proof includes witness tree structure information and a set of collision tree nodes.

[0078] The witness tree structure information includes the unique nodes of each data item and their association with shared nodes in the collision tree, such as data items... The parent node hash must be associated with the left child node of node X in the collision tree. The collision tree node set includes the hash values ​​of all shared nodes.

[0079] Further, the hash values ​​of all nodes in the collision tree are extracted to obtain a first data set; the structured information in the witness tree is extracted to obtain a second data set, wherein the structured information includes the parent-child relationship between leaf nodes and the position of the branch node of the branch sub-path; the first data set and the second data set are combined to generate the structured batch proof.

[0080] In one embodiment, the shared node hashes of the collision tree are stored in hierarchical order as an array or hash table; the unique nodes of the witness tree are stored in categories according to data item indexes, along with their associated metadata with the collision tree nodes.

[0081] Specifically, all nodes of the collision tree are traversed, their hash values ​​are extracted, and stored in tree-level order to form the first data set (hash array or hash table); the unique node (leaf node and sibling node) of each data item is extracted from the witness tree, and its association information with the shared nodes in the collision tree is recorded to form the second data set (structured metadata, including node hash, association rules, hierarchical position, etc.).

[0082] Simultaneously, auxiliary information can be generated, such as path reconstruction guidelines and metadata headers. The path reconstruction guidelines describe how to reconstruct the complete Merkle path for each data item using a combination of collision trees and witness trees; the metadata header records the version number of the batch proof, the hash algorithm type, the number of data items k, and the verification of the collision tree and witness tree, etc.

[0083] The first data set (shared node hashes), the second data set (unique nodes and association rules), and auxiliary information are merged to generate the final structured batch proof. This structured batch proof includes a shared node set, a unique node set, association metadata, and auxiliary information.

[0084] The shared node set includes the hash values ​​of all collision tree nodes, used to verify the common parts of the path. The unique node set contains the leaf nodes and sibling node hash values ​​of each data item in the witness tree, used to verify the independent parts of the path. Associated metadata describes how unique nodes reconstruct the complete verification path using shared nodes; for example: parent node hash = hash(unique node + shared sibling node). Supporting information includes path reconstruction guidelines and metadata headers.

[0085] This embodiment constructs a structured Merkle batch proof model, which decomposes batch proofs into two composable structures: "Witness Trees" and "Collision Trees". This model can clearly express the node sharing relationship between different proof paths, thereby eliminating duplicate hash nodes and achieving a theoretically optimal proof size of O(k·log(n / k)).

[0086] After generating the structured batch proof, the output structured batch proof can be verified. The verification steps include: reconstructing a data verification path for each data item to be verified based on the structured batch proof using path reconstruction auxiliary information; calculating the hash value layer by layer upwards along the data verification path starting from the data item to be verified to obtain the computed root hash; comparing the computed root hash with the trusted root hash to obtain the verification result; and when the verification result is a verification failure, reconstructing the witness tree and the collision tree, and regenerating the structured batch proof based on the reconstructed witness tree and the collision tree.

[0087] In one embodiment, upon receiving a structured batch proof, a path reconstruction operation is performed. Specifically, the path reconstruction auxiliary information contained in the structured batch proof is parsed. This auxiliary information explicitly describes how to combine shared nodes in the collision tree with unique nodes in the witness tree to reconstruct the complete Merkle path for each data item to be verified. Based on the index or identifier in the auxiliary information, shared nodes are located in the collision tree node set, and unique nodes are located in the witness tree node set. Following the Merkle tree hierarchy, the shared nodes and unique nodes are assembled into a complete verification path from the data item to be verified (leaf node) to the root node. For example, the auxiliary information might indicate "data item..." The parent node is the left child node of node X in the collision tree. Based on this, the verifier will determine the data item. The hash value of node X is combined with the hash value of the left child node of node X for calculation.

[0088] Starting from the leaf node of the data item to be verified, calculate the hash value layer by layer upwards along the reconstructed verification path. For each layer, perform a hash operation on the current node and its sibling nodes (determined based on path reconstruction auxiliary information) to obtain the hash value of the parent node. Repeat the above process until the root node is reached to obtain the root hash.

[0089] The calculated root hash is compared with a trusted root hash maintained by the system (such as the block header hash in the blockchain, the root hash commitment in the database, etc.). If they match, the verification passes, proving that the data item is complete and has not been tampered with; if they do not match, the verification fails.

[0090] When all data items pass verification, a success result is returned. When the verification result fails, a failure handling process is initiated to analyze the cause of the failure. Specifically, by comparing the difference between the calculated root hash and the trusted root hash, the level and node of hash inconsistency are located to preliminarily determine the location of data tampering; the integrity of the structured batch proof itself is checked, and whether there is data corruption or transmission error; the trusted root hash is checked to see if it has expired or been updated, and the verification environment is confirmed to be consistent with the proof generation environment.

[0091] If the analysis indicates that the verification failure is due to inconsistency between the proof data and the current system state, the witness tree and collision tree are reconstructed. Specifically, the latest data state and trusted root hash are obtained; based on the latest data item and Merkle tree structure, the target leaf node is relocated, sibling nodes on the path are collected, and a new witness tree is constructed; based on the new witness tree, branching sub-paths and shared sub-paths are re-identified, shared nodes are merged, and a new collision tree is constructed.

[0092] Extract the hash values ​​of all nodes from the new collision tree to form a new first data set; extract structured information such as the parent-child relationship of nodes and the position of fork nodes from the new witness tree to form a new second data set; combine the new first data set and the second data set to generate a new structured batch proof and update the path reconstruction auxiliary information.

[0093] This embodiment decomposes batch proofs into two core components: a "collision tree node set" and "witness tree structure information," achieving extreme compression and structured expression of the verification path. By introducing path reconstruction auxiliary information, the verifier can efficiently reconstruct the complete verification path and perform integrity verification. At the same time, through an automatic reconstruction mechanism after verification failure, the consistency between the proof data and the system state is ensured, thereby constructing an efficient, reliable, and self-healing structured batch proof generation and verification system.

[0094] Generally, traditional Merkle trees suffer from a significant performance bottleneck when faced with dynamic data updates: any modification to the underlying data necessitates recalculating the hash values ​​of all intermediate nodes along the entire path from the leaf node to the root node, thus triggering a complete reconstruction of the Merkle tree. This full-update approach incurs enormous computational overhead and system latency in high-frequency trading or real-time systems with frequent data changes, severely limiting the system's scalability and responsiveness.

[0095] To address this technical problem, this application proposes an updatable incremental maintenance algorithm. This algorithm enables batch proofs to be completed without overall reconstruction when underlying leaf nodes change. Instead, it involves maintaining locally conflicting nodes, updating related subtrees, and synchronizing the hash dependency graph. This design significantly reduces update costs in dynamic systems, making this application applicable to scenarios requiring high-frequency updates, such as stateless blockchains and distributed databases.

[0096] In one embodiment, when the bottom leaf node of the Merkle tree is modified, a node to be updated that has a data association with the bottom leaf node is identified; the update hash value of the node to be updated is calculated; the update hash value is applied to the node to be updated in the Merkle tree to obtain an updated Merkle tree; based on the updated Merkle tree, the hash dependency graph is updated to obtain an updated hash dependency graph, so that the hash values ​​of the Merkle tree and the hash dependency graph are consistent.

[0097] When a leaf node at the bottom level of a Merkle tree is modified, the write operations to the underlying data are monitored, and the index of the modified underlying data is recorded. The hash value of the modified underlying data is recalculated and compared with the old hash value of the corresponding leaf node in the Merkle tree to confirm whether a substantial change has occurred. If a hash value inconsistency is detected, an incremental update process is triggered.

[0098] A bottom-up path tracing strategy is employed to identify all affected nodes awaiting update. The modified leaf node itself is the primary node to be updated. Starting from the modified leaf node, the Merkle tree path is traversed level by level upwards until the root node is reached. All intermediate nodes on the path (parent nodes, grandparent nodes, etc.) require recalculation of their hash values ​​due to changes in the factor node hash and are therefore marked as nodes awaiting update.

[0099] Meanwhile, the hash dependency graph records the child nodes that each node depends on for hash value calculation. By querying the hash dependency graph, the set of all nodes that directly or indirectly depend on the modified leaf node can be quickly located, thereby efficiently determining the update range.

[0100] For modified underlying leaf nodes, their new hash values ​​can be calculated directly. Specifically, a specified hash function (such as SHA-256) is applied to the modified underlying data content to generate new leaf node hash values. If the leaf node contains additional metadata (such as version numbers or timestamps), this metadata is hashed together with the underlying data content.

[0101] For internal nodes (non-leaf nodes) on the path, their hash values ​​can be recalculated recursively or iteratively. Specifically, obtain the latest hash values ​​of all child nodes of the internal node. If a child node has not been updated, use its old hash value; if a child node has been updated, use its new hash value. Combine the hash values ​​of the child nodes according to the Merkle tree construction rules (usually concatenating the hashes of the left and right child nodes), and then apply a hash function to generate a new hash value for the internal node. Start from the bottom-level internal node and calculate upwards layer by layer until the root node. Ensure that the hashes of its child nodes have been updated when the hash of the parent node is calculated.

[0102] To ensure data consistency, updates to Merkle tree nodes employ atomic operations. First, during the update process, the node to be updated or its subtree is locked to prevent data inconsistency caused by concurrent reads and writes. Second, the calculated new hash value can be directly written to the corresponding node's storage location in the Merkle tree data structure, replacing the old hash value. Finally, all node update operations are treated as a single transaction; either all succeed or all are rolled back. If an error occurs during the update process, the system can roll back to the state before the update.

[0103] The hash dependency graph records the hash calculation dependencies between nodes. After an update to the Merkle tree, the hash dependency graph must be updated synchronously. Specifically, dependencies related to modified nodes become invalid due to changes in node hash values; therefore, all old dependencies related to the modified nodes need to be removed from the hash dependency graph. Dependencies are then re-established based on the updated Merkle tree node relationships. For example, if the new hash value of node A depends on the new hash values ​​of its children B and C, new edges from A to B and C are added to the hash dependency graph. Only the affected local areas in the hash dependency graph are modified, rather than the entire graph being rebuilt, to improve efficiency. After the update, the hash dependency graph is traversed to verify that the dependencies of each node are consistent with the actual parent-child relationships in the Merkle tree, ensuring that the graph and tree are synchronized.

[0104] After updating the Merkle tree and hash dependency graph, the witness tree and collision tree are reconstructed based on the updated Merkle tree and hash dependency graph; and an updated structured batch proof is generated based on the reconstructed witness tree and the updated collision tree.

[0105] Before reconstructing the witness tree and collision tree, the synchronization status of the Merkle tree and hash dependency graph is first verified. Specifically, the root hash of the Merkle tree is checked to ensure that it matches the root node hash recorded in the hash dependency graph, guaranteeing that they are on the same data version. The hash dependency graph is traversed to verify that the dependent child nodes of each node exist in the Merkle tree and that their hash values ​​match, ensuring that the graph and tree structures correspond correctly. The hash dependency graph is used to quickly locate the range of nodes that have changed since the last proof was generated, identifying the subtree regions that need to be reconstructed.

[0106] Receive new batch query requests or reuse the previous query index set. Sort, deduplicate, and validate the query index. Analyze the impact of data changes on query results using a hash dependency graph. If the changed data block is not within the query scope and does not affect nodes on the query path, some of the old proof structure can be reused.

[0107] Using the storage structure of a Merkle tree (such as an array index or a B+ tree), the target leaf node is relocated in the updated Merkle tree based on the index information. During the location process, a hash dependency graph is used to verify the validity of the path nodes, ensuring that the located leaf node is the latest version.

[0108] Starting from the target leaf node, traverse upwards along the Merkle tree path. For each node on the path, determine its sibling nodes based on its position within its parent node (left or right child). Extract the latest hash value of the sibling node from the Merkle tree. Record the complete verification path, including the node hashes at each level and their sibling node information.

[0109] The collected node information is organized into a witness tree structure. Specifically, starting from the target leaf node, sibling nodes along the path are organized into a witness tree according to the hierarchical relationship of a Merkle tree. Metadata such as version information and hash algorithm identifiers are attached to each node to ensure the integrity and verifiability of the witness tree.

[0110] Based on the reconstructed witness tree, the sharing relationships between verification paths of different data items are analyzed. The verification paths of multiple data items are aligned and compared to identify common path prefixes and determine the node positions where paths begin to branch, i.e., the end point of shared paths and the start point of unique paths. Nodes common to multiple paths are extracted and merged into a single instance to eliminate redundant storage. At the end of a shared path, a branch node is used to represent the start point of a unique path for a different data item. The shared nodes and branch nodes are organized into a tree structure, forming a collision tree.

[0111] The data required to generate structured batch proofs is extracted from the reconstructed witness tree and collision tree, including the collision tree node set and witness tree structure information. Specifically, the hash values ​​of all nodes in the collision tree are extracted to form the collision tree node set, which represents the shared part of the verification path; the parent-child relationship, branch position, and other structured information of the nodes in the witness tree are extracted to form the witness tree structure information, which describes how unique nodes and shared nodes are combined into a complete verification path.

[0112] Serialize the collision tree node set and witness tree structure information into binary or JSON format for easy transmission and storage. Add metadata such as proof generation time, version number, and number of data items.

[0113] This process generates information to assist the verifier in verifying structured batch proofs, such as path reconstruction guidelines and dependency descriptions. The path reconstruction guidelines are a sequence of instructions describing how to reconstruct the verification path using collision trees and witness trees. The dependency descriptions include the dependencies between data items in the structured batch proof, facilitating the verifier's understanding of the proof structure.

[0114] This embodiment introduces an incremental maintenance algorithm. When the underlying data changes, only the hash values ​​of the affected local nodes need to be recalculated, and the hash dependency graph is updated synchronously, thus avoiding the huge overhead of full reconstruction of the traditional Merkle tree. By reconstructing the witness tree and collision tree based on the updated state and generating new structured batch proofs, the consistency between the proof data and the latest state of the system is ensured, realizing efficient and low-latency batch proof generation and maintenance in a dynamic data environment.

[0115] This embodiment provides a Merkle batch proof generation method. This method receives batch query requests and locates the target leaf node, enabling precise focus on the data item to be verified and avoiding the overhead of full tree traversal. It locates the target leaf node in a pre-constructed hash Merkle tree and builds a witness tree, collecting all sibling nodes on the verification path of each data item, providing a complete structured data foundation for subsequent path analysis. By traversing the witness tree and identifying shared sub-paths of branching sub-paths, and merging these shared sub-paths to construct a collision tree, it can intelligently analyze the common parts between multiple verification paths, effectively identifying and eliminating redundant nodes in the verification path, achieving extreme compression of the verification path and eliminating data redundancy. The structured batch proof generated based on the witness tree and collision tree not only contains the minimum set of nodes required for verification but also retains path reconstruction capabilities through structural information. Therefore, while ensuring verification integrity, it significantly improves the transmission efficiency and computational performance of data verification, reduces communication overhead and computational resource consumption, and enhances the generation and verification efficiency of data proofs.

[0116] Please see Figure 3 , Figure 3 This is a schematic diagram of the current embodiment of a Merkle batch proof generation device provided in this application. The Merkle batch proof generation device is used to execute the aforementioned Merkle batch proof generation method.

[0117] like Figure 3 As shown, the Merkle batch proof generation device 200 includes: a request receiving module 201, a witness tree construction module 202, a collision tree construction module 203, and a batch proof generation module 204.

[0118] The request receiving module 201 is used to receive batch query requests, wherein the batch query requests contain index information of at least one data item to be proved; Witness tree construction module 202 is used to locate the target leaf node corresponding to the index information in the pre-built hash Merkle tree and construct the witness tree; The collision tree construction module 203 is used to traverse the witness tree, identify the shared sub-paths of all branched sub-paths, and merge the shared sub-paths to construct the collision tree; The batch proof generation module 204 is used to generate structured batch proofs based on the witness tree and the collision tree.

[0119] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the device and each module described above can be referred to the corresponding process in the aforementioned Merkle batch proof generation method embodiment, and will not be repeated here.

[0120] The apparatus provided in the above embodiments can be implemented as a computer program, which can be used in, for example... Figure 4 It runs on the computer device shown.

[0121] Please see Figure 4 , Figure 4 This is a schematic block diagram illustrating the structure of a computer device according to an embodiment of this application. The computer device may be a server.

[0122] See Figure 4 The computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0123] Non-volatile storage media can store operating systems and computer programs. These computer programs include program instructions that, when executed, cause the processor to perform any Merkle batch proof generation method.

[0124] The processor provides computing and control capabilities, supporting the operation of the entire computer device.

[0125] Internal memory provides an environment for the execution of computer programs in non-volatile storage media, which, when executed by a processor, enable the processor to perform any Merkle batch proof generation method.

[0126] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0127] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0128] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps: Receive a batch query request, wherein the batch query request contains index information of at least one data item to be proved; Locate the target leaf node corresponding to the index information in the pre-built hash Merkle tree, and construct the witness tree; Traverse the witness tree, identify the shared sub-paths of all branching sub-paths, and merge the shared sub-paths to construct a collision tree; Based on the witness tree and the collision tree, a structured batch proof is generated.

[0129] The embodiments of this application also provide a computer-readable storage medium storing a computer program, the computer program including program instructions, and the processor executing the program instructions to implement any of the Merkle batch proof generation methods provided in the embodiments of this application.

[0130] The computer-readable storage medium may be an internal storage unit of the computer device described in the foregoing embodiments, such as the hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, SmartMediaCard (SMC), SecureDigital (SD) card, or FlashCard equipped on the computer device.

[0131] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A Merkle batch proof generation method, characterized in that, The method includes: Receive a batch query request, wherein the batch query request contains index information of at least one data item to be proved; Locate the target leaf node corresponding to the index information in the pre-built hash Merkle tree, and construct the witness tree; Traverse the witness tree, identify the shared sub-paths of all branching sub-paths, and merge the shared sub-paths to construct a collision tree; Based on the witness tree and the collision tree, a structured batch proof is generated.

2. The Merkle batch proof generation method according to claim 1, characterized in that, The process of traversing the witness tree, identifying shared sub-paths of all branching sub-paths, and merging the shared sub-paths to construct a collision tree includes: Starting from the leaf node of the witness tree, traverse upwards layer by layer until the root node of the witness tree; For each internal node in the witness tree, check whether the internal node has a branching sub-path; If the internal node has branched sub-paths, analyze the shared sub-paths of each branched sub-path; The shared sub-paths of each of the branched sub-paths are merged to obtain the collision tree.

3. The Merkle batch proof generation method according to claim 1, characterized in that, The step of locating the target leaf node corresponding to the index information in the pre-constructed hash Merkle tree and constructing the witness tree includes: Starting from the target leaf node corresponding to the index information, traverse the Merkle tree layer by layer upwards until the root node, and determine all sibling nodes on the path from the target leaf node to the root node; The sibling nodes are organized into subtrees according to the tree structure of the Merkle tree to obtain the witness tree.

4. The Merkle batch proof generation method according to claim 1, characterized in that, The method further includes: When the bottom leaf node of the Merkle tree is modified, identify the node to be updated that has a data association with the bottom leaf node; Calculate the update hash value of the node to be updated; The update hash value is applied to the node to be updated in the Merkle tree to obtain the updated Merkle tree; Based on the updated Merkle tree, the hash dependency graph is updated to obtain an updated hash dependency graph, so that the hash values ​​of the Merkle tree and the hash dependency graph are consistent.

5. The Merkle batch proof generation method according to claim 4, characterized in that, After updating the hash dependency graph based on the updated Merkle tree to obtain the updated hash dependency graph, the process further includes: Based on the updated Merkle tree and the hash dependency graph, the witness tree and the collision tree are reconstructed. Based on the reconstructed witness tree and the updated collision tree, an updated structured batch proof is generated.

6. The Merkle batch proof generation method according to claim 1, characterized in that, The generation of structured batch proofs based on the witness tree and the collision tree includes: Extract the hash values ​​of all nodes in the collision tree to obtain the first data set; Extract the structured information from the witness tree to obtain a second data set, wherein the structured information includes the parent-child relationship between leaf nodes and the position of the branch node of the branch sub-path; The first data set and the second data set are combined to generate the structured batch proof.

7. The Merkle batch proof generation method according to claim 1, characterized in that, After generating structured batch proofs based on the witness tree and the collision tree, the process further includes: Based on the structured batch proof, the data verification path is reconstructed for each of the data items to be verified using path reconstruction auxiliary information; Starting from the data item to be verified, calculate the hash value layer by layer upwards along the data verification path to obtain the root hash; The calculated root hash is compared with the trusted root hash to obtain the verification result; If the verification result is a verification failure, the witness tree and the collision tree are reconstructed, and the structured batch proof is regenerated based on the reconstructed witness tree and the collision tree.

8. A Merkle batch proof generation device, characterized in that, The Merkle batch proof generation device includes: A request receiving module is used to receive batch query requests, wherein the batch query request contains index information of at least one data item to be proved; The witness tree construction module is used to locate the target leaf node corresponding to the index information in the pre-built hash Merkle tree and construct the witness tree; The collision tree construction module is used to traverse the witness tree, identify the shared sub-paths of all branched sub-paths, and merge the shared sub-paths to construct the collision tree; The batch proof generation module is used to generate structured batch proofs based on the witness tree and the collision tree.

9. A computer device, characterized in that, The computer device includes a processor, a memory, and a computer program stored in the memory and executable by the processor, wherein when the computer program is executed by the processor, it implements the steps of the Merkle batch proof generation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the Merkle batch proof generation method as described in any one of claims 1 to 7.

Images