News
Integration of blockchain and ZK-ROLLUP for an efficient healthcare data privacy protection system via IPFS
The proposed model guarantees that the legitimate owner has the necessary access control over their health data, in our case the patient. Patients use encryption applied within the system to protect their data from unauthorized access, abuse or fraud. Patients do not need to know how encryption works or how encryption is performed. They can use the front-end system like any other web application and provide access to the doctor/hospital when needed. Once access is terminated they will be able to revoke it. In this way, any user with basic computer knowledge can join this proposed network and protect their health data. All encryption, consensus mechanism, storage and retrieval are done within the system by design. Figure 2 shows the integration of blockchain with IPFS, while the data generated by individuals or hospitals is provided to TX Batch, then this data (TX) is uploaded to a zero-knowledge proof smart contract, and the aggregate information index is placed on the main chain, with the specific details of the data stored 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).
Regulatory 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 aggregated information index is placed on the main chain. The EMR generated by communication between patients and doctors is written directly into it as key-value pairs based on the needs of scientific research or all settings. Doctors directly upload the file to the IPFS network via command line tools or custom 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 all related metadata or transaction information. Smart contracts can include logic to verify the validity of CIDs, such as checking for existence in the IPFS network or performing operations that involve transferring ownership of files. Next, the relevant transactions are sent to ZK Rollup via 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 proofs of validity, then writes the summary results and proofs to the Ethereum main chain. The following is the detailed classification and 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, with the aim of emphasizing universality.)
Doctor’s knots
The doctor node differs from the hospital node in that when a patient goes to the hospital, according to certain rules an uncontested electronic medical record is generated, which is loaded by the doctor into the ZK smart contract and signed with his private key, and then transmitted to the main chain through the smart contract. When the doctor visits or carries out other activities that require reading medical data, he must load a smart contract that simply verifies her identity to prove that it is not a malicious node, thus ensuring data security. Then you can perform a series of operations such as adding, deleting, editing and checking. Doctors need to be full nodes, even if the data does not belong to anyone, patients and doctors have the right to use it, but patient nodes do not need to be deeply involved in building the network, and need doctor nodes to maintain the functioning of the blockchain. Furthermore, the doctor node is a contracted user, each doctor must interact with different contracts, so he must be a contracted user, even if there is a generated public and private key, but the key account is not within the scope of consideration.
Patient nodes
Half of the patient lymph nodes are light nodes37 unless there are special requirements, they are necessarily light nodes because membership in the network is 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 sufficient, therefore they can only release their medical data and modify the transaction according to the doctor’s instructions. Of course, the creation 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; data is just data, it seems like it’s just medical data. Furthermore, 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 medical node, its main function is to maintain the operation of the system, provide arithmetic power, so that the whole system has strong robustness, so the hospital node is necessarily a complete 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 does this job. After the data OR transaction is loaded onto the chain by the smart contract, the returned summary will exist in IPFS, which not only improves the loading speed but also ensures the security of the summary taken back from the blockchain and inserted into IPFS after hashing .
ZK nodes
Overall, nodes running ZK are not a particular class of nodes, but rather nodes that have the ability and arithmetic power to run ZK. Some of the patient nodes, all doctor nodes, and hospital nodes are ZK nodes, unlike patient nodes, which sometimes have too little depth in the system and variable time to complete ZK tests in real time. Individual contracts on the main chain are used to hold all the money and maintain a concise cryptographic promise that indicates 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.
Submitting transactions via the API or SDK provided by ZK Rollup waits for 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 Layer 2 state machine and wait for batch processing b) Generate a proof of validity for this transaction using a zero-knowledge proof algorithm. (Next is the ZK Rollup level logic, and doctors usually do not directly participate in this step.) When a batch of transactions completes, the ZK Rollup node will calculate a new state root and proof.
It includes applying transactions to the state tree and generating proofs using the zk SNARK toolchain. Send the compressed state and proof to the ZK Rollup smart contract on the Ethereum mainnet. The “submitBatch” method is fictional and may involve multiple steps in practice, such as inserting proof of multiple transactions into a single batch, verifying the integrity of the batch, and performing specific commit functions on the chain. After verification, the smart contract will update the latest stored state root. In this way, the Ethereum main chain stores only a small amount of proof-of-validity data, while the majority of computation and transaction data is stored on Layer 2, thus 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 doctor so that each retains their own information, based on the visit information, the doctor determines the EMR, based on the order of loading the data sent to the ZK Smart contract, after processing the contract, after queuing the Ethernet main chain, at this time the Ethernet information is only the index (summary) of this data. Subsequently, the index of this data can be inserted into IPFS to further free the contents of the chain and keep the data flow smooth.
Figure 3
Figure 4 shows the process when the patient or doctor requests medical data, uploading their own proof of public-private key pairs to ensure its legitimacy and security, then the request will be processed into the contract, and after sending it to the main chain to generate an index , the index can be used to search for the required data in the framework.
Figure 4
Interaction between patient and doctor node with blockchain and IPFS network.