Index server, user terminal, and transaction data indexing method thereof

Abstract

This invention provides an index server, user terminals, and methods for verifying the completeness of question results using a partial Merkle tree of terminal nodes. [Solution] The index server indexes the 2D location data included in the transaction data using a KdB tree, constructs a partial Merkle tree for a group of terminal nodes using the KdB tree, stores hierarchical hash information based on the partial Merkle tree in each node of the KdB tree, and when it obtains a query related to the location data through the interface module, it searches the KdB tree to find a query result corresponding to the obtained query, generates verification data for verifying the query result found based on the partial Merkle tree and hierarchical hash information, and provides the query result and verification data to the user terminal so that the user terminal can verify the integrity of the query result using the partial Merkle tree and hierarchical hash information.

Description

Technical Field

[0001] The various embodiments disclosed in this document relate to blockchain indexing technology.

Background Art

[0002] Blockchain technology is one of the key technologies of the fourth industrial revolution and has attracted worldwide attention as a method for securely and transparently recording and managing data. A blockchain is a distributed digital ledger technology in which all users participating in a network store data in a decentralized manner, and all records of the data are shared. One of the core features of a blockchain is that once data is recorded, it cannot be modified or deleted, and only new data can be added (append-only). Due to such characteristics, a blockchain guarantees data immutability, integrity, transparency, reliability, etc., and maximizes data security so that the blockchain can be used as a reliable distributed ledger system.

[0003] Blockchain-based services are possible through the search and analysis of blockchain data in response to user queries. However, since the amount of blockchain data continues to increase over time, there is a growing need to efficiently search and analyze large-scale and high-capacity blockchain data. Blockchains such as Bitcoin and Ethereum provide their own search functions for transactions, blocks, and account information using LevelDB, a key infrastructure developed by Google.

Summary of the Invention

Problems to be Solved by the Invention

[0004] By the way, the current blockchain search function provides a limited one-dimensional search, so it has the disadvantage of being inefficient for searching multi-dimensional data.

[0005] Furthermore, blockchain analysis technology has the following limitations. For example, blockchain networks limit transaction performance by duplicating data on all participating nodes. Also, because only basic block transaction access is possible, there are no high-level analytical indexes. Moreover, the search function for stored data is underperforming and the methods of accessing data are limited.

[0006] The various embodiments disclosed herein can provide an index server, a user terminal, and a transaction data indexing method that can index two-dimensional location data included in blockchain transactions using a KdB tree and verify the completeness of query results using a partial Merkle tree of the terminal node. [Means for solving the problem]

[0007] An index server according to one embodiment disclosed herein includes an interface module capable of interfacing with a user terminal; an index DB related to indexing transaction data stored in blocks on a blockchain network; and a processor, wherein the processor indexes two-dimensional location data included in the transaction data using a KdB tree, constructs a partial Merkle tree for a group of terminal nodes using the KdB tree, stores hierarchical hash information based on the partial Merkle tree at each node of the KdB tree, obtains a query related to the location data through the interface module, searches the KdB tree to find a query result corresponding to the obtained query, generates verification data for verifying the searched query result based on the partial Merkle tree and the hierarchical hash information, and can provide the query result and the verification data to the user terminal so that the user terminal can use the partial Merkle tree and the hierarchical hash information to verify the integrity of the query result.

[0008] Furthermore, a user terminal according to one embodiment disclosed in this document includes a communication module that establishes a communication channel with an index server that manages an index DB related to indexing transaction data within a blockchain network, and a processor, wherein the index DB indexes two-dimensional location data included in the transaction data in a KdB tree, constructs a partial Merkle tree for a group of terminal nodes in the KdB tree, and provides hierarchical hash information of the KdB tree in relation to each node of the KdB tree based on the partial Merkle tree; the processor transmits a query related to the location data through the communication module, receives the query result and verification data provided as a result of the index server searching for a query result corresponding to the query in the KdB tree, calculates root hash information of the KdB tree related to the searched terminal node included in the query result using information related to the construction of the partial Merkle tree and the hierarchical hash information included in the verification data, and can verify the integrity of the query result based on the calculated root hash information.

[0009] Furthermore, the blockchain transaction data indexing method by an index server according to one embodiment disclosed in this document may include: indexing two-dimensional position data within transaction data stored in block units on the blockchain network using a KdB tree; constructing a partial Merkle tree for a group of terminal nodes in the KdB tree and storing hierarchical hash information based on the partial Merkle tree in each node of the KdB tree; searching the KdB tree to find a question result corresponding to the acquired question when a question related to the position data is obtained from the user terminal; generating verification data for verifying the searched question result based on the partial Merkle tree and the hierarchical hash information; and providing the question result and the verification data to the user terminal so that the user terminal can verify the integrity of the question result using the partial Merkle tree and the hierarchical hash information. [Effects of the Invention]

[0010] According to the various embodiments disclosed in this document, 2D location data included in blockchain transaction data can be indexed using a KdB tree (generating a completeness verification index), and the completeness of the query results can be verified using a partial Merkle tree of the terminal nodes. In addition, various other effects may be provided, which can be directly or indirectly understood through this document. [Brief explanation of the drawing]

[0011] [Figure 1] An example of a completeness-verified index using a Merkle hash tree is shown. [Figure 2] A conceptual diagram of a blockchain index system according to one embodiment is shown. [Figure 3] A functional configuration diagram of an index server according to one embodiment is shown. [Figure 4] The diagram shows the configuration of an index server according to one embodiment. [Figure 5] The distribution of two-dimensional position data according to an embodiment and the corresponding K-d-B tree partition region information are shown. [Figure 6] The position data stored in the K-d-B tree according to an embodiment is shown on the spatial plane of the K-d-B tree. [Figure 7] The index DB in which the K-d-B tree and the Merkle tree according to an embodiment are combined is shown. [Figure 8] Three main query types for the position data according to an embodiment are shown. [Figure 9] It is a drawing for explaining the exact match query (q1) search method according to an embodiment. [Figure 10] An example of the region query (q2) search method according to an embodiment is shown. [Figure 11] The correctness verification plan for the query result according to an embodiment is shown. [Figure 12] The completeness verification plan for the query result according to an embodiment is shown. [Figure 13] The index-related costs proposed in a static situation where the update of transaction data is not frequent are shown. [Figure 14] When the transaction data is updated, the update cost of the index DB is shown. [Figure 15] The configuration diagram of the user terminal according to an embodiment is shown. [Figure 16] The flowchart of the blockchain transaction data indexing method according to an embodiment is shown.

[0012] In connection with the description of the drawings, the same or similar reference numerals may be used for the same or similar components.

Best Mode for Carrying Out the Invention

[0013] The symbols used in this document have the following meanings.

Table 1

