Distributed medical data security sharing method based on blockchain and AI

Abstract

This invention belongs to the field of data analysis technology and discloses a distributed medical data secure sharing method based on blockchain and AI. A core smart contract is deployed on a consortium blockchain, where each data institution constructs a cryptographic commitment to its local medical data and registers the cryptographic commitment and consent credential on the consortium blockchain. The task initiator generates a task description and a minimal data declaration, and registers the task identifier and the cryptographic digest value of the minimal data declaration on the consortium blockchain. Based on the minimal data declaration and consent credential, the data institution executes computation tasks in a secure environment and generates a cryptographic credential for verifying the compliance of data use. The cryptographic credential is submitted to the consortium blockchain for verification. After successful verification, the computation results from all parties are aggregated, and an access token is generated. When the consent credential is withdrawn or expires, a withdrawal event is registered on the consortium blockchain, thus realizing distributed medical data secure sharing based on blockchain and AI.

Description

Technical Field

[0001] This invention relates to the field of data analysis technology, and more specifically, to a method for secure sharing of distributed medical data based on blockchain and AI. Background Technology

[0002] With the rapid development of "Internet + Healthcare" technology, different hospitals are creating shared AI to share patient information and enable data-sharing diagnosis when patients switch hospitals. For example, hospitals A, B, and C combine their medical data to jointly train a shared AI diagnostic model. To protect privacy, data is not directly shared, and blockchain is used to record all operations, ensuring transparency and immutability. However, existing technologies (access control + blockchain audit logs) can only solve the problem of "who accessed the data and when," but cannot address the issue of verifiable forgetting after a patient withdraws their data consent. Specifically, according to privacy regulations, patients have the right to withdraw their consent to use their data at any time. Once withdrawn, the data user should delete the data and ideally "forget" the patient's information from the trained AI model. However, deleting data is easy, but making the model "forget" is extremely difficult. An AI model is not a database; it does not simply store data but learns patterns or rules from massive amounts of data. Once a piece of data is used, its impact is already integrated into the model's parameters, affecting the model's operation and use. To address this problem, existing techniques involve "retraining" or "empirical ablation," which involves removing the patient's data and retraining a new model. However, this presents two challenges:

[0003] 1. It is impractical to retrain the large model every time a patient withdraws consent. Firstly, because the model is designed for a large number of patients, the number of times a patient withdraws consent during use is uncertain. This results in a huge potential number of retraining attempts at each frequency, which is extremely costly and computationally infeasible.

[0004] 2. It is impossible to prove to patients and auditors that the new model does not contain any information that was not consented to. Patients may suspect that the researchers may have just pretended to retrain the model, and it is also impossible to verify. Therefore, the existing technology cannot provide a "forgotten certificate" that can be automatically verified by a machine.

[0005] Based on the above problem description, a distributed medical data security sharing method based on blockchain and AI is designed. Summary of the Invention

[0006] To overcome the aforementioned shortcomings of existing technologies and achieve the above objectives, this invention provides the following technical solution: a distributed medical data secure sharing method based on blockchain and AI, comprising:

[0007] Step S1: Deploy the core smart contract on the consortium blockchain. Each data institution constructs a cryptographic commitment for local medical data, compiles the patient's consent into a consent certificate, and registers the cryptographic commitment and consent certificate on the consortium blockchain.

[0008] Step S2: The task initiator generates a task description and a minimal data declaration, and registers the task identifier and the cryptographic digest value of the minimal data declaration on the consortium blockchain;

[0009] Step S3: Based on the minimum data declaration and consent certificate, the data agency extracts a compliant data subset from local data, performs computational tasks in a secure environment, and generates cryptographic credentials for verifying the compliance of data use.

[0010] Step S4: Submit the cryptographic credentials to the consortium blockchain for verification. After successful verification, aggregate the calculation results from all parties and generate an access token.

[0011] Step S5: When the consent certificate is withdrawn or expires, the withdrawal event is registered on the consortium blockchain. The data agency locates the contribution of the withdrawn data, removes the contribution from the original model in a secure environment to generate a new model, and generates a forgetting proof to verify whether the forgetting operation was executed correctly.

[0012] Step S6: Submit the forget proof to the consortium blockchain for verification. After successful verification, update the model state and clean up access tokens that conflict with the revocation event.

[0013] Preferably, the core smart contract includes a strategy contract and a proof verification contract. The strategy contract is used to manage the data usage strategy, and the proof verification contract is used to verify the cryptographic proof. Each data institution constructs a Merkel commitment tree for the local medical dataset and calculates its root hash value as the dataset commitment root, thus forming the construction of the cryptographic commitment.

[0014] For patient-authorized data, the consent compilation process converts it into a digital consent certificate with a unique identifier, and the version identifier of the consent certificate is registered on the consortium blockchain.

[0015] Preferably, the task description is a file containing the task objective and task type, which is submitted to the consortium blockchain.

[0016] Generate a unique task identifier;

[0017] The minimum data declaration is generated locally by the task initiator and includes at least the set of field names required by the task, denoted as the field set; the Boolean predicate conditions used to filter qualified samples, denoted as the sample selection predicate; and the differential privacy budget parameters, denoted as the privacy parameters.

[0018] Register the task identifier and the cryptographic digest value of the minimal data declaration on the consortium blockchain.

[0019] Preferably, the method for extracting a compliant subset of data from local data and performing computational tasks in a secure environment includes:

