A blockchain-based differential privacy protection method for electronic health records

Abstract

This application discloses a blockchain-based differential privacy protection method for electronic health records. Belonging to the field of differential privacy protection technology, this solution constructs a decentralized trust execution environment based on blockchain and cryptography, enabling multiple medical institutions to securely collaborate without completely trusting any central party. Through smart contracts, it automates the allocation of fair privacy resources and process coordination, guiding participating nodes to locally add noise to sensitive health records to meet differential privacy requirements and generate verifiable commitments. Using homomorphic encryption and zero-knowledge proof technology, it completes verifiable and secure aggregation of data in encrypted form. Finally, through collaborative decryption, it obtains a globally statistical result with strict privacy protection. The entire process achieves precise calculation of privacy consumption and real-time on-chain settlement, generating an immutable, end-to-end audit evidence chain. Thus, while ensuring compliance with personal privacy regulations, it effectively releases the research value of dispersed medical data.

Description

Technical Field

[0001] This invention relates to the field of differential privacy protection technology, specifically a blockchain-based differential privacy protection method for electronic health records. Background Technology

[0002] In the healthcare field, establishing regional or specialized medical consortia has become an important model for improving overall diagnostic and treatment levels and research capabilities. Within these consortia, the core prerequisite for conducting high-quality clinical research, such as efficacy comparisons for specific diseases, epidemiological analyses, or safety and efficacy evaluations of new drugs, lies in the safe and compliant aggregation and analysis of electronic health records held by member hospitals. However, this scenario faces multiple practical constraints. First, the information systems of different hospitals differ significantly in data formats, structural standards, and storage methods, forming a natural technical barrier. Second, electronic health records contain a large amount of sensitive personal information, and their management is subject to strict regulations such as the Personal Information Protection Law. The regulations impose compliance requirements on data sharing and use, stipulating that data should be "usable but not visible." In addition, while there is an inherent motivation among medical institutions within the consortium to promote scientific research collaboration through data sharing, there are also implicit concerns about data protection and ownership due to factors such as academic competition and patient resources. These internal factors and external regulatory pressures are intertwined, making the traditional path of directly exchanging or aggregating original patient data legally and ethically unfeasible. Furthermore, traditional anonymization or obfuscation techniques have been proven to be unable to resist complex re-identification attacks and cannot provide provable privacy guarantees. As a result, medical consortia are generally trapped in the "data silo" dilemma, which seriously restricts the progress of research based on multi-center real-world data.

[0003] To address these challenges, differential privacy technology has garnered significant attention due to its ability to provide strict and quantifiable privacy boundaries. However, existing solutions exhibit significant drawbacks when applied to collaborative computing of cross-institutional medical data. Centralized differential privacy models require a trusted data aggregator that collects raw data from all parties and uniformly adds noise. This is impractical in consortia composed of multiple equal and autonomous medical institutions, as no single institution can be unconditionally trusted by other members as a data intermediary. On the other hand, while localized differential privacy models eliminate the dependence on a trusted central node, allowing participants to perturb their data locally before uploading, the amount of noise injected to ensure strong privacy is enormous. In a distributed environment, achieving acceptable levels of noise becomes problematic. The statistical precision required by these studies far exceeds the sample size of centralized models. For medical consortia, which typically have limited single-point data, this often leads to a sharp decline in the utility of the final analysis results, making them unsuitable for research needs. Therefore, the current state of technology in the specific scenario of medical consortia reveals a core contradiction: how to design a collaborative computing framework that enables multiple data holders to jointly complete high-value data analysis tasks while protecting their respective data privacy, in the absence of a trusted third party. Specifically, this involves how to accurately coordinate and manage the allocation and consumption of the global privacy budget under a distributed architecture, and achieve a better balance between privacy and utility than a purely localized model, thereby meeting the dual rigid requirements of cross-institutional clinical research for data security and result accuracy. Summary of the Invention

[0004] The purpose of this invention is to provide a blockchain-based differential privacy protection method for electronic health records. It constructs a decentralized medical data collaborative computing framework and achieves automatic process coordination, verifiable privacy protection and secure aggregation through blockchain and cryptographic technologies. Under the premise of ensuring strict compliance, it produces credible statistical results and generates a complete audit chain, thereby releasing the scientific research value of dispersed data and solving the problems mentioned in the background technology.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A blockchain-based differential privacy protection method for electronic health records includes the following steps: Step S1: In response to a research request for the target research task, within a smart contract deployed in the permissioned blockchain network, based on the global privacy loss budget declared in the research request, the list of participating nodes, and the predefined allocation strategy, an initial node privacy budget is calculated and allocated for each participating node in the list of participating nodes, and this value is recorded as the initial node privacy budget for each participating node; the research request, the global privacy loss budget, the list of participating nodes, and the initial node privacy budget allocated to each participating node are recorded in the smart contract; Step S2: Each participating node calculates the local statistics of its locally stored electronic health record data according to the query function corresponding to the target research task recorded in the smart contract, and adds noise to the local statistics based on the initial node privacy budget allocated to it in step S1 to generate perturbed local statistics; then, the participating node generates a cryptographic commitment to the perturbed local statistics and submits the commitment transaction containing the cryptographic commitment and cryptographic auxiliary information to the smart contract. Step S3: After verifying that all participating nodes have completed the commitment transaction submission, the smart contract triggers the aggregation calculation phase. In the aggregation calculation phase, each participating node encrypts the perturbation local statistics generated in step S2 using a homomorphic encryption algorithm to obtain homomorphic ciphertext, and sends the homomorphic ciphertext to the aggregation node designated by the smart contract. The aggregation node uses the homomorphic property of homomorphic encryption to perform aggregation operations on all received homomorphic ciphertexts to obtain the aggregation result ciphertext, and generates a zero-knowledge proof to prove the correctness of the aggregation operation. The aggregation result ciphertext and the zero-knowledge proof are submitted to the smart contract as an aggregation transaction. Step S4: The smart contract verifies the validity of the zero-knowledge proof in the aggregation transaction. After the verification is passed, it coordinates all participating nodes to collaboratively decrypt the ciphertext of the aggregation result to obtain the final aggregation result that satisfies the global privacy loss budget. At the same time, the smart contract updates the node privacy budget of each participating node recorded in the smart contract according to the actual node privacy budget consumed in this research task to reflect the remaining amount after consumption, and stores the full-process audit information of this research task as an audit log. As a further aspect of the present invention: In step S1, the process of calculating and allocating an initial node privacy budget for each participating node in the participating node list based on the global privacy loss budget declared in the research request, the list of participating nodes, and the predefined allocation strategy is specifically as follows: The global privacy loss budget is set by the research initiator and represents the upper limit of the total privacy resources allowed to be consumed in this research task; the list of participating nodes contains unique identifiers for multiple participating nodes, which have completed access verification of the permissioned blockchain network; the research request also declares the query function corresponding to the target research task; the predefined allocation strategy is calculated based on the node metadata of each participating node, which includes at least the number of valid electronic health records provided by each participating node for the research task, and the data sensitivity score calculated based on the electronic health records provided by it; The allocation strategy performs calculations by constructing a composite weight model based on contribution and risk perception. First, a data contribution weight is calculated for each participating node, which is equal to a first adjustment coefficient multiplied by the proportion of the data provided by this participating node to the total data provided by all participating nodes. Second, a data risk weight is calculated for each participating node, which is equal to a second adjustment coefficient multiplied by the difference between the node's data sensitivity score and the ratio of the node's data sensitivity score to the highest data sensitivity score among all participating nodes. Next, a composite weight is calculated for each participating node, which is equal to the sum of the data contribution weight and the data risk weight of that participating node; the sum of the composite weights of all participating nodes is calculated as a normalization factor; finally, an initial node privacy budget is calculated for each participating node, which is equal to the global privacy loss budget multiplied by the composite weight of that participating node, and then divided by the normalization factor.

