A knowledge graph secret state collaborative storage and verifiable retrieval method and system

Abstract

This application relates to the field of cryptography and knowledge graph fusion technology, and discloses a method and system for encrypted collaborative storage and verifiable retrieval of knowledge graphs. The method includes: registering lightweight metadata on the blockchain via smart contracts to establish a verifiable binding relationship between on-chain metadata and off-chain encrypted attribute data; using a Merkle tree structure to perform integrity aggregation and anchoring of entity relationship data, generating integrity anchoring credentials with Merkle verification paths; generating verifiable query instructions to be sent to off-chain storage nodes based on user-initiated query requests; the smart contract calling the integrity anchoring credentials to complete data integrity and query validity verification, and returning off-chain encrypted attribute ciphertext to the user after successful verification; the user decrypting the off-chain encrypted attribute data, preserving the entity association topology structure based on the relationship topology index, and finally reconstructing a one-hop subgraph of the knowledge graph to complete subgraph retrieval. This application implements integrity verification of ciphertext retrieval results.

Description

Technical Field

[0001] This application relates to the field of cryptography and knowledge graph fusion technology, and in particular to a knowledge graph-based encrypted collaborative storage and verifiable retrieval method and system. Background Technology

[0002] Currently, knowledge graph technology is evolving from closed, single-domain applications to open, cross-domain collaborations, giving rise to a specific technological scenario: the circulation of highly sensitive data elements. Typical scenarios include collaborative research networks across medical institutions, anti-fraud alliances across financial institutions, and data collaboration platforms across supply chain enterprises. In such scenarios, the various stakeholders involved in the collaboration constitute a "multi-party untrustworthy environment" where data must be shared but trust cannot be established: each party has a strong business drive to share knowledge graph data and mine deep-seated value such as disease transmission chain deduction, but due to strict data privacy and trade secret protection, it is strictly prohibited to aggregate raw data to a single central node.

[0003] The contradiction between the "demand for high-value data circulation" and the "lack of trust among multiple parties" renders traditional technical methods ineffective. On the one hand, while using centralized graph databases (such as Neo4j) with access control can maintain graph retrieval performance, it introduces single-point trust risks and data monopoly issues. Furthermore, centralized authentication mechanisms cannot prevent internal administrators from exceeding their authority or external attackers from tampering with logs, failing to meet the non-repudiation requirements under multi-party collaboration. On the other hand, while using pure cryptographic distributed storage solutions such as end-to-end encryption or fully homomorphic encryption can ensure data confidentiality at the transmission and storage levels, it disrupts the topological relationships of the graph structure, making efficient one-hop subgraph traversal impossible. More importantly, pure cryptographic solutions lack an immutable "trust anchor" to solidify execution logic, making it impossible to prove the integrity of retrieval results in a decentralized environment (i.e., unable to distinguish between naturally missing data and malicious server concealment), and also making it difficult to achieve fine-grained, non-centralized dynamic access control. Therefore, existing technologies cannot simultaneously meet the stringent requirements for graph data association retrieval efficiency, result verifiability, and operational traceability in an environment where multiple parties are not trusted, while ensuring the confidentiality of data throughout the entire data chain. Summary of the Invention

[0004] In view of this, this application provides a method and system for secure collaborative storage and verifiable retrieval of knowledge graphs in a dense state. This allows distrustful parties to achieve secure sharing of large-scale knowledge graph associated data and integrity verification of dense state retrieval results without disclosing plaintext knowledge graph data and topological relationships.

[0005] This application discloses a knowledge graph dense-state collaborative storage and verifiable retrieval method, which includes: S1: Adopt a non-native attribute graph knowledge graph encoding scheme adapted to blockchain to encode the entities and relationships in the knowledge graph into attribute graphs, and generate a mapping structure between on-chain metadata and off-chain encrypted attribute data; S2: Based on the mapping structure, an on-chain and off-chain collaborative hierarchical storage architecture is adopted. Lightweight metadata and relation topology indexes are built on the chain, and entity attributes and relation attributes are homomorphically encrypted off-chain to generate off-chain encrypted attribute data. S3: Register lightweight metadata on the chain through smart contracts, establish a verifiable binding relationship between on-chain metadata and off-chain encrypted attribute data, use the Merkle tree structure to collect and anchor entity relationship data for integrity, and generate integrity anchoring credentials with Merkle verification paths. S4: Based on the query request initiated by the user, the smart contract completes the user's permission and identity verification, and relies on the integrity anchor certificate to schedule the off-chain storage node to initiate the secret state retrieval scheduling, and generates verifiable query instructions to be issued to the off-chain storage node; S5: The off-chain storage node responds to the verifiable query command, returns the off-chain encrypted attribute data and Merkle proof, and the smart contract calls the integrity anchor certificate to complete the data integrity and query validity verification. After the verification is successful, the off-chain encrypted attribute ciphertext is sent back to the user. S6: The user decrypts the off-chain encrypted attribute data, retains the entity association topology structure based on the relation topology index, improves the query response efficiency by relying on the prefetching mechanism, and finally reconstructs the knowledge graph one-hop subgraph to complete the subgraph retrieval.

[0006] Further, S1 includes: Each edge in the attribute graph is modeled as two independent key-value pairs, outgoing and incoming, in the key-value store. The GenMetaData blockchain metadata generation algorithm is used as input, with the entity / relationship encoding key and the data owner's private key sk as input. The algorithm generates the entity's unique identifier EntityID, the off-chain encrypted attribute hash value, and the Merkle root of the relationship through SHA3. The metadata record is then generated and stored on the blockchain. The on-chain metadata is associated and bound with the homomorphically encrypted off-chain entity and relationship attribute data to construct a mapping structure between on-chain metadata and off-chain encrypted attribute data.

