A query method, verification method, and electronic device for a graph database.

Abstract

This invention relates to the field of verifiable query technology for graph databases, and discloses a query method, a verification method, and an electronic device for graph databases. The query method includes: receiving a graph query request for private graph data; determining a constraint structure corresponding to the graph query request, wherein the constraint structure represents at least one graph query processing logic among node expansion, path relationship processing, relationship matching, result filtering, or result sorting; executing the graph query request based on the private graph data to obtain a graph query result; constructing witness data; using the witness data as variable values ​​in the constraint structure, and generating a verifiable proof corresponding to the graph query result based on the prover key, the graph query result, and the constraint structure; and outputting the graph query result and the verifiable proof. This scheme enables the verification of graph query results without disclosing the underlying private graph data.

Description

Technical Field

[0001] This invention relates to the field of graph database query and verification technology, specifically to a graph database query method, verification method, and electronic device. Background Technology

[0002] Graph database query verification technology is used to check and confirm the correspondence between query results and underlying graph data during graph data storage and query execution. Graph data typically represents objects and relationships between them using nodes and edges. The query process usually revolves around operations such as node expansion, edge relationship matching, path finding, attribute filtering, and result sorting. Graph databases are widely used in scenarios such as financial risk control, social relationship analysis, knowledge graph processing, and bioinformatics network analysis because they are suitable for expressing complex relational structures. At the same time, the graph data in these scenarios is often highly sensitive; while external users need to obtain query results, they should not directly access the underlying graph data. Therefore, how to enable external verification of query results without disclosing the underlying graph data has gradually become an important technical problem in graph database applications.

[0003] In typical graph database applications, query requests are usually executed by the system of the data holder. The recipient of the result, i.e., the aforementioned external user, typically only sees the final query result and cannot directly determine whether the result truly originates from the complete graph data or whether it was obtained strictly according to the predetermined query logic. If the original graph data is directly disclosed for verification purposes, it can easily lead to the leakage of node attributes, edge relationships, and local structures. To address this, existing technologies include a type of solution based on a trusted execution environment. This type of solution typically executes the graph query process in a protected hardware environment to protect the underlying graph data and the execution process. However, the trust foundation of this type of solution depends on a specific hardware platform and its operating environment. When graph queries involve multi-hop expansion, path searching, and intermediate state updates, the execution process may also expose access patterns related to data distribution. Adding a hidden access mechanism would further increase implementation complexity and performance overhead.

[0004] Existing technologies also include a class of schemes based on authentication data structures. These schemes typically pre-construct an authentication structure for the data and return the results and authentication path during queries, allowing the verifier to check whether the results match the original data. This type of scheme is highly efficient when handling queries with relatively fixed structures. However, graph queries often involve multi-hop expansion, node set evolution, and multi-type relationship connections, resulting in significant changes in intermediate states between different query paths. For such queries, if a predefined authentication structure is still relied upon, a corresponding structure usually needs to be designed for specific query patterns, making it difficult to balance query flexibility and versatility.

[0005] With the development of zero-knowledge proof technology, using zero-knowledge proofs to provide verification capabilities for database query results is gradually becoming a new technological direction. Zero-knowledge proofs typically require first representing the computation process to be proven as a checkable constraint structure, then having the prover generate a proof based on this constraint structure, and finally having the verifier verify the proof. In this process, the constraint structure used to describe the computation steps and checking rules is usually called a zero-knowledge proof circuit. In other words, zero-knowledge proofs are used to prove and verify the results, while zero-knowledge proof circuits are used to describe the rules that the computation to be proven should satisfy. In graph database scenarios, if the graph query process can be represented as a corresponding constraint structure, and the prover generates a proof based on this constraint structure, the verifier can confirm whether the query result satisfies the predetermined query logic without obtaining the underlying graph data.

[0006] However, directly incorporating graph queries into a zero-knowledge proof framework is no easy task. Graph query processing often involves multiple rounds of node expansion, path propagation, edge relationship filtering, and intermediate set updates. For example, in multi-hop friend relationship queries, the node set needs to be expanded layer by layer from the source node; in single-source shortest path queries, node distances and predecessor relationships need to be continuously updated; and in message-linked graph queries, matching and filtering are repeatedly performed among multiple types of nodes and edges. If traditional graph algorithms are directly and completely converted into zero-knowledge proof circuits, a large number of intermediate states and checking rules need to be explicitly represented in the circuit, leading to an increase in circuit size and further problems such as high proof generation time, large storage overhead, and high implementation complexity.

[0007] Therefore, it is still necessary to provide a graph database query method, verification method, and electronic device to establish a verifiable mechanism for graph query results without leaking the underlying graph data, and to reduce the implementation complexity caused by directly circuitizing complex graph queries. Summary of the Invention

[0008] The purpose of this invention is to provide a query method, verification method, and electronic device for graph databases, which solves the problems that in the context of private graph data, it is difficult to establish a verifiable mechanism for graph query results without disclosing the underlying graph data, and that if complex graph queries are directly converted into zero-knowledge proof circuits, it will easily lead to increased circuit size, high proof generation overhead, and high implementation complexity.

[0009] On one hand, a query method for a graph database is provided, comprising: receiving a graph query request for private graph data; determining a constraint structure corresponding to the graph query request, the constraint structure being used to characterize at least one graph query processing logic among node expansion, path relationship processing, relationship matching, result filtering, or result sorting; executing the graph query request based on the private graph data to obtain a graph query result; constructing witness data, the witness data including values ​​of the private graph data and intermediate assignments used to satisfy the constraint structure; using the witness data as variable values ​​in the constraint structure, and generating a verifiable proof corresponding to the graph query result based on the prover key, the graph query result, and the constraint structure; and outputting the graph query result and the verifiable proof.

[0010] In some implementations, the node expansion includes single-source expansion or set expansion; or, the path relationship processing includes shortest path distance processing; or, the relationship matching includes bidirectional relationship normalization matching; or, the result filtering includes candidate set filtering; or, the result sorting includes sorting based on time, distance, node identifier, or attribute value.

[0011] In some implementations, the constructed witness data includes at least one intermediate assignment from the following: constructed node distance, predecessor node, predecessor distance, edge selection flag, set member flag, alignment value, next alignment value, and sorting boundary value, so that the relation consistency condition in the constraint structure is met.

[0012] In some implementations, the constraint structure includes at least one of the following constraints: edge existence constraint, node relationship constraint, predecessor relationship constraint, distance relaxation constraint, set membership constraint, order constraint, deduplication consistency constraint, or normalization constraint.

[0013] In some implementations, the private graph data represents graph edge relationships in the form of an edge list, and the witness data is constructed based on edge relationship records sorted by source node identifier.

[0014] On the other hand, a verification method for a graph database is provided, comprising: obtaining a graph query result, a verifiable proof corresponding to the graph query result, and a verification key, wherein the graph query result is obtained from a graph query request for private graph data; executing a verification algorithm based on the verification key, the graph query result, and the verifiable proof to verify whether there is witness data corresponding to the graph query request, so that the constraint structure corresponding to the graph query request is valid; and determining the graph query result as a trustworthy result when the verification is successful.

[0015] In some implementations, the constraint structure is used to characterize at least one graph query processing logic among node expansion, path relationship processing, relationship matching, result filtering, or result sorting.

[0016] In some implementations, the execution of the verification algorithm to verify the existence of witness data corresponding to the graph query request, so that the constraint structure corresponding to the graph query request is valid, includes verifying at least one of the following relationships: distance propagation relationship between node distance and predecessor distance, edge existence relationship between predecessor node and current node, distance relaxation relationship between nodes at both ends of an edge, member correspondence relationship between edge record and target set, equivalence relationship before and after bidirectional relationship normalization, and order relationship between sorting result and candidate result.

[0017] In some implementations, the graph query result further includes at least one of the following public output information: public boundary value, public message identifier, public node identifier, or public sorting result corresponding to the graph query result, and the verification algorithm verifies the verifiable proof based on the public output information.

[0018] In another aspect, an electronic device is provided, including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the aforementioned query method or verification method for the graph database.

[0019] In the technical solution provided by this invention, the graph query processing logic is converted into a constraint structure. The values ​​of the private graph data and the intermediate states during the query process are organized into witness data. The graph query result and verifiable proof are output together. The verification side can execute a verification algorithm based on the graph query result, verifiable proof, and verification key, thereby establishing a verifiable mechanism for the graph query result without disclosing the underlying private graph data. Furthermore, complex graph queries are decomposed into at least one graph query processing logic, including node expansion, path relationship processing, relationship matching, result filtering, and result sorting. Intermediate assignments and relationship constraints are constructed around this graph query processing logic, thus avoiding directly converting the entire complex graph query into a single large-scale proof circuit. This helps reduce the size of the proof structure and the complexity of proof generation and implementation, making verifiable queries in graph databases easier to implement. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of the overall implementation architecture of a graph database verifiable query in one embodiment.

[0022] Figure 2 This is a schematic diagram of the graph query request, constraint structure, witness data, graph query results, proof and verification object relationships in one embodiment.

[0023] Figure 3 This is a schematic diagram illustrating the relationship between graph query requests, private graph data, witness data, and graph query results in one embodiment.

[0024] Figure 4 This is a schematic diagram illustrating the system initialization, public parameter generation, and prover key and verification key generation process in one embodiment.

[0025] Figure 5 This is a schematic diagram of the main flow of a graph database query method in one embodiment.

[0026] Figure 6 This is a schematic diagram of the graph query request parameters and their corresponding graph query processing logic in one embodiment.

[0027] Figure 7 This is a schematic diagram of the classification of basic graph operations and constraint structure mapping in one embodiment.

[0028] Figure 8 This is a schematic diagram of the edge representation structure in the form of an edge list in one embodiment.

[0029] Figure 9 This is a schematic diagram illustrating the single-source expansion processing and edge selection relationship in one embodiment.

[0030] Figure 10 This is a schematic diagram illustrating set expansion processing, boundary pair positioning, and member flag generation in one embodiment.

[0031] Figure 11 This is a schematic diagram of path relationship processing in one embodiment.

[0032] Figure 12 This is a schematic diagram of constraint structure variable mapping and proof input combination in one embodiment.

[0033] Figure 13 This is a schematic diagram of the relation verification logic in the proof generation process of one embodiment.

[0034] Figure 14 This is a schematic diagram of the verification-side processing flow in one embodiment.

[0035] Figure 15 This is a logical diagram illustrating the verification side performing checks around different relationship types in one embodiment.

[0036] Figure 16 This is a schematic diagram illustrating the sorting results of the first N items and the boundary relationship check in one embodiment.

[0037] Figure 17 This is a schematic diagram of an electronic device structure in one embodiment.

[0038] Figure 18 This is a schematic diagram of a separate deployment structure for the query side and the verification side in one embodiment.

[0039] Figure 19 This is a schematic diagram of an integrated deployment structure in one embodiment.

[0040] Figure 20 This is a schematic diagram of the interaction process between graph query results and verifiable proofs in one embodiment.

[0041] Figure 21 This is a schematic diagram illustrating the basic principles of zero-knowledge proof and the key setting process in one embodiment. Detailed Implementation

[0042] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0043] Before proceeding with each embodiment, let's first combine... Figure 21 This document provides a unified explanation of the basic principles of zero-knowledge proofs. Zero-knowledge proofs are a type of cryptographic mechanism used to prove the validity of a proposition without revealing underlying private data. In one embodiment, a zero-knowledge proof system includes a prover 2101, a verifier 2102, a constraint structure 2103, witness data 2104, a public input 2105, a verifiable proof 2106, a prover key 2107, and a verification key 2108. The content to be proven is usually not a result in isolation, but rather the existence of a set of witness data 2104 such that this set of witness data 2104, together with the public input 2105, satisfies the constraints defined in the constraint structure 2103. The constraint structure 2103 can be understood as a formal expression of the computational logic to be proven. Unlike ordinary programs that drive computation with control flow and instruction sequences, the constraint structure 2103 emphasizes the relationships that variables should satisfy. For example, in a verifiable query scenario in a graph database, node extension relationships, path distance propagation relationships, predecessor node relationships, relationship matching relationships, result filtering relationships, and result sorting relationships can all be rewritten as constraints in constraint structure 2103.

[0044] Witness data 2104 is used to provide specific values ​​for the variables in constraint structure 2103. Witness data 2104 is not equivalent to a query request, nor is it limited to the underlying original private input. Instead, it typically includes two parts: one part is the private input, and the other part is the intermediate assignments required for constraint structure 2103 to hold. Taking the aforementioned graph database scenario as an example, private input can include values ​​such as node identifiers, edge relationships, and attribute records in the private graph data; intermediate assignments can include edge selection flags, node distances, predecessor nodes, predecessor distances, set membership flags, alignment values, next alignment values, and sorting boundary values. The reason for needing intermediate assignments is that many relationships to be verified cannot be directly checked by the final output and the original private input alone. Instead, they require the intermediate states formed during query processing to compress complex calculations into a set of local relationships suitable for verification. Therefore, witness data 2104 is not arbitrary data attached to the proof, but rather a set of variable values ​​that enables constraint structure 2103 to have instantiable conditions.

[0045] Public input 2105 corresponds to the input content that the verification side can see and participate in the verification of. In different proof tasks, public input 2105 can contain different data. For a verifiable query of a graph database in one embodiment of this application, the graph query result can typically be part of public input 2105, and may also include at least one of the following public output information: public boundary values, public message identifiers, public node identifiers, or public sorting results, if necessary. The prover 2101, having mastered the witness data 2104, substitutes the witness data 2104 and public input 2105 into the constraint structure 2103, and runs the proof algorithm based on the prover key 2107 to generate a verifiable proof 2106. This verifiable proof 2106 does not require explicit exposure of the witness data 2104 itself, but it can convince the verifier 2102 that a set of witness data 2104 satisfying the constraint structure 2103 does exist. After receiving public input 2105, verifiable proof 2106, and verification key 2108, the verifier 2102 runs the verification algorithm to determine whether the verifiable proof 2106 is valid. If the verification passes, the proposition to be proved is considered true; if the verification fails, it means that the prover 2101 failed to prove the existence of valid witness data 2104 that conforms to the constraint structure 2103.

