Chapter 9

Distributed Ledger Technology

Abstract
Distributed Ledger Technology (DLT) is one of the most promising innovations in
the field of information technologies with the potential to change organization and
collaboration in the economy, society, and industry. This chapter introduces the
technical background and use cases of distributed ledger technology. It presents the
major innovations originating from distributed ledger technology since the introduc-
tion of the blockchain concept. Furthermore, cryptocurrencies’ historical back-
ground as a driver of fully decentralized distributed ledgers is outlined from their
origins in the 1990s until the blockchain concept’s introduction in 2009. DLT’s
technical principles are introduced to provide a sound understanding. Subsequently,
the functioning of distributed ledger technology is illustrated by means of the Bitcoin
blockchain example, which was the first fully decentralized cryptocurrency to not
require a trusted authority (i.e., banks). Thereafter, smart contracts and the idea of
decentralized applications are explained. Selected use cases for distributed ledger
technology’s application are subsequently discussed. This chapter concludes with a
discussion of the prevailing challenges in the field of distributed ledger technology.

Learning Objectives of this Chapter

In this chapter, students are given a basic understanding of Distributed Ledger
Technology (DLT), its historical background, and application possibilities. The
chapter therefore explains DLT’s technical innovations since the introduction of
the blockchain concept. For a better understanding of DLT’s functionality in general,
the different types of DLT designs are explained, as are the terms hash value, Merkle
tree, digital signature, and consensus mechanism. Students should also be able to
assign these terms’ role to a blockchain concept and internalize the idea and use of
smart contracts. Finally, they should understand the usefulness of DLT in real-world
application areas, be able to mention selected use cases, and explain DLT’s role in
these use cases.

Structure of this Chapter

Section one introduces DLT’s potential compared to other distributed databases.
Subsequently, DLT is given a nomenclature to establish a common understanding of

© Springer Nature Switzerland AG 2020 265

A. Sunyaev, Internet Computing, [Link]
266 9 Distributed Ledger Technology

its terms. The historic background of DLT’s evolvement concludes section one.
Section two explains the technical foundations of distributed ledger technology,
including hashing and public key infrastructure. Based on the DLT nomenclature
and the technical foundations, the Bitcoin blockchain’s function is explained. Sub-
sequently, smart contracts are introduced as a useful extension of distributed ledgers.
Finally, various application areas integrating distributed ledger technology are
presented and the current challenges in distributed ledger technology discussed.

9.1 Background of Distributed Ledger Technology

Distributed Ledger Technology (DLT) is one of the most ‘hyped’ technologies of the
last few years. The wide adoption of the cryptocurrency Bitcoin made blockchain

and DLT in general
a highly discussed topic in practice and research. A
cryptocurrency is a digital asset designed to be used as a medium of exchange. By
applying cryptographic techniques, transactions, and represented assets are
safeguarded from manipulation and theft (Chohan 2017). This section sheds light
on why DLT has the potential to change the business landscape and everyday life in
dramatic ways (Kursh and Gold 2016). Furthermore, the section provides an over-
view of the historic background of the best-known DLT application, namely
cryptocurrencies. Finally, a terminology is presented for DLT concepts and charac-
teristics and important DLT characteristics are introduced.

9.1.1 Distributed Ledger Technology as a Game Changer

Storing and managing data are an integral part of many applications, which is why
databases are applied. Data are mostly organized in relational databases with clearly
defined tables and dependencies between those tables holding the relevant data for
the application. Data organization in databases allows for four operations, also
referred to as CRUD (Create, Read, Update, Delete) operations. First, new data are
created in the database. Once created, data can be read, updated, or be deleted. All
database operations perform a certain unit of work on the database. The relevant unit
of work is called a transaction, whose execution ends with a commit that makes the
changes to the database visible to its other users. Each transaction is executed in
isolation, which enables database operations to be clearly differentiated. Database
operations can therefore be reversed in case of a failure (e.g., a create operation being
interrupted).
Three types of databases can be used to organize data: centralized databases,
decentralized databases, and distributed databases. Centralized databases reside on
a single storage device and can, therefore, be better maintained than those distributed
across multiple, physically separated, storage devices. However, centralized data-
bases have drawbacks in terms of, for instance, their availability and performance. A
9.1 Background of Distributed Ledger Technology 267

system’s availability (here, a database) describes the probability of a system being

reachable at a random time and of it functioning correctly. Centralized databases can
become a bottleneck if too many requests need to be processed during a specific
period, which decreases the system’s overall performance. In decentralized data-
bases, there is no central storage; data are simply stored on multiple storage devices
connected with one another, but usually located in different physical locations. A
decentralized database’s storage devices are organized in a hierarchical structure
with a set of nodes communicating with a particular node, which can be a node of a
superordinate set of nodes. Decentralized databases therefore incorporate multiple,
hierarchically organized, centralized databases. Distributed databases are a well-
known concept for increasing availability and avoiding performance issues. In
distributed databases, replications of the data are stored across multiple, physically
independent, storage devices. When a distributed database’s storage device fails or
cannot be accessed for a time, other, still operating storage devices can therefore
respond to open requests and provide a similar result. Such a distribution can
increase performance, because it allows requests to be distributed across the storage
devices and be processed in parallel. A distributed database’s storage devices do not
(usually) follow a hierarchical structure, but instead form a mesh of connected
storage devices, with each storage device connected to another. The following refers
a distributed database’s storage device as a node.

Distributed Database
A distributed database is a type of database where data are replicated across
multiple storage devices (nodes) with equal rights.

Although distributed databases are physically separated on different nodes, a

distributed database’s CRUD operations should always return the same results, no
matter on which node the operation is performed. For instance, proceeding with a
read operation on one database replication run by a particular node should return the
same result when executing the same read operation on any other node of the
distributed database. Consequently, owing to all the nodes’ targeted consistency,
distributed databases are considered logically centralized, but architecturally distrib-
uted (Buterin 2017). To achieve consistency between all the nodes, the stored data
need to be identical on each of the distributed database replications, which makes
distributed databases generally more complex than centralized database. If all the
data are identical across all the nodes, the distributed database is in a consistent state,
with the all nodes having eventually agreed on this state and, therefore, having
reached consensus. To reach a consistent state, the stored data must be synchronized
between a distributed database’s nodes. Because the nodes are physically distrib-
uted, they must communicate with one another by means of a network, which could,
however, lead to Byzantine failures occurring, thus complicating consensus. The
term Byzantine failure is derived from the Byzantine Generals' Problem (Lamport
et al. 1982), referring to actors having to agree on a mutual strategy to avoid
268 9 Distributed Ledger Technology

catastrophic failure, but some of the actors are unreliable. In computer science, there
are multiple forms of Byzantine failures. First, a node (e.g., a computer or robot) can
be ascertained as having crashed or not being reachable via the network, because the
node no longer responds. Second, a monitoring system may be unable to determine a
certain node’s status, which happens when, for instance, this node crashes or when
network failures result in inconclusive responses from the node. Third, nodes may
pursue malicious intentions, such as trying to store incorrect data in the distributed
database. To overcome the first and second Byzantine failures, protocols and algo-
rithms (e.g., Paxos, RAFT) were introduced and applied to ensure nodes’ reliable
synchronization and consistency in distributed databases (Lamport and Massa 2004).
These algorithms and protocols managing the synchronization between nodes are
called consensus mechanisms, since they seek to achieve a consistent state across a
distributed database’s nodes.

Consensus Mechanism
A consensus mechanism is designed to achieve agreement on the respective
state of replications of stored data between a distributed database’s nodes
under consideration of network failures.

Consensus mechanisms can negotiate a consistent state in a probabilistic or total

finality-preserving way. Probabilistic consensus mechanisms only assume to a
certain probability that the majority of the benign nodes has agreed on the relevant
stored ledger’s specific state. Over time, the likelihood increases that all of the nodes
will eventually agree on this state, because subsequent operations build on the
previous states. However, it may still be possible to change the state post hoc
(Eyal and Sirer 2014). In contrast, consensus mechanisms, which ensure total
finality, establish the ledger’s definitive state on which all the nodes agree. The
particular state on which the nodes have agreed cannot be changed. However, most
consensus mechanisms in distributed databases fail to handle the third Byzantine
failure. Consequently, a distributed database’s consistent state can only be
established in a controlled network with verified, honest nodes.
The distributed ledger is special type of distributed database comprising a led-
ger’s local replications on several nodes. Ledgers only allow new data to be
appended; consequently, deleting or updating appended data post hoc should be
impossible. Furthermore, distributed ledgers assume the presence of malicious
nodes, which requires the applied consensus mechanism to cope with the third
Byzantine failure (malicious behavior of nodes) (Hileman and Rauchs 2017). To
assure consistency in distributed ledgers, the third Byzantine failure becomes even
more crucial where nodes may arbitrarily join or leave the network (Pass and Shi
2017). Once the Bitcoin blockchain was introduced, it provided a solution for the
third Byzantine failure in distributed ledgers (Nakamoto 2008), resulting in no
central authority being required to administrate the distributed ledger’s contents
and to distinguish between honest and malicious nodes.
9.1 Background of Distributed Ledger Technology 269

Distributed Ledger
A distributed ledger is a type of distributed database that assumes the presence
of nodes with malicious intentions. A distributed ledger comprises a ledger’s
multiple replications in which data can only be appended or read.

Owing to the application of game theory to consensus finding in distributed

databases, DLT allows distributed ledgers to be run on arbitrary nodes whose
providers are not necessarily known or trusted. Game theory is the “[. . .] study of
mathematical models of conflict and cooperation of intelligent rational decision-
makers” (Myerson 2004). Anyone can contribute to a distributed ledger and partic-
ipate in the consensus mechanism to assure that malicious nodes cannot corrupt the
stored data (see chapter 9.2.4). The reliable synchronization of a distributed ledger’s
dynamically changing set of nodes in the presence of all types of Byzantine failures
is one of DLT’s main innovations.

Distributed Ledger Technology

Distributed Ledger Technology (DLT) enables the realization and operation of
distributed ledgers, which allow benign nodes, through a shared consensus
mechanism, to agree on an (almost) immutable record of transactions despite
Byzantine failures and eventually achieving consistency.

The use of cryptocurrencies (e.g., Bitcoin) was one of the main drivers of
blockchain and DLT’s invention. Customers’ need to trust their bank and the
banking system that has to return their money after they have deposited it, was
predominantly the motivation for cryptocurrencies. For instance, during the financial
crisis, Greek bank customers lost confidence in the banking system and tried to
secure their money by withdrawing cash. The sudden mass cash withdrawals
threatened the banks’ liquidity, which led the Greek government to introduce several
regulatory interventions to tackle the issue. In 2013, the financial crisis became
dramatic for the Bank of Cyprus customers. Deposits at the Bank of Cyprus
exceeding EUR 100,000 lost up to 60% of their value when the rest of the money
was converted into bank shares (Hadjicostis 2013). Bitcoins, and the later
cryptocurrencies (e.g., Ethereum1), allow people to own digital assets, such as digital
coins, without the need for institutions such as banks. No other party may spend the
asset without the owner’s consent, which renders a trusted third party, such as a
bank, obsolete for certain services.
Digital assets can also be transferred from the asset owner to another user via
transactions committed to the ledger. DLT transactions can be compared to bank
transfers, which include (at least) a sender, a receiver, and a certain value being
transferred. The sender and the receiver are represented by a unique character string,