[0006] As a further aspect of the present invention: the specific operation of recording the research request, global privacy loss budget, participating node list, and initial node privacy budget allocated to each participating node in the smart contract is as follows: The smart contract creates and maintains a task state record that uniquely corresponds to the target research task in the state store. The task state record is used to persistently store the global privacy loss budget value, the declared query function, and the list of participating nodes contained in the research request, and to create a budget allocation mapping table. The budget allocation mapping table associates and stores the unique identity of each participating node with its calculated initial node privacy budget. After completing the calculation of the initial node privacy budget and the creation of the budget allocation mapping table, the smart contract generates an event log indicating that the state initialization is complete, and waits for more than a preset threshold number of participating nodes from the participating node list to submit digital signature confirmations for the task state record containing the global privacy loss budget, query function, participating node list, and budget allocation mapping table; when a preset threshold number of valid digital signatures are collected, the state of the smart contract is locked.

[0007] As a further aspect of the present invention: the specific process of generating the perturbation local statistics in step S2 is as follows: The participating node listens to the permissioned blockchain network. After confirming that the state of the smart contract in step S1 is locked, it obtains the query function defined by the target research task and the initial node privacy budget allocated to itself from the locked smart contract state. Next, in a local secure environment, participating nodes extract electronic health record data related to the research task from the database and apply query functions to calculate the extracted electronic health record data to obtain undisturbed raw local statistics. Subsequently, based on the obtained initial node privacy budget and the inherent global sensitivity of the query function, participating nodes determine the core scale parameters for noise generation. Based on this, the participating nodes calculate the dispersion measure of the extracted electronic health record data on the dimension targeted by the query function, and obtain the average of the corresponding dispersion measure of all participating nodes; the participating nodes then divide their local dispersion measure by the average, add one to the resulting ratio, take the natural logarithm, and finally add one to the result to obtain the local data feature factor. The participating nodes construct a probability distribution for noise generation based on the initial node privacy budget, the global sensitivity of the query function, and local data feature factors, so that the probability density of the generated noise is proportional to the result of the exponential operation with the natural constant e as the base. Finally, the participating nodes sample a noise from the constructed probability distribution and add the noise to the calculated original local statistic. The result is the perturbation local statistic.

[0008] As a further aspect of the present invention: the specific operation of the participating node generating a cryptographic commitment to the perturbation local statistics and submitting the commitment transaction containing the cryptographic commitment and cryptographic auxiliary information to the smart contract is as follows: After generating the perturbation local statistics, the participating nodes first generate a cryptographically secure random number as the commitment random number. The participating nodes then concatenate the perturbation local statistics and the commitment random number sequentially to form a data string. The data string is then input into a cryptographic hash function for calculation, and the resulting hash output value serves as the cryptographic commitment. Simultaneously, the participating nodes use a pre-obtained public key from the smart contract and a designated recipient to encrypt the commitment random number, generating an encrypted commitment random number, which serves as cryptographic auxiliary information. Each participating node constructs a commitment transaction, which includes a cryptographic commitment and encrypted auxiliary information. Each participating node digitally signs the commitment transaction using its own private key. After the digital signature is completed, the participating nodes broadcast the digitally signed commitment transaction to the permissioned blockchain network; the smart contract receives the commitment transaction, verifies the validity of the digital signature, and records the cryptographic commitment and cryptographic auxiliary information in the smart contract state after the verification is successful.

[0009] As a further aspect of the present invention: in step S3, the process of sending the homomorphic ciphertext to the aggregation node specified by the smart contract specifically involves: The smart contract maintains a task status record corresponding to the target research task. The task status record is used to track and confirm whether the committed transactions from each participating node in the list of participating nodes have been successfully received and verified by digital signature. When the smart contract detects that the task status record shows that the committed transactions of all participating nodes have been verified and recorded, the smart contract automatically transitions its internal state to an aggregable state and executes the trigger operation. The triggering operation includes broadcasting an event to the permissioned blockchain network that marks the start of the aggregation computation phase, and publishing the identity of an aggregation node in this event. The aggregation node is specified by the smart contract from the list of participating nodes according to predefined rules. After each participating node detects the triggering event, it retrieves the perturbation local statistics generated in step S2 from its local machine, and uses an aggregate public key that is pre-disclosed on the chain by a smart contract and supports additive homomorphic operations to perform encryption operations on the perturbation local statistics to generate the corresponding homomorphic ciphertext. After generating the homomorphic ciphertext, each participating node securely transmits its own homomorphic ciphertext to the designated aggregation node announced in the triggering event via a point-to-point network channel.

[0010] As a further aspect of the present invention: the process of submitting the ciphertext of the aggregation result and the zero-knowledge proof as an aggregation transaction to the smart contract specifically involves: After collecting homomorphic ciphertexts from all participating nodes, the designated aggregation node does not perform decryption. Instead, it performs a chain multiplication operation on all received homomorphic ciphertexts to obtain an aggregation result ciphertext, which is the ciphertext of the sum of the local statistics of each perturbation. To prove to the blockchain network that the aggregated result ciphertext was obtained by correctly performing a chain multiplication operation on all received homomorphic ciphertexts, the aggregating node constructs a zero-knowledge proof. This zero-knowledge proof is used to prove that the submitted aggregated result ciphertext satisfies a chain multiplication relationship with the homomorphic ciphertexts received by the aggregating node that correspond to all nodes in the list of participating nodes recorded in the smart contract. This proof process does not reveal any plaintext information that perturbs local statistics. After generating the zero-knowledge proof, the aggregating node packages the ciphertext of the aggregation result together with this zero-knowledge proof into an aggregate transaction, digitally signs it using its own private key, and submits the digitally signed aggregate transaction to the smart contract.

