Cloudchain: A Blockchain-Based Coopetition Differential Game Model for Cloud Computing

Abstract

In this paper, we introduce, design and develop Cloudchain, a blockchain-based cloud federation, to enable cloud service providers to trade their computing resources through smart contracts. Traditional cloud federations have strict challenges that might hinder the members’ motivation to participate in, such as forming stable coalitions with long-term commitments, participants’ trustworthiness, shared revenue, and security of the managed data and services. Cloudchain provides a fully distributed structure over the public Ethereum network to overcome these issues. Three types of contracts are defined where cloud providers can register themselves, create a profile and list of their transactions, and initiate a request for a service. We further design a dynamic differential game among the Cloudchain members, with roles of cloud service requesters and suppliers, to maximize their profit. Within this paradigm, providers engage in coopetitions (i.e., cooperative competitions) with each other while their service demand is dynamically changing based on two variables of gas price and reputation value. We implemented Cloudchain and simulated the differential game using Solidity and Web3.js for five cloud providers during 100 days. The results showed that cloud providers who request services achieve higher profitability through Cloudchain compared to those providers that supply these requests. Meanwhile, spending high gas price is not economically appealing for cloud requesters with a high number of requests, and fairly cheaper prices might cause some delays in their transactions during the network peak times. The best strategy for cloud suppliers was found to be gradually increasing their reputation, especially when the requesters’ demand is not significantly impacted by the reputation value.

Keywords

1 Introduction

To mitigate the issue of underutilized and over provisioned computing resources, cloud providers scaled their pool of resources by forming cloud federations to maximize their profit and provide guaranteed Quality of Services (QoS) [4, 6, 11]. In spite of the prominent federation advantages, cloud providers are reluctant to participate in due to some strict challenges, mainly: 1- The stability of a federation is a key factor for the cloud providers to ensure their profitability [6]. Such a stability requires long-term commitments from the providers, which is very hard to obtain. 2- A federation needs to address the complications of a fair revenue sharing model to warrant that each cloud provider will gain a revenue according to the amount of computational resources contributed to the federation. 3- The presence of unknown and untrusted participants in a federation can degrade the QoS of the federated services [16]. The trust issue limits conventional federations to enroll only trusted providers and disregard the new ones. 4- Having a large pool of computing resources in a grand coalition might increase the opportunity of botnet attacks. Meanwhile, forming a small federation might hinder the revenue maximization of its participants [2]. 5- There are some security and privacy concerns regarding the managed data and services as well as the creation and management of the cloud federation itself. All the necessary information to manage a federation is usually maintained in a centralized trusted third party. This implies that a federation must maintain roles concerning the authorization to manage the participants’ information that yields, which makes not only a single point of failure, but also raises trustfulness concerns [11].

Contributions: This research overcomes the traditional cloud federation issues by contributing a novel architecture and an innovative strategic game model:

• 1. To provide a practical cooperative solution that any cloud provider can embrace regardless of their market position and trustworthiness, we advocate a fully distributed architecture with a democratic governance structure, called Cloudchain. To effectively enforce such a structure, Cloudchain proposes an innovative exploitation of blockchain to prompt and support interoperability and coopetition among the cloud providers over the public Ethereum network. Within Cloudchain, cloud providers endeavor to overcome the resource limitation in their local infrastructure by outsourcing their customers’ requests to other members of the Cloudchain. Moreover, it allows providers to access underutilized resources and lease them at cheaper prices. By leveraging blockchain-enabled smart contracts [17], we eliminate the need for trust in the federation and reduce barriers of entry [9].

• 2. To incentivize the cloud providers and help them make wise decisions about the utilization of Cloudchain, a dynamic differential game is designed, solved and simulated. This game aims to maximize the profit of the Cloudchain members who cooperatively compete while their service demand is dynamically changing. Two variables are considered to impact the cloud provider’s revenue, the demand variability and the quality of the provided service: gas cost and reputation value. Gas is a proportional amount that Ethereum pays to motivate the miners to participate in the mining process and to supply a fair compensation for their computation effort [12]. Reputation value is defined to assign a credibility proportional to the quality that a Cloudchain member provides.