[0046] The prover key 2107 and verification key 2108 typically originate from a parameter generation process related to the constraint structure 2103. This process can be either centralized or decentralized. In a centralized approach, a single trusted setter executes a setting algorithm based on the constraint structure 2103 and common parameters to generate the prover key 2107 and verification key 2108. This approach has a shorter implementation path and is easy to deploy quickly, but its trust foundation is concentrated on the setter. In a decentralized approach, multiple participants contribute random contributions, and through a multi-party parameter generation process, common parameters are formed, which further derive the prover key 2107 and verification key 2108. When using this approach, as long as at least one of the participating parties is honest and their random contributions are not completely disclosed, the reliance on a single setter can be reduced. Regardless of the setup method used, the goal is to enable the prover 2101 to hold the prover key 2107 used to generate the proof, and the verifier 2102 to hold the verification key 2108 used to perform the verification. The verifier 2102 does not need to revisit the complete details of the original constraint structure 2103 during the verification phase, nor does it need to obtain the witness data 2104 itself.

[0047] From the perspective of the entire proof chain, the key to zero-knowledge proof is not merely generating a proof, but rather expressing the computation to be proven as a constraint structure 2103, organizing the original private inputs and intermediate states as witness data 2104, organizing the externally visible results as public input 2105, and then having the prover 2101 and the verifier 2102 complete the proof and verification respectively using the prover key 2107 and the verification key 2108. For the verifiable query of the graph database in one embodiment of this application, it is based on this principle that the graph query processing logic can be encoded as a constraint structure, the private graph data values ​​and intermediate assignments can be organized as witness data, and the graph query result can be used as part of the public input, thereby allowing the correctness of the query result to be verified without disclosing the underlying private graph data.

[0048] Based on the principle of zero-knowledge proof described above, one embodiment of this application provides a query method, verification method, and electronic device for graph databases. This device can be used to generate verifiable proofs for graph query results without disclosing the underlying graph data, and allows the verification side to determine whether the graph query result is credible based solely on the graph query result, the verifiable proof, and the verification key. Figure 1 The overall implementation architecture is shown in the figure, which includes a private graph data storage area 101, a query request receiving unit 102, a constraint structure determination unit 103, a query execution unit 104, a witness data construction unit 105, a proof generation unit 106, a proof output unit 107, a verification input receiving unit 108, and a verification processing unit 109. Figure 1The units within the system can be centrally deployed within a single electronic device or distributed across multiple electronic devices. In a distributed deployment, the private graph data storage area 101, query request receiving unit 102, constraint structure determination unit 103, query execution unit 104, witness data construction unit 105, proof generation unit 106, and proof output unit 107 can form the proof side, while the verification input receiving unit 108 and verification processing unit 109 can form the verification side. With this deployment, the verification side does not directly hold the private graph data; it only receives the graph query results and their corresponding verifiable proofs, thereby reducing the risk of exposing the underlying graph data.

[0049] Figure 2 The data relationships corresponding to the zero-knowledge proof process are shown. Figure 2 The system includes a graph query request 201, a constraint structure 202, private graph data 203, witness data 204, a graph query result 205, a prover key 206, a verifiable proof 207, a verification key 208, and a verification result 209. The graph query request 201 describes the graph query task to be executed. The constraint structure 202 characterizes the graph query processing logic in the graph query task. The private graph data 203 provides the data source for query execution. The witness data 204 provides values ​​for the variables in the constraint structure 202. The graph query result 205 characterizes the output after query execution. The prover key 206 supports the prover side in generating the verifiable proof 207. The verification key 208 supports the verifier side in verifying the verifiable proof 207. The verification result 209 characterizes the output of the verification processing unit 109 after executing the verification algorithm on the verifiable proof 207.

[0050] Figure 2 The constraint structure 202 can be understood as a set of constraints used to encode the graph query processing logic, rather than the ordinary database query statement itself. The constraint structure 202 typically contains variables and the relationships that should be satisfied between them. Witness data 204 corresponds to the specific values ​​of these variables. Substituting witness data 204 into the constraint structure 202 allows for checking whether the constraints are met. The proof side generates a verifiable proof 207 based on the prover key 206, the graph query result 205, and the substituted constraint structure 202. The verification side receives the graph query result 205, the verifiable proof 207, and the verification key 208, and runs a standard verification algorithm. If the verification algorithm passes, the verification result 209 indicates the existence of a set of witness data 204 consistent with the private graph data 203, making the graph query processing logic corresponding to the graph query request 201 valid in the constraint structure 202.

[0051] The source and function of witness data 204 need further explanation here. Witness data 204 consists of two parts. The first part is the value of private graph data 203. This part of the value comes from the underlying graph data itself, such as node identifiers, edge start points, edge end points, node attributes, edge attributes, or record values ​​related to the query. The second part is intermediate assignments. These values ​​are not the graph query request 201 itself, but rather intermediate states formed during the execution of the graph query, used to ensure that the constraints in constraint structure 202 are met. Taking the single-source shortest path as an example, node distance, predecessor node, and predecessor distance can be used as intermediate assignments; taking set expansion as an example, edge selection flag, set member flag, alignment value, and next alignment value can be used as intermediate assignments; taking result sorting as an example, sorting boundary value, equality flag, and candidate record comparison value can be used as intermediate assignments. Therefore, witness data 204 is not an abstract concept, but rather the set of variable values ​​actually written into constraint structure 202 in zero-knowledge proof.

[0052] Figure 3 This diagram illustrates the relationship between graph query request 201, private graph data 203, witness data 204, and graph query result 205. Graph query request 201 represents the type of graph query to be executed, typically including one or more of the following: source node identifier, target node identifier, hop count range, path constraints, attribute filtering conditions, time boundary conditions, and sorting conditions. Private graph data 203 represents the underlying graph data used to respond to graph query request 201. Witness data 204 is a set of variables extracted from private graph data 203 during the execution of graph query request 201 and combined with intermediate states during the query process. Graph query result 205 is the visible output provided to the verification side. Taking the example of finding a target node whose name meets the given conditions within a 3-hop range starting from user node A, the graph query request 201 includes the source node A, the hop range, and the name conditions; the private graph data 203 includes the nodes and edges in the social graph; the witness data 204 includes the data values ​​corresponding to the edge relationships, as well as intermediate assignments such as node distance, predecessor node, candidate set, and sorting boundary value; and the graph query result 205 includes the final returned target node identifier and related public attributes.

[0053] In one embodiment, the system initialization process is as follows: Figure 4 As shown. Figure 4The system includes a public parameter generation phase 401, a constraint structure input phase 402, a prover key generation phase 403, and a verification key generation phase 404. The public parameter generation phase 401 generates public parameters based on the zero-knowledge proof framework during system deployment. This phase typically does not directly correspond to a single specific query request but is closer to preparing the capacity boundaries of the proof system, such as the maximum number of rows supported, the maximum constraint size, or the maximum amount of data supported. After the public parameter generation is completed, the constraint structure input phase 402 receives the constraint structure 202 corresponding to the graph query request 201. Subsequently, the prover key generation phase 403 generates the prover key 206 based on the public parameters and constraint structure 202, and the verification key generation phase 404 generates the verification key 208 based on the public parameters and constraint structure 202.

[0054] Figure 4 The process described above can be used to explain the relationship between constraint structure 202 and graph query request 201. Common parameters can be pre-generated and reused by multiple query tasks, but constraint structure 202 is not necessarily a single structure shared by all queries. A more appropriate understanding is that the system can predefine a set of constraint templates corresponding to basic graph operations, and when a specific graph query request 201 arrives, it selects and combines these constraint templates to create the constraint structure 202 corresponding to the current graph query request 201. In the current implementation, if graph query request 201 corresponds to different graph query processing logic, then constraint structure 202 will also change accordingly. Therefore, common parameters may be unrelated to graph query request 201, while constraint structure 202 is usually related to graph query request 201, or at least related to the graph query processing logic corresponding to graph query request 201.

[0055] Figure 5 This shows the main processing procedure on the query side. Figure 5 In this process, the query request receiving unit 102 first receives the graph query request 201. After receiving it, the constraint structure determination unit 103 determines the constraint structure 202 based on the actual graph query processing logic involved in the graph query request 201. The query execution unit 104 then executes the graph query request 201 based on the private graph data 203, obtaining the graph query result 205. Subsequently, the witness data construction unit 105 forms witness data 204 based on the private graph data 203 and the query execution process. The proof generation unit 106 uses the witness data 204 as a variable value in the constraint structure 202 and combines it with the prover key 206 and the graph query result 205 to generate a verifiable proof 207. The proof output unit 107 outputs the graph query result 205 and the verifiable proof 207. This process is similar to... Figure 1 and Figure 2The object relationships within the framework remain consistent. The focus is not simply on adding a proof result to the ordinary database execution process, but on organizing the entire verifiable query chain around constraint structure 202 and witness data 204 from the moment the query request is received.

[0056] In this embodiment, the graph query request 201 can be described using a parameterized structure. Figure 6 This illustrates a form of graph query request composition. Figure 6 The parameters include source node parameter 601, target node parameter 602, hop count parameter 603, relation type parameter 604, attribute filtering parameter 605, time boundary parameter 606, and sorting parameter 607. Different graph queries do not necessarily use all parameters simultaneously. If the graph query task is simply to find the one-hop adjacent nodes of a certain node, only source node parameter 601 and relation type parameter 604 need to be used. If the graph query task is to find the shortest path length between two nodes, source node parameter 601, target node parameter 602, and relation type parameter 604 can be used. If the graph query task is to filter messages from friends within a certain number of hops and sort them by time, time boundary parameter 606 and sorting parameter 607 can also be added. Because these parameters are combined in different ways, after receiving the graph query request 201, the constraint structure determination unit 103 will identify which processing logics are involved in the current query, such as node expansion, path relationship processing, relation matching, result filtering, or result sorting.

[0057] Figure 7 The basic graph operation classification is shown in this embodiment. Figure 7 The process includes node expansion processing 701, path relationship processing 702, relationship matching processing 703, result filtering processing 704, and result sorting processing 705. Node expansion processing 701 represents the processing logic of obtaining adjacent nodes along graph edges starting from a single source node or set of nodes. Path relationship processing 702 represents node distance propagation, predecessor relationship determination, reachability judgment, and path length calculation. Relationship matching processing 703 represents the mapping and connection between nodes and edges, nodes and messages, messages and creators, nodes and locations, and nodes and organizations. Result filtering processing 704 represents filtering rules such as attribute conditions, time conditions, and candidate set conditions. Result sorting processing 705 represents the processing logic of sequentially arranging results according to time, distance, node identifier, or attribute value, and truncating the first N items. The constraint structure 202 can include the corresponding parts of the processing logic actually included in the current graph query request 201, without needing to indiscriminately cover all types.

[0058] In a specific implementation, if graph query request 201 involves finding a set of target nodes within a certain hop range starting from a source node, then constraint structure 202 typically includes at least node expansion processing 701 and result filtering processing 704. If graph query request 201 also requires outputting the shortest path length, then constraint structure 202 also needs to include path relationship processing 702. If graph query request 201 contains message creator mapping, then constraint structure 202 also needs to include relationship matching processing 703. If graph query request 201 requires sorting by time, distance, or identifier, then constraint structure 202 also needs to include result sorting processing 705. This approach decomposes complex graph queries into basic graph operations, and the constraints corresponding to these basic graph operations collectively form constraint structure 202.

[0059] Figure 8 The preferred diagram edge representation of this embodiment is shown. Figure 8 In the graph, edge list 801 includes multiple edge records 802, each edge record 802 including at least a source node identifier 803 and a target node identifier 804, and may also include edge attributes 805 when necessary. Edge list 801 is suitable for expressing edge existence relations, set membership relations, and ordering relations during the proof phase. Compared to the compressed representation that relies on row offsets and column indices, the edge relations in edge list 801 are explicitly expanded, making it generally more direct when constructing lookup constraints, matching constraints, or permutation consistency constraints. For example, when it is necessary to verify whether a certain output edge does indeed come from a specified set of source nodes, one can directly check whether the source node identifier 803 in edge record 802 satisfies the set membership relation, without having to additionally recover the edge segment corresponding to the index interval. This representation is more suitable for transcribing graph relations into relational conditions in constraint structure 202.

[0060] In a different embodiment, the underlying graph database can still use other storage methods, such as compressed sparse row format or other graph index formats. However, when entering the proof phase, the edge relationships related to the current graph query request 201 can be organized into an edge list 801. This approach does not require a complete change to the graph database's storage structure; instead, it adapts the graph relationships involved in the current query before proof generation. This maintains the original storage method of the underlying system while making it easier for the constraint structure 202 to express edge relationship conditions during the proof phase.

[0061] In one embodiment, after receiving the graph query request 201 and having the constraint structure 202 determined by the constraint structure determination unit 103, the query execution unit 104 does not directly write the entire control flow of the traditional graph algorithm into the constraint structure 202. Instead, it first executes the corresponding graph query processing logic on the private graph data 203, and then organizes the values ​​and intermediate states necessary for the proof into the witness data 204. The reason for this approach is that the graph query result 205 typically relies on multiple processing steps such as node expansion, relation matching, path propagation, and result sorting. If the entire program-level control flow were copied into the constraint structure 202, the constraint scale would increase significantly. In contrast, executing the graph query first and then constructing the witness data 204 around the relations that actually need to be checked in the graph query processing logic is more conducive to converging the proof task to the relation consistency itself.