[0011] As a further aspect of the present invention: In step S4, after verification, the process of coordinating all participating nodes to collaboratively decrypt the ciphertext of the aggregation result to obtain the final aggregation result that satisfies the global privacy loss budget is specifically as follows: The smart contract receives and parses the aggregation transaction submitted by the aggregation node, extracting the ciphertext of the aggregation result and the zero-knowledge proof contained in the aggregation transaction. The smart contract calls the verification algorithm corresponding to the zero-knowledge proof system, using the ciphertext of the aggregation result, the list of homomorphic ciphertexts corresponding to all participating nodes obtained from the on-chain records, and the public statement describing the aggregation operation as a multiplication relationship as inputs to verify the validity of the zero-knowledge proof. If the verification fails, the smart contract rejects the aggregation transaction and the process terminates. If the verification passes, the smart contract advances its internal state from the state of pending aggregation verification to the state of pending collaborative decryption and triggers a threshold decryption protocol. The smart contract broadcasts a decryption request to multiple pre-defined key custodian nodes. Upon receiving the request, each key custodian node uses its own private key fragment to perform a partial decryption operation on the aggregated result ciphertext. Specifically, it uses the private key fragment to perform a modular exponentiation operation on the aggregated result ciphertext to generate a partial decryption result and generates a proof to prove the correctness of the partial decryption operation. The partial decryption result along with its proof is then submitted back to the smart contract. The smart contract collects partial decryption results from the key custodian node and verifies the validity of the attached proof; Once a number of valid partial decryption results, no less than a preset threshold, are collected, the smart contract uses these partial decryption results to perform combined calculations by applying the Lagrange interpolation principle to restore the plaintext value corresponding to the ciphertext of the aggregated result. The plaintext value is the sum of the perturbation local statistics of all participating nodes, which is also the final aggregated result that satisfies the global privacy loss budget.

[0012] As a further aspect of the present invention: the process of updating the node privacy budget of each participating node recorded in the smart contract based on the actual node privacy budget consumed in this research task, and storing the full-process audit information as an audit log, specifically involves: After obtaining the final aggregation result, for each participating node, the smart contract calculates an actual privacy loss. The calculation process is as follows: multiply the global sensitivity of the query function by an adjustment coefficient related to the dispersion measure of the local data of the participating node, and then divide the product by the absolute value estimate of the noise added to the participating node in step S2. The result is the actual privacy loss. The smart contract calculates the actual privacy loss for each participating node, deducts it from the initial node privacy budget recorded in the smart contract state for that participating node, and uses the remaining balance as the new node privacy budget balance for that participating node, updating the budget allocation mapping table maintained by the smart contract. After all participating nodes have updated their privacy budgets, the smart contract automatically generates a complete audit log. As a blockchain transaction, the audit log includes at least the following: the unique identifier of the target research task, the list of participating nodes, the initial global privacy loss budget, the privacy budget values ​​of each participating node before and after the task, a description of the query function executed in the task, the final aggregation result, the hash value of the aggregation transaction, the verification result of the zero-knowledge proof, the list of key storage nodes participating in collaborative decryption, the calculated actual privacy loss of each participating node, and the blockchain timestamps of each key step from task initiation to result publication. This audit log is permanently recorded in the distributed ledger of the permissioned blockchain network.

[0013] Compared with existing technologies, the beneficial effects of this invention are as follows: This solution constructs a decentralized trust execution environment based on blockchain and cryptography, enabling multiple medical institutions to collaborate securely without completely trusting any central party. Through smart contracts, it automates the allocation of fair privacy resources and process coordination, guiding each participating node to add noise to sensitive health records locally to meet differential privacy requirements and generate verifiable commitments. Using homomorphic encryption and zero-knowledge proof technology, it completes the verifiable and secure aggregation of data in encrypted form. Finally, through collaborative decryption, it obtains a global statistical result with strict privacy protection. The entire process realizes the precise calculation of privacy consumption and real-time on-chain settlement, and generates an immutable full-process audit evidence chain, thereby effectively releasing the research value of dispersed medical data while ensuring compliance with personal privacy regulations.

[0014] Other features and advantages of the present invention will be disclosed in detail in the following detailed description and accompanying drawings. Attached Figure Description

[0015] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0016] 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.

[0017] In this embodiment of the invention, a blockchain-based differential privacy protection method for electronic health records is described below. Figure 1 As shown, the specific steps include: Step S1: In response to a research request for the target research task, within a smart contract deployed in the permissioned blockchain network, based on the global privacy loss budget declared in the research request, the list of participating nodes, and the predefined allocation strategy, an initial node privacy budget is calculated and allocated for each participating node in the list of participating nodes, and this value is recorded as the initial node privacy budget for each participating node; the research request, the global privacy loss budget, the list of participating nodes, and the initial node privacy budget allocated to each participating node are recorded in the smart contract; Step S2: Each participating node calculates the local statistics of its locally stored electronic health record data according to the query function corresponding to the target research task recorded in the smart contract, and adds noise to the local statistics based on the initial node privacy budget allocated to it in step S1 to generate perturbed local statistics; then, the participating node generates a cryptographic commitment to the perturbed local statistics and submits the commitment transaction containing the cryptographic commitment and cryptographic auxiliary information to the smart contract. Step S3: After verifying that all participating nodes have completed the commitment transaction submission, the smart contract triggers the aggregation calculation phase. In the aggregation calculation phase, each participating node encrypts the perturbation local statistics generated in step S2 using a homomorphic encryption algorithm to obtain homomorphic ciphertext, and sends the homomorphic ciphertext to the aggregation node designated by the smart contract. The aggregation node uses the homomorphic property of homomorphic encryption to perform aggregation operations on all received homomorphic ciphertexts to obtain the aggregation result ciphertext, and generates a zero-knowledge proof to prove the correctness of the aggregation operation. The aggregation result ciphertext and the zero-knowledge proof are submitted to the smart contract as an aggregation transaction. Step S4: The smart contract verifies the validity of the zero-knowledge proof in the aggregation transaction. After the verification is successful, it coordinates all participating nodes to collaboratively decrypt the ciphertext of the aggregation result to obtain the final aggregation result that satisfies the global privacy loss budget. At the same time, the smart contract updates the node privacy budget of each participating node recorded in the smart contract according to the actual node privacy budget consumed in this research task, so as to reflect the remaining amount after consumption, and stores the full-process audit information of this research task as an audit log.

