# BDTS: A Blockchain-based Data Trading System
with Fair Exchange

Bo Qin†, Qin Wang≀, Qianhong Wu‡, Sanxi Li†, Wenchang Shi†, Yingxin Bi†, Wenyi
Tang§ † Renmin University of China, Beijing, China
§ University of Notre Dame, Indiana, US
‡ Beihang University, Beijing, China
≀ CSIRO Data61, Sydney, Australia

###### Abstract.

Trading data through blockchain platforms is hard to achieve fair exchange.
Reasons come from two folds: Firstly, guaranteeing fairness between sellers
and consumers is a challenging task as the deception of any participating
parties is risk-free. This leads to the second issue where judging the
behavior of data executors (such as cloud service providers) among distrustful
parties is impractical in traditional trading protocols. To fill the gaps, in
this paper, we present a blockchain-based data trading system, named BDTS. The
proposed BDTS implements a fair-exchange protocol in which benign behaviors
can obtain rewards while dishonest behaviors will be punished. Our scheme
leverages the smart contract technique to act as the agency, managing data
distribution and payment execution. The solution requires the seller to
provide consumers with the correct decryption keys for proper execution and
encourages a rational data executor to behave faithfully for maximum benefits.
We analyze the strategies of consumers, sellers, and dealers based on the game
theory and prove that our game can reach the subgame perfect Nash equilibrium
when each party honestly behaves. Further, we implement our scheme based on
the Hyperledger Fabric platform with a full-functional design. Evaluations
show that our scheme achieves satisfactory efficiency and feasibility.

##  1\. Introduction

Recently, data affects every field in the world as its commercial value is
being gradually excavated. It plays an important role in commercial ecosystems
where many producers sell data such as movies, novels, and videos for profits.
Meanwhile, artificial intelligence takes data as raw material, generating
useful data for further usage. To facilitate data exchange, data trading
intermediaries (also known as dealers, agent or data executor) have recently
proliferated (liu2019novel, ) and many of them earn agency fees between
sellers and consumers. Consumers, sellers, and dealers together form a
thriving data trading ecosystem. In a traditional data trading ecosystem, a
consumer has to pay a fortune to the seller for acquisition and the seller
could make some profits by providing the appropriate data. Fairness and
security are all guaranteed by a trusted dealer.

However, such a high density of centralization is likely to be the weak spot
to be attacked. On the one hand, any participating roles may act maliciously
in the unsupervised system. In a transaction, sellers may provide fake data
for profits as they may not own data as they claimed. The consumer may refuse
to pay after receiving the appropriate data. The service providers (dealers)
such as cloud service providers may manipulate the stored data without
permission from users (wang2011toward, )(zhu2011dynamic, ). On the other hand,
relying on centralized servers confront heavy communication and security
pressure, greatly constraining the efficiency of the entire trading system. A
single point service provider may lead to unpleasant downloading experiences
due to its limited resources, such as bandwidth, which may fail to cope with
the environment of large-scale downloading. Moreover, the service providers
providing download services may fabricate data to earn profits. Rewarding or
punishing them for their misbehaviors is difficult due to the absence of valid
evidence. An inappropriate incentive may decrease their willingness to act
honest behaviors. These challenges lead to the following questions,

Is it possible to propose a protocol in the data trading system with
guaranteed fairness for both participated parities without significantly
compromising efficiency?

Traditional solutions (kupccu2010usable, )(micali2003simple, ) provide
countermeasures by using cryptography technologies. This series of schemes
implicitly rely on a strong assumption of the trusted third party (TTP). This
means a TTP must obey all the predefined rules and act honestly. However,
realizing a completely fair exchange protocol without the TTP is impossible
(pagnia1999impossibility, ), and it is widely acknowledged that finding such a
TTP is reckon hard in practice. Instead of using the seemingly old-fashioned
cryptographic gradual release method111The gradual release method means each
party in the game takes turns to release a small part of the secret. Once a
party is detected doing evil, other parties can stop immediately and recover
the desired output with similar computational resources. (blum1983exchange,
)(pinkas2003fair, ), many solutions (dziembowski2018fairswap, )(he2021fair,
)(shin2017t, )(choudhuri2017fairness, )(kiayias2016fair, )(eckey2020optiswap,
) have been proposed by leveraging blockchain technologies (wood2014ethereum,
) for better decentralization. Blockchain provides a public bulletin board for
every participating party with persistent evidence. Any malicious activities
can be traced back later on for the claim of compensation.

Based on such investigations, we adopt the blockchain technique as our
baseline solution. Blockchain brings benefits to our fair exchange protocol
from three folds. Firstly, thanks to the decentralization character of
blockchain, this mechanism ensures that the platform can always benignly act
and follow the agreed principles. A normal operating blockchain platform
greatly reduces the risk of being attacked like a single-point failure or
compromised by adversaries. Secondly, exposing parts of data on the blockchain
as public information can decrease the risk of sellers’ providing data far
from the description, (which is called fake data below). The content of these
parts can be verified by potential consumers so that fake data cannot be
accepted and will not create profits. Thirdly, using distributed and peer-to-
peer optimization as references, we also allow any participants, who own data
backup, to provide downloading services for earning extra revenues. Consumers
can download from multiple dealers directly and accordingly pay some fees to
these self-service providers. This will incentive involved participants.

Specifically, we implement our scheme with strict logic of fair exchange on
the Hyperledger blockchain (androulaki2018hyperledger, ) to ensure the
exchange fairness that are threatened from four aspects: (i) the seller may
provide fake data, (ii) the seller may provide a false decryption key, (iii)
the consumer may not pay for authentic data or (iv) resell data for multiple
times. In our design, the deployed blockchain smart contracts can regulate
that: the uploaded data by users and the related decryption key from sellers
are authentic whereas fake ones cannot pass the verification (conquer i and
ii); a consumer automatically gets charged for requested data (overcome iii);
and every data can only be sold once since each transaction is unique in the
blockchain systems (address iv). Notably, we use the uniqueness index
mechanism and compare Merkle roots of different data to prevent someone from
reselling data purchased from others. We only guarantee that the data sold on
this platform is unique and reselling through other platforms is beyond this
article’s scope.

Contributions. Overall, implementing a data trading system with both exchange
fairness and efficiency for real usage is the key task in this paper. To fill
the gap, our contributions are as follows.

  * •

We purpose BDTS, an innovative data trading system based on blockchain. The
proposed scheme realize the exchange fairness for all participated parties,
namely, consumer, seller and service provider. Each party has to obey the
rules, and benign actors can fairly obtain rewards as the incentive.

  * •

We prove the security of our scheme majorly from the economical side based on
game theory. Our game theory-based proof simulates the behaviors of different
parities in real scenarios, which is an effective hint to show actual
reflection towards conflicts as well as real action affected by competitive
peer members. The proofs demonstrate that our game reaches the subgame perform
equilibrium.

  * •

We implement our scheme on the Hyperledager blockchain platform with
comprehensive evaluations. Experimental testing results prove this. the
practicability and efficiency of our scheme. Compared to existing solutions
with complex crypto-algorithms (such as ZKP), our scheme is sufficiently fast
for lightweight deceives.

Paper Structure. Section 2 presents preliminaries. Section 3 provides a bird’s
view of our scheme with security assumptions and models. Section 4 details our
system. Section 5 presents our implementations on Hyperledger. Section 6
proves its security while Section 7 discusses efficiency. Section 8 provide
further discussions. Section 9 reviews related work surrounding our system.
Appendix A-C provide supplementary details of this work.

##  2\. Preliminary

This section introduces the core components of blockchain systems that are
closely related to our scheme, including smart contract, and Merkle Tree.
Also, we give a snapshot of the concept of Nash equilibrium used in our
security proofs.

Smart Contract. The smart contract, proposed by Szabo (szabo1996smart, ), aims
to enable the self-execution of clauses and logic. Since the emergence of
Ethereum (wood2014ethereum, ), the concept of the smart contract becomes
prevailing (dwivedi2021legally, )(li2022sok, ). It is a program deployed and
executed based on blockchain with benefits of decentralization, automation,
and unforgeability. A normal operating blockchain system can trigger the state
transition of the contract. Miners would guarantee the consistency of state
across different nodes. It can be seen as a procedure that will be executed by
almost all miners and the result agreed upon by more than half will be
considered the final result. Also, they will verify the results and reject the
false ones. Thus, the smart contract can hardly be falsified and it’s
considered to be sufficiently secure in the blockchain ecosystem.

Technically, in Ethereum, a smart contract contains a 160-bit address named
contract account, runtime, bytecode, and a bunch of related transactions
(delmolino2016step, ). After being written and compiled into bytecode, a smart
contract should be deployed so that miners can record and then invoke it. The
deployer builds a transaction (Tx) with bytecode, signature, and so on. Then,
the deployer sends Tx to miners, waiting for miners to pack it. The miner will
verify the signature and then pack it into a block so that every node can
reach an agreement on the same state. After being deployed, the smart contract
gets its unique account address. Everyone can interact with it by sending
another Tx to that address. This latter Tx will be packed into a block as well
and every miner will execute the smart contract in Ethereum Virtual Machine
(EVM). The result of it will be recorded and confirmed by miners.