[0007] Furthermore, building the tiered storage architecture includes: On-chain configuration includes an entity metadata table and a relationship topology index table. The entity metadata table stores the entity's unique identifier (EntityID), entity metadata hash value, relationship root hash value (RelationRoot), and access control policies. The relationship topology index table uses the (SourceEntityID, EdgeType, TargetEntityID) triple as the index key, encoding both the relationship semantic type and association direction through the relationship type identifier. If the EdgeType value is greater than a preset value, it represents an outgoing edge; if the EdgeType value is less than a preset value, it represents an incoming edge. Off-chain, encrypted entity attributes in JSON format are stored using EntityID as the key, and encrypted relationship attributes are stored using the topology triple as the key. Off-chain data is stored using IPFS distributed nodes. SourceEntityID is the starting entity identifier, EdgeType is the relationship type identifier, and TargetEntityID is the target entity identifier. The establishment of a verifiable binding relationship and completion of integrity anchoring includes: establishing a binding relationship between ValueHash and CID based on the data content identifier (CID) registered in the smart contract; building a bidirectional verifiable connection between on-chain and off-chain data using hash pointers; collecting entity relationship data using a Merkle tree; and generating an integrity anchoring credential with a verification path, where ValueHash is an attribute hash value. Further, the scheduling of off-chain storage nodes to initiate encrypted retrieval scheduling based on the integrity anchoring credential includes: Configure the VerifiableGet algorithm for entity verification queries; using user digital signatures and EntityIDs as processing objects, after the smart contract verifies the legitimacy of the signature identity, it reads on-chain metadata and generates Merkle proof instructions, obtains off-chain encrypted attribute data and two-factor Merkle proofs from off-chain, and completes integrity verification based on ValueHash and integrity anchor credentials; after the verification is successful, it decrypts to obtain entity attributes, which serve as the basic attribute data for subgraph reconstruction.

[0008] Furthermore, the dense-state retrieval scheduling also includes a relational retrieval step; The relationship retrieval process includes: The configuration relationship can be verified using the VerifiableNext algorithm. Taking the starting entity EntityID and the relationship direction flag as the processing objects, the on-chain triple topology index is traversed to obtain a triple list. Merkle path proof instructions are generated in batches, and the off-chain encrypted relationship attributes and corresponding Merkle proofs are retrieved. After verification by ValueHash and integrity anchor credentials, the set of related relationship attributes is decrypted. The set of related relationship attributes serves as the relationship support data for reconstructing a one-hop subgraph of the knowledge graph.

[0009] Furthermore, the reconstructed knowledge graph one-hop subgraph includes: The VerifiableGet algorithm is called to obtain the initial entity attributes. The VerifiableNext algorithm is called to retrieve the associations in the outgoing and incoming edge directions respectively. The entity attributes, outgoing edge relationships and incoming edge relationships are merged. A Merkle-Patricia tree combined with a Merkle forest structure is used. The RelationRoot and integrity anchor credentials are reused to realize the local integrity verification of the one-hop subgraph. The verification cost increases logarithmically with the data size. Finally, the complete one-hop subgraph is merged and output.

[0010] Furthermore, the homomorphic encryption of entity attributes and relation attributes includes: The Paillier homomorphic encryption algorithm is used to perform plaintext encryption operations to obtain encrypted data. This encryption method meets the IND-CPA security standard, supports homomorphic ciphertext addition operations, and has quantum computing resistance. Distributed key management eliminates the risk of single-point key leakage. The SHA3-512 hash algorithm is used to generate ValueHash.

[0011] Furthermore, the entire process of generating the mapping structure, building the hierarchical storage architecture, and scheduling the encrypted retrieval also includes a privacy protection process; The privacy protection process includes: It integrates zk-SNARKs zero-knowledge proof technology, hides sensitive information about entity associations in the on-chain topological index through arithmetic circuits and polynomial commitments, and limits the success probability of attribute inference attacks to below the preset probability, which complies with GDPR anonymization specifications; combined with ring signature technology, it obfuscates the user's retrieval access mode, so that the entire retrieval process meets the IND-CCA2 security standard, and the security level is better than the traditional RCPA security model.

[0012] Furthermore, it also includes a security protection process; the security protection process includes: Threat models are constructed by dividing trusted and untrusted domains, identifying three types of attack paths, and building a four-fold security protection mechanism. The blockchain adopts the PBFT consensus algorithm, which has 3f+1 node fault tolerance capability. It defends against replay attacks through a combination of timestamps and nonce mechanisms, suppresses attacks by relying on PoS proof-of-stake and economic staking mechanisms, and realizes full-chain operation auditing and traceability based on the blockchain's immutable ledger.

[0013] This application also discloses a knowledge graph dense state collaborative storage and verifiable retrieval system, which implements the knowledge graph dense state collaborative storage and verifiable retrieval method described above, and includes a user / application layer, a blockchain core layer, and a distributed node network layer; The user / application layer is used to allow users to interact with the blockchain core layer through a query request interface; The core layer of the blockchain includes a smart contract module, an on-chain storage module, and an off-chain storage module; The smart contract module is responsible for query request verification, encrypted query execution, and data integrity verification. The on-chain storage module is used to maintain lightweight verification data, which includes metadata hashes, index Merkle roots, and access control policies. The off-chain storage module is used to store encrypted entity data, relational data, and encrypted index structure. The on-chain storage module and the off-chain storage module establish a verifiable connection through a hash pointer to ensure data consistency. The distributed node network layer is used to maintain the immutability and traceability of the blockchain through a consensus mechanism.

[0014] Due to the adoption of the above technical solution, this application has the following advantages: 1. A topology-preserving dense state knowledge graph construction model was built, breaking through the limitation of "data silos" caused by traditional encryption.

[0015] Existing encrypted storage schemes typically flatten knowledge graphs into independent key-value pairs or documents for encryption, thus destroying the topological interconnectivity of the graph structure. This application proposes a hierarchical encoded encrypted attribute graph model. By designing directional encoding and prefix matching mechanisms, it maps complex graph topological logic into on-chain verifiable lightweight metadata. This model fully preserves the many-to-many association characteristics of the knowledge graph without revealing plaintext entities and relational attributes. This makes the encrypted data no longer isolated encrypted fragments, but a logically complete and topologically reachable encrypted graph structure, laying a data structure foundation for subsequent association analysis.

[0016] 2. It realizes association retrieval and integrity verification in the undecrypted state, filling the gap in the verifiability of encrypted graph calculation.

