Blockchain technology is a type of distributed database that achieves consensus in an open network without a central authority. However, blockchain may not always be needed, as other distributed database solutions can often achieve the same goals more efficiently. The unique property of blockchain is enabling consensus in a permissionless network, but for permissioned networks a traditional distributed database may suffice. While blockchain technology has potential benefits, its applications are currently limited to scenarios where no trusted third party is available. Other existing distributed database technologies can often meet use case needs without blockchain's limitations.

1. The Need for Blockchain Technology.
Tommy Koens
ING - DLT team
Abstract. Blockchain technology has mushroomed a global rethinking
of business problems and the creation of new opportunities. However,
blockchain technology may not always be the answer to those problems
and opportunities. In essence, this technology is a distributed database
that achieves a single feat: reaching consensus in an open network that is
not limited by the number of participants. In this article we argue that,
despite the ingenious work of blockchain technology, its application so far
is limited to scenarios where no trusted third party can be present. From
both an industry and government perspective, other existing, tested, and
proven solutions in the distributed database domain are readily available,
without the limitations that blockchain technology currently holds.
1 Introduction
Recent reports show that both industry [15] and governments [19] are looking
at the possibilities of blockchain technology [17]. Although some advocate that
blockchain technology will change the world [11], others [18] state that blockchain
technology is just a hype. However, the question if blockchain technology actually
is needed remains an interesting one. In this paper we aim to answer that question
and, additionally, add fuel for thought on the need for blockchain technology.
We do this by first abstracting from blockchain technology which is, in essence, a
distributed database. We have a look at the domain of distributed databases and
some of its typical properties in Section 2. Then in Section 3 we have a look at
distributed ledger technology. In Section 4 we discuss the benefit of blockchain
technology, and discuss the need for distributed ledger technology. Finally, in
Section 5 we conclude this work.
2 On Distributed Databases
To understand where to place distributed ledger technology in the domain of
databases, we first will discuss the concept of distributed databases.
Distributed databases allow for dispersion of data across multiple geographi-
cally located computers. Typically, a distributed database is identified by having
multiple storage devices that are not connected to a single processor. This is
called a loosely coupled system. This is in contrast to a tightly coupled system
such as a database, where there is a strong link between a processor and the
storage device. An example of a tightly coupled system is the SQL database

2. 2
that is stored on my hard disk which is located in my laptop, together with its
processor. On the other hand, company X may be located in multiple countries.
In Japan, company X maintains a Human Resource database, in Germany a
Sales database, and in Australia another Sales database. These databases are
connected by a database management system that allows for updates on each
database. This is an example of a loosely coupled system, since none of the
storage devices located in different sites share the same processor.
2.1 Distributed Database Types
In principle, two types of distributed databases exist, homogeneous distributed
databases, and heterogeneous distributed databases. Within a homogeneous dis-
tributed database each site that stores the database has identical software. Each
site is aware of the other sites, and all agree on processing user requests.
In a heterogeneous distributed database at least one of the database uses a
different schema and software. Here, a database schema defines how data in the
database is organized. In case of a different schema, this may run into problems
when querying the database. In the case of company X mentioned above, if a
set of data is labeled ’Products’ in Australia and ’Produkte’ in Germany, an
ambiguous query for a total overview of sold products may return only half of
the desired result.
2.2 Database mirroring, replication and fragmentation
We now have a look at the purposes of having a distributed database and the
techniques that achieve this purpose.
Database mirroring involves one or more identical copies of a database that
resides on nodes in different locations. At any given time, only one copy of the
database is available for nodes. This one copy is referred to as the principle
database, whereas its copies are referred to as the mirror databases. Mirroring
is useful, for example, in maintaining a backup. In case the principle databases
crashes, the mirror database may still provide the data needed.
Database replication refers to the frequent copying of data from one database
to other databases. Note that all databases may be used by individual nodes at
a given moment, which is a significant difference from database mirroring. The
main goal of data replication is to ensure that all nodes have the same view of
the information available. Typically, three types of replication can be performed.
First, copying the entire content from one database to another at frequent in-
tervals is called snapshot replication. Second, data from two or more databases
is merged into a single database. This is called merging replication. Third, after
nodes receive an initial copy of the database, transactional replication updates
all databases periodically when data changes.
Database fragmentation, in principle, fragments the database into chunks of
data which are stored at nodes. The entire database can be reconstructed from
these chunks. This may be useful if, for example, a database is very large and
therefore is distributed over several drives. Another purpose for fragmentation

