key: cord-0058316-ykihimji
authors: Koens, Tommy; Poll, Erik
title: Blockchain Utility in Use Cases: Observations, Red Flags, and Requirements
date: 2021-02-15
journal: Euro-Par 2020: Parallel Processing Workshops
DOI: 10.1007/978-3-030-71593-9_1
sha: 5fbe2af945e3038b1adb92d3af7c1ba8384834ec
doc_id: 58316
cord_uid: ykihimji

On a global scale blockchain is persistently proposed in thousands of use cases by corporates, governments, and academics. However, there is a lack of systematic evaluation of these use cases and the utility of blockchain. In this work we systematically evaluate fifteen use cases that use blockchain. Based on our evaluation we observe six recurring problems in these use cases. These problems either relate to the utility of blockchain in the use case, or to how well-documented a use case description is. We point out four red flags that, whenever they occur in a use case description, signal that blockchain may be a sub-optimal solution for that use case. Notably, one of these red flags indicates that there are no clear requirements in the use case descriptions that warrant the use of blockchain. We address this by proposing a set of requirement templates for any use case that includes a transaction system.

It is estimated that global spending on blockchain reaches 9.2 billion US dollars in 2021 [7] . Indeed, there is much attention from corporate institutions, governments, and academics to blockchain. Many use cases have been proposed that use blockchain in, for example, healthcare [43] , and cloud computing [33] . Such use cases advocate blockchain as a solution to a particular use case problem. There is, however, a lack of a systematic evaluation of use cases and the utility of blockchain. To address this we make the following three contributions:

1. We systematically evaluate fifteen use cases that apply blockchain based on a decision scheme which we improve. From our evaluation we observe six recurring problems, including that there is a bias towards decentralisation, fallacies on blockchain properties occur, and there are no requirements that warrant the use of blockchain.

2. From these six observations we introduce four red flags. Raising such a flag signals that blockchain may be a sub-optimal solution for a use case; blockchain is a sub-optimal solution when alternative technologies can be used. These red flags also allow for a quick evaluation of a use case description. We apply these red flags to the fifteen use cases and evaluate our findings. 3. Red flag 1 'no clear requirements' is raised for all fifteen use case descriptions.

We argue that defining use case requirements must precede any technological choice. We address this by proposing a set of requirement templates for any use case that includes a transaction system.

Bitcoin [30] and Ethereum [41] are two examples of a decentralised transaction system. Both systems use blockchain to create a public and permissionless ledger. This type of ledger allows for an unbounded number of pseudonymous participants to reach consensus on the state of a ledger. By contrast, private and permissioned ledgers, such as Corda [17] , allow a select number of known participants to view the content of the ledger. Also, a select number of participants can participate in creating and verifying transactions. In this research we evaluate use cases that aim to use either Bitcoin or Ethereum. We use Bitcoin as an example to describe a public and permissionless ledger because such a description is sufficient for our research. In a public and permissionless ledger participants may own one ore more tokens (e.g. bitcoins). Participants can propose a change of ownership by means of transactions (txs). To prevent a participant from spending a token twice, transactions are bundled in a one megabyte (MB) block by participants called miners. A miner that creates a new block attempts to solve a difficult cryptographic puzzle which is easy to verify. The probability of solving this puzzle increases with the amount of computational power a miner has. As such, miners may form a mining pool in which they combine their computational power.

Occasionally two miners find a block at the same time which may contain, possible, conflicting transactions. Here the chain of blocks branches into a fork. To address a fork, a rule in Bitcoin exists stating that only the chain with the most cumulative work (i.e. a solved puzzle) is valid. If one of the branches is extended by another block, then that branch becomes the new and valid chain, and the shorter branch is discarded by all network participants.

Currently there are four main challenges with public and permissionless ledgers. First, the transaction throughput in blockchain is limited. Bitcoin can process 7 transactions per second. Although improvements have been proposed for blockchain to increase transaction throughput, such as an increase in block size or off-chain payments, these solutions could lead to centralisation [24] . Second, some devices can not store the blockchain as it is too large, for example IoT devices. Although this can be addressed by light-clients, it would also lead to centralisation as a large group of nodes is now dependent on a small group of nodes to update the ledger [15] . Third, transaction finality is probabilistic.