1
[Link]
270 9 Distributed Ledger Technology

which is generated by using cryptographic techniques such as hash functions (see

9.2.1) and public key cryptography (see 9.2.3). All users can receive and send
transactions through their accounts. In the DLT context, a transaction history
keeps a chronological list of all the transactions associated with an account. For
example, the transaction history represents a bank account’s history of payment
transactions (see 9.3). Using cryptographic techniques, such as hash functions (see
9.2.1), the transaction history’s integrity is protected from post hoc changes to each
node of the distributed ledger. Furthermore, public key cryptography ensures that no
other user can transfer values that belong to another account by means of digital
signatures (see 9.2.3).
The double-spending problem is a well-known one in cryptocurrencies, referring
to the same user spending the same digital asset (e.g., a coin) multiple times. In
cryptocurrencies double spending would occur, for example, if Alice paid Bob one
coin and then simultaneously used the same coin to pay Carl. With physical coins,
double spending of the same coin is obviously impossible. In addition, preventing
the double spending of digital coins is very challenging, because these coins are only
represented by numerical values and are not bound to physical objects. To overcome
the double-spending problem, nodes are commonly used to validate transactions and
only such validated transactions are included in the distributed ledger.
During the last decade, it was realized that DLT did not only apply to crypto-
currencies. Distributed ledgers’ structure and functionality were developed further to
allow them to store additional data beyond assets’ values. Consequently, even
programs, also called smart contracts (see 9.4), can be stored inside transactions.
Such smart contracts can be used to formalize business processes (or parts thereof),
which makes DLT a promising technology to automate and speed up business
processes while decreasing transaction costs. The former is possible due to DLT’s
potential to remove parties from the equation, thus requiring less coordination effort
and possibly speeding up business processes. Since intermediaries can be excluded
from several services, the fees for these services can be reduced. In supply chain
management, for example, DLT allows individual products’ provenance to be
retraced by means of the data stored on a distributed ledger during manufacturing
or transportation (Corkery and Popper 2018). In the financial sector, DLT projects,
such as Ripple2, aim to accelerate inter-bank transactions while decreasing the
costs. Internet users’ identity management can be improved by using DLT to provide
a platform that will dynamically grant and revoke access to their personal
data, thus making the use of personal data more transparent to users without a
trusted intermediary and preventing the manipulation of access rights. In terms of
Estonia’s public administration, it was transformed into a digital government by
moving all government-related transactions online and backing these by means of a
distributed ledger3 that allows documents to be digitally signed and stored immuta-
bly. Paper-based documents can now be stored as indelible, digital entries.
Government-related transactions include taxes, voting, and issuing Estonian ID

2
[Link]
3
[Link]
9.1 Background of Distributed Ledger Technology 271

cards. The Estonian ID card’s concept integrates DLT to grant the owner access to
electronic services such as banking and medical prescriptions. Section 9.5 presents a
more detailed selection of important DLT application areas.

9.1.2 History of Distributed Ledger Technology

DLT became popular with the public with the rise of the cryptocurrency Bitcoin,
which was presented in a white paper published in 2008 under the pseudonym
Satoshi Nakamoto (Nakamoto 2008). The large scale-adoption of Bitcoin during
the last decade may make one assume that it was the first cryptocurrency. However,
the idea of cryptocurrencies already appeared in the 1980s, introduced by Dr. David
Chaum (Chaum 1983). Originally incentivized by the vision of establishing an
anonymous and secure digital voting system, Chaum developed a cryptographic
technique called blind signatures that allowed pseudonymity in data exchanges.
Blind signatures made use of public cryptography, which meant each user has a
publicly known public key and a secret private key. Blind signatures allowed one to
sign data digitally with a private key. The digitally signed data could be used to
prove that the data had originated from a certain identity, although only this
identity’s public key was known. It is therefore not necessary to know the sender’s
real identity to validate a message’s originator (see 9.2.3). Based on his findings in
the field of cryptography, Chaum envisioned an anonymous electronic payment
system (Chaum 1983), subsequently founding the company DigiCash in 1989,
which developed the cryptocurrency eCash that focused on payments’ anonymity
and untraceability by using blind signatures (Chaum 1983). eCash was designed to
enable micropayments through cryptographically secured files that stored a certain
monetary value and were generated in exchange for fiat money (e.g., U.S. dollars).
Consequently, customers needed to first transfer funds from their relevant bank
account to their eCash account. Thereafter the bank generated encrypted files storing
a certain value that was also stored on the eCash customer's computer. A special
utility program was provided to manage the encrypted files and execute payments.
To avoid the double-spending problem, Chaum’s concept assigned banks the
responsibility of verifying that the eCash had not already been spent in other trans-
actions. For example, when Alice sends an eCash value to Bob, Bob then sends the
received eCash to the issuing bank. The issuing bank then verifies that the eCash has
not already been used. Chaum’s concept was, however, still dependent on interme-
diaries, such as the participating trusted authorities.
eCash was tested in the United States as a micropayment system from 1995 to
1998. The system was free for purchasers, but merchants had to pay a transaction fee.
Nevertheless, a broad user base remained unconvinced of eCash’s benefits, and
credit cards were introduced instead. In Europe, financial institutions remained more
interested in eCash, because credit cards were not widely used, and cash transactions
were preferred. Several European financial institutions, such as Credit Suisse and
Deutsche Bank, therefore adopted eCash in 1998. Despite eCash’s success,
DigiCash filed a Chapter 11 bankruptcy in 1998 and was finally sold for assets in
272 9 Distributed Ledger Technology

2002, with credit cards replacing eCash. Later, PayPal enabled the immediate
exchange of assets from person to person and customer to merchant, and Chaum’s
ideas of payment anonymity almost fell into oblivion.
In 1996, Douglas Jackson and Barry Downey introduced the cryptocurrency
e-gold, which Gold & Silver Reserve Inc. ran under the name e-gold Ltd. As the
name suggests, gold backed the e-gold cryptocurrency. In 2004, e-gold was the first
cryptocurrency to reach a critical mass of customers and merchants when it regis-
tered more than 1,3 million accounts (e-gold 2004). To use e-gold, users had to
register an account on the e-gold web site, which allowed them to make instant
e-gold transfers to other e-gold accounts (Hughes et al. 2007). E-gold also offered an
application programming interface (API), which enabled e-gold payments’ integra-
tion into various services and e-commerce platforms (Gold and Silver Reserve
1999). However, e-gold became a target of early phishing scams and malware.
Inspired by the first known phishing attack against a financial institution in June
2001 (Cryptography 2005), another attack was used to defraud e-gold in 2003. In
2007, asset transfers via e-gold were suspended due to legal issues, such as money
laundry. Nonetheless, e-gold was the first successful online payment system and paved
the way for many technologies currently still used in e-commerce, for instance, secure
communication (for payments) using SSL encryption and the flexible integration of
payment services into external systems by providing an API.
In 1997, Adam Back created one of the first implementations of a Proof of Work
(PoW) system, called hashcash. Cynthia Dwork and Moni Naor (Cynthia and Moni
1993) invented the PoW concept, which Markus Jakobsson and Ari Juels (Jakobsson
and Juels 1999) later formalized. PoW is an economic measure (e.g., computational
power) used to prevent service abuses, such as spamming or Denial of Service (DoS)
attacks (Back 1997). DoS attacks are aimed at making so many requests for a service
that it cannot handle them and eventually crashes. In PoW systems, a service
requester must perform a certain task, like solving a certain mathematical problem,
before being allowed to request a service. On the one hand, this task needs be
moderately hard to prevent the service requester from making too many requests; on
the other hand, the service provider needs to assess the task’s output easily. PoW
systems do not usually require the users to solve these tasks, as the terminal devices
perform the required task automatically. hashcash showed that PoW could be used to
reduce spamming and the threat of DoS attacks in practice. Currently, PoW plays a
fundamental role in consensus mechanisms applied to distributed ledgers, such as
Bitcoin and Ethereum.
In 1998, the computer scientist Wei Dai shared two protocol drafts for a digital
currency called b-money. He was driven by the idea of crypto-anarchy, which
Timothy C. May introduced (Dai 1998). A crypto-anarchy involves a government’s
permanent absence and postulates anonymity and censorship resistance in respect of,
for example, payments. In this context, a system is considered censorship resistant, if
there is no possibility of modifying or even blocking a third party’s data. Payments
should be made by using cryptographically secured cryptocurrency tokens. Such
tokens represent a medium of exchange to allow people to cooperate with each other
efficiently, and are often called coins in cryptocurrencies (Dai 1998). In the same
year, Nick Szabo had the initial idea for the development of BitGold (Szabo 1997).
9.1 Background of Distributed Ledger Technology 273

BitGold was never implemented but is considered the direct precursor of the Bitcoin
architecture. Szabo’s BitGold scheme applied PoW, because the users would use
computer power to solve the cryptographic equations that the system assigned. In
addition, Szabo aimed at eliminating intermediaries and tried to prevent double
spending by implementing algorithmic and structural improvements. The latter
were still a problem at that time, because previous solutions still depended on a
trusted authority. In essence, the BitGold concept envisioned a fully decentralized
cryptocurrency by replacing intermediary processes with automated processes.
However, both b-money and BitGold failed to achieve large scale adoption.
In 2009, the Bitcoin blockchain was implemented and made accessible to the
public. Bitcoin paved the way for a distributed ledger for digital money transfers,
which can be considered the DLT generation4 1.0. The Bitcoin blockchain was the
first cryptocurrency on a distributed ledger to solve all three types of Byzantine
failures and eliminate the need for intermediaries (Nakamoto 2008). Since Bitcoin
builds on a distributed ledger, its underlying infrastructure is architecturally distrib-
uted and logically centralized. Furthermore, Bitcoin is decentrally governed, because
individual parties can maintain each node in the Bitcoin blockchain (Buterin 2017).
After several years, Bitcoin became highly popular and reached a maximum market
value of more than USD 19,783.06 per coin on December 11, 2017 (Morris 2018).
Besides executing transactions, the Bitcoin blockchain allows the use of a scripting
language to develop scripts that, for instance, automatically undertakes pay-outs if
multiple parties agree on this payout (Atzei et al. 2018). Although Bitcoin’s scripting
language provides the environment to apply a simple version of smart contracts, it is
very limited, because it is not Turing complete5. Incentivized by the Bitcoin break-
through, several foundations, such as the Ethereum Foundation, were established to
develop blockchain further. Although the Bitcoin blockchain introduced the concept
for the first fully decentralized cryptocurrency, the Bitcoin blockchain came with
several constraints, such as low throughput (seven transactions per second on
average), pseudonymity instead of real anonymity, and the above-mentioned limi-
tations of the scripting language. The subsequent DLT generation 2.0 specifically
addressed the latter issue in order to improve DLT’s flexibility and applicability in
applications by means of more powerful smart contracts. In 2015, the Ethereum
Foundation introduced the Ethereum blockchain, which paved the way for the use of
Turing complete smart contracts on a distributed ledger. The Turing complete
environment of Ethereum
the Ethereum Virtual Machine (EVM)
allows the
execution of smart contracts that can be developed in a high-level programming
language (HLL) (Buterin 2018). An HLL is an abstraction from executable machine
code and provides a natural language for program code development. HLLs

