A verifiable medical data query method based on a DAG blockchain architecture

Abstract

The application discloses a verifiable medical data query method based on a DAG blockchain architecture, and belongs to the technical field of blockchain and medical information management. The method models medical events such as diagnosis and treatment records and image reports as DAG nodes, constructs an on-chain topology with time sequence and causal correlation through an encrypted hash pointer, realizes dynamic indexing and multi-keyword verifiable query in combination with an off-chain authentication data structure, receives a verification object containing a matching node set and a verification path, independently completes authenticity, integrity and timeliness verification based on an authentication root stored on the chain, and does not need to rely on a third party. Through on-chain and off-chain collaborative storage and incremental authentication updating mechanism, the application significantly improves query efficiency, verification performance and scalability under high concurrency on the premise of ensuring medical data privacy and tamper resistance, has lower communication and resource overhead, and is suitable for application scenarios such as cross-institution medical data sharing, remote diagnosis and treatment and compliance audit.

Description

Technical Field

[0001] This invention relates to the fields of blockchain and medical information management technology, and in particular to a verifiable medical data query method based on a DAG blockchain architecture, which falls under the category of data security and trusted computing technology. Background Technology

[0002] With the rapid development of healthcare informatization, a large amount of electronic health records (EHRs), medical images, laboratory reports, and prescription data are continuously collected and shared, forming a massive and complex medical data system. This data is of significant value in clinical diagnosis and treatment, scientific research and analysis, and telemedicine. However, existing centralized data management models suffer from risks of data leakage, potential for result tampering, and difficulty in verifying reliability. Especially in cross-institutional sharing or cloud storage environments, data providers may maliciously tamper with results, and users cannot independently verify the authenticity and integrity of the data they query.

[0003] To enhance the credibility of medical data, researchers have attempted to introduce blockchain technology, leveraging its decentralized and immutable characteristics to achieve data storage and traceability. However, traditional blockchain systems based on linear structures still have significant shortcomings: firstly, they struggle to express complex dependencies between medical events; secondly, their query performance is poor, making it difficult to support multi-keyword and structured verification; and thirdly, on-chain storage is burdensome, making them unsuitable for high-frequency medical data update scenarios. Blockchain systems employing hybrid storage architectures alleviate performance pressure to some extent, achieving collaborative management by recording data summaries on-chain and storing raw data off-chain. However, most of these solutions only store Merkle roots or set hashes, lacking a global consistency verification mechanism for off-chain data, and users still need to rely on centralized nodes to complete query and verification operations. Furthermore, the update cost of traditional indexes is high, making it difficult to meet the application requirements of highly dynamic medical data.

[0004] In recent years, Directed Acyclic Graph (DAG) structures have been introduced into blockchain systems to improve concurrency and scalability. Compared to linear blockchains, DAGs allow multiple blocks to be generated in parallel, and their multi-parent node reference mechanism can more naturally express the temporal and logical dependencies between events. This characteristic makes them theoretically very suitable for modeling scenarios with complex causal and temporal logic, such as medical behavioral chains. However, existing DAG-related solutions mainly focus on performance optimization and lack verifiable query mechanisms that combine Authenticated Data Structures (ADS), making it difficult to simultaneously achieve efficiency and security. Existing verifiable query methods are mostly based on Merkle trees, RSA accumulators, or Bloom filters. Although they can provide some verification capabilities, in scenarios with multi-keyword queries and large-scale dynamic updates, they suffer from high computational complexity, lengthy verification paths, and insufficient response performance, making it difficult to meet the practical application needs of healthcare. Summary of the Invention

[0005] To address the aforementioned shortcomings of existing technologies, this invention provides a verifiable medical data query method based on a DAG blockchain architecture. This invention establishes an on-chain and off-chain collaborative data authentication and query verification mechanism to verify the authenticity, integrity, and traceability of medical data in untrusted environments. Furthermore, this invention introduces a Directed Acyclic Graph (DAG) structure and an Authentication Data Structure (ADS) to construct an efficient data index and verifiable query model, supporting trusted sharing and efficient access to cross-institutional, multi-source medical data.

[0006] The specific technical solution of the present invention is as follows:

[0007] This invention provides a verifiable medical data query method based on a DAG blockchain architecture, comprising the following steps:

[0008] Step S1: Construct a DAG-based hybrid storage blockchain architecture: Collect medical data generated by medical events, model the medical data as DAG nodes, establish causal dependencies and temporal order between nodes through encrypted hash pointers, construct a medical event chain with semantic associations, and form the core topology of the DAG main chain; calculate the hash value of the current batch of medical data and extract its keyword set, encapsulate the parent block hash set, the keyword set, and the hash value of the current batch of medical data into a new block, and add the new block to the DAG main chain to complete the chain structure expansion;

[0009] Step S2: Construct an authentication data structure and authentication index for the current batch of medical data stored off-chain: Generate a hash digest H(D) of the batch of data, and construct an authentication data structure ADS by combining a Merkle hash tree and an algebraic accumulator, thereby generating an authentication index for verifying the consistency between the on-chain digest and the off-chain original.

[0010] Step S3: Perform medical data writing and authentication root update operations: When the data provider writes the new block, the corresponding authentication data structure ADS node is updated according to the keyword set extracted from the medical data that has passed the legality verification. The updated authentication root hash is calculated and submitted to the blockchain to realize the dual binding of the block hash of the new block and the authentication root hash.

[0011] Step S4: Generate Query Verification Object: When a user initiates a query request, the service provider uses the set of keywords entered by the user as the search criteria, executes a query in the off-chain authentication data structure ADS, retrieves and generates a verification object VO containing a set of matching nodes;

[0012] Step S5: Perform local verification of query results: The user terminal performs local verification based on the root hash of the ADS authentication data structure stored on the blockchain and the returned verification object VO to confirm the authenticity, completeness and traceability of the query results.

[0013] Preferably, before steps S1 and S2, a medical data legality verification step is also included:

[0014] The original medical data undergoes comprehensive verification, including verification of data source, digital signature, timestamp, and provider qualifications. Preset rules confirm that the data source is an authorized medical institution, the signature is valid and matches the provider's identity, the timestamp conforms to the logic of the medical event, and the provider has legitimate upload permissions. Verified data is used for DAG main chain block encapsulation in step S1 and ADS construction in step S2. Data that fails verification is directly rejected by the system and does not proceed to any subsequent processing.

[0015] Preferably, the medical event mentioned in step S1 is a clinical diagnosis and treatment process, and the medical data is a record or result of the medical event, including: diagnosis and treatment records, imaging reports, and prescription information;

[0016] The process of establishing causal dependencies and temporal order between nodes using encrypted hash pointers specifically employs an automated causal dependency extraction algorithm. This algorithm maps the causal relationships between events in the medical data into directed edges, and it follows these rules:

[0017] (1) Time order rule: If the timestamp of an event is earlier than that of another event, then a time dependency edge is established;

[0018] (2) Subject consistency rule: If two events belong to the same patient and have a dependency relationship in the clinical process, a causal edge is automatically established;

[0019] (3) Semantic matching rules: Semantic matching of event tags is performed using medical ontology such as patient name and disease type. If the output field of event A appears in the input field of event B, a semantic dependency of A to B is established.

[0020] (4) Key field triggering rules: If an image report or test result generated by an event is used for subsequent diagnosis and treatment, it will be automatically added as a dependency edge;

[0021] Based on the above rules, each medical order, image, and record is causally scanned to generate a set of parent events and construct a complete DAG structure to form the core topology of the DAG main chain containing the semantically related medical event chain.

[0022] Preferably, when encapsulating the new block in step S1, the k nearest blocks are selected as the parent block set, and the structure of the new block is defined as follows:

[0023] ;

[0024] in, For medical data batches, A set of keywords extracted from medical data. For the parent block hash, For Merkle root hash, The root of the authentication data structure ADS;

[0025] During the encapsulation process, the parent block hash set and the Merkle root hash calculated from the current batch of medical data are written together into the block header of the new block to form a hash dependency chain across blocks, ensuring the traceability of the on-chain index and the integrity of the off-chain data of the DAG main chain.