[0014] For example, blockchain analysis tools and interrogation technologies such as EtherQL, Amazon QLDB, and BigChainDB replicate the ledger data of a blockchain network to generate and maintain a separate database (outsourcing database) outside the blockchain network. Such an outsourcing database is managed by utilizing a database system (such as MongoDB, CouchDB, etc.) to reduce management costs and improve interrogation processing efficiency. In addition, the outsourcing database can provide a user-friendly SQL-compatible interrogation language for the interrogation interface.

[0015] By the way, although the outsourcing database provides high efficiency in terms of blockchain interrogation processing, it may have the following limiting points / issues from the perspective of blockchain reliability. (1) By storing and managing data in an external database, there is a risk of original data leakage and data manipulation / leakage. (2) Instead of replicating and storing all the ledger data, it is necessary to support efficient interrogation processing while maintaining the minimum amount of data for interrogation processing. (3) Technologies are needed to ensure the accuracy, reliability, and completeness of interrogation results utilizing an external database and indexes.

[0016] On the other hand, as the interest in cloud computing increases, research on database outsourcing utilizing this has been actively progressing.

[0017] Database outsourcing separates the "data owner" and the "service provider," with the data owner building the database and the service provider managing the database acquired from the data owner and providing application services. Furthermore, "authenticated users" can access the data and search for desired information through the service provider's application services. However, the accuracy and reliability of the data that arises when data owners entrust their asset data to service providers is attracting attention as a significant issue.

[0018] The query result completeness verification technique for outsourced databases in a cloud computing environment is a method for ensuring the correctness of query results and the completeness of the data. The correctness of query results means that the query results actually exist in the original database and have not been modified in any way. The correctness of query results requires that all items in the result set be confirmed to be identical to the original data through verification data. Completeness of the data indicates that all items satisfying the query conditions are returned. A complete result set means a set containing all items that should be included in the results according to the query conditions.

[0019] The accuracy of the question results and the completeness of the data can be verified through question result completeness verification techniques. Question result completeness verification techniques are methods that allow service providers to confirm that they have not damaged (deleted or modified) the data received from data owners during the question processing process and that they have returned accurate results to the questions requested by the user.

[0020] Typically, there are two methods for verifying the results of a question and answer: (1) Merkle-hash tree-based verification and (2) signature-based verification. The following explains each method.

[0021] (1) Merkle-Hash Tree-Based Verification Technique The Merkle-hash tree-based data integrity verification technique, proposed by RCMerkle, stores data in a binary tree structure and guarantees data integrity using a one-way hash function. In this method, hash information generated based on each data tuple is stored in the terminal nodes of the tree, and internal nodes concatenate the hash information of their child nodes. The root node of the tree represents signature information generated by the data owner, and this signature information is transmitted to the authenticated user. The Merkle hash-based query result integrity verification technique for outsourced database environments was proposed by the PTDevanbu group. In this research, when a query is performed, the service provider provides the user with tree search information and integrity verification data (Verification Object) along with the query result. The user analyzes the VO to perform data integrity verification.

[0022] Figure 1 shows an example of an integrity verification index using a Merkle hash tree. The Merkle hash tree-based integrity verification technique is the origin of the Merkle-Patricia Tree, which is used to guarantee data integrity in blockchain networks such as Bitcoin and Ethereum. A Merkle tree stores data in a binary tree structure and uses a one-way hash function. In this case, terminal nodes of the Merkle tree store hash information generated based on each data tuple, and internal nodes concatenate the hash information of the child nodes. The root node of the Merkle tree is represented by signature information that concatenates the hashes of all child node data, and this is transmitted to the authenticated user.

[0023] Referring to Figure 1, the integrity verification of question result data based on a Merkle tree can be performed as follows.

[0024] First, when a user performs a query to search for an arbitrary transaction t1, the query result returned to the user is t1, and the query result verification data includes {h2, h34, h5678}. Since the authenticated user (user terminal) knows the hash function (Hash) information and root hash (h_Root) used to construct the query verification index, it can generate h1 using t1. Therefore, the generated h1 is concatenated with the hashes {h2, h34, h5678} received in the verification data to calculate the root hash, and data integrity verification is performed by comparing it with the root hash (h_Root) received from the data owner. At this time, if the received root hash and the root hash generated by the user match, it is determined that a query result with guaranteed data integrity has been received.

[0025] (2) Signature-based questioning result integrity verification technique Signature-based integrity verification techniques verify the results of a query by having the data owner generate a signature for each data tuple using their private key and then transmitting the key for signature generation to the authenticated user.

[0026] This method requires only query results and data signature information, thus solving the problem of increased verification data transmission costs that occur with tree-based techniques. Furthermore, since it requires only a simple index to store signature information, it also solves the problem of increased data update costs that occur with tree-based indexes. For example, the research by Narasimha and G. Tsudik verifies the integrity of query results using a signature chain formed by concatenating various data tuples. For instance, if R5 is retrieved as a query result, all signature chain data including R5 is transmitted and integrity is verified through comparison. However, a drawback is that the amount of data to be transmitted and the computational overhead increase as the size of the data group included in the query results increases. Due to the aforementioned data transmission and computational overhead, signature-based integrity verification techniques may be difficult to apply to environments with large amounts of data.

[0027] Blockchain platforms possess technical characteristics and advantages such as data transparency, reliability, security, and data processing through smart contracts. Due to these advantages, blockchain technology is attracting attention as a technology that will bring innovation to various industrial sectors. In particular, storing location data on the blockchain is even more important because it can be used as a means of tracking and auditing in logistics systems, smart cities, location-based services, and medical services. For example, in medical services, blockchain-based telemedicine and patient location tracking services can securely manage patient location information and travel routes, allowing for rapid location identification and response in emergency situations. Furthermore, there is a growing number of blockchain-based proof-of-concept applications utilizing location information, such as real-time tracking of logistics and transportation, authenticated route recording, traffic management systems in smart city applications, disaster response, and emergency services.

[0028] In blockchain-based application services, it is crucial not only to store data reliably but also to provide diverse methods for searching and analyzing it. In particular, since two-dimensional location data is searched using queries based on spatial similarity, an index that takes these characteristics into account is necessary. However, current blockchain systems only support search functions for key information such as blocks and transactions, which can be inefficient for searching two-dimensional data. Furthermore, since location data has the characteristic of rapidly increasing in real time, it is necessary to design an index structure that takes dynamic data into account.

[0029] Blockchain technology guarantees reliability for the network as a whole, but it does not guarantee reliability for individual nodes. Therefore, even if participating nodes in the blockchain network perform index-based analysis, it cannot be guaranteed that no operations such as data forgery, alteration, arbitrary deletion, or addition have occurred at each node. Consequently, a separate means of verifying the integrity of participating nodes in the blockchain network is necessary.

[0030] Figure 2 shows a conceptual diagram of a blockchain index system according to one embodiment. The blockchain index system in Figure 2 could be a model for an outsourced database.

