A field query method, device, equipment, medium and product

Abstract

This application provides a field query method, apparatus, device, medium, and product, comprising: receiving a query request sent by a blockchain light node; parsing the query field from the query request; determining the field's popularity and whether it meets a preset index construction trigger condition; if so, parsing the query type from the query request and determining the target index structure from a preset set of index structure types; performing a query operation on the query request to obtain a query result; further generating verification information; compiling the verification information into a Boolean circuit; and generating a zero-knowledge proof based on the Boolean circuit; and sending the query result and the zero-knowledge proof to the light node. Thus, while improving query efficiency, it effectively controls verification and communication overhead and enhances the long-term stability of the blockchain system.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a field query method, apparatus, device, medium and product. Background Technology

[0002] With the rapid development and popularization of blockchain technology, efficient and reliable on-chain data querying has become a key requirement supporting its widespread application. In recent years, blockchain has been deeply applied in many fields such as financial transactions, supply chain traceability, and electronic health records, leading to a continuous increase in the scale of on-chain data and increasingly frequent query requests. In this decentralized environment, users typically need to independently verify the correctness and integrity of the data they obtain without completely trusting any single node, i.e., achieving "trustless" query verification. However, current mainstream query methods often require traversing large amounts of data and performing complex verifications, resulting in huge computational overhead and slow response speeds, making it difficult to meet the requirements of high real-time scenarios. Especially for lightweight nodes with limited storage and computing resources, they cannot store complete historical blockchain data, thus requiring a lightweight query mechanism with low resource consumption, high query efficiency, and verifiable proofs.

[0003] To address this challenge, the research field has proposed a technical approach called "full-node verifiable query," which involves designing special encrypted data structures, indexes, or zero-knowledge proof protocols to enable query results to be independently verified by any node on the chain, without relying on the trust guarantees of a specific service provider. While some preliminary solutions based on verifiable databases or Merkle tree indexes exist, most are designed for static data and face significant limitations in the dynamic blockchain environment: First, existing index structures are typically fixed, making it difficult to flexibly adapt to frequent data updates and changes in query patterns, especially during sudden surges in access to hot data, which can easily cause performance bottlenecks; second, most solutions lack effective verification aggregation mechanisms, requiring the generation and transmission of numerous independent proofs when facing complex queries with multiple conditions, leading to a linear increase in communication and verification overhead, thus limiting the overall system throughput and response speed.

[0004] In summary, existing on-chain data query technologies generally struggle to adapt to the continuous and dynamic updates of blockchain data, and are unable to maintain low verification overhead when data changes frequently. Furthermore, their fixed indexing mechanisms lack the ability to flexibly respond to diverse query patterns, resulting in significant limitations in supporting dynamic data evolution, achieving efficient compressed verification, and adaptive query structures. Summary of the Invention

[0005] This application provides a field query method, apparatus, device, medium, and product to address the technical limitations of existing blockchain data query schemes in supporting dynamic data evolution, achieving efficient compressed verification, and adaptive query structures.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows:

[0007] In a first aspect, embodiments of this application provide a field query method, which is applied to a blockchain full node, and the method includes:

[0008] Receive a query request sent by a blockchain light node, parse the query field from the query request, determine the field popularity based on the query field, and determine whether the field popularity meets the preset index construction triggering conditions;

[0009] If the field popularity meets the index building trigger condition, the query type is parsed from the query request, and the target index structure is determined from the preset index structure type set according to the query type;

[0010] Based on the target index structure, a query operation is performed on the query request to obtain the query result. Verification information is generated according to the location information of the query result in the target index structure. The verification information is compiled into a Boolean circuit, and a zero-knowledge proof is generated according to the Boolean circuit.

[0011] The query results and the zero-knowledge proof are sent to the light node.

[0012] Optionally, the field popularity is determined based on the query field, and it is determined whether the field popularity meets the preset index building trigger conditions, including:

[0013] Set a time-sliding window, count the number of queries for each query field within the time-sliding window, and count the total number of queries for all query requests within the time-sliding window;

[0014] The ratio between the number of queries and the total number of queries is calculated, and the ratio is used as the field popularity of each query field.

[0015] The field popularity is compared with a preset popularity threshold. If the field popularity is greater than the popularity threshold, the query field is determined to meet the index construction triggering condition.

[0016] Optionally, the set of index structure types includes hash tables, B+ trees, and inverted indexes; determining the target index structure from the preset set of index structure types according to the query type includes:

[0017] Based on the preset correspondence between the query type and each index structure type in the index structure type set, candidate index structures matching the query type are selected from the index structure type set; wherein, the query type includes equality query, range query and fuzzy query, the equality query corresponds to the hash table, the range query corresponds to the B+ tree, and the fuzzy query corresponds to the inverted index;

[0018] For each of the selected candidate index structures, the performance parameters of the candidate index structure are evaluated based on the structural characteristics of the candidate index structure. The performance parameters include hit rate, average query latency, and storage overhead.

[0019] The performance parameters are input into a preset multi-objective utility function, and the utility value of each candidate index structure is calculated by the multi-objective utility function; wherein, the optimization objectives of the multi-objective utility function include maximizing the hit rate, minimizing the query latency, and minimizing the storage overhead;

[0020] The utility values ​​of each candidate index structure are compared, and the candidate index structure with the highest utility value is determined as the target index structure.

[0021] Optionally, the verification information is compiled into a Boolean circuit, and a zero-knowledge proof is generated based on the Boolean circuit, including:

[0022] The query conditions are parsed from the query request and then decomposed into multiple sub-words.

[0023] For each of the sub-words, the sub-words are compiled into corresponding sub-circuits, and input fields are extracted from each of the sub-circuits;

[0024] Obtain the input fields of each sub-circuit and determine whether there is any overlap between the input fields of each sub-circuit; if there is no overlap between the input fields of each sub-circuit, then mark each sub-circuit as an independent sub-circuit that can be processed in parallel.

[0025] Based on the concise non-interactive zero-knowledge proof zk-SNARK protocol, a proof generation operation is performed on each of the independent sub-circuits to obtain a sub-proof corresponding to each of the independent sub-circuits.

[0026] An aggregation operation is performed on each of the sub-proofs, and the output of the aggregation operation is used as the zero-knowledge proof.

[0027] Optionally, an aggregation operation is performed on each of the sub-proofs, and the output of the aggregation operation is used as the zero-knowledge proof, including:

[0028] Extract proof elements from each of the sub-proofs;

[0029] Generate a random index, and use the random index to weight each of the proof elements to obtain the weighted proof elements;

[0030] Based on a pre-defined bilinear pairing aggregation algorithm, the weighted proof elements are aggregated into a single aggregated proof.

[0031] The aggregated proof is used as the zero-knowledge proof;

[0032] Specifically, while generating the zero-knowledge proof, a common verification parameter corresponding to the zero-knowledge proof is generated, and the common verification parameter is sent to the light node.

[0033] Optionally, after sending the query result and the zero-knowledge proof to the light node, the method further includes:

[0034] For each of the query fields, query records for the query fields within a continuous time period are continuously acquired. The query records are processed based on a preset exponentially weighted moving average model, and the real-time popularity value of the query field is calculated based on the processing results.

[0035] The real-time popularity value is matched with a preset popularity range, and each query field is divided into a corresponding popularity region based on the matching result. The popularity region includes a hot spot area, a middle area and a cold spot area.

[0036] Based on the popularity region to which each of the query fields belongs, the structural mutation type to be performed on the target index structure is determined from a preset set of structural mutation types, wherein the set of structural mutation types includes hotspot expansion, path compression, and hotspot fusion;

[0037] Based on the determined structural mutation type, the corresponding structural mutation operation is performed on the target index structure.

[0038] Optionally, based on the popularity region to which each of the query fields belongs, the type of structural mutation to be performed on the target index structure is determined from a preset set of structural mutation types, and the corresponding structural mutation operation is performed according to the determined structural mutation type, including:

[0039] When the query field is assigned to the hotspot area, the real-time popularity value is compared with a first preset threshold. If the real-time popularity value is greater than the first preset threshold, the structural mutation type is determined to be hotspot expansion from the set of structural mutation types, and a multi-level secondary index is constructed in the target index structure based on the hotspot expansion for the query field.

