# Blockchain-Empowered Trustworthy Data Sharing:
Fundamentals, Applications, and Challenges

Linh T. Nguyen, Lam Duc Nguyen, Thong Hoang, Dilum Bandara,
Qin Wang, Qinghua Lu, Xiwei Xu, Liming Zhu,
Petar Popovski, and Shiping Chen Linh T. Nguyen was with Posts and
Telecommunications Institute of Technology, Hanoi 10000, Vietnam. Email:
<EMAIL_ADDRESS>Nguyen, Dilum Bandara, Qin Wang, James
Hoang, Qinghua Lu, Sherry Xu, Liming Zhu, and Shiping Chen are with CSIRO
Data61, Eveleight 2015, Sydney, Australia. Email: {lam.nguyen, james.hoang,
dilum.bandara, qinghua.lu, Xiwei.Xu, liming.zhu<EMAIL_ADDRESS>Petar Popovski is with the Connectivity Section, Department of Electronic
Systems, Aalborg University, Aalborg 9220, Denmark. Email<EMAIL_ADDRESS>Corresponding Author: Lam Duc Nguyen

###### Abstract

Various data-sharing platforms have emerged with the growing public demand for
open data and legislation mandating certain data to remain open. Most of these
platforms remain opaque, leading to many questions about data accuracy,
provenance and lineage, privacy implications, consent management, and the lack
of fair incentives for data providers. With their transparency, immutability,
non-repudiation, and decentralization properties, blockchains could not be
more apt to answer these questions and enhance trust in a data-sharing
platform. However, blockchains are not good at handling the four _Vs_ of big
data (i.e., volume, variety, velocity, and veracity) due to their limited
performance, scalability, and high cost. Given many related works proposes
blockchain-based trustworthy data-sharing solutions, there is increasing
confusion and difficulties in understanding and selecting these technologies
and platforms in terms of their sharing mechanisms, sharing services, quality
of services, and applications. In this paper, we conduct a comprehensive
survey on blockchain-based data-sharing architectures and applications to fill
the gap. First, we present the foundations of blockchains and discuss the
challenges of current data-sharing techniques. Second, we focus on the
convergence of blockchain and data sharing to give a clear picture of this
landscape and propose a reference architecture for blockchain-based data
sharing. Third, we discuss the industrial applications of blockchain-based
data sharing, ranging from healthcare and smart grid to transportation and
decarbonization. For each application, we provide lessons learned for the
deployment of Blockchain-based data sharing. Finally, we discuss research
challenges and open research directions.

###### Index Terms:

Blockchain, Data Sharing, Data Privacy, Privacy-preserving, Federated
Learning.

##  I Introduction

###  I-A Motivation

“Data is the new oil”, a tremendously valuable and untapped asset in the 21st
century [1]. Today, every individual, business, and government needs data to
offer, and improve their services and applications regardless of the
discipline. However, data silos held by individuals and organizations are not
diverse and significant enough to serve the needs of complex tasks such as
training machine learning (ML) models [2, 3] or supply chain management (SCM)
[4]. Therefore, _data sharing_ has emerged to make data available to one or
more individuals or organizations to maximize the value of the data and
provide more robust data pools. The more data organizations hold via data
sharing, the higher the chance they could maximize their business and social
value. There is a growing public demand for shareable data to reach such
broader business and societal benefits. Governments also support this demand
by mandating certain data types remain open and shareable through legislation.

Data sharing motivates parties to connect, collaborate, and provide more
significant insights leading to better decision-making processes [5]. For
example, in healthcare, data sharing can reduce emergency department
admissions, repeated doctor visits, and patient worries [6, 7, 8]. Sharing
medical and health data helps doctors gain more information about a patient’s
medical and drug histories, thereby reducing diagnosis errors, medication
errors, duplicate testing, and complicated document administration [9].

Cloud service providers (CSPs) have emerged as a scalable and cost-effective
platform for generating, collecting, storing, and sharing data that possess
the four Vs of big data, namely volume, variety, velocity, and veracity [10].
The use of CSPs, however, leads to several limitations and security/privacy
concerns. First, due to a general lack of trust in sharing data with others
and data sovereignty concerns, most users hesitate to store their sensitive
data in the cloud [11]. Second, due to the multi-tenancy paradigm, multiple
customers are simultaneously vulnerable to attacks [12]. Finally, customers’
data may be leaked, manipulated, and illegally exploited for profit by
insiders [13]. The challenges in managing data sharing stem from the reliance
on centralization for storage, sharing, and access to the data. However, this
approach is only effective if the central storage, networking infrastructure,
and data access control (DAC) services are functioning and well-equipped.
Previous research [14] has shown that data custodians face difficulties
setting up central data access management. Moreover, the manual nature of
traditional data sharing and access makes it difficult to monitor and enforce
data consent and data access agreements. Furthermore, centralized platforms do
not allow for the active involvement of various stakeholders, including
individuals and organizations, in the management of data sharing.

With the emerging need for distributed data sharing, a spectrum of blockchain-
based solutions is being proposed to build decentralized, trustworthy, and
transparent data-sharing environments [15]. On one end of the spectrum, all
collected data are stored in the blockchain, and all access to the data is
recorded as transactions in the distributed ledger in a redundant manner, and
each miner verifies these transactions. This enhances the immutability,
transparency, non-repudiation, and decentralization of a data-sharing
platform, making it challenging for malicious parties to attack and manipulate
the data for their advantage. Besides, blockchains help solve the problem of
sharing data in heterogeneous systems by having a unified data model and
interface [16]. However, realizing the limited performance, scalability,
privacy concerns, and high cost of the current blockchain technology, the
other end of the spectrum uses blockchains only to facilitate the data-sharing
business process without storing data on-chain. Therefore, exploring the
emerging spectrum of blockchain-based data-sharing platforms is imperative.

###  I-B Related Works

Driven by the rapid innovations in blockchains, a plethora of studies have
been conducted to review and survey related topics. However, a survey and
taxonomy on data-sharing topics are still missing. For instance, a line of
works covers key concepts like blockchain architecture [17, 18, 19, 20],
system components [21, 22, 23, 24], properties [25, 26, 27, 28], consensus
algorithms [29, 30, 31], and further analyzes blockchain applications in
various domains from healthcare, smart grid to supply chains [32, 33, 34, 35,
36, 37, 38]. In [20], authors present distributed ledger technology (DLT)111In
the scope of this paper, we use Distributed Ledger Technologies (DLTs) and
Blockchain interchangeably. and blockchain properties, architecture, etc., and
provide instruments to decide when, which, and how to use and deploy
blockchains.

For example, Sanka et al. [26] focused on related concepts in cryptography and
applications like the Internet of Things (IoT) and banking with various
quantitative surveys and analyses. Meanwhile, the survey in [38] presented
blockchain-based smart contracts, underlying technologies, and atop
applications. Besides, security and privacy are two major concerns needing to
be investigated, and blockchain is of no exception. In [27], the authors
conducted the first systematic examination and survey on security risks and
attacks on blockchain platforms, with potential research directions in this
field.

Many related works explore the applicability of blockchains in real-world
applications (e.g., IoT and healthcare). In [32, 33, 34], motivations for
integrating blockchains and IoT under different schemes are analyzed, as well
as potential advantages, challenges, and applications are discussed. Mollah et
al. [35] discussed blockchain’s contribution to smart grid applications, e.g.,
applicability in advanced metering infrastructure. The authors also discussed
the features and drawbacks of multiple blockchain-based industrial solutions
for smart grids. Agbo et al. [37] conducted a systematic review in which they
discussed questions about blockchain use cases in healthcare and presented
blockchain-based healthcare applications and their challenges and limitations.
From the application perspective, the use of blockchain combined with secure
storage and access, the Internet of Medical Things, and Federated Learning
(FL) for medical data sharing is studied in [39]. Moreover, Wan et al. [40]
identified the influences for the use of blockchains for data sharing by
reviewing a large number of literature.

In Figure 1, we summarize the number of related research papers that appeared
between 2019 and 2022 as reported by the Dimensions AI software [41]. The
number of publications on blockchains and blockchain-based data sharing
increases each year. This indicates the trend of blockchain and data-sharing
technologies, as well as the need and significance of this survey and taxonomy
study. We conducted research on the number of publications with four specific
keywords, namely, _"Cloud and Data Sharing", "Blockchain and Data Sharing",
"Blockchain", and "Data Sharing"_. The fact is that the studies have related
keywords of data sharing via cloud techniques and using Blockchain is just
over _1000_ publications. Meanwhile, there are a tremendous number of research
about Blockchain, and the _"Data Sharing"_ keyword is mentioned around
_12000-14000_ publications. As suggested by much literature above, blockchains
are projected to bring new opportunities to mitigate risks and threats in
terms of privacy and security, i.e., availability and integrity, for data
sharing compared to centralized approaches. Table I presents a detailed
comparison between our survey and previous studies.

Figure 1: Number of annual publications on blockchains (BC) & data sharing (DS) Table I: Existing surveys on blockchain-related topics and our research contributions. Topics |  Ref |  Key Contributions |  Differences From Our Research
---|---|---|---
Blockchain concepts |  [17, 18, 19] |  A survey on blockchain design, characteristics, consensus algorithms, applications, research challenges, and future directions. |  Lacks deep analysis on applications and does not cover blockchain-based data-sharing applications.
[20] |  A survey on DLT and blockchain designs, consensus algorithms, and answering three questions when which, and how to apply blockchain. |  Lacks application guidelines and does not cover blockchain-based data-sharing applications.
[38] |  An extensive survey on specific applications, research challenges, and future works on smart contracts. |  Focuses on smart contract technology.
Blockchain & security |  [27] |  A systematic survey on security threats and attacks on blockchain platforms, along with potential solutions to enhance security. |  Focuses on security aspects of blockchains.
[42] |  A survey on blockchain security at process, data, and infrastructure levels from the perspective of information systems. |  Concentrates on the security aspects of blockchains.
Blockchain & privacy |  [25] |  A survey on privacy issues in blockchain platforms, along with possible cryptographic defense mechanisms and future research directions. |  Focuses on the privacy aspects of blockchains.
Blockchain & IoT |  [32, 33, 34] |  The applicability of integrating blockchain and IoT, issues, advantages, and applications are discussed. |  Focuses on the applications of blockchain in IoT in general.
[35] |  A survey on using blockchain for future smart grid: requirements, opportunities, and challenges. |  Mainly discusses the applications of blockchain in smart grids in general.
Blockchain & healthcare |  [37] |  A systematic review on blockchain use cases in healthcare, applications, and research challenges. |  Mainly discusses the role of blockchain in healthcare.
[39] |  A review of the development of blockchain-based medical data sharing |  Lacks detailed architecture and techniques for data sharing in healthcare.
Blockchain, data sharing, & supply chain |  [40] |  A systematic review on impacts, potential challenges, and future work of applying blockchain for data sharing in supply chains. |  Lacks data-sharing architecture and applications, and only discusses aspects of data sharing in the supply chain.
Blockchain-based data sharing |  _Our survey_ |  An extensive survey on blockchain-based data sharing:  • We present an overview of the data-sharing topic, including fundamental concepts, diversity, and limitations, and We discuss the need for leveraging blockchains in data sharing. Then, we introduce a reference architecture called _BLockDaSh_ , which can be used widely for data-sharing applications. • To our best knowledge, this is the first survey and taxonomy on leveraging blockchain/smart contract technology for sharing data in diverse applications, i.e., healthcare, supply chain, transportation, smart grid, data marketplace, and industry. • Fine-grained tables of classification and key lessons learned are presented to provide insights into blockchain-based data-sharing solutions. More details of contribution are given in the text. |

###  I-C Contributions

Even though emerging blockchain technology has accelerated the data-sharing
deployment process, many significant challenges still exist. This manuscript
takes a closer look at the design and applications of blockchain-based data-
sharing deployments. To the best of our knowledge, even though several surveys
and literature reviews have been proposed (Section I-B), they mainly discuss
general blockchain constructions or the specific data-sharing scenario. Any
work focusing on the status of combination, usage, and applications between
blockchain and data sharing is still absent. It is beneficial to draw a clear
roadmap to help learn the ways of adopting blockchain technologies, with
appropriate nature and properties, for data sharing in environments with low
or no trust. Moreover, the applicability of blockchain for data sharing in
applications such as transportation, data marketplace, decarbonization, and
digital industries has not been explored [39, 40]. To fill this gap, we
conduct a survey and taxonomy on blockchain-based data sharing. The main
contributions of this paper are highlighted as follows:

  1. $\triangleright$

First, we _present an overview of data sharing_ , including concepts, types,
and limitations. Then, _we provide an overview of DLTs and blockchains_ ,
including their classifications (types and properties), fundamental components
(smart contracts and storage), and related techniques (e.g., privacy-
preserving techniques).

  2. $\triangleright$

Second, we _focus on exploring the need for applying blockchain technology in
data-sharing solutions_ and accordingly _design a reference architecture for
blockchain-based data sharing, called BlockDaSh_. The proposed _BlockDaSh_
provides a structural construction for a data-sharing solution and includes
key building blocks and layers (majorly on data processing, sharing, and
storage). We also discuss how the reference architecture can be adapted for
different application scenarios.

  3. $\triangleright$

Third, we _delineate an in-depth taxonomy of blockchain-based data-sharing
applications in multiple use cases._ Specifically, we emphasize the cases as a
set of scenarios that closely relate to users’ daily needs (measured by
frequency, convenience, and importance), including healthcare, supply chain,
transportation, smart grid, data markets, education, government, and
decarbonization.

  4. $\triangleright$

Specifically, _we provide detailed lessons learned from deploying Blockchain-
based data-sharing schemes to various domains_. The lessons learned provide a
guideline for deployments of Blockchain-based data-sharing schemes in these
applications.

  5. $\triangleright$

We _discuss open research issues and potential research directions_ on these
approaches. We dive into the analysis and discussions of the several critical
properties that contribute to data sharing and usage, covering connectivity,
security, privacy, incentive/punishment, scalability, and editability.

Figure 2: The organization for the paper’s content

###  I-D Paper Organization.

The organization of this paper is depicted in Figure 2. First, we present the
background on data sharing and blockchain technologies in Section II and III,
respectively. In Section IV, we present a reference architecture for
blockchain-based data sharing, which can be applied in various application
domains. Next, in Section V, we present selected examples from these
application domains while discussing their designs and crucially evaluating
their abilities to achieve data-sharing goals. Section VI discusses research
challenges and future directions. Finally, we conclude the paper in Section
VII.

##  II Data Sharing

Figure 3: Types of data-sharing architectures

This section introduces the basic concepts of data sharing and outlines the
limitations of existing data-sharing solutions.

###  II-A Introduction to Data Sharing

Data sharing is the practice of making data accessible to enhance its quality
and value. It involves the exchange of data among individuals, organizations,
and governments through various means, such as email, file-sharing software,
and disk drives. Advancements in technology have made data sharing faster,
more efficient, and more widespread. The growth of IoT devices and services
has further increased the number of potential data sources, reinforcing the
trend toward data sharing. By sharing data, organizations can gain valuable
insights, improve decision-making, and foster innovation. However, data
sharing also presents challenges related to privacy, security, and ethical
considerations that must be carefully addressed to ensure the protection of
sensitive information [43].

The data-sharing process involves two main entities: data providers (DPs) and
data requesters (DRs). DPs and DRs (Table II presents a list of abbreviations
used in the paper) can be individuals, businesses, or organizations. DPs own
meaningful data or don’t necessarily hold the data but they have the right to
access it and share it with third parties. Besides, they are willing to share
their data for non-profit purposes or monetize it. DRs aim to exchange data
with DPs to derive business insights, build services, or create products.
There are two main approaches to data sharing: 1) _direct data sharing_
between DPs and DRs and 2) _platform-based data sharing_ where DPs store data
in a local or third-party platform/repository (e.g., cloud storage) and set
rules and restrictions DRs’ accessing on the shared data. The first approach
is not scalable and raises serious security and privacy concerns. In addition,
with this kind of sharing, DPs lose control over the usage of shared data,
which poses potential risks for DPs, especially when sharing sensitive data.
Therefore, the latter approach has been considered an effective solution and
is widely applied in a variety of applications.

