1 Introduction

Ever since the invention of blockchain in 2008 [46], this technology has piqued the interest of industry, and many blockchain initiatives have arisen. Over a 1000 patents [1] in this technology were filed, and it is estimated that blockchain global spending reaches 2 billion US dollar in 2018 [15].

Following the blockchain hype [48], many initiatives discovered that blockchain as it is used in for example Bitcoin and Ethereum is not a panacea. Instead, alternative blockchain technologies have been proposed that fit better. To be able to determine if, and if so which blockchain is needed in a particular scenario, various decision models have been proposed. However, there are significant differences between such schemes. In fact, some schemes provide different answers for the same scenario. This raises the question: Which decision scheme should you use? This paper addresses that question and makes the following contributions:

  • We perform a critical analysis of decision schemes in Sect. 3. Our analysis demonstrates some contradictions between schemes and suggests that none of the schemes is complete, in that they do not take current limitations of blockchain technology into account and ignore what alternative database technologies besides blockchain there are.

  • To repair this omission, we propose a new scheme in Sect. 4, which does take these alternatives into account. With our scheme the need for blockchain of for alternative technologies can be determined. We discuss our scheme in Sect. 5. Given the global interest and financial resources spend on blockchain, our scheme can be used as a sanity check for blockchain initiatives.

Section 6 discusses future work and we summarize our conclusions in Sect. 7.

2 Background

Blockchain technology underlying cryptocurrencies such as Bitcoin and Ethereum offers a unique property. Namely, it allows for reaching agreement on a single state of a shared ledger by a consortium of unknown participants [50]. Transaction sets, called blocks, are proposed at frequent time intervals, where each block includes the cryptographic hash of its predecessor block. This creates a chain of blocks, which explains the term blockchain. Two important characteristics of this technology, as it is originally used in e.g. Bitcoin, are that the blockchain is permissionless and public. Permissionless means that anyone may join or leave the network at will. Public means that anyone, in principle, may propose a new state of the ledger.

However, there currently are several issues with this technology. First, it performs poorly regarding transaction scalability. For example, Ripple, a technology that is not blockchain-based [9, 28], claims to be able to scale to 50.000 transactions per second (tps) [27], whereas Bitcoin can handle 7 tps and Ethereum 14 tps. Second, although a blockchain is a form of database, it is currently not suited to store large amounts of transaction data.

Furthermore, some authors [51, 52, 55] claim that blockchain is an immutable ledger. However, this is a misconception, as blockchains are mutable. First of all, an important purpose of this technology is that state changes are made possible. Therefore, state stored on the blockchain is by default mutable. Mutability may also refer to the stored transactions on the ledger. Again, these transactions are also mutable, although they are much harder to change than state. For example, anyone with over half of Bitcoin’s network resources can rewrite the ledger’s history [35], which is also called mutable-by-hashing-power [38]. Recent work suggests that even a quarter of the resources is sufficient to ultimately achieve the same goal [39]. Another example that further illustrates the mutability of blockchains is the hard fork of Ethereum after the DAO hack, where 50 million dollars worth of Ether was stolen through a bug in a smart contract. The current ledger called Ethereum Classic left the funds stolen. However, a new ledger (called Ethereum) was created, returning the stolen funds, thus undoing the hack and rewriting history. Although blockchains are mutable, in most cases it is hard to rewrite history. However, there are scenarios where easy mutability is a requirement, for example, because of the need to correct accidental mistakes.

To overcome these blockchain issues (scalability, performance, hard to alter history), alternative database technologies may be more useful. For example, permissioned and public database technology can be found in Ripple [27], which uses a distributed ledger [28]. Here, anyone may join the network and read from the ledger, but only a limited set of participants may propose new ledger states. Also, permissioned and private database technologies have been proposed, for example in R3 Corda [25]. Here, participation in the network is by invitation only, and also a limited number of the participants may propose new states.

Following these types of database technologies, initiatives have to decide which technology is appropriate for a particular scenario. To support this decision making process, decision schemes for database technologies, and in particular blockchain, have been proposed. However, the decision schemes are not always clear in what is meant with blockchain.

2.1 Blockchain Terminology