[0020] Step A1: The data agency parses the minimal data declaration, uses the sample selection predicate and field set as query conditions, and combines them with the currently effective consent credentials to execute the query on the Merkel commitment tree; it then filters out specific samples and fields that simultaneously meet the declaration conditions and the patient's authorization status, forming a compliant field-sample subset.

[0021] Step A2: Load the field-sample subset into the secure environment, execute the task on the predefined model, perform gradient clipping and differential privacy noise injection on the intermediate results of the model, and obtain the update vector;

[0022] Step A3: Within the secure environment, synchronously record a contribution accumulator log; this log should contain at least the index position of the sample used in the Merkle commitment tree and its corresponding, pruned gradient summary value.

[0023] Step A4: Based on the data from steps A1 to A3 above, generate cryptographic credentials for verifying the compliance of data use.

[0024] Preferably, step A4 includes:

[0025] The cryptographic digest value of the minimum data declaration, the dataset commitment root, and the version identifier of the consent credential are used as input parameters; at the same time, the prepared private witness parameters include the specific path information for performing the data selection operation in step A1, and the random number seed used for differential privacy noise injection in step A2.

[0026] The input parameters and private witness parameters are submitted to the zero-knowledge proof mechanism Q2 to perform cryptographic calculations and generate a proof of use. Simultaneously, a model update commitment representing the result of this model update is output. The model update commitment and the proof of use together constitute a cryptographic credential used to verify the compliance of data use.

[0027] Preferably, step S4 includes:

[0028] The purpose proof and model update commitment are submitted to the proof verification contract on the consortium blockchain. The contract automatically verifies whether the purpose proof is valid. If the verification is successful, the model update commitments from various data institutions are aggregated to generate a global model commitment.

[0029] Subsequently, the current task identifier, the global model commitment, and the version identifiers of all consent credentials that this task depends on are bound together and written into the consortium blockchain as an immutable audit event. An access token for the task initiator to access the final aggregation result is then generated.

[0030] Preferably, the method for registering retraction events on the consortium blockchain, and for data agencies to locate the contribution of the retracted data, includes:

[0031] When a patient or data subject withdraws their consent certificate or the consent certificate expires, a withdrawal event containing the scope of withdrawal and a timestamp is registered on the consortium blockchain, and a unique withdrawal event identifier is generated.

[0032] Each relevant data institution monitors retraction events and, based on the content of the event, searches and matches them in the local contribution accumulator log to locate the Merkle commitment tree index corresponding to all retracted samples and the gradient contribution summary generated in historical training.

[0033] Preferably, the method for removing the contribution from the original model in a secure environment to generate a new model includes:

[0034] Within a safe environment, based on the located Merkel commitment tree index and gradient contribution summary, the old model parameters are calculated by constructing a reverse gradient update that is opposite to the original update direction, or by applying an influence function to calculate an approximate update amount, thereby obtaining the new model parameters after forgetting.

[0035] Simultaneously, the correlation proof between the old model commitment, the withdrawal set commitment consisting of the withdrawn sample set, and the new model commitment is calculated.

[0036] Preferably, the method for generating a forgetting proof to verify whether the forgetting operation was performed correctly includes:

[0037] The old model commitment, the withdrawal event identifier, and the new model commitment are used as input parameters; the prepared private witness parameters include the calculation process and intermediate results of the back gradient update or the amount of the function update, as well as the generated proof of the correlation.

[0038] The input parameters and private witness parameters are submitted to the zero-knowledge proof mechanism Q1, which performs cryptographic computations based on predefined forgetting verification rules and outputs a forgetting proof.

[0039] Preferably, step S6 includes:

[0040] The forgetting proof is submitted to the proof verification contract on the consortium blockchain for verification; after the verification is successful, the new model commitment is registered on the consortium blockchain and the old model commitment that was replaced is marked as invalid; at the same time, the status of all unexpired access tokens is checked and any access token that depends on the withdrawn consent certificate is marked as unavailable.

[0041] The technical effects and advantages of this invention's distributed medical data security sharing method based on blockchain and AI:

[0042] Through the minimum data declaration mechanism, the task party must clearly declare the specific fields and sample range required, which fundamentally prevents excessive data collection. Each data agency performs precise data slicing locally and only provides data within the declared range, realizing on-demand provision rather than full openness.

[0043] By using zero-knowledge proof technology to generate proof of use, cryptographically verifying whether the use of data fully complies with the declared scope and purpose, and through a forgetting proof mechanism, providing machine-verifiable evidence for model updates after data withdrawal, the problem of unverifiable retraining in traditional schemes is solved.

[0044] When a patient withdraws consent, the system can quickly locate the contribution of that data across all historical tasks, avoid the high cost of retraining the entire model through precise reverse update calculations, automatically clean up related access tokens, and ensure that the withdrawal operation takes effect immediately.

[0045] As an immutable auditing layer, blockchain records the commitments and proofs of all key operations. Participants do not need to trust each other; they can be assured of the compliance of each other's behavior through cryptographic proof. Smart contracts automatically execute verification logic, eliminating human intervention and potential disputes.

[0046] Sensitive computations are performed within a secure environment (TEE) where the original data remains within the domain. Differential privacy technology provides strict mathematical privacy guarantees for the output results, ensuring the statistical utility of the aggregated results while protecting individual privacy. The entire process, from data preparation and task declaration to computation result aggregation, is auditable, and the contribution of each data sample can be precisely located through Merkle tree indexing. Attached Figure Description

