A spatio-temporal keyword blockchain query method based on hierarchical merkle tree

Abstract

This invention provides a spatiotemporal keyword blockchain query method based on hierarchical Merkle trees, comprising the following steps: improving the block header; constructing a Merkle BCK-tree; constructing a Merkle TBK-tree; constructing a Merkle PKR-tree and inserting data into it; filtering queries and verifying results based on spatial and keyword attribute constraints; filtering queries and verifying results based on temporal attribute constraints; and achieving accurate transaction querying and verification. The beneficial effects of this invention are: improving the block header enables the blockchain to support efficient management of spatiotemporal keyword data, including effective storage and efficient querying of spatiotemporal keyword data; to achieve efficient querying, this invention fully considers the filtering mechanism, utilizing a two-layer filtering index to greatly improve the search efficiency of spatiotemporal keyword data across multiple blockchains; to ensure the correctness of query results, this invention uses a method combining Merkle trees with spatial and temporal indexing mechanisms to construct a verifiable index structure, ensuring the correctness and completeness of query results.

Description

Technical Field

[0001] This invention belongs to the field of blockchain, and in particular relates to a spatiotemporal keyword blockchain query method based on hierarchical Merkle trees. Background Technology

[0002] Blockchain is essentially a decentralized, distributed database that supports reliable and secure transaction records. It has been widely applied in the financial sector to address issues such as vulnerability to attacks, insecure transaction storage, and low system efficiency in traditional centralized network systems. Today, blockchain is increasingly demonstrating its applicability in spatiotemporal data management. For example, in the scenario of spatiotemporal keyword blockchain data management for parking violation detection, data security requirements are extremely high, necessitating the writing of continuously updated data to the blockchain to ensure that parking information is not tampered with. Compared to the transaction data currently supported by financial blockchains, the spatiotemporal keyword feature data of these moving objects exhibits a high growth rate; therefore, querying movement information from such a massive blockchain network is a significant challenge.

[0003] In existing technologies, a Block-DAG (Directed Acyclic Graph) structure is used to improve transaction throughput. To enable blockchain to support efficient storage and fast query processing of spatiotemporal data, this research improves the block header, including (i) adding start and end times of transactions to the block header and performing time range queries through breadth-first traversal of the block header; and (ii) improving the Merkle KD-tree to create a spatial index in the block header for spatial range queries. However, due to the lack of a verifiable time search index, the filtering effect of breadth-first traversal is not ideal. Furthermore, existing technologies also introduce a cryptographically signed spatial index data structure, Merkel Block Space Index (BSI), into the block header to achieve fast queries on spatial constraints. For time constraints, Temporal Graph Search (TGS) is used to perform breadth-first traversal on the block DAG; this structure is called TGS-BSI. Additionally, existing technologies also introduce a Merkle Patricia-trie (MPT) into the block header to manage accounts and track their spatial location. This work enriches the understanding of various mainstream query types, such as bounded k-nearest neighbors and sphere queries, and expands research on spatial and temporal range searches. However, it still does not consider verifiable temporal search indexes.

[0004] Therefore, while existing technologies ensure the effective storage and retrieval of spatiotemporal data in the blockchain, they lack management of keyword attributes, failing to meet requirements in scenarios with spatiotemporal keyword queries. Furthermore, existing technologies do not consider hierarchical verifiable filtering index structures, resulting in low query efficiency. Therefore, this application improves the block header to ensure the blockchain supports the storage of spatiotemporal keyword transactions and proposes a blockchain query method based on hierarchical Merkle trees. This method utilizes the characteristics of Merkle trees to construct verifiable index structures at the "inter-chain," "inter-block," and "intra-block" levels to improve query efficiency. Summary of the Invention

[0005] In view of this, the present invention aims to propose a spatiotemporal keyword blockchain query method based on hierarchical Merkle trees. In order to address the current blockchain's inability to simultaneously support the management of spatiotemporal attribute and keyword attribute data, the block header is improved. To improve the query efficiency of the blockchain, verifiable index structures are constructed at the "inter-chain", "inter-block", and "intra-block" levels, respectively, thereby improving query efficiency and ensuring the integrity of query results.

[0006] To achieve the above objectives, the technical solution of the present invention is implemented as follows:

[0007] A spatiotemporal keyword blockchain query method based on hierarchical Merkle trees includes the following steps:

[0008] S1. Improve the block header so that the blockchain can simultaneously support the effective storage and retrieval of time, space and keyword attribute data;

[0009] S2. Use the K-means algorithm to cluster bnodes to construct the Merkle BCK-tree, an inter-chain verifiable index;

[0010] S3, blockchain bnode full nodes use the start and end times in blocks to build a Merkle TBK-tree, an inter-block verifiable index;

[0011] S4. Construct a Merkle PKR-tree and insert the spatiotemporal keyword data monitored by the bnode into the Merkle PKR-tree tree index structure;

[0012] S5. Implement filtering queries and result validation based on spatial and keyword attribute constraints using Merkle BCK-tree;

[0013] S6. Implement filtering queries and result validation based on time attribute constraints using Merkle TBK-tree;

[0014] S7. Use Merkle PKR-tree to query and verify precise transactions.

[0015] Furthermore, in step S1, the block header is improved to enable the blockchain to simultaneously support the efficient storage and retrieval of time, space, and keyword attribute data, including:

