Knirsch et al.

EURASIP Journal on Information Security

https://doi.org/10.1186/s13635-019-0085-3
(2019) 2019:2
EURASIP Journal on
Information Security

R ES EA R CH Open Access

Implementing a blockchain from

scratch: why, how, and what we learned
Fabian Knirsch, Andreas Unterweger* and Dominik Engel

Abstract
Blockchains are proposed for many application domains apart from financial transactions. While there are generic
blockchains that can be molded for specific use cases, they often lack a lightweight and easy-to-customize
implementation. In this paper, we introduce the core concepts of blockchain technology and investigate a real-world
use case from the energy domain, where customers trade portions of their photovoltaic power plant via a blockchain.
This does not only involve blockchain technology, but also requires user interaction. Therefore, a fully custom, private,
and permissioned blockchain is implemented from scratch. We evaluate and motivate the need for blockchain
technology within this use case, as well as the desired properties of the system. We then describe the implementation
and the insights from our implementation in detail, serving as a guide for others and to show potential opportunities
and pitfalls when implementing a blockchain from scratch.
Keywords: Blockchain, Private chain, Implementation, Practical insights

1 Introduction when they need less energy themselves, e.g., when they
After being originally proposed as a public, decentral- are traveling.
ized and trust-less ledger for digital currencies, blockchain For this use case, we evaluate the need for blockchain
technology has gained widespread adoption in many fields technology and the applicability of different types of con-
[1–3]. Recently, utilities and network operators in the sensus algorithms and permissions/visibilities. A num-
energy domain have begun focusing on using the novel ber of existing implementations, such as MultiChain [8],
possibilities provided by blockchain technology for realiz- OpenChain2 , Ethereum [9], and a Bitcoin fork [1], were
ing such decentralized, trust-less applications that do not initially taken into consideration. However, due to scal-
rely on a single trusted third party. This includes protocols ability issues on the desired hardware and for achieving
for tariff matching [4, 5] and energy trading [6, 7]. Util- a lightweight and simple solution, a blockchain has been
ity providers and network operators aim at exploring the implemented from scratch. Furthermore, this use case
properties and benefits, as well as the shortcomings of this does not only involve blockchain technology, but also
technology for their respective use cases1 . requires user interaction and customer acceptance, as well
In this paper, a novel and previously unsolved real- as the processing of privacy-sensitive data, all of which
world use case of two major Austrian utility com- adds an additional layer of complexity.
panies is investigated: National legislature, which also This paper describes the real-world use case, the design,
applies to other European countries, requires that for and the final implementation as well as the outcomes in
a shared ownership of small photovoltaic power plants, detail. It aims at serving as a guide for others by showing
such as those commonly found in multi-party rental potential opportunities and pitfalls when implementing a
apartments, customers can exchange portions of their blockchain for a particular field of application other than
energy production with neighbors. This allows customers financial transactions.
to save money by shifting portions to other consumers The rest of the paper is structured as follows: In
Section 2, we give an introduction to blockchain tech-
*Correspondence: [email protected] nology. In Section 3, we describe the underlying use case
Salzburg University of Applied Sciences, Center for Secure Energy Informatics, and its legal requirements in detail, including related
Urstein Süd 1, 5412 Puch bei Hallein, Austria work on the subject. We further motivate the use of

© The Author(s). 2019 Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0
International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and
reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the
Creative Commons license, and indicate if changes were made.
Knirsch et al. EURASIP Journal on Information Security (2019) 2019:2 Page 2 of 14

blockchain technology for the proposed application. In have agreed on this state, the information is stored
Section 4, we discuss existing blockchain implementations permanently and immutably. Changing the
and their drawbacks in our use case and continue to moti- information contained in a particular block would
vate and describe our custom implementation in detail require to also change all the following blocks up to
in Section 5. Finally, in Section 6, we discuss the lessons the last block, which is considered to be infeasible
learned from our implementation before concluding the [1, 11].
paper. • Scalability : The block rate, comprised of the
throughput and propagation time of information,
2 Blockchain technology overview depends on the consensus algorithm and the number
This section provides an overview of blockchain technol- of participants. This can be a limiting factor for
ogy. The scope of this section is to introduce and present a applications that require high throughput [10]. Since
generic view of the technology and to go beyond its well- all nodes hold a copy of the blockchain, scalability
known use for financial transactions. First, blockchain issues also arise in terms of the total amount of data
technology is introduced as a decentralized, trustless, and that can be stored. Furthermore, in order to check
immutable database. It is further discussed how a consen- the integrity of the blockchain, a new node needs to
sus is achieved within such a distributed network of nodes, download a copy and validate the integrity of the
and the most common consensus algorithm is briefly dis- entire chain. Note that more recent proposals for
cussed. Finally, the drawbacks of blockchain technology BFT-based consensus algorithms improved on this,
are shown. e.g., [12].
• Limited privacy : All data in the blockchain is publicly
2.1 Blockchain technology visible to all participants. Private or permissioned
Blockchain technology can be described as a trustless and blockchains limit the range of disclosure. However,
fully decentralized peer-to-peer data storage that is spread they do not cryptographically protect the data. In
over all participants that are often referred to as nodes. order to achieve privacy, additional layers, such as
The blockchain is designed to hold immutable informa- zero-knowledge proofs [13] or a commitment
tion once data is committed to the chain, and it is there- scheme are required [14].
fore a decentralized, distributed, and immutable database
in which data is logically structured as a sequence of In the originally proposed Bitcoin protocol from [1],
smaller chunks (blocks). Each block Bi>0 is immutably the blockchain is used to keep track of coins, i.e., a pub-
connected to a single preceding block Bi−1 through a lic list of financial transactions and how many coins are
cryptographic hash function H(Bi−1 ). Changes to Bi−1 owned by each participant. For this purpose, each trans-
would yield an invalid hash in Bi and all following blocks. action contains sender and receiver information, as well as
The very first block B0 is called the genesis block and is the number of coins to be transferred. A number of such
the only block without a predecessor. In order to assure transactions – once confirmed by the peers – become a
the integrity of a block and the data contained in it, new block. Such a block also includes the hash of the pre-
respectively, the block is usually digitally signed. vious block and is appended to the chain. The transactions
For some applications, it is more useful to view a are therefore permanently linked to the series of previous
blockchain as a state machine [9]. Each block contains a transactions.
new state with the very last block representing the current This list of chained blocks is public, kept by all mem-
state. Given the list of blocks and the data in this block, bers in the network, and can be verified by all participants
there is a unique and immutable order of transitions that by checking the integrity of the new block and the cor-
lead to the current state. rect calculation of the hash. Participants in the network
The main features of blockchain technology can be are identified by a private-public key pair, which is often
summarized as follows: referred to as the ID or address.
A blockchain can be generalized to store arbitrary data.
• Decentralization: Instead of relying on a single In its simplest form, a block Bi consists of the following
trusted entity, trust is spread across multiple or all data:
participants, depending on the agreed-upon
consensus algorithm [10]. This does not only mean • Hash of previous block hi : A cryptographic hash of the
that multiple copies of a data item are stored on all previous block, i.e., hi := H(Bi−1 ), as described above.
nodes, but also that the integrity of the data is • Payload pi : Arbitrary data that is stored in this block.
governed by many decentralized parties. In many practical applications, this data has to follow
• Immutability : Once data is committed to the a predefined pattern (e.g., transactions in Bitcoin or
blockchain and a sufficient number of participants operations in Ethereum).
Knirsch et al. EURASIP Journal on Information Security (2019) 2019:2 Page 3 of 14