[0031] Referring to Figure 2, the blockchain index system 10 according to one embodiment may include a user terminal 300, an administrator device 100, and an index server 200.

[0032] The user terminal 300 may be a computing device used by a blockchain service user. For example, the user terminal 300 may be a mobile device, a smart pad, or a personal computer.

[0033] The user terminal 300 can acquire user inquiries and send the acquired user inquiries to the index server 200.

[0034] The administrator device 100 may be a computing device used by a blockchain data administrator (or data owner). The administrator device 100 can set managed transaction data, including two-dimensional location data within the blockchain network, generate a mixed index of KdB trees and Merkle trees for the transaction data set based on the location data within the transaction data using the index server 200, and store the generated index in the index DB of the index server 200. The Merkle tree is configured for each terminal node of the KdB tree, and each node of the KdB tree can store hierarchical hash information of the Merkle tree.

[0035] Index Server 200 could be a blockchain-based application service provider server.

[0036] The index server 200 supports indexing services for transaction data, including location data, and can store the indexed location data (or an index of location data, or an index database).

[0037] When the index server 200 receives a query from the user terminal 300, it can search for the query result (response data) based on the index DB 235 and generate verification data for verifying the completeness of the searched query result. The verification data may include hash information of nodes visited for query search, top-level hash information of unvisited nodes, and minimal information for constructing the Merkle tree.

[0038] The index server 200 provides the searched query results and verification data to the user terminal 300.

[0039] Thereafter, when the user terminal 300 obtains the question result (response data) and integrity verification data corresponding to the question from the index server 200, it can use the verification data to verify the integrity (accuracy and completeness) of the question result.

[0040] Thus, the blockchain index system 10 according to one embodiment can not only index transaction data through a mixture of KdB trees and Merkle trees, taking into account the characteristics of two-dimensional position data within transaction data, but can also provide a new blockchain data index structure that enables integrity verification, including the accuracy and completeness of query results.

[0041] Figure 3 shows a functional configuration diagram of an index server according to one embodiment.

[0042] Referring to Figure 3, the index server 200 may further include a blockchain connector 215, a question conversion unit 211, an index classification unit 212, a search unit 213, a verification unit 214, and an index DB 235. The blockchain connector 215, the question conversion unit 211, the index classification unit 212, the search unit 213, and the verification unit 214 may be included in the processor 210 in Figure 4, or may be software or hardware modules executed by the processor 210. Therefore, the execution of the blockchain connector 215, the question conversion unit 211, the index classification unit 212, the search unit 213, and the verification unit 214 may be described below primarily from the perspective of the processor 210.

[0043] The query conversion unit 211 can obtain the original query from the user terminal 300 and convert the obtained query into a query for data retrieval. For example, the original query may be input using human-friendly query words, such as SQL-like query statements, and the query conversion unit 211 can convert the input query words into a query that can be parsed by the processor.

[0044] The index classification unit 212 can analyze the converted question to determine whether it is a question that utilizes the index of the location data infrastructure. If the received question utilizes the index of the location data infrastructure, the index classification unit 212 can request the search unit 213 to search for the question.

[0045] The search unit 213 searches for an index that satisfies the query conditions through a binary tree search on the KdB tree and can provide the searched index information to the verification unit 214. The searched index information may include at least one of the location data or transaction ID stored in the searched node.

[0046] The search unit 213 can obtain transaction data (txList) corresponding to the transaction ID from the blockchain network (or blockchain network storage) through the blockchain connector 215. The query result may be, for example, location data stored on the terminal node, and may be location data and transaction ID, or transaction data corresponding to the transaction ID.

[0047] The verification unit 214 can generate verification data (VO; Verification Object) for the query results and send it to the user terminal 300. The verification data may include hash information of nodes visited during the search process, top-level hash information of nodes other than those visited, hash information related to the configuration of the partial Merkle tree of the terminal node searched within the query results, and original root hash information of the KdB tree.

[0048] On the other hand, once the index classification unit 212 confirms that the converted query does not utilize the index of the location data base, the search unit 213 can perform the blockchain chaincode base query.

[0049] The user terminal 300 can analyze the verification data VO to verify the integrity of the searched question results. Once authentication is complete, the user terminal 300 can receive the public key and the hash function used for integrity verification from the index server 200.

[0050] Figure 4 shows a diagram of the index server configuration according to one embodiment.

[0051] Referring to Figure 4, the index server 200 may include at least one of a processor 210, memory 230, input interface device 250, output interface device 260, and storage device 240 that communicate via bus 270. The index server 200 may further include a network-connected communication device 220. The processor 210 may be a central processing unit (CPU) or a semiconductor device that executes instructions stored in memory 230 or storage device 240. The memory 230 and storage device 240 may include various forms of volatile or non-volatile storage media. For example, the memory 230 may include ROM (read-only memory) and RAM (random access memory). In the embodiments described herein, the memory 230 may be located inside or outside the processor 210, and the memory 230 may be connected to the processor 210 through various already known means.

[0052] Memory 230 may include (or store) an index DB 235 containing an integrity verification index for transaction data stored in block units on the blockchain network. The index DB may be constructed by indexing transaction data, including two-dimensional location data of the blockchain network, into a combined structure of a KdB tree and a partial Merkle tree based on that location data. For example, the index DB may be provided by indexing the location data within the transaction data in a KdB tree, constructing a partial Merkle tree for the data groups included in each terminal node of the KdB tree, and storing hierarchical hash information based on the constructed partial Merkle tree in each node (terminal node and internal node) of the KdB tree. Internal nodes, including the root node in the KdB tree, can store the spatial partitioning information of the two-dimensional location data, the page ID, and the hierarchical hash information which sequentially stores all data hashes of the lower nodes. Each terminal node in the KdB tree can store the location data, the transaction ID of the transaction data, and information related to the configuration of the partial Merkle tree of each terminal node. The combined structure of the KdB tree and the partial Merkle tree will be described later with reference to Figures 5-7.

[0053] The processor 210 can obtain queries related to location data from the user terminal 300 through the input interface device 250 (interface module). The obtained query type may include at least one of the following queries: exact match queries, area queries, or nearest neighbor search queries.

[0054] The processor 210 can search for a query result corresponding to the query obtained by performing a binary search of the KdB tree based on the query. The query result may be, for example, position data corresponding to the query.

[0055] According to one embodiment, the processor 210 generates verification data for verifying the searched query results based on the partial Merkle tree and the hierarchical hash information, and can provide the query results and verification data to the user terminal 300 via the communication device 220. Thereafter, the user terminal 300 can verify the integrity of the query results using the partial Merkle tree and the hierarchical hash information.