[0016] Adding a spatial attribute field (Minimum Bounding Rectangle), a time attribute field, a keyword attribute field, and the root node of a Merkle PKR-tree to the block header enables the blockchain to simultaneously support the management of spatial, time, and keyword attribute data.

[0017] Furthermore, in step S2, the K-means algorithm is used to cluster the bnodes to construct the Merkle BCK-tree, an inter-chain verifiable index.

[0018] The blockchain network includes bnode nodes for monitoring transaction information and trusted snode nodes with high-performance storage and computing capabilities for building and storing the Merkle BCK-tree. The snode nodes cluster the bnode nodes using spatial and key attributes and construct the Merkle BCK-tree, as follows:

[0019] S21, Selection One bnode node is used as the initial cluster center;

[0020] S22. Calculate the distance between all bnode nodes and the cluster center. When the distance between a bnode node and a cluster center is the smallest, assign it to that cluster.

[0021] S23. Adjust and update the cluster centers until they no longer change; at this point, the clustering process terminates; because before clustering, the number of bnode nodes was greater than that of other nodes. Much larger, of which It is the maximum number of child nodes of a Merkle BCK-tree node in the network, so ultimately, the bnode node is assigned to a unique cluster;

[0022] S24. For each bnode cluster, iterate through and calculate the number of bnode nodes contained in each cluster, denoted as . ;

[0023] like satisfy Set the cluster as a leaf node of the Merkle BCK-tree and record a summary of the space and key of the leaf node;

[0024] like Not satisfied Then, the algorithm for constructing a MerkleBCK-tree is recursively called on the cluster to cluster the bnode nodes in the cluster;

[0025] Record the child nodes of the root node for each cluster node, and record the spatial and keyword summaries until the traversal and judgment of the clusters generated by each clustering are completed.

[0026] Furthermore, in step S3, the blockchain bnode full node constructs an inter-block verifiable index, the Merkle TBK-tree, using the start and end times in the blocks. The construction of the Merkle TBK-tree includes:

[0027] The entire time series is divided into n granularities. The middle granularity is taken as the root node to construct a Merkle TBK-tree. The time granularity of the left child node of each non-leaf node is smaller than that of the non-leaf node, and the time granularity of the right child node is larger than that of the non-leaf node.

[0028] Each non-leaf node contains spatial, temporal, and key information from its child nodes;

[0029] Each leaf node in a Merkle TBK-tree contains multiple blocks and summarizes the spatial, temporal, and keyword information of the transaction objects within them.

[0030] Furthermore, in step S4, a Merkle PKR-tree is constructed and the spatiotemporal keyword data monitored by the bnode is inserted into the Merkle PKR-tree tree index structure, wherein,

[0031] The Merkle PKR-tree is constructed by light node miners and is used to manage and organize transaction information monitored by bnodes. Furthermore, the Merkle PKR-tree is a tree-like index structure that combines Merkle-tree and MB-tree. The key-value and hash value of the Merkle PKR-tree are integrated to construct the Merkle PKR-tree.

[0032] (1)

[0033] (2)

[0034] in, This refers to the time division of the node transaction list in the Merkle PKR-tree. Indicates in Hilbert curve values ​​for the location of the trading object in the middle. It is the encoded value of the key of the transaction object;

[0035] After constructing the Merkle PKR-tree, transactions with spatiotemporal key attributes detected by the bnode are inserted into the Merkle PKR-tree tree index structure within the block.

[0036] Furthermore, in step S5, filtering queries and result validation based on spatial and keyword attribute constraints are implemented using the Merkle BCK-tree, including:

[0037] The client sends a query request. ,in Indicates the spatial range of the query. This represents a keyword attribute field;

[0038] When filtering queries, we start from the root node of the Merkle BCK-tree stored on the snode. If the intersection of the space of the root node and the space of the query constraint is not empty, and the key of the root node is related to the key of the query constraint, then we continue to judge the child nodes of the root node. Otherwise, its child nodes will not be accessed until the set of leaf nodes that intersect with the space and key of the query constraint is found.

[0039] The space, keywords, and summary information of the pruned blocks during the entire search process are stored in the next valid result area block and added as a Validation Object (VO), which is returned along with the query results;

[0040] During result verification, the client uses VO to recalculate the spatial and key digests of the Merkle BCK-tree root node and compares them with the Merkle BCK-tree root node signature stored in the snode. If they match, the query result is correct; otherwise, the query result is incorrect.

[0041] Furthermore, in step S6, filtering queries and result validation based on time attribute constraints are implemented using a Merkle TBK-tree, including:

[0042] The client sends a query request. ,in Represents the query time;

[0043] When filtering queries, the query first starts from the root node of the Merkle TBK-tree stored on the trusted full node bnode. When the time and space keywords of the query constraint overlap with the time and space keywords of the Merkle TBK-tree root node, the query continues to evaluate the child nodes of the root node until a set of leaf nodes that intersects with the space, time and keywords of the query constraint is found. Otherwise, the time, space and keyword summary values ​​of the child nodes of the root node will be added as VO to the block and returned along with the query results.

[0044] During result verification, the client recalculates the spatial, temporal, and key digests of the Merkle TBK-tree root based on the returned query results and VO, and compares and verifies them with the spatial, temporal, and key signatures of the Merkle TBK-tree root stored in the trusted bnode full node.

[0045] Furthermore, in step S7, the Merkle PKR-tree is used to query and verify precise transactions, including:

[0046] Range query: First, calculate the encoded value of the keyword to be queried. Then, for each query time partition, obtain the range of key values ​​for the query constraint by integrating a set of one-dimensional Hilbert value intervals and the binary value of the keyword encoding.

[0047] For each node in the Merkle PKR-tree, its node key value range is compared with the key value range of the query constraint, and the node is pruned until a leaf node that meets the query requirements is found. At the same time, the pruned node is added as a VO and returned along with the query result.

[0048] During verification, the client recalculates the digest of the Merkle PKR-tree root based on the returned query results and VO, and compares it with the Merkle PKR-tree root signature stored in the trusted bnode light node for verification.

[0049] KNN query: from the initial search radius Start by expanding incrementally. This continues until the KNN query result is returned; Both increments are set to ,in Is it a query position and its first The estimated distance between the nearest locations; The expression is Equation (3), and Equation (3) is:

[0050] (3)

[0051] in It represents the total number of positions within a unit of space;

[0052] When answering a KNN query, each time partition of and Values ​​are integrated to form a search space; the search space is represented as follows: Assuming the search requires The range of rounds is expanded to include each round. , respectively and Indicates the start and end points of the corresponding one-dimensional search interval;

[0053] Explore the search order in the search space, because The smaller, The shorter the distance to the query location, therefore For smaller Prioritize searching;

[0054] KNN queries also return query results and VOs; for KNN result verification, the client recalculates the key-value hash of the root based on the query results and VOs, and verifies it based on the decrypted root signature.

[0055] Compared with existing technologies, the spatiotemporal keyword blockchain query method based on hierarchical Merkle trees described in this invention has the following advantages:

[0056] The spatiotemporal keyword blockchain query method based on hierarchical Merkle trees described in this invention improves the block header, enabling the blockchain to support efficient management of spatiotemporal keyword data, including effective storage and efficient querying of spatiotemporal keyword data. To achieve efficient querying, this invention fully considers the filtering mechanism, using a two-layer filtering index to greatly improve the search efficiency of spatiotemporal keyword data in multiple blockchains. To ensure the correctness of query results, this invention uses a method combining Merkle trees with spatial and temporal indexing mechanisms to construct a verifiable index structure, which can ensure the correctness and completeness of query results. Attached Figure Description

[0057] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0058] Figure 1 This is a schematic diagram of the improved block header structure described in an embodiment of the present invention;

[0059] Figure 2 This is a schematic diagram of the blockchain regulatory area partitioning and Merkle BCK-tree index structure as described in an embodiment of the present invention;

[0060] Figure 3 This is a schematic diagram of the Merkle TBK-tree index structure according to an embodiment of the present invention;

[0061] Figure 4 This is a schematic diagram of a MerklePKR-tree node based on a combination of Merkle-tree and MB-tree, as described in an embodiment of the present invention.

[0062] Figure 5This is a schematic diagram of the spatiotemporal keyword blockchain query framework using a two-layer filtering and one-layer precise query structure as described in an embodiment of the present invention;

[0063] Figure 6 This is a schematic diagram showing the change curves of the query time of the present invention and existing methods under different conditions, such as changing the block size, changing the number of transactions, changing the query time range, and changing the k value. Detailed Implementation

[0064] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0065] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0066] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0067] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0068] Definitions:

[0069] Inter-chain: Inter-chain refers to the relationship between different blockchains. In blockchain technology, each blockchain is an independent distributed ledger used to record specific types of transactions or data. Inter-chain technology involves establishing connections or communication mechanisms between different blockchains so that data can be exchanged across different blockchains.

[0070] Inter-block: Inter-block refers to the relationship between different blocks within the same blockchain. A block is the basic unit in a blockchain; they are linked together to form a blockchain.

[0071] Within a block: This refers to the data relationships within a single block. A block consists of a block header and a block body, where the block body contains a list of transactions. The block header contains transaction-related information and a set of hash values ​​used to reference other block headers. It also maintains the root node of a Merkle PKR-tree spatial index tree.

[0072] like Figure 1 As shown, this method first improves the block header of the Block-DAG block, enabling the blockchain to simultaneously support efficient storage and querying of spatial, temporal, and keyword attribute data. It then utilizes hierarchical, verifiable index structures, Merkle BCK-tree and Merkle TBK-tree, to progressively filter by "spatial," "keyword," and "time" attributes. Finally, it achieves precise querying within the block using Merkle PKR-tree while ensuring query completeness. Figure 2-4 These are schematic diagrams of the verifiable index structures. A detailed query framework diagram is shown below. Figure 5 As shown, the system architecture of the present invention, which involves two layers of filtering and one layer of querying, consists of three parts:

[0073] (i) Spatial and Keyword-Based Local Blockchain Filtering: This strategy simultaneously locates and stores relevant transaction objects within a local blockchain based on spatial keyword constraints. This reduces the burden on blockchain nodes, requiring them to monitor only valuable data while storing block information for a small number of nodes within a reduced search space. Since the location of bnodes and the spatial keyword information of the transactions they monitor do not change over time, filtering can be performed on any timestamp before bnodes are exhausted.

[0074] (ii) Block spatiotemporal keyword filtering in local blockchains: Inefficient blocks need to be further filtered because the returned local blockchains may still contain transaction blocks that are incompatible with spatiotemporal keyword query constraints;

