2.1. Research questions

We have initially realized that sharing data through blockchain is challenging, even when utilizing private blockchains which impose less restrictions compared to public ones. Thus, one of the goals of this research is to actually see if the use case of blockchain for data sharing is sensible, of course based on the current state of the blockchain technology. If this implementation is relevant, we would carefully select all the different technologies to achieve this data sharing, ranging from the actual blockchain itself, the off-chain technology supporting the blockchain, etc. If it’s not relevant, we could show it by comparing the metrics (e.g., related to performance and security) between a blockchain-based data sharing scheme and a more traditional peer-to-peer system, for example, based on IPFS which is a protocol and network designed for storing and sharing data in a distributed file system. IPFS uses content addressing to uniquely identify each file in a global namespace, connecting all computing devices (Benet, Reference Benet2014).

As previously mentioned, it is clear that utilizing blockchain as the sole technology for a data sharing platform would be difficult. Thus, we want to see how far can the blockchain go as a standalone data sharing technology before mixing it with an off-chain technology to actually handle the aforementioned limits. This is the goal of this research question:

The work on the previous research question will also prove useful as a starting point for the next one. Now that blockchain is a valid solution for patient’s data collection and sharing, we jump to our next research question on how to customize incentives in a medical data sharing blockchain platform.

Once the data are collected by patients, in order to assure data quality, we need to implement a schema for data cross-validation. This brings us to our next research question:

2.2. Hybrid on-/off-chain blockchain solution

On-chain data sharing, which refers to data storage and processing directly on the blockchain, has several limitations that can hinder its efficiency and scalability. Some of these limitations include:

• • Scalability: On-chain data storage can be inefficient for large-scale applications as every piece of data is recorded on the blockchain, leading to increased block size and slower transaction times.

• • Cost: Storing data on the blockchain incurs transaction fees and requires more gas consumption, making it expensive, especially for large volumes of data.

• • Privacy: Public blockchains have transparent and immutable data, which can compromise the privacy and security of sensitive information.

• • Storage capacity: Blockchain’s decentralized nature means that every node must store a copy of the entire blockchain, which can lead to storage capacity issues, especially for data-heavy applications.

• • Regulatory compliance: Storing sensitive or personally identifiable information on the blockchain can create challenges regarding compliance with data protection laws and regulations.

To overcome these limitations, off-chain technologies are utilized to complement on-chain data sharing solutions. Off-chain technologies involve storing data outside the blockchain while still maintaining a connection to the blockchain for security and verification purposes. Here’s how off-chain technology improves data sharing solutions:

• • Scalability: By moving data off-chain, the burden on the main blockchain is reduced, improving scalability and speeding up transaction times.

• • Cost efficiency: Off-chain solutions often offer lower transaction costs, making data sharing more affordable, especially for applications that require large data storage.

• • Privacy: Off-chain solutions can use encryption and access controls to protect sensitive data, providing better privacy and security than on-chain storage.

• • Storage capacity: Storing data off-chain allows for more flexible storage options, including utilizing cloud-based solutions, which can easily scale as needed.

• • Regulatory compliance: Off-chain solutions can incorporate data governance mechanisms and comply with data protection regulations more effectively, as data can be more easily controlled and audited.

By combining on-chain and off-chain technologies, developers can create hybrid solutions that take advantage of the strengths of both technologies. This approach is known as layer 2 scaling solutions, where most transactions occur off-chain, but their validity is anchored to the main blockchain, providing a balance between efficiency, security, and data management for decentralized applications. Layer 2 scaling solutions are in fact technologies that aim to address the performance limitations of blockchain systems. These solutions operate on top of the base layer of the blockchain and provide mechanisms for increasing transaction throughput and reducing transaction fees without modifying the underlying blockchain structure (Hafid et al., Reference Hafid, Hafid and Smith2020). Examples of layer 2 scaling solutions include state channels, sidechains, and off-chain computation networks like Plasma and Rollups, ZK-rollups, optimistic rollups, computing oracles, and privacy-preserving blockchain solutions (Hafid et al., Reference Hafid, Hafid and Smith2020).

