An efficient and verifiable query method for blockchain that supports rich retrieval

Abstract

This invention provides an efficient and verifiable query method for blockchain that supports rich retrieval, relating to the field of blockchain technology. This invention performs relational modeling on data in the blockchain to achieve rich queries; after relational modeling, different data types in the blockchain are stored in different data storage modules; indexes are built for the data in blocks to support efficient verifiable relational queries and verifiable key-value queries. Block data and historical data are indexed using aggregated MB trees, while state data is indexed using sorted balanced binary trees. This invention supports rich query types, allowing retrieval of different attributes to meet the needs of user data analysis and data mining; the queries are verifiable, ensuring correctness and completeness, achieving trusted traceability of the blockchain, improving the efficiency of verifiable queries, expanding the application scenarios of blockchain in production and daily life, and meeting more application needs.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to an efficient and verifiable query method for blockchain that supports rich retrieval. Background Technology

[0002] To enrich the types of blockchain retrieval and improve the efficiency of blockchain data query, existing technical solutions can be broadly divided into two types: external databases and built-in indexes.

[0003] External database access involves importing data from blockchain blocks into an off-chain database, transferring the blockchain storage portion to the database for processing, and providing data query services through the off-chain database's query API. External database access can be further subdivided into two methods based on its implementation: the first method imports data from the blockchain system into the off-chain database, and the second method utilizes the blockchain network to synchronize database operations, updating the off-chain database state by replaying transactions from the blockchain. Built-in indexing uses specific data structures to build indexes for block data, meeting the needs of various query types within the blockchain system, such as LineageChain and ForkBase.

[0004] External databases typically provide rich query capabilities through traditional databases. However, this approach also has drawbacks: First, data stored off-chain is no longer protected by the blockchain. Retrieving data detaches from the blockchain, lacking verification mechanisms for the correctness and completeness of query result sets, making it difficult to guarantee data integrity. Second, maintaining an additional database outside the blockchain increases storage costs. Built-in indexing, on the other hand, adds indexes to the blockchain data based on user query needs. This method uses less space, and the data remains protected by the blockchain. However, built-in indexes are more complex to implement, their query efficiency cannot compare to external databases, and frequent addition and deletion of indexes when needs change is cumbersome.

[0005] Among existing research methods, those supporting verifiable queries can be broadly categorized into three types: circuit-based verifiable computation, trusted hardware-based methods, and verifiable data structure-based methods. Verifiable data structure-based methods can be further divided into digital signatures, tree-based ADS, and cryptographic accumulator-based ADS. In circuit-based verifiable computation, the dataset and its operations are pre-compiled into arithmetic or Boolean circuits according to a verifiable computation protocol. The client can then interact with the untrusted server according to the protocol. Trusted hardware provides a trusted execution environment on untrusted nodes, allowing users to run code within this environment. For example, CorrectDB implements a verifiable database based on the trusted hardware IBM4764 co-processor (SCPU). Cryptographic accumulator methods accumulate a set of elements into a single value, which each element can use to prove its presence.

[0006] In traditional verifiable query support schemes, verifiable computation-based and digital signature-based schemes cannot be directly applied to blockchain verifiable query processing scenarios due to performance issues or the need for DO signatures; trusted hardware-based schemes require participants to have corresponding hardware and assume that the hardware is trusted; tree-based verification structures and cryptographic accumulator-based verification structures are more suitable for blockchain application scenarios.

[0007] Currently, the Merkle tree, the verifiable data structure used in mainstream blockchains, supports a limited number of verifiable query types and suffers from low query efficiency. With the widespread deployment of data-intensive applications in blockchain networks, this verification structure is clearly insufficient to meet users' diverse query needs for blockchain data. Existing methods based on MB trees and cryptographic accumulators can support some complex queries, but their implementation is complex and introduces additional storage overhead. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to address the shortcomings of the prior art by providing an efficient and verifiable query method for blockchain that supports rich retrieval. The invention constructs a data storage module to reorganize the data in the blockchain, improves the existing verifiable data structure, supports rich verifiable queries, and improves query efficiency.