4
The term blockchain generation is normally used. However, since blockchain can be considered a
DLT concept, the more general term DLT generation is used.
5
Turing completeness (named after the British computer scientist Alan Turing) describes a system’s
ability to simulate any other Turing machine. Turing completeness enables the use of loops in
programming, which is the multiple execution of programing code until a defined condition is
fulfilled. The concept of loops is important in programming to increase flexibility and to decrease
code duplications.
274 9 Distributed Ledger Technology

generally facilitate program code development through the automation of certain

areas of computing systems (e.g. memory management). Ethereum advanced the
basic Bitcoin transaction structure with ERC-20, a more flexible standard for smart
contracts. Ethereum is therefore not limited to using Bitcoin as a cryptocurrency, but
also enables the development of applications that share a distributed ledger as a
common backend to, for example, store data. The game CryptoKitties6 is a popular
example of a DLT application, because it uses Ethereum as a backend. In the DLT
generation 3.0, the DLT designs were advanced to meet business use case require-
ments, such as a high throughput, improved confidentiality, and increased flexibility
in the development of DLT applications. The initial idea of DLT designs as a
publicly available, fully distributed ledger that allows user pseudonymity has there-
fore changed. To keep a distributed ledger’s data private, several DLT designs, such
as HyperLedger Fabric7, are run by a small set of identifiable organizations or
companies. These DLT applications are predominantly tied to business applications,
which demand more flexible tokens in order to store arbitrary data. By offering this,
DLT designs are applicable to various domains, such as supply chain management
(Li et al. 2017), health IT (Dagher et al. 2018), access management (Alansari et al.
2017), and identity management (Abbasi and Khan 2017).

9.1.3 Terminology in Distributed Ledger Technology

Based on the introduced definition of DLT (see chapter 9.1.1), it is clear that DLT is
a very broad term that is often used interchangeably with blockchain. DLT includes
different concepts, which differ in the way the distributed ledger organizes trans-
actions (Yeow et al. 2018; Kannengießer et al. 2019). The remainder of this chapter
briefly introduces different DLT concepts and how they differ in terms of their DLT
designs, DLT properties, and DLT characteristics (see Fig. 9.1).

Dist ribut ed Ledger Technology

DLT Concept Blockchain blockDAG TDAG ...

DLT Design Bitcoin ... RChain ... IOTA ...

DLT
Security Performance ...
Properties

DLT
Availability Confidentiality ... Throughput ...
Characteristics

Fig. 9.1 Overview of the hierarchical structure of selected DLT concepts, DLT designs, DLT
properties, and DLT characteristics

6
[Link]
7
[Link]
9.1 Background of Distributed Ledger Technology 275

A DLT concept provides an abstract description of a distributed ledger’s archi-

tecture and the organization of transactions. The DLT concepts that are most
discussed are blockchain (Nakamoto 2008; Buterin 2018), block-based directed
acyclic graphs (blockDAG) (Yeow et al. 2018; Sompolinsky et al. 2018), and
transaction-based directed acyclic graphs (TDAG) (Yeow et al. 2018; Popov
2018). In blockchain, transactions are included in a superordinate data structure
called blocks. The blocks are chained together, forming a chain of blocks, with each
block cryptographically linked to a single predecessor. In contrast, blockDAGs can
have multiple predecessors or successors. In TDAGs, blocks are not used at all and
transactions are directly linked to others.
Each DLT concept can be implemented in different ways. The concrete imple-
mentation of a DLT concept is called a DLT design. For example, distributed
ledgers’ Bitcoin and Ethereum both employ the DLT concept blockchain. However,
Bitcoin and Ethereum’s implementations differ significantly. While Bitcoin generates
a new block every 10 minutes on average, Ethereum issues a new block approximately
every 7 seconds. Furthermore, Bitcoin comes with a pre-defined maximum block size
of 1 MB. In contrast, Ethereum does not limit the size of blocks explicitly, but ties the
costs in the form of coins to a particular block size. All DLT designs incorporate six
DLT properties described in Table 9.1 (Kannengießer et al. 2019).

Table 9.1 DLT Properties (adapted from Kannengießer et al. (2019))

Development Flexibility
The possibilities that a DLT design offers for maintenance and further development.
Institutionalization
The emerging embedding of concepts and artifacts (here DLT) in social structures.
Anonymity
The degree to which individuals are not identifiable within a set of subjects (Pfitzmann et al.
2006).
Performance
The accomplishment of a given task measured against standards of accuracy, completeness, costs,
and speed.
Security
Preservation of confidentiality, integrity, and the availability of information (ISO/IEC 2009).
Usability
The extent to which specified users can use a DLT design to achieve specified goals with respect
to effectiveness, efficiency, and satisfaction in a use context (IOS/DIS 2018).

Each of the DLT properties incorporates multiple DLT characteristics, which are
crucial for a DLT design’s suitability for DLT applications. Owing to the differences
between DLT concepts, not every DLT characteristic applies to each of the DLT
designs. For example, TDAGs will not feature in the DLT characteristic block size
(Kannengießer et al. 2019). Table 9.2 presents an excerpt of often-mentioned DLT
characteristics as summarized by Kannengießer et al. (Kannengießer et al. 2019).
This chapter refers to the DLT characteristics as shown in Table 9.2.
276 9 Distributed Ledger Technology

Table 9.2 Excerpt of DLT Characteristics (adapted from Kannengießer et al. (2019))
Prop. DLT characteristic
Performance Block creation interval
The time between consecutive blocks’ creation.
Scalability
A DLT design’s capability to handle an increasing amount of workload or its
potential to be enlarged to accommodate that growth
Throughput
The number of transactions validated and appended to the ledger in a given time
interval
Security Availability
The probability that a system operates correctly at an arbitrary point in time.
Integrity
DLT’s high degree of integrity requires stored transactions to be protected
against unauthorized modification or deletion, as well as against authorized
users’ irrevocable, accidental, and undesired changes.

9.2 Technical Foundations

DLT designs can be instantiated as a public or private distributed ledger (Xu et al.
2017; Yeow et al. 2018). In public DLT designs, the underlying network allows
arbitrary nodes to join and participate in the distributed ledger’s maintenance. No
registration or verification of the nodes’ identities is required. Public DLT designs
are usually maintained by a large number of nodes, for example, in Bitcoin and
Ethereum. Owing to the large number of nodes in the network, each of which stores a
replication of the ledger, public DLT designs achieve a high level of availability. To
allow many (arbitrary) nodes to find consensus, public DLT designs should be well
scalable to not deter performance when the number of nodes increases. In contrast,
private DLT designs engage a defined set of nodes, with each node identifiable and
known to the other network nodes. Consequently, private DLT designs require
verification of the nodes that join the distributed ledger, for example, by using a
Public Key Infrastructure (PKI, see 9.2.3). Private DLT designs are often used if the
public should not be able to access the stored data (Bott and Milkau 2016). For
example, companies can use a common ledger in Supply Chain Management to
collaborate, but do not want to disclose the data to other companies not involved in
the collaboration.
Owing to the differences between public and private DLT designs, the consensus
mechanisms’ requirements also differ. Public DLT designs must be highly scalable,
especially regarding consensus finding between nodes. Consensus mechanisms for
private ledgers are predominantly designed for a comparably small number of nodes
to reach consensus. Most consensus mechanisms applied to private DLT design are
therefore not suitable for public DLT designs. However, public consensus mecha-
nisms can be applied to private distributed ledgers, but this comes at the cost of
9.2 Technical Foundations 277

efficiency (e.g., a low number of validated transactions per second or high ineffi-
ciency). For example, the blockchain concept, which is instantiated in DLT designs
such as Bitcoin and Ethereum, requires each node to maintain a full replication of the
data stored on the distributed ledger.
Besides the choice of using a public or private distributed ledger, consensus
finding or transaction validation can be delegated to a subset of a distributed ledger’s
nodes (Xu et al. 2017; Yeow et al. 2018). If consensus finding is delegated to a
subset of nodes (which is usually small), the DLT design is designated as
permissioned. Since only selected nodes can validate new transactions or participate
in consensus finding, fast consensus finding can be applied, which enables a
throughput of multiple thousands of transactions per second (Castro and Liskov
1999). Owing to the small number of nodes involved in consensus finding, they can
reach finality, which means that all of a distributed ledger’s permitted nodes come to
an agreement regarding the distributed ledger’s current state.
In permissionless DLT designs, the nodes’ identity does not have to be known
(Yeow et al. 2018), because all of them have the same permissions. In permissionless
DLT designs with a large number of nodes (e.g., Bitcoin, Ethereum), consensus
finding is usually probabilistic and does not provide total finality, because it is
impossible to reach finality in networks that allow nodes to arbitrarily join or leave.
Consequently, the consistency between all the nodes of a public, permissionless
distributed ledger can, at a certain point in time, only be assumed with a certain
probability. Furthermore, a transaction appended to a distributed ledger is only
assumed to be immutably stored to a certain probability. In blockchains, this proba-
bility of a particular transaction’s immutability increases when new blocks are added
to the blockchain (Nakamoto 2008). The period until an added transaction is consid-
ered immutable is also called confirmation latency.
Since DLT incorporates multiple computer science techniques, such as peer-to-
peer networking, public key infrastructure, public key cryptography, and hashing,
the technical foundations are explained in the following section for a better under-
standing of chapter 9.3 on the functioning of the DLT blockchain concept.

9.2.1 Hash Functions

Hash functions serve a crucial role in several systems, such as distributed ledgers,
because they enable the use of digital signatures (see 9.2.3) and the verifying of data
integrity. Hash functions are injective functions used to map data blocks of an
arbitrary size to data of a defined, fixed size (e.g., 160 bit), also called hash values.
All data blocks should ideally be transformed into an unambiguous hash value.
Furthermore, hash functions must be deterministic, which is why those that a hash
function produces never differ in respect of a specific input. Ideally, each possible
hash value’s probabilities are uniformly distributed. Hash functions should not
reveal the original data, making it difficult for an attacker to guess a data block
d for a hash value h such that h ¼ hash(d ). Depending on how difficult it is to find a
278 9 Distributed Ledger Technology