[0047] Figure 1 This is a schematic diagram of the distributed medical data security sharing method based on blockchain and AI according to the present invention;

[0048] Figure 2 This is a schematic diagram of the method of performing computing tasks in a secure environment according to the present invention. Detailed Implementation

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

[0050] Please see Figure 1 and Figure 2 In this embodiment of the invention, a method for securely sharing distributed medical data based on blockchain and AI includes:

[0051] Step S1: Deploy the core smart contract on the consortium blockchain. Each data institution constructs a cryptographic commitment to the local medical data, compiles the patient's consent into a consent certificate, and registers the cryptographic commitment and consent certificate on the consortium blockchain. The registration here does not refer to storing the original data itself (because the data volume is too large and involves privacy), but rather that the data institution initiates a transaction with the data's "commitment" or "fingerprint" and key "metadata". After the node verifies the transaction, it packages it into a new block. From then on, this cryptographic commitment or consent certificate is permanently and immutably recorded on the chain.

[0052] Step S2: The task initiator generates a task description and a minimal data declaration, and registers the task identifier and the cryptographic digest value of the minimal data declaration on the consortium blockchain;

[0053] Step S3: Based on the minimum data declaration and consent certificate, the data agency extracts a compliant data subset from local data, performs computational tasks in a secure environment, and generates cryptographic credentials for verifying the compliance of data use.

[0054] Step S4: Submit the cryptographic credentials to the consortium blockchain for verification. After successful verification, aggregate the calculation results from all parties and generate an access token.

[0055] Step S5: When the consent certificate is withdrawn or expires, the withdrawal event is registered on the consortium blockchain. The data agency locates the contribution of the withdrawn data, removes the contribution from the original model in a secure environment to generate a new model, and generates a forgetting proof to verify whether the forgetting operation was executed correctly.

[0056] Step S6: Submit the forget proof to the consortium blockchain for verification. After successful verification, update the model state and clean up access tokens that conflict with the revocation event.

[0057] In existing technologies, data sharing lacks reliable commitment mechanisms and patient consent management, failing to ensure the transparency and immutability of data usage, especially when patients withdraw their consent, making it impossible to trace and verify the history of data usage. This results in audits being limited to "who accessed what," but failing to address the issue of data "melting" within the model (i.e., data influence being incorporated into model parameters).

[0058] The core smart contract includes a strategy contract and a proof verification contract. The strategy contract manages the data usage policy, defining "who can use what data, under what conditions, and what actions to take." For example, only task participants holding a "diabetes research" type license can request data containing a "blood sugar" field; when a task initiator submits a task description, the strategy contract checks whether its claims conform to these preset rules. The proof verification contract has a built-in cryptographic verification algorithm to verify cryptographic proofs, that is, to verify the validity of submitted "proof of use" or "proof of forgetting." For example, when a proof is received, the algorithm is run based on the public input (such as a data commitment root), and the output is either "true" or "false." If it is "true," it indicates that the other party has indeed correctly performed the calculation according to the claimed rules, without needing to know the specific details of the calculation, providing a verifiable foundation of trust.

[0059] Each data institution (referring to all entities participating in this distributed medical data sharing network and holding medical data, such as hospitals at all levels, medical research centers, disease control centers, medical insurance institutions, and pharmaceutical R&D departments, etc.) constructs a Merkle commitment tree for its local medical dataset (referring to the distributed raw data set stored within each data institution and not shared). It then calculates the root hash value as the dataset commitment root, forming the cryptographic commitment. Specifically, the local medical dataset is structured, for example, each patient's data record is treated as a data unit. A cryptographic hash value (such as SHA-256) is calculated for each data record. These hash values ​​serve as leaf nodes in the Merkle tree. The hash values ​​of two adjacent leaf nodes are concatenated to calculate a new hash value, which becomes their parent node. This process is repeated, concatenating and hashing the hash values ​​of adjacent parent nodes to generate higher-level parent nodes, recursively upwards until only a single top-level root node remains. The hash value of this root node is the dataset commitment root.

[0060] Example: Suppose there are 4 records with hash values ​​Ha, Hb, Hc, and Hd.

[0061] First layer: Hab = Hash(Ha + Hb), Hcd = Hash(Hc + Hd).

[0062] Root layer: Hroot = Hash(Hab + Hcd).

[0063] Hroot is the commitment root of this dataset. The technical advantage here is that if you want to prove that a certain piece of data (such as the data corresponding to Ha) is indeed included in this dataset, you only need to provide Hb and Hcd (i.e., the Merkel proof path) to verify whether the path Ha→Hab→Hroot is correct through calculation, without needing to know any other data in the dataset.

[0064] For patient-authorized data, a consent compilation process is used to transform it into a digital consent certificate with a unique identifier, and the version identifier of this consent certificate is registered on the consortium blockchain. The purpose of this step is to transform the legal and textual "patient consent" into machine-executable and verifiable instructions. This involves extracting key elements from the patient's natural language consent form, converting it into a machine-readable format (such as JSON), and then digitally signing it (using the patient's private key or a certificate issued by a trusted third party) to generate a tamper-proof digital consent certificate. This certificate itself will have a unique identifier (CID), which is the version identifier.