[0062] Figure 9 This illustrates a single-source extended processing procedure. Figure 9 In the graph, source node 901 is connected to multiple target nodes 903 through edge list 902. For single-source expansion, query execution unit 104 can read the edge record corresponding to source node 901 from edge list 902 and form a set of output target nodes 903 accordingly. If this process is directly described as conventional graph processing, its core is simply finding the edge record whose starting point is equal to source node 901; however, in verifiable query scenarios, in addition to outputting target nodes 903, it is also necessary to form intermediate assignments that can prove the correctness of the result. To this end, witness data construction unit 105 can generate an edge selection flag 904 for each edge record in edge list 902. The edge selection flag 904 is used to characterize whether the edge record satisfies the source node matching condition. If the source node identifier of an edge record is equal to the source node 901, then the edge selection flag 904 of the edge record can take the first value; otherwise, it can take the second value. In this way, constraint structure 202 does not need to repeat the complete edge traversal process in subsequent proofs. It only needs to check the relationship between edge selection flag 904 and source node matching conditions, as well as the consistency relationship between output target node 903 and selected edge record.

[0063] exist Figure 9 In the corresponding processing, the edge selection flag 904 is not additional data independent of the query results, but rather an intermediate assignment used to make constraint structure 202 valid. Taking the edge selected in edge list 902 as an example... Taking an edge record as an example, if the source node identifier of the edge record is denoted as... The target node identifier is denoted as The identifier of source node 901 is denoted as Then you can define an edge selection flag for that edge record. .when hour, Take 1; otherwise Set it to 0. Thus, after the query execution unit 104 completes edge filtering in the normal execution environment, the witness data construction unit 105 can... Include witness data 204 together. Then, constraint structure 202 only needs to be checked. and and The correspondence between them, and all Does the edge record correspond exactly to the output target node 903? This method can transform the proof object of single-source expansion from a complete traversal process to an edge selection relationship and an output consistency relationship.

[0064] Figure 10 This illustrates a set expansion process. Figure 10 In this context, the source node set 1001 includes multiple node identifiers, the edge list 1002 includes edge records to be inspected, the extended set 1003 is an ordered set formed by adding boundary values ​​to the source node set 1001, the boundary pair 1004 consists of adjacent values ​​in the extended set 1003, the alignment value 1005 and the next alignment value 1006 are used to characterize which pair of boundaries the source node identifier of a certain edge record falls between, and the membership flag 1007 is used to characterize whether the source node of the edge record belongs to the source node set 1001. For Figure 10 In the processing, the query execution unit 104 can first obtain the source node set 1001 in the normal execution environment, and then the witness data construction unit 105 can construct the extended set 1003. In addition to the values ​​of the original source node set 1001, the extended set 1003 can also include a smaller boundary value and a larger boundary value. Taking the case where all node identifiers are non-negative integers as an example, the smaller boundary value can be 0, and the larger boundary value can be a preset upper bound that is not less than the identifiers of all candidate nodes.

[0065] Figure 10 Boundary pair 1004 in the set consists of adjacent elements in the extended set 1003. For any edge record in the edge list 1002, if its source node identifier is denoted as... Then, a satisfactory result can be found in the extended set 1003. A pair of boundaries and will Recorded as alignment value 1005, This is denoted as the next alignment value, 1006. At this point, if... If , it means that the source node recorded by this edge belongs to the source node set 1001; if This indicates that the source node recorded by the edge does not belong to the source node set 1001, but only falls within the boundary interval. The membership flag 1007 can be determined accordingly. Thus, the correctness of the membership flag 1007 no longer depends on a linear comparison of each element in the entire source node set 1001, but rather on the relationship between the alignment value 1005, the next alignment value 1006, and the boundary pair 1004. This processing method corresponds to... Figure 10 The set extension logic in the code does not focus on simply copying the ordinary set judgment procedure into constraint structure 202, but rather on rewriting the set member judgment into interval positioning relationship and alignment equality relationship.

[0066] exist Figure 10 In the implementation, the alignment value 1005 and the next alignment value 1006 are both intermediate assignments in the witness data 204. Their purpose is to transform the problem of whether the source node of an edge record belongs to the source node set 1001 into a type of order relationship problem that is easier to express with constraints. If the elements in the source node set 1001 are arranged in ascending order, and the adjacent elements in the extended set 1003 are combined into boundary pairs 1004, then for any source node identifier... You can find satisfaction in any of them.

[0067]

[0068] A set of boundaries. In equation (1), This indicates an alignment value of 1005. This indicates the next alignment value is 1006. This represents the source node identifier of the current edge record. If further satisfying... If the current edge records the source node as belonging to the source node set 1001; if only the condition is met... If the current edge records the source node, then the source node does not belong to the source node set 1001. In this way, set membership judgments can be expressed with fewer relational conditions, thereby reducing the constraint expansion caused by direct element-by-element matching.

[0069] Figure 9 and Figure 10 The processing methods differ structurally, but the underlying principle remains the same: first, graph query processing is completed in a normal execution environment, and then the relationships that must be proven are fixed using intermediate assignments. For single-source expansion, the key intermediate assignment is the edge selection flag 904; for set expansion, the key intermediate assignments are the alignment value 1005, the next alignment value 1006, and the membership flag 1007. Thus, the task of constraint structure 202 is not to reenact the normal program execution process, but to check whether these intermediate assignments are consistent with the graph relationships, and whether the output results match these intermediate assignments.

[0070] In one embodiment, if the graph query request 201 involves shortest path related processing, the query execution unit 104 can perform the path search process in a normal execution environment, and the witness data construction unit 105 can construct intermediate assignments around the path relationship. Figure 11 This demonstrates one method for handling path relationships. Figure 11 In the shortest path verification, the source node 1101, the current node 1102, the predecessor node 1103, the node distance 1104, the predecessor distance 1105, and the edge relationship 1106 together constitute the main elements required for verification. For the current node 1102, if it is not the source node 1101, then the predecessor node 1103 and the predecessor distance 1105 are usually required. Here, the predecessor node 1103 represents the previous node of the current node 1102 in a certain path, and the predecessor distance 1105 represents the distance from the source node 1101 to the predecessor node 1103. The node distance 1104 represents the distance from the source node 1101 to the current node 1102. If the current node 1102 is indeed located on a shortest path originating from the source node 1101, then the node distance 1104 and the predecessor distance 1105 should generally satisfy the distance propagation relationship.

[0071] In a typical implementation, if the cost of all edges is uniformly 1, then the node distance 1104 and the predecessor distance 1105 can satisfy the condition.

[0072]

[0073] In equation (2), This indicates that the distance between the current node 1102 and the node 1104 is 1104. This represents the predecessor distance 1105 of the predecessor node 1103. This relationship indicates that the current node 1102 traverses one more edge than the predecessor node 1103. In order for equation (2) to have verification significance, it is also necessary to check whether there is an edge relationship 1106 between the predecessor node 1103 and the current node 1102. That is to say, it is not enough to just satisfy equation (2), it is also necessary that the predecessor node 1103 and the current node 1102 can be mapped to a real edge in the edge list. In this way, the node distance 1104 of the current node 1102, the predecessor node 1103 and the predecessor distance 1105 together constitute part of the witness data 204 that can be used for verification.

[0074] Figure 11 The processing in the text can be further enhanced by introducing edge relaxation relations. For any edge in edge relation 1106, if the distance from the starting point of the edge is denoted as... The distance to the endpoint of the edge is denoted as Then you can check

[0075]

[0076] In equation (3), This represents the distance from the starting point of the edge. This represents the distance to the endpoint of an edge. This relationship indicates that, under a unit edge cost scenario, the distance to the endpoint of any edge should not be greater than the distance to the starting point of the edge plus one. If the distance of a node is incorrectly increased or decreased, then the corresponding edge relationship will usually not satisfy equation (3). Thus, equations (2) and (3) can together form the constraint basis in path relationship processing. Equation (2) is responsible for checking the local path relationship between a current node 1102 and its predecessor node 1103, and equation (3) is responsible for checking the global distance consistency of the edge relationships in the entire graph. After the two types of relationships are combined, the verification side can check the shortest path distance result without rerunning the complete path search algorithm.

[0077] The approach here differs from directly executing the traditional pathfinding algorithm within the constraint structure 202. If each round of queue states, access flags, and distance update processes from breadth-first search were incorporated into the constraint structure 202, the number of constraints would significantly increase with the graph size and hop count. The current implementation does not handle this in this way. Instead, the query execution unit 104 first performs the pathfinding, then the witness data construction unit 105 provides intermediate assignments such as node distance 1104, predecessor node 1103, and predecessor distance 1105. Finally, the constraint structure 202 checks whether these values ​​satisfy local and global relations. The advantage of this approach is that the proof task is focused on whether the relation holds, rather than how the program-level control flow unfolds, making it more suitable for zero-knowledge proof frameworks.

[0078] exist Figure 9 , Figure 10 and Figure 11 Based on this, it can be seen that the structure of witness data 204 has obvious engineering characteristics. First, witness data 204 is not directly equal to graph query result 205, but contains more intermediate information than graph query result 205. Second, this intermediate information is not necessarily better the more it is, but rather selected around the relationships in constraint structure 202 that actually need to be checked. Third, the intermediate assignment types corresponding to different graph query processing logics are different, but they can all return to the basic categories of node expansion, path relationship processing, relationship matching, result filtering, and result sorting. In this way, this embodiment can rewrite graph query processing logic into mathematical relationships suitable for verification without disclosing private graph data 203.

[0079] Regarding the role of graph query result 205 in the proof process, it can also be combined with... Figures 9 to 11Understanding. Graph query result 205 does not replace witness data 204, but rather participates in the processing of proof generation unit 106 together with witness data 204. Graph query result 205 is usually a publicly visible output on the verification side, while witness data 204 is a variable value held internally by the proof side. After writing witness data 204 into constraint structure 202, proof generation unit 106 combines it with graph query result 205 to generate verifiable proof 207. The verification side uses graph query result 205, verification key 208, and verifiable proof 207 in subsequent verification. Thus, although graph query result 205 and witness data 204 are both related to queries, they play different roles in the zero-knowledge proof process: graph query result 205 is more like a public input, while witness data 204 is more like a private variable value.

[0080] In one different embodiment, the graph query result 205, in addition to the final output items such as node identifiers, message identifiers, distance values, time values, or attribute values, may further include a small number of public boundary values ​​directly related to the result. For example, when the query result 205 contains the top 20 nodes after sorting, the graph query result 205 may include the sorting boundary value of the 20th item; when the query result 205 involves message time filtering, the graph query result 205 may also include public time boundaries. With this processing, the verification side can use these public boundary values ​​to perform a more granular check on the verifiable proof 207 without obtaining the private graph data 203. These public boundary values ​​do not change the basic role of the graph query result 205 as a public output; they only help compress the inference chain in the verification process in certain scenarios.

[0081] The above section revolves around Figures 9 to 11 This section explains the basic relationship between the graph query result 205, the witness data 204, and the constraint structure 202. The query execution unit 104 first obtains the graph query result 205 from the private graph data 203. The witness data construction unit 105 then forms intermediate assignments through processes such as single-source expansion, set expansion, and path relationship processing. The proof generation unit 106 writes these intermediate assignments along with the values ​​from the private graph data into the constraint structure 202. In this way, complex graph queries do not need to completely replay traditional graph algorithms in the constraint structure 202; instead, verifiable queries are achieved by checking the consistency between the intermediate assignments and the graph relationships.

[0082] In one embodiment, Figure 5 The processing flow shown can be revolved around a complete verifiable query process for a graph database. This process can begin with step S110. Step S110: Receive a graph query request for private graph data. The recipient of the graph query request can be... Figure 1The query request receiving unit 102 can also be an interface program, service process, or hardware control logic with equivalent function. After a graph query request enters the system, it is not directly used as a proof object, but is first parsed into target conditions required for subsequent graph query processing. These target conditions typically include one or more of the following: query start point, query end point, hop count range, edge relationship type, attribute filtering conditions, time boundary conditions, and sorting conditions. In graph database scenarios, graph query requests are usually not isolated parameters, but rather task descriptions closely related to graph relationship processing logic. If this task description is not clearly decomposed, the subsequent constraint structure will be difficult to generate stably.

[0083] Figure 6 The source node parameter 601, target node parameter 602, hop count parameter 603, relation type parameter 604, attribute filtering parameter 605, time boundary parameter 606, and sorting parameter 607 shown can be components of a graph query request. In a specific example, a graph query request can be described as: Starting from user node A, find target nodes with the name "Mike" within a range of 1 to 3 hops, and output the top 20 results sorted by shortest distance, target node last name, and target node identifier. For this request, source node parameter 601 can be user node A, hop count parameter 603 can be 1 to 3, attribute filtering parameter 605 can be "name equal to Mike," and sorting parameter 607 can include distance priority, last name priority, and node identifier priority. As another example, a graph query request can be described as: Given two user nodes A and B, output the shortest path length between node A and node B. For this request, source node parameter 601 and target node parameter 602 constitute the main conditions, while sorting parameter 607 can be ignored in the current task. The work done by the query request receiving unit 102 in step S110 is not only to collect the original parameters, but also to organize these parameters into a task description that has clear constraints on the subsequent graph query processing logic.