[0040] When the query field is assigned to the cold zone, the miss duration of the index node corresponding to the query field in the target index structure is counted, and the miss duration is compared with a preset duration threshold. If the miss duration exceeds the preset duration threshold, the structural mutation type is determined to be path compression from the set of structural mutation types, and the index node is reclaimed based on the path compression to release storage space.

[0041] When multiple query fields are assigned to the hotspot area, the difference between the real-time popularity values ​​of each query field is calculated, and the difference is compared with a second preset threshold. If the difference is less than the second preset threshold, the structural mutation type is determined to be hotspot fusion from the set of structural mutation types, and the index paths of the multiple query fields are aggregated into a unified composite index path based on the hotspot fusion.

[0042] Optionally, before determining the type of structural mutation to be performed on the target index structure, the method further includes:

[0043] Obtain the current status information of the target index structure, and generate a version snapshot identifier based on the current status information;

[0044] The version snapshot identifier is stored locally and then sent to the light node.

[0045] After performing the corresponding structural mutation operation on the target index structure according to the determined structural mutation type, the method further includes:

[0046] Set a preset monitoring period. Within the preset monitoring period, count the number of verification failures and the total number of verifications of the index structure after the mutation. Calculate the ratio between the number of verification failures and the total number of verifications, and use the ratio as the verification failure rate.

[0047] The verification failure rate is compared with a preset tolerance threshold; if the verification failure rate exceeds the tolerance threshold, the index structure state before the mutation is obtained based on the version snapshot identifier, and the current index structure is rolled back to the index structure state before the mutation.

[0048] Secondly, embodiments of this application provide a field query method, which is applied to a blockchain light node, and the method includes:

[0049] Generate a query request based on the data to be queried, and send the query request to the full node of the blockchain;

[0050] The system receives the query results, zero-knowledge proof, and public verification parameters returned by the blockchain full node. The zero-knowledge proof is generated by the blockchain full node based on the query request, and the public verification parameters are generated synchronously by the blockchain full node when generating the zero-knowledge proof.

[0051] Obtain the block header information stored locally, and perform verifiability verification on the query result based on the block header information, the public verification parameters, and the zero-knowledge proof to obtain the verification result. If the verification result is successful, the query result is determined to be correct and complete.

[0052] Optionally, based on the block header information, the public verification parameters, and the zero-knowledge proof, a verifiability check is performed on the query result, including:

[0053] Extract the aggregated proof from the zero-knowledge proof;

[0054] The public verification parameters are validated based on the block header information. If the validation passes, the public verification parameters are used as the validation input.

[0055] Based on the preset pairing verification equation, the verification input and the aggregated proof are substituted into the pairing verification equation to perform the verification operation;

[0056] The verification result is determined based on the result of the verification operation: if the pairing verification equation is true, the verification result is determined to be passed; if the pairing verification equation is false, the verification result is determined to be failed.

[0057] Thirdly, embodiments of this application provide a field query device, which is applied to a blockchain full node, and the device includes:

[0058] The receiving module is used to receive query requests sent by blockchain light nodes, parse the query fields from the query requests, determine the field popularity based on the query fields, and determine whether the field popularity meets the preset index construction trigger conditions.

[0059] The first execution module is used to parse the query type from the query request when the field popularity meets the index building triggering condition, and determine the target index structure from the preset index structure type set according to the query type;

[0060] Based on the target index structure, a query operation is performed on the query request to obtain the query result. Verification information is generated according to the location information of the query result in the target index structure. The verification information is compiled into a Boolean circuit, and a zero-knowledge proof is generated according to the Boolean circuit.

[0061] The query results and the zero-knowledge proof are sent to the light node.

[0062] Fourthly, embodiments of this application provide a field query device, which is applied to a blockchain light node, and the device includes:

[0063] The sending module is used to generate a query request based on the data to be queried and send the query request to the full node of the blockchain;

[0064] The second execution module is used to receive the query result, zero-knowledge proof, and public verification parameters returned by the blockchain full node, wherein the zero-knowledge proof is generated by the blockchain full node based on the query request, and the public verification parameters are generated synchronously by the blockchain full node when generating the zero-knowledge proof;

[0065] Obtain the block header information stored locally, and perform verifiability verification on the query result based on the block header information, the public verification parameters, and the zero-knowledge proof to obtain the verification result. If the verification result is successful, the query result is determined to be correct and complete.

[0066] Fifthly, embodiments of this application provide a network device, including: a processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, it implements the steps of a field query method as described in the first or second aspect.

[0067] Sixthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of a field query method as described in the first or second aspect.

[0068] In a seventh aspect, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the steps of a field query method as described in the first or second aspect.

[0069] In this embodiment, by having the full blockchain node parse the query fields and determine their popularity after receiving query requests from the light node, index construction is triggered only when the field access frequency reaches a preset condition. This avoids the waste of resources caused by blindly creating indexes for all data and significantly reduces computational overhead. Subsequently, a target index structure is intelligently selected from a preset set of index structures based on the query type, ensuring that the index matches the specific query pattern type and improving the accuracy and efficiency of the query operation. Then, the query is executed based on the target index structure and verification information is generated. By compiling it into a Boolean circuit and converting it into a zero-knowledge proof, the light node can quickly verify the correctness and completeness of the results without trusting the full node, thereby significantly shortening the verification time while ensuring security.

[0070] Therefore, the method shown in the embodiments of this application realizes on-demand self-adaptive indexing and compressed verifiable proof output for dynamic blockchain environments, which improves query efficiency, effectively controls verification and communication overhead, and enhances the long-term stability of the blockchain system. Attached Figure Description

[0071] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0072] Figure 1 A flowchart illustrating a field query method provided in an embodiment of this application;

[0073] Figure 2 A flowchart illustrating a field query method provided in an embodiment of this application;

[0074] Figure 3 A structural block diagram of a field query system provided in an embodiment of this application;

[0075] Figure 4 A structural block diagram of a field query device provided in an embodiment of this application;

[0076] Figure 5 A structural block diagram of a field query device provided in an embodiment of this application;

[0077] Figure 6 This is a structural block diagram of a network device provided in an embodiment of this application. Detailed Implementation

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

[0079] The technical terms (1, 2) and technical routes (3, 4) related to a field query method provided in the embodiments of this application are introduced below.

[0080] 1. Blockchain is a distributed ledger system maintained by multiple nodes and built on a cryptographic hash chain. Its data structure typically consists of blocks, each containing several transactions and the hash of the previous block, forming an immutable, time-ordered data chain. Blockchain possesses characteristics such as data immutability, decentralization, transparency, and traceability, making it a core technology for building trusted data infrastructure. However, blockchain inherently has weak support for external queries; nodes accessing historical data on the chain require a traversal scan, which is inefficient. Especially when facing queries from lightweight nodes, the inability to obtain full-chain data significantly restricts data query capabilities in practical applications.

[0081] 2. Verifiable Data Structures (VDS): Merkle trees are data structures built using recursive hashing, widely used in blockchains to prove the existence of a data item within a dataset. Users only need to obtain the data item and its hash path to the root node to complete the verification, resulting in low computational complexity. However, this structure is primarily suitable for single-point exact verification and is difficult to scale for complex queries (such as range queries and multi-field combinations). Furthermore, in lightweight node scenarios, it still requires the support of a full-chain hash root structure, making it difficult to efficiently parallelize verification operations.

[0082] 3. Light Node Block Traversal: Light node block traversal is a basic blockchain data verification method. In a blockchain network, light nodes cannot store complete blockchain data due to resource limitations. Therefore, light nodes obtain data from full nodes through a peer-to-peer network and verify the correctness of the data based on the block header information.

[0083] 4. Full Nodes Preconstruct Verifiable Data Structures: Preconstructing verifiable data structures by full nodes is a traditional method for implementing verifiable queries. The basic idea is that when writing data to the blockchain, the full node simultaneously builds an index based on a Merkle tree or other verifiable data structure and writes the root hash of this structure into the block header. When a light node initiates a query, the full node, in addition to returning the query result, also provides a verification path (such as a Merkle path) from the data item to the root hash, allowing the light node to verify the correctness of the result without obtaining the full amount of data. However, this preconstructed verifiable data structure is static; once built, it is difficult to adjust and cannot adapt to changes in query patterns. Each query requires a complete path, and the verification complexity increases with the amount of data.