[0026] Furthermore, after constructing the core topology of the DAG main chain containing semantically related medical event chains in step S1, the method further includes: performing time-series logic verification on the medical data DAG nodes in the core topology of the DAG main chain; by comparing the timestamps of the medical events associated with the nodes with the causal dependencies, ensuring that the causal dependencies and time order of each node are consistent (e.g., the timestamp of the node corresponding to the medical data of the diagnosis event is later than the timestamp of the node corresponding to the medical data of the examination event it depends on), to avoid topological structure conflicts; after the time-series logic verification is passed, the operation of calculating the hash value of the medical data verified by off-chain legality and encapsulating the new block is performed to ensure the time-series consistency of the new block with the DAG main chain topology.

[0027] Preferably, in step S2, privacy enhancement processing and authentication data structure construction are performed on the legally verified medical data, specifically including:

[0028] (1) Privacy enhancement processing: First, sensitive fields such as patient name and ID number in the data are masked and desensitized. Then, a symmetric encryption algorithm is used to encrypt the complete original data after desensitization. The encryption key is uniformly distributed to authorized nodes by the key management center.

[0029] (2) Construction of authentication data structure: Based on the encrypted data, generate its cryptographic hash digest H(D), and construct the authentication data structure ADS with this as the core to achieve the unity of data privacy protection and verifiability.

[0030] Preferably, the authentication data structure ADS is constructed based on a combination of a Merkle hash tree and an algebraic accumulator; the algebraic accumulator adopts an RSA algebraic accumulator, and its algorithm for supporting incremental updates is defined as follows:

[0031] ;

[0032] Where, Δ t For the newly added medical dataset, P(H(x)) is the generation function after hash mapping; this design realizes incremental authentication updates and fast index verification of off-chain data.

[0033] Furthermore, after performing legality verification on the original medical data in step S2, the process also includes: generating a corresponding hash digest (consistent with the hash digest H(D)) and index metadata (including data type, patient identifier, and the occurrence time of the corresponding medical event) from the verified medical data, and forming a data authentication certificate; the data authentication certificate serves as the basis for subsequent on-chain registration and is simultaneously uploaded to the blockchain when the authentication root hash is submitted in step S3, for use in auditing to trace the source of the medical data and the associated information of the corresponding medical event.

[0034] Preferably, when performing the authentication root update operation in step S3, an incremental update mechanism is adopted: only the ADS nodes corresponding to the newly added medical data are hashed and their status is updated. Based on the association between the newly added node and the original node, the local update hash value is calculated, and then the original authentication root hash is merged to generate a new authentication root hash. During the incremental update process, an update log is recorded, which includes the update time, the identifier of the newly added data and the node association information, so as to realize the traceability and efficiency improvement of the authentication root update.

[0035] Preferably, the verification object VO generated in step S4 includes a set of matching nodes, a set of non-matching nodes, an accumulator proof path, and a latest number verification path;

[0036] Wherein, the matching node set is the medical data DAG node that matches the user's query keywords, the non-matching node set is the medical data DAG node that does not match the user's query keywords but needs to participate in the verification, the accumulator proof path is the accumulator calculation path used to verify the membership of the keyword set, and the latest number verification path is the block number path used to verify the timeliness of the data.

[0037] The user terminal uses the verification object VO to reconstruct a temporary authentication subtree, calculates the root hash of the temporary authentication subtree, and compares it with the root hash of the authentication data structure ADS stored on the blockchain. If the comparison is consistent, a self-verification mechanism without the participation of a trustless third party is realized.

[0038] Preferably, during the collaborative storage and verification process in step S4, the topological order consistency of the new block in the DAG main chain is maintained through the DAG weight mechanism, and the block weight value is calculated as follows:

[0039] ;

[0040] in, Indicates the current block The weight of the new block mentioned above, Indicates the current block The set of parent blocks; express Each parent block in;

[0041] The weight values ​​are used for conflict and fork resolution and on-chain global sorting of the DAG main chain, achieving structural order and data security in chain structure expansion under high-concurrency write conditions.

[0042] Furthermore, in step S4, the service provider performs a query in the off-chain authentication data structure (ADS), specifically including the following on-chain and off-chain collaborative processes:

[0043] On-chain positioning phase: The smart contract uses the set of keywords and query conditions input by the user (such as the time range of medical data generation and the range of patient identification) as the data source, traverses the block header information of the DAG main chain, automatically locates the block number associated with the keyword, and extracts the hash tree root node R recorded in the block;

[0044] Off-chain retrieval phase: The trusted service provider performs keyword matching retrieval in its maintained Authentication Data Structure (ADS) based on the index pointer obtained from the chain (pointing to the complete medical data associated with the block stored off-chain) and the keyword set, generates a set of nodes matching the medical data and the corresponding verification path (including Merkle path and accumulator path), and encapsulates the matching node set and verification path into the verification object (VO) and returns it to the user.

[0045] Preferably, the local verification performed in step S5 specifically includes:

[0046] (1) Based on the verification path in the verification object VO, reconstruct the local authentication tree and calculate the root hash value of the local authentication tree according to the Merkle hash tree calculation rules;

[0047] (2) Compare the calculated local authentication tree root hash value with the authentication data structure ADS root hash stored in the new block;

[0048] (3) Perform legality verification and timeliness verification on each keyword in the keyword set: legality verification is performed by calling the legality verification function VeriWit to confirm that the medical data result set corresponding to the keyword comes from the legal block of the DAG main chain; timeliness verification is performed by calling the timeliness verification function VeriFresh to confirm that the medical data returned by the keyword is the latest version in the DAG main chain.

[0049] If the comparison in step (2) is consistent and all verifications in step (3) are successful, then the query result is confirmed to be true and complete.

[0050] The beneficial technical effects of this invention are as follows:

[0051] (1) This invention achieves parallel writing and temporal consistency of multi-source medical data through DAG structure, enhances system scalability, expresses the temporal and logical relationships between medical events by using the multi-parent node reference mechanism of DAG, and adapts to the complex modeling requirements of medical behavior chain; achieves structural orderliness and data security under high-concurrency writing through DAG weight mechanism; adopts on-chain and off-chain collaborative storage mechanism, only stores data digest, authentication root and key meta information on the chain, reduces gas overhead and ensures data privacy, avoids the block expansion problem caused by large-scale on-chain medical records, and effectively solves the problems of low verification efficiency and difficulty in causal tracing in existing medical blockchain under high-concurrency data scenarios.

[0052] (2) This invention adopts the ADS index structure (based on the combination of Merkle tree and algebraic accumulator) to realize dynamic and verifiable binding of on-chain and off-chain data, and supports incremental updates. Its core component, RSA algebraic accumulator, supports dynamic updates. Adding new keywords only requires performing incremental accumulation operations, without rebuilding the entire index structure, which is suitable for high-frequency update scenarios of medical data. Combined with Bloom filter, it realizes fast screening and efficient verification of the query process. Bloom filter can quickly filter out non-existent numbers or keywords in the initial stage of query, reducing invalid query overhead. ADS structure provides integrity verification of query results, which significantly improves system response performance.

[0053] (3) The present invention constructs a verification mechanism that users can complete independently. The user end can reconstruct a temporary authentication subtree using the verification object (VO) and complete self-verification by comparing it with the root hash of the on-chain ADS. It does not need to rely on a centralized verification service, ensuring the authenticity, integrity and traceability of the query results in an untrusted environment, and improving the security and credibility of the system. The off-chain data legality verification module comprehensively verifies the producer, signature, timestamp and source identifier of medical data, effectively preventing unauthorized data tampering and illegal on-chain, and ensuring the security and compliance of the data entry process. The on-chain and off-chain synchronization binding mechanism constructed by the smart contract ensures the consistency between the on-chain index and the off-chain data, avoids node tampering, data omission or information asynchrony, and improves the security and availability of the system.