Merkle Tree. Merkle tree is a type of tree designed in a layered architecture.
Every parent node (the top one is denoted as root) stores the hash of its
subnodes, while the leaf node in the bottom layer stores the hash value of
data. A typical Merkle Tree consists of three algorithms, namely,
$\mathsf{Mtree}$, $\mathsf{Mproof}$, and $\mathsf{Mvrfy}$. The algorithm
$\mathsf{Mtree}$ takes data $(x_{1},x_{2},...,x_{n})$ as input and outputs
Merkle tree $M$ with root $r$. $\mathsf{Mproof}$ takes an index $i$ and $M$ as
input and outputs the proof $\pi$. $\mathsf{Mvrfy}$ takes $(\pi,r,x_{i},p)$ as
input and return true if is the same as before, otherwise it returns false.
Merkle tree is used to efficiently verify a large size of stored data. It
ensures the data received from peers stays undamaged and unchanged. Merkle
tree is one of the foundational components for building a blockchain, securing
the system with a strong data integrity promise.

Strategy | A | B | $p_{i}$
---|---|---|---
$p_{j}$ | A | 1,1 | 1,-1 |
B | -1,1 | 0,0 |

Game theory. Game theory provides an ideal environment to simulate the
interactions among rational decision-makers (also known as players). It
utilizes a set of mathematical tools to drive every possibility and
corresponding impact. Each decision-maker in the game targets to maximize its
utility by also considering strategies from others. The game will reach a Nash
equilibrium if no players can gain higher utility by altering their strategy
while others remain unchanged as well. For instance, in a most generic model
(static non-cooperative game model (harker1991generalized, )), if the first
player $p_{i}$ adopts strategy A whereas the second player $p_{j}$ selects B,
both of them cannot obtain the overall maximum utility. If $p_{i}$ adopts A
while $p_{j}$ with B, the system will reach a Nash equilibrium, as shown in
the following table. Our analysis is based on a (dynamically) sequential game
theory model (fang2021introduction, ) where a follower acts later than the
previous player. Our security goal is to make each participant adopt an honest
strategy so that the game will finally achieve the subgame perfect Nash
equilibrium (moore1988subgame, ). This is also the Nash equilibrium for the
entire system.

##  3\. Architecture and Security model

In this section, we firstly introduce system targets and architecture. Then,
we provide security assumptions and a security model.

###  3.1. Problem Overview

Entities. First of all, we clarify the participated roles in our scheme. A
total of three types entities are involved: consumer (CM), seller (SL), and
service provider (SP)222Service providers generally act as the role of
centralized authorities such as dealers and agencies in a traditional fair
exchange protocol.. Consumers pay for data and downloading service with
cryptocurrencies such as Ether. Sellers provide encrypted data as well as
exposing the segment of divided data when necessary to guarantee correctness.
Service providers take tasks of download services, and any participant who
stores encrypted data can be regarded as a service provider. Miners and other
entities participating in systems are omitted as they are out of the scope of
this paper.

Problem Statement. Then, we have a quick summary of problems existing in
current data trading systems.

The fairness of data trading cannot be guaranteed. The fairness of the data
trading system includes two folds. The data providers (sellers) should be paid
enough according to their contributions and data users (consumers) should be
charged faithfully. Data reselling is another threat that may harm the
sellers’ profits.

The quality of data may not as true as descriptions provided by sellers.
Sellers should provide authentic data just as they claim False advertising
will damage the interests of consumers. How to prevent sellers from providing
lousy data is a challenge as well.

Rewarding or punishing service providers of their misbehaviors is difficult.
Service providers provide download services to earn profits, but they may
manipulate or misuse data. Judging whether a service provider send appropriate
data or not is a hard task.

A large-scale downloading request may lead to high communication pressure. For
trading markets, the trading size is huge and the efficiency requirement is
strict. Traditional single-point model cannot bear this pressure and may
reduce efficiency. The involvement of multiple service providers can speed up
the download.

Desired Requirements. To address such issues, the proposed BDTS system should
fulfill the following requirements.

A protocol with guarantees on exchange fairness. The fairness ensures both
sellers and consumers can faithfully obtain the rewards based on their actual
activities.

Every piece of uploaded data should be authentic. The requirement mainly
refers to data during the on-chain stage, rather than the off-chain phase. The
system should guarantee that the data transferred in the system cannot be
falsified or destroyed. This ensures participants can exchange high-quality
data.

Incentive designs should be considered to avoid unnecessary frictions.
Economical incentive is important for the encouragement of involved parties to
act honestly.

The system should operate with satisfactory performance. Regarding the high
volume of data such as streaming data (video/audio), the system should have
enough bandwidth and sufficient efficiency.

###  3.2. Architecture.

We design a novel data trading ecosystem that builds on the top of the
blockchain platform. A typical workflow in BDTS is that: Sellers upload their
encrypted data and description to service providers. Service providers store
received data and establish download services. Consumers decide which pieces
of data to purchase based on related descriptions. At last, the consumer
downloads from service providers and pays the negotiated prices to sellers and
service providers. Our fair exchange scheme is used to ensure every
participant can exchange data with payments without cheating and sudden
denial. The detailed execution flow is presented as follows.

Data Upload. The seller first sends his description of data to the blockchain.
Description and other information such as the Merkle root of data would be
recorded by blockchain. Here, the seller must broadcast the Merkle root and
they are demanded to provide some parts in plaintext form. Service providers
can decide whether they are going to store it by the stated information. At
the time, the seller waits for the decision from the service providers. If a
service provider decides to store encrypted data for earning future
downloading fees, he first sends his information to the blockchain. The seller
will post encrypted data to the service provider and the service provider
starts to store the raw data. Notably, the seller can also become a self-
maintained service provider if he can build up similar basic services.

Data Download. The consumer decides to download or not according to the
description and exposed parts provided by the seller. Before downloading, the
consumer should first store enough tokens on the smart contract. Then, the
consumer sends a request for data from service providers. Service providers
will send it to the consumer after encrypting the raw data with the private
key. For security and efficiency, these processes will be executed via smart
contracts, except for data encryption and downloading.

Decryption and Appealing. At last, the consumer should pay for data and get
the corresponding decryption key. The service provider and seller will provide
their decryption key separately. The decryption key is broadcast through the
blockchain so that it cannot be tampered with. The consumer can appeal if he
confronts any issues. According to predefined rules. The smart contract will
arbitrate based on evidence provided by the consumer.

###  3.3. Security Assumption

In this scheme, we have three basic security assumptions.

The blockchain itself is assumed to be safe. Our scheme operates on a safe
blockchain model with well-promised liveness and safety (garay2015bitcoin, ).
Meanwhile, miners are considered to be honest but curious: they will execute
smart contracts correctly but may be curious about the plaintext recorded on-
chain.

The basic crypto-related algorithm is safe. This assumption indicates that the
encryption and decryption algorithm will not suffer major attacks that may
destroy the system. Specifically, AES and the elliptic curve, used for
asymmetric encryption algorithms, are sufficiently supposed to be safe in
cryptography.

Participants in this scheme are rational. As the assumption of game theory,
all players (consumer, seller, and service provider) are assumed to be
rational: these three types of players will act honestly but still pursue
profits within the legal scope.

###  3.4. Security model

Before analyzing the game among consumers, sellers, and service providers, we
dive into the strategies of each party.

Seller. Sellers intend to obtain more payment by selling their data. In our
scheme, a seller needs to provide mainly three sectors: data, description, and
decryption-key. To earn profits, a seller would claim the data is popular and
deserved to be downloaded, but he may provide fake data. From the perspective
of commercialization, the description of data is hard to distinguish, in which
consumers pay for data merely by relying on it. The exchange is deemed as fair
if consumers obtain authentic data that is matched with claimed descriptions.
Then, the seller can receive rewards. The encryption is another component
provided by the seller. Only the correct decryption key can decrypt the
encrypted data, whereas the false one cannot. In summary, there are four
potential strategies for sellers: a) matched data (towards corresponding
description) and matched key (towards data), b) matched data and non-matched
key, c) non-matched data and matched key, and d) non-matched data and non-
matched key.

Consumer. Consumers intend to exchange their money for data and downloading
services. Downloading ciphertext and decrypting it to gain plaintext is in
their favor. Consumers provide related fees in our scheme and then download
encrypted data from service providers who store the uploaded data. To earn
profits, they intend to obtain data without paying for it, or paying less than
expected. Paying the full price as expected for data is a sub-optimal choice.
The payment of consumers can be divided into two parts: paying the seller for
the decryption key and paying service providers for the downloading service.
Based on that, there are four strategies for consumers: a) pay enough for
sellers, b) pay less for sellers, c) pay enough for service providers, and d)
pay less for service providers.