[0056] According to one embodiment, the processor 210 can generate verification data that includes hash information of nodes visited during the search process, top-level hash information of nodes other than those visited, configuration-related hash information of the partial Merkle tree of the terminal node searched within the query results, and original root hash information of the KdB tree. Therefore, the user terminal 300 can use the partial Merkle tree of the searched terminal node and the hierarchical hash information to calculate the root hash information of the KdB tree and verify the completeness (accuracy) of the query results based on the original root hash information. In this case, the processor 210 can generate verification data that includes the minimum hash information from which the user terminal 300 can calculate hash information using a public key or hash function from among the multiple hash information in the verification data.

[0057] According to one embodiment, the processor 210 can generate and provide the verification data, which further includes a signed copy of the original root hash information encrypted with a secret key. Therefore, the user terminal 300 can verify the integrity of the original root hash information using a previously acquired public key and the signed copy, and then verify the integrity of the index DB based on the verified original root hash information.

[0058] According to one embodiment, the processor 210 can configure an index DB that further stores each terminal node of the KdB tree with location data and axis-specific adjacency data, which includes the next location data on the x-axis and the next location data on the y-axis of each location data. In this case, the processor 210 can provide verification data that further includes axis-specific adjacency data. Therefore, the user terminal 300 can verify the integrity of the index DB based on the distinction between each location data and the axis-specific adjacency data.

[0059] Additionally or alternatively, the processor 210 may sign axis-specific adjacency data with a secret key and store the signed adjacency data in relation to each location data at each terminal node of the KdB tree. In this case, the processor 210 can provide the user terminal with the verification data, which further includes the location data and its adjacency data included in the query results. Thus, the user terminal 300 can verify the integrity of the query results by relating the location data to the adjacency data. For example, the user terminal 300 can verify the integrity of the query results by confirming that the searched location data is different from the adjacency data or does not fall within the range of the adjacency data.

[0060] According to one embodiment, when the processor 210 constructs an index DB (e.g., during initial construction), once an indexing range is set on the blockchain network, it can calculate at least one of the following costs for transaction data corresponding to the indexing range: the storage cost of the index DB (or integrity verification index), the computation cost of the index DB (integrity verification index), the configuration cost of the verification data, and the reliability verification cost for the query results. The processor 210 can then provide the calculated at least one cost to the administrator (e.g., data owner) associated with the construction of the index DB.

[0061] Additionally, the processor 210 can periodically check for updates to transaction data within a set range. Upon checking for updated transaction data, the processor 210 can calculate at least one cost for the updated transaction data. The processor 210 can then display the calculated cost to the administrator or data owner. Subsequently, with the consent of the administrator or data owner, the processor 210 can update the index DB based on the location data within the updated transaction data.

[0062] In the embodiments described above, the index server 200 focused on describing an index structure for two-dimensional positional data within the spatial data. However, it is not limited to this. For example, the index server 200 may generate, configure, or utilize the data index structure for indexing and verifying spatial data stored in the form of lines or polygons.

[0063] Thus, the index server 200 according to one embodiment first generates verification information (hash information) for the data group of the terminal node by a partial Merkle tree configured at the terminal node of the KdB tree, and thereafter, by concatenating the hash information of the child nodes to the higher-level nodes in the KdB tree, the reliability and completeness of the query index can be verified by calculating the root hash information and comparing it with the original root hash information, and the completeness (accuracy) of the searched query results can be verified.

[0064] Furthermore, the index server 200 according to one embodiment can reduce the size of the verification data transmitted to terminal nodes along with the query results by using a partial Merkle tree, while minimizing the generation and updating of hash information, even in environments where data updates are frequent, such as blockchain networks.

[0065] Furthermore, the index server 200 according to one embodiment can more stably guarantee the integrity of the query results by applying signature-based integrity verification to the verification data, in addition to Merkle tree-based integrity verification.

[0066] Consequently, the index server 200 according to one embodiment can sign each location data and adjacent data when configuring the index DB, store them in relation to each location data, and provide adjacent data along with the query results to the user terminal to further guarantee the integrity of the query results.

[0067] The following describes methods for indexing multidimensional data. Indexing structures for multidimensional data, such as 2D data, are broadly classified into PAM (Point Access Method) and SAM (Spatial Access Method) based on the approach method. PAM is a method for storing multidimensional point data and is an approach method for efficiently searching multidimensional data. PAM index structures include Kd trees, grid files, and LSH (Locality Sensitive Hashing). SAM is a method for storing multidimensional spatial data and is suitable for storing and indexing structures such as points, lines, and planes. SAM index structures include R-trees, quad trees, Kd trees, and KdB trees.

[0068] This example provides a query verification index based on location data, which falls under the category of SAM (Spatial Access Method), and specifically utilizes a verification index based on a KdB tree. The access method for spatial data must consider the unique characteristics of spatial queries, which search for adjacent objects in a specific space. Therefore, an index structure is needed that can manage the size of spatial objects through the index. In the case of a KdB tree, it is a fully balanced tree that maintains balance during data insertion and deletion, and its node structure, which stores a large amount of data at once, minimizes disk access, making it useful for processing large volumes of dynamic data.

[0069] Furthermore, because it divides and stores multidimensional space, it has features suitable for range queries and nearest neighbor search (k-Nearest Neighbor, k-NN) queries, which are essential for geographic information systems and multidimensional data analysis. Therefore, to efficiently store location data of the blockchain network, the index server 200 adopted a SAM-type KdB tree structure as the basic structure of the query result verification index and constructed the index DB. The following explanation will be given with reference to the diagram.

[0070] Figure 5 shows the distribution of 2D position data according to one embodiment and the corresponding KdB tree division region information. Figure 6 shows the position data stored in the KdB tree according to one embodiment on the spatial plane of the KdB tree. Figure 7 shows the index DB in which the KdB tree and Merkle tree according to one embodiment are combined.

[0071] A KdB tree is an index structure that combines the characteristics of a Kd tree and a B+ tree, and is composed of area pages and data pages depending on the information to be stored.

[0072] In a conventional KdB tree, domain pages correspond to the root node and intermediate nodes, and each domain page contains entries for "spatial partitioning information, page-id" pairs. In a KdB tree, all data is stored only in terminal nodes, and the amount of data stored in terminal nodes can be adjusted by the size of the disk page or the page size set by the user. A data page is a terminal node (leaf node) that contains entries for data information and address pairs. The address may be the location where the data record is stored on the blockchain network. The data information may be two-dimensional location data. The KdB tree structure can be adapted to environments that are frequently updated, such as location data.

[0073] In one embodiment, the index DB (integrity verification index) can construct a partial Merkle tree for each terminal node of the KdB tree, generate verification information (hash information) for the data groups contained in each terminal node, and store the generated verification information in relation to the terminal node. Furthermore, the hash information of child nodes can be concatenated and stored in the higher-level nodes of the KdB tree (hereinafter referred to as "hierarchical hash information"). Therefore, the area page (internal node) containing the root node of the index DB can store spatial partitioning information, page-ID, and hierarchical hash information that concatenates all the data hashes of the lower nodes. The data pages of the index DB can store location data, transaction ID, and partial Merkle tree information of the data groups contained in the terminal node (e.g., see the triangular section in Figure 7).