[0009] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0010] An efficient and verifiable blockchain query method supporting rich retrieval includes the following steps:

[0011] Step 1: Data in the blockchain undergoes consensus verification. After successful verification and submission, it enters different data storage modules according to its data type; if verification fails, error handling is required.

[0012] Step 2: Model the relationship between block data and historical data. The modeled data is stored in different data storage modules: block data is stored in the Block Data Storage Module BlockDB, historical data is stored in the History Data Storage Module HistoryDB, and state data is stored in the State Data Storage Module StateDB.

[0013] The three data storage modules and their corresponding tables are created when the blockchain starts. After the block data storage module BlockDB is created, it needs to check some information in the blockchain, including whether the chain is empty and the latest block number, and then store the block data in BlockDB. The history data storage module HistoryDB needs to verify whether the transaction is successful. After successful verification, it updates the status of the history database and stores the historical data in HistoryDB.

[0014] Step 3: After data storage is completed, check whether the states in the three data storage modules are consistent. Confirm whether the states of the State data storage module StateDB and the History data storage module HistoryDB are consistent with the Block data storage module BlockDB. If the states in the three data storage modules are consistent, proceed to Step 4. If they are inconsistent, perform error handling to keep the states of StateDB and HistoryDB consistent with BlockDB.

[0015] Step 4: Create different indexes for the data in different data storage modules to support efficient and verifiable queries. Block data and historical data are indexed using aggregated MB trees, while status data is indexed using sort-based balanced binary trees.

[0016] Step 5: Verifiable query processing. The full node aggregates the MB tree or a sorted balanced binary tree based on the verifiable data structure from Step 4 to generate verifiable information VO. The verifiable information VO is returned to the light node along with the query results. In verifiable relation queries, the verifiable data structure AggSetDigest is added to the verifiable information VO and returned along with the query results to prove correctness. For those that do not meet the integrity proof, a mismatch proof is generated using the verifiable data structure.

[0017] Step 6: The light node verifies the correctness and completeness of the query result set based on the verifiable information (VO), and then returns the verification results to the full node.

[0018] Furthermore, in the relationship modeling of step 2, the block data is divided into two tables: a block relationship model and a transaction relationship model. The block relationship model includes the block number, block hash, previous block hash, transaction data hash, and metadata. The transaction relationship model includes the block number, intra-block transaction number, transaction ID, and transaction data.

[0019] Historical data relationship modeling includes block number, transaction ID, key, name of the database where the transaction data is located, and name of the data table where the transaction data is located;

[0020] Status data is still stored in a key-value database.

[0021] Furthermore, the three data storage modules each use a corresponding database: the BlockDB data storage module uses MongoDB, the HistoryDB data storage module uses MySQL, and the StateDB data storage module uses LevelDB.

[0022] Furthermore, the general interface of the data storage module is the Ledger Provider interface, which is responsible for the creation, initialization, and destruction of the ledger instance. The ledger interface is also responsible for processing block data, resolving whether the genesis block exists, and determining whether the genesis block exists before creating the data storage module. Only if the genesis block exists can the data storage module be constructed. The ledger interface is also responsible for submitting block data and transaction data. When transaction data is packaged into a block and verified by the blockchain network consensus, and it is determined to be written into the blockchain ledger, the block will be broadcast to all nodes on the blockchain. Each node will hand the block data over to the ledger instance for processing. The ledger instance stores the data on the chain in the MongoDB database by calling the specific methods of the Block data storage module BlockDB. The storage of state data and historical data also needs to be implemented by the ledger interface calling the specific methods of the corresponding data storage module.

[0023] Furthermore, the BlockDB interface of the block data storage module includes the following functions: writing the modeled block data and transaction data into the MongoDB database, querying block data based on block number and block height, and querying transaction data by transaction ID, block number, and transaction number within the block;

[0024] The StateDB interface of the state data storage module includes the following methods: writing the latest value of the key to the database, querying the latest state of the key, querying the latest value of multiple keys at the same time, and querying the block height corresponding to the latest state update.