Service Provider. Service providers intend to provide the downloading service
and earn profits. They will obtain a downloading fee paid from consumers
instead of a conventional storage fee. Service providers can receive
encryption data uploaded from sellers and then provide downloading services
for consumers. For uploading, service providers can choose whether to store
data or not. Here, a seller can act as a service provider by himself if he can
provide similar services of storage and download. For downloading, service
providers will provide encrypted data and the corresponding decryption key.
The strategies for service providers are listed as follows: a) authentic
correct data and matched key, b) authentic data and non-matched key, c) fake
data and matched key, and d) fake data and non-matched key. The first two need
the premise of storing the seller’s data.

For security, an ideal strategy for the system is to reach a Nash equilibrium
for all participants: sellers adopt the correct data and matched key strategy,
consumers adopt the pay enough for sellers, paying enough for service
providers and service providers who provide storing services adopt the
authentic correct data and matched key strategy (discussed in Sec.6).

##  4\. The BDTS Scheme

In this section, we provide the concrete construction. To achieve security
goals as discussed, we propose our blockchain-based trading system, called
BDTS. It includes four stages: contract deployment, encrypted data uploading,
data downloading, and decryption and appealing. Our scheme involves three
types of contracts. Here, we omit the procedures such as the signature
verification and block mining because they are known as the common sense.

###  4.1. Module design

The system contains three types of smart contracts: seller-service provider
matching contract (SSMC), service provider-consumer matching contract (SCMC),
and consumer payment contract (CPC).

Seller-service provider matching contract. SSMC records the description and
the Merkle root of data. The seller is required to broadcast certain parts of
data and the index of these parts should be randomly generated by the
blockchain. It should be noted that these indexes cannot be changed once they
have been identified. Last, SSMC matches service providers for every seller.

Service provider-consumer matching contract. SCMC helps service providers and
consumers reach an agreement. It receives the consumers’ data, including
required data and related information, and then stores them. The contract
requires consumers to send payment. Then, the payment is sent to CPC for the
next step.

Consumer payment contract. CPC works to command consumers to pay for data and
command sellers to provide the decryption key. It achieves the fair exchange
between decryption key and payment as well as between downloading and payment.

###  4.2. Encrypted Data Upload

In this module, a seller registers on SSMC and exposes some parts of his data.
The service provider stores encrypted data (cf. Fig.4.a).

Step1. When a seller expects to sell data for profits, he should first divide
data into several pieces and encrypt them separately with different keys
(denoted as $K_{i}$, where $i=1,2,...,n$), which is generated based on $K$.
Such pieces of data should be valuable so that others can judge the quality of
full data with the received segments. Here,
$D_{i}=Enc^{AES}_{K_{i}}(Data_{i})$ is the encrypted data.

Step2. The seller sends a registration demand in the form of a transaction.
The registration demand includes seller’s information and data description.
The seller information consists of $A_{seller}$ and $IP_{seller}$. Data
description includes four main parts: content description, data size, the root
$r_{d}$ and the root $r_{e}d$. Here, $r_{d}$ is the root of $M_{d}$ and
$r_{ed}$ is the root of $M_{ed}$, where
$M_{d}=\mathsf{Mtree}(Data_{1},Data_{2},...,Data_{n})$ and
$M_{ed}=\mathsf{Mtree}(D_{1},D_{2},...,D_{n})$. They will be recorded in SSMC.
The deposit will also be sent in this step. SSMC will reject the request if
the corresponding $r_{d}$ is the same as that of data recorded before. This
mechanism prevents reselling on the blockchain platform.

Step3 and Step4. After approving the seller’s registration demand, SSMC stores
useful information. Blockchain generates the hash of the next block, which is
used as a public random $seed$.

Step5, and Step6. The seller runs $\mathsf{Rand}(seed)$ to get $I_{rand}$ and
provides ($data_{I_{rand}},P_{d_{i}},P_{ed_{i}})$ to SSMC, where
$P_{d_{i}}=\mathsf{Mproof}(M_{d},i)$ and
$P_{ed_{i}}=\mathsf{Mproof}(M_{ed},i)$. Then, the contract SSMC checks
$\mathsf{Mvrfy}(i,r_{d},Data_{i},P_{d_{i}})==1$ and
$\mathsf{Mvrfy}(i,r_{ed},D_{i},P_{ed})==1$. If not, SSMC stops execution and
returns error. Then, the exposed pieces of data will be compared to other
pieces by utilizing the uniqueness index (chen2017bootstrapping, ). Data
plagiarism will result in deposit loss, preventing the reselling behavior.

Step7 and Step8. The service provider (SP) registration demand can be divide
into $IP_{sp}$, $A_{sp}$, and $ID_{data}$.

Step9, Step10 and Step11. The seller sends encrypted data and Merkle proof to
the service provider according to $IP_{sp}$ and confirms the service provider
registration demand so that the corresponding service provider can participate
in the next stage.

###  4.3. Matching and Data Downloading

In this module, a consumer registers on SCMC and selects the service provider
to download data (see Fig.4.b).

Step1 and Step2. The consumer queries for data description to the
corresponding service provider. Once the consumer receives the feedback from
SSMC, he select data according to requirements.

Step3, Step4, Step5. The consumer stores the tuple
$(IP_{sp},A_{cm},ID_{data})$ on SCMC and sends enough tokens to pay for the
download service. These tokens will be sent to CPC and, if unfortunately the
service provider or seller cheat at this transaction, will be returned to the
consumer. When receiving the demand, SCMC queries SSMC with $ID_{data}$ to
obtain price and data size. Then, SCMC will verify $Tkn_{cm}\geq
price+size*unit\,price$. Failed transactions will be discarded while the rest
be broadcast. The seller can determine to download which part of data or from
which service providers by giving index $i$ and the corresponding address.

Step6, Step7, Step8. The consumer contacts with the service provider based on
$IP_{sp}$, which is received in Step2. In Step7, a service provider encrypts
data $D$ with the random key $K_{sp}$. The service provider will calculate
$M_{eed}$, where $M_{eed}=\mathsf{Mtree}(Enc^{AES}_{K_{sp}}(D_{1}),\\\
Enc^{AES}_{K_{sp}}(D_{2}),...,Enc^{AES}_{K_{sp}}(D_{n}))$, with the Merkle
root $r_{eed}$ and uploaded $P_{eed_{i}}$, where
$P_{eed_{i}}=\mathsf{Mproof}(M_{eed},i)$ and $i$ is the index.

Step9. The selected service provider information is provided in this step. It
is composed of $A_{sp}$ and the index of downloading pieces from the
corresponding service providers. The consumer can download data from different
service providers for efficiency.

Step12, Step13, and Step14. The consumer acquires from SCMC. After the service
provider sends $Enc^{AES}_{K_{sp}}$ and $P_{eed_{i}}$ to consumers, consumers
will verify whether
$\mathsf{Mvrfy}(i,r_{eed},Enc^{AES}_{K_{sp}},P_{eed_{i}})==1$. If not, the
(double-)encrypted data will be considered as an error if it cannot pass the
verification and the consumer, as a result, will not execute step14.

###  4.4. Decryption and Appealing

In this module, the consumer pays to both the service provider and the seller
(see Fig.4.c).

  * -

Step1, Step2, Step3. SSMC transfers tokens and $(A_{cm},A_{sp},\\\ ID_{data})$
to CPC. The consumer generates a key pair $(Pub_{cm},\\\ Pri_{cm})$ and
broadcast $Pub_{cm}$ to CPC. CPC waits for the service provider to get
$Enc_{Pub_{cm}}(K_{sp})$. If obtaining it, CPC will wait for a while for the
appealing process. Otherwise, CPC will send tokens to the service provider
directly.

  * -

Step4, Step5, and Step6. The consumer obtains $Enc_{Pub_{cm}}(K_{sp})$ from
CPC and decrypts it with his private key. Then decrypt data with $K_{sp}$ to
get $D_{i}$. If $\mathsf{Mvrfy(i,r_{ed},D_{i},P_{ed})\neq 1}$, the consumer
executes the appealing phase. Appeal contains
$(Pri_{cm},i,Enc^{AES}_{K_{sp}}(D_{i}))$. Here, $Pri_{cm}$ is generated in
every download process.

  * -

Step7, Step8, Step9. CPC calculates both $K_{sp}$ and $D_{i}$, where
$K_{sp}=Dec_{pub_{cm}}(Enc_{pub_{cm}}(K_{sp}))$ while the decryption key
$D_{i}=Dec^{AES}(Enc^{AES}_{K_{sp}}(D_{i}))$. Then, CPC verifies whether
$\mathsf{Mvrfy}(i,r_{ed},D_{i},P_{ed})\neq 1$. If it passes the verification,
CPC withdraws the tokens to SSMC. Otherwise, CPC will pay to the service
providers.

Paying the seller is similar to paying to the service providers, the
differences between mainly concentrate on Step2, Step3, Step4, Step7, and
Step8 (see Fig.4.d).

  * -