Table II: List of abbreviations used in the paper Acronym |  Definition |  Acronym |  Definition
---|---|---|---
API |  Application Programming Interface |  IIoT |  Industrial Internet of Things
ABE |  Attribute-Based Encryption |  IPFS |  InterPlanetary File System
B2B |  Business-to-Business |  ITS |  Intelligent Transportation System
CA |  Certificate Authority |  IV |  Intelligent Vehicle
CHF |  Chameleon Hash Function |  KSI |  Keyless Signature Infrastructure
CID |  Content Identifier |  ML |  Machine Learning
CP-ABE |  Ciphertext-Policy Attribute-Based Encryption |  MPC |  Multi-party Computation
CSP |  Cloud Service Provider |  OBU |  Onboard Unit
dApp |  Decentralized Application |  P2P |  Peer-to-Peer
DAC |  Data Access Control |  PBFT |  Practical Byzantine Fault Tolerance
DAG |  Directed Acyclic Graph |  PET |  Privacy-Enhancing Technology
DDB |  Distributed Database |  PII |  Personally Identifiable Information
DHT |  Distributed Hash Table |  PoA |  Proof of Authority
DLT |  Distributed Ledger Technology |  PoW |  Proof of Work
DP |  Data Provider |  PPT |  Privacy-Preserving Technique
DR |  Data Requester |  PRE |  Proxy Re-encryption
DSP |  Data Service Provide |  RSU |  Roadside unit
DSV |  Data Shapley Value |  SCM |  Supply Chain Management
DUC |  Data Usage Control |  SHR |  Surgery Health Record
EHR |  Electronic Health Record |  SPOF |  Single Point of Failure
EMR |  Electronic Medical Record |  SCSSM |  Supply Chain Social Sustainability Management
ERP |  Enterprise Resource Planning |  TEE |  Trusted Execution Environment
FDI |  False Data Injection |  TET |  Transparency-Enhancing Technology
FL |  Federated Learning |  TPS |  Transactions per Second
FSC |  Food Supply Chain |  TSSS |  Threshold Secret Sharing Scheme
HACCP |  Hazard Analysis and Critical Control Point |  V2V |  Vehicle to Vehicle
HE |  Homomorphic Encryption |  VANET |  Vehicular ad-hoc Network
IA |  Information Asymmetry |  VECON |  Vehicular edge Computing and network
IoT |  Internet of Things |  zk-SNARK |  Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge

Data-sharing software architectures (cf. Figure 3) can be classified into two
main categories: centralized (e.g., cloud-based solutions) and decentralized
(e.g., FL, multi-party computation (MPC), or blockchain-based solutions). In
the centralized approach, DPs are limited to the scope of an individual, an
enterprise, or a small group of parties. All shared data are kept on a local
or a cloud server and are visible to the storage administrator. For example,
consider a company (i.e., a DR) wanting to develop an ML-based tourist
destination recommendation service. To train the ML model, it needs data from
sources ranging from travel agencies to local tourism authorities (i.e., DPs).
If the company can convince such parties to provide data, it can ask them to
upload their data to its cloud-based Dropbox [44] account (without losing
generality). Alternatively, DPs may share data via their Dropbox, allowing the
company to download their data. While most security issues can be overcome by
setting appropriate access controls for DPs and DRs, this approach is
vulnerable to a single point of failure, not scalable (e.g., high data volume,
velocity, and requires too many integrations at the central server), and
limits privacy (e.g., the administrator has access to all data and DPs lose
control of their data as soon as they are shared).

Conversely, the decentralized data-sharing approach can support many DPs
(e.g., thousands of IoT devices and parties) to join the data exchange
process. Shared data can be stored in a decentralized manner, e.g., in each
DP’s local storage, reducing system-wide data leakage and data breaches. For
example, FL has emerged as a decentralized and collaborative data-sharing
solution for training ML models while improving privacy and security [45, 46,
47]. The core idea of FL is that DPs (aka FL clients), such as IoT sensors or
institutions, collaboratively support the model training process with the
federated server without revealing their raw datasets [48, 49]. To begin a
training phase, the federated server (e.g., a DR in Figure 3) initiates a
naive model and distributes it to a selected set of DPs for partial training
tasks. DPs then conduct local training with the initial ML model and their
private data. Next, DPs send updated model weights or gradients to the
federated server. The server aggregates local updates and sends the upgraded
model back to a new-selected set of DPs for the next round. The training
process continues iteratively until desired performance metrics are met and/or
the ML model reaches convergence.

MPC is another potential approach for decentralized inter-organizational data
sharing using cryptographic techniques while maintaining the privacy of inputs
[50, 51]. MPC typically makes use of the idea of homomorphic encryption (HE),
which allows computing on encrypted data without having to decrypt them [52].
MPC decreases the reliance on third parties as the computation is performed
locally. Unlike FL which shares model weights after each iteration, MPC only
shares the final result with DRs after the complete calculation round.
Moreover, the final result is composed of encoded original data fragments.
Therefore, MPC is deemed to have a higher level of privacy and security than
FL.

###  II-B Limitations of Current Data-sharing Solutions

Although existing data-sharing solutions offer salient features, they pose
several challenges as follows:

  * •

_Centralization._ When shared data are collected, stored, and processed in a
central server managed by a single party, it leads to security, privacy, and
trust issues.

  * •

_Heterogeneity and interoperability._ As shared data are often collected and
gathered from various data sources in different data types and communication
protocols [53], it is challenging to process and exchange data between
vertical domains and organizations.

  * •

_Resource consumption._ In the centralized design, the central server needs
sufficient bandwidth and storage to handle aggregated data from multiple DPs.
The same concern exists, albeit to a lesser extent, also for the aggregated
server in FL, even though DPs do not provide raw data. In addition, as MPC
must produce a massive number of random numbers to prevent raw data from being
leaked, it requires significant computational resources, potentially lowering
the system’s performance. Moreover, transferring many messages among MPC
parties distributed across multiple locations increases communication delay
and costs.

  * •

_Security._ Due to the decentralization and heterogeneity of data sources, and
the central management and storage approach, current data-sharing systems are
vulnerable to breaches and attacks. Moreover, there are known cases of shared
data being modified, manipulated, or illegally exploited for profit by
untrustworthy central server operators, and malicious clients, who submitted
modified or misleading parameters, reducing the utility of the global model in
FL [13, 54].

  * •

_Privacy._ During the data exchange process, shared data containing personally
identifiable information (PII) may be intentionally or inadvertently leaked.
Furthermore, once data are shared, DPs lose control over their shared data
because they do not know what forms of data which DRs intend to collect, the
purpose of their data collection, and where and with whom the data will be
further shared. It leads to a high information asymmetry (IA) between DPs and
DRs and threatens the privacy of DPs. Regulations on data sharing have been
imposed to overcome some of these concerns, e.g., the Personal Data Protection
Act [55], the General Data Protection Regulation [56], and the Cyber Security
Law of the People’s Republic [57].

  * •

_Trust._ In an untrustworthy environment like the Internet, current solutions
bring uncertainty and threats to customers, especially due to the
aforementioned security and privacy issues. Consequently, there is a general
lack of trust across the entire ecosystem, ranging from DPs, DRs, data
subjects, and data aggregators to platform providers, inhibiting the
contribution and use of data.

Recent advancements in blockchain technology provide potential solutions to
overcome many of these problems such as centralization, heterogeneity, poor
interoperability, privacy, and security (e.g., integrity, availability, and
non-reputation) [58, 59]. Furthermore, blockchains can increase the provenance
of data and the traceability of data-sharing systems. After providing a
briefing on background knowledge about DLTs, blockchains, and privacy-
preserving methods in Section III, we then discuss how blockchain-based data-
sharing solutions leverage these properties.

##  III Background Knowledge

In this section, we present some background knowledge about blockchain
technology and privacy-preserving techniques (PPTS).

###  III-A Distributed Ledger and Blockchain Technology

Distributed Ledger Technologies. In recent years, we have heard various
buzzwords appearing in every media hype like Metaverse [60], cryptocurrencies
[61], or non-fungible tokens[62]. Their appearance has piqued the interest of
researchers from various disciplines, e.g. finance [63], technology [64],
economics [65] and management [66] to participate in the research and study.
And, DLT is the underlying underpinning of the explosion and rapid development
of these technologies. A distributed ledger is an immutable, transparent, and
decentralized data storage and transfer protocol that is maintained by a peer-
to-peer (P2P) network of participants. Besides, the network participants use a
consensus protocol to determine which participant has the right to update the
ledger and in which order. The ledger is updated using transactions that
contain a set of attributes like sender and receiver addresses, the amount of
cryptocurrency to transfer, a smart contract function to invoke and its input
parameters, and a digital signature. A distributed ledger can be structured as
a blockchain (i.e., a linked chain of blocks), directed acyclic graph (DAG)
[21], HashGraph, HoloChain, or Tempo [67].

In the first type of DLT, blockchain organizes transactions into blocks, which
are linked together by consensus mechanisms [68]. Differently, DAG technology
does not require miners to confirm and validate transactions like Proof of
Work consensus (PoW) does [69]. The DAG transactions are confirmed in the
sequential flow by nodes, which validated at least two of the previous
transactions on the ledger. Furthermore, a node’s transactions on the
distributed ledger database become more valid when this node validated more
preceding transactions. DAG is considered as an alternative approach to the
blockchain with greater improvements in terms of scalability and fee-less
nano-transactions. Next, for the hashgraph structure, transactions are stored
in a parallel structure on the same timestamp. With the support of gossip and
virtual voting protocols, the transaction is verified by nodes in the network
before being recorded in the ledger [70]. This structure stands out for its
small storage unit requirement and the fact that each node will be aware when
a consensus has been reached that the blockchain’s nodes are uncertain.
Especially, a much more decentralized-driven architecture, named Holochain,
intends to avoid using any global consensus protocol. Therefore, it provides
every node with its own chain and becomes an agent-centric structure [71]. The
last one, called Tempo, uses a technique known as sharding to divide the
ledger, which properly orders all of the network events that occurred. In
essence, transactions are recorded in the ledger according to the sequence of
events rather than the time stamp [67]. Until now, since BC is the distributed
ledger technology that is most commonly used, we mainly focus on BC technology
in this work.