[0017] Unlike traditional searchable encryption schemes that only support simple point queries or keyword matching, this application pioneers a one-hop subgraph traversal mechanism based on cryptographic verification. By integrating Merkle proofs and zero-knowledge proofs, this application enables the querying party to not only perform cryptographic retrieval of the target entity's attributes but also to verify the integrity of the returned one-hop neighbor subgraph without decrypting the data or trusting the server. This "retrieval as verification" mechanism mathematically guarantees that the returned results are neither omitted nor tampered with, solving the technical challenge of "knowledge-associative retrieval and integrity verification" in a cryptographic environment.

[0018] 3. A lightweight storage paradigm with on-chain / off-chain collaboration was designed to solve the performance paradox of large-scale graph data on-chain.

[0019] Addressing the pain points of expensive blockchain storage and its unsuitability for complex computations, this application does not simply move data onto the chain, but rather designs a collaborative storage paradigm of "logic on-chain, data off-chain." Only lightweight topology indexes used for verification and addressing are anchored on the chain, while the massive encrypted attribute data is offloaded to a distributed storage network. This on-chain / off-chain layered storage architecture not only avoids the storage bloat and computational congestion caused by uploading the entire graph to the chain, but also significantly improves the retrieval efficiency and scalability of large-scale knowledge graphs in encrypted states through a local access mechanism for off-chain encrypted data.

[0020] 4. A decentralized, fine-grained access control logic has been established, eliminating the single point of trust risk brought about by centralized authentication.

[0021] This application migrates access control policies from centralized servers to smart contract code, achieving rule-driven dynamic permission management. Unlike traditional solutions where permission configurations can be tampered with by administrators, this solution solidifies access logic into immutable on-chain code rules. Any attempt to access the encrypted knowledge graph must undergo pre-defined cryptographic verification and contract logic validation. This ensures that even the data owner cannot tamper with access records afterward, fundamentally achieving permission fairness and operational non-repudiation under multi-party collaboration. Attached Figure Description

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

[0023] Figure 1 This is a block diagram of a knowledge graph dense-state collaborative storage and verifiable retrieval system according to an embodiment of this application; Figure 2 This is a schematic diagram of the blockchain hierarchical storage structure of the KG-BC-ENC scheme in an embodiment of this application; Figure 3 This is a schematic diagram of a case knowledge graph (attribute graph example) according to an embodiment of this application; Figure 4 This is an example diagram of the key-value storage mode in an embodiment of this application; Figure 5 This is a schematic diagram illustrating the dense state knowledge graph construction process in an embodiment of this application; Figure 6 This is a diagram of a dense state knowledge graph threat model according to an embodiment of this application. Detailed Implementation

[0024] The present application will be further described in conjunction with the accompanying drawings and embodiments. The described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by those skilled in the art should fall within the protection scope of the embodiments of the present application.

[0025] This application addresses the following three key technical issues: First, this paper addresses the challenge of adapting the underlying key-value storage model to the complex topology of knowledge graphs. In blockchain distributed ledgers, the underlying key-value storage model is inherently difficult to directly express many-to-many relationships between entities. Using a full graph-on-chain approach not only leads to a rapid increase in storage due to block capacity limitations, but also incurs extremely high system resource overhead (such as computation and communication costs) during graph traversal queries, resulting in network congestion. Using simple hash-based on-chain methods completely eliminates the retrieval capabilities of the graph structure. This application designs a lightweight on-chain index structure with layered encoding, mapping the complex attribute graph topology logic to on-chain storable metadata. Only the encrypted entity attributes and relationship details are off-chain stored, thus achieving physical separation between the graph structure logic and the encrypted data. This approach avoids the performance bottleneck of full on-chain storage while preserving the reachability of the graph topology.

[0026] Secondly, this application addresses the lack of logical credibility and impartiality in access control for simple encryption schemes in decentralized environments. Traditional solutions rely on centralized servers to configure access control policies. However, in scenarios where multiple parties are untrusted, the central node can easily become a single point of failure or a target of internal attacks, leading to unauthorized modification of permissions or falsification of query logs. This application leverages the automated execution and consensus-driven mechanism of blockchain smart contracts to write access control policies and query verification algorithms into the blockchain as code. This means that data access permissions are no longer a variable configuration stored on a central server, but rather immutable rules constrained by on-chain consensus. No participant (including the data owner) can tamper with access records or deny actions afterward, thus replacing human trust with code logic and ensuring the impartiality of the retrieval execution process and permission verification.

[0027] Third, this application addresses the challenge of simultaneously achieving association retrieval and integrity verification of encrypted data in a distributed environment. Existing searchable encryption technologies often only support simple peer-to-peer queries, failing to support the unique "one-hop subgraph" association traversal required by knowledge graphs. Furthermore, the returned ciphertext results cannot prove to users that they represent a complete association dataset (i.e., it cannot distinguish whether data is missing or the server returned partial results). This application constructs an on-chain verification mechanism based on Merkle trees, combined with directional encoding and prefix matching techniques. This allows users to perform cryptographic integrity verification of the returned one-hop subgraph based on on-chain anchored hash pointers without decrypting off-chain data. This breaks down the "data silos" caused by traditional encryption technologies and enables the mining of association value in encrypted form. This application constructs an on-chain / off-chain hierarchical storage architecture, combining Paillier homomorphic encryption and zk-SNARKs (concise non-interactive zero-knowledge proofs) technology. It achieves encrypted retrieval of one-hop subgraph associations in a decentralized environment and relies on Merkle proofs and smart contract logic to verify the integrity of the ciphertext retrieval results. This patent overcomes the limitations of existing encrypted knowledge graph technologies, such as reliance on centralized authority, lack of result integrity verification, and inability to support large-scale related data retrieval, by constructing a decentralized trust mechanism, introducing cryptographic verifiability, and designing an on-chain / off-chain layered collaborative paradigm. It provides a practical and feasible systematic solution for the value mining and privacy protection of highly sensitive knowledge in multi-party untrusted environments.