[0075] (iii) Querying transaction objects with precise spatiotemporal keywords in the block: Further filter inefficient transaction objects from the returned blocks to ensure that the returned transaction objects meet the spatiotemporal keyword query constraints.

[0076] This method improves the block header of Block-DAG, enabling the blockchain to simultaneously support efficient storage and querying of spatial, temporal, and keyword attribute data. It utilizes a hierarchical, verifiable index structure to progressively filter by "spatial," "keyword," and "time" attributes, thereby improving query efficiency and ensuring query integrity. The method specifically includes the following steps:

[0077] Step 1: Improve the block header so that the blockchain can simultaneously support the effective storage and retrieval of time, space and keyword attribute data.

[0078] Step one specifically involves adding the spatial attribute field Minimum BoundingRectangle (MBR), the time attribute field (start and end times of the transaction list within the block), the keyword attribute field Keyword, and the root node of the Merkle PKR-tree to the block header, enabling the blockchain to simultaneously support the management of spatial, time, and keyword attribute data.

[0079] Step 2: Use the K-means algorithm to cluster bnodes to construct the Merkle BCK-tree, an inter-chain verifiable index.

[0080] The blockchain network includes resource-constrained bnode nodes for monitoring transaction information and trusted snode nodes with high-performance storage and computing capabilities for building and storing the Merkle BCK-tree. The snodes cluster the blockchain nodes (bnodes) using spatial and key attributes and construct the Merkle BCK-tree, with the specific steps as follows:

[0081] (2.1) Selection One bnode node is used as the initial cluster center.

[0082] (2.2) Calculate the distance between all bnodes and the cluster center. When the distance between a bnode and a cluster center is the smallest, assign it to that cluster.

[0083] (2.3) Adjust and update the cluster centers until they no longer change. At this point, the clustering process terminates. Typically, before clustering, the number of bnodes is greater than that of the cluster centers. Much larger, of which This is the maximum number of child nodes of a Merkle BCK-tree node in the network. Ultimately, each bnode node is assigned to a unique cluster.

[0084] (2.4) For each bnode cluster, iterate through and calculate the number of bnodes contained in each cluster, denoted as . ,like satisfy Set this cluster as a leaf node of the Merkle BCK-tree, and record a summary of the space and key of this leaf node. If... Not satisfied Then, the algorithm for constructing the Merkle BCK-tree is recursively called on the cluster to cluster the bnode nodes in the cluster and record (i) the child nodes of the root node, (ii) the spatial and key summaries, until the traversal and judgment of the clusters generated by each clustering are completed.

[0085] Step 3: The blockchain bnode full node uses the start and end times in the blocks to build a Merkle TBK-tree, a verifiable index between blocks.

[0086] The construction of a Merkle TBK-tree involves dividing the entire time series into n granularities, using the middle granularity as the root node to construct the Merkle TBK-tree. The time granularity of the left child node of each non-leaf node is smaller than that of the non-leaf node, while the time granularity of the right child node is larger than that of the non-leaf node. Each non-leaf node summarizes the spatial, temporal, and key information of its child nodes. Each leaf node in the Merkle TBK-tree contains multiple blocks and summarizes the spatial, temporal, and key information of the transaction objects within them.

[0087] Step 4: Construct a Merkle PKR-tree and insert the spatiotemporal keyword data monitored by the bnode into the Merkle PKR-tree tree index structure.

[0088] The Merkle PKR-tree is constructed by light node miners to manage and organize transaction information monitored by bnodes. The Merkle PKR-tree is a tree-like index structure combining Merkle-tree and MB-tree. The key-value pairs (Equation (1)) and hash values ​​(Equation (2)) of the Merkle PKR-tree are... Integrate.

[0089] (1)

[0090] (2)

[0091] in, This refers to the time division of the node transaction list in the Merkle PKR-tree. Indicates in Hilbert curve values ​​for the location of the trading object in the middle. This is the encoded value of the transaction object's key. Use Transaction objects with similar spatial and temporal keywords tend to be stored in a single index node. The Merkle PKR-tree works similarly to the MB-tree, where nodes are expanded by the hash value associated with each pointer item. The hash value associated with leaf nodes is calculated based on database records, while the hash value associated with non-leaf nodes is calculated by combining the hash values ​​of their child nodes.

[0092] After constructing the Merkle PKR-tree, transactions with spatiotemporal key attributes detected by the bnode are inserted into the Merkle PKR-tree tree index structure within the block.

[0093] Step 5: Implement filtering queries and result validation based on spatial and keyword attribute constraints using Merkle BCK-tree.

[0094] Step five specifically involves the client sending a query request. ,in Indicates the spatial range of the query. This represents the query keywords. The query filtering begins with the Merkle BCK-tree root node stored in the snode. If the intersection of the root node's space and the query constraint's space is not empty, and the root node's keyword is relevant to the query constraint's keyword, then the root node's child nodes are evaluated. Otherwise, its child nodes are not visited, until a set of leaf nodes intersects with the query constraint's space and keyword is found. During the entire search process, the space, keywords, and their summary information of pruned blocks are stored in the next valid result area block and added as a Validation Object (VO), returned along with the query results. The validation process is similar to the query process. The client uses the VO to recalculate the Merkle BCK-tree root node's space and keyword summary and compares it with the Merkle BCK-tree root node signature stored in the snode. If they match, the query result is correct; otherwise, the query result is incorrect.