Step2, Step3 and Step4. The consumer generates a new public-private key pair
$(Pub_{cm},Pri_{cm})$ and broadcasts $Pub_{cm}$ to CPC. After listening to CPC
to get $Pub_{cm}$, the seller calculate $Enc_{pub_{cm}}(K_{seller})$ and send
it to CPC.

  * -

Step7 and Step8. During the appealing phase, the consumer relies on his
private key to prove his ownership. CPC verifies the encryption of the
corresponding data, which is similar to the step of paying for service
providers. The verification will determine the token flow.

##  5\. Implementations

In this section, we provide the detailed implementation of three major
functions, including sharding encryption that splits a full message into
several pieces, product matching to show the progress of finding a targeted
product, and payment that present the ways to pay for each participant. Our
full practical implementation is based on Go language with 5 files, realizing
the major functions of each contact that can be operated on Hyperledger
platform333Source code: Hidden due to the anonymity policy.. We provide
implementation details in Appendix A.

##  6\. Security Analysis

In this section, we provide the analysis of BDTS based on game theory. The
basic model of our solution is a dynamically sequential game with multiple
players. The analyses are based on backward induction. We prove that our model
can achieve a subgame perfect Nash equilibrium (SPNE) if all participants
honestly behave.

Specifically, our proposed scheme consists of three types of parties,
including seller (SL), service provider (SP), and consumer (SM) as shown in
Fig.1 (left). These parties will act one by one, forming a sequential game.
The following party can learn the actions from the previous. Specifically, A
SL will first upload the data with the corresponding encryption key to the SP
(workflow in black line). Once receiving data, the SP encrypts data by his
private key, and stores the raw data at local while related information is on-
chain. A CM searches online to find products and pay for the favorite ones
both to SP and SL via smart contracts (in blue line). Last, the SP sends the
raw data and related keys to CM (in brown line). Based on that, we define our
analysis model as follows.

######  Definition 1.

Our SM-SP-CM involved system forms an extensive game denoted by

$\mathcal{G}=\\{\mathcal{N},\mathcal{H},\mathcal{R},P,u_{i}\\}.$

Here, $\mathcal{N}$ represents the participated players where
$\mathcal{N}=\\{SL,SP,CM\\}$; $\mathcal{R}$ is the strategy set; $\mathcal{H}$
is the history, $P$ is the player function where
$P:\mathcal{N}\times\mathcal{R}\xrightarrow{}\mathcal{H}$; and $u_{i}$ is the
payoff function.

For each of participated parties, they have four strategies as defined in
Sec.3.4 (security model). SL has actions on both updated data and related
decryption keys (AES for raw data), forming his strategies $\mathcal{R}_{SL}$,
where $\mathcal{R}_{SL}=\\{a,b,c,d\\}$. Similarly, CM has strategies
$\mathcal{R}_{CM}=\\{e,f,g,h\\}$ to show his actions on payments to SL or SP.
SP has strategies $\mathcal{R}_{SP}=\\{i,j,k,l\\}$ for actions on downloading
data and related keys. We list them at Table.1. However, it is not enough for
quantitative analysis of the costs of these actions are unknown. According to
the market prices and operation cost, we suppose that a piece of raw data
worth $10$ units, while generating keys compensates $1$ unit. The service fee
during the transactions is $1$ units for each party. Thus, we provide the cost
of each strategy in the Table.1. The parameters of $x$ and $y$ are actual
payments from CM, where $0\leq x<20,0\leq y<4,x+y<24$.

Figure 1. Game and Game Tree

Then, we dive into the history set $\mathcal{H}$ that reflects the conducted
strategies from all parties before. For instance, the history $aei$ represents
all parties performing honestly. There are a total of 64 possible combinations
(calculated by $64=4*4*4$) based on sequential steps of SL, SM, and SP. We
provide their game tree in Tab.1 (right). We omit their detailed
representation due to their intuitive induction. Our analysis is based on
these fundamental definitions and knowledge. We separately show the optimal
strategy (with maximum rewards) for each party, and then show how to reach a
subgame perfect Nash equilibrium, which is also the Nash equilibrium of the
entire game. Before diving into the details of calculating each subgame, we
first drive a series of lemmas as follows.

######  Lemma 1.

If one seller provides data not corresponding to the description, the seller
cannot obtain payments.

######  Proof.

The description and Merkle root of data are first broadcast before the
generation of random indexes. Once completing the registration of the seller,
the blockchain generates a random index. Exposed pieces are required to match
the Merkle roots so that the seller cannot provide fake ones. Meanwhile, these
pieces ensure that data can conform to the description. Otherwise, consumers
will not pay for the content and service providers will not store it, neither.
∎

######  Lemma 2.

If one seller provides a decryption key not conforming to the description, the
seller cannot obtain payments.

######  Proof.

The seller encrypts data (segmented data included) with his private keys. The
results of both encryption and related evidence will be recorded by the smart
contract, which covers the Merkle root of encrypted data and the Merkle root
of data. If a seller provides a mis-matched key, the consumer cannot decrypt
the data and he has to start the appealing process. As $D_{i}$ and receipt are
owned by the consumer, if the consumer cannot obtain correct data, the
consumer can appeal with evidence. The smart contract can automatically judge
this appeal. If submitted evidence is correct as well as the decryption result
cannot match the Merkle root of data, the smart contract will return deposited
tokens to the consumer. ∎

Table 1. Strategies and Costs

SL Strategy | Matched data | Non-matched data
---|---|---
Matched key | a, -11 | b, -1
Non-matched key | c, -10 | d, 0
CM Strategy | Sufficiently | Insufficiently (to SL)
Sufficiently (to SP) | e, -24 | f, -(x+4)
Insufficiently Paid | g, -(y+20) | h, -(x+y)
SP Strategy | Authentic data | Non-authentic data
Matched key | i, -2 | j, -1
Non-matched key | k, -1 | l, 0

  * •

The cost of -11 units are short for -11, applicable to all.

  * •

Data is sold at 20 (to SL) while the service fee is 4 (to SP).

######  Lemma 3.

A consumer without sufficient payments cannot normally use the data.

######  Proof.

The consumer will first send enough tokens to SCMC and this code of the smart
contract is safe. The smart contract will verify whether the received tokens
are enough for the purchase. After the seller and consumer provide their
decryption key through the smart contract, the consumer can appeal at a
certain time, or it’s considered that the key is correct and payments will be
distributed to the seller and service providers. ∎

######  Lemma 4.

If one service provider provides data not conforming to that of the seller, he
cannot obtain payments.

######  Proof.

This proof is similar to Lemma 1. ∎

######  Lemma 5.

If one service provider provides a decryption key not conforming to data, he
cannot obtain payments.

Here, Lemma 1 to Lemma 5 prove the payoff function of each behavior. Based on
such analyses, we can precisely calculate the payoff function of combined
strategies in our sequential game. As discussed before, a total of 64 possible
combinations exist, and we accordingly calculate the corresponding profits as
presented in Tab.2. We demonstrate that the system can reach the subgame
perfect Nash equilibrium under the following theorem.

######  Theorem 1.

The game will achieve the only subgame perfect Nash equilibrium (SPNE) if all
three parties act honestly: sellers upload the matched data, matched key,
service providers adopt the authentic data, and matched decryption key, and
consumers purchase with sufficient payments. Meanwhile, the SPE is also the
optimal strategy for the entire system as a Nash Equilibrium. ∎

######  Proof.

First, we dive into the rewards of each role, investigating their payoffs
under different strategies. For the seller, we observe that the system is not
stable (cannot reach Nash equilibrium) under his optimal strategies. As shown
in Tab.2, the optimal strategies for sellers (dei,dej,dek,del,dgi,dgj,dgk,dgl)
is to provide mismatched keys and data, while at the same time obtain payments
from consumers. However, based on Lemma 1 and Lemma 2, the seller in such
cases cannot obtain payments due to the punishment from smart contracts. These
are impractical strategies when launching the backward induction for the
subgame tree in Fig.1. Similarly, for both consumers and service providers,
the system is not stable and cannot reach Nash equilibrium under their optimal
strategies. Based on that, we find that the optimal strategy for each party is
not the optimal strategy for the system.

Then, we focus on strategies with the highest payoffs (equiv. utilities). As
illustrated in Tab.2 (red background), the strategies of aei, afi and agi hold
the maximal payoffs where $u_{aei}=u_{afi}=u_{agi}=7$. Their payoffs are
greater than all competitive strategies in the history set $\mathcal{H}$. This
means the system reaches Nash equilibrium under these three strategies.
However, multiple Nash equilibriums cannot drive the most optimal strategy
because some of them are impractical.

We conduct the backward induction for each game with Nash equilibriums. We
find that only one of them is the subgame perfect Nash equilibrium with
feasibility in the real world. Based on Lemma 3, a consumer without sufficient
payments, either to the seller or service provider, cannot successfully
decrypt the raw data. He will lose all the paid money ($x+y$). This means both
afi and agi are impractical. With the previous analyses in the arm, we finally
conclude that only the strategy aei, in which all parties act honestly, can
reach the subgame perfect Nash equilibrium. This strategy is also the Nash
equilibrium for the entire BDTS game. ∎