[0084] Figure 1 A flowchart of a field query method according to an embodiment of this application is shown. The method is applied to a blockchain full node, such as... Figure 1 As shown, the method includes:

[0085] Step S101: Receive the query request sent by the blockchain light node, parse the query field from the query request, determine the field popularity based on the query field, and determine whether the field popularity meets the preset index construction triggering condition.

[0086] Step S102: If the field popularity meets the index building triggering condition, the query type is parsed from the query request, and the target index structure is determined from the preset index structure type set according to the query type.

[0087] Step S103: Perform a query operation on the query request based on the target index structure to obtain the query result, generate verification information based on the location information of the query result in the target index structure, compile the verification information into a Boolean circuit, and generate a zero-knowledge proof based on the Boolean circuit.

[0088] Step S104: Send the query results and zero-knowledge proof to the light node.

[0089] It should be noted that, Figure 1 The core of the method shown is to enable the full node of the blockchain to form processing logic around the query fields in the query request, such as field popularity, index building trigger conditions, target index structure, and verifiable output, after receiving the query request sent by the light node of the blockchain, thereby balancing query efficiency and verifiability.

[0090] Specifically, a blockchain full node parses the query fields from the query request, determines the field popularity based on the query fields, and then uses whether the field popularity meets the preset index construction trigger conditions as the basis for judgment. This allows the blockchain full node to decide whether to enter the index construction path when faced with changes in the access intensity of different query fields. If the field popularity meets the index construction trigger conditions, the blockchain full node further parses the query type from the query request and determines the target index structure from the preset set of index structure types based on the query type. This allows subsequent query operations to be executed on the target index structure that matches the query type, thereby providing a structural foundation for obtaining query results.

[0091] The full blockchain node executes a query operation on the query request based on the target index structure to obtain the query result. It then uses the location information of the query result within the target index structure to generate verification information, establishing a traceable correspondence between the verification information and the query result. Furthermore, the verification information is compiled into a Boolean circuit, and a zero-knowledge proof is generated based on this circuit. This allows the light blockchain node to verify the correctness and completeness of the query result without needing to access the full blockchain node's complete data and execution details. Finally, the full blockchain node sends the query result and the zero-knowledge proof to the light blockchain node, providing the light node with a combination of outputs that can be used for verification.

[0092] This enables the integrated processing of field queries and zero-knowledge proof generation on the blockchain full node side, thereby improving the adaptability of query processing while providing verifiable evidence for lightweight verification.

[0093] In one possible implementation, the field popularity is determined based on the query field, and it is then determined whether the field popularity meets the preset index building triggering conditions. This includes: setting a time sliding window, counting the number of queries for each query field within the time sliding window, and counting the total number of queries for all query requests within the time sliding window; calculating the ratio between the number of queries and the total number of queries, and using this ratio as the field popularity of each query field; comparing the field popularity with a preset popularity threshold, and if the field popularity is greater than the popularity threshold, then the query field is determined to meet the index building triggering conditions.

[0094] It should be noted that this possible implementation method is in Figure 1Building upon the method described, this paper further explains the process of "determining field popularity based on query fields and judging whether the field popularity meets the preset index building trigger conditions." The key lies in introducing a time-sliding window to characterize the access distribution of query fields over time, giving field popularity an updatable and comparable quantitative meaning. By setting a time-sliding window and counting the number of queries for each query field within that window, while simultaneously counting the total number of queries for all query requests within the time-sliding window, blockchain full nodes can obtain the relative access frequency of a particular query field within that time-sliding window. Furthermore, the ratio between the number of queries and the total number of queries is calculated and used as the field popularity for each query field, thus maintaining comparability even with different time-sliding window sizes or different total request volumes. Subsequently, the field popularity is compared with a preset popularity threshold. When the field popularity exceeds the threshold, the query field is determined to meet the index building trigger conditions. This comparison mechanism provides a clear boundary for the index building trigger conditions, avoiding instability in the index building strategy due to short-term fluctuations or subjective judgment.

[0095] Overall, by combining time sliding window, query count, total query count, ratio, and popularity threshold, the calculation of field popularity and the determination of index building trigger conditions are made more objective and repeatable, thereby forming a more stable trigger decision effect on the full node side.

[0096] In one possible implementation, the set of index structure types includes hash tables, B+ trees, and inverted indexes. The target index structure is determined from the preset set of index structure types based on the query type. This includes: filtering candidate index structures that match the query type from the set of index structure types based on a preset correspondence between the query type and each index structure type in the set; wherein the query types include equality queries, range queries, and fuzzy queries, with equality queries corresponding to hash tables, range queries to B+ trees, and fuzzy queries to inverted indexes; for each candidate index structure, performance parameters are evaluated based on its structural characteristics, including hit rate, average query latency, and storage overhead; the performance parameters are input into a preset multi-objective utility function, which calculates the utility value of each candidate index structure; wherein the optimization objectives of the multi-objective utility function include maximizing the hit rate, minimizing query latency, and minimizing storage overhead; the utility values ​​of each candidate index structure are compared, and the candidate index structure with the highest utility value is determined as the target index structure.

[0097] It should be noted that the set of index structure types includes hash tables, B+ trees, and inverted indexes, and a pre-established correspondence between query types and each index structure type in the set is established. The query types include equality queries, range queries, and fuzzy queries, with equality queries corresponding to hash tables, range queries to B+ trees, and fuzzy queries to inverted indexes. Thus, blockchain full nodes can first filter out candidate index structures that match the query type from the set of index structure types.

[0098] To avoid overly absolute selection based solely on correspondence, performance parameters for each candidate index structure can be evaluated based on its structural characteristics. These parameters include hit rate, average query latency, and storage overhead, thus transforming the merits of candidate index structures in practical operation into comparable metrics. These performance parameters are then input into a pre-defined multi-objective utility function, which calculates the utility value for each candidate index structure. The optimization objectives of this multi-objective utility function include maximizing hit rate, minimizing query latency, and minimizing storage overhead, ensuring that index selection reflects a balance between query efficiency and resource cost. Finally, by comparing the utility values ​​of each candidate index structure, the one with the highest utility value is determined as the target index structure. This ensures that the target index structure adopted by the blockchain full nodes is more closely aligned with the current query type and operational constraints. This makes the determination of the target index structure more adaptive, thereby improving the overall efficiency of subsequent query operations.

[0099] In one possible implementation, the verification information is compiled into a Boolean circuit, and a zero-knowledge proof is generated based on the Boolean circuit. This includes: parsing query conditions from a query request and decomposing the query conditions into multiple sub-words; for each sub-word, compiling the sub-word into a corresponding sub-circuit and extracting input fields from each sub-circuit; obtaining the input fields of each sub-circuit and determining whether there is any overlap between the input fields of each sub-circuit; if there is no overlap between the input fields of each sub-circuit, marking each sub-circuit as an independent sub-circuit that can be processed in parallel; performing a proof generation operation on each independent sub-circuit based on the zk-SNARK protocol to obtain a sub-proof corresponding to each independent sub-circuit; performing an aggregation operation on each sub-proof and using the output of the aggregation operation as the zero-knowledge proof.

[0100] Among them, k-SNARK is a concise, non-interactive zero-knowledge proof. Utilizing the zk-SNARK protocol, query conditions can be compiled into Boolean circuits or constraint systems to generate compact proofs. Its focus is on designing circuit block optimization and proof aggregation mechanisms, which can further improve the verification efficiency of multi-condition queries.

[0101] It should be noted that in this possible implementation, the query conditions in the query request are structurally decomposed into Boolean circuit units that can be processed in parallel. This improves the generation efficiency of zero-knowledge proofs and maintains the consistency between the proof semantics and the query conditions. Specifically, the blockchain full node parses the query conditions from the query request and decomposes them into multiple sub-words, dividing the complex query conditions into multiple components with relatively independent semantics. Then, for each sub-word, it is compiled into a corresponding sub-circuit, and the input fields are extracted from each sub-circuit. This makes it clear which input fields each sub-circuit depends on, thus providing a basis for parallelism judgment. Further, the input fields of each sub-circuit are obtained, and it is determined whether there is any overlap between the input fields of each sub-circuit. When there is no overlap between the input fields of each sub-circuit, each sub-circuit is marked as an independent sub-circuit that can be processed in parallel. This marking mechanism allows the blockchain full node to divide sub-circuits that do not need to share input fields into independent sub-circuits, thereby reducing serial dependencies. Based on the zk-SNARK protocol, a proof generation operation is performed on each independent sub-circuit to obtain a sub-proof. Then, an aggregation operation is performed on each sub-proof, and the output of the aggregation operation is used as a zero-knowledge proof. This allows the zero-knowledge proof to cover the complete query conditions while reducing generation costs through parallel generation and aggregation mechanisms. Overall, this approach can improve the proof generation efficiency on the blockchain's full node side while maintaining verifiability.