We implement the Cloudchain prototype using Solidity and Web3.js which is available open source in Github¹. We further simulated the differential game using the Gratner’s rating dataset² where five real-world providers trade their services. Despite being costlier to transact for cloud-service providers who request a service rather than supply, the obtained results proved it is economically justified to adopt Cloudchain.

2 Related Work

The literature about cloud-providers cooperation focuses on federation formation as coalitional games where capacity and revenue are shared [15]. Coronado et al. had an intensive investigation on federation-formation variables among cloud providers, including revenue sharing mechanisms, capacity and cost disparity, and the presence of a big competitor [5]. They defined revenue sharing mechanisms as the most important factor. Among these mechanisms, shapely value and outsourcing models had the least and best performance, respectively. They indicated that collaborating cloud providers can implement a mechanism in which a provider outsources some of its business and gets a percentage of the revenue. The outsourcing model allows the provider to keep some of the revenue of its secured business, even though it is not able to fulfill that business alone. The authors had an insight through the demand peaks and concluded that cloud providers tend to stay in outsourcing collaboration when the demand is high. However, interoperability, trust among cloud providers and service quality or SLA are not considered in their study. The findings from this study confirm the superiority of outsourcing in terms of maximizing the profit of cloud providers, which is what we are proposing in this paper in addition of having the advantage of coopetition among cloud providers. The fact that providers tend to collaborate when they face a hike in their demand, reinforces the consideration of a dynamic and long/short-term federation like Cloudchain. The challenges of interoperability and trust issues among cloud providers are also addressed by the blockchain platform we propose in this paper. Another cloud outsourcing model has been performed by Chen et al. [4] who analyzed the interrelated workload factoring and coalition formation game among private clouds. The authors integrated two types of federations: (1) vertical (outsource workload to public clouds), ad (2) horizontal (share resources with other private clouds. Their experiments found this approach to be promising to improve the cloud’s service quality and decrease the delay by 11%. However, their research was limited to service quality and economic aspects of stable cooperation patterns without considering other challenges of a traditional federation explained in the previous section.

Very few efforts have been made to study the potential of blockchain in real-world applications despite its great potential for businesses to share data and collaborate in a secure and customized manner [13]. According to Tractica, a market research firm, the annual revenue for enterprise applications of blockchain is estimated to increase to $19.9 billion by 2025 [8]. The majority of studies about blockchain’s application have focused on finance [19], energy [14] and IoT applications [21]. In cloud computing and service industry, to the best of our knowledge, there has been only one academic initiative that proposed a cloud marketplace based on the blockchain technology. Klems et al. designed Desmaa, a conceptual framework for trustless intermediation in service marketplaces using blockchain [9]. This conceptual framework modeled the interactions between a service provider and a service consumer and tried to overcome problems of conventional marketplace systems, such as barriers of entry and transaction costs. Yet, the outsourcing model with collaboration and competition among cloud providers themselves are not considered in their research. Moreover, the providers’ profit and the best strategies for utilizing this marketplace is not elaborated nor modeled. Even though the authors developed a prototype, no evaluation and validation against real-world’s scenarios were provided.

3 Cloudchain Architecture

Cloudchain incorporates three types of smart contracts including a set of executable functions and state variables. Similar contracts are proposed in [1] in the context of medical data management. Contract 1 (C1) or Cloudchain Registery (CCR) is a global contract that maps cloud providers identification values (including Name, Reputation Value, Computing Capacity and Storage Capacity) to their Ethereum address identities (equivalent to public keys). The reputation values can be computed from the customers’ ratings given to each provider through online rating platforms. Policies coded into the contract can regulate registering new providers or changing the mapping of the existing ones. The cloud provider registration can be restricted only to certified providers. CCR also maps identities to the Cloudchain Contract (CCC) address on the blockchain, where a special contract regarding each provider profile and list of services is recorded.

Contract 2 (C2) denotes Cloudchain Profile (CCP). It holds a list of references to CCC, representing all the participants’ previous and current engagements with other nodes in the system. CCP also implements a functionality to enable provider notifications. Providers should register their requests in this contract. Each transaction list stores a status variable. This indicates whether the transaction is newly established, awaiting pending updates and has or has not been completed. This contract is important as it stores the address of all new CCC contracts, without which Cloudchain can simply lose the track of all the contracts.

Contract 3 (C3) represents the Cloudchain Contract (CCC). It is issued between two nodes in the system when one node accepts and provides the requested service for the other. The beneficiaries can also complete, or cancel the contract. Once the contract is completed or canceled, the contract balance would be transferred to the supplier-, or requester address respectively, and the contract status would also be updated. There are two approaches to reduce the size of the data as well as the cost of transactions over Cloudchain. The first approach is a common practice for data storage in smart contracts and consists of storing raw data off-chain, and meta-data, small critical data, and hashes of the raw data on-chain [20]. However, the selection of off-chain data storage has some concerns regarding the interaction between the blockchain and the off-chain data storage. The other approach is to provide a common glossary among cloud providers to define the generic terms and policies to be referred to in the contract.

Fig. 1.

Cloudchain interactions

Figure 1 provides the steps taken by the Cloudchain members to register and establish their requirements by interacting via Cloudchain. In step 1, a provider registers in CCR. Each registered user is assigned with a public key pair. Guaranteed SLA tenants require performance consistency and scale predictability. When a member faces a computing-resources deficiency to meet its end users’ demand with guaranteed SLA, it can submit a request for a service using CCP to deploy a CCC to the blockchain in step 2. Requesters are required to pay a deposit in advance and it is stored in the contract. Meanwhile, a rule for providers is set by the requesters to ensure that qualified providers could ultimately receive the task, e.g. reputation value threshold. Function calls on contracts are transactions, and those which update the contract storage need to be validated by miners. Once a new block is mined with the newly linked CCC, it would be broadcasted to other nodes in step 3. Through step 4, the first node that accepts the request should update the respective CCC contract. Each provider who accepts a task should deposit some coins or its reputation value to guarantee the quality of the task. The contract termination and delivery of the requested service have to be confirmed by the service requester in step 5. The requester is required to rate the supplier based on the received service quality.

4 Cloudchain Members’ Revenue Optimization

A true blockchain-led federation will not happen unless cloud providers are widely engaged and able to manage the costs and properly play their role. The use of a differential game [3] is motivated by the need to model the time constrained and dynamic strategies of selfish cloud providers willing to maximize their own revenue. Let us consider two typical cloud providers (CP) over Cloudchain, $CP_{r}$ as the provider who is facing a peak time and is going to request some VMs from other Cloudchain members, and $CP_{s}$ as the Cloudchain member that has some idle servers and is willing to rent them out with the price offered by $CP_{r}$. For simplicity and without losing generality, we will focus on a single VM type, with $\phi$ denoting the capacity and the process rate of VM instances that can be hosted by a typical $CP_j$ that can be $CP_{r}$ or $CP_{s}$.

To make a request and create a contract, $CP_{r}$ has to define the price of gas $G_{r}$ for the created transaction (e.g. 5 gwei). If the price is high enough, the transaction will be executed sooner, since miners will execute transactions with the highest gas price first. If the price is set too low, $CP_{r}$ may end up waiting longer for execution of its transaction and distribution of its request. This waiting time may degrade the service quality for its users and hinder its profit. On the other hand, setting a high gas price for every single transaction and update incurs higher costs. So, the gas price is a decisive factor in profit optimization and we define it as the control path at time t for $CP_{r}$, denoted by $G_{r}(t)$. In this game, VM price is assumed to be given by $CP_{r}$. To be qualified to supply a cloud service, the provider $CP_{s}$ has to maintain a good reputation $R_{s}$ which is given based on the quality of service for end users and the quality of collaboration (e.g. speedy communication) with the cloud provider that requested the service, $CP_{r}$. Even though the reputation value is given by $CP_{r}$ and not $CP_{s}$ itself, yet it has a control over this value through the service quality and gas price of its own transactions. Therefore, $R_{s}(t)$ is considered as the control path of $CP_{s}$ to coopete with $CP_{r}$ within Cloudchain to gain higher profit. Table 1 provides a summary of the notations used in our model.

Table 1. Notations used in Cloudchain

In order to capture the demand elasticities and variations specific for each user, we define the user demand using the Cobb-Douglas function that models well these elasticity aspects in terms of price and reputation, adopted from [18]. It is assumed that the user will have the opportunity to check the cloud provider rating that represents the actual user satisfaction level and reputation value defined through Cloudchain. The user demand function is defined as follows:

$$\begin{aligned} D_{u}= \mu \ p^{-\alpha _{u}} \ R^{\beta _{u}} \end{aligned}$$

(1)

In the mining race, miners have to compete to solve proof of work and propagate the block to reach consensus. The new blocks’ generation follows a Poisson process with a constant rate $\dfrac{1}{\varGamma }$ throughout the whole Cloudchain network [10]. Before the race, miners collect their selected pending transactions into their blocks with a total gas amount of $\sum _{j=1}^{k}M_{j}$. When miner j propagates its block to Cloudchain for consensus, the time for verifying each transaction is affected by the size of transactions $M_{j}$. The first miner j who successfully has its block achieves consensus will be rewarded based on the amount of the assigned capacity $\phi _j^{''}$. Thus, miner j’s expected reward $Rw_j(\phi _j^{''})$ is:

$$\begin{aligned} Rw_{j}(\phi _{j}^{''})= Rw_{j} \mathbb {P}_{j}(\phi _{j}^{''},M_j) \end{aligned}$$

(2)

where $\mathbb {P}_{j}(\phi _{j}^{''},M_j)$ is the probability that miner j receives the reward by contributing a block. To win the reward, provider must perform a successful mining and instant propagation. The miner may fail to obtain the reward if its new block does not achieve consensus as the first. This kind of mined block that cannot be added to the blockchain is called orphaned block. The block containing a larger size of transactions has a higher chance of becoming orphaned since a larger block requires more propagation time, thus, causing a higher delay for consensus. As the arrival of new blocks follows a poisson distribution, miner j’s orphaning probability, $\mathbb {P}_{j}^0$, can be approximated as:

$$\begin{aligned} \mathbb {P}_{j}^0 = 1-exp(-\dfrac{1}{\varGamma })\tau _{j} \end{aligned}$$

(3)

Here, we assume miner j’s block propagation time $\tau _{j}$ is linear with the size of transactions in its block, $\tau _{j}= M_j \eta _{j}$, where $\eta _j$ is a constant that reflects the impact of $M_j$ over $\tau _j$. Therefore, we obtain the reward probability as follows:

$$\begin{aligned} \mathbb {P}_{j}(\phi _{j}^{''},M_j)= 1 - \mathbb {P}_{j}^0 = \phi _{j}^{''} e^{-\dfrac{1}{\varGamma } M_j \eta _{j}} \end{aligned}$$

(4)

Substituting Eq. 4 into Eq. 2 provides an estimation of total revenues that $CP_{j}$ may obtain by attending the mining tournament. To model the transactions’ distribution, we use the compound Poisson process, which is a generalization of the Poisson process where each arrival is weighted according to a distribution. The compound Poisson process represents better the transactions dynamics. In this case, the assumption is that transactions sent to Cloudchain follow a Poisson process, but the amount of gas they require follows a compound Poisson process. The reason is that the difference between the amount of gas is based on the complexity of the transaction, for example, the creation of a contract requires a much higher amount of gas than updating the contract. Therefore, the probability of the required gas by $X_j$ transactions occurring in $[0-T]$ follows an exponential distribution based on the compound Poisson process as follows:

$$\begin{aligned} \mathbb {P}_{j}(X)= \dfrac{e^{-\omega T} (\omega T)^{X_j}}{X_{j}!} \end{aligned}$$

(5)

4.1 Cloud Provider as a Requester

Here we explain the scenario from the perspective of $CP_r$ that has to optimize its profit $CPP_r$ while requesting VMs as follows:

$$\begin{aligned} CPP_{r}(G_{r}(t), D_{r}^{'}(t), t)&= (p_{r} - \ \phi _{r} \ C_{r}) \ D_{r} + (p_{r}- p_{s}^{'} \phi _{s}^{'}) D_{r}^{'} (t) \nonumber \\&- \dfrac{e^{-\omega T} (\omega T)^{X_r}}{X_{r}!} M^{'}_{r} G_{r}(t) + Rw_{r} \phi _{r}^{''} e^{-\dfrac{1}{\varGamma } M \eta } \end{aligned}$$

(6)

$M^{'}_{r}$ represents the amount of required gas that depends on the complexity of the transaction a provider wants to initiate. The transaction fees go to the miner that mines the block, so if a provider attends a mining process, it will be rewarded according to Eqs. 2 and 4. $D_{r}^{'}(t)$ is the demand that $CP_r$ intends to outsource to obtain the idle capacity of $\phi _{s}^{'}$ for a secondary price of $p^{'}$. Considering the time-dependent profit functions of $CP_r$ in Eq. 6, the objective function is the total discounted cloud provider’s payoff over the planning horizon $[0-T]$:

$$\begin{aligned} \text {maximize}&\quad \int _{0}^{T} e^{\rho t} \{ CPP_{r}(G_{r}(t), D_{r}^{'}(t), t) \} dt \nonumber \\ \text {subject to}&\quad \dot{D}_{r}^{'}(t) = G_{r}^{\beta _{u}}(t)\psi _{r} +\check{\theta } R_{s}^{\beta _{u}}(t) - \delta _{r} D_{r}^{'}(t) \nonumber \\&\quad D_{r}^{'}(0) = D_{0r}^{'} \end{aligned}$$

(7)

The users’ demands evolution over time is represented as $\dot{D}_{r}^{'}(t)$ for $CP_r$ that increases when the service quality rises. The service quality is aggregated through two factors of gas price that $CP_r$ pays and the reputation of $CP_s$. The demand decays at a certain rate of $\delta _{r}$. It is important to note that Eq. 7 formulates an optimal control problem with the gas price as a control variable and the cumulative demand of $CP_r$ as a state variable. The analysis of differential games relies profoundly on the concepts and techniques of optimal control theory [7]. To study the dynamics of the payoff function and the path of control variable, we leverage the Hamiltonian systems. Equilibrium strategies in the open-loop structures can be found by solving a two-point boundary value problem for ordinary differential equations derived from the Pontryagin maximum principle in Hamiltonian functions. The Pontryagin maximum principle gives the necessary condition for a control path to be optimal open-loop control. To acquire the optimal control, we first formulate the Hamiltonian system of the cloud provider’s payoffs:

$$\begin{aligned} H_{r}(G_{r}(t), D_{r}^{'}(t), \lambda _{r}(t),t) = (p_{r} - \ \phi _{r} \ C_{r}) \ D_{r}(t) + (p_{r}- p_{s}^{'} \phi _{s}^{'}) D_{r}^{'} (t)\nonumber \\ - \dfrac{e^{-\omega T} (\omega T)^{X_r}}{X_{r}!} M^{'}_{r} G_{r}(t) + Rw_{r} \phi _{r}^{''} e^{-\dfrac{1}{\varGamma } M \eta } \nonumber \\ +\lambda _{r}(t) (G_{r}^{\beta _{m}}(t)\psi _{r} +\check{\theta } R_{s}^{\beta _{m}}(t) - \delta _{r} D_{r}^{'}(t)) \end{aligned}$$

(8)

According to the control theory, the optimal control strategy of the original problem must also maximize the corresponding Hamiltonian function. Thus, based on the Pontryagin maximum principle, the candidate optimal strategy has to satisfy the following necessary conditions:

$$\begin{aligned} \begin{aligned} \frac{\partial H_{r}(t)}{\partial G_{r} (t)} = - \dfrac{e^{-\omega T} (\omega T)^{X_r}}{X_{r}!} M^{'}_{r} + \lambda _{r}(t)\beta _{m} G_{r}^{\beta _{m}-1}(t) \psi _{r} = 0 \end{aligned} \end{aligned}$$

(9)

$$\begin{aligned} \begin{aligned} \dot{\lambda }_{r}(t) = \rho \lambda _{r}(t) - \frac{\partial H_{r}(t)}{\partial D_{r}^{'} (t)} = (\rho + \delta _{r}) \lambda _{r}(t) - p_{r} + p_{s}^{'} \phi _{s}^{'} , \lambda _{r}(T) = 0 \end{aligned} \end{aligned}$$

(10)

When only one boundary condition is specified as $D_{r}^{'}(0) = D_{0r}^{'}$, the free-end condition is used as $\lambda _{r} = 0$ at $t = T$. The formulated differential equation Eq. 10 can lead us to the adjoint variable:

$$\begin{aligned} \lambda _{r}(t) = \frac{p_{r} - p_{s}^{'} \phi _{s}^{'}}{\rho + \delta _{r}} (1- e^{(\rho + \delta _{r})(t-T)}) \end{aligned}$$

(11)

Replacing Eq. 11 in Eq. 9 gives us the optimal gas price control path as follows:

$$\begin{aligned} G^*_{r}(t) = (\frac{M^{'}_{r} e^{-\omega T} (\omega T)^{X_r} (\rho + \delta _{r}) }{X_{r}! (p_{r} - p_{s}^{'} \phi _{s}^{'}) (1- e^{(\rho + \delta _{r})(t-T)}) \beta _{m} \psi _{r}})^{\frac{1}{\beta _{m}-1}} \end{aligned}$$

(12)

4.2 Cloud Provider as a Supplier

Cloud provider as a supplier has a different scenario. $CP_s$ observes the total demand of its own users, $D_{s}$, and the capacity preserved for the mining process to determine the remaining capacity $\phi _{s}^{'}$, to optimize its profit as follows:

$$\begin{aligned} CPP_{s}(R_{s}(t), D_{r}^{'}(t), t) = (p_{s} - \ \phi _{s} \ C_{s}) \ D_{s} + (p_{s}^{'} - \ \phi _{s}^{'} \ C^{'}_{s}) D_{r}^{'}(t) \nonumber \\ - \dfrac{e^{-\omega T} (\omega T)^{X_s}}{X_{s}!} M^{'}_{s} G_{s}(R_{s}(t)) +Rw_{s} \phi _{s}^{''} e^{-\dfrac{1}{\varGamma } M \eta }\nonumber \\ \end{aligned}$$

(13)

$G(R_{s}(t))$ denotes the gas cost that the suppliers pay to earn higher reputation for having prompt communication. Considering the time-dependent profit functions of $CP_s$ in Eq. 13, the objective function is the total discounted cloud provider’s payoff over the planning horizon $[0-T]$:

$$\begin{aligned} \text {maximize}&\quad \int _{0}^{T} e^{\rho t} \{ CPP_{s}(R_{s}(t), D_{r}^{'}(t), t) \} dt \nonumber \\ \text {subject to}&\quad \dot{D}_{r}^{'}(t) = \hat{\theta }_{r} {R_{s}(t)}^{\beta _{n}} - \delta _{s} D_{r}^{'}(t) \nonumber \\&\quad D_{r}^{'}(0) = D_{0r}^{'} \nonumber \\ \end{aligned}$$

(14)

The demand dynamics of $CP_s$ is defined based on the demand that it receives from $CP_r$ that evolves with its own reputation and decays at a rate $\delta _{s}$. By solving a corresponding Hamiltonian system of Eq. 14, similar to Eq. 8, the optimal reputation control path is obtained as follows:

$$\begin{aligned} R^*_{s}(t) = (\frac{M^{'}_{s} e^{-\omega T} (\omega T)^{X_s} G_{s} (\rho + \delta _{s}) }{X_{s}! (p_{s}^{'} -\phi _{s}^{'} \ C^{'}_{s}) (1- e^{(\rho + \delta _{s})(t-T)}) \beta _{n} \hat{\theta }_{r}})^{\frac{1}{\beta _{n}-1}} \end{aligned}$$

(15)

5 Implementation, Simulation and Discussion

We implemented the coopetitive Cloudchain prototype on Ethereum using Solidity (version 0.4.24), the script language on Ethereum, to test our proposed framework and the effect of gas price and reputation values on cloud providers revenues. This program is available open source in Github (See footnote 1). The program was written with the main concern of the minimum consumption of gas per each transaction and was tested using remix³, an online IDE for Solidity. The gas price unit is in gwei, which is $1\times 10^{-9}$ ether. Ethereum stores arbitrary data in smart contracts in two ways. The first option is to store the data as a variable in a smart contract. The cost of storing data in the contract storage is based on the number of SSTORE operations on the contract variable. The second option is to store arbitrary data as a log event. There are also memory variables such as contract arguments and defined memory variables, which are not stored permanently inside the contracts. Memory variables are disposed after the function execution is complete. In our implemented prototype, we used solidity structures and variables to store provider’s data and requests inside the contracts. Meanwhile, each transaction is logged with a summary using an event to make it easily accessible for the other providers (blockchain nodes) to track new transactions. Once a new transaction with a specific event (e.g. New Request) is created, other providers can call the contract to get more information and/or change contract stored data (e.g. to accept a new request). Calling a contract and retrieving data are expensive transactions, the stored data as events can provide enough information without any retrieval cost. The events are retrieved and filtered using the Web3.js platform to notify the providers on important changes (e.g. New registration, updates, deactivations, new requests, etc.) in Cloudchain. CCR and CCP contracts are deployed once, but CCC would be deployed every time a new request is registered.

Table 2. Provider’s estimated transactions and costs on Cloudchain based on the proposed scenarios

For the sake of representation, we assumed a small number of 5 cloud providers (Amazon, Microsoft, Rackspace, Alibaba cloud, and Century Link) using Cloudchain for a duration of 100 days to investigate their economic gain through the differential game. The scalability of our system for higher number of cloud providers is not questioned since the Ethereum platform is proven to be scalable. We simulated Rackspace, Alibaba and Century Link as cloud requesters who make 8, 17 and 15 requests of service, respectively. Meanwhile, Amazon accepts Rackspace and Century Links requests with a reputation threshold of 75, and Microsoft takes Alibaba’s orders, which were set for a minimum reputation of 85. Due to the limitation of Solidity in defining float numbers, we scaled the reputation values collected from Gartner to [0–100]. The on-demand cloud services’ prices are borrowed from the providers’ websites with an assumption of the secondary price of Amazon and Microsoft to be two times less for the Cloudchain members. The collected real-world data (e.g. reputation and price), simulated number of requests and supplies, as well as the simulated results of total gas consumption, gas price and transactions delays are shown in Table 2. Since there is no time-dependent profit maximization model similar to our proposal, not even in traditional centralized federations or related experiments to be compared to, only the results of our model are reported.

In our simulated scenario, three cloud providers of Amazon, Microsoft and Rackspace are supposed to be miners and collect their rewards. To make the simulation more realistic, we followed up all the contract transactions from registering in the Cloudchain up to confirmation of the contract completion, depositing the payment and assigning a reputation. Century Link and Alibaba are assumed to cancel their requests for few times after making the contract before acceptation. As Table 2 depicts, the obtained gas consumptions of cloud service requesters are much higher than those that answer these requests and supply these services. This is why Alibaba has the most and Microsoft the least gas consumption.

Fig. 2.

Gas prices of the three cloud service requesters

Fig. 3.

Microsoft’s optimal reputation with different values of ($0.1\le \hat{\theta }_{r}\le 0.9$)

The gas price of Amazon and Microsoft are considered as constant inputs and they are set to 15. This price guarantees a fast execution of transactions to avoid tarnishing their reputation and will not impose them huge cost due to their minimal gas required as the role of suppliers. To estimate the time delay for each transaction, we tested different prices in different time slots to obtain an approximate range of delay depending on the traffic of the Ethereum network.

Fig. 4.

Average of cloud providers’ profit and demands’ evolution in Nash Equilibrium

The obtained optimal gas prices for the three cloud requesters are shown in Fig. 2. Alibaba has to pay the minimal price, which is almost 11 gwei for the whole period of time. This cloud provider has the highest number of requests, so it is not profitable if it invests more money over gas. With this price, Alibaba has to pay almost $248.45, at the time of writing this paper. However, because of the cheap gas price, Alibaba has a delay of 27 to 5459 s for each transaction (refer to Table 2). Even though high traffic happens not very often, yet, it would be advisable to predict its demand in advance to avoid the delays that can cause user dissatisfaction. Century Link also has to pay cheap gas price, but not as cheap as Alibaba. It is reasonable since this cloud provider has less gas consumption, higher end-users’ prices and lower reputation. To win the users’ satisfaction proportional to its service’s price, Century Link has to increase the gas price sharply, to speed up the communication and avoid major delays. Based on the results, Rackspace has to pay the highest price for the gas among the cloud requesters. The main reason can be the highest end users’ price, the low amount of transactions and gas consumption. The participation in the mining process could also add up to its wealth to afford higher price and higher quality with minimum delays. It worth to note that even though the gas is costly for all cloud providers, it is a one-time cost for a permanent storage.

Figure 3 depicts Microsoft’s optimal reputation value during these 100 days as obtained in our experiment. It is worth mentioning that Amazon showed a similar pattern. To investigate the behavior of cloud requesters’ demand over these reputation values, we considered the demand rate $\hat{\theta }_{r}$ varying from 0.1 to 0.9. As the effectiveness of reputation over demands’ rate raises, the provider has to aim for a higher reputation at the beginning to earn the eligibility for more demands. However, these optimums do not follow the same trend. In the case of lower effectiveness, the provider has to increase the service quality and gas price leading to a higher reputation over time, but as effectiveness gets intense, the reputation starts to decline. This is where the provider has established its credibility at first and made the major profit halfway through the period, and the increase of reputation is not profitable anymore. This confirms that keeping a high reputation is costly and not always economically justified.

Figure 4 presents a comparative analysis of the average of profit and demands’ evolution for the Cloudchain members. The demands’ evolution $\dot{D}^{'}_r(t)$ for cloud service suppliers have noticed a higher spike. Yet, interestingly, cloud service requesters have received a higher profit from Cloudchain due to fulfilling their initial demand and selling to their own end-users. The cloud service requesters could obtain cheaper prices from the suppliers and sell at their own prices. However, it should be noted that they can face the risk of not fulfilling their commitments to the end-users if none of the suppliers have the required preserved capacity to rent out. Although it seems that Cloudchain benefits more the cloud requesters, yet it is not true. The main profit of cloud suppliers is from their own market and users, and they only rent the partial idle computing resources, which are not being used. As the number of cloud service requesters elevates, their share of profit from the outsourced demand and the mining rewards increases.

6 Conclusion

In this paper, we introduced a new distributed blockchain-based framework for cloud providers federation to overcome the limitations of conventional centralized federations. Due to the coopetitive environment of Cloudchain, and high expense of public smart contracts, we further designed and solved a differential game. This game modeled the best strategies of cloud providers to make a request with an optimal transaction cost and time, as well as, to optimize their reputation value to receive the requests from other providers. Cloudchain was implemented using Solidity over the Ethereum network and the differential game was simulated for a sample of five cloud providers during 100 days. The findings can be summarized from two perspectives of the cloud service requesters and suppliers. For cloud requesters with a high number of requests, spending high gas price is not economically appealing. With cheaper gas prices, they might face some delays in peak times, which needs to be predicted in advance. Although requesters incurred higher costs from Cloudchain, yet they gained a significantly high income by outsourcing some parts of their customers’ demands that could not be fulfilled by their own. The results showed that cloud suppliers have minimal gas consumption, which makes it more affordable for them to pay higher prices and enhance their communication and reputation. Though increasing the reputation was not always the best strategy for highly reputed cloud providers, a gradual increase is recommended when the requesters’ demand is not significantly impacted. The end-user’s service price is found to be a very decisive factor in deciding the level of quality and gas/reputation values for both of the cloud service requesters and suppliers.