• Signature si : A digital signature of the block data, i.e., coin twice, also referred to as the double-spending attack.
si = σsk (hi |pi ), signed with the secret key sk of the In order to create a valid branch, a malicious subset of
creator of the block. This signature can be verified by nodes must control at least 50% of the computing power
the public key pk. in the network [1]. However, it is shown in [11] that
there is a theoretical threshold of only 33% for specific
In public blockchains, all participants can create and attacks. The 50% threshold is improved by [19]. There-
append new blocks. Once a new block is created and fore, a blockchain does not require a single trusted party,
successfully linked to the chain, it is broadcasted to the but instead is trustless if at least half of the computing
network. If other participants receive such a new block power used for creating and verifying blocks is spent by
and consider it to be valid (i.e., by verifying the signature, honest peers.
checking the hash, and checking the validity of the pay- Furthermore, peers and transactions are pseudonymous
load), they extend their local copy of the chain with the in the sense that the sender and the receiver are only
newly created block and eventually broadcast the block to identified by their addresses and that a new pair of keys
other participants. If a block is invalid, it is discarded and (and therefore a new address) can be created for every
does not become part of the chain. transaction. Further advances in blockchain technology
Blockchains therefore boil down to the question of are described in Section 4.
how to achieve consensus in a distributed network with
potentially faulty participants. This is referred to as 2.2 Drawbacks
Byzantine Fault Tolerance (BFT), originally introduced in Despite the advantages of decentralization, trustlessness,
[15], together with optimal algorithms for a variable num- and immutability, there are two major issues with cur-
ber of adversaries, up to one third of the participants. This rent blockchain technology—scalability and power con-
has been further investigated for asynchronous networks, sumption [10]. Scalability refers to the time needed for
such as blockchains, by many others, e.g., [11, 16]. It must propagating, processing, and validating transactions. The
be noted, however, that BFT algorithms for asynchronous higher the number of nodes is, the more limiting network
networks are only practical up to about 1000 participants bandwidth, overall storage space, and power consumption
[17] due to the incurred overhead of the cryptographic become.
algorithms. The current power consumption (as of May 2018) of
In [1], a practical solution for achieving consensus in the Bitcoin network is approximately 70 TWh per year3 .
asynchronous networks of millions of participants and This is mainly caused by the approximately 35 exahashes
under the presence of Sybil attacks, where one attacker is per second (3.5 × 1019 H/s) which need to be computed
in control of multiple nodes, is presented. Bitcoin requires for the PoW. Thus, for energy-sensitive use cases, using
synchrony among nodes to achieve consensus and uses Bitcoin in its current state is not a sustainable approach.
the Proof-of-Work (PoW) algorithm. In order to consider
a new block to be valid, the participant who initially pro- 3 Use case description
vides this block has to prove that a significant amount In this section, we describe the use case for which we
of work has been spent for creating this block. The node implemented our blockchain. We first describe the legal
therefore varies the input of a cryptographic hash func- requirements which make a (technical) implementation
tion in order to get an output that has a certain pattern, of the use case necessary in the first place and provide
e.g., a certain number of leading zeros. This becomes a high-level description of the use case with all actors.
a computationally expensive problem by exploiting the Finally, we outline the reasons why a blockchain-based
preimage resistance of cryptographic hash functions [18]. implementation is sensible and discuss related work.
Given such a hash function and its output h = H(m), it
is practically infeasible to find m for a given h. In order to 3.1 Legal requirements
incentivize nodes to verify transactions and append new Solar energy plants allow generating electricity at cus-
blocks (and thus spend time computing time and energy), tomer premises. This additional energy can be consumed
the effort is rewarded in the form of newly created coins, by the customer directly and thus reduces the household’s
referred to as mining reward. The process of creating new total energy consumption. It also avoids feeding power
blocks is therefore also referred to as mining. into the public grid. If the amount of electricity generated
In practice, branches may occur, where one or more exceeds the amount of electricity consumed, the excess
nodes create new blocks at the same time. Commonly, energy has to be stored in (typically expensive) batteries
the branch that contains more work, i.e., the longer or fed into the public grid, the reimbursements for which
branch, is considered to be the valid one. PoW there- are often very small [20].
fore prevents malicious nodes from forging data or—in This problem exacerbates for multi-party homes with
the case of crypto currencies—from spending the same shared solar energy plants, where the excess energy
Knirsch et al. EURASIP Journal on Information Security (2019) 2019:2 Page 4 of 14

of one party could be “transferred” to another instead 3.3 Use of blockchain technology
of feeding into the public grid [21], thereby reduc- The reasons for building this use case atop a blockchain
ing the energy costs for the receiving party. How- are manifold. First, a global state needs to be stored
ever, various legal aspects and technicalities have made that all parties agree on. Second, customers do not fully
such setups practically impossible [22] until recently trust each other and malicious customers may attempt
[21, 23], despite the large number of multi-party apart- to double-spend their portions in order to profit. Third,
ment complexes and potential roof areas in urban there is no single trusted third party due to the number
regions [23]. of stakeholders involved. Therefore, a private and permis-
In 2017, legislation to enable energy “transfers” between sioned blockchain is implemented. In [30], the use case
parties of a shared photovolatic power plant has been requirements for such a blockchain are defined as follows:
introduced in both Austria [24] and Germany [25]. In par- • Need for storing a state : For the desired use case, a
ticular, § 16a ElWOG 2010 [26] as of 2017 [24, 27] as well global state representing the portions for each
as § 21, 21b and 21c EEG 2017 [25, 28, 29] require that customer at each time slot needs to be stored.
the energy provider considers “transferred” portions of • Dealing with multiple writers : Customers can
electricity generation for each customer at 15-min gran- transfer portions at any time, simultaneously.
ularity. More precisely, the participants agree on a distri- • Always-online trusted third party cannot be used :
bution key for the energy generated by the shared solar Since each customer in the EU can choose their
power plant for each 15-min time slot of each day, which energy provider individually [31], no utility provider
in turn reduces each participant’s energy consumption can be considered trusted by all participants in the
accordingly. general case. Furthermore, customers in different
locations do not share the same network operator.
3.2 Conceptual overview Thus, no trusted third party can be appointed.
For the implemented use case, two categories of actors • All writers are known : Initial portions of photovoltaic
exist—utility providers and customers. A group of cus- power are assigned to customers. All customers
tomers is assigned to a shared photovoltaic power plant. trading in the network are therefore known and need
Usually, this power plant is installed at a multi-party apart- to be verified for billing.
ment building and each customer receives a certain per- • Not all writers are trusted : Malicious users are
centage of the generated power. Customers further receive assumed to maximize their shares, i.e., try to
power from the grid and are therefore assigned to a utility double-spend portions.
provider. • Public verifiability is not required : The distribution of
For this work, it is assumed that participants who shares only needs to be verified by other participants
invested in a shared solar energy plant agree on a default within the network and the energy providers. The
distribution for their photovoltaic power, e.g., customer latter need to observe valid states, i.e., no more than
A, 20%; customer B, 20%; and customer C, 60%. For each 100% of the portions are assigned in total.
15-min interval, customers can then transfer their con-
tributions independently and as desired, e.g., customer A In our private and permissioned blockchain, a consor-
transfers the full 20% to customer B for the next 16 time tium of energy providers and network operators assigns
slots (i.e., 4 h). permissions to new customers. These permissions allow
If customers do not shift their portions, the default customers to interact, i.e., read from and write to, the
distribution applies. After each day or 96 time slots4 , blockchain, similar to [32]. A revocation process ensures
customers are billed based on their energy consumption that inactive users no longer participate in the blockchain.
from the grid, minus the power generation relative to the
portions they were holding in each time slot. Note that 3.4 Related work
customers cannot transfer more portions than they hold, Due to the novelty of the legislature regulating the real-
but they can transfer portions they received. For instance, ization of our use case, related work is sparse. Apart
if, for one time slot, customer A transfers 20% to customer from literature on energy trading in general, as out-
B (now holding 40%), customer B can— for this time slot— lined below, we are not aware of any publications which
transfer this portion entirely to customer C (then holding specifically describe blockchain-based implementations
100%). to record transferred photovoltaic energy portions as in
In summary, customers agree on a distribution of shares our use case at the time of writing (May 2018).
for each 15-min time slot. This information is forwarded Blockchain-based solutions to trade energy between
to the utility provider that individually bills each customer households have been proposed. In [33], a Bitcoin-based
based on their energy demand and supply for each time application is described which allows for energy trad-
slot. ing, but comes at the cost of requiring micropayments
Knirsch et al. EURASIP Journal on Information Security (2019) 2019:2 Page 5 of 14

for transactions as well as the general limitations of A private Bitcoin network would be more suitable for
the Bitcoin network such as transaction speed. Even our case—the meta data size limits as well as the through-
though they simulate solar energy production and sup- put could be increased. This would also allow zero-cost
port partial transfer of energy, the transaction costs of transactions. However, the consensus algorithm of Bitcoin
their protocol are impractically high for a use case such only deals with double-spending of Bitcoins, not portions
as ours. of photovoltaic power. Modifying this algorithm would be
In [34, 35], a custom cryptocurrency for local energy possible, but the design of Bitcoin does not fit the use case
trading is proposed which changes its monetary value well. For example, new Bitcoins are generated with new
based on demand and supply. It allows “reserving” a cer- blocks, whereas, for our use case, balances for each time
tain amount of power for consumption at a future point slot must be available regardless of the block rate.
in time at the current market value. Our use case does not Thus, we deemed the modifications to Bitcoin and its
require this feature since the prices are set by the energy most popular implementation to be infeasible. The effort
provider and individual customers can only transfer por- to modify the existing source could would very likely
tions, but not negotiate prices. Furthermore, the proposal exceed the effort of implementing a blockchain from
of a custom cryptocurrency by itself is not sufficient to scratch. The same is true for ByzCoin [39], which uses a
implement trading in practice, as opposed to our real- BFT-based consensus algorithm, but is otherwise compa-
world implementation. Similarly, the concept presented rable in design.
in [22] proposes a private blockchain to handle local
energy trading, but rather focuses on trading aspects and 4.2 Ethereum
the market setup instead of presenting insights from an Ethereum [9] allows implementing smart contracts in var-
implementation. ious programming languages, e.g., Solidity6 . Such smart
Other blockchain-based approaches include [6, 7, 36]. contracts are capable of representing practically arbitrar-
While [36] focuses on machine-to-machine trading of ily complex transactions. These are not limited to financial
energy in the context of the Chemical industry, [6] and transactions as in Bitcoin, but allow for representing states
[7] trade actual monetary units similar to [33]. In con- and state changes as required by our use case.
trast, in our work, the blockchain is only used to represent Despite Ethereum’s flexibility, previous research found
portions, i.e., percentages of ownership for photovoltaic that even smart contracts of modest complexity are rel-
energy production for each time slot. Billing data is there- atively expensive [14]. Furthermore, frequent changes
fore never released publicly, but processed within the in the cost structure of executed operations as well as
utility’s premises—the individual customers receive their changes in the exchange rate to Euros7 make costs unpre-
receipt along with the regular power bill. dictable [40, 41].
Further related work on local energy trading with- Even though the cost issue could be eliminated by using
out blockchains is presented, e.g., in [37, 38]. They a private blockchain, the complexity of Ethereum exceeds
assume trading processes via agents, but require a stock- the requirements for our use case by far. Whenever a
market-like exchange. Such a centralized trusted party (at value needs to be stored in a smart contract, a modified
neighborhood- or provider-level) is not required in our Merkle Patricia Trie is updated, which is relatively time-
use case due to the security guarantees of blockchains. consuming, as has been shown in [42]. In addition, it has
been shown that this leads to a slow speed of execution
4 Available implementations when the volume of data increases, which is detrimental
For implementing the private and permissioned for our use case, especially from the users’ perspective.
blockchain, a number of available implementations were
considered. The following sections describe the relevant 4.3 MultiChain
implementations and our reasons for not choosing them. MultiChain [8] is a private and permissioned blockchain
Table 1 summarizes the properties of these implemen- implementation. Like Bitcoin, it is primarily focused on
tations, as well as of ours at the time of selecting basis financial transactions and thus the consensus algorithm
implementations (September 2017). would have to be modified significantly. Although this is
likely easier than it is for Bitcoin, MultiChain’s currently
4.1 Bitcoin supported platforms are a major limitation for our use
Bitcoin [1] and its client Bitcoin Core5 are designed to case.
handle financial transactions. Even though it is possible to At the time of writing (May 2018), MultiChain is only
include small amounts of meta data in each block, the lim- supported on 64-bit systems and has several related soft-
ited available space as well as the low throughput and high ware dependencies8 . Furthermore, the current documen-
delay of the Bitcoin network make it unsuitable for storing tation indicates that only x86-64 CPU architectures are
any significant amount of meta data [4]. supported explicitly, which excludes low-power and low-
Knirsch et al. EURASIP Journal on Information Security (2019) 2019:2 Page 6 of 14

Table 1 Comparison of available implementations and their properties at the time of selecting basis implementations (September 2017)
and our work for comparison
Name Consensus Permissioned Limitation
Bitcoin PoW – Extent of modifications infeasible
Ethereum PoW – Complexity exceeds requirements
√
MultiChain PoW Limited to high power consumption platforms
√
OpenChain PoA PoA algorithm not suitable for use case
√
Hyperledger Sawtooth Dynamic Not mature at time of evaluation
√
Hyperledger Fabric Dynamic Known security flaws
HAWK PoW – Implementation not available
√
Corda PoA PoA algorithm not suitable for use case
√
Tendermint BFT Not available at time of evaluation
Stellar BFT – Not mature at time of evaluation
√
EOS BFT Not mature at time of evaluation
NEO BFT – Complexity exceeds requirements
OmniLedger BFT – Not available at time of evaluation
ByzCoin BFT – Extent of modifications infeasible
√
This work PoW∗ Requires tamper-proof hardware†
∗ See Section 6. † This is a requirement for electricity meters in the energy domain; see Section 5

costs hardware such as the Raspberry Pi, which is based 4.5 Other implementations
on ARM. Hyperledger16 allows operating private blockchains.
Even though it is possible to emulate x86-64 instruc- However, at the time of selecting implementations
tions on a Raspberry Pi, the possibilities are limited and (September 2017), Hyperledger Sawtooth17 had not yet
the overhead is significant. One of the most prominent reached version 1.0 and uses a storage structure similar
options for emulation, QEMU 9 , offers x86 support, but to the one of Ethereum. As described in the Section 4.2,
only limited x86-64 support10 . Using an x86-64 platform this structure is not suitable for our use case due
is not an option due to the price—Up Squared11 , for exam- to processing time. Hyperledger Fabric has not been
ple, which is one of the most similar to the Raspberry chosen since it is insecure in case single nodes act
Pi, costs about six times as much12 with a CPU power maliciously [43].
consumption that is more than ten times as high13,14 . HAWK [44] is a privacy-preserving blockchain. How-
As power consumption and price are main criteria in ever, at the time of writing (May 2018), no implementation
our use case, we use Raspberry Pis without the overhead is available18 .
of simulating x86-64 architecture on it. Thus, we cannot In addition, there are several blockchain implemen-
use MultiChain to base our implementation on. tations that use BFT as a consensus algorithm, e.g.,
Tendermint19 , Stellar [45], EOS20 and OmniLedger [46].
4.4 OpenChain However, at the time of selecting implementations
OpenChain15 is a private blockchain designed to be (September 2017), the aforementioned solutions were
efficient in terms of energy consumption, network com- either not available (Tendermint, OmniLedger) or had not
munication, and block rate. It is therefore built on a yet released a stable version (Stellar and EOS). In contrast,
client-server model rather than a peer-to-peer network the BFT-based NEO blockchain21 can be considered sta-
and uses proof of authority instead of proof of work as a ble enough, but its complexity, which allows to execute
consensus algorithm. Since the objective of this work is to smart contracts similar to Ethereum, exhibits the same
build a decentralized and trust-less model, a centralized issues as the latter (see above).
approach such as implemented by the proof of authority Due to the specific requirements of our use case and in
consensus algorithm in OpenChain cannot be used. Nom- order to get insights into the full cycle of blockchain devel-
inating a designated authority that validates transactions opment and implementation, we decided to build our own
would contradict the desired security and trust proper- custom blockchain tailored to the particular legal require-
ties. The same holds for all blockchains which use Proof ments and needs for sharing percentages of solar power
of Authority (PoA) to achieve consensus, e.g., Corda [32]. plants.
Knirsch et al. EURASIP Journal on Information Security (2019) 2019:2 Page 7 of 14

5 Implementation This information is also fed back to each user through the
In this section, we describe our implementation. First, app.
we give an overview of our system. Second, we go into The following sections describe the design of the nodes
detail for each of the three core components—the nodes, and the network. While the interface of the blockchain is
the clearing server, and the smartphone app. Finally, we described, the details of both the clearing server and the
discuss our network setup which guarantees that only app are not within the scope of this paper. Thus, they are
qualified participants can actually interact with the rest of only described briefly.
the network.
The implemented solution is currently in use in two 5.2 Nodes
locations operated by different energy providers and net- The nodes are implemented in Java 8 and designed to run
work operators—the Austrian Smart Grid Model region on Raspberry Pi 2 Model B. This hardware was chosen
Köstendorf in Salzburg22 and Böheimkirchen in Lower due to its general availability, ease of use, and little energy
Austria23 . consumption, which closely resembles the hardware capa-
bilities of a smart meter [47]. The device will be sealed and
5.1 Overview installed in the customer premises, as is legally required
Figure 1 shows our system and its main components. Each for electricity meters [48]. For the prototypical implemen-
participant has a node installed in their home which runs tation of this use case, there are no specific performance
the blockchain node software as well as a portable app requirements, but cost and proximity to legal require-
which allows sending commands to the node, in particu- ments is of the essence. Given the relatively low retail
lar to send and receive portions of solar energy. All nodes prices24 and the availability of well-tested software25 , the
are interconnected via the Internet, albeit within a vir- Raspberry Pi is a reasonable choice as a platform.
tual private network (VPN), so that they can communicate Figure 2 illustrates the fundamental architecture of our
with one another despite not using public IP addresses. At node implementation. The internal state of a node is rep-
each utility’s premises, there is a clearing server installed. resented by two main data structures—a tree and a state
It is connected to a node listening on the blockchain and table. The tree stores a representation of the blockchain as
reading the portions of the utility’s customers in order to currently seen by the node, and the state table is a tabu-
calculate the net energy consumption of each participant. lar view of time slots and the corresponding portions for
each customer. The latter is extracted from incoming valid
transactions. On startup, the node reads the last persisted
state from disk and initializes the internal tree data struc-
ture, which represents the blockchain, as well as the state
table and connected auxiliary data structures. After that,
it starts the watchdog for the server threads to listen for
incoming messages from other known participants.
It also starts the mining thread which processes uncon-
firmed transactions and combines them to blocks which
are appended to the tree data structure. The list of uncon-
firmed transactions as well as other internal auxiliary data
structures is not depicted in Fig. 2 for clarity.
The mining thread is an infinite loop that waits for
unconfirmed transactions, checks their integrity and
validity, and then creates a new block. A block is con-
sidered valid if the numeric interpretation of its crypto-
graphic hash (SHA-256) is below a predefined threshold.
This is a slightly adapted version of the proof of work con-
sensus algorithm proposed in [1]. In our use case, every
Fig. 1 Overview of the setup, including nodes, the clearing server, the node is a sealed hardware device provided by the network
app, and a conceptual view of the blockchain. Each customer operator upon registration in the network. In this real-
possesses an app that is connected to a node (for sending new
transactions and receiving confirmations) and to the clearing server
ization of the PoW, every node has the same hash rate.
(for billing). New transactions (denoted as Tx) reside in a pool of Upgrading to more powerful mining devices is not pos-
unconfirmed transactions until they are mined by a node and sible, which makes the 51% attack hard, since a collusion
appended to the blockchain. The clearing server retrieves data from with half of the network is unlikely in practice.
the blockchain and sends billing information to the customers’ When mining succeeds, the mined block is distributed
smartphone apps
to other known nodes through client threads. Similar to
Knirsch et al. EURASIP Journal on Information Security (2019) 2019:2 Page 8 of 14

Fig. 2 Program overview: The mining thread as well as up to n server threads and up to n client threads operate on the core tree data structure
representing the blockchain and the state table representing the assignments of portions. The state of the data structure as well as auxiliary
representations like time-slot-accurate portion assignments are persisted to disk. Server and client threads include watchdogs to detect and
potentially resume lost connections to other nodes

the server threads, there is one thread per peer, which 2 If the longest chain has changed, find the first
avoids delays due to permanent or temporary unreacha- common parent node for the branch of the previous
bility of other nodes. Watchdogs make sure that connec- longest chain and the current longest chain;
tion timeouts or remote failures lead to a re-initialization otherwise proceed with step 5.
of the corresponding connection. Note that there is no 3 Temporarily revert all transactions (i.e., remove them
mining reward as each node’s incentive to spend resources from the state table) from the previous branch up to
is to operate a trustless network without a centralized the common ancestor (parent) node.
party such as the energy provider. 4 Process all transactions from the current longest
The central tree data structure representing the branch starting from the common ancestor node.
blockchain is read from and written to by all threads 5 If a single transaction in the newly added block is
concurrently. This requires the use of concurrent pro- invalid (e.g., due to double spending or unknown
gramming paradigms [49], which are simplified by Java recipients), the whole process is reverted and the new
8’s concurrent data structures for the auxiliary lists and block is discarded.
hash maps as well as atomic primitive types like coun-
ters26 . Under the absence of a concurrent tree class, an After a block has been appended successfully (or dis-
append-only blockchain is implemented as a custom tree carded in case of an invalid block), the longest chain and
data structure. The state of the tree is persisted using the state table represent the current state of the system,
Java’s serialization API27 , and the state table is stored in an i.e., all portions of all participants for all possible time
SQLite28 database. Keeping a persistent tree reduces run- slots. For convenience, this information can be queried by
time memory usage by having only a small portion of the others, e.g., the smartphone app and the clearing server
tree in the internal memory and by loading branches and through the node’s API.
blocks from the disk only if needed.
In order to achieve a consensus with all nodes, blocks 5.3 Clearing server
and transactions need to be valid before actually being Billing is one off-chain by a clearing server. One instance
stored in the tree. Both incoming blocks from other nodes of this server is operated by each utility provider. In our
and blocks for mining undergo a conformity check before use case, there are currently two clearing servers active.
being appended and broadcasted, respectively. This is a Note that, while the clearing server is an essential com-
two-stage check for (i) block integrity and (ii) transaction ponent for this use case, it is not required for running
validity. For checking the block integrity, the signature of the blockchain itself. It guarantees that the billing pro-
the block is checked and the hash of the block is recom- cess of each utility is handled off-chain and by each utility
puted. Then it is verified whether the block hash satisfies individually.
the currently active difficulty level and whether the block To feed the billing process, the clearing server uses the
is appendable to the current tree. Checking the trans- node’s API to request the currently known distribution of
action validity is a more complex process that works as portions. The portions held by each customer for each
follows: time slot are then used for billing. Therefore, the cus-
tomers’ energy consumption and energy production (as
1 Append the block temporarily to the tree and check read from the smart meters) is mapped to their respective
whether this block changes the longest chain. portions. The resulting value in kWh and monetary units
Knirsch et al. EURASIP Journal on Information Security (2019) 2019:2 Page 9 of 14

is displayed to the customer in the app. The details of the The communication link between the clearing server
mapping, the meter readings, and the internal billing are and the app uses out-of-the-box HTTPS with authentica-
out of scope for this paper. tion and encryption. All components of our system—the
nodes, the clearing servers, and the apps–communicate
5.4 Smartphone App over a virtual private network (VPN). Since the nodes
For user interaction, a smart phone app is provided to the are placed on customer premises, where unchanging pub-
customers. The app focuses on a high degree of usability lic IP addresses are not guaranteed and network address
and on being an abstraction layer between the under- translation (NAT) is common, the VPN simplifies com-
lying complexity of the blockchain and the high-level munication on the network layer.
customer interaction. The app is connected to a node
and the clearing server of the customer’s utility provider. 6 Outcomes
The connection to the node is used for sending new In this section, we outline what we have learned from
transactions to the network and for receiving information implementing our own blockchain as described in the pre-
about incoming portions. The app therefore requests a vious section. We focus on the main take-aways which
list of blocks from the longest chain and filters the con- are noteworthy due to their unexpectedness and/or their
tained transactions for those related to the respective cus- value for others who plan on implementing their own
tomer. These transactions are visualized so that the cus- blockchain.
tomers can see for each point in time how many portions
they hold. 6.1 Scalability can be improved with BFT
After the real-world testing of the implemented
5.5 Network setup blockchain had started in June 2018, we learned that there
Nodes communicate with each other, the app and the is a more viable alternative to the implemented PoW
clearing server over TCP/IP and XML messages on the algorithm for a small number of users. Since software in
application layer. Using a text-based protocol allows for the energy domain that runs in the customers’ premises
easy debugging and an illustration of messages which is is required to be certified and usually operates on sealed
suitable also for non-technical people. This is an impor- hardware, an in-place upgrade would have been neither
tant aspect of this work, where the abilities of blockchain feasible nor practical.
technology are observed in a practical setting. Due to the private and permissioned nature of the
The node’s API defines four main types of messages: blockchain, in the implementation of the nodes (see
(i) Block, (ii) Transaction, (iii) Utility Transaction, and Section 5), mining is used to prevent Sybil attacks, which
(iv) Status. Block messages can either propagate a newly would give the attacker an unfair advantage. In addition
mined block or be the response of a block request to the permissioned nature, in our setup, all devices have
from another node. Transaction messages are sent by the same computing power and need to be tamper-proof.
the smartphone app and initiate a new shift of por- Thus, such an attack is not feasible. Consequently and due
tions. Utility transaction messages are sent by dedicated to the small number of nodes, PoW is not needed and
clients, e.g., the clearing servers of each utility that have could be replaced by more lightweight approaches, such
the permission to setup and create new photovoltaic as BFT consensus algorithms.
power plants and assign customers and default distribu- BFT consensus algorithms are a better choice for net-
tions to these power plants. Status messages are used works with about 1000 nodes or less [17, 39]. In our test
for displaying the node status to customers as well as case, there are less than 1000 users and thus less than 1000
for debugging purposes. Internally, the XML for blocks nodes. However, since our implementation is designed
and transactions is serialized from and deserialized to as a prototype for a more general solution, houses with
Java objects. significantly more than 1000 parties must be considered.
All communication links between nodes as well as For example, the Autobahnüberbauung Schlangenbader
between the node and the app are secured with TLS v1.2 Straße in Berlin, Germany, has more than 2000 apart-
using a hybrid encryption scheme based on Elliptic Curve ments 29 , where BFT would likely be infeasible.
Diffie-Hellman key exchange and AES-256 with CBC [50]. After releasing our implementation for real-world test-
In order to reduce the overhead for communication, there ing in June 2018, there appeared new works that resolve
is no authentication on the TLS layer. However, this does the aforementioned limitations of BFT and provide better
not weaken the security since all messages (most impor- scalability through sharding, e.g., [46].
tantly blocks and transactions) are signed by their respec-
tive sender. In a permissioned blockchain, such as ours, 6.2 TLS handshakes introduce significant delays
the public keys of all nodes are known to one another and In our first prototype, we used unencrypted connections
messages with invalid signatures are discarded. to test the basic communication functionality of our net-
Knirsch et al. EURASIP Journal on Information Security (2019) 2019:2 Page 10 of 14

work. When we switched to encrypted connections with 6.3 AES-256 is disabled in Java 8 by default
TLS [51], we noticed significant delays despite the small Due to export restrictions30 , Java 8 imposes a limit on the
amount of (test) data to be encrypted. The issue practi- cryptographic key sizes by default. For example, AES is
cally disappeared when the connections were kept open. limited to 128 bits31 , meaning that AES-256 is not avail-
This indicated that the initial connection between two able. To work around this limitation, strong cryptography
nodes, i.e., the TLS handshake, was taking longer than has to be enabled explicitly.
expected. The official solution proposed by Oracle is to install
We decided to measure this for our setup, i.e., two the Java Cryptography Extension (JCE) Unlimited Strength
Raspberry Pis 2 Model B with Raspbian establishing Java- Jurisdiction Policy Files 8 by overwriting two policy jar
based SSLSocket connections with TLS v1.2. We use files32 . For a system-wide Java Runtime Environment
a local Gigabit Ethernet network with a Netgear GS108 (JRE) installation like in our case, this requires root priv-
gigabit switch between the nodes to keep the propa- ileges which make deployment more difficult and intro-
gation delay low. To measure the handshake delay, we duce an error source for JRE updates and system resets—
open a connection from one node to another and close when the policy files are not overwritten, requesting
it immediately after successfully connecting. This is per- AES-256 encryption will fail.
formed for both regular sockets and TLS sockets. We use A more flexible, albeit unofficial solution is to remove
the built-in System.nanoTime() command to mea- the restrictions on strong cryptography via reflection33 .
sure the execution time on the sending node (i.e., the This does not require root privileges and can be per-
one that opens a connection) and repeat the experiment formed during startup of the node implementation. How-
1000 times. ever, JRE updates might break the functionality as the
Figure 3 shows the connection times in milliseconds internals might change between JRE versions without
for regular sockets and TLS-based sockets. It is clear prior notice34 .
that the handshake, in particular the key exchange, Circumventing cryptographic restrictions to achieve an
requires about as much time as the unencrypted con- adequate level of security is undesirable. However, from
nection does in total. This makes the delay of a TLS- a practical point of view, it is more convenient than to
based socket double that of a regular socket. In our re-implement the nodes in another runtime environment
use case, this is still acceptable, but needs to be taken or programming language. Nonetheless, we would like to
into consideration during debugging when configuring point out that Java might not be the best choice for imple-
timeouts. menting blockchains with strong cryptography. Assuring

Fig. 3 Connection times in milliseconds (ms) for regular sockets and TLS-based sockets
Knirsch et al. EURASIP Journal on Information Security (2019) 2019:2 Page 11 of 14

the latter on all devices in the network is hard and error- 6.5 Resynchronization is hard
prone, since fallbacks to AES-128 or other algorithms Sometimes nodes get out of synchronization due to
might significantly weaken the security of node-to-node temporary network failures or due to a huge number
communication. of concurrent messages. Incoming blocks are then not
appendable to the chain since one or more blocks between
6.4 One communication thread is not enough the last appended block and the incoming blocks are miss-
When we initially designed the peer-to-peer communi- ing. In this case, a backup algorithm is used that eventually
cation for our node implementation, we dedicated one triggers a resynchronization with neighboring nodes.
thread to handle all the messages to be sent to the node’s The resynchronization algorithm for our blockchain
peers. This means that one thread with a message queue implementation works as follows: Once a node receives a
would process the messages to be sent one by one and block that cannot be appended due to missing blocks in
other threads, e.g., the miner, would place the messages between, it queries the sender of that block for the miss-
to be sent in this queue. In a small and stable network, ing blocks. Additionally, the hash of the last known block
this works fine. However, when connections are lost or the of the unsynchronized node is submitted in order to allow
number of nodes is larger, communication can slow down the receiver to check whether it can serve the request, i.e.,
significantly or even come to a halt. sender and receiver are on the same longest branch. If the
When a connection is lost, the timeout can take sev- requested node does not reply (or cannot reply), the block
eral seconds to be noticed by the transport layer. In the is discarded and the node proceeds with normal opera-
meantime, the communication thread waits for a reply tion. Similarly, if the requested node replies with invalid
or a timeout and is not able to process other messages or unappendable blocks, synchronization with this node
from its queue. This leads to the remaining nodes not is aborted to prevent the node from being locked by a
receiving further messages until the timeout is noticed. malicious actor.
Communication is slowed down significantly if timeouts All these actions are performed synchronously and in
occur often, e.g., when a node has an unstable network a blocking function. This assures that the node is always
connection or is offline. in a defined state while synchronizing and that threads
Similarly, when the number of nodes increases in a sta- are not blocked by incoming transactions or not actively
ble network, the message queue fills up because each mes- requested incoming blocks. Note that our design of sepa-
sage transmission is synchronous and the time required rate client and server threads (see above) allows for con-
to send messages exceeds the time it takes to mine a new current operations and communication with all remaining
block. nodes.
Note that a single-threaded messaging implementa- Initially, we designed an algorithm that picks a random
tion is also a security liability. An attacker could delib- node and requests the missing blocks for synchroniza-
erately cause connection timeouts and pre-mine blocks tion. This was handled completely asynchronously, i.e.,
which deliberately exclude certain transaction. Having after sending the request, the other node sent blocks and
the longest chain and sustaining it by further deliberate they were treated just as if they were normal incoming
timeouts can postpone valid unconfirmed transactions blocks broadcasted by this node. If the list of unappend-
indefinitely. able blocks was still growing, an exponential backup was
To avoid these issues, we implemented one communi- triggered that increased the window of requested blocks.
cation thread per peer, each with its own message queue, This allowed to reuse already included features for resyn-
as outlined in the previous section. Since timeouts on chronization and did not pose much overhead to the
one connection do not influence the other threads, the requesting node.
latter can still make progress independently. However, While this simple algorithm is sufficient for small net-
having one thread per peer increases runtime overhead works and low block rates, it fails if blocks are generated
in terms of memory consumption and scheduling. In our at a higher frequency. In this case, nodes get out of syn-
use case, the number of peers is small enough so that this chronization more likely and multiple nodes that are not
is not an issue. In larger networks, however, Raspberry synchronized themselves try to find a new consensus
Pis might not be sufficient to handle the large number of with each other. This additionally floods the network with
communication threads. blocks and causes even more unsychronized states.
Bitcoin relays transactions to all of its peers, the list of The source code of our implemented blockchain will be
which is changing through a discovery process and is lim- made available for research purposes.
ited to 8 peers per node [52]. This number is similar to the
total number of clients in our network. Ethereum follows 6.6 Idle chains are a security liability
an approach similar to Kademlia35 for peer discovery and Blockchains like Bitcoin and Ethereum see a constant
each node has a configurable maximum number of peers. stream of new transactions to fill up their blocks36 ,
Knirsch et al. EURASIP Journal on Information Security (2019) 2019:2 Page 12 of 14