data block d producing the targeted hash value h, it is almost impossible to recon-
struct the original data block d by hashing arbitrary messages by means of a brute
force search. The harder it is to reconstruct the original message, the more secure the
hashed data are. Reconstructing a message from its hash value is called a preimage
attack. It should be difficult to find two different m1, m2 messages with identical
hash values hash(m1) ¼ hash(m2). If it is not computationally feasible to find such a
second data block m2, the hash function is second preimage resistant. The presence
of two different m1, m2 messages with equal hash values is called a collision. High
collision resistance describes a low probability of collisions.
The unambiguity of hash values allows for verifying data integrity by storing a
document’s hash. If the original data block is not altered, the document’s hash value
will match the stored hash value. Hash values are used to verify data integrity in, for
instance, the Bitcoin blockchain, where the order of the stored blocks is secured by
means of the hash values (Nakamoto 2008). Hash values are also essential to create
digital signatures, which are used to verify digital messages or documents’ authen-
ticity, for example, in message authentication codes (ISO/IEC 2011). In crypto-
currencies, digital signatures are commonly used (see 9.2.3) to prove ownership of a
certain amount of coins (Nakamoto 2008).
Multiple secure hash algorithms (SHA), such as SHA-1, SHA-2, and SHA-3,
have already been developed. Each SHA makes use of different hash functions to
produce collision-resistant hash values and has a different level of security. For
example, SHA-1 is less collision resistant than SHA-2 and should, therefore, be
replaced by SHA-2. SHA-2 forms a family of hash algorithms that produces hash
values of different lengths, such as 224 or 512 bits. Accordingly, SHA are labeled
SHA-224, SHA-256, SHA-384, SHA-512, and so on. The most commonly used
SHA-2 hash algorithms are SHA-256 and SHA-512. SHA-2 is widely used in
security applications and protocols, including TLS and SSL. Fig. 9.2 illustrates
what SHA-224 hash values look like.

input1 = "distributed ledger technology"

SHA256(input1) = 0x2a96ccbeaeee5fe993dce9c4b6c8922687f8df23f0d57526
381353b102c4ccd3

input2 = "Distributed Ledger Technology"

SHA256(input2) = 0x74178260022e2a5117ed1422e09f82c9e794eddf0cb3bb2
f380f10db3d60b15e

Fig. 9.2 Examples of SHA-256 Hash Values

9.2.2 Merkle Tree

Similar to the previously explained hash function use case, Merkle trees can be used
for the efficient verification of data blocks’ integrity. A Merkle tree is a data structure
based on hashes and introduced by Ralph Merkle (Merkle 1988). Merkle trees are
9.2 Technical Foundations 279

similar in structure to an upturned tree, comprising nodes connected by vertexes.

There are two types of nodes: leaf nodes and non-leaf nodes. Generally, each
non-leaf node np is connected to two distinct childnodes nC1 and nC2, where nC1
and nC2 can be leaf nodes or non-leaf nodes. The relevant parentnode np is labeled
with the hash value hP, which is the hashed concatenation of its childrens’ hash
values hC1, hC2, namely hP ¼ hash(hC1 + hC2). At the bottom of the Merkle tree, each
leaf node is a hash value of a dataset. Leaf nodes are not connected to childnodes.
The nodes’ hash values are therefore iteratively concatenated and hashed, beginning
with the leaf nodes and continuing to the root of the Merkle tree, which is called the
root hash. The root hash can even be used to verify the integrity of multiple data
blocks and large data structures, which are represented by the single hash values that
the leaf nodes require. Currently Merkle trees are main used in peer-to-peer net-
works, such as Bitcoin and Tor Network.
The data structure’s one advantage is that it is not necessary to know the entire
Merkle tree to verify a data block’s integrity. In Fig. 9.3, for example, the integrity of
data block DB2 can be verified immediately
if the tree already contains h1 and
h6
by hashing the data block and iteratively combining the result with hash h1 and
then h6, and by finally comparing the result with the hash root. Terminal devices
whose storage size is constrained can therefore verify data blocks’ integrity without
keeping a full replication of the ledger.

hash root

h7 = hash(h5 + h6)
0 1

h5 = hash(h1 + h2) h6 = hash (h3 + h4)

0 1 0 1

h1 = hash(DB1) h2 = hash(DB2) h3 = hash(DB3) h4 = hash(DB4)

DB1 DB2 DB3 DB4

DataBlocks (DB)

Fig. 9.3 Example of a Binary Merkle Tree

9.2.3 Public Key Infrastructure

A public key infrastructure (PKI) comprises hardware, software, policies, proce-

dures, and roles that are used for the secure electronic transfer of data by means of an
insecure network such as the Internet. A PKI manages the creation, distribution, and
280 9 Distributed Ledger Technology

revocation of digital certificates, which the use of public key cryptography requires.
A public key cryptography (or asymmetric-key cryptography) uses a public and a
private key. Such a public-private key pair allows identities in the network to be
verified by the relevant public key, which enables the encryption and decryption of
data. Furthermore, public key encryption allows the digital signing of data, which
fulfills the same purpose as real signatures on paper documents and, for example,
verifies authenticity when granting permission for something. An exemplary use of a
PKI is to secure network connections in Secure Sockets Layer (SSL) and Hypertext
Transfer Protocol Secure Sockets (HTTPS). In these uses, a PKI is applied to encrypt
data exchange between entities (e.g., a browser and a server) to, for example, keep
passwords secret.
A PKI is usually comprised of the following roles: certification authority (CA),
registration authority (RA), subscribers, repositories, and relying parties. A CA
binds public keys to subscribers by means of digital certificates. To prove the digital
certificates’ validity, the CA signs the issued digital certificates digitally by using a
private key. The CA also issues a self-signed certificate that makes its public key
available to the network participants. The CA’s public key is mandatory to verify all
the digital certificates that it has signed digitally, because digital signatures can only
be verified by using the relevant public key. The RA is an optional, subordinate
CA. The relevant CA certifies the RA, who is only permitted to issue digital certificates
for specific uses. Repositories serve as a database of digital certificates. Repositories
save requests for digital certificates, as well as already issued and revoked digital
certificates. If a CA finds a certificate invalid, the digital certificate can be added to the
repository’s certification revocation lists (CRL). The CRL serves as a black list of
digital certificates. The relying parties (e.g., users or terminal devices) make use of the
PKI to apply public key cryptography. These parties must rely on the correctness of
the digital certificates issued. The relying parties retrieve the required digital certificate
from the repository to encrypt data and to verify digitally signed data. After a relying
party has received a digital certificate, it is stored locally in a certification store. Once
obtained, certificates do not have to be reloaded from the repository before they can
be used.
As mentioned before, public key cryptography can be used to encrypt data before
sending these by means of the network. The data are encrypted using the data
receiver’s public key, which is first retrieved from the PKI’s repository. The
encrypted data can only be decrypted by using the private key matching the public
key used for encryption.

encrypt ðdataBlock, publicKeyreceiver Þ ! fencryptedDataBlock g

decrypt ðencryptedDataBlock, privateKeyreceiver Þ ! fdataBlock g

Finding a matching private key to a corresponding public key by means of brute

force is not computationally feasible (excluding quantum computers). Brute forcing
tests all combinations of possible private keys systematically to find the corresponding
9.2 Technical Foundations 281

private key to a known public key. Once encrypted, only those who know the private
key can therefore decrypt the data.
In DLT, public key cryptography is an essential approach, which is used, for
example, for the creation and digitally signing of transactions. Current crypto-
currencies rely on authentication by means of digital signatures to secure users’
funds. Authentication is undertaken as a part of the transaction validation process
and is referred to as proof of ownership (Nakamoto 2008). The private key is used to
digitally sign a transaction to ensure that the origin of the transaction is legitimate.
Given a data block that needs to be digitally signed and the relevant private key, the
following function produces a unique digital signature for that data block:

signðdataBlock, privateKeyÞ ! fsignatureg

To verify whether a user had signed a digitally signed block, the data block, the
signature, and the public key must be known. The following function returns a
binary response if a user whose public key is known signed the data block:

verifyðmessage, publicKey, signatureÞ ! ftrue, falseg

9.2.4 Consensus Mechanisms in Distributed Ledger

Technology

In the context of DLT, consensus mechanisms describe the process in which a

distributed ledger’s benign nodes agree on the maintained ledger replication’s
specific state. The state of a ledger replication within a distributed ledger can be
regarded as a snapshot of the data stored in the ledger replication. Such a state can
(only) be changed by adding new data to the ledger replication.
Probabilistic consensus mechanisms are better suitable for distributed ledgers that
a large network maintains, because the majority of nodes must participate in
consensus finding until a state can be assumed to be consistent to a certain proba-
bility. In contrast, consensus mechanisms that provide finality take all the nodes into
account that are allowed to participate in the decision on what the current state of the
distributed ledger should look like. After all the permitted nodes have agreed on the
state, they are said to have reached consensus. Finality regarding the distributed
ledgers of a small network can therefore be reached if its size and the resulting efforts
for communication and synchronization is small. In the following, the most common
consensus mechanisms for different types of DLT designs are briefly introduced.
Proof-of-Work
As discussed in chapter 9.1.2, PoW was originally designed to deter spam e-mails
and DoS-attacks by requiring clients to do a certain amount of work before
282 9 Distributed Ledger Technology

requesting a service. In various public, permissionless DLT designs (e.g., Bitcoin),

the PoW concept was extended and ultimately applied to a consensus mechanism
(Nakamoto 2008). In DLT designs that use PoW as a consensus mechanism, each
node must solve a computationally difficult challenge before new transactions can be
included in the ledger. A reward is given to the node that first solves the particular
challenge and contributes computational power. This reward takes the form of coins
(e.g., BTC), with protocol defining the number of coins. In DLT designs that use
blocks, the generation of blocks for a reward is called mining. Nodes that participate
in the mining process are called miners. In Bitcoin, the PoW challenge, which must
be solved before a node can publish a new block, is to guess an arbitrary nonce
(a random string), whose hash value has at least the number of preceding zeros that a
target has defined. The target is dynamically adapted to the overall computing power
of a distributed ledger’s nodes. If the overall computing power increases, the
required number of preceding zeros in the target is increased. Consequently, the
difficulty of finding the random nonce also increases. By adjusting the target’s
difficulty, the work to be performed as PoW is kept in keeping with the overall
computing power in the distributed ledger. New blocks are therefore generated at a
relatively even interval, for example, every 10 minutes in Bitcoin (Nakamoto 2008).
When applying a consensus mechanism that provides a public, permissionless
DLT design with probabilistic finality (e.g., PoW), the distributed ledger can be in an
inconsistent state, due to forks. A fork appears in a distributed ledger when at least
two nodes issue blocks almost simultaneously, allowing the network nodes to accept
different blocks as the correct successor of the last block. The consensus mechanism
resolved such forks automatically by following a defined fork resolution rule.
Bitcoin’s fork resolution rule keeps the version of the distributed ledger that required
the most work and replicates it on all nodes. In other words, nodes will always prefer
the longest chain (Nakamoto 2008). Blocks that were mined, but not included in the
distributed ledger, are called stale blocks. In Bitcoin, stale blocks are abandoned
when the fork resolution rule decides another fork is the main chain.
PoW is very energy consuming, because it is computationally difficult to find a
nonce with a corresponding hash value that is smaller than the target. Consequently,
Bitcoin and other DLT designs based on PoW are often criticized for their ineffi-
ciency. Several alternative consensus mechanisms have been developed that, more
efficiently, establish a consistent state between a distributed ledger’s nodes, as
described in the following.
Proof-of-Stake
Proof-of-Stake (PoS) is a less energy-consuming substitute for PoW and requires
much less computational power in terms of mining. The PoS stipulates that the
likelihood of a node mining the next block is closely linked to the balance of the
miner’s held tokens. In PoS-based cryptocurrencies, the next block’s creator is
chosen by means of various combinations of random selection and the stake’s wealth
or age. Selecting a miner according to its account balance would result in (undesir-
able) centralization, as the single richest node would have a permanent advantage.
9.2 Technical Foundations 283