[0074] Referring to Figures 5 and 6, the index DB (question result verification index) in one embodiment can be composed of the same items as the KdB tree.

[0075] Referring to Figure 7, each terminal node in the KdB tree has a partial Merkle tree added to it for the group data it contains. For example, if the fan-out of the question result verification index (or group data) is fs, each terminal node generates a partial Merkle tree consisting of up to fs data points. Each terminal node stores hash information related to the configuration of the partial Merkle tree, and the internal nodes of the KdB tree store the hierarchical hash information of the partial Merkle tree.

[0076] Therefore, the index server 200 according to one embodiment can authenticate the integrity of the query results using hierarchical hash information based on a partial Merkle tree. For example, the user terminal 300 can calculate the root hash information of the root node by repeatedly generating hash information of higher-level nodes based on each data (location data) and the hash information of each node. The user terminal 300 can also verify the integrity of the query results by comparing the root hash information with the original root hash information.

[0077] Figure 8 shows three main types of questions regarding positional data in one embodiment.

[0078] Questions regarding location data can be broadly categorized into three types.

[0079] Firstly, an exact match query (e.g., q1 in Figure 8) is a query that searches for an object that matches the same spatial data coordinates, and is similar to a key search in a general database. Exact match queries can be used to confirm the existence or non-existence of a specific location or object.

[0080] Secondly, a range query (e.g., q2 in Figure 8) is a query that searches for all objects contained within a given spatial region (such as a line, rectangle, or circle). Range queries are used very frequently with multidimensional data and return all objects within a given range in a space of two or more dimensions.

[0081] Thirdly, the k-Nearest Neighbor (k-NN) query (e.g., q3 in Figure 8) searches for the k closest neighbors to a given query point. Nearest neighbor queries are essential when performing distance-based searches in spatial data infrastructure applications.

[0082] Therefore, the query types that can be processed by the index server 200 according to one embodiment may include at least one of the following types: exact matching queries, region queries, and k-Nearest Neighbor (k-NN) queries. Thus, the index DB can support the execution of searches for the three query types and the verification of the completeness of the query results.

[0083] According to various embodiments, the index server 200 can also process complex queries such as k-means algorithms and data clustering, which combine and extend exact match queries, region queries, and k-NN queries for data analysis.

[0084] Figure 9 is a diagram illustrating a method for searching for perfectly matching questions (q1) according to one embodiment.

[0085] Referring to Figure 9, the index server 200 can respond to question q1(65, 65) by searching for location data (p17) that satisfies the question result through a tree search (e.g., breadth-first search).

number

[0086] Furthermore, the index server 200 can generate verification data for verifying the integrity of the searched query results (p17). For example, the verification data may include hash information of nodes visited during the search process (nodes shown as circles), top-level hash information of unvisited nodes, original root hash information (h(Root)), and adjacent data (LB, RB) of the query results. In order to search for query results, the index server 200 can extract hash information for visited nodes (nodes shown as circles) and top-level hash information (level 1 h(p1|…|p10))) for unvisited nodes. The index server 200 can also extract hash information of data necessary for constructing the sub-Merkle tree of the searched nodes as a query result. The index server 200 can generate verification data of mathematical formula 2, including the extracted hash information.

number

[0087] The index server 200 can send the searched query results (Result(q1)) and verification data VO to the user terminal 300.

[0088] On the other hand, the user terminal 300 can verify the integrity of the query results using verification data. For example, the user terminal 300 can repeatedly generate hashes for terminal nodes by hashing the data and grouping the hash information until the hashes for all terminal nodes included in the query results have been calculated. Once hash information for all terminal nodes included in the query results has been generated, the user terminal 300 can calculate the parent node hash of the generated terminal nodes. The user terminal 300 can then combine the hash information of the regenerated nodes with the top-level hash information of all nodes not included in the query search path to calculate the hash value of the root. The user terminal 300 can then verify whether the reconstructed root hash information matches the original root hash information.

[0089] If the reconstructed root hash information matches the original root hash information, the user terminal 300 can check whether the values ​​of the adjacent data (LB(q1)=p16, RB(q1)=p18) are excluded from the query result. If the values ​​of the adjacent data are not included in the query result, the user terminal 300 can determine that it has received a query result whose completeness is guaranteed in terms of accuracy and completeness.

[0090] Figure 9 illustrates an example where adjacent data is selected from location data that share a higher-level node with the terminal node explored in the KdB tree, and the adjacent data closest to the x and y axes is selected. However, adjacent data can be the closest data among all location data. Therefore, it is necessary to associate each location data with adjacent data when constructing the index DB. This will be explained later with reference to Figure 12.

[0091] Figure 10 shows an example of a region question (q2) search method according to one embodiment.

[0092] Referring to Figure 10, when the index server 200 obtains the question area q2 ((10, 10), (40, 30)) from the user terminal 300, it performs a tree search related to the obtained question area, and as a result, it can search for data (p2, p3, p4) that satisfy the question result as shown in mathematical formula 3 below.

number

[0093] The index server 200 generates additional integrity verification data VO of the searched query results and transmits it to the user terminal 300. The verification data VO may include node and data information represented by circles, and adjacent data (LB, RB) of the query results.

[0094]

number

[0095] On the other hand, in the case of the k-nearest neighbor search query (q3) shown in Figure 8, only the step of searching for k nearest neighbors from the initial query point is added, and the subsequent process can be the same as that of a domain query. For this reason, a more detailed explanation of the process will be omitted.

[0096] Figure 11 shows a method for verifying the correctness of query results in one embodiment. For the sake of clarity in this document, the number of fan-outs (f) for the terminal node was set to 1. As mentioned above, correctness means that the response data (query results) from the index server 200 to the client query was not manipulated.

[0097] First, the data owner constructs a Merkle tree based on the 2D location data they possess. The data owner then constructs the Merkle root (h) of the derived Merkle tree. root ) sign and the corresponding signature value (s root ) and the entire Merkle tree are stored on index server 200. In this case, the Merkle tree is stored on the terminal node of the KdB tree.

[0098] When the index server 200 receives a user question, it searches for the question result (response data) corresponding to the question and can generate verification data VO for verifying the searched question result. The index server 200 can send the question result and verification data to the user terminal 300. The verification data is data for confirming whether the question result is true or false, and includes the Merkle root signature value (s root ) can include the minimum information necessary for Merkle root configuration. This minimum information may include, for example, hash information for nodes visited during the search process (nodes shown as circles) and top-level hash information for unvisited nodes, original root hash information (h(Root)), and adjacent data (LB, RB) from the query results.

[0099] When the user terminal 300 obtains the question results and verification data, it can determine the accuracy of the question results as follows: The user terminal 300 obtains the Merkle root value (h) from the index server 200 through the data owner's signature (public key). root ) can be used to verify whether it has been forged or altered.