Blockchain. Satoshi Nakamoto introduced the first blockchain, Bitcoin, in 2008
[68], and it was released in 2009 as the sparking platform for more than 10000
cryptocurrencies that have evolved since then [72]. blockchain is made up of
records of transactions or blocks that are chained together to form a tamper-
resistant ledger, and it allows for secure decentralized data storage in
distributed networks. As an element of the blockchain, each block consists of
a header and a body containing a batch of validated transactions. The header
of a block, in particular (except for the first, known as the genesis block),
contains an inverse reference pointing to a previous block. The hashed value
of the previous block is used as the inverse reference. This prevents
fraudulent actions because a change in any block in historical records
invalidates all blocks because all subsequent hashes change, and nodes in the
blockchain detect it. A block header also contains other fields such as
Version, Timestamp, MerkleRoot, or Nonce, counting on specific purposes.
Besides, different blockchains have different block size limits. For instance,
while the block size of Bitcoin is limited to 1 MB and is able to store around
2000 transactions, each Ethereum block has a target size of 15 million gas,
expandable to 30 million based on demand [68, 73, 74].

To form a distributed consensus between nodes, blocks and their transactions
are transmitted and verified across the network. When a transaction is
created, it is signed by the owner of the source assets, who possesses a pair
of public and private keys. Then, the transaction is broadcast to the entire
blockchain network, where each network node validates and propagates it based
on a list of criteria. Every node, known as a miner or validator, that
receives transactions from various sources, only forwards transactions to its
peers when it has already verified these transactions. This ensures invalid
transactions are immediately dropped. They will have a memory pool of verified
transactions for building blocks at the time. In addition, if a miner wants to
create a block, the distributed consensus problem must be solved. Therefore,
only miners who solve the consensus problem can broadcast their new blocks
across the network. Now, other nodes will participate in the block validation
process [75, 76]. When a block is proved to be eligible by any node who saw
it, it is appended to miners’ local chains where the miners have not solved
the consensus problem yet, via the inverse reference pointing to the parent
block. A block’s generator may claim a certain number of new coins as well as
fees collected from all enclosed transactions.

For example, in the case of Bitcoin, Alice and Bob create their own public and
private keys. They are able to share public keys with each other in the entire
network, while private keys are kept secretly. Alice wants to send two
bitcoins to Bob. To accomplish this, Alice must sign a transaction with her
private key containing the main information, such as transaction inputs and
outputs. This transaction is now broadcast to the Bitcoin network to wait for
verification. Then, miners in the network try to verify Alice’s transaction by
validating a list of criteria such as the signature in this one. If all
requirements are valid, the transaction is grouped into blocks with other
verified transactions by miners. Each node or miner works on solving a
difficult puzzle for its block in the PoW consensus algorithm. The first miner
who successfully completes PoW is permitted to propagate its newly-created
block to neighbors. After that, other miners will double checks this block
under shared rules. For instance, miners ensure that all transactions in the
proposed block are valid (e.g., the block size is within acceptable limits and
the first (and only) transaction is a coinbase generation transaction). Next,
they also check whether the new block points to its predecessor in the longest
chain. If it does, this block would be assembled into miners’ local chains.
Different miners will build upon it by referring to it as the prior block.
Eventually, as blocks are added to the longest chain, the transaction is
completed, and Bob receives Alice’s coins. The miner who creates the accepted
block receives a number of coins and transaction fees for their effort. The
entire process of a transaction working is illustrated in Figure 4.

Figure 4: The general working flow of a blockchain network.

###  III-B Key Properties of Blockchain

Blockchains have several unique properties that make them suitable for new
trustworthy and efficient ways of employing them [18, 77]. Following are some
of the key properties:

_Decentralization._ Blockchain is maintained and operated by a P2P network of
nodes rather than a single authority. With decentralization, everyone has
access to the blockchain network, can send transactions, and build blocks.
Moreover, users can securely store and share their assets on the blockchain,
and they can exercise full control over their assets using their private keys.
It eliminates the dependence on a trusted third party that is likely to lead
to a single point of failure, performance concerns, and censoring. For
example, in traditional payment systems, clients must rely on a bank to hold
their funds and wait for the bank’s authentication and validation before
completing transactions. If the bank network faces a large-scale attack (e.g.,
distributed denial-of-service) it could result in a single point of failure
and loss of funds.

_Immutability._ On blockchain platforms, any manipulation or attempt to tamper
with transactions would be detected and aborted by peers. The main reason is
that blocks are linked together, and each block header contains the hash of
the predecessor block. Specifically, the hash value of a block is computed
from its header content (e.g., its parent hash value and Merkle root hash that
act as a fingerprint of all transactions in the block) using a hash algorithm
like SHA-256. Therefore, if malicious entities attempt to modify any data in a
transaction, they must regenerate the new block hash to match the modified
transaction(s). Also, if any successor blocks are generated, attackers need to
regenerate each of them to match the predecessor’s new block hash. However,
depending on the consensus protocol adopted by the blockchain modifying a
chain of blocks is either computationally impossible or would require a
supermajority (typically more than 2/3) of votes or cryptocurrency held by the
blockchain peers. Therefore, a blockchain can be used to store data with high
a level of immutability.

_Transparency._ The content of transactions and the ledger state are visible
to all network nodes that validate transactions, build blocks, and store a
copy of the ledger. Such a high level of transparency helps blockchain-based
applications instantly identify non-compliant actions, operational mistakes,
and execution errors.

_Traceability._ Because all transactions and ledger state changes are
immutably recorded, timestamped, and transparent, a blockchain provides an
audit trail of activities on an asset or by a party [78, 18]. For example, SCM
systems use blockchains to track the provenance and chain-of-custody of goods
[79, 80]. _Non-repudiation._ A blockchain transaction must be
cryptographically signed by the sender and the signature is validated by all
network nodes before including in the leader. Hence, a party cannot repudiate
later that the transaction did not happen.

_Pseudonymity._ Blockchain transactions are recorded based on sender and
receiver addresses derived from the public keys. Hence, blockchain addresses
do not reflect the individuals or organizations behind a transaction. However,
through other means such as tracking IP addresses, analyzing payments and
withdrawals at centralized exchanges, and social media posts, it has been
possible to deanonymize transacting parties, particularly if addresses are
reused in multiple transactions. Hence, blockchain provides pseudonymity [81].

###  III-C Types of Blockchain Platforms

When developing a blockchain-based solution, it is necessary to determine
which type of blockchain is best suited for the project. Therefore, it is
critical to have a thorough understanding of blockchain structure
classifications.

Blockchain platforms can be broadly classified across two dimensions: 1) based
on the technical excludability of users (i.e., public vs. private) and 2) the
ability to perform activities such as validating transactions and updating the
protocol (i.e., permissioned vs. permissionless) [82, 83, 17, 84]. A _public
blockchain_ is accessible to the public for use, and provides incentives for
users to join, contribute computing power, and charge fees for the use. No
single entity owns or controls the entire blockchain [85]. A _private
blockchain_ is accessible only to a limited group of users for use and
typically sits within a physical or virtual private network. The network peers
are authorised by some centralized party or consortium and are not offered
explicit incentive mechanisms like paying transaction fees. Any blockchain
platform can be used as a private blockchain. In a _permissioned blockchain_ ,
pre-authorisation is required to perform a particular activity, such as
issuing transactions, validating them, and building a block. They may also
offer fine-grained permissions such as permission to create a particular
asset/data and execute a function in a smart contract. Conversely, in a
_permissionless blockchain_ , no such authorization is required to perform any
activity.

Based on these two dimensions, there can be four combinations of blockchain
platforms: public-permissionless, public-permissioned, private-permissionless,
and private-permissioned. _Public-permissionless blockchains_ , such as
Bitcoin and Ethereum, can be used by anyone to transact, validate
transactions, and build blocks. While they have the highest level of
transparency and security, they typically have lower transaction throughput
and higher latency to finalize a transaction. _Public-permissioned
blockchains_ , such as Ripple, Avalanche, and Algorand, allow anyone to
transact but only a pre-authorised set of network peers can validate
transactions. They still charge transaction fees. These blockchains tend to
have better transaction throughput, lower latency to finalize a transaction,
and lower costs compared to public-permissioned blockchains due to the lower
number of preselected peers involved in transaction validation. Conversely,
the lower number of peers and their selection by a centralized authority also
make them more vulnerable to traditional attacks, hence, are considered less
secure than public-permissionless blockchains [83, 86]. While a _private-
permissionless blockchain_ has pre-authorised network peers, those peers do
not need any further permissions to issue transactions. For example, Ethereum,
which is permissionless, can be used in a private network. Private networks
tend to have higher transaction throughput and lower latency to finalize a
transaction compared to public networks [87]. _Private-permissioned
blockchains_ , such as Hyperledger Fabric, have pre-authorised network peers
and users need to satisfy fine-grained permissions to transact. They are more
suitable for regulated industries (e.g., finance and healthcare industries)
where it is essential to know your customers. Hence, an approval process is
used before giving access to the blockchain, and further authorization is
required to issue transactions. Also, they offer the greatest level of privacy
[87]. This privacy and transparency trade-off needs to be balanced when
sharing data using blockchains [83].

When a group of organizations use a private blockchain it is typically
referred to as a _consortium blockchain_. Such blockchains are more accessible
than private blockchains, as they are partially decentralized. Moreover, most
consortium blockchains are private-permissioned; hence, have better privacy
properties. Because of the decentralization and better privacy private-
permissioned blockchains are more attractive for data-sharing use cases.

Hybrid blockchains combine properties of both private and public blockchains.
They are essentially sidechains that anchor to public-permissionless
blockchains to enhance data integrity [88]. This is achieved using approaches
like storing the Merkel Root hash of the ledger state or block hash of the
private blockchain on a public blockchain. Hybrid blockchains can be widely
applied for sharing data in application domains such as SCM, banking, and
governments.

###  III-D Smart Contract

A traditional contract is an agreement between individuals or organizations to
carry out a set of activities. Proposed in the 1990s by Nick Szabo, smart
contracts are digital programs where traditional contractual stipulations are
embedded into hardware or software, which automatically executes pre-agreed
contract terms under different constraints [89]. With the advent of blockchain
technology, smart contracts are being applied in a wide range of applications
(e.g., SCM and healthcare). A _smart contract_ is a set of executable codes
that represents an agreement between two untrustworthy entities without
reliance on a trusted third party [73, 90]. It is built above the ledger and
consensus layers of a blockchain architecture [91]. Applications that are
built while using smart contracts and the underlying business logic and data
storage are known as _decentralized applications_ (dApp) [92, 93].

Once deployed a smart contract is recorded immutably on the blockchain. Its
functions could be invoked by submitting a transaction to its address [38].
Distinct access controls can also be defined for each function in a smart
contract. When conditions in the contract are met, the corresponding actions
are enforced and executed automatically [94]. The updated states and recorded
on the ledger and the results are sent to the transaction issuer. Every peer
in the blockchain network keeps a copy of the smart contract in its local
ledger and executes the smart contract based on the transaction inputs. Like
data immutability, this hinders tampering attempts from malicious attackers.
By utilizing smart contracts, actions can be immediately enforced and executed
in a deterministic manner when certain pre-defined conditions are satisfied.
Therefore, smart contracts add programmability to data and assets managed by a
blockchain. Moreover, the smart contract is transparent to all users as per
the blockchain’s permission setting; thus, increasing trust and fairness.

###  III-E Storage

One of the most vital aspects of blockchains is ledger storage, where data are
stored, uploaded, and retrieved. As of October 2022, the sizes of the Bitcoin
[95] and Ethereum [96] ledgers were approximately 433 and 975 GB,
respectively. These numbers continue to increase as more transactions are
processed. Therefore, recording large volume data is a challenge not only for
cryptocurrencies but also for IoT [97] and data-sharing applications.

A blockchain-based application can store data on the blockchain (on-chain) or
outside (off-chain) [98]. With on-chain solutions, data can be sent to the
blockchain via transactions and can be stored in the ledger state or on the
transaction log. In public blockchains, a transaction fee must be paid to
store data on-chain. Also, transactions with large data payloads reduce the
number of transactions that can be included in a block, reducing the
transaction throughput of the network.

Alternatively, off-chain solutions store data off the blockchain but record
metadata about data on the blockchain. This provides an integrity check for
data stored off-chain. Generally, the hash of data and a reference to access
data (e.g., URL) are stored on the blockchain. This establishes a link between
off-chain data and on-chain metadata, which can be used to validate the
integrity of off-chain data. Because metadata tends to be smaller, the
corresponding storage cost will be lower and the impact on the transaction
throughput is minimal. Therefore, off-chain storage is popular among
blockchain-based data-sharing solutions. However, this approach provides only
an integrity check as data cannot be recovered if off-chain data are modified
or lost.

InterPlanetary File System (IPFS) is a distributed hash table (DHT) based P2P
storage network solution to share and retrieve data in a distributed system
[99, 100]. IPFS introduces the concept of content addressing when content can
be retrieved based on a content-based routing mechanism rather than its
location like in traditional protocols. When a client imports a file to the
IPFS network, the file is split into small chunks [101]. The hash of a chunk’s
data is used as its content identifier (CID) [102]. These CIDs form a Merkle-
directed acyclic graph to link chunks together. IPFS uses a DHT to allocate
chunks to IPFS nodes and later locate them using their CID value [103]. When
retrieving chunks, they are hashed again and matched against their CID to
verify the integrity. IPFS is a popular off-chain storage solution for dApps
and is also adopted by data-sharing constructions [104, 105, 106, 107].