[0065] A consortium blockchain is a permissioned blockchain. Unlike public blockchains like Bitcoin and Ethereum, where anyone can join, participants in a consortium blockchain are typically pre-screened entities (such as multiple hospitals, research institutions, or regulatory bodies). It is jointly maintained by the consortium members, combining the distributed trust of public blockchains with the efficiency and privacy controls of private blockchains. In the medical data sharing scenario designed in this paper, the consortium blockchain ensures that only authorized institutions can participate, while guaranteeing the transparency and immutability of the operational process.

[0066] The process of deploying core smart contracts on a consortium blockchain involves the following steps: Technical personnel (typically the initiator or technology provider of the consortium) write code for the strategy contract and proof verification contract using a blockchain programming language (such as Solidity for Ethereum). An account with deployment permissions sends the compiled contract code as a "transaction" to the consortium blockchain network. After the on-chain nodes (nodes run by various data institutions) verify the transaction, they record the contract code in a block and generate a unique contract address. Subsequently, all participants can use this address to invoke the functions defined in the contract.

[0067] By deploying core smart contracts (policy contracts and proof verification contracts), automated management of data usage policies and verification of cryptographic proofs were achieved, improving the system's transparency and auditability. A Merkel commitment tree was used to construct the dataset commitment root, ensuring the integrity and non-repudiation of local medical data and facilitating subsequent verification and handling of forgotten data. Patient consent was transformed into digital consent credentials and registered with version identifiers on the consortium blockchain, resolving the dynamic nature of consent management, supporting the traceability of withdrawal events, and reducing the cost of retraining (because contributions can be selectively removed rather than retraining the entire system). The data sharing process was ensured to comply with regulatory requirements.

[0068] The lack of precise task definition and data minimization principles at the time of task initiation leads to a high risk of data overuse or privacy breaches. It also exacerbates the difficulty of forgetting tasks after consent has been withdrawn, as tasks may involve excessive data, making it impossible to accurately track the impact.

[0069] The task description is a file containing the task purpose and task type. After being submitted to the consortium blockchain, a unique task identifier is generated either off-chain or on-chain (automatically generated by the smart contract when it receives the task and creates a transaction).

[0070] The minimum data declaration is generated locally by the task initiator and includes at least the set of field names required by the task (e.g., if the required field names include fasting blood glucose, glycated hemoglobin, age, and body mass index, then name and address cannot be provided), denoted as the field set; a Boolean predicate condition for filtering qualified samples (here, a sample refers to a set of patient data), denoted as the sample selection predicate; and differential privacy budget parameters (e.g., using a Gaussian mechanism, the privacy budget is (ε=0.7, δ=1e-5), where ε and δ are both parameters in the Gaussian mechanism used to limit the total amount of privacy information that can be obtained in this task), denoted as the privacy parameter;

[0071] Register the task identifier and the cryptographic digest value of the minimal data declaration (calculate the hash of the minimal data declaration using SHA-256 and use the output string as the cryptographic digest value) on the consortium blockchain.

[0072] By generating a unique task identifier and a minimal data manifesto (including field set, sample selection predicate, and privacy parameters), data minimization is achieved, ensuring that only necessary subsets of data are extracted and reducing privacy risks.

[0073] Registering the task identifier and the cryptographic digest value of the minimal data declaration on the consortium blockchain provides an immutable audit log, facilitating subsequent verification of task compliance and data contribution tracking. It reduces the complexity of forgetting when withdrawing consent (because privacy parameters help quantify data impact). Unnecessary data processing is avoided, indirectly reducing overall computational costs.

[0074] When extracting and performing computations from local data, existing technologies cannot ensure the compliance of data subsets (i.e., compliance with patient consent and task requirements), leading to potential privacy violations, especially in distributed environments where it is difficult to verify data usage. This relates to the problem in the background technology of "inability to verify whether retracted data was forgotten in the model."

[0075] The method for extracting a compliant subset of data from local data and performing computational tasks in a secure environment includes:

[0076] Step A1: The data agency parses the minimal data declaration, uses the sample selection predicate and field set as query conditions, and combines them with the currently effective consent credentials to execute the query on the locally constructed Merkel commitment tree; it then filters out specific samples and fields that simultaneously meet the declaration conditions and the patient's authorization status, forming a compliant field-sample subset.

[0077] Step A2: Load the field-sample subset into a secure environment and execute the task on the predefined model. The predefined model is the core business object for patient data sharing and processing, which is the AI ​​diagnostic model training mentioned in the background technology; calculate the model gradient on this subset and use it as an intermediate result; then, perform gradient pruning and differential privacy noise injection operations on the intermediate result of the model in sequence to obtain a secure model update vector.

[0078] Step A3: Within the secure environment, synchronously record a contribution accumulator log; this log should contain at least the index position of the sample used in the Merkle commitment tree and its corresponding, pruned gradient summary value.

[0079] Step A4: Based on the data from steps A1 to A3 above, generate cryptographic credentials to verify the compliance of data use, and to verify that all operations are correctly based on the minimum data declaration and consent credentials registered on the chain.

[0080] For example: Suppose Huashan Hospital, in collaboration with multiple hospitals, trains an AI diagnostic model for diabetic retinopathy (DR). The minimum data declaration includes a set of fields [patient anonymous ID, diagnosis result, fundus image feature vector], a sample selection predicate (diagnosis result: DR or diagnosis result: healthy), privacy parameters (ε=1.0, δ=1e-5), and consent credentials: credentials of patients P1, P2, P3, and P4, which record whether the patients authorize their data to be used for "ophthalmic AI model research".