3. 3
is that only part of the database needs to be queried by specific applications.
Querying only a subset of the database speeds up the search process.
2.3 Reaching consensus
In all three replication types a single challenge stands, namely, how do all par-
ticipants reach consensus on the state of the database? Consensus is reached
when all participants agree on a single state of the database. In a network where
a single node determines the next state, reaching consensus is not much of a
challenge, because the master-node dictates the next ledger state. However, in a
network without such a node, reaching consensus becomes much harder, as all
nodes must agree, ultimately, on the same state. The main problem of consensus
(from a computer science perspective) is to have a distributed set of nodes to
agree on a common value. For example, when a database is mirrored, all nodes
that store a copy of the database must agree on the same state of the database.
This may not always be the case, as nodes may crash, transactions may not be
received, or a malicious actor may try to disrupt nodes from reaching consensus.
In an important work, Fischer Lynch and Patterson [7] state that in an
asynchronous setting where only one node might crash, it is impossible that
a distributed algorithm solves the consensus problem. Indeed, under their as-
sumptions made, no algorithm can reach consensus in bounded time. However,
in practice, consensus can be achieved, since the assumptions made rarely occur.
Consensus in distributed network is reached by so-called consensus algo-
rithms. A recent paper [2] provides an extensive list of such algorithms. This
paper, however, does not list all types and variants of consensus mechanisms. In
practice, over a 100 types of consensus algorithms exist for distributed databases.
To name a few consensus algorithms:
– PAXOS - Named after a fictional legislative consensus system on the Greek
island [13], PAXOS is a crash tolerant consensus protocol. It allows for nodes
to rejoin the protocol after the node has crashed.
– PBFT - Practical Byzantine Fault Tolerant (PBFT) [4] allows for reach-
ing consensus in an untrusted network by transaction voting, as long as a
majority of nodes follows the protocol. This protocol allows for Byzantine
behavior, where nodes may crash, may collude, or messages may be forced.
– PoW - Proof of Work (PoW) [14] is used in many cryptocurrencies, including
Bitcoin and Ethereum. Its main idea is to frequently elect a leader who then
may propose state changes to the database. Note that PoW is, like PBFT,
Byzantine fault tolerant.
3 Distributed Ledger Technology
Having discussed some of the concepts of distributed databases, their purpose
and how consensus is achieved, we now will have a look at distributed ledger
technology. A distributed ledger is a state of data that is shared, and replicated

4. 4
amongst its participants without having a central party managing the ledger.
From a content perspective, the ledger may consist of accounts that hold a token
of value. A well-known example is Bitcoin, where the state of accounts represents
the number of bitcoins that are in possession of the account owner. In princi-
ple, there exists three types of distributed ledgers, public permissionless ledgers,
public permissioned ledgers, and permissioned private ledgers. Here, ’public’ usu-
ally implies that anyone can read the ledger, whereas ’private’ means that only
a few, selected, known participants can read from the ledger. ’Permissionless’
means that anyone may join the network and participate in the consensus pro-
cess, whereas ’permissioned’ implies that both joining the network as well as
taking part in the consensus process is limited to only a few known participants.
3.1 Public Permissionless Ledgers
Within a permissionless distributed ledger there exists no central party that
validates new ledger state updates. Instead, all participants join in participating
in the consensus process, to reach a new state of the ledger. Typically, state
updates is done by voting where, in principle, each participant may vote once per
ledger state update. The main challenge here is to reach consensus amongst the
participants on new ledger states without a central party, and without a single
party introducing thousands of nodes. This so-called Sybil attack [6], allows for
an adversary to deploy twice as many nodes (plus one) than the entire network
consists of. This allows an adversary to out-vote the entire network, and single-
handedly determine the next ledger state. Note that this is an unwanted scenario,
as the initial aim was to have no central party proposing ledger states.
In 2009 Bitcoin was proposed by its pseudonymous author Satoshi Nakamoto
[14]. More important, in this work [14] a technology is proposed to to solve the
consensus problem in a public, permissionless network: blockchain technology. In
short, consensus is achieved by all parties participating in the consensus process
through a lottery. You may win the lottery when you can proof that you have
solved a difficult cryptographic puzzle. On average, every ten minutes a puzzle
is solved and new lottery ticket is created. With this ticket, a participant may
propose a new state of the ledger. As a participant has performed some work (i.e.
solving a cryptographic puzzle), this process is called Proof-of-Work (PoW). Note
that ledger states are proposed in blocks. A block is a set of unique transactions
that have not been seen before and marked as valid. As every new block points
to the previous found block, a chain of blocks is created, hence blockchain.
Indeed, blockchain technology has a single unique property over other DLTs,
namely, it allows for reaching consensus in an open network that is not limited
by the number of participants [16]. However, this currently comes at a cost.
The throughput in public blockchain technology is low compared to centralized
payment providers. For example, Bitcoin in practice processes 4 transactions
per second. In contrast, VISA can process over 50.000 transactions per second.
Also, the decentralized nature of public blockchains may limit public adoption.
Central banks may offer compensation when a bank account has been emptied by
someone other than its owner. Skimming, someone stealing your PIN code and