There is a probability that a transaction will be removed from the ledger due to the appearance of a fork. Only when time progresses there is an increased probability that the transaction will remain on ledger. Fourth, transaction cost may exceed the value of tokens being transferred in a transaction. This makes that blockchain may not be suitable for specific use cases, for example, a use case that deals with micro-transactions.

Blockchain has been proposed in use cases where its usefulness is questionable. To address this, decision schemes have been proposed to determine if blockchain should be applied. We use the scheme by Koens and Poll [22] as they propose a new scheme based on an evaluation of 30 of such schemes. They show that there are contradictions between some of these schemes, whereas other schemes are biased towards blockchain. Their scheme allows for determining if blockchain is an optimal solution, and which alternative technologies can be used.

Their scheme involves nine conditions, where each condition either leads to another condition or leads to a technology that is considered the optimal solution for a use case. We briefly introduce these conditions in their respective order.

1. Need to store state? When state should not be stored then there is no need for a database. 2. Is there a single writer? If only a single writer exists then a central database can be used. 3. Need to control functionality? Controlling functionality is being able to determine which and how many functions a system can perform. For example, determining how the data is stored in a database. If control of functionality is required then a shared central database can be used. 4. Can you use a third party (TP)? If a third party can be used then a shared central database can be used. 5. Is there transaction (tx) interaction? This refers to the interdependency between transactions. For example, an account holding zero tokens can only send tokens by means of tx 2 once it receives tokens first from another transaction tx 1 . Transaction tx 1 therefore must be stored on the ledger first before transaction tx 2 can occur. If there is no need for transaction interaction then a distributed database should be used. 6. Are the participants known? This refers to if the identity of the participants should be known in a use case. If the identity of the participants should be known then the following question appears: 7. Can anyone join the network? If participants are known and anyone can join the network, a permissioned ledger should be used, such as Ripple [4] . If the participants are known and only a limited set of participants can join the network, then a permissioned ledger such as Corda [17] should be used. 8. Transaction throughput matters? Blockchains currently can not process a large amount of transactions per second [28] , which may be a limitation for a use case. 9 . Store large amount of data? Another limitation may be the need for storing large amount of data. Blockchains currently can not store large amount of data [28] .

Our Improvements to the Decision Scheme. We make three improvements to the scheme of Koens and Poll [22] :

1. We omit condition 3 from the scheme. A third party can be used if functionality needs to be controlled, which is related to the condition 4. If a third party can not be used then functionality can not be controlled. Therefore, the condition regarding the control of functionality is already included in the condition of being able to use a third party. 2. We find that all use cases can use a third party. According to the decision scheme a shared central database should be used. However, use cases 4 and 8 argue that the problem of the use case lies within centralisation itself. Even though it would be technically feasible to use a third party in these use cases, a third party seems not to be suitable because of trust issues. Therefore we add another condition: a. Is a centralised solution based on a single third party (TP) suitable? 3. Conditions 8 and 9 concern potential limitations of blockchain. Blockchain is proposed as a solution when none of these limitations matter. Otherwise, there currently is no solution available. However, these are not the only current limitations, as discussed in Sect. 2, which is why we add two more conditions: a. Transaction finality matters? and b. Transaction cost matters?

In our research we make six observations, see Sect. 4.1. Observations 1-6 have been made separately in the literature but are unrelated, for example in [10] and [22] in which fallacies about blockchain and blockchain limitations are discussed separately. In our work the six observations are a set of recurring problems in the fifteen use cases. In addition, our observations support each separate observation made in the literature. A description of the fallacies that occur, see Sect. 4, are furthermore described in the literature, for example in [38] . In our research we go beyond this description as we observe that these fallacies are used as a rationale to apply blockchain, and we argue in Sect. 4 that these fallacies can not be used as an argument for applying blockchain. In Sect. 4.2 we propose and discuss four red flags. We did not find any existing work that proposes similar red flags. Also, the observed relationship between red flags 3 and 4 is new in the literature.