[0028] See Figure 1 This application provides an embodiment of a knowledge graph dense-state collaborative storage and verifiable retrieval method, which includes: S1: Adopt a non-native attribute graph knowledge graph encoding scheme adapted to blockchain to encode the entities and relationships in the knowledge graph into attribute graphs, and generate a mapping structure between on-chain metadata and off-chain encrypted attribute data; S2: Based on the mapping structure, an on-chain and off-chain collaborative hierarchical storage architecture is adopted. Lightweight metadata and relation topology indexes are built on the chain, and entity attributes and relation attributes are homomorphically encrypted off-chain to generate off-chain encrypted attribute data. The off-chain encrypted attribute data can be stored in a distributed storage network. S3: Register lightweight metadata on the chain through smart contracts, establish a verifiable binding relationship between on-chain metadata and off-chain encrypted attribute data, use the Merkle tree structure to collect and anchor entity relationship data for integrity, and generate integrity anchoring credentials with Merkle verification paths. S4: Based on the query request initiated by the user, the smart contract completes the user's permission and identity verification, and relies on the integrity anchor certificate to schedule the off-chain storage node to initiate the secret state retrieval scheduling, and generates verifiable query instructions to be issued to the off-chain storage node; S5: The off-chain storage node responds to the verifiable query command, returns the off-chain encrypted attribute data and Merkle proof, and the smart contract calls the integrity anchor certificate to complete the data integrity and query validity verification. After the verification is successful, the off-chain encrypted attribute ciphertext is sent back to the user. S6: The user decrypts the off-chain encrypted attribute data, retains the entity association topology structure based on the relation topology index, improves the query response efficiency by relying on the prefetching mechanism, and finally reconstructs the knowledge graph one-hop subgraph to complete the subgraph retrieval.

[0029] Optionally, S1 includes: Each edge in the attribute graph is modeled as two independent key-value pairs, outgoing and incoming, in the key-value store. The GenMetaData blockchain metadata generation algorithm is used as input, with the entity / relationship encoding key and the data owner's private key sk as input. The algorithm generates the entity's unique identifier EntityID, the off-chain encrypted attribute hash value, and the Merkle root of the relationship through SHA3. The metadata record is then generated and stored on the blockchain. The on-chain metadata is associated and bound with the homomorphically encrypted off-chain entity and relationship attribute data to construct a mapping structure between on-chain metadata and off-chain encrypted attribute data.

[0030] Optionally, building the tiered storage architecture includes: On-chain configuration includes an entity metadata table and a relationship topology index table. The entity metadata table stores the entity's unique identifier (EntityID), entity metadata hash value, relationship root hash value (RelationRoot), and access control policies. The relationship topology index table uses the (SourceEntityID, EdgeType, TargetEntityID) triple as the index key, encoding both the relationship semantic type and association direction through the relationship type identifier. If the EdgeType value is greater than a preset value, it represents an outgoing edge; if the EdgeType value is less than a preset value, it represents an incoming edge. Off-chain, encrypted entity attributes in JSON format are stored using EntityID as the key, and encrypted relationship attributes are stored using the topology triple as the key. Off-chain data is stored using IPFS distributed nodes. SourceEntityID is the starting entity identifier, EdgeType is the relationship type identifier, and TargetEntityID is the target entity identifier. The establishment of a verifiable binding relationship and completion of integrity anchoring includes: establishing a binding relationship between ValueHash and CID based on the data content identifier (CID) registered in the smart contract; building a bidirectional verifiable connection between on-chain and off-chain data using hash pointers; collecting entity relationship data using a Merkle tree; and generating an integrity anchoring credential with a verification path, where ValueHash is an attribute hash value. Optionally, the scheduling of off-chain storage nodes to initiate encrypted retrieval based on the integrity anchoring credential includes: Configure the VerifiableGet algorithm for entity verification queries; using user digital signatures and EntityIDs as processing objects, after the smart contract verifies the legitimacy of the signature identity, it reads on-chain metadata and generates Merkle proof instructions, obtains off-chain encrypted attribute data and two-factor Merkle proofs from off-chain, and completes integrity verification based on ValueHash and integrity anchor credentials; after the verification is successful, it decrypts to obtain entity attributes, which serve as the basic attribute data for subgraph reconstruction.

[0031] Optionally, the dense-state retrieval scheduling also includes an association retrieval step; The relationship retrieval process includes: The configuration relationship can be verified using the VerifiableNext algorithm. Taking the starting entity EntityID and the relationship direction flag as the processing objects, the on-chain triple topology index is traversed to obtain a triple list. Merkle path proof instructions are generated in batches, and the off-chain encrypted relationship attributes and corresponding Merkle proofs are retrieved. After verification by ValueHash and integrity anchor credentials, the set of related relationship attributes is decrypted. The set of related relationship attributes serves as the relationship support data for reconstructing a one-hop subgraph of the knowledge graph.

[0032] Optionally, the reconstruction yields a one-hop subgraph of the knowledge graph, including: The VerifiableGet algorithm is called to obtain the initial entity attributes. The VerifiableNext algorithm is called to retrieve the associations in the outgoing and incoming edge directions respectively. The entity attributes, outgoing edge relationships and incoming edge relationships are merged. A Merkle-Patricia tree combined with a Merkle forest structure is used. The RelationRoot and integrity anchor credentials are reused to realize the local integrity verification of the one-hop subgraph. The verification cost increases logarithmically with the data size. Finally, the complete one-hop subgraph is merged and output.

[0033] Optionally, the homomorphic encryption of entity attributes and relation attributes includes: The Paillier homomorphic encryption algorithm is used to perform plaintext encryption operations to obtain encrypted data. This encryption method meets the IND-CPA security standard, supports homomorphic ciphertext addition operations, and has quantum computing resistance. Distributed key management eliminates the risk of single-point key leakage. The SHA3-512 hash algorithm is used to generate ValueHash.

[0034] Optionally, the entire process of generating the mapping structure, building the hierarchical storage architecture, and scheduling the encrypted retrieval also includes a privacy protection process; The privacy protection process includes: It integrates zk-SNARKs zero-knowledge proof technology, hides sensitive information about entity associations in the on-chain topological index through arithmetic circuits and polynomial commitments, and limits the success probability of attribute inference attacks to below the preset probability, which complies with GDPR anonymization specifications; combined with ring signature technology, it obfuscates the user's retrieval access mode, so that the entire retrieval process meets the IND-CCA2 security standard, and the security level is better than the traditional RCPA security model.