[0095] Step 6: Implement filtering queries and result validation based on time attribute constraints using Merkle TBK-tree.

[0096] Step six specifically involves the client sending a query request. ,in This represents the query time. The query begins with the Merkle TBK-tree root node stored on the trusted full node (bnode). If the time and spatial keywords of the query constraint overlap with the time and spatial keywords of the Merkle TBK-tree root node, the query continues to evaluate the child nodes of that root node until a set of leaf nodes that intersects with both the space, time, and keyword of the query constraint is found. Otherwise, the time, space, and keyword digest values ​​of the root node's child nodes are added as VOs to the block and returned along with the query results. Similar to the root digest calculation process of the Merkle BCK-tree, to verify the results, the client recalculates the space, time, and keyword digests of the Merkle TBK-tree root based on the returned query results and VOs, and compares them with the space, time, and keyword signatures of the Merkle TBK-tree root stored on the trusted full node (bnode).

[0097] Step 7: Use the Merkle PKR-tree to query and verify precise transactions.

[0098] Step seven specifically includes:

[0099] (i) Range Query: First, the encoded value of the keyword to be queried is calculated. Then, for each query time partition, the key value range of the query constraint is obtained by integrating a set of one-dimensional Hilbert value ranges and the binary value of the keyword encoding. For each node of the Merkle PKR-tree, its node key value range is compared with the key value range of the query constraint, and pruning is performed until a leaf node that meets the query requirements is found. At the same time, the pruned node is added as a VO and returned along with the query result. Similar to the root digest calculation process of Merkle BCK-tree and Merkle TBK-tree, in order to verify the results, the client recalculates the digest of the Merkle PKR-tree root based on the returned query result and VO, and compares it with the Merkle PKR-tree root signature stored in the trusted bnode light node for verification.

[0100] (ii) KNN query: This is a progressively expanding range query that starts from the initial search radius. Start by expanding incrementally. This continues until the KNN query result is returned. Both increments are set to ,in (As shown in equation (3), where) (This is the total number of positions in a unit of space) is the query position and its number. The estimated distance between the nearest locations.

[0101] (3)

[0102] To answer KNN queries, each time partition of and Values ​​are integrated to form a search space. The search space is represented as follows: Assuming the search requires... The range of rounds is expanded to include each round. We used respectively and This represents the start and end points of the corresponding one-dimensional search interval. We also explored the search order within the search space to obtain query results as quickly as possible. For the search space given above, The smaller, The shorter the distance to the query location, therefore For smaller The search will be prioritized. KNN queries also return query results and VOs. For KNN result verification, the client recalculates the key-value hash of the root based on the query results and VO, and verifies it based on the decrypted root signature. To ensure the correctness of the KNN result, it is necessary to check whether the distance to the k-th object is no worse than the distances to all other objects in the VO.

[0103] The beneficial effects of this invention are as follows:

[0104] 1. Improve the block header to enable the blockchain to support efficient management of spatiotemporal keyword data, including effective storage and efficient querying of spatiotemporal keyword data.

[0105] 2. In order to achieve efficient querying, this invention fully considers the filtering mechanism and uses two layers of filtering indexes to greatly improve the search efficiency of spatiotemporal keyword data in multiple blockchains.

[0106] 3. To ensure the correctness of query results, this invention uses a combination of Merkle trees and spatial and temporal indexing mechanisms to construct a verifiable index structure, which can ensure the correctness and completeness of query results.

[0107] Example 1

[0108] This embodiment takes querying spatiotemporal keyword transactions in a blockchain as an example. Melbourne parking violation spatiotemporal keyword data is selected as the spatiotemporal keyword transaction data and stored in a Block-DAG. This dataset contains 342,850 data entries. For experimental purposes, the dataset was divided into five parts, each containing 50,000, 100,000, 150,000, 200,000, and 250,000 data entries respectively. A blockchain spatiotemporal keyword query method based on a hierarchical Merkle tree includes the following steps:

[0109] Step 1: Improve the block header so that the blockchain can simultaneously support the effective storage and retrieval of time, space and keyword attribute data.