Use case requirements have been proposed for particular domains, such as healthcare [43] , and internet service architecture [33] . Other use cases requirements have been proposed that are set by an external party [31] . These requirements are limited to a specific use case that is using blockchain. In Sect. 4.3 we propose a set of requirement templates. Our set of requirements can be used for any use case that includes a transaction system. This is useful because our requirements can be used to 1. prevent raising any of the red flags, and 2. determine the feasibility of using blockchain.

We conduct our research based on the Design Science Research (DSR) methodology. DSR is a research paradigm in which a researcher aims to answers questions via the creation of artefacts, thereby contributing new knowledge to the literature [18] . Such artefacts may include models, methods, constructs, and design theories [19] . In our research these artefacts are the red flags in Sect. 4.2 and the requirement templates in Sect. 4.3. We use a case study as our research method [14] . We use the improved version of the decision scheme, as discussed in Sect. 2, to systematically evaluate fifteen use cases that use blockchain. All use cases propose to use either the Bitcoin blockchain or the Ethereum blockchain. We choose five use cases that apply blockchain in identity management, five use cases in IoT, and five use cases in business process management, see Table 1 . We choose these topics as they are one of many application domains of blockchain [1] and because we find these interesting, and because the use case address a topic other than cryptocurrencies. Besides this, we aim to choose the use cases randomly to prevent a bias in evaluating the use cases. We aim to answer all scheme questions for each use case. The results of our evaluation are shown in Table 2 , where Y stands for 'yes', N stands for 'no', and U stands for 'unknown'. Here, 'unknown' means that the use case description does not provide an answer to the scheme question. In what follows we discuss our evaluation in more detail. 

Is there a single writer ?  N N N N N N N N N N N N N N N 

The difference between questions 3 and 4 is discussed in Sect. 2.1

From our evaluation we make the following six observations: In what follows we will discuss the observations in more detail.

Observation 1. The downsides of decentralisation are not discussed in any of the fifteen use cases. The use cases that do not wish to use a third party mention the downsides of centralisation, such as lack of trust between participants and a third party, lack of decentralisation, and lack of transparency. However, long before the advent of blockchain it has been argued that there are downsides of decentralisation [12] . In fact, Prud'Homme states that "... there are serious drawbacks that should be considered in designing any decentralisation program" [35] . A downside of fiscal decentralisation, for example, is that it may lead to disparity and adversely affect the distribution of equity, it may jeopardise stability, and it may undermine efficiency [35] . Note that these arguments are blockchain agnostic as they were stated before blockchain was proposed by Nakamoto [30] . As these downsides are not discussed there appears to be a bias towards decentralisation in the use cases. Such drawbacks should be discussed in the use cases, as the downsides of centralisation are also being discussed.

In the use case descriptions fallacies occur on blockchain properties. Such fallacies may lead to misconceptions about the advantages and limitations of blockchain [9] . The following fallacies occur in the use cases:

1. "Blockchain is immutable". Smith [38] , for example, argues that a blockchain is not immutable. Indeed, a blockchain must be mutable as forks may occur, as discussed in Sect. 2. 2. "Blockchain is fully decentralised". Bitcoin and Ethereum are not fully decentralised. In fact, the Bitcoin network is largely controlled by 8 mining pools, and the Ethereum network is largely controlled by 5 mining pools [13] . This centralisation contradicts the goal of the Bitcoin network [30] , as now participants have to rely on a few third parties processing payments. 3. "Blockchain does not include trusted third parties". Blockchain networks are largely dominated by a limited set of participants, see fallacy 2, and trust is placed in these participants to not to collude. 4. "Blockchain is trustless", and "blockchain increases trust". Lemieux [23] , for example, argues that blockchain is a trusted chain of transactions. Also, following the description at fallacy 2, trust is placed in a small group of miners to not to collude. 5. "Blockchain is scalable". In contrast, one of the challenges of blockchain is its transaction scalability [28] , as discussed in Sect. 2. 6. "Blockchain is safe and credible". The use cases do not provide a definition of the terms 'safe' and 'credible'. As such, there is no proof for this statement. 7. "Blockchain is anonymous". All use cases propose to use either the Bitcoin blockchain or the Ethereum blockchain. It has been shown that these blockchains do not provide anonymity as identities can be retrieved [29] .