[0018] In this embodiment, it is specifically necessary to explain that in step S1, the process of calculating and allocating an initial node privacy budget for each participating node in the participating node list based on the global privacy loss budget declared in the research request, the list of participating nodes, and the predefined allocation strategy is as follows: The global privacy loss budget is a real number greater than zero, set by the research initiator (usually the lead institution in a medical consortium). It represents the upper limit of the total privacy resources allowed to be consumed in this research task. This budget value needs to be rigorously derived and set based on the differential privacy mechanism and query sensitivity, while meeting the requirements for the usable accuracy of the final statistical results. The list of participating nodes contains unique identifiers for multiple participating nodes. These participating nodes have completed access verification on the permissioned blockchain network. The research request also declares the query function corresponding to the target research task. The predefined allocation strategy is calculated based on the node metadata of each participating node. The node metadata includes at least the number of valid electronic health records provided by each participating node for the research task, as well as the data sensitivity score calculated based on the electronic health records provided. The data sensitivity score can be obtained through a predefined scoring rule table or calculation model based on factors such as the sensitivity level of diagnostic codes contained in the records, the degree of abnormality of laboratory indicators, and whether direct identifiers are contained. The allocation strategy employs a composite weighting model based on contribution and risk perception. This model aims to fairly reflect the difference between the value of each node's data contribution and the privacy risks it bears. First, a data contribution weight is calculated for each participating node. This weight equals a first adjustment coefficient multiplied by the proportion of data provided by the node to the total data provided by all participating nodes. The first adjustment coefficient controls the weight of data contribution in the overall allocation, and its value can be set according to the alliance strategy; for example, it can be set to 0.7 if data scale is emphasized. Second, a data risk weight is calculated for each participating node. This weight equals a second adjustment coefficient multiplied by the difference between the node's data sensitivity score and the ratio of the node's data sensitivity score to the highest data sensitivity score among all participating nodes. This design ensures that nodes with higher data sensitivity have lower risk weights, thus receiving a smaller initial budget and incentivizing them to provide stronger protection for high-risk data. Both the first and second adjustment coefficients are constants greater than zero and less than one, and their sum is one. This sum of 1 ensures the normalization basis of the weight allocation. Next, a composite weight is calculated for each participating node, which is equal to the sum of the data contribution weight and the data risk weight of that participating node. The sum of the composite weights of all participating nodes is then calculated as a normalization factor. Finally, an initial node privacy budget is calculated for each participating node, which is equal to the global privacy loss budget multiplied by the composite weight of that participating node, and then divided by the normalization factor. Dividing by the normalization factor ensures that the sum of the initial node privacy budgets allocated to all nodes is strictly equal to the global privacy loss budget, achieving precise allocation and waste-free distribution of total resources. Through the above calculations, it is ensured that the sum of the initial node privacy budgets of all participating nodes is equal to the global privacy loss budget. The research request, global privacy loss budget, list of participating nodes, and initial node privacy budget allocated to each participating node are recorded in the smart contract. The specific operations are as follows: The smart contract creates and maintains a task state record that uniquely corresponds to the target research task in the state storage. The task state record is used to persistently store the global privacy loss budget value, the declared query function, and the list of participating nodes contained in the research request, and to create a budget allocation mapping table. The budget allocation mapping table associates and stores the unique identity of each participating node with its calculated initial node privacy budget. This mapping table constitutes the core data structure for each participating node to query and verify its permissions and resource reserves in all subsequent steps. After completing the calculation of the initial node privacy budget and the creation of the budget allocation mapping table, the smart contract generates an event log indicating that the state initialization is complete. This event log allows all nodes in the network to listen for and perceive when a task enters a pending confirmation state. It then waits for more than a preset threshold of participating nodes from the participating node list to submit digital signatures confirming the task state record, which includes the global privacy loss budget, query function, participating node list, and budget allocation mapping table. The preset threshold is typically set to more than two-thirds of the total number of participating nodes to ensure broad representativeness of the consensus and prevent malicious obstruction by a few nodes. The digital signature uses each node's private key to sign the hash value of the task state record, proving that it is aware of and agrees to the initial state. Once the preset threshold of valid digital signatures is collected, the smart contract... Once the state is locked, the global privacy loss budget, the list of participating nodes, and the budget allocation mapping table stored in the smart contract become read-only and cannot be modified unless unlocked through an equally rigorous consensus process. The query functions and budget allocation mapping table stored therein are established as the sole data source with consensus authority that all participating nodes must follow in subsequent steps. Whenever any participating node needs to use its initial node privacy budget or query function in subsequent steps, it must query its corresponding budget allocation mapping table from the locked smart contract state. This ensures that, starting from step S2, the "initial node privacy budget" parameter used by each participating node comes from an authoritative record that has undergone multi-party consensus and cannot be tampered with, thereby guaranteeing the consistency and credibility of the entire method's execution basis.