[0084] After step S110, the graph query request receiving unit 102 can pass the parsed target conditions to the constraint structure determination unit 103. This transition is crucial. If only the original text form or simple command form is retained at this step without extracting the actual conditions, step S120 will struggle to accurately identify the graph query processing logic. In other words, the result of step S110 is not just receiving a request, but also forming the condition inputs required for subsequent constraint structure determination. Different parts of the graph query request correspond to different types of graph query processing logic. The source node parameter 601 and hop count parameter 603 more easily lead to node expansion processing 701; the source node parameter 601 and target node parameter 602 more easily lead to path relationship processing 702; message identifiers, creator relationships, and content records more easily lead to relationship matching processing 703; attribute boundaries and time boundaries more easily lead to result filtering processing 704; and sequence conditions and truncation counts more easily lead to result sorting processing 705. In this way, the content in the graph query request can be gradually transitioned to... Figure 7 The logical categories in the constraint structure can be used instead of mechanically writing the query text directly into the constraint structure.

[0085] In one different embodiment, the graph query request receiving unit 102 may not necessarily receive the final user-facing graph query statement, but could also receive an intermediate task description. For example, the upper-layer business system can first convert natural language or graph query language into structured task parameters, and then the query request receiving unit 102 can receive these structured task parameters. As long as the system can clearly identify which graph query processing logic needs to be executed for the current graph query before proceeding to step S120, the process in this embodiment can be implemented. Therefore, the key to step S110 is not in the syntax of the request, but in the ability of the request to be parsed into the technical conditions required for subsequent constraint structure determination.

[0086] Step S120: Determine the constraint structure corresponding to the graph query request. The constraint structure is used to characterize at least one graph query processing logic among node expansion, path relationship processing, relationship matching, result filtering, or result sorting. Figure 1 The constraint structure determination unit 103 can execute this process. Here, the constraint structure is not ordinary program source code, nor is it a simple database execution plan, but rather a set of constraints used in zero-knowledge proofs to encode the computational logic to be proven. Figure 2 The constraint structure 202 in the code corresponds to the output of the current step. To avoid interpreting the constraint structure as a vague name, it can be understood as a set of relational rules that describe: under the current query task, which variables should satisfy what kind of relationship, which edge records should be selected, which nodes should be assigned to a candidate set, which path relationships should be valid, and which sorting relationships should be satisfied.

[0087] In this embodiment, the constraint structure can be determined based on a predefined constraint template. Figure 7 The node expansion processing 701, path relationship processing 702, relationship matching processing 703, result filtering processing 704, and result sorting processing 705 can each correspond to several basic constraint templates. In step S120, a completely new circuit is not invented from scratch each time; instead, corresponding parts are selected and combined from predefined constraint templates based on the actual processing logic involved in the graph query request. If the graph query request only involves single-source expansion and attribute filtering, the constraint structure can mainly consist of the constraints corresponding to node expansion processing 701 and result filtering processing 704. If the graph query request further involves shortest path output, the constraint structure can also include the constraints corresponding to path relationship processing 702. If the graph query request also requires sorting by distance and node identifier to select the top 20 items, the constraint structure can also include the constraints corresponding to result sorting processing 705.

[0088] This process can be combined Figure 8 Let's understand edge list 801. Taking edge list 801 as an example, if a graph query request requires finding a one-hop adjacent node starting from the source node, the constraint structure needs to represent at least the following two types of relationships. One type of relationship is the edge selection relationship, that is, whether the source node identifier 803 of a certain edge record 802 is equal to the query starting point. The other type of relationship is the output consistency relationship, that is, whether the target node identifier 804 of all edge records 802 that satisfy the edge selection relationship exactly forms the output result. If the graph query request requires performing set expansion starting from a set of nodes, the constraint structure also needs to represent the member positioning relationship, that is, whether the source node of a certain edge record falls within the valid boundary interval of the expanded set 1003. If the graph query request requires processing the shortest path, the constraint structure needs to introduce constraints such as node distance 1104, predecessor node 1103, predecessor distance 1105, and edge relaxation relationship. It can be seen that the essence of step S120 is to translate the query processing logic into a set of relational conditions that can be verified by the provable system.

[0089] In one implementation, the constraint structure determined in step S120 can be represented using arithmetic constraints. If the graph query processing logic is mapped to variables and constraints over a finite field, then each variable in the constraint structure needs to obtain a specific value in subsequent steps. Figure 2The witness data 204 is constructed around this point. The variables in the constraint structure can represent either the original values ​​in the private graph data 203 or intermediate values ​​generated during graph query execution. If a constraint structure corresponds to shortest path relation processing, the relevant variables can include the current node distance, predecessor node, and predecessor distance. If a constraint structure corresponds to set expansion processing, the relevant variables can include edge selection flag, alignment value, next alignment value, and membership flag. If a constraint structure corresponds to sorting processing, the relevant variables can include the current record sort value, next record sort value, and equality flag. In this way, the constraint structure determined in step S120 can strictly correspond to the witness data constructed in step S140.

[0090] To illustrate how the constraint structure is determined in step S120, we can refer to... Figure 9 , Figure 10 and Figure 11 The three typical operations shown are further elaborated. Figure 9 The single-source extension processing in the model corresponds to a basic constraint template, which establishes relationships around the source node 901, the edge list 902, the target node 903, and the edge selection flag 904. Figure 10 The set expansion processing in the template corresponds to another basic constraint template, which establishes relationships around the source node set 1001, edge list 1002, expansion set 1003, boundary pair 1004, alignment value 1005, next alignment value 1006, and member flag 1007. Figure 11 The path relationship processing in the graph corresponds to another basic constraint template, which establishes relationships around the source node 1101, the current node 1102, the predecessor node 1103, the node distance 1104, the predecessor distance 1105, and the edge relationship 1106. In step S120, once it is identified which basic operations are required for the current graph query request, the corresponding constraint templates can be combined to form the constraint structure 202.

[0091] In one different embodiment, step S120 can also tailor the constraint structure according to query complexity or deployment environment. For example, in a resource-constrained environment, an edge list of form 801 can be preferred, and constraints can be constructed around relational consistency, without introducing excessive program-level states that are completely consistent with ordinary control flow. This reduces the constraint size, making the subsequent proof generation process easier to deploy. If the query task itself only requires outputting a single shortest path length, without requiring a complete list of path nodes, the constraint structure can be prioritized based on node distances and edge relaxation relations, without additionally expanding to a constraint set that enumerates the complete path. This trade-off does not change the technical principle, but rather controls the constraint size under the same technical principle to adapt to different deployment scenarios.

[0092] Step S130: Execute a graph query request based on the private graph data to obtain the graph query results. Figure 1 The query execution unit 104 can perform this process. A key feature of step S130 is that it occurs within a general graph query computation environment, rather than directly within the constraint structure. This general graph query computation environment refers to the query execution unit 104 utilizing the existing traversal, matching, filtering, joining, and sorting capabilities of the graph database to first complete the result computation on the private graph data 203. This approach is adopted because complex graph queries often involve a large amount of control flow and state changes. Requiring all these control flows to be progressively reenacted in the subsequent proof structure would be costly. In this embodiment, the graph query result 205 is obtained first in step S130, and then witness data 204 is constructed in subsequent steps around the relationships that actually need to be checked in the graph query processing logic.

[0093] by Figure 9 Taking the single-source expansion processing as an example, if the query request is to find a 1-hop adjacent node starting from node A, the query execution unit 104 can search for the edge record 802 in the edge list 902 where the source node identifier 803 is equal to node A, and organize the corresponding target node identifier 804 into the graph query result 205. Figure 10 Taking the set expansion processing as an example, if the query request is to find edge records that meet certain conditions starting from the node set S, the query execution unit 104 can first determine the source node set 1001, then traverse the candidate edge records in the edge list 1002, and extract the target nodes corresponding to the edge records whose source nodes belong to the source node set 1001. Figure 11 Taking path relationship processing as an example, if the query request is the shortest path distance from the source node 1101 to other nodes, the query execution unit 104 can perform breadth-first search or other path search methods to obtain the node distance 1104 of the current node 1102 and the predecessor node 1103, etc.

[0094] Here, the division of labor between steps S130 and S140 needs special explanation. Step S130 focuses on actually calculating the graph query, that is, obtaining the graph query result 205. Step S140 focuses on which intermediate states need to be retained so that these results can be proven within the zero-knowledge proof framework. Without step S130, the system cannot obtain the graph query result 205; if there is only step S130 but no step S140, although the system can obtain the graph query result 205, it cannot stably form the witness data 204 for subsequent proof. Therefore, these two steps are not substitutes for each other, but rather follow each other. Step S130 first provides the source of the result and intermediate states, and step S140 then organizes these sources into witness data 204 around the constraint structure 202.

[0095] In a specific example, if the graph query request is to find the target node named Mike within a 3-hop range starting from node A, and then sort the top 20 items by distance, last name, and node identifier, the query execution unit 104 in step S130 can first perform the following processing on the private graph data 203: expand layer by layer from node A to obtain 1-hop, 2-hop, and 3-hop candidate sets; filter the target nodes named Mike from the candidate sets based on the name attribute; calculate the distance from each target node to node A; then sort the data based on distance, last name, and node identifier, and extract the top 20 items to form the graph query result 205. This process itself can be implemented using a regular graph query, but the generated candidate set, distance information, and sorting boundary values ​​will be converted into part of the witness data 204 in the next step.

[0096] Step S140: Construct witness data, which includes the values ​​of the private graph data and intermediate assignments used to satisfy the constraint structure. Figure 1 The witness data construction unit 105 can execute this process. As explained in the previous section, step S130 is mainly responsible for executing the graph query request on the private graph data 203 and obtaining the graph query result 205. The role of step S140 is not to recalculate the graph query result 205, but to organize the variable values ​​corresponding to the graph query result 205 and enabling the constraint structure 202 to hold. If only the graph query result 205 is output without organizing the witness data 204, then even if the proof generation unit 106 holds the prover key 206, it will be difficult to transform the graph query processing logic into a provable object. The witness data 204 is necessary because the variables in the constraint structure 202 need to be valued, and the local relations in the constraint structure 202 also need to be supported by specific variables.

[0097] In one embodiment, the witness data 204 can be divided into two categories: original data values ​​and intermediate assignments. Original data values ​​come directly from the private graph data 203, such as node identifiers, edge start points, edge end points, message identifiers, message creation times, relationship attributes, and node attributes. Intermediate assignments come from the intermediate states during the graph query process in step S130, such as edge selection flags, node distances, predecessor nodes, predecessor distances, alignment values, next alignment values, membership flags, sorting boundary values, and equality flags. Both are indispensable. If only original data values ​​are available, many relationships in the constraint structure 202 cannot be directly checked because there is a lack of an intermediate bridge to project the complex graph query processing logic into local relationships. If only intermediate assignments are available without original data values, the intermediate assignments cannot prove their consistency with the private graph data 203, nor can it be confirmed whether these intermediate assignments are based on real graph relationships.

[0098] Figure 9The single-source expansion process in step S140 can be used as an illustrative example. Figure 9 In the graph, edge list 902 includes several edge records 802, each edge record 802 containing at least a source node identifier 803 and a target node identifier 804. If a graph query request requires a one-hop expansion starting from source node 901, step S130 can find all edge records 802 where the source node identifier 803 is equal to the source node 901, and form the output target node 903 accordingly. In step S140, witness data construction unit 105 can organize the relevant values ​​in edge list 902 and edge selection flags 904 together. Taking an edge record as an example, let its source node identifier be... The target node is identified as The source node identifier for the query is The selected side is marked as .like ,but It can be 1; if ,but It can be set to 0. In this case, the edge selection flag 904 becomes an intermediate assignment used to satisfy constraint structure 202. Constraint structure 202 can be checked in subsequent proofs for two types of relations: one type is used for confirmation. Whether or not and The matching relationship is consistent; another type of relationship is used to confirm all. Check whether the edge record is consistent with the output target node 903.

[0099] In a more specific expression, the selection relationship in a single-source extension can be written in the following form:

[0100]

[0101] In equation (4), Indicates the first The edge record corresponds to the edge selection flag. Indicates the first The source node identifier of the edge record. This represents the source node identifier in the query request. Equation (4) does not require the direct implementation of a piecewise function in the constraint structure 202, but rather specifies the semantic relationship that the edge selection flag 904 in the witness data 204 should satisfy. Subsequently, in the zero-knowledge proof circuit, this relationship can be indirectly implemented using zero-value judgment or equivalence judgment constraints. In this way, the part that truly needs to be proven in the single-source extension is compressed into a set of edge selection relationships and output consistency relationships, instead of moving the complete edge traversal process into the proof object one by one.

[0102] Figure 10The set expansion process further illustrates the organization of intermediate assignments. In step S130, if the query execution unit 104 has obtained the source node set 1001, then in step S140, the witness data construction unit 105 can further construct an extended set 1003 around the source node set 1001. The extended set 1003 typically adds smaller and larger boundary values ​​to the source node set 1001. Then, adjacent elements in the extended set 1003 are paired to form boundary pairs 1004. For any edge record in the edge list 1002, if its source node is identified as... Then, a solution satisfying the condition is found in the extended set 1003. A set of boundary values, and put As the alignment value 1005, As the next alignment value, 1006. If both conditions are met... If the edge records that the source node belongs to the source node set 1001, then the edge records that the source node is only located in the corresponding interval and does not belong to the source node set 1001. Therefore, the member flag 1007 can be valued accordingly.

[0103] Figure 10 This relationship can be written as:

[0104]

[0105] In equation (5), Indicates the first The source node identifier of the edge record. Indicates and The corresponding alignment value is 1005. Indicates and The corresponding next alignment value is 1006. If further conditions are met...

[0106]

[0107] but This can represent the member flag 1007 of the edge record. Equation (5) guarantees the source node identifier. The adjacent boundary intervals are correctly located in the extended set 1003, and equation (6) ensures that the member flag 1007 and the alignment value 1005 remain consistent. Thus, the intermediate assignments constructed in step S140 include not only the source node set 1001 itself, but also the alignment value 1005, the next alignment value 1006, and the member flag 1007. In subsequent proofs, verifying the relationship between these intermediate assignments and the boundary pair 1004 is sufficient to support the correctness check of the set expansion result.