There are multiple on-chain metrics that allow for a benchmarking of blockchain. Indeed, tools such as Santiment, Covalent, or Etherscan provide many metrics that all serve a certain purpose. For the first research question, we focus on the ones that actually allow for bigger security in the broad sense, as security in a blockchain network can signify different things and is not a clearly defined concept. By finding and optimizing those metrics, the solution will undeniably suffer in other categories, such as throughput of data.

As a matter of fact, we aim to investigate these metrics, parameters, and overall functionalities by such a hybrid on/off-chain blockchain solution. We look at customization as a dynamic or adaptive strategy to determine when/how/what data should be stored on-chain or off-chain to face the trade-off between performance and security. We explore the relevant research questions and the metrics/parameters by implementing a proof-of-concept solution using Hyperledger-fabric and IPFS (see Behfar et al., Reference Behfar, Théodoloz, Schranz and Hosseinpour2023). This leads to a balance customization problem depending on the data amount required to be on-chain, the infrastructure, the performance requirement, and some other metrics. Finally, it offers an optimal solution for data sharing; by passing the data type, volume, and chain metrics manually as input parameters, one could provide the best configuration in terms of performance and security.

2.3. Customizable incentive

Medical data sharing even using blockchain technology is not a new topic of research, but our solution provides innovation on how it performs it. Indeed, there are some projects that have studied and/or implemented a blockchain-based data sharing solution. The current state of the art is either focused on how the technology is used to implement the solution, on the tweaking and testing of certain setups to provide better metrics on that application, or on the implementation of incentives to ensure activity on the network. Thus, to the best of our knowledge, what we are trying to achieve has not been yet explored by any of the previously mentioned work. In our solution, the uniqueness comes from the way we tackle the incentive. The way this would work is by adapting the incentive for a data seller depending on the characteristics of his data. In a use case, we focus on patients with cognitive disorders, Alzheimer’s disease in particular, because it is an almost 20-year-long disease where obtaining chronological data is quite important. In addition, not only data obtention in different stages of this disease is critical, but also age, ethnicity, genetics, and other factors play a role. For instance, data from a European individual suffering from Alzheimer’s disease does not provide the exact same information as data from an Asian affected by the same disease. Also, while having a few years of data from those patients is useful, large chronological data are an invaluable asset for research purposes.

Thus, we need to encourage the owners of that kind of specific and rare data to share it, and that’s precisely what our customizable incentive would do. For every transaction made on the network, a small fee would be added to fill up an ETH pool (see Figure 1). The initial pool reserve would be covered by some of the research budgets. Our user structure would contain multiple attributes such as age, ethnicity, the actual disease, and the time range of the data. Our platform would track the most sought-after data and, when a user provides corresponding data to sell on the network, the base smart contract and the specific contract made with the buyer would automatically adjust the money received by gathering from the pool. Not to forget that, although test data need to be completely anonymous, we request the sellers to digitally sign some ethics formulaire that they are fully aware of how these data will be used.

Figure 1. Architecture of customizable incentive.

As we already stated, patients are the actual owners of the said data; this could be a debatable concept. If the patient signs a contract turning over the ownership of the data to the research facility, that‘s perfectly legal, and to argue about ethics is misguided and irrelevant. If one assumes, for the sake of argument, that patient has irrevocable and unassignable rights to their health data, the problem increases in complexity for the purpose of data sharing, as some patients may deny such sharing. Other studies have also discussed medical data ownership concept (see Mirchev et al., Reference Mirchev, Mircheva and Kerekovska2020). Zhang et al. (Reference Zhang, Wang, Zhang, Zhang and Zhang2022) have mentioned that if a patient wants to share his data, he should be able to do it as one stakeholder in this environment or ecosystem.

2.4. Cross-validation