[0019] In this embodiment, the specific process of generating the perturbation local statistics in step S2 is as follows: The participating node listens to the permissioned blockchain network. After confirming that the state of the smart contract in step S1 is locked, it obtains the query function defined by the target research task and the initial node privacy budget allocated to itself from the locked smart contract state. The query function clarifies the data dimensions and calculation methods to be statistically analyzed, such as the summation or counting of specific disease indicators. Next, in a secure local environment, participating nodes extract electronic health record data related to the research task from the database and apply query functions to calculate the extracted electronic health record data to obtain unperturbed raw local statistics (the raw local statistics reflect the node's true contribution to the queried data). Subsequently, based on the obtained initial node privacy budget and the inherent global sensitivity of the query function, participating nodes determine the core scale parameter for noise generation. This core scale parameter defines the benchmark of noise magnitude and is usually proportional to the global sensitivity and inversely proportional to the initial node privacy budget. Based on this, the participating nodes calculate the dispersion measure of the extracted electronic health record data on the dimension targeted by the query function. The dispersion measure is used to quantify the fluctuation of local data and can be calculated using the mean absolute deviation or quantile-based statistics. The average of the dispersion measures of all participating nodes is then obtained, and this average is used as a global benchmark to measure the relative dispersion level of individual node data. The participating nodes then divide their local dispersion measure by this average, add one to the resulting ratio, take the natural logarithm, and finally add one to the result again to obtain the local data feature factor. This calculation process ensures that the local data feature factor is always greater than or equal to one. When the dispersion measure is equal to the average level, the factor is approximately 1; when the dispersion measure is large, the factor is greater than 1. Participating nodes construct a probability distribution for noise generation based on the initial node privacy budget, the global sensitivity of the query function, and local data feature factors. This distribution ensures that the probability density of the generated noise is proportional to the result of an exponential operation with the natural constant e as the base. The power of this exponential operation is the negative of the result of the operation on the absolute value of the generated noise, the local data feature factor, the global sensitivity of the query function, and the initial node privacy budget. This probability distribution is a variant of the exponential mechanism. The local data feature factor acts as a moderating factor; its increase makes the probability distribution curve steeper, thus making the generated noise value more likely to approach zero. This optimizes the utility of highly discrete data under the same privacy budget. Specifically, increasing the local data feature factor causes the probability distribution to be more concentrated near zero. This means that for nodes with large internal differences in the data, under the same level of privacy protection, the added noise has less distortion on the statistical results, thereby improving the overall data usability. Finally, the participating nodes sample a noise from the constructed probability distribution. The sampling process is implemented using a pseudo-random number generator to ensure the randomness of the noise value. The noise is then added to the calculated original local statistics, and the result is the perturbation local statistics. The perturbation local statistics meet the local differential privacy requirements, and its noise level is adaptive. The specific operation of participating nodes generating cryptographic commitments to perturb local statistics and submitting the commitment transaction containing the cryptographic commitment and cryptographic auxiliary information to the smart contract is as follows: After generating the perturbation local statistics, participating nodes first generate a cryptographically secure random number as a commitment random number. This commitment random number must have sufficient entropy to prevent speculation. The participating nodes then concatenate the perturbation local statistics and the commitment random number sequentially to form a data string. This data string is input into a cryptographic hash function for calculation, and the resulting hash output value serves as the cryptographic commitment. The cryptographic hash function can use the SHA-256 algorithm, whose one-way and collision-resistant properties ensure that the original value cannot be deduced from the commitment, and that it is difficult to find different data that generate the same commitment. Simultaneously, participating nodes use a pre-obtained, designated recipient public key from the smart contract to encrypt the commitment random number, generating an encrypted commitment random number. This encrypted commitment random number serves as encryption auxiliary information. The recipient public key is published by the smart contract during task initialization. The encryption algorithm can be RSA-OAEP, ensuring that only the corresponding private key holder can decrypt the ciphertext to obtain the commitment random number. Participating nodes construct a commitment transaction, which includes cryptographic commitments and cryptographic auxiliary information. Participating nodes use their own private keys to digitally sign the commitment transaction. The digital signature algorithm can be ECDSA, which is used to prove that the transaction was indeed generated by the participating node and that the content has not been tampered with. After completing the digital signature, the participating nodes broadcast the digitally signed commitment transaction to the permissioned blockchain network. The smart contract receives the commitment transaction, verifies the validity of the digital signature, and the verification includes using the public key registered by the participating nodes to verify the signature and checking the compliance of the transaction format. After the verification is passed, the cryptographic commitment and encrypted auxiliary information in the commitment transaction are recorded in the smart contract state. After being recorded, the commitment becomes an immutable on-chain evidence, which is used in subsequent steps to verify the honesty of the participating nodes' behavior.

[0020] In this embodiment, it is specifically necessary to explain that in step S3, the process of sending the homomorphic ciphertext to the aggregation node specified by the smart contract is as follows: The smart contract internally maintains a task state record corresponding to the target research task. The task state record is used to track and confirm whether the commitment transactions from each participating node in the list of participating nodes have been successfully received and verified by digital signature. This verification ensures that the data source is authentic and has not been tampered with. The commitment transactions include the cryptographic commitments and encryption auxiliary information generated by the participating nodes in step S2. When the smart contract detects that the task state record shows that the commitment transactions of all participating nodes have been verified and recorded, the smart contract automatically transitions its internal state to an aggregatable state and executes the trigger operation. The state machine model guarantees the atomicity and sequentiality of the process. The triggering operation includes broadcasting an event to the permissioned blockchain network that marks the start of the aggregation computation phase, and publishing the identity of an aggregation node in this event. The aggregation node is specified by a smart contract from a list of participating nodes according to predefined rules, which can be random selection, rotation, or selection based on node reputation, aiming to avoid a single fixed node being trusted for a long time. After each participating node hears the triggering event, it retrieves the perturbation local statistics generated in step S2 from its local machine, and uses an aggregate public key that is pre-published on the chain by a smart contract and supports additive homomorphic operations to perform encryption operations on the perturbation local statistics to generate the corresponding homomorphic ciphertext. The aggregate public key usually corresponds to the public key in a threshold encryption scheme, and its private key is distributed to multiple custodians to ensure that no single entity can decrypt it independently. After generating homomorphic ciphertext, each participating node securely transmits its own homomorphic ciphertext to the designated aggregation node announced in the triggering event via a peer-to-peer network channel. Peer-to-peer transmission reduces network congestion and can ensure the security of the transmission process through encrypted links such as TLS. The process of submitting the ciphertext of the aggregation result and the zero-knowledge proof as an aggregation transaction to the smart contract is as follows: After the designated aggregation node collects the homomorphic ciphertext from all participating nodes, it does not perform decryption. Instead, it performs a chain multiplication operation on all the received homomorphic ciphertexts. In homomorphic encryption schemes such as Paillier, the chain multiplication operation of ciphertexts corresponds to the addition of plaintexts, thus obtaining an aggregated ciphertext. This aggregated ciphertext is the ciphertext of the sum of the local statistics of each perturbation. To prove to the blockchain network that the aggregated result ciphertext was obtained by correctly performing a chain multiplication operation on all received homomorphic ciphertexts, the aggregating node constructs a zero-knowledge proof. This zero-knowledge proof can be generated using a non-interactive zero-knowledge proof system such as zk-SNARKs or Bulletproofs. The proof generation requires homomorphic ciphertexts as public input and the randomness generated by the aggregating node during the chain multiplication process as private witness. This zero-knowledge proof demonstrates that the submitted aggregated result ciphertext satisfies a chain multiplication relationship with the homomorphic ciphertexts received by the aggregating node, corresponding to all nodes in the participating node list recorded in the smart contract. This chain multiplication relationship is the core of verifying the correctness of the calculation, ensuring that the aggregated result has not been forged or tampered with. This proof process does not reveal any plaintext information that perturbs local statistics; the zero-knowledge nature ensures that the confidentiality of the data is maintained during the verification process. After generating the zero-knowledge proof, the aggregating node packages the ciphertext of the aggregation result together with this zero-knowledge proof into an aggregate transaction. It then uses its own private key to digitally sign the transaction. The digital signature uses algorithms such as ECDSA to authenticate the source of the transaction and ensure its integrity. Finally, the digitally signed aggregate transaction is submitted to the smart contract. After submission, the smart contract can publicly verify the signature and the zero-knowledge proof, thus ensuring the correctness of the aggregation result without trusting the aggregating node.

[0021] In this embodiment, it is particularly important to explain step S4, where, after successful verification, the participating nodes coordinate to collaboratively decrypt the ciphertext of the aggregation result to obtain the final aggregation result that satisfies the global privacy loss budget. The specific process is as follows: The smart contract receives and parses the aggregation transaction submitted by the aggregation node, extracting the ciphertext of the aggregation result and the zero-knowledge proof contained in the aggregation transaction. The smart contract calls the verification algorithm corresponding to the zero-knowledge proof system, using the ciphertext of the aggregation result, the list of homomorphic ciphertexts corresponding to all participating nodes obtained from the on-chain records, and the public statement describing the aggregation operation as a multiplication relationship as inputs to verify the validity of the zero-knowledge proof. This verification utilizes the publicly verifiable nature of zero-knowledge proofs, enabling the smart contract to independently determine whether the calculation is correct without relying on the trustworthiness of the aggregation node. If the verification fails, the smart contract rejects the aggregation transaction, and the process terminates. If the verification passes, the smart contract advances its internal state from the state of pending aggregation verification to the state of pending collaborative decryption, and triggers a threshold decryption protocol. The state transition ensures the sequentiality and non-reversibility of the process. The smart contract broadcasts a decryption request to multiple pre-defined key custodian nodes. Upon receiving the request, each key custodian node uses its own private key fragment to perform a partial decryption operation on the aggregated ciphertext. Specifically, it uses the private key fragment to perform a modular exponentiation operation on the aggregated ciphertext. In threshold encryption schemes such as Paillier, partial decryption is usually represented by a modular exponentiation operation with the private key fragment as the exponent, generating a partial decryption result and a proof to prove the correctness of the partial decryption operation. This proof is usually a zero-knowledge proof to prevent malicious key custodian nodes from submitting incorrect results to obstruct decryption. The partial decryption result along with its proof is then submitted back to the smart contract. The smart contract collects partial decryption results from the key custodian node and verifies the validity of the attached proof; Once a number of valid partial decryption results, no less than a preset threshold number, are collected, the preset threshold number is determined by the parameters of the threshold encryption scheme used. For example, in a (3,5) threshold scheme, this number is 3. The smart contract uses these partial decryption results to perform combined calculations on the partial decryption results by applying the Lagrange interpolation principle. The Lagrange interpolation is performed on the exponent to restore the role of the complete private key in decryption and restore the plaintext value corresponding to the ciphertext of the aggregated result. The plaintext value is the sum of the perturbation local statistics of all participating nodes, which is also the final aggregated result that satisfies the global privacy loss budget. This final aggregated result is the sum of statistical data contributed by all participating nodes and protected by differential privacy. The process of updating the node privacy budget of each participating node recorded in the smart contract based on the actual node privacy budget consumed in this research task, and storing the full-process audit information as an audit log, is as follows: After obtaining the final aggregation result, the smart contract calculates an actual privacy loss for each participating node. The calculation process is as follows: multiply the global sensitivity of the query function by an adjustment coefficient related to the dispersion measure of the local data of the participating node, and then divide the product by the absolute value estimate of the noise added to the participating node in step S2. The result is the actual privacy loss. This calculation formula aims to quantify the actual privacy impact of each query on a single node, rather than using the theoretical maximum value. The adjustment coefficient is a value between 0.5 and 1, determined by the ratio of the dispersion measure of the participating nodes to the average dispersion measure of all participating nodes. This coefficient can be calculated using a sigmoid function. When the ratio equals 1, the adjustment coefficient is approximately 0.73; when the ratio is much greater than 1, the adjustment coefficient approaches 1; when the ratio is much less than 1, the adjustment coefficient approaches 0.5. When the dispersion measure of the participating nodes is higher than the average dispersion measure, the adjustment coefficient approaches 1, indicating that the information leaked from high-dispersion data is more discriminative and has a greater impact on privacy. When the dispersion measure of the participating nodes is lower than the average dispersion measure, the adjustment coefficient approaches 0.5, indicating that the information leaked from low-dispersion data has relatively lower value. The absolute value of the noise added by the participating nodes in step S2 is estimated based on the cryptographic commitment verified by the commitment random number obtained from the cryptographic auxiliary information in step S2, and is calculated in combination with the final aggregation result. By opening the commitment to obtain the perturbation local statistics declared by the participating nodes, and combining them with the global sum, the magnitude of the noise added can be constrained or estimated within a certain error range. The smart contract calculates the actual privacy loss for each participating node and deducts it from the initial node privacy budget recorded in the smart contract state for that participating node. The remaining balance after deduction is used as the new node privacy budget balance for that participating node and updated in the budget allocation mapping table maintained by the smart contract. This update operation ensures the real-time and accurate calculation of privacy budget resources and provides a basis for the available balance for subsequent queries. After all participating nodes have updated their privacy budgets, the smart contract automatically generates a complete audit log. As a blockchain transaction, the audit log includes at least the following: the unique identifier of the target research task, a list of participating nodes, the initial global privacy loss budget, the privacy budget values ​​of each participating node before and after the task, a description of the query function executed in the task, the final aggregation result, the hash value of the aggregation transaction, the verification result of the zero-knowledge proof, a list of key storage nodes participating in collaborative decryption, the calculated actual privacy loss amount for each participating node, and blockchain timestamps for each key step from task initiation to result publication. Each timestamp is associated with a corresponding block on the blockchain, providing an immutable proof of time. This audit log is permanently recorded in the distributed ledger of the permissioned blockchain network, forming a complete, traceable, and non-repudiable process record.

[0022] This invention provides a blockchain-based differential privacy protection method for electronic health records. This solution constructs a decentralized trust execution environment based on blockchain and cryptography, enabling multiple medical institutions to securely collaborate without completely trusting any central authority. Through smart contracts, it automates the allocation of fair privacy resources and process coordination, guiding participating nodes to locally add noise to sensitive health records to meet differential privacy requirements and generate verifiable commitments. Using homomorphic encryption and zero-knowledge proofs, it completes verifiable and secure aggregation of data in encrypted form. Finally, through collaborative decryption, it obtains a globally statistical result with strict privacy protection. The entire process achieves precise calculation of privacy consumption and real-time on-chain settlement, generating an immutable, end-to-end audit evidence chain. Thus, while ensuring compliance with personal privacy regulations, it effectively releases the research value of dispersed medical data.

[0023] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0024] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A blockchain-based differential privacy protection method for electronic health records, characterized in that, Specifically, the steps include the following: Step S1: In response to a research request for the target research task, within a smart contract deployed in the permissioned blockchain network, based on the global privacy loss budget declared in the research request, the list of participating nodes, and the predefined allocation strategy, an initial node privacy budget is calculated and allocated for each participating node in the list of participating nodes, and this value is recorded as the initial node privacy budget for each participating node; the research request, the global privacy loss budget, the list of participating nodes, and the initial node privacy budget allocated to each participating node are recorded in the smart contract; Step S2: Each participating node calculates the local statistics of its locally stored electronic health record data according to the query function corresponding to the target research task recorded in the smart contract, and adds noise to the local statistics based on the initial node privacy budget allocated to it in step S1 to generate perturbed local statistics; then, the participating node generates a cryptographic commitment to the perturbed local statistics and submits the commitment transaction containing the cryptographic commitment and cryptographic auxiliary information to the smart contract. Step S3: After verifying that all participating nodes have completed the commitment transaction submission, the smart contract triggers the aggregation calculation phase. In the aggregation calculation phase, each participating node encrypts the perturbation local statistics generated in step S2 using a homomorphic encryption algorithm to obtain homomorphic ciphertext, and sends the homomorphic ciphertext to the aggregation node specified by the smart contract. The aggregation node utilizes the homomorphic property of homomorphic encryption to perform aggregation operations on all received homomorphic ciphertexts, obtains the aggregation result ciphertext, generates a zero-knowledge proof to prove the correctness of the aggregation operation, and submits the aggregation result ciphertext and the zero-knowledge proof as an aggregation transaction to the smart contract. Step S4: The smart contract verifies the validity of the zero-knowledge proof in the aggregation transaction. After the verification is successful, it coordinates all participating nodes to collaboratively decrypt the ciphertext of the aggregation result to obtain the final aggregation result that satisfies the global privacy loss budget. At the same time, the smart contract updates the node privacy budget of each participating node recorded in the smart contract according to the actual node privacy budget consumed in this research task, so as to reflect the remaining amount after consumption, and stores the full-process audit information of this research task as an audit log.