Multiple selection variants were therefore developed, such as randomized block

selection, coin-age-based selection, and Delegated PoS (DPoS).
In randomized block selection, the lowest hash value, in combination with the
size of the stake that a particular node holds, predicts the next block miner (Pavel
2014). Since a miner’s stakes are public, each node can predict which account will
next win the right to write a block, which is often criticized as weakness.
Coin-age-based selection combines randomized block selection with the "coin
age" concept, a number derived from the product of the number of coins multiplied
by the number of days a miner has held the coins. Nodes that own coins unspent for
at least 30 days begin to compete to generate the next block. The older or larger the
relevant owned coins are, the higher the probability of generating the next block.
However, once a miner’s stake of coins has been used to sign a block, it must start
over with a "coin age" of zero and wait at least 30 days before signing another block.
Furthermore, the probability of generating the next block reaches a maximum after
90 days in order to prevent very old or very large collections of stakes dominating
the blockchain (King and Nadal 2012).
In DPoS the system uses a limited number of nodes to propose and validate
blocks to be appended to the blockchain. This is meant to keep the transaction
processing fast. For example, the DLT design EOS.IO8 uses a set of 21 randomly
chosen nodes that participates in the block generation. The chosen nodes are called
block producers. The distributed ledger’s nodes holding coins on an [Link]
blockchain automatically vote for block producers. The voting restarts after
126 blocks have been generated. Each node can become a block producer if enough
coin holders vote for it. A node is excluded from the voting process if the node, as a
block producer, has failed to produce a block and has not produced a block during
the last 24 hours. A node excluded from the voting process must notify the
blockchain if it wants to be considered in the voting process again ([Link] 2018).
The "nothing-at-stake" problem, which arises when successful block miners have
nothing to lose by voting for multiple blockchain histories, thereby preventing
consensus from being achieved, is an issue that can arise in PoS systems. Unlike
in PoW systems, it costs little to work on multiple chains (Buterin 2014).
Practical Byzantine Fault Tolerance
Unlike the previously introduced consensus mechanisms, the practical Byzantine
fault tolerance (PBFT) is used in private, permissioned DLT designs, where the
network owner first vetted each of the distributed ledger’s nodes. The PBFT, which
enables the implementation of high-performance Byzantine fault-tolerant replicated
state machines (RSMs), was introduced by Miguel Castro and Barbara Liskov in
1999 (Castro and Liskov 1999). An RSM is a system in which multiple, independent
devices keep a replication of the same data set. RSM protocols allow the nodes in an
RSM to function as a state machine, which receives an input in one state and
generates an output based on the defined operations. The execution of an operation

8
[Link]
284 9 Distributed Ledger Technology

forms a transition from one state to a subsequent state, with a state being a view of a
data set. Such RSMs can process thousands of requests per second, but have poor
scalability (Castro and Liskov 1999).
To deal with the issue of Byzantine failures, the PBFT model assumes that the
number of faulty nodes in the network cannot, in a given period of vulnerability, be
simultaneously equal or exceed a third of the overall nodes in the distributed system. In
a network that includes an assumed maximum number of faulty nodes f, the mini-
mum number of benign nodes {R} is therefore calculated as follows: |{R}| ¼ 3f + 1.
Essentially, all nodes in the PBFT model are arranged in order, with one node
called the primary node p, and the others backup nodes. The selection of p depends
on the view number v, as follows: p ¼ v mod |R|. v is an integer value that increments
whenever the ledger data are changed, for example, after data have been added to the
v. View changes are also carried out after a certain amount of time has passed
without the leader node having multicasted requests.
All the nodes within the distributed ledger communicate with one another to
eventually achieve consensus on the distributed ledger’s next view. Each round of
PBFT consensus comprises four sequential phases (Castro and Liskov 1999):
A client sends a request to p to invoke a service operation.
p multicasts9 the request to the backup nodes.
The backup nodes execute the request and then send a reply to the client.
The client awaits f + 1 replies from different nodes with the same result. This result is
the operation’s result.
The node requirements are that they should be deterministic and start in the same
state. The operations performed on the local ledger replication determine a node’s
state. The result is that all the benign nodes agree on the results of an operation
performed on the distributed ledger, for example, they either accept or reject the need
to add data.

9.3 The Bitcoin Blockchain

Blockchain is currently one of the most popular DLT concepts. The blockchain
concept was introduced with the advent of Bitcoin, which is one of the first practical
solution to previously unsolved problems in distributed computing, namely the
handling of nodes’ fraudulent behavior (see 9.2.4) and the double-spending problem.
A blockchain comprises a chronologically ordered list of blocks that are crypto-
graphically linked to their relevant predecessor by using this previous block’s hash

9
Multicasting is a group communication in which data transmission is simultaneously directed at a
group of target computers. Multicasting can be a distribution of data from one-to-many devices or
from many-to-many devices.
9.3 The Bitcoin Blockchain 285

value. A block is a data structure that stores transactions and additional data, such as
a reference to the previous block (Fig. 9.4).

Block Header Block Header Block Header

Prev Hash Nonce Prev Hash Nonce Prev Hash Nonce

Merkle Root Merkle Root Merkle Root

Hash01 Hash23
Merkle Branch for Tx3
Hash2 Hash3

Tx3

Fig. 9.4 Structure of the Bitcoin blockchain (adapted from Nakamoto (2008))

Blockchain
Blockchain is a DLT concept comprising a chain of cryptographically linked,
chronologically ordered, ‘blocks’ containing batched transactions.

This chapter explains the basic functioning of the Bitcoin blockchain that inspired
the development of other distributed ledgers, such as Ethereum. As of January 2019,
Bitcoin had a market capitalization of more than USD 67.8 billion (CCN 2019).
The schematic process of issuing and validating transactions, as well as the gener-
ation of blocks is illustrated in Fig. 9.5. Since the cryptocurrency on the Bitcoin
blockchain is also called Bitcoin, the remainder of this chapter refers to the Bitcoin
currency as “BTC.”
Users of Bitcoin are represented by accounts with a unique Bitcoin address,
which are used to define a receiver of transactions. A Bitcoin address is a string
of digits and characters that can be shared to receive BTC. Bitcoin addresses are
produced by each user’s public key and consist of a string of numbers and letters. A
user’s public key is first hashed. Thereafter, a 160 Bit number is generated from the
hash value, using the RIPEMD160 algorithm:

bitcoinAddress ¼ RIPEMD160ðSHA256ðpublicKeyÞÞ

End-users usually create public and private keys, storing them in a so-called
wallet, and allowing them to use public key cryptography. The digital keys in a
286 9 Distributed Ledger Technology

user’s wallet are completely independent of the Bitcoin protocol, and the user’s
wallet software can generate and manage them without reference to the blockchain
or access to the Internet. Additionally, various wallets store a set of unspent
transaction outputs UTXOs to proceed faster with new transactions linked to this
set. Other wallets retrieve a user’s unspent transaction outputs from an API that the
DLT design provides. While miners store a full replication of the distributed ledger,
wallets are predominantly light nodes that only store transactions related to the
relevant user. Since ownership of BTC can only be proved by using public keys or
users’ digital signatures, users must not lose their keys otherwise the relevant BTCs
cannot be accessed.
Bitcoin is based on a public peer-to-peer network, with each node maintaining a
list of a few other Bitcoin nodes that it discovers during the start-up of the peer-to-
peer protocol. These known nodes are called neighbored nodes. To notify each
Bitcoin node of a new transaction or block, a gossip protocol is applied, which works
as follows: After a Bitcoin node has received a network message, the message is
multicasted to the neighbored nodes and finally propagated throughout the entire
network, which is only loosely coupled, and the number of nodes that may join or
leave the network is arbitrary. Consequently, Bitcoin does not have a fixed network
and nodes must update their list of neighbored nodes periodically to assure messages
are reliably propagated throughout the entire network.
When users initiate a new transaction, their wallets send the transaction to the
distributed ledger (1). When a node receives a new transaction, it validates the
transaction (2). The transaction validation includes a proof of ownership by means
of digital signatures, and proof that there is sufficient balance in the user’s account.
Valid transactions are added to the node’s local Mem-Pool, which is a temporary
storage for validated transactions that will be included in future blocks, and are
also multicasted to neighbored nodes. In parallel, each node in the Bitcoin
blockchain performs a PoW by randomly generating arbitrary nonces, which are
then hashed. The produced hash value is then compared to the current target (see
9.2.4). If the arbitrary nonce is smaller than the target, the node adds the nonce to
the current block that it mines. The preceding block (the last block included in the
local ledger replication) is hashed, and the produced hash value is also included in
the new block. The hash value of the preceding block is used as a reference to a
block’s predecessor and proves the preceding block’s integrity (and that of the
included transactions). Furthermore, transactions are taken from the Mem-Pool,
organized in a Merkle tree (see 9.2.2), and included in the new mined block (3).
Subsequently, the node appends the new block to the local ledger replication and
multicasts the new block to its neighbored nodes. When a neighbored node
receives the new block, it validates the nonce first. If successful, the node also
appends the new block to the local ledger replication (4). All transactions included
in the stored block’s Merkle tree are then removed from the relevant node’s local
Mem-Pool.
9.3 The Bitcoin Blockchain 287

Distributed ledger network

1
TransacƟon (Tx)
issuance

Node received 3.1 6.1

BroadcasƟng BroadcasƟng Node generated a
new Tx the validated Tx new block new block
Process on each node

2 Storage 5
Tx validaƟon Mining
Authentication using Add the 6.2 Generation
digital signatures
Local ReplicaƟon of the ledger new block of a nonce,
Check wether Tx was to the local which in
already used (UTXO) ledger concotena-
Check account’s Unspent TransacƟons Output (UTXO) tion with
balance List of unspent Tx the block
Check if Tx is already 4 data
in Mem-Pool 3.2 Include generates a
Include Memory Pool (Mem-Pool) Tx into the hash value
new Tx Validated Tx that are not yet stored in a block new block less than t
Validated Tx

Fig. 9.5 Schematic Overview of the Inclusion of a Transaction in the Blockchain

Bitcoin nodes receive incentives for participating in the consensus mechanism;