[0025] The HistoryDB interface of the historical data storage module includes the following functions: writing data extracted from block data into the historical database, querying the block height at the most recent update, and quickly querying the change history of key values ​​based on block number and transaction ID.

[0026] Furthermore, the nodes of the aggregated MB tree are divided into leaf nodes and index nodes; the data nodes of the tree are the leaf nodes, and each leaf node includes a transaction object in a block. The leaf nodes are connected by pointers to form a circular linked list; each leaf node is represented as... <o i , h i >, stores the object and its hash value; o i It stores three fields: t i Timestamp, V i Numerical attributes, W i Non-numerical attribute set;

[0027] The index node has 5 fields.<Key,P,W,AggSetDigest,H()> The first field is the Key. i Field, records the key-value pair of the aggregated MB tree, P i The field is a pointer field, pointing to the first child node of this index node, W. i It aggregates the attributes of the child nodes of the index node, AggSetDigest i It is an aggregate attribute value field, H i Perform a hash operation between the hash value of the child node and the aggregate attribute value;

[0028] The hash value of the root node and the newly added field AggSetDigest in the verifiable data structure are written into the block header. The data structure of the block header includes the hash of the previous block PreBkHash, the timestamp TS, the hash value MerkleRoot of the root node, and the attribute set summary information AggSetDigest. AggSetDigest can record the attribute W of all transaction objects. This field can be used to determine whether the transaction object meets the query conditions. If the transaction object does not match the query conditions, the VO returned to the light node does not need to contain the entire field, but only the attribute set summary information field. The size of the AggSetDigest field is fixed and is independent of the number of transaction objects.

[0029] Furthermore, in the sorted balanced binary tree, leaf nodes store the values ​​of all transaction objects, while non-leaf nodes (i.e., internal nodes) do not store transaction object values. Leaf nodes are arranged in ascending order from left to right according to the value of the transaction object keys. Each leaf node stores the original key-value pairs...<key,value> Based on this, a `nextkey` field is added. The `nextkey` field stores the key value of the rightmost leaf node adjacent to the current leaf node. Therefore, the actual data stored in a leaf node is a triple.<key,nextkey,value> The first leaf node has a key value of 0, and the last leaf node has a nextkey value of positive infinity. The hash value of a leaf node is calculated as h = H(key|nextkey|value). Based on a sorted balanced binary tree, to prove that a given query key-value pair exists, first find the largest key-value pair less than the search condition k by traversing the tree, and then compare the nextkey value of that key-value pair with the search condition k. If nextkey is greater than k, the transaction list does not contain the given query. If nextkey is equal to the search condition k, the transaction list contains the given query, and the tree continues to traverse to the right until the nextkey field of a leaf node is greater than the search condition k. Since the nextkey value of the last leaf node is positive infinity, there is no need to check whether the last node has been reached.

[0030] The beneficial effects of adopting the above technical solution are as follows: The efficient and verifiable query method for blockchain provided by this invention supports rich retrieval, supports rich query types, can retrieve different attributes, and meets the needs of user data analysis and data mining; on the other hand, the queries are verifiable, which can meet the correctness and completeness of the queries, realize the trustworthy traceability of blockchain, improve the efficiency of verifiable queries, expand the application scenarios of blockchain in production and life, and meet more application needs. Attached Figure Description

[0031] Figure 1 Flowchart of an efficient and verifiable blockchain query method supporting rich retrieval provided in this embodiment of the invention;

[0032] Figure 2 A relational modeling diagram provided for embodiments of the present invention;

[0033] Figure 3 This is a design diagram of the storage module interface provided in an embodiment of the present invention;

[0034] Figure 4 The aggregated MB tree provided in the embodiments of the present invention;

[0035] Figure 5 This invention provides a sorting-based balanced binary tree. Detailed Implementation

[0036] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0037] like Figure 1 As shown, the method of this embodiment is described below.

[0038] Step 1: Data in the blockchain undergoes consensus verification. After successful verification and confirmation, the data is entered into different data storage modules according to its data type. If verification fails, error handling is required.