[0035] Optionally, it also includes a security protection process; the security protection process includes: Threat models are constructed by dividing trusted and untrusted domains, identifying three types of attack paths, and building a four-fold security protection mechanism. The blockchain adopts the PBFT consensus algorithm, which has 3f+1 node fault tolerance capability. It defends against replay attacks through a combination of timestamps and nonce mechanisms, suppresses attacks by relying on PoS proof-of-stake and economic staking mechanisms, and realizes full-chain operation auditing and traceability based on the blockchain's immutable ledger.

[0036] This application also provides an embodiment of a knowledge graph dense collaborative storage and verifiable retrieval system, which implements the knowledge graph dense collaborative storage and verifiable retrieval method described in the above embodiment, and includes a user / application layer, a blockchain core layer, and a distributed node network layer; The user / application layer is used to allow users to interact with the blockchain core layer through a query request interface; The core layer of the blockchain includes a smart contract module, an on-chain storage module, and an off-chain storage module; The smart contract module is responsible for query request verification, encrypted query execution, and data integrity verification. The on-chain storage module is used to maintain lightweight verification data, which includes metadata hashes, index Merkle roots, and access control policies. The off-chain storage module is used to store encrypted entity data, relational data, and encrypted index structure. The on-chain storage module and the off-chain storage module establish a verifiable connection through a hash pointer to ensure data consistency. The distributed node network layer is used to maintain the immutability and traceability of the blockchain through a consensus mechanism.

[0037] For ease of understanding, this application provides a more specific embodiment: The system architecture of this application is as follows: Figure 1As shown, the top layer of the architecture is the user / application layer, which interacts with the blockchain core layer through a query request interface. The core layer consists of three main modules: ① a smart contract module responsible for query request verification, encrypted query execution, and data integrity verification; ② an on-chain storage module that maintains lightweight verification data such as key metadata hashes, Merkle roots, and access control policies; and ③ an off-chain storage module that stores encrypted entity data, relational data, and encrypted index structures. The on-chain and off-chain modules establish a verifiable connection through hash pointers to ensure data consistency. The underlying distributed node network maintains the immutability and traceability of the blockchain through a consensus mechanism. The entire architecture, through a smart contract-driven query processing flow (user request → contract execution → verification result return) and an on-chain / off-chain collaborative storage mechanism, ensures data confidentiality and integrity while supporting verifiable one-hop subgraph retrieval functionality.

[0038] During knowledge graph construction, data owners encode the knowledge graph data using attribute graphs, generating encrypted entity and relation data, and simultaneously calculating the blockchain hash value of key metadata. Off-chain storage nodes store the encrypted entity data, relation data, and encrypted index structure, while the blockchain network records metadata hashes, the Merkle root of the index, and access control policies through smart contracts. During knowledge graph retrieval, users submit query requests to the blockchain network. The smart contract first verifies the request permissions, then generates a verifiable query instruction and sends it to the off-chain storage nodes. After executing the encrypted retrieval, the off-chain storage nodes return the encrypted results and the corresponding Merkle proofs to the blockchain network. The smart contract verifies data integrity and query validity before returning the encrypted results to the user. The user ultimately decrypts the data and constructs the graph object.

[0039] This application is based on a non-native attribute graph knowledge graph encoding scheme adapted for blockchain storage (named KG-BC-ENC). This scheme achieves a hierarchical representation of knowledge graph data through an on-chain / off-chain collaborative model: lightweight metadata of entity relationship topology (such as Merkle roots and hash pointers) is stored on-chain, while encrypted entity attributes and relationship data are stored off-chain. This encoding method maintains data relevance through smart contracts, and when supporting one-hop subgraph queries, Merkle proofs can be used to achieve efficient and verifiable retrieval.

[0040] This application introduces blockchain cryptographic primitives and a smart contract execution engine onto the KG-BC-ENC platform to achieve encrypted storage and verifiable querying of knowledge graphs. It employs a smart contract-based query verification mechanism (integrating zero-knowledge proofs or homomorphic encryption technology) to ensure performance for large-scale data retrieval while maintaining the topological locality of a one-hop subgraph through on-chain metadata. Specifically, the entity relationship hash pointers stored on-chain can quickly locate the physical distribution of related data off-chain, and combined with a prefetching mechanism, query efficiency is optimized, reducing the I / O overhead of off-chain storage.

[0041] In the KG-BC-ENC solution, the knowledge graph adopts a non-native attribute graph model adapted to blockchain, and data storage is achieved through an on-chain / off-chain collaborative architecture: lightweight metadata is stored on-chain (including a hash-based unique entity identifier EntityID, entity metadata hash MetadataHash, and relation Merkle root), while off-chain distributed nodes store encrypted entity and relation attributes; the relationship between entities is maintained through an on-chain triple topology index (SourceEntityID, EdgeType, TargetEntityID), where EdgeType encodes the relation direction (>0 for outgoing edges, <0 for incoming edges), and ValueHash verifies the integrity of off-chain encrypted attributes. This design ensures one-hop subgraph query efficiency through a smart contract-driven verifiable retrieval mechanism, while also achieving data immutability and confidentiality.

[0042] Figure 2 This presentation showcases the KG-BC-ENC blockchain layered storage structure, employing an on-chain / off-chain collaborative mechanism to achieve verifiable storage of knowledge graph data. The on-chain blockchain layer stores two types of core metadata: ① An entity metadata table containing EntityID (a hash-based unique entity identifier), MetadataHash (entity metadata hash), RelationRoot (the Merkle root of the relationship), and AccessPolicy (access control policy); ② A relationship topology index table using triples (SourceEntityID, EdgeType, TargetEntityID) as keys, where EdgeType encodes the relationship direction (>0 for outgoing edges, <0 for incoming edges) and semantic type, and ValueHash stores a summary of the encrypted attributes off-chain. Off-chain distributed nodes store encrypted detailed attribute data: entity attributes are stored as encrypted JSON attributes using EntityID as the key, and relationship attributes are stored as encrypted relationship features using topology triples as keys. On-chain and off-chain data are linked through a two-way verification mechanism: the RelationRoot in the entity metadata maintains the Merkle proof of the relationship, the ValueHash in the relationship index verifies the integrity of off-chain attributes, and the hash pointer indicated by the dashed arrow ensures data consistency. This design enables efficient and verifiable queries of a one-hop subgraph through smart contracts.

