\section{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 \cite{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 \cite{wang2011toward}\cite{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,

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

Traditional solutions \cite{kupccu2010usable}\cite{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 \cite{pagnia1999impossibility}, and it is widely acknowledged that finding such a TTP is reckon hard in practice. Instead of using the seemingly old-fashioned cryptographic \textit{gradual release} method\footnote{The \textit{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.} \cite{blum1983exchange}\cite{pinkas2003fair}, many solutions \cite{dziembowski2018fairswap}\cite{he2021fair}\cite{shin2017t}\cite{choudhuri2017fairness}\cite{kiayias2016fair}\cite{eckey2020optiswap} have been proposed by leveraging blockchain technologies \cite{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 \textit{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 \cite{androulaki2018hyperledger} to ensure the exchange fairness that are threatened from four aspects: \textit{(i)} the seller may provide \textit{fake data}, \textit{(ii)} the seller may provide \textit{a false decryption key}, \textit{(iii)} the consumer may \textit{not pay for authentic data} or \textit{(iv)} \textit{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 \textit{i} and \textit{ii}); a consumer automatically gets charged for requested data (overcome \textit{iii}); and every data can only be sold once since each transaction is unique in the blockchain systems (address \textit{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.

\smallskip
\noindent\textbf{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.

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

\item 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 \textit{subgame perform equilibrium}.

\item 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.

\end{itemize}

\noindent\textbf{Paper Structure.} Section \ref{sec-prelimi} presents preliminaries. Section  \ref{sec-archi} provides a bird's view of our scheme with security assumptions and models. Section \ref{sec-system} details our system.  Section \ref{sec-imple} presents our implementations on Hyperledger. Section \ref{sec-security} proves its security while Section \ref{sec-efficiency} discusses efficiency. Section \ref{sec-discuss} provide further discussions. Section \ref{sec-rw} reviews related work surrounding our system. Appendix A-C provide supplementary details of this work.

\section{Preliminary}
\label{sec-prelimi}
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.

\smallskip
\noindent\textbf{Smart Contract.}
The smart contract, proposed by Szabo \cite{szabo1996smart}, aims to enable the self-execution of clauses and logic. Since the emergence of Ethereum \cite{wood2014ethereum}, the concept of the smart contract becomes prevailing \cite{dwivedi2021legally}\cite{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 \textit{contract account}, \textit{runtime}, \textit{bytecode}, and a bunch of related \textit{transaction}s \cite{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.

\smallskip
\noindent\textbf{Merkle Tree.}
Merkle tree is a type of tree designed in a layered architecture. Every parent node (the top one is denoted as \textit{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 \textit{true} if is the same as before, otherwise it returns \textit{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.

\begin{wraptable}{r}{3.5cm}
\centering
\begin{tabular}{cc|ccc}
 \toprule
 \multicolumn{2}{c}{\textit{Strategy} }    &  \multicolumn{1}{|c}{\textbf{A}   }          & \textbf{B} & $p_i$ \\
 \midrule
 \multirow{2}{*}{$p_j$} & \textbf{A}           & 1,1    & 1,-1  \\
 & \textbf{B}           & -1,1         &  0,0      \\
 \bottomrule
\end{tabular}
\end{wraptable}

\smallskip
\noindent\textbf{Game theory.} Game theory provides an ideal environment to simulate the interactions among rational decision-makers (also known as \textit{player}s). 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 \cite{harker1991generalized}), if the first player $p_i$ adopts strategy \textbf{A} whereas the second player $p_j$ selects \textbf{B}, both of them cannot obtain the overall maximum utility. If $p_i$ adopts \textbf{A} while $p_j$ with \textbf{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 \cite{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 \cite{moore1988subgame}. This is also the Nash equilibrium for the entire system.

\section{Architecture and Security model}
\label{sec-archi}

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

\subsection{Problem Overview}

\smallskip
\noindent\textbf{Entities.} First of all, we clarify the participated roles in our scheme. A total of three types entities are involved: \textit{consumer (CM)}, \textit{seller (SL)}, and \textit{service provider (SP)}\footnote{Service 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.

\smallskip
\noindent\textbf{Problem Statement.} Then, we have a quick summary of problems existing in current data trading systems.

\noindent\hangindent 1em \textit{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.

\noindent\hangindent 1em \textit{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.

\noindent\hangindent 1em \textit{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.

\noindent\hangindent 1em \textit{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.

\smallskip
\noindent\textbf{Desired Requirements.} To address such issues, the proposed BDTS system should fulfill the following requirements.

\noindent\hangindent 1em \textit{A protocol with guarantees on exchange fairness.} The fairness ensures both sellers and consumers can faithfully obtain the rewards based on their actual activities.

\noindent\hangindent 1em \textit{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.

\noindent\hangindent 1em \textit{Incentive designs should be considered to avoid unnecessary frictions.} Economical incentive is important for the encouragement of involved parties to act honestly.

\noindent\hangindent 1em \textit{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.

\subsection{Architecture.}

We design a novel data trading ecosystem that builds on the top of the blockchain platform. A typical workflow in BDTS is that: \textit{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.

\noindent\hangindent 1em \textit{\textbf{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.

\noindent\hangindent 1em \textit{\textbf{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.

\noindent\hangindent 1em \textit{\textbf{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.

\subsection{Security Assumption}
In this scheme, we have three basic security assumptions.

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

\noindent\hangindent 1em \textit{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.

\noindent\hangindent 1em \textit{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.

\subsection{Security model}\label{subsec-secritymodel}

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

\noindent\hangindent 1em \textit{\textbf{Seller}}. Sellers intend to obtain more payment by selling their data. In our scheme, a seller needs to provide mainly three sectors: \textit{data}, \textit{description}, and \textit{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 \textit{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) \textit{matched data (towards corresponding description) and matched key (towards data)}, b) \textit{matched data and non-matched key}, c) \textit{non-matched data and matched key}, and d) \textit{non-matched data and non-matched key}.

\noindent\hangindent 1em \textit{\textbf{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) \textit{pay enough for sellers}, b) \textit{pay less for sellers}, c) \textit{pay enough for service providers}, and d) \textit{pay less for service providers}.

\noindent\hangindent 1em \textit{\textbf{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) \textit{authentic correct data and matched key},  b) \textit{authentic data and non-matched key},  c) \textit{fake data and matched key},  and d) \textit{fake data and non-matched key}. The first two need the premise of storing the seller's data.

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

\section{The BDTS Scheme}
\label{sec-system}

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: \textit{contract deployment}, \textit{encrypted data uploading}, \textit{data downloading}, and \textit{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.

\subsection{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).

\noindent\hangindent 1em \textit{\textbf{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.

\noindent\hangindent 1em \textit{\textbf{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.

\noindent\hangindent 1em \textit{\textbf{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.

\subsection{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.\ref{fig:combined}.a).

\noindent\hangindent 1em \textit{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.

\noindent\hangindent 1em \textit{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: \textit{content description}, \textit{data size}, \textit{the root} $r_d$ and \textit{the root} $r_ed$. 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.

\noindent\hangindent 1em \textit{Step3} and \textit{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$.

\noindent\hangindent 1em \textit{Step5}, and \textit{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 \cite{chen2017bootstrapping}. Data plagiarism will result in deposit loss, preventing the reselling behavior.

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

\noindent\hangindent 1em \textit{Step9}, \textit{Step10} and \textit{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.

\subsection{Matching and Data Downloading}

In this module, a consumer registers on SCMC and selects the service provider to download data (see Fig.\ref{fig:combined}.b).

\noindent\hangindent 1em  \textit{Step1} and \textit{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.

\noindent\hangindent 1em  \textit{Step3}, \textit{Step4}, \textit{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.

\noindent\hangindent 1em  \textit{Step6}, \textit{Step7}, \textit{Step8}. The consumer contacts with the service provider based on $IP_{sp}$, which is received in \textit{Step2}.  In \textit{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.

\noindent\hangindent 1em  \textit{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.

\noindent\hangindent 1em  \textit{Step12}, \textit{Step13}, and \textit{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 \textit{step14}.

\subsection{Decryption and Appealing}

In this module, the consumer pays to both the service provider and the seller (see Fig.\ref{fig:combined}.c).

\begin{itemize}
    \item[-] \textit{Step1}, \textit{Step2}, \textit{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.

    \item[-] \textit{Step4}, \textit{Step5}, and \textit{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.

    \item[-] \textit{Step7}, \textit{Step8}, \textit{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.

\end{itemize}

\noindent Paying the seller is similar to paying to the service providers, the differences between mainly concentrate on \textit{Step2}, \textit{Step3}, \textit{Step4}, \textit{Step7}, and \textit{Step8} (see Fig.\ref{fig:combined}.d).

\begin{itemize}

    \item[-] \textit{Step2}, \textit{Step3} and \textit{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.

    \item[-] \textit{Step7} and \textit{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.

\end{itemize}

\section{Implementations}
\label{sec-imple}

In this section, we provide the detailed implementation of three major functions, including \textit{sharding encryption} that splits a full message into several pieces, \textit{product matching} to show the progress of finding a targeted product, and \textit{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 platform\footnote{Source code: Hidden due to the anonymity policy.}. We provide implementation details in Appendix A.

\section{Security Analysis}
\label{sec-security}

In this section, we provide the analysis of BDTS based on game theory. The basic model of our solution is a \textit{dynamically sequential game} with \textit{multiple players}. The analyses are based on \textit{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.\ref{fig-game} (\textit{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 \textit{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 \textit{blue} line). Last, the SP sends the raw data and related keys to CM  (in \textit{brown} line). Based on that, we define our analysis model as follows.

\begin{defi} 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.
\end{defi}

For each of participated parties, they have four strategies as defined in Sec.\ref{subsec-secritymodel} (\textit{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.\ref{tab:game}. 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$ \textit{unit}s, while generating keys compensates $1$  \textit{unit}. The service fee during the transactions is $1$  \textit{unit}s for each party. Thus, we provide the cost of each strategy in the Table.\ref{tab:game}. The parameters of $x$ and $y$ are actual payments from CM, where $0\leq x<20,0\leq y<4, x+y<24$.

\begin{figure}[!hbt]
    \centering
    \includegraphics[width=\linewidth]{img/game.png}
   \caption{Game and Game Tree}
    \label{fig-game}
\end{figure}

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.\ref{fig-game} (\textit{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.

\begin{lem}\label{lma-seller}
If one seller provides data not corresponding to the description, the seller cannot obtain payments.
\end{lem}

\begin{prf}
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. \qed
\end{prf}

\begin{lem}\label{lma-sellerkey}
If one seller provides a decryption key not conforming to the description, the seller cannot obtain payments.
\end{lem}

\begin{prf}
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.  \qed
\end{prf}

\begin{table}[!hbt]
\caption{Strategies and Costs}\label{tab:game}
\begin{center}
\resizebox{0.85\linewidth}{!}{
\begin{tabular}{c|cc}
 \toprule
 \multicolumn{1}{c}{\textit{\textbf{SL Strategy}} }    &  \multicolumn{1}{|c}{Matched data}          & {Non-matched data} \\
 \midrule
  {Matched key}        & a, -11  & b, -1 \\
  {Non-matched key}    & c, -10  &  d, 0\\
  \midrule
 \multicolumn{1}{c}{\textit{\textbf{CM Strategy}} }    &  \multicolumn{1}{|c}{Sufficiently}       & {Insufficiently} (to SL) \\
 \midrule
  {Sufficiently} (to SP)  & e, -24  & f, -(x+4) \\
  {Insufficiently Paid}   &  g, -(y+20)    &  h, -(x+y) \\
\midrule
 \multicolumn{1}{c}{\textit{\textbf{SP Strategy}} }    &  \multicolumn{1}{|c}{Authentic data}       &  Non-authentic data  \\
 \midrule
  {Matched key}       & i, -2   & j, -1 \\
  {Non-matched key}  &  k, -1     & l, 0   \\
 \bottomrule
\end{tabular}
}\end{center}
 \begin{tablenotes}
      \footnotesize
       \item \quad\quad\quad The cost of -11 \textit{unit}s are short for -11, applicable to all.
       \item \quad\quad\quad Data is sold at 20 (to SL) while the service fee is 4 (to SP).
     \end{tablenotes}
\end{table}

\begin{lem}\label{lma-cm}
A consumer without sufficient payments cannot normally use the data.
\end{lem}

\begin{prf}
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.  \qed
\end{prf}

\begin{lem}
If one service provider provides data not conforming to that of the seller, he cannot obtain payments.
\end{lem}

\begin{prf}
This proof is similar to Lemma \ref{lma-seller}.  \qed
\end{prf}

\begin{lem}\label{lma-sp}
If one service provider provides a decryption key not conforming to data, he cannot obtain payments.
\end{lem}

Here, \textbf{Lemma \ref{lma-seller}} to \textbf{Lemma \ref{lma-sp}} 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.\ref{tab:net}. We demonstrate that the system can reach the subgame perfect Nash equilibrium under the following theorem.

\begin{thm}
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. \qed
\end{thm}

\begin{prf} 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.\ref{tab:net}, the optimal strategies for sellers (\textit{dei},\textit{dej},\textit{dek},\textit{del},\textit{dgi},\textit{dgj},\textit{dgk},\textit{dgl}) is to provide mismatched keys and data, while at the same time obtain payments from consumers. However, based on Lemma \ref{lma-seller} and Lemma \ref{lma-sellerkey}, 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.\ref{fig-game}. 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.\ref{tab:net} (red background), the strategies of \textit{aei}, \textit{afi} and \textit{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 \ref{lma-cm}, 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 \textit{afi} and \textit{agi} are impractical. With the previous analyses in the arm, we finally conclude that only the strategy \textit{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.  \qed
\end{prf}

\begin{table}[!hbt]
\caption{Payoff Function and Profits}\label{tab:net}
\begin{center}
\resizebox{\linewidth}{!}{
\begin{tabular}{c|c|c|c|c|c|c|c}
 \toprule
 \multicolumn{1}{c}{\textit{\textbf{$\mathcal{H}$}} }  & \multicolumn{4}{c}{\textbf{Payoff} in the form of (SL,CM,SP)} \\
 \midrule
 \textit{aei} & \textcolor{blue}{\text{(9,-4,2)}} & \textit{bei} & (19,-24,2) &  \textit{cei} & (10,-24,2) & \textit{dei} & (20,-24,2) \\
 \textit{aej} & (9,-24,3) & \textit{bej} & (19,-24,3) &  \textit{cej}& (10,-24,3) &  \textit{dej} & (20,-24,3) \\
 \textit{aek} & (9,-24,3) & \textit{bek} & (19,-24,3) &  \textit{cek}& (10,-24,3) &  \textit{dek} & (20,-24,3) \\
 \textit{ael} & (9,-24,4) & \textit{bel} & (19,-24,4) &  \textit{cel} & (10,-24,4) &  \textit{del} & (20,-24,4) \\
 \midrule
 \textit{afi} &  \textcolor{blue}{\text{(x-11,16-x,2)}} & \textit{bfi} & (x-1,-24,2) &  \textit{cfi}& (x-10,-24,2) &  \textit{dfi} & (x,-24,2) \\
 \textit{afj} & (x-11,-24,3) & \textit{bfj} & (x-1,-24,3) &  \textit{cfj}& (x-10,-24,3)  &  \textit{dfj} & (x,-24,3) \\
 \textit{afk} & (x-11,-24,3) & \textit{bfk} & (x-1,-24,3) &  \textit{cfk}& (x-10,-24,3) &  \textit{dfk} & (x,-24,3) \\
 \textit{afl} & (x-11,-24,4) & \textit{bfl} & (x-1,-24,4) &  \textit{cfl}& (x-10,-24,4) &  \textit{dfl} & (x,-24,4) \\
 \midrule
 \textit{agi} &  \textcolor{blue}{\text{(9,-y,y-2)}} & \textit{bgi} & (19,-24,y-2) &  \textit{cgi}& (10,-24,y-2) &  \textit{dgi} & (20,-24,y-2) \\
 \textit{agj} & (9,-24,y-1) & \textit{bgj} & (19,-24,y-1) &  \textit{cgj}& (10,-24,y-1) &  \textit{dgj} & (20,-24,y-1) \\
 \textit{agk} & (9,-24,y-1) & \textit{bgk} & (19,-24,y-1) &  \textit{cgk}& (10,-24,y-1) &  \textit{dgk} & (20,-24,y-1) \\
 \textit{agl} & (9,-24,y) & \textit{bgl} & (19,-24,y) &  \textit{cgl}& (10,-24,y) &  \textit{dgl} & (20,-24,y) \\
 \midrule
 \textit{ahi} &(x-11,-x-y,y-2) & \textit{bhi} & (x-1,-24,y-2) &  \textit{chi}& (x-10,,-24,y-2) &  \textit{dhi} & (x,-24,y-2) \\
 \textit{ahj} & (x-11,-24,y-1) & \textit{bhj} & (x-1,-24,y-1) &  \textit{chj}& (x-10,,-24,y-1) &  \textit{dhj} & (x,-24,y-1) \\
 \textit{ahk} & (x-11,-24,y-1) & \textit{bhk} & (x-1,-24,y-1) &  \textit{chk}& (x-10,,-24,y-1) &  \textit{dhk} & (x,-24,y-1) \\
 \textit{ahl} & (x-11,-24,y) & \textit{bhl} & (x-1,-24,y) &  \textit{chl}& (x-10,,-24,y) &  \textit{dhl} & (x,-24,y) \\
 \bottomrule
\end{tabular}
}
 \begin{tablenotes}
      \footnotesize
       \item \quad The texts in blue color reach Nash Equilibrium.
     \end{tablenotes}
\end{center}
\end{table}

\section{Efficiency Analysis}
\label{sec-efficiency}

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.

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

\subsection{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.\ref{tab-complexity}.

Firstly, at the \textit{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 \textit{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 \textit{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 \cite{goyal2019secure} spends $O(n)$ as they store all the chunks of delivering data on-chain. CacheCas \cite{almashaqbeh2019cachecash} takes the cost at a range of  $[\mathcal{O}(1), \mathcal{O}(n)]$ due to its \textit{lottery tickets} mechanism. FairDwonload \cite{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)$.

\begin{table}[!hbt]
\caption{Computational Complexity and Comparison}
 \label{tab-complexity}
 \resizebox{0.95\linewidth}{!}{
 \begin{tabular}{c|c}
    \toprule
     \multicolumn{1}{c}{\textbf{Algorithm}}   & \multicolumn{1}{c}{\textbf{Complexity}}
       \\
     \midrule
   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}$   \\
   \midrule
    \multicolumn{1}{c}{\textbf{Competitive Schemes}}   & \\
    \midrule
    \multicolumn{1}{c|}{Gringotts \cite{goyal2019secure} } &   $\mathcal{O}(n)$ \\
    \multicolumn{1}{c|}{ CacheCash \cite{almashaqbeh2019cachecash} } &   $[\mathcal{O}(1), \mathcal{O}(n)]$ \\
    \multicolumn{1}{c|}{ FairDwonload \cite{he2021fair} } &  $\mathcal{O}(1)$ \\
    \multicolumn{1}{c|}{\textbf{\textit{our BDTS}}} &   $\mathcal{O}(1)$ \\
   \bottomrule
  \end{tabular}
  }
    \begin{tablenotes}
       \footnotesize
       \item \quad $i$ is the number of segmented data;  $n$ represents a full chunk of data.
     \end{tablenotes}

\end{table}

\subsection{Experimental Evaluation}
Then, we evaluate the practical performance. We focus on the functionaries of \textbf{\textit{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.

\smallskip
\noindent\textbf{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.\ref{fig-tests} 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 \textit{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.

\smallskip
\noindent\textbf{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.\ref{fig-tests}, 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 \textit{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.

\smallskip
\noindent\textbf{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 \textit{left}, \textit{middle} and \textit{right}) in Fig.\ref{fig-tests} show the same trend: \textit{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.

\begin{figure*}[!hbt]
    \centering
    \includegraphics[width=\linewidth]{img/tests.png}
   \caption{\textbf{Download Times of Different Data Type, Data Size and Storage Capacity}: We evaluate three types of data formats including video \textit{(the grey color)}, image \textit{(orange)}, and text \textit{(blue)}. For each of data type, we separately test their download times in distinguished data size with 10M \textit{(the left figure)}, 100M \textit{(middle)} and 1G \textit{(right)}. Meanwhile, we also investigate the performance along with increased number of storage devices \textit{(from 1 to 4)}, or equivalently the number of service providers.}
    \label{fig-tests}
\end{figure*}

\smallskip
\noindent\textbf{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.\ref{tab-avgtime}, 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.\ref{fig-performance}. 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.

\section{Discussion}
\label{sec-discuss}

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

\smallskip
\noindent\textbf{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 \textit{data}, \textit{description} and \textit{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.

\smallskip
\noindent\textbf{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 \cite{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 \cite{gentry2002hierarchical} to manage its complicated data, as well as remain the efficiency of fast query.

\smallskip
\noindent\textbf{Extensibility.} BDTS can extend functionalities by incorporating off-chain payment techniques (also known as layer-two solutions \cite{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 \cite{malavolta2017concurrency}. Our implementation only set the backbone protocol for fair exchange, leaving many flexible slots to extend functionalities by equipping matured techniques.

\begin{figure*}
    \begin{minipage}[!h]{0.65\linewidth}
    \captionof{table}{Average Download Time}
 \label{tab-avgtime}
 \resizebox{0.93\linewidth}{!}{
 \begin{tabular}{c|cccccc|cc}
    \toprule
     \multicolumn{1}{c}{\quad}   & \multicolumn{6}{c}{\quad\textbf{Data Size (Text)}\quad}
     & \multicolumn{1}{c}{\quad\textbf{Average Time }\quad}   \\
     \midrule
    \multicolumn{1}{c|}{\textbf{Storage}}   &  {\textbf{1M}}  &  {\textbf{10M}}  &  {\textbf{50M}} &  {\textbf{100M}}  &    {\textbf{500M}}    & \textbf{1G}  &
    \quad\textbf{(M/s)}\quad     \\% &  \quad\textbf{2G (Video)}\quad
    \midrule
   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 \\%& 88.75
   5 & 0.04 & 0.38 & 1.79 & 3.33  & 18.88  & 34.52  & 0.039  \\%& 70.55
   6 & 0.03 & 0.32 & 1.56 & 2.88 & 14.69 &   29.48  & 0.031  \\%& 60.95
   \bottomrule
  \end{tabular}
 }
 \end{minipage}
 \begin{minipage}[!h]{0.33\linewidth}
    \caption{Trend of Download Time}
    \label{fig-performance}
    \includegraphics[height = 3.65cm]{img/performance.png}
    \end{minipage}

\end{figure*}

\section{Related Work}
\label{sec-rw}

In this section, we provide related primitives surrounding \textit{fair exchange} protocols and \textit{blockchain}s. We also give backgrounds of supporting techniques of \textit{game theory}.

\smallskip
\noindent\textbf{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 \cite{li2020accountable}. Many scholars work to build their robust trading systems by leveraging blockchain and smart contracts. Jung et al. \cite{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. \cite{chen2017bootstrapping} design an offline digital content trading system. If a dispute occurs, the arbitration institution will conduct it.  Dai et al. \cite{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. \cite{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. \cite{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 \textit{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.

\smallskip
\noindent\textbf{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. \cite{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. \cite{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. \cite{eckey2020optiswap} propose a smart contract-based fair exchange protocol with an optimistic mode. They maximally decrease the interaction between different parties. Janin et al. \cite{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 \cite{shin2017t}\cite{choudhuri2017fairness}\cite{kiayias2016blockchain}.

\smallskip
\noindent\textbf{Game Theory in Blockchain.} Game theory is frequently adopted in the blockchain field due to the players' profit-pursuing nature \cite{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 \cite{kiayias2016blockchain}, the cooperative game \cite{lewenberg2015bitcoin}, the evolutionary game \cite{kim2019mining} and the Stackelberg game \cite{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. \cite{lohr2022formalizing} and Janin et al. \cite{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 \cite{eyal2015miner}\cite{kwon2017selfish}\cite{negy2020selfish}\cite{sapirshtein2016optimal}, multiple miners strategy  \cite{bai2021blockchain}, the compliance strategy towards PoW/PoS \cite{karakostas2022blockchain}, pooled strategies \cite{wang2019pool}\cite{li2020mining}, and fickle mining in different chains \cite{kwon2019bitcoin}. Our analyses are compliant with previous research principles.

\section{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.

\bibliographystyle{unsrt}

\section{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 \cite{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 \cite{wang2011toward}\cite{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,

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

Traditional solutions \cite{kupccu2010usable}\cite{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 \cite{pagnia1999impossibility}, and it is widely acknowledged that finding such a TTP is reckon hard in practice. Instead of using the seemingly old-fashioned cryptographic \textit{gradual release} method\footnote{The \textit{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.} \cite{blum1983exchange}\cite{pinkas2003fair}, many solutions \cite{dziembowski2018fairswap}\cite{he2021fair}\cite{shin2017t}\cite{choudhuri2017fairness}\cite{kiayias2016fair}\cite{eckey2020optiswap} have been proposed by leveraging blockchain technologies \cite{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 \textit{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 \cite{androulaki2018hyperledger} to ensure the exchange fairness that are threatened from four aspects: \textit{(i)} the seller may provide \textit{fake data}, \textit{(ii)} the seller may provide \textit{a false decryption key}, \textit{(iii)} the consumer may \textit{not pay for authentic data} or \textit{(iv)} \textit{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 \textit{i} and \textit{ii}); a consumer automatically gets charged for requested data (overcome \textit{iii}); and every data can only be sold once since each transaction is unique in the blockchain systems (address \textit{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.

\smallskip
\noindent\textbf{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.

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

\item 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 \textit{subgame perform equilibrium}.

\item 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.

\end{itemize}

\noindent\textbf{Paper Structure.} Section \ref{sec-prelimi} presents preliminaries. Section  \ref{sec-archi} provides a bird's view of our scheme with security assumptions and models. Section \ref{sec-system} details our system.  Section \ref{sec-imple} presents our implementations on Hyperledger. Section \ref{sec-security} proves its security while Section \ref{sec-efficiency} discusses efficiency. Section \ref{sec-discuss} provide further discussions. Section \ref{sec-rw} reviews related work surrounding our system. Appendix A-C provide supplementary details of this work.

\section{Preliminary}
\label{sec-prelimi}
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.

\smallskip
\noindent\textbf{Smart Contract.}
The smart contract, proposed by Szabo \cite{szabo1996smart}, aims to enable the self-execution of clauses and logic. Since the emergence of Ethereum \cite{wood2014ethereum}, the concept of the smart contract becomes prevailing \cite{dwivedi2021legally}\cite{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 \textit{contract account}, \textit{runtime}, \textit{bytecode}, and a bunch of related \textit{transaction}s \cite{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.

\smallskip
\noindent\textbf{Merkle Tree.}
Merkle tree is a type of tree designed in a layered architecture. Every parent node (the top one is denoted as \textit{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 \textit{true} if is the same as before, otherwise it returns \textit{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.

\begin{wraptable}{r}{3.5cm}
\centering
\begin{tabular}{cc|ccc}
 \toprule
 \multicolumn{2}{c}{\textit{Strategy} }    &  \multicolumn{1}{|c}{\textbf{A}   }          & \textbf{B} & $p_i$ \\
 \midrule
 \multirow{2}{*}{$p_j$} & \textbf{A}           & 1,1    & 1,-1  \\
 & \textbf{B}           & -1,1         &  0,0      \\
 \bottomrule
\end{tabular}
\end{wraptable}

\smallskip
\noindent\textbf{Game theory.} Game theory provides an ideal environment to simulate the interactions among rational decision-makers (also known as \textit{player}s). 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 \cite{harker1991generalized}), if the first player $p_i$ adopts strategy \textbf{A} whereas the second player $p_j$ selects \textbf{B}, both of them cannot obtain the overall maximum utility. If $p_i$ adopts \textbf{A} while $p_j$ with \textbf{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 \cite{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 \cite{moore1988subgame}. This is also the Nash equilibrium for the entire system.

\section{Architecture and Security model}
\label{sec-archi}

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

\subsection{Problem Overview}

\smallskip
\noindent\textbf{Entities.} First of all, we clarify the participated roles in our scheme. A total of three types entities are involved: \textit{consumer (CM)}, \textit{seller (SL)}, and \textit{service provider (SP)}\footnote{Service 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.

\smallskip
\noindent\textbf{Problem Statement.} Then, we have a quick summary of problems existing in current data trading systems.

\noindent\hangindent 1em \textit{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.

\noindent\hangindent 1em \textit{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.

\noindent\hangindent 1em \textit{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.

\noindent\hangindent 1em \textit{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.

\smallskip
\noindent\textbf{Desired Requirements.} To address such issues, the proposed BDTS system should fulfill the following requirements.

\noindent\hangindent 1em \textit{A protocol with guarantees on exchange fairness.} The fairness ensures both sellers and consumers can faithfully obtain the rewards based on their actual activities.

\noindent\hangindent 1em \textit{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.

\noindent\hangindent 1em \textit{Incentive designs should be considered to avoid unnecessary frictions.} Economical incentive is important for the encouragement of involved parties to act honestly.

\noindent\hangindent 1em \textit{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.

\subsection{Architecture.}

We design a novel data trading ecosystem that builds on the top of the blockchain platform. A typical workflow in BDTS is that: \textit{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.

\noindent\hangindent 1em \textit{\textbf{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.

\noindent\hangindent 1em \textit{\textbf{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.

\noindent\hangindent 1em \textit{\textbf{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.

\subsection{Security Assumption}
In this scheme, we have three basic security assumptions.

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

\noindent\hangindent 1em \textit{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.

\noindent\hangindent 1em \textit{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.

\subsection{Security model}\label{subsec-secritymodel}

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

\noindent\hangindent 1em \textit{\textbf{Seller}}. Sellers intend to obtain more payment by selling their data. In our scheme, a seller needs to provide mainly three sectors: \textit{data}, \textit{description}, and \textit{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 \textit{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) \textit{matched data (towards corresponding description) and matched key (towards data)}, b) \textit{matched data and non-matched key}, c) \textit{non-matched data and matched key}, and d) \textit{non-matched data and non-matched key}.

\noindent\hangindent 1em \textit{\textbf{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) \textit{pay enough for sellers}, b) \textit{pay less for sellers}, c) \textit{pay enough for service providers}, and d) \textit{pay less for service providers}.

\noindent\hangindent 1em \textit{\textbf{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) \textit{authentic correct data and matched key},  b) \textit{authentic data and non-matched key},  c) \textit{fake data and matched key},  and d) \textit{fake data and non-matched key}. The first two need the premise of storing the seller's data.

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

\section{The BDTS Scheme}
\label{sec-system}

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: \textit{contract deployment}, \textit{encrypted data uploading}, \textit{data downloading}, and \textit{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.

\subsection{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).

\noindent\hangindent 1em \textit{\textbf{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.

\noindent\hangindent 1em \textit{\textbf{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.

\noindent\hangindent 1em \textit{\textbf{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.

\subsection{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.\ref{fig:combined}.a).

\noindent\hangindent 1em \textit{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.

\noindent\hangindent 1em \textit{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: \textit{content description}, \textit{data size}, \textit{the root} $r_d$ and \textit{the root} $r_ed$. 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.

\noindent\hangindent 1em \textit{Step3} and \textit{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$.

\noindent\hangindent 1em \textit{Step5}, and \textit{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 \cite{chen2017bootstrapping}. Data plagiarism will result in deposit loss, preventing the reselling behavior.

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

\noindent\hangindent 1em \textit{Step9}, \textit{Step10} and \textit{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.

\subsection{Matching and Data Downloading}

In this module, a consumer registers on SCMC and selects the service provider to download data (see Fig.\ref{fig:combined}.b).

\noindent\hangindent 1em  \textit{Step1} and \textit{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.

\noindent\hangindent 1em  \textit{Step3}, \textit{Step4}, \textit{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.

\noindent\hangindent 1em  \textit{Step6}, \textit{Step7}, \textit{Step8}. The consumer contacts with the service provider based on $IP_{sp}$, which is received in \textit{Step2}.  In \textit{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.

\noindent\hangindent 1em  \textit{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.

\noindent\hangindent 1em  \textit{Step12}, \textit{Step13}, and \textit{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 \textit{step14}.

\subsection{Decryption and Appealing}

In this module, the consumer pays to both the service provider and the seller (see Fig.\ref{fig:combined}.c).

\begin{itemize}
    \item[-] \textit{Step1}, \textit{Step2}, \textit{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.

    \item[-] \textit{Step4}, \textit{Step5}, and \textit{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.

    \item[-] \textit{Step7}, \textit{Step8}, \textit{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.

\end{itemize}

\noindent Paying the seller is similar to paying to the service providers, the differences between mainly concentrate on \textit{Step2}, \textit{Step3}, \textit{Step4}, \textit{Step7}, and \textit{Step8} (see Fig.\ref{fig:combined}.d).

\begin{itemize}

    \item[-] \textit{Step2}, \textit{Step3} and \textit{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.

    \item[-] \textit{Step7} and \textit{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.

\end{itemize}

\section{Implementations}
\label{sec-imple}

In this section, we provide the detailed implementation of three major functions, including \textit{sharding encryption} that splits a full message into several pieces, \textit{product matching} to show the progress of finding a targeted product, and \textit{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 platform\footnote{Source code: Hidden due to the anonymity policy.}. We provide implementation details in Appendix A.

\section{Security Analysis}
\label{sec-security}

In this section, we provide the analysis of BDTS based on game theory. The basic model of our solution is a \textit{dynamically sequential game} with \textit{multiple players}. The analyses are based on \textit{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.\ref{fig-game} (\textit{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 \textit{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 \textit{blue} line). Last, the SP sends the raw data and related keys to CM  (in \textit{brown} line). Based on that, we define our analysis model as follows.

\begin{defi} 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.
\end{defi}

For each of participated parties, they have four strategies as defined in Sec.\ref{subsec-secritymodel} (\textit{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.\ref{tab:game}. 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$ \textit{unit}s, while generating keys compensates $1$  \textit{unit}. The service fee during the transactions is $1$  \textit{unit}s for each party. Thus, we provide the cost of each strategy in the Table.\ref{tab:game}. The parameters of $x$ and $y$ are actual payments from CM, where $0\leq x<20,0\leq y<4, x+y<24$.

\begin{figure}[!hbt]
    \centering
    \includegraphics[width=\linewidth]{img/game.png}
   \caption{Game and Game Tree}
    \label{fig-game}
\end{figure}

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.\ref{fig-game} (\textit{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.

\begin{lem}\label{lma-seller}
If one seller provides data not corresponding to the description, the seller cannot obtain payments.
\end{lem}

\begin{prf}
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. \qed
\end{prf}

\begin{lem}\label{lma-sellerkey}
If one seller provides a decryption key not conforming to the description, the seller cannot obtain payments.
\end{lem}

\begin{prf}
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.  \qed
\end{prf}

\begin{table}[!hbt]
\caption{Strategies and Costs}\label{tab:game}
\begin{center}
\resizebox{0.85\linewidth}{!}{
\begin{tabular}{c|cc}
 \toprule
 \multicolumn{1}{c}{\textit{\textbf{SL Strategy}} }    &  \multicolumn{1}{|c}{Matched data}          & {Non-matched data} \\
 \midrule
  {Matched key}        & a, -11  & b, -1 \\
  {Non-matched key}    & c, -10  &  d, 0\\
  \midrule
 \multicolumn{1}{c}{\textit{\textbf{CM Strategy}} }    &  \multicolumn{1}{|c}{Sufficiently}       & {Insufficiently} (to SL) \\
 \midrule
  {Sufficiently} (to SP)  & e, -24  & f, -(x+4) \\
  {Insufficiently Paid}   &  g, -(y+20)    &  h, -(x+y) \\
\midrule
 \multicolumn{1}{c}{\textit{\textbf{SP Strategy}} }    &  \multicolumn{1}{|c}{Authentic data}       &  Non-authentic data  \\
 \midrule
  {Matched key}       & i, -2   & j, -1 \\
  {Non-matched key}  &  k, -1     & l, 0   \\
 \bottomrule
\end{tabular}
}\end{center}
 \begin{tablenotes}
      \footnotesize
       \item \quad\quad\quad The cost of -11 \textit{unit}s are short for -11, applicable to all.
       \item \quad\quad\quad Data is sold at 20 (to SL) while the service fee is 4 (to SP).
     \end{tablenotes}
\end{table}

\begin{lem}\label{lma-cm}
A consumer without sufficient payments cannot normally use the data.
\end{lem}

\begin{prf}
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.  \qed
\end{prf}

\begin{lem}
If one service provider provides data not conforming to that of the seller, he cannot obtain payments.
\end{lem}

\begin{prf}
This proof is similar to Lemma \ref{lma-seller}.  \qed
\end{prf}

\begin{lem}\label{lma-sp}
If one service provider provides a decryption key not conforming to data, he cannot obtain payments.
\end{lem}

Here, \textbf{Lemma \ref{lma-seller}} to \textbf{Lemma \ref{lma-sp}} 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.\ref{tab:net}. We demonstrate that the system can reach the subgame perfect Nash equilibrium under the following theorem.

\begin{thm}
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. \qed
\end{thm}

\begin{prf} 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.\ref{tab:net}, the optimal strategies for sellers (\textit{dei},\textit{dej},\textit{dek},\textit{del},\textit{dgi},\textit{dgj},\textit{dgk},\textit{dgl}) is to provide mismatched keys and data, while at the same time obtain payments from consumers. However, based on Lemma \ref{lma-seller} and Lemma \ref{lma-sellerkey}, 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.\ref{fig-game}. 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.\ref{tab:net} (red background), the strategies of \textit{aei}, \textit{afi} and \textit{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 \ref{lma-cm}, 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 \textit{afi} and \textit{agi} are impractical. With the previous analyses in the arm, we finally conclude that only the strategy \textit{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.  \qed
\end{prf}

\begin{table}[!hbt]
\caption{Payoff Function and Profits}\label{tab:net}
\begin{center}
\resizebox{\linewidth}{!}{
\begin{tabular}{c|c|c|c|c|c|c|c}
 \toprule
 \multicolumn{1}{c}{\textit{\textbf{$\mathcal{H}$}} }  & \multicolumn{4}{c}{\textbf{Payoff} in the form of (SL,CM,SP)} \\
 \midrule
 \textit{aei} & \textcolor{blue}{\text{(9,-4,2)}} & \textit{bei} & (19,-24,2) &  \textit{cei} & (10,-24,2) & \textit{dei} & (20,-24,2) \\
 \textit{aej} & (9,-24,3) & \textit{bej} & (19,-24,3) &  \textit{cej}& (10,-24,3) &  \textit{dej} & (20,-24,3) \\
 \textit{aek} & (9,-24,3) & \textit{bek} & (19,-24,3) &  \textit{cek}& (10,-24,3) &  \textit{dek} & (20,-24,3) \\
 \textit{ael} & (9,-24,4) & \textit{bel} & (19,-24,4) &  \textit{cel} & (10,-24,4) &  \textit{del} & (20,-24,4) \\
 \midrule
 \textit{afi} &  \textcolor{blue}{\text{(x-11,16-x,2)}} & \textit{bfi} & (x-1,-24,2) &  \textit{cfi}& (x-10,-24,2) &  \textit{dfi} & (x,-24,2) \\
 \textit{afj} & (x-11,-24,3) & \textit{bfj} & (x-1,-24,3) &  \textit{cfj}& (x-10,-24,3)  &  \textit{dfj} & (x,-24,3) \\
 \textit{afk} & (x-11,-24,3) & \textit{bfk} & (x-1,-24,3) &  \textit{cfk}& (x-10,-24,3) &  \textit{dfk} & (x,-24,3) \\
 \textit{afl} & (x-11,-24,4) & \textit{bfl} & (x-1,-24,4) &  \textit{cfl}& (x-10,-24,4) &  \textit{dfl} & (x,-24,4) \\
 \midrule
 \textit{agi} &  \textcolor{blue}{\text{(9,-y,y-2)}} & \textit{bgi} & (19,-24,y-2) &  \textit{cgi}& (10,-24,y-2) &  \textit{dgi} & (20,-24,y-2) \\
 \textit{agj} & (9,-24,y-1) & \textit{bgj} & (19,-24,y-1) &  \textit{cgj}& (10,-24,y-1) &  \textit{dgj} & (20,-24,y-1) \\
 \textit{agk} & (9,-24,y-1) & \textit{bgk} & (19,-24,y-1) &  \textit{cgk}& (10,-24,y-1) &  \textit{dgk} & (20,-24,y-1) \\
 \textit{agl} & (9,-24,y) & \textit{bgl} & (19,-24,y) &  \textit{cgl}& (10,-24,y) &  \textit{dgl} & (20,-24,y) \\
 \midrule
 \textit{ahi} &(x-11,-x-y,y-2) & \textit{bhi} & (x-1,-24,y-2) &  \textit{chi}& (x-10,,-24,y-2) &  \textit{dhi} & (x,-24,y-2) \\
 \textit{ahj} & (x-11,-24,y-1) & \textit{bhj} & (x-1,-24,y-1) &  \textit{chj}& (x-10,,-24,y-1) &  \textit{dhj} & (x,-24,y-1) \\
 \textit{ahk} & (x-11,-24,y-1) & \textit{bhk} & (x-1,-24,y-1) &  \textit{chk}& (x-10,,-24,y-1) &  \textit{dhk} & (x,-24,y-1) \\
 \textit{ahl} & (x-11,-24,y) & \textit{bhl} & (x-1,-24,y) &  \textit{chl}& (x-10,,-24,y) &  \textit{dhl} & (x,-24,y) \\
 \bottomrule
\end{tabular}
}
 \begin{tablenotes}
      \footnotesize
       \item \quad The texts in blue color reach Nash Equilibrium.
     \end{tablenotes}
\end{center}
\end{table}

\section{Efficiency Analysis}
\label{sec-efficiency}

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.

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

\subsection{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.\ref{tab-complexity}.

Firstly, at the \textit{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 \textit{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 \textit{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 \cite{goyal2019secure} spends $O(n)$ as they store all the chunks of delivering data on-chain. CacheCas \cite{almashaqbeh2019cachecash} takes the cost at a range of  $[\mathcal{O}(1), \mathcal{O}(n)]$ due to its \textit{lottery tickets} mechanism. FairDwonload \cite{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)$.

\begin{table}[!hbt]
\caption{Computational Complexity and Comparison}
 \label{tab-complexity}
 \resizebox{0.95\linewidth}{!}{
 \begin{tabular}{c|c}
    \toprule
     \multicolumn{1}{c}{\textbf{Algorithm}}   & \multicolumn{1}{c}{\textbf{Complexity}}
       \\
     \midrule
   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}$   \\
   \midrule
    \multicolumn{1}{c}{\textbf{Competitive Schemes}}   & \\
    \midrule
    \multicolumn{1}{c|}{Gringotts \cite{goyal2019secure} } &   $\mathcal{O}(n)$ \\
    \multicolumn{1}{c|}{ CacheCash \cite{almashaqbeh2019cachecash} } &   $[\mathcal{O}(1), \mathcal{O}(n)]$ \\
    \multicolumn{1}{c|}{ FairDwonload \cite{he2021fair} } &  $\mathcal{O}(1)$ \\
    \multicolumn{1}{c|}{\textbf{\textit{our BDTS}}} &   $\mathcal{O}(1)$ \\
   \bottomrule
  \end{tabular}
  }
    \begin{tablenotes}
       \footnotesize
       \item \quad $i$ is the number of segmented data;  $n$ represents a full chunk of data.
     \end{tablenotes}

\end{table}

\subsection{Experimental Evaluation}
Then, we evaluate the practical performance. We focus on the functionaries of \textbf{\textit{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.

\smallskip
\noindent\textbf{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.\ref{fig-tests} 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 \textit{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.

\smallskip
\noindent\textbf{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.\ref{fig-tests}, 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 \textit{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.

\smallskip
\noindent\textbf{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 \textit{left}, \textit{middle} and \textit{right}) in Fig.\ref{fig-tests} show the same trend: \textit{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.

\begin{figure*}[!hbt]
    \centering
    \includegraphics[width=\linewidth]{img/tests.png}
   \caption{\textbf{Download Times of Different Data Type, Data Size and Storage Capacity}: We evaluate three types of data formats including video \textit{(the grey color)}, image \textit{(orange)}, and text \textit{(blue)}. For each of data type, we separately test their download times in distinguished data size with 10M \textit{(the left figure)}, 100M \textit{(middle)} and 1G \textit{(right)}. Meanwhile, we also investigate the performance along with increased number of storage devices \textit{(from 1 to 4)}, or equivalently the number of service providers.}
    \label{fig-tests}
\end{figure*}

\smallskip
\noindent\textbf{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.\ref{tab-avgtime}, 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.\ref{fig-performance}. 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.

\section{Discussion}
\label{sec-discuss}

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

\smallskip
\noindent\textbf{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 \textit{data}, \textit{description} and \textit{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.

\smallskip
\noindent\textbf{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 \cite{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 \cite{gentry2002hierarchical} to manage its complicated data, as well as remain the efficiency of fast query.

\smallskip
\noindent\textbf{Extensibility.} BDTS can extend functionalities by incorporating off-chain payment techniques (also known as layer-two solutions \cite{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 \cite{malavolta2017concurrency}. Our implementation only set the backbone protocol for fair exchange, leaving many flexible slots to extend functionalities by equipping matured techniques.

\begin{figure*}
    \begin{minipage}[!h]{0.65\linewidth}
    \captionof{table}{Average Download Time}
 \label{tab-avgtime}
 \resizebox{0.93\linewidth}{!}{
 \begin{tabular}{c|cccccc|cc}
    \toprule
     \multicolumn{1}{c}{\quad}   & \multicolumn{6}{c}{\quad\textbf{Data Size (Text)}\quad}
     & \multicolumn{1}{c}{\quad\textbf{Average Time }\quad}   \\
     \midrule
    \multicolumn{1}{c|}{\textbf{Storage}}   &  {\textbf{1M}}  &  {\textbf{10M}}  &  {\textbf{50M}} &  {\textbf{100M}}  &    {\textbf{500M}}    & \textbf{1G}  &
    \quad\textbf{(M/s)}\quad     \\% &  \quad\textbf{2G (Video)}\quad
    \midrule
   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 \\%& 88.75
   5 & 0.04 & 0.38 & 1.79 & 3.33  & 18.88  & 34.52  & 0.039  \\%& 70.55
   6 & 0.03 & 0.32 & 1.56 & 2.88 & 14.69 &   29.48  & 0.031  \\%& 60.95
   \bottomrule
  \end{tabular}
 }
 \end{minipage}
 \begin{minipage}[!h]{0.33\linewidth}
    \caption{Trend of Download Time}
    \label{fig-performance}
    \includegraphics[height = 3.65cm]{img/performance.png}
    \end{minipage}

\end{figure*}

\section{Related Work}
\label{sec-rw}

In this section, we provide related primitives surrounding \textit{fair exchange} protocols and \textit{blockchain}s. We also give backgrounds of supporting techniques of \textit{game theory}.

\smallskip
\noindent\textbf{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 \cite{li2020accountable}. Many scholars work to build their robust trading systems by leveraging blockchain and smart contracts. Jung et al. \cite{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. \cite{chen2017bootstrapping} design an offline digital content trading system. If a dispute occurs, the arbitration institution will conduct it.  Dai et al. \cite{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. \cite{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. \cite{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 \textit{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.

\smallskip
\noindent\textbf{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. \cite{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. \cite{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. \cite{eckey2020optiswap} propose a smart contract-based fair exchange protocol with an optimistic mode. They maximally decrease the interaction between different parties. Janin et al. \cite{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 \cite{shin2017t}\cite{choudhuri2017fairness}\cite{kiayias2016blockchain}.

\smallskip
\noindent\textbf{Game Theory in Blockchain.} Game theory is frequently adopted in the blockchain field due to the players' profit-pursuing nature \cite{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 \cite{kiayias2016blockchain}, the cooperative game \cite{lewenberg2015bitcoin}, the evolutionary game \cite{kim2019mining} and the Stackelberg game \cite{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. \cite{lohr2022formalizing} and Janin et al. \cite{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 \cite{eyal2015miner}\cite{kwon2017selfish}\cite{negy2020selfish}\cite{sapirshtein2016optimal}, multiple miners strategy  \cite{bai2021blockchain}, the compliance strategy towards PoW/PoS \cite{karakostas2022blockchain}, pooled strategies \cite{wang2019pool}\cite{li2020mining}, and fickle mining in different chains \cite{kwon2019bitcoin}. Our analyses are compliant with previous research principles.

\section{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.

\bibliographystyle{unsrt}