[0081] Suppose that Huashan Hospital's local database (the leaf nodes of its Merkel commitment tree) contains the following four patient records:

[0082]

[0083] Then, in step A1: Huashan Hospital's system parses the minimum data declaration, applies predicates to filter out patients P1 (diabetic retinopathy), P3 (healthy), and P4 (diabetic retinopathy), and excludes P2 (glaucoma). Check that P1 (authorized) and P4 (authorized) meet the criteria, and exclude P3 (unauthorized). For the final P1 and P4 that meet the criteria, only the three authorized fields [Patient Anonymous ID, Diagnosis Result, Fundus Photograph Feature Vector] are retained, and undeclared fields such as contact information are filtered out. The output field-sample subset is then used.

[0084] Step A2: Load the field-sample subset into the secure environment (TEE), obtain the parameters of the currently shared diabetic retinopathy AI diagnostic model, use the data from P1 and P4 to calculate the loss between the model prediction and the true label (diagnosis result), and then calculate the model gradient (i.e. the original gradient vector) through backpropagation. This is the intermediate result, which contains information from the original data.

[0085] The L2 norm of the original gradient vector is calculated, assuming it to be 5.6. The system's preset pruning threshold is 3.0. Since 5.6 > 3.0, the system scales down the gradient vector proportionally, resulting in a pruned gradient vector = original gradient vector × (3.0 ÷ 5.6), which limits the maximum impact of any sample in a single update.

[0086] A noise vector is randomly sampled from a Gaussian distribution that satisfies the privacy parameters (ε=1.0, δ=1e-5), and added to the clipped gradient vector to output a safe model update vector, which is a noisy gradient vector, such as [0.024, -0.156, ..., 0.078]. After privacy processing, this vector can be safely sent out.

[0087] Step A3: Inside the TEE, the system creates a log for this calculation and outputs (Contribution Accumulator Log). This log is key to the next step of implementing "verifiable forgetting".

[0088] Step A4: Based on all the above steps, prove that: "I (Huashan Hospital) correctly executed the query required by the minimum data digest on the Merkel root dataset, based on the consent credentials, and calculated the gradient in the TEE for the resulting P1 and P4 data, adding noise strictly according to the parameter ε=1.0, ultimately obtaining the secure model update vector." Output a cryptographic proof document. Anyone (or on-chain contract) who obtains this proof document can verify that the above statement is true without knowing the specific data of P1 and P4, the original gradient calculated, or the specific noise added.

[0089] By parsing the minimal data manifesto and combining it with consent credentials, queries are performed on the Merkel commitment tree to form a compliant field-sample subset, ensuring the accuracy and compliance of data extraction. Tasks, including gradient pruning and differential privacy noise injection, are executed in a secure environment to generate update vectors and contribution accumulator logs, achieving traceability of data contributions and facilitating subsequent forgetting operations. Recording sample indices and gradient summary values ​​supports precise location of contributions to retracted data, avoiding the inefficiency of retraining in the background. This reduces the risk of data leakage and provides foundational data for zero-knowledge proofs.

[0090] Current technologies lack verifiable cryptographic credentials to prove the compliance of data use, especially in distributed AI training, where it is impossible to mechanically verify whether only authorized data was used. This results in the inability to provide "forgotten credentials" after consent is withdrawn, making it difficult for patients and auditors to trust the forgetting process.

[0091] Step A4 includes:

[0092] The cryptographic digest value of the minimum data declaration registered on the consortium blockchain, the dataset commitment root, and the version identifier of the consent credential used as input parameters are used. Meanwhile, the prepared private witness parameters include the specific path information for performing the data selection operation in step A1, and the random number seed used for differential privacy noise injection in step A2.

[0093] The input parameters and private witness parameters are submitted to the zero-knowledge proof mechanism Q2. This mechanism performs cryptographic computations based on predefined verification rules to generate a proof of use. The verification rules prove that the data selection operation correctly selects a subset of data that simultaneously satisfies the minimal data declaration and consent credential constraints, and that the secure cryptographic computation process strictly follows the privacy parameters declared in the declaration. A model update commitment representing the result of this model update is output simultaneously (the model update commitment is a cryptographic credential, a short data generated by the zero-knowledge proof mechanism Q2, usually a hash value, serving as a digital fingerprint of the "model update vector" that is immutable and hidden). The model update commitment and the proof of use together constitute a cryptographic credential used to verify the compliance of data use.

[0094] The Q2 zero-knowledge proof mechanism is used to generate proofs of use and commitments to model updates, ensuring the verifiability of data use compliance (such as minimal data declarations and consent credentials) without revealing private details. Efficient proof generation is achieved by using cryptographic digest values, dataset commitment roots, and consent credential versions as inputs, combined with private witness parameters (such as path information and random seeds). Machine-verifiable credentials are provided, addressing the problem of "inability to prove forgetting to patients" in the prior art, thus enhancing the system's credibility and auditability.

[0095] When aggregating calculation results, existing technologies cannot automatically verify the compliance of contributions from all parties, resulting in the final model potentially containing unauthorized data and lacking an auditable record of unalterable events. This exacerbates the problem of forgetting to verify after consent has been withdrawn.

[0096] Step S4 includes:

[0097] The purpose proof and model update commitment are submitted to the proof verification contract on the consortium blockchain. The contract automatically verifies whether the purpose proof is valid. If the verification is successful, the model update commitments from various data institutions are aggregated to generate a global model commitment.