[0102] In one possible implementation, an aggregation operation is performed on each sub-proof, and the output of the aggregation operation is used as a zero-knowledge proof. This includes: extracting proof elements from each sub-proof; generating a random index and using the random index to weight each proof element to obtain a weighted proof element; aggregating each weighted proof element into a single aggregated proof based on a preset bilinear pairing aggregation algorithm; and using the aggregated proof as a zero-knowledge proof. Simultaneously with generating the zero-knowledge proof, a common verification parameter corresponding to the zero-knowledge proof is generated, and the common verification parameter is sent to the light node.

[0103] It should be noted that this possible implementation limits the implementation details of "performing an aggregation operation on each sub-proof and using the output of the aggregation operation as a zero-knowledge proof". It emphasizes forming a single aggregate proof through the extraction of proof elements, the weighted processing of random exponents, and a preset bilinear pairing aggregation algorithm, and simultaneously generating public verification parameters for verification by blockchain light nodes.

[0104] Specifically, proof elements are extracted from each sub-proof, giving the aggregation operation a clear target. Then, a random index is generated, and the proving elements are weighted using this index to obtain weighted proof elements. This weighting process ensures that the aggregation process maintains verifiable relationships while providing a unified combination method and a computable structural input for subsequent aggregations. Based on this, a pre-defined bilinear pairing aggregation algorithm is used to aggregate the weighted proof elements into a single aggregated proof. This aggregated proof serves as a zero-knowledge proof, thus compressing the zero-knowledge proof output by the blockchain full node from multiple sub-proofs into a single proof, reducing the burden of transmission and verification.

[0105] At the same time, while generating the zero-knowledge proof, a public verification parameter corresponding to the zero-knowledge proof is generated, and the public verification parameter is sent to the blockchain light node so that the blockchain light node can obtain the necessary verification input during subsequent verifiability verification.

[0106] Therefore, by combining random exponents, weighted proof elements, a pre-defined bilinear pairing aggregation algorithm, and common verification parameters, zero-knowledge proofs become more compact and easier to verify while maintaining coverage, thereby improving the verification feasibility of the blockchain light node side and the communication efficiency of the overall system.

[0107] In one possible implementation, after sending the query results and zero-knowledge proofs to the light node, the method further includes: continuously acquiring query records for each query field within a continuous time period, processing the query records based on a preset exponentially weighted moving average model, and calculating the real-time popularity value of the query field based on the processing results; matching the real-time popularity value with a preset popularity interval, and dividing each query field into a corresponding popularity region based on the matching results, wherein the popularity region includes hot spots, intermediate zones, and cold spots; determining the type of structural mutation to be performed on the target index structure from a preset set of structural mutation types based on the popularity region to which each query field belongs, wherein the set of structural mutation types includes hotspot expansion, path compression, and hotspot fusion; and performing the corresponding structural mutation operation on the target index structure according to the determined structural mutation type.

[0108] It should be noted that, for each query field, the blockchain full node continuously acquires query records for that field within a continuous time period and processes these records based on a preset exponentially weighted moving average model. The processing result is used to calculate the real-time popularity value of the query field, ensuring that the real-time popularity value takes into account both recent changes and historical trends. Subsequently, the real-time popularity value is matched with a preset popularity interval. Based on the matching result, each query field is divided into a corresponding popularity region, which includes hotspot areas, intermediate areas, and cold areas. This transforms the continuous real-time popularity value into partitioning semantics that can be used for strategy selection. Further, based on the popularity region to which each query field belongs, a preset set of structural mutation types is used to determine the type of structural mutation to be performed on the target index structure. This set includes hotspot expansion, path compression, and hotspot fusion, allowing different popularity regions to trigger different types of structural mutations. Finally, the corresponding structural mutation operation is performed on the target index structure according to the determined structural mutation type, achieving a dynamic balance between storage overhead and query efficiency.

[0109] Overall, this enables blockchain full nodes to continuously optimize the target index structure without changing the interaction method of light nodes, thereby improving query stability and resource utilization in long-term operation scenarios.

[0110] In one possible implementation, based on the popularity region to which each query field belongs, the type of structural mutation to be performed on the target index structure is determined from a preset set of structural mutation types, and the corresponding structural mutation operation is performed according to the determined structural mutation type, including:

[0111] When the query field is classified into the hot spot area, the real-time heat value is compared with the first preset threshold. If the real-time heat value is greater than the first preset threshold, the structural mutation type is determined to be hot spot expansion from the set of structural mutation types, and a multi-level secondary index is built in the target index structure based on the hot spot expansion for the query field.

[0112] When the query field is assigned to a cold zone, the miss duration of the index node corresponding to the query field in the target index structure is counted. The miss duration is compared with a preset duration threshold. If the miss duration exceeds the preset duration threshold, the structural mutation type is determined to be path compression from the set of structural mutation types. Based on path compression, the index node is reclaimed to release storage space.

[0113] When multiple query fields are assigned to hotspot areas, the difference between the real-time popularity values ​​of each query field is calculated. The difference is compared with a second preset threshold. If the difference is less than the second preset threshold, the structural mutation type is determined to be hotspot fusion from the set of structural mutation types. Based on hotspot fusion, the index paths of multiple query fields are aggregated into a unified composite index path.

[0114] It should be noted that this possible implementation further refines the decision rule of "determining the structural mutation type and performing structural mutation operation based on the popularity region to which each query field belongs", so that hotspot expansion, path compression and hotspot fusion no longer remain at the level of abstract selection, but establish clear triggering logic with real-time popularity value, miss duration and popularity difference between multiple query fields.

[0115] When a query field is assigned to a hotspot area, the real-time popularity value is compared with a first preset threshold. If the real-time popularity value is greater than the first preset threshold, the structural mutation type is determined to be hotspot expansion. Based on hotspot expansion, a multi-level secondary index is built in the target index structure for the query field, thereby giving the high-frequency query field in the hotspot area a more refined index organization to improve hit efficiency. When a query field is assigned to a coldspot area, the miss duration of the index node corresponding to the query field in the target index structure is statistically analyzed and compared with a preset duration threshold. If the miss duration exceeds the preset duration threshold, the structural mutation type is determined to be path compression. Based on path compression, index nodes are reclaimed to release storage space, so that the query field in the coldspot area no longer occupies too much structural resources. In addition, when multiple query fields are assigned to hotspot areas, the difference between the real-time popularity values ​​of each query field is calculated and compared with a second preset threshold. If the difference is less than the second preset threshold, the structural mutation type is determined to be hotspot fusion. Based on hotspot fusion, the index paths of multiple query fields are aggregated into a unified composite index path, so that similar popularity fields within the hotspot area can share index paths to reduce structural redundancy.

[0116] Therefore, the mapping between hot regions and the set of structural mutation types is refined into directly executable rules, so that the structural mutation operation of the target index structure can both tilt towards hot regions to improve query performance and shrink towards cold regions to control storage overhead. In multi-hot scenarios, hotspot fusion can reduce the maintenance cost caused by repeated paths.

[0117] In one possible implementation, before determining the type of structural mutation to be performed on the target index structure, the method further includes: obtaining the current state information of the target index structure and generating a version snapshot identifier based on the current state information; storing the version snapshot identifier locally and sending the version snapshot identifier to a light node; after performing the corresponding structural mutation operation on the target index structure according to the determined structural mutation type, the method further includes: setting a preset monitoring period; within the preset monitoring period, counting the number of verification failures and the total number of verifications of the mutated index structure; calculating the ratio between the number of verification failures and the total number of verifications; using the ratio as the verification failure rate; comparing the verification failure rate with a preset tolerance threshold; if the verification failure rate exceeds the tolerance threshold, obtaining the index structure state before the mutation based on the version snapshot identifier and rolling back the current index structure to the index structure state before the mutation.

