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 trees 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?” interactive decision tree.

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 interactive decision tree below 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.

The decision tree is also available as a questionnaire in a PDF download.

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.

1. What are the requirements for the consensus algorithm?

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.

2. Are all readers and writers known?

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.

3. Are all transactions public?

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.

4. Are transaction rules uniform across participants?

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.

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

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.