[0108] Figure 11The path relationship processing further illustrates the construction method of witness data 204 in shortest path type queries. If the query execution unit 104 in step S130 obtains the node distance 1104 and the predecessor node 1103 using breadth-first search or other path search methods, then the witness data construction unit 105 in step S140 can organize the current node 1102, node distance 1104, predecessor node 1103, and predecessor distance 1105 into the witness data 204. For non-source nodes, there should generally be an edge relationship 1106 between the current node 1102 and the predecessor node 1103, and the node distance 1104 and the predecessor distance 1105 should satisfy the distance propagation relationship. If the edge cost is uniformly 1, then a method can be used.

[0109]

[0110] In equation (7), This indicates that the distance between the current node 1102 and the node 1104 is 1104. This indicates the predecessor distance 1105 of the predecessor node 1103. Meanwhile, for any side relationship 1106 in the diagram, it is also possible to check...

[0111]

[0112] In equation (8), This represents the distance from the starting point of the edge. The distance to the endpoint of the edge is represented. Equation (7) is used to characterize the local path relationship between the current node 1102 and the predecessor node 1103, and Equation (8) is used to characterize the global distance consistency on the edge relationship in the graph. The intermediate assignments formed in step S140 not only make Equation (7) checkable, but also make Equation (8) checkable. In this way, the subsequent proof generation unit 106 does not need to reenact the queue state of each round of breadth-first search in the constraint structure 202, but only needs to verify whether these intermediate assignments satisfy the local and global relationships.

[0113] from Figures 9 to 11 It can be seen that the process of constructing witness data in step S140 is not a simple stacking of intermediate columns, but rather a selective organization of variable values ​​around the relationships that truly need to be established in constraint structure 202. For single-source expansion, the focus is on edge selection flag 904; for set expansion, the focus is on alignment value 1005, next alignment value 1006, and member flag 1007; for path relationship processing, the focus is on node distance 1104, predecessor node 1103, and predecessor distance 1105. If all temporary states in ordinary procedures are included in witness data 204, although theoretically a proof object could be formed, it would cause constraint structure 202 and witness data 204 to expand synchronously, which is not conducive to efficiency. Therefore, in step S140 of this embodiment, intermediate assignments that can directly support relationship consistency checks are preferentially retained.

[0114] Step S150: Use the witness data as the variable value in the constraint structure, and generate a verifiable proof corresponding to the graph query result based on the prover key, graph query result, and constraint structure. Figure 1 The proof generation unit 106 can perform this step. There is a technically misunderstood point here: how the witness data corresponds to the constraint structure. The witness data is not appended to the constraint structure as independent text, but rather written into the structure as the specific values ​​of the variables within the constraint structure. That is, the constraint structure 202 first defines the variables and the relationships that must be satisfied between them, and then the witness data 204 generated in step S140 fills in the values ​​for these variables. Only after the variable values ​​are clearly defined do the relationships in the constraint structure 202 become verifiable, and only then does the proof generation unit 106 have actual objects to prove.

[0115] Figure 12 This illustrates the process of mapping constraint structure variables. Figure 12 This includes a raw variable area 1201, an intermediate variable area 1202, a graph query result area 1203, and a proof input combination area 1204. The raw variable area 1201 corresponds to the values ​​of the private graph data, such as node identifiers, edge start points, and edge end points. The intermediate variable area 1202 corresponds to the intermediate assignments constructed in step S140, such as edge selection flags, node distances, predecessor nodes, alignment values, and sorting boundary values. The graph query result area 1203 corresponds to the graph query results visible to the verification side. The proof input combination area 1204 represents the input set used by the proof generation unit 106 when forming the verifiable proof 207. In other words, step S150 does not only use the graph query result area 1203 for proof, nor only the raw variable area 1201, but uses both the raw variable area 1201 and the intermediate variable area 1202 as witness data 204, and then combines them with the graph query result area 1203 and the prover key 206 to generate the verifiable proof 207.

[0116] In one embodiment, the proof generation unit 106 can write the witness data 204 into the suggestion column, instance column, or other equivalent variable positions in the constraint structure 202. If the PLONK class or PLONKish constraint form is used, the private graph data values ​​and intermediate assignments can correspond to the values ​​in the suggestion column, the graph query results can correspond to the values ​​in the instance column, and the constraint structure 202 itself is defined by fixed columns and constraint expressions. For the technical solution of this embodiment, the key is not that a certain column naming must be used, but that the values ​​in the original variable area 1201 and the intermediate variable area 1202 need to be loaded into the constraint structure 202 so that subsequent relationship checks can be performed. For example, if the constraint structure 202 requires that the edge selection flag be 1 when an edge records the source node and the query source node matches, then the edge record source node value and the edge selection flag value must be written into the corresponding variable positions. If the constraint structure 202 requires that the current node distance is equal to the predecessor distance plus one, then the node distance value and the predecessor distance value must be written into the corresponding variable positions.

[0117] Figure 12 The proof input combination area 1204 can be further understood in conjunction with the graph query result 205. In this embodiment, the graph query result 205 is both the output content of the query side and the content subsequently visible to the verification side. When the proof generation unit 106 generates the verifiable proof 207 in step S150, it uses the graph query result 205 as part of the public input. In this way, the verification side can confirm whether the graph query result 205 is indeed derived from the witness data 204 that satisfies the constraint structure 202 without accessing the private graph data 203. There is no contradiction here that "the graph query result 205 is duplicated with the public input" because, for the zero-knowledge proof process, the graph query result 205 itself is the input content publicly visible to the verification side. Correspondingly, the witness data 204 is the value of a private variable held internally by the proof side.

[0118] Figure 13 The relation verification logic in the proof generation process is shown. Figure 13This includes relationship consistency verification 1301, set membership verification 1302, path relationship verification 1303, and sorting relationship verification 1304. Relationship consistency verification 1301 mainly focuses on the mapping relationship between edge records and node records, such as whether the start and end points of an edge record correspond to actual nodes. Set membership verification 1302 mainly focuses on member flags, alignment values, and boundary interval relationships in set expansion. Path relationship verification 1303 mainly focuses on node distance, predecessor relationships, and edge relaxation relationships. Sorting relationship verification 1304 mainly focuses on boundary values, equality flags, and order comparisons in result sorting. In step S150, the proof generation unit 106 does not generate multiple isolated proofs separately, but rather incorporates these relationship verifications into the same constraint structure 202, and then generates a verifiable proof 207 as a whole.

[0119] Taking the sorting relationship verification 1304 as an example, if the graph query request requires retrieving the first 20 items in descending order of time and then ascending order of node identifier, then in step S140, intermediate assignments such as the time value of the candidate record, the record identifier, the comparison result of the time of adjacent records, and the comparison result of the identifier of adjacent records can be generated. In step S150, after the proof generation unit 106 writes these intermediate assignments as variable values ​​into the constraint structure 202, it can check whether the sorting relationship is valid. In this way, the first 20 items in the graph query result are no longer just the output of the query execution unit 104, but become a sorting result that can be supported by mathematical relations. This processing method can also be used for message connection type queries, shortest path type queries, and multi-hop expansion type queries, only the focus of the relationship verification is different.

[0120] Figure 14 The processing procedure on the verification side is shown. Figure 14 The input includes a graph query result input 1401, a verifiable proof input 1402, a verification key input 1403, a verification algorithm execution 1404, and a trusted result output 1405. The verification input receiving unit 108 can receive the graph query result input 1401, the verifiable proof input 1402, and the verification key input 1403. The verification processing unit 109 then executes the verification algorithm 1404 based on these inputs. If the verification algorithm 1404 outputs a pass, the graph query result input 1401 can be used as the trusted result output 1405. The graph query result 205 and the verifiable proof 207 output in step S150 are precisely... Figure 14 One of the main inputs used on the verification side.

[0121] As can be seen from the embodiment consisting of steps S140 and S150, the witness data 204 is not an additional patch outside the zero-knowledge proof process, but a key component that allows the constraint structure 202 to be instantiated and enter into proof generation. First, the values ​​of the private graph data in the original variable area 1201 enable the constraint structure 202 to correspond to the real graph data. Second, the intermediate assignments in the intermediate variable area 1202 compress the complex graph query processing logic into a set of local relations. Third, the graph query result area 1203 participates in proof generation as a public output, allowing the verification side to confirm the credibility of the result without accessing the underlying graph data. Because this closed loop is formed between the graph query result 205, the witness data 204, and the constraint structure 202, the query side can not only output the result but also simultaneously output the verifiable proof 207 corresponding to the result.

[0122] In one embodiment, the graph database verification method can revolve around Figure 14 The processing steps are shown below. Figure 14 After the verification input receiving unit 108 receives the graph query result input 1401, the verifiable proof input 1402, and the verification key input 1403, the verification processing unit 109 executes the verification algorithm 1404 based on these three types of inputs and outputs a reliable result 1405 when the verification is successful. This process corresponds to... Figure 2 The graph query result 205, verifiable proof 207, verification key 208, and verification result 209 are included. In this embodiment, the verification side does not need to access the private graph data 203 again, nor does it need to re-execute the graph query calculation in step S130. Instead, it uses verification algorithm 1404 to determine whether there exists a set of witness data 204 corresponding to the graph query request, so that the constraint structure 202 corresponding to the graph query request is valid. If the answer is yes, the graph query result 205 can be considered a reliable result.

[0123] It is necessary to further explain why the verification side can confirm the credibility of the graph query result 205 without accessing the private graph data 203. The core reason is that the verifiable proof 207 does not prove that the graph query result 205 is valid in isolation, but rather that there exists a set of witness data 204, such that the witness data 204 and the graph query result 205 together satisfy the relational conditions in the constraint structure 202. When executing the verification algorithm 1404, the verification processing unit 109 does not need to know the specific value of the witness data 204, nor does it need to restore the original appearance of the private graph data 203. It only needs to check whether the verifiable proof 207 satisfies the verification rules of the corresponding proof system based on the verification key 208 and the graph query result 205. Since the verification key 208 is generated based on the constraint structure 202, and the graph query processing logic contained in the constraint structure 202 has been solidified into the verification rules used by the verification side through the key generation process, once the verification is successful, it means that the graph query result 205 is not an arbitrarily constructed result, but can be derived from the witness data 204 that satisfies the constraint structure 202.

[0124] Figure 15 This illustrates the logic of the validation side performing checks around different relationship types. Figure 15 This includes node extension relationship check 1501, path relationship check 1502, relationship matching check 1503, result filtering check 1504, and result sorting check 1505. Figure 15 The listed checks are not manually performed by the verification side after reading the private graph data 203 line by line. Instead, these relationships have been encoded into the constraint structure 202 and ultimately reflected in the verifiable proof 207. When the verification processing unit 109 verifies the verifiable proof 207, it is equivalent to verifying that these relationships are mathematically valid. The node extension relationship check 1501 mainly corresponds to... Figure 9 and Figure 10 The single-source expansion and set expansion logic in the code. Path relationship check 1502 mainly corresponds to... Figure 11 The graph query results include node distances, predecessor relationships, and edge relaxation relationships. Relationship matching check 1503 primarily addresses the mapping relationships between nodes and messages, messages and creators, nodes and locations, and nodes and organizations. Result filtering check 1504 primarily checks whether the candidate set meets the time, attribute, and set conditions. Result sorting check 205 primarily checks whether the record order in the graph query results meets the predetermined sorting rules.

[0125] In one embodiment, if the graph query request involves the output of the shortest path length, the verification processing unit 109 will focus its inspection on the path relationship check 1502. Taking the shortest path length query from node A to node B as an example, the query side can calculate the distance from node A to node B in step S130, and construct intermediate assignments related to node distance, predecessor node, and predecessor distance in step S140. In step S150, these intermediate assignments, along with the graph query result 205, are used to generate a verifiable proof 207. After receiving the graph query result 205, the verification side can include at least the final distance value corresponding to node B. The verification algorithm 1404 does not need to know the edge distribution of the entire graph, but it needs to confirm whether there is a set of witness data 204 that allows the distance value of node B to be obtained by propagating layer by layer through predecessor relationships, while all relevant edge relationships in the graph satisfy the edge relaxation condition. If the verification passes, it means that the distance of node B is not an arbitrarily specified value, but is consistent with a set of graph relationships that satisfy the path relationship processing 702.

[0126] To illustrate this more clearly, we can combine... Figure 11 Let's unfold it again. Figure 11 In the graph, the current node 1102 and the predecessor node 1103 are connected by edge relation 1106, and the node distance 1104 and the predecessor distance 1105 satisfy the relationship described by equations (7) and (8). If the query result 205 claims that the shortest path length between node B and node A is 3, then the verification algorithm 1404 needs to confirm that there is a set of witness data 204, which makes it possible for the distance value of node B to be propagated step by step from the predecessor distance to 3, and all edge relations involved in the propagation satisfy the path relation check 1502. If a node distance is forged, for example, the real shortest path length is 4 but the graph query result 205 outputs 3, then there will usually be a situation in which the relevant predecessor relation or edge relaxation relation cannot be satisfied at the same time, and the verifiable proof 207 will fail the verification. It can be seen that although the verification processing unit 109 cannot see the private graph data 203, it can still establish a credibility judgment on the shortest path result through the path relation check 1502.

[0127] In one embodiment, if the graph query request involves a message creator query, the verification processing unit 109 will focus more on the relationship matching check 1503 and the result filtering check 1504. Taking a creator query corresponding to a message object as an example, in step S130, the query side can find the creator node corresponding to the message identifier from the message-creator relationship and organize the identifier and public attributes of the creator node into the graph query result 205. In step S140, intermediate assignments related to message identifier matching, creator matching, and output mapping consistency can be further formed. In step S150, the verification proof 207 can be used to include these relationships into the proof object. After receiving the graph query result 205, the verification side does not need to access the complete message table and creator relationship table again. It only needs to confirm through the verification algorithm 1404 whether there is a set of witness data 204 that makes the relationship matching check 1503 between the message identifier, creator node, and result output valid. If the message creator is incorrectly replaced, or the mapping relationship between the message and the creator is manually changed, there will be an inconsistency between the graph query result 205 and the constraint structure 202, which will cause the verifiable proof 207 to fail verification.