We observed that the term blockchain is used arbitrarily in the schemes. Indeed, Birch et al. [34] and Maull [45] also state that many authors use the term blockchain in different ways. Interestingly, in the original work by Nakamoto [46] the term blockchain is not used, but the term distributed time-stamp server is used. Pahl [47], Birch et al. [34] and Lin [43] state that blockchain is a distributed ledger. Pahl [47] also calls blockchain is a distributed database, while Birch et al. [34] use the term ‘shared ledger’. Wüst and Gervais distinguish permissionless and permissioned blockchains, and provide examples for each type. Their Corda example, however, can be considered a decentralized database [22]. Although Corda is heavily inspired by blockchain systems [26], Corda does not use a chain of blocks. These examples show that, indeed, various terms are used interchangeably and are not always correctly.

The terminology for the different solutions we use in this paper is illustrated in Fig. 1 and explained below. We distinguish two types of databases: central databases (DBs) and distributed databases. In a central database, data is centrally stored. Following this, a central ledger is a central database with the inclusion of transaction interaction. Transaction interaction [12] refers to the interdependency of transactions of different participants. For example, a Bitcoin account with a balance of 0 can only create a valid transaction after it receives a transaction that increases its current balance. Additionally, a shared central ledger can be used when multiple writers are present.

A distributed database stores data across multiple locations, and provides read and write access to participants. Following this, a distributed ledger is a distributed database with the inclusion of transaction interaction. We consider blockchain (BC) to be particular form of distributed ledger technology (DLT), as here unknown participants can read from and write to the ledger, and reach consensus on the state of the ledger.

Fig. 1.
figure 1

Our classification of database technologies

Full size image

3 Evaluation of Decision Schemes

In this section we analyze 30 blockchain decision schemes, listed in Table 1. We classify the schemes by type, based on the question(s) they answer. We also classify the choices that the schemes involve, listed in Table 2, and we investigate contradictions between some of the schemes.

3.1 An Overview of Schemes

We found 30 decision schemes in the literature and on the web, and included all schemes found; see Table 1. Five schemes are represented as a questionnaire, indicated by a ‘Q’ in Table 1. The remaining 25 schemes are represented by a flow diagram, indicated by an ‘F’ in Table 1, where a sequence of binary choices lead to an end state that provides the optimal solution for a given scenario.

We observe that all schemes can be classified in (a combination of) three models, where each model addresses a primary question:

  • Model 1: Determine if blockchain should be used. Schemes that aim to determine if you should use a distributed ledger or, more specific, blockchain.

  • Model 2: Determine blockchain type. These schemes aim to determine which type of blockchain fits best to a particular problem.

  • Model 3: Determine alternative technologies. The third model suggests alternative technologies such as traditional databases.