Similar to our customizable incentive model for patients who provide rare data, we would take advantage of the same kind of incentive for data validators. The way it would work is with a reviewing system, where a set of network validators can review the data that are being uploaded on the network to verify if the formatting is good. Validators would get a score associated with their reviews. For example, if someone rates some data well while most of the others treat it as unusable, this particular validator will lower his personal score and, on the contrary, good reviews will increase his score. The reviews would also provide a bonus score for good review streaks. They would also not be consultable before a certain time, and would all be released at the same time, making them reviewable by the other members.

This implementation solves two problems at once: firstly, it’s obviously a way to automize cross-validation without needing to employ people for doing so, which also provides extra decentralization to our solution. This also prevents the usage of botting, as bots wouldn’t be able to consult other reviews to base theirs on. Also, the inner complexity of such health-care data would necessitate very sophisticated bots to provide good reviews consistently, and thus, they wouldn’t be able to benefit from the streak bonus and would most likely have their review score decreased at some point.

The only downside to this implementation is another reliance on the ETH pool, and we would need to make sure that it is sufficiently filled up to pay both the data sharers and the data validators. A solution to this problem is an alternative incentive for data validators by giving them an equivalent status to the premium members (see Figure 2). They would get, instead of money from the pool, a priority on the data they are most interested in, which would alleviate some of the pressure on the pool.

Figure 2. Illustration of the data validation process.

We need to define the best blockchain to use for our implementation process. For that, we have chosen to implement Hyperledger Fabric for its ease of use and its inner characteristics. Hyperledger Fabric is a private/permissioned ledger technology from the Linux Foundation which is commonly used to build enterprise blockchain solutions. It is in fact an open-source blockchain platform that provides a foundation for developing enterprise-grade blockchain solutions (Ullah et al., Reference Ullah, Mugahed Al-Rahmi, Alzahrani, Alfarraj and Alblehai2021). It is designed to be a permissioned blockchain, meaning that participants must be granted access and follow certain rules to join the network (Makhdoom et al., Reference Makhdoom, Zhou, Abolhasan, Lipman and Ni2020). Hyperledger Fabric distinguishes itself from other blockchain technologies by having a modular architecture that separates the blockchain ledger and the world state, which is a database that keeps track of the ledger states (Makhdoom et al., Reference Makhdoom, Zhou, Abolhasan, Lipman and Ni2020). We also look at more options such as Multichain, IBM blockchain, and Proprietary blockchain for “hybrid” solutions. In our future works, we are also going to explore the possibility of utilizing public blockchain to increase the security and the decentralization aspect of our solution. In our current case, Hyperledger Fabric is very adapted to the platform we build for multiple reasons:

• • It is highly configurable, which means we can easily adapt the technical specifications of the blockchain according to the results of the study. One example of that is what they call “pluggable consensus protocol,” which basically allows for a fully customized consensus depending on our needs. For instance, the framework comes with a pBFT (Practical Byzantine Fault Tolerance) consensus implementation, which might be a good fit to our application. Indeed, it allows for high throughput and good security at the expense of high scalability which might not be necessary in our case.

• • It is permissioned, which allows for the users of the application to have a certain level of trust in the system without having to use some more expensive/energy-unfriendly blockchains like Ethereum, which is also commonly used for application-focused blockchain solutions.

• • It uses a “channel”-based architecture where we can ensure that only the participants of this particular channel can see the data that are being transferred, which is not only crucial but very adapted to our core idea in medical data sharing scenario.

For the configuration, we need to define a few criteria such as the creation of the previously mentioned channels, but also the configuration of the base network to start the customization.