Some of these fallacies are used as a rationale to support the use of blockchain in the fifteen use cases. However, as these are fallacies they can not serve as an argument for using blockchain. Observation 5. None of the use cases consider alternative technologies other than blockchain. As decentralisation is a recurring theme in all fifteen use cases, see observation 1, at least other technologies should be considered that also achieve decentralisation such as a distributed ledger.

Clear requirements that warrant the use of blockchain are not specified in the use case descriptions. In particular, scheme questions 8, 10 and 11 remain mostly unanswered, see Table 2 . To address observation 6 we propose a set of requirement templates for use cases that include a transaction system in Sect. 4.3.

In this section we propose four red flags for use cases that use blockchain, and we apply these red flags to the fifteen use cases. Blockchain may be a sub-optimal solution for a use case when one of the following flags is raised: Red flag 1 and 2 measure how well-documented use cases are, whereas red flag 3 and 4 provide technical insight in the utility of blockchain. Red flag 1 is derived from observations 1 and 6, as discussed in Sect. 4.1. Red flag 2 is derived from observations 4 and 5, red flag 3 is derived from observations 2 and 3, and red flag 4 is derived from observation 3, We observe from Table 3 that for all use cases almost all flags are raised. Red flags 3 and 4 are closely related in the fifteen use cases. Red flag 3 is not raised when current blockchain limitations are addressed, however, this raises red flag 4 for six of the fifteen use cases as a centralised solution is introduced, for example, a cloud provider. Red flag 4 is not raised when no centralised solution is proposed, however, this raises red flag 3 for nine of the fifteen use cases as the current blockchain issues are not addressed. The findings in Sect. 4.1, where we argue that the use cases may also use other technologies, appear to support the validity of raising these flags. This suggests that raising three of the four red flags is a signal that blockchain is a sub-optimal solution for a use case.

Our requirement templates are based on an analyses of use cases that are limited to either Bitcoin or Ethereum. Potentially, additional or other requirements can be proposed based on an analyses of use cases that use a blockchain other than Bitcoin or Ethereum. Additional requirements may be derived from an analyses of use cases in other domains, such as energy, health care, and finance. Evaluation of additional use cases based on other decision schemes, for example [42] and [34] , could be preceded by using our red flags. Those findings may introduce new red flags, and may support the validity of our red flags.

The need for decentralisation in the fifteen use cases is the opinion of those that performed the research. Looking beyond that opinion, future research should include the opinion of participants (such as consumers of a product) of a use case, and to what extent they believe decentralisation should be applied. Also, the meaning and consequences of decentralisation could be critically discussed in future work. Furthermore, a similar evaluation to our research could be performed of decentralised solutions that are not blockchain based, such as a Directed Acyclic Graph (DAG) [8] and Hashgraph [6] .

In this research we systematically evaluate fifteen use cases that propose blockchain as a solution. We argue that blockchain is a sub-optimal solution for these fifteen use cases. With billions of US dollars spend on blockchain, this is a concern, as blockchain may be a sub-optimal solution for other use cases, too. We point out four red flags that, whenever they are raised, signal that blockchain is a sub-optimal solution for that use case. Red flag 1, no clear requirements, is raised for all fifteen use cases. We address this by presenting eight requirement templates that can be applied to any use case that includes a transaction system. With these templates, corporates, governments, and academics may become more aware of the need for blockchain, or the lack of any such a need.

Blockchain applications-usage in different domains

SCPKI: a smart contract-based PKI and identity system

Blockchain-based ownership management for medical IoT (MIoT) devices

Ripple: overview and outlook