[0110] Step one specifically involves: Figure 1 As shown, the block header is augmented with a spatial attribute field (Minimum Bounding Rectangle (MBR), a time attribute field (start and end times of the transaction list within the block), a keyword attribute field (Keyword), and the root node of a Merkle PKR-tree, enabling the blockchain to simultaneously support the management of spatial, time, and keyword attribute data.

[0111] Step 2: Use the K-means algorithm to cluster bnodes to construct the Merkle BCK-tree, an inter-chain verifiable index.

[0112] The blockchain network includes resource-constrained bnode nodes for monitoring transaction information and trusted snode nodes with high-performance storage and computing capabilities for building and storing the Merkle BCK-tree. The snodes cluster the blockchain nodes (bnodes) using spatial and key attributes and construct the Merkle BCK-tree, with the specific steps as follows:

[0113] (2.1) Selection Each bnode node serves as the initial cluster center, such as Figure 2 As shown in (a), k is set to 2.

[0114] (2.2) Calculate the distance between all bnodes and the cluster center. When the distance between a bnode and a cluster center is the smallest, assign it to that cluster.

[0115] (2.3) Adjust and update the cluster centers until they no longer change. At this point, the clustering process terminates. Typically, before clustering, the number of bnodes is greater than that of the cluster centers. Much larger, of which It is the maximum number of child nodes of a Merkle BCK-tree node in the network, such as Figure 2 As shown in (b), The value is 4. Ultimately, the bnode node is assigned to a single cluster.

[0116] (2.4) For each bnode cluster, iterate through and calculate the number of bnodes contained in each cluster, denoted as . ,like satisfy Set this cluster as a leaf node of the Merkle BCK-tree, and record a summary of the space and key of this leaf node. If... Not satisfied Then, the algorithm for constructing a Merkle BCK-tree is recursively called on the cluster to cluster the bnode nodes in the cluster, and (i) the child nodes of the root node, (ii) the spatial and key summaries are recorded, until the traversal and judgment of the clusters generated by each clustering are completed. Figure 2 As shown, the root node of the Merkle BCK-tree is The left subtree is The right subtree is . The left and right subtrees are respectively and . The left and right subtrees are respectively and ,and The left and right subtrees are respectively and .

[0117] Step 3: The blockchain bnode full node uses the start and end times in the blocks to build a Merkle TBK-tree, a verifiable index between blocks.

[0118] The construction of the Merkle TBK-tree is as follows: The entire time series is divided into n granularities. Since the time attribute of the dataset is from April 1, 2016 to October 1, 2016, n equals 7. The middle granularity (corresponding to July in the dataset) is taken as the root node to construct the Merkle TBK-tree. The time granularity of the left child node of each non-leaf node is smaller than that of the non-leaf node (corresponding to April, May, and June in the dataset), and the time granularity of the right child node is larger than that of the non-leaf node (corresponding to August, September, and October in the dataset). Each non-leaf node summarizes the spatial, temporal, and keyword information of its child nodes. Each leaf node in the Merkle TBK-tree contains multiple blocks and summarizes the spatial, temporal, and keyword information of the transaction objects within them.

[0119] Step 4: Construct a Merkle PKR-tree and insert the spatiotemporal keyword data monitored by the bnode into the Merkle PKR-tree tree index structure.

[0120] The Merkle PKR-tree is constructed by light node miners to manage and organize transaction information monitored by bnodes. The Merkle PKR-tree is a tree-like index structure combining Merkle-tree and MB-tree. The key-value pairs (Equation (1)) and hash values ​​(Equation (2)) of the Merkle PKR-tree are... Integrate.

[0121] (1)

[0122] (2)

[0123] in, This refers to the time division of the node transaction list in the Merkle PKR-tree. Indicates in Hilbert curve values ​​for the location of the trading object in the middle. This is the encoded value of the transaction object's key. Use Transaction objects with similar spatial and temporal keywords tend to be stored in a single index node. The Merkle PKR-tree works similarly to the MB-tree, where nodes are expanded by the hash value associated with each pointer item. The hash value associated with leaf nodes is calculated based on database records, while the hash value associated with non-leaf nodes is calculated by combining the hash values ​​of their child nodes.

[0124] After constructing the Merkle PKR-tree, transactions with spatiotemporal key attributes detected by the bnode are inserted into the Merkle PKR-tree tree index structure within the block.

[0125] Step 5: Implement filtering queries and result validation based on spatial and keyword attribute constraints using Merkle BCK-tree.

[0126] Step five specifically involves the client sending a query request. ,in Indicates the spatial range of the query. This represents the keywords used in the query. (Corresponding dataset) The range values ​​are (-37.82, 144.94) and (-37.81, 144.95), keywords. The value is Docklands. The filtering query starts from the Merkle BCK-tree root node stored on the snode. If the intersection of the root node's space and the query constraint's space is not empty, and the root node's key is relevant to the query constraint's key, then the root node's child nodes are evaluated. Otherwise, its child nodes are not visited, until a set of leaf nodes intersects with the query constraint's space and key is found. During the entire search process, the space, key, and summary information of pruned blocks are stored in the next valid result area block, such as... Figure 2 As shown in (b), Space, keywords, and their summary information are stored middle, and Space, keywords, and their summary information are stored The snode is added as a Validation Object (VO) and returned along with the query results. The validation process is similar to the query process: the client uses the VO to recalculate the spatial and key digests of the Merkle BCK-tree root node and compares them with the Merkle BCK-tree root node signature stored in the snode. If they match, the query result is correct; otherwise, the query result is incorrect.

[0127] Step 6: Implement filtering queries and result validation based on time attribute constraints using Merkle TBK-tree.

[0128] Step six specifically involves the client sending a query request. ,in This represents the query time, corresponding to the query time of the dataset. The value is September 1, 2016. The query begins with the Merkle TBK-tree root node stored on the trusted full node (bnode). If the time and space keys of the query constraint overlap with the time and space keys of the Merkle TBK-tree root node, the query continues to evaluate the child nodes of that root node until a set of leaf nodes that intersects with both the space, time, and key keys of the query constraint is found. Otherwise, the time, space, and key digest values ​​of the root node's child nodes are added as VOs to the block and returned along with the query results. Similar to the root digest calculation process of the Merkle BCK-tree, to verify the results, the client recalculates the space, time, and key digests of the Merkle TBK-tree root based on the returned query results and VOs, and compares them with the space, time, and key signatures of the Merkle TBK-tree root stored on the trusted full node (bnode).

[0129] Step 7: Use the Merkle PKR-tree to query and verify precise transactions.

[0130] Step seven specifically includes:

[0131] (i) Range Query: First, the encoded value of the keyword to be queried is calculated. Then, for each query time partition, the key value range of the query constraint is obtained by integrating a set of one-dimensional Hilbert value ranges and the binary value of the keyword encoding. For each node of the Merkle PKR-tree, its node key value range is compared with the key value range of the query constraint, and pruning is performed until a leaf node that meets the query requirements is found. At the same time, the pruned node is added as a VO and returned along with the query result. Similar to the root digest calculation process of Merkle BCK-tree and Merkle TBK-tree, in order to verify the results, the client recalculates the digest of the Merkle PKR-tree root based on the returned query result and VO, and compares it with the Merkle PKR-tree root signature stored in the trusted bnode light node for verification.

[0132] (ii) KNN query: This is a progressively expanding range query that starts from the initial search radius. Start by expanding incrementally. This continues until the KNN query result is returned. Both increments are set to ,in (As shown in equation (3), where) (This is the total number of positions in a unit of space) is the query position and its number. Estimated distance between the nearest locations. (Query in progress) The values ​​were set to 1, 10, 20, 30, and 40 respectively. (Corresponding dataset) The values ​​are 50,000, 100,000, 150,000, 200,000, and 250,000 respectively.

[0133] (3)

[0134] To answer KNN queries, each time partition of and Values ​​are integrated to form a search space. The search space is represented as follows: Assuming the search requires... The range of rounds is expanded to include each round. We used respectively and This represents the start and end points of the corresponding one-dimensional search interval. We also explored the search order within the search space to obtain query results as quickly as possible. For the search space given above, The smaller, The shorter the distance to the query location, therefore For smaller The search will be prioritized. KNN queries also return query results and VOs. For KNN result verification, the client recalculates the key-value hash of the root based on the query results and VO, and verifies it based on the decrypted root signature. To ensure the correctness of the KNN result, it is necessary to check whether the distance to the k-th object is no worse than the distances to all other objects in the VO.

[0135] The comparison method used in this experiment is as follows: BTP represents the method proposed in this invention, which is to use Merkle BCK-tree, Merkle TBK-tree and Merkle PKR-tree to filter and search for spatiotemporal keyword transactions; SCAN represents a scanning method, which first filters transactions from the time aspect and then filters transactions from the space and keyword aspects; InvertedIndex[3] represents a reverse indexing method, which first finds documents containing keyword transactions and then filters the results from the time and space aspects through the scanning method. Here, in order to simplify the query process, the reverse index is used to access the blockchain instead of the server; TGS-BSI represents a method for storing spatiotemporal data based on Block-DAG, which uses Temporal Graph Search (TGS) and Merkle Tree Spatial Index (BSI) Merkle KD-tree to search for spatiotemporal data and uses scanning operations to filter keyword constraints.

[0136] Figure 6 The graph shows the change in query time compared to existing methods under varying block size, number of transactions, query time range, and k value. It can be seen that the method used in this invention is optimal under all changing conditions, thanks to our two-layer filtering index structure design.

[0137] Any aspects not covered in this invention are applicable to existing technologies. The above description is merely a preferred embodiment of this invention and is not intended to limit the invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this invention should be included within the protection scope of this invention.

Claims

1. A spatio-temporal keyword blockchain query method based on hierarchical Merkle tree, characterized in that: Includes the following steps: S1. Improve the block header so that the blockchain can simultaneously support the effective storage and retrieval of time, space and keyword attribute data; S2. Use the K-means algorithm to cluster bnodes to construct the Merkle BCK-tree, an inter-chain verifiable index; S3, blockchain bnode full nodes use the start and end times in blocks to build a Merkle TBK-tree, an inter-block verifiable index; S4. Construct a Merkle PKR-tree and insert the spatiotemporal keyword data monitored by the bnode into the Merkle PKR-tree tree index structure; S5. Implement filtering queries and result validation based on spatial and keyword attribute constraints using Merkle BCK-tree; S6. Implement filtering queries and result validation based on time attribute constraints using Merkle TBK-tree; S7. Use Merkle PKR-tree to query and verify precise transactions; In step S2, the blockchain network includes bnode nodes for monitoring transaction information and trusted snode nodes with high-performance storage and computing capabilities for building and storing the Merkle BCK-tree. The snode nodes cluster the bnode nodes using spatial and key attributes and construct a Merkle BCK-tree; Step S3 includes: The entire time series is divided into x granularities. The middle granularity is taken as the root node to construct a Merkle TBK-tree. The time granularity of the left child node of each non-leaf node is smaller than that of the non-leaf node, and the time granularity of the right child node is larger than that of the non-leaf node. Each non-leaf node contains spatial, temporal, and key information from its child nodes; Each leaf node in a Merkle TBK-tree contains multiple blocks and summarizes the spatial, temporal, and key information of the transaction objects within them; In step S4, the construction of the Merkle PKR-tree is completed by the light node miner, which is used to manage and organize the transaction information monitored by the bnode; and the Merkle PKR-tree is a tree index structure that combines the Merkle-tree and MB-tree. The key value and hash value of the Merkle PKR-tree are integrated to construct the Merkle PKR-tree. （1） （2） in, This refers to the time division of the node transaction list in the Merkle PKR-tree. Indicates in Hilbert curve values ​​for the location of the trading object in the middle. It is the encoded value of the key of the transaction object; After constructing the Merkle PKR-tree, transactions with spatiotemporal key attributes detected by the bnode are inserted into the Merkle PKR-tree tree index structure within the block.

2. The spatiotemporal keyword blockchain query method based on hierarchical Merkle trees according to claim 1, characterized in that: In step S1, the block header is improved to enable the blockchain to simultaneously support the efficient storage and retrieval of time, space, and keyword attribute data, including: Adding a spatial attribute field (Minimum Bounding Rectangle), a time attribute field, a keyword attribute field, and the root node of a Merkle PKR-tree to the block header enables the blockchain to simultaneously support the management of spatial, time, and keyword attribute data.

3. The spatiotemporal keyword blockchain query method based on hierarchical Merkle trees according to claim 1, characterized in that: In step S5, filtering queries and result validation based on spatial and keyword attribute constraints are implemented using the Merkle BCK-tree, including: The client sends a query request. ,in Indicates the spatial range of the query. This represents a keyword attribute field; When filtering queries, we start from the root node of the Merkle BCK-tree stored on the snode. If the intersection of the space of the root node and the space of the query constraint is not empty, and the key of the root node is related to the key of the query constraint, then we continue to judge the child nodes of the root node. Otherwise, its child nodes will not be accessed until the set of leaf nodes that intersect with the space and key of the query constraint is found. The space, keywords, and summary information of the pruned blocks during the entire search process are stored in the next valid result area block and added as a validation object (VO), which is returned along with the query results. During result verification, the client uses VO to recalculate the spatial and key digests of the Merkle BCK-tree root node and compares them with the Merkle BCK-tree root node signature stored in the snode. If they match, the query result is correct; otherwise, the query result is incorrect.

4. The spatiotemporal keyword blockchain query method based on hierarchical Merkle trees according to claim 3, characterized in that: In step S6, filtering queries and result validation based on time attribute constraints are implemented using Merkle TBK-tree, including: The client sends a query request. ,in Represents the query time; When filtering queries, the query first starts from the root node of the Merkle TBK-tree stored on the trusted full node of bnode. When the time and space keywords of the query constraint overlap with the time and space keywords of the Merkle TBK-tree root node, the query continues to evaluate the child nodes of the root node until a set of leaf nodes that intersects with the space, time and keywords of the query constraint is found. Otherwise, the time, space and keyword summary values ​​of the child nodes of the root node will be added as VO to the block and returned along with the query results. During result verification, the client recalculates the spatial, temporal, and key digests of the Merkle TBK-tree root based on the returned query results and VO, and compares and verifies them with the spatial, temporal, and key signatures of the Merkle TBK-tree root stored in the trusted bnode full node.

5. The spatiotemporal keyword blockchain query method based on hierarchical Merkle trees according to claim 4, characterized in that: In step S7, the Merkle PKR-tree is used to query and verify precise transactions, including: Range query: First, calculate the encoded value of the keyword to be queried. Then, for each query time partition, obtain the range of key values ​​for the query constraint by integrating a set of one-dimensional Hilbert value intervals and the binary value of the keyword encoding. For each node in the Merkle PKR-tree, its node key value range is compared with the key value range of the query constraint, and the node is pruned until a leaf node that meets the query requirements is found. At the same time, the pruned node is added as a VO and returned along with the query result. During verification, the client recalculates the digest of the Merkle PKR-tree root based on the returned query results and VO, and compares it with the Merkle PKR-tree root signature stored in the trusted bnode light node for verification. KNN query: from the initial search radius Start by expanding incrementally. This continues until the KNN query result is returned; Both increments are set to ,in Is it a query position and its first The estimated distance between the nearest locations; The expression is Equation (3), and Equation (3) is: （3） in It represents the total number of positions within a unit of space; When answering a KNN query, each time partition of and Values ​​are integrated to form a search space; the search space is represented as follows: Assuming the search requires The range of rounds is expanded to include each round. , respectively and Indicates the start and end points of the corresponding one-dimensional search interval; Explore the search order in the search space, because The smaller, The shorter the distance to the query location, therefore For smaller Prioritize searching; KNN queries also return query results and VOs; for KNN result verification, the client recalculates the key-value hash of the root based on the query results and VOs, and verifies it based on the decrypted root signature.

6. The spatiotemporal keyword blockchain query method based on hierarchical Merkle trees according to claim 1, characterized in that: The specific steps of step S2 are as follows: S21. Select m bnode nodes as the initial cluster centers; S22. Calculate the distance between all bnode nodes and the cluster center. When the distance between a bnode node and a cluster center is the smallest, assign it to that cluster. S23. Adjust and update the cluster centers until they no longer change; at this point, the clustering process terminates; because before clustering, the number of bnode nodes was greater than that of other nodes. Much larger, of which It is the maximum number of child nodes of a Merkle BCK-tree node in the network, so ultimately, the bnode node is assigned to a unique cluster; S24. For each bnode cluster, iterate through and calculate the number of bnode nodes contained in each cluster, denoted as . ; like satisfy Set the cluster as a leaf node of the Merkle BCK-tree and record a summary of the space and key of the leaf node; like Not satisfied Then, the algorithm for constructing a Merkle BCK-tree is recursively called on the cluster to cluster the bnode nodes in the cluster; Record the child nodes of the root node for each cluster node, and record the spatial and keyword summaries until the traversal and judgment of the clusters generated by each clustering are completed.

Images