As previously mentioned, Hyperledger is an open-source distributed ledger framework enabling the development of smart contracts and decentralized applications. Unlike Bitcoin or Ethereum networks, where anyone can freely create and own a node to join the network in order to secure it and be rewarded for this work, Hyperledger is a private blockchain and is only accessible by the users, recognized parties, and the members of a channel; see the online resource in the reference “Hyperledger Fabric, A Blockchain Platform for the Enterprise.” The operation is based on a majority consortium that takes place during the validation of transactions. Here, the players are all considered “in good faith”; there is no consensus based on proof of work or proof of stake. The advantage of Hyperledger among its competitors lies in the many customization possibilities of the system. We can cite the choice of the consensus algorithm, the management of access to data, or the channels, acting as a compartment for communications between the different organizations. Indeed, the modularity as well as the flexibility of Hyperledger has a price to pay, which is the difficulty of the implementation. In order to understand better the Hyperledger transaction process, Nijssen and Bollen (Reference Nijssen and Bollen2019) made it quite illustrative.

2.5. Methodology and implementation theory

Data monetization in a blockchain platform involves various mathematical formulas and calculations to determine data pricing and economic incentives. Below are some key math formulas used in data monetization on a blockchain platform:

• - Data pricing formula

Data pricing can be calculated based on factors such as data quality, uniqueness, demand, and supply. A basic formula for data pricing can be

$$ Data\_ Price= Base\_ Price+ Quality\_ Factor+ Uniqueness\_ Factor+ Demand\_ Supply\_ Factor, $$

where:

Base_Price: A fixed base price set by the data provider (based on certain medical test data).

Quality_Factor: A factor representing the quality or accuracy of the medical data.

Uniqueness_Factor: A factor representing uniqueness or exclusivity of the data (how rare medical data is).

Demand_Supply_Factor: A factor representing the demand and supply dynamics of the medical data in the marketplace.

• - Data usage metrics formula:

Data usage metrics can be used to measure the utilization of data by consumers. A simple formula for data usage metrics can be

$$ Data\_ Usage\_ Metrics= Usage\_ Time+ Usage\_ Frequency+ Insight\_ Derived, $$

where:

Usage_Time: The total time for which the data were accessed by consumers.

Usage_Frequency: The frequency of access to the data by consumers.

Insight_Derived: A measure of the specific insights or value derived from the data.

• - Data privacy formula:

Data privacy is a critical consideration in medical data monetization. Blockchain-based techniques, such as homomorphic encryption or zero-knowledge proofs, can be used to ensure secure data sharing while preserving patient privacy. The specific formulas depend on the encryption and privacy-preserving techniques used.

• - Homomorphic encryption formula:

Here, we assume there is a medical data value x that needs to be encrypted for sharing, and the encryption function is denoted as E(x). The formula for homomorphic encryption can be represented as

$$ Encrypted\_ Data=E(x). $$

With homomorphic encryption, the blockchain platform or data consumers can perform specific computations on the encrypted data without knowing the actual value of x. The encrypted data can be stored on the blockchain or shared among authorized parties, and operations can be performed on it in its encrypted form. For example, consider a basic arithmetic operation on encrypted data:

Addition: Suppose we have two encrypted medical data values, E(x) and E(y). The blockchain platform can perform an addition operation on the encrypted values without decrypting them:

$$ Encrypted\_ Result=E(x)+E(y). $$

The result of the addition, Encrypted_Result, will still be in encrypted form, ensuring that the actual values of x and y remain private. By employing homomorphic encryption or other privacy-preserving techniques, blockchain-based medical data sharing platforms can enable secure and confidential data sharing while maintaining patient privacy. It allows authorized parties to perform computations on encrypted data without compromising the sensitive information contained within it.

Here, we explain this system with detailed steps to better comprehend how the cross-validation process works:

1. 1. A patient wants to sell his data. He inputs it on the platform and some nodes that flagged themselves as volunteer validators get access to some bits of data.

   This last point is very important: we cannot give access to the entire data as this would imply the reviewers could basically steal the data instead of reviewing it. Getting snippets of the data is sufficient to evaluate whether or not the data are formatted nicely, but it also diminishes its size which is critical as it would most likely be inserted in a smart contract transaction. This also means that the final data uploaded on IPFS would not be changed, but it needs to be validated as good before being actually uploaded.