[0039] Step 2: Model the relationship between block data and historical data. The modeled data is then stored in different data storage modules: block data is stored in the Block Data Storage Module BlockDB, historical data is stored in the History Data Storage Module HistoryDB, and state data is stored in the State Data Storage Module StateDB.

[0040] The three data storage modules and their corresponding tables are created when the blockchain starts. After the block data storage module BlockDB is created, it needs to check some information in the blockchain, including whether the chain is empty and the latest block number, before storing the block data in BlockDB. The history data storage module HistoryDB needs to verify whether the transaction is successful. After successful verification, it updates the status of the history database and stores the historical data in HistoryDB.

[0041] Figure 2 This is a relationship modeling diagram between block data and historical data. Data in the blockchain is collectively referred to as ledger data, which is divided into block data, state data, and historical data. Block data is composed of multiple transaction data sets, written when a block is created. State data records the current state of transaction data, typically stored in key-value format, and stores the latest value corresponding to each key. Historical data records the history of changes in transaction data, documenting the history of valid transactions. In actual storage, the historical database only stores the key values ​​related to transactions, not the changes in the corresponding value values. When querying historical records, the block number and transaction number are first retrieved based on the key value, and then the changes in the corresponding value are searched within the block data.

[0042] Block data is divided into two tables in relational modeling: one is the block relation model, and the other is the transaction relation model. The block relation model includes the block number, block hash, previous block hash, transaction data hash, and metadata; the transaction relation model includes the block number, transaction number within the block, transaction ID, and transaction data.

[0043] Historical data relationship modeling includes block number, transaction ID, key, the name of the database where the transaction data is located, and the name of the data table where the transaction data is located.

[0044] Status data is still stored in a key-value database.

[0045] Figure 3 This is the interface design diagram for the data storage module. After relational modeling, block data, due to its frequent writes and queries, is stored in a MongoDB database, which has good read and write performance. Historical data, due to its infrequent writes and frequent queries, is stored in a MySQL database, which has good query performance. State data, since it generally involves simple queries, is stored in a LevelDB database in key-value format, allowing for fast lookup of values ​​using the key.

[0046] The Ledger Provider interface is the main interface for the data storage module. It is primarily responsible for the creation, initialization, and destruction of the ledger instance. The ledger interface also handles block data processing, resolving whether the genesis block exists. When creating a data storage module, it must first determine if the genesis block exists; only if the genesis block exists can the data storage module be constructed. The ledger interface is also responsible for submitting block data and transaction data. Once transaction data is packaged into a block and verified through blockchain network consensus, and is confirmed to be written into the blockchain ledger, the block is broadcast to all nodes on the blockchain. Each node then hands the block data to the ledger instance for processing. The ledger instance, by calling the specific methods of the BlockDB data storage module, stores the data in a MongoDB database, completing the data on-chain process. Similarly, the storage of state data and historical data also requires the ledger interface to call the specific methods of the corresponding data storage modules.

[0047] The BlockDB interface of the block data storage module mainly includes the following functions: writing the modeled block data and transaction data into the MongoDB database, querying block data by block number and block height, and querying transaction data by transaction ID, block number, and transaction number within the block.

[0048] The StateDB interface of the state data storage module offers the following methods: writing the latest value of a key to the database, querying the latest state of a key, querying the latest values ​​of multiple keys simultaneously, and querying the block height corresponding to the latest state update.

[0049] The HistoryDB interface, a historical data storage module, mainly includes the following functions: writing data extracted from block data into the historical database, querying the block height at the most recent update, and quickly querying the history of key value changes based on block number and transaction ID.

[0050] Step 3: After data storage is completed, check whether the states in the three data storage modules are consistent. Confirm whether the states of the State data storage module (StateDB) and the History data storage module (HistoryDB) are consistent with the Block data storage module (BlockDB). If the states in the three data storage modules are consistent, proceed to Step 4. If they are inconsistent, perform error handling to keep the states of StateDB and HistoryDB consistent with BlockDB.

[0051] Step 4: Create different indexes for the data in different data storage modules to support efficient and verifiable queries. Block data and historical data are indexed using aggregated MB trees, while status data is indexed using sorted balanced binary trees.