[0118] It should be noted that the purpose of this possible implementation is to ensure that the target index structure remains verifiable and stable after a structural mutation operation, and to restore the index structure to its pre-mutation state in the event of anomalies. Specifically, before determining the type of structural mutation to be performed on the target index structure, the current state information of the target index structure is obtained, and a version snapshot identifier is generated based on this information. This identifier is then stored locally and sent to the blockchain light node, ensuring that the full blockchain node and the light node have a consistent identifier for the current index structure state, thus providing a basis for post-mutation verification and potential recovery. After performing the corresponding structural mutation operation on the target index structure according to the determined mutation type, a preset monitoring period is set, and the number of verification failures and the total number of verifications of the mutated index structure are counted within this period. The ratio of these two counts is used as the verification failure rate, allowing the impact of the index structure evolution to be reflected by a quantitative indicator. The verification failure rate is then compared with a preset tolerance threshold. When the failure rate exceeds the threshold, the pre-mutation index structure state is retrieved based on the version snapshot identifier, and the current index structure is rolled back to its pre-mutation state. This allows the system to promptly stop the damage to verifiability and restore a stable state.

[0119] Overall, by linking version snapshot identification with verification failure rate, structural mutation operations are no longer irreversible structural changes, but rather controlled evolution processes with monitoring and rollback capabilities, thereby improving the reliability and maintainability of the target index structure during dynamic optimization.

[0120] In this embodiment, by having the full blockchain node parse the query fields and determine their popularity after receiving query requests from the light node, index construction is triggered only when the field access frequency reaches a preset condition. This avoids the waste of resources caused by blindly creating indexes for all data and significantly reduces computational overhead. Subsequently, a target index structure is intelligently selected from a preset set of index structures based on the query type, ensuring that the index matches the specific query pattern type and improving the accuracy and efficiency of the query operation. Then, the query is executed based on the target index structure and verification information is generated. By compiling it into a Boolean circuit and converting it into a zero-knowledge proof, the light node can quickly verify the correctness and completeness of the results without trusting the full node, thereby significantly shortening the verification time while ensuring security.

[0121] Therefore, the method shown in the embodiments of this application realizes on-demand self-adaptive indexing and compressed verifiable proof output for dynamic blockchain environments, which improves query efficiency, effectively controls verification and communication overhead, and enhances the long-term stability of the blockchain system.

[0122] Figure 2 A flowchart of a field query method according to an embodiment of this application is shown. The method is applied to a blockchain light node, such as... Figure 2 As shown, the method includes:

[0123] Step S201: Generate a query request based on the data to be queried, and send the query request to the blockchain full node;

[0124] Step S202: Receive the query results, zero-knowledge proofs, and public verification parameters returned by the full blockchain node;

[0125] Among them, the zero-knowledge proof is generated by the blockchain full node based on the query request, and the public verification parameters are generated synchronously by the blockchain full node when generating the zero-knowledge proof;

[0126] Step S203: Obtain the block header information stored locally. Based on the block header information, public verification parameters, and zero-knowledge proof, perform verifiability verification on the query results to obtain the verification results.

[0127] If the verification result is passed, the query result is determined to be correct and complete.

[0128] It should be noted that, Figure 2The method shown is applied to blockchain light nodes, enabling them to initiate field queries and verify the returned results even under resource constraints, thus combining lightweight querying with trusted verification. The light node generates a query request based on the data to be queried and sends it to the full blockchain node, transmitting the query intent in the form of a query request. It then receives the query result, zero-knowledge proof, and public verification parameters returned by the full blockchain node. The zero-knowledge proof is generated by the full blockchain node based on the query request, and the public verification parameters are generated synchronously by the full blockchain node when generating the zero-knowledge proof. This combination of responses allows the light node to obtain not only the query result itself but also the supporting proof materials and verification inputs for verifiability verification. Further, the light node obtains the locally stored block header information and performs verifiability verification on the query result based on the block header information, public verification parameters, and zero-knowledge proof. When the verification result is successful, the query result is determined to be correct and complete, thus transforming "trustworthiness" into a conclusion that the light node can independently determine.

[0129] This allows blockchain light nodes to obtain verifiable query results without storing all on-chain data. Trustworthy confirmation is achieved through block header information and public verification parameters combined with zero-knowledge proofs, thereby improving the query availability and result credibility on the blockchain light node side.

[0130] In one possible implementation, verifiability verification is performed on the query results based on block header information, public verification parameters, and zero-knowledge proofs. This includes: extracting aggregate proofs from the zero-knowledge proofs; verifying the legality of the public verification parameters based on the block header information, and using the public verification parameters as verification inputs after successful verification; performing verification operations by substituting the verification inputs and aggregate proofs into the pairing verification equations based on a preset pairing verification equation; and determining the verification result based on the result of the verification operation: if the pairing verification equation is true, the verification result is determined to be successful; if the pairing verification equation is false, the verification result is determined to be unsuccessful.

[0131] It's important to note that the blockchain light node first extracts the aggregated proof from the zero-knowledge proof, ensuring that subsequent verification revolves around this aggregated proof. Simultaneously, the light node verifies the legality of public verification parameters based on the block header information. Upon successful verification, the public verification parameters are used as verification input. This arrangement prevents public verification parameters from directly participating in verification without constraints, thus guaranteeing a consistent foundation between the verification input and the block header information. Subsequently, the light node performs verification operations based on a pre-defined pairing verification equation, substituting the verification input and aggregated proof into the equation. The verification result is determined based on the verification operation result: if the pairing verification equation is true, the verification result is considered passed; if the pairing verification equation is false, the verification result is considered failed, providing a clear and reproducible judgment standard for the verification result.

[0132] Therefore, by connecting aggregated proofs, block header information, public verification parameters, verification inputs and paired verification equations, the verifiability verification on the blockchain lightweight node side has both a formal verification path and can naturally correspond to the aggregated proof generation method on the full node side, thereby achieving reliable confirmation of the correctness and completeness of query results under the premise of lightweightness.

[0133] This paper introduces a method for constructing a dynamic, verifiable query index for blockchain full nodes, based on specific application scenarios, supporting dynamic, verifiable user queries. The system architecture shown in this application includes the following main components (such as...). Figure 3 (as shown)

[0134] 1. Light Blockchain Nodes: Light nodes only store the block header information of the blockchain and do not store the complete blockchain data. When data needs to be queried, the light node sends a query request to the full node. After receiving the query result returned by the full node, the light node verifies the correctness and completeness of the query result based on the block header information it stores.

[0135] 2. Full Blockchain Node: Responsible for maintaining complete blockchain ledger data, possessing the ability to store complete transaction records, block header information, and state. In verifiable queries, the full node is responsible for dynamic index management, query popularity monitoring, and verification information generation, providing service responses and verification interfaces to light nodes. It is the execution entity for implementing dynamic index scheduling and zero-knowledge proof generation.

[0136] 3. Dynamic Authentication Index Network Module: This module is responsible for sensing query behavior and dynamically building adaptive index structures. By monitoring the access patterns, field popularity, and query types of query requests within the full node, it uses a multi-objective optimization function to evaluate the cost-effectiveness of various index structures. When certain trigger thresholds are met, it automatically builds or adjusts the corresponding indexes, supports evolutionary operations such as index mutation, path fusion, and redundancy pruning, and achieves on-chain maintenance of self-optimizing indexes.

[0137] 4. Zero-Knowledge Compressed Verification Module (ZKV): The Zero-Knowledge Compressed Verification Module is responsible for generating compressed and verifiable zero-knowledge proofs. It compiles query conditions into Boolean circuits and constructs corresponding proofs using zk-SNARK technology. Combining circuit block optimization and pairing aggregation algorithms, it compresses the proof volume and speeds up the verification process.

[0138] 5. Index Structure Detection Module: This module is responsible for real-time monitoring of the usage status and popularity changes of the index structure, and evaluating the index evolution trend based on the index weighted model. It automatically adjusts existing indexes using predefined mutation operators (such as hotspot expansion, path folding, and structure pruning), and combines version identification and failure rollback mechanisms to ensure the traceability and stability of index changes.

[0139] The dynamic authentication index network module will now be introduced in detail:

[0140] Currently, blockchain systems face large-scale data structures that are high-dimensional, multi-type, and tamper-proof. The main technical bottlenecks include: 1) High cold start latency: Newly added full nodes do not build pre-built query indexes, causing initial queries to traverse the entire chain of data, resulting in a complexity of O(n log n). 1) It is not conducive to the immediate response of lightweight nodes. 2) Static redundancy in index structure: Even if a static index is established, the space occupied is at most 2 to 3 times that of the original data, and most fields are not continuously hot spots, so fixed indexes bring low utilization problems. 3) Insensitive to hot spot bursts: The query mode changes drastically during runtime, and hot fields change significantly. Traditional indexes do not have the ability to "sense" and cannot adapt in time.

[0141] The dynamic authentication index network module is designed for all nodes, enabling index building to proactively adapt to the evolution of popular queries and dynamically generate and maintain verifiable data structures for different query types. The process is as follows:

[0142] 1. Basics of Full Node Data Indexing:

[0143] Blockchain data possesses inherent sequentiality; any data unit... It can be uniquely represented as:

[0144]

[0145] in, Represents the height of the block containing the data; This represents the transaction offset within that block. This tuple structure allows the index to avoid copying the original data, simply mapping it to its location. The dynamic authentication index network module does not directly record the original field values, but instead identifies them using lightweight fingerprints:

[0146]

[0147] in, For query fields (such as amount, contract address, etc.), the fingerprint is a fixed length of 32 bytes and has collision resistance.

[0148] 2. Dynamically constructed data indexes:

[0149] By monitoring all query requests within a time-sliding window, then... Representative field Number of queries, The total number of queries within the window period, the hotness condition that triggers the build is defined as:

[0150]

[0151] in, A threshold is set for the system to adjust query sensitivity, ensuring that indexes are created only for truly frequent fields. Within the aforementioned time window, structures are built for different data query types: 1) equality queries use hash tables; 2) range queries use B+ trees; 3) fuzzy queries use inverted indexes. Furthermore, based on changes in data popularity, a dynamic adaptation mechanism for the query structure is designed, meaning each index structure has the following utility metrics at time t:

[0152]

[0153] in, Hit rate Average query latency Storage occupied by this index (MB) : Prevent zero disturbance term, take , Adjustable weights (reflecting system preferences).

[0154] Weight updates follow a gradient strategy:

[0155]

[0156] in To optimize the speed, it is usually set to The index adapts to changes using the following three types of operations, as shown in Table 1.

[0157] Table 1

[0158]

[0159] A detailed analysis of the complexity of this design: Let... For data volume, Given the number of indexes already created, the expected query complexity is:

[0160]

[0161] As the size of the index system increases exponentially, the query time will approach constant level. The maximum storage space required for the constructed index is:

[0162]

[0163] Based on the utility function in the dynamic evolution engine It can be proved that the following convergence theorem applies in a finite number of mutation cycles. Then, if the index optimization space approaches convergence, then:

[0164]

[0165] At this point, the index reaches a local Pareto optimum, and the system is in a stable index state.

[0166] The zero-knowledge compression verification module will now be introduced in detail:

[0167] The inherent trustless nature of blockchain data requires query results to possess zero-trust verification capabilities. Current verification methods, such as Merkle Trees, have proven in practice to be large in size, time-consuming to generate, and unable to be aggregated in parallel. Specifically, at block heights of... In the chain, a Merkle path from a transaction to the root node contains There are 10 hash nodes. If the validation conditions contain multiple fields (especially range or logical combination queries), an additional Boolean circuit or lookup set needs to be constructed, resulting in a complexity of up to 100%. Meanwhile, proofs of multiple fields or batch results cannot be efficiently aggregated, and the verifier still needs to verify them one by one. To address this, the zero-knowledge compression verification module combines the generated query index to ensure the on-chain verifiability of off-chain query results.

[0168] 1. Query circuit generation process:

[0169] Any user query Generally by Composed of predicates:

[0170]

[0171] Each subquery Given a basic Boolean condition, ZKV compiles these conditions into a Boolean circuit. :

[0172]

[0173] in, It is the circuit block corresponding to each predicate. This is a vector of field values. In cases with multiple fields and independent conditions, the sub-circuit independence theorem applies:

[0174] like and The input fields do not overlap (i.e.: Then the total circuit can be decomposed into parallel sub-circuits:

[0175]

[0176] 2. Proof of the construction process:

[0177] The zero-knowledge compression verification module uses the zk-SNARK series of protocols for proof. This process does not reveal the original field values, and the communication volume is constant. Its design includes three phases:

[0178] 1) Circuit generation: The compiler constructs Boolean conditions into a constraint system.

[0179]

[0180] 2) Proof generation: The prover constructs a set of proofs. satisfy:

[0181]

[0182] in The prover (satisfying the circuit's input) has a generation complexity of O(n). .

[0183] 3) Verification: The verifier only needs constant time to verify. Perform pairing verification:

[0184]

[0185] 3. Aggregate proof mechanism:

[0186] In compound queries, each field may generate a separate proof. If the verification party needs to verify Each independent condition must be met. The communication complexity is O(n pairs). The ZKV module introduces a bilinear pair aggregation algorithm, and the proofs are as follows:

[0187]

[0188] Selecting the stochastic index Aggregates into:

[0189]

[0190] The verification method uniformly verifies whether the following equation holds true:

[0191]

[0192] This method can transfer composite query communication from Down to .

[0193] The ZKV module converts the index generated by the dynamic authentication index network into a circuit input, that is, the located fingerprint. Used as a circuit Input, verification Determine if the query is compounded and output verifiable proof: The light node received... Zero-knowledge verification is used to confirm that the fingerprint belongs to the query result set. This construction only makes the query result verifiable if it simultaneously satisfies both logical verification and on-chain location. To retrieve the output fingerprint, ZKV must satisfy the following:

[0194]

[0195] The index detection module will now be introduced in detail:

[0196] The above describes a dynamic adaptation mechanism for the query structure. Each index structure has the following utility metrics at time t. Based on this, the index detection module acts as a decision coordinator to address situations where a certain data field might suddenly become the focus of queries due to a short-term hot event; the access distribution changes continuously over time under alternating hot and cold cycles, with historically high-frequency fields potentially cooling down quickly; and multiple query dimensions may fluctuate in tandem, resulting in structural changes in access patterns. Based on real-time query popularity feedback, structural mutations are performed on the index structure to maintain globally optimal query efficiency.

[0197] 1. Behavior perception detection:

[0198] Set query fields The query sequence is a time function, and its popularity is defined as:

[0199]

[0200] These are the exponential weighting coefficients; For indicator functions, when It happens all the time The value is 1 for queries and 0 otherwise. This model uses EWMA (Exponential Weighted Moving Average), which is more sensitive to recent queries. Based on the popularity value... The interval distribution divides the fields into three categories, and the system adopts different indexing strategies for the three categories of regions, as shown in Table 2.

[0201] Table 2

[0202]

[0203] 2. Design of structural catastrophe operators:

[0204] This module proposes a set of heat-driven structural reconstruction operators, including:

[0205] 1) Hotspot expansion: Build multi-level, fine-grained secondary indexes for hotspot fields.

[0206] Applicable conditions:

[0207]

[0208] Operation definition:

[0209]

[0210] in Indicates in the field Based on the original index, add subfields (such as transaction amount under contract ID) as new index levels.

[0211] 2) Path compression reclaims index nodes that have not been hit for a long time, saving space and maintenance costs:

[0212] Applicable conditions:

[0213]

[0214] Operation definition:

[0215]

[0216] in Indicates a node with a certain index field. The subtree structure with the root can be understood as a "pruning" operation.

[0217] 3) Hotspot fusion aggregates query fields with similar query popularity into a unified index path, reducing multiple query jumps:

[0218] Applicable conditions:

[0219]

[0220] Operation definition:

[0221]

[0222] After aggregation, a multidimensional B+ tree structure is formed, which improves the efficiency of multi-field joint queries.

[0223] 3. Verify query structure control and management:

[0224] Each structural change in the index detection module is accompanied by version information generation to support auditing and rollback operations. Snapshot identifier generation:

[0225]

[0226] This identifier is also recorded locally on the light node, ensuring that all nodes have a consistent view of the index structure.