2. 2. The system checks the volunteer reviewer count. The review score mentioned in the former step would depend on the count: the more reviewers there are, the bigger (exponentially) the final score, and thus, the final incentive. The reasoning behind this is to avoid the scenario where a single reviewer or a very small number of them that could actually be collaborating together provide a botched review, for example, by people not actually knowledgeable in the field or misleading, for example, flagging good data as bad purposely. That also prevents botting to some extent, as bot-made reviews would be flagged as bad by other reviewers.

3. 3. The reviewers analyze the data with the process being made outside the platform and review it. When they are done, they upload a review tied to the data and the second review process begins. The reviewers would now go through the other reviews that have been done and give them a pertinence score (on the visual workflow, this is the percentage). Note that reviewers would purposely not be placed in the same review process multiple times before a certain amount of time has passed to prevent self-serving team motives.

4. 4. There are now two possibilities:

   1. a. Everybody agrees that the data are bad, and the reviews all mention it. It would, thus, not be uploaded on the platform, and the reviewers would all share a base remuneration for their work coming from the ETH pool (with the amount depending on their score).

   2. b. The data are good, and some reviews explain the reason based on the knowledge of the reviewer. Each reviewer, by evaluating colleagues’ reviews, gives a score to the said reviews. Depending on the quality of the review, every reviewer would get a personal score, adding up with each review they make on the platform and further increasing with good review streaks. The higher the score, the more money they get from reviewing. As such, it encourages activity on the network but also prevents bad reviews with the possibility of diminishing one’s score.

      There’s also a sub-possibility that involves giving priority to data purchase instead of money to the reviewers. The reason is to prevent the ETH pool running out of money for sellers’ incentives, which is the main goal of this project. Indeed, with the pool’s money coming from transaction fees, it is possible that, depending on the activity on the network, it doesn’t contain a lot of tokens. This is also something that the dynamic incentive would take into consideration when assigning the extra gain on a data sale.

We use the following parameter(s) and get the following output(s) (Table 1):

Table 1. List of input parameters and the outputs

By inputting information such as the disease, one is affected by, and the time range of the said disease and providing the data about it, the patient can enter the network. There would be an initial gas fee for doing so, but that could be either covered by the ETH pool or be added as a fee for the buyer to cover the expense. Different parameters would be mapped to certain filters, which would allow potential buyers to better look for them on the platform.

2.6. Differential privacy

Applying differential privacy to blockchain-based medical data monetization involves implementing privacy-preserving techniques that protect individual data privacy while allowing the use of aggregated data for monetization purposes. Here’s how one can achieve this:

• - Data aggregation: Instead of sharing raw individual medical data, blockchain-based systems can perform data aggregation on the blockchain. Aggregated data hides specific details of individuals while retaining useful insights for monetization and analysis.

• - Noise addition: One of the core principles of differential privacy is adding controlled random noise to the aggregated data. This noise obscures individual values, ensuring that the presence or absence of a single individual’s data does not significantly impact the aggregated results.

• - Smart contracts and consent management: Implement smart contracts on the blockchain to manage data sharing and consent. Patients should provide informed consent for their data to be used for monetization purposes, and smart contracts can enforce the terms of consent.

• - Data budget: Set a privacy budget or threshold to limit the amount of privacy loss that can occur during data aggregation and monetization. This ensures that the cumulative privacy loss remains within an acceptable limit over time.

• - Access control: Enforce access control mechanisms through smart contracts to restrict data access only to authorized parties who have the required consent from patients. Access can be granted based on predefined terms and conditions.

• - Regular auditing and monitoring: Regularly audit and monitor the blockchain-based system to ensure that privacy measures are correctly implemented and privacy guarantees are maintained. Any potential breaches or privacy risks should be promptly addressed.