[0052] Data query services need to meet the requirements of correctness and completeness while also considering query efficiency. To improve the efficiency of verifiable queries, this embodiment proposes two verifiable data structures: an aggregated MB tree and a sorted balanced binary tree. The aggregated MB tree is used to achieve efficient verifiable relation queries, while the sorted balanced binary tree is used to achieve efficient verifiable key-value queries.

[0053] Figure 4 It is an aggregated MB tree. Nodes in an aggregated MB tree are divided into leaf nodes and index nodes. The data nodes of the tree are the leaf nodes, and each leaf node contains a transaction object from a block. The leaf nodes are connected by pointers, forming a circular linked list. Each leaf node can be represented as... <o i , h i >, stores the object and the object's hash value. i It stores three fields: t i Timestamp, V i Numerical attributes, W i Non-numerical attribute set. Separating timestamps, numerical attributes, and non-numerical attributes enables better querying of various data types.

[0054] The index node has 5 fields.<Key,P,W,AggSetDigest,H()> The first field is the Key. i Field, records the key-value pair of the aggregated MB tree, P i The field is a pointer field, pointing to the first child node of this index node, W. iIt aggregates the attributes of the child nodes of the index node, AggSetDigest i It is an aggregate attribute value field, H i Perform a hash operation between the hash value of the child node and the aggregate attribute value.

[0055] The hash value of the root node and the newly added field `AggSetDigest` in the verifiable data structure are written into the block header. The block header data structure consists of the previous block hash (`PreBkHash`), the timestamp (`TS`), the root node hash value (`MerkleRoot`), and the attribute set digest information (`AggSetDigest`). `AggSetDigest` records the attribute `W` of all transaction objects. This field can be used to determine whether a transaction object meets the query conditions. If a transaction object does not match the query conditions, the VO returned to the light node does not need to contain the entire field; only the attribute set digest information field is required. The size of the `AggSetDigest` field is fixed and independent of the number of transaction objects.

[0056] Figure 5 This is a sorted balanced binary tree. In a sorted balanced binary tree, leaf nodes store the values ​​of all transaction objects, while non-leaf nodes (internal nodes) do not store transaction object values. In this embodiment, the leaf nodes are arranged in ascending order from left to right according to the size of the transaction object keys. Each leaf node stores the original key-value pairs...<key,value> Based on this, a `nextkey` field is added. The `nextkey` field stores the key value of the rightmost leaf node adjacent to the current leaf node. Therefore, the actual data stored in a leaf node is a triple.<key,nextkey,value> The first leaf node has a key value of 0, and the last leaf node has a nextkey value of positive infinity. The hash value of a leaf node is calculated as h = H(key|nextkey|value). Given a query condition k, a traditional Merkle tree requires traversing the entire verifiable tree structure to query all values ​​that satisfy the condition, generating a query result set and a VO. A sorted balanced binary tree, when proving the existence of a key-value pair for a given query, first finds the largest key-value pair smaller than the search condition k, then compares the nextkey value of that key-value pair with the search condition k. If nextkey is greater than k, then the transaction list does not contain the given query. If nextkey is equal to the search condition k, it proves the transaction list contains the given query, and the traversal continues to the right until the nextkey field of a leaf node is greater than the search condition k. Since the nextkey value of the last leaf node is positive infinity, there is no need to check whether the last node has been reached. By introducing the nextkey field, the sorted balanced binary tree simplifies the non-existence verification process and unifies the logic of existence and non-existence proofs in querying and verification.

[0057] Step 5: Verifiable query processing. The full node aggregates the MB tree or a sorted balanced binary tree based on the verifiable data structure from Step 4 to generate verifiable information VO. The verifiable information VO is returned to the light node along with the query results. In verifiable relation queries, the verifiable data structure AggSetDigest is added to the verifiable information VO and returned along with the query results to prove correctness. For those that do not meet the integrity proof, a mismatch proof is generated using the verifiable data structure.

[0058] Step 6: The light node verifies the correctness and completeness of the query result set based on the verifiable information (VO), and then returns the verification results to the full node.