[0098] Subsequently, the strategy contract or a dedicated audit log contract is invoked to bind the current task identifier, the global model commitment, and the version identifiers of all consent credentials that this task depends on, and write them into the consortium blockchain as an immutable audit event, and generate an access token for the task initiator to access the final aggregation result.

[0099] The method by which the proof verification contract automatically verifies the validity of a purpose proof includes: the proof verification contract has a pre-built verification algorithm that matches the zero-knowledge proof mechanism Q3 used when generating the proof. The contract runs this algorithm, taking the purpose proof and common input parameters as input for computation. If the computation output is true, the proof data agency has indeed correctly performed the operation, and the verification passes; if the output is false, at least one step in the proof operation has not been correctly performed, and the verification fails.

[0100] Methods for aggregating model update commitments from various data agencies include collecting all verified model update commitments submitted by all data agencies participating in this task, forming a list, and using the hash value of this list as the "global model commitment," or adding the model update commitments of various data agencies together and selecting based on actual production needs.

[0101] The system automatically verifies proofs of purpose by verifying contracts and aggregates model update commitments to generate global model commitments, ensuring the compliance and integrity of the aggregation process. Task identifiers, global model commitments, and consent credential versions are bound as audit events and written to the consortium blockchain, providing permanent and immutable records for easy traceability and verification of forgotten information. Access tokens are generated to support secure access to the final result and provide a basis for retraction events (facilitating dependency checks). This improves system efficiency and security, addresses the issue of insufficient audit logs in the background, and enables verifiable model state management.

[0102] When patients withdraw their consent, existing technologies are unable to efficiently register and locate the affected data contributions, leading to forgotten procedures relying on costly retraining and lacking automation mechanisms.

[0103] The method for registering retraction events on the consortium blockchain, and for data agencies to locate the contribution of the retracted data, includes:

[0104] When a patient or data subject withdraws their consent certificate through a client or when the consent certificate expires, a withdrawal event containing the withdrawal scope and timestamp is registered on the consortium blockchain, and a unique withdrawal event identifier is generated using the transaction hash.

[0105] Each relevant data institution monitors retraction events and, based on the event content, searches and matches them in its local contribution accumulator log to locate the Merkle commitment tree index corresponding to all retracted samples and their gradient contribution summaries generated during historical training. It should be noted that the contribution accumulator log is a structured database, illustrated with the following example:

[0106] Assume the core fields of the contribution accumulator log (generated within the TEE) are as follows:

[0107]

[0108] The data agency's system listens for withdrawal events on the blockchain. Assuming the event content is (withdrawal of consent certificate consent_v1_pid_123), it executes a database-like query command in the local contribution accumulator log, and the query engine quickly finds all matching records.

[0109] Based on the table above, it will locate two records:

[0110] (Task: task_abc, Index: 0, Gradient Summary: a1b2...);

[0111] (Task: task_def, Index: 0, Gradient Summary: e5f6...);

[0112] The system thus accurately determined that patient pid_123's data contributed to the two historical tasks, task_abc and task_def.

[0113] This process enables precise querying through blockchain event-driven and local structured logs, automatically and accurately identifying data footprints that need to be forgotten, providing clear input for subsequent computation.

[0114] Registering retraction events (including scope and timestamp) on the consortium blockchain generates a unique identifier, ensuring transparency and real-time processing of retractions. Data agencies monitor events and search for matches in the contribution accumulator log to precisely locate the index and gradient contribution summary of the retracted sample, avoiding the inefficiency of global search. It supports automated responses in distributed environments, reducing the computational cost of forgetting operations (without retraining the entire model). This provides a precise foundation for subsequent contribution removal, addressing the high cost of retraining in the background technologies.

[0115] When removing withdrawn data contributions from AI models, existing techniques rely on "retraining" or "empirical ablation," which is costly and impractical, especially when patients frequently withdraw data. This fails to address the core issue of data influencing parameters already "integrated" into the model.

[0116] The method for removing the contribution from the original model in a secure environment to generate a new model includes:

[0117] Within a secure environment, based on the located Merkel commitment tree index and gradient contribution summary, the old model commitments that need to be forgotten and their corresponding old model parameters are obtained from the consortium blockchain.

[0118] The old model parameters, Merkel commitment tree index, and gradient contribution summary are loaded into a safe environment. By constructing a reverse gradient update that is opposite to the original update direction, or by applying an influence function to calculate an approximate update amount, the old model parameters are calculated to eliminate the influence of the withdrawn data, thereby directly obtaining the new model parameters after forgetting.

[0119] Specifically, this involves constructing a reverse gradient update in the opposite direction to the original update. The principle is that in machine learning, models learn through gradient descent. A data point's "contribution" to the model is reflected in its resulting gradient g_i. This gradient g_i tells the model which direction to adjust its parameters to better fit the data. Therefore, since the model initially learned the data by adding this gradient g_i, the most direct way to forget it is to subtract its influence. Thus, by setting a learning rate η identical to the original model training, calculating the reverse update amount Δ = -η × g_i, and applying this reverse update to the old model parameters (new model parameters = old model parameters + Δ), the model moves a small step in the exact opposite direction to when it learned the data, thereby forgetting what the sample taught.

