A Comprehensive Reference Model for Blockchain-based Distributed Ledger Technology Andreas Ellervee1 , Raimundas Matulevičius1 , Nicolas Mayer2 1 Institute of Computer Science, University of Tartu, Estonia, andrease@ut.ee, raimundas.matulevicius@ut.ee 2 Luxembourg Institute of Science and Technology, 5 Avenue des Hauts-Fourneaux, L-4362 Esch-sur-Alzette, Luxembourg Nicolas.Mayer@list.lu Abstract. Blockchain is a distributed, transactional database that is shared across all the nodes participating in the network. This is the main technical innovation of Bitcoin and it acts as a public ledger for the transactions. However, this technology lacks standardisation and uni- form understanding. This is due to a few studies, that would provide a comprehensive model of the blockchain and the distributed ledger tech- nology. In this paper we compare four blockchain technology platforms and focus on their business level properties including actors and roles, services, and processes and data model. Our comparison results in a ref- erence model, which could potentially guide the business analysts, sys- tem analysts and software developers when developing new blockchain platforms or their supported implementations. Accuracy of the proposed reference model is validated by considering it against selected blockchain technologies. Keywords: Blockchain technology, Reference model, Distributed ledger, Bitcoin, Etherum 1 Introduction The first implementation of the blockchain technology, i.e. Bitcoin, was intro- duced in 2009 [12]. Since its release, the popularity of bitcoins and cryptocurren- cies has only kept growing, because customers have started to value the conve- nience and security of digital currencies, enabled by the blockchain technology. In the traditional banking systems, the ledger is a centralised party (e.g., the bank), which stores all the transactions. Blockchain, which serves as the decen- tralised public ledger, can also be applied to other fields, such as healthcare, insurance, data verification and others. Different businesses have developed various implementations using the block- chains. However, only limited analysis [10] exists on the conceptual explanation and understanding of the blockchain technology. In this paper we consider how to unify this understanding and propose a comprehensive reference model to characterise the blockchain technology. Our proposed model is developed and Copyright © by the paper’s authors. Copying permitted only for private and academic purposes. In: C. Cabanillas, S. España, S. Farshidi (eds.): Proceedings of the ER Forum 2017 and the ER 2017 Demo track, Valencia, Spain, November 6th-9th, 2017, published at http://ceur-ws.org 2 A. Ellervee, R. Matulevičius, N. Mayer its accuracy is validated by considering actors, services, processes, and data of the existing blockchain platforms. Being presented in ArchiMate, BPMN and UML modelling languages, the proposed reference model could potentially guide business analysts, system analysts and software developers when engineering applications using blockchain technology, developing new blockchain technology platforms, analysing and comparing existing blockchain solutions. In Section 2 we give an overview of the state of the art of the blockchain technology. Based on it, in Section 3 we present the reference model for the blockchain technology. Section 4 describes how the accuracy of our proposal is validated. Finally, Section 5 concludes the study and presents some future work. 2 State of the Art In this section, first we will define scope and discuss study background. Next we will survey the blockchain technologies following the scoped properties. 2.1 Scope and Background Blockchain acts as a distributed public ledger. It is a digital record of transactions and ownership, that is replicated among all of the participants of a peer-to-peer network. A consensus algorithm ensures that each node owns the same copy of the ledger as the other nodes. Technically, it is a back-linked ordered list of blocks, where each block contains transactions [2]. Each time a transaction is made, it is broadcasted to the network. If it is valid, it gets added to a block. When new block is published to the network, all participants (nodes) will run algorithm to validate the block. Majority of the nodes have to agree that the new block is valid and if so, it will be added to the blockchain. Once a block of data is recorded on the blockchain ledger, data becomes more secure as the blockchain grows [13]. There are two main types of blockchains: public and private. Bitcoin has a public ledger i.e., a public blockchain, where anyone is allowed to contribute [14]. There is no need for a third authority to grant permissions. Private blockchain is a network where all the participants are known and trusted [6] and the consensus process is managed by a pre-selected set of participants [3]. In our study we consider both public and private blockchains along the following properties: – Platforms - we are considering implementations of the blockchain technol- ogy that introduce different approaches to privacy and smart contracts. – Actors - we want to know who the actors are and what roles they play in the given blockchain technology. – Services - what services are provided by the blockchain platform? Who interacts with the services (business level)? – Processes - what are the underlying processes to services? How do network, transaction and mining/consensus processes work? – Data models - what are the entities that hold information? What are the relationships between them? Comprehensive Reference Model for Blockchain Technology 3 Blockchain technology platforms can be separated into four groups [1] [11] as illustrated in Table 1. For our study we have selected one blockchain platform of each group. Some others could have been chosen, but we decided to select the most widespread, based on our current knowledge. They can be characterised as follows: – Permissionless - Fully public blockchains, where anyone can read and write. – Permissioned blockchain technology allows to define different permis- sions on different users on the network. There can be different permissions for reading data, creating transactions, validating blocks, creating new ones and others. – Blockchains with Smart Contracts enable “smart contract” like capa- bilities and allow building business logic and business process mechanism into the chain. – Blockchains with transactions only are built for transaction capabilities. They support transferring value from one account to another. Table 1: Overview of chosen blockchain technologies Permissionless Permissioned With Smart Contracts Ethereum Chain Core Transactions only Bitcoin MultiChain 2.2 Comparison of Actors Blockchain technology relies on a decentralised network of individual nodes, but nodes have different purposes and different roles. Table 2 shows an overview of actors who are present in the analysed blockchain platforms. Table 2: Overview of actors from different platforms Platform Actors Bitcoin Client (Sender / Receiver of Bitcoins), Miner MultiChain Client, Miner Ethereum Externally Owned Account, Contract Account, Miner Chain Core Client (Issuer / Spender of assets), Blockchain operator (Generator / Signer) For each platform, there exists a notion of a Client and a Miner or someone who builds and agrees upon which transactions are included in a block [2] [9] [8] [5]. Client interacts with the blockchain (exchanges or adds value by creating and broadcasting transactions). In Ethereum an Externally Owned Account (EOA) is equivalent to the physical actor; and Contract Accounts (CA) can be understood as a system user which acts upon a request by an EOA or by another CA. Since CA is created by an EOA and interacted with by EOA and that they are autonomous agents living inside the execution environments [8], we do not consider CA as a separate actor. 4 A. Ellervee, R. Matulevičius, N. Mayer Miners deal with validating transactions and building new blocks. Since Chain Core is a private blockchain, it has Blockchain operators, who are either block generators or signers. Fundamentally, a Blockchain operator is a miner, because miner’s tasks in a blockchain environment are to create new blocks, sign them, validate them and submit them to the blockchain. In conclusion, blockchain technology has two primary actors at the business level: – Human actor who interacts with the blockchain by creating transactions. This actor can be called a “User”. – Human or system actor responsible for verification and validation of trans- actions, building new blocks, signing new blocks and publishing new blocks to the blockchain. This actor supports trust between the parties involved. In case of public blockchains “proof of work” is provided by the mining software (system), but, for example in Chain Core there exist Blockchain operators (human) who decide on the consensus. This actor can be labelled as “Block generator”. 2.3 Comparison of Services In this section we will compare services used by actors defined in the previous section. The services are summarized in Table 3. Table 3: Overview of services from different platforms Platform Services Bitcoin Create transactions, Mine bitcoins MultiChain Create assets, Create transactions, Grant permissions, Revoke permis- sions, Mine blocks Ethereum Create transactions, Create contracts, (Send messages), Mine blocks Chain Core Define and Issue assets, Submit transaction, Validate block, Gather valid transactions, Generate block, Publish block, Sign block, Determine who can participate in the network Firstly, every platform provides a service to create and broadcast transactions to the network. This is an essential service because transactions dictate the state of the blockchain and add new data to the blockchain. MultiChain and Chain Core have the notion of assets, which is a type of value, that is issued on the blockchain [9] [5]. Bitcoin and Ethereum both have their native currencies, bitcoin3 [2] and ether [8] respectively. MultiChain and Chain Core allow creation of different assets. Bitcoin and MultiChain focus on transactions and exchanging value. Ethereum and Chain Core also rely on state and smart contracts. Ethereum provides a ser- vice to create a new contract, that can be submitted to the network; and Chain Core supports the use of smart contract while issuing assets, by defining business 3 Bitcoin (with upper B) stands for protocol, the software and community, bitcoin (with lower b) stands for a unit of currency Comprehensive Reference Model for Blockchain Technology 5 rules for issuing (issuance program [5]) new units of given assets and also rules for spending the assets (control program [5]). Since MultiChain and Chain Core are both designed to support private block- chains, they support services to manage permissions. MultiChain provides ser- vices for granting and revoking permissions to and from specific users [9]. Chain Core allows Blockchain operator to manage connections via network tokens. All platforms except Chain Core are proof-of-work-based mining solutions. Mining in Bitcoin and Ethereum is publically available for anyone, while in MultiChain user needs to have permission to perform mining (or if everyone on the blockchain are known users, mining can be turned off alltogether [9]). In Chain Core, federated consensus [5] is applied by Block generators and signers. Block generator will use services like gathering valid transactions, generate block and publish a block. Block signers, who validate and sign the block, use block validation services and block signing services. In conclusion, common services among the technologies are creating trans- actions, validating blocks and mining / creating blocks. Additionally, permis- sioned blockchains provide services to manage permissions. Overall, it depends on the features offered by a blockchain, e.g., with Bitcoin being the most generic blockchain, the number of provided services is different compared to Chain or MultiChain. Features like assets, smart contracts and permissions add additional services to the commonly offered ones. 2.4 Comparison of Processes Table 4 provides our overview of the processes from different platforms. Processes are realisation of services, that the actors of the technology use. Table 4: Overview of processes from different platforms Platform Processes Bitcoin Network discovery process, Transaction creation process, Mining process, Block verification process MultiChain Handshake process, Transactions creation process, Mining process Ethereum Network discovery process, Transaction creation process, Mining process, Block validation process Chain Core Network discovery process, Transaction process, Chain consensus process Every platform has a network discovery process, which consists of 4 main steps - Peer discovery (finding peers to connect to, either user already knows the IPs or acquires them), Handshake (version check, establishing connection, pro- viding ownership of private key), Network discovery (finding neighbouring peers and letting the network know that a new node has connected) and Synchroniza- tion (downloading the latest block data from the network). In Bitcoin and Ethereum, new node connects to a known peer, they verify that both are running the same version of the software and have the same, latest and longest chain of blocks. In case of differences, new node will download the previous blocks up to the latest one. MultiChain expands the Handshake process 6 A. Ellervee, R. Matulevičius, N. Mayer [9] introduced in Bitcoin, by verifying that the connecting node’s public address is on the permitted list and by receiving a proof of the ownership of the private key. In Chain Core, the Block Generator will provide Block Generator’s URL, a network token and the blockchain ID to the connecting node. Creating the transaction in Bitcoin requires user to enter value and the receivers address. The transaction is then signed by the user and broadcasted to the network (to neighbouring nodes). The neighbouring nodes check the trans- action for validity. If valid, they will propagate it forward to other peers [2]. MultiChain adds additional metadata to the transaction, specifying asset name and transaction type (issuing or spending assets, granting permissions etc.). Similarly the transaction is constructed, signed and broadcasted to the network. In Chain Core, transactions issue new assets or spend existing assets. Issuing new assets or spending assets have to comply with the rules defined in the is- suance program or in the control program [5]. Ethereum also supports regular value transactions. The input parameters for the transaction are similar to Bit- coin and MultiChain (i.e. amount and the address of the receiver). Additionally Ethereum supports creating contracts and calling contract functions, which is an additional metadata added to a transaction. Another common process is the Mining process (Block generation pro- cess). Mining is based on the proof-of-work. A miner will build a new block, add collected unverified transactions and metadata, and calculate the computa- tionally exhaustive proof-of-work for the block. If he is the first one to solve the task and mine the block, he can submit the block to the network and receive a reward for that work. In Ethereum, the mining process also requires a state transition process, since it keeps a state of the blockchain. In the state transition process, transactions are validated and in case of contracts, code execution is also performed. When all the state transition functions are valid, miner in Ethereum will provide the proof-of-work for the block. In MultiChain, proof-of-work [9] is optional and mining is permissioned. MultiChain introduces mining diversity to vary the miners creating the blocks. Chain Core introduces a Chain consensus process [5]. When a new trans- action is submitted, it will be transferred to the Block generator who will add it to the new block. After certain periods, Block generator will construct the block and send it to block signers, who will validate the block, sign it and send it back to the Block generator. The Block generator can only submit the block if the required block signers have signed the block, according to the consensus program [5]. Bitcoin and Ethereum introduce the block validation process which is performed by every node once the miner broadcasts a new block. Since in the public blockchains the miners are anonymous, there has to be a guarantee that the miner has indeed produced a valid block. In Bitcoin, this is called a ‘consen- sus’ if all the nodes validate the new blocks against the same rules. In Ethereum, the validation is similar, but additionally it includes the state transition process, which each node has to perform before accepting the block [8]. Comprehensive Reference Model for Blockchain Technology 7 The four platforms provide similar general processes: Network discovery, Transaction creation, Block generation and submission (Mining and Chain con- sensus process) and Block validation. Conceptually, the processes may be similar, but the inner workflow differs from one technology to another. 2.5 Comparison of Data models All four blockchain technologies introduce a Block, a Block header and Transac- tions. Bitcoin, MultiChain and Chain Core also include Transaction Inputs and Transaction Outputs (UTXO). Ethereum relies on the state replication, where each new block’s state is the outcome of the transactions that were included in the block. Ethereum has chosen not to use the Input-Output transaction method, because it does not support multi-stage contracts or scripts that could keep an internal state [8]. Ethereum has the notion of Accounts, which are either user accounts or virtual contract accounts, that hold the balance, contract code and internal storage. In Ethereum case, all this data is stored on the blockchain. With the addition of Assets, Chain Core keeps an Asset entity containing only the asset ID. The assets are tied with certain programs (i.e. Issuance program, for issuing new assets, or Control program, for spending assets). The Consensus program is used by Block generator to verify that a block is ready to be submitted to the network. To conclude, the main set of entities are the Block, Block Header and Trans- actions. The Input-Output transactions are de facto Bitcoin solution to prevent double-spending, but there are several arguments about the use of unspent trans- action outputs and their scalability [4], so in case of Ethereum, to enable the multi-stage smart contracts, UTXO’s are not used. 3 A Reference Model for Blockchain Technology Figure 1 presents the business layer of the reference model represented with ArchiMate4 . It consists of six major components - Actors and Roles, Services and processes for Network Discovery, Transaction, Consensus and Block generation. We will discuss these components in the following subsections. 3.1 Actors and Roles In Section 2 we have concluded that there are two main roles (see Figure 1) for each node in the blockchain. We name these as User and Block generator: – User - Actor who interacts with the blockchain by creating transactions. – Block generator - Human or system actor responsible for validation of transactions, building new blocks, signing new blocks and broadcasting new blocks to the blockchain. This actor can also provide consensus to support trust between the parties involved (proof-of-work, proof-of-stake etc). 4 http://www.opengroup.org/subjectareas/enterprise/archimate-overview 8 A. Ellervee, R. Matulevičius, N. Mayer Fig. 1. Reference model for the blockchain technology 3.2 Services Figure 1 presents Service components which display the services used by actors to interact with the technology (services with dark background are specific to permissioned blockchains). Services are: – Transaction creation - Transactions allow Users to add information to the blockchain. Transactions can be used to create assets, spend assets, create smart contracts, call functions on smart contracts, manage permissions etc. – Transaction submission - Transaction submission support signing and broadcasting the transaction to the network. – Block validation - Block validation is a general service used by the nodes to validate the newest blocks that have been added to the blockchain. – Block generation - Block generation is broken down into smaller services that are used differently depending on the type of consensus. A miner in a public blockchain would use the block generation services, but in Chain Core, one party creates the block and other parties sign the block [5]. – Blockchain access - Blockchain access is specific to private and permis- sioned blockchains, where administrative nodes grant access to known par- ties. Can also be used to create network tokens for nodes. Comprehensive Reference Model for Blockchain Technology 9 3.3 Processes The reference model (Figure 1) includes four processes: Network discovery pro- cess, Transaction process, Consensus process, and Block generation process. We expand these processes using the BPMN modelling language.5 Network discovery process (Figure 2) consists of four subprocesses - Peer Discovery, Handshake, Discovering additional peers and Synchronization. Pro- cess begins by acquiring an IP of the known peer or blockchain (IP is known from the last session or is acquired from an outside source). Once connected, private blockchains will perform a check if the user is allowed to connect via its public IP or a network token. If permitted, a handshake process is carried out to verify versions and check that both nodes have the same blockchain with the latest blocks. Next, the connected node’s IP will be propagated to the network. Once the network is discovered the connecting node will synchronise its blockchain if any differences in terms of the latest block is observed. Fig. 2. Network Discovery process Transaction process (Figure 3) starts creation of a new transaction. Rel- evant metadata are added depending on the transaction type (e.g., standard transfer of funds, creating assets, deploying smart contract, etc.). In the case of private blockchains, there will be a permission check: (i ) whether the specific user is permitted to create the transaction, (ii ) whether the receiver is permitted to receive funds, (iii ) whether the network permits transfer of funds or creation of specific type of transactions, etc. If the transaction is permitted (or in case of public blockchains, the creator signs the transaction), it will be broadcasted to the network, i.e., to the neighbouring nodes. Consensus process (Figure 4) is performed by each node when a new block has been broadcasted. Each blockchain defines its own “Consensus rules”, according to the type of the validated blocks and transactions. If validated, the nodes will append the new block to the blockchain; otherwise it will be rejected. During the Block generation process (Figure 5), first, a new block is created; next, the previous block’s metadata is added. In case of the permis- sioned blockchains, permission changes have to be applied in order to avoid 5 http://www.bpmn.org/ 10 A. Ellervee, R. Matulevičius, N. Mayer Fig. 3. Transaction process Blockchain network Validate Validate proof generation Consensus process of work transaction for each Block rejected transaction No public blockchain Validate block Yes Add the new Verify according to block to private transactions consensus rules blockchain New block blockchain Block validated received Is the block valid? Fig. 4. Consensus process unwanted actions performed by users, who do not have permission. Next, all transactions will be validated against the consensus rules on the blockchain. In public blockchains, the block generators (i.e., miners) will provide a proof of the work (i.e., proof-of-work or proof-of-stake etc.) and will be rewarded for their work. In private blockchains, the consensus process might be part of the block generation process. Once the block is constructed, it is submitted to the network and propagated to all the nodes. 3.4 Data model The data model is presented in Figure 6. The model shows that keeping the state of the blockchain is preferred here in comparison to the Input-Output type transaction logic. Since UTXOs are stateless [4], they are preferred for issuing assets or performing standard transfer of value (assets or cryptocurrency). However, since smart contracts are powerful, keeping the state of the blockchain supports complex logic better than UTXOs. State contains accounts, which have balance and address. In case of contracts (marked with grey box in Figure 6), they also have to keep the executable code and storage specific to the given account. Accounts are linked to transactions and Comprehensive Reference Model for Blockchain Technology 11 Network Unverified for each transactions transaction Apply public Create new Block generation process permission blockchain Broadcast the block Provide proof block to the changes for each Previous block transaction network created private blockchain Validate Collect Add previous transactions Consensus unverified Sign the block block metadata public according to process transactions Block created blockchain consensus rules private blockchain Fig. 5. Block generation process Fig. 6. Data model each transaction changes the state of the blockchain (balance changes, contracts function calls etc.). Block and Block Header are standard and essential to every blockchain platform. Block contains transactions; the block’s metadata is kept in the Block Header. 4 Validation To validate the reference model we investigate its accuracy by comparing it to the existing blockchain solutions. Firstly, we compare the reference model to the four implementations that were used to build it. We define a Delta (i.e. ∆) metric, which represents the differenc between the reference model and the models of the considered blockchain technologies. Secondly, we select four new blockchain platforms and calculate the Delta value for them. Our goal is to show that using the reference model we are able to capture business perspective of all selected blockchain technologies. Delta definition. Finding the delta ∆ for the four initial Blockchain tech- nologies (Figure 7), we will compare actors, services, processes and data models 12 A. Ellervee, R. Matulevičius, N. Mayer Fig. 7. Accuraccy validation process separately. The overall ∆ will be the sum of all deltas (∆ = ∆actors + ∆services + ∆processes +∆datamodels ). ∆ = 0 means they have the same entities. ∆ > 0 means the unified model has more entities. ∆ < 0 means that the reference model is missing some entities, that the comparable model has. Finding the delta ∆ for the four new Blockchain technologies (Figure 7), we will also compare actors, services, processes and data models separately, but we will only take into eval- uation if the given entity exists or is present in the newly presented technology. ∆ = 0 means they have the same entities. ∆ > 0 means the reference model has more entities. Table 5: Results of the delta ∆ for the selected Blockchain technologies Actors Services Data model Networking Transactions Consensus Validation Blockchain platforms used to construct reference model Bitcoin 0 0 2 0 0 0 0 MultiChain 0 0 2 0 0 0 0 Ethereum 0 0 0 0 0 0 0 Chain Core 0 0 0 0 0 0 0 Blockchain platforms not used to construct reference model Cryptonote 0 0 2 0 0 0 0 NXT 0 0 1 0 0 0 0 Hyperledger 0 0 1 1 0 1 0 Tendermint 0 0 1 0 0 0 0 Results for the ∆ values are presented in Table 5. The goal of accuracy validation was to get a ∆ value as close to 0 as possible for initial four technologies as well as for four new technologies that were not used as a basis of building the model. From the results we can see that the initial four technologies are covered almost accurately by the reference model, with subtle differences in Data models (e.g., four differences - Bitcoin and MultiChain do not support Accounts and State). We consider this result acceptable, because of the differences that smart contracts introduce to the data model (see Figure 6). Comprehensive Reference Model for Blockchain Technology 13 As for the four technologies that were not part of the initial building of the model, we found differences in the data models (e.g., five entity differences - CryptoNote and NXT do not keep the blockchain state, Hyperledger Fabric does not have Block Header, Tendermint misses account representation), Networking process (one entity difference - Block synchronization) and Consensus process (e.g., one entity differences - Transactions in Hyperledger Fabric are verified and endorsed before reaching the miner). This result is also considered acceptable, due to the fact that the new blockchain technologies are different from the initial four technologies, but still perform well under the defined blockchain properties. Threats to validity. The accuracy validation was done by the first author of this paper with the technologies in hand. Thus, another validation approach might conceive different results, either by defining the Delta differently or by se- lecting different implementations of the technology. We did not constructed con- ceptual models for platforms which were not used to create the reference model. These were assessed following their documentations. Potentially we could miss some concepts from the comparison. However this is less likely as the majority of the entities were in fact captured as shown in Table 5. 5 Concluding remarks This paper gives an overview of the disruptive blockchain platforms: Bitcoin, MultiChain, Ethereum and Chain Core. Each of them presented a different ap- proach to networking, transactions, mining, validation, security and permissions. The comparison resulted in the reference model, that aims to represent the do- main of the blockchain technology. The model contributes to the explicit under- standing of the technology and its work processes. The paper also presents a brief overview of validation performed on model with the corresponding results. The results reflect that the reference model performed well to cover the known blockchain technologies, such as Cryptonote, NXT, Hyperledger and Tender- mint. The results potentially indicate how to develop this fast growing technol- ogy further and in a more secure way by expanding its disruptive nature to other application domains. When it comes to standardisation of the blockchain technology and its pre- sentation it in an unified way, there exist some study that thrive towards this goal. In [10] the technology is defined using three layers - Essential, Infologi- cal and Datalogical layer. The information is presented in the UML model and explains the general overview. However it lacks details to define relationships between actors and processes. In our work we have used different notations to present the reference model. We hope that it would guide the business analysts and help them to communicate with the developers. Additionally, we explicitly present the link between the users and processes and expand these processes by showing targeted private and public activities. Finally, the accuracy of our proposal is validated with respect to other blockchain platforms, which were not used to create the reference model. 14 A. Ellervee, R. Matulevičius, N. Mayer This type of research on the blockchain technology is a first and hopefully a basis to future research. This being said, we plan to further validate the model via security assessment [7], by aligning the reference model to ISSRM6 . This alignment (using ArchiMate and BPMN) will help us observe what actors are affected, what services are they using and what processes implement those ser- vices. Then, using BPMN representations it will possible get a details of the affected processes. This can be achieved thanks to the reference model. References 1. Allaby, D.: The Trust Trade-Off: Permissioned vs Permissionless Blockchains. Fjord (Oct 2016), https://www.fjordnet.com/conversations/ the-trust-trade-off-permissioned-vs-permissionless-blockchains/ 2. Antonopoulos, A.M.: Mastering Bitcoin: Unlocking Digital Crypto-Currencies. O’Reilly Media, Inc., 1st edn. (2014) 3. Buterin, V.: On Public and Private Blockchains (2015), https://blog.ethereum. org/2015/08/07/on-public-and-private-blockchains/ 4. Buterin, V.: Thoughts on UTXOs by Vitalik Buterin, Co- Founder of Ethereum (2016), https://medium.com/@ConsenSys/ thoughts-on-utxo-by-vitalik-buterin-2bb782c67e53#.s3c7dtmxp, [Online; ac- cessed 10-January-2017] 5. Chain: Chain Protocol Whitepaper. Tech. rep., https://chain.com/docs/protocol/ papers/whitepaper 6. David Moskowitz, Tim Swanson, R.C.: A Gentle Introduction to Blockchain Technology (2015), https://bitsonblocks.net/2015/09/09/ a-gentle-introduction-to-blockchain-technology/ 7. Ellervee, A.: A Comprehensive Reference Model for Blockchain-based Distributed Ledger Technology (2017), http://kodu.ut.ee/∼andrease/ellervee blockchain reference model.html 8. Ethereum: A Next-Generation Smart Contract and Decentralized Application Plat- form (2016), https://github.com/ethereum/wiki/wiki/White-Paper, [Online; ac- cessed 6-October-2016] 9. Greenspan, D.G.: Bitcoin network — Wikipedia, The Free Encyclopedia (2015), http://www.multichain.com/download/MultiChain-White-Paper.pdf, [Online; ac- cessed 12-December-2016] 10. de Kruiff, J.: Understanding the Blockchain Using Enterprise Ontol- ogy (2017), https://www.list.lu/fileadmin/files/Event/sites/tudor/files/Training Center/OTHERS/VMBO2017 paper 5.pdf 11. Kuhlman, C.: How I (currently) Explain The State of Blockchains To Executives and Researchers (2015), https://monax.io/2015/08/10/ how-i-current-explain-blockchains/?redirect from eris=true 12. Nakamoto, S.: Bitcoin: A Peer-to-Peer Electronic Cash System. Tech. rep., https: //bitcoin.org/bitcoin.pdf 13. Norton, S.: CIO Explainer: What Is Blockchain? The Wall Street Journal (2016), http://blogs.wsj.com/cio/2016/02/02/cio-explainer-what-is-blockchain/ 14. Pilkington, M.: Blockchain Technology: Principles and Applications. Research Handbook on Digital Transformations, edited by F. Xavier Olleros and Majlinda Zhegu. Edward Elgar (2016) 6 Information Systems Security Risk Management