[0100] Furthermore, the user terminal 300 recalculates the root hash information (the root value of the Merkle tree) using the question results and verification data VO, and compares the recalculated root hash information with the original root hash information obtained from the index server 200. If the two root hash information are the same, the accuracy of the question results can be guaranteed by the properties of the collision-resistant hash function.

[0101] Figure 12 shows a method for verifying the completeness of the question results in one embodiment. Completeness means that there is no missing data in the question results (response data) of the index server 200 corresponding to the user's question.

[0102] The data owner (administrator device 100) (or the index server 200 under the control of the data owner) can sort two-dimensional data independently in ascending order for both dimensions (X, Y). The data owner (administrator device 100) can, through the index server 200, generate a signed copy of the next data for each sorted data using a secret key, and then store the signed copies of the data (adjacent data) in relation to each data. For example, the next data on the X-axis of data p3 is p4, and the next data on the Y-axis is p6. Therefore, p3 is concatenated with the adjacent data and hash information for each axis. In addition, the signed copy S(p3|p4) of the X-axis adjacent data of p3 and the signed copy S(p3|p6) of the Y-axis adjacent data of p3 are stored together. If the data has the largest value in a particular dimension, a null (φ) value is added and signed. The data owner constructs a Merkle tree with the signed data and stores the hierarchical hash information of the Merkle tree in the index DB at each node of the KdB tree.

[0103] When a two-dimensional range query is obtained from the user terminal 300, the index server 200 can generate verification data that includes the data contained within the obtained range, along with axis-specific (or in each dimension) adjacent data, and provide it to the user terminal 300.

[0104] The user terminal 300 can verify the completeness of the query results in the following way: The user terminal 300 restores the adjacent data included in the verification data through the data owner's signature (public key). The user terminal 300 can compare the location data and adjacent data corresponding to the query results with the query scope. For example, if all the data corresponding to the query results falls within the query scope, and all the adjacent data corresponding to the query results (or confirmed in the verification data) falls outside the query scope, the user terminal 300 can determine that the index server 200's response to the query satisfies the completeness requirement.

[0105] Thus, the index server 200 according to one embodiment is designed to have structural features similar to an outsourced database linked to a blockchain network, and by applying a question result verification algorithm, it is possible to improve the completeness and correctness of the question results while also improving the question processing performance and efficiency.

[0106] Furthermore, the index server 200 according to one embodiment can improve question processing efficiency by placing an index server that stores the minimum necessary information for each type of question on the question processing server.

[0107] The costs associated with the construction and utilization of an index database according to one embodiment will be explained below with reference to Figures 13 and 14.

[0108] Building and utilizing a location data-based index for blockchain transaction data incurs costs for index storage and processing. In one embodiment, the index server 200 can provide the data owner with the costs required for the configuration and utilization of the index DB prior to or during updates. Therefore, the data owner can decide whether or not to apply the index or perform system updates by considering the costs of index utilization in both static and dynamic data environments.

[0109] Figure 13 shows the proposed index-related costs in a static scenario where transaction data is not frequently updated. These index-related costs may include at least one of the following: the cost of storing the index DB for transaction data corresponding to the configured indexing range, the cost of computing the index DB, the cost of structuring the validation data, and the cost of verifying the validation data on the user terminal 300.

[0110] Firstly, preservation costs

number

number

[0111] In the aforementioned mathematical formula 5, the storage cost consists of the size of the KdB tree and the size of the signature, and the size of the KdB tree is expressed by mathematical formula 6. Here, P is the size of the page and f is the fanout number (the maximum number of divisions in one terminal node). Also, the size of the signature is that two additional signatures (original root hash information and a signed copy of the original root hash information) must be stored for each data record,

number

number

number

[0112] Secondly, construction costs

number

number

[0113] Here,

number

number

number

number

number

number

[0114] Thirdly, the cost of configuring the validation data.

number

number

[0115] In the aforementioned mathematical formula 8,

number

number

number

number

number

number

number

number

[0116] Here

number

number

number

[0117] Finally, reliability verification costs

number

number

[0118] In mathematical formula 10,

number

number

number

number

number

number

[0119] Figure 14 shows the cost of updating the index database when transaction data is updated. Since the blockchain only allows for data addition, data deletion is not considered.

[0120] In a dynamic environment, data owners can update the index database based on blockchain data (transaction data) that has been updated (periodically) at predefined time intervals.

[0121] The update cost is calculated by determining the signature calculation cost, which is then divided into the cost of creating a new signature and the I / O cost.

[0122] As shown in Figure 14, when a new data record is added, a total of 4 additional signatures are required (updating the added data record and two adjacent records for each dimension). When k records are added simultaneously, the number of signatures to be updated is...

number

number

[0123] Additionally, the I / O costs incurred by the update are

number

number

number

[0124] Here,

number

number

number

number

[0125] Index Server 200 can present at least one cost to the data owner or other administrators of Index Server 200. This allows the data owner to decide whether or not to configure the index DB, or to verify the efficiency of the index DB. Alternatively, other administrators can be helped to allocate additional computing resources of Index Server 200 as needed or to calculate service charges.

[0126] In this way, the index server 200 can assist data owners in deciding whether or not to build a system and updating computing resources by providing various cost models for storing, processing, and updating transactional data that will be indexed, both before and during the configuration of the index database.

[0127] Furthermore, the index server 200 can reflect the data update status and evaluate the index management costs when applying indexes in static and dynamic data environments, helping to select the optimal index structure.

[0128] Figure 15 shows a diagram of the user terminal configuration according to one embodiment.

[0129] Referring to Figure 15, the user terminal 300 according to one embodiment may include a communication module 310, memory 340, and processor 350. In one embodiment, the user terminal 300 may omit some components or include additional components. Furthermore, although some components of the user terminal 300 are combined to form a single unit, the functions of the components before the combination can be performed identically.

[0130] The input device 320 can receive user input using the user terminal 300. The input device 320 may include, for example, at least one input sensing circuit from a button, a touchscreen, or a microphone.

[0131] The output device 330 can output at least one data, such as a symbol, number, or character, visually or audibly under the control of the processor 350. The output device 330 may include, for example, at least one output device, such as a liquid crystal display, OLED, touchscreen display, or speaker.

[0132] The communication module 310 can assist in establishing a communication channel or wireless communication channel between the user terminal 300 and other devices (e.g., an index server 200), and in carrying out communication through the established communication channel. The communication channel may include at least one of the following: LAN, FTTH, xDSL, Wibro, Wireless LAN, Wi-Fi, Bluetooth®, Zigbee, WFD (Wi-Fi Direct), UWB (Ultrawideband), Infrared Data Association (IrDA), BLE (Bluetooth Low Energy), NFC (Near Field Communication), 3G, 4G, or 5G.