[0128] In one embodiment, if the graph query request involves sorting the top 20 outputs, for example, if the graph query request requires the top 20 items to be sorted in descending order of message creation time and ascending order of message identifier, then the verification processing unit 109 will focus more on result filtering check 1504 and result sorting check 1505. In step S130, the query side can first form a candidate message set, then filter valid messages according to time boundaries, and then sort them by time and message identifier, extracting the top 20 records as the graph query result 205. In step S140, intermediate assignments related to time comparison values, identifier comparison values, adjacent record equality flags, the boundary value of the 20th record, and the relative boundary relationships of candidate records can be formed. In step S150, the verification proof 207 can be generated based on these intermediate assignments. After receiving the graph query result 205, the verification side does not need to re-sort all candidate messages, but needs to confirm the two types of relationships through verification algorithm 1404. One type is the order relationship within the graph query result 205, that is, whether the first 20 records meet the predetermined sorting order; the other type is the boundary relationship between the graph query result 205 and the remaining candidate records, that is, records that are not included in the first 20 should not be superior to the 20th record.

[0129] Figure 16 The logic for checking the relationships related to the sorting of the first 20 items is shown. Figure 16This includes the current result record 1601, the next result record 1602, the 20th boundary record 1603, and the remaining candidate records 1604. The order of the current result record 1601 and the next result record 1602 can be confirmed through result sorting check 1505 to ensure it follows the rules of time priority and identifier secondary priority. The order of the 20th boundary record 1603 and the remaining candidate records 1604 can be confirmed through result filtering check 1504 and result sorting check 1505: if the remaining candidate record 1604 meets the filtering conditions such as time boundary, its sorting position should not be higher than that of the 20th boundary record 1603. Thus, although the verification side cannot directly see the entire candidate set, it can confirm through verifiable proof 207 that the first 20 items in the graph query result 205 are both internally ordered and satisfy the first N-item truncation boundary relationship with the remaining candidates.

[0130] In one embodiment, the graph query result 205 may also include a small amount of public output information to allow the verification algorithm 1404 to more directly utilize public boundary conditions. This public output information may include one or more of the following: public boundary values, public message identifiers, public node identifiers, or public sorting results. For example, in a top 20 sorting query, the graph query result 205 may include the public boundary value of the 20th record; in a shortest path length query, the graph query result 205 may directly include the target node identifier and the final distance value; in a message creator query, the graph query result 205 may include the message identifier and the creator identifier. In this way, the verification processing unit 109 can directly use this public output information as input to execute the verification algorithm 1404. The introduction of public output information does not change the basic principle of verification; its role is more about enabling the verification side to more clearly understand which contents of the current graph query result 205 are the public inputs around which the verification algorithm 1404 operates.

[0131] Figure 14 and Figure 16 In combination, this illustrates the processing chain on the verification side. Graph query result input 1401 provides the public result that the verification side needs to confirm; verifiable proof input 1402 provides the proof data generated by the query side based on constraint structure 202 and witness data 204; and verification key input 1403 provides the verification key 208 adapted to constraint structure 202. After the verification processing unit 109 executes verification algorithm 1404, if the result is successful, the trusted result output 1405 can directly use the content in graph query result input 1401. Here, "trusted" does not mean that the verification side recalculated the query itself, but rather that the verification side has confirmed the existence of a set of witness data 204 consistent with the private graph data 203, making the graph query processing logic corresponding to graph query request 201 valid, and allowing the current graph query result 205 to be derived.

[0132] Depend on Figures 14 to 16As can be seen from the embodiments, there is a strict sequential relationship between the graph database verification method and the graph database query method. The query side organizes the graph query request 201, private graph data 203, witness data 204, graph query result 205, and verifiable proof 207 into a complete proof object through steps S110 to S150; the verification side executes the verification algorithm 1404 through the graph query result input 1401, verifiable proof input 1402, and verification key input 1403. Thus, the query side and the verification side are not two loosely connected processes, but rather a closed-loop processing chain formed on the common basis of constraint structure 202 and witness data 204. This closed-loop processing chain ensures that the credibility of the graph query result 205 no longer depends on a unilateral declaration by the executor, but rather on the existence of witness data 204 that satisfies constraint structure 202. For sensitive graph data scenarios, this mechanism can establish a verification basis for the graph query result 205 without disclosing the underlying graph data 203.

[0133] In one different embodiment, the verification side is not limited to being deployed on a single independent device; it can also be deployed on the same device as part of the query side logic. For example, in an integrated deployment scenario, the electronic device may include a query request receiving unit 102, a query execution unit 104, and a proof generation unit 106, or it may include a verification processing unit 109. In this way, the graph query result 205 and the verifiable proof 207 can be generated and verified immediately within the device, thereby being used for local auditing, local self-inspection, or internal compliance checks. Compared with distributed verification, integrated deployment is more suitable for internal control scenarios; conversely, distributed deployment is more suitable for third-party verification scenarios. Although the deployment forms are different, the objects on which the verification side executes the verification algorithm 1404 remain unchanged: the graph query result 205, the verifiable proof 207, and the verification key 208.

[0134] The above section provides a detailed explanation of the graph database verification method. After receiving the graph query result 205, the verifiable proof 207, and the verification key 208, the verification processing unit 109 does not need to access the private graph data 203, nor does it need to re-execute the complex graph algorithm. Instead, it uses the verification algorithm 1404 to confirm whether witness data 204 exists that satisfies the constraint structure 202. Whether it is single-source expansion, set expansion, shortest path distance processing, message creator matching, or the first 20 items sorting, as long as the query side has encoded the corresponding graph query processing logic into the constraint structure 202 and constructed the corresponding witness data 204 in step S140, the verification side can use it. Figures 14 to 16 The processing method shown is used to determine the credibility of graph query result 205.

[0135] In one embodiment, an electronic device can serve as the execution carrier for graph database query methods and graph database verification methods. Figure 17 The structural form of the electronic device is shown. Figure 17 It includes a processor 1701, a memory 1702, a bus 1703, a communication interface 1704, and a program instruction storage area 1705. The processor 1701 can call program instructions from the memory 1702 and interact with the communication interface 1704 and the program instruction storage area 1705 via the bus 1703. The program instruction storage area 1705 can store software instructions for implementing the query request receiving unit 102, the constraint structure determination unit 103, the query execution unit 104, the witness data construction unit 105, the proof generation unit 106, the proof output unit 107, the verification input receiving unit 108, and the verification processing unit 109. Thus, Figure 1 The functional units in the process need not be understood as physical modules that must exist independently; they can also be implemented on the processor 1701 by program logic in the same electronic device.

[0136] When the electronic device is used as a query-side device, the processor 1701 can execute programs related to query request reception, constraint structure determination, graph query execution, witness data construction, and verifiable proof generation. The communication interface 1704 can receive graph query requests and output graph query results and verifiable proofs to the outside. The memory 1702 can store the data content corresponding to the private graph data storage area 101, or maintain an access cache to an external graph database. If the electronic device is used as a verification-side device, the processor 1701 can execute verification input reception and verification algorithm processing programs, and the communication interface 1704 can receive graph query results, verifiable proofs, and verification keys. Therefore, Figure 17 The electronic device shown can perform only query-side functions, only verification-side functions, or a combination of query-side and verification-side functions.

[0137] In one embodiment, the program flow executed inside the electronic device can be consistent with... Figure 5 and Figure 14 This establishes a one-to-one correspondence. Processor 1701 executes... Figure 5 In the corresponding program, the process can first respond to the graph query request receiving action, then parse the parameters used to generate constraint structure 202 according to the graph query request, then perform a graph query on private graph data 203 to form graph query result 205, then construct witness data 204 based on the private graph data values ​​and intermediate assignments, and finally use the prover key 206 to generate verifiable proof 207. Processor 1701 executes and Figure 14 In the corresponding program, upon receiving the graph query result 205, the verifiable proof 207, and the verification key 208, the verification algorithm can be run, and the verification result 209 can be output. This implementation method allows the verifiable query capability of the graph database to be embedded in electronic devices without requiring external systems to additionally program the underlying proof logic.

[0138] Figure 18 This demonstrates a deployment model that separates the query side and the verification side. Figure 18 The system includes a query device 1801, a verification device 1802, and a communication link 1803. The query device 1801 may internally include a private graph data storage area 101, a query request receiving unit 102, a constraint structure determination unit 103, a query execution unit 104, a witness data construction unit 105, a proof generation unit 106, and a proof output unit 107. The verification device 1802 may internally include a verification input receiving unit 108 and a verification processing unit 109. The communication link 1803 is used to transmit the graph query result 205, the verifiable proof 207, and the verification key 208. Figure 18 In the deployment method shown, verification device 1802 does not need to access the private graph data 203 in query device 1801; it only needs to receive public results and supporting materials to perform verification. This deployment method is more suitable for scenarios involving cross-organizational data sharing, external auditing, and third-party verification.

[0139] In a different embodiment, it may also be adopted Figure 19 The integrated deployment method shown is illustrated. Figure 19 The system includes an integrated device 1901, which internally possesses query execution, proof generation, and verification processing capabilities. If the system is used for local self-inspection, local auditing, or internal compliance verification, it is not necessary to separate the query and verification sides. In the integrated device 1901, after the query execution unit 104 outputs the graph query result 205, the proof generation unit 106 can immediately generate a verifiable proof 207, and the verification processing unit 109 can immediately verify the proof using the verification key 208. This method typically has shorter processing latency because the graph query result 205 and the verifiable proof 207 can participate in verification without external transmission, but it leans more towards internal system verification in terms of trust structure. Figure 18 and Figure 19 Both deployment methods shown can be adapted to the technical solution in this embodiment. The main difference between the two lies in the system boundary, rather than in the graph query verifiable principle itself.

[0140] In one embodiment, electronic devices can share common parameters when processing different graph query tasks, but are not required to share identical constraint structures. The reuse of common parameters corresponds to... Figure 4In the common parameter generation stage 401, this stage is not directly bound to a specific query. For the query task itself, the electronic device can select suitable parts from the predefined basic graph operation constraint template and combine them into a constraint structure 202 corresponding to the current graph query request. This approach has a practical advantage: when there are many types of graph queries, it is not necessary to design a very large and fixed constraint structure for all queries, but rather to organize the graph query processing logic at a smaller granularity. For example, when the electronic device faces a single-source extended class query, it can prioritize using... Figure 9 The corresponding edge selection relationship and output consistency relationship; when facing collection extension class queries, it is advisable to use it first. Figure 10 The corresponding alignment value is 1005, the next alignment value is 1006, and the member flag is 1007; when dealing with shortest path queries, these can be used preferentially. Figure 11 The corresponding node distance is 1104, the predecessor node is 1103, and the predecessor distance is 1105. This reduces the introduction of constraints that are irrelevant to the current query task.

[0141] From an engineering perspective, this approach of selecting and combining constraint structures based on graph query processing logic is beneficial for controlling constraint size. If all possible graph query processing logic is pre-placed into a single, overly large constraint structure, subsequent proof generation would require carrying numerous relational conditions not currently used in the task. Even if these relational conditions are logically irrelevant to the current task, they still increase the complexity of constraint organization. By using a basic graph operation template combination method, electronic devices can focus on the actual node expansion, path relationship processing, relation matching, result filtering, and result sorting involved in the current graph query request. This not only helps shorten proof generation time but also reduces the organizational pressure on witness data 204.

[0142] In one embodiment, the organization of the graph query result 205 can also vary depending on the task type. If the graph query task is a simple message creator query, the graph query result 205 may include the message identifier, creator identifier, and creator public attributes. If the graph query task is a shortest path length query, the graph query result 205 may include the source node identifier, target node identifier, and shortest path length. If the graph query task is a friend message sorting query, the graph query result 205 may include the friend node identifier, message identifier, message time, message content summary, and sorting position. The verification side truly relies on the publicly output content in the graph query result 205, not all the intermediate states known to the query side. Therefore, when outputting the graph query result 205, the electronic device can retain only the public items required by the verification side and business users, while keeping the remaining relationship information in the witness data 204, with its correctness carried by the verifiable proof 207.

[0143] Figure 20This illustrates an interactive process surrounding graph query result 205 and verifiable proof 207. Figure 20 This includes query request input 2001, graph query result output 2002, verifiable proof output 2003, and verification conclusion output 2004. After query request input 2001 enters the query side, graph query result output 2002 and verifiable proof output 2003 are generated together. Subsequently, the verification side forms verification conclusion output 2004 based on verification key 208 and verification algorithm 1404. Figure 20 This indicates that, compared to ordinary graph database queries, verifiable queries in graph databases do not simply return an additional field; rather, they add a proof link that is generated synchronously with the result in the query output chain. This proof link ensures that the credibility of graph query result 205 no longer relies on the external user's unilateral trust in the executor, but can be confirmed by the verification side through mathematical verification.

