Multi-service provider oriented fine-grained verifiable data query method and system

Abstract

The present application relates to a kind of multi-service provider-oriented fine-grained verifiable data query method and system, data owner obtains the data unit of original data, according to the sub-data of data unit being stored by service provider, data unit commitment is generated using vector commitment and RSA accumulator, and then chain summary is obtained based on data unit commitment;Data owner chains on-chain summary;Query user initiates query request to target service provider;Target service provider retrieves local database in response to query request, obtains the query result that meets query request and constructs multi-layer verification object, including data layer verification object, unit layer verification object and row column / surface layer verification object;Target service provider returns query result and multi-layer verification object to query user;Query user issues request to chain and obtains chain summary required for query result;And query result is verified in multiple layers in combination with chain summary and the source of error data is realized fine-grained positioning.

Description

Technical Field

[0001] This invention relates to the fields of data security and blockchain technology, and in particular to a fine-grained verifiable data query method and system for multiple service providers. Background Technology

[0002] The statements in this section are merely background information relating to this disclosure and do not necessarily constitute prior art.

[0003] With the surge in data generation from terminal devices, data owners often outsource data to service providers to alleviate local storage and computing pressure. However, the semi-trustworthy nature of service providers leads to the risk of outsourced data being tampered with or damaged. Hybrid storage blockchain technology provides a solution for data query credibility by storing data verification roots on-chain and storing original data and generating verification objects off-chain by service providers. However, existing solutions, such as the literature "Fine-grained query authentication based on hybrid storage blockchain", have the following key problems: (1) Insufficient adaptation to multiple service providers: Most existing solutions are designed based on the scenario of "a single service provider storing all data", without considering the actual needs of multiple service providers to divide the storage of data. Data distribution is complex in a multi-service provider environment, and existing solutions do not design a data query verification mechanism for multi-service provider scenarios; (2) Insufficient compatibility of verification structure with multi-source data: Existing solutions are based on the premise of "ordered data from a single data source" and achieve verification by designing a verifiable data structure. However, in the scenario of multiple service providers, the same data dimension may be scattered among different service providers. The data formats and update frequencies of each service provider are different. The verification structure of the comparison file is difficult to integrate and verify the multi-source data in a unified manner, which easily leads to the verification failure problem caused by "data silos"; (3) Data skew and redundant query: The data distribution in multiple service providers is skewed, making it difficult for users to quickly locate the service provider storing the target data, which easily generates a large number of redundant queries and limits the practicality of verifiable queries.

[0004] Taking a medical scenario as an example, a hospital possesses a large number of medical records. Based on cost-benefit analysis, the data owner may outsource data for different disease types to different service providers. For instance, for records of acute illnesses such as gastroenteritis and heart disease, they might prefer a service provider with a fast response time (1); for records of illnesses requiring long-term monitoring and maintenance, such as hypertension and hyperglycemia, they might prefer a stable and reliable service provider (2); and for records where all values ​​are within the normal range, they might prefer a low-cost service provider (n). The data owner generates a verifiable data structure and sends the original data and the verifiable data structure to multiple off-chain service providers. A diabetes research institution needs to query information for all diabetic patients within a certain age range, such as <age: [50, 70], fasting blood glucose value: [100, 200]>. Service providers with data matching the query range need to return the results. However, some service providers might maliciously return tampered records. If the institution cannot locate the specific erroneous data after receiving the query results, it must discard all results returned by that service provider, including any correct data, reducing data utilization. Furthermore, the user must resubmit the query request, increasing transmission costs.

[0005] Therefore, in order to address the pain points of redundant queries, high on-chain storage overhead, and difficulty in error location in multi-service provider data storage scenarios, this invention deeply integrates hybrid storage blockchain technology with fine-grained verification technology to build a verifiable data query system that supports collaboration among multiple service providers. While ensuring the authenticity and completeness of data query results, it locates specific erroneous data entries and reduces on-chain storage costs and query verification overhead, thereby improving the practicality and efficiency of data query in multi-service provider environments. Summary of the Invention

[0006] To address, or at least partially address, the aforementioned technical problems, this invention provides a fine-grained verifiable data query method and system for multiple service providers.

[0007] In a first aspect, the present invention provides a fine-grained, verifiable data query method for multiple service providers, comprising:

[0008] The data owner organizes the raw data into a two-dimensional matrix or a multi-dimensional cube according to the dimensions and obtains data units. Based on the sub-data stored by the service provider, the data unit owner generates a data unit commitment for the data unit using vector commitment and RSA accumulator, and then obtains an on-chain digest based on the data unit commitment.

[0009] The data owner uploads the on-chain digest to the blockchain digest storage contract;

[0010] The querying user requests the blockchain to obtain the target service provider for the corresponding query request, and then initiates the query request to the target service provider;

[0011] After receiving a query request from a user, the target service provider retrieves the query results from its local database. The target service provider then constructs multi-layered validation objects for the query results, including data layer validation objects, cell layer validation objects, and row / column / face layer validation objects. Finally, the target service provider returns the query results and validation objects to the user.

[0012] After receiving the returned query results and verification object, the querying user sends a request to the blockchain to obtain the on-chain digest required for the query results; and performs multi-level verification on the query results in combination with the on-chain digest; if the verification fails, the multi-level verification results are used to locate the source of the erroneous data.

[0013] Furthermore, the data owner organizes the raw data into a matrix or multidimensional cube by dimension and obtains data units. Based on the sub-data stored by the service provider, the data unit generates a data unit commitment using vector commitments and an RSA accumulator. Then, based on the data unit commitment, an on-chain digest is obtained, including:

[0014] Data owners organize their raw data according to dimensions into a two-dimensional matrix or a multi-dimensional cube containing data units;

[0015] Obtain the sub-data of the data unit, which is distributed across multiple service providers. Generate a vector commitment for the sub-data stored by each service provider. Aggregate all the sub-data vector commitments of the data unit to obtain the data unit commitment.

[0016] Generate an on-chain digest based on the data unit commitment.

[0017] Furthermore, the on-chain digest uses row-column digests and / or facet digests; the process of generating row-column digests and / or facet digests based on data unit commitments includes:

[0018] The cell commitments are obtained row by row according to the two-dimensional matrix of data, and a row summary is generated for each cell commitment in each row of the two-dimensional matrix using an RSA accumulator; the cell commitments are obtained column by column, and a column summary is generated for each cell commitment in each column of the two-dimensional matrix using an RSA accumulator.

[0019] The cell commitments are obtained face by face from the multidimensional cube of data, and a face summary is generated from the cell commitments of each face of the multidimensional cube using an RSA accumulator.

[0020] Furthermore, the on-chain digest uses an aggregate digest; the process of generating an aggregate digest based on the data unit commitment includes:

[0021] The cell commitments are obtained row by row according to the two-dimensional matrix of data, and a row summary is generated for each cell commitment in each row of the two-dimensional matrix using an RSA accumulator; the cell commitments are obtained column by column, and a column summary is generated for each cell commitment in each column of the two-dimensional matrix using an RSA accumulator.