[0227] If the rollback mechanism is triggered and the new index structure verification fails, the failure rate will be affected. Exceeding the tolerance threshold :

[0228]

[0229] Ensure that index evolution does not affect query correctness. The index detection module interacts with the aforementioned modules, initiating a mutation request upon triggering a query popularity threshold. After assessing system resources and historical volatility, a decision is made regarding whether to perform a structural refactoring. It must be ensured that changes to the index structure do not affect the zero-knowledge proof structure, i.e., the updated index must be regenerated. Mapping rules; if the input set of the sub-circuit changes, ZKV needs to be refreshed. Mapping relationships; aggregated proofs can be buffered and generated before structural changes, avoiding on-chain verification failures.

[0230] The mutation stability theorem can be formally represented as: Let the evolution function be... Index structure If: all mutations satisfy ;

[0231] Evolution frequency ;

[0232] The system eventually converges to a stable set of indices:

[0233]

[0234] The final detection costs and benefits, unified into a utility function, can be formalized as follows:

[0235]

[0236] in, Increased hit rate Increased space usage Delayed change It is a system sensitivity factor.

[0237] In summary, the field query method shown in the embodiments of this application has the following technical effects:

[0238] 1. The embodiments of this application can realize a self-evolution mechanism for indexes under dynamic behavior awareness. Existing solutions are mostly based on static indexes or manually set field construction structures, lacking the ability to perceive query behavior. This solution introduces a real-time popularity model and a utility function-driven mutation strategy, enabling the system to adaptively adjust the index configuration according to user access behavior, realizing dynamic construction from a dynamic index paradigm, and improving the long-term operational stability and query efficiency of the blockchain system.

[0239] 2. The method described in this application provides a highly compressible and fast zero-knowledge proof mechanism. Addressing the challenges of traditional Merkle path proofs, which rely on a full-chain structure, are lengthy in verification, and have large proof volumes, this solution constructs a highly efficient and compressed ZKV mechanism through Boolean circuit segmentation, independent sub-circuit mapping, and zk-SNARK aggregation. This enables even lightweight nodes to complete highly reliable query verification with extremely low communication overhead. This mechanism, while ensuring privacy, balances performance and correctness, outperforming Merkle or pure ZKP solutions.

[0240] 3. The method described in this application supports dynamic index generation management and version consistency maintenance. Unlike existing strategies where indexes are built once and remain unchanged for a long time, this method introduces version snapshots and rollback protocols to ensure that index structure changes are auditable and consistent, avoiding mismatches between the index states of light nodes and full nodes. This mechanism supports tracking the index change process over time and quickly rolling back when verification fails, enhancing system security and stability.

[0241] 4. The method described in this application constructs a dynamic closed loop of query, verification, and indexing, systematically integrating the three major modules. It exhibits good portability and scalability in single-node, lightweight node, and even cross-chain environments. Compared to the fragmented structure of existing methods, this system has higher architectural integrity, performance adaptability, and upgradeability, demonstrating significant technological advancement.

[0242] Figure 4 This diagram illustrates a structural block diagram of a field query device according to an embodiment of this application. The device is applied to a blockchain full node, such as... Figure 4 As shown, the device 40 includes:

[0243] The receiving module 401 is used to receive query requests sent by blockchain light nodes, parse the query fields from the query requests, determine the field popularity based on the query fields, and determine whether the field popularity meets the preset index construction trigger conditions.

[0244] The first execution module 402 is used to parse the query type from the query request when the field popularity meets the index building trigger condition, and determine the target index structure from the preset index structure type set according to the query type.

[0245] Based on the target index structure, a query operation is performed on the query request to obtain the query result. Verification information is generated based on the location information of the query result in the target index structure. The verification information is compiled into a Boolean circuit and a zero-knowledge proof is generated based on the Boolean circuit.

[0246] Send the query results and zero-knowledge proof to the light node.

[0247] Figure 5 This diagram illustrates a structural block diagram of a field query device according to an embodiment of this application. The device is applied to a blockchain light node, such as... Figure 5 As shown, the device 50 includes:

[0248] The sending module 501 is used to generate a query request based on the data to be queried and send the query request to the full node of the blockchain.

[0249] The second execution module 502 is used to receive the query results, zero-knowledge proof and public verification parameters returned by the blockchain full node. The zero-knowledge proof is generated by the blockchain full node based on the query request, and the public verification parameters are generated synchronously by the blockchain full node when generating the zero-knowledge proof.

[0250] Retrieve the block header information stored locally. Based on the block header information, public verification parameters, and zero-knowledge proof, perform verifiability verification on the query results to obtain the verification result. If the verification result is successful, the query results are determined to be correct and complete.

[0251] Overall, the method described in this application introduces a dynamic authentication index network to construct a self-evolving index structure. The dynamic authentication index network structure is designed to dynamically evaluate query popularity and drive the organic evolution of the index structure. A sliding window statistical popularity function is used to identify hot fields in real time and automatically perform index expansion, folding, or pruning operations. It supports flexible switching between multiple index structures (hash tables, B+ trees, inverted indexes) and dynamically performs structural mutations based on system load and query frequency, enabling the system to continuously maintain optimal index configuration without manual intervention.

[0252] To support privacy-friendly verifiable queries, a zero-knowledge compression verification mechanism is constructed. The ZKV module maps the query logic to Boolean circuits, and lightweight zero-knowledge proofs are generated using zk-SNARK, effectively compressing the verification information volume. Simultaneously, circuit block optimization and proof aggregation mechanisms are introduced, allowing multiple conditional sub-circuits to be generated independently and aggregated in parallel, reducing generation and verification time and ensuring that lightweight nodes can complete result verification without accessing the original data.

[0253] The design incorporates an index structure mutation driver to achieve real-time index strategy scheduling. This module, based on the EWMA heat decay model, senses changes in query behavior and performs mutation control on the index structure in the dynamically certified index network. Operators such as hotspot expansion, path compression, and field fusion precisely control the direction of structural evolution, while version snapshots and rollback mechanisms ensure index stability and consistency. The three modules are integrated into a unified query system, enabling control over index construction, verification generation, and structural adjustment. Queries begin with heat assessment, dynamically determining the index strategy and generating aggregatable ZKV for rapid verification by lightweight nodes. This workflow supports on-chain result verification, structural snapshot synchronization, and multi-party proof sharing, ensuring consistent verification capabilities of query results across all nodes on the chain while maintaining system performance.

[0254] This application provides a network device 60, such as... Figure 6 As shown, the network device 60 includes a processor 601, a memory 602, and a program stored in the memory 602 and executable on the processor 601. When the program is executed by the processor 601, it implements the steps of a field query method as shown in the above embodiment.

[0255] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the steps of a field query method as shown in the above embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0256] This application also provides a computer program product, including computer instructions. When executed by a processor, the computer instructions implement the steps of the field query method shown in the above embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0257] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0258] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0259] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A field query method, characterized in that, The method is applied to a blockchain full node, and the method includes: Receive a query request sent by a blockchain light node, parse the query field from the query request, determine the field popularity based on the query field, and determine whether the field popularity meets the preset index construction triggering conditions; If the field popularity meets the index building trigger condition, the query type is parsed from the query request, and the target index structure is determined from the preset index structure type set according to the query type; Based on the target index structure, a query operation is performed on the query request to obtain the query result. Verification information is generated according to the location information of the query result in the target index structure. The verification information is compiled into a Boolean circuit, and a zero-knowledge proof is generated according to the Boolean circuit. The query results and the zero-knowledge proof are sent to the light node.

2. The method according to claim 1, characterized in that, The field popularity is determined based on the query field, and it is determined whether the field popularity meets the preset index building trigger conditions, including: Set a time-sliding window, count the number of queries for each query field within the time-sliding window, and count the total number of queries for all query requests within the time-sliding window; The ratio between the number of queries and the total number of queries is calculated, and the ratio is used as the field popularity of each query field. The field popularity is compared with a preset popularity threshold. If the field popularity is greater than the popularity threshold, the query field is determined to meet the index construction triggering condition.