[0054] (4) The present invention replaces the traditional linear Merkle hash tree with a hierarchical hash aggregation mechanism based on DAG. While ensuring data security and tamper resistance, it improves the scalability and verification efficiency of the system in high-concurrency scenarios. When adding new medical data blocks, only the hash nodes on the relevant paths need to be recalculated, without rebuilding the entire tree, which further improves the dynamic data processing capability and real-time verification performance. The query performance is excellent. Under the premise of ensuring data privacy, the query latency increases sublinearly with the growth of data scale, which is better than most of the comparison schemes. The verification efficiency is optimal. In the case of large-scale data, the verification time is significantly lower than that of comparison schemes such as vsChain and vChain. The communication overhead is low and stable, which can significantly reduce the amount of data transmission between on-chain and off-chain interactions and improve the system bandwidth utilization and cross-institutional collaboration performance. The gas consumption is low and stable. Under the premise of maintaining dynamic updability and security verifiability, the gas overhead is lower than that of most comparison schemes that support dynamic queries. It has stronger scalability and reliability and is suitable for multiple practical application scenarios such as medical data sharing, remote diagnosis and treatment and audit supervision. Attached Figure Description

[0055] Figure 1 A schematic diagram of the overall process of a verifiable medical data query method based on a DAG blockchain architecture provided by the present invention;

[0056] Figure 2 A schematic diagram of the core architecture of the verifiable medical data query method based on DAG blockchain architecture provided by the present invention;

[0057] Figure 3 This is a comparison chart of the query performance of the present invention under different medical data scales, comparing the query efficiency differences between DAG structure and traditional chain structure;

[0058] Figure 4 This is a schematic diagram illustrating the trend of verification latency under different data scales, used to compare the verification performance of the system in large-scale and multi-keyword scenarios.

[0059] Figure 5 This is a graph showing the trend of communication overhead of this invention under different data scales, used to illustrate its bandwidth utilization and scalability in large-scale and multi-keyword query scenarios;

[0060] Figure 6 This is a schematic diagram comparing the average Gas consumption of file insertion operations under different dataset sizes in the scheme of this invention, showing the performance differences between the present invention and existing schemes in terms of on-chain execution efficiency and resource consumption. Detailed Implementation

[0061] The present invention will now be described in detail with reference to the accompanying drawings and embodiments. Obviously, the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0062] Example 1: Method Example

[0063] In practice, the overall process of the method of the present invention can be divided into two core links: off-chain data authentication and on-chain collaborative storage and verifiable query.

[0064] The off-chain data authentication process is responsible for establishing a foundation of trust before data is added to the blockchain. This process first comprehensively verifies the producer, signature, timestamp, and source identifier of the medical data to ensure its legitimacy. For verified data, the system generates a corresponding hash digest and index metadata, and constructs an Authenticated Data Structure (ADS) based on this, forming a data authentication credential. This mechanism is crucial for preventing data tampering and unauthorized on-chain uploads from the source, ensuring the security and compliance of the data source.

[0065] The on-chain collaborative storage and verifiable query process further covers the organization, storage, and retrieval verification of data. This process specifically includes the following two core components:

[0066] ① Collaborative Storage and Index Synchronization: The system adopts an on-chain and off-chain collaborative storage architecture—only data hashes, authentication roots (ADS roots), and key metadata are stored on-chain; complete medical records are stored off-chain by trusted service providers (SPs). The blockchain layer uses a DAG structure, explicitly constructing the temporal order and causal dependencies between data through multiple parent block references, thereby achieving full traceability of medical events. Each new block records the Merkle root hash, parent block hash set, and keyword index set of the batch of medical data. These blocks are interconnected through encrypted hash pointers, forming a globally verifiable block topology. To ensure consistency between the on-chain index and the off-chain data, the system constructs and maintains a synchronization binding mechanism between the two through smart contracts, enabling dynamic and verifiable updates of the on-chain authentication root as the off-chain data changes.

[0067] ② Verifiable Query Component: The system employs an ADS-based verifiable index tree as its core query structure and can integrate a Bloom filter for rapid pre-screening. When a user initiates a query request, the off-chain service provider performs a search in the ADS based on keywords and generates a Verification Object (VO) containing the result set and necessary path information. Upon receiving the VO, the user can independently verify the authenticity, completeness, and timeliness of the query results, without any centralized third-party intervention.

[0068] The embodiments of this invention can be applied to large-scale medical data query scenarios, and the core architecture is as follows: Figure 2 As shown, the overall process of the method is as follows: Figure 1 As shown, the specific steps include:

[0069] First, the original medical data undergoes comprehensive verification, including verification of data source, digital signature, timestamp, and provider qualifications. Pre-defined rules confirm that the data source is an authorized medical institution, the signature is valid and matches the provider's identity, the timestamp conforms to the logic of the medical event, and the provider has legitimate upload permissions. Verified data is used for subsequent DAG main chain block encapsulation in S1 and ADS construction in S2; data that fails verification is directly rejected by the system and does not proceed to any further processing.

[0070] For medical data that has passed the legitimacy verification, a corresponding hash digest (consistent with the hash digest H(D) in subsequent S2) and index metadata (including data type, patient identifier, and the occurrence time of the corresponding medical event) must be generated, and a data authentication certificate must be formed. This data authentication certificate serves as the basis for subsequent on-chain registration and will be uploaded to the blockchain simultaneously when the authentication root hash is submitted in S3. It is used to trace the source of medical data and the associated information of the corresponding medical event during auditing.

[0071] Step S1: Construct a DAG-based hybrid storage blockchain architecture

[0072] This step aims to construct a hybrid storage blockchain architecture. This architecture divides data storage into on-chain and off-chain components: on-chain stores lightweight, high-verification-value information, including data hash fingerprints (such as block hashes and authentication root hashes), transaction metadata, and index pointers; off-chain stores raw, complete medical data (such as medical record details and image files) to ensure data privacy and storage efficiency. Based on this, the core of this step is to form a DAG blockchain topology with temporal order and causal logic by "modeling medical events as DAG nodes" and "extracting causal relationships from events to construct directed edges." This is specifically divided into the following two parts:

[0073] (1) Medical event modeling and new block generation

[0074] In the medical data management system of this embodiment, each medical event (such as diagnosis, examination, prescription, etc.) is first abstracted as a node in a DAG structure, and then connected to the preceding node through a cryptographic hash pointer, thereby forming a topological structure with temporal order and causal logic.