5. 5
emptying your account, are good examples where third party covers your losses.
Also, when you loose your PIN code, you can request a new one at your bank,
and regain access to your account. Currently, decentralized payment systems,
however, have no proper decentralized way of dealing with stolen tokens. Losing
your key, in principle, implies losing access to your funds.
3.2 Public Permissioned Distributed Ledgers
Within a permissioned distributed ledger, a database (the ledger) is shared
amongst participants where at least one or more parties determine who may
join the network. Blockchain technology could play a role here, depending on
the number of participants that are involved in the consensus process. If more
than 20 participants are involved in the consensus process, blockchain technology
(or any of the upcoming technologies, like Hashgraph [9]) may offer a solution.
Again, key here is the number of participants that are involved in the consen-
sus process. In all other cases, other distributed technologies can be used. For
example, consensus algorithms such as PBFT [3] and RBFT [1] may be used to
reach consensus. There appears to be no need to achieve consensus by proposing
blocks, and creating a blockchain, as consensus algorithms such a PBFT can
process much more transactions per second than PoW.
3.3 Private Permissioned Distributed Ledgers
A private permissioned distributed ledger allows for reaching consensus within
a selected group of participants. Additionally, not every participant (nor those
that do not participate) may read every part of the ledger. Typically, scenarios
where transaction throughput and more importantly, privacy, plays an impor-
tant role, these types of ledgers are applied. For example, ING uses a technology
developed by R3 called Corda [5]. Here, a selected group of nodes called valida-
tors is trusted. This group validate transactions and propose new state updates.
However, if a transaction occurs between party A and B, only these two parties
and the validators know of the transaction. All other participants (e.g. party C,
D and E) are not aware of this transaction, which introduces some privacy on
transactions. Note that Corda does not use blockchain technology as, indeed,
there is no need for it.
4 Do You Need Blockchain Technology?
Blockchain technology seems to have sparked the rethinking of existing pro-
cess problems. Again, this does not imply that blockchain technology is the
answer to the problems being addressed. At this point, the unique selling point
of blockchain technology is that it achieves eventual consensus on the state of
the ledger in a permissionless environment [16].
A recent work by W¨ust and Gervais [20] aims at providing a framework that
allows for deciding the appropriateness of blockchain technology. Based on six use

6. 6
case properties, their model aims to answer if, and if so, which type of blockchain
technology is appropriate for a particular use case. However, their model, in
principle suggests either using blockchain technology, or not using blockchain
technology. In fact, the model fails to mention alternative solutions, such as a
distributed database. However, the use case properties in their model are an
indication of the core elements of use cases where distributed ledger technology
may be appropriate. We extend their model by adding another possible solution,
that of a distributed database. We list the use case properties and compare these
with the distributed ledger technologies, see Table 1.
Table 1. Comparing distributed databases
Use case properties Database type
Permissioned,
priv. blockchain
Permissioned,
pub. blockchain
Permissionless,
pub. blockchain
Distributed
database
Store state? x x x x
Multiple writers? x x x x
Writers known? x x x
Writers trusted?
Public verifiability? x x
Can use a TTP? x x x
First, we observe that a private permissioned distributed blockchain matches
the same use case properties as a distributed database. Note that blockchain
technology still has some issues, such as scalability [12], privacy [10], and central-
ization [8]. Therefore, it would make more sense to apply a distributed database
instead of a private permissioned blockchain.
Second, as argued by Perlman [16], the novel part of blockchain technology
(as used in, for example, Bitcoin) is having a consortium of unknown participants
to reach consensus. As we can see from Table 1, none of the other distributed
database types offer such a solution. More important, this gives rise to the argu-
ment that a public permissioned blockchain is only suitable for use cases where
you can not use a Trusted Third Party (TTP).
Third, most of the use case properties are focused on the technology itself.
However, there could be other use case properties that drive blockchain tech-
nology. There is unpublished work on this, which we expect to appear later this
year.
5 Conclusion
The global interest in blockchain technology shows that, indeed, there is a need
and room for improvement in existing or new (business) processes in which dis-
tributed ledgers play an important role. As we discussed in the previous section,
blockchain technology is a type of database within the domain of distributed
database technologies. In fact, the domain of distributed databases is large, and