###  III-F Privacy-Preserving Technologies

Due to growing data privacy concerns and privacy policies restricting storing,
exchanging, and utilizing data, especially PII data, PPTs have been developed
to safeguard data from unintentional leaks and deliberate disclosure efforts
[108, 109, 110]. The PPTs are commonly categorized into two sub-classes:
privacy-enhancing technology (PET) [111] and transparency-enhancing technology
(TET) [112] with various protection purposes [113]. While PETs focus on data
minimization, confidentiality, and unlinkability, TETs tend to reinforce
transparency and intervenability.

PETs can be implemented in hardware and software, and enable individuals and
organizations to benefit from a significant volume of data without disclosing
it. PETs also ensure that sensitive data are gathered as infrequently as
feasible (i.e., data minimization) and only authorized parties have access to
and use the data (i.e., data confidentiality). Moreover, the data are
processed and analyzed exclusively for the purpose for which they were
acquired (i.e., data unlinkability). There are three approaches to protect
data privacy in PETs [114]. The first approach uses specialized hardware and
cryptographic techniques to isolate input data and computations performed on
them, and then share only the output data with DRs. Typical techniques include
the use of a trusted execution environment (TEE) like Intel SGX, MPC, and HE.
For example, with HE [115], DPs can achieve a higher standard of data security
and privacy by performing computations on encrypted data and sharing outputs
with DRs in encrypted form. Theoretically, for a given HE function $E$ with
respect to a function $f$, the encrypted of $f$ can be computed by computing a
function $g$, over encrypted variables of $X=\\{x_{1},x_{2},...x_{n}\\}$.

$E(f(x_{1},x_{2},...,x_{n}))\equiv g(E(x_{1}),E(x_{2}),...,E(x_{n}))$ (1)

Each participant can encrypt his private $x_{i}$ and transmit $E(x_{i})$ to
another. Next, that party calculates the function $g$ on encrypted data via
homomorphism of the encryption method, and the party gets the encrypted value
of function $f$. However, it is still a challenge to apply HE in real
applications [116] as HE requires either application modifications or
specialized client-server applications to make it work.

Table III: Quantitative comparison of privacy-preserving data sharing
strategies

PPT Attributes |  | Privacy
---
Size | Speed | Data Utility | Deployment
Secure Multi-party Computing |  $\star$$\star$$\star$$\star$$\star$ |  $\star$$\star$ |  $\star$$\star$ |  $\star$$\star$$\star$$\star$ | $\star$
Homomorphic Encryption |  $\star$$\star$$\star$$\star$$\star$ |  $\star$$\star$ |  $\star$$\star$ |  $\star$$\star$$\star$$\star$ | $\star$
Differential Privacy |  $\star$$\star$$\star$$\star$ |  $\star$$\star$$\star$$\star$ |  $\star$$\star$$\star$$\star$ |  $\star$$\star$$\star$ |  $\star$$\star$$\star$
Synthetic Data |  $\star$$\star$$\star$$\star$$\star$ |  $\star$$\star$$\star$ |  $\star$$\star$$\star$ |  $\star$$\star$$\star$ |  $\star$$\star$$\star$
Federated Learning |  $\star$$\star$$\star$$\star$$\star$ |  $\star$$\star$$\star$ |  $\star$$\star$$\star$ | $\star$ |  $\star$$\star$

Another possible solution to enhance data when making sensitive private data
securely available is differential privacy. The definition of differential
privacy is defined as follows: a randomized algorithm
$\mathcal{A}:\mathcal{D}\rightarrow\mathcal{R}$ with domain $\mathcal{D}$ and
range $\mathcal{R}$ is $(\epsilon,\delta)$ \- differential privacy if for any
two adjacent training dataset $D_{1},D_{2}\subseteq\mathcal{D}$, in which the
data points in these two datasets are difference, and any subset of output
$S\in\mathcal{R}$, satisfies the condition:

$Pr[\mathcal{A}(D_{1})\in S]\leq e^{\epsilon}Pr[\mathcal{A}(D_{2})\in
S]+\delta,$ (2)

where $\epsilon$ and $\delta$ are called privacy budget and failure rate,
respectively. A smaller $\epsilon$, a stronger privacy guarantee. However, DP
also has some serious flaws [117]. Some DP queries leak a small amount of
data, hence if an attacker is able to repeat similar queries, the total loss
could be catastrophic. A quantitative comparison of privacy-preserving
techniques is described in Table III

To date, Internet users have given up their personal information and privacy
in order to use services and applications in the Internet environment. On the
one hand, the more information users supply, the better the service providers’
experience. When providers understand their customers through shared data,
they may customize and improve their services and applications to adapt to
customers’ demands. Customers, on the other hand, have a difficult time
recalling and determining what data providers collect and use for what
purposes. The TET was created to give users a clear picture of what and how
their data are gathered, analyzed, and utilized to promote information
transparency between users and services [118] without aiming at data
minimization. With this mission, the TET is a complementary tool to PET to
bring a comprehensive privacy-preserving solution.

Integrating privacy protection solutions, i.e., PPTs, helps businesses and
organizations solve the worry of adopting blockchain technology in data-
sharing applications. This is because the risk of revealing personal and
sensitive information is high when sharing it via transactions stored in a
publicly accessible ledger, even if encryption algorithms and pseudonyms are
used [119, 120]. Therefore, the combination of PPTs and blockchain technology
is urgently needed to develop secure and privacy-preserving data-sharing
applications.

##  IV Blockchain-based Data Sharing Solution

This section presents some approaches that take advantage of blockchain
platforms to solve data-sharing problems.

###  IV-A Advantages of Integrating Blockchain with Data Sharing

In the preceding Section II-B, we highlighted the research obstacles that
data-sharing solutions face, such as centralization, security, and privacy
concerns, and a lack of trust among parties. Blockchain can improve data
sharing by enabling decentralization, increasing security and privacy levels,
and providing incentive mechanisms. The primary benefits of integrating
blockchain with data sharing are summarized here.

_Decentralization of data-sharing systems_. Shared data and access to the data
would be stored as transactions on distributed nodes for storage purposes. The
blockchain platform is managed by participants rather than a central operator,
ensuring that the entire system is not governed by a single entity.

_Traceability of data-sharing systems_. Using a traceable and immutable
distributed ledger, blockchain technology provides an audit trail for parties
to retrieve information at various stages. In a supply chain, for example, all
information on product provenance, manufacturing, distribution, and
transportation until the product reaches customers would be shared and
recorded in the blockchain managed by authorized stakeholders. They have the
authority to inspect, test, and verify the product’s dependability throughout
the entire process.

_Security of data-sharing systems_. Blockchain technology ensures the
integrity and availability of data-sharing solutions. It decreases the risks
of data modification and falsification without permission by eliminating the
reliance on a single entity for data storage and management. However, to
protect data confidentiality, data-sharing solutions must adopt permissioned
blockchains, i.e., private or consortium ones, instead of public ones, or
combine blockchains with cryptographic technologies, e.g., symmetric
encryption and asymmetric encryption. Also, thanks to digital signature
technology, and immutability and traceability properties, any malicious
operations on the data in the blockchain network will be recognized, rejected,
and traceable, which is not possible with other data-sharing systems. For
example, it might appear out of control to identify and track malevolent
clients who provide altered and deceptive learning parameters in FL-based
decentralized data-sharing systems.

_Privacy of data-sharing systems_. On the blockchain platform, an individual’s
identity is represented by a public address. In other words, the public
address is a pseudonym, which is displayed in every transaction for the
individual in possession of the accompanying public key. Although transactions
made with this address could be traced back due to blockchain’s transparency,
blockchain technology adds a new layer of identity protection to protect the
individual’s identity rather than using the real identity like traditional
approaches, i.e., using CSP’s solutions. Moreover, because of cryptographic
keys, users are capable of controlling who and how third parties access and
use their data.

_Incentive and punishment mechanisms of data-sharing systems._ Integrating
blockchain technology into data-sharing solutions offers both financial
rewards and non-monetary incentives. In addition to making revenues by sharing
quality data, individuals, businesses, and organizations can gain rewards by
participating in consensus processes to validate and append blocks of
transactions to blockchains. More importantly, with the reliability in terms
of privacy and security that blockchain brings, it encourages parties to join
the blockchain network to exchange their data with others, which promotes
collaboration among them in vertical disciplines for building better user-
oriented services and applications. Besides, malevolent parties, who try to
corrupt the data-sharing system, will lose their deposit in the blockchain and
be detected and banned from the system if seriously violate regulations.

Figure 5: _BlockDaSh_ \- our proposed blockchain-based data-sharing reference
system architecture

###  IV-B Reference System Architecture

In this section, we propose a permissioned (i.e., private or consortium)
blockchain-based data-sharing system architecture called _BlockDaSh_. There
are several reasons that hinder integrating permissionless (i.e., public)
blockchains with general data-sharing applications, especially the security
and privacy paradox in the permissionless blockchain:

Transparency. In permissionless blockchain platforms, transactions are
transparent and accessible to everyone. This leads to a situation in which
malicious parties access, view, analyze, and use data (e.g., sensitive
information from credit cards, and medical records) for illegal purposes
without the data provider’s consent.

Immutability. Also, because everyone is accessible to permissionless
blockchain-based data-sharing systems, the risks of storing improper,
sensitive, or illegal data are inevitable. Still, these data cannot be
withdrawn and deleted due to the immutable characteristic [121]. It takes up
storage space, interferes with personal life, breaches intellectual rights,
and violates users’ rights to control their data.

Traceability. When there are hundreds, thousands, or millions of users in the
blockchain platform, resulting in massive transactions, tracking information
at milestones when disagreements arise becomes increasingly complex and
difficult.

Therefore, we focus on utilizing permissioned blockchains in designing
blockchain-based data-sharing architecture in this survey. The proposed
_BlockDaSh_ consists of five main components: Data Providers (DPs), Data
Aggregators (DAs), blockchain network,  Data Requesters (DRs) and Data Service
Providers (DSPs), and three subsystems: data processing, data storage, and
data sharing. The architecture is shown in Figure 5. The detail of the
components is described below:

DPs are the owners of smart homes, smart grids, hospitals, or banks that
gather, store, transform, integrate, and encrypt the huge amount of raw data
generated from data sources (DSs) such as humans, services, transactions,
appliances, manufacturing machines, IoT devices, and enterprise resource
planning (ERP) systems by using their connected data handling units. Data
handling units are devices or servers which have a stable network connection,
medium storage capacity, and computational capability. Besides, DPs are
willing to share their data ( i.e., their collected and processed data, or
third parties’ data under their consent) with other parties to monetize data
or for public contributions. DPs acting as lightweight nodes are in charge of
communicating and interacting with the blockchain network instead of using
local resource-constrained devices to reduce storage and communication costs,
and latency of the system. To protect data confidentiality, DPs always encrypt
their data before uploading it to the outside.

DAs play the role of full nodes, which maintain a copy of the entire ledger in
the blockchain network and are responsible for fully validating transactions
and blocks. Besides, DAs also assist lightweight clients in transmitting
transactions to the blockchain network. DAs are pre-selected and distributed
across the network and serve as edge computing nodes that manage a cluster of
DPs [122, 123]. They have a stronger wireless connection and larger computing
and storage capacities than DPs, and they provide services for DPs within
their coverage. Especially in the second use case of the data-sharing
subsystem, DAs also work as aggregators to aggregate local model updates sent
from FL clients, i.e., DPs.

Blockchain network is maintained by a group of consensus nodes known as DAs
that are pre-selected and ensure the data they hold is valid, secure, and
accessible to authorized users. The indices of DPs’ data returned from online
repositories and any operations (e.g., access or usage) on shared data are
recorded and stored on the blockchain. In the blockchain network, DPs and DRs
play the role of lightweight nodes. Therefore, each DP and DR only downloads
the block header instead of storing the whole blockchain and can interact with
the blockchain network via full nodes.

DRs are individuals, businesses, or organizations who desire to access and use
data shared by DPs for their own purposes. For example, to choose the best
route to a location, drivers want to be informed of the weather and road
conditions along particular paths. With shared information from other vehicles
on different routes, drivers will make better decisions for their travel.
Besides, DRs need to pay an amount of money or cryptocurrency for DPs to
purchase the data they want, in addition to transaction fees. Furthermore, DRs
are able to rate DPs based on the relevance and quality of shared data.

DSPs are data-sharing platforms built over the blockchain network and run by a
single organization or groups of organizations to provide a secure place for
data sharing between DPs and DRs. They offer a wide range of services for DPs
and DRs to join, upload data, or request data in a variety of real-world
applications such as healthcare, supply chain, or transportation. In addition,
user registration, data storage, data sharing, and payment and reputation
management services are exposed to DPs and DRs to make the entire data-sharing
procedure more convenient and accessible to people who wish to exchange data
in different application areas. Regarding storage, DSPs can use external
online repositories, e.g., cloud servers or IPFS, which have almost infinite
storage space for off-chain processing and storage, to reduce storage and
networking burdens on the blockchain network.

###  IV-C The BlockDaSh Framework