[0075] When medical data providers collect a new batch of medical data When (e.g., patient A's CT images, diagnostic report, and prescription), the system generates and adds a new block according to the following process:

[0076] Select the k most recent blocks from the DAG structure as the set of parent blocks for the current new block: ;

[0077] H() converts data input of arbitrary length into a unique hash value of fixed length; It is the identifier of a parent block;

[0078] ② Calculate the hash value of the current batch of medical data: , represents the root hash obtained after constructing a Merkle tree on dataset D, representing the integrity proof of the entire batch of data;

[0079] ③ Extract the keyword set of the current batch of medical data It is encapsulated together with the parent block hash to generate a new block. The structure of the new block is defined as follows:

[0080] ;

[0081] in, For medical data batches, A set of keywords extracted from medical data. For the parent block hash, For Merkle root hash, The root of the authentication data structure ADS;

[0082] ④ During the encapsulation process, the hash set of the parent block and the Merkle root hash calculated from the current batch of medical data are written together into the block header of the new block to form a hash dependency chain across blocks, ensuring the traceability of the on-chain index of the DAG main chain and the integrity of the off-chain data.

[0083] ⑤ New block Add it to the DAG main chain to expand the chain structure.

[0084] This mechanism allows multiple nodes to write new blocks simultaneously, maintains data immutability through hash pointers, and maintains the temporal and causal consistency of medical events through parent-child block reference relationships.

[0085] (2) Automated causal dependency extraction and complete DAG construction

[0086] To ensure that medical data can be verifiably stored and retrieved in a DAG blockchain, this invention proposes a complete on-chain and off-chain collaborative indexing and authentication method. During the construction of the DAG blockchain structure, the system employs an automated causal dependency extraction algorithm to map the causal relationships between events in the medical data as directed edges. Specifically, the algorithm follows these rules:

[0087] ① Time sequence rule: If events The timestamp is earlier than Then, a time dependency edge is established between the two.

[0088] ② Subject Consistency Rule: If two events belong to the same patient and have a dependency relationship in the clinical process (such as "examination → diagnosis → prescription"), then a causal edge is automatically established;

[0089] ③ Semantic matching rules: Semantic matching of event tags is performed using medical ontology databases such as patient name and disease type; if the output field of event A appears in the input field of event B, a semantic dependency edge "A→B" is established.

[0090] ④ Key field triggering rules: If an image report or test result generated by an event is used for subsequent diagnosis and treatment, the event will be automatically added as a dependency of the subsequent event.

[0091] Based on the above rules, the system performs causal scanning on each medical order, image, and record, generating a set of parent events corresponding to each node. Ultimately, a complete DAG structure is constructed to realize a traceable and verifiable causal chain between medical events.

[0092] (3) DAG main chain topology timing logic verification

[0093] After constructing the core topology of the DAG main chain containing semantically related medical event chains, it is necessary to perform time-series logic verification on the medical data DAG nodes: by comparing the timestamps and causal dependencies of the medical events associated with each node, it is ensured that the causal dependencies and time order of each node are consistent (e.g., the timestamp of the node corresponding to the medical data of a diagnosis event is later than the timestamp of the node corresponding to the medical data of the examination event it depends on), to avoid topological structure conflicts. After the time-series logic verification passes, the above-mentioned medical data hash value calculation, new block encapsulation and addition operations are performed to ensure the time-series consistency of the new block with the DAG main chain topology.

[0094] Step S2: Construct the off-chain authentication data structure and authentication index

[0095] This step targets the original medical data records processed in step S1 and stored off-chain. The core is to build a dynamically updatable and verifiable off-chain authentication and indexing system, as detailed below:

[0096] (1) Privacy enhancement processing and ADS initialization

[0097] For legally verified medical data, privacy enhancement processing is performed first, and then the authentication data structure ADS is constructed:

[0098] ① Privacy enhancement processing: First, sensitive fields such as patient names and ID numbers in the data are masked and desensitized. Then, a symmetric encryption algorithm is used to encrypt the complete desensitized data. The encryption key is uniformly distributed to authorized nodes by the key management center.

[0099] ②ADS Initialization: Based on the encrypted data, generate its cryptographic hash digest. This digest corresponds to the hash value calculated and uploaded to the chain in S1, and together they form the basis for on-chain and off-chain medical data consistency verification. Based on this hash digest and data element information, an Authenticated Data Structure (ADS) is constructed to provide a carrier for subsequent on-chain and off-chain consistency verification.

[0100] (2) ADS structural design and incremental update rules

[0101] The authentication data structure ADS is built based on a combination of a Merkle hash tree and an algebraic accumulator. The algebraic accumulator uses an RSA algebraic accumulator, which ensures data integrity while supporting efficient dynamic updates. Its update rules are as follows:

[0102] (1);

[0103] in, This indicates the currently added batch of medical data. A polynomial function generated by a hash map; This is the updated root hash. This represents the root hash at time t−1, which is also the original authentication root of the previous round;

[0104] The specific function implementation algorithm for this rule is defined as follows:

[0105] (2);

[0106] in, and Corresponding to the update rules and That is, the authentication root hash of the current moment and the previous moment; This indicates the addition of a new medical dataset. This is the generated function after hash mapping. The algorithm uses the authentication root of the previous state. The generated function values ​​of all elements in the newly added dataset By performing a product operation, a new authentication root can be generated iteratively. This enables incremental updates to the authentication status.

[0107] The advantage of this design is that when adding or modifying medical data, it is not necessary to rebuild the entire Merkle tree; only the local paths need to be recalculated, significantly reducing index update overhead and adapting to application scenarios where medical data changes frequently. In this embodiment, the Merkle tree is used to generate and verify the integrity hash of the medical data itself; the RSA algebraic accumulator is used for efficient authentication and dynamic updating of the keyword set associated with the data. The authentication status of the two is linked to achieve unified authentication of data integrity and keyword verifiability.

[0108] (3) Working mechanism of RSA algebraic accumulator

[0109] The RSA algebraic accumulator, as a core component of ADS, has a workflow divided into three stages: initialization, keyword processing, and verification.

[0110] ① Initialization phase: Select large prime numbers p and q to generate the modulus. q and N are moduli obtained by multiplying two large prime numbers p and q, and are the core foundation for public and private key generation in the RSA encryption algorithm; and define the initial value of the accumulator. This means that the initial value is obtained by taking the remainder of the base g modulo N. It is used for the initialization of cryptographic accumulators or verifiable structures (mod represents modulo operation), laying the foundation for subsequent key accumulation;

[0111] ② Keyword processing stage: For the keywords of each medical data... The system first calculates its hash value. Then, substitute the hash value into the accumulator and perform the accumulation operation. mod N forms the accumulator state bound to the keyword set;

[0112] ③ Verification phase: When a user needs to verify a keyword When determining whether a member belongs to the target set, the off-chain server returns a membership certificate. And the current accumulator value A, the user verifies the formula. This will confirm the keyword. The legitimacy of it.

[0113] This RSA algebraic accumulator supports dynamic updates. When adding new keywords, only an incremental accumulation operation needs to be performed, without rebuilding the entire index structure. It can perfectly adapt to the needs of scenarios with high-frequency updates of medical data.

[0114] Example of on-chain and off-chain collaborative index

[0115] To further illustrate the openness and operability of the indexing mechanism, this embodiment provides a complete example of on-chain and off-chain collaborative indexing.

[0116] Suppose a medical data node contains the keyword set {“CT”, “Lung”, “Diagnosis”}, the system executes the following process:

[0117] ① Calculate the hash value of each keyword sequentially. ;

[0118] ② Hash the above keywords Insert the RSA algebraic accumulator one by one to generate the updated accumulator value. ;

[0119] ③ Set the accumulator value Write the ADS root of the current block to complete the binding between the off-chain index and the on-chain authentication root;

[0120] ④ When a user queries the keyword "Diagnosis", the off-chain server returns a membership proof for that keyword. Users verify the formula Whether the validity of "Diagnosis" is established;

[0121] ⑤ If the verification is successful and the corresponding data node is matched, the off-chain server returns the data and verification path; the user reconstructs the local Merkle tree through this path, and then compares the reconstructed Merkle root with the ADS root stored on the chain, and finally completes the data integrity verification and traceability confirmation.

[0122] Step S3: Perform medical data writing and authentication root update operations.

[0123] The core of this step is to introduce a hierarchical hash aggregation mechanism based on DAG (to replace the traditional linear Merkle hash tree). A verifiable hash tree is constructed through "data sharding → hash calculation → multi-dimensional aggregation → root node generation," and the division of labor between on-chain and off-chain storage and the local verification logic are clearly defined, as follows:

[0124] (1) The purpose of introducing the DAG hierarchical hash aggregation mechanism

[0125] To achieve verifiable indexing and on-chain authentication of medical data, this invention introduces a hierarchical hash aggregation mechanism based on directed acyclic graphs (DAGs) into the medical data management system, replacing the linear Merkle hash tree structure used in traditional blockchains.

[0126] The advantage of this mechanism is that it constructs non-linear aggregation paths through hash dependencies between nodes, which can ensure data security and tamper resistance, and effectively improve the scalability and verification efficiency of the system in high-concurrency scenarios.

[0127] (2) Verifiable hash tree construction process

[0128] The construction process follows the logic of "fine-grained sharding → local hash calculation → multi-dimensional aggregation → global authentication root generation", and the steps are as follows:

[0129] ① Medical data fragmentation: Dividing medical datasets into multiple fine-grained data fragments. This includes, but is not limited to, medical records, imaging reports, test results, or prescription information;

[0130] ② Local hash calculation: For each data segment The local hash value is calculated separately using the following formula:

[0131] (3);

[0132] in, This represents the local hash value of the i-th data segment d, also known as the leaf node hash value; This represents the i-th data segment; This represents a secure hash function that maps inputs of arbitrary length to outputs of fixed length. This indicates that there are a total of n such data segments;

[0133] ③ Multidimensional aggregation to generate intermediate nodes: Based on the dependencies between nodes in the DAG structure and time series constraints, multiple leaf nodes (i.e., the local hash nodes corresponding to data segments) are multidimensionally aggregated to form intermediate hash nodes containing time logical labels, defined as... ,in, This represents the hash value of the left child node of node i; This represents the hash value of the right child node of node i;

[0134] ④ Generate the global authentication root: Using the DAG topology traversal algorithm, all intermediate hash nodes are further aggregated. After aggregation, the global authentication root node is generated. The value used as the authentication value for this batch of medical data is calculated using the following formula: ,in, This represents the hash value of the left child node of the root node; This represents the hash value of the right child node of the root node.

[0135] (3) On-chain and off-chain storage division of labor design

[0136] To balance storage efficiency and data security, a division of labor model of "on-chain lightweight storage + off-chain complete storage" is adopted:

[0137] ① On-chain storage: When each new block is written to the blockchain, it only contains the hash value of the globally certified root node. This serves as proof of the integrity of all medical data within the block, significantly reducing on-chain data redundancy and storage pressure, and avoiding the block expansion problem caused by large-scale on-chain medical records.

[0138] ② Off-chain storage: The complete hash tree structure and its corresponding leaf node data are stored in an off-chain trusted service provider (SSP) for subsequent verification, auditing and traceability operations.

[0139] (4) Incremental update operation of authentication root

[0140] When performing the authentication root update operation, an incremental update mechanism is adopted: only the ADS nodes corresponding to newly added medical data are subjected to hash calculation and status update. Based on the association relationship between the new node and the original nodes, a local update hash value is calculated, and then merged with the original authentication root hash to generate a new authentication root hash. An update log is recorded during the incremental update process, including the update time, the identifier of the new data, and the node association information, thereby achieving traceability and improving the efficiency of the authentication root update.

[0141] When a data provider writes a new block generated in S1, the corresponding authentication data structure ADS node is updated based on the keyword set extracted from the legally verified medical data. The updated authentication root hash is calculated and simultaneously submitted to the blockchain along with the data authentication credential generated in S2, achieving a dual binding between the block hash and the authentication root hash of the new block. At the same time, the authentication status of the Merkle tree and the RSA algebraic accumulator (i.e., the Merkle root hash and the accumulator value) are submitted together to the blockchain block header, completing the association and binding.

[0142] (5) Incremental update and partial verification features

[0143] Furthermore, the Merkle tree structure supports efficient incremental updates and partial validation features, adapting to the high-frequency changes in medical data.

[0144] When new medical data blocks are added When adding data to the system, there is no need to rebuild the entire hash tree. Only the leaf node corresponding to the data block and the associated intermediate hash node path need to be recalculated to complete the update. At the same time, during verification, partial verification can be performed on newly added data blocks without traversing all nodes.

[0145] This mechanism further enhances the system's dynamic data processing capabilities and real-time verification performance in multi-organizational environments.

[0146] Step S4: Generate query verification object

[0147] The core of this step is to build a collaborative architecture between lightweight on-chain verification and high-performance off-chain storage by clarifying the division of responsibilities between on-chain and off-chain data, standardizing the query execution process, and maintaining block topology consistency, thereby generating a query verification object (VO), as detailed below:

[0148] (1) Core objective of the collaborative mechanism

[0149] The on-chain and off-chain collaborative storage and verification mechanism of this invention aims to achieve efficient access and verifiable querying of medical data in multi-source heterogeneous environments. By coordinating the "division of responsibilities, state synchronization, and verification interaction" between on-chain and off-chain data, the authenticity, integrity, and traceability of medical data are ultimately guaranteed.

[0150] (2) Division of responsibilities for on-chain and off-chain data

[0151] To balance storage efficiency and query security, the system clearly defines the storage content and functions of on-chain and off-chain data:

[0152] ① Content and function of on-chain storage: The root node of the hash tree on the blockchain stores only medical data. The root hash and related index information are used for on-chain verification (as a benchmark for data integrity).

[0153] ② Content and function of off-chain storage: The complete hash tree structure, leaf node data and metadata are all stored in the off-chain distributed storage platform. The core is used for high-capacity medical data storage and fast query, and supports off-chain retrieval and verification path generation.

[0154] (3) The four-stage execution process of user query

[0155] When a user initiates a medical data query request, the system executes the process in the following order: "on-chain location → off-chain retrieval → result verification → consistency maintenance," ensuring efficient querying and reliable results.

[0156] ① On-chain location phase: Led by a smart contract, based on the set of keywords and query conditions input by the user, the block number associated with the keyword is automatically located, and the root node of the hash tree recorded in that block is extracted. This ensures that users only need to access a minimal amount of on-chain information to complete indexing and locating, avoiding high-frequency access to the blockchain and reducing on-chain computing and communication load.

[0157] ② Off-chain retrieval phase: The off-chain trusted service provider (SSP) performs keyword matching retrieval in its maintained authentication data structure (ADS) based on the index pointer and keyword set obtained from the chain. The specific operations include: filtering out nodes that match the keywords to form a "matching node set"; generating a "verification path" corresponding to the matching node set (for subsequent user verification); and encapsulating the "matching node set + verification path" into a verification object (VO) and returning it to the user.

[0158] ③ Block topology consistency maintenance: The topological order of new blocks in the DAG main chain is maintained through the DAG weight mechanism. The block weight value is calculated as follows:

[0159] (4);

[0160] in, Indicates the current block The weight of the new block mentioned above, Indicates the current block The set of parent blocks; express Each parent block in; This formula calculates the maximum weight value among all parent blocks; the meaning of this formula is: whenever a new block is created... At that time, the system will first search for all its parent blocks. Obtain their weights Calculate the maximum weight value and add 1 to it; this value will be the weight of the new block. The system sorts blocks according to their weights, and during verification or querying, only the legal path with the highest weight is recognized as a valid tracing path. The weight values ​​are used for conflict and fork resolution and on-chain global sorting of the DAG main chain, ensuring structural order and data security during chain expansion under high-concurrency write conditions.

[0161] Step S5: Perform local validation of query results.

[0162] The core of this step is to enable users to independently verify the authenticity, completeness, and traceability of query results without third-party involvement through "verification object deconstruction → temporary ADS reconstruction → root hash comparison → keyword-level integrity verification." The entire process revolves around the correspondence between the on-chain ADS root and the off-chain generated VO, ensuring the reliability of the query result source and the absence of data tampering. Specifically:

[0163] (1) The core objective of the local verification mechanism

[0164] This ensures that users can independently verify the authenticity and completeness of query results without relying on any service node after receiving them. By deconstructing, reconstructing, and comparing matching nodes, non-matching nodes, and their corresponding proof structures in the VO, consistency verification between on-chain record states and off-chain query results is achieved, thereby guaranteeing that query results have not been maliciously forged, filtered, or tampered with.

[0165] (2) Verification of the structure and initial processing of the object (VO)

[0166] When a user submits a keyword search request Subsequently, the system generates a Verification Object (VO) off-chain based on the target block matched in the DAG. The VO's content includes: the block hash. Data sets matching keywords Data integrity proof Merkle root hash of the block This includes matching and non-matching node sets. After receiving the VO, the client first initializes the verification flag. And we are preparing to perform structured parsing on the VO for subsequent reconstruction of the temporary authentication data structure.

[0167] (3) Reconstruction of temporary authentication data structure and comparison of root hash

[0168] The user matches the set of matching nodes contained in the VO ( ) and non-matching node set ( ), Reconstruct the temporary authentication data structure tree for the corresponding query Then the root hash of the temporary tree is calculated. and link it to the on-chain block ADS root hash stored in The two hashes are compared. If they do not match, it indicates that the data may have been tampered with, and the verification fails immediately; if the root hashes match, the verification proceeds to the next stage, keyword-level verification.

[0169] (4) Distributed local verification process

[0170] In addition to the root hash ratio mentioned above, when any verification node or querying user needs to verify a piece of medical data, verification can also be completed independently through the following process:

[0171] ① Obtain the hash path of the leaf node corresponding to the medical data (i.e., the path hash sequence from the leaf node to the global authentication root node).

[0172] ② Reconstruct the local hash tree structure locally; calculate the root hash value of the local hash tree. ;

[0173] ③ Calculate locally With the root node of the hash tree stored on the blockchain Compare: If If so, it confirms that the medical data has not been tampered with during storage and transmission, and the verification result is authentic and reliable; if If the query fails, the data is deemed abnormal and the query result is invalid.

[0174] This design implements a verifiable, traceable, and trustless distributed medical data verification mechanism, effectively reducing redundancy and storage pressure on on-chain data.

[0175] (5) Verification of the completeness and legality of keyword-level results

[0176] After the root hash comparison passes, the user continues to verify the results corresponding to each keyword in the VO. For each matching node... User extracts keywords and its corresponding result set The largest sequence number in the result set Integrity and validity checks are performed by calling the validity verification function VeriWit, whose specific implementation logic is as follows:

[0177] ① Input parameters: The function receives two key parameters: one is BlockHash (the hash of the block where the data to be verified is located), and the other is MerkleProof (the Merkle tree path proof obtained from the VO that points to the data).

[0178] ② Core verification: The function uses MerkleProof to calculate the hash of its parent node level by level, starting from the leaf node (i.e., the data hash), and finally reconstructs the root hash value Calculated_Root locally;

[0179] ③ On-chain verification: The function accesses the DAG main chain, retrieves the block header of the corresponding BlockHash block, and reads the official root hash value Stored_Root of the pre-stored Authentication Data Structure (ADS);

[0180] ④ Result Judgment: Compare Calculated_Root and Stored_Root. The function returns True if and only if the two are completely identical, confirming that the medical data result set corresponding to the keyword comes from a valid and tamper-proof block in the DAG main chain; otherwise, it returns False.

[0181] Data timeliness verification is performed by calling the timeliness verification function VeriFresh, and its specific implementation logic is as follows:

[0182] ① Input parameters: The function accepts two parameters: BlockHeight (the height of the block where the current verification data is located) and LatestBlockHeight (the latest block height of the DAG main chain obtained from the blockchain network);

[0183] ② Logical judgment: The function calculates LatestBlockHeight - BlockHeight. If the difference is less than or equal to the preset threshold N (N represents the data version delay allowed by the system, for example, N=1 means only the latest or second newest block data is accepted), then the data is determined to be the latest version and "Valid (True)" is returned;

[0184] ③ Update Guarantee: This verification ensures that the query results do not come from outdated, updated on-chain forks, thus confirming that the returned data is the latest version of the medical data for that keyword in the DAG main chain.

[0185] If the VeriWit or VeriFresh validation for a keyword is invalid, or the sequence number does not match the cumulative count, the process will terminate immediately and return to the previous page. If all keywords pass the validation, it means that the queried data is real, complete, up-to-date, and has not been tampered with.

[0186] (6) Final judgment and credibility assurance of verification results

[0187] When the temporary ADS root hash comparison and the verification of each keyword result are both successful, the system will set the verification flag to 0. This indicates that the user can confirm that the result set is completely consistent with the on-chain records. Through this verification process without third-party involvement, this invention constructs a trusted query verification mechanism that users can execute independently locally, ensuring that the query process still possesses traceability, integrity verification, and strong security guarantees even in untrusted environments.

[0188] In summary, the core advantages of the collaborative architecture are: the blockchain layer is responsible for maintaining the integrity of the authentication root and index, while the off-chain storage layer is responsible for managing the raw data and verification path, which significantly reduces the storage and computing load of the blockchain, while ensuring the system's trustworthiness and high scalability in medical data sharing and cross-institutional query environments.

[0189] Example 2: Experimental Verification

[0190] This part of the experiment was conducted in a unified and controllable hardware and software environment. It focused on four core metrics: query performance, verification latency, communication overhead, and gas consumption. Comparative tests were performed with existing solutions to comprehensively verify the performance advantages of this invention. The experiment is divided into two parts: experimental environment setup and multi-dimensional performance analysis.

[0191] (I) Setup of the experimental environment

[0192] (1) Hardware and software environment configuration

[0193] To ensure the reproducibility of experimental results, the entire experiment was conducted in a standardized environment:

[0194] ① Development and runtime environment: The off-chain algorithm module is developed using the Go language, calling the native Go cryptography library to implement the core security components. The symmetric encryption module uses the AES algorithm, the pseudo-random function (PRF) is constructed using SHA-1, and the related operations of the authentication data structure (ADS) and algebraic accumulator are all implemented based on this cryptography library. The blockchain part uses a local simulated network and the Ethereum test chain as the runtime environment. The smart contract is written using Solidity 0.8.21 and deployed on the Ethereum private chain for testing on-chain verification, index writing, and gas consumption performance.

[0195] ② Hardware and System Platform: All experiments were run on the Windows 11 operating system. The test equipment was configured with an Intel(R) Core(TM) i5-13490F @ 2.50 GHz CPU and 16 GB RAM. The data processing module, off-chain verification service and blockchain node running on this platform were deployed as independent processes to avoid additional system interference.

[0196] (2) Preparation of experimental data

[0197] The experimental data comes from actual clinical medical datasets and consists of two core data parts, covering basic data volume and diverse data types. It has also undergone standardized preprocessing to adapt to experimental requirements.

[0198] ① Core Basic Data: This includes 100,000 data items such as consultation records, forming the basic data scale of the experiment. To protect privacy, all medical samples are constructed into DAG nodes according to the type of medical event. Each node contains a data summary, timestamp, keyword set, and meta-attribute tags to ensure that the data meets the system storage structure requirements.

[0199] ② Diverse supplementary data: sourced from real medical datasets, covering various types of medical samples such as image diagnosis records, prescription information, and test reports, enriching the coverage of experimental data and making the test scenarios more in line with actual medical data management needs;

[0200] All data undergoes standardization and hash digest processing before uploading to form medical event nodes that conform to the system structure. These nodes are then organized and managed in the blockchain in the form of a directed acyclic graph (DAG), thereby achieving data traceability and tamper-proofing.

[0201] (3) Core experimental mechanism

[0202] The system in this experimental environment adopts a DAG structure, hash tree index, and on-chain and off-chain collaborative verification mechanism to achieve efficient and verifiable querying and full-process traceability of medical data, ensuring that the experimental scenario is highly consistent with the actual application scenario.

[0203] (II) Comparison of Schemes

[0204] The comparison schemes selected in this experiment are all representative schemes in the field of verifiable medical data queries. The core features of each scheme are as follows, providing a benchmark for subsequent performance comparisons:

[0205] vChain and vChain+: Both are classic verifiable query solutions with the core advantage of low on-chain gas overhead, but they have functional limitations, do not support dynamic data updates, and are difficult to adapt to real-world application scenarios where medical data changes frequently.

[0206] vsChain and vsChain+: Compared to the vChain series of solutions, this series of solutions adds dynamic query function and has higher security, but at the cost of significantly increased on-chain gas consumption, resulting in higher system operating costs.

[0207] SMI and CI: Traditional plaintext index query schemes do not require encryption processing, so the computational overhead during the query phase is extremely low, but they do not provide data encryption protection and cannot meet the core privacy and security requirements of medical data.

[0208] VCKS: A verifiable solution focused on keyword queries, it has certain applicability in specific scenarios, but experiments have shown that it has excessive communication overhead and its performance is limited in large-scale data scenarios.

[0209] (III) Performance Test Parameter Description

[0210] This performance comparison test selected four core performance parameters. The test conditions and measurement objectives for each parameter were determined based on experimental requirements, as detailed below, providing a basis for parameter definition for subsequent multi-dimensional performance analysis:

[0211] Query latency: The time (in milliseconds) from when a user initiates a query request to when the complete query result is received, reflecting the system's response speed and efficiency when processing different data scales;

[0212] Validation latency: The time (in milliseconds) taken from receiving the query result to verifying the correctness of the result;

[0213] Communication overhead: The amount of data transmitted (unit: MB) generated when the system interacts with data on-chain or off-chain or across nodes, reflecting network bandwidth usage and data exchange efficiency;

[0214] Gas consumption: Measures the cost of computing resources required to perform operations on the blockchain, such as inserting files or updating indexes.

[0215] (iv) Multi-dimensional performance analysis

[0216] (1) Query performance comparison

[0217] Figure 3 The query performance trends of each solution are presented under different medical data scales. The test data scale gradually increased from 20,000 records to 100,000 records. The results show that the query latency of each solution generally increased sublinearly, but the differences were significant.

[0218] Traditional SMI and CI solutions have low computational overhead because they query directly on the plaintext index, with query times of only 0.095ms and 0.149ms respectively when n=100000. However, neither of them provides encryption protection, making it difficult to meet the privacy and security requirements of medical data.

[0219] While ensuring data privacy, this invention reduces query latency from 0.381ms to 0.953ms, a relatively small increase. Overall performance is better than vsChain and vsChain+, and comparable to vChain and vChain+. This demonstrates that the solution of this invention can maintain low and gradually increasing query latency when processing larger-scale data, and has good scalability.

[0220] When the data size increases to 100,000 records, the query latency of vChain and vChain+ reaches 1.908ms and 1.112ms respectively, significantly higher than the method of this invention. Importantly, the vChain and vChain+ schemes also possess strong privacy protection capabilities. Experimental results show that, while providing equivalent privacy protection, the query latency of this invention is significantly lower than that of the vChain and vChain+ schemes. This demonstrates that this invention achieves a better balance between data privacy protection and query efficiency, realizing a unity of security and usability, and exhibiting high system scalability. To provide quantitative evidence, Table 1 lists the query latency data of each scheme as the data size increases when the number of query keywords q=2 is fixed. Table 2 further shows that when the data size n=100,000 is fixed, the query latency of this invention remains low under different numbers of query keywords, verifying the stability and scalability of its query efficiency.

[0221] Table 1. Comparison of query latency for each scheme (unit: ms, q=2)

[0222]

[0223] Table 2. Comparison of query latency for each scheme (unit: ms, n=100000)

[0224]

[0225] (2) Verification delay comparison

[0226] Figure 4 The validation latency trends of various schemes under different medical data scales are presented. This test fixed the number of query keywords q=2 to explore the impact of increasing dataset size on validation time. The validation time of all schemes increased with increasing dataset size, but the rate of increase differed significantly. The scheme of this invention showed the best validation efficiency under all data scales.

[0227] When the data size reaches n=100000, the verification time of this invention is only 0.58 milliseconds, which is significantly better than the vsChain (0.92ms), vsChain+ (0.83ms), vChain (3.2ms) and vChain+ (2.8ms) schemes. Compared with the SMI (0.98ms), VCKS (115ms) and CI (999ms) methods, the verification latency of this scheme is also greatly reduced, and the verification efficiency is significantly improved.

[0228] It is worth noting that the extreme differences in verification latency exhibited by different schemes stem from the differences in their underlying technical mechanisms:

[0229] ①The CI scheme is based on the Verifiable Delay Function (VDF) and uses a repeated hash chain structure to achieve time delay guarantee. Although it provides verifiable delay characteristics, it also leads to significant verification delay.

[0230] ② The VCKS scheme is based on bilinear pairing technology and uses bilinear mapping function to achieve verifiability. Its computational complexity is high, which brings a large verification overhead.

[0231] ③ The SMI scheme directly uses a plaintext index structure, avoiding encryption and complex verification calculations, thus resulting in extremely low verification latency, but it cannot provide privacy protection;

[0232] ④ Under the premise of ensuring data privacy, the present invention achieves significant advantages in verification efficiency through optimized authentication data structure and lightweight verification mechanism.

[0233] Tables 3 and 4 provide detailed verification time data under the conditions of fixed q=2 and fixed n=100000, respectively, which further support the above conclusions and show that the present invention has efficient verification capabilities under dynamic data scale and multi-keyword scenarios.

[0234] Table 3 Comparison of verification delays for each scheme (unit: ms, q=2)

[0235]

[0236] Table 4 Comparison of verification delays for each scheme (unit: ms, n=100000)

[0237]

[0238] (3) Comparison of communication overhead

[0239] Figure 5 The study presents the communication overhead trends of various approaches under different medical data scales. In this test, the number of query keywords was fixed at q=2 to observe the changes in communication overhead as the data scale increased. The communication overhead of all approaches increased with the increase in dataset size, but the method proposed in this invention consistently maintained a low and stable communication cost.

[0240] Even when the data volume increases from 20,000 to 100,000, the solution of this invention still has good transmission efficiency and scalability;

[0241] When n=100000, the communication overhead of this scheme is only 0.63 MB, which is approximately 6.6%, 5.9%, 78.8%, 63.4%, 7%, 0.6%, and 8.7% of the vsChain, vsChain+, vChain, vChain+, SMI, CI, and VCKS methods, respectively.

[0242] These results demonstrate that, in large-scale medical data environments, this invention can significantly reduce the data transmission volume during on-chain and off-chain interactions, effectively improving system bandwidth utilization and cross-institutional collaboration performance. Tables 5 and 6 show communication overhead data at different scales, providing concrete data support for the advantages of this solution in terms of transmission efficiency.

[0243] Table 5. Comparison of communication overhead for each scheme (unit: MB, q=2)

[0244]

[0245] Table 6. Comparison of communication overhead for each scheme (unit: MB, n=100000)

[0246]

[0247] (4) Gas consumption comparison

[0248] Figure 6 The average gas consumption per file insertion operation for each scheme is presented under different dataset sizes. Test results show that as the data size gradually increases, the gas consumption of each scheme exhibits a slight upward trend, but this invention maintains a consistently low and stable consumption level, demonstrating good on-chain execution efficiency and system scalability.

[0249] It should be noted that the vChain and vChain+ schemes use a static storage structure and do not support dynamic data updates. Their on-chain operation complexity is fixed, so gas consumption does not change with the data size, but is only related to the operation type. In contrast, although this invention supports dynamic updates, it still maintains stable and low gas overhead by optimizing the index structure and incremental update mechanism.

[0250] In an overall comparison, the vChain and vChain+ solutions have the lowest gas overhead, but neither supports dynamic data updates, limiting their functionality and making it difficult to meet the actual needs of frequent changes in medical data; while vsChain and vsChain+ support dynamic queries and have higher security, their gas consumption increases significantly, resulting in higher operating costs.

[0251] While maintaining dynamic updability and security verifiability, the gas overhead of this invention is always lower than that of vsChain and vsChain+, only slightly higher than that of vChain and vChain+, and is superior to or equal to that of representative solutions SMI and CI.

[0252] Experimental results demonstrate that this invention achieves a good balance between functional integrity and on-chain execution efficiency. Even as the dataset size continues to increase, the system's gas consumption growth remains within a controllable range, indicating that this scheme possesses stable on-chain performance and excellent resource utilization, making it suitable for scenarios involving real-time on-chain storage, sharing, and verifiable storage of large-scale medical data. Table 7 further shows the gas consumption data of each scheme under the condition of fixed q=2, providing quantitative evidence for the resource efficiency advantages of this invention.

[0253] Table 7. Comparison of Gas Consumption for Each Scheme (q=2)

[0254]

[0255] In summary, this invention, through encrypted indexing and optimized query mechanisms, achieves low query latency, high verification efficiency, stable low communication overhead, and controllable gas consumption while ensuring the privacy and security of medical data, significantly outperforming existing solutions. Its innovations lie in balancing privacy protection and query performance, adopting a lightweight verifiable mechanism, optimizing on-chain and off-chain data transmission, and efficiently utilizing on-chain resources, enabling the system to possess excellent scalability, real-time performance, and cross-institutional collaboration capabilities in large-scale medical data environments.

[0256] Although the embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, and for those of ordinary skill in the art, various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the present invention. Therefore, the present invention is not limited to the specific details without departing from the general concept defined by the claims and their equivalents.

Claims

1. A verifiable medical data query method based on a DAG blockchain architecture, characterized in that, Includes the following steps: Step S1: Construct a DAG-based hybrid storage blockchain architecture: Collect medical data generated by medical events, model the medical data as DAG nodes, establish causal dependencies and temporal order between nodes through encrypted hash pointers, construct a medical event chain with semantic associations, and form the core topology of the DAG main chain; calculate the hash value of the current batch of medical data and extract its keyword set, encapsulate the parent block hash set, the keyword set, and the hash value of the current batch of medical data into a new block, and add the new block to the DAG main chain to complete the chain structure expansion; Step S2: Construct an authentication data structure and authentication index for the current batch of medical data stored off-chain: Generate a hash digest H(D) of the batch of data, and construct an authentication data structure ADS by combining a Merkle hash tree and an algebraic accumulator, thereby generating an authentication index for verifying the consistency between the on-chain digest and the off-chain original. Step S3: Perform medical data writing and authentication root update operations: When the data provider writes the new block, the corresponding authentication data structure ADS node is updated according to the keyword set extracted from the medical data that has passed the legality verification. The updated authentication root hash is calculated and submitted to the blockchain to realize the dual binding of the block hash of the new block and the authentication root hash. Step S4: Generate Query Verification Object: When a user initiates a query request, the service provider uses the set of keywords entered by the user as the search criteria and executes the query in the off-chain authentication data structure ADS. The DAG weight mechanism maintains the topological order consistency of the new block in the DAG main chain. The block weight value is calculated as follows: in, Indicates the current block The weight of the new block mentioned above, Indicates the current block The set of parent blocks; express Each parent block in; The weight value is used for conflict and fork resolution and on-chain global sorting of the DAG main chain, to achieve structural order and data security in the chain structure expansion under high-concurrency write conditions, and then to retrieve and generate a verification object VO containing a set of matching nodes. Step S5: Perform local verification of query results: The user terminal performs local verification based on the root hash of the ADS authentication data structure stored on the blockchain and the returned verification object VO to confirm the authenticity, completeness and traceability of the query results.

2. The method according to claim 1, characterized in that, Before steps S1 and S2, there is also a medical data legality verification step: The original medical data undergoes comprehensive verification, including verification of data source, digital signature, timestamp, and provider qualifications. Preset rules confirm that the data source is an authorized medical institution, the signature is valid and matches the provider's identity, the timestamp conforms to the logic of the medical event, and the provider has legitimate upload permissions. Verified data is used for DAG main chain block encapsulation in step S1 and ADS construction in step S2. Data that fails verification is directly rejected by the system and does not proceed to any subsequent processing.

3. The method according to claim 1, characterized in that, The medical event mentioned in step S1 refers to the clinical diagnosis and treatment process, and the medical data refers to the records or results generated by the medical event, including: diagnosis and treatment records, imaging reports, and prescription information; The process of establishing causal dependencies and temporal order between nodes using encrypted hash pointers specifically employs an automated causal dependency extraction algorithm. This algorithm maps the causal relationships between events in the medical data into directed edges, and it follows these rules: (1) Time order rule: If the timestamp of an event is earlier than that of another event, then a time dependency edge is established; (2) Subject consistency rule: If two events belong to the same patient and have a dependency relationship in the clinical process, a causal edge is automatically established; (3) Semantic matching rules: Semantic matching of event tags is performed using the medical ontology library of patient name and disease type. If the output field of event A appears in the input field of event B, then a semantic dependency of A to B is established. (4) Key field triggering rules: If an image report or test result generated by an event is used for subsequent diagnosis and treatment, it will be automatically added as a dependency edge; Based on the above rules, each medical order, image, and record is causally scanned to generate a set of parent events and construct a complete DAG structure to form the core topology of the DAG main chain containing the semantically related medical event chain.

4. The method according to claim 3, characterized in that, In step S1, when encapsulating the new block, the k nearest blocks are selected as the parent block set, and the structure of the new block is defined as follows: in, For medical data batches, A set of keywords extracted from medical data. For the parent block hash, For Merkle root hash, The root of the authentication data structure ADS; During the encapsulation process, the parent block hash set and the Merkle root hash calculated from the current batch of medical data are written together into the block header of the new block to form a hash dependency chain across blocks, ensuring the traceability of the on-chain index and the integrity of the off-chain data of the DAG main chain.

5. The method according to claim 4, characterized in that, In step S2, privacy enhancement processing and authentication data structure construction are performed on the medical data that has passed the legitimacy verification, specifically including: (1) Privacy enhancement processing: First, the patient's name and ID number in the data are masked and desensitized. Then, a symmetric encryption algorithm is used to encrypt the complete original data after desensitization. The encryption key is uniformly distributed to authorized nodes by the key management center. (2) Construction of authentication data structure: Based on the encrypted data, generate its cryptographic hash digest H(D), and construct the authentication data structure ADS with this as the core to achieve the unity of data privacy protection and verifiability.

6. The method according to claim 5, characterized in that, The authentication data structure ADS is constructed based on a combination of a Merkle hash tree and an algebraic accumulator; the algebraic accumulator uses an RSA algebraic accumulator, and its algorithm for supporting incremental updates is defined as follows: in, and Δ is the root hash of the authentication at the current time and the previous time. t For the newly added medical dataset, P(H(x)) is the generating function after hash mapping; the design of this authentication data structure ADS realizes incremental authentication updates and fast index verification of off-chain data.

7. The method according to claim 6, characterized in that, When performing the authentication root update operation in step S3, an incremental update mechanism is adopted: only the ADS nodes corresponding to the newly added medical data are hashed and their status is updated. Based on the association between the newly added node and the original node, the local update hash value is calculated, and then the original authentication root hash is merged to generate a new authentication root hash. During the incremental update process, an update log is recorded, which includes the update time, the identifier of the newly added data and the node association information, so as to realize the traceability and efficiency improvement of the authentication root update.

8. The method according to claim 1, characterized in that, The verification object VO generated in step S4 includes a set of matching nodes, a set of non-matching nodes, an accumulator proof path, and a latest number verification path; Wherein, the matching node set is the medical data DAG node that matches the user's query keywords, the non-matching node set is the medical data DAG node that does not match the user's query keywords but needs to participate in the verification, the accumulator proof path is the accumulator calculation path used to verify the membership of the keyword set, and the latest number verification path is the block number path used to verify the timeliness of the data. The user terminal uses the verification object VO to reconstruct a temporary authentication subtree, calculates the root hash of the temporary authentication subtree, and compares it with the root hash of the authentication data structure ADS stored on the blockchain. If the comparison is consistent, a self-verification mechanism without the participation of a trustless third party is realized.

9. The method according to claim 1, characterized in that, The local verification process described in step S5 specifically includes: (1) Based on the verification path in the verification object VO, reconstruct the local authentication tree and calculate the root hash value of the local authentication tree according to the Merkle hash tree calculation rules; (2) Compare the calculated local authentication tree root hash value with the authentication data structure ADS root hash stored in the new block; (3) Perform legality verification and timeliness verification on each keyword in the keyword set: legality verification is performed by calling the legality verification function VeriWit to confirm that the medical data result set corresponding to the keyword comes from the legal block of the DAG main chain; timeliness verification is performed by calling the timeliness verification function VeriFresh to confirm that the medical data returned by the keyword is the latest version in the DAG main chain. If the comparison in step (2) is consistent and all verifications in step (3) are successful, then the query result is confirmed to be true and complete.

Images