7. REFERENCES 7
many solutions are available. Blockchain technology is and should not be the
default solution, as other distributed database technologies can achieve most of
its feats. These technologies should be explored as well when addressing business
problems, since these solutions overcome the drawbacks of blockchain technol-
ogy. If you are going to change your (business) processes or create new ones, you
might as well want to do it with the appropriate technology.
Acknowledgements
We would like to thank Jochem Kleine, Stijn Meijer, Han Voorbraak, and Cees
van Wijk for reviewing the initial versions of this paper. We also would like to
thank ING’s distributed ledger team for sparking the discussion on (the need
for) blockchain technology.
References
[1] Pierre-Louis Aublin, Sonia Ben Mokhtar, and Vivien Qu´ema. “Rbft: Re-
dundant byzantine fault tolerance”. In: Distributed Computing Systems
(ICDCS), 2013 IEEE 33rd International Conference on. IEEE. 2013, pp. 297–
306.
[2] Shehar Bano et al. “Consensus in the Age of Blockchains”. In: arXiv
preprint arXiv:1711.03936 (2017).
[3] Miguel Castro and Barbara Liskov. “Practical Byzantine fault tolerance
and proactive recovery”. In: ACM Transactions on Computer Systems
(TOCS) 20.4 (2002), pp. 398–461.
[4] Miguel Castro, Barbara Liskov, et al. “Practical Byzantine fault toler-
ance”. In: OSDI. Vol. 99. 1999, pp. 173–186.
[5] Corda. Web page. url: https://github.com/corda/corda.
[6] John R Douceur. “The sybil attack”. In: International workshop on peer-
to-peer systems. Springer. 2002, pp. 251–260.
[7] Michael J Fischer, Nancy A Lynch, and Michael S Paterson. “Impossibility
of distributed consensus with one faulty process”. In: Journal of the ACM
(JACM) 32.2 (1985), pp. 374–382.
[8] Adem Efe Gencer et al. “Decentralization in Bitcoin and Ethereum Net-
works”. In: arXiv preprint arXiv:1801.03998 (2018).
[9] Hashgraph Consensus: Fair, Fast, Byzantine Fault Tolerance. url: https:
//www.swirlds.com/whitepapers/.
[10] Daira Hopwood et al. Zcash protocol specification. Tech. rep. Tech. rep.
2016-1.10. Zerocoin Electric Coin Company, 2016.
[11] How blockchains could change the world. Web page. url: https://www.
mckinsey.com/industries/high-tech/our-insights/how-blockchains-
could-change-the-world.
[12] Eleftherios Kokoris-Kogias et al. “OmniLedger: A Secure, Scale-Out, De-
centralized Ledger.” In: IACR Cryptology ePrint Archive 2017 (2017),
p. 406.

8. 8 REFERENCES
[13] Leslie Lamport. “The part-time parliament”. In: ACM Transactions on
Computer Systems (TOCS) 16.2 (1998), pp. 133–169.
[14] S. Nakamoto. “Bitcoin: A Peer-to-Peer Electronic Cash System”. In: (2008).
https://bitcoin.org/bitcoin.pdf Accessed 20 Jun 2017.
[15] Nearly 6 in 10 large corporations considering blockchain deployment. url:
https://www.juniperresearch.com/press/press-releases/6-in-
10-large-corporations-considering-blockhain.
[16] Radia Perlman. “Blockchain: Hype or Hope?” In: ;login: 42.2 (2017), pp. 68–
72.
[17] SelfKey Self-Sovereign Identity Network. Web page. url: https://selfkey.
org/.
[18] Top Trends in the Gartner Hype Cycle for Emerging Technologies, 2017.
Web page. url: https://www.gartner.com/smarterwithgartner/top-
trends-in-the-gartner-hype-cycle-for-emerging-technologies-
2017/.
[19] Will blockchain transform the public sector? Web page. url: https://
www2 . deloitte . com / insights / us / en / industry / public - sector /
understanding-basics-of-blockchain-in-government.html.
[20] Karl W¨ust and Arthur Gervais. “Do you need a Blockchain?” In: IACR
Cryptology ePrint Archive 2017 (2017), p. 375.