[0144] In one embodiment, the technical effects of this embodiment can be combined Figures 1 to 20 Analyze the query. Query 201 in the graph. Figure 5 The corresponding processing chain does not directly map to ordinary database output. Instead, it is converted into constraint structure 202 by constraint structure determination unit 103, then graph query result 205 is formed on private graph data 203 by query execution unit 104, witness data 204 is formed by witness data construction unit 105, and verifiable proof 207 is generated by proof generation unit 106. Since witness data 204 includes not only private graph data values ​​but also intermediate assignments required for constraint structure 202 to hold, the complex graph query processing logic can be decomposed into several checkable local relations. In this way, verification processing unit 109 does not need to rerun the complete graph algorithm or access private graph data 203 to determine the credibility of the result based on graph query result 205, verification key 208, and verifiable proof 207. Compared with schemes that rely solely on execution environment credibility, this embodiment can establish the credibility of the result on the basis of constraint holding and verifiable proof. Compared with the method of directly and gradually circuitizing the entire complex graph algorithm, this embodiment further reduces the implementation pressure on the proof side by organizing intermediate assignments and decomposing basic graph operations.

[0145] In one embodiment, the effectiveness of this solution can also be further understood from the perspective of data representation. Figure 8 The edge list 801 is preferred not because it has the smallest storage size in all database scenarios, but because in verifiable query scenarios of graph databases, edge list 801 makes it easier to translate edge existence relationships, node set relationships, and relationship matching relationships into constraints. If a graph edge representation that relies on dynamic index access is used instead, additional index location and range judgment logic usually needs to be introduced during the proof phase. Figure 8The edge list 801 shown can transform this dynamic recovery pressure into explicit edge record inspection pressure, which is more conducive to constructing relational consistency constraints around the source node identifier 803, the target node identifier 804, and the edge attribute 805. This trade-off reflects proof friendliness, rather than simply a database storage compression goal.

[0146] In one different embodiment, the electronic device can also adjust the retention range of witness data 204 according to the task type. If the graph query task is relatively simple, such as involving only single edge relationship matching, then witness data 204 can mainly include message identifier, node identifier, and matching flag. If the graph query task is more complex, such as involving candidate set expansion within a 3-hop range and sorting of the top 20 items, then witness data 204 can further include node distance, predecessor relationship, set membership flag, sorting boundary value, and remaining candidate comparison value. This scalable organization allows witness data 204 to fit the current query task as closely as possible, without carrying a large number of irrelevant intermediate assignments for the sake of a uniform format. This ensures good engineering adaptability for the query side during implementation.

[0147] The above section further elaborates on the verifiable query scheme for graph databases from several perspectives, including electronic devices, deployment methods, constraint template combinations, result output structure, and technical effects. Figures 17 to 20 The content shown indicates that the graph database query method and verification method in this embodiment are not limited to a fixed software architecture, but can achieve consistent technical principles under different electronic devices, different system boundaries and different graph query tasks. That is: construct a constraint structure 202 around the graph query processing logic, construct witness data 204 around the private graph data 203 and intermediate states, generate a verifiable proof 207 based on the prover key 206, and then the verification side completes the credibility confirmation using the verification key 208 and the graph query result 205.

[0148] In one embodiment, the graph database query method and graph database validation method can be explained in conjunction with a specific query example. The purpose of this is not to introduce new technical approaches, but rather to... Figures 1 to 20 The object relationships, step relationships, and constraint relationships already developed are placed in a more complete application scenario to illustrate how constraint structure 202, witness data 204, graph query results 205, and verifiable proof 207 work together.

[0149] Let's first look at the friend-based extended query. Suppose that query request 201 requests to find a set of target nodes within a 2-hop range, starting from source node A. In step S110, after receiving the request, query request receiving unit 102 identifies that the request involves at least... Figure 7The node expansion process is 701. If the query results also require deduplication or sorting by node identifier, result filtering process 704 and result sorting process 705 will also be involved. In step S120, the constraint structure determination unit 103 can determine the constraint structure 202 corresponding to the request. In this constraint structure 202, a part of the constraints is used to characterize the edge selection relationship from the source node A to the 1-hop candidate set, and another part of the constraints is used to characterize the set expansion relationship from the 1-hop candidate set to the 2-hop candidate set. If it is also required to remove duplicate nodes, the constraint structure 202 can also include relationship conditions related to deduplication consistency.

[0150] In step S130, the query execution unit 104 performs expansion processing on the edge list 801. For 1-hop expansion, the target node corresponding to the edge record whose edge starting point is equal to the source node A can enter the 1-hop candidate set. For 2-hop expansion, the 1-hop candidate set is used as the source node set 1001, and then the edge record whose source node belongs to this set is searched in the edge list 1002. Its target node can enter the 2-hop candidate set. In step S140, the witness data construction unit 105 not only retains the 2-hop candidate set itself, but also retains intermediate assignments such as the edge selection flag 904, alignment value 1005, next alignment value 1006, and member flag 1007. In this way, when the proof generation unit 106 generates the verifiable proof 207 in step S150, it can prove two points: first, each node in the 2-hop candidate set comes from a real edge relationship; second, the source node in the expansion process does indeed belong to the upper-level candidate set, and is not arbitrarily forged.

[0151] After receiving the graph query result 205, the verifiable proof 207, and the verification key 208, the verification processing unit 109 executes the verification algorithm 1404. At this point, even if the verification side does not possess the edge list 801, it can confirm the existence of a set of witness data 204, enabling... Figure 9 and Figure 10 The corresponding single-source extension relation, set extension relation, and member correspondence relation are all valid. If the verification passes, the 2-hop target node set output in graph query result 205 can be considered a reliable result. This example illustrates that the reason why multi-hop extension type queries can be verified is not because the verification side re-executes the graph traversal, but because the query side compresses the extension process into edge selection relations and member positioning relations, and solidifies them into constraint structure 202.

[0152] Next, let's look at the shortest path length query. Graph query request 201 requests the output of the shortest path length between source node A and target node B. In step S110, query request receiving unit 102 identifies the source node parameter 601 and target node parameter 602. In step S120, constraint structure determination unit 103 introduces path relationship processing 702 based on this. In step S130, query execution unit 104 can perform breadth-first search or other processing methods suitable for shortest paths in unweighted graphs to obtain the final distance to node B, and simultaneously determine the predecessor node 1103 and predecessor distance 1105 for reachable nodes in the path. In step S140, witness data construction unit 105 can organize the node distance 1104, predecessor node 1103, and predecessor distance 1105 into part of witness data 204. If a node is not the source node, its node distance 1104 and predecessor distance 1105 can satisfy equation (7), and there should be a real edge between the predecessor node 1103 and the current node 1102 in the edge relationship list.

[0153] In this example, the proof generation unit 106 in step S150 writes these values ​​into the constraint structure 202 and generates a verifiable proof 207. When the verification side receives the graph query result 205, the graph query result 205 may include at least the source node A, the target node B, and the shortest path length. The verification processing unit 109 does not need to know which nodes are traversed in the complete path, nor does it need to rerun the breadth-first search. Instead, it only needs to confirm, based on the verification key 208 and the verifiable proof 207, whether there exists a set of node distance, predecessor node, and predecessor distance values ​​consistent with the private graph data 203, such that the final distance of the target node B can be supported by both the local and global relationships in the path relationship processing 702. If the verification passes, the shortest path length in the graph query result 205 can be considered reliable. This example illustrates a core idea of ​​this embodiment: the focus of path query verification is not on replaying the control flow, but on proving that the local distance propagation relationship and the global edge relaxation relationship are simultaneously valid.

[0154] Next, consider the message association sorting query. Query request 201 requests to find messages created before a given time boundary from friends within one or two hops of source node A, and output the top 20 messages in descending order of message time and ascending order of message identifier. For this task, in step S110, the query request receiving unit 102 will identify four types of processing logic: node expansion, relationship matching, result filtering, and result sorting. In step S120, the constraint structure determination unit 103 can simultaneously introduce... Figure 7The process includes node expansion processing 701, relationship matching processing 703, result filtering processing 704, and result sorting processing 705. In step S130, the query execution unit 104 first expands to obtain the friend set, then searches for message records in the message-creator relationship where the creator belongs to the friend set, then filters out messages that meet the conditions based on time boundaries, and finally sorts them by time and message identifier and extracts the top 20 items to form the graph query result 205.

[0155] Step S140 in this example is particularly important. The first 20 results alone are insufficient to explain why they hold true. The witness data construction unit 105 can further retain the following intermediate assignments: friend set member flag, message creator alignment value, time boundary comparison value, time comparison value between adjacent result records, equality flag, and comparison value between the 20th boundary record and the remaining candidate records. Thus, the proof generation unit 106 in step S150 can incorporate the relational basis behind the first 20 sorting results into the verifiable proof 207. The verification side does not need to access all candidate messages or see all friend relationships during verification, but rather confirms at least three types of relationships through the verifiable proof 207: the friend set expansion relationship holds, the message creator matching relationship holds, and the first 20 sorting boundary relationship holds. If all three types of relationships are proven, the first 20 messages in the graph query result 205 can be considered credible.

[0156] The friend extension query corresponds to the set extension direction. The shortest path length query corresponds to the shortest path verification direction. The message association sorting query corresponds to the basic graph operation combination direction. Observing these three types of instances together makes the common processing framework of this embodiment clearer. Step S110 does not directly verify the result, but first determines what query task needs to be processed. Step S120 does not directly calculate the result, but first determines which relationships should be proved. Step S130 is responsible for calculating the result. Step S140 is responsible for solidifying the necessary intermediate states behind the result into witness data 204. Step S150 is responsible for writing this witness data 204 into the constraint structure 202, and generating a verifiable proof 207 with the help of the prover key 206. The verification side then... Figure 14 The process shown determines the reliability of the query result 205. It can be seen that the query method and verification method in this embodiment are not two separate processes, but rather organized around the same constraint structure 202 and the same witness data 204.

[0157] From a technical perspective, existing graph database queries, when used across entities, typically only return results directly, making it difficult to prove the correctness of the results without disclosing the underlying graph data. If relying solely on the executor's declaration, external users cannot determine whether the results originate from complete graph data or whether they strictly adhere to the predetermined query logic. The technical solution provided in this embodiment transforms the graph query processing logic into a constraint structure 202 in step S120, organizes the private graph data values ​​and intermediate assignments into witness data 204 in step S140, and generates a verifiable proof 207 in step S150. Since the verification side can independently execute the verification algorithm 1404 using the graph query result 205, the verification key 208, and the verifiable proof 207, the credibility of the graph query result 205 no longer needs to be based on the executor's unilateral declaration but can be based on the mathematical foundation of the constraint's validity. Therefore, this embodiment addresses the problem of difficulty in verifying query results in the background art.

[0158] From the perspective of technical implementation challenges, complex graph queries typically involve multiple processes such as node expansion, path propagation, relation joining, and sorting / truncation. If traditional graph algorithms are directly translated into a single large circuit, not only will the constraint size easily expand with the number of hops, path length, and candidates, but a large amount of program-level control flow will also be brought into the proof process. This embodiment does not follow this direct overall circuit approach. Instead, it decomposes complex graph queries into basic graph operations such as node expansion processing 701, path relation processing 702, relation matching processing 703, result filtering processing 704, and result sorting processing 705, and constructs intermediate assignments around these basic graph operations. In this way, the focus of proof generation shifts from control flow replay to relation consistency verification. Since intermediate assignments can compress the complex query process into a set of local relations, this embodiment can reduce the implementation pressure of the proof stage while maintaining the verifiability of the graph query.

[0159] From a data security perspective, this embodiment discloses the graph query result 205 and the verifiable proof 207 to the verification side, rather than the underlying private graph data 203. While witness data 204 participates in proof generation, it does not need to be sent entirely to the verification side. The verification side confirms through verification algorithm 1404 the existence of a set of witness data 204 that makes the constraint structure 202 valid, rather than obtaining the witness data 204 itself. In other words, the verification side obtains proof of the result's correctness, not a copy of the private graph data 203 or plaintext of intermediate states. This approach reduces the chance of directly exposing node relationships, edge relationships, attribute records, and local graph structures, making it suitable for scenarios where private graph data is sensitive but query results require external confirmation.

[0160] From the perspective of result quality, the result sorting and boundary relationship processing in this embodiment can not only verify the relative order between output records, but also verify the boundary relationship between the output results and the remaining candidate records. Figure 16 For example, the relationship between the current result record 1601 and the next result record 1602 can verify whether the sorting is correct, and the relationship between the 20th boundary record 1603 and the remaining candidate records 1604 can verify whether the truncation of the first 20 items is correct. Thus, the verification side not only knows that the returned records themselves are ordered, but also that the unreturned candidate records have not crossed the boundary. Therefore, this embodiment can elevate the reliability of the results from simple internal sorting to overall sorting reliability that includes boundary validity.

[0161] As can be further seen from the embodiments constituted in this section, the technical solution provided in this embodiment can solve the problems of difficulty in verifying graph query results, high cost of direct circuitization of complex graph queries, and unsuitability for public disclosure of private graph data because: after the graph query request 201 enters the system, it is not directly converted into ordinary output, but is first mapped to constraint structure 202; the necessary intermediate states generated during the graph query processing are not discarded after the query ends, but are organized into witness data 204; the verifiable proof 207 does not exist independently of the graph query result 205, but is constrained by constraint structure 202 together with the graph query result 205. Because these three points are simultaneously true, the query side can provide results, the verification side can independently confirm the credibility of the results, and the underlying private graph data 203 does not need to be disclosed to the verification side.

[0162] In one embodiment, the aforementioned Figures 1 to 20The processing procedure shown can be further extended to different graph database deployment environments without changing its basic technical principles. If the graph database is deployed on a central server, the private graph data storage area 101, query request receiving unit 102, constraint structure determination unit 103, query execution unit 104, witness data construction unit 105, and proof generation unit 106 can be centrally deployed on the server side, and the external verification device only undertakes the functions of the verification input receiving unit 108 and the verification processing unit 109. If the graph database is deployed on an edge node or local terminal, the processor 1701 can simultaneously undertake query calculation and proof generation tasks, and verification can also be performed within the same device. For hybrid deployment scenarios, the central server can also execute steps S110 to S140, and then send the graph query result 205, verifiable proof 207, and verification key 208 to the edge terminal for verification. Under different deployment modes, what changes is the location of the data flow and the main body responsible for computation. What remains unchanged is that the graph query request 201 must be mapped to the constraint structure 202, the witness data 204 must be composed of private graph data values ​​and intermediate assignments, the graph query result 205 must be output synchronously with the verifiable proof 207, and the verification side must execute the verification algorithm 1404 based on the verification key 208, the graph query result 205 and the verifiable proof 207.