2. The method for differential privacy protection of electronic health records based on blockchain according to claim 1, characterized in that: In step S1, the process of calculating and allocating an initial node privacy budget for each participating node in the participating node list based on the global privacy loss budget declared in the research request, the list of participating nodes, and the predefined allocation strategy is as follows: The global privacy loss budget is set by the research initiator and represents the upper limit of the total privacy resources allowed to be consumed in this research task; the list of participating nodes contains unique identifiers for multiple participating nodes, which have completed access verification of the permissioned blockchain network; the research request also declares the query function corresponding to the target research task; the predefined allocation strategy is calculated based on the node metadata of each participating node, which includes at least the number of valid electronic health records provided by each participating node for the research task, and the data sensitivity score calculated based on the electronic health records provided by it; The allocation strategy performs calculations by constructing a composite weight model based on contribution and risk perception. First, a data contribution weight is calculated for each participating node, which is equal to the first adjustment coefficient multiplied by the proportion of the amount of data provided by this participating node to the total amount of data provided by all participating nodes. Secondly, a data risk weight is calculated for each participating node. This data risk weight is equal to the second adjustment coefficient multiplied by the difference between the ratio of the node's data sensitivity score and the highest data sensitivity score among all participating nodes. Next, a composite weight is calculated for each participating node, which is equal to the sum of the data contribution weight and the data risk weight of that participating node; The sum of the composite weights of all participating nodes is calculated as a normalization factor. Finally, the initial node privacy budget for each participating node is calculated, which is equal to the global privacy loss budget multiplied by the composite weight of the participating node and then divided by the normalization factor.