[0059] This invention analyzes current blockchain application scenarios and, based on practical needs, proposes and implements technologies to achieve rich and efficient verifiable queries that can meet more application requirements. Specifically, these technologies are:

[0060] (1) This invention innovates the storage structure of existing blockchain systems and performs relational modeling on the data in the blockchain to achieve rich queries.

[0061] (2) This invention uses different data storage modules. After the data in the blockchain is modeled in relation, different data types are stored in different data storage modules.

[0062] (3) Index the data in the blocks to support efficient verifiable relational queries and verifiable key-value queries. Block data and historical data are indexed using aggregated MB trees, while status data is indexed using sorted balanced binary trees.

[0063] In summary, the efficient and verifiable query method proposed in this invention supports rich retrieval, supports a wide range of query types, and can retrieve different attributes to meet the needs of user data analysis and data mining. On the other hand, the queries are verifiable, ensuring the correctness and completeness of the queries, realizing the trusted traceability of the blockchain, improving the efficiency of verifiable queries, expanding the application scenarios of blockchain in production and life, and meeting more application needs.

[0064] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope defined by the claims of the present invention.

Claims

1. A blockchain-based efficient and verifiable query method supporting rich retrieval, characterized in that: Includes the following steps: Step 1: Data in the blockchain undergoes consensus verification. After successful verification and submission, it enters different data storage modules according to its data type. If the verification fails, error handling is required. Step 2: Model the relationship between block data and historical data. The modeled data is stored in different data storage modules: block data is stored in the Block Data Storage Module BlockDB, historical data is stored in the History Data Storage Module HistoryDB, and state data is stored in the State Data Storage Module StateDB. The three data storage modules and their corresponding tables mentioned above are created when the blockchain starts. After the BlockDB data storage module is created, it needs to check some information in the blockchain, including whether the chain is empty and the latest block number, before storing the block data into BlockDB. The HistoryDB data storage module needs to verify whether the transaction is successful. After successful verification, it updates the status of the history database and stores the historical data into HistoryDB. Step 3: After data storage is completed, check whether the states in the three data storage modules are consistent. Confirm whether the states of the State data storage module StateDB and the History data storage module HistoryDB are consistent with the Block data storage module BlockDB. If the states in the three data storage modules are consistent, proceed to Step 4. If they are inconsistent, perform error handling to keep the states of StateDB and HistoryDB consistent with BlockDB. Step 4: Create different indexes for the data in different data storage modules to support efficient and verifiable queries. Block data and historical data are indexed using aggregated MB trees, while status data is indexed using sort-based balanced binary trees. Step 5: Verifiable query processing. The full node aggregates the MB tree or a sorted balanced binary tree based on the verifiable data structure from Step 4 to generate verifiable information VO. The verifiable information VO is returned to the light node along with the query results. In verifiable relation queries, the verifiable data structure AggSetDigest is added to the verifiable information VO and returned along with the query results to prove correctness. For those that do not meet the integrity proof, a mismatch proof is generated using the verifiable data structure. Step 6: The light node verifies the correctness and completeness of the query result set based on the verifiable information (VO), and then returns the verification results to the full node.

2. The efficient and verifiable blockchain query method supporting rich retrieval as described in claim 1, characterized in that: In the relationship modeling of step 2, the block data is divided into two tables: a block relationship model and a transaction relationship model. The block relationship model includes the block number, block hash, previous block hash, transaction data hash, and metadata. The transaction relationship model includes the block number, intra-block transaction number, transaction ID, and transaction data. Historical data relationship modeling includes block number, transaction ID, key, name of the database where the transaction data is located, and name of the data table where the transaction data is located; Status data is still stored in a key-value database.

3. The efficient and verifiable blockchain query method supporting rich retrieval as described in claim 2, characterized in that: The three data storage modules each use a corresponding database: the BlockDB data storage module uses MongoDB, the HistoryDB data storage module uses MySQL, and the StateDB data storage module uses LevelDB.