As shown in Figure 5, our _BlockDaSh_ system comprises three subsystems, which
are data processing, data storage, and data sharing, making trustworthy data
sharing between DPs and DRs without relying on a central third party:

####  IV-C1 Data processing

The data processing subsystem provides two functions: data collection and data
pre-processing. In the former function, DPs possess and collect raw data that
is diverse, noisy, and heterogeneous by nature from a range of data sources
(DSs). DSs transfer their raw data to the connected data handling units via
wired and wireless communication. In the case of DPs directly sending the
original data to the blockchain-based system infrastructure, it will be costly
in terms of communication overhead and energy consumption throughout the
transmission process. Besides, sending them still containing noise without
pre-processing may affect the quality of the data, leading to low rewards. As
a result, raw data must be pre-processed by using data handling units to clean
noise (e.g., data duplication, incomplete data, sensitive data, or incorrect
data), integrate data from multiple DSs, and transform them into meaningful
information. For example, a hospital is capable of collecting patient data
generated from EMRs uploaded by doctors and medical devices in various
departments. The data are then cleaned, transformed, and classified into
different collections based on the sickness, such as the data collection of
lung scans of patients after contracting COVID-19 or based on each patient. At
the time, because DPs own transformed data and find it valuable and useful,
they are willing to share it to monetize it and assist each other, e.g., other
hospitals.

Figure 6: The flow chart of the data processing subsystem

####  IV-C2 Data storage

Shared data is an essential resource for offering more valuable insights,
promoting collaboration, and developing services for different applications,
so the confidentiality, availability, and integrity of the shared data are
critical. For that reason, the storage of shared data for data discovery and
retrieval must be taken into account to guarantee data security. Accordingly,
a permissioned blockchain network is utilized to manage shared data to achieve
decentralized, privacy-preserving, and secure storage and management. The
processed data from DPs is safely stored using the permissioned blockchain
network and the off-chain storage solution. The specific process of shared
data storage is shown in Figure 7 and demonstrated through the following
steps:

Figure 7: The workflow diagram of the data storage subsystem

Step 1. (System initialization): At first, DPs have to register with trusted
certificate authorities (CAs), e.g., government departments of public health,
to join the blockchain-based data-sharing system. When the authentication
process is finished, registered DPs and DRs can join and connect to the
blockchain network as trusted participants to exchange data. Each legitimate
user holds a public key, a private key, and a corresponding digital
certificate for authentication, authorization, and encryption tasks. After
that, legitimate users download the latest block header from full nodes in the
blockchain network to stay updated about the current state of the shared
ledger.

Figure 8: The workflow diagram of the data sharing subsystem

Step 2. (Data uploading): As the volume of shared data in a wide range of
applications is huge and may be sensitive, storing all data on the blockchain,
which has limited space, is expensive and inefficient for a long period. Thus,
storing metadata on-chain and shared data off-chain is adopted to achieve high
scalability and security. Then, processed data will be encrypted by DPs before
being sent to the off-chain storage source (i.e., IPFS or cloud servers) to
improve scalability and protect the confidentiality of shared data. DPs
extract searchable keywords and generate data descriptions from their local
data. After the off-chain storage source returns a storage address for the
ciphertext of shared data, a DP sends a transaction signed by its private key,
in which the transaction contains information such as the timestamp of
transaction creation and metadata, to the blockchain network for storage and
sharing. The metadata may comprise information, e.g., shared data
identification (i.e., hash digest), DPs identification, encrypted data storage
address, DPs reputation, searchable keywords, and the data description.

Step 3. (Block generation and consensus process): DAs gather transactions sent
from DPs in their communication coverage. DAs compete with each other to
create new blocks filled with valid transactions. The block production will
generate a cryptographic hash link between the current block and its prior
block to ensure authenticity, immutability, and traceability. Consensus
algorithms are used to achieve common agreement and trustworthiness across DAs
regarding the current state of the distributed ledger. The winner, i.e., a DA,
of the consensus procedure will broadcast the new block to peer nodes or other
DAs in the blockchain network for verification and audit. If other DAs verify
the newly created block as valid, it will be added on-chain for storage.

####  IV-C3 Data sharing

This is a core subsystem in the proposed _BlockDaSh_ system architecture where
DPs and DRs can securely exchange data. Also, we provide a set of practical
use cases to illustrate the workflow of the data-sharing subsystem.

Use Case 1: Transferring Data among Parties.
In the first use case, DPs and DRs can be matched based on DRs’ requests, DPs’
relevant data, and DPs’ reputation, and then data, such as electronic and
energy consumption information or traffic-related data, can be exchanged via
smart contracts in the proposed  _BlockDaSh_ architecture. We present the
interactive process between DPs and DRs as follows:

Step 1. (Sending requests) DRs having interests in exchanging data in the
permissioned blockchain network need to pass the registration phase under the
control of trusted CAs. DRs begin by sending data-searching transactions to
the blockchain network for searching and discovering their data of interest
based on metadata saved on-chain. When the blockchain finds suitable DPs who
have the highest reputation and possess the most relevant data for DRs’ needs,
the blockchain network will return the result to DRs containing information
for data retrieval. Now, DRs can submit data-sharing requests to DPs to
request rights for accessing the shared data.

Step 2. (Data sharing permission grant) After a chosen DP receives a data-
sharing request from a DR, it first verifies the identity of the DR via the
DR’s digital certificate to assure that the request comes from a trustworthy
and legitimate user. After that, DP will establish payment, DAC, and data
usage control (DUC) policies with the expiration time of these policies for
their data. While DAC policies specify who can access what kind of data, DUC
ones define how data are used for what purposes. When DP and DR reach a common
agreement about DAC, DUC, and payment, DP will deploy a smart contract to
permit transactions and agreements between them to be automatically carried
out. When most consensus nodes verify the smart contract, it is irreversible,
available, and accessible in all blockchain nodes.

Step 3: (Data retrieval) With the consent granted by a DP, a DR can submit a
transaction containing the amount of cryptocurrency to deposit to invoke the
deployed smart contract on the blockchain network. The DP’s metadata (e.g.,
the DP’s data storage address) and needed information for data retrieval will
be sent back to the DR. Based on the data storage address of the data
retrieved from the blockchain network, the DR sends a request to query data
from the off-chain storage source. This process does not cost anything. When
retrieval results are returned to the DR, it uses its cryptographic key to
decrypt them, get the data it requires, and verify them to ensure the shared
data has not been modified. At this time, DR can use the shared data for their
work.

Step 4. (Payment and rating management) In the end, after a DR obtains shared
data from a DP, it will pay the DP using cryptocurrencies. The DR will also
initiate another transaction to inform peer nodes that shared data has been
successfully obtained. Besides, if the DR finds the shared data from the DP to
be useful, relevant, and proper to its requirements as well as useful for its
tasks, it generates a rating transaction on the blockchain. The rating
transaction will invoke a rating verification smart contract to verify the
rating message to ensure its correctness. The high rating value would reflect
the quality of shared data and affect the reputation of the DP. The reputation
of the DP will be updated over the blockchain network. Besides, DRs who
actively contribute accurate feedback will have a great chance to receive
incentives for their contributions.

Use Case 2: Leveraging trustworthy data-sharing for collaborative learning.

Blockchain-based FL refers to a decentralized approach for data sharing and
analysis, where multiple parties can collaborate on developing ML models
without the need to share their sensitive data with each other[124]. In this
approach, the data remains local to the participating parties and is never
transferred to a central location. Instead, a blockchain is used to store and
verify the accuracy of the ML models. Each party contributes to the training
of the model by computing local updates and sharing only a summary of these
updates with the other parties via smart contracts. The use of blockchain
technology provides transparency, immutability, and security to the machine
learning process, ensuring that the shared models are trustworthy and can be
audited at any time. This approach has the potential to enable data sharing in
various domains, including healthcare, finance, and smart cities while
preserving data privacy and security.

FL Concept. Suppose that a DP or a client $i$-th has a private dataset
$D_{i}$. In FL, this translates to finding an optimal global model parameter
$w\in\mathbb{R}^{d}$ that minimizes the empirical risk on all of the
distributed training data samples[125]. The clients collaborate to solve the
distributed optimization problem as follows:

$\underset{w\in\mathbb{R}^{\textrm{d}}}{\text{min}}F(w):=\frac{1}{N}\sum_{i=1}^{N}F_{i}(w)$
(3)

where $N$ is the number of clients (i.e., DPs). The objective function for the
client $i$ is as follows:

$F_{i}(w):=L(w;D_{i}),$ (4)

where $L$ is a loss function [126]. We assume that the configuration ensures
that if two FL clients have identical local datasets, then they have the same
local models, e.g, $D_{i}=D_{j}$, so $F_{i}=F_{j}$. In order to solve the
optimization problem of (3), we can leverage the federated averaging (FedAvg)
algorithm [127], which is widely used in FL. The FedAvg algorithm employs
stochastic gradient descent (SGD)[128] parallelly on a randomly sampled subset
of clients and submits local model updates to a central server in each round.
Specifically, $I=\\{1,...,N\\}$ is the set of FL clients in each training
round $t$. We present the FedAvg as follows:

Figure 9: The standard FL architecture and workflow diagram [129]

  1. 1.

First, the centralized server broadcasts a last global model $w^{t}$ to all FL
clients, say data providers.

  2. 2.

Then, all data provider $i$ updates its local model by configuring
$w_{i}^{t}=w^{t}$ for all FL client $i$.

$w_{i}^{t_{1}}=w_{i}-\eta^{t}\nabla F_{i}(w_{i}^{t}),$ (5)

where learning rate $n^{t}$ is used in round $t$-th. The default value of
$n^{t}=0.1$

  3. 3.

Based on the client selection scheduling algorithm, a subset $I_{t}\subseteq
I$ of FL clients is selected. The FedAvg algorithm randomly selects clients
for local updates.

  4. 4.

Next, the central server aggregates the submitted local models to generate a
new global model

$w^{t+1}=\frac{1}{|I_{t}|}\sum_{i\in I_{t}}w^{t+1}$ (6)

The FL training process is iterated until the global loss function converges
or achieves a desirable test evaluation metric, e.g., accuracy. The network
architecture and communication process of standard FL are shown in Figure 9.

_* These steps will be iterated in multiple rounds if pre-defined criteria of
the global model are not met._

Figure 10: The workflow diagram of the trustworthy data sharing for
collaborative learning

Workflow. This use case is different from the first one because it requires
DPs to contribute not only their data but also their computational resources
in multiple communication rounds. While the first service provides a one-by-
one match between a DP and a DR for trading data, e.g., electronic medical
records (EMRs), this service allows DRs, with the support of smart contracts,
to train effective ML models that are hard for a single individual,
organization, or business to achieve due to the shortage of data in terms of
the amount, quality, and diversity. It is important to note that DRs can also
buy pre-trained ML models if available from the first service, but they want
to train their models from scratch in this case. Therefore, as shown in Figure
10, a DR will be able to get its well-trained ML model via _BlockDaSh_ in the
following steps:

Step 1. (Initializing and Publishing global model): At the early stage, the DR
initializes a naive ML model (or global model) and publishes it to the
blockchain following the transaction format. Then, the transaction consisting
of the global model is validated, verified, and appended to the blockchain.

Step 2. (Selecting DPs): DAs playing the role of model aggregators send
requests to random DPs to ask for their data size relating to the current
training task, available computational resources, and communication channel
states [130]. Then, based on DPs’ responses, DAs estimate the time required
for downloading/uploading local model updates and the training time of each
DP. As a result, DAs will have solid evidence to decide which clients are
selected for the training task and ensure efficient utilization of DPs’
resources.

Step 3. (Downloading and Training global model): The global ML model on the
blockchain is downloaded by chosen DPs to train with their data with the goal
of minimizing the loss function or optimizing the evaluation metric, e.g.,
accuracy or mean squared error. Also, the data of DPs will be kept locally and
not exposed to the outside.

Step 4. (Uploading local model updates): Selected clients to upload
transactions of their local model updates on-chain.

Step 5. (Cross-verification and aggregation of local models): These
transactions are then broadcast, validated, put into blocks, and verified by
other DAs on-chain. In the meantime, each DA validates the quality of the
received local model updates by treating their data as a validation dataset.
Only local model updates meeting pre-defined criteria of performance, e.g., a
prediction accuracy of above 95%, given by DR, are accepted as valid
transactions and kept for aggregation. It is noteworthy that the local model
update validation process is integrated into consensus protocols to address
model/data poisoning attacks and save computational resources for DAs. After
that, validated local model updates are aggregated into a new global model by
DAs. The new global model will be published, propagated, validated, verified,
and appended to the blockchain. Until the global model achieves a desirable
evaluation metric value, all steps are iterated except for the first step
_Initializing and Publishing global model_.

Step 6. (Settlement): When the global model reaches a certain level of
performance, and the block containing the global model is included in the
blockchain, a smart contract is triggered to settle the deal between DPs and
the DR. At this time, DR is able to download the desired ML model from the
blockchain, and rewards will be given to DPs.

Step 7. (Payment): Finally, based on the efforts in training the global model
and improving its performance, the smart contract calculates appropriate
incentives to reward DPs.

