Do You Need a Blockchain? A very simple decision tree

In a previous blog, I said that the question whether you need a blockchain only makes sense if you know what your goals are. If you don’t have a goal, you don’t need anything.

So let’s suppose that you know your goals. How do you find out whether you need blockchains to achieve those goals? This is the question I discuss in this blog.

Why another decision tree?

The lists are different because each includes some of the questions that become relevant after you have chosen for blockchain technology. The four core questions needed to make the decision are the same, but they are hidden in the larger lists. I give these core questions below, in the “Do you need a blockchain?” questionnaire.

When you decide to use blockchain technology then other questions become relevant, such as which consensus algorithm to use and whether your users are anonymous. I list these questions below too, in the section “What kind of blockchain do you need?”. But first, let me explain what I mean by a few keywords.

First, some terminology.

A decentralized ledger (DL) is a system that consists of a set of communicating nodes, which can engage in peer-to-peer transactions. There is no intermediary that handles these transactions. The system keeps a log of these transactions in each of the nodes, and there is a consensus algorithm running in all nodes that keeps these logs mutually consistent. In some systems, all nodes contain exactly the same replicate of the complete log. But there are also systems in which different nodes may store different, overlapping parts of the log that are mutually consistent.

Decentralized ledgers are usually called “distributed ledgers”. This is misleading because the essence of a decentralized ledger is not only that data is distributed across nodes, but that there is no central control.

A blockchain (BC) is a decentralized ledger where the transaction log is a linked list of blocks. Each block contains a set of transactions that are considered to have taken place at the same time. Each block also contains a hash (a sort of fingerprint) of the previous block in the list. If any block is changed, its fingerprint changes, and hence the fingerprints of all subsequent blocks in the list. So if you have the fingerprint of the most recent block, you can easily check if any block in the chain has been changed.

In addition to having a data structure, BCs have a consensus algorithm by which the nodes in the decentralized ledger agree on the contents of the blockchain. To ensure immutability of the transaction log, blockchains use a consensus algorithm that makes it unfeasible to change the log. Different consensus algorithms do this in a different way. The guarantee of immutability is not 100% but very strong.

Beware that some companies that sell decentralized ledgers call them blockchains for marketing reasons. For example, Corda is promoted as a blockchain system even though it has a non-blockchain architecture. In my terminology, it is a decentralized ledger.

A database (DB) is a system that stores centrally managed data. The data may be distributed across several nodes, or stored on one node. Databases in my terminology are centralized, which mean they have a single owner who is responsible for its functioning.

Do you need a blockchain?

What kind of blockchain do you need?

1. What are the requirements for the consensus algorithm?

Possible requirements include scalability in the number of nodes, number of transactions per second, energy usage (some algorithms require a lot of computing power), the finality of transactions (is there a period during which a transaction is not yet final?), and vulnerability to fraud. A short guide to five consensus mechanisms is given here. Slightly more recent is this overview of 30+ algorithms.

2. Are all readers and writers known?

Nonpermissioned decentralized ledgers, such as ledgers for cryptocurrency payments, have no barrier to participation, and use wallets to generate pseudonymous addresses. Permissioned systems, used for example by financial institutions, use identity management systems to identify and admit participants.

3. Are all transactions public?

For example, transactions in nonpermissioned systems such as the Bitcoin network are visible to all users. Transactions in permissioned systems, such as R3’s Corda, are visible to a small number of participants on a need-to-know basis.

4. Are transaction rules uniform across participants?

The validity of transactions in decentralized ledgers is checked by smart contracts associated with the transaction. All transactions execute the same smart contract code, which is uniform across participants.

5. How is the data store connected to the real world?

To secure a relationship between a data item and a real-world event, we can use sensors (e.g. an RFID chip that measures the location of a box), physical measures (closing the box with a seal), and regulatory measures (certifying and monitoring agents who handle the box).

Reflecting on these five questions, note that except the first question, they are relevant for databases too.

Professor emeritus Information Systems, University of Twente, The Netherlands. Co-founder and Director, The Value Engineers (

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store