A classification of each scheme towards these three models can be found in Table 1 (column: Model). Additionally, we counted the number of end states (column: #ES) for each decision scheme. This already shows that there exists a difference between similar scheme types and number of end states. Furthermore, we grouped the various end state descriptions (column: End states), according to our terminology definition in Sect. 2, in the columns below. Typically, in the literature blockchains are classified in three categories:

  • Permissionless (anyone may write to the ledger) and public (anyone may read from the ledger).

  • Permissioned and private (only a limited set of participants may read from the ledger).

  • Permissioned and public.

Table 1. An overview of decision schemes
Full size table

From these columns we also note various levels of granularity of end state descriptions. For example, it is not clear if end state B.1.a (public BC) is permissionless (similar to B.1.c) or permissioned (similar to B.3.b). Also, Birch et al. [34] introduce new terminology, such as the public double permissionless DLT (B.2). This includes the reward mechanism of writing to the ledger which, when intrinsic to the consensus process, is called double permissionless. An extrinsic mechanism where a writer receives a physical reward (e.g. cash) is called permissionless [34].

figure a

3.2 Model 1 Scheme End States

Model 1 schemes aim to determine if you should use a blockchain. Several schemes, for example Pahl, Gardner, and Greenspan, give a clear yes-or-no answer whether a blockchain should used or not. Other schemes are more conservative. For example Peck, Meuller, and DHS, only say that blockchain may be an option. Typically, these schemes do not elaborate what further conditions have to be met to determine if blockchain should (or should not) be used.

3.3 Model 2 Scheme End States

Model 2 schemes aim to determine which type of blockchain is needed. Typically, these schemes also answer the question whether you should you a blockchain or not, so they are also model 1 schemes.

Both Saiko and Birch et al. propose a type 2 scheme only. Interestingly, Saiko considers three types of blockchains, although uses the terms blockchain and ledger interchangeably. In contrast, Birch et al. consider four distributed ledger types, although in their work they do provide examples that include blockchain. The main difference between the two schemes is that Birch et al. suggest two types of public ledgers and two types of private ledgers, whereas Saiko suggests a single public ledger and two types of private ledgers. Here, again, we observe a difference in schemes, similar to model 1 schemes.

However, we consider blockchain variants not a viable option, as better, alternative technologies are available. We will discuss this further in Sect. 5.

3.4 Model 3 Scheme End States

Model 3 schemes also consider alternative technologies other than blockchain. One of the outcomes of IBM’s scheme is ‘consider alternative approaches’, but it does not say what these alternatives might be. The scheme by DHS does suggest some concrete alternatives, such as a database or a managed database. Quindazzi refers to the traditional ledger (as in the current banking system) as an alternative to other types of ledgers. However, these suggestions are generic and do not point out which type of database should be used. Clearly, the end states of which type of database to use can be refined in these models.

3.5 Scheme Questions

In this section we analyze all schemes, and group and classify the questions that are used to determine an end state; see Table 2. To be able to reach any of the three model end states (as discussed in the previous section), each question should lead to an answer which holds a (database) technology property. In particular, we are interested in questions that differentiate between technologies [41], which we label ‘T’. For our scheme we currently consider the remaining questions as not relevant. We classified the questions as follows:

  1. 1.

    Our first question type refers to determining which database type is needed. We label these as ‘T’.

  2. 2.

    Also, there exist questions that address the current limitations of blockchain, which we label as ‘L’.

  3. 3.

    A particular set of questions focus on the system design, instead of technological properties. For example ‘(do you need) censorship resistance’ and ‘where is consensus determined’ are design questions. These scheme questions consider this to be a prerequisite for the use of a technology. We do not consider these questions for our scheme, as they do not distinguish between technologies from a technical perspective. We label these questions as ‘E’.

  4. 4.

    We label our fourth question type as process questions, ‘P’. The answers to these questions also do not in particular differentiate between technologies. Therefore, these questions types in the schemes are irrelevant for determining if, and if so, which database technology can be used. For example, the questions ‘aiming to remove third parties?’, ‘looking to reduce costs?’, and ‘can participants adopt?’ are process related questions. We do not include these questions in our scheme, see Sect. 4.

    Also, some schemes (e.g. Cooke, Suichies, WEF) include the question ‘Are writers interests unified?’ to determine the appropriateness of blockchain, and consider that if this is indeed true, no blockchain is needed. However, the interests of the honest participants may be aligned, but not the interests of a malicious participant. The point here being that when choosing a particular technology, the basic issues (such as the double spend attack in blockchain) should be considered as part of the system. Therefore, the interests of participants by default are not aligned, which is why we consider this question not to be relevant for our scheme.

  5. 5.

    Two questions stand out because these are the questions that we aim to answer, namely if, and if so which blockchain is needed in a particular scenario. These two questions, which we label ‘D’, are ‘Traditional approach results in consistency loss?’, and ‘Can other technologies offer a solution?’. Again, we exclude these particular questions from our scheme, as they do not differentiate between technologies.

Including the Questionnaires. The questionnaires consist of a list of questions that must be answered affirmatively to determine if blockchain may be a suitable solution However, only the schemes by Greenspan and Deloitte state that all questions must be answered affirmatively for this technology to be useful. Therefore, because of the schemes boolean end states, these can be considered a flow diagram, too. The questionnaires by Capgemini, PWC and Meunier provide an approximation of the number of questions that must be answered affirmative, making it unclear when exactly blockchain is useful.

From all questionnaires we can conclude that there are two end states, similar to scheme model 1. Although the questionnaires do not follow a particular flow, their questions can be classified, similar to the questions made in the flow diagrams. Therefore, we include their questions in Table 2, too.

Summary. From Table 2 we observe that most questions are process questions. Moreover 25 out of the 30 schemes contain questions that do not contribute to the overall question the scheme aims to answer. Furthermore, none of the schemes address all tech type questions. This suggests the need for a new scheme.

Table 2. Scheme questions classification
Full size table

3.6 Inconsistency Between Schemes

There are clear contradictions between some of the schemes: these schemes come to different conclusions based on identical answers to the questions used in the schemes. Below we give some examples of contradictions we observed.

Comparison 1: Cooke vs. Gardner. We present our results in Table 3. From this table we observe that making similar decisions in the schemes may lead to different answers. The difference can be explained by the additional question by Cooke, namely ‘are writers interests unified?’. Cooke considers this a relevant question, whereas Gardner’s scheme omits this question. As discussed in the previous paragraph, we consider this question not to be relevant for deciding which scheme to use as one must assume that writers interest always are misaligned.

Table 3. Comparing scheme choices of Cooke, and Gardner
Full size table

Comparison 2: Wüst vs. Hyperledger. In Table 4 we compare the two schemes of Hyperledger and Wüst in deciding which type of blockchain could be used. In this comparison a difference in terminology appears, as the scheme by Wüst is more fine-grained. Whereas Wüst uses a combination of two axis (permissionless/permissioned, and, public/private) to describe blockchain, Hyperledger uses only two terms (either permissioned, or public). Here, the Hyperledger scheme could be improved by using similar end states as Wüst.

Table 4. Scheme end state comparison between Wüst and Hyperledger
Full size table

Comparison 3: IBM vs. Verslype. The IBM scheme suggests that working with complex business logic may be an argument for using a blockchain. In contrast, Verslype suggests that simple business rules may be an argument for using a blockchain. Clearly, these two schemes contradict each other. It is not clear which scheme is correct, as there is a lack of description of what this specific question means. A possible explanation for the apparent contradiction is that the two schemes consider different types of blockchain. Complex business rules can be, to some extent, captured by smart contracts. Therefore, the IBM scheme is probably considering a blockchain similar to Ethereum that supports smart contracts. However, not all blockchains can deal with complex smart contracts; for instance, Bitcoin does not. Therefore, the scheme by Verslype is probably considering a blockchain as used in Bitcoin.

Summary. These comparisons show that inconsistencies between schemes may be explained by several factors. First, the comparison between the schemes of Cooke and Gardner show clear contradictions. Second, the comparison between Wüst and Hyperledger shows that there is a difference in granularity of the end state description. Finally, some inconsistencies between schemes may explained by the schemes considering different types of blockchain solutions, as we assume is the case in the contradiction between IBM and Verslype.

4 A New Scheme

In this section we propose a new scheme that is based on the three scheme models identified in Sect. 3. Our scheme aims to answer three questions:

  1. 1.

    Should you use a blockchain? (scheme model 1).

  2. 2.

    If so, which type of blockchain is best? (scheme model 2).

  3. 3.

    If not, which alternative database technology is best? (scheme model 3).

We include alternative technologies in our scheme, and we focus only on the questions that differentiate between technologies. Because of this, our scheme aims to replace all 30 schemes.

4.1 Scheme Questions and End States

In explaining our scheme, we use our terminology from Sect. 2. Our new scheme starts with the need for storing state (1, see Fig. 2). If indeed a database is needed and there exists only a single writer (2) that performs state updates, a central database (end state II, see Fig. 2) can be used.

If, however, there are multiple writers (2) and there exists the need to control functionality (3) by a specific party a shared central database (III) should be used. Here we assume that there exists such a specific party, and that the writers trust this party. Controlling database functionality may include setting the rules on how database permissions are set (such as create, store, delete), how the data is stored in the database (a relational database or an object oriented database), or how the database can be queried (e.g. ServerSQL, or MySQL). Similarly, if all participants agree that a third party (4) provides states updates, also a shared central database should be used. Note that we omit the question ‘Is public verifiability required?’, in contrast to, for example, Wüst and Gervais [56], as we consider this to be a design question. In particular for blockchain, this question is inherent to the technology. For all other technologies some form of public verifiability could be present, for example by giving auditors access to the ledger.

Thus, so far we consider that there is a need to store state and multiple participants are present that do not wish to use a single party for state updates.

The next question is about transaction interaction. If no transaction interaction (5) is required, a distributed database could be used, for example the cloud storage network Storj (IV) [30].

If transaction interaction is required, participants are known (e.g. through a certificate authority) (6), and anyone can join the network (7), again a distributed ledger could be used, for example Ripple (V). When a form of access control (7) is in place, still, a distributed ledger can be used, for example Corda (VI). Note that, in principle, a blockchain could be used in these cases (IV, V, VI). However, other technologies are present that do not lack the current drawbacks of blockchain. As one of the anonymous reviewers pointed out: “Blockchains are often sufficient but not often necessary”.

If participants are unknown, then blockchain may provide a solution. Here, our scheme is in line with Perlman [50] who states that a blockchain can achieve consensus amongst a consortium of unknown participants. Our scheme also takes some of the current limitations of blockchain into account. Currently, blockchain is limited in processing a large number (a ball park figure is greater than 2000 transactions per second) of transactions (8). and is not fit for storing large amounts (e.g. Tera-bytes) of transactional data (9). Although current research in scalability has shown significant improvements, for example Omniledger [42], there are currently no real life implementations on a global scale. Then, according to our scheme, there is currently no solution available (VII). However, if these two properties do not matter, then a public permissionless blockchain (VIII) should be used.

Fig. 2.
figure 2

Scheme for determining which type of database is appropriate

Full size image

5 Discussion

Following our scheme, blockchain is only needed where there exists a group of unknown participants that wish to reach consensus. Blockchain could be used in any case where there exists a need for a database. This may give rise to the notion of public permissioned blockchains and private permissioned blockchains, which are in essence a shared database [3, 45]. However, using blockchain in those cases where alternative technologies are suggested in our scheme may not be the best choice, considering the issues blockchain currently has, as discussed in Sect. 2. This is why our scheme includes only one type of blockchain, namely the ‘classic’ public and permissionless blockchain.

Schemes closely related to our work, for example Wüst and Gervais, Peck, Pahl, and Lin et al., address the question ‘do you need a blockchain?’. Their schemes suggest either to use a type of blockchain, or not to use a blockchain. This, however, is misleading as the scheme suggests that blockchain is needed, whereas other technologies are available. Such technologies do not have the current limitations of blockchain. In fact, these technologies have been tested over time and have proven to provide a functionality that is desired. We argue that the end states of decision schemes should at least include technologies that provide the desired functionality, and where possible without the limitations of blockchain. Therefore, we argue that the schemes that do not include alternative technologies are incomplete and hence wrong.

Also, in our analyses we labeled a large number of scheme questions as ‘process’, as these questions do not contribute to the overall question the scheme aims to answer, as discussed in Sect. 3. The questions labeled ‘process’, therefore, should not be included in these decision making schemes. Additionally, we labeled 9 questions as ‘tech’ meaning that these in fact do contribute to any of the scheme goals. We used these 9 questions and created a new scheme, together with the end states of alternative technologies, see Fig. 2. As our scheme includes all relevant questions of the identified schemes and questionnaires, includes end states that suggest alternative technologies, and our scheme determines if blockchain should be used, we argue that our scheme can replace the identified 30 schemes.

6 Future Work

Our scheme can be used for determining if blockchain is needed from a technical perspective. Our scheme can be extended with non-technical questions that drive the adoption of blockchain, for example philosophical beliefs and economic incentives. Furthermore, our scheme provides an overview of various types of distributed ledger technologies. This could be expanded with more distributed ledger technologies. Additionally, our scheme could be expanded by including current issues of distributed ledgers. Additionally, a further analysis on the consensus between the schemes can be made.

The concept of trust also merits further research. Trust is a important concept which is not really considered in our scheme (except in the question ‘can you use a third party?’). It is clear that trust shifts with the introduction of blockchain. Indeed, replacing trust with cryptographic proofs was one of the motivations behind Bitcoin. Still, introducing a blockchain does not remove all need for trust, as it may also introduces new types of trust.

7 Conclusion

With a growing global interest in blockchain, many decision schemes have been proposed to determine if blockchain is suitable, and if so which type. This paper analyzed 30 of such schemes. We classified these schemes based on which of the following three questions they try to answer: Should you use a blockchain? If so, which blockchain variant is best? If not, which alternative is best?

Our analysis of these schemes shows that over half of the schemes contain questions that do not contribute to the goal of the scheme. Furthermore, many schemes are biased in favor of blockchain-based solutions, as their end states only consider some type of blockchain. Such schemes seem to disregard alternative solutions and suggest that blockchain is needed in most scenarios – incorrectly in our opinion, if one takes into account that these alternatives lack some of the drawbacks and limitations of blockchain-based solutions. Of course, we are not the first to argue that for many proposed applications blockchain-based solutions are not the best solution, or not even suitable at all [12, 36, 37, 40, 44, 49, 50, 53, 54].

Furthermore, like Birch et al. [34] and Maull [45], we observe that there exists a Babylonian confusion with regards to the term blockchain. This is why we put the term blockchain into perspective alongside other database technologies, before our analysis of the schemes.

Our analysis shows that there are inconsistencies between the schemes, where the same decisions lead to different outcomes, or, conversely, similar outcomes can be reached with opposing decisions. There clearly is a need to improve these decision schemes.

We argued that if one uses a blockchain-based solution, only a public permissionless blockchain really makes sense. Although other blockchain types could be used in some scenarios, alternative technological solutions are then always a better choice as they lack some of the downsides and limitations of blockchain. Finally, our scheme is a practical guide for blockchain initiatives that need to determine which technology is suitable for a particular scenario.