[0120] The approximate update amount is calculated by applying the influence function by analyzing the second derivative (Hessian matrix) of the old model and the loss function to approximate the impact of the data on the current model parameters, and then the same process is repeated.

[0121] Simultaneously, based on the obtained new model parameters, its cryptographic hash value is calculated as the new model commitment; at the same time, the commitment of the revoked sample set is calculated as the revocation set commitment, and a proof of the association between the old model commitment, the revocation set commitment, and the new model commitment is generated. This proof of association is not a recalculation of the commitments, but rather the generation of a proof demonstrating that the transition from the old model commitment to the new model commitment is legitimate and correct—that is, the transition is solely due to the removal of authorized revocation samples. In effect, it refers to generating a zero-knowledge proof, that is, binding the three commitments together through the zero-knowledge proof mechanism Q1 to form an undeniable chain of evidence.

[0122] In a secure environment, backward gradient updates or influence functions are used to calculate the removal contribution, generating new model parameters and achieving precise "machine forgetting" rather than overall retraining. Cryptographic relationships are calculated between the old model commitment, the withdrawal set commitment, and the new model commitment to ensure the integrity and verifiability of the forgetting operation. This significantly reduces computational costs (targeted removal rather than retraining) and is suitable for high-frequency withdrawal scenarios.

[0123] Existing technologies cannot generate machine-verifiable "proof of forgetting," which makes it difficult for patients and auditors to confirm that retracted data has been removed from the model, resulting in low trust levels.

[0124] The method for generating cryptographic forget proofs to verify whether the forget operation was executed correctly includes:

[0125] A forgetting proof is constructed using a zero-knowledge proof mechanism. The old model commitment, the withdrawal event identifier, and the new model commitment are used as input parameters. The prepared private witness parameters include the calculation process and intermediate results of the back gradient update or the update of the influencing function, as well as the generated correlation proof.

[0126] The input parameters and private witness parameters are submitted to the zero-knowledge proof mechanism Q1, which performs cryptographic computation based on a predefined forgetting verification rule. The forgetting verification rule is used to prove that the new model parameters corresponding to the new model commitment are obtained by strictly removing the sample contribution authorized by the revocation event identifier from the old model parameters corresponding to the old model commitment in accordance with the forgetting rule.

[0127] The zero-knowledge proof mechanism Q1 outputs a forgetting proof, which is the final cryptographic credential verifying that the forgetting operation was executed correctly.

[0128] The zero-knowledge proof mechanisms Q1, Q2, and Q3 mentioned above are all based on the existing zero-knowledge proof system operation mechanism, only the predefined verification rules, inputs, and outputs are different.

[0129] The Q1 zero-knowledge proof mechanism generates forgetting proofs, using old or new model commitments and retraction event identifiers as inputs, combined with private witness parameters, to ensure the correctness and verifiability of forgetting operations. Cryptographic computations are performed based on predefined forgetting verification rules, outputting proofs without revealing sensitive details. This addresses the background issue of "inability to prove that the new model does not contain unconsented information," enhancing the system's auditability and user trust.

[0130] Step S6 includes:

[0131] The forgetting proof is submitted to the proof verification contract on the consortium blockchain for on-chain verification (by constructing a blockchain transaction that calls a specific verification method in the proof verification contract; the proof verification contract has a pre-built verification algorithm identical to that used when generating the forgetting proof, outputting a binary verification result; if the new model is indeed obtained by legally removing the specified data contribution from the old model, and the forgetting proof operation was indeed executed correctly, then the verification passes; otherwise, the verification fails). After successful verification, the new model commitment is registered on the consortium blockchain, and the replaced old model commitment is marked as expired. Simultaneously, backtracking to the audit event recorded in step S4, the status of all unexpired access tokens is checked, and all access tokens with a valid status are queried. The criteria for validity are that the associated model commitment equals the currently replaced old model commitment and the list of dependent consent credentials contains the version identifier of the revoked consent credential.

[0132] Mark any access token that relies on withdrawn consent credentials as unavailable to prevent subsequent unauthorized access.

[0133] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0134] It should be noted that all formulas in this manual are calculated by removing dimensions and taking their numerical values. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0135] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

Claims

1. A distributed medical data security sharing method based on blockchain and AI, characterized in that, include: Step S1: Deploy the core smart contract on the consortium blockchain. Each data institution constructs a cryptographic commitment for local medical data, compiles the patient's consent into a consent certificate, and registers the cryptographic commitment and consent certificate on the consortium blockchain. Step S2: The task initiator generates a task description and a minimal data declaration, and registers the task identifier and the cryptographic digest value of the minimal data declaration on the consortium blockchain; The minimum data declaration is generated locally by the task initiator and includes at least the set of field names required by the task, denoted as the field set; the Boolean predicate conditions used to filter qualified samples, denoted as the sample selection predicate; and the differential privacy budget parameters, denoted as the privacy parameters. Step S3: Based on the minimum data declaration and consent certificate, the data agency extracts a compliant data subset from local data, performs computational tasks in a secure environment, and generates cryptographic credentials for verifying the compliance of data use. Step S4: Submit the cryptographic credentials to the consortium blockchain for verification. After successful verification, aggregate the calculation results from all parties and generate an access token. Step S5: When the consent certificate is withdrawn or expires, the withdrawal event is registered on the consortium blockchain. The data agency locates the contribution of the withdrawn data, removes the contribution from the original model in a secure environment to generate a new model, and generates a forgetting proof to verify whether the forgetting operation was executed correctly. Step S6: Submit the forget proof to the consortium blockchain for verification. After successful verification, update the model state and clean up access tokens that conflict with the revocation event.