[0043] To further explain the data organization logic of the KG-BC-ENC scheme described above, the following explanation is provided in conjunction with specific embodiments. Figure 3The case knowledge graph shown (an example of an attribute graph) includes entities representing the patient (vertex v1), guardian (vertex v2), treatment operation (vertex v3), and disease (vertex v4), as well as relationships representing the patient and guardian (edge ​​e1), patient treatment operation (edge ​​e2), and patient's disease (edge ​​e3). Figure 4 As shown, this application maps the attribute graph to the key-value storage mode of the underlying blockchain. During the mapping process, this application uses special encoding for the graph topology: each edge in the attribute graph is modeled as two independent key-value pairs in the key-value storage, representing the outgoing edge and the incoming edge, respectively.

[0044] During the construction process, data owners register metadata on the blockchain network through smart contracts, distributed storage nodes process encrypted data, and the blockchain verifiable data structure generation algorithm is shown in Algorithm 1.

[0045] Algorithm 1: Blockchain Metadata Generation Algorithm (GenMetaData)

[0046] The knowledge graph construction process proposed in this application is as follows: Figure 5 As shown, knowledge graph construction consists of the following 5 steps: Step 1: Attribute Graph Encoding: Encode entities and relationships according to the KG-BC-ENC scheme to generate a mapping structure between on-chain metadata and off-chain encrypted data.

[0047] Step 2: Data layering processing: Entity metadata (EntityID, ValueHash, MerkleRoot) and relationship topology index (SourceID, EdgeType, TargetID) are generated on the chain. The entity attribute vi and relationship attribute rj are homomorphically encrypted off-chain to generate ciphertext data Enc(vi) and Enc(rj).

[0048] Step 3: Distributed storage deployment: Store the encrypted data {Enc(vi), Enc(rj)} to distributed storage nodes such as IPFS, generate a data content identifier (CID) and record it in the smart contract.

[0049] Step 4: Blockchain Registration: Metadata is uploaded to the blockchain via smart contracts. Entity metadata is registered to the on-chain entity table, and relation triples are registered to the topology index table. The smart contract generates a binding relationship between ValueHash and off-chain CID, establishing a verifiable connection.

[0050] Step 5: Integrity Anchoring: The smart contract calculates the Merkle root of the entity relationship set, writes it into the RelationRoot field, and generates a Merkle forest structure of the topological index, which supports efficient verification of one-hop subgraphs.

[0051] According to this application, on-chain storage is maintained in the blockchain state database (storing lightweight metadata and topology indexes), while off-chain encrypted data is stored in a distributed storage network. EntityID allows direct location of entity on-chain metadata, and Merkle roots are used to verify the integrity of relationships. The EdgeType field in the topology index (>0 indicates outgoing edges, <0 indicates incoming edges) maintains the logical locality of a one-hop subgraph. Combined with the prefetch optimization mechanism of smart contracts, batch retrieval of off-chain data can be achieved during queries, significantly reducing the I / O overhead of distributed storage. This design, through the immutability of the blockchain and cryptographic verification mechanisms, ensures the scalability of a knowledge graph of millions of entities while protecting data confidentiality and integrity.

[0052] According to this application, a one-hop subgraph query retrieves entity attributes and relationships using entity identifiers (EntityID). The one-hop subgraph query process is coordinated by a smart contract and relies on two core algorithms: As shown in Algorithm 2, VerifiableGet is used to obtain entity attributes. The user initiates a request via digital signature, the smart contract verifies the identity and generates a Merkle proof instruction, the off-chain node returns encrypted data and proof, and the user decrypts the data after the contract verifies its integrity; As shown in Algorithm 3, VerifiableNext is used to retrieve relationships, using a triple index (SourceID, EdgeType, TargetID) to locate relationships in batches, where EdgeType>0 retrieves outgoing edges and <0 retrieves incoming edges. The one-hop subgraph query is shown in Algorithm 4.

[0053] Algorithm 2: Verifiable Entity Query (VerifiableGet)

[0054] Algorithm 3: Verifiable Next Relational Queries

[0055] Algorithm 4 One-hop subgraph query

[0056] This scheme maintains the logical continuity of entity relationships through on-chain topological indexes, ensuring that the relational data retrieved each time remains physically related. This not only reduces the number of random accesses to distributed storage but also significantly optimizes I / O efficiency through a batch retrieval mechanism. Digital signatures replace trapdoors for decentralized identity authentication, Merkle proofs guarantee data integrity, and smart contracts execute fine-grained access control, enabling secure and efficient retrieval within a million-level entity graph.

[0057] In the security analysis of this application, the system architecture includes three core components: the user terminal, the blockchain network, and off-chain storage nodes. The blockchain network establishes a trusted foundation through a consensus mechanism, the user terminal stores its private key in a secure environment, and the off-chain storage nodes are considered semi-trusted / untrusted components. The threat model mainly targets two types of attackers: external attackers may intrude into off-chain nodes to steal encrypted data or tamper with transmitted data, and internal malicious administrators may attempt to illegally access sensitive information. The security objectives of this application focus on a four-fold protection mechanism: (1) data confidentiality guarantee based on homomorphic encryption, ensuring that attackers can only obtain invalid ciphertext; (2) dual integrity protection built by the blockchain consensus layer and Merkle proof, real-time detection of data tampering; (3) fine-grained access control for smart contract execution, realizing entity-level permission management; and (4) identity non-repudiation guaranteed by digital signatures, supporting full-link operation traceability. This security model significantly improves the ability to combat advanced persistent threats by shifting the trust anchor from a centralized agent to a decentralized blockchain.

[0058] Figure 6 This paper presents the threat model architecture of the proposed solution, dividing the system into trusted and untrusted domains using a trust boundary: the trusted domain on the left includes the user terminal (responsible for private key storage and digital signature generation) and the blockchain network (maintaining an immutable state through a consensus mechanism); the untrusted domain on the right consists of off-chain storage nodes (potentially vulnerable to external attacks or internal threats). The model clearly identifies three types of attack paths: (1) External attackers intrude into storage nodes to steal encrypted data (path 1); (2) Man-in-the-middle attack tampered with data in transit (path 2); (3) The internal administrator forged a user request (path 3).