A usercentric system for verified identities on the bitcoin blockchain

ESORICS/DPM/CBT -2017

The swirlds hashgraph consensus algorithm: fair, fast, byzantine fault tolerance

Mastering Blockchain: Distributed Ledger Technology, Decentralization, and Smart Contracts Explained

Distributed ledger technology: blockchain compared to directed acyclic graph

Blockchain Beyond the Hype: What is the Strategic Business Value

Blockchain: properties and misconceptions

Requirements Engineering

Decentralization and corruption: evidence across countries

Decentralization in Bitcoin and Ethereum networks

Case Study Research: Principles and Practices

Is Bitcoin a decentralized currency?

DMN decision execution on the Ethereum blockchain

Corda: a distributed ledger

Design science research in information systems

Design science in information systems research

A decentralized solution for IoT data trusted exchange based-on blockchain

Managing IoT devices using blockchain platform

What blockchain alternative do you need?

Trusting records: is blockchain technology the answer? Rec. Manage

Lightning network: a second path towards centralisation of the Bitcoin economy

An identity management system based on blockchain

Caterpillar: a business process execution engine on the Ethereum blockchain

Blockchain based proxy re-encryption scheme for secure IoT data sharing

Top ten obstacles along distributed ledgers path to adoption

A fistful of Bitcoins: characterizing payments among men with no names

Bitcoin: a peer-to-peer electronic cash system

A blockchain-based approach for data accountability and provenance tracking

Designing a blockchain-based IoT with Ethereum, Swarm, and loRa: the software solution to create high availability with minimal security risks

Blockchain security in cloud computing: use cases, challenges, and solutions

Blockchain world-do you need a blockchain? This chart will tell you if the technology can solve your problem

The dangers of decentralization

Runtime verification for business processes utilizing the Bitcoin blockchain

Identity management using blockchain for cognitive cellular networks

The blockchain litmus test

Blockchain-based business process management (BPM) framework for service composition in industry 4.0

On availability for blockchain-based systems

Ethereum: a secure decentralised generalised transaction ledger. Ethereum project yellow paper

Do you need a blockchain?

Blockchain technology use cases in healthcare

Decentralizing privacy: using blockchain to protect personal data

 Table 3 . Red flags raised in each use case Red flag raised in use case a Red flag 1 2 3 . 4 5 6 7 8 9 10 11 12 13 14 15the flag is raised for a use case. N: the flag is not raised.

Red flag 1 'No clear requirements' is raised for all fifteen use cases. As such, none of the use case descriptions state clear requirements for the use of blockchain. This is a concern as use case requirements have to be defined before choosing any solution. Leaving the requirements implicit imposes a risk to the implementation of the use case, as better solutions may be available. To address this concern we propose a set of requirement templates. We derive requirements 1-4 from observation 3, and requirements 5-8 are derived from observation 2, as discussed in Sect. 4.1. These requirements can be used in any use case that includes a transaction system to verify the feasibility of the use case.Requirement Templates. Our requirement templates are based on the format proposed in the standard textbook on requirements engineering [11] : the <system> shall be able to <f unction> <object>.1. The <system> shall be able to process <...> transactions per second. 2. The <system> shall be able to store <...> MB of data.3. The <system> shall be able to finalise transactions in <...> seconds. 4. The <system> shall be able to limit the cost of a transaction to a maximum of <...> US dollar per transaction. 5. The <system> shall be able to provide a data storage that is <...> -Mutable. Data stored can be modified and appended.-Append-only. Data stored can only be appended.-Immutable. Data stored can not be modified or appended. 6. The <system> shall be able to provide user identities that are <...> -Known. The legal identity of a participant is known to all participants, for example the true name of a person. -Pseudonymous. The identity of a person is disguised by providing a false name, for example a public key. -Anonymous. The identity of a person being unknown. 7. The <system> shall be able to include at least <...> parties (for example, 1, 2, etc.) to use the <system>. 8. The <system> shall be able to distribute the capability of modifying the database over <...> (for example, anyone, a limited set of participants)