more precisely, for mining the next block (see 9.2.4). A node receives a reward in the
form of BTC coins, with a mathematical function determining the amount, for
completing this task. This function, also called reward halving, halves Bitcoin
block-mining rewards every 210,000 blocks. In this sense, the received benefit per
block is reduced due to the growing number of mined blocks. For example, the
reward decreased from 12.5 BTC to 6.25 BTC on May 25, 2020. In other words, it
takes more effort to obtain the same amount of BTC tokens over time. Once mined,
BTC tokens can be traded on a dedicated market place with other cryptocurrencies or
exchanged for fiat money. In addition to the block reward, miners receive a trans-
action fee for each transaction included in the mined block. Miners can prioritize
transactions with high transaction fees rather than those with low transaction fees
when including transactions in blocks. To increase the transaction fee, users can
define what they are willing to pay when issuing a transaction through their wallet.
After the total amount of BTC has been reached (BTC 21,000,000), miners will only
be incentivized to keep on sharing their computational power if they receive
transaction fees as a reward when validating a transaction and including it into a
block.
The transfer of BTC from one Bitcoin account to another is represented in
transactions’ directed graph (DAG) (Fig. 9.6). Each transaction has at least one
input representing a debit against the transaction originator’s Bitcoin account.
Transactions need at least one output (i.e., payouts added to a Bitcoin account). A
new transaction’s inputs refer to previously created transactions with no successive
transactions as yet. Consequently, these transactions’ outputs are not used and are
called unspent transaction outputs (UTXOs). Any new transaction provides a new
UTXO that can be used to transfer BTC in subsequent transactions. Each UTXO
288 9 Distributed Ledger Technology

contains a locking script or scriptPubKey. Locking scripts define the condition (e.g., a
corresponding signature) that must be fulfilled to spend a UTXO. Transaction inputs
refer to previous UTXOs and contain an unlocking script or scriptSig. Unlocking
scripts require defining the conditions in the locking script before a transaction can be
performed. A user account can have multiple UTXOs, which can be combined to
transfer BTC. To transfer BTC to a Bitcoin account, the originator of a transaction
must digitally sign the hash(es) of the previous transaction(s) and the receiver’s public
key. The produced digital signature is then added to the end of the new transaction (see
Fig. 9.6), with the previous transaction(s) serving as input(s). The BTC receiver can
verify the signature in order to verify the chain of ownership. Any node can verify the
proof of ownership when validating a new transaction. If the transaction is invalid, the
node will reject it and synchronously return a rejection message to the originator. All
BTC locked in a transaction are transferred when this transaction is unlocked. If the
amount of BTC locked in a transaction does not match the amount of BTC that should
be transferred, the transaction’s originator receives the remaining BTC in an additional
transaction, which is linked to a second transaction output. The change equals the
difference between the sum of the BTC unlocked in the relevant transactions, the
amount of spent BTC, and additional transactions fees.

Transaction Transaction Transaction

Owner 1‘s Owner 2‘s Owner 3‘s

Public Key Public Key Public Key

Hash Hash Hash

Verify Verify

Owner 0‘s Owner 1‘s Owner 2‘s

Signature Signature Signature

Sign Sign

Owner 1‘s Owner 2‘s Owner 3‘s

Private Key Private Key Private Key

Fig. 9.6 Bitcoin Transaction Chain (adapted from Nakamoto (2008))

Bitcoin has several constraints, some of which have already been addressed
during the last few years but have not been satisfactory solved. For instance,
Bitcoin’s throughput is about 7 transactions per second (tps) and is constrained by
its maximum block size of 1 MB (Croman et al. 2016). Owing to this relatively poor
throughput of Bitcoin, a transaction may be delayed, depending on the number of
9.4 Smart Contracts 289

uncommitted transactions that remains in the Mem-Pool. Consequently, advanced

blockchain implementations approaches have been developed, such as Ethereum,
HyperLedger Fabric10, and ZCash11. These projects introduced several improve-
ments, such as the higher throughput (e.g., HyperLedger Farbic with about
3,500 tps), and the unidentifiability and untraceability in ZCash.
Nevertheless, the improvement of a particular DLT characteristic usually comes
at the cost of other DLT characteristics. For example, practical Byzantine fault-
tolerance (see 9.2.4) can archive a much higher throughput than PoW, but requires a
small number of nodes to participate in the consensus mechanism, which decreases
its resistance to individual nodes’ malicious behavior (Kannengießer et al. 2019).
Consequently, there are many specialized DLT designs that fulfill the requirements
for a particular use case.
Although blockchains are often considered immutable, public, permissionless
blockchains are especially vulnerable to attacks on the stored data’s integrity (Eyal
and Sirer 2014; Deirmentzoglou et al. 2019). Owing to the occurrence of forks
(see 9.2.4), the integrity of blockchains can be specifically deterred in, for example,
51% of attacks. In 51% attacks, more than 50% of the nodes are assumed to have a
malicious intent. In this case, the distributed ledger’s transaction history should be
reversed, and the stored data’s integrity is no longer assured. Other attacks, such as
selfish-mining (Göbel et al. 2016) and the balance attack (Natoli and Gramoli 2017),
can also pose a threat to the distributed ledger’s integrity. However, these attacks lie
outside this section’s scope.

9.4 Smart Contracts

When renting an apartment, a deposit account is often set up to allow the tenant to
pay the rent sum into it. The tenant cannot withdraw money from this account
without the landlord's consent. Likewise, the landlord cannot withdraw the money
without the tenant's consent. Only if both parties agree, can the money be withdrawn.
Banks usually offer and maintain such accounts. However, DLT now enables the
digital mapping of such deposit accounts, as well as even more complex agreements
without a third party, such as a bank, by means of smart contracts. Smart contracts
are computer programs in which a business logic is formalized; they therefore allow
secure transaction issuance without the need for third parties. The transactions that a
smart contract issues, have similar characteristics to those that users issue: they are
traceable and immutable. The purpose of smart contracts is to reduce the transaction
costs associated with contracting and to accelerate the enforcement of agreements
formalized in smart contracts. Nick Szabo (Szabo 1997) coined the term smart
contract.

10
[Link]
11
[Link]
290 9 Distributed Ledger Technology

Bitcoin already provides the option to determine certain conditions that need to be
fulfilled before a transaction can be issued, which means that, in principle, it can be
used to deploy smart contracts. In order for Bitcoin to do so, its scripting language
consists of a predefined functionality, the Bitcoin OP_CODE, which is a Turing-
incomplete script language enabling the use of simple forms of smart contracts, such
as multi-signature accounts, time locks, and atomic cross-chain trading, without
requiring a trusted third party (Atzei et al. 2018).
The Ethereum blockchain is the most popular example of smart contracts’ use.
The Ethereum blockchain comes with a Turing-complete programming language
(Solidity) and a virtual machine, the Ethereum virtual machine (EVM), which serves
as an environment for the execution of smart contracts. EVM enables the execution
of a custom (sophisticated) logic formalized in smart contracts for automate pro-
cesses, such as withdrawals of tokens (Buterin 2018). Ethereum was the first DLT
design to provide a Turing-complete environment for the execution of smart con-
tracts, which can be developed by using an HLL (Buterin 2018). To deploy smart
contracts on the Ethereum blockchain, Ethereum makes use of tokens that follow
a defined structure, namely the ERC-20 token standard12. In Ethereum, smart
contracts are first compiled to executable byte code and thereafter included in a
transaction according to the ERC-20 standard. The transaction is issued to the
Ethereum blockchain and regularly validated by each node. After the transaction
has been included in the blockchain, the issuer receives the smart contract’s address,
which is similar to an account’s address and is used to interact with the deployed
smart contract. The smart contract will always retain this address and is stored on
each of the Ethereum blockchain’s nodes, as it is in financial transactions. Likewise,
after a smart contract’s deployment, it can no longer be maintained or deleted. In
order to execute a deployed smart contract, a transaction must be sent to this smart
contract’s address. Like any other transaction, triggering a smart contract is propa-
gated throughout the network, with each node executing the relevant smart contract
asynchronously.
Smart contracts are not restricted to data stored on the same distributed ledger
(on-chain), but can also communicate with external (off-chain) services, such as
an external REST API. External services used as data feeds and called from smart
contracts are called oracles.

9.5 Applications of Distributed Ledger Technology

As discussed in the previous sections, DLT is steadily becoming more versatile in

terms of applicable use cases. The following examples introduce a selection of
highly discussed applications that go beyond DLT’s application in cryptocurrencies.
Following the understanding of DLT applications in the previous section, all the
following applications can also be considered examples of DLT applications.

12
[Link]
9.5 Applications of Distributed Ledger Technology 291

9.5.1 Financial Technology

Payments
Cryptocurrency coins (e.g., Bitcoin, Ether, or ZCash) were developed to facilitate
online payments without the need for a trusted third party, such as financial service
providers like banks. No central bank or public authority issues cryptographic coins
and are therefore not usually linked to a legally defined currency (fiat currency).
However, certain natural or legal persons do accept cryptocurrencies as a means of
exchange. Applications to use cryptocurrencies in the financial industry can be found
in areas such as payment transactions, securities settlement, and trade financing.
DLT is promising as it could accelerate all of these areas by means of automation and
increasing transparency while decreasing transaction costs (WTO 2018).
To simplify the settlements of trade and foreign exchange transactions with
different currencies, banks often open a reference account (nostro account) in
another bank to provide the targeted currency. For example, if a Ghanaian company
buys or sells products in Germany often, but does not have a physical presence there,
this company will ask its local bank to set up a Euro account. The Ghanaian bank
will then look for a bank in Germany that offers Euro and ask it to open a bank
account. The Euro bank will set up a bank account that is not a typical checking
account. In this constellation, both banks need to keep records of the amount of
money that one bank keeps on behalf of the other. When DLT is used for the
accounting of digital assets, it can become more efficient and reliable (Brown
et al. 2016). Owing to the decreased bookkeeping effort, DLT can provide both
account holders and their service providers with real-time transparency regarding the
available and forecasted liquidity in the nostro account. In the long-term, banks
might not even look for a partner bank to open a new account, because payments
might be transferred directly to the targeted bank account without considering the
bank’s current country. Consequently, DLT has the potential to reduce the number of
required intermediaries.
The Interbank Information Network (IIN) was found by J.P. Morgan to carry
out international payment transactions based on the private DLT design called
Quorum13. In 2018, more than 75 banks participated in the IIN (Morgan 2018).
Seed Funding
To finance start-ups, a new form of financing based on DLT was developed in
2015
the initial coin offerings (ICOs). ICOs represent a process through which
companies or other project sponsors raise capital for their projects in exchange for
tokens. ICOs are used for the early-stage financing of companies or projects that
often have only one project concept, like fundraising. ICOs differ from classic
early-stage financing by means of a venture capital (VC) company in that private
investors can support them directly. Usually, several intermediaries, such as
investment banks, notaries, or crowd-funding platforms (e.g., Kickstarter), are

13
[Link]
292 9 Distributed Ledger Technology

involved in fundraising, which impedes the fundraising process. These intermedi-

aries can be (partially) replaced by using DLT for the fundraising, because it allows
small-sized companies and start-ups to raise funds for projects at very little costs. A
recent study shows that the funds raised via ICOs have nearly quadrupled from
USD 4.1 billion in 2017 to USD 15.5 billion in early 2018 (Ernst and Young
Global 2018). However, 86 percent of the tokens issued in 2017 are traded below
their initial price. ICOs from 2017 show an average loss of 66 percent compared to
their peak value. Overall, the volumes achieved indicate that, basically, ICOs
might be an attractive form of financing for start-ups, although the extent to
which they are suitable as a viable form of investment remains to be seen in
view of the described losses.