• - Collaboration with privacy experts: Designing and implementing a differential privacy mechanism requires expertise in privacy-preserving techniques. Collaborating with privacy experts ensures that the system meets privacy standards and best practices.

• - Transparency and communication: Transparently communicate with patients about how their data will be used, aggregated, and protected. Maintain open communication about the benefits and risks of data monetization and how privacy is being safeguarded.

By incorporating these measures, blockchain-based medical data monetization can achieve a balance between preserving individual privacy and enabling valuable data monetization opportunities. Differential privacy techniques provide a strong foundation for ensuring that patient data remain protected while still allowing researchers, pharmaceutical companies, or other stakeholders to derive valuable insights from aggregated data.

The mathematical formula for differential privacy in blockchain-based medical data monetization can be expressed as follows. A mechanism satisfies ε-differential privacy if, for all possible datasets D1 and D2 that differ in only one data point, and for all possible outcomes S in the output space of the mechanism:

$$ P\left(M(D1)\in S\right)\le {e}^{\varepsilon}\ast P\left(M(D2)\in S\right)+\delta, $$

where:

M(D1) represents the output of the mechanism when the dataset D1 is used.

M(D2) represents the output of the mechanism when the dataset D2 is used.

The probability on the left side represents the probability of the mechanism outputting result S using dataset D1, and the probability on the right side represents the probability of the mechanism outputting result S using dataset D2, with the additional privacy breach probability δ.

The ε parameter controls the privacy budget or the maximum allowable privacy loss, while the δ parameter represents the probability of the mechanism failing to provide ε-differential privacy. Smaller values of ε and δ indicate stronger privacy protection and lower risk of privacy violations, respectively.

In the context of blockchain-based medical data monetization, differential privacy techniques are applied to ensure that the presence or absence of individual data points does not significantly impact the monetization results while preserving the privacy of the participants’ medical data. By controlling the values of ε and δ, stakeholders can strike a balance between privacy and the utility of aggregated data for monetization purposes.

3.1. Creation of the Ethereum-based platform

This is basically where all the configuration is going to be done to start working on the most innovative part of our solution. As previously mentioned, the blockchain we use for this project is going to be Ethereum. Thus, there are a few tools we will need to first install and configure in order to create our decentralized platform such as wallets for the transactions and tools for the development. The tools that we chose are considered standard for Ethereum-based DApps (decentralized applications):

• - Truffle: framework for DApp development contains:

• - Solidity: the language that we use to develop our smart contracts.

• - Ganache: simulator that comes with a local blockchain and fake Ethereum addresses loaded with ETH. It allows for testing without having to wait nor pay gas fees.

• - Metamask: a reliable Ethereum wallet for most usages.

The goal is to create a working implementation allowing for Ethereum transactions on a set of nodes. We also create an initial front end at this point to test things more easily and prepare the mapping with the blockchain through Metamask.

3.2. Blockchain incentive customization model on the platform

Here is where a big part of the research is done. Indeed, we need to create the final model for our customizable incentive, which involves medical research, thorough calculation, tests, and calibration. Indeed, the flexibility of the model depends on many factors, so a lot of thinking still needs to be done to have a balanced yet appealing solution for end users. We need to assure that the model is working properly, which means we need to develop all the features and components of the model and map everything with IPFS to answer the following research questions:

• • How is it possible to store chronological medical tests via patients onto a hybrid on-/off-chain blockchain platform?

• • How is it possible to customize incentives in a medical data sharing blockchain platform based on quality and scarcity of data?

3.3. Medical data cross-validation and mainnet implementation

Some of the implementation part to create our cross-validation framework has already been done in the prior section. Here, we also do calculation, test, and calibration for the most part, but in relation to the review system for the cross-validation instead of the base customized incentive. When the cross-validation model is finished, we add it to the base solution and run some tests. Here, we work on the research question RQ3: How do we implement a framework for medical data cross-validation based on customizable incentives according to data anomaly?

Here are the steps for the creation of the cross-validation framework: