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?

Several authors have provided decision tree to help you decide whether you need a blockchain. Wüst & Gervais give a decision flow of six questions in an excellent academic paper. The Linux Foundation published a list of seven somewhat different questions based on experience with Hyperledger Fabric proof-of-concept projects. And a recent NIST report gives a list of seven, again slightly different questions, based on an extensive technology survey. These questionnaires all include important questions but they are not the same. That’s confusing. Are they describing different technologies?

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 node in what follows is a computing resource that can store data and execute software, and can communicate with others nodes.

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?

The questionnaire below is a decision tree that guides you through a few simple questions aimed at determining whether you really need any of the distinguishing features of BC technology: shared data store, multiple writers, lack of a trusted intermediary, and immutability. Here are the four core questions.

What kind of blockchain do you need?

If you decide you do need a blockchain or decentralized ledger, you must answer a few more questions in order to select a particular decentralized ledger technology. I explain the questions and their possible answers in the next few sections.

The data stored in the nodes of a decentralized ledger must be synchronized by an algorithm. In some systems, all nodes replicate the ledger. In other systems, different nodes may contain overlapping data. But in all decentralized ledgers, the data in the nodes must be kept mutually consistent by a 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.

Cryptocurrency systems allow their users to be anonymous. Systems used in financial institutions, by contrast, need to implement Know Your Customer regulations and require identity management.

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.

In cryptocurrency systems, transactions are public so that anyone can check that they have not been tampered with. In the regulated payment systems managed by the financial industry, transactions are confidential and we have to trust the institutions that they do not tamper with them.

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.

All payment transactions have the same rules: The payer must own the money and not spend it twice. Other transactions, such as the sale of a company, must be crafted individually.

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.

Tracing a box of grapes through the value chain requires a link between the data trace and a sequence of real-world events.

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