Table 2. Payoff Function and Profits

$\mathcal{H}$ |  Payoff in the form of (SL,CM,SP) |  |  |
---|---|---|---|---
aei | (9,-4,2) | bei | (19,-24,2) | cei | (10,-24,2) | dei | (20,-24,2)
aej | (9,-24,3) | bej | (19,-24,3) | cej | (10,-24,3) | dej | (20,-24,3)
aek | (9,-24,3) | bek | (19,-24,3) | cek | (10,-24,3) | dek | (20,-24,3)
ael | (9,-24,4) | bel | (19,-24,4) | cel | (10,-24,4) | del | (20,-24,4)
afi | (x-11,16-x,2) | bfi | (x-1,-24,2) | cfi | (x-10,-24,2) | dfi | (x,-24,2)
afj | (x-11,-24,3) | bfj | (x-1,-24,3) | cfj | (x-10,-24,3) | dfj | (x,-24,3)
afk | (x-11,-24,3) | bfk | (x-1,-24,3) | cfk | (x-10,-24,3) | dfk | (x,-24,3)
afl | (x-11,-24,4) | bfl | (x-1,-24,4) | cfl | (x-10,-24,4) | dfl | (x,-24,4)
agi | (9,-y,y-2) | bgi | (19,-24,y-2) | cgi | (10,-24,y-2) | dgi | (20,-24,y-2)
agj | (9,-24,y-1) | bgj | (19,-24,y-1) | cgj | (10,-24,y-1) | dgj | (20,-24,y-1)
agk | (9,-24,y-1) | bgk | (19,-24,y-1) | cgk | (10,-24,y-1) | dgk | (20,-24,y-1)
agl | (9,-24,y) | bgl | (19,-24,y) | cgl | (10,-24,y) | dgl | (20,-24,y)
ahi | (x-11,-x-y,y-2) | bhi | (x-1,-24,y-2) | chi | (x-10,,-24,y-2) | dhi | (x,-24,y-2)
ahj | (x-11,-24,y-1) | bhj | (x-1,-24,y-1) | chj | (x-10,,-24,y-1) | dhj | (x,-24,y-1)
ahk | (x-11,-24,y-1) | bhk | (x-1,-24,y-1) | chk | (x-10,,-24,y-1) | dhk | (x,-24,y-1)
ahl | (x-11,-24,y) | bhl | (x-1,-24,y) | chl | (x-10,,-24,y) | dhl | (x,-24,y)

  * •

The texts in blue color reach Nash Equilibrium.

##  7\. Efficiency Analysis

In this section, we evaluate the performance. We firstly provide a theoretical
analysis of the system and make comparisons with competitive schemes. Then, we
launch experimental tests in multi-dimensions, covering data type, data size,
and storage capacity.

Experimental Configurations. Our implementation operates on Hyperledger Fabric
blockchain (androulaki2018hyperledger, ), running on a desk server with
Intel(R) Core(TM) i7-7500U CPU2.70GHz and 8.00 GB RAM. We simulate each role
of BDTS (consumer, seller and service providers) at three virtual nodes,
respectively. These nodes are enclosed inside separated dockers under the
Ubuntu 18.04 TLS operating system.

###  7.1. Theoretical Analysis

We first analyze the computational complexity. We set $\tau_{E}$,
$\tau_{E_{A}}$, $\tau_{D}$, $\tau_{D_{A}}$, $\tau_{M}$ and $\tau_{V}$ to
separately represent the asymmetric encryption time, the symmetric encryption
time (AES), the asymmetric decryption time and the symmetric encryption time,
the Merkle tree merging operation time and the Merkle proof verification time.
We give our theoretical analsysis of each step in Tab.3.

Firstly, at the encrypted data uploading module, the seller will divide the
entire data into several pieces of data and upload their proofs on-chain. The
main off-chain procedure is to encrypt the segmented data. We assume the data
has been split into $i$ pieces, and every piece of data $Data_{i}$ needs to be
encrypted into $D_{i}$. Then, these encrypted data have been stored at the
Merkle leaves, merging both $Data_{i}$ and $D_{i}$ to obtain $M_{d}$ and
$r_{ed}$. Secondly, at the matching and data downloading module, the consumer
can select service providers to download different data segments from them.
Before providing the service, the service provider needs to encrypt the
received $D_{i}$ with their private keys, accompanied by corresponding Merkle
proofs as in the previous step. Here, the encryption is based on a symmetric
encryption algorithm. Once completed, multiple downloads occur at the same
time. More service providers will improve the efficiency of downloading
because the P2P connection can make full use of network speed. Last, at the
decryption and appealing module, the consumer obtains each encrypted piece of
data and starts to decryption them. They need to verify whether the received
data and its proof are matched. If all passes, they can use the valid keys
(after payment) for the decryption. Here, the appeal time is related to the
number of appeal parts instead of appeal size.

We further make an comparison, in terms of on-chain costs, with existing
blockchain-based fair exchange protocols. Gringotts (goyal2019secure, ) spends
$O(n)$ as they store all the chunks of delivering data on-chain. CacheCas
(almashaqbeh2019cachecash, ) takes the cost at a range of
$[\mathcal{O}(1),\mathcal{O}(n)]$ due to its lottery tickets mechanism.
FairDwonload (he2021fair, ), as they claimed, spends $\mathcal{O}(1)$. But
they separate the functions of delivering streaming content and download
chunks. Our protocol retain these functions without compromising efficiency,
which only takes $\mathcal{O}(1)$.

Table 3. Computational Complexity and Comparison

Algorithm | Complexity
---|---
Encrypted data uploading | $i{\tau_{E}}+2{\tau_{M}}+2{\tau_{V}}$
Matching and Data downloading | $i{\tau_{E_{A}}}+2{\tau_{M}}+2{\tau_{V}}$
Encryption and appealing | $i{\tau_{D}+\tau_{D_{A}}}+2{\tau_{M}}+2{\tau_{V}}$
Competitive Schemes |
Gringotts (goyal2019secure, ) | $\mathcal{O}(n)$
CacheCash (almashaqbeh2019cachecash, ) | $[\mathcal{O}(1),\mathcal{O}(n)]$
FairDwonload (he2021fair, ) | $\mathcal{O}(1)$
our BDTS | $\mathcal{O}(1)$

  * •

$i$ is the number of segmented data; $n$ represents a full chunk of data.

###  7.2. Experimental Evaluation

Then, we evaluate the practical performance. We focus on the functionaries of
download, which is the most essential function (due to its high frequency and
large bandwidth) invoked by users. We set the experiments from three
orthogonal dimensions, covering different data type, data size and storage
capacity.

Data Type. We evaluate three mainstream data types, covering text, image, and
video. The text-based file is the most prevailing data format in personal
computers. As a standard, a text file contains plain text that can be opened
and edited in any word-processing program. The image format encompasses a
variety of different subtypes such as TIFF, png, jpeg, and BMP, which are used
for different scenarios like printing or web graphics. We omit the subtle
differences between each sub-format because they perform equivalently in terms
of download services. Similarly, video has a lot of sub-types including MP4,
MOV, MP4, WMV, AVI, FLV, etc. We only focus on its general type. From the
results in Fig.2 with distinguished colors, we can observe that all three
types of data have approximately the same performance, under different
configurations of data size and storage capacity. The results indicate that
the performance of the download service has no significant relationship with
the data type.  This is an intuitive outcome that can also be proved by our
common sense. The upload and download service merely opens a channel for
inside data, regardless of its content and types.

Data Size. We adjust data sizes at three levels, including 10M, 100M, and 1G,
to represent a wide range of applications in each level. As shown in Fig.2,
10M data (Text, 1 storage) costs at most no more than $2$ seconds, 100M data
in the same format spends around 18s, and 1G data costs 170s. The results
indicate that the download time is positively proportional to its data size.
The larger the data have, the slower it downloads. This can also apply to
different types of data and different storage capacities. A useful inspiration
from evaluations of data size is to ensure a small size. This is also a major
consideration to explain reasons of splitting data into pieces. The splitting
procedure can significantly improve service quality either for uploading or
downloading. Sharded data can be reassembled into its full version once
receiving all pieces of segments.

Storage Capacity. The storage capacity refers to the number of storage devices
that can provide download services. The device is a general term that can be a
single laptop or a cluster of cloud servers. If each service provider
maintains one device, the number of devices is equal to the participated
service providers. We adjust the storage capacity from 1 device to 4 devices
in each data type and data size. All the subfigures (the columns in left,
middle and right) in Fig.2 show the same trend: increasing the storage
capacity over the distributed network will shorten the download time. The
result can apply to all the data types and data sizes. The most obvious change
in this series of experiments is adding devices from 1 to 2, which is almost
short half of the download time. A reasonable explanation might be that a
single point service is easily affected by other factors such as network
connection, bandwidth usage, or propagating latency. Any changes of these
factors may greatly influence the download service from users. But once adding
another device, the risk of single-point diminishes as the download service
become decentralized and robust. More connections can drive better
availability, as also proved by setting devices to 2, 3 and 4.