[0022] The cell commitments are obtained face by face according to the multidimensional cube of data, and the RSA accumulator is used to generate a face summary of the cell commitments of each face of the multidimensional cube.

[0023] The RSA accumulator aggregates all row and column summaries or aggregates all face summaries to obtain an aggregated summary of row and column summaries or face summaries.

[0024] Furthermore, the querying user requests the blockchain to obtain the target service provider for the corresponding query request. The process of initiating a query request to the target service provider includes: in the blockchain routing smart contract, building a Bloom filter for each data field of each service provider and recording the range of data values ​​stored by the service provider.

[0025] After a user initiates a query request to the blockchain, the blockchain executes a routing smart contract to process the query request, including: the routing smart contract parses the fields and value ranges of the query request as query conditions; for each service provider, it calls the Bloom filter of the corresponding field according to the query conditions to check whether it matches the value range containing the query conditions; and returns a list of all matching service providers to the user.

[0026] The querying user only sends data query requests to the target service providers in the returned list of service providers.

[0027] Furthermore, after receiving a query request from a user, the target service provider retrieves the local database, obtains query results that match the query request, and constructs a multi-layered validation object, including:

[0028] After receiving a query request from a user, each target service provider searches its local database and combines the search results and boundary results to obtain query results that match the query request.

[0029] Each target service provider generates a multi-layered validation object for the query results. The multi-layered validation object includes:

[0030] Data layer verification object: For each service provider's sub-data in the search results, generate the location proof of each grandchild data, and aggregate all the location proofs of the grandchild data of the sub-data into a data layer verification object;

[0031] Unit-level verification object: Generates the membership proof of the vector commitment of the sub-data of any data unit stored by any service provider in the data unit commitment of that data unit, and aggregates the membership proofs of the vector commitments of all sub-data of the data unit in the data unit commitment into a unit-level verification object;

[0032] Row / Column / Surface Validation Object: Promises a data cell to generate its row proof in the row digest; promises a data cell to generate its column proof in the column digest; aggregates the row and column proofs of the cell promises into a row / column / surface validation object.

[0033] Furthermore, after receiving a query request from a user, the target service provider retrieves the local database, obtains query results that match the query request, and constructs a multi-layered validation object, including:

[0034] After receiving a query request from a user, each target service provider searches its local database and combines the search results and boundary results to obtain query results that match the query request.

[0035] Each target service provider generates a multi-layered validation object for the query results. The multi-layered validation object includes:

[0036] Data layer verification object: For each service provider's sub-data in the search results, generate the location proof of each grandchild data, and aggregate all the location proofs of the grandchild data of the sub-data into a data layer verification object;

[0037] Unit-level verification object: Generates the membership proof of the vector commitment of the sub-data of any data unit stored by any service provider in the data unit commitment of that data unit, and aggregates the membership proofs of the vector commitments of all sub-data of the data unit in the data unit commitment into a unit-level verification object;

[0038] Row / Column / Surface Validation Object: Promises a data cell to generate its row proof in the row digest; promises a data cell to generate its column proof in the column digest; aggregates the row and column proofs of the cell promises into a row / column / surface validation object.

[0039] Aggregate layer verification object: Generates a proof of existence of the row and column digest in the aggregate digest.

[0040] Furthermore, by combining on-chain digests and multi-layered verification objects, the query results are verified in multiple layers. If verification fails, the source of the error is located, including:

[0041] Data layer validation is performed using the data layer validation object of the query results, based on the sub-data of the data unit stored by the service provider. and its vector commitment Sun Data (v) Location proof and index , call To verify each piece of grandchild data for each target service provider in the search results. ( v Does it actually exist in the sub-data? If verification fails, locate the erroneous data as follows: ( v ), service provider l For storing sub-data Target service providers;

[0042] Perform unit-level validation using the unit-level validation object of the query results. Utilize unit-level validation based on the service provider... l Data unit commitment of stored data unit Sub-data of a data unit Vector commitment Sub-data Vector commitment In data unit commitment Membership proof and target service provider identification l Call To verify service providers l Sub-data of stored data units Is it a data unit? Members; if it fails, the location error occurs, and the sub-data... Not a data unit Members, target service providers l For the evildoer;

[0043] Row and column summary validation is performed using the row and column summaries of the query results, based on cell-based data unit commitments. , proof of line and verify the true line summary , call Verify data unit commitment Whether it actually exists in the row summary, cell-based data unit commitment List of proofs and verify the true column summary , call Verify data unit commitment Does it actually exist in the column summary? If it fails, locate the error cell. ;

[0044] Range and data integrity verification:

[0045] Range integrity verification: Verify the integrity of the query boundary (BR) by validating the actual row and column summaries;

[0046] Data integrity: through sub-data The number of vector commitments is checked to ensure that no child data is missing in the cell.

[0047] Furthermore, by combining on-chain digests and multi-layered verification objects, the query results are verified in multiple layers. If verification fails, the source of the error is located, including:

[0048] Data layer validation is performed using the data layer validation object of the query results, based on the sub-data of the data unit stored by the service provider. and its vector commitment Sun Data ( v Proof of location and index , call To verify each piece of grandchild data for each target service provider in the search results. (v) Does it actually exist in the subdata? If verification fails, locate the erroneous data as follows: ( v Service provider l is responsible for storing sub-data. Target service providers;

[0049] Unit-level validation is performed using the unit-level validation object of the query results. Unit-level validation is then used to establish data unit commitments based on the data units stored by the service provider. Sub-data of a data unit Vector commitment Sub-data Vector commitment In data unit commitment Membership proof and target service provider identification l Call To verify the sub-data of the data unit stored by the service provider. Is it a data unit? Members; if it fails, the location error occurs, and the sub-data... Not a data unit Members, target service providers l For the evildoer;

[0050] First, retrieve the row and column summaries for the query user. / Based on row and column summaries / Aggregated summary Row and column summary / In aggregate summary Existence proof in Call and Verify the authenticity of the row and column summaries; after verifying the authenticity of the row and column summaries, commit the data units based on the cells. , proof of line and verify the true line summary , call Verify data unit commitment Whether it truly exists in the row summary, cell-based data unit commitment List of proofs and verify the true column summary , call Verify data unit commitment Does it actually exist in the column summary? If it fails, locate the error cell. ;

[0051] Range and data integrity verification:

[0052] Range integrity verification: Verify the integrity of the query boundary (BR) by verifying the actual row and column summaries;

[0053] Data integrity: through sub-data The number of vector commitments is checked to ensure that no child data is missing in the cell.

[0054] Secondly, the present invention provides a fine-grained verifiable data query system for multiple service providers, including a data owner module, a query user module, and a hybrid storage blockchain module incorporating blockchain and multiple service providers. The modules interact through a preset protocol, as detailed below:

[0055] The data owner module is configured with at least the following components: a data organization unit, which organizes the data owner's original data into a two-dimensional matrix or a multi-dimensional cube; a verifiable data structure generation unit, which generates vector commitments, row / column / face summaries, and aggregate summaries of structured data units based on vector commitments and RSA accumulators; and a summary uploading unit, which uploads the verifiable data structure summary to the summary storage contract unit of the hybrid storage blockchain, whereby the blockchain's summary storage contract unit stores the received summary and the blockchain's record storage unit generates an immutable record.

[0056] The hybrid storage blockchain module comprises multiple service providers and a blockchain for data management. The service providers are configured with at least the following: a data storage unit that stores the raw data outsourced by the data owner and corresponding data unit commitments; a verification object generation unit that, upon receiving a query request from a user, generates verification objects at the data layer, unit layer, row / column / face layer, and aggregation layer; and a result return unit that returns the query result and the verification objects to the user. The blockchain is configured with at least the following: a digest storage contract unit that stores on-chain digests uploaded by the data owner; a routing smart contract unit that deploys Bloom filters for each service provider's fields to locate the target service provider based on the query request from the user module; and a record storage unit that stores data upload, usage, and transaction records to ensure data traceability.

[0057] The user query module is configured with at least the following: a query initiation unit, which generates a multi-dimensional query request and locates the target service provider through the blockchain's routing smart contract unit to send the query request; a result verification unit, which verifies the authenticity and completeness of the query result in multiple layers by combining the digest on the blockchain; and an error location unit, which locates the specific location of the erroneous data based on the verification result if the verification fails.

[0058] The technical solutions provided in the embodiments of the present invention have the following advantages compared with the prior art:

[0059] This disclosure provides a fine-grained error localization mechanism for multiple service providers. Through a three-layer verification process of "data layer - unit layer - row / column / surface layer", users can verify the correctness and completeness of query results from all service providers in a single verification, avoiding the cumbersome process of multiple rounds of independent verification, significantly improving verification efficiency, and adapting to complex real-world scenarios where multiple service providers share storage. When verification fails, the erroneous data can be located to the specific service provider and specific data entry, avoiding the abandonment of the overall results, improving data utilization, and solving the problems of difficult error tracing and high accountability costs in multi-service provider scenarios.

[0060] This disclosure implements on-chain storage optimization, significantly reducing blockchain storage overhead through digest aggregation. Correspondingly, a fine-grained error localization mechanism for multiple service providers adaptively verifies through an "aggregation layer-data layer-unit layer-row / column / surface layer," pinpointing erroneous data to specific service providers and data entries, preventing overall result discarding and improving data utilization. This disclosure optimizes on-chain digest storage, adapting to ultra-large-scale multi-source data. Through digest aggregation, it significantly reduces blockchain storage overhead while avoiding blockchain storage fragmentation caused by multiple service providers independently storing digests, thus adapting to the storage and verification needs of ultra-large-scale multi-source data.

[0061] This disclosure provides a routing mechanism based on Bloom filters, which improves query efficiency and enables rapid location of target service providers. The Bloom filter-based routing mechanism quickly filters out a list of service providers that may contain the target data. Users only need to send data query requests to the matched target service providers, eliminating the need for "traversal" requests to all service providers, thus improving query efficiency.

[0062] This disclosure provides security guarantees for data queries. Based on the security of anti-collision hash digests, RSA accumulators and vector commitments, combined with the immutability of blockchain, it ensures that malicious service providers cannot forge verified results, thus meeting the requirements for data authenticity and integrity. Attached Figure Description

[0063] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0064] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0065] Figure 1 A flowchart illustrating a fine-grained, verifiable data query method for multiple service providers, provided as an embodiment of the present invention;

[0066] Figure 2 for Figure 1 The given embodiments provide a flowchart for generating on-chain digests in the form of row and column digests or face digests;

[0067] Figure 3 for Figure 1 The given embodiment provides a flowchart of the target service provider responding to a query request, obtaining query results that match the query request, and constructing a multi-layered verification object;

[0068] Figure 4 for Figure 1 The given embodiment provides a flowchart of multi-level verification of query results by combining on-chain digests and multi-level verification objects, and locating the source of the error if the verification fails.

[0069] Figure 5 A flowchart illustrating a fine-grained, verifiable data query method for multiple service providers, provided as an embodiment of the present invention;

[0070] Figure 6 for Figure 2 The given embodiment provides a flowchart for generating an on-chain digest in the form of an aggregated digest;

[0071] Figure 7 for Figure 2 The given embodiment provides a flowchart of the target service provider responding to a query request, obtaining query results that match the query request, and constructing a multi-layered verification object;

[0072] Figure 8 for Figure 2 The given embodiment provides a flowchart of multi-level verification of query results by combining on-chain digests and multi-level verification objects, and locating the source of the error if the verification fails.

[0073] Figure 9 This is a schematic diagram of a fine-grained verifiable data query system for multiple service providers provided in an embodiment of the present invention. Detailed Implementation

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

[0075] 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. Without further limitation, 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 said element.

[0076] The purpose of this invention is to overcome the shortcomings of the prior art and provide a fine-grained verifiable data query method for multiple service providers. By including a hierarchical verification structure, summary aggregation and Bloom filter routing, it realizes fine-grained verification, error location and efficiency optimization of data query in multi-service provider scenarios.

[0077] Example 1

[0078] like Figure 1 As shown, this embodiment of the invention provides a fine-grained verifiable data query method for multiple service providers, including:

[0079] S100 performs system module initialization and cryptographic tool deployment.

[0080] Specifically, data owners, service providers, and query users initialize their roles and identities on the hybrid storage blockchain; public and private key pairs are generated for data owners, service providers, and query users through an asymmetric encryption algorithm, and the public key is uploaded to the blockchain for record-keeping in the hybrid storage blockchain for subsequent data encryption and signing.

[0081] The required cryptographic tools include:

[0082] RSA accumulator: The RSA accumulator generates the public key. (N is the product of large prime numbers, g is the generator of the cyclic group, (a quadratic residue group of N) and the private key , used to generate aggregate summaries and membership proofs;

[0083] Vector Commitment: Generating Common Parameters (λ is the security parameter, n is the vector length), used to generate data unit commitments and location proofs.

[0084] In S200, the data owner organizes the raw data into a matrix or multi-dimensional cube according to its dimensions and obtains data units. Based on the sub-data stored by the service provider, a data unit commitment is generated using vector commitments and an RSA accumulator. Then, an on-chain digest for verification is obtained based on the data unit commitment. This step achieves the generation of verifiable data structures, such as... Figure 3 As shown, it specifically includes:

[0085] S201, the data owner organizes its original data into a two-dimensional matrix or a multi-dimensional cube according to the data dimensions; the data in the form of a two-dimensional matrix or a multi-dimensional cube has data units, where the data units of the two-dimensional matrix data are cells, and the data units of the multi-dimensional cube data are cube units, corresponding to the intersection units of the three-dimensional fields.

[0086] S202, generating a data unit commitment for a data unit, including: obtaining sub-data of the data unit distributed across multiple service providers, generating a vector commitment for the sub-data stored for each service provider, and aggregating all sub-data vector commitments of the data unit to obtain a data unit commitment.

[0087] Taking two-dimensional matrix data as an example, its data unit is a cell: for any cell (in the i-th row and j-th column), if its data is distributed across k service providers, then... Represents any service provider l Stored cells Sub-data, sub-data stored for each service provider. Generate Vector Commitment Aggregate all sub-data in the same cell. Vector commitment The cell commitment that generated this cell Similarly, for data in the form of multidimensional cubes, the generation of cube unit commitments is also possible.

[0088] S203, Generate an on-chain digest based on the data unit commitment; in this embodiment, the on-chain digest adopts a row-column digest and / or a facet digest; the process of generating a row-column digest and / or a facet digest based on the data unit commitment includes:

[0089] Taking an n×m two-dimensional matrix as an example, where n is the total number of rows and m is the total number of columns; using an RSA accumulator, a row digest is generated from the cell commitments of each row of the two-dimensional matrix. For example, to obtain the cell commitment of the i-th row cell: The RSA accumulator generates the i-th row summary based on the cell commitment of the i-th row cell. Similarly, an RSA accumulator can be used to generate a column summary from the cell commitments of each column in a two-dimensional matrix. For example, to obtain the cell commitment of the j-th column: The RSA accumulator generates a summary in column j based on the cell commitment of column j. .

[0090] In a multidimensional cube scenario, generate corresponding face summaries. Obtain cell commitments face by face according to the multidimensional cube data, and use an RSA accumulator to generate face summaries from the cell commitments of each face of the multidimensional cube.

[0091] S300: The data owner uploads the on-chain digest to the blockchain digest storage contract; specifically, it stores the digests of all rows in the two-dimensional data matrix. Summary of Columns Upload the digest storage contract to the blockchain, or / and upload the digests of all faces of the multidimensional cube to the digest storage contract on the blockchain. Implement on-chain storage of digests.

[0092] S400: The querying user requests the blockchain to obtain the target service provider corresponding to the query request, and then initiates a query request to the target service provider.

[0093] In the specific implementation, a routing smart contract based on a Bloom filter is deployed on the blockchain. Within the blockchain routing smart contract, a Bloom filter is constructed for each data field (e.g., "age", "disease type") of each service provider, recording the range of data values ​​stored by the service provider. After a user initiates a query request Q to the blockchain, the blockchain executes the routing smart contract to process the query request Q, including: query condition parsing, i.e., the routing smart contract parses the fields (e.g., "age", "fasting blood glucose") and value ranges (e.g., [50, 70]) of the query request Q as query conditions; for each service provider, the Bloom filter for its corresponding field is called according to the query conditions to check whether it matches the value range containing the query conditions; and a list of all matching service providers, Result_SPs, is returned to the user. The user only sends data query requests to the target service providers in the returned list Result_SPs.

[0094] In practice, to ensure the accuracy of the Bloom filter, service providers regularly update their field information and synchronize it to the routing smart contract. The routing smart contract records and verifies the update process.

[0095] S500: After receiving a query request from a user, the target service provider retrieves the local database and obtains query results that match the query request. The target service provider constructs multi-layered validation objects for the query results, including data layer validation objects, cell layer validation objects, and row / column / face layer validation objects. The target service provider returns the query results and multi-layered validation objects to the user.

[0096] In the specific implementation process, such as Figure 3 As shown, after receiving a query request from a user, each target service provider searches its local database and combines the search results and boundary results to obtain query results that match the query request: , where SR represents the search results and BR represents the boundary results.

[0097] Each target service provider generates a multi-layered validation object for the query results. In this embodiment, the multi-layered validation object specifically includes:

[0098] Data layer validation objects: Sub-data for each service provider in the search results SR Generate the location proof for each grandchild data. ,in, v For grandson data in sub-data The index in the middle will sub-data All the location proofs of the grandchild data are aggregated into a data layer verification object. Where s is sub-data Total number of records in Zhongsun data;

[0099] Unit-level verification object: for service providers l Sub-data of stored data units Vector commitment Generate its commitment in the data unit Membership proof: Sub-data of data unit The member proofs of the vector commitments in the data unit commitments are aggregated into unit-level verification objects. ;

[0100] Row / column / surface verification object: commitment to data unit Generate its in-line summary Linear proof in the middle: ,in, A commitment is made for all cells in the i-th row; similarly, a commitment is made for each data cell. Generate its in-list summary Proof of the column: , Commit to all cells in column j; aggregate the row and column proofs of the cell commitments into a row / column / surface verification object: ;

[0101] Each target service provider will Return the results to the user who made the query.

[0102] S600: After receiving the query results and multi-level verification objects returned by each target service provider, the query user sends a request to the blockchain to obtain the on-chain digest required for the query results; and performs multi-level verification on the query results by combining the on-chain digest and the multi-level verification objects; if the verification fails, the multi-level verification is used to locate the source of the erroneous data; and the correct data that has passed the verification is obtained.

[0103] In the specific implementation process, the query user receives Then, a request is sent to the chain to obtain the on-chain digest required for the query results, which in this embodiment is the row / column / face digest.

[0104] The query results are validated in multiple layers by combining on-chain digests and multi-layered validation objects. If validation fails, the source of the error is located. Figure 4 As shown, it specifically includes:

[0105] Data layer validation is performed using the data layer validation object in the query results. This data layer validation verifies each piece of grandchild data for each target service provider in the search results (SR). ( v Does it actually exist in the sub-data? Specifically, based on the service provider l Sub-data of stored data units and its vector commitment Sun Data ( v The location proof and index of ) are called. Verification; if verification fails, locate the erroneous data. ( v ), service provider l For storing sub-data The target service provider.

[0106] Perform unit-level validation using unit-level validation objects from the query results. Utilize unit-level validation to verify service providers. l Sub-data of stored data units Is it a data unit? Members. Specifically, based on service providers. l Data unit commitment of stored data unit Sub-data of a data unit Vector commitment Sub-data Vector commitment In data unit commitment Membership proof and target service provider identifier l call Validate sub-data Vector commitment Is it a data unit commitment? Members; if it fails, the location error occurs, and the sub-data... Not a data unit Members, target service providers l For those who commit evil.

[0107] Row and column digest validation is performed using the on-chain digest (row and column digest) of the query results. This validation verifies whether a cell exists within the two-dimensional matrix of data. Specifically, it involves committing data units based on the cell's structure. , proof of line Summary of Hexing , call Verify data unit commitment Whether it truly exists in the row summary, cell-based data unit commitment List of proofs Summary of He Lie , call Verify data unit commitment Does it actually exist in the column summary?

[0108] Range and data integrity verification:

[0109] Integrity check: The integrity of the query boundary (BR) is checked by row and column summaries. For example, if a user queries [52,54] and the target service provider returns [52,53], the check fails.

[0110] Data integrity: through sub-data The quantity verification of vector commitments ensures that no child data is missing in a cell, such as... The number of data rows is consistent with the number of vector commitments of its sub-data.

[0111] Example 2

[0112] like Figure 5 As shown, this embodiment of the invention provides another method for fine-grained verifiable data querying for multiple service providers, including:

[0113] S10, perform system module initialization and cryptographic tool deployment.

[0114] Specifically, data owners, service providers, and query users initialize their roles and identities on the hybrid storage blockchain; public and private key pairs are generated for data owners, service providers, and query users through an asymmetric encryption algorithm, and the public key is uploaded to the blockchain for record-keeping in the hybrid storage blockchain for subsequent data encryption and signing.

[0115] The required cryptographic tools include:

[0116] RSA accumulator: The RSA accumulator generates the public key. (N is the product of large prime numbers, g is the generator of the cyclic group, (a quadratic residue group of N) and the private key , used to generate aggregate summaries and membership proofs;

[0117] Vector Commitment: Generating Common Parameters (λ is the security parameter, n is the vector length), used to generate data unit commitments and location proofs.

[0118] S20: The data owner organizes the original data into a matrix or multi-dimensional cube according to its dimensions and obtains data units. Based on the sub-data stored by the service provider, the data unit generates a data unit commitment using vector commitments and an RSA accumulator. Then, based on the data unit commitment, an on-chain digest for verification is obtained. This step realizes the generation of verifiable data structures, specifically including:

[0119] S21, the data owner organizes its original data into a two-dimensional matrix or a multi-dimensional cube according to dimensions; the data in the form of a two-dimensional matrix or a multi-dimensional cube has data units, where the data units of the data in the form of a two-dimensional matrix are cells, and the data units of the data in the form of a multi-dimensional cube are cube units, corresponding to the intersection units of the three-dimensional fields.

[0120] S22, generating a data unit commitment for a data unit, including: obtaining sub-data of the data unit distributed across multiple service providers, generating a vector commitment for the sub-data stored for each service provider, and aggregating all sub-data vector commitments of the data unit to obtain a data unit commitment.

[0121] Taking two-dimensional matrix data as an example, its data unit is a cell: for any cell (in the i-th row and j-th column), if its data is distributed across k service providers, then... Represents any service provider l Stored cells Sub-data, sub-data stored for each service provider. Generate Vector Commitment Aggregate all sub-data in the same cell. Vector commitment The cell commitment that generated this cell Similarly, for data in the form of multidimensional cubes, the generation of cube unit commitments is also possible.

[0122] S23, Generate an on-chain digest based on the data unit commitment; in this embodiment, the on-chain digest is an aggregated digest; the process of generating an aggregated digest based on the data unit commitment includes: generating row and column digests and / or face digests using the data unit commitments; aggregating all row and column digests or all face digests to generate an aggregated digest.

[0123] The process of generating row and column summaries and / or face summaries based on data unit commitments includes:

[0124] Taking an n×m two-dimensional matrix as an example, where n is the total number of rows and m is the total number of columns; using an RSA accumulator, a row digest is generated from the cell commitments of each row of the two-dimensional matrix. For example, to obtain the cell commitment of the i-th row cell: The RSA accumulator generates the i-th row summary based on the cell commitment of the i-th row cell. Similarly, an RSA accumulator can be used to generate a column summary from the cell commitments of each column in a two-dimensional matrix. For example, to obtain the cell commitment of the j-th column: The RSA accumulator generates a summary in column j based on the cell commitment of column j. .

[0125] In a multidimensional cube scenario, generate corresponding face summaries. Obtain cell commitments face by face according to the multidimensional cube data, and use an RSA accumulator to generate face summaries from the cell commitments of each face of the multidimensional cube.

[0126] S24, the RSA accumulator aggregates all row and column summaries to obtain its aggregated summary representation as follows:

[0127] .

[0128] Similarly, the RSA accumulator aggregates all face summaries to obtain its aggregated summary.

[0129] S30, the data owner uploads the on-chain digest to the blockchain digest storage contract;

[0130] When using aggregated digests for on-chain summaries, the aggregated digest is uploaded to the blockchain's digest storage contract. Uploading only the aggregated digest to the blockchain reduces the on-chain storage overhead and costs. Since on-chain summaries only use aggregated digests, subsequent verification processes also need adaptive improvements to enable fine-grained queries.

[0131] S40, the querying user requests the blockchain to obtain the target service provider corresponding to the query request, and then initiates a query request to the target service provider.

[0132] In the specific implementation, a routing smart contract based on a Bloom filter is deployed on the blockchain. Within the blockchain routing smart contract, a Bloom filter is constructed for each data field (e.g., "age", "disease type") of each service provider, recording the range of data values ​​stored by the service provider. After a user initiates a query request Q to the blockchain, the blockchain executes the routing smart contract to process the query request Q, including: query condition parsing, i.e., the routing smart contract parses the fields (e.g., "age", "fasting blood glucose") and value ranges (e.g., [50, 70]) of the query request Q as query conditions; for each service provider, the Bloom filter for its corresponding field is called according to the query conditions to check whether it matches the value range containing the query conditions; and a list of all matching service providers, Result_SPs, is returned to the user. The user only sends data query requests to the target service providers in the returned list Result_SPs.

[0133] In practice, to ensure the accuracy of the Bloom filter, service providers regularly update their field information and synchronize it to the routing smart contract. The routing smart contract records and verifies the update process.

[0134] S50: After receiving the query request from the querying user, the target service provider retrieves the local database and obtains the query results that match the query request; the target service provider constructs a multi-layered validation object for the query results, including a data layer validation object, a cell layer validation object, and a row / column / face layer validation object; the target service provider returns the query results and the multi-layered validation object to the querying user.

[0135] In the specific implementation process, such as Figure 7 As shown, after receiving a query request from a user, each target service provider searches its local database and combines the search results and boundary results to obtain query results that match the query request: , where SR represents the search results and BR represents the boundary results.

[0136] Each target service provider generates a multi-layered validation object for the query results. In this embodiment, the multi-layered validation object specifically includes:

[0137] Data layer validation objects: Sub-data for each service provider in the search results SR Generate the location proof for each grandchild data. ,in, v For grandson data in sub-data The index in the middle will sub-data All the location proofs of the grandchild data are aggregated into a data layer verification object. Where s is sub-data Total number of records in Zhongsun data;

[0138] Unit-level verification object: for any service provider l Sub-data of stored data units Vector commitment Generate its commitment in the data unit Membership proof: All sub-data of the data unit The member proofs of the vector commitments in the data unit commitments are aggregated into unit-level verification objects. ;

[0139] Row / column / surface verification object: commitment to data unit Generate its in-line summary Linear proof in the middle: ,in, A commitment is made for all cells in the i-th row; similarly, a commitment is made for each data cell. Generate its in-list summary Proof of the column: , Commit to all cells in column j; aggregate the row and column proofs of the cell commitments into a row / column / surface verification object: ;

[0140] Aggregate layer verification object: When the corresponding target service provider generates a multi-layer verification object, it performs row and column summaries. / Generate its aggregated summary Existence proof in The existence proof of the row and column digests in the aggregate digest is added to the multi-level verification object as an aggregate layer verification object.

[0141] The target service provider returns the query results and multi-level validation objects.

[0142] S60: After receiving the query results and verification objects returned by the service provider, the query user sends a request to the blockchain to obtain the on-chain digest required for the query results, i.e., the aggregated digest. The query results are then verified in multiple layers based on the on-chain digest and the multi-layered verification objects. If verification fails, the multi-layered verification is used to locate the source of the erroneous data; and the correct data that has passed verification is obtained.

[0143] In the specific implementation process, the query user receives Then, a request is sent to the chain to obtain the on-chain digest required for the query results, which in this embodiment is the aggregated digest.

[0144] The query results are validated in multiple layers by combining on-chain digests and multi-layered validation objects. If validation fails, the source of the error is located. Figure 8 As shown, it specifically includes:

[0145] Data layer validation is performed using the data layer validation object in the query results. This data layer validation verifies each piece of grandchild data for each target service provider in the search results (SR). ( v Does it actually exist in the sub-data? Specifically, based on the service provider l Sub-data of stored data units and its vector commitment Sun Data ( v The location proof and index of ) are called. Verification; if verification fails, locate the erroneous data. ( v ), service provider l For storing sub-data The target service provider.

[0146] Perform unit-level validation using unit-level validation objects from the query results. Utilize unit-level validation to verify service providers. l Sub-data of stored data units Is it a data unit? Members. Specifically, based on service providers. l Data unit commitment of stored data unit Sub-data of a data unit Vector commitment Sub-data Vector commitment In data unit commitment Membership proof and target service provider identifier l call Validate sub-data Vector commitment Is it a data unit commitment? Members; if it fails, the location error occurs, and the sub-data... Not a data unit Members, target service providers l For those who commit evil.

[0147] First, retrieve the row and column summaries for the query user. / Based on row and column summaries / ， Aggregated Summary Row and column summary / In aggregate summary Existence proof in Call and Verify the authenticity of the row and column summaries; after verifying the authenticity of the row and column summaries, commit the data units based on the cells. , proof of line and verify the true line summary , call Verify data unit commitment Whether it truly exists in the row summary, cell-based data unit commitment List of proofs and verify the true column summary , call Verify data unit commitment Does it actually exist in the column summary? If it fails, locate the error cell. .

[0148] Range and data integrity verification:

[0149] Integrity check: Verify the integrity of the query boundary (BR) by verifying the actual row and column summaries. For example, if a user queries [52,54] and the target service provider returns [52,53], the verification fails.

[0150] Data integrity: through sub-data The quantity verification of vector commitments ensures that no child data is missing in a cell, such as... The number of data rows is consistent with the number of vector commitments of its sub-data.

[0151] Example 3

[0152] like Figure 9 As shown, this disclosure provides a fine-grained verifiable data query system for multiple service providers, including a data owner module, a query user module, and a hybrid storage blockchain module incorporating blockchain and multiple service providers. The modules interact through a preset protocol, as detailed below:

[0153] The data owner module is configured at least as a data organization unit, which organizes the data owner's raw data into a two-dimensional matrix or a multi-dimensional cube according to dimensions. Specifically, it does not simply divide the raw data, but first performs in-depth preprocessing on the raw data, including cleaning redundant information and correcting format errors. Then, based on the core attribute dimensions of the data (such as patient basic information and examination indicators in medical data), a two-dimensional matrix or multi-dimensional cube is constructed. For example, for medical data containing patient age, gender, and multiple physical examination indicators, a cube can be constructed in three dimensions: "age-gender-physical examination indicators," with each data unit precisely corresponding to a specific value under a specific combination of dimensions. A verifiable data structure generation unit generates vector commitments, row / column / face summaries, and aggregate summaries for data units of structured data based on vector commitments and an RSA accumulator. Specifically, the verifiable data structure generation unit generates a unique vector commitment for each data unit, which is tightly bound to the specific value of the data unit to ensure that the data unit cannot be tampered with. Then, based on the vector commitments, aggregate calculations are performed on each row and column of a two-dimensional matrix or each face of a multi-dimensional cube to generate row / column summaries or face summaries. These summaries can quickly verify whether the data in a certain row, column, or face is complete. It supports further aggregating all row / column summaries or face summaries to generate a global aggregate summary. A summary uploading unit uploads the verifiable data structure summary to the summary storage contract unit of the hybrid storage blockchain. Specifically, the generated row / column / face summaries and aggregate summaries are organized according to a preset format and then submitted to the blockchain's summary storage contract unit via encrypted transmission. During the upload process, key information such as the summary generation time and the identifier of the corresponding dataset are recorded. The blockchain's summary storage contract unit stores the received summaries, and the blockchain's record storage unit generates an immutable record.

[0154] The hybrid storage blockchain module comprises multiple service providers and a blockchain for data management. The service providers are configured with at least the following components: a data storage unit, which stores raw data outsourced by the data owner and corresponding data unit commitments. Specifically, after receiving the raw data and corresponding unit commitments from the data owner, it stores them using a distributed storage architecture. To improve data security, the raw data is sharded and encrypted, with each shard stored on a different physical node. A data index is also created, containing the data's dimensional information and storage location for easy and quick data location and retrieval. Furthermore, the stored data and data unit commitments are periodically checked for consistency to ensure the data has not been tampered with or lost. A verification object generation unit, upon receiving a query request from a user, generates verification objects at the data layer, unit layer, row / column / face layer, or aggregation layer. Specifically, it parses the query request to obtain query conditions and determine the range of data to be queried. Then, for the data within this range, the original data is extracted; the data unit commitments corresponding to the data units are extracted; the relevant row / column digests or facet digests are calculated and extracted; the corresponding aggregate digests are obtained; these extracted and calculated data are integrated to generate hierarchical multi-layered verification objects. Each level of verification object is closely related to the query results, providing a basis for subsequent verification. The result return unit returns the query results and verification objects to the querying user. Specifically, the queried original data results and the generated multi-layered verification objects are packaged, with metadata such as timestamps and service provider identifiers added during the packaging process. Then, the data packet is sent to the querying user through a secure communication protocol, recording the query time, query content, and receiving user information for subsequent auditing and traceability. To ensure the security of the transmission process, the data packet is encrypted, and only the querying user can decrypt and obtain the content using the corresponding key. The blockchain is configured at least as follows: a digest storage contract unit, which stores the on-chain digest (row / column / facet digest or aggregate digest) of the verifiable data structure uploaded by the data owner. Specifically, the summary storage contract unit configures a summary storage contract. This contract is a smart contract specifically designed to store summary information, with a fixed storage structure and access permissions. When a data owner uploads a summary, the summary storage contract verifies its format and integrity. If the verification passes, the summary is stored in the blockchain's distributed ledger, generating a corresponding hash value. When a user or other system needs to query a summary, they can call the summary storage contract's query interface, inputting information such as the dataset identifier. The summary storage contract will then return the corresponding summary information. All query and storage operations are recorded in the blockchain's record storage unit and are immutable. The routing smart contract unit deploys Bloom filters for each service provider's fields to locate the target service provider based on the query request issued by the user module.Specifically, the routing smart contract unit configures a routing smart contract, which deploys Bloom filters for the data fields provided by various service providers. These Bloom filters pre-store field information that service providers can process. When a user initiates a query request, the routing smart contract extracts the fields from the request and matches them against the Bloom filters of each service provider, quickly filtering out target service providers that may contain the required data. To ensure the accuracy of the Bloom filters, service providers periodically update their field information and synchronize it to the routing smart contract, which records and verifies the update process. The record storage unit stores data upload, usage, and transaction records to ensure data traceability. Specifically, the record storage unit records all operations, including data owner data uploads, service provider data storage and processing, and user data queries. The records include operation time, operation subject, operation object, and operation result. This information is encrypted and stored on the blockchain, forming an immutable record. When it is necessary to trace the data usage process or resolve disputes, accurate information can be obtained by querying the record, ensuring transparent and traceable data usage.

[0155] The user query module is configured with at least the following components: a query initiation unit, which generates a multi-dimensional query request (e.g., <age: [50, 70], fasting blood glucose: [100, 200]>) and locates the target service provider through the blockchain's routing smart contract unit. Specifically, the user inputs multi-dimensional query conditions through the query initiation unit, which converts the query conditions into a standardized query request. Then, the query initiation unit interacts with the blockchain's routing smart contract unit, submitting the field information in the query request to the routing smart contract unit. The routing smart contract unit matches service providers according to a preset Bloom filter, locating the target service provider that can provide data matching the query conditions. The query initiation unit receives and records the target service provider's information and then sends the query request to it. A result verification unit verifies the authenticity and completeness of the query results using a multi-layered method, combining the digest on the blockchain. Specifically, after receiving the query results and multi-layered verification objects returned by the target service provider, the result verification unit obtains the corresponding row / column / face digests or aggregated digests from the blockchain for multi-layered verification to ensure the authenticity and completeness of the query results. The error location unit, if verification fails, locates the specific location of the erroneous data (such as a specific piece of data from a service provider) based on the verification result.

[0156] In the embodiments provided by this invention, it should be understood that the disclosed structures and methods can be implemented in other ways. For example, the structural embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, structures, or units, and may be electrical, mechanical, or other forms.

[0157] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0158] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0159] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A fine-grained, verifiable data query method for multiple service providers, characterized in that, include: The data owner organizes the raw data into a two-dimensional matrix or multi-dimensional cube according to dimensions and obtains data units. Based on the sub-data stored by the service provider, the data unit generates a data unit commitment using vector commitments and an RSA accumulator. Then, an on-chain digest is obtained based on the data unit commitment. This process includes: the data owner organizing the raw data into a two-dimensional matrix or multi-dimensional cube with data units according to dimensions; obtaining the sub-data of the data unit stored in multiple service providers; generating a vector commitment for the sub-data stored by each service provider; aggregating all the sub-data vector commitments of the data unit to obtain the data unit commitment; and generating an on-chain digest based on the data unit commitment. The data owner uploads the on-chain digest to the blockchain digest storage contract; A user submits a query request to the blockchain to retrieve the target service provider for their query request. The blockchain's routing smart contract constructs a Bloom filter for each data field of every service provider, recording the range of data values ​​stored by each provider. After a user submits a query request, the blockchain executes the routing smart contract to process the request, including: parsing the fields and value ranges of the query request as query conditions; for each service provider, calling the Bloom filter for its corresponding field based on the query conditions to check if it matches a value range containing the query conditions; returning a list of all matching service providers to the user; and only sending data query requests to the target service providers in the returned list. After receiving a query request from a user, the target service provider retrieves the query results from its local database. The target service provider then constructs multi-layered validation objects for the query results, including data-layer validation objects, cell-layer validation objects, and row / column / face-layer validation objects. Finally, the target service provider returns the query results and validation objects to the user. These include: Data-layer validation objects: For each service provider's sub-data in the search results, a location proof for each grandchild data is generated, and all location proofs for the grandchild data are aggregated into a data-layer validation object; Cell-layer validation objects: For any data unit stored by any service provider, a membership proof in the data unit's data unit commitment is generated for the vector commitment of the sub-data within that data unit, and all membership proofs for the vector commitments of the sub-data within that data unit are aggregated into a cell-layer validation object; Row / column / face-layer validation objects: For a data unit commitment, a row proof in the row digest is generated; for a data unit commitment, a column proof in the column digest is generated; and the row / column proofs for the cell commitment are aggregated into a row / column / face-layer validation object. After receiving the returned query results and verification object, the querying user sends a request to the blockchain to obtain the on-chain digest required for the query results; and performs multi-level verification on the query results in combination with the on-chain digest; if the verification fails, the multi-level verification results are used to locate the source of the erroneous data. The query results are validated in multiple layers by combining on-chain digests and multi-layered validation objects. If validation fails, the source of the error is located, including: Data layer validation is performed using the data layer validation object of the query results, based on the sub-data of the data unit stored by the service provider. and its vector commitment Sun Data (v) Location proof and index , call To verify each piece of grandchild data for each target service provider in the search results. ( v Does it actually exist in the sub-data? If verification fails, locate the erroneous data as follows: ( v ), service provider l For storing sub-data Target service providers; Perform unit-level validation using the unit-level validation object of the query results. Then, use unit-level validation based on the service provider... l Data unit commitment of stored data unit Sub-data of a data unit Vector commitment Sub-data Vector commitment In data unit commitment Membership proof and target service provider identification l Call To verify service providers l Sub-data of stored data units Is it a data unit? The members; if it fails, the location error is found, and the sub-data... Not a data unit Members, target service providers l For the evildoer; Row and column summary validation is performed using the row and column summaries of the query results, based on cell-based data unit commitments. , proof of line and verify the true line summary , call Verify data unit commitment Whether it actually exists in the row summary, cell-based data unit commitment List of proofs and verify the true column summary , call Verify data unit commitment Does it actually exist in the column summary? If it fails, locate the error cell. ; Range and data integrity verification: Range integrity verification: Verify the integrity of the query boundary (BR) by verifying the actual row and column summaries; Data integrity: through sub-data The number of vector commitments is checked to ensure that no child data is missing in the cell.

2. The fine-grained verifiable data query method for multiple service providers according to claim 1, characterized in that, On-chain digests use row-column digests and / or facet digests; the process of generating row-column digests and / or facet digests based on data unit commitments includes: The cell commitments are obtained row by row according to the two-dimensional matrix of data, and a row summary is generated for each cell commitment in the two-dimensional matrix using an RSA accumulator; the cell commitments are obtained column by column, and a column summary is generated for each cell commitment in the two-dimensional matrix using an RSA accumulator. The cell commitments are obtained face by face from the multidimensional cube of data, and a face summary is generated from the cell commitments of each face of the multidimensional cube using an RSA accumulator.

3. The fine-grained verifiable data query method for multiple service providers according to claim 1, characterized in that, On-chain digests use aggregate digests; the process of generating aggregate digests based on data unit commitments includes: The cell commitments are obtained row by row according to the two-dimensional matrix of data, and a row summary is generated for each cell commitment in the two-dimensional matrix using an RSA accumulator; the cell commitments are obtained column by column, and a column summary is generated for each cell commitment in the two-dimensional matrix using an RSA accumulator. The cell commitments are obtained face by face according to the multidimensional cube of data, and the RSA accumulator is used to generate a face summary of the cell commitments of each face of the multidimensional cube. The RSA accumulator aggregates all row and column summaries or aggregates all face summaries to obtain an aggregated summary of row and column summaries or face summaries.

4. The fine-grained verifiable data query method for multiple service providers according to claim 1, characterized in that, After receiving a query request from a user, each target service provider searches its local database and combines the search results and boundary results to obtain query results that match the query request. Each target service provider generates a multi-layered validation object for the query results.

5. The fine-grained verifiable data query method for multiple service providers according to claim 1, characterized in that, After receiving a query request from a user, the target service provider retrieves the query results from its local database, obtains the query results that match the query request, and constructs a multi-layered validation object, including: After receiving a query request from a user, each target service provider searches its local database and combines the search results and boundary results to obtain query results that match the query request. Each target service provider generates a multi-layered validation object for the query results. The multi-layered validation object includes: Data layer verification object: For each service provider's sub-data in the search results, generate the location proof of each grandchild data, and aggregate all the location proofs of the grandchild data of the sub-data into a data layer verification object; Unit-level verification object: Generates the membership proof of the vector commitment of the sub-data of any data unit stored by any service provider in the data unit commitment of that data unit, and aggregates the membership proofs of the vector commitments of all sub-data of the data unit in the data unit commitment into a unit-level verification object; Row / Column / Surface Validation Object: Promises a data cell to generate its row proof in the row digest; promises a data cell to generate its column proof in the column digest; aggregates the row and column proofs of the cell promises into a row / column / surface validation object; Aggregate layer verification object: Generates a proof of existence of the row and column digest in the aggregate digest.

6. A fine-grained verifiable data query system for multiple service providers, implementing the fine-grained verifiable data query method for multiple service providers as described in any one of claims 1-5, characterized in that, It includes a data owner module, a query user module, and a hybrid storage blockchain module that incorporates blockchain and multiple service providers. These modules interact through a pre-defined protocol, as detailed below: The data owner module is configured with at least the following components: a data organization unit, which organizes the data owner's original data into a two-dimensional matrix or a multi-dimensional cube; a verifiable data structure generation unit, which generates vector commitments, row / column / face summaries, and aggregate summaries of data units of structured data based on vector commitments and an RSA accumulator, wherein sub-data of data units are obtained and distributed across multiple service providers, a vector commitment is generated for each sub-data stored by a service provider, and the vector commitments of all sub-data of the data unit are aggregated to obtain the data unit commitment; and a summary uploading unit, which uploads the verifiable data structure summary to the summary storage contract unit of the hybrid storage blockchain, where the blockchain's summary storage contract unit stores the received summary and the blockchain's record storage unit generates an immutable record. A hybrid storage blockchain module includes multiple service providers and a blockchain for data management. Each service provider is configured with at least: a data storage unit storing raw data outsourced by the data owner and corresponding data unit commitments; and a verification object generation unit that, upon receiving a query request from a user, generates verification objects for a data layer, unit layer, row / column / face layer, and aggregation layer. These include: a data layer verification object generating a location proof for each grandchild data item for each service provider's sub-data in the search results, aggregating all grandchild data location proofs into a data layer verification object; a unit layer verification object generating a membership proof in the data unit commitment for the vector commitment of any data unit stored by any service provider, aggregating all vector commitments in the data unit commitment into a unit layer verification object; and a row / column / face layer verification object generating a row proof in the row digest for each data unit commitment; and generating a row proof in the row digest for each data unit commitment. The blockchain is configured with at least the following components: column proofs in the column digest; aggregation of row and column proofs from cell commitments into row / column / surface verification objects; result return unit, which returns the query results and verification objects to the querying user; a blockchain storage contract unit, which stores on-chain digests uploaded by data owners; a routing smart contract unit, which deploys Bloom filters for fields of each service provider to record the range of data values ​​stored by the service providers; after a querying user initiates a query request to the blockchain, the blockchain executes the routing smart contract to process the query request, including: the routing smart contract parses the fields and value ranges of the query request as query conditions; for each service provider, it calls the Bloom filter of its corresponding field according to the query conditions to check whether it matches the value range containing the query conditions; returns a list of all matching service providers to the querying user; the querying user only issues data query requests to the target service providers in the returned list of service providers; and a record storage unit, which stores data upload, usage, and transaction records to ensure data traceability. The user query module is configured with at least the following components: a query initiation unit, which generates a multi-dimensional query request and locates the target service provider through a blockchain routing smart contract unit to send the query request; a result verification unit, which verifies the authenticity and completeness of the query results in multiple layers based on the on-chain digest; and an error location unit, which, if verification fails, locates the specific location of the erroneous data based on the verification result, performs multi-layered verification of the query results in combination with the on-chain digest and multi-layered verification objects, and if verification fails, locates the source of the error, including: Data layer validation is performed using the data layer validation object of the query results, based on the sub-data of the data unit stored by the service provider. and its vector commitment Sun Data (v) Location proof and index , call To verify each piece of grandchild data for each target service provider in the search results. ( v Does it actually exist in the sub-data? If verification fails, locate the erroneous data as follows: ( v ), service provider l For storing sub-data Target service providers; Perform unit-level validation using the unit-level validation object of the query results. Then, use unit-level validation based on the service provider... l Data unit commitment of stored data unit Sub-data of a data unit Vector commitment Sub-data Vector commitment In data unit commitment Membership proof and target service provider identification l Call To verify service providers l Sub-data of stored data units Is it a data unit? The members; if it fails, the location error is found, and the sub-data... Not a data unit Members, target service providers l For the evildoer; Row and column summary validation is performed using the row and column summaries of the query results, based on cell-based data unit commitments. , proof of line and verify the true line summary , call Verify data unit commitment Whether it actually exists in the row summary, cell-based data unit commitment List of proofs and verify the true column summary , call Verify data unit commitment Does it actually exist in the column summary? If it fails, locate the error cell. ; Range and data integrity verification: Range integrity verification: Verify the integrity of the query boundary (BR) by verifying the actual row and column summaries; Data integrity: through sub-data The number of vector commitments is checked to ensure that no child data is missing in the cell.

Images