[0133] The memory 340 can include various forms of volatile or non-volatile memory. For example, the memory 340 can include ROM (read-only memory) and RAM (random access memory). In one embodiment, the memory 340 can be located inside or outside the processor 350, and the memory 340 can be connected to the processor 350 through various already known means. The memory 340 can store various data used by at least one component of the user terminal 300 (e.g., the processor 350). The data can include, for example, input or output data for software and related instructions. For example, the memory 340 can store at least one instruction and data for providing a location data lookup service based on the index server 200. For example, the memory 340 can store instructions and data related to the execution of a specified application using an index based on location data.

[0134] The processor 350 can control at least one other component (e.g., hardware or software component) of the user terminal 300 and perform various data processing or calculations. The processor 350 may include at least one of the following: a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor, an application processor, an application-specific integrated circuit (ASIC), or a field-programmable gate array (FPGA), and may have multiple cores. The processor 350 can retrieve transaction data through the index server 200 by executing a specified application.

[0135] The processor 350 can acquire user queries through the input device 320 and transmit the acquired queries to the index server 200 via the communication module 310. The queries may include at least one of the following: exact match queries, region queries, or nearest neighbor search queries.

[0136] The processor 350 receives query results and verification data searched by the index server 200, and uses the information related to the configuration of the partial Merkle tree and the hierarchical hash information included in the verification data to calculate the root hash information of the KdB tree associated with the searched terminal node included in the query results, and can verify the integrity of the query results based on the calculated root hash information. For example, the processor 350 can calculate hash information of the terminal node associated with the searched terminal node based on the verification data, use the calculated hash information and the hierarchical hash information to calculate the root hash information of the KdB tree, and verify the integrity of the query results by comparing the calculated root hash information with the original root hash information.

[0137] Once the integrity of the query results is verified, the processor 350 can obtain the transaction data from the blockchain network based on the transaction ID contained in the searched terminal node. Alternatively, once the integrity is verified, the processor 350 can obtain the transaction data contained in the query results through the index server 200.

[0138] The processor 350 can obtain verification data which further includes a signed copy of the original root hash information encrypted with a private key. After verifying the integrity of the original root hash information using the previously obtained public key and the signed copy, the processor 350 can verify the integrity of the query result by comparing the verified original root hash information with the calculated root hash information.

[0139] The processor 350 can acquire verification data for each terminal node of the KdB tree, which further includes position data and axis-specific adjacency data, which includes the next position data on the x-axis and the next position data on the y-axis of each position data. The processor 350 can verify the integrity of the index DB based on the continuity between each position data and the axis-specific adjacency data contained in the explored terminal node.

[0140] The processor 350 can obtain the verification data, which further includes the axis-specific adjacency data signed with a secret key. If the query is a range query, the processor 350 can verify the integrity of the index DB by checking whether all axis-specific adjacency data included in the verification data falls outside the relevant range.

[0141] The processor 350 can output the integrity verification result (whether or not authentication failed) for the query results through the output device 330. The processor 350 can also output the query results through the output device 330.

[0142] Figure 16 shows a flowchart of a blockchain transaction data indexing method according to one embodiment.

[0143] Referring to Figure 16, in operation 1610, the index server 200 can index the two-dimensional position data within the transaction data stored in block units on the blockchain network using a KdB tree.

[0144] In operation 1620, the index server 200 can construct a partial Merkle tree for a group of terminal nodes in the KdB tree.

[0145] In operation 1630, the index server 200 can store hierarchical hash information based on a partial Merkle tree in each node of the KdB tree.

[0146] In operation 1640, when the index server 200 obtains a query related to the location data from the user terminal 300, it can search the KdB tree to find a query result corresponding to the obtained query.

[0147] In operation 1650, the index server 200 can generate verification data for verifying the searched query results based on the partial Merkle tree and the hierarchical hash information.

[0148] In operation 1660, the index server 200 can provide the question results and the verification data to the user terminal 300.

[0149] The various embodiments and the terminology used in this document should be understood not as intended to limit the technical features described herein to any particular embodiment, but as including various modifications, equivalents, or substitutes for the embodiments in question. In relation to the description of the drawings, similar or related reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the items unless the context clearly indicates otherwise. In this document, phrases such as "A or B," "at least one of A and B," "at least one of A or B," "A, B or C," "at least one of A, B and C," and "at least one of A, B, or C" may each include any one of the items listed together in the phrase in question, or any possible combination thereof. Terms such as "first," "second," or "first" or "second" may be used simply to distinguish the component in question from other components in question, and do not limit the component in question in any other respect (e.g., importance or order). When a component (e.g., the first) is referred to as "coupled" or "connected" with or without the terms "functionally" or "communically" to another component (e.g., the second), it means that the first component may be connected to the other component directly (e.g., by wire), wirelessly, or through the third component.

[0150] As used in this document, the term "module" can include units embodied in hardware, software, or firmware, and can be used interchangeably with terms such as logic, logic block, component, or circuit. A module can be a component configured as a whole or the smallest unit or part of such component that performs one or more functions. For example, according to one embodiment, a module can be embodied in the form of an ASIC (application-specific integrated circuit).

[0151] The various embodiments of this document can be embodied in software (e.g., a program) containing one or more instruction words stored in a storage medium (e.g., internal or external memory, memory (memory 230 in Figure 4)) readable by a machine (e.g., an electronic device). For example, the processor (e.g., processor 210) of a machine (e.g., an index server 200) can invoke and execute at least one instruction from the one or more instruction words stored in the storage medium. This allows the machine to be operated to perform at least one function by the invoked at least one instruction word. The one or more instruction words may include code generated by a compiler or code that can be executed by an interpreter. The storage medium readable by the machine may be provided in the form of a non-transitory storage medium. Here, "non-transitory" simply means that the storage medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and this term does not distinguish between cases where data is stored semi-permanently and cases where it is stored temporarily on the storage medium.

[0152] According to one embodiment, the methods relating to the various embodiments disclosed herein may be provided in a computer program product. The computer program product may be traded as a commodity between sellers and buyers. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)) or through an application store (e.g., Play Store). TM Computer programs can be distributed online (e.g., downloaded or uploaded) through a network or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily generated on a device-readable storage medium such as the memory of the manufacturer's server, the application store's server, or an intermediary server.

[0153] The components relating to the various embodiments of this document may be embodied in software or hardware such as a DSP (digital signal processor), FPGA (Field Programmable Gate Array), or ASIC (Application Specific Integrated Circuit), and may perform a predetermined role. The term "component" is not limited to software or hardware; each component may be configured to reside on an addressable storage medium, or to generate one or more processors. As an example, components may include software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, processors, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0154] According to various embodiments, each component of the aforementioned components (e.g., a module or program) may contain one or more individuals. According to various embodiments, one or more components or operations within the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, multiple components (e.g., a module or program) may be integrated into a single component. In such cases, the integrated component may perform one or more functions of each of the multiple components in the same or similar manner as they were performed by the respective components of the multiple components prior to the integration. According to various embodiments, operations performed by modules, programs or other components may be performed sequentially, in parallel, repeatedly, or heuristically, or one or more of the operations may be performed in a different order, omitted, or one or more other operations may be added.