Figure 2. Download Times of Different Data Type, Data Size and Storage
Capacity: We evaluate three types of data formats including video (the grey
color), image (orange), and text (blue). For each of data type, we separately
test their download times in distinguished data size with 10M (the left
figure), 100M (middle) and 1G (right). Meanwhile, we also investigate the
performance along with increased number of storage devices (from 1 to 4), or
equivalently the number of service providers.

Average Time. We dive into one of the data types to evaluate its i) average
download times that are measured in MB/sec by repeating multiple times of
experiments under different data sizes; and 2) the trend along with the
increased number of storage devices. Compared to previous evaluations, this
series of experiments scrutinize the subtle variations under different
configurations, figuring a suite of curves. As stated in Tab.4, the average
downloading times under the storage capacity (from 1 to 6) are respectively
$0.167$s, $0.102$s, $0.068$s, $0.051$s, $0.039$s, and $0.031$s. Their changes
start to deteriorate, approaching a convex (downward) function as illustrated
in Fig.3. This indicates that the trend of download time is not strictly
proportional to the changes in storage capacity. They merely have a positive
relation, following a diminishing marginal effect.

##  8\. Discussion

In this section, we highlight several major features of BDTS, covering its
usability, compatibility, and extensibility.

Usability. Our proposed scheme improves the usability in two folds. Firstly,
we separately store the raw data and abstract data. The raw data provided by
the sellers are stored at the local servers of service providers, while the
corresponding abstract data (in the context of this paper, covering data,
description and proof) is recorded on-chain. A successful download requires
matching both decryption keys and data proofs under the supervision of smart
contracts. Secondly, the data trade in our system includes all types of
streaming data such as video, audio, and text. These types can cover the most
range of existing online resources.

Compatibility. Our solution can be integrated with existing crypto-based
schemes. For instance, to avoid the repeated payment of the same data, simply
relying on the index technique is not enough due to its weakness. The
watermarking (yang2020collusion, ) technique is a practical way to embed a
specific piece of mark into data without significantly changing its
functionality. It can also incorporate bio-information from users, greatly
enhance security. Beyond that, the storage (encrypted) data can leverage the
hierarchical scheme (gentry2002hierarchical, ) to manage its complicated data,
as well as remain the efficiency of fast query.