9.5.2 Health Care

Currently, people have to manually reconcile medical health records across, for
example, laboratories, physicians, and pharmacies. Arguably, this requires people
to maintain a list of all stakeholders that process their data. For instance, it may not
be clear what kind of drugs a patient is currently taking. Although data standards
are better than ever, each electronic health record (EHR) stores data by using
different workflows, making it unclear which person recorded what data and at
which point in time. DLT is a promising means of overcoming these issues.
MedRec is a decentralized record management system that handles EHRs by
means of blockchain technology (Azaria et al. 2016) and aims to reduce the efforts
required to obtain a full representation of a particular patient’s EHR to ensure the
best possible treatment.
MedRec stores the EHR’s digital signature on a blockchain and patients are
ultimately in control of who views their data. The signature assures that an unaltered
copy of the EHR is obtained. MedRec also shifts the focus of control from the
institution (e.g., a hospital) to the patient, and, in turn, allows patients to take charge
of their EHR management, which they may, however, find a burden. MedRec is
therefore faced with building an interface that patients will find easy to use.

9.5.3 Supply Chain Management

Escrow Service in Supply Chain Management

The use of DLT addresses many supply chain management issues. Consider the
following example: When a company A buys a product from company B, an
agreement must be made to determine payment, delivery, and the product condi-
tions. There are basically two options for managing the payment: first, B delivers the
product to A without prior payment, or, second, A first pays for the product without
knowing whether it meets the requirements. To solve this issue, A and B usually
9.5 Applications of Distributed Ledger Technology 293

utilize a financial service that holds the money for the product in trust. Such financial
services require the presence of, among others, a financial institution and a notary,
which is why they are costly and time-consuming. Smart contracts can revolutionize
financial services in terms of their cost and speed (BMO et al. 2018). A and B can,
however, formalize the conditions for payment in a smart contract. Company A then
sends the requested funds to the smart contract. Neither A nor B can access the sent
funds as long as the conditions defined in the smart contract are not fulfilled; that is,
A must first confirm that the received product meets its requirements. After the
product has arrived at A, it can check this product and either confirm the payment in
the smart contract or negotiate with B if the product has defects.
Product Tracking via Digital Twins
During the last few years, the public have become very interested in sustainability
and economic awareness, demanding more transparency in supply chains. For
example, end-customers, companies, and governmental institutions are interested
in tracking products’ provenance in order to determine their production conditions.
End-customers want to know where a product (e.g., food or clothes) comes from.
Consequently, some companies now add codes to their products, allowing their
origin to be traced online. By addressing these information needs, companies can
foster their image in terms of, for instance, their ecological sustainability. Imported
products’ origin and production conditions are of special importance for govern-
mental institutions. For example, reliable provenance tracking allows blood dia-
monds, which violate diamond mining’s ethical standards, to be identified. However,
stored data used for provenance tracking are currently relatively easy to manipulate,
because they are either based on paper documents or stored in a central database.
DLT is a promising way of overcoming the issue of post hoc modifiable documen-
tation. This concept involves creating a digital representation of a real-world prod-
uct, a digital twin. Assigning a digital twin unambiguously to a real-world entity
(e.g., a product) requires the generation of a unique identifier (UID) that only the
producer of the relevant product can generate. Such a UID can be based on, for
example, a product’s inherent characteristics (e.g., surface texture), a specific color,
or a specialized hardware device (e.g., a near-field communication device). The
product’s UID is then registered on the distributed ledger, which also allows all the
relevant data from current paper documents to be added. Each time the product is
handed to another individual or organization, a transaction on the DLT design
documents the change of ownership.
Everledger14 is a successful tracker of diamonds’ provenance, aimed at protecting
diamonds’ value throughout the supply chain and facilitating responsible and ethical
sourcing of diamonds. The Everledger system allows blood diamonds to be identi-
fied, the reliable retrieval of their characteristics, such as their carat and size, and the
approval of diamond certifications. When a diamond is registered in the system, a
laser gives it a unique inscription, which represents its UID and is used as a reference

14
[Link]
294 9 Distributed Ledger Technology

to its digital twin on the blockchain. To check a diamond’s provenance, the relevant
UID can be looked up on the distributed ledger. Currently, more than 1.6 million
diamonds are registered on a blockchain.
End-customers’ demand for transparency regarding the production and delivery
of products in the food sector has increased over the last few years. Walmart and
IBM therefore jointly developed a DLT-based system for tracing the origin of food
products, focusing on lettuce initially (Corkery and Popper 2018). In the meantime,
there are plans to adapt food safety via blockchain to the provenance tracking of
cereals (Pyrzenski 2017), coffee (Widdifield 2018), and fishing (Lehikoinen 2018).

Summary

DLT is a promising technology that enables the realization of distributed ledgers,

which are a type of distributed database with new data appended to the end of the
ledger. Generally, distributed ledgers only allow read and create operations and only
append new data to the ledger. Distributed ledgers can be applied in settings
requiring a highly available, immutable, and reliable database as a shared data
storage for different actors who do not trust one another.
Originating from the idea of a completely decentralized cryptocurrency that does
not require the presence of banks or governments, the idea of digital money arose in
the 1990s. However, the first digital currencies, like eCash, still required intermedi-
aries to administer digital money and to prevent double-spending. Double-spending
refers to the problem of spending the same digital asset at the same time for multiple
purposes. Further, subsequent cryptocurrencies, such as e-gold, could not assert
themselves against, for example, credit cards. Satoshi Nakamoto's whitepaper on
Bitcoin, published in 2008, introduced the first fully decentralized cryptocurrency,
which became popular worldwide in the following years. Bitcoin is the DLT gen-
eration 1.0, as it first allowed the exchange of values based on self-generated coins
without the need for an intermediary. DLT generation 1.0 was developed further to
make it better suited for purposes other than cryptocurrencies. Technical advance-
ments were made, which not only improved DLT’s performance, but also its
flexibility regarding application areas. Consequently, DLT is now used in industrial
applications. The types of DLT designs can be divided into private and public, and
these in turn into permissioned and permissionless designs. While private and
permissioned DLT designs promise a high throughput, public permissionless
designs have a higher degree of anonymity and decentralization.
Bitcoin and distributed ledgers developed later, such as Ethereum, combine
technologies from cryptography, distributed systems, and game theory. These
DLTs’ nodes are interconnected in a peer-to-peer network and achieve a consistent
state by means of a consensus mechanism that is Byzantine fault tolerant. A con-
sistent state means that all of the distributed ledger’s nodes agree on the stored
replication ledger having the same content and structure. Byzantine fault tolerance
describes a system’s ability to reach a consistent state, although the nodes may
(temporarily) not be available or could even be malicious.
References 295

The essential cryptographic concepts used in DLT designs are hash functions and
public key cryptography. DLT designs use hash functions to maintain data integrity.
Public key cryptography proves the ownership of assets locked in transactions. The
public key cryptography requires a public key and a corresponding private key, with
data being encrypted by using the public key. The corresponding private key is used to
decrypt encrypted data. Furthermore, data can be digitally signed by using the private
key. The signing of data is essential for DLT, as this makes the ownership of digital
assets traceable. Among other things, hash functions are used for Merkle trees to
maintain stored transactions’ integrity and to quickly check stored data’s correctness.
The description of the technical basics was completed by presenting three pre-
dominantly used consensus mechanisms: proof-of-work (PoW), proof-of-stake
(PoS), and practical Byzantine fault tolerance (PBFT). PoW is used in the Bitcoin
protocol and is a crucial part of the first consensus mechanisms applied to DLT. The
more energy efficient PoS overcomes PoW’s intense energy consumption and takes
the miners’ particular stakes into consideration. The PBFT approach is frequently
used for permissioned DLT designs. Based on the technical basics, a description was
subsequently provided of the Bitcoin blockchain’s basic functionality.
Smart contracts are programs that can be deployed on a distributed ledger; they
allow agreements to be formalized and to be reliably enforced on the distributed
ledger. When a transaction is sent to a smart contract, the latter is executed. Each
node of the distributed ledger executes the smart contract independently. Subse-
quently, consensus is sought regarding the smart contract’s results. It is often
necessary to use external data feeds (oracles) to obtain data from the real world in
order to achieve consensus.
DLT is of interest in domains such as finance, healthcare, and supply chain
management. Several prototypes have already been developed, but only a few are
actually used in industries.

Questions

1. What was the motivation behind the development of a crypto currency?

2. What is DLT and how can blockchain be classified within DLT?
3. What are inherent characteristics of DLT?
4. What is a digital signature and what purpose does it serve in DLT?
5. What are hash functions used for in DLT and why?
6. How does the Bitcoin blockchain work?
7. What are smart contracts and what can they be used for?

References

Abbasi AG, Khan Z (2017) VeidBlock: verifiable identity using blockchain and ledger in a software
defined network. Paper presented at the 10th international conference on utility and cloud
computing, Austin, TX, 5–8 Dec 2017
296 9 Distributed Ledger Technology

Alansari S, Paci F, Margheri A, Sassone V (2017) Privacy-preserving access control in cloud