Table IV: Comparison permissioned blockchain platforms Ref. | Platform | Governance |  Customer target |  Consensus protocol |  Smart contract language | Performance |  Smart contract |  Open source
---|---|---|---|---|---|---|---|---
[131] |  Enterprise Ethereum |  Enterprise Ethereum Alliance |  Enterprise |  PoW, PoS |  Solidity, Python, Go, C++ |  - |  ✓ |  ✓
[132] |  Hyperledger Fabric |  Linux Foundation |  Enterprise |  Pluggable consensus |  JavaScript, Go, Java |  Strong throughput and latency |  ✓ |  ✓
[133] |  Quorum |  ConsenSys |  Financial Enterprise |  Raft, Istanbul BFT |  Solidity, Vyper |  Strong throughput, poor latency |  ✓ |  ✓
[134] |  Corda |  R3 Consortium |  Financial Enterprise |  Pluggable consensus |  Java, Kotlin |  Poor throughput, strong latency |  ✓ |  ✓
[135] |  Multichain |  Coin Sciences |  Enterprise |  Distributed consensus |  Javascript |  Strong throughput, decent latency |  ✓ |  ✓
[136] |  Hydrachain |  Brainbot Technologies |  Enterprises |  PBFT |  Python |  - |  ✓ |  ✓
[137] |  NEO |  NEO Foundation |  Enterprise |  dBFT |  Python, Java, Go, C# |  - |  ✓ |  ✓

###  IV-D Tutorials for Deploying of BlockDaSh

Generally, integrating blockchain with data-sharing solutions is promising
when blockchain technology brings trustworthiness and significant benefits to
users. While users are able to monetize their data in a secure and privacy-
preserving manner, they also benefit from enhanced services and applications
that are customized, personalized, and upgraded using their sharing data. To
realize such blockchain-based data-sharing systems, designing a detailed plan,
choosing suitable technologies, and building a practical architecture are
mandatory. In the following part, we provide recommendations for successfully
deploying _BlockDaSh_ in a wide range of real-world applications in terms of
designing blockchain networks. Regarding the data storage system, we can refer
to the storage part in _the BlockDaSh framework section_.

####  IV-D1 Objectives

It is crucial to first identify the problem, its scope, intended outcomes, and
potential technologies before choosing to implement blockchain technology and
the _BlockDaSh_ reference system architecture. Organizations can refer to a
list of assessment criteria published by PwC222https://www.pwc.com/ to ensure
that the final decision is the best fit for their project. The first questions
to consider are the number of parties that need access, viewing, and retrieval
of shared data and whether these actions must be recorded. Verification
requirements for these actions among stakeholders must also be considered.
Organizations must also assess costs and complexity when deciding to adopt
_BlockDaSh_ in their data-sharing solutions, compared to traditional
approaches such as relying on central providers like CSPs. The delay in
interactions among stakeholders is crucial as it directly affects the quality
of business services, so organizations must determine whether interactions
need to be time-sensitive. Finally, it is essential to consider if
transactions interact with each other in the data-sharing model.

####  IV-D2 Design the Blockchain network

_BlockDaSh_ is utilized as the reference system model for a blockchain-based
data-sharing solution. The next step is to determine a suitable permissioned
blockchain platform for storage and management. A wide range of permissioned
blockchain platforms are being developed and offer distinct technical
properties targeted at different use cases. The authors in [138, 139]
comprehensively analyzed other distributed ledger technologies, e.g.,
Hyperledger Fabric[132], Ethereum, IoTA[140], Solana[141], and Quorum[142],
applied in industrial IoT applications.

Selecting an appropriate Blockchain platform could be based on several
factors, e.g., scalability, latency, throughput, security, and smart contract
functionality. These factors are crucial for data-sharing applications because
large volumes of data from DPs generated millions of transactions daily [143],
requiring a high-efficiency consensus mechanism. Latency is also essential,
and confirmation times for Bitcoin and Ethereum may not be suitable for real-
time monitoring. Transaction fees are another critical factor to consider, as
they can significantly increase operational costs and negatively impact
throughput [144]. Ethereum requires fees and gas for each transaction, while
Hyperledger Fabric and IOTA offer free solutions. Meanwhile, Solana is a high-
performance, decentralized blockchain platform designed for building
decentralized applications and facilitating fast, secure transactions. Solana
is designed to scale linearly as the network grows. It can currently process
over 65,000 transactions per second (TPS), making it one of the fastest
blockchain platforms in existence.

Another critical factor for a secured data-sharing platform is support for
permissioned and permissionless nodes. Both Ethereum and Hyperledger Fabric
support public and private solutions, while Bitcoin and IOTA only provide
public ones. Public networks may be more secure because the data is encrypted,
verified, and stored on all devices, making it transparent. However,
permissionless blockchains are not ideal for enterprise use, where companies
deal with sensitive data and cannot allow anyone to join their network.
Permissioned blockchains can be altered by their owners, making them more
vulnerable to hacking, but they provide lower fees for validation and a faster
consensus process [145].

Finally, smart contract technology is considered as the key innovation in the
blockchain era. Smart contracts act as autonomous entities on the ledger and
execute logic expressed as functions of the data. Smart contracts can
automatically react to specific events, such as real-time policy enforcement
for sharing data. Solana, Ethereum, and Hyperledger Fabric support smart
contracts, while IOTA has a smart contract type called Quobic. Hyperledger
Fabric also provides various features such as identity management, transaction
integrity, and authorization with a trusted CA. These features are essential
in a trusted IoT system. The comparison of DLTs in these areas is illustrated
in Table IV.

##  V Applications of Blockchain-based Data Sharing

With the rapid advancement and innovation driving today’s society, blockchain
is a technology that possesses all of the properties required to assist data-
sharing solutions in overcoming present obstacles and progressing to the next
level. In this section, we review existing blockchain-based data-sharing
applications in a wide range of fields ranging from healthcare, supply chain,
transportation, smart grid, and data marketplace to a bunch of industrial
applications.

###  V-A Healthcare

Good health is required to completely enjoy life. The significance of it is
far reinforced, especially now that the entire world has confronted the health
repercussions of the COVID-19 pandemic [146]. However, there are numerous
hurdles that relate to authenticity, security, and privacy concerns for
patients’ medical data and negatively affect medical staff in the process of
analyzing and diagnosing patients’ health in the traditional healthcare domain
[147]. For example, patients’ EMRs, which record the whole process of their
medical treatment, are very sensitive, scattered, and not synchronized among
various medical institutions. Moreover, patients also do not have permission
to access their EMRs because they are privately stored in the local databases
of these institutions. Fortunately, blockchain technology has emerged and
solved the above-mentioned problems by providing distributed and immutable
storage to facilitate the sharing of medical data in a secure and privacy-
preserving way among healthcare organizations while patients keep control over
their data. The relevant study on blockchain-based medical data-sharing
solutions will be summarized in the following.

In [9], a scheme named BSPP was presented to improve diagnosis in e-Health
systems. Authors used both private and consortium blockchains for storing and
sharing EHRs in a secure and searchable way. While the private blockchain is
used to store encrypted data, the consortium maintains records of EHR indexes.
A keyword search protocol is introduced to allow authorized doctors to search
historical EHRs while precluding them from searching for future records in
order to improve data retrieval for treatment. Furthermore, the authors
defined a Proof-of-Conformance consensus algorithm for broadcasting,
validating, and appending new blocks to the chains. The proposed scheme was
then implemented on JUICE platform for evaluation and achieved considerable
results in terms of computation, storage, and time.

In [107], Chen et al. proposed BFHS, a framework that provides a comprehensive
DAC and data storage solution for electronic health record (EHR) sharing. To
store EHRs in a decentralized and secure manner, and effectively retrieve
them, BFHS used IPFS technology in the company of the consortium blockchain.
In particular, while IPFS keeps encrypted patient’s EHRs and returns indices
of them, the consortium blockchain stores ciphertext of indices that are
encrypted by patients using ciphertext-policy attribute-based encryption (CP-
ABE) [148]. Furthermore, the smart contract was created to manage access
control policies for patients, individuals, and organizations who desire to
own EHRs. It also supports credit calculation for consensus nodes. The higher
a node’s reputation, the more likely it is to be picked to participate in the
consensus process.

In [149], authors presented a blockchain-based system, named MeDShare, to
reduce risks to patients’ EMRs related to privacy issues when sharing them
among CSPs. MeDShare, with the help of smart contracts, enabled capabilities
like data traceability, data audit, and DAC over medical records during data-
sharing processes. The system was designed with four layers: user, data query,
data structuring and provenance, and existing database infrastructure. Smart
contracts and an access control mechanism were utilized to trace actions
performed on requested data to ensure that the data was used properly. If
detecting any misbehavior on shared data, smart contracts revoke the access
permission of the requester. Furthermore, these actions on the request and
delivery of data would be stored in an immutable blockchain network maintained
by consensus nodes. The authors evaluated and discussed the system performance
by employing scenarios of two different threat levels (data and report swap).

The work in [150] aimed to improve the efficiency and privacy of patient EMR
sharing and retrieval in eHealth systems. The authors developed SPChain, a
public or permissionless blockchain system that uses chameleon hash functions
(CHFs) [151] to create new kinds of block structure (keyblocks and
microblocks) to securely store EMRs, as well as proxy re-encryption (PRE) to
ensure data privacy while exchanging EMR. Furthermore, to incentivize medical
institutions to participate in the data-sharing and mining process, a
reputation-based consensus protocol was designed. To demonstrate the
effectiveness and scalability of the proposed system, performance metrics such
as storage cost, throughput, and time cost were assessed in a real-world
implementation. Besides, the proposal was also resilient to different types of
attacks.

Figure 11: BC-based data-sharing system in healthcare [152]

The authors in [153] proposed a blockchain-based system to share data between
patients and hospitals with efficient EMR retrieval and access control
mechanisms. The proposed system, named MeDBlock, uses local databases to store
encrypted EMRs of patients among different hospitals, while their hash values
are stored on the blockchain network. Because searching a historical patient’s
EMR over the entire ledgers across hospitals is inefficient and takes time,
authors used a breadcrumbs mechanism that caches the hash of department-based
patient-related blocks in hospitals per query for faster data retrieval.
Moreover, for unauthorized users, information about signatures and encrypted
summaries of EMRs is hidden before their identities are authenticated to
ensure privacy for sensitive data.

The authors in [154] proposed a blockchain-based framework called Ancile to
balance privacy and the necessity for access to EHRs. Ancile used smart
contracts to manage access permissions for individuals who needed to access
data for a specific reason. Furthermore, to improve data privacy, a
distributed PRE method with blinding is given for data sharing between
parties. This approach assures that messages and cryptographic key information
cannot be fully decrypted if any hazards exist. To reduce storage costs, only
transaction hashes were stored on the blockchain, while query link information
was transmitted through the Hypertext Transfer Protocol Secure protocol.

Table V: TAXONOMY OF BLOCKCHAIN-BASED DATA SHARING SOLUTIONS

Area | Ref. | Objective | Blockchain used | PPT | Key contributions | Limitations
---|---|---|---|---|---|---
|  |  |  Pub. |  Pri. |  Con. |  Hyb. |  |  |
Healthcare |  [9] |  Storage, search |  - |  ✓ |  ✓ |  - |  $\times$ |  Introduces two blockchains for storage, and a keyword search algorithm. |  Security risks on computer clients.
[107] |  DAC, storage |  - |  - |  ✓ |  - |  $\times$ |  Provides a fine-grained DAC using PRE and ABE with IPFS technology. |  Computational overhead.
[149] |  DAC, auditability |  - |  ✓ |  - |  - |  $\times$ |  Proposes a four-layer EMR sharing system, data access revocation mechanism. |  Data privacy protection.
[150] |  DAC, data retrieval |  ✓ |  - |  - |  - |  $\times$ |  Develops new block and chain structures with CHF. |  Throughput, scalability.
[153] |  DAC, data retrieval |  - |  ✓ |  - |  - |  $\times$ |  Uses bread crumbs mechanism for finding encrypted EMR location. |  Scalability, risks on CA.
[154] |  DAC |  - |  ✓ |  - |  - |  $\times$ |  Uses a distributed PRE method with blinding. |  Lacks performance evaluations.
[155] |  DAC |  - |  ✓ |  - |  - |  $\times$ |  Develops hierarchical ABE, and adopts redactable BC. |  Scalability and storage costs.
[152] |  DAC, storage |  - |  ✓ |  - |  - |  $\times$ |  Implements IoT-based collection system and utilizes PRE algorithm. |  Security on cloud servers.
[156] |  DAC, search |  - |  - |  ✓ |  - |  $\times$ |  Develops constant-size ABE and on-chain boolean search schemes. |  Management and security.
[157] |  Storage |  - |  ✓ |  - |  - |  $\times$ |  Proposes a cross-chain system, leverages Wanchain technology. |  Security and privacy on CSPs.
Supply chain |  [80] |  Traceability, DAC |  - |  ✓ |  - |  - |  $\times$ |  A framework for textile & clothing supply chains. |  Security analysis.
[158] |  DAC, IA |  ✓ |  - |  - |  - |  $\times$ |  Implements an IIoT collection system, utilizes ABE for DAC. |  Lacks performance evaluations.
[159] |  Traceability, IA |  - |  ✓ |  - |  - |  ✓ |  Combines BC with HE for privacy-preserving data sharing. |  Lacks performance evaluations.
[160] |  Traceability |  - |  ✓ |  - |  - |  $\times$ |  Proposes a key management scheme, a consensus protocol. |  Data gathering, data traceability.
[161] |  Traceability |  - |  ✓ |  - |  - |  $\times$ |  A data sharing framework for FSC traceability. |  Scalability.
[162] |  Traceability |  - |  - |  - |  - |  $\times$ |  Combines BigchainDB, HACCP and IoT. |  Lacks data privacy protection.
[163] |  Transparency |  ✓ |  - |  - |  - |  $\times$ |  A FSC data sharing platform utilizing KSI, smart contracts. |  Security on the central authority.
[164] |  Transparency |  - |  - |  - |  - |  $\times$ |  A system architecture for SCSSM, theoretical contributions. |  Research scope for SCSSM.

  * •