Extensibility. BDTS can extend functionalities by incorporating off-chain
payment techniques (also known as layer-two solutions (gudgeon2020sok, ). Off-
chain payment has the advantage of low transaction fees in multiple trades
with the same person. Besides, existing off-chain payment solutions have many
advanced properties such as privacy-preserving and concurrency
(malavolta2017concurrency, ). Our implementation only set the backbone
protocol for fair exchange, leaving many flexible slots to extend
functionalities by equipping matured techniques.

Table 4. Average Download Time

|  Data Size (Text) |  Average Time
---|---|---
Storage | 1M | 10M | 50M | 100M | 500M | 1G |  (M/s)
1 | 0.16 | 1.78 | 7.96 | 16.55 | 80.52 | 166.45 | 0.167
2 | 0.10 | 0.98 | 4.89 | 8.60 | 43.48 | 88.04 | 0.102
3 | 0.07 | 0.77 | 2.54 | 5.29 | 27.44 | 56.15 | 0.068
4 | 0.05 | 0.61 | 2.03 | 4.21 | 22.22 | 43.51 | 0.051
5 | 0.04 | 0.38 | 1.79 | 3.33 | 18.88 | 34.52 | 0.039
6 | 0.03 | 0.32 | 1.56 | 2.88 | 14.69 | 29.48 | 0.031

Figure 3. Trend of Download Time

##  9\. Related Work

In this section, we provide related primitives surrounding fair exchange
protocols and blockchains. We also give backgrounds of supporting techniques
of game theory.

Blockchain in Trading Systems. Blockchain has been widely used in trading
systems due to its advantageous security properties of non-repudiation, non-
equivocation, and non-frameability (li2020accountable, ). Many scholars work
to build their robust trading systems by leveraging blockchain and smart
contracts. Jung et al. (jung2017accounttrade, ) propose AccountTrade, an
accountable trading system between customers who distrust each other. Any
misbehaving consumer can be detected and punished by using book-keeping
abilities. Chen et al. (chen2017bootstrapping, ) design an offline digital
content trading system. If a dispute occurs, the arbitration institution will
conduct it. Dai et al. (dai2019sdte, ) propose SDTE, a trading system that
protects data as well as prevents analysis code from leakage. They employ the
TEE technology (especially Intel SGX) to protect the data in an isolated area
at the hardware level. Similarly, Li et al. (li2020accountable, ) leverage the
TEE-assisted smart contract to trace the evidence of investigators’ actions.
Automatic executions enable warrant execution accountability under the help of
TEE. Zhou et al. (zhou2018distributed, ) introduce a data trading system that
prevents index data leakage. In this scheme, participants exchange data based
on a smart contract. These solutions rely on blockchain to generate persistent
evidence and act as a transparent authority to solve disputes. However, these
solutions merely performs effective in trading the data in the text version,
rather than data cast in streaming channels such as TV shows, films, which are
costly. The fairness issue in trades has, neither, not been seriously
discussed.

Fair Exchanges using Blockchain. Traditional ways of promoting fair exchange
across distrustful parties rely on trusted third parties because they can
monitor the activities of participants, judging whether they have faithfully
behaved. However, centralization is the major hurdle. Blockchain with the
intrinsic nature of decentralization, automation, and accountability can
perfectly replace the role of TTP. The behaviors of involved parties are
transparently recorded on-chain, avoiding any types of cheating and
compromising. Meanwhile, a predefined incentive model can be automatically
operated by smart contracts, guaranteeing that each participant can be
rewarded according to their contributions. Based on that, blockchain-based
fair exchange protocols have been well researched. Dziembowski et al.
(dziembowski2018fairswap, ) propose Fairswap, utilizing the smart contract to
guarantee fairness. The contract plays the role of an external judge to
resolve the disagreement. He et al. (he2021fair, ) propose a fair content
delivery scheme by using blockchain. They scrutinize the concepts between
exchange fairness and delivery fairness during the trades. Eckey et al.
(eckey2020optiswap, ) propose a smart contract-based fair exchange protocol
with an optimistic mode. They maximally decrease the interaction between
different parties. Janin et al. (janin2020filebounty, ) present FileBounty, a
fair protocol using the smart contract. The scheme ensures a buyer purchases
data at an agreed price without compromising content integrity. Besides,
blockchains are further applied to multi-party computations of trading systems
(shin2017t, )(choudhuri2017fairness, )(kiayias2016blockchain, ).

Game Theory in Blockchain. Game theory is frequently adopted in the blockchain
field due to the players’ profit-pursuing nature (liu2019survey, ). It is used
to simulate the actual behaviors of each rational player under complex
scenarios. Among the analysis, the very first thing is to set the constraints
including either static or dynamic, two-party or multi-party, etc. Based on
that, the theory can be used in simulating optimal profitable behaviors of a
rational miner in many different game scenarios such as the stochastic game
(kiayias2016blockchain, ), the cooperative game (lewenberg2015bitcoin, ), the
evolutionary game (kim2019mining, ) and the Stackelberg game (chen2022absnft,
). The second step is to select a suitable model that can match each assumed
condition, and apply it to real cases. Lohr et al. (lohr2022formalizing, ) and
Janin et al. (janin2020filebounty, ) give their analyses of two-party exchange
protocol. Analyzing whether a behavior deviates from the Nash equilibrium
drives many useful results on the loss and gain of a protocol design. Besides,
other interesting outcomes can also be investigated, especially for the
fairness and security of mining procedures. Existing studies independently
observes the miner’s strategy in selfish mining (eyal2015miner,
)(kwon2017selfish, )(negy2020selfish, )(sapirshtein2016optimal, ), multiple
miners strategy (bai2021blockchain, ), the compliance strategy towards PoW/PoS
(karakostas2022blockchain, ), pooled strategies (wang2019pool, )(li2020mining,
), and fickle mining in different chains (kwon2019bitcoin, ). Our analyses are
compliant with previous research principles.

##  10\. Conclusion

In this paper, we explore the fairness issue existing in current data trading
solutions. Traditional centralized authorities are not reliable due to their
superpower without any supervision. Our proposed scheme, BDTS, addresses such
issues by leveraging then blockchain technology with well-designed smart
contracts. The scheme utilizes automatically-operating smart contracts to act
the role of a data executor with transparency and accountability. Meanwhile,
BDTS can incentive involved parties to behave honestly. Our analyses, based on
strict game theory induction, prove that the game can achieve a subgame
perfect Nash equilibrium with optimal payoffs under the benign actions of all
players. Furthermore, we implement the scheme on the top of the Hyperleder
Fabric platform with comprehensive evaluations. The results demonstrate that
our system can provide fast and reliable services for users.

## References

  * [1] Kang Liu, Wuhui Chen, Zibin Zheng, Zhenni Li, and Wei Liang.  A novel debt-credit mechanism for blockchain-based data-trading in internet of vehicles.  IEEE Internet of Things Journal, 6(5):9098–9111, 2019.
  * [2] Cong Wang, Qian Wang, Kui Ren, Ning Cao, and Wenjing Lou.  Toward secure and dependable storage services in cloud computing.  IEEE Transactions on Services Computing (TSC), 5(2):220–232, 2011\.
  * [3] Yan Zhu, Gail-Joon Ahn, Hongxin Hu, Stephen S Yau, Ho G An, and Chang-Jun Hu.  Dynamic audit services for outsourced storages in clouds.  IEEE Transactions on Services Computing (TSC), 6(2):227–238, 2011\.
  * [4] Alptekin Küpçü et al.  Usable optimistic fair exchange.  In Cryptographers’ Track at the RSA Conference (CT-RSA), pages 252–267. Springer, 2010.
  * [5] Silvio Micali.  Simple and fast optimistic protocols for fair electronic exchange.  In Proceedings of the twenty-second annual symposium on Principles of Distributed Computing (PODC), pages 12–19, 2003.
  * [6] Henning Pagnia, Felix C Gärtner, et al.  On the impossibility of fair exchange without a trusted third party.  Technical report, Citeseer, 1999.
  * [7] Manuel Blum.  How to exchange (secret) keys.  ACM Transactions on Computer Systems (TOCS), 1(2):175–193, 1983\.
  * [8] Benny Pinkas.  Fair secure two-party computation.  In International Conference on the Theory and Applications of Cryptographic Techniques (EUROCRYPT), pages 87–105. Springer, 2003.
  * [9] Stefan Dziembowski, Lisa Eckey, and Sebastian Faust.  Fairswap: How to fairly exchange digital goods.  In ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 967–984, 2018.
  * [10] Songlin He, Yuan Lu, Qiang Tang, Guiling Wang, and Chase Qishi Wu.  Fair peer-to-peer content delivery via blockchain.  In European Symposium on Research in Computer Security (ESORICS), pages 348–369. Springer, 2021.
  * [11] Kyuyong Shin, Carlee Joe-Wong, Sangtae Ha, Yung Yi, Injong Rhee, and Douglas S Reeves.  T-chain: A general incentive scheme for cooperative computing.  IEEE/ACM Transactions on Networking, 25(4):2122–2137, 2017.
  * [12] Arka Rai Choudhuri, Matthew Green, Abhishek Jain, Gabriel Kaptchuk, and Ian Miers.  Fairness in an unfair world: Fair multiparty computation from public bulletin boards.  In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 719–728, 2017.
  * [13] Aggelos Kiayias, Hong-Sheng Zhou, and Vassilis Zikas.  Fair and robust multi-party computation using a global transaction ledger.  In Annual International Conference on the Theory and Applications of Cryptographic Techniques (EUROCRYPT), pages 705–734. Springer, 2016.
  * [14] Lisa Eckey, Sebastian Faust, and Benjamin Schlosser.  Optiswap: Fast optimistic fair exchange.  In Proceedings of the 15th ACM Asia Conference on Computer and Communications Security (AsiaCCS), pages 543–557, 2020.
  * [15] Gavin Wood et al.  Ethereum: A secure decentralised generalised transaction ledger.  https://ethereum.github.io/yellowpaper/paper.pdf, 2022.
  * [16] Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, et al.  Hyperledger fabric: a distributed operating system for permissioned blockchains.  In Proceedings of the thirteenth EuroSys conference (EuroSys), pages 1–15, 2018.
  * [17] Nick Szabo.  Formalizing and securing relationships on public networks.  First monday, 1997.
  * [18] Vimal Dwivedi et al.  Legally enforceable smart-contract languages: A systematic literature review.  ACM Computing Surveys (CSUR), 54(5):1–34, 2021.
  * [19] Rujia Li, Qin Wang, et al.  Sok: Tee-assisted confidential smart contract.  Proceedings on Privacy Enhancing Technologies (PETs), 2022.
  * [20] Kevin Delmolino, Mitchell Arnett, Ahmed Kosba, Andrew Miller, and Elaine Shi.  Step by step towards creating a safe smart contract: Lessons and insights from a cryptocurrency lab.  In International Conference on Financial Cryptography and Data Security (FC), pages 79–94. Springer, 2016.
  * [21] Patrick T Harker.  Generalized nash games and quasi-variational inequalities.  European Journal of Operational Research, 54(1):81–94, 1991.
  * [22] Fei Fang, Shutian Liu, Anjon Basak, Quanyan Zhu, Christopher D Kiekintveld, and Charles A Kamhoua.  Introduction to game theory.  Game Theory and Machine Learning for Cyber Security, pages 21–46, 2021.
  * [23] John Moore and Rafael Repullo.  Subgame perfect implementation.  Econometrica: Journal of the Econometric Society, pages 1191–1220, 1988.
  * [24] Juan Garay et al.  The bitcoin backbone protocol: Analysis and applications.  In Annual International Conference on the Theory and Applications of Cryptographic Techniques (EUROCRYPT), pages 281–310. Springer, 2015.
  * [25] Jinchuan Chen and Yunzhi Xue.  Bootstrapping a blockchain based ecosystem for big data exchange.  In 2017 IEEE International Congress on Big Data (bigdata congress), pages 460–463. IEEE, 2017.
  * [26] Prateesh Goyal, Ravi Netravali, Mohammad Alizadeh, and Hari Balakrishnan.  Secure incentivization for decentralized content delivery.  In 2nd USENIX Workshop on Hot Topics in Edge Computing (HotEdge 19), 2019.
  * [27] Ghada Almashaqbeh.  CacheCash: A Cryptocurrency-based Decentralized Content Delivery Network.  Columbia University, 2019.
  * [28] Rupeng Yang et al.  Collusion resistant watermarkable prfs from standard assumptions.  In CRYPTO, pages 590–620. Springer, 2020.
  * [29] Craig Gentry and Alice Silverberg.  Hierarchical id-based cryptography.  In International conference on the Theory and Application of Cryptology and Information Security (EUROCRYPT), pages 548–566. Springer, 2002\.
  * [30] Lewis Gudgeon, Pedro Moreno-Sanchez, Stefanie Roos, Patrick McCorry, and Arthur Gervais.  Sok: Layer-two blockchain protocols.  In International Conference on Financial Cryptography and Data Security (FC), pages 201–226. Springer, 2020.
  * [31] Giulio Malavolta, Pedro Moreno-Sanchez, Aniket Kate, Matteo Maffei, and Srivatsan Ravi.  Concurrency and privacy with payment-channel networks.  In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 455–471, 2017.
  * [32] Rujia Li et al.  An accountable decryption system based on privacy-preserving smart contracts.  In International Conference on Information Security (ISC), pages 372–390. Springer, 2020.
  * [33] Taeho Jung, Xiang-Yang Li, Wenchao Huang, Jianwei Qian, Linlin Chen, Junze Han, Jiahui Hou, and Cheng Su.  Accounttrade: Accountable protocols for big data trading against dishonest consumers.  In IEEE Conference on Computer Communications (INFOCOM), pages 1–9. IEEE, 2017.
  * [34] Weiqi Dai et al.  Sdte: A secure blockchain-based data trading ecosystem.  IEEE Transactions on Information Forensics and Security (TIFS), 15:725–737, 2019.
  * [35] Jiayu Zhou et al.  Distributed data vending on blockchain.  In IEEE International Conference on Internet of Things (iThings), pages 1100–1107. IEEE, 2018.
  * [36] Simon Janin, Kaihua Qin, Akaki Mamageishvili, and Arthur Gervais.  Filebounty: Fair data exchange.  In 2020 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), pages 357–366. IEEE, 2020.
  * [37] Aggelos Kiayias, Elias Koutsoupias, Maria Kyropoulou, and Yiannis Tselekounis.  Blockchain mining games.  In Proceedings of the 2016 ACM Conference on Economics and Computation (EC), pages 365–382, 2016.
  * [38] Ziyao Liu, Nguyen Cong Luong, Wenbo Wang, Dusit Niyato, Ping Wang, Ying-Chang Liang, and Dong In Kim.  A survey on applications of game theory in blockchain.  arXiv preprint arXiv:1902.10865, 2019.
  * [39] Yoad Lewenberg, Yoram Bachrach, Yonatan Sompolinsky, Aviv Zohar, and Jeffrey S Rosenschein.  Bitcoin mining pools: A cooperative game theoretic analysis.  In Proceedings of the 2015 International Conference on Autonomous Agents and Multiagent Systems (AAMAS), pages 919–927. Citeseer, 2015\.
  * [40] Seonggeun Kim et al.  Mining pool manipulation in blockchain network over evolutionary block withholding attack.  IEEE Access, 7:144230–144244, 2019.
  * [41] Hongyin Chen, Yukun Cheng, Xiaotie Deng, Wenhan Huang, and Linxuan Rong.  Absnft: Securitization and repurchase scheme for non-fungible tokens based on game theoretical analysis.  arXiv preprint arXiv:2202.02199, 2022.
  * [42] Matthias Lohr, Kenneth Skiba, et al.  Formalizing cost fairness for two-party exchange protocols using game theory and applications to blockchain (extended version).  arXiv preprint arXiv:2203.05925, 2022.
  * [43] Ittay Eyal.  The miner’s dilemma.  In 2015 IEEE Symposium on Security and Privacy (SP), pages 89–103. IEEE, 2015.
  * [44] Yujin Kwon, Dohyun Kim, Yunmok Son, Eugene Vasserman, and Yongdae Kim.  Be selfish and avoid dilemmas: Fork after withholding (faw) attacks on bitcoin.  In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 195–209, 2017.
  * [45] Kevin Alarcón Negy, Peter R Rizun, and Emin Gün Sirer.  Selfish mining re-examined.  In International Conference on Financial Cryptography and Data Security (FC), pages 61–78. Springer, 2020.
  * [46] Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar.  Optimal selfish mining strategies in bitcoin.  In International Conference on Financial Cryptography and Data Security (FC), pages 515–532. Springer, 2016.
  * [47] Qianlan Bai, Yuedong Xu, Nianyi Liu, and Xin Wang.  Blockchain mining with multiple selfish miners.  arXiv preprint arXiv:2112.10454, 2021.
  * [48] Dimitris Karakostas, Aggelos Kiayias, and Thomas Zacharias.  Blockchain nash dynamics and the pursuit of compliance.  arXiv preprint arXiv:2201.00858, 2022.
  * [49] Yue Wang, Changbing Tang, Feilong Lin, Zhonglong Zheng, and Zhongyu Chen.  Pool strategies selection in pow-based blockchain networks: Game-theoretic analysis.  IEEE Access, 7:8427–8436, 2019.
  * [50] Wenbai Li et al.  Mining pool game model and nash equilibrium analysis for pow-based blockchain networks.  IEEE Access, 8:101049–101060, 2020.
  * [51] Yujin Kwon, Hyoungshick Kim, Jinwoo Shin, and Yongdae Kim.  Bitcoin vs. bitcoin cash: Coexistence or downfall of bitcoin cash?  In 2019 IEEE Symposium on Security and Privacy (SP), pages 935–951. IEEE, 2019.