federations. Paper presented at the 10th IEEE international conference on cloud computing,
Honolulu, HI, 25–30 June 2017
Atzei N, Bartoletti M, Cimoli T, Lande S, Zunino R (2018) SoK: unraveling bitcoin smart contracts.
Paper presented at the international conference on principles of security and trust, Thessaloniki,
16–19 Apr 2018
Azaria A, Ekblaw A, Vieira T, Lippman A (2016) MedRec: using blockchain for medical data
access and permission management. Paper presented at the 2nd international conference on open
and big data, Vienna, 22–24 Aug 2016
Back A (1997) A partial hash collision based postage scheme. [Link]
[Link]. Accessed 23 Sept 2019
BMO, CaixaBank, commerzbank, Group E, IBM, UBS (2018) First pilot client transactions
successfully executed on Batavia global trade finance platform. [Link]
20190313101647/[Link]
1/2018-04-19_PR_Batavia_First_Transactions_EN.pdf. Accessed 12 Mar 2019
Bott J, Milkau U (2016) Towards a framework for the evaluation and design of distributed ledger
technologies in banking and payments. J Paym Strateg Syst 2:153–171
Brown RG, Carlyle J, Grigg I, Hearn M (2016) Corda: an introduction. [Link]
releases/release-M7.0/_static/[Link]. Accessed 19 Sept 2019
Buterin V (2014) On stake. [Link] Accessed 23 Sept 2019
Buterin V (2017) The meaning of decentralization. [Link]
ing-of-decentralization-a0c92b76a274. Accessed 19 Sept 2019
Buterin V (2018) Ethereum whitepaper. [Link]
Accessed 19 Sept 2019
Castro M, Liskov B (1999) Practical Byzantine fault tolerance. Paper presented at the 3rd sympo-
sium on operating systems design and implementation, New Orleans, LA, 22–25 Feb 1999
CCN (2019) Marketcap with prices of cryptocurrencies like bitcoin and ethereum. [Link]
com/marketcap/. Accessed 23 Sept 2019
Chaum D (1983) Blind signatures for untraceable payments. In: Chaum D, Rivest RL, Sherman AT
(eds) Advances in cryptology. Springer, Boston, MA, pp 199–203
Chohan (2017) Cryptocurrencies: a brief thematic review. [Link]
CFM?ABSTRACT_ID¼3024330. Accessed 19 Sept 2019
Corkery M, Popper N (2018) From farm to blockchain: Walmart tracks its lettuce. New York
Times, 24 Sept 2018
Croman K, Decker C, Eyal I, Gencer AE, Juels A, Kosba A, Miller A, Saxena P, Shi E, Gün Sirer E
(2016) On scaling decentralized blockchains. Paper presented at the financial cryptography and
data security, Christchurch, 3–7 Apr 2016
Cryptography F (2005) GP4.3 – growth and fraud – case #3 – phishing. [Link]
fi[Link]/mt/archives/[Link]. Accessed 19 Sept 2019
Cynthia D, Moni N (1993) Pricing via processing, or, combatting junk mail, advances in cryptol-
ogy. Paper presented at the annual international cryptology conference, Santa Barbara, CA,
22–26 Aug 1993
Dagher G, Mohler J, Milojkovic M, Marella P (2018) Ancile: privacy-preserving framework for
access control and interoperability of electronic health records using blockchain technology.
Sustain Cities Soc 39:283–297
Dai W (1998) B-money. [Link] Accessed 19 Sept 2019
Deirmentzoglou E, Papakyriakopoulos G, Patsakis C (2019) A survey on long-range attacks for
proof of stake protocols. IEEE Access 7:28712–28725
e-gold (2004) e-gold statistics. [Link]
com/[Link]. Accessed 23 Sept 2019
[Link] (2018) [Link] technical white paper v2. [Link]
blob/master/TechDoc/[Link]. Accessed 23 Sept 2019
References 297

Ernst & Young Global (2018) EY study: initial coin offerings (ICOs). The class of 2017 – one year
later. [Link]
[Link]. Accessed 19 Sept 2019
Eyal I, Sirer EG (2014) Majority is not enough: bitcoin mining is vulnerable. Commun ACM
61(7):95–102
Göbel J, Keeler H, Krzesinski A, Taylor P (2016) Bitcoin blockchain dynamics: the selfish-mine
strategy in the presence of propagation delay. Perform Eval 104:23–41
Gold & Silver Reserve I (1999) e-gold shopping cart interface specification. [Link]
org/web/20000815224815/[Link] Accessed 23 Sept
2019
Hadjicostis M (2013) Bank of cyprus big savers to lose up to 60 percent. CNBC, 30 Mar 2013
Hileman G, Rauchs M (2017) Global blockchain benchmarking study. [Link]
[Link]?abstract_id¼3040224. Accessed 20 Sept 2019
Hughes SJ, Middlebrook ST, Broox WP (2007) Developments in the law concerning stored-value
cards and other electronic payments products. Bus Law 63(1):237–269
IOS/DIS (2018) Ergonomics of human-system interaction – part 11: Usability: definitions and
concepts. [Link] Accessed 20 Sept 2019
ISO/IEC (2009) Information technology – security techniques – information security management
systems – overview and vocabulary. [Link] Accessed
20 Sept 2019
ISO/IEC (2011) Information technology – security techniques – message authentication codes
(MACs) – Part 1: Mechanisms using a block cipher. [Link]
html. Accessed 20 Sept 2019
Jakobsson M, Juels A (1999) Proofs of work and bread pudding protocols. In: Preneel B (ed) Secure
information networks: communications and multimedia security. Springer, Boston, MA, pp
258–272
Kannengießer N, Lins S, Dehling T, Sunyaev A (2019) What does not fit can be made to fit! Trade-
offs in distributed ledger technology designs. Paper presented at the 52nd Hawaii international
conference on system sciences, Maui, HI, 8–11 Jan 2019
King S, Nadal S (2012) PPCoin: peer-to-peer crypto-currency with proof-of-stake. [Link]
[Link]/vendor/[Link]. Accessed 20 Sept 2019
Kursh SR, Gold NA (2016) Adding fintech and blockchain to your curriculum. Bus Edu Innov J
8(2):6–12
Lamport L, Massa M (2004) Cheap Paxos. Paper presented at the international conference on
dependable systems and networks, Florence, 28 June–1 July 2004
Lamport L, Shostak R, Pease M (1982) The Byzantine generals problem. ACM Trans Program
Lang Syst 4(3):382–401
Lehikoinen T (2018) This summer, fishing in Finland means food traceability on the menu. https://
[Link]/blogs/blockchain/2018/07/this-summer-fishing-in-finland-means-food-traceabil
ity-on-the-menu/. Accessed 19 Sept 2019
Li Z, Wu H, King B, Miled ZB, Wassick J, Tazelaar J (2017) On the integration of event-based and
transaction-based architectures for supply chains. Paper presented at the 37th IEEE international
conference on distributed computing systems workshops, Atlanta, GA, 5–8 June 2017
Merkle RC (1988) A digital signature based on a conventional encryption function. Paper presented
at the annual international cryptology conference, Santa Barbara, CA, 16–20 Aug 1987
Morgan JP (2018) J.P. Morgan Interbank Information NetworkSM expands to more than 75 banks.
[Link] Accessed 19 Sept 2019
Morris DZ (2018) Bitcoin hits a new record high, but stops short of $20,000. Fortune, 17 Dec 2018
Myerson RB (2004) Game theory: analysis of conflict, 6th edn. Harvard University Press,
Cambridge, MA
Nakamoto S (2008) Bitcoin: a peer-to-peer electronic cash system. [Link]
[Link]/54517945/Bitcoin_paper_Original_2.pdf?response-content-dispositi
on¼inline%3B%20filename%3DBitcoin_A_Peer-to-Peer_Electronic_Cash_S.pdf&X-Amz-
298 9 Distributed Ledger Technology

Algorithm¼AWS4-HMAC-SHA256&X-Amz-Credential¼AKIAIWOWYYGZ2Y53UL3A%
2F20190920%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date¼20190920T114421Z&X-
Amz-Expires¼3600&X-Amz-SignedHeaders¼host&X-Amz-Signature¼2da287fe23d2b1684
1842150c8a6f629efc062afab512ca1de042376fc568b83. Accessed 20 Sept 2019
Natoli C, Gramoli V (2017) The balance attack or why forkable blockchains are ill-suited for
consortium. Paper presented at the 47th annual IEEE/IFIP international conference on depend-
able systems and networks, Denver, CO, 26–29 June 2017
Pass R, Shi E (2017) The sleepy model of consensus. Paper presented at the international
conference on the theory and application of cryptology and information security, Hong Kong,
3–7 Dec 2017
Pavel V (2014) BlackCoin’s proof-of-stake protocol v2. [Link]
AMIfv96zY1Qy1kHDkKj-0P5_SZMG5ffHm8EyOVwBzPTtqbINPo-R3femZWkzk08i-
ISg5ZgACMrdCMHH-jovVKeXoXlrSy-zF7NZt7NMWRpT-gmWDrW-
Qz6NdOUdmOvYLXOreooL3-
[Link]. Accessed 20 Sept 2019
Pfitzmann A, Hansen M, Köhntopp M (2006) Anonymity, unlinkability, unobservability, pseudo-
nymity, and identity management – a consolidated proposal for terminology. [Link]
[Link]/viewdoc/download?doi¼[Link].421&rep¼rep1&type¼pdf. Accessed 20 Sept
2019
Popov S (2018) The tangle. [Link]
[Link]. Accessed 19 Sept 2019
Pyrzenski D (2017) I’ll only eat blockchain cereal with a food safety label on the box. [Link]
[Link]/blogs/blockchain/2017/09/ill-only-eat-blockchain-cereal-with-a-food-safety-label-on-
the-box/. Accessed 19 Sept 2019
Sompolinsky Y, Lewenberg Y, Zohar A (2018) SPECTRE: serialization of proof-of-work events:
confirming transactions via recursive elections. [Link]
protocol-7dbbebb707b5. Accessed 20 Sept 2019
Szabo N (1997) Formalizing and securing relationships on public networks. First Monday 2(9)
Widdifield J (2018) Brewing blockchain: tracing ethically sourced coffee. [Link]
blogs/blockchain/2018/08/brewing-blockchain-tracing-ethically-sourced-coffee/. Accessed
19 Sept 2019
WTO (2018) World trade report 2018. [Link]
trade_report18_e.pdf. Accessed 19 Sept 2019
Xu X, Weber I, Staples M, Zhu L, Bosch J, Bass L, Pautasso C, Rimba P (2017) A taxonomy of
blockchain-based systems for architecture design. Paper presented at the IEEE international
conference on software architecture, Gothenburg, 3–7 Apr 2017
Yeow K, Gani A, Ahmad RW, Rodrigues JJPC, Ko K (2018) Decentralized consensus for edge-
centric internet of things: a review, taxonomy, and research issues. IEEE Access 6:1513–1524

Further Reading

Buterin V (2018) Ethereum whitepaper. [Link]

Accessed 19 Sept 2019
Glaser F, Bezzenberger L (2015) Beyond cryptocurrencies – a taxonomy of decentralized consen-
sus systems. 23rd European conference on information systems, Münster, pp 1–18
Göbel J, Krzesinski AE (2017) Increased block size and Bitcoin blockchain dynamics. 27th
international telecommunication networks and applications conference, Auckland, 2017, pp 1–6
Further Reading 299

Kannengießer N, Lins S, Dehling T, Sunyaev A (2019) What does not fit can be made to fit! Trade-
offs in distributed ledger technology designs. Paper presented at the 52nd Hawaii international
conference on system sciences, Maui, HI, 8–11 Jan 2019
Kannengießer N, Pfister M, Greulich M, Lins S, Sunyaev A (2020) Bridges between islands: cross-
chain technology for distributed ledger technology. Presented at the 53rd Hawaii international
conference on system sciences, Waikoloa, Hawaii
Nakamoto S (2008) Bitcoin: a peer-to-peer electronic cash system. [Link]
[Link]/54517945/Bitcoin_paper_Original_2.pdf?response-content-dispositi
on¼inline%3B%20filename%3DBitcoin_A_Peer-to-Peer_Electronic_Cash_S.pdf&X-Amz-
Algorithm¼AWS4-HMAC-SHA256&X-Amz-Credential¼AKIAIWOWYYGZ2Y53UL3A%
2F20190920%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date¼20190920T114421Z&X-
Amz-Expires¼3600&X-Amz-SignedHeaders¼host&X-Amz-Signature¼2da287fe23d2b1684
1842150c8a6f629efc062afab512ca1de042376fc568b83. Accessed 20 Sept 2019
Yeow K, Gani A, Ahmad RW, Rodrigues JJPC, Ko K (2018) Decentralized consensus for edge-
centric internet of things: a review, taxonomy, and research issues. IEEE Access 6:1513–1524