1. Introduction
With the development of network technology, cloud storage technology developed with cloud computing has attracted more and more attention from enterprises and researchers [
1,
2,
3]. The characteristics such as high reliability, availability and scalability have attracted more and more cloud users [
4,
5,
6,
7]. Many public cloud storage platforms are available in the market such as Google Storage, Amazon S3, Microsoft Azure, RackSpace CloudFiles, etc. However, these cloud storage platforms or applications suffered from different problems such as single-point failures and vendor lock-in [
8,
9,
10]. For example, Microsoft Azure and Amazon S3 have experienced service outages for several times, causing huge economic losses to cloud storage service companies and users. In the result, the multi-cloud storage has been proposed, which places data on multiple could storage providers to achieve better quality of service by avoiding vendor lock-in and improving fault-tolerance. The multi-cloud storage is beneficial to applications which need to keep a large amount of data such as data backup, document archiving or electronic health recording.
In a multi-cloud system, data can be held by multiple storage providers to avoid vendor lock-in and improve fault-tolerant which obtains higher Quality of Service (QoS) in reliability, availability and scalability than single-cloud storage. Storage policy with erasure coding combined with a multi-cloud environment can not only improve the QoS in storage but also reduce the cost of data storage, and it has attracted more studies [
11,
12,
13,
14]. With erasure coding, a demander’s data are divided into
k blocks, and then these blocks are used to generate
encoded data blocks (
n blocks in total,
). The numbers
n and
k are called as parameter (
) of erasure coding. These
n data blocks will be placed to
n cloud storage providers, and each provider holds just one data block respectively. Compared to full replication, the storage policy with erasure coding can decrease the backup size of the data. With this feature, a demander can choose the cheaper providers as well as keeping the QoS. Some works have used feature of erasure coding in multi-cloud storage system [
15,
16,
17].
With the storage policy of erasure coding, how to select the cloud providers to store the data and execute the transaction securely is an important problem. Transaction mechanisms in cloud storage have been studied [
17,
18,
19,
20,
21,
22], some of which address the problem—how to choose the resources in competitive environment such as [
18,
19]. However, although these mechanisms investigate the distributed storage to avoid the disadvantage of centralized mode, they still adopt traditional centralized trading mode, without considering the transaction in decentralized environment. The weaknesses of centralized model still exist such as high cost, vendor lock-in, single point failure risk, etc. Recently, the blockchain technology has been applied in storage transaction such as Storj [
23], N2C [
24], but these applications did not investigate the cloud provider selection mechanism in the competitive environment.
Therefore, in this paper, to help the storage demander select suitable resource providers and execute transactions in decentralized environment, we construct a decentralized resource transaction mechanism with blockchain technology.
The contributions of our work are as follows.
First, to guarantee the availability and decrease the storing cost for storage policy with erasure coding, a reverse VCG (Vickrey-Clarke-Groves)-based auction mechanism is proposed for storage resource selection and transaction which can incentivize the cloud providers to report truthful cost in decentralized environment.
Second, we deploy the proposed mechanism by designing a corresponding smart contract. Especially, by dividing the whole transaction process into four stages: publishing requirement, submitting sealed bids, revealing sealed bids and auction, and payment. We present a solution for the problem—how to implement a VCG-like mechanism in a blockchain environment.
The remainder of the paper is organized as follows. The problem model and transaction mechanism are respectively introduced in
Section 2 and
Section 3. In
Section 4 we focus on the cloud storage resource transaction method based on smart contract. In
Section 5 it is the experimental analysis in the private chain to show the correctness of transaction and finally we conclude and discuss the future work of the paper in
Section 6.
3. Storage Resource Transaction Mechanism
First, we introduce the definition of incentive compatible.
Definition 1 (Incentive Compatible, IC)
. A mechanism is incentive compatible, if for any provider i, regardless of the type reports of other providers, declaring a bid that reveals its true type can maximize its utility. Let be the truthful cost of storage resource to provider i. Formally, given any cost profile of others , we have: To minimize the total storage cost, we should design an incentive compatible mechanism to make providers reveal their true bids.
Now we introduce reverse VCG auction mechanism. Let denote the set of available allocation results. is a allocation result, . Given cost profile of all providers , a reverse VCG mechanism satisfies following rules:
- (1)
Allocation function can minimize the social cost:
- (2)
Let , . The payment for provider i is .
The first rule means that the allocation of reverse VCG auction mechanism always minimizes the social cost. In the second rule,
is the allocation with minimal social cost, and
is the allocation with minimal social cost if
i is not present.
is the minimal social cost if
i does not participate the mechanism, and
is the total social cost of other participants excluding
i under the allocation
. Therefore, the payment of
i implies the saving social cost due to the participation of provider
i. The reverse VCG auction mechanism is incentive compatible, the proof process is similar to VCG mechanism [
25].
Assume that the storage policy is based on erasure coding. In our work, we design a reverse VCG-based transaction mechanism to help the demander select cloud providers with different costs.
Figure 3 explains these functions in detail.
The process in
Figure 3 is as following:
- Step 1
The demander posts requirement information, including the required number of cloud providers , the availability of resource, required storage capacity .
- Step 2
Each provider who can provision storage resource and satisfy the requirement of availability submits the bid .
- Step 3
When the amounts of bidders who participate in the transaction is larger than , we think that the transaction is successful. The allocation and payment are determined by the rule of VCG mechanism. Otherwise, the amount of provider participating in the transaction is less than , the transaction is failed.
- Step 4
Select providers who can minimize the total costs of the demander as the winners. The payoff of the winner is , where is the optimal allocation, and is the optimal allocation if provider i is not present.
In our mechanism, according to Step 4, the winners are the providers with the lowest bids, and computed payoff of the winner equals to the highest bid of the losers. According to the above processes, we can get a truthful transaction mechanism, lowest social cost of the required resource. At the same time, our mechanism has some features of erasure coding such as high fault-tolerance and avoiding vendor lock-in.
5. Experimental Analysis
The main objective of our work is to design a distributed data storage transaction mechanism in blockchain environment. In order to test our proposed mechanism, we have implemented a software prototype on Ethereum and write complex codes by Solidity. The simulation used five demanders and 20 providers to construct auction scenario. Smart contract was executed on our proposed mechanism. We assume that all providers can provision storage resource and bid for demander’s request.
In order to evaluate the correctness of the mechanism proposed in this paper, we publish the smart contract which realizes the resource transaction mechanism on the private chain of Ethereum. The experimental environment as a distributed transaction platform simulates the auction environment. We assume that there always exist demanders in the auction, and we consider providers are independent identically. A demander publishes the number of suppliers
, data block size
as shown in
Table 1 and 20 providers participate in the auction. The bidding strategy of each provider is related to his total cost of resources, which mainly includes storage cost and bandwidth cost, etc. We suppose that the cost of each provider follows uniform distribution in
, and we choose
and
. After the smart contract is deployed in Ethereum blockchain, we publish the bid information of a demander including
,
and deadline of each stage. In our experiments, we set same time periods for each demander. The stage period of submitting sealed bids is within 5 min. A duration of 5–8 min is the stage period of revealing sealed bids and auction; the next 8–10 min is the payment period. We pre-deposit
per account before starting the simulation, because the user has to pay a service fee when invoking the smart contract. For the sake of preventing DDoS attacks, providers are required to send Ether as deposit in the auction. Furthermore, the bid information of providers is encrypted and saved in data storage, thus no malicious attackers can decrypt and read them. By this way, the cloud storage resource transaction could be performed by smart contract rather than any unbelievably third agent.
We used the Ubuntu operating system to install the Ethereum private chain for testing environment. The stable version of GETH was installed. And in order to operate smart contract easily, we installed the Ethereum wallet for smart contract deployment. After a series of complicate environments have been built, the Ethereum private chain for deploying smart contract can be officially started. Smart contract deployment is to pay attention to Solidity syntax, and it is better to perform simple operations on smart contract functions to avoid gas shortage which may lead to transaction failure.
First, we completed five transactions of experiments according to above procedures. In these experiments, each provider who can provision resources submits the two consistent bids in Stage 2 and Stage 3.
Figure 4 shows the total cost of demander with each sample transaction. We compared the cost with that computed by MATLAB, and the results are consistent which implies the correct of our algorithm of auction mechanism. In addition, each provider can come or go freely in the auction, which does not affect the overall process of trading.
Furthermore, we select transaction 2 as an example to further check the correctness of functions in four stages. We show part of bidding information of providers in
Table 2 because of page size limited. The cost and random string are combined to form sealed bid and revealed bid. For example, the bid “6.41edf” of provider
i means that the bid is “6.41” and the encrypted random string is “edf”. From the
Table 2, we can get following information. According to sealed bidding information,
is 2.04, but provider 7 submitted 3.43 in revealed bids, which is not consistent with bid
submitted in sealed bid. Therefore, our system considers the bidding of submitted by provider 7 as invalid bidding which cannot be allocated. Provider 5 submitted his bid in sealed bidding stage, but did not submit bid in revealing sealed bids stage, so his submission is also invalid. Provider 4 is also not allocated, even though his sealed bid is consistent with revealed bid, but random string is not consistent.