[0059] To address these threats, the architecture employs a triple-layered defense mechanism: homomorphic encryption ensures off-chain data confidentiality (green defense box), Merkle proofs verify data integrity (yellow defense box), and digital signatures provide authentication and non-repudiation (blue defense box). This model intuitively presents the security principle of "trust minimization" in a decentralized architecture.

[0060] In the security analysis of the construction of encrypted knowledge graphs, data confidentiality is fundamentally guaranteed by the Paillier homomorphic encryption algorithm. This algorithm not only meets the IND-CPA (Indistinguishability under chosen-plaintext attack) security standard, but also supports additive homomorphic operations in the ciphertext state, enabling the system to perform limited computations on encrypted data without decryption. Compared to the traditional AES-CTR symmetric encryption mode, the Paillier algorithm has stronger resistance to quantum computing. Its mathematical foundation, based on the large integer factorization problem, can provide [quantum computation resistance] under current computing power. It features a key lifecycle of magnitude and completely eliminates the risk of single-point leakage through a distributed key management mechanism.

[0061] Regarding data integrity assurance, the solution uses the SHA3-512 hash algorithm to generate ValueHash. This algorithm is based on the Keccak sponge structure design and provides O(...). Its collision resistance is significantly superior to traditional SHA-256 series algorithms. Combined with an optimized Merkle-Patricia tree structure, it achieves localized proof for one-hop subgraph queries, ensuring that verification overhead grows logarithmically with data size rather than linearly. The automated verification loop built by smart contracts ensures that every data operation triggers a complete "generate-store-verify" process through pre-compiled contract code, eliminating security vulnerabilities caused by human error.

[0062] To protect metadata privacy, the on-chain topological index innovatively integrates zk-SNARKs zero-knowledge proof technology, using arithmetic circuits and polynomial commitments to conceal entity association patterns. This mechanism ensures that attackers cannot infer sensitive business information from publicly available triple indexes, and its statistical anonymity guarantees suppress the success rate of attribute inference attacks to a very low level. The following meet the most stringent GDPR anonymization requirements.

[0063] The blockchain's inherent security system employs a triple-layered defense: the PBFT consensus algorithm provides 3f+1 fault tolerance, ensuring the system maintains its correct state when malicious nodes do not exceed one-third; the transaction verification mechanism combining timestamps and nonces effectively defends against replay attacks, with each transaction bound to a unique time sequence identifier; and the node admission mechanism based on Proof-of-Stake (PoS) suppresses Sybil attacks through economic staking, forming a dual constraint of cryptography and economic incentives. This layered defense architecture supports the efficient construction of millions of entities while establishing a security boundary that surpasses traditional centralized solutions, providing theoretical guarantees for the secure deployment of knowledge graphs in distributed environments.

[0064] In the security analysis of encrypted knowledge graph retrieval, this application reconstructs end-to-end protection through blockchain native mechanisms: the user end uses ECDSA-secp256k1 digital signatures to generate unforgeable identity credentials; smart contracts execute permission verification and retrieval path optimization based on entity relationship topology, replacing traditional trapdoor mechanisms; off-chain nodes return Paillier homomorphic encrypted data and two-factor Merkle proofs (leaf node hash + path proof), providing order-of-magnitude integrity guarantees; zk-SNARKs circuits implement zero-knowledge verification of query logic, combined with ring signature technology to obfuscate access patterns, completely hiding retrieval behavior characteristics. This architecture meets the IND-CCA2 security standard. Even if an adversary controls off-chain nodes, they can only obtain invalid ciphertext and cannot forge smart contract verification responses. The immutable blockchain ledger further enables end-to-end operation auditing, establishing a security boundary that surpasses the traditional RCPA model while maintaining sub-second retrieval efficiency.

[0065] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and not to limit them. Although this application has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of this application. Any modifications or equivalent substitutions that do not depart from the spirit and scope of this application should be covered within the protection scope of the claims of this application.

Claims

1. A method for dense-state collaborative storage and verifiable retrieval of knowledge graphs, characterized in that, include: S1: Adopt a non-native attribute graph knowledge graph encoding scheme adapted to blockchain to encode the entities and relationships in the knowledge graph into attribute graphs, and generate a mapping structure between on-chain metadata and off-chain encrypted attribute data; S2: Based on the mapping structure, an on-chain and off-chain collaborative hierarchical storage architecture is adopted. Lightweight metadata and relation topology indexes are built on the chain, and entity attributes and relation attributes are homomorphically encrypted off-chain to generate off-chain encrypted attribute data. S3: Register lightweight metadata on the chain through smart contracts, establish a verifiable binding relationship between on-chain metadata and off-chain encrypted attribute data, use the Merkle tree structure to collect and anchor entity relationship data for integrity, and generate integrity anchoring credentials with Merkle verification paths. S4: Based on the query request initiated by the user, the smart contract completes the user's permission and identity verification, and relies on the integrity anchor certificate to schedule the off-chain storage node to initiate the secret state retrieval scheduling, and generates verifiable query instructions to be issued to the off-chain storage node; S5: The off-chain storage node responds to the verifiable query command, returns the off-chain encrypted attribute data and Merkle proof, and the smart contract calls the integrity anchor certificate to complete the data integrity and query validity verification. After the verification is successful, the off-chain encrypted attribute ciphertext is sent back to the user. S6: The user decrypts the off-chain encrypted attribute data, retains the entity association topology structure based on the relation topology index, improves the query response efficiency by relying on the prefetching mechanism, and finally reconstructs the knowledge graph one-hop subgraph to complete the subgraph retrieval.

2. The knowledge graph dense-state collaborative storage and verifiable retrieval method according to claim 1, characterized in that, S1 includes: Each edge in the attribute graph is modeled as two independent key-value pairs, outgoing and incoming, in the key-value store. The GenMetaData blockchain metadata generation algorithm is used, with the entity / relationship encoding key (key) and the data owner's private key (sk) as inputs, and the SHA3 algorithm is used to generate the entity's unique identifier (EntityID), the off-chain encrypted attribute hash value, and the Merkle root of the association relationship. These are combined to generate metadata records and stored on the blockchain. The on-chain metadata is then associated and bound with the homomorphically encrypted off-chain entity and relationship attribute data to construct a mapping structure between on-chain metadata and off-chain encrypted attribute data.