4. The efficient and verifiable blockchain query method supporting rich retrieval as described in claim 3, characterized in that: The main interface of the data storage module is the Ledger Provider interface, which is responsible for the creation, initialization, and destruction of the ledger instance. The ledger interface is also responsible for processing block data, resolving whether the genesis block exists, and determining whether the genesis block exists before creating the data storage module. The ledger interface is also responsible for submitting block data and transaction data. When transaction data is packaged into a block and verified by the blockchain network consensus, and it is determined to be written into the blockchain ledger, the block will be broadcast to all nodes on the blockchain. Each node will hand the block data over to the ledger instance for processing. The ledger instance stores the data on the blockchain in the MongoDB database by calling the specific methods of the BlockData storage module. The storage of state data and historical data also needs to be implemented by the ledger interface calling the specific methods of the corresponding data storage module.

5. The efficient and verifiable blockchain query method supporting rich retrieval as described in claim 4, characterized in that: The BlockDB interface of the block data storage module includes the following functions: writing the modeled block data and transaction data into the MongoDB database, querying block data by block number and block height, and querying transaction data by transaction ID, block number, and transaction number within the block; The StateDB interface of the state data storage module includes the following methods: writing the latest value of the key to the database, querying the latest state of the key, querying the latest value of multiple keys at the same time, and querying the block height corresponding to the latest state update. The HistoryDB interface of the historical data storage module includes the following functions: writing data extracted from block data into the historical database, querying the block height at the most recent update, and quickly querying the change history of key values ​​based on block number and transaction ID.

6. The efficient and verifiable blockchain query method supporting rich retrieval according to claim 1, characterized in that: The nodes of the aggregated MB tree are divided into leaf nodes and index nodes; the data nodes of the tree are the leaf nodes, and each leaf node includes a transaction object in a block. The leaf nodes are connected by pointers to form a circular linked list; each leaf node is represented as... <o i , h i >, stores the object and its hash value; o i It stores three fields: t i Timestamp, V i Numerical attributes, W i Non-numerical attribute set; The index node has 5 fields.<Key,P,W,AggSetDigest,H()> The first field is the Key. i Field, records the key-value pair of the aggregated MB tree, P i The field is a pointer field, pointing to the first child node of this index node, W. i It aggregates the attributes of the child nodes of the index node, AggSetDigest i It is an aggregate attribute value field, H i Perform a hash operation between the hash value of the child node and the aggregate attribute value; The hash value of the root node and the newly added field AggSetDigest in the verifiable data structure are written into the block header. The data structure of the block header includes the hash of the previous block PreBkHash, the timestamp TS, the hash value MerkleRoot of the root node, and the attribute set summary information AggSetDigest. AggSetDigest can record the attribute W of all transaction objects. This field can be used to determine whether the transaction object meets the query conditions. If the transaction object does not match the query conditions, the VO returned to the light node does not need to contain the entire field, but only the attribute set summary information field. The size of the AggSetDigest field is fixed and is independent of the number of transaction objects.

7. The efficient and verifiable blockchain query method supporting rich retrieval as described in claim 1, characterized in that: The sorted balanced binary tree stores the values ​​of all transaction objects in the leaf nodes, while non-leaf nodes (internal nodes) do not store transaction object values. The leaf nodes are arranged in ascending order from left to right according to the transaction object keys. Each leaf node contains the original key-value pairs...<key,value> Based on this, a `nextkey` field is added. The `nextkey` field stores the key value of the rightmost leaf node adjacent to the current leaf node. Therefore, the actual data stored in a leaf node is a triple.<key,nextkey,value> The first leaf node has a key value of 0, and the last leaf node has a nextkey value of positive infinity. The hash value of a leaf node is calculated as h = H(key|nextkey|value). Based on a sorted balanced binary tree, to prove that a given query key-value pair exists, first find the largest key-value pair less than the search condition k by traversing the tree, and then compare the nextkey value of that key-value pair with the search condition k. If nextkey is greater than k, the transaction list does not contain the given query. If nextkey is equal to the search condition k, the transaction list contains the given query, and the tree continues to traverse to the right until the nextkey field of a leaf node is greater than the search condition k. Since the nextkey value of the last leaf node is positive infinity, there is no need to check whether the last node has been reached.

Images