2. The distributed medical data secure sharing method based on blockchain and AI according to claim 1, characterized in that, The core smart contract includes a strategy contract and a proof verification contract. The strategy contract is used to manage the data usage strategy, and the proof verification contract is used to verify the cryptographic proof. Each data institution constructs a Merkel commitment tree for its local medical dataset and calculates its root hash value as the dataset commitment root, thus forming the construction of cryptographic commitment. For patient-authorized data, the consent compilation process converts it into a digital consent certificate with a unique identifier, and the version identifier of the consent certificate is registered on the consortium blockchain.

3. The distributed medical data secure sharing method based on blockchain and AI according to claim 2, characterized in that, The task description is a file containing the task objective and task type, which is submitted to the consortium blockchain. Generate a unique task identifier; Register the task identifier and the cryptographic digest value of the minimal data declaration on the consortium blockchain.

4. The distributed medical data secure sharing method based on blockchain and AI according to claim 3, characterized in that, The method for extracting a compliant subset of data from local data and performing computational tasks in a secure environment includes: Step A1: The data agency parses the minimal data declaration, uses the sample selection predicate and field set as query conditions, and combines them with the currently effective consent credentials to execute the query on the Merkel commitment tree; it then filters out specific samples and fields that simultaneously meet the declaration conditions and the patient's authorization status, forming a compliant field-sample subset. Step A2: Load the field-sample subset into the secure environment, execute the task on the predefined model, perform gradient clipping and differential privacy noise injection on the intermediate results of the model, and obtain the update vector; Step A3: Within the secure environment, synchronously record a contribution accumulator log; this log should contain at least the index position of the sample used in the Merkle commitment tree and its corresponding, pruned gradient summary value. Step A4: Based on the data from steps A1 to A3 above, generate cryptographic credentials for verifying the compliance of data usage.

5. The distributed medical data secure sharing method based on blockchain and AI according to claim 4, characterized in that, Step A4 includes: The cryptographic digest value of the minimum data declaration, the dataset commitment root, and the version identifier of the consent credential are used as input parameters; at the same time, the prepared private witness parameters include the specific path information for performing the data selection operation in step A1, and the random number seed used for differential privacy noise injection in step A2. The input parameters and private witness parameters are submitted to the zero-knowledge proof mechanism Q2 to perform cryptographic calculations and generate a proof of use. Simultaneously, a model update commitment representing the result of this model update is output. The model update commitment and the proof of use together constitute a cryptographic credential used to verify the compliance of data use.

6. The distributed medical data secure sharing method based on blockchain and AI according to claim 5, characterized in that, Step S4 includes: The purpose proof and model update commitment are submitted to the proof verification contract on the consortium blockchain. The contract automatically verifies whether the purpose proof is valid. If the verification is successful, it aggregates the model update commitments from various data institutions to generate a global model commitment. Subsequently, the current task identifier, the global model commitment, and the version identifiers of all consent credentials that this task depends on are bound together and written into the consortium blockchain as an immutable audit event. An access token for the task initiator to access the final aggregation result is then generated.

7. The distributed medical data secure sharing method based on blockchain and AI according to claim 6, characterized in that, The method for registering retraction events on the consortium blockchain, and for data agencies to locate the contribution of the retracted data, includes: When a patient or data subject withdraws their consent certificate or the consent certificate expires, a withdrawal event containing the scope of withdrawal and a timestamp is registered on the consortium blockchain, and a unique withdrawal event identifier is generated. Each relevant data institution monitors retraction events and, based on the content of the event, searches and matches them in the local contribution accumulator log to locate the Merkle commitment tree index corresponding to all retracted samples and the gradient contribution summary generated in historical training.

8. The distributed medical data secure sharing method based on blockchain and AI according to claim 7, characterized in that, The method for removing the contribution from the original model in a secure environment to generate a new model includes: Within a safe environment, based on the located Merkel commitment tree index and gradient contribution summary, the old model parameters are calculated by constructing a reverse gradient update that is opposite to the original update direction, or by applying an influence function to calculate an approximate update amount, thereby obtaining the new model parameters after forgetting. Simultaneously, the correlation proof between the old model commitment, the withdrawal set commitment consisting of the withdrawn sample set, and the new model commitment is calculated.

9. The distributed medical data secure sharing method based on blockchain and AI according to claim 8, characterized in that, The method for generating a forgetting proof to verify whether the forgetting operation was executed correctly includes: The old model commitment, the withdrawal event identifier, and the new model commitment are used as input parameters; the prepared private witness parameters include the calculation process and intermediate results of the back gradient update or the amount of the function update, as well as the generated proof of the correlation. The input parameters and private witness parameters are submitted to the zero-knowledge proof mechanism Q1, which performs cryptographic computations based on predefined forgetting verification rules and outputs a forgetting proof.

10. The distributed medical data secure sharing method based on blockchain and AI according to claim 9, characterized in that, Step S6 includes: The forgetting proof is submitted to the proof verification contract on the consortium blockchain for verification; after the verification is successful, the new model commitment is registered on the consortium blockchain and the old model commitment that was replaced is marked as invalid; at the same time, the status of all unexpired access tokens is checked and any access token that depends on the withdrawn consent certificate is marked as unavailable.

Images