3. The knowledge graph dense-state collaborative storage and verifiable retrieval method according to claim 1, characterized in that, Building the tiered storage architecture includes: On-chain configuration includes an entity metadata table and a relationship topology index table. The entity metadata table stores the entity's unique identifier (EntityID), entity metadata hash value, relationship root hash value (RelationRoot), and access control policies. The relationship topology index table uses the (SourceEntityID, EdgeType, TargetEntityID) triple as the index key, encoding both the relationship semantic type and association direction through the relationship type identifier. If the EdgeType value is greater than a preset value, it represents an outgoing edge; if the EdgeType value is less than a preset value, it represents an incoming edge. Off-chain, encrypted entity attributes in JSON format are stored using EntityID as the key, and encrypted relationship attributes are stored using the topology triple as the key. Off-chain data is stored using IPFS distributed nodes. SourceEntityID is the starting entity identifier, EdgeType is the relationship type identifier, and TargetEntityID is the target entity identifier. The establishment of a verifiable binding relationship and completion of integrity anchoring includes: relying on the smart contract to register the data content identifier CID, establishing a binding relationship between ValueHash and CID, using hash pointers to build a two-way verifiable connection between on-chain and off-chain, relying on Merkle trees to collect entity relationship data, and generating an integrity anchoring certificate with a verification path, where ValueHash is an attribute hash value.

4. The knowledge graph dense-state collaborative storage and verifiable retrieval method according to claim 1, characterized in that, The scheduling of encrypted retrieval by the offline storage node based on integrity anchored credentials includes: Configure the VerifiableGet algorithm for entity verification queries; using user digital signatures and EntityIDs as processing objects, after the smart contract verifies the legitimacy of the signature identity, it reads on-chain metadata and generates Merkle proof instructions, obtains off-chain encrypted attribute data and two-factor Merkle proofs from off-chain, and completes integrity verification based on ValueHash and integrity anchor credentials; after the verification is successful, it decrypts to obtain entity attributes, which serve as the basic attribute data for subgraph reconstruction.

5. The knowledge graph dense-state collaborative storage and verifiable retrieval method according to claim 4, characterized in that, The dense-state retrieval scheduling also includes a relational retrieval step; The relationship retrieval process includes: The configuration relationship can be verified using the VerifiableNext algorithm. Taking the starting entity EntityID and the relationship direction flag as the processing objects, the on-chain triple topology index is traversed to obtain a triple list. Merkle path proof instructions are generated in batches, and the off-chain encrypted relationship attributes and corresponding Merkle proofs are retrieved. After verification by ValueHash and integrity anchor credentials, the set of related relationship attributes is decrypted. The set of related relationship attributes serves as the relationship support data for reconstructing a one-hop subgraph of the knowledge graph.

6. The knowledge graph dense-state collaborative storage and verifiable retrieval method according to claim 1, characterized in that, The reconstruction yields a one-hop subgraph of the knowledge graph, including: The VerifiableGet algorithm is called to obtain the initial entity attributes. The VerifiableNext algorithm is called to retrieve the associations in the outgoing and incoming edge directions respectively. The entity attributes, outgoing edge relationships and incoming edge relationships are merged. A Merkle-Patricia tree combined with a Merkle forest structure is used. The RelationRoot and integrity anchor credentials are reused to realize the local integrity verification of the one-hop subgraph. The verification cost increases logarithmically with the data size. Finally, the complete one-hop subgraph is merged and output.

7. The knowledge graph dense-state collaborative storage and verifiable retrieval method according to claim 1, characterized in that, The homomorphic encryption of entity attributes and relation attributes includes: The Paillier homomorphic encryption algorithm is used to perform encryption operations on the plaintext attribute data of entities and relationships to obtain off-chain encrypted attribute data; the hash value of the off-chain encrypted attribute data is calculated by the SHA3-512 algorithm to generate ValueHash for data verification and cross-chain binding.

8. The knowledge graph dense-state collaborative storage and verifiable retrieval method according to claim 1, characterized in that, The entire process of mapping structure generation, hierarchical storage architecture construction, and encrypted retrieval scheduling also includes a privacy protection process. The privacy protection process includes: It integrates zk-SNARKs zero-knowledge proof technology, hides sensitive information about entity associations in the on-chain topological index through arithmetic circuits and polynomial commitments, and limits the success probability of attribute inference attacks to below the preset probability, which complies with GDPR anonymization specifications; combined with ring signature technology, it obfuscates the user's retrieval access mode, so that the entire retrieval process meets the IND-CCA2 security standard, and the security level is better than the traditional RCPA security model.

9. The knowledge graph dense-state collaborative storage and verifiable retrieval method according to claim 1, characterized in that, It also includes a security protection process; the security protection process includes: Threat models are constructed by dividing trusted and untrusted domains, identifying three types of attack paths, and building a four-fold security protection mechanism. The blockchain adopts the PBFT consensus algorithm, which has 3f+1 node fault tolerance capability. It defends against replay attacks through a combination of timestamps and nonce mechanisms, suppresses attacks by relying on PoS proof-of-stake and economic staking mechanisms, and realizes full-chain operation auditing and traceability based on the blockchain's immutable ledger.

10. A knowledge graph dense-state collaborative storage and verifiable retrieval system, implementing the knowledge graph dense-state collaborative storage and verifiable retrieval method according to any one of claims 1-9, characterized in that, It includes the user / application layer, the blockchain core layer, and the distributed node network layer; The user / application layer is used to allow users to interact with the blockchain core layer through a query request interface; The core layer of the blockchain includes a smart contract module, an on-chain storage module, and an off-chain storage module; The smart contract module is responsible for query request verification, encrypted query execution, and data integrity verification. The on-chain storage module is used to maintain lightweight verification data, which includes metadata hashes, index Merkle roots, and access control policies. The off-chain storage module is used to store encrypted entity data, relational data, and encrypted index structure. The on-chain storage module and the off-chain storage module establish a verifiable connection through a hash pointer to ensure data consistency. The distributed node network layer is used to maintain the immutability and traceability of the blockchain through a consensus mechanism.

Images