Integrating blockchain and ZK-ROLLUP for efficient healthcare data privacy protection system via IPFS

The proposed model ensures that the rightful owner has the required access control over their health data, in our case the patient. Patients use cryptography applied within the system to protect their data from unauthorized access, misuse or fraud. Patients don’t need to know how cryptography works or how encryption is done. They can use the front-end system like any other web application and provide access to the physician/hospital entity when needed. When the access is over, they may revoke it. In this way, any user with basic computer knowledge can join this proposed network and protect their health data. All the cryptography, consensus mechanism, storage and retrieval is done within the system by design. Figure 2 shows the integration of blockchain with IPFS, while data generated by individuals or hospitals is given to TX Batch, and then this data (TX) is uploaded to a zero-knowledge proof smart contract, and the index of the aggregated information is placed on the main chain, with the specific details of the data being held by IPFS together with the smart contract (there is a high degree of freedom, there is no focus, and it doesn’t matter which one stores more or less).

Framework overview and process.

Overview

Figure 2 shows the integration of blockchain and IPFS, while providing personal or hospital-generated data to TX Batch, which is then uploaded to a zero-knowledge proof smart contract, and the index of aggregated information is placed on the main chain. The EMR generated by communication between patients and doctors is directly written into it as key-value pairs according to scientific research needs or all settings. Doctors directly upload the file to the IPFS network through command-line tools or customized client software to obtain the corresponding CID (content identifier). But it is connected by the main chain in the middle, and users call the smart contract deployed on the Ethereum main chain and provide it with the CID obtained from IPFS and any related metadata or transaction information. Smart contracts may include logic to verify the validity of CIDs, such as checking for existence in the IPFS network, or performing operations involving file ownership transfer. Afterward, relevant transactions are submitted to ZK Rollup through the Layer 2 interface, including CID, transaction details, and zero-knowledge proof (proof that the files have been successfully stored on IPFS). ZK Rollup batch processes these transactions and generates validity proofs, and then writes the summary results and proofs into the Ethereum main chain. The following is the classification and detailed division of labor of nodes in this process. (In Fig. 2, individuals and hospital can refer to individuals and organizations. In this article, individuals refer to patients and doctors, aiming to emphasize universality.)

Doctor nodes

The doctor node is different from the hospital node in that when a patient visits the hospital, a non-contested electronic medical record is generated according to certain rules, which is uploaded by the doctor to ZK’s smart contract and signed with his own private key, and then transmitted to the main chain through the smart contract. When the doctor visits or performs other activities that require reading medical data, he or she has to upload a smart contract that merely verifies his or her identity to prove that he or she is not an evil node, thus ensuring the security of the data. And then a series of operations such as adding, deleting, changing and checking can be performed. Doctors must be full nodes, although the data does not belong to anyone, patients and doctors have the right to use it, but the patient nodes do not need to be deeply involved in the construction of the network, and need the doctor nodes to maintain the operation of the blockchain. In addition, the doctor node is a contract user, each doctor has to interact with various contracts, so it must be a contract user, although there is a generated public and private key, but the key account is not in the scope of consideration.

Patient nodes

Half of the patient nodes are light nodes³⁷ unless there are special requirements, they are necessarily light nodes because they join the network generally temporary, most people use this network for less than a few hours or more than a few days, and the depth of participation is not enough, so they can only carry out the release of their own medical data and modify the transaction according to the doctor’s recommendations. Of course, the generation of electronic medical records is also based on the medical recommendations of doctors. But this data belongs neither to the patient nor to the hospital; the data is just data, it just happens to be medical data. In addition, every patient is a contract user and interacts with contracts, especially ZK contracts. They are not full nodes and therefore only store block headers.

Hospital nodes(IPFS)

The hospital node is different from the doctor node, its main function is to maintain the system operation, provide arithmetic power, so that the whole system has a strong robustness, so the hospital node is necessarily a full node. It is equivalent to a Server in C/S architecture, but in this system it is decentralized, no institution or unit can be the traditional centralized database, only the blockchain serves this job. After the data OR transaction is uploaded to the chain by the smart contract, the returned summary will exist in IPFS, which not only improves the uploading speed but also ensures the security of the summary taken back from the blockchain and placed in IPFS after hashing.

ZK-nodes

Overall, the nodes that perform ZK are not a particular class of nodes, but rather nodes that have the ability and arithmetic power to perform ZK. Some of the patient nodes, all of the doctor nodes, and the hospital nodes are ZK nodes, in contrast to the patient nodes, which sometimes have too little depth into the system and variable time to complete ZK proofs in real-time. Individual contracts on the main chain are used to hold all the money and keep a concise cryptographic promise that points to the state of the “sidechain” (typically a Merkle tree of accounts, account balances, etc.)

Data flow and process

The following is a description using pseudocode.

Submit transactions through the API or SDK provided by ZK Rollup await ZK-Rollup.submitTransaction (userWallet, functionCallData);

At this point, the smart contract on the Ethereum main chain will verify the proof and record the new state root. a) Add the transaction to the state machine of Layer 2 and wait for batch processing b) Generate a proof of validity for this transaction using a zero-knowledge proof algorithm.(Next is the logic of the ZK Rollup layer, and doctors usually do not directly participate in this step).When a batch of transactions is completed, the ZK Rollup node will calculate a new state root and proof.

It includes applying transactions to the state tree and then generating proofs using the zk SNARK toolchain. Submit the compressed state and proof to the ZK Rollup smart contract on the Ethereum main network. ‘The submitBatch’ method is fictional and may involve multiple steps in practice, such as packaging the proof of multiple transactions into one batch, verifying batch integrity, and executing specific commit functions on the chain. After verification, the smart contract will update its stored latest status root. In this way, the Ethereum main chain only stores a small amount of validity proof data, while most of the calculation and transaction data is retained on Layer 2, thereby improving the scalability of the entire system.

Figure 3 shows some specific processes. a good random source generates the public and private keys (RSA is used in the experiments and can be replaced depending on the actual.) Distributed to the patient and the doctor so that they each keep their own information, based on the visit information, the doctor determines the EMR, according to the order of uploading the data was submitted to the ZK Smart contract, after the contract processing, after queuing to the Ethernet main chain, at this time the information on the Ethernet is just the index (summary) of these data. Later, the index of these data can be placed in IPFS to further free up the contents of the chain and keep the data flow smooth.

Figure 4 shows the process when either the patient or the doctor seeks medical data, by uploading their own proof of public–private key pairs to ensure their legitimacy and security, and then the request will be processed in the contract, and after submitting it to the main chain to generate an index, the index can be used to look for the required data in the framework.

Patient and doctor node interaction with blockchain and IPFS network.