3. The method for differential privacy protection of electronic health records based on blockchain according to claim 2, characterized in that: The specific operations for recording the research request, global privacy loss budget, list of participating nodes, and initial node privacy budget allocated to each participating node in the smart contract are as follows: The smart contract creates and maintains a task state record that uniquely corresponds to the target research task in the state store. The task state record is used to persistently store the global privacy loss budget value, the declared query function, and the list of participating nodes contained in the research request, and to create a budget allocation mapping table. The budget allocation mapping table associates and stores the unique identity of each participating node with its calculated initial node privacy budget. After completing the calculation of the initial node privacy budget and the creation of the budget allocation mapping table, the smart contract generates an event log indicating that the state initialization is complete, and waits for more than a preset threshold of participating nodes from the participating node list to submit digital signature confirmations for the task state record containing the global privacy loss budget, query function, participating node list, and budget allocation mapping table; once a preset threshold of valid digital signatures is collected, the state of the smart contract is locked.

4. The method for differential privacy protection of electronic health records based on blockchain according to claim 3, characterized in that: In step S2, the specific process of generating the local statistics of the disturbance is as follows: The participating node listens to the permissioned blockchain network. After confirming that the state of the smart contract in step S1 is locked, it obtains the query function defined by the target research task and the initial node privacy budget allocated to itself from the locked smart contract state. Next, the participating nodes extract electronic health record data related to the research task from the database in a local secure environment, and apply query functions to calculate the extracted electronic health record data to obtain the undisturbed raw local statistics. Subsequently, the participating nodes determine the core scale parameters for noise generation based on the initial node privacy budget obtained and the inherent global sensitivity of the query function; Based on this, the participating nodes calculate the dispersion measure of the extracted electronic health record data on the dimension targeted by the query function, and obtain the average of the corresponding dispersion measure of all participating nodes; the participating nodes then divide their local dispersion measure by the average, add one to the resulting ratio, take the natural logarithm, and finally add one to the result to obtain the local data feature factor. The participating nodes construct a probability distribution for noise generation based on the initial node privacy budget, the global sensitivity of the query function, and local data feature factors, so that the probability density of the generated noise is proportional to the result of the exponential operation with the natural constant e as the base. Finally, the participating nodes sample a noise from the constructed probability distribution and add the noise to the calculated original local statistic. The result is the perturbation local statistic.