## Appendix A. Implementation Details

In this part, we give more details of the implementation. We focus on three
major components as follows.

Sharding Encryption. Based on the real scenario, data transmitted in our
system is large in scale. The mainstream data types on the Internet are text,
pictures, and videos. A promising way for transferring the data is deliver
them in segments (also known as data sharding). Different from the sharding in
the context of classic blockchains, data sharding does not affect the system
consensus or consistency. Instead, data sharding is an off-chain operation
conducted by sellers that will be processed before uploading. A full piece of
data is split into several shards (or pieces, segments), being encrypted and
stored in different memories. The blockchain only reserve its sequential
orders and related evidence such as descriptions, address and proofs. When a
consumer confirms the purchase, he needs to download the data on service
providers according to the storage list and obtain the decryption key after a
successful payment. Then, he can decrypt the data in pieces, and finally
resemble them according to the sequences for the entire piece of data.

We implement the data sharding with the logic in Algm.1. Given the size of a
slot (indicating the expected size of a shard), we firstly calculate the
number of data segments (line 4). Then, a full piece of data is split into $n$
segments (line 5). The seller then create its encryption keys
$(K_{1},K_{2},...,K_{n})$ based on his master private key $K_{seller}$ (line
6). Once completed the data splitting and key generation, the algorithm starts
to encrypt each of the data segment under the seller’s private keys (line
8-11). The encrypted data also generate its proofs for further verifications
(line 10). Last, both raw data and encrypted data are stored on the leaves of
Merkle tree to generate the on-chain roots $MT1$ and $MT2$ (line 12-14).

Algorithm 1 Sharding Encryption

1:Private Key (seller), Data

2:$MD,MT1,MT2$

3:function ENCRYPT($K_{seller},Data$)

4: $n\leftarrow 1$

5: if $slot<Data$ then

6: $n\leftarrow Data/slot$

7: $Data_{1},Data_{2},...,Data_{n}\leftarrow Data$

8: $K_{1},K_{2},...,K_{n}\leftarrow K_{seller}$

9: end if

10: for $i=1$ to $n$ do

11: $D_{i}\leftarrow AES(K_{i})[Data_{i}]$

12: $MD\leftarrow D_{i}$

13: end for

14: $MT1\leftarrow Hash(Data_{1},Data_{2},...,Data_{n})$

15: $MT2\leftarrow Hash(D_{1},D_{2},...,D_{n})$

16: return $MD,MT1,MT2$

17:end function

Product Matching. This function describes the process of searching a targeted
source from service providers. In the context of Algm.2, the terms keyword,
choice, ProductList, SPList, MD, Data and Desc represent the searchable
keywords, user’s preferences of products, product list, service provider list,
data and product description, respectively. When a consumer inputs a keyword,
the algorithm starts to search matched ones (line 3) by ranging all
descriptions in the product list (line 2-5). Matched products will be
recommend to a channel called showlist for consumers. The algorithm then
inputs the choice requested from the consumer, and search related sources
(encrypted data, data, description) from service providers (line 8-13).
Returned information is sent to the consumer.

Algorithm 2 Products Matching

1:keyword, choice, ProductList, SPList

2:MD, Data, Desc

3:function MATCH($keyword,choice,ProductList,SPList$)

4: for $i=1$ to $ProductList.length$ do

5: if $ProductList[i].Desc==keyword$ then

6: $ShowList\leftarrow$ProductList[i]

7: end if

8: end for

9: $ShowList$ $show$

10: if $choice$ then

11: $Map\leftarrow$ProductList[choice].SPList

12: $Datas\leftarrow$ProductList[choice].Data

13: $Desc\leftarrow$ProductList[choice].Desc

14: $D\leftarrow$Map $load$

15: end if

16: return $MD,Data,Desc$

17:end function

Payment. This function mainly describes the method of making payments. The
terms in Algm.3 cmAddr, slrAddr, spAddr and Price stand for the consumer’s
address, the seller’s address, the service provider’s address and the price of
commodities. The result (either True or False) represents the final result on
whether the payment has been successfully executed. The algorithm inputs the
addresses of all three entities and the commodity price (line 1). If the token
amount of consumer is less than selling prices, the algorithm returns false
and the transaction fails (line 1-3). Otherwise, the transaction proceeds. A
major difference compared to traditional exchange protocols is that the
consumer needs to pay both service providers for their on-chain services and
the seller for his resources (line 4-9). The service provider in our scheme
can obtain sufficient rewards if he acts always faithfully, helping to build a
long-lasting ecosystem.

Algorithm 3 Payment

1:cmAddr, slrAddr, spAddr, Price

2:result (True/False)

3:function PAY($cmAddr,slrAddr,Price$)

4: if $cmAddr.amount<Price$ then

5: $result\leftarrow false$

6: else

7: $slrAddr\leftarrow cmAddr.transfer(Price)$

8: $spAddr\leftarrow cmAddr.transfer(Price)$

9: $result\leftarrow true$

10: end if

11: return $result$

12:end function

## Appendix B. Notations

Table 5. Notations

Role | Explanation
---|---
$A_{role}$ | Ethereum address of role
$IP_{role}$ | IP address of role
$K_{role}$ | the key of symmetric encryption algorithm of role
$Data_{seller}$ | the data to be sold by seller, binary form
$Tkn_{cm}$ | the token sent by the consumer
$Pub_{role}$ | the public key of asymmetric encryption algorithm
$Pri_{role}$ | the private key of asymmetric encryption algorithm
Notation | Explanation
$Enc^{AES}(b)$/$Dec^{AES}(b)$ | encrypt/decrypt $b$ under AES, an symmetric encryption
$Enc(b)/Dec(b)$ | encrypt/decrypt $b$ under a using asymmetric algorithm
$Data_{i}$ | the $i$-th unit of $Data_{seller}$
$n$ | the total number of spited data units
$\mathsf{Mtree/Mproof/Mvrfy}$ | the Merkle tree algorithms
$Desc$ | the seller’s description of data
$D$ | data encrypted by seller, consists of $D_{i}$, the $i$-th unit of $D$
$Price$ | the price of entire data
$Unit\,Price$ | dowloading price for each unit
$I_{rand}$ | a random index
$ID_{data}$ | the data ID, index of data in SSMC (see later)
$\mathsf{Rand()}$ | a random value generator

## Appendix C. Processing Components

We provide the concrete processing workflow for the phases of seller-consumer
matching, service provider-consumer matching, sending payments to service
provider and sending payments to sellers. All charts (Fig.4) are aligned with
the steps listed in Sec.3.

Figure 4. The Processing Components