* Pub., Pri., Con., and Hyb. stand for _Public_ , _Private_ , _Consortium_ , and _Hybrid_ respectively.

  * •

* BC stands for blockchain.

Zhang et al. [155] contributed a hierarchical access control mechanism for
those who need to perform necessary operations on malicious content without
affecting block hash values. Attribute authorities, DPs, data modifiers, and a
blockchain network are the four components of the proposed system. The authors
employed a decentralized attribute-based encryption (ABE) method with
hierarchical authorization to avoid the single-point-of-failure problem and
limit the power of modifiers. Furthermore, when employing redactable
blockchain technology with the CHF, the hash value of a block is not changed
if the transactions within it are amended. If no updating operations are
required, the traditional hash function will be performed instead of the
Chameleon one.

In [152], authors focused on building a blockchain-based EMR/surgery health
record (SHR) sharing system using IoT devices, Hyperledger Fabric, cloud
servers, and the PRE algorithm. The proposed system architecture includes five
layers: the system management layer, the data collection layer, the blockchain
network layer, the cloud service layer, and the application layer. Thanks to
doctors and medical IoT devices, real-time EMR/SHR data are collected and
gathered for processing and storage. Regarding storage, encrypted EMR/SHR are
kept on cloud servers, and the indexes with data usage records are stored on-
chain. The authors proposed a PRE-based data sharing scheme to ensure secure
data sharing on semi-trusted cloud servers, guaranteeing that those cloud
servers cannot obtain any raw data and cryptographic keys. The performance has
been discussed, and achieved significant results in terms of throughput and
attack resistance.

MedShare [156] is a privacy-preserving consortium blockchain-based EHR sharing
system that provides fine-grained access management and efficient data
retrieval. MedShare’s architecture is comprised of four components: health
centers, users with different EHR access permissions, a blockchain system, and
attribute authority. Encrypted EHRs were stored locally at healthcare
institutions in this study, whereas encrypted searchable indices based on
access permissions for distinct roles were put on the blockchain network.
Specifically, the authors developed an on-chain constant-size ABE-based access
control method to embed access control policies into search results without
incurring high storage costs, as well as a multi-keyword conjunctive boolean
search approach for efficiently performing an on-chain search.

The authors of [157] tackled the problem of cross-hospital diagnosis by
developing an EHR-sharing system called CPDS. CSPs and private hospital
blockchains were used to build CPDS storage. To cut storage costs on the
blockchain while also complying with data protection rules, researchers
employed the former to store original EHRs and the latter just EHR indices. It
is worth mentioning that each hospital owns a private blockchain, thereby
creating a huge storage network, including blockchains between hospitals. CPDS
leverages Wanchain technology for rapid EHR transfer among hospitals,
resulting in a robust solution for scalability and variety for further
development. With this solution, patients have the ability to delete EHRs when
they desire. Finally, the security level of the proposal against multiple
adversary attacks was discussed and analyzed.

Lessons learned. Blockchain technology promotes EMR sharing among patients,
hospitals, and third parties for better diagnosis, detailed treatment plans,
and efficient data management.

  * •

DPs must encrypt their EMRs before uploading them to storage systems due to
security and privacy concerns. Because the number of EMRs is massive and
increases exponentially day by day, it is inefficient and costly to store all
raw EMRs on blockchain network. Therefore, only hash values of EMRs are kept
on the blockchain, while encrypted EMRs are stored on local hospital servers,
cloud servers, or distributed storage systems such as IPFS and Swarm.

  * •

In blockchain-based healthcare applications, EMR/EHR access control also needs
to be carefully investigated and developed because it allows DPs to monitor
and govern actions performed on their shared data. By using smart contracts
and cryptographic techniques (e.g., ABE), DPs are able to flexibly set access
control policies to prevent EMRs from being accessible to unauthorized
entities.

  * •

Another issue that has arisen in blockchain-based healthcare applications is
the retrieval or querying of historical EMRs. Although a patient’s previous
EMRs may be scattered across multiple medical institutions, applications must
ensure that DRs, in general, can easily query them to provide quick and
accurate diagnoses for a specific purpose. Because searching the entire ledger
is inefficient, techniques and mechanisms (e.g., Bread crumbs [153]) might be
used to speed up data accessing and querying.

  * •

The majority of current blockchain-based healthcare applications have not
considered using PPTs to protect the sensitive data privacy of patients. If
DRs are nurses and doctors who are in charge of the patient’s medical
examination, data sharing without PPTs may be acceptable because they still
need to see explainable raw data (e.g., X-ray images) for diagnosis. Regarding
third-party requesters, not all patients want their raw EMRs leaked, viewed,
and monetized. As a result, there is a need to combine PPTs and blockchain in
order to build a secure and privacy-preserving blockchain-based healthcare
application like _BlockDaSh_. Especially, when the number of intelligent AI-
based systems having large impacts on primary care and requiring a ton of
medical data for training models increases at a rapid pace [165, 166],
_BlockDaSh_ is able to support them in reducing the risks of patients’ data
leakage thanks to the trusted data sharing for collaborative learning service.

###  V-B Supply Chain

A supply chain is a series of processes in which multiple entities, suppliers,
manufacturers, carriers, retailers, and customers take part in producing and
distributing goods. Besides, SCM is a set of approaches to manage the entire
supply chain to realize high performance with lower risks [167]. To achieve
the smooth functioning of SCM, it requires active collaboration, engagement,
and faithful commitment among entities in the supply chain. However, due to a
lack of transparency, trust, and a strict binding force between supply chain
members, existing SCM systems have faced various problems in product
availability, product quality, product monitoring, product traceability and
information synchronization. These flaws can be fixed with the solution of
data sharing among entities by adopting blockchain technology. Blockchain
technology provides supply chains with a decentralized, secure data repository
to store and exchange information. Malicious entities and attackers cannot
falsify cargo information during the process of goods’ circulation. Therefore,
information about products or business processes is transparent, traceable and
symmetric for members of the supply chain, making SCM systems more effective
and manageable. In the subsection, the related research on blockchain-based
data-sharing solutions for supply chains will be summarized.

The authors in [80] centered on traceability to address IA and poor visibility
issues in the textile and clothing supply chain. All transactions were
securely recorded and stored using blockchain technology, guaranteeing
traceability. The proposed private blockchain-based framework was designed by
the authors on two levels: organization and operation. While the
organizational layer specified access control configurations between the
blockchain network and partners, the operational layer described how smart
contracts and transaction rules in supply chain traceability applications
work. Afterward, an example of a supply chain for organic products was
provided to demonstrate the proposed framework’s data-sharing and traceability
capabilities.

In [158], Wen et al. solved the IA by proposing a blockchain-based data-
sharing scheme using Industrial IoT (IIoT) technology, the ABE method, and
smart contracts. IIoT devices are in charge of collecting, gathering, and
transmitting product-related data in real-time to the blockchain network. Only
parties having attributes that match the access policies posed by DPs could
execute transactions using ABE and smart contracts, eliminating the need for
an intermediary party. With the help of IIoT and blockchain, data provenance,
data integrity, and data transparency in SCM are guaranteed, thereby realizing
information symmetry among parties.

The authors of [159] suggested a blockchain-based information-sharing system
to handle the capacity risk problem in SCM caused by IA and demand forecasting
capacities. To safeguard data privacy, HE technology was used, which allows
computational processes to be conducted on encrypted data without disclosing
any original information. The authors provided a Bitcoin-based modified block
for sharing of "one data," which includes different sorts of transactions
between suppliers, manufacturers, and retailers.

Dwivedi et al. [160] used blockchain technology to develop a pharmaceutical
SCM system that tracked data and ensured data integrity, participant
authentication, and secure sharing. The suggested blockchain-based
architecture has two layers: physical (end users, pharmacists, retailers,
warehouses, manufacturers, and raw material suppliers) and consensus. With the
help of CA servers and state machine model-based smart contracts,
cryptographic keys were securely handed to organizations that then conducted
actions based on converting states. Furthermore, in the presented consensus
mechanism, a leader-validator node validates and creates transaction blocks.
Performance metrics such as communication, calculation, execution, and storage
costs have been analyzed and measured.

In [161], authors proposed a decentralized blockchain-based information-
sharing architecture for traceability in the food supply chain (FSC). Three
smart contracts have been deployed to enable the sharing of information and
the traceability of products and raw materials, stakeholders, and processes.
All hashes of the product’s data were stored in IPFS storage. To demonstrate
the applicability of the suggested framework, a real-world situation involving
dairy products was implemented and discussed.

Authors employed IoT and blockchain technology to safeguard food safety by
presenting a reliable and scalable real-time FSC traceability and sharing
solution between stakeholders in [162]. To manage and prevent hazards in FSCs,
the Hazard Analysis and Critical Control Points (HACCP) approach was used in
conjunction with a food chain model that included five processes:
manufacturing, processing, warehousing, distribution, and retail. Furthermore,
the suggested system used IoT devices to collect data, which was subsequently
kept in BigChainDB [168] for scalability. Proposed smart contracts define a
set of rules for supply chain members to follow when accessing, exchanging,
and interacting with data and each other.

In [163], authors proposed an Ethereum-based FSC platform that provides
transparency and sharing of product information between customers, local
producers, and companies as well. All records of product-related data could be
visible, integral, immutable, and verified by customers and members in the FSC
by using Keyless Signature Infrastructure (KSI) and blockchain technology. In
addition, two smart contracts were put in place to oversee the entire
production and supply chain.

The authors in [164] introduced a blockchain-based system architecture for
transparency in supply chain social sustainability management (SCSSM). The
proposed system was divided into five layers: intelligent objects,
communication channels, data analysis, blockchain network, and applications.
Data from each layer was transparent, visible, and authenticated by its
typical users (i.e., inspectors and operators at the intelligent objects
layer). Mainly, the blockchain network layer played a vital part in securely
storing processed data from the data analysis layer with a fair incentive
mechanism to encourage stakeholders to record and share their data.

Lessons learned: The following are key lessons learned via using blockchain-
based data sharing in supply chains:

  * •

IoT and IIoT technologies, when combined with the blockchain, facilitate
traceability that allows for the real-time and nearly real-time capture and
tracking of product quality, operation control, and logistical information
throughout the supply chain. As a result, there is less chance of data
manipulation, and the supply chain’s operation runs smoothly.

  * •

Supply chain will always provide the latest information and have solid and
accurate evidence to trust others and make better decisions during the process
of circulation because the information is shared, readily available, and
transparent to authorized stakeholders in the supply chain thanks to
blockchain and cryptographic techniques.

  * •

Although current blockchain-based data-sharing solutions for supply chains
have solved most of the drawbacks of conventional approaches, such as product
IA, product traceability, and transparency, there is anxiety among entities
about sharing their (sensitive) data in the trend of outsourced manufacturing
and distribution, and supply chain globalization. Access control mechanisms
are not enough to safeguard the confidentiality of data when the number of
malicious entities makes up the majority of a supply chain. Therefore,
considering PPTs to create an additional security layer for data is needed for
blockchain-based supply chain data-sharing applications.

###  V-C Transportation

With the brisk advancement of ML, Big data, wireless communication, IoT, and
traffic infrastructure, the intelligent transportation system (ITS) has
captivated attention in academia and industry in recent years [169, 170, 171].
ITSs assist in operating the entire transport system, minimizing travel
delays, reducing fuel consumption, and improving road safety by providing
transport network operators and drivers with accurate and timely information
about traffic conditions. In ITS, intelligent vehicles (IVs), which are
equipped with onboard units (OBUs), play a crucial role in collecting and
sharing a large amount of traffic-related data with the internet of other
vehicles (IoVs). Nevertheless, sharing data in current transportation systems
has security and privacy problems. The plans still rely on a centralized node
to store data, creating a single failure point (SPOF) from large-scale
attacks. Besides, in an open communication environment, the risk of data
manipulation and eavesdropping is high, thereby threatening drivers’ safety
when they use tampered data to make decisions on the road. Blockchain
technology provides a secure and trusted environment for vehicles to exchange
their data without relying on an intermediary. We review recent studies on
transportation data-sharing applications that apply blockchain technology in
the following.

In [172], Di et al. focused on developing a data-sharing system architecture
containing essential components such as OBU, roadside unit (RSU), trusted
authority (TA), and consortium blockchain for vehicular ad-hoc networks
(VANETs). The consortium blockchain, in which RSUs serve as verification
nodes, stored encrypted data sent from OBUs while reducing communication
overhead and enhancing security. The searchable attribute-based proxy re-
encryption (ABPRE) [173] technique was applied to help ensure data privacy at
OBUs and enable secure data sharing. Furthermore, smart contracts are deployed
to provide different services for police, vehicle owners, and insurance
companies.