5. A blockchain-based differential privacy protection method for electronic health records according to claim 4, characterized in that: The specific operation of the participating node generating a cryptographic commitment to the perturbation local statistics and submitting the commitment transaction containing the cryptographic commitment and cryptographic auxiliary information to the smart contract is as follows: After generating the perturbation local statistics, the participating nodes first generate a cryptographically secure random number as the commitment random number. The participating nodes then concatenate the perturbation local statistics and the commitment random number sequentially to form a data string. The data string is then input into a cryptographic hash function for calculation, and the resulting hash output value serves as the cryptographic commitment. Simultaneously, the participating nodes use a pre-obtained public key from the smart contract and a designated recipient to encrypt the commitment random number, generating an encrypted commitment random number, which serves as cryptographic auxiliary information. Each participating node constructs a commitment transaction, which includes a cryptographic commitment and encrypted auxiliary information. Each participating node digitally signs the commitment transaction using its own private key. After the digital signature is completed, the participating nodes broadcast the digitally signed commitment transaction to the permissioned blockchain network; the smart contract receives the commitment transaction, verifies the validity of the digital signature, and records the cryptographic commitment and cryptographic auxiliary information in the smart contract state after the verification is successful.

6. The method for differential privacy protection of electronic health records based on blockchain according to claim 5, characterized in that: In step S3, the process of sending the homomorphic ciphertext to the aggregation node specified by the smart contract is as follows: The smart contract maintains a task status record corresponding to the target research task. The task status record is used to track and confirm whether the committed transactions from each participating node in the list of participating nodes have been successfully received and verified by digital signature. When the smart contract detects that the task status record shows that the committed transactions of all participating nodes have been verified and recorded, the smart contract automatically transitions its internal state to an aggregable state and executes the trigger operation. The triggering operation includes broadcasting an event to the permissioned blockchain network that marks the start of the aggregation computation phase, and publishing the identity of an aggregation node in this event. The aggregation node is specified by the smart contract from the list of participating nodes according to predefined rules. After each participating node detects the triggering event, it retrieves the perturbation local statistics generated in step S2 from its local machine, and uses an aggregate public key that is pre-disclosed on the chain by a smart contract and supports additive homomorphic operations to perform encryption operations on the perturbation local statistics to generate the corresponding homomorphic ciphertext. After generating the homomorphic ciphertext, each participating node securely transmits its own homomorphic ciphertext to the designated aggregation node announced in the triggering event via a point-to-point network channel.

7. A blockchain-based differential privacy protection method for electronic health records according to claim 6, characterized in that: The process of submitting the aggregated result ciphertext and zero-knowledge proof as an aggregated transaction to the smart contract is as follows: After collecting homomorphic ciphertexts from all participating nodes, the designated aggregation node does not perform decryption. Instead, it performs a chain multiplication operation on all received homomorphic ciphertexts to obtain an aggregation result ciphertext, which is the ciphertext of the sum of the local statistics of each perturbation. To prove to the blockchain network that the aggregated result ciphertext was obtained by correctly performing a chain multiplication operation on all received homomorphic ciphertexts, the aggregating node constructs a zero-knowledge proof. This zero-knowledge proof is used to prove that the submitted aggregated result ciphertext satisfies a chain multiplication relationship with the homomorphic ciphertexts received by the aggregating node that correspond to all nodes in the list of participating nodes recorded in the smart contract. This proof process does not reveal any plaintext information that perturbs local statistics. After generating the zero-knowledge proof, the aggregating node packages the ciphertext of the aggregation result together with this zero-knowledge proof into an aggregate transaction, digitally signs it using its own private key, and submits the digitally signed aggregate transaction to the smart contract.

8. A blockchain-based differential privacy protection method for electronic health records according to claim 7, characterized in that: In step S4, after successful verification, the participating nodes coordinate to collaboratively decrypt the ciphertext of the aggregation result to obtain the final aggregation result that satisfies the global privacy loss budget. The specific process is as follows: The smart contract receives and parses the aggregation transaction submitted by the aggregation node, extracting the ciphertext of the aggregation result and the zero-knowledge proof contained in the aggregation transaction. The smart contract calls the verification algorithm corresponding to the zero-knowledge proof system, using the ciphertext of the aggregation result, the list of homomorphic ciphertexts corresponding to all participating nodes obtained from the on-chain records, and the public statement describing the aggregation operation as a chain multiplication relationship as inputs to verify the validity of the zero-knowledge proof. If the verification fails, the smart contract rejects the aggregation transaction, and the process terminates. If the verification passes, the smart contract advances its internal state from the state of pending aggregation verification to the state of pending collaborative decryption, and triggers a threshold decryption protocol; The smart contract broadcasts a decryption request to multiple pre-defined key custodian nodes. Upon receiving the request, each key custodian node uses its own private key fragment to perform a partial decryption operation on the aggregated result ciphertext. Specifically, it uses the private key fragment to perform a modular exponentiation operation on the aggregated result ciphertext to generate a partial decryption result and generates a proof to prove the correctness of the partial decryption operation. The partial decryption result along with its proof is then submitted back to the smart contract. The smart contract collects partial decryption results from the key custodian node and verifies the validity of the attached proof; Once a number of valid partial decryption results, no less than a preset threshold, are collected, the smart contract uses these partial decryption results to perform combined calculations by applying the Lagrange interpolation principle to restore the plaintext value corresponding to the ciphertext of the aggregated result. The plaintext value is the sum of the perturbation local statistics of all participating nodes, which is also the final aggregated result that satisfies the global privacy loss budget.

9. A blockchain-based differential privacy protection method for electronic health records according to claim 8, characterized in that: The process of updating the node privacy budget of each participating node recorded in the smart contract based on the actual node privacy budget consumed in this research task, and storing the full-process audit information as an audit log, is as follows: After obtaining the final aggregation result, for each participating node, the smart contract calculates an actual privacy loss. The calculation process is as follows: multiply the global sensitivity of the query function by an adjustment coefficient related to the dispersion measure of the local data of the participating node, and then divide the product by the absolute value estimate of the noise added to the participating node in step S2. The result is the actual privacy loss. The smart contract calculates the actual privacy loss for each participating node, deducts it from the initial node privacy budget recorded in the smart contract state for that participating node, and uses the remaining balance as the new node privacy budget balance for that participating node, updating the budget allocation mapping table maintained by the smart contract. After all participating nodes have updated their privacy budgets, the smart contract automatically generates a complete audit log. As a blockchain transaction, the audit log includes at least the following: the unique identifier of the target research task, the list of participating nodes, the initial global privacy loss budget, the privacy budget values ​​of each participating node before and after the task, a description of the query function executed in the task, the final aggregation result, the hash value of the aggregation transaction, the verification result of the zero-knowledge proof, the list of key storage nodes participating in collaborative decryption, the calculated actual privacy loss of each participating node, and the blockchain timestamps of each key step from task initiation to result publication. This audit log is permanently recorded in the distributed ledger of the permissioned blockchain network.

Images