with an adaptive mining difficulty to keep the time 7 Conclusion

between blocks roughly constant [1, 9]. In our use We motivated and presented our blockchain implemen-
case, however, it is expected that there are periods of tation for fulfilling the recent legal requirements for
decreased or even no activity. On the one hand, all the transfer of energy from shared photovoltaic power
users are in the same time zone, meaning that peri- plants. We described our architecture as well as selected
ods of nightly inactivity can be expected. On the other details of our implemented system. In our analysis, we
hand, during winter or when energy generation is likely elaborated on six take-aways blockchain implementers
to be insignificant, there are no portions transferred should be aware of th following: (i) scalability can be
as there would be no financial gain for either party. improved with Byzantinum Fault Tolerance algorithms
Thus, it is possible that there may be no unconfirmed when the number of users is small; (ii) TLS handshakes for
transactions for several hours or even days within the secure communication links introduce additional delays
network. of approx. 6.6 milliseconds; (iii) AES-256 is disabled in
This could be used by an attacker to pre-mine a Java 8 by default due to export regulations, which requires
longer chain than the rest of the network during the to remove the restrictions via reflection; (iv) one commu-
idle time and subsequently deliberately exclude certain nication thread is not enough for asynchronous peer-to-
transactions from the longest chain. This issue has been peer communication; (v) resynchronization of the node’s
addressed in related work on proof-of-work security from states is hard, especially for small networks and high
the pre-blockchain-era [53] as well as in [54] for a pro- block rates; (vi) idle chains are a security liability, which
tocol similar to Bitcoin and in [55] for Bitcoin itself. can be mitigated by mining empty blocks; and (vii) new
Although Bitcoin and Ethereum assume that there is insights would lead to a different implementation. In
always a significantly high number of transactions to keep summary, implementing a custom, private permissioned
the network active, they both allow for mining empty blockchain from scratch is hard, but viable for use cases
blocks [54]37 . like ours.
Our proposed solution is to mine (empty) blocks even
if there are no transactions. There are sources, e.g., the Endnotes
1
Wiki of libbitcoin38 , which mention the existence of empty http://energyweb.org/news/ewf-february-5-2018/
blocks, but not explicitly as a way to circumvent the secu- 2
https://www.openchain.org/
rity issues of an idle blockchain. In a use case like ours, 3
https://digiconomist.net/bitcoin-energy-
where transaction frequency can be too low for a difficulty
consumption
adjustment to be effective, mining empty blocks might be 4
the only viable solution to prevent pre-mining attacks. Note that, due to daylight saving time, there are 2 days
in each year with 92 and 100 time slots, respectively.
5
6.7 New insights would lead to a different approach https://bitcoin.org/en/download
Given the outcomes mentioned above and the rapid devel- 6
http://solidity.readthedocs.io/en/develop/
opment of blockchain technology, a re-implementation 7
The same is true for US Dollars and other currencies.
at the time of writing (May 2018) would lead to a 8
https://github.com/MultiChain/multichain
different choice for the consensus algorithm. Recently 9
published work, which was not available at the time https://www.qemu.org/
10
of selecting basis implementations, e.g., [46], shows https://qemu.weilnetz.de/doc/qemu-doc.html#x86
11
that scalability for BFT algorithms can be significantly http://www.up-board.org/upsquared/
improved and allows for settings with more than 1000 12
http://www.up-board.org/wp-content/uploads/2017/
nodes. This achieved by sharded blockchain, where not 11/UP-Square-DatasheetV0.5.pdf
every node has to store all blocks. A re-evaluation 13
https://ark.intel.com/products/95598/Intel-Celeron-
of consensus algorithms and available implementations
would thus likely lead to a BFT-based approach instead Processor-N3350-2M-Cache-up-to-2_4-GHz
14
of PoW. https://developer.arm.com/products/processors/
In addition, the choice for BFT is justified by the fact cortex-a/cortex-a7
that PoW is used to prevent Sybil attacks. In a setup as 15
https://www.openchain.org/
the one in our use case, where participants have no incen- 16
https://www.hyperledger.org/
tive to act dishonest or sealed hardware does not allow 17
https://github.com/hyperledger/sawtooth-core
to change the algorithm or upgrade the computing power, 18
a computationally less expensive consensus algorithm is http://oblivm.com/hawk/download.html
19
sufficient. This would reduce power consumption and https://tendermint.com/
scale well nonetheless. 20
https://eos.io/
Knirsch et al. EURASIP Journal on Information Security (2019) 2019:2 Page 13 of 14

21
http://docs.neo.org/en-us/whitepaper.html (40%). Section 5 was written by AU (40%) and FK (60%). Section 6 was written
22 by AU (60%) and FK (40%). The conclusion was written by AU (50%) and FK
http://www.smartgridssalzburg.at/content/website_
(50%). The legal background research was done by AU (100%). Editorial work
smartgrids/de_at/modellregion-salzburg.html was done by DE (100%). All authors read and approved the final manuscript.
23
https://futurezone.at/b2b/verbund-und-salzburg-ag- Authors’ information
starten-blockchain-pilotprojekte/297.880.235 The contact information of the first author is available on the very first page of
24 this document.
https://www.raspberrypi.org/blog/raspberry-pi-2-
Competing interests
on-sale/
The authors declare that they have no competing interests.
25
https://www.raspberrypi.org/blog/raspberry-pi-3-
Publisher’s Note
on-sale/ Springer Nature remains neutral with regard to jurisdictional claims in
26
https://docs.oracle.com/javase/8/docs/api/java/util/ published maps and institutional affiliations.

concurrent/package-summary.html Received: 7 June 2018 Accepted: 13 February 2019

27
https://docs.oracle.com/javase/8/docs/api/java/io/
Serializable.html
References
28
https://www.sqlite.org/ 1. S. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System. Technical
29 report (2008). https://bitcoin.org/bitcoin.pdf
https://ugk-berlin.de/projects/schlangenbader-
2. F. Tschorsch, B. Scheuermann, Bitcoin and beyond: a technical survey on
strasse-ueberbauung-der-stadtautobahn/ decentralized digital currencies. IEEE Commun. Surv. Tutor. 18(3),
30
https://docs.oracle.com/javase/8/docs/technotes/ 2084–2123 (2016)
3. K. Christidis, M. Devetsikiotis, Blockchains and smart contracts for the
guides/security/crypto/CryptoSpec.html#AppC Internet of Things. IEEE Access. 4, 2292–2303 (2016)
31 4. F. Knirsch, A. Unterweger, G. Eibl, D. Engel, in Sustainable Cloud and Energy
https://docs.oracle.com/javase/8/docs/technotes/ Services: Principles and Practices. Chap. 4, ed. by W. Rivera.
guides/security/SunProviders.html#importlimits Privacy-Preserving Smart Grid Tariff Decisions with Blockchain-Based
32 Smart Contracts (Springer, Cham, 2017), pp. 85–116
http://www.oracle.com/technetwork/java/javase/ 5. F. Knirsch, A. Unterweger, D. Engel, Privacy-preserving blockchain-based
downloads/jce8-download-2133166.html electric vehicle charging with dynamic tariff decisions. J. Comput. Sci. Res.
33 Dev. (CSRD). 33(1), 71–79 (2018)
https://stackoverflow.com/questions/1179672/how- 6. E. Munsing, J. Mather, S. Moura, in 2017 IEEE Conference on Control
to-avoid-installing-unlimited-strength-jce-policy-files- Technology and Applications (CCTA). Blockchains for decentralized
optimization of energy resources in microgrid networks (IEEE, Mauna
when-deploying-an/44056166#44056166 Lani, 2017), pp. 2164–2171
34 7. E. Mengelkamp, B. Notheisen, C. Beer, D. Dauer, C. Weinhardt, A
https://stackoverflow.com/a/38625821/4568958
35 blockchain-based smart grid: towards sustainable local energy markets.
https://github.com/ethereum/devp2p/blob/master/ Comput. Sci. Res. Dev. 33(1), 207–214 (2018)
rlpx.md 8. G. Greenspan, MultiChain Private Blockchain - White Paper. Technical
36
report, Coin Sciences Ltd (2015). http://www.multichain.com/download/
https://blockchain.info/ MultiChain-White-Paper.pdf
37
https://github.com/ethereum/EIPs/issues/186 9. G. Wood, Ethereum: A Secure Decentralised Generalised Transaction
38
Ledger. Technical report, Ethereum (2017). arXiv:1011.1669v3. https://
https://github.com/libbitcoin/libbitcoin/wiki/Empty- ethereum.github.io/yellowpaper/paper.pdf
10. K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, A. Miller, P.
Block-Fallacy Saxena, E. Shi, E. Gün Sirer, D. Song, R. Wattenhofer, in International
Acknowledgements Conference on Financial Cryptography and Data Security. On Scaling
The financial support by the Federal State of Salzburg is gratefully Decentralized Blockchains (Springer, Christ Church, 2016), pp. 106–125
11. I. Eyal, E. G. Sirer, in Financial Cryptography and Data Security, 18th
acknowledged. Funding by the Austrian Research Promotion Agency (FFG)
International Conference, FC 2014, Christ Church, Barbados, March 3-7, 2014,
under project number 865082 (ProChain) is gratefully acknowledged.
Revised Selected Papers, ed. by N. Christin, R. Safavi-Naini. Majority Is Not
Additional funding as well as input and feedback by our company partners
Enough: Bitcoin Mining Is Vulnerable (Springer, Berlin Heidelberg, 2014),
Salzburg AG (Georg Baumgartner), Salzburg Netz GmbH (Christoph Groiß) and
pp. 436–454. arXiv:1311.0243
Verbund AG (Werner Eder, Michael Schramel, Peter Poier, and Clemens
12. K. Nikitin, E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, I. Khoffi, J.
Theuermann-Bernhardt) is gratefully acknowledged. The authors would like to
Cappos, B. Ford, in 26th USENIX Security Symposium (USENIX Security 17).
thank the reviewers for their valuable comments which helped to significantly
CHAINIAC: Proactive Software-Update Transparency via Collectively
improve this paper.
Signed Skipchains and Verified Builds (USENIX Association, Vancouver,
Funding 2017), pp. 1271–1287
Funding information is provided in the “Acknowledgements” section. 13. E. Ben-Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, M. Virza,
in Proceedings – IEEE Symposium on Security and Privacy. Zerocash:
Availability of data and materials Decentralized Anonymous Payments from Bitcoin (IEEE, San Jose, 2014),
Not applicable. pp. 459–474
14. A. Unterweger, F. Knirsch, C. Leixnering, D. Engel, in 2018 9th IFIP
Authors’ contributions International Conference on New Technologies, Mobility and Security (NTMS).
This paper was written by FK (45%), AU (45%), and DE (10%). The detailed Lessons Learned from Implementing a Privacy-Preserving Smart Contract
contributions are as follows: The idea for the paper and the blockchain in Ethereum (IEEE, Paris, 2018)
concept were developed by AU (40%), FK (40%), and DE (20%). The Abstract 15. L. Lamport, R. Shostak, M. Pease, The Byzantine Generals Problem. ACM
was written by AU (50%) and FK (50%). Section 1 was written by AU (50%) and Trans. Program. Lang. Syst. 4(3), 382–401 (1982). arXiv:1011.1669v3
FK (50%). Section 2 was written by AU (20%) and FK (80%). Section 3 was 16. R. Canetti, T. Rabin, in Proceedings of the Twenty-fifth Annual ACM
written by AU (50%) and FK (50%). Section 4 was written by AU (60%) and FK Symposium on Theory of Computing. Fast Asynchronous Byzantine
Knirsch et al. EURASIP Journal on Information Security (2019) 2019:2 Page 14 of 14

Agreement with Optimal Resilience 1 Introduction (ACM, San Diego, NRG-X-Change - A Novel Mechanism for Trading of Renewable Energy in
1993), pp. 42–51 Smart Grids (SciTePress, Barcelona, 2014), pp. 101–106. arXiv:1011.1669v3
17. M. Vukolić, in Open Problems in Network Security. The Quest for Scalable 36. J. J. Sikorski, J. Haughton, M. Kraft, Blockchain technology in the chemical
Blockchain Fabric: Proof-of-Work vs. BFT Replication (Springer, Cham, industry: Machine-to-machine electricity market. Appl. Energy. 195,
2016), pp. 112–125 234–246 (2017)
18. J. Katz, Y. Lindell, Introduction to Modern Cryptography, 1st edn. (Chapman 37. D. Ilic, P. G. Da Silva, S. Karnouskos, M. Griesemer, in IEEE International
and Hall/CRC, New York, 2007), pp. 1–498 Conference on Digital Ecosystems and Technologies. An energy market for
19. I. Abraham, D. Malkhi, K. Nayak, L. Ren, A. Spiegelman, in The 21st
trading electricity in smart grid neighbourhoods (IEEE, Atlanta, 2012),
International Conference on Principles of Distributed Systems. Solida: A Blockchain
pp. 1–6
Protocol Based on Reconfigurable Byzantine Consensus, (Lisbon, 2017),
38. Y. Wang, W. Saad, Z. Han, H. V. Poor, T. Başar, A game-theoretic approach
pp. 1–17. http://arxiv.org/abs/1612.02916. Accessed 24 Jan 2019
20. J. A. Lesser, X. Su, Design of an economically efficient feed-in tariff structure to energy trading in the smart grid. IEEE Trans. Smart Grid. 5(3),
for renewable energy development. Energy Pol. 36(3), 981–990 (2008) 1439–1450 (2014). http://arxiv.org/abs/1310.1814
21. L. Krampe, M. Wünsch, Schlussbericht Mieterstrom – Rechtliche 39. E. Kokoris-Kogias, P. Jovanovic, N. Gailly, I. Khoffi, L. Gasser, B. Ford, in 25th
Einordnung, Organisationsformen, Potenziale und Wirtschaftlichkeit von USENIX Security Symposium (USENIX 2016). Enhancing Bitcoin Security and
Mieterstrommodellen (MSM). Technical report (2017). https://www.bmwi. Performance with Strong Consistency via Collective Signing (USENIX
de/Redaktion/DE/Publikationen/Studien/schlussbericht-mieterstrom. Association, Austin, 2016), pp. 279–296
pdf?__blob=publicationFile&v=10 40. J. Bucko, D. Pal’ová, M. Vejačka, in Central European Conference In Finance
22. E. Mengelkamp, J. Gärttner, K. Rock, S. Kessler, L. Orsini, C. Weinhardt, And Economics. Security and Trust in Cryptocurrencies (Technical
Designing microgrid energy markets: A case study: The Brooklyn University of Košice, Herlany, 2015), pp. 14–24
Microgrid. Appl. Energy. 210, 870–880 (2018) 41. A. Unterweger, F. Knirsch, C. Leixnering, D. Engel, Update: Lessons
23. Bundeskanzleramt, Kleine Ökostromnovelle –Erläuterungen (2017). Learned from Implementing a Privacy-Preserving Smart Contract in
https://www.ris.bka.gv.at/Dokumente/RegV/ Ethereum. Technical report, Center for Secure Energy Informatics,
REGV_COO_2026_100_2_1346954/COO_2026_100_2_1347360.pdf. Salzburg University of Applied Sciences, Austria (nov 2017). http://www.
Accessed 24 Jan 2019 en-trust.at/papers/Unterweger18a-t.pdf
24. Nationalrat, Änderung des Ökostromgesetzes 2012, des 42. F. Knirsch, A. Unterweger, K. Karlsson, D. Engel, S. B. Wicker, Evaluation of a
Elektrizitätswirtschafts- und -organisationsgesetzes 2010, des Blockchain-based Proof-of-Possession Implementation. Technical report,
Gaswirtschaftsgesetzes 2011, des KWK-Punkte-Gesetzes und des Center for Secure Energy Informatics, Salzburg University of Applied
Energie-Control-Gesetzes sowie Bundesgesetz, mit dem zusätzliche Sciences, Austria (2018). http://www.en-trust.at/papers/Knirsch18a-t.pdf
Mittel aus von der .. BGBl. I Nr. 108/2017 (NR: GP XXV RV 1519 AB 1527 S. 43. R. Han, V. Gramoli, X. Xu, in 9th IFIP Conference on New Technologies,
190. BR: 9831 AB 9873 S. 870.) (2017). https://www.ris.bka.gv.at/eli/bgbl/I/ Mobility & Security (NTMS 2018). Evaluating Blockchains for IoT (IEEE/IFIP,
2017/108. Accessed 24 Jan 2019 Paris, 2018), pp. 0–4
25. Bundestag, Gesetz zur Förderung von Mieterstrom und zur Änderung 44. A. Kosba, A. Miller, E. Shi, Z. Wen, C. Papamanthou, in 2016 IEEE Symposium
weiterer Vorschriften des Erneuerbare-Energien-Gesetzes. on Security and Privacy (SP). Hawk: The Blockchain Model of Cryptography
Bundesgesetzblatt Teil I. 2017(49), 2532–2539 (2017) and Privacy-Preserving Smart Contracts (IEEE, San Jose, 2016), pp. 839–858
26. Nationalrat, Bundesgesetz, mit dem die Organisation auf dem Gebiet der 45. D. Mazières, The Stellar Consensus Protocol: A Federated Model for
Elektrizitätswirtschaft neu geregelt wird (Elektrizitätswirtschafts- und Internet-level Consensus. Technical report, Stellar Development
-organisationsgesetz 2010 – ElWOG 2010). BGBl. I Nr. 110/2010 (NR: GP Foundation (2016). https://www.stellar.org/papers/stellar-consensus-
XXIV RV 994 AB 997 S. 86. BR: 8420 AB 8421 S. 791.) (2010). https://www. protocol.pdf
ris.bka.gv.at/eli/bgbl/I/2010/110. Accessed 24 Jan 2019 46. E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, B. Ford,
27. Nationalrat, Bundesrecht konsolidiert: Gesamte Rechtsvorschrift für OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding. IEEE
Elektrizitätswirtschafts- und -organisationsgesetz 2010, Fassung vom Symp. Secur. Priv., 583–598 (2018)
14.02.2018 (2018). https://www.ris.bka.gv.at/GeltendeFassung.wxe? 47. D. Engel, G. Eibl, Wavelet-Based Multiresolution Smart Meter Privacy. IEEE
Abfrage=Bundesnormen&Gesetzesnummer=20007045. Accessed 24 Jan Trans. Smart Grid. 8(4), 1710–1721 (2017)
2019 48. D. Laupichler, S. Vollmer, H. Bast, M. Intemann, Das BSI-Schutzprofil:
28. Bundestag, Gesetz zur grundlegenden Reform des Anforderungen an den Datenschutz und die Datensicherheit für Smart
Erneuerbare-Energien-Gesetzes und zur Änderung weiterer Metering Systeme. Datenschutz und Datensicherheit - DuD. 35(8),
Bestimmungen des Energiewirtschaftsrechts. Bundesgesetzblatt Teil I. 542–546 (2011)
2014(33), 1066–1132 (2014) 49. M. Herlihy, N. Shavit, The Art of Multiprocessor Programming, rev. 1st edn.
29. Bundestag, Erneuerbare-Energien-Gesetz vom 21. Juli 2014 (BGBl. I S. (Morgan Kaufmann, Waltham, 2012)
1066), das zuletzt durch Artikel 1 des Gesetzes vom 17. Juli 2017 (BGBl. I S. 50. E. Barker, W. Barker, W. Burr, W. Polk, M. Smid, C. S. Division, NIST 800-57:
2532) geändert worden ist (2017). https://www.gesetze-im-internet.de/ Computer Security. NIST (2012). National Institute of Standards &
eeg_2014/BJNR106610014.html. Accessed 24 Jan 2019 Technology. https://csrc.nist.gov/publications/detail/sp/800-57-part-1/
30. K. Wüst, A. Gervais, Do you need a Blockchain. https://eprint.iacr.org/ revised/archive/2007-03-01
2017/375.pdf 51. T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol Version
31. European Parliament and Council of the European Union, Directive 1.2. RFC 5246 (2008). https://tools.ietf.org/html/rfc5246. Accessed 24 Jan
2009/72/EC of the European Parliament and of the Council of 13 July 2019
2009 concerning common rules for the internal market in electricity and 52. C. Decker, R. Wattenhofer, Information propagation in the Bitcoin network
repealing Directive 2003/54/EC (2009). http://eur-lex.europa.eu/legal- Information Propagation in the Bitcoin Network (IEEE P2P 2013
content/EN/TXT/?uri=CELEX:32009L0072. Accessed 24 Jan 2019 Proceedings, Trento, 2013), pp. 1–10
32. M. Hearn, Corda: A distributed ledger, Version 0.5. Technical report. Corda. 53. M. Jakobsson, A. Juels, in Secure Information Networks: Communications
Accessed September 2018 (2016). https://www.corda.net/content/corda- and Multimedia Security IFIP TC6/TC11 Joint Working Conference on
technical-whitepaper.pdf Communications and Multimedia Security (CMS’99) September 20–21, 1999,
33. N. Zhumabekuly Aitzhan, D. Svetinovic, Security and Privacy in Leuven, Belgium, ed. by B. Preneel. Proofs of Work and Bread Pudding
Decentralized Energy Trading through Multi-signatures, Blockchain and Protocols (Extended Abstract) (Springer, Dordrecht, 1999), pp. 258–272
Anonymous Messaging Streams. IEEE Trans. Dependable Secure Comput. 54. I. Eyal, A. E. Gencer, E. G. Sirer, R. van Renesse, in Proceedings of the 13th
15(5), 840–852 (2016) Usenix Conference on Networked Systems Design and Implementation.
34. M. Mihaylov, S. Jurado, N. Avellana, K. Van Moffaert, I. M. De Abril, A. Nowé, NSDI’16. Bitcoin-NG: A Scalable Blockchain Protocol (USENIX Association,
in 11th International Conference on the European Energy Market, EEM. Santa Clara, 2016), pp. 45–59. http://arxiv.org/abs/1510.02037
55. M. Carlsten, H. Kalodner, S. M. Weinberg, A. Narayanan, in Proceedings of
NRGcoin: Virtual currency for trading of renewable energy in smart grids
the 2016 ACM SIGSAC Conference on Computer and Communications
(IEEE, Krakow, 2014)
Security - CCS’16. On the Instability of Bitcoin Without the Block Reward
35. M. Mihaylov, S. Jurado, K. V. Moffaert, A. Now, in Proceedings of the 3rd
(ACM, Vienna, 2016), pp. 154–167
International Conference on Smart Grids and Green IT Systems.