Claims

1. In the index server, An interface module that can interface with the user's terminal; An index database related to indexing transaction data stored in block units on a blockchain network; and a processor, the processor, The two-dimensional data included in the transaction data is indexed using a K-d-B tree, a partial Merkle tree is constructed for a group of terminal nodes using the K-d-B tree, and hierarchical hash information based on the partial Merkle tree is stored in each node of the K-d-B tree; The aforementioned partial Merkle tree and the aforementioned hierarchical hash information are used to generate verification data for questions obtained through the interface module, in an index server.

2. In the K-d-B tree, the internal nodes, including the root node, store the spatial partitioning information of the location data, the page ID, and the hierarchical hash information for the data hashes of the subordinate nodes. In the K-d-B tree, each terminal node stores the two-dimensional data, the transaction ID of the transaction data, and information related to the configuration of the sub-Merkle tree of each terminal node. The index server according to claim 1.

3. The aforementioned processor, By generating verification data that includes hash information of nodes visited during the search process, top-level hash information of nodes other than those visited, configuration-related hash information of the partial Merkle tree of the terminal node searched within the query results, and original root hash information of the K-d-B tree, the user terminal calculates the root hash information of the K-d-B tree using the partial Merkle tree of the searched terminal node and the hierarchical hash information, and verifies the integrity of the query results based on the original root hash information. The index server according to claim 1.

4. The aforementioned processor, The verification data is generated by excluding the minimum hash information from among the multiple hash information within the verification data, which can be calculated by the user terminal using a public key or hash function. The index server according to claim 3.

5. The aforementioned processor, By generating and providing the verification data, which further includes a signed copy of the original root hash information encrypted with a private key, the user terminal verifies the integrity of the original root hash information using a public key and the signed copy, and then verifies the integrity of the index DB based on the verified original root hash information. The index server according to claim 3.

6. The aforementioned processor, By further storing axis-specific adjacency data, which includes each 2D data and the next 2D data on the x-axis and y-axis of each 2D data, at each terminal node of the K-d-B tree, the user terminal verifies the integrity of the index DB based on the distinction between each 2D data and the axis-specific adjacency data. The index server according to claim 1.

7. The aforementioned processor, The axis-specific adjacency data is signed with a secret key, and the signed adjacency data is stored in relation to each of the two-dimensional data points at each terminal node of the K-d-B tree. The index server according to claim 6.

8. The aforementioned processor, By providing the user terminal with the verification data, which further includes the two-dimensional data and adjacent data contained in the question results, the user terminal verifies the completeness of the question results by relating the two-dimensional data corresponding to the question results with the adjacent data. The index server according to claim 6.

9. The aforementioned processor, The system provides the question results in response to at least one of the following questions: an exact match question, a domain question, or a nearest neighbor search question. The index server according to claim 1.

10. The aforementioned processor, When an indexing range is set in the blockchain network, the system calculates at least one of the following costs for transaction data corresponding to the indexing range: the cost of storing the index database, the cost of calculating the index database, the cost of structuring the verification data, and the cost of verifying the reliability of the query results. The calculated cost is then displayed. The index server according to claim 1.

11. The aforementioned processor, The system periodically checks whether transaction data within the set range has been updated, calculates the cost of at least one of the updated transaction data, and displays the calculated cost. The index server according to claim 10.

12. On the user's terminal, A communication module that establishes a communication channel with an index server that manages an index DB related to indexing transaction data within a blockchain network; and a processor, wherein the index DB indexes the two-dimensional data contained in the transaction data using a K-d-B tree, constructs a partial Merkle tree for a group of terminal nodes using the K-d-B tree, and provides hierarchical hash information of the K-d-B tree based on the partial Merkle tree in relation to each node of the K-d-B tree; the processor, The communication module transmits questions related to the two-dimensional data. The index server retrieves and provides the question results corresponding to the question in the Kd-B tree, and the index server receives the question results and verification data from the index server. Using the information related to the configuration of the partial Merkle tree included in the verification data and the hierarchical hash information, the root hash information of the K-d-B tree associated with the searched terminal node included in the query results is calculated. The completeness of the question results is verified based on the calculated root hash information. User terminal.

13. The aforementioned processor, Once the completeness of the results of the aforementioned questioning is verified, the transaction data is searched from the blockchain network based on the transaction ID contained in the searched terminal node. The user terminal according to claim 12.

14. The verification data includes hash information of nodes visited by the index server during the search process for the query results, top-level hash information of nodes other than those visited, configuration-related information of the partial Merkle tree of the searched terminal node, and original root hash information. The processor calculates hash information of the terminal node associated with the searched terminal node based on the verification data, calculates the root hash information of the K-d-B tree using the calculated hash information and the hierarchical hash information, and verifies the completeness of the query results by comparing the calculated root hash information with the original root hash information. The user terminal according to claim 12.

15. The verification data further includes a signed copy of the original root hash information encrypted with a secret key, The processor verifies the integrity of the original root hash information using the previously acquired public key and the signed book, and then compares the verified original root hash information with the calculated root hash information. The user terminal according to claim 14.

16. The verification data further includes axis-specific adjacency data for each terminal node of the K-d-B tree, which includes each 2D data and the next 2D data on the x-axis and the next 2D data on the y-axis of each 2D data. The processor verifies the integrity of the index DB based on the continuity between each of the two-dimensional data contained in the searched terminal node and the axis-specific adjacency data. The user terminal according to claim 12.

17. The verification data further includes the axis-specific adjacency data, The processor, when the query is a range query, verifies the integrity of the index DB by checking whether all of the axis-specific adjacent data included in the verification data fall outside the range. The user terminal according to claim 16.

18. The axis-specific adjacent data is signed with a secret key, The processor recovers the axis-specific adjacency data included in the verification data using the public key, and then checks whether it falls outside the range. The user terminal according to claim 17.

19. The aforementioned processor, The system receives the question result in response to at least one of the following questions: an exact match question, a domain question, or a nearest neighbor search question. The user terminal according to claim 12.

20. In a blockchain transaction data indexing method using an index server, The process of indexing two-dimensional data within transaction data stored in blocks on a blockchain network using a K-d-B tree; The operation of constructing a partial Merkle tree for a group of terminal nodes in the aforementioned K-d-B tree; An operation to store hierarchical hash information based on the aforementioned partial Merkle tree in each node of the K-d-B tree; The aforementioned partial Merkle tree and hierarchical hash information are used to generate verification data for questions obtained from the user terminal. Transactional data indexing method.

Images