3. The method according to claim 2, characterized in that, The set of index structure types includes hash tables, B+ trees, and inverted indexes; the target index structure is determined from the preset set of index structure types according to the query type, including: Based on the preset correspondence between the query type and each index structure type in the index structure type set, candidate index structures matching the query type are selected from the index structure type set; wherein, the query type includes equality query, range query and fuzzy query, the equality query corresponds to the hash table, the range query corresponds to the B+ tree, and the fuzzy query corresponds to the inverted index; For each of the selected candidate index structures, the performance parameters of the candidate index structure are evaluated based on the structural characteristics of the candidate index structure. The performance parameters include hit rate, average query latency, and storage overhead. The performance parameters are input into a preset multi-objective utility function, and the utility value of each candidate index structure is calculated by the multi-objective utility function; wherein, the optimization objectives of the multi-objective utility function include maximizing the hit rate, minimizing the query latency, and minimizing the storage overhead; The utility values ​​of each candidate index structure are compared, and the candidate index structure with the highest utility value is determined as the target index structure.

4. The method according to claim 1, characterized in that, The verification information is compiled into a Boolean circuit, and a zero-knowledge proof is generated based on the Boolean circuit, including: The query conditions are parsed from the query request and then decomposed into multiple sub-words. For each of the sub-words, the sub-words are compiled into corresponding sub-circuits, and input fields are extracted from each of the sub-circuits; Obtain the input fields of each sub-circuit and determine whether there is any overlap between the input fields of each sub-circuit; if there is no overlap between the input fields of each sub-circuit, then mark each sub-circuit as an independent sub-circuit that can be processed in parallel. Based on the concise non-interactive zero-knowledge proof zk-SNARK protocol, a proof generation operation is performed on each of the independent sub-circuits to obtain a sub-proof corresponding to each of the independent sub-circuits. An aggregation operation is performed on each of the sub-proofs, and the output of the aggregation operation is used as the zero-knowledge proof.

5. The method according to claim 4, characterized in that, Performing an aggregation operation on each of the sub-proofs, and using the output of the aggregation operation as the zero-knowledge proof, includes: Extract proof elements from each of the sub-proofs; Generate a random index, and use the random index to weight each of the proof elements to obtain the weighted proof elements; Based on a pre-defined bilinear pairing aggregation algorithm, the weighted proof elements are aggregated into a single aggregated proof. The aggregated proof is used as the zero-knowledge proof; Specifically, while generating the zero-knowledge proof, a common verification parameter corresponding to the zero-knowledge proof is generated, and the common verification parameter is sent to the light node.

6. The method according to any one of claims 1-5, characterized in that, After sending the query result and the zero-knowledge proof to the light node, the method further includes: For each of the query fields, query records for the query fields within a continuous time period are continuously acquired. The query records are processed based on a preset exponentially weighted moving average model, and the real-time popularity value of the query field is calculated based on the processing results. The real-time popularity value is matched with a preset popularity range, and each query field is divided into a corresponding popularity region based on the matching result. The popularity region includes a hot spot area, a middle area and a cold spot area. Based on the popularity region to which each of the query fields belongs, the structural mutation type to be performed on the target index structure is determined from a preset set of structural mutation types, wherein the set of structural mutation types includes hotspot expansion, path compression, and hotspot fusion; Based on the determined structural mutation type, the corresponding structural mutation operation is performed on the target index structure.

7. The method according to claim 6, characterized in that, Based on the popularity region to which each of the query fields belongs, determine the type of structural mutation to be performed on the target index structure from a preset set of structural mutation types, and perform the corresponding structural mutation operation according to the determined structural mutation type, including: When the query field is assigned to the hotspot area, the real-time popularity value is compared with a first preset threshold. If the real-time popularity value is greater than the first preset threshold, the structural mutation type is determined to be hotspot expansion from the set of structural mutation types, and a multi-level secondary index is constructed in the target index structure based on the hotspot expansion for the query field. When the query field is assigned to the cold zone, the miss duration of the index node corresponding to the query field in the target index structure is counted, and the miss duration is compared with a preset duration threshold. If the miss duration exceeds the preset duration threshold, the structural mutation type is determined to be path compression from the set of structural mutation types, and the index node is reclaimed based on the path compression to release storage space. In the case where multiple query fields are all assigned to the hotspot area, the difference between the real-time popularity values ​​of each query field is calculated, and the difference is compared with a second preset threshold. If the difference is less than the second preset threshold, the structural mutation type is determined to be hotspot fusion from the set of structural mutation types, and the index paths of multiple query fields are aggregated into a unified composite index path based on the hotspot fusion.

8. The method according to claim 6, characterized in that, Before determining the type of structural mutation to be performed on the target index structure, the method further includes: Obtain the current status information of the target index structure, and generate a version snapshot identifier based on the current status information; The version snapshot identifier is stored locally and then sent to the light node. After performing the corresponding structural mutation operation on the target index structure according to the determined structural mutation type, the method further includes: Set a preset monitoring period. Within the preset monitoring period, count the number of verification failures and the total number of verifications of the index structure after the mutation. Calculate the ratio between the number of verification failures and the total number of verifications, and use the ratio as the verification failure rate. The verification failure rate is compared with a preset tolerance threshold; if the verification failure rate exceeds the tolerance threshold, the index structure state before the mutation is obtained based on the version snapshot identifier, and the current index structure is rolled back to the index structure state before the mutation.

9. A field query method, characterized in that, The method is applied to a blockchain light node, and the method includes: Generate a query request based on the data to be queried, and send the query request to the full node of the blockchain; The system receives the query results, zero-knowledge proof, and public verification parameters returned by the blockchain full node. The zero-knowledge proof is generated by the blockchain full node based on the query request, and the public verification parameters are generated synchronously by the blockchain full node when generating the zero-knowledge proof. Obtain the block header information stored locally, and perform verifiability verification on the query result based on the block header information, the public verification parameters, and the zero-knowledge proof to obtain the verification result. If the verification result is successful, the query result is determined to be correct and complete.

10. The method according to claim 9, characterized in that, Based on the block header information, the public verification parameters, and the zero-knowledge proof, a verifiability check is performed on the query result, including: Extract the aggregated proof from the zero-knowledge proof; The public verification parameters are validated based on the block header information. If the validation passes, the public verification parameters are used as the validation input. Based on the preset pairwise verification equation, the verification input and the aggregated proof are substituted into the pairwise verification equation to perform the verification operation; The verification result is determined based on the result of the verification operation: if the pairing verification equation is true, the verification result is determined to be passed; if the pairing verification equation is false, the verification result is determined to be failed.

11. A field query device, characterized in that, The device is used in a blockchain full node, and the device includes: The receiving module is used to receive query requests sent by blockchain light nodes, parse the query fields from the query requests, determine the field popularity based on the query fields, and determine whether the field popularity meets the preset index construction trigger conditions. The first execution module is used to parse the query type from the query request when the field popularity meets the index building triggering condition, and determine the target index structure from the preset index structure type set according to the query type; Based on the target index structure, a query operation is performed on the query request to obtain the query result. Verification information is generated according to the location information of the query result in the target index structure. The verification information is compiled into a Boolean circuit, and a zero-knowledge proof is generated according to the Boolean circuit. The query results and the zero-knowledge proof are sent to the light node.

12. A field query device, characterized in that, The device is used in a blockchain light node, and the device includes: The sending module is used to generate a query request based on the data to be queried and send the query request to the full node of the blockchain; The second execution module is used to receive the query result, zero-knowledge proof, and public verification parameters returned by the blockchain full node, wherein the zero-knowledge proof is generated by the blockchain full node based on the query request, and the public verification parameters are generated synchronously by the blockchain full node when generating the zero-knowledge proof; Obtain the block header information stored locally, and perform verifiability verification on the query result based on the block header information, the public verification parameters, and the zero-knowledge proof to obtain the verification result. If the verification result is successful, the query result is determined to be correct and complete.

13. A network device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, it implements the steps of a field query method as described in any one of claims 1 to 8, or, when the program is executed by the processor, it implements the steps of a field query method as described in any one of claims 9 to 10.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of a field query method as described in any one of claims 1 to 8, or, when executed by the processor, implements the steps of a field query method as described in any one of claims 9 to 10.

15. A computer program product, characterized in that, The method includes computer instructions that, when executed by a processor, implement the steps of a field query method as described in any one of claims 1 to 8, or, when executed by the processor, implement the steps of a field query method as described in any one of claims 9 to 10.

Images