Figure 12: A consortium blockchain-based storage and data sharing model in
VECONs [123]

The authors in [174] proposed DrivMan, a trust management and data-sharing
solution for VANETs. To maintain the reliability of shared data, a physical
unclonable function (PUF) is adopted to allocate each IV a unique
cryptographic fingerprint to protect IVs’ identities. In addition to serving
as consensus nodes, in the proposed network model, RSUs also play a role as
CAs for registering and revoking IV permissions, ensuring shared data comes
from trusted sources. Two smart contracts are used to validate data, store
data, and retrieve data from the blockchain network.

In [175], authors introduced a consortium blockchain-based secure data sharing
system among IVs and RSUs, named DSSCB, for VANETS. The consortium blockchain,
in which RSUs are consensus nodes, was implemented to store shared data.
Besides, to protect data provenance and integrity, shared data would be signed
before transmission using a digital signature technique. Smart contracts are
designed to determine a reasonable incentive for data contributors. Authors
also imposed constraints on conditions to trigger smart contracts in order to
regulate data usage and sharing better.

The authors in [176] demonstrated a lightweight blockchain-based data-sharing
framework among vehicles and UAVs for rescuing in natural disasters where
network infrastructures were damaged. A vehicular blockchain was established
to record blocks of transactions between authorized UAVs and vehicles. In
addition, the authors presented a credit-based DPoS consensus process with
faster verification and lower energy consumption. Finally, reinforcement
learning techniques were used to facilitate the sharing of high-quality data.

The authors of [177] presented a blockchain-based high-speed data-sharing
system for vehicle-to-vehicle (V2V) communications in the Internet of Vehicles
(IoV) [174, 178]. Some authorized IVs are considered data providers since they
possess data collected and observed by their drivers in the presented system.
5th generation base stations provide high-speed transmission for V2V
communication and serve as data forwarders for vehicles. Data providers submit
their data indexes to consortium blockchain for rewards. A smart contract was
developed to verify and authenticate ratings from DRs after they receive
providers’ shared data, thereby facilitating the sharing of higher-quality
data. To increase the performance of the system in terms of delay and
throughput, the authors designed an enhanced delegated proof-of-stake (DPoS)
consensus protocol.

The authors in [179] integrated blockchain technology with FL to enable
sharing of data among vehicles in the IoV. In this paper, a hybrid blockchain
method for securely storing shared data events and ML model parameters was
developed, which included a permissioned blockchain established by RSUs and a
local DAG run by vehicles. With a DAG deployed on each vehicle, data sharing
became more efficient and rapid, especially in time-sensitive scenarios in the
IoV. Moreover, the shared data will be examined twice, promoting the exchange
of qualified data while avoiding the sharing of fraudulent data.

The authors in [180] focused on motivating data sharing among vehicles with a
mechanism to evaluate data quality using blockchain technology in the IoV. The
proposed architecture includes three main components: vehicles that collect,
sell, or request data; cloud/edge servers; and RSUs, which are a communication
bridge between vehicles and cloud/edge servers and run the consortium
blockchain network. Cloud/edger servers receive requests, conduct checks on
sellers’ off-chain data using an expectation maximization (EM) algorithm, and
make payments using a data quality-driven auction (DQDA). The data-sharing
process is automatically executed by the smart contract between vehicles and
edge/cloud servers.

In [123], authors proposed a blockchain-based secure storage and data-sharing
solution for vehicular edge computing and networks (VECONs). The solution
utilized a consortium blockchain run by RSUs to store and retrieve data from
data providers (vehicles) and DRs (vehicles), respectively. An edge node,
e.g., a RSU, that uses the most storage space to keep shared data is
recognized and receives rewards via a scheme managed by a data storage smart
contract and Proof-of-Storage protocol. In terms of the sharing scheme, an
ISSC smart contract, the PoW protocol, and a reputation-based mechanism with
three-weight subjective logic (TWSL) are utilized to assist in selecting
credible data providers and enable the exchange of high-quality data.

The work [181] utilized the consortium blockchain and smart contracts to
present a data storage and sharing architecture. The rating of a vehicle’s
shared data is calculated by its neighboring vehicle and then reviewed by the
nearest RSUs. This assures that shared data are trustworthy and high-quality,
boosting driving safety. Authenticated data would be considered to be appended
to the blockchain by employing a smart contract with the Practical Byzantine
Fault Tolerance (PBFT) consensus protocol. Vehicles that share and rate data
receive rewards for their contributions as an encouragement.

Lessons learned. The following are the principal lessons from the applications
towards the transportation sector:

  * •

There are three main types of shared data in transport applications: 1)
vehicle-generated data, such as weather conditions, road conditions, or engine
status, collected by sensors installed on vehicles; 2) data imported by
drivers and passengers, like nearby gas stations, charging stations, or
ratings of services in restaurants and hotels; and 3) verified data that
drivers found trustworthy and useful that is received from other vehicles and
RSUs in other areas but might be helpful and suitable on this road.

  * •

The majority of current research prefers to use permissioned blockchain, to
construct vehicular blockchain systems for data sharing due to resource-
constrained vehicles and traffic infrastructure, security, and privacy issues.
In order to store records of data sharing, including indexes of shared data,
ratings of shared data, or reputation scores of IVs who shared data, RSUs or
IVs are configured to act as consensus nodes. The vehicular blockchain network
only allowed authenticated and authorized vehicles to join and share data,
thus shared data are high-quality, traceable, and reliable. Additionally,
smart contracts are used and deployed on these blockchain nodes to make it
easier to store and share data by defining sets of rules for access control
and rewards.

  * •

Similar to healthcare and supply chain applications, data providers in
transportation applications are also concerned about the risk of sensitive and
personal data leakage, such as driver licenses and frequently traveled routes,
and are reluctant to share their data, even when the reward is high. Not to
mention that sharing data also costs them because they are resource-limited.
Almost current solutions have not yet pondered utilizing PPTs to enhance the
privacy of shared data for data providers. Although there have been a few
attempts to use PPTs, they are limited and need to be widely adopted.

Table VI: TAXONOMY OF BLOCKCHAIN-BASED DATA SHARING SOLUTIONS (CONTINUED)

Area | Ref. | Objective | Blockchain used | PPT | Key contributions | Limitations
---|---|---|---|---|---|---
|  |  |  Pub. |  Pri. |  Con. |  Hyb. |  |  |
Transportation |  [123] |  Data reliability |  - |  - |  ✓ |  - |  $\times$ |  A reputation-based data sharing scheme with TWSL model. |  Lacks performance evaluations.
[172] |  DAC, services |  - |  - |  ✓ |  - |  $\times$ |  Proposes an ABPRE algorithm for data searching, data retrieval. |  System performance.
[174] |  IV’s privacy |  - |  ✓ |  - |  - |  $\times$ |  Provides a cryptographic fingerprint and keys for each IV using PUF, public key infrastructure. |  Lacks performance evaluations.
[175] |  DUC, data reliability |  - |  - |  ✓ |  - |  $\times$ |  Provides a digital signature technique, an incentive mechanism. |  Security and costs on RSUs.
[176] |  Storage |  - |  ✓ |  - |  - |  $\times$ |  A lightweight BC with a credit-based DPoS protocol for disaster rescue. |  Scalability.
[177] |  Data reliability |  - |  - |  ✓ |  - |  $\times$ |  A high-speed data sharing system without RSUs, trust score management. |  Scalability.
[179] |  Data reliability |  - |  ✓ |  - |  - |  ✓ |  A BC-powered asynchronous FL architecture, two-stage verification. |  Lacks of incentive mechanism.
[180] |  Incentive |  - |  - |  ✓ |  - |  $\times$ |  A quality-focused assessment of the reward and off-chain data. |  Risks on the TA.
[181] |  Storage, incentive |  - |  - |  ✓ |  - |  $\times$ |  A reputation-based data sharing scheme using smart contracts. |  Lacks data privacy protection.
Smart grid |  [182] |  DAC, DUC |  - |  - |  ✓ |  - |  ✓ |  Avails DPaaS, develops a TEE-enabled off-chain smart contract. |  Identities are not guarded.
[183] |  Incentive, DAC |  - |  ✓ |  - |  - |  ✓ |  A PoA protocol, a privacy-based incentive mechanism, using differential privacy. |  Communication overhead.
[184] |  DAC |  - |  - |  ✓ |  - |  $\times$ |  On-chain/off-chain solutions with edge computing, a distributed authority. |  Lacks data privacy protection.
[185] |  DAC |  - |  - |  - |  ✓ |  $\times$ |  A dual BC with cloud storage for intelligent pricing system. |  Security, incentive.
[186] |  Incentive |  - |  ✓ |  - |  - |  $\times$ |  A realistic FDI attack model, an incentive-compatible mechanism. |  Lacks data privacy protection.
[187] |  Dual-side privacy |  - |  - |  ✓ |  - |  ✓ |  Presents a data obfuscation method. |  Computational overhead.
Data marketplace |  [124] |  ML models, IoT data |  - |  ✓ |  - |  - |  ✓ |  Proposes an AI model marketplace, a data estimation algorithm. |  Time for training on IoT devices.
[188] |  DAC, health data |  |  ✓ |  - |  - |  $\times$ |  Proposes a medical data marketplace model, a zk-SNARK protocol. |  Lacks incentive mechanism.
[189] |  IoT data |  - |  ✓ |  - |  - |  $\times$ |  Presents an IIoT data martketplace, trust score calculation, DID verification. |  Lacks shared data quality evaluation.
[190] |  IoT data |  ✓ |  - |  - |  - |  $\times$ |  Proposes an IoT data marketplace for smart cities using SC, SDPP. |  Scalability, data privacy.
[191] |  IoT data |  ✓ |  - |  - |  - |  $\times$ |  Presents an IoT data marketplace with querying and voting mechanism. |  Lacks data privacy protection.
[192] |  IoT data |  - |  - |  - |  - |  $\times$ |  Proposes a collectability-based IoT data marketplace model. |  Scalability, data privacy.
[193] |  Personal data |  - |  - |  - |  ✓ |  $\times$ |  A data marketplace with arbitration using a side-contracts mechanism. |  Time consumption for encryption.

  * •

* Pub., Pri., Con., and Hyb. stand for _Public_ , _Private_ , _Consortium_ , and _Hybrid_ , respectively.

  * •

* BC stands for blockchain.

###  V-D Smart Grid

A smart grid is a self-healing power network that uses digital technologies to
supply electricity to consumers via bidirectional communication [194, 195,
196]. This system enables monitoring, measuring, sharing, and controlling of
power and information flow to increase efficiency and resilience, optimize
energy consumption and costs, and reduce transmission losses. Smart grid
systems can be achieved by implementing electronic power generators,
transmission, distribution systems, control centers, renewable energy sources,
and energy storage integration. Following this development, smart grid 2.0 has
been developed to connect all energy sources anywhere, at any time, with the
aid of the Internet technology as the number of power resources surged and the
grid networks become more complex and distributed [35, 197]. Although the
trend toward moving to decentralized structures ameliorates the connectivity
and integration problems of the smart grid, how to exchange information among
entities in the grid system while complying with data privacy legislation and
ensuring data security remains a major barrier for researchers and companies.
Fortunately, blockchain technology offers excellent properties to not only
create decentralized grid systems but also enhance trust, data security, and
privacy for the information exchange of grid systems[198]. Here, we review
studies on smart grid applications relating to our framework.

Figure 13: A blockchain-based privacy-preserving data sharing system in smart
grid domain [182]

In [182], blockchain technology was used to present a data-sharing scheme with
the management of private DAC and DUC. A framework, called SPDS, was proposed
allowing DPs to establish access policies and track historical usage records
over their shared data. Moreover, a smart contract-based data processing as a
service (DPaaS) solution was developed to secure shared data privacy and
reduce the computing demands on user devices.

In [183], authors proposed a blockchain-based data-sharing system that trades
off privacy risks against rewards in deregulated smart grids. A Proof of
Authority (PoA) protocol that enables a mining node with the highest
reputation score to have a chance to append its block to the chain was
presented to minimize computational and gas costs, and achieve reliability for
the process of reaching a consensus in the blockchain network. Moreover, the
authors designed a fair incentive mechanism based on the levels of risks
related to privacy to motivate customers who have valuable data to share.
Finally, to reduce the possibility of original information leakage,
differential privacy technique was utilized.

The authors in [184] focused on designing an edge blockchain-enabled DAC
framework using CP-ABE, _(t, n)_ threshold secret sharing scheme (TSSS), IoT
devices and Hyperledger Fabric. CP-ABE was used to establish an access control
attribute-based mechanism over shared data for DRs. Besides, both on-chain and
off-chain models were proposed for flexible data sharing and data storage. To
mitigate computational burdens on resource-constrained device nodes,
cryptographic operations are outsourced to a consortium blockchain network.
Unlike conventional centralized authority approaches, _(t, n)_ TSSS was given
to build up a distributed authority that assists to solve the SPOF problem.

In [185], authors proposed a dual blockchain-based electricity data-sharing
solution for power supply’s pricing center in smart grids. With the support of
cloud infrastructure, encrypted shared data was securely stored, and it
minimized storage costs for blockchain network. The private blockchain is