PreprintPDF Available
Preprints and early-stage research may not have been peer reviewed yet.

Abstract and Figures

Research in the field of blockchain technology and applications is increasing at a fast pace. Although the Bitcoin whitepaper by Nakamoto is already ten years old, the field can still be seen as immature and at an early stage. Current research in this area is lacking a commonly shared knowledge and consensus about terms used to describe the technology and its properties. At the same time this research is challenging fundamental aspects of the Bitcoin core concept. It has to be questioned whether all of these new approaches still adequately could be described as blockchain technology. We propose to use the term Decentralized Consensus Technology as a general category instead. Decentralized Consensus Technology consists of decentralized ledger and non-ledger technologies. Blockchain technology in turn is only one of multiple implementations of the Decentralized Ledger Technology. Furthermore, we identified three main characteristics of Decentralized Consensus Technology: decentralization, trustlessness and ability to eventually reach consensus. Depending on the use case of the specific implementation the following additional properties have to be considered: privacy, participation incentive, irreversibility and immutability, operation purpose, confirmation time, transaction costs, ability to externalize transactions and computations and scalability possibilities.
Content may be subject to copyright.
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
In the last years a lot of research has been done, both in academia and industry,
regarding blockchain technology. Unfortunately, we found very little research
covering what properties a system is required to have to be called a blockchain
system and, if they do not fulfill these criteria, what terminology can be used to
describe them instead.
A phrase attributed to Socrates is that ”the beginning of wisdom is the
definition of terms”. We believe that, especially in such a fast developing area
like blockchain technology, a clear definition of terms is important to gain a
commonly shared way to communicate concepts and thoughts.
The following paper is a draft we developed in 2018 during internal discussions
concerning this topic. We are discussing what properties we believe a blockchain
system is required to have to do justice to this term. Furthermore, we argue that
an alternative term is needed to discuss technologies not fulfilling all requirements
to be called blockchain but being related to this technology. We believe that the
term Decentralized Consensus Technology might be both generic and specific
enough to cover all the advancement in the area of blockchain technology without
excluding possible solutions for challenges in that area.
Between the end of 2018 and the beginning of 2019 we submitted the paper
both to a conference covering topics of security, privacy and distributed systems
and later (after addressing reviewer feedback) to a journal covering the topic
of software engineering. Unfortunately, both times the paper was rejected. The
reasons for the rejections can be summarized as follows:
We didn’t meet the expected format and the degree of novelty was deemed
too low
We lack a scientific process for collecting the presented concepts and data.
E.g. a systematic mapping study would have been preferred.
It is unknown in which direction the technology will develop and it cannot
be said whether our proposed terminology covers the complete connotation
of blockchain systems.
Due to various discussions both inside and outside our research group we
decided that the following draft might serve as a good starting point for further
discussions in the context of blockchain terminology. We therefore decided to
publish it on a publicly accessible platform, regardless of whether it was rejected
by the conference and journal. We hope that it helps to develop a commonly shared
understanding regarding the properties of such systems and the terminology to
describe them. Feel free to use it as a basis for further research and to get in
touch with us to discuss this topic.
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Properties of Decentralized Consensus
Technology – Why not every Blockchain is a
Christopher Ehmke, Florian Blum, and Volker Gruhn
University of Duisburg-Essen, Schuetzenbahn 70, 45127 Essen, Germany
Research in the field of blockchain technology and applica-
tions is increasing at a fast pace. Although the Bitcoin whitepaper by
Nakamoto is already ten years old, the field can still be seen as immature
and at an early stage. Current research in this area is lacking a commonly
shared knowledge and consensus about terms used to describe the tech-
nology and its properties. At the same time this research is challenging
fundamental aspects of the Bitcoin core concept. It has to be questioned
whether all of these new approaches still adequately could be described
as blockchain technology. We propose to use the term Decentralized Con-
sensus Technology as a general category instead. Decentralized Consensus
Technology consists of decentralized ledger and non-ledger technologies.
Blockchain technology in turn is only one of multiple implementations
of the Decentralized Ledger Technology. Furthermore, we identified three
main characteristics of Decentralized Consensus Technology:decentraliza-
tion,trustlessness and ability to eventually reach consensus. Depending on
the use case of the specific implementation the following additional prop-
erties have to be considered: privacy,participation incentive,irreversibility
and immutability,operation purpose,confirmation time,transaction costs,
ability to externalize transactions and computations and scalability possi-
decentralized consensus technology
tralized ledger technology
distributed consensus
technology ·properties ·DCT ·DCS ·DLT ·DLS
1 Introduction
Blockchain technology is an innovation said to be one of the most disruptive
inventions of the past decades [
]. Although, initially only intended to be a
decentralized alternative to the traditional centralized financial currency system
], it is now used in various different scenarios. Since the Bitcoin white paper
presenting the first concepts, later named blockchain technology [
], a lot of
research has been done to further improve the concept and implementations. In
spite of all these improvements, or maybe even because of them, it is hard to
describe how a blockchain system is characterized [
]. There is little commonly
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 3
shared knowledge and agreed-upon terminology for the specific properties a
system has to provide to be seen as a blockchain technology and which properties
of a certain system might prevent such a classification. This area of research
is growing and in the last year a few publications started to address this issue
(cf. [
]). The problem of having no commonly known and accepted
description of the system under examination becomes visible when analyzing
the state of research for blockchain applications: Nearly all start with their own
introduction and definition of blockchain technology. Often some properties are
mentioned used to classify a blockchain project as such. Several papers state
for example that decentralization,immutability of included data and being able
to operate without relying on trust between the participants are fundamental
properties of blockchain technology [
]. Furthermore, there is a lot of research
regarding the modification of certain properties (e.g. see [
]) while still
claiming the resulting systems to be blockchains.
Remarkably, even though Nakamotos [
] white paper is considered to be origin
of the blockchain technology, the term ”Blockchain” is not used in their paper.
We will show that it is hard to point out which properties characterize blockchain
technology, especially when several approaches modify, remove or extend ideas
from the initial concept by Nakamoto. During the last years the term Distributed
Ledger Technology (DLT), respectively Distributed Ledger System (DLS), came up
to handle these terminology shortcomings [
]. Unfortunately, even these terms do
not cover all forms of system that came up in the context of blockchain technology.
For example, it has to be discussed whether a distributed computation platform
like Ethereum [
] can be accurately described as a (decentralized) ledger. We
propose to use the term ”Decentralized Consensus Technology” (DCT) (cf. [
aiming at describing a wider range of technologies in the context of blockchains
without being too specific to cover modified versions of the concept. We will show
why the distinction between blockchain technology and the term Decentralized
Consensus Technology (DCT) is important and should be considered in further
This paper is structured as follows: The next section will give a short intro-
duction to the initial concept presented by Nakamoto, derive specific properties of
their approach as a baseline for further comparison and highlight some problems
of this initial concept. Section 3 will give a brief overview of current research
topics modifying properties of the initial system. Section 4 covers insights about
the definition of the term DCT and will show that the question which properties
characterize Decentralized Consensus Technology depends on the application to
be developed. Section 5 will present related work in this context and Section 6
will conclude our work.
2 A brief history of blockchain innovations
Bitcoin is said to be the first blockchain application and is therefore considered
the technology which has coined the term blockchain. The technology of Bitcoin
is based on a whitepaper [
] published in 2008 by a person (or group) acting
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
4 C. Ehmke et al.
under the name Nakamoto (which is believed to be a pseudonym [
]). It is
based both on cryptographic principles (like [
] and [
]) and ideas concerning
decentralized currencies (like [130] and [46]) that were published before.
Nakamoto designed a digital currency system in which the coins are based
on digital signatures. Doing so, they insured the security and integrity of coin
transfers by using established cryptographic methods. In contrast to previous
digital currencies like Szabos Bit gold [
] or Dais b-money [
] Nakamoto further
solved the so-called double-spending problem. The double-spending problem
describes the fact that digital goods might be duplicated easily. In contrast to
physical money which can only be spent once (and is not in your possession
thereafter), it is hard to assure that digital assets are only passed over to a single
person or to make sure that such a multiple spending is at least noticed by others.
2.1 Technical implementation of the Bitcoin blockchain system
Nakamoto solved the double-spending problem of previous decentralized curren-
cies by defining that only the first attempt to spend a certain coin should be
seen as valid. Later attempts should be rejected by the network. To make this
possible, every member of the network has to be able to check the validity of any
request to spend coins and to figure out if there have been previous requests of
spending the same coins.
Coin transfers between owners is handled in transactions which contain
information about the sender, the receiver, the amount of coins to be send and
a proof that the sender is entitled to request the transaction (i.e, a proof that
they are the owner of the coins they want to send). Proving the ownership of a
certain coin is done using cryptographic concepts like digital signatures. Instead
of relying solely on digital signatures to prove ownership, Nakamoto decided to
introduce a script language that is used for this task. The decision came from
considerations about enabling the modelling of complex requirements that need
to be fulfilled to spend a certain coin. For example, it is possible to create a coin
which can only be spent after a certain time period [58].
Having transactions which can be validated with regard to the ownership of
the coins is not enough to prevent double-spending attempts. To enable this,
Nakamoto has decided that transactions are not broadcasted separately but in
groups, the so-called blocks. Blocks are ordered and linked as a chain with each
block pointing to its direct ancestor. By doing this, the order of the processed
transactions can be captured. Grouping the transactions in blocks is still insuffi-
cient to solve the double-spending problem: a malicious member of the network
could try to manipulate the blocks and leave out certain transactions. To prevent
this, the blocks are protected against manipulation by a procedure Nakamoto
called ”proof-of-work”. Proof-of-work is a cryptographic method introduced by
Back [
] to prevent e-mail spam. The core idea is to include a proof that a certain
amount of work has been done in order to demonstrate a certain commitment
for the message being sent. In reality, this is often implemented by including
a hash value that fulfills certain requirements (e.g. to start with a predefined
number of zeros). Since hash functions are almost impossible to reverse or predict
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 5
(i.e., finding the input for a given hash), the sender of the message has to try a
lot of different input values (e.g. the message and a random value) to find one
that leads to a hash value matching the requirements. Nakamoto used the same
mechanism to secure the integrity of blocks. The hash value of a valid block has
to start with a predefined number of zeros. If a block is changed, the hash value
would change as well and, in most cases, not fulfill the requirements anymore.
This enables the detection of illegal modifications [3,58,47].
Besides the technical prevention of illegal modifications of issued blocks, the
concept of Nakamotos blockchain depends on game theoretical elements as well
]: Nakamoto decided that (at least in the reference implementation of Bitcoin)
clients should accept the blockchain with the highest accumulated proof-of-work
difficulty as valid [
, p. 200ff.]. Combined with the fact that the creation of new
blocks requires a huge amount of computational power, this led to a system
discouraging fraudulent behavior and promoting honesty [
]. Even though
there have been some problems with this assumption (see e.g. [
as far as we know, there has been no successful attack targeting this specific
attack vector (cf. [
] for successful ones). In the last years it has been shown
that there are various problems with the concept presented by Nakamoto. Also,
multiple attempts have been made to solve them. Some solutions are proposed
as so-called Bitcoin Improvement Proposal (BIP)
, others as completely new
blockchain networks (e.g. Ethereum [5]).
2.2 Properties of blockchain technology
According to Nakamoto the goal of Bitcoin was to create an electronic payment
system that does not depend on trusted third parties and enables any two parties
to transact directly with each other [
]. Chatterjee [
] states that there are five
properties characterizing blockchain technology:
Immutable: It should be practically impossible to modify a block.
: It should not be possible to reverse a transaction once it was
processed by the network participants.
: Everybody should be able to participate in the network and be
able to validate and process transactions.
No Centralized Authority
: There should not be a centralized organization
the network depends on.
: The system should be able to handle faulty messages without
opening up opportunities for fraud (also see [85]).
There are further properties mentioned in the literature which are paraphras-
ing those listed above. There are also very generic properties which can be used to
describe other non-Bitcoin Decentralized Consensus Technology (see Section 4) as
well. Furthermore, there are characteristics used to describe blockchain technology
that we believe are applied wrongly. To make it more clear, we give an example
for each category:
1 (visited on 2018-08-09)
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
6 C. Ehmke et al.
Properties paraphrasing the above ones – One prominent example for prop-
erties meaning the same but being described by different words is the dis-
tribution of the system. As it was stated before, authors like Chatterjee [
or Nakamoto [
] themselves see the fact that the system does not depend
on a central service and that everybody is enabled to participate as core
factors of the concept. In the literature ”distributed” and ”decentralized”
are used synonymously in order to describe blockchain technology, ignoring
the semantic differences between the two words [
]. Section 3.9 will
elaborate on the differences in more detail. Independent from the question
which of both words is the correct one to characterize the technology, it
serves as a good example to demonstrate the fact that different authors use
different words to describe the same properties of blockchain concepts.
Too generic properties – Some properties used to describe blockchain-like
systems are very generic. Conte de Leon states that being digital is a fun-
damental concept of blockchain technology [
]. Without questioning this
fact, it is clear that this property is too generic to describe and differentiate
blockchain networks.
Generic properties are not necessarily bad but they still need to define a
boundary in order to be useful. For example there might be a superior category
embracing both blockchain and non block- or chain-based Decentralized
Consensus Technology; independently of the internal functionality of such
systems, being digital would also be a basic property. Another example of these
kind of properties is that blockchain technologies are said to be ”trustless”.
It means that they do not rely on a (central) trusted third party [
]. Some
definitions even go one step further and declare that this trustlessness means
that there has been a shift from trust in institutions or persons towards trust
in algorithms and mathematical concepts (cf. [
]). But similar to the
digitality property, this also applies to a more generic term and not only
blockchain technology.
Wrongly applied characteristics – In literature sometimes properties used
to describe blockchain technology are applied wrongly. One example for an
alleged property of blockchain technology is the anonymity of blockchain
users. The misconception that blockchain technology, respectively Bitcoin, is
anonymous might go back to the fact that Nakamoto discusses transaction
privacy in their white paper [
]. To be more precise, they compare the
privacy of transaction in their presented system to the traditional money
systems. In that comparison Bitcoin is better since there is no trusted third
party keeping records of all transactions but only hashed public keys as
indicators on how much money belongs to a certain Bitcoin address. This
might have led to the erroneous belief that Bitcoin is anonymous and could
therefore be used for criminal reasons (see [
]). Nevertheless, various
studies (like [
]) have shown that this assumption is not correct and
Bitcoin can only be described as pseudonymous. More information on the
anonymity of blockchain technology, and on the fact that only some specific
blockchain systems offer their users anonymity, is given in Section 3.1.
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 7
2.3 Problem categories of Bitcoin technology
Since the release of Bitcoin, several problems of the system have been shown. Some
came up from practical considerations and some only from scientific examinations.
Lin and Liao [
] identified several problems threatening the security and usability
of the system: attacks focusing problems of the protocol, forks of the network,
confirmation time of transactions, regulatory problems, scalability issues and
integrated costs. We will now briefly discuss the categories attacks,confirmation
time and transaction costs and scalability.
Attacks – During the last years several attacks have been presented that could
be used to publish fraudulent transactions, to double-spend coins or to trick
other participants into believing that a certain transaction has been processed
even though it has been rejected by the network. Examples for these kind of
attacks are the so-called ”Finney Attack” [
], ”Race Attack” [
], ”Eclipse
Attacks” [
] or ”50% + 1 Attack” [
]. The first three focus on other users
of the network and try to trick them into thinking that they successfully
received their coins. Eclipse attacks try to achieve this by isolating the victim
of the attack from the other members of the network. If this is possible, the
attacker can fake the acceptance of their transactions so that the victim
believes that the transaction has been processed successfully while it was
actually rejected. The 50% + 1 attack describes an attack vector in which
the attacker controls the majority of the network’s computational power and
therefore is able to rewrite the transaction history. If this is possible, they
could undo certain transactions and spend these coins again. Despite the
name, recent studies have shown that it is not necessary to gain more than
50 percent of the total network computation power but that one third is
sufficient [
]. Franco [
] describes an attack called ”transaction spamming”
which could be seen as a form of denial-of-service attack. The attacker tries
to flood the network (or certain members) with a huge amount of (useless)
transactions so that they are not able to process the legitimate ones in time
Confirmation time and transaction costs – Other problems that prevent
Bitcoin from being used for everyday services are the long confirmation time
of transactions and the integrated costs of new transactions. The time until
transactions become confirmed results from design decision by Nakamoto that
a new block should be created roughly every ten minutes [
]. This results
in a confirmation time of a new transaction of roughly 60 minutes as the
current best practice emerged that a transaction is valid if it is included in a
block with more than six successors (at that point the probability that an
attacker can modify enough blocks quickly enough to erase this transaction
becomes acceptably small [
]). This long period until a transaction is
securely included in the blockchain might complicate the development of
certain use-cases and hinders the everyday usage of the technology. On the
other hand, authors like Antonopoulos [
, p. 247] argue it is not necessary to
wait until a certain transaction has been included irreversibly, only until the
risk of fraud is acceptably small.
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
8 C. Ehmke et al.
Another problem preventing Bitcoin from being used in daily life are the
potentially high transaction costs. In general, though not strictly required, it
is common to pay a small transaction fee besides the actual payment. This is
done both to incentivize the other members of the network to process the
own transaction and to prevent misuse of the network [
]. One problem
of this concept is the fluctuation and actual amount of the transaction fee
that has to be paid. Figure 1 illustrates this issue. From mid to end 2018 it
shows an average transaction fee of about half a US-Dollar. But on the other
hand the transaction fee peaked at nearly 55 USD in December 2017. Such
volatility in the costs of a single transaction might prevent people from using
Bitcoin for everyday services.
Scalability – Scalability in the context of blockchain technology covers a wide
range of different problems with the following three as the most threatening
ones: Energy consumption, size of the blocks and total size of the blockchain.
Energy consumption is an issue due to the concept of basing the security
of the network on computational expensive routines, where a lot of energy
is required for that task. De Vries examines this fact and concludes that
the Bitcoin network consumes nearly as much electric energy as Ireland in
2018. There are calculations stating that the energy consumption will grow
further extensively [
]. The size of a single block is important for scalability
considerations because it limits how many transactions can be included in one
block and therefore processed in a certain time. In literature there is often a
comparison between the number of transactions per second of Bitcoin and
the amount of transactions in the same time frame of a traditional payment
provider. The studies often compare Bitcoin’s 7 transactions per second [
with traditional payment providers like VISA which processes up to 56.000
transactions in the same time [
]. This comparison is not entirely correct
anymore since the size limitation of a single block was increased in the Bitcoin
system in August 2017 [
]. Instead of being a fixed size of 1 MB it was
converted to a unit based system and increased to 4,000,000 units. Even
when this would mean that more transactions could be processed in the same
time as before, it is still no match for the traditional payment providers.
Ehmke et al. [
] point out that the growing size of the complete blockchain
poses another problem considering new participants of the network. Since
new members of the network need to download the whole blockchain before
they can start to participate in the process of creating new blocks, an ever
growing blockchain poses a challenge. If the blockchain should be used in
the context of Internet-of-Things it might even prevent devices, respectively
members, from participating at all because they might not have the storage
to download the blockchain initially.
There are two general ways how the community handles changes to improve
the technology and mitigate problems: The first one is the proposition of a
so-called Bitcoin Improvement Proposal (BIP). These BIPs are a semi-formal
way to propose changes in the network protocol (or the implementation) and
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 9
Fig. 1.
Average Bitcoin transaction fee in USD according to
(visited 2019-01-21)
follow a process also described in form of a BIP
. The idea of BIPs is that new
ideas are discussed in discussion groups growing in size until they reach the whole
community. At that point the network members are able to vote in favor (or
against) such an improvement and can therefore activate or reject it (see BIP 9
for more information). If a BIP was accepted and implemented in the core code,
it might lead to a fork of the blockchain. This can happen in situations where
mining nodes do not accept the new software version or simply have not update
their software yet. The term fork describes an event in which the blockchain is
split into two or more separated chains with the same ancestor blocks. In reality
there is a distinction between soft-forks and hard-forks. The difference between
these two is the compatibility with blocks created by clients that do not follow
the new protocol. Soft-forks are a type of fork in which the old clients can still
process blocks produced by the new ones (e.g. when a certain rule has become
more strict than before). Hard-forks means full incompatibility between the new
and the old protocol version [90].
Another possibility to improve or modify the protocol is to create completely
new systems. Due to the origin of blockchain applications (namely the usage
as a currency) these new systems are often called ”altcoins” or ”altchains” [
These terms describe both completely new networks or meta coin platforms
which operate on top of existing blockchains but add extra features by inserting
additional data into blocks or transactions. Even though some approaches try to
enable the interoperability of different altcoins (see e.g. [
]), currently different
chains are mostly unable to interact with each other [133].
(visited on
(visited on
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
10 C. Ehmke et al.
3 Evolution of the blockchain idea –
The current state of the art
In the previous section we discussed that there are multiple properties a blockchain
system is said to have. In this section an overview of the current state of the
art, respectively the evolution of the blockchain concept in the last few years, is
given. Each aspect that will be presented should demonstrate the modification of
certain properties of the blockchain concept. There are approaches that change
or remove properties that Nakamoto [
] deemed essential but still make sense
for certain use cases. Therefore a more general term describing technologies
following the basic ideas of Nakamoto but not all of its concepts is required.
Nonetheless, the following survey shows the diversity of the current research in
this topic and will show that a lot of the properties of Nakamotos system are
being questioned. By examining the different modifications and improvements of
the original idea by Nakamoto it will become apparent that there are a lot of
attributes and properties the new approaches have or lack, which have not been
discussed consciously but have been implicitly seen as granted.
3.1 Privacy – Between anonymity and pseudonymity
One of the properties that has been misinterpreted very often is the privacy of
blockchain technology. Since its invention, Bitcoins decentralized character and
its seeming anonymity [
] led to a wide usage for criminal or illegal purposes
]. Nevertheless, studies like [
] showed that the Bitcoin system
is not anonymous but could be seen as pseudonymous.
Since Bitcoin is often used by people that do not want their financial transac-
tions to be traceable (see [
]) different improvements (e.g. Zerocoin [
have been made that also lead to completely new cryptocurrencies focusing on
anonymity as a primary goal (see e.g. Monero [80,88]).
Besides completely new and privacy-centered coins, there are other techniques
such as the so-called mixing services trying to anonymize payments by creating
huge transactions with a lot of ingoing and outgoing addresses. The goal of these
services is to complicate the analysis of the transactions and therefore to hide
the sender and receiver of payments. This is done by mixing the actual payments
with a lot of other, completely independent payments while it is only guaranteed
that the receiver gets the agreed amount and not that it is received from a certain
address (cf. [44,32,120]).
Van Wegberg et al. [
] point out that one of the problems of the anonymity
of cryptocurrencies is that you often have to convert them back to a traditional
(fiat) currency such as USD and EUR to be able to use them in everyday scenarios.
Furthermore, the security of the system, independently of the security of its
underlying protocol, often depends on the number of active users. Considering,
for example, that Ripple is only maintained by very few servers (according to [
the main network only consists of seven validating servers), the anonymity of the
users can easily be compromised without the usage of costly analysis like [
Gervais et al. [61] point out that this critique is also valid for Bitcoin itself.
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 11
3.2 Incentive for participation
There is an ongoing discussion whether coins, respectively a native, inherent
currency, is necessary for blockchains or if they could work without them. Blog
posts like [
] ask whether blockchain technology might could go on even when the
inherent cryptocurrencies fail. Kravchenko [
] points out that there are different
kinds of coins and tokens that could be used in blockchain environments. On
the one hand there are inherent coins used in the protocol of the underlying
blockchain and on the other hand there are tokens built on top of it (that might
also be used in Initial Coin Offering (ICOs)). The need for these two kind of
coins, respectively tokens, has to be answered separately. More important is
the discussion whether the inherent coins are needed for the working of the
currency. There are different answers to that question. Cadigan [
] states
that there are different working blockchain projects without having the concept
of inherent currencies. Private blockchains like R3’s Corda or IBM’s Fabric
demonstrate that it is possible to construct systems without the need for inherent
currencies [
]. On the other hand these systems modify one important concept
of previous blockchain systems, namely the openness for all people to participate
(see Section 3.4 for more details).
Considering only public permissionless blockchains, in which everybody is
allowed to participate, the reasons for an inherent currency were already given in
Nakamoto’s original paper: They state that the inherent currency helps to ensure
that the participants stay honest [
]. They justify this claim through the idea
that, to create a stable system, staying honest has to be more profitable than
trying to cheat. Therefore, a (real-world) incentive is needed to reward honest
and punish dishonest participants [
]. Lewenberg et al. [
] and Badertscher
et al. [
] further support this claim by providing a game theoretical explanation
for the stability of the system that relies on the concept of an external incentive
for participants (like receiving coins which are valued by the participants and
therefore serve as a currency).
Even though coins and tokens in blockchain systems are often called currencies,
it is important to point out that in a legal definition they are not seen as such in
most countries [
]. Instead they are sometimes seen as commodities or digital
goods. Moreover there is an ongoing discussion about regulations and whether
some coins or tokens qualify as a security
. Independent of the classification of
these inherent currencies, the current (tax) law has to be considered when coins
and tokens are owned or used [81].
cf. the SEC’s statement which explains why e.g. Ethereum is not deemed
as a security:
the Swiss FINMA regarding ICOs:
wegleitung.pdf?la=en (both visited on 2018-10-29)
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
12 C. Ehmke et al.
3.3 Irreversibility and Immutability
Properties, blockchain technology is often attributed for, are its irreversibility and
immutability. Irreversibility means that it is impossible to manipulate already
issued blocks and is therefore the base for the immutability property of blockchains,
which prevents a double-spending of coins [
]. Newer studies demonstrate that
these properties are not an intrinsic property of the technology, although they
are often misunderstood as such. Conte de Leon et al. [
] point out that the
blockchain is neither irreversible nor immutable. The probability that a certain
already included transaction gets modified or removed, decreases over time so
that it becomes unlikely, although it is not completely impossible [85].
One real-world example demonstrating the absence of both the irreversibility
and immutability of blockchains is the Ethereum blockchain. In 2016 a bug in
a smart contract deployed on the Ethereum blockchain (the concept of smart
contracts will be described in more detail in Section 3.5) led to a loss of coins worth
nearly 60,000,000 USD (the ”DAO-bug” [
]). Since the loss was caused by a bug,
respectively its active exploitation (and was considered a hack therefore), there
has been a lot of discussions how to recover the coins [
]. In the end the majority
of the network modified an old block and restarted the blockchain from that
point on. Not all participants appreciated that solution which caused the network
to split up into two parties, one using the ”corrected” blockchain (Ethereum,
”ETH”) and one following the blockchain accepting the bug (Ethereum Classic,
”ETC”) [
]. This incident and the caused hard-fork demonstrate that blocks in
the blockchain are not immutable at all. If enough members agree to modify a
block or reverse certain transactions, they are able to do so.
Apart from bugs in the code of blockchains there might be other reasons why
it could be necessary to be able to modify previous blocks: Matzutt et al. [
published a study showing that the Bitcoin blockchain contains data that might
be illegal to own and to share with others (e.g. child abuse imagery). Since every
participant of the network shares the stored blocks with other (new) participants,
the members of the Bitcoin blockchain distribute these illegal images. Strictly
speaking, the fact that these kinds of images are included in the blockchain makes
it illegal in some countries to participate as a miner node [93].
At the time of writing, there are very few options on how these kind of data
could be erased from the blockchain. One possibility is forcing a hard-fork of
the blockchain (as it happened in the Ethereum network after the DAO-bug)
and starting from a previous point in time again. This would mean that a lot
of transaction data would be lost and payments therefore reverted. Since this
would lead to a possible double-spending of the coins in newer blocks, this would
jeopardize the whole concept of Nakamotos blockchain idea: preventing double-
spending would not be possible anymore. Furthermore, at the moment there is
no mechanism preventing the insertion of illegal data. In the last years there has
been some research on the question of how a blockchain could be implemented
offering the modification of previous blocks (see Ateniese et al. [
] and Puddu
et al. [
]). Another possible solution that might minimize the risks of these
problems is the idea of processing transactions off-chain (see Section 3.8 for more
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 13
information on that topic) or enabling mechanisms in which not all data of the
blockchain have to be cached to be able to participate as a full member in the
network [51].
For developers of smart contracts the irreversibility and immutability poses
a problem for debugging and upgrading their software. As we have seen in the
example before, a bug in a smart contract can usually only be fixed by deploying
a new version of it. Changes to an existing contract are not possible although
there are some design patterns that support dynamic dispatching of function
calls, e.g., the proxy
or proxy delegate pattern
, the
opcode in
Ethereum7or registry contracts.
3.4 Trustlessness – Reaching consensus between participants
Trust is one of the core elements of blockchain technology and being able to
maintain consensus about a shared ledger without the need to trust a central
party or any participant is one of the main features blockchain technology enables.
It is sometimes said that blockchain based systems represent a shift from trust
in institutions (like banks and governments) to trust in cryptographic principles
]. Nakamoto describes the goal of their system as allowing two parties to
transact without the need for a trusted third party [97].
A central question in this context is which cryptographic principles, respec-
tively methods how the network agrees on a commonly shared state, are used
to replace the formerly trusted third parties. Nakamoto builds upon the con-
cepts of Back [
], Dwork and Naor [
] and proposes to use a procedure they
call ”proof-of-work” (PoW). This makes the creation of blocks a resource- and
time-consuming process and they define that the chain of blocks with the highest
accumulated proof-of-work is seen as valid. As mentioned in Section 2.3 this
procedure is often criticized due to its high energy consumption.
Multiple alternatives with different benefits and disadvantages are being
discussed in literature. Some of them will be discussed in the following:
Practical Byzantine Fault Tolerance (PBFT) is a technique by Castro and
Liskov [
] that enables distributed members of a network to efficiently
agree on a common state. One disadvantage of this procedure is that the
participants of the network have to be known in advance [
]. It is therefore
not possible to be used in systems such as Bitcoin that want to enable anyone
to join and leave the network at any time.
Proof-of-Stake (PoS) modifies the initial proof-of-work idea by making it
easier for participants who already own coins to create a new block (the
more coins somebody owns, the easier it is to create a new block) [
5 (visited on 2018-10-24)
6 delegate.html
(visited on
(visited on 2018-10-
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
14 C. Ehmke et al.
The core idea of the concept is that participants who already own coins are
willing to contribute work to stabilize the network because the value of their
coins depends on it. Attacking the network would destabilize it and therefore
jeopardize the value of their own coins as well. Giving participants who own
coins, and therefore are interested in a stable network, more responsibilities
and options to contribute to that goal, seems to be conceived as a good
idea. Nonetheless, some researchers indicate there might be attack vectors
preventing a real-world usage [108].
Proof-of-Activity tries to mitigate the shortcomings of proof-of-work and
proof-of-stake algorithms by proposing a schema in which multiple users
have to work together to create a new block [
]. It could be seen as a
combination of the voting idea of PBFT-protocols with the idea of the proof-
of-work concepts that the right to create blocks should require dedicated
work. Unfortunately, as far as we know, these kinds of methods are not widely
adapted and therefore also lack a deep practical evaluation.
Proof-of-Elapsed-Time is an example of a schema that relies on trusted
computing hardware and uses this to make the creation of blocks verifiable
time-consuming [
]. One example of this technique is the Hyperledger
Sawtooth project [
]. Unfortunately, this technique requires the users to
trust in specific hardware vendors, which could be seen as a contradiction to
Nakamoto’s idea to trust in algorithms instead of specific institutions.
Other approaches: Apart from the previous concepts, there are also various
other attempts to replace the proof-of-work technique with ones that are more
suitable in certain situations. Examples for this are ”more useful” proof-of-
work algorithms like the Primecoin system in which chains of prime numbers
are searched [
], proof-of-burn schemata [
, p. 236f.], proof-of-capacity [
(e.g. used in Storj [
]) or hybrid approaches as combinations that try to
mitigate the disadvantages of the single concepts (cf. [58, p. 173f.], [33]).
As previously mentioned the different concepts have various benefits, prob-
lems and restrictions. Some researches even state that reaching consensus in an
asynchronous system in which a single entity might fail, is impossible altogether
One general distinction between the types of system is the ability for new
participants to join the network. The importance of this difference even led to a
distinction in terminology for blockchain systems steering more towards a closed
or open direction. There are three broad categories of blockchain systems: Private
blockchains, consortium blockchains and public blockchains [
]. Each
category offers a different degree of trustlessness and level of security. In private
blockchains write permissions are restricted to a single entity or company who is
responsible for adding data. Therefore, a distributed consensus mechanism is not
required. The stored data can be visible to the public or its read access restricted.
This blockchain variation is highly centralized but could offer easier auditability
than common databases by using cryptographic elements. Consortium blockchains
employ a consensus process which is usually controlled by a predefined set of
participants (i.e. the consortium). Therefore, write permissions are partially
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 15
decentralized and adding a block to the shared ledger requires the majority of
the participants to confirm its validity. Reading the ledger can also be public or
limited to the consortium itself. Consortium blockchains are sometimes called
hybrid blockchains as they are located between private blockchains, with a single
trusted entity, as one end of the spectrum and public blockchains, without the
need for trust in any participant, on the other end. Public blockchains allow
anyone to read the current state and send valid transactions to be included in the
shared ledger (i.e. writing data to the blockchain). The consensus process is run
by many participants who do not necessarily know or trust each other as anyone
can participate and support the process. This results in a highly decentralized
3.5 Operational purpose
Blockchain technology has been developed initially with the goal to be an alterna-
tive to the traditional money system and was extended over time to become the
base of various use cases [
]. In literature this evolution is separated into three
different stages. Even though different names for the layers exist, they basically
mean the same: Swan [
] and Zhang et al. [
] call them ”Blockchain 1.0”,
”Blockchain 2.0” and ”Blockchain 3.0”, whereas Bodrova [
] and Johnston [
call them ”Type I DApps”,”Type II DApps” and ”Type III DApps” (where DApp
stands for Decentralized Applications). They share the same understanding of
the different layers: The first layer consists only of cryptocurrencies (like Bitcoin)
that use an own blockchain operated by the users of the corresponding currency.
The second layer is based on this, but enhances it by providing smart contracts
that could be used to transfer assets of any kinds between the members of the
network. Applications of the second layer generally do not use an own blockchain
but are part of an existing one in which they are integrated through issued tokens.
The third layer describes all other applications that could be build on top of a
blockchain but that are not focused on asset transactions.
Blockchain 1.0 – Cryptocurrencies As already stated Nakamoto designed their
system as an alternative to the traditional financial system which relied on trust
in different institutions. Instead the system should only rely on the soundness of
mathematical concepts (respectively algorithms) [
]. A lot of subsequent altcoins
followed this approach. The website
lists more than 2.000
different coins at the time of writing. Even though not all listed coins are solely
designed as cryptocurrencies, but provide solutions for the other two layers of
blockchain applications as well, some of the oldest and widely used currencies
(like Litecoin, Dogecoin or Ripple) fall in this category [129].
Blockchain 2.0 – Smart Contracts and Decentralized Code Execution One of the
design decisions of the Bitcoin protocol was the limitation of its script language
(which is used to prove the ownership of a certain address and therefore of the coins
8 (visited on 2018-10-05)
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
16 C. Ehmke et al.
associated with it) to being explicitly Turing-incomplete [
]. The decision was
justified by the need to find a way to prevent attackers from creating transactions
with infinity loops that might lock the verifier of the transaction in never-ending
calculations and prevent them from processing legitimate transactions [
]. At the
moment the Bitcoin reference implementation even further restricts the flexibility
of the script language by accepting only certain predefined types of transactions
In 2012 a proposal called ”The Second Bitcoin Whitepaper” was published
trying to enhance the flexibility of conditions that have to be fulfilled to validate
a transaction [
]. The proposal led to more general propositions about ways to
embed small programs in the blockchain [
]. In 2013 the project Mastercoin
published its whitepaper and proposed an alternative to Bitcoin that allows its
users not only to trade assets but to share small programs with others. These
programs would be executed by all participants of the network when triggered
and could therefore change the global state of the network as it is replicated by
the different participants. These initial ideas were the base for the development
of Ethereum [146] which is the second most valuable blockchain at the moment
(according to
). Currently there are projects trying to enable
users of the original Bitcoin network to execute smart contracts as well. For
example Rootstock/RSK [
] and Counterparty [
] try to establish this feature
through sidechains [27] (see Section 3.8 for more information).
One important aspect is the fact that smart contracts are only the foundation
of the second layer of blockchain applications. Antonopoulos [
] points out that
decentralized applications consist of a (web) front-end, data storage, communi-
cation layers and the back-end software. Only the back-end (or sometimes even
only parts of it [141]) are implemented as smart contracts.
Blockchain 3.0 – Further applications The third layer of blockchains comprises
all applications beyond financial transactions. Antonopoulos states that there are
various use cases for blockchain technology and financial applications are only
the first [
]. Blockchain technology is often said to be for new digital businesses
what TCP/IP has been for the internet: to serve as a technology base layer
enabling new use cases [
]. The possibilities for use cases range from medical
applications [
] over usages in state government [
] to usage in the
context of Internet-of-Things (IoT) [
]. There is ongoing research covering
the topic on how to determine whether a certain business idea might benefit from
using blockchain technology (see e.g. [141,147,91,105]).
Since there are very different business cases in which blockchains can be
integrated, there are also various ways how these applications interact with
the blockchain. Some use the blockchain e.g. to record the timestamps of data
through inserting their hashes into an existing blockchain (see digital notary
services like OriginStamp [
] or Stampery [
]). Other projects try to establish
a decentralized market using blockchain technology (see e.g. [
]). Both concepts
have to face different challenges. The idea of using existing blockchains to store
arbitrary data leads to several discussions about the technical possibilities (e.g.
the introduction of the OP RETURN operator for the Bitcoin validation script
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 17
]) and about the general reasoning for storing data on the blockchain at all
(e.g. the Bitcoin Foundation stated that Bitcoin is not designed for this task
]). Furthermore, since the data included in the blockchain is distributed to
all participants and cannot be erased easily, once it was included, serious legal
concerns came up (see e.g. [
]). Using the blockchain for non-financial use
cases often imposes another difficult problem: how can smart contracts that
are deterministic and are not able to depend on data outside the blockchain
interact with real-world data? One practical example for this kind of problem is a
decentralized insurance policy, e.g. where an immediate compensation for delayed
flights is implemented
. The smart contract of the insurance should automatically
activate the payment process in that case, but due to its nature is not able notice
delays (or other real-world events). Services like [
] offer a solution
to this problem by recording real-world events in the blockchain (where it is
accessible by the smart contracts again), but the research is still ongoing [128].
3.6 Confirmation time and transaction costs
From a business perspective, there are two major flaws with blockchain technology:
On the one hand, sellers are required to wait for a given time until it is certain that
a payment transaction cannot be reversed and on the other hand, publishing a
transaction costs a certain fee that might outstrip the value of the actual payment
]. In the last years a lot of research has been done on how to handle this and
and how this influences the operational costs of the resulting software architecture
(e.g. [
]). An easy solution to reduce the confirmation time would be to decrease
the average time between blocks (in Bitcoin this is about ten minutes). Several
altcoins and alternative blockchains have done so [
]. Unfortunately, if the
blockchain is designed as a linear chain of blocks (as its name suggests) this
might lead to problems since a smaller blocktime inevitably leads to a higher rate
of forks in the blockchain (cf. [
]), which in turn leads to a waste of energy since
all concurrent blocks but the ones of the longest chain (respectively that one with
the highest cumulated proof-of-work) are dismissed [
, p. 247]. Sompolinsky et
al. [
] present a procedure for interpreting the blockchain as a directed graph
and taking sibling blocks into consideration when determining which path of the
blockchain is the valid one. Because of this, the computational power included
in sibling blocks is not completely wasted anymore, which reduces the need to
avoid forks. The (adapted) implementation of the proposed procedure enabled
alternative blockchains like Ethereum to reduce their block time significantly (on
average 12 seconds for Ethereum versus 10 minutes for Bitcoin) [34].
Other concepts follow this idea and try to take the ”stale” blocks, which
would be dismissed in Bitcoin-like concepts, into consideration when building
the block structure. For example IOTA’s data structure The Tangle [
] groups
transactions in a directed acyclic graph (DAG) instead of a single linear chain.
In this case the energy used to create the blocks not belonging to the main
chain would not be wasted but used to further stabilize it. Another benefit
9see e.g. (visited 2018-10-29) or P¨uttgen and Kaulartz [114]
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
18 C. Ehmke et al.
of this procedure is that the transactions grouped in sibling blocks would not
be ignored by the network but would belong to the replicated data structure
known by all participants independently of the fact that they are not part of the
main chain. Hashgraph [
] proposed to use an adapted consensus protocol
in which the constantly forking of the chain is intended and the agreement of
the other participants of the network to a certain network state can be proven
mathematically instead of waiting for them to explicitly express it. This procedure
leads to a system in which forks are nothing negative that should be avoided and
is therefore able to issue blocks with a very small block time. To give a holistic
picture it is necessary to add that, to our knowledge, Hashgraph is not widely
used yet (maybe due to the fact that it is patented [
]) and that The Tangle was
criticized a lot because it is difficult for researchers outside the IOTA company
to independently evaluate the proposed technology (cf. [103]).
There are also projects trying to solve the confirmation time problem of
Bitcoin without using a DAG data structure. Eyal et al. [
] propose a concept
that does not only use blocks but also so-called microblocks that are issued every
10 seconds (while the ”full” blocks are still issued roughly every 10 minutes). The
microblocks are issued by the creator of the last full block and do not require a
proof-of-work. Therefore, the network is able to process more transactions in less
time compared to a (Bitcoin-like) system in which every block is secured by such
Apart from the confirmation time of transactions, the second problem that
prevents the wide usage of blockchain technology is the required transaction
fees. Nakamoto [
] introduced them as an incentive for the miners to process
transactions of other users. In an addition to the transaction fee there is also
a block reward that is used to incentivize miners to participate in the Bitcoin
network. Because Bitcoin is designed as a currency with a fixed maximum amount
of coins, the block reward is halved roughly every four years [
, p. 214]. The
halving of the mining reward might has some interesting consequences. While it
is possible that the transaction fee could simply rise to compensate the miners for
the decreasing block reward (even though studies from 2015 [
] and the actual
transaction fee development of the last years (see Figure 1) seem to disprove
this theory), there might also be other consequences like attacks on the network
to validate only certain transactions with an especially high transaction fee (cf.
]). There are research projects trying to solve these problems, e.g. the IOTA
project states that there are no transaction fees in their network
. Projects
like Soluna [
] try to use renewable energy to mine new blocks and might be
able to do so economically without requiring huge transaction fees. Furthermore,
there are concepts like off-chaining and sidechains trying to separate multiple
small transactions from the main chain (using it only as a security reference)
that might be able to offer solutions in which the transaction costs could be
reduced significantly compared to a solution using the main blockchain for every
transaction (see the following Section 3.8 for more information).
see paragraph ”Zero fees” at IOTAs Q&A page (
whatisiota.shtml (visited on 2018-10-16))
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 19
3.7 Scalability
Several problems of blockchain technology are summarized under the term
scalability. One is the amount of transactions the system can process in a certain
time. Since Bitcoin as the origin of blockchain technology is seen as an alternative
to the traditional payment processors, Bitcoins ability to process transactions is
often compared to traditional credit card vendors. It is often stated that Bitcoin
can process a maximum of 7 transactions per second [
] while Visa is said
to be able to process a peak number of 56,000 transactions per second [
Independent of the question of how long it takes until a transaction is (practically)
irreversibly included in the blockchain (see the previous Section 3.6) this is quite
an important consideration since it is often sufficiently secure enough when a
certain transaction was included in the blockchain at all (cf. [3, p. 25]).
One solution for this problem is called ”Segregated Witness” (SegWit) and
was proposed in the Bitcoin Improvement Proposals BIP-141, BIP-143, BIP-144
and BIP-145
. In addition to other improvements the core idea of the concept
was to change how the size of transactions is counted. In fact, following the
proposal, the locking script that is used to prove the ownership of a certain
coin to be spent, will not be counted anymore when calculating the size of a
transaction. This led to a mechanism which allows more transactions to be
included in a block while maintaining the same blocksize as before (which is
fixed at 1 MB) [
, p. 329ff.]. For a proposal to additionally increase the maximum
block size to 2 MB no consensus between the participants could be reached [
Another aspect of scalability is the way how new participants can be integrated
into the network: How easily can the network scale by distributing it to more
network members? Although this question is also influenced by the block size,
the accumulated size of the whole blockchain is relevant here. The Bitcoin system
expects each full member to validate incoming transactions which is only possible
if they know about the current state (respectively the amount of coins all addresses
possess) of the network. Since the current state of the network is not distributed
directly, but has to be calculated by processing all accepted transactions of
the network again, new participants have to download the whole blockchain [
p. 32ff]. The Bitcoin blockchain contains of more than 180 GB of data at the
time of writing (Figure 2 visualizes the growing of the Bitcoin blockchain over
time). The huge amount of data that has to be downloaded by new participants
might be a barrier for their involvement [
]. It is sometimes argued that
new participants do not necessarily need the whole blockchain because there are
lightweight verification protocols (cf. ”Simplified Payment Verification” (SPV)
in Nakamoto’s initial paper [
]), but they rely on other participants to have
downloaded the whole blockchain and do not enable its users to create new blocks.
Solutions like [
] or [
] try to introduce approaches in which old transactions
could be dismissed and do not have to be downloaded by new participants
anymore. Therefore space and time requirements for new participants could be
the BIPs can be found here:
(visited on 2018-10-
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
20 C. Ehmke et al.
reduced, which in turn might encourage more people to actively participate in
the verification and creation of blocks.
Fig. 2.
Size of the Bitcoin blockchain in MB according to
de/charts/blocks-size (visited on 2019-01-21)
Other approaches like sidechains and off-chaining (as explained in the following
section) propose to reduce the number of operations required to be executed on
the main chain and therefore would help to slow down the growing of the chain.
Nevertheless, new participants would still need to download the previous data.
3.8 Sidechains and Off-Chaining
Scalability as outlined in the previous section poses several challenges for designing
blockchain technologies and has to be kept in mind when creating decentralized
applications. Buterin et al. summarize the challenges of blockchain technology in
three fundamental properties
: Decentralization, scalability and security. The
”scalability trilemma” (cf. [
]) states that it is not possible for a blockchain
system to fully support all three properties simultaneously but only two of them.
There are three possible combinations: (1) A centralized system (e.g., a web
server) offers high scalability and security by being able to add resources on
demand (e.g., by adding more RAM to its virtual machine). In contrast, (2)
a highly decentralized system offers high security by distributing its elements
on many nodes, which comes with the drawback of low scalability. (3) A high
degree of decentralization and high scalability can be achieved by simplifying the
consensus process, which in turn results in less security. For example the current
implementation of Ethereum focuses on decentralization and security, whereas
scalability remains as an open issue. There are several proposed solutions which
are currently under examination and development.
(visited on 2018-10-
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 21
Sidechains are built on top of a main blockchain (e.g. Ethereum) and can
use a custom consensus algorithm with own public nodes (e.g. Plasma[
] or
Loom Network DAppChains [
]). This concept increases the performance, makes
all transaction on the sidechain publicly visible and simultaneously secures the
execution of transactions as the sidechain is connected to the main chain.
In contrast to sidechains, ”off-chain” interactions are executed independently
from the main chain [
]. During the interaction between two parties, signed
receipts of small transactions are exchanged and only the final result will be
written to the main chain (in case both parties agree). Off-chaining concepts
can be separated into three categories: (1) Transactional off-chaining aims at
exchanging tokens (e.g. ERC-20 tokens in Raiden [
]) or coins (Bitcoins in
Lightning [
]) between two parties via channels that are separated from the
main chain. (2) Storage off-chaining aims at providing a means to store arbitrary
data (e.g. text and binary files) usually to a decentralized storage network such
as IPFS [
], Sia [
] or Storj [
]. This is due to the fact that storage is very
expensive on blockchains such as Ethereum and Bitcoin [
]. (3) Computational
off-chaining such as zero-knowledge proofs (see e.g. Zcash, zkSNARKs) can be
used because complex computations are not only expensive to be executed, e.g.
in a smart-contract, but can also be technically impossible due to the blocksize
limit which allows only a certain amount of instructions per block.
3.9 Centralized, Decentralized and Distributed Architectures
In the Bitcoin paper Nakamoto [
] states that their technology should enable two
parties to transact directly with each other. Later, they use the term ”peer-to-peer
distributed timestamp server” [
] to describe the proposed Bitcoin system as a
solution to enable this. This wording is controversial because in literature the
terms ”decentralized ” and ”distributed” are often used synonymously to describe
blockchain-like systems (see e.g. [
]). Internet discussions (e.g. [
] or
]) often refer to an explanation of Baran [
] to demonstrate the differences
between these two terms. Figure 3 is taken from the original paper from Baran
and visualizes their distinction: In a centralized system all nodes are connected to
a single central node. In a decentralized system there are multiple nodes serving
as bridges between the others. In a fully distributed system any node is connected
with all the others via more than one route and therefore preventing the creation
of essential nodes, which would split the network in case of an outage.
Independent from the distinction whether Bitcoin is distributed or just de-
centralized, it is sometimes questioned whether it is even not-centralized at all.
Arguments against seeing the technology as not-centralized criticize the central
role the developers of the reference implementation, mining-pool operators and
the online wallet and exchange operators play [
]. Baran uses their dis-
tinction between the terms centralized,decentralized and distributed mainly to
discuss the ability of the network to handle failures of (important) parts of the
network and its resilience against attacks. Both aspects have also be considered
when discussing whether current blockchain systems are not-centralized at all.
Event though there is ongoing research trying to develop consensus mechanisms
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
22 C. Ehmke et al.
Fig. 3.
Distinction between centralized, decentralized and distributed systems according
to Baran (Figure taken from [17])
that cannot be outsourced to mining pools [
] and that are not easily adaptable
for specialized hardware [
], it still has to be questioned whether the
current networks can handle specific attacks while the consensus mechanism
heavily rely on certain hardware and vendors (cf. [
]). In an online article
Buterin [
] picks up this discussion and argues that the distinction of Baran
(see Section 3) is misleading. Instead they propose to consider three dimensions
of (de-)centralization:
Architectural (de-)centralization – How many physical computers is a system
made up of?
Political (de-)centralization – How many individuals or organizations practi-
cally control these computers?
Logical (de-)centralization – Is the system, although distributed to multiple
physical computers, representing one logical unit?
They argue that blockchain systems are often politically decentralized (since
no single organization controls them) and architecturally decentralized (since the
system is designed to be distributed to a lot of physically independent computers)
but logically centralized (since it shares one logical state all participants agree
on) [
]. Nonetheless, their claim that systems like Ethereum are politically
decentralized is often doubted: First, as already said, because of the central role
of mining pools, exchanges and online wallet operators, second because of the
important role of the reference implementation developers. Laurie [
] argues
that e.g. Bitcoin implemented a checkpoint concept in its blockchain to increase
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 23
scalability and make the integration of transactions more deterministic (since
it is not longer possible to modify the chain before the newest checkpoint, data
in these blocks are not only unlikely to be modified anymore but it is nearly
impossible to do so). The members of the network have to agree which block is
considered a checkpoint. Laurie argues that this is done by a group of developers
and not in a decentralized manner [
]. To counter this critique, the Ethereum
community implemented a decentralized procedure that defines checkpoint blocks
Other blockchain implementations like private or consortium chains (see
Section 3.4) might lead to a different degree of (de-)centralization. Therefore, it
is still an area of ongoing research and should be considered when developing
blockchain applications (cf. [141]).
4 Decentralized Consensus Technology
The huge amount of projects and research, both from academia and industry,
concerning blockchain technology shows that it is a topic of huge interest and
rapid development. In the previous Section 3 we gave an overview about the wide
range of research topics, the problems researchers are trying to solve and the
benefits and disadvantages of those solutions. Furthermore, the overview shows
that there is a quick evolution of the initial concept presented by Nakamoto.
Several of the presented concepts modify or remove core concepts of Nakamotos
approach but there are also several projects adding new abilities to the systems
they develop that were not mentioned or envisioned in the initial paper of the
These variations of the concept of Nakamoto led to an interesting question:
Is the term ”blockchain” still appropriate to describe a technology which has
modified core concepts of the blockchain idea? To give a more catchy example:
Schiener, co-founder of IOTA, describes the IOTA concepts as being a ”Blockchain
without Blocks and the Chain” [
]. Do we still consider such a system a
blockchain or is another term needed to describe such a huge deviation from the
initial concept?
We argue that the latter is the case. A proverb, Sokrates is often attributed
for, states that the beginning of wisdom is the definition of terms. This might also
be true for technical topics. We believe that a lot of the projects presented in the
previous section are not modified versions of the initial Bitcoin-like concept but
instead developed into independent technologies. To describe them accurately
we propose to use the term ”Decentralized Consensus Technology” (DCT). Note
that this term is not new: Chen et al. [
] already used the term Decentralized
Consensus System in 1992 within a slightly different context and Glaser et al. [
picked it up in context of blockchain systems. Unfortunately, to our knowledge,
this terminology is not widely used in literature yet.
Our understanding of the terminology and the relationship of the different
terms is visualized in Figure 4. The following Section 4.1 will briefly explain the
differentiation and will try to give examples for the different categories. Despite
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
24 C. Ehmke et al.
the differences between the systems summarized with the term Decentralized
Consensus Technology, we still believe that there are shared properties. We will
elaborate further on this in Section 4.2.
Decentralized Consensus Technology
Decentralized Ledger
Blockchain Tangle
Fig. 4. Decentralized Consensus Technology and its subsets
4.1 Differentiation of Distributed Ledger Technology
We described before that a lot of projects and innovations are based on Bitcoin-
like blockchain technology but sometimes modify important properties of the
original concept. Nevertheless, they are very often still described with term
blockchain technology. While this is probably correct in some cases, there are
counterexamples for which it is plainly misleading: IOTA’s Tangle for example
(”Blockchain without Blocks and the Chain” [
]) or Hashgraph, which clearly
use different data structures and have steered away from the initial concept
in important aspects. To regard this fact in literature the term ”Decentralized
Ledger Technology” is sometimes used (e.g. [152]).
Nonetheless, we still deem that term to be too specific for some applications:
It suggests that the members of the network in question are trying to agree on
a commonly available ledger (e.g. the transactions record). On the other hand
there are many projects that use a technology inspired by Bitcoin that does
not necessarily have a ledger. Considering projects like IPFS [
], respectively
Filecoin [
], it becomes clear that there are also projects agreeing on elements
other than a shared ledger. The Filecoin network, for example, agrees on a
shared (virtual) file system. Even though there are projects combining these
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 25
ideas with a ledger (like Storj does to create a payment and incentive system
within their network [
]), it becomes apparent that the term Distributed Ledger
Technology is too restrictive for these kinds of projects. Another example would
be the Google project Certificate Transparency
which aims at making SSL/TLS
certificates more secure. One of the founders of the project lists several arguments
why Bitcoin-like blockchain projects are not suitable for the project goals [
Nevertheless, the implementation of the project has some remarkable similarities
to the initial Bitcoin ideas (e.g. the Log Servers are using append-only data
structures to store the monitored certificates). Even though the Log Servers
do not directly agree on one global shared log, the network is able to agree
on shared knowledge about which certificates have been issued officially and
are valid therefore. Following this argumentation, the term Distributed Ledger
Technology is still too restrictive to cover the different projects. We propose to
use the term Decentralized Consensus Technology instead. The example of the
Certificate Transparency project can also be used to argue, why we propose
to use the term ”Decentralized Consensus Technology” instead of ”Distributed
Consensus Technology”: There are several projects that favor a decentralized
architecture (following the definition of Baran [
]) but do not necessarily are
designed in a fully distributed way (in which multiple paths exist between nearly
every node; see Figure 3). Further examples for systems being decentralized but
not always distributed are some consortium blockchains (see Section 3.4).
4.2 Properties of Decentralized Consensus Technology
In Section 3 we presented several projects and research approaches that are based
on Nakamoto’s blockchain concept and further evolved it. We showed that there
is no common agreement about the terms and properties of these technologies
and therefore proposed the term Decentralized Consensus Technology. Given
the presented research and literature (e.g. [
]) we propose to use the
following three properties as a base line for Decentralized Consensus Technology:
– Decentralization:
One characteristic of most evaluated projects and re-
search approaches was the common goal to replace a, previously central,
service with a decentralized or distributed solution. This is even true for
private and consortium blockchains which do not aim at including every
willing participant but only some selected ones.
Trustlessness and Resilience:
Another property is the general agreement
to develop a solution that helps to shift the needed trust from people or
institutions to hardware- or software-based algorithms. Furthermore, all
approaches we know about are based on the assumption that participants
might spread, consciously or by mistake, false and fraudulent messages.
Eventual Consensus and Growing Confidence:
The last property we
observed during our studies was the common goal to agree on a shared state
with all other network members. Herein, the state might be both a ledger or
13 (visited on 2018-10-19)
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
26 C. Ehmke et al.
something abstract like the certificates that are seen as valid or the state after
executing decentralized code. Furthermore, all approaches known to us, are
presenting a methodology in which fraudulent modifications of already issued
messages are getting harder and therefore unlikelier the older the message,
respectively the block, is.
In addition to these properties, we believe that there are further, use case
specific ones. Consider a cryptocurrency that should be developed for highly
privacy concerned users, in which case anonymity might also be a key property
of the new system. On the other hand, if the application goal depends on smart
contracts, the ability to execute code in a decentralized environment might be a
core attribute of the system. Wessling et al. [
] propose to use the trust property
in order to determine whether and where a blockchain should be integrated into
the planned application architecture. We propose to do this for other properties
as well. Properties that should be considered are the following:
Privacy describes the degree of anonymity, respectively retraceability, of
transactions in the system. Is it possible to identify the real world identity of
the sender and receiver of transactions?
Participation incentive means the way how honest behavior is incentivized
and dishonest discouraged. This decision affects the used consensus algorithm,
respectively is affected by the selected one.
Irreversibility and immutability deals with whether transactions that have
been accepted by the network can be revoked later on. Is it possible to revert
actions unwanted by the majority of the network?
Operation purpose describes the overall goal of the system. Should it serve
as a decentralized currency or should it be possible to execute arbitrary
computations in a decentralized system?
Confirmation time and Transaction costs have to be considered when design-
ing or selecting a suitable foundation of the application to be developed. Both
affect the stability and security of the network but might greatly influence
how a new application has to be used.
Ability to externalize transactions and computations enables possibilities
to decrease the financial and time costs of transactions in the network.
Sidechains and Off-Chaining are ways how frequent or complex transactions
and calculations can be securely included in the network without negatively
influencing the other participants.
Scalability possibilities are ways how the performance of the network can be
increased without decreasing the overall security. Several ways have been
proposed in the previous years how this can be archived but the impacts
and consequences of these ways have to be considered when designing a new
application using such a network.
5 Related Work
At the time of writing, there are only a few papers in the context of our work.
For example Bonneau et al. [
] and Conte de Leon et al. [
] evaluate research
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 27
questions and challenges in the context of cryptocurrencies. In contrast to this
work they evaluate the strengths and weaknesses of blockchain-like systems
without using this knowledge to advocate a new term describing systems that
broadly differ from the initial Bitcoin concept. Furthermore, Conte de Leon et
al. [
] even use the term ”distributed ledger system” throughout their paper
without describing how this differs from blockchain systems, but uses both
descriptions synonymously. Both Bonneau et al. [
] and Conte de Leon et
al. [
], of course, only consider work that was known during the time of writing
of their articles. Since Decentralized Consensus Technology is a fast developing
field of research a lot of important aspects and improvements of the recent years
are therefore not present and considered in their work but in ours.
There are different works trying to identify properties of blockchain systems
(especially Bitcoin), such as [
], [
], [
] or [
]. Approaches like [
] focus
a broader and less technical view on that topic and studies like [
] evaluate
the properties of such systems with focus on the attributes decentralisation,
consistency and scalability in comparison with the CAP theorem of traditional
database systems. Furthermore, there are efforts from the National Institute of
Standards and Technology (NIST) [
] and the International Organization for
Standardization (ISO)
to define terms in the context of Decentralized Consensus
Technology. To our knowledge, both exclusively focus on blockchain technology
(like Bitcoin) and do not propose a more generic term to cope with the properties
new research approaches modify, remove or add. In contrast to our contribution,
their target audience has none or little knowledge of blockchain technology (cf.
[149, p. iii]).
6 Conclusion
Starting with the Bitcoin concept a lot of research has been done in the context
of blockchain technology and applications. Unfortunately, there is no commonly
shared knowledge about terms in that field of research. Various research papers
start with a (new) introduction to that topic and partly new terms. The core
concept as implemented by Bitcoin is often called blockchain technology because
(financial) transactions are bundled in blocks which refer to their ancestors and
therefore form a chain. Due to their cryptographic implementation and game
theoretical concepts, the confidence that a certain block cannot be modified, grows
over time. The initial concept by Nakamoto has some problems, like scalability
issues, attack vectors or confirmation time and costs for new transactions. In the
last years a lot of research, both by academical and industrial researchers, has
been done to address these problems. Some of them modify the core principles
of the original concept significantly or focus on other properties than the initial
proposal. It has to be questioned whether these new concepts still adequately
could be described as blockchain technology. Consider technologies explicitly
refusing to be seen as blockchain technology but following similar ideas. We
proposed to use the term Decentralized Consensus Technology as a general
14 (visited on 2018-10-22)
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
28 C. Ehmke et al.
category instead. Decentralized Consensus Technology consists of decentralized
ledger and non-ledger technologies. Blockchain technology in turn is only one
variant of Decentralized Ledger Technology.
Furthermore, we identified three main characteristics of Decentralized Con-
sensus Technologies:decentralization,trustlessness and its ability to eventually
reach consensus. Depending on the use case of the specific implementation other
properties also have to be considered. We gave an overview of the current research
and showed which properties of the initial concept are modified or removed and
which new attributes are added by the various scientific contributions. We used
this insights to further derive use case specific properties like privacy,participa-
tion incentive,irreversibility and immutability,operation purpose,confirmation
time,transaction costs,ability to externalize transactions and computations and
scalability possibilities. We propose to take these terminology and properties into
consideration when evaluating, describing and modelling the creation or usage of
Decentralized Consensus Technology in upcoming projects and research.
Andreas M. Antonopoulos: Introduction to bitcoin (2016),
Androulaki, E., Karame, G.O.: Hiding transaction amounts and balances in bitcoin.
In: Holz, T., Ioannidis, S. (eds.) Trust and Trustworthy Computing. pp. 161–178.
Lecture Notes in Computer Science, Springer International Publishing (2014)
3. Antonopoulos, A.M.: Mastering bitcoin. O’Reilly, 1. edition edn. (2015)
Antonopoulos, A.M.: Mastering Bitcoin: Programming the Open Blockchain.
”O’Reilly Media, Inc.” (2017)
Antonopoulos, A.M., Wood, G.: Mastering Ethereum: Building Smart Con-
tracts and Dapps. O’Reilly Media, Incorporated (2018),
ethereumbook/ethereumbook, google-Books-ID: SedSMQAACAAJ
Armknecht, F., Karame, G.O., Mandal, A., Youssef, F., Zenner, E.: Ripple:
Overview and outlook. In: Conti, M., Schunter, M., Askoxylakis, I. (eds.) Trust
and Trustworthy Computing. pp. 163–180. Lecture Notes in Computer Science,
Springer International Publishing (2015)
Aru, I.: Can blockchain technology survive without cryptocurrencies?
(2018), without-
Ateniese, G., Magri, B., Venturi, D., Andrade, E.: Redactable blockchain
- or - rewriting history in bitcoin and friends. In: 2017 IEEE Euro-
pean Symposium on Security and Privacy (EuroS P). pp. 111–126 (2017).
Atzei, N., Bartoletti, M., Cimoli, T.: A survey of attacks on ethereum smart
contracts (SoK). In: Maffei, M., Ryan, M. (eds.) Principles of Security and Trust.
pp. 164–186. Lecture Notes in Computer Science, Springer Berlin Heidelberg
Azaria, A., Ekblaw, A., Vieira, T., Lippman, A.: MedRec: Using blockchain
for medical data access and permission management. In: 2016 2nd Inter-
national Conference on Open and Big Data (OBD). pp. 25–30 (2016).
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 29
Back, A.: Hashcash - a denial of service counter-measure (2002),
Back, A., Corallo, M., Dashjr, L., Friedenbach, M., Maxwell, G., Miller, A.,
Poelstra, A., Tim´on, J., Wuille, P.: Enabling blockchain innovations with pegged
sidechains (2014),
Badertscher, C., Garay, J., Maurer, U., Tschudi, D., Zikas, V.: But why
does it work? a rational protocol design treatment of bitcoin. In: Advances
in Cryptology EUROCRYPT 2018. pp. 34–65. Lecture Notes in Computer
Science, Springer, Cham (2018). 2, 8 2
Baird, L.: The swirlds hashgraph consensus algorithm: Fair, fast, byzantine fault tol-
erance (2016),
Baird, L.: Methods and apparatus for a distributed database within a network
Bamert, T., Decker, C., Elsen, L., Wattenhofer, R., Welten, S.: Have a snack, pay
with bitcoins. In: 13th IEEE International Conference on Peer-to-Peer Computing.
pp. 1–5 (2013).
Baran, P.: On distributed communications networks. IEEE
Transactions on Communications Systems
(1), 1–9 (1964).
Bartoletti, M., Pompianu, L.: An analysis of bitcoin OP return metadata. In: Fi-
nancial Cryptography and Data Security. pp. 218–230. Lecture Notes in Computer
Science, Springer International Publishing (2017)
Bartolucci, S., Bernat, P., Joseph, D.: SHARVOT: Secret SHARe-based VOTing
on the blockchain. In: Proceedings of the 1st International Workshop on Emerging
Trends in Software Engineering for Blockchain. pp. 30–34. WETSEB ’18, ACM
Beck, R., Czepluch, J.S., Lollike, N., Malone, S.: Blockchain - the gateway to
trust-free crypthographic transactions. In: Twenty-Fourth European Conference
on Information Systems (ECIS). p. 15 (2016)
Beikverdi, A., JooSeok Song: Trend of centralization in bitcoin’s distributed
network. In: 2015 IEEE/ACIS 16th International Conference on Software Engi-
neering, Artificial Intelligence, Networking and Parallel/Distributed Computing
(SNPD). pp. 1–6. IEEE (2015).,
Belizaire, J.: Soluna powering the blockchain (2018),
content/uploads/2018/09/Soluna white paper v1.2 20180905.pdf
Ben-Or, M., Goldwasser, S., Wigderson, A.: Completeness theorems for non-
cryptographic fault-tolerant distributed computation. In: Proceedings of the Twen-
tieth Annual ACM Symposium on Theory of Computing. pp. 1–10. STOC ’88,
ACM (1988).,
Benet, J.: IPFS - content addressed, versioned, p2p file system (2018),
Bentov, I., Gabizon, A., Mizrahi, A.: Cryptocurrencies without proof of work. In: Fi-
nancial Cryptography and Data Security. pp. 142–157. Lecture Notes in Computer
Science, Springer, Berlin, Heidelberg (2016).
53357-4 10,
4 10
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
30 C. Ehmke et al.
Bentov, I., Lee, C., Mizrahi, A., Rosenfeld, M.: Proof of activity:
Extending bitcoin’s proof of work via proof of stake [extended ab-
stract]. ACM SIGMETRICS Performance Evaluation Review
(3), 34–37
Bocek, T., Stiller, B.: Smart contracts - blockchains in the wings. In: Linnhoff-
Popien, C., Schneider, R., Zaddach, M. (eds.) Digital Marketplaces Unleashed, pp.
169–184. Springer Berlin Heidelberg (2018).
49275-8 19, 662-49275-8 19
Bodrova, A.: What are decentralized applications (dapps) (2017), decentralized-
Boehm, F., Pesch, P.: Bitcoin: A first legal analysis. In: Financial Cryptography
and Data Security. pp. 43–54. Lecture Notes in Computer Science, Springer,
Berlin, Heidelberg (2014). 4,
// 1 4
Bohr, J., Bashir, M.: Who uses bitcoin? an exploration of the bitcoin community.
In: 2014 Twelfth Annual International Conference on Privacy, Security and Trust.
pp. 94–101 (2014).
Bonneau, J., Miller, A., Clark, J., Narayanan, A., Kroll, J.A., Felten, E.W.:
SoK: Research perspectives and challenges for bitcoin and cryptocurrencies.
In: 2015 IEEE Symposium on Security and Privacy. pp. 104–121 (2015).
Bonneau, J., Narayanan, A., Miller, A., Clark, J., Kroll, J.A., Felten, E.W.:
Mixcoin: Anonymity for bitcoin with accountable mixes. In: Christin, N., Safavi-
Naini, R. (eds.) Financial Cryptography and Data Security. pp. 486–504. Lecture
Notes in Computer Science, Springer Berlin Heidelberg (2014)
Bradbury, D.: In blocks [security bitcoin]. Engineering Technology
(2), 68–71
Buterin, V.: Ethereum White Paper - A Next-Generation Smart Contract and
Decentralized Application Platform (2014),
Buterin, V.: The meaning of decentralization (2017),
@VitalikButerin/the-meaning-of-decentralization- a0c92b76a274
Buterin, V.: A prehistory of the ethereum protocol (2017),
Buterin, V., Griffith, V.: Casper the friendly finality gadget. arXiv:1710.09437 [cs]
Cachin, C.: Blockchain, cryptography, and consensus (2017),
, ITU Workshop on ”Security
Aspects of Blockchain”
Carlsten, M., Kalodner, H., Weinberg, S.M., Narayanan, A.: On the instability of
bitcoin without the block reward. In: Proceedings of the 2016 ACM SIGSAC Con-
ference on Computer and Communications Security. pp. 154–167. CCS ’16, ACM
Castro, M., Liskov, B.: Practical byzantine fault tolerance. In: Proceedings of the
Third Symposium on Operating Systems Design and Implementation. vol. 99, pp.
173–186 (1999)
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 31
Chatterjee, R.: An overview of the emerging technology: Blockchain. In: 2017 3rd
International Conference on Computational Intelligence and Networks (CINE).
pp. 126–127 (2017).
Chen, L., Xu, L., Shah, N., Gao, Z., Lu, Y., Shi, W.: On security anal-
ysis of proof-of-elapsed-time (PoET). In: Stabilization, Safety, and Security
of Distributed Systems. pp. 282–297. Lecture Notes in Computer Science,
Springer, Cham (2017). 19,
// 1 19
Chen, M., Wu, K., Yu, P.S.: Efficient decentralized consensus protocols in
a distributed computing system. In: [1992] Proceedings of the 12th Interna-
tional Conference on Distributed Computing Systems. pp. 426–433 (1992).
Chohan, U.W.: The cryptocurrency tumblers: Risks, legality and oversight. SSRN
Scholarly Paper ID 3080361, Social Science Research Network (2017),
45. Protocol specification
counterparty (2018),
https:// specification/
46. Dai, W.: b-money (1998),
Decker, C., Wattenhofer, R.: Information propagation in the bit-
coin network. In: IEEE P2P 2013 Proceedings. pp. 1–10 (2013).
Duffy, J.M.: Everything you need to know about loom network, all in one place (up-
dated regularly) (2018),
need-to-know-about- loom-network- all-in- one-place- updated-regularly-
Dwork, C., Naor, M.: Pricing via processing or combatting junk mail. In: Brickell,
E.F. (ed.) Advances in Cryptology CRYPTO 92. pp. 139–147. Lecture Notes in
Computer Science, Springer Berlin Heidelberg (1993)
Eberhardt, J., Tai, S.: On or off the blockchain? insights on off-chaining computa-
tion and data. In: Service-Oriented and Cloud Computing. pp. 3–15. Lecture Notes
in Computer Science, Springer, Cham (2007).
67262-5 1, 5 1
Ehmke, C., Wessling, F., Friedrich, C.M.: Proof-of-property: a lightweight and
scalable blockchain protocol. In: Proceedings of the 1st International Work-
shop on Emerging Trends in Software Engineering for Blockchain. pp. 48–51.
ACM Press (2018).,
Ekblaw, A., Barabas, C., Harvey-Buschel, J., Lippman, A.: Bitcoin and the myth
of decentralization: Socio-technical proposals for restoring network integrity. In:
2016 IEEE 1st International Workshops on Foundations and Applications of Self*
Systems (FAS*W). pp. 18–23 (2016).
Eyal, I., Gencer, A.E., Sirer, E.G., Van Renesse, R.: Bitcoin-NG: A scalable
blockchain protocol. In: Proceedings of the 13th Usenix Conference on Networked
Systems Design and Implementation. pp. 45–59. NSDI’16, USENIX Association
Eyal, I., Sirer, E.G.: Majority is not enough: bitcoin mining is vulnerable. Com-
munications of the ACM
(7), 95–102 (2018).,
Finestone, M.: Game theory and blockchain — coinsquare news (2017),
// blockchain/
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
32 C. Ehmke et al.
Fischer, M.J., Lynch, N.A., Paterson, M.S.: Impossibility of distributed consensus
with one faulty process. Journal of the ACM (JACM)
(2), 374–382 (1985).,
Foley, S., Karlsen, J.R., Putni¸s, T.J.: Sex, drugs, and bitcoin: How much illegal
activity is financed through cryptocurrencies? SSRN Electronic Journal (2018).,
Franco, P.: Understanding bitcoin: cryptography, engineering and economics.
John Wiley & Sons (2015),
OCLC: 894170560
Gao, X., Clark, G.D., Lindqvist, J.: Of two minds, multiple addresses, and
one ledger: Characterizing opinions, knowledge, and perceptions of bitcoin
across users and non-users. In: Proceedings of the 2016 CHI Conference
on Human Factors in Computing Systems. pp. 1656–1668. CHI ’16, ACM
Gencer, A.E., Basu, S., Eyal, I., Sirer, E.G.: Decentralization in bitcoin and
ethereum networks. In: Financial Cryptography and Data Security 2018. p. 18
Gervais, A., Karame, G.O., Capkun, V., Capkun, S.: Is bitcoin a de-
centralized currency? IEEE Security & Privacy
(3), 54–60 (2014).,
Gervais, A., Ritzdorf, H., Karame, G.O., Capkun, S.: Tampering with the
delivery of blocks and transactions in bitcoin. In: Proceedings of the 22Nd
ACM SIGSAC Conference on Computer and Communications Security. pp. 692–
705. CCS ’15, ACM (2015).,
Gipp, B., Meuschke, N., Gernandt, A.: Decentralized trusted timestamping
using the crypto currency bitcoin (2015),
Glaser, F., Bezzenberger, L.: Beyond cryptocurrencies - a taxonomy of decentralized
consensus systems. In: 23rd European Conference on Information Systems (ECIS).
p. 19 (2015)
Goranovi´c, A., Meisel, M., Fotiadis, L., Wilker, S., Treytl, A., Sauter, T.: Blockchain
applications in microgrids an overview of current projects and concepts. In: IECON
2017 - 43rd Annual Conference of the IEEE Industrial Electronics Society. pp.
6153–6158 (2017).
Grier, D.A.: All that glitters is not gold. Computer
(4), 116–116 (2014).
Gries, S., Meyer, O., Wessling, F., Hesenius, M., Gruhn, V.: Using blockchain
technology to ensure trustful information flow monitoring in CPS. In: 2018 IEEE
International Conference on Software Architecture Companion (ICSA-C). pp.
35–38 (2018).
Heilman, E., Kendler, A., Zohar, A., Goldberg, S.: Eclipse attacks on bit-
coin’s peer-to-peer network. In: Proceedings of the 24th USENIX Conference
on Security Symposium. pp. 129–144. SEC’15, USENIX Association (2015),
Hern, A.: Bitcoin currency could have been destroyed by ’512014),
destroyed-51-attack-ghash- io
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 33
Hornyak, T.: One group controls 51 percent of bitcoin mining, threatening secu-
rity sanctity (Jun 2014),
price-dips-as-backers- fear-mining- monopoly.html
Hrones, M.: Segwit activated: How it works & what’s next for bitcoin (2017),
Iansiti, M., Lakhani, K.R.: The truth about blockchain. Harvard Business
(1), 118–127 (2017),
Johnston, D., Yilmaz, S.O., Kandah, J., Bentenitis, N., Hashemi, F., Gross,
R., Wilkinson, S., Mason, S.: DecentralizedApplications: Decentralized appli-
cations white paper and spec (2013),
Karame, G.O.: Two bitcoins at the price of one? double-spending attacks on fast
payments in bitcoin. In: In Proc. of Conference on Computer and Communication
Security (2012)
Kiffer, L., Levin, D., Mislove, A.: Stick a fork in it: Analyzing the ethereum network
partition. In: Proceedings of the 16th ACM Workshop on Hot Topics in Networks.
pp. 94–100. HotNets-XVI, ACM (2017).,
King, S.: Primecoin: Cryptocurrency with prime number
proof-of-work (2013),
Kokoris-Kogias, E., Jovanovic, P., Gasser, L., Gailly, N., Syta, E., Ford,
B.: OmniLedger: A secure, scale-out, decentralized ledger via shard-
ing. IEEE Symposium on Security and Privacy (SP) pp. 19–34 (2018).
Kravchenko, P.: Does a blockchain really need a native coin? (2016), need-
Kshetri, N.: Can blockchain strengthen the internet of things? IT Professional
19(4), 68–72 (2017).
Kumar, A., Fischer, C., Tople, S., Saxena, P.: A traceability analysis of monero’s
blockchain. In: Foley, S.N., Gollmann, D., Snekkenes, E. (eds.) Computer Security
- ESORICS 2017. pp. 153–173. Lecture Notes in Computer Science, Springer
International Publishing (2017)
unnapas, K.: From Bitcoin to Smart Contracts: Legal Revolution or Evolution
from the Perspective of de lege ferenda?, pp. 111–131. Springer International
Publishing, Cham (2016). 6,
// 5 6
Labs, P.: Filecoin: A decentralized storage network (2017),
Laurie, B.: Decentralised currencies are probably impossible (2011),
Lee, T.B.: A brief history of bitcoin hacks and frauds (Dec 2017), of-
Conte de Leon, D., Stalick, A.Q., Jillepalli, A.A., Haney, M.A., Sheldon, F.T.:
Blockchain: properties and misconceptions. Asia Pacific Journal of Innovation and
(3), 286–300 (2017).
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
34 C. Ehmke et al.
Lerner, S.D.: RSK - white paper overview (2015),
RSK White Paper-Overview.pdf
Lewenberg, Y., Bachrach, Y., Sompolinsky, Y., Zohar, A., Rosenschein, J.S.: Bitcoin
mining pools: A cooperative game theoretic analysis. In: Proceedings of the 2015
International Conference on Autonomous Agents and Multiagent Systems. pp. 919–
927. AAMAS ’15, International Foundation for Autonomous Agents and Multiagent
Systems (2015),
Li, K., Yang, R., Au, M.H., Xu, Q.: Practical range proof for cryptocurrency
monero with provable security. In: Qing, S., Mitchell, C., Chen, L., Liu, D. (eds.)
Information and Communications Security (ICICS 2017). pp. 255–262. Lecture
Notes in Computer Science, Springer International Publishing (2017)
89. Limited, O.: Oraclize documentation (2018),
Lin, I.C., Liao, T.C.: A survey of blockchain security issues and chal-
lenges. International Journal of Network Security
(5), 653–659 (2017).
Lo, S.K., Xu, X., Chiam, Y.K., Lu, Q.: Evaluating suitability of applying blockchain.
In: 2017 22nd International Conference on Engineering of Complex Computer
Systems (ICECCS). pp. 158–161 (2017).
Lustig, C., Nardi, B.: Algorithmic authority: The case of bitcoin. In: 2015
48th Hawaii International Conference on System Sciences. pp. 743–752. IEEE
Matzutt, R., Hiller, J., Henze, M., Ziegeldorf, J.H., Hohlfeld, O., Wehrle, K.:
A quantitative analysis of the impact of arbitrary blockchain content on bit-
coin. In: Proceedings of the 22nd International Conference on Financial Cryp-
tography and Data Security 2018. p. 18. Springer (2018),
Merkle, R.C.: Protocols for public key cryptosystems. In: 1980 IEEE Symposium on
Security and Privacy. pp. 122–122 (1980).
Miers, I., Garman, C., Green, M., Rubin, A.D.: Zerocoin: Anonymous distributed
e-cash from bitcoin. In: 2013 IEEE Symposium on Security and Privacy. pp.
397–411 (2013).
oser, M., B¨ohme, R.: Trends, tips, tolls: A longitudinal study of bitcoin transac-
tion fees. In: Financial Cryptography and Data Security. pp. 19–33. Lecture Notes
in Computer Science, Springer Berlin Heidelberg (2015)
Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008),
//, visited on 2018-10-22
Ølnes, S., Ubacht, J., Janssen, M.: Blockchain in government: Benefits and implica-
tions of distributed ledger technology for information sharing. Government Informa-
tion Quarterly
(3), 355–364 (2017).,
Olson, K., Bowman, M., Mitchell, J., Middleton, D., Montgomery, C.: Sawtooth: An
introduction (2018),
01/Hyperledger Sawtooth WhitePaper.pdf
Panetta, K.: Top trends in the gartner hype cycle for emerging technolo-
gies, 2017 (2017),
in-the-gartner-hype- cycle-for- emerging-technologies- 2017/
Patel, D., Bothra, J., Patel, V.: Blockchain exhumed. In: 2017
ISEA Asia Security and Privacy (ISEASP). pp. 1–12 (2017).
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 35
Patterson, R.: Alternatives for proof of work, part 2: Proof of activity,
proof of burn, proof of capacity, and byzantine generals bytecoin blog
blog/proof-of-activity-proof- of-burn- proof-of- capacity/
Peck, M.: Cryptographers urge people to abandon IOTA after leaked emails,
urge-users-and-researchers- to-abandon- iota-after- leaked-emails
Peck, M.E.: Bitcoin: The cryptoanarchists answer to cash (2012),
Peck, M.E.: Blockchain world - do you need a blockchain? this chart will tell you
if the technology can solve your problem. IEEE Spectrum
(10), 38–60 (2017).
de Pedro Crespo, A.S., Cuende Garc´ıa, L.I.: Stampery blockchain timestamping
architecture (BTA) - version 6 (2017),
Perez, S.: Does a blockchain need a token?,
blockchain-need-a-token- 66c894d566fb
Poelstra, A.: Distributed consensus from proof of stake is impossible (2014),
Poon, J., Buterin, V.: Plasma: Scalable autonomous smart contracts (2017),
Poon, J., Dryja, T.: The bitcoin lightning network: Scalable off-chain instant
payments (2016),
Pop, C., Cioara, T., Antal, M., Anghel, I., Salomie, I., Bertoncini, M.: Blockchain
based decentralized management of demand response programs in smart energy
grids. Sensors 18(1) (2018).
Popov, S.: The tangle - version 1.4.3 (2018),
Puddu, I., Dmitrienko, A., Capkun, S.: uchain: How to forget without hard forks
uttgen, F., Kaulartz, M.: Versicherung 4.0. ERA Forum
(2), 249–262
Redman, J.: Segregated witness has officially activated on the bitcoin net-
work (2017),
activated-on-the-bitcoin- network/
Reid, F., Harrigan, M.: An analysis of anonymity in the bitcoin sys-
tem. In: Altshuler, Y., Elovici, Y., Cremers, A.B., Aharony, N., Pent-
land, A. (eds.) Security and Privacy in Social Networks, pp. 197–223.
Springer New York (2013). 10,
// 7 10
Ren, L., Devadas, S.: Bandwidth hard functions for ASIC resistance. In: Theory
of Cryptography. pp. 466–492. Lecture Notes in Computer Science, Springer
International Publishing (2017)
Rimba, P., Tran, A.B., Weber, I., Staples, M., Ponomarev, A., Xu, X.: Comparing
blockchain and cloud services for business process execution. In: 2017 IEEE Inter-
national Conference on Software Architecture (ICSA). pp. 257–260. IEEE (2017).,
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
36 C. Ehmke et al.
Rosic, A.: What is ethereum classic? ethereum vs ethereum classic (2018),
Ruffing, T., Moreno-Sanchez, P., Kate, A.: CoinShuffle: Practical decentralized
coin mixing for bitcoin. In: Computer Security - ESORICS 2014. pp. 345–364.
Lecture Notes in Computer Science, Springer International Publishing (2014)
van Saberhagen, N.: CryptoNote v 2.0 (2013),
Sankar, L.S., Sindhu, M., Sethumadhavan, M.: Survey of consensus proto-
cols on blockchain applications. In: 2017 4th International Conference on Ad-
vanced Computing and Communication Systems (ICACCS). pp. 1–5 (2017).
Schiener, D.: A primer on IOTA (with presentation) (2017),
https:// with-presentation- e0a6eb2cc621
Sheikh, J.: Raiden network 0.14.0 documentation (2018),
Silverstein, S., Cadigan, T.N.: A blockchain without cryptocurrency is just a
database innovation - and that’s great (2018),
blockchain-with-no-cryptocurrency- a-database- innovation-2018- 2
Skudnov, R.: The mini-blockchain scheme (2017),
Sompolinsky, Y., Zohar, A.: Secure high-rate transaction processing in bitcoin. In:
Financial Cryptography and Data Security. pp. 507–527. Lecture Notes in Com-
puter Science, Springer, Berlin, Heidelberg (2015).
3-662-47854-7 32,
47854-7 32
Swan, M.: Blockchain thinking : The brain as a decentralized autonomous
corporation. IEEE Technology and Society Magazine
(4), 41–52 (2015).
Swan, M.: Blockchain: blueprint for a new economy. O’Reilly, 1th edition edn.
(2015), OCLC: ocn898924255
Szabo, N.: Bit gold (2008-12),
Tasatanattakool, P., Techapanupreeda, C.: Blockchain: Challenges and applications.
In: 2018 International Conference on Information Networking (ICOIN). pp. 473–475
Tschorsch, F., Scheuermann, B.: Bitcoin and beyond: A technical survey on
decentralized digital currencies. IEEE Communications Surveys & Tutorials
(3), 2084–2123 (2016).,
Underwood, S.: Blockchain beyond bitcoin. Communications of the ACM
15–17 (2016).,
Vigna, P.: Bitcoin dodges split that threatened its surging price. Wall Street
Journal (2017),
threatened-its-surging-price- 1510172701
Visa Inc.: Visa inc. at a glance (2015),
Vorick, D., Champine, L.: Sia: Simple decentralized storage (2014),
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
Why not every Blockchain is a Blockchain 37
de Vries, A.: Bitcoin’s growing energy problem. Joule
(5), 801–805 (2018).,
Vukoli´c, M.: The quest for scalable blockchain fabric: Proof-of-work vs. BFT
replication. In: Open Problems in Network Security. pp. 112–125. Lecture Notes
in Computer Science, Springer, Cham (2015).
39028-4 9, 4 9
Walch, A.: The path of the blockchain lexicon (and the law). Review of Banking &
Financial Law
, 713–765 (2017),
van Wegberg, R., Oerlemans, J.J., van Deventer, O.: Bitcoin money
laundering: mixed results? an explorative study on money laun-
dering of cybercrime proceeds using bitcoin. Journal of Financial
Crime pp. 00–00 (2018).,
Wessling, F., Ehmke, C., Hesenius, M., Gruhn, V.: How much blockchain
do you need?: Towards a concept for building hybrid DApp architectures.
In: Proceedings of the 1st International Workshop on Emerging Trends
in Software Engineering for Blockchain. pp. 44–47. WETSEB ’18, ACM
Wessling, F., Ehmke, C., Meyer, O., Gruhn, V.: Towards blockchain tactics:
Building hybrid decentralized software architectures. In: 2019 IEEE International
Conference on Software Architecture Companion (ICSA-C) (2019)
Wilkinson, S., Boshevski, T., Brandoff, J., Prestwich, J., Hall, G., Gerbes, P.,
Hutchins, P., Pollard, C.: Storj a peer-to-peer cloud storage network (2016),
Willett, J.R.: The second bitcoin whitepaper (2012),
Wilmoth, J.: Bitmain’s mining pools now control nearly 51% of the bitcoin
hashrate (2018), control-
nearly-51-percent-of- the-bitcoin- hashrate/
Wood, G.: Ethereum: A secure decentralised generalised transaction ledger (2014),
ust, K., Gervais, A.: Do you need a blockchain? (2017),
Xu, X., Weber, I., Staples, M., Zhu, L., Bosch, J., Bass, L., Pautasso, C., Rimba,
P.: A taxonomy of blockchain-based systems for architecture design. In: 2017 IEEE
International Conference on Software Architecture (ICSA). pp. 243–252 (2017).
Yaga, D., Mell, P., Roby, N., Scarfone, K.: Blockchain technology overview.
Tech. Rep. NIST IR 8202, National Institute of Standards and Technol-
ogy (2018).,
Yelowitz, A., Wilson, M.: Characteristics of bitcoin users: an analy-
sis of google search data. Applied Economics Letters
(13), 1030–
1036 (2015).,
Zamanov, A.R., Erokhin, V.A., Fedotov, P.S.: ASIC-resistant hash func-
tions. In: 2018 IEEE Conference of Russian Young Researchers in
Electrical and Electronic Engineering (EIConRus). pp. 394–396 (2018).
Draft – Not Peer Reviewed – Open For Comments
Draft – Not Peer Reviewed – Open For Comments
38 C. Ehmke et al.
Zhang, K., Jacobsen, H.A.: Towards dependable, scalable, and pervasive dis-
tributed ledgers with blockchains. In: 2018 IEEE 38th International Con-
ference on Distributed Computing Systems (ICDCS). pp. 1337–1346 (2018).
Zheng, Z., Xie, S., Dai, H., Chen, X., Wang, H.: An overview of blockchain
technology: Architecture, consensus, and future trends. In: 2017 IEEE In-
ternational Congress on Big Data (BigData Congress). pp. 557–564 (2017).
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
Designing a secure permissionless distributed ledger (blockchain) that performs on par with centralized payment processors, such as Visa, is a challenging task. Most existing distributed ledgers are unable to scale-out, i.e., to grow their total processing capacity with the number of validators; and those that do, compromise security or decentralization. We present OmniLedger, a novel scale-out distributed ledger that preserves longterm security under permissionless operation. It ensures security and correctness by using a bias-resistant public-randomness protocol for choosing large, statistically representative shards that process transactions, and by introducing an efficient cross-shard commit protocol that atomically handles transactions affecting multiple shards. OmniLedger also optimizes performance via parallel intra-shard transaction processing, ledger pruning via collectively-signed state blocks, and low-latency "trust-but-verify" validation for low-value transactions. An evaluation of our experimental prototype shows that OmniLedger's throughput scales linearly in the number of active validators, supporting Visa-level workloads and beyond, while confirming typical transactions in under two seconds.
Full-text available
The electricity that is expended in the process of mining Bitcoin has become a topic of heavy debate over the past few years. It is a process that makes Bitcoin extremely energy-hungry by design, as the currency requires a huge amount of hash calculations for its ultimate goal of processing financial transactions without intermediaries (peer-to-peer). The primary fuel for each of these calculations is electricity. The Bitcoin network can be estimated to consume at least 2.55 gigawatts of electricity currently, and potentially 7.67 gigawatts in the future, making it comparable with countries such as Ireland (3.1 gigawatts) and Austria (8.2 gigawatts). Economic models tell us that Bitcoin’s electricity consumption will gravitate toward the latter number. A look at Bitcoin miner production estimates suggests that this number could already be reached in 2018.
Cryptocurrencies are among the largest unregulated markets in the world. We find that approximately one-quarter of bitcoin users are involved in illegal activity. We estimate that around $76 billion of illegal activity per year involve bitcoin (46% of bitcoin transactions), which is close to the scale of the U.S. and European markets for illegal drugs. The illegal share of bitcoin activity declines with mainstream interest in bitcoin and with the emergence of more opaque cryptocurrencies. The techniques developed in this paper have applications in cryptocurrency surveillance. Our findings suggest that cryptocurrencies are transforming the black markets by enabling “black e-commerce.” Received June 1, 2017; editorial decision December 8, 2018 by Editor Andrew Karolyi. Authors have furnished an Internet Appendix, which is available on the Oxford University Press Web site next to the link to the final published paper online.
Blockchain technologies is one of the most popular issue in recent years, it has already changed people's lifestyle in some area due to its great in uence on many business or industry, and what it can do will still continue cause impact in many places. Although the feature of blockchain technologies may bring us more reliable and convenient services, the security issues and challenges behind this innovative technique is also an important topic that we need to concern.
Conference Paper
Adding blockchain technology to existing systems instead of building them from the ground up poses several challenges. It is difficult to find out which attributes of blockchains are important for a given use case (e.g. immutable, trustless, anonymous) and to decide which elements of an architecture should employ blockchain technologies. Current approaches generally only give a hint on whether blockchain technology makes sense for a given use case or not. This paper proposes a more fine-grained approach to decide which elements of an application architecture could benefit from the use of blockchain technology. We illustrate the first outline of our approach which identifies participants, their trust relations and interactions to derive a hybrid architecture (i.e., an architecture embedding blockchain technology in existing software systems or creating new systems using blockchain only in certain parts).
The Bitcoin cryptocurrency records its transactions in a public log called the blockchain. Its security rests critically on the distributed protocol that maintains the blockchain, run by participants called miners. Conventional wisdom asserts that the mining protocol is incentive-compatible and secure against colluding minority groups, that is, it incentivizes miners to follow the protocol as prescribed. We show that the Bitcoin mining protocol is not incentive-compatible. We present an attack with which colluding miners' revenue is larger than their fair share. The attack can have significant consequences for Bitcoin: Rational miners will prefer to join the attackers, and the colluding group will increase in size until it becomes a majority. At this point, the Bitcoin system ceases to be a decentralized currency. Unless certain assumptions are made, selfish mining may be feasible for any coalition size of colluding miners. We propose a practical modification to the Bitcoin protocol that protects Bitcoin in the general case. It prohibits selfish mining by a coalition that command less than 1/4 of the resources. This threshold is lower than the wrongly assumed 1/2 bound, but better than the current reality where a coalition of any size can compromise the system.
Conference Paper
The expansion of blockchain technologies from financial applications to other fields intensifies the problem of an increasing size of data stored in the blockchain. Unfortunately, new participants of the blockchain network are required to download the whole blockchain to gain an overview about the state of the system and to validate incoming transactions. Approaches like IOTA, SegWit or the Lightning Network try to solve the scalability issues of blockchain applications. Unfortunately, they focus on strategies slowing down the blockchain's growth instead of reducing the problems arising from a growing chain or introduce new concepts to oust the linear blockchain altogether. The approach proposed in this paper is based on the idea of Ethereum to keep the state of the system explicitly in the current block but further pursues this by including the relevant part of the current system state in new transactions as well. This enables other participants to validate incoming transactions without having to download the whole blockchain initially. Following this idea use cases can be supported that require scal-able blockchain technology but not necessarily an indefinite and complete transaction history.