[0163] In one embodiment, the graph query request 201 is not limited to a single independent query, but can also be a subtask within a compound query. If the upper-layer business breaks down a complex business query into multiple graph operation subtasks, each subtask can correspond to a constraint structure 202, or multiple subtasks can share a set of basic graph operation constraint templates and be combined sequentially. In this approach, the query execution unit 104 can execute graph query processing in the order of subtasks, while the witness data construction unit 105 can organize the intermediate assignments that truly need to be proven in each subtask into segments. One practical significance of this is that some graph database business queries do not end in a single step, but go through multiple stages such as friend set generation, message mapping, location matching, time filtering, and result sorting. If each stage organizes the witness data 204 around relational consistency, although the overall query remains complex, the proof objective of each stage is clearer, and it is not necessary to squeeze all the logic into a single indivisible large object.

[0164] In one different embodiment, the relationship matching process 703 can be extended to more graph object types without changing its processing logic. In addition to matching messages with creators, it can also include matching between users and locations, users and organizations, messages and tags, and entities and attribute records. For these matching relationships, the query execution unit 104 in step S130 can perform join or lookup operations based on the private graph data 203. In step S140, the witness data construction unit 105 can retain intermediate assignments such as message identifiers, object identifiers, relationship identifiers, matching flags, and output mapping values ​​for the matching relationships. In step S150, the proof generation unit 106 generates verifiable proofs 207 based on these intermediate assignments. As long as the relationship matching can be represented as a mapping consistency relationship between objects, the constraint structure 202 in this embodiment can carry the corresponding proof logic. Therefore, the relationship matching process 703 in this embodiment is not a limitation on a specific social graph pattern, but a general expression of a class of graph object mapping relationships.

[0165] In one embodiment, the result sorting process 705 can also use different combinations of sorting keys without changing the sorting verification principle. Examples given earlier frequently include time, distance, node identifier, and attribute values. For other business scenarios, popularity values, risk values, weight values, or other comparable fields can also be used as sorting criteria. When there is only one sorting key, step S140 can retain the comparison values ​​between adjacent records; when there are multiple sorting keys, step S140 can retain the comparison values ​​of the primary sorting key, the comparison values ​​of the secondary sorting keys, and the equality flag. Thus, when generating the verifiable proof 207 in step S150, it can prove that the output records in the graph query result 205 satisfy the lexicographical sorting relationship, and... Figure 16 The boundary relationships in the code still apply. In other words, sort validation does not rely on the business semantics of the sorting fields themselves, but rather on the fact that these fields can be compared and form stable order relationships.

[0166] In one embodiment, the intermediate assignments in step S140 can employ different granularities of retention based on the complexity of the query task. If the query task only requires verifying whether a node belongs to the result set, then membership flags and a small number of edge relation values ​​are sufficient. If the query task involves multi-hop expansion and sort truncation, then the intermediate assignments can be expanded accordingly to include node distance, predecessor node, predecessor distance, alignment value, next alignment value, edge selection flag, candidate boundary value, and sort equality flag, etc. This scalable approach reflects an implementation trade-off: the witness data 204 is not necessarily more detailed, but rather sufficient to support the validity of the constraint structure 202. Retaining too little data will make it difficult to verify certain key relationships; retaining too much data will increase the complexity of the proof organization. Selecting intermediate assignments around the basic graph operations allows step S140 to maintain a scale that matches the current graph query request 201.

[0167] In one embodiment, if an edge list 801 is used to represent graph edge relationships, the data flow between steps S130 and S150 is easier to connect. Edge records 802 in edge list 801 naturally include source node identifiers 803 and target node identifiers 804, making it suitable for directly generating edge selection flags 904, member flags 1007, and predecessor edge relationships. If the underlying graph database uses other graph index structures, the edge relationships related to the current query can also be extracted into the form of edge list 801 before entering the proof process. This is because the proof phase focuses more on whether the edge records satisfy the relational conditions, rather than on the compression method used by the underlying graph database to store edges. Organizing the constraint structure 202 around edge list 801 reduces the interference of the dynamic index recovery process on constraint expression, making the mapping from query logic to proof logic more direct.

[0168] For the three examples mentioned above, a unified analysis can be performed on the overall chain. In friend-based extended queries, the key technical approach is to break down the node extension process into edge selection relationships and set membership relationships, and then... Figure 9 and Figure 10 The intermediate assignments shown provide supporting proof. In shortest path length queries, the key technical approach is to compress the path search process into... Figure 11 The node distances, predecessor nodes, and edge relaxation relationships are shown, without requiring verification of the complete search process. In message association sorting queries, the key technical approach is to break down expansion, matching, filtering, and sorting into basic relationships, and then... Figure 16 The internal order and boundary relationships in the graph query jointly support the first N results. Although the three instances are oriented towards different graph query tasks, they are consistent in their processing structure. They first identify the graph query processing logic from the graph query request 201, then use the constraint structure 202 to carry this logic, use the witness data 204 to carry the variable values ​​required to implement this logic, and finally use the verifiable proof 207 to bind the graph query result 205 to the constraint structure 202.

[0169] Based on the aforementioned processing chain, it can be further deduced that this embodiment can solve several key problems raised in the background art. Regarding the difficulty in verifying query results, this embodiment does not stop at adding explanations after returning the results, but instead, through steps S120, S140, and S150, makes the graph query result 205 directly correspond to a verifiable proof object. Therefore, external users do not need to access the private graph data 203, nor do they need to simply trust the executor, to confirm the reliability of the result through verification algorithm 1404. Regarding the problem of high overall circuit burden in complex graph queries, this embodiment transforms the control flow proof, which might have expanded rapidly with traversal depth and candidate size, into a local relation consistency proof through basic graph operation decomposition and intermediate assignment organization. This does not eliminate all proof costs, but it concentrates the proof pressure on truly necessary relations, rather than allowing program-level control flow to occupy the main overhead. Regarding the problem of private graph data being unsuitable for public disclosure, this embodiment discloses the graph query result 205, the verifiable proof 207, and necessary public output information to the verification side, rather than the plaintext content of the underlying node and edge relationships. The verification side confirms the existence of witness data 204 that satisfies constraint structure 202, rather than directly obtaining witness data 204 itself, thus reducing the risk of private graph data exposure.

[0170] From the perspective of the technical effect formation mechanism, this embodiment can simultaneously ensure the credibility of the result and the confidentiality of the data. This is not because it simply superimposes two independent processes, query and proof, but because the constraint structure 202 and witness data 204 are organized around the verification target during the query stage. Without step S120, the graph query processing logic cannot be converted into a checkable relation in advance; without step S140, the intermediate state cannot be converted into variable values ​​usable for subsequent proof; without step S150, there is no verifiable link between the graph query result 205 and the graph query processing logic. Accordingly, the reason why the verification side can determine the credibility of the graph query result 205 without disclosing the private graph data 203 is because the verification rules corresponding to the verification key 208 have solidified the graph query processing logic in the constraint structure 202, and the verifiable proof 207 shows that there exists a set of witness data 204 consistent with the private graph data 203 that satisfies these logics. Thus, the credibility of the query result is based on the mathematical condition that the constraint is met, rather than on the identity of the executing entity or the credibility of the operating environment.

[0171] From an engineering deployment perspective, the technical solution in this embodiment also has good adaptability. Figures 17 to 20This indicates that the solution can be deployed on the server side, the terminal side, or the edge side; it can support both separate query and verification sides, as well as integrated verification on the same device; and it can be designed for single query tasks or sub-task chains within complex queries. Under different deployment configurations, the roles of the processor 1701, memory 1702, and communication interface 1704 will vary, but the technical essence embodied in steps S110 to S150 remains unchanged, as does the technical essence of the verification side executing the verification algorithm 1404 around the graph query result 205, the verifiable proof 207, and the verification key 208.

[0172] In conclusion, Figures 1 to 20 The illustrated implementation shows that a graph database query method, verification method, and electronic device can receive a graph query request for private graph data, determine the constraint structure corresponding to the graph query request, execute the graph query request based on the private graph data to obtain the graph query result, construct witness data including private graph data values ​​and intermediate assignments, use the witness data as variable values ​​in the constraint structure to generate a verifiable proof corresponding to the graph query result, and then have the verification side execute a verification algorithm based on the graph query result, the verifiable proof, and the verification key. Because this technical solution transcribes the graph query processing logic, such as node expansion, path relationship processing, relationship matching, result filtering, and result sorting, into verifiable constraint relationships, and retains the variable values ​​required for these constraints to hold through the witness data 204, it can establish a verification basis for the graph query result without disclosing the underlying private graph data. Furthermore, because complex graph queries are decomposed into basic graph operations and proof objects are organized around intermediate assignments, the implementation pressure of directly mapping the entire complex graph algorithm to a single proof structure can be reduced, thus making the verifiable output of the graph database query result feasible and engineering-practical.

[0173] It should be understood that the method steps in the foregoing embodiments can be implemented by program instructions controlling related hardware, or by dedicated circuits, programmable logic devices, or a combination thereof. Correspondingly, the systems, devices, modules, units, or components in the foregoing embodiments can be implemented in software, hardware, or a combination of both. The division of modules, units, or components is merely a logical division for the purpose of illustrating the technical solution; in actual implementation, they can be combined, split, or integrated as needed.

[0174] In one embodiment, the electronic device may include a processor, a memory, and a communication interface, wherein the memory is used to store program instructions, and the processor is used to call and execute the program instructions to implement all or part of the steps in the foregoing method embodiments. The electronic device may be a server, a terminal device, an edge computing node, a cloud computing device, or other device with data processing capabilities.

[0175] In one embodiment, this application may also be implemented in the form of a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, causes the processor to implement all or part of the steps in the foregoing method embodiments. The computer-readable storage medium may be a read-only memory, random access memory, flash memory, hard disk, solid-state drive, optical disk, or other non-transitory storage medium.

[0176] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0177] Furthermore, the terms "including," "comprising," and "having" used in the specification are all non-exclusive inclusions; the terms "first," "second," etc., are only used to distinguish technical features and do not indicate limitations on order, quantity, or importance. The execution order of each step in the method embodiments is also not absolutely limited. Without departing from the technical concept of this application, the steps can be adjusted in order, executed in parallel, combined, or split for execution.

Claims

1. A query method for a graph database, comprising: Receive graph query requests for private graph data; Determine the constraint structure corresponding to the graph query request. The constraint structure is used to characterize at least one graph query processing logic among node expansion, path relationship processing, relationship matching, result filtering, or result sorting. The graph query request is executed based on the private graph data to obtain the graph query result; Construct witness data, which includes the values ​​of the private graph data and intermediate assignments used to satisfy the constraint structure; The witness data is used as the variable value in the constraint structure, and a verifiable proof corresponding to the graph query result is generated based on the prover key, the graph query result, and the constraint structure. Output the graph query results and the verifiable proof.

2. The graph database query method as described in claim 1, wherein: The node expansion includes single-source expansion or set expansion; or, The path relationship processing includes shortest path distance processing; or, The relation matching includes bidirectional relation normalization matching; or, The result filtering includes candidate set filtering; or, The result sorting includes sorting based on time, distance, node identifier, or attribute value.

3. The graph database query method as described in claim 1, wherein, The constructed witness data includes: Construct at least one intermediate value from among node distance, predecessor node, predecessor distance, edge selection flag, set member flag, alignment value, next alignment value, and sorting boundary value to ensure that the relational consistency condition in the constraint structure is met.

4. The graph database query method as described in claim 1, wherein, The constraint structure includes at least one of the following constraints: Edge existence constraint, node relationship constraint, predecessor relationship constraint, distance relaxation constraint, set membership constraint, order constraint, deduplication consistency constraint or normalization constraint.

5. The graph database query method as described in claim 1, wherein, The private graph data represents graph edge relationships in the form of an edge list, and the witness data is constructed based on edge relationship records sorted by source node identifier.

6. A method for validating a graph database, comprising: Obtain the graph query result, the verifiable proof corresponding to the graph query result, and the verification key. The graph query result is obtained from a graph query request for private graph data. Based on the verification key, the graph query result, and the verifiable proof, a verification algorithm is executed to verify whether there is witness data corresponding to the graph query request, so that the constraint structure corresponding to the graph query request is valid; If the verification passes, the graph query result is determined to be a reliable result.

7. The graph database verification method as described in claim 6, wherein, The constraint structure is used to characterize at least one of the following graph query processing logics: node expansion, path relationship processing, relationship matching, result filtering, or result sorting.

8. The verification method for a graph database as described in claim 6, wherein, The execution verification algorithm verifies whether witness data exists corresponding to the graph query request, so that the constraint structure corresponding to the graph query request is valid, including verifying at least one of the following relationships: The distance propagation relationship between node distance and predecessor distance, the edge existence relationship between predecessor node and current node, the distance relaxation relationship between the nodes at both ends of an edge, the member correspondence relationship between edge record and target set, the equivalence relationship before and after bidirectional relation normalization, and the order relationship between sorting result and candidate result.

9. The verification method for a graph database as described in claim 6, wherein, The graph query result also includes at least one of the following public output information corresponding to the graph query result: public boundary value, public message identifier, public node identifier, or public sorting result, and the verification algorithm verifies the verifiable proof based on the public output information.

10. An electronic device comprising a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method of any one of claims 1 to 9.

Images