randomly determined for each participant. The net-
work communication is optimized because the ran-
dom component does not send so many checksum re-
sults through the network. The proof of luck contains
a proof of work. If a branch is formed, the chain with
the greatest accumulated luck is used in the next step
(Milutinovic et al., 2016).
3 PROBLEM
We have already highlighted the problem of increased
energy consumption in the Bitcoin checksum calcula-
tions in the introduction. Although, Bitcoin mining
has its own specially designed data centers, there are
other cryptocurrencies that run in standard data cen-
ters. The energy consumption of datacenter industry
witnessed a gigantic growth in the last years. Statisti-
cal analysis suggests a total growth of roughly a hun-
dred percent between 2005 and 2010 with a steadily
increasing behaviour (Koomey, 2011). Clearly, the
associated CO2 emissions of datacentre’s operations
reported an immense growth and observed to be the
most accelerated growing carbon-footprint compared
to various IT-fields (Avgerinou et al., 2017). Accord-
ingly, the worldwide energy consumption and its as-
sociated carbon-footprint have triggered extreme anx-
iety on an international level. In the meantime, this
problem stands in the top agendas of many coun-
tries. For instance, the European Union has intro-
duced many new regulations in addition to some ini-
tiatives and research to reduce the proportion of data-
center’s operations of CO2 global emissions (Avgeri-
nou et al., 2017).
In this paper we address the enormous environ-
mental pollution caused by the high energy consump-
tion of Proof-of-work-cryptocurrencies and the sus-
tainable use of data centers.
The various concepts for changing the consensus
in section 2 have always been motivated by the so-
lution to the same problem. The computing time of
the proof of work should be reduced to regulate en-
ergy consumption. However, the approaches do not
really do justice to the claim, since only the puzzle
was simplified and the possible circle of authorized
persons for the checksum calculation was regulated.
The proof of work still has to be executed. Further-
more, in some concepts (e.g. proof of stake) partici-
pants are preferred, so that there is a risk of third party
creation.
We therefore continue to address the abolition of
the proof of work from the consensus mechanism
and the avoidance of preferential treatment of partici-
pants.
4 CONCEPT
We now present a consensus concept of a blockchain
technology that can be used to provide cloud comput-
ing instances in data center. As a starting point we
consider a peer-to-peer network in which transactions
should take place.
Participants. The participants of this blockchain
technology are primarily cloud providers, who always
keep the ledger of the blockchain available and can
provide cloud computing instances in their own data
center. If a subscriber does not fulfill the second con-
dition, he is only active in the network as an auditor of
the blockchain. Other participants initially take on the
role of the customer who commissions a cloud com-
puting instance.
Based on familiar blockchain concepts, all partic-
ipants are equipped with a unique ID and a key pair
for authorization.
Smart Contract. The provision of cloud comput-
ing instances by a provider to a customer is recorded
in a smart contract. This contract specifies the time
of availability, equipment and the amount due. The
amount due is transferred at the end of the contract
period or at defined intervals. The smart contract se-
cures the future receipt of the amount.
Availability is checked via a software component
running on the cloud computing instance. At short
intervals, the software component sends a signal to
the smart contract. If a user is active on the instance,
the software sends a proactive status. If the instance
is available, the status is transmitted as active, oth-
erwise as inactive. If an instance is inactive for too
long, defined rules (e.g. fines, invalidity of contract)
will apply.
Software Component. The software component con-
sists of a module that transmits the status and an ad-
ditional module that calculates the checksums of the
blockchain transactions. While a customer is using an
instance, the software sends a customer signed com-
bination of identifier (e.g. MAC address) and times-
tamp. This ensures that the user is really using the
instance. If the instance is in sleep mode, only a
provider signed variant can be sent. Otherwise, the
smart contract receives the message that the instance
is inactive. The second module of the software is de-
scribed in more detail in the next section.
Block Creation. A new block containing a set of
transactions can be created in a predefined time win-
dow (e.g. every 60 seconds). If a time limit is
reached, a time-based random value is formed by the
blockchain. However, this value can only be read
from a current blockchain, i.e. the signals of all run-
ning Smart Contracts must be current. This random
Proof of Provision: Improving Blockchain Technology by Cloud Computing
525