Comparative Analysis of Blockchain Technologies for Data Ownership and Smart Contract Negotiation Master’s Thesis in Computer Systems and Networks VAIOS TAXIARCHIS MALAMA KASANDA Department of Computer Science and Engineering CHALMERS UNIVERSITY OF TECHNOLOGY UNIVERSITY OF GOTHENBURG Gothenburg, Sweden 2019 Master’s thesis 2019 Comparative Analysis of Blockchain Technologies for Data Ownership and Smart Contract Negotiation VAIOS TAXIARCHIS MALAMA KASANDA Department of Computer Science and Engineering Chalmers University of Technology University of Gothenburg Gothenburg, Sweden 2019 “Comparative Analysis of Blockchain Technologies for Data Ownership and Smart Contract Negotiation” VAIOS TAXIARCHIS MALAMA KASANDA © VAIOS TAXIARCHIS, 2019. © MALAMA KASANDA, 2019. Supervisor: Gerardo Schneider, Computer Science and Engineering Examiner: Carl-Johan Seger, Computer Science and Engineering Master’s Thesis 2019 Department of Computer Science and Engineering Chalmers University of Technology and University of Gothenburg SE-412 96 Gothenburg Telephone +46 31 772 1000 Typeset in LATEX Gothenburg, Sweden 2019 iv Abstract Blockchain technologies have gained significant popularity in the recent past. They are distributed ledgers that record all the transactions on the network and allows parties who do not trust each other to transact. The parties collaborate in its main- tenance. The Blockchain’s distributed nature connotes multiple ethical and privacy concerns, such as unauthorized access and control of decentralized applications. In this thesis, we first survey the state of the art, focusing on a comparative analysis of public and private implementations of distributed ledgers. Additionally, we present a proof of concept (PoC) implementation on the access control to certain parts of smart contracts as well as investigate the possibility of negotiating the terms of a smart contract. We make use of the commercial real estate leasing operations as a case study. We conduct a comprehensive evaluation of our PoC. This evalu- ation demonstrates a trade-off in the choice of blockchain technology for building distributed applications. Drawing from the process flow of paper based contract negotiations, we design a library mechanism that can be used to negotiate contract terms in a bilateral fashion. Keywords: blockchain, smart contract, access control, commercial real estate, Ethereum, Hyperledger Fabric v Acknowledgements We would like to express our undying gratitude to our supervisor Professor Gerardo Schneider under whose guidance this work came to fruition. Furthermore, we would love to extend a vote of thanks to our examiner Professor Carl-Johan Seger whose constructive feedback went a long way during the course of our work. Vaios Taxiarchis and Malama Kasanda, Gothenburg, 2019 vii Contents List of Figures xiii List of Tables xv 1 Introduction 1 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Goals and Research Questions . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 Theoretical Background 7 2.1 Digital Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.1 Cryptographic Hash Functions . . . . . . . . . . . . . . . . . . 8 2.1.2 Symmetric-key Cryptography . . . . . . . . . . . . . . . . . . 9 2.1.3 Public-key Cryptography . . . . . . . . . . . . . . . . . . . . . 10 2.2 Blockchain Technology . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1 Public Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.1.1 Bitcoin: A Peer-to-Peer Electronic Cash System . . . 13 2.2.2 Private Blockchain . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.3 Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3 Use Case: Commercial Real Estate . . . . . . . . . . . . . . . . . . . 17 2.4 Role-Based Access Control . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3 Comparative Analysis 21 3.1 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.1 Ethereum Virtual Machine . . . . . . . . . . . . . . . . . . . . 21 3.1.2 Ether and Gas . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.1.3 Accounts, Transactions and Messages . . . . . . . . . . . . . . 23 3.1.3.1 Accounts . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.3.2 Transactions . . . . . . . . . . . . . . . . . . . . . . 23 3.1.3.3 Messages . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.4 Consensus Algorithm (Mining) . . . . . . . . . . . . . . . . . 24 3.1.5 Smart Contracts Deployment . . . . . . . . . . . . . . . . . . 25 3.2 Hyperledger Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.1 Transaction Processing . . . . . . . . . . . . . . . . . . . . . . 27 ix Contents 3.2.1.1 Endorsement Policies . . . . . . . . . . . . . . . . . . 28 3.2.1.2 Consensus Algorithm . . . . . . . . . . . . . . . . . . 28 3.2.2 Membership Services and Identity Management . . . . . . . . 29 3.3 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.1 Similarities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.2 Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.2.1 Network operation . . . . . . . . . . . . . . . . . . . 30 3.3.2.2 Consensus algorithm . . . . . . . . . . . . . . . . . . 31 3.3.2.3 Smart contracts . . . . . . . . . . . . . . . . . . . . . 31 3.3.2.4 System currency . . . . . . . . . . . . . . . . . . . . 32 3.3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4 Implementation 33 4.1 Design and Specification . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.1 System Description . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.2 Design of the Smart Contract . . . . . . . . . . . . . . . . . . 35 4.1.3 Design of the Negotiation Mechanism . . . . . . . . . . . . . . 37 4.1.4 Role-based Access Control Model . . . . . . . . . . . . . . . . 38 4.2 Hyperledger Fabric Implementation . . . . . . . . . . . . . . . . . . . 39 4.2.1 System Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.2.2 Transaction Processing . . . . . . . . . . . . . . . . . . . . . . 41 4.2.2.1 Access Restriction . . . . . . . . . . . . . . . . . . . 42 4.2.3 Negotiation Mechanism . . . . . . . . . . . . . . . . . . . . . . 43 4.3 Ethereum Implementation . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.1 System setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.3.1.1 Ethereum Node . . . . . . . . . . . . . . . . . . . . . 44 4.3.1.2 Remix Web Browser IDE . . . . . . . . . . . . . . . 44 4.3.2 Building the Smart Contract . . . . . . . . . . . . . . . . . . . 45 4.3.2.1 State Variables . . . . . . . . . . . . . . . . . . . . . 45 4.3.2.2 Functions . . . . . . . . . . . . . . . . . . . . . . . . 45 4.3.2.3 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.2.4 Access Restriction (Modifiers) . . . . . . . . . . . . . 47 4.3.2.5 Helper Functions . . . . . . . . . . . . . . . . . . . . 48 4.3.3 Negotiation Mechanism . . . . . . . . . . . . . . . . . . . . . . 49 4.3.3.1 Libraries in Solidity . . . . . . . . . . . . . . . . . . 49 4.3.3.2 Library Implementation . . . . . . . . . . . . . . . . 49 4.3.4 Wallet Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5 Evaluation 53 5.1 Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.2 Descriptive Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.2.1 Leasing Operation . . . . . . . . . . . . . . . . . . . . . . . . 54 5.2.2 RBAC Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2.3 Negotiation Library . . . . . . . . . . . . . . . . . . . . . . . . 60 5.2.3.1 Wallet Recovery . . . . . . . . . . . . . . . . . . . . 61 5.3 Ethereum gas consumption . . . . . . . . . . . . . . . . . . . . . . . . 62 x Contents 6 Conclusion 65 6.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Bibliography 69 A Appendix A I B Appendix B IX xi Contents xii List of Figures 2.1 Symmetric-key cryptography (single secret key). . . . . . . . . . . . . 9 2.2 Public-key cryptography (private and public key). . . . . . . . . . . . 10 2.3 Blockchain as a linked list data structure. . . . . . . . . . . . . . . . . 11 2.4 How digital assets are transferred on the Bitcoin blockchain. . . . . . 13 2.5 How Bitcoin solves the double spending problem. . . . . . . . . . . . 14 2.6 Bank system vs. public blockchain vs. private blockchain. . . . . . . . 15 2.7 Creation and execution of a smart contract in steps. . . . . . . . . . . 16 3.1 Ethereum transaction and gas consumption. . . . . . . . . . . . . . . 24 3.2 Ethereum smart contracts deployment process. . . . . . . . . . . . . . 25 3.3 Transaction processing in Hyperledger Fabric. . . . . . . . . . . . . . 27 4.1 The deployment and the signing of the smart contract. . . . . . . . . 35 4.2 The payment process and the transfer of digital money. . . . . . . . . 35 4.3 The termination of the agreement by the landlord. . . . . . . . . . . . 36 4.4 The smart contract negotiation process initiated by the tenant. . . . . 37 4.5 Simplified CRE business network model in Hyperledger. . . . . . . . . 40 4.6 Interaction between the smart contract and the library. . . . . . . . . 50 4.7 Tenant links a new wallet using the private recovery key. . . . . . . . 51 5.1 Smart contract deployment on Ethereum blokchain. . . . . . . . . . . 55 5.2 Negotiation library deployment on Ethereum blokchain. . . . . . . . . 55 5.3 Deployment of the business network to Hyperledger Fabric. . . . . . . 56 5.4 Creation of two network participants on Hyperledger Fabric. . . . . . 56 5.5 The potential tenant reads the terms and signs the contract. . . . . . 58 5.6 A non-authorized user attempts to sign the smart contract. . . . . . . 58 5.7 Participant identities issued by the administrator. . . . . . . . . . . . 59 5.8 Tenant attempts to access a contract assigned to another tenant. . . . 59 5.9 Terms negotiation between the landlord and potential tenant. . . . . 60 5.10 Terms negotiation transaction in Hyperledger Fabric. . . . . . . . . . 61 5.11 Landlord links a new wallet to the smart contract. . . . . . . . . . . . 62 5.12 Ethereum price in relation to USD and Bitcoin [47]. . . . . . . . . . . 63 xiii List of Figures xiv List of Tables 3.1 Differences between Ethereum and Hyperledger Fabric. . . . . . . . . 30 4.1 Smart contract basic operations for landlord and tenant. . . . . . . . 36 4.2 Smart contract functions used for negotiations of the terms. . . . . . 37 4.3 Access control list for the smart contract basic operations. . . . . . . 38 4.4 Access control list for the terms negotiation functions. . . . . . . . . . 39 5.1 Evaluation criteria for Ethereum and Hyperledger Fabric. . . . . . . . 54 5.2 Evaluation of the RBAC mechanism for the leasing operation. . . . . 57 5.3 Ethereum performance evaluation in terms of gas consumption. . . . 63 xv List of Tables xvi Listings 4.1 Sample transaction processor function to make payments. . . . . . . . 41 4.2 Access Control List (ACL) rule to restrict access to the read terms function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.3 Example modifier used to check a condition prior to executing the function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 xvii Listings xviii 1 Introduction 1.1 Motivation Blockchain technologies have in the recent past become popular, mainly due to the success of Bitcoin [1]. A blockchain is simply a decentralized peer-to-peer network, where each participant maintains a replica of a shared ledger of digitally signed transactions. Blockchains store records in groups called “blocks” and each of them is time-stamped and linked to the previous block using cryptographic functions [2]. It is a fault tolerant network that establishes trust using a distributed consensus algorithm. In addition, the information recorded on the blockchain is append-only using cryptographic means that guarantee the integrity of the recorded informa- tion. This immutability property makes it possible to establish the provenance of information. First conceptualized in 2008 by Satoshi Nakamoto [1], as the technology to fuel the creation of Bitcoin, the blockchain’s use has since evolved beyond crypto- currencies to support Turing complete state machines [3]. For instance, Ethereum [4] and Hyperledger Fabric [5] support self-executing functions that can be stored on the blockchain network, known as smart contracts, and utilized to create de- centralized applications (dApps). Interest from industry has given birth to a new type of blockchain called private (or permissioned) where participants need to be authenticated before joining the network as opposed to earlier blockchains where participants are free to join and leave the network as they please, these blockchains are called public (or permissionless). The provenance, immutability and finality features (See Chapter 2 for more on these features) make the blockchain suitable for several application use cases. Applications such as banking and insurance [12], digi- tal identity and trade finance [13], supply chain business and commercial real estate [14], audit and compliance [15] have since been proposed or are under development. Amid the digitization of information, people all around the world are increas- ingly becoming protective of their personal data. This protective nature of personal data has been exacerbated by recent media reports of data breaches in the form of the Cambridge Analytica [10] that entangled the worlds largest social media site Facebook. Alongside the data privacy revolution, Satoshi Nakamoto [1] defined an electronic cash system as a chain of digital signatures. Bitcoin’s transactions are 1 1. Introduction tracked through the digital signatures that permanently reside in the blockchain. As a result, it is possible to infer the identity of a peer from this chain. While distributed ledgers provide cryptographic encryption to safeguard information, it lacks the flexibility of traditional systems when it comes to granting and removing access to data [16]. Consequently, business networks want to own their information so that they can only grant access to trusted members. However, data privacy and ownership are well-known concerns in the blockchain community. Thus, business houses looking to adopt the blockchain technology are highly interested in address- ing these privacy issues, because their users want to control and own their data, such as transaction history [17]. Public blockchains operates with full transparency, allowing everyone to access the data stored in the distributed ledger, thus it guarantees only a low level of privacy to its users. On the other hand, private blockchains which use a central authority (CA) to verify their users cannot provide any transparency at all. Hence, there is an innate trade-off between transparency and privacy. A blockchain providing public verifiability of its overall state without revealing any information about the state of each participant [18], can guarantee privacy while the process of state transitions is made in a transparent way. In the case of smart contracts [4, 5], the owner of the contract needs to control a small amount of private, sensitive data like transaction history. One way of doing this is to implement a role or attribute-based access control to the smart contract [27, 28, 29]. Consequently, business networks that operate in an environment with competitors can limit the execution of parts of the smart contracts that reveal certain information deemed as either confidential or personal. For example, in a commercial real estate business, a lessee might have an exclusive agreement at a special rate with a lessor. The lessor might want to keep this contract private, and anyone not purview to it should not execute the function in the smart contract that reveals the amount involved. In their current form, smart contracts are not sufficient to replace many of today’s paper-based contracts, due to their lack of flexibility in terms of changing the terms of the contract [26]. Smart contracts operating on the blockchain can provide immutability, but once they are deployed, it is impossible to change any of their terms. As a result, it is immensely costly to run smart contracts in a volatile environment (where terms of an agreement may need to be re-adjusted as new factors creep in). Hence, there is a need for a mechanism that allows parties to propose and agree on new terms. 1.2 Goals and Research Questions The aim of this thesis is twofold. Firstly, we will present a keyhole comparison between Ethereum [4] (public) and Hyperledger Fabric [5] (private), focusing on the architectural similarities and differences in relation to data ownership i.e specific parties have access to specific contents of the smart contract. 2 1. Introduction Secondly, we will design a mechanism for negotiating the terms of a smart contract involving two parties. Based on the previous comparison we will study the feasibility of implementing it in both kinds of blockchain networks. We further exemplify this comparative analysis by designing and implementing a Role-Based Access Control (RBAC) paradigm around a use case application to enhance data ownership. Blockchains track ownership of transactions in a shared ledger based on the source and the destination ID of the transaction [1]. Our main research questions are: • What is the main difference between public and private blockchain regarding the access restriction to the contents of the smart con- tract? Private blockchains provide an access control mechanism to restrict the access of the participants in a smart contract, while public blockchains are built to operate publicly without any restrictions. We will perform a compara- tive analysis of these two types of blockchains by investigating the operational differences (network operation, consensus algorithm, etc.). • Can we design a library to achieve negotiation of smart contract terms and evaluate the library using a use case implementation? In order to design the negotiation library, we will summarize the methodology proposed by Scoca et al in [26]. The summary of this methodology will help answer this question. • Can we implement a role-based access control to smart contract contents based on the source and destination ID of the transaction? In order to implement our role-based access control to smart contract contents, we will model and evaluate a proof of concept (PoC) implementation around roles of the source and destination ID of transactions. In addition, an extensive literature review will be done to compare how transactions and smart contracts are handled in Ethereum and Hyperledger Fabric. The comparison will help answer this question. • If so, what are the implications on the scalability of such an imple- mentation in Ethereum, a public blockchain? This research question seeks to answer the scalability in terms of ether gas exhaustion by transac- tions. We evaluate our implementation to make sure transactions complete their tasks before the gas runs out as well as investigate what happens when peers disappear and re-join the network. Contract negotiation can be a lengthy and tedious process, but with the advent of blockchain technology, this process can be shortened. Our present research is therefore intended to make the following contribution: • Ease the contract negotiation process using smart contracts by designing a li- brary mechanism that can be used to negotiate the terms of the smart contract which involves two parties in a specified use case implementation. 3 1. Introduction 1.3 Limitations Other surveys of blockchain frameworks [3, 20] center around the performance of blockchain technologies, which is a crucial part of the choice of blockchain technology yet does not present the blockchain as a platform that enhances data ownership. Our work is limited to the analysis of the methods for restricting the execution of smart contract contents in terms of data ownership of user information. Furthermore, we concern ourselves with enforcing access control at the programing language level as opposed to applying it at the blockchain or application level. In particular, we concentrate on implementing access control using the underlying smart contracts. We chose to concentrate on the programming language level due to time con- straints. The smart contract implementation languages of both Ethereum and Hy- perledger Fabric are relatively easy to bootstrap. For example, Ethereum has sev- eral different client implementations including C++, Go, Python, Java, and Haskell. These tools provide flexibility with how a node interacts with the Ethereum network. Additionally, the development of smart contracts within the Ethereum network is straightforward, due to its matured ecosystem. The same can be said about the Hy- perledger community that provides an interactive console that developers can build and execute smart contracts in an efficient way. 1.4 Methodology Hevner et al. [46] proposed a conceptual framework as a guideline for evaluating Design Science and Information System research. In order to perform an evaluation process they proposed that an implementation meets the following specific attributes; “functionality, performance, completeness, consistency, accuracy, reliability, usabil- ity”. Given the scope of the thesis and the novelty of the blockchain technology, we decided to evaluate our PoC implementation according to the descriptive evaluation method. This method is divided into two parts: informed argument and scenarios. During the first part of the process, we use information from the knowledge base (e.g. relevant research) to build a convincing argument for the artifact’s utility, while in the second, we construct detailed scenarios around the artifact to demonstrate its utility. In addition to that, we conducted a performance evaluation specifically for the Ethereum implementation, to illustrate the gas consumption of the smart contract deployment and use in real time scenarios. 4 1. Introduction 1.5 Outline To complete this thesis, we organize our work as follows: • Chapter 2: Theoretical Background. We present a thorough technical background to lay the foundation for our work. In addition, we explain in detail our use case and the need for Role-based Access Control (RBAC). • Chapter 3: Comparative Analysis. We shade more light on Ethereum and Hyperledger Fabric as two famous blockchain systems available today. We further present the similarities and differences between these two blockchain systems. • Chapter 4: Implementation. We describe the methodology and the tools we used to implement our Proof of Concept (PoC). Further, we propose a library for smart contract terms negotiation. • Chapter 5: Evaluation. We present the evaluation process of our imple- mentation. • Chapter 6: Conclusion. We conclude the thesis with our final thoughts and suggest areas for further future work. 5 1. Introduction 6 2 Theoretical Background In this chapter, we present the technical background to our work. We provide a summary background regarding modern digital cryptography, in order to ease the description of blockchain afterwards. We also explain the blockchain as a data struc- ture and related concepts such as smart contracts, public and private blockchains. In addition, we give a description of our use case as well as a summary of role-based access control and the work done by others in relation to our thesis. 2.1 Digital Cryptography Modern computer technology has revolutionized the ancient art of encoding mes- sages to render them unreadable to anyone but the intended recipient. Conversely, cryptography has had a profound effect on how we use our information systems today. The process of secure communication between two or more parties in the presence of third parties (adversaries) is called cryptography. Digital cryptogra- phy plays a major role in many applications such as banking transaction cards, computer passwords or e-commerce transactions [30]. At first, cryptography was closely associated with the encryption, but during the past decade cryptography is based on solving comple mathematical problems. Modern cryptography studies the techniques that used to prevent adversaries from accessing private information in various aspects of information security such as data confidentiality, data integrity, authentication and non-repudiation [31]. Digital cryptography is most often associated with the process of converting any type of information (plaintext) into impenetrable text (ciphertext). This process is also known as encryption. The reverse process of converting the ciphertext into plaintext is called decryption. The set of algorithms that creates the encryption and decryption operations is called cipher, and is controlled by an algorithm and a “key” [30]. The key is known only to the parties participating in the communication and it is not revealed in any case to the rest of the parties. The key usually consists of a string of characters (which is secret) and is used to decrypt a ciphertext. Typically, a “cryptosystem” consists of three basic algorithms, one for generating the key, one for the encryption process and one for the decryption process respectively. 7 2. Theoretical Background Traditionally, there are two kinds of cryptosystems used in digital cryptogra- phy: symmetric and asymmetric. In symmetric systems, the parties use the same secret key to encrypt and decrypt the messages. However, in asymmetric systems, the parties use a public key to encrypt the messages and a private key to decrypt them [30]. The asymmetric cryptography scheme enhances the security of commu- nication between the parties, but the data manipulation becomes very slow, since they use keys of larger size, comparing to the ones generated in symmetric cryp- tosystems [31]. DES (Data Encryption Standard) is one of the most commonly used cryptosystems using symmetric cryptography, but it has been replaced by AES (Ad- vanced Encryption Standard). On the other hand, RSA (Rivest-Shamir-Adleman) and ECC (Elliptic Curve Cryptography) are the most typical examples of asymmet- ric cryptosystems which are widely used for secure data transmission [32]. 2.1.1 Cryptographic Hash Functions Hash functions are mathematical algorithms that map data of arbitrary size to data of a fixed size. The output of a hash function is called message digest, and a hash function with identical inputs always produces the same output. Cryptographic hash functions belong to a special class of hash functions that are used in cryptography. Cryptographic hash functions have all of the properties of the hash functions, but they are designed in a such a way that is infeasible to invert (one-way functions). Specifically, it is computationally very hard for an adversary to find two different messages (brute-force attempt) that produce the same message digest (hash of the message). Thus, it is not impossible to break such a system, but it is infeasible to do so by any known practical means or it takes a substantial amount of time for an adversary to break it. MD5 [33], an upgrade of the prior variant called MD4, is one of the most widely used hash functions, but it is proved to be broken in practice. MD5 produces a 128-bit hash value and its only use is as a checksum to verify data integrity because it suffers from extensive vulnerabilities [34]. The United States National Security Agency designed SHA-1 [35] (Secure Hash Algorithm 1), a cryptographic hash function that produces a 160-bit (equivalent to 20-byte) hash value for a given input. SHA-1 established as a U.S. Federal Information Processing Standard many widely used security applications and protocols, such as TLS and SSL, PGP, SSH, S/MIME, and IPsec rely on that. However, since 2005 it has not been considered completely secure and Microsoft [36], Google [37], Apple [38] and Mozilla [39] have all announced that their respective browsers will stop accepting SHA-1 SSL certificates by 2017. Because SHA-1 collision attacks have finally become practical by Stevens et al. [41] which forge two PDF documents with the same SHA-1 hash in roughly 263.1 SHA-1 evaluations, two upgrades to SHA-1 have been proposed over the past decade namely SHA-2 and SHA-3 [40] respectively. 8 2. Theoretical Background 2.1.2 Symmetric-key Cryptography Symmetric-key cryptography covers the encryption methods which use a single pri- vate key for both encryption and decryption. In order to describe how symmetric-key cryptography works, we will give an example of a secret-key cryptosystem as a cryp- tographic solution to the privacy problem arising from the communication between sender and receiver. Formally, a secret-key cryptosystem can be defined as a tuple (M, C,K, E ,D) with the following properties [30, 31]: 1. M is a set called the message space (the elements are called messages). 2. C is a set called the ciphertext space (the elements are called ciphertexts). 3. K is a set called the key space (the elements are called keys). 4. E = {Ek : k ∈ K} is a set of functions Ek : M → C (each of them called encryption function). 5. D = {Dk : k ∈ K} is a set of functions Dk : C → M (each of them called decryption function). 6. For each e ∈ K, there is a d ∈ K such that Dd(Ee(m)) = m, for all m ∈M. Figure 2.1: Symmetric-key cryptography (single secret key). Figure 2.1 illustrates the communication between Alice and Bob over an insecure channel (in the presence of adversaries) using a symmetric-key cryptosystem. Before the initiation of any communication, Alice and Bob have to agree upon an encryption scheme: a message space M, a ciphertext space C, a key space K and two set of functions E and D for encryption and decryption respectively. The two parties have to agree upon a common secret key k ∈ K such that Dk(Ek(m)) = m. In this particular scenario, Bob wants to send a message to Alice. In order to do so, he encrypts his message m ∈M using the encryption function E such that c = Ek(m) and then sends it to Alice. Alice then decrypts the ciphertext c using the decryption function D and reads the message m = Dk(c). 9 2. Theoretical Background Symmetric-key cryptography has an evident problem since both of the parties have to obtain the secret key (shared). The key distribution requires communication over a secure channel, that in most cases is impractical. Whitfield Diffie and Martin Hellman have proposed a solution to the key distribution problem in 1976 [42] in which two different keys (public and private) are used. 2.1.3 Public-key Cryptography In contrast to symmetric-key cryptography, public-key cryptography uses two differ- ent keys, the public key that is freely shared among the parties and the private key of each party that must remain secret (each party knows its own key). In public- key cryptosystems, the public (shared) key is used for encryption, while the private (secret) key is used for decryption. Formally, a public-key encryption (PKE) scheme can be defined as a triple of algorithms (Gen, E ,D) with the following properties [43]: 1. The key generation algorithm Gen(1k) generates a triple of (pk, sk,Mk) where pk is the public-key, sk is the secret key, andMk) is the message space asso- ciated with the pk, sk pair. 2. The encryption algorithm E takes as an input a message m ∈Mk and outputs a ciphertext c = Epk (m). 3. The decryption algorithm D takes as an input a ciphertext c and outputs a message m′ = Dsk (c). 4. For every message m ∈Mk, m′ = m and Dsk (Epk (m)) = m. Figure 2.2: Public-key cryptography (private and public key). Figure 2.2 illustrates the communication between Alice and Bob over an in- secure channel using a public-key encryption scheme. Before the initiation of any communication, Alice and Bob have to agree upon an encryption transformation and each of them generate their keys pkA, skA and pkB, skB respectively, such that 10 2. Theoretical Background Dsk(Epk(m)) = m, for all m ∈ Mk. The public keys are made public to both par- ties while the private keys remain secret. In this particular scenario Bob wants to send a message to Alice, thus he encrypts his message using Alice’s public key pkA and the encryption algorithm E such that c = EpkA (m) and then sends it to Alice. Alice then decrypts the ciphertext c using her private key skA and the decryption function D to read the message m = DskA (c). The first public-key cryptosystem was proposed by Rivest, Shamir, and Adleman in 1978 [44] also known as the RSA algorithm. RSA is widely used for secure data transmission, and it is based on the practical difficulty of the factorization of the product of two large prime numbers (factoring problem). 2.2 Blockchain Technology Blockchain technology is a mechanism that untrusted participants can share infor- mation by using a single digital history log (distributed ledger). A common digital history is important because digital assets and transactions are, in theory, easily faked or duplicated [1]. Blockchain technology solves this problem without using a trusted intermediary. At the heart of the blockchain are blocks linked together to form a chain. Figure 2.3 shows how these multiple blocks are connected to each other to form a chain (the blockchain). Figure 2.3: Blockchain as a linked list data structure. Each block contains its own block header, the hash of the previous block and a collection of time-stamped valid transactions. The hash of the previous block links the blocks together, hence the blockchain can be thought of as a linked list data structure. Furthermore, the hash of the previous block cryptographically prevents the blocks from being altered or a block to be inserted between two existing blocks. As such, each subsequent block strengthens the verification of the previous block and hence the entire blockchain. Furthermore, a transaction can be any transfer of value between network participants (e.g. from one Bitcoin address to another). All of the previous transactions are hashed and paired, creating a single final hash value, called the Merkle root (from the Merkle tree). 11 2. Theoretical Background Today, traditional methods of recording business transactions allow participants to maintain their own ledgers of transactions. This traditional method can be ex- pensive, in some measure because third parties may charge fees for this service (e.g. renting cloud computing infrastructure for databases services). Clearly, this method is inefficient due to the duplication of efforts to maintain a number of ledgers for the same transactions. Furthermore, it may prove as a single point of failure if a central entity (for example a bank) is compromised, due to fraud or a cyber attack. On the other hand, the blockchain introduces efficiency into business networks by eliminat- ing duplication efforts of recording transactions on numerous ledgers. Furthermore, transactions are secure and authenticated. As already noted, the blockchain tech- nology has the following characteristics and advantages over traditional methods of recording transactions: 1. Provenance: network participants are able to determine the origin of the asset and how its ownership has changed over time. This feature provides increased trust and no authority “owns” provenance of assets. In other words, blockchains can be described as systems of proof [5]. 2. Consensus: a mechanism to guarantee that the information added to the distributed ledger is valid (majority of the network nodes are in agreement). This feature prevents the double spending or other invalid data from being appended to the blockchain by ensuring that the next block being added rep- resents the most current transactions on the network. 3. Immutability: participants are not allowed to modify or delete a transaction once it has been committed to the ledger. To correct an erroneous transaction, a new one must be issued and both transactions will be visible on the ledger. This feature helps to lower the cost of audit and compliance. 4. Finality: the single shared ledger becomes the only go-to place to verify the existence of an asset or completion of a transaction as opposed to checking various ledgers for the existence of transactions. The blockchain technology provides business networks an opportunity to conduct their transactions in a secured, shared ledger that reduces the inefficiencies associ- ated with traditional record systems, such as time and costs of maintaining separate ledgers while improving trust among participants and keeping all transactions visi- ble. 2.2.1 Public Blockchain Public blockchain networks are entirely open, and anyone can join and participate in the system. Strictly speaking, blockchain networks can be public in two ways: • Anyone can write data to the blockchain. 12 2. Theoretical Background • Anyone can read data from the blockchain. The network usually has incentives to encourage more participants to join and to discourage network participants from cheating. Mining is the mechanism that en- ables decentralized security on the blockchain [15]. Miners validate new transactions and record them on the global ledger by solving intricate mathematical problems based on a cryptographic hash algorithm. Miners receive a reward whenever they “solve” a block (transactions contained in the block are considered confirmed). Bit- coin [1] is the typical example of a public blockchain network today. The openness and transparency of public blockchain come with a cost, which implies no privacy for the transactions. The main advantage of public blockchains is that they have plenty of use cases due to their “openness”. However, one of the disadvantages of public blockchains is that they require a substantial amount of computational power to maintain a very large distributed ledger. In other words, every node in the network has to solve a resource-intensive cryptographic problem to reach consensus. 2.2.1.1 Bitcoin: A Peer-to-Peer Electronic Cash System Figure 2.4: How digital assets are transferred on the Bitcoin blockchain. As earlier stated, Satoshi Nakamoto introduced Bitcoin as an electronic payment system combining the concepts of cryptography and distributed systems. The main goal of Bitcoin is to allow the transfer of digital assets without the need for a trusted third party such as a bank. The Bitcoin network is a public blockchain that consists of nodes that verify and group transactions by solving cryptographic problems. Bit- coin users digitally sign their transactions using the hash of the previous transaction and the public key of the recipient. In other words, to send Bitcoins, the public key 13 2. Theoretical Background of the recipient must be known beforehand. In a sense, the public key allows users to be pseudonymous. Bitcoin users can come and go on the network and can create as many accounts as they wish. However, they need to accept the proof-of-work chain as evidence of the activities that happened in their absence. The transaction is broadcast across the network and is propagated to all peers in order for the recipient to verify the chain of ownership of the coin. Figure 2.4 illustrates how digital assets can be transferred on the Bitcoin blockchain [1]. Ideally, network participants bundle their transactions into a block, which is later broadcast across the network to all participants. Using a consensus algorithm called Proof of Work (PoW), the transaction is validated and verified by the network peers. Thereafter, the block is appended to the chain and the transaction is completed successfully. Bitcoins are sent from a personal wallet - which is a client application used to generate transactions. To avoid the double-spending problem; a scenario where a payee sends the same coin value to different recipients, the system implements the longest acceptable chain available for that particular coin. The longest chain is a universal confirmation mechanism on the blockchain and is determined by the earlier accepted signatures of a coin. Figure 2.5 shows a Buyer that signs and sends a coin value to Merchant A, in the hope of tricking the system, the Buyer signs and sends the same coin value to Merchant B on a different address. Both transactions end up in the unconfirmed pool of transactions. However, only the first transaction was verified by the miners and added to the next block while the second transaction got fewer confirmations and hence was deemed invalid and pulled from the network rendering the transaction to be declined. Figure 2.5: How Bitcoin solves the double spending problem. The economics of Bitcoin allow the ecosystem to flourish. The generation of the genesis block introduces the first coin into the system. Subsequent block generation incentives allow a constant supply of Bitcoins into circulation that are owned to the block creators. At the time of writing this thesis, there was more than 130 billion USD worth of Bitcoins in existence, but Bitcoins will stop being created when the total number of coins reaches 21 billion in the year 2040 [7]. However, incentives can be realized from transaction fees as well. The difference between the output and 14 2. Theoretical Background input value of a coin is the transaction fee which is added to the block containing the transaction. The block creator is paid this transaction fee as an incentive. 2.2.2 Private Blockchain Conversely, in a private blockchain, network members are known and trusted to participate in the network. Strictly speaking, blockchains can be private in two ways: • write permissions are restricted to authenticated members • read permissions are either restricted or public These permission-based networks restrict the members allowed to participate in the network, and as a consequence, the validation of transactions is delegated to special peers through a consensus algorithm. The participant receives an invitation to gain access to the network and contribute to the maintenance of the blockchain. Classic examples of this blockchain are Hyperledger Fabric [5] and Ripple [6]. Figure 2.6: Bank system vs. public blockchain vs. private blockchain. Figure 2.6 illustrates the key difference between the current bank system and the public and private blockchain. Generally speaking, private blockchains are usu- ally administered by an organization or a trusted consortium that controls access permissions to the blockchain such as rights to read and modify the blockchain state. For the most part, these blockchains have received a lot of attention from financial institutions as they move to adopt the blockchain technology. This attention is at- tributed to the significant advantages private blockchains posses in comparison to their public counterparts. These advantages include the following: • The organization whose jurisdiction the blockchain falls under can manage the rules of participation if the need arises. Furthermore, if read access is restricted, private blockchains can offer increased levels of privacy to the blockchain contents. • As opposed to public blockchains, where transaction validation is done by a 15 2. Theoretical Background number of nodes, in private blockchains transaction validators, are known, hence transactions are cheaper and block creation time is minimized. This advantage also prevents validators from colluding among themselves. 2.2.3 Smart Contracts Nick Szabo [11] first defined a smart contract in 1994 as a “set of promises specified in digital form, including protocols that the parties perform to honor the promises”. Figure 2.7 shows how smart contracts are created and executed on the blockchain. Szabo defined four design objectives for contracts which include: Figure 2.7: Creation and execution of a smart contract in steps. • Observability: the means for participating parties to observe each others’ performance in regard to the contract or to prove their performance to each other. Ideally, the accounts department would see to it that the contracts an organization is involved with becoming more observable. • Verifiability: this is the ability for a party to prove to a body officially appointed to settle a dispute that the contract was honored or otherwise a dispute occurred. • Privity: this is the ability to distribute the knowledge or contents of the contract to parties that are only purview to it. In common law, third parties other than designated arbitrators or intermediaries should not have access to a contract. • Enforceability: these are means of enforcing the contract. One way is to institute self-enforcing schemes where the contract is executed upon a pre-set condition. It can be noticed that the design objectives form two sets of observations; priv- ity exerts restrictions over the contract contents, minimizing the exposure of the contract to third parties. On the other hand, observability, verifiability, and en- forceability entail access to contractual information by third parties. Consequently, a trade-off must be met where controlled access to the contract is met while it is 16 2. Theoretical Background possible to verify, enforce and observe the contract by third parties. These design properties enable both parties to observe the performance of the other party and verify if and when a contract has been performed, guarantee that only the details necessary for completion of the contract are revealed to both parties and be self- enforcing to eliminate the time spent observing the contract. In the context of the blockchain, a smart contract is an agreement that governs business rules and provides business logic. It is executed automatically as part of the transaction and is stored on the blockchain. The state of the blockchain is changed by execution of the smart contract. Often, smart contracts allow the exchange of money, property, shares, or any asset in a transparent and conflict-free way. In most blockchain implementations, smart contracts have their own address or in some cases contain crypto-balance (e.g. Ethereum) and can be set up in three phases: • Smart contract construction with agreed upon terms using a supported pro- gramming language. • Deployment of the smart contract to the peers of the blockchain. • Self-execution upon the occurrence of the pre-set condition. If however, the condition is external to the blockchain, a third party entity is needed to enter the information required for the smart contract to run. The execution of the smart contract through the blockchain renders it reli- able. The reliability is guaranteed using the consensus algorithm of the underlying blockchain. The blockchain network is able to verify whether the smart contract has been executed properly and resolve any dispute that may arise. 2.3 Use Case: Commercial Real Estate Commercial Real Estate (CRE) denotes any property owned solely for the purpose of generating an income. CRE traditionally keeps several of its operations secret, such as comparable lease rentals, property prices, and valuations to create a competitive advantage. However, the inherent advantages of blockchains such as a distributed ledger, tamper-proof, censorship resistance, and smart contracts have the potential to transform CRE operations such as property purchase, financing, leasing, and management. To be specific, leasing, purchase, and sale transaction processes can benefit from blockchain adoption as it can take advantage of the benefits of the technology. The following illustrates how blockchain can promote CRE leasing, purchase and sales operations: 1. Property Searching: The lessor and the lessee or their respective brokers list their requirements on a listing service. A transparent listing service system enables all parties to view the available listings based on their requirements. The property searching can be powered by a blockchain enabled listing service. 17 2. Theoretical Background 2. Pre-lease Due Diligence: The lessor conducts a background check on the lessee, and the lessee checks the prior transactions and legal claims on the property. 3. Lease Agreement: The key terms of the agreement are recorded on the blockchain and executed using a smart contract. The smart contract initi- ates payment of security deposit/advance rent either through cryptocurrency wallets or bank accounts using a payment interface. 4. Automated payments and cash flow management: Based on the terms of the agreement, the smart contract initiates the regular lease payments from the lessee to the lessor, after paying the outstanding maintenance expenses to the contractors. The smart contract initiates the transfer of the security deposit to the lessor using the preferred mode of payment on completion of the lease term. This use case provides us with an opportunity to note that data ownership is paramount in situations that comprise competitors. Once an agreement has been reached, participants should have the possibility to retain access control to their information. We will make use of the CRE operations to conclude our comparative study. 2.4 Role-Based Access Control Role-Based Access Control (RBAC) is a common approach to manage users’ access to resources or operations. RBAC enables the creation of hierarchies of roles and permissions [27, 28]. Permissions specify exactly which resources and actions can be accessed by whom. In our implementation, they can be realized in two ways [22]: 1. Using the inbuilt blockchain crypto-conditions, 2. Enforcing the access control through a third party-system like a cloud platform and build an asset transfer application on the blockchain. In the first option, we can use property owners as partial owners of the property; primarily we can retain the ownership to the underlying blockchain in the data model and assign roles as lessee and lessor. As a result, a crypto-condition such as a threshold condition (1 of n) can be used to transfer assets. Basically, in a threshold condition, the application is modeled around assets, inputs, and outputs as a mechanism by which control of an asset is transferred. The amounts of an asset are encoded in the outputs of a transaction, and each output may be spent separately. To spend an output, the output’s condition must be met by an input that provides a corresponding fulfillment. The second option is somewhat easier; we can model the applications access rights and allow a third party application to host them. However, there remain some challenges with these methods, which have been 18 2. Theoretical Background addressed in previous research [22]. The first option does not scale easily because whenever partial players in the leasing business are added or removed, a new transfer trail of assets is created. The second option drifts away from the decentralized nature of the blockchain and creates a single point of failure in the third party application to host the access rights. 2.5 Related Work This section discusses a number of implementations related to our thesis. It also describes how our thesis work differs from the proposed systems in the related work. Public key infrastructures (PKI) facilitate the secure electronic transfer of in- formation across various network applications (e.g. e-commerce, internet banking, confidential email). Well-known PKI-based systems, such as the most widely used email encryption standard, OpenPGP [23], and its implementation GnuPG [24], are complex systems with a very high cost of maintenance. Additionally, those systems rely on a Certificate Authority (CA), a trusted third party, which is responsible for the distribution and management of the digital certificates. The CA centralization creates a single point of failure, making both systems target for multiple attacks. A typical example is the DigiNotar [25] attack, where an attacker penetrated the Dutch CA DigiNotar and gained complete access to all eight of the company’s certificate- issuing servers. In our implementation, we aim to investigate how to restrict access to smart contracts in a new efficient and decentralized way without the use of an additional central entity responsible for that. Scoca et al. [26] presented a methodology for the autonomous negotiation of smart contracts in cloud services, by introducing a formal language to describe the interactions between offers and requests. They also analyzed the cost and the modifications required to reach consensus, by providing a full evaluation process. In our thesis work, we propose an implementation that allows dynamic inclusion of new terms within a smart contract. Flexible smart contracts that allow alteration in their contents by preserving privacy at the same time can be very useful in business- to-business networks. Particularly, we propose a library that can be used by any smart contract in order to handle negotiations between the involved parties in our use case scenario (landlord and tenant). Ouaddah et al. [27] proposed a novel framework for access control in IoT- based on the blockchain technology. They proposed FairAccess, a fully decentralized pseudonymous and privacy-preserving authorization management framework that enables users to own and control their data. They also provide a reference model for the proposed framework within the objectives, models, architecture and mechanism specification in IoT. Likewise, Zhang et al. [28] proposed a smart contract-based framework, which consists of multiple access control contracts (ACCs), one judge contract (JC) and one register contract (RC), to achieve distributed and trustworthy access control for IoT systems. Each ACC provides one access control method for 19 2. Theoretical Background a subject-object pair and implements both static access right validation based on predefined policies and dynamic access right validation by checking the behavior of the subject. In addition, the JC implements a misbehavior-judging method to facilitate the dynamic validation of the ACCs by receiving misbehavior reports from the ACCs, judging the misbehavior and returning the corresponding penalty. Both implementations focus on IoT security allowing their users to control their own data, while our implementation describes the design and implementation of a role-based mechanism in smart contracts for the purpose of real estate leasing operations. Cruz et al. [29] proposed a blockchain-based RBAC system using the Bitcoin network as an infrastructure, aiming to provide an irrefutable proof of the role of a user (issued by an organization) by verifying the connection of the user to the or- ganization through the Bitcoin blockchain. Specifically, whenever an unknown user claims to have a role from a particular organization, the system will create a Bitcoin transaction, then a service-providing organization will verify the Bitcoin transaction containing the addresses of the organization and the user. This implementation is inspired by the mechanism of Hyperledger Fabric, used for issuing and verifying user transactions from the rest of the users. Our thesis work aims to investigate how an RBAC scheme can be implemented in Ethereum blockchain, in order to create smart contracts that have the ability to restrict access to certain users. Hypeledger Fabric has a built-in mechanism to support access control in smart contracts, due to its permissioned type of operation. 20 3 Comparative Analysis Since the inception of Bitcoin, there has been a surge in the development of industry grade blockchains. Although Ethereum and Hyperledger Fabric are some of the matured blockchain ecosystems on the market, their implementation styles differ significantly. In this chapter, we shade more light on the architecture of Ethereum and Hyperledger Fabric. Furthermore, we present a keyhole comparison between Ethereum and Hyperledger Fabric by analyzing their key similarities and differences. 3.1 Ethereum Ethereum [4] was proposed towards the end of 2013 by Vitalik Buterin and offi- cially launched in July of 2015. At the time of writing, Ethereum had a market capitalization of 60 billion USD, not counting its attraction as a platform of choice for a lot of decentralized applications as well as for the creation and launch of ICOs (Initial Coin Offerings). Ethereum is an open source platform, operating on a public blockchain network, providing easy, fast and reliable payments similarly to Bitcoin. But in addition to that, it enables developers to build and deploy decentralized applications, called smart contracts. Ethereum smart contracts define rules and penalties for an agreement between members by enforcing those obligations [4]. Therefore, smart contracts are stored in the Ethereum blockchain as decentralized applications (dApps) and can used by the Ethereum users in the future. Ethereum allows developers to create smart contracts consisting of an unlimited number of operations, without restricting them in a set of limited operations [29]. 3.1.1 Ethereum Virtual Machine The Ethereum Virtual Machine (EVM) can be viewed as a distributed global com- puter where all smart contracts are executed [4]. In order to restrict the resources used by the smart contracts running in the EVM, every computation is paid in ether (ETH), the built-in currency of the Ethereum blockchain. Thus, smart contract op- 21 3. Comparative Analysis erations that is executed in the EVM, are broadcast to every node in the network. It is evident that the Ethereum project was built with the prospect of introducing such a sandboxed environment to simplify the smart contract development in the future. The EVM can be considered to be a “learning environment”, which gives developers a testing platform in order to ease the development process of applications on the blockchain. The EVM is a good testing bed because it is completely isolated from the rest of the main network. Additionally, the EVM has been implemented in C++, Python, Ruby, and a few other programming languages, while every Ethereum node in the network runs their own EVM implementation and is capable of executing the same instructions. 3.1.2 Ether and Gas The native value token of Ethereum blockchain is called ether [4] and it is the main element for operating the distributed applications in Ethereum platform. Essen- tially, ether is the fuel of the Ethereum network, a form of payment made by the clients of the platform to the machines executing the requested operations. Thus, developers are motivated to write quality code to keep the network healthy, since the deployment of wasteful code leads to additional cost. Whenever a contract is executed as a result of being triggered by a message or transaction, every instruc- tion is executed on every node of the network. Every operation executed on the blockchain comes with a cost, measured in gas units. Gas price is the amount of ether the sender is willing to spend on every unit of gas, and is measured in gwei. ‘Wei’ is the smallest unit of ether, where 118 wei represents 1 ether. One gwei is 1,000,000,000 wei. With every transaction, a sender sets a gas limit and gas price. The product of gas price and gas limit represents the maximum amount of wei (or ‘TX fee’) that the sender is willing to pay for executing a transaction. Sending tokens will typically cost about 50000 gwei to 100000 gwei, so the total TX fee is about 0.001 to 0.002 of ether. This restriction provides an efficient way to reach consensus on the system without the need of trusted third parties, or intermediates. Each smart contract execution is redundantly replicated across many nodes making the execution expensive. Therefore, Ethereum platform encourages only the execution of the necessary operations on the blockchain and all of the unnecessary operations can be executed offline (without using the blockchain itself). The miners can purchase gas for ether after they have executed the code of a smart contract. Due to the price fluctuation of ether as a result of the open market, the price of gas varies accordingly. Basically, the price of gas is decided by the miners, who can refuse to process a transaction with a lower gas price than their minimum limit. There is an automated process that purchases gas for ether in each Ethereum client according to the limit specified for the transaction. Moreover, Ethereum’s execution fees apply for every computational step within a smart contract, preventing intentional attacks or abuse on the Ethereum network. 22 3. Comparative Analysis 3.1.3 Accounts, Transactions and Messages 3.1.3.1 Accounts Transactions in Ethereum smart contracts can simply be considered as a transfer of ether from one Ethereum account to another. Generally, there are two types of accounts: Contract Accounts (CA) and Externally Owned Accounts (EOA). Con- tract accounts have an ether balance, an associated code and their code execution is triggered by transactions or messages (function call) received from other contracts. On the other hand, Externally Owned Accounts (EOAs) have an ether balance and they can send transactions by either simply transferring ether or trigger the code of a contract. An EOA is completely controlled by a private key and has no associated code. 3.1.3.2 Transactions Transactions in Ethereum formally refer to the signed data package that stores a message that has to be sent from an Externally Owned Account (EOA) to another account on the blockchain. The transaction contains the Ethereum address of the recipient, a signature that identifies the sender, the amount of ether being transferred (VALUE), two extra values STARTGAS and GASPRICE, and an optional data field. The signature is used to identify the sender and verify their intention to send the message to the recipient using the Ethereum network. The VALUE field stores the amount of wei to transfer from the sender to the recipient, the STARTGAS field which represents the maximum number of computational steps the transaction execution is allowed to take, and the GASPRICE field represents the fee the sender is willing to pay for gas; one unit of gas corresponds to the execution of one atomic instruction (computational step). 3.1.3.3 Messages Ethereum smart contracts can also send “messages” to other smart contracts. These messages are virtual objects that exist only in the Ethereum execution environment and can be used as function calls. Similarly, each message contains the identity of the sender and the recipient, the amount of ether being transferred (VALUE), an extra value STARTGAS and an optional data field. STARTGAS value restricts the amount of gas that can be consumed by the code execution triggering. Ethereum messages act like transactions and can only be produced by contracts, not from external accounts. 23 3. Comparative Analysis 3.1.4 Consensus Algorithm (Mining) Figure 3.1 illustrates the execution of an Ethereum transaction showing the gas consumption of every instruction in the transaction. Ethereum, like all blockchain technologies, uses a consensus algorithm which is based on choosing the block with the highest total difficulty [4]. In Ethereum, the difficulty is an integer that indicates how difficult it is for the miners to mine a new block by finding a hash below a given target, while total difficulty holds for the difficulty of the whole chain until this block. During this process, miners produce blocks which then other miners have to check for their validity. In particular, Ethereum uses a Proof-of-Work (PoW) system where all miners use a special software to solve mathematical problems. Figure 3.1: Ethereum transaction and gas consumption. Generally, Ethereum blockchain is very similar to the Bitcoin blockchain, al- though Ethereum proposes a more enhanced consensus mechanism. The blocks of both blockchain implementations contain a copy of the transaction list and the most recent state, which is technically the root hash of the Merkle tree. In addition to that, each Ethereum block contains the number of the block and its difficulty. These two additional values give an extra level of security and the validation of the blocks becomes even harder. The PoW algorithm used in Ethereum platform is called Ethash, which is a modified version of the Dagger-Hashimoto algorithm [4]. This algorithm suggests that miners have to scan and test for a nonce to find a solution that is below a certain difficulty threshold. Specifically, the protocol indicates that the difficulty can be adjusted dynamically in such a way that on average one block is produced by the entire network every 15 seconds. Thus, any node participating in the Ethereum network can become a miner and their expected total reward from mining will be directly proportional to their mining power, or hashrate. Moreover, Ethash is a memory intensive computational problem, making it application-specific integrated circuit (ASIC) resistant, thus, it allows a more equally distributed (decentralized) notion of security. In order to modify a block, someone has to redo the work spent on this block, including the work spent on the blocks that have been chained to it. Thus, the majority of the total computation power of the miners participating in the Ethereum network are controlled only by honest miners, enhancing the levels of security throughout the blockchain. 24 3. Comparative Analysis 3.1.5 Smart Contracts Deployment Ethereum offers a very large distribution of software tools for smart contract devel- opment. Figure 3.2 illustrates the steps of deploying a smart contract in Ethereum platform. Developers interested in the development of Ethereum smart contracts use the following steps to successively construct and deploy a smart contract to the blockchain system: 1. Write the source code of the smart contract in a file (or a group of files) with the extension *.sol, using the programming language Solidity. 2. Compile the file (or files) containing the source code of the smart contract using the Solidity compiler (solc). Developers can call the Solidity compiler, which runs inside the Ethereum node that they have already started, using the JavaScript API called web3.js. The correctness of the smart contracts can be verified in a private Ethereum network using a local testnet, without consuming any gas. Figure 3.2: Ethereum smart contracts deployment process. 25 3. Comparative Analysis 3. The binary file generated from the source file (or files) written in Solidity, is sent back to the dApp in the front-end JavaScript environment. In the Ethereum community, dApps provide a practical UI to interact with the smart contracts. 4. The dApp publishes the smart contract (the binary file of the smart contract) to the main network, using the web3.js JavaScript API. 5. The smart contract is signed using the Ethereum node default wallet address (or another Ethereum address). The step of deploying the smart contract to the network costs ether. 6. The Ethereum node sends back the blockchain address of the smart contract and the ABI (a JSON file containing all the variables, events and methods of the compiled smart contract). 7. Whenever the dApp calls a method of the published smart contract, it uses the blockchain address and ABI of the smart contract, along with the nonce value. Nonces start with a value equal to zero when the smart contract is published on the blockchain and they are used to prevent pushing duplicated transactions, while at the same time they increase the lifetime of the key. 3.2 Hyperledger Fabric Hyperledger Fabric is a project housed under the Linux Foundation to provide in- dustry grade private blockchain technology that renders immediate finality. At the time of writing this thesis, v1.1.0 was the current version in production. Hyper- ledger Fabric’s smart contracts are called chaincode and written in either Java or Go programming languages and deployed to peers. Hyperledger Fabric is divided into two sets of peers: validating and non-validating peers. A validating peer is one that participates in the maintenance of the ledger, runs the consensus algorithm and validates transactions. On the contrary, non-validating peers only issue transactions to validating peers on behalf of clients. The validating peers execute transactions in the form of three transaction types to interact with the blockchain: • Deploy transaction: This transaction installs the smart contracts to the peers. • Invoke transaction: A particular chaincode that has been installed using the deploy transaction can be invoked with arguments specific to the type of trans- action. The chaincode either writes or reads entries in its state and indicates whether it has failed or succeeded. • Query transaction: This transaction reads and returns the state of the peers’ permanent storage. 26 3. Comparative Analysis 3.2.1 Transaction Processing Unlike other blockchain technologies, Hyperledger Fabric takes a different approach to executing transactions. The system is designed to separate the execution of the smart contract and updating the distributed ledger [8]. A transaction between two clients with corresponding peers on the blockchain network makes use of the three transaction types listed above. Figure 3.3 shows the flow of the transaction to complete the asset exchange between two clients. The flow typically follows the steps listed below: Figure 3.3: Transaction processing in Hyperledger Fabric. 1. Client transaction initialization: The client intending to partake in the trans- action (e.g rent a house from a landlord) sends a request. This transaction request targets the corresponding peers on the blockchain network. Depending on the endorsement policy (See Section 3.2.1.1 for more) of that network, the transaction is directed to the right peers to sign the request. The transac- tion request is bundled into a transaction proposal by the Standard Develop- ment Kit (SDK) responsible for the smart contract. The transaction proposal marks the request to execute a smart contract function that reads/writes data to/from the ledger. 2. Transaction endorsement: This process takes care of the housekeeping duties before a transaction is committed to the ledger. In particular, the endorsing peers verify that the transaction is correctly issued and that it has not been submitted before. Furthermore, the endorsing peers make sure that the sig- nature from step 1 is valid and that the peer submitting the transaction has the necessary rights to do so. If the request passes all these checks, the smart contract is executed to generate a response that is sent back to the applica- tion. This response often contains the read and write sets. At this point, the transaction is not yet committed to the ledger unless a write transaction is executed. 3. Inspection of proposal responses and assembly of endorsements: The response 27 3. Comparative Analysis from the endorsing peers is inspected by the respective client application. If the transaction involved querying the ledger, the application displays the in- formation. However, if the transaction involved writing, the client application inspects the endorsement policy before sending it to the ordering service to update the ledger. The client application then broadcasts the transaction pro- posal and response to the ordering service by including it in a transaction message. The ordering service then creates a block of transaction per channel. 4. Transaction validation: The blocks of transactions are then delivered to all the peers. As noted before, the transactions in the blocks are considered to be validated. 5. Ledger Update: Each peer applies the write sets of the transactions in the block thereby updating the ledger of each channel. 3.2.1.1 Endorsement Policies An endorsement policy in Hyperledger Fabric refers to the peers that must agree on the results of a transaction before it can be added to the ledger. Hyperledger Fabric uses a small-domain language called CLI to define endorsement policies. Examples of endorsement policies include: • All of the peers of each organization must endorse the transaction of type T , thus the endorsement policy T = (peer I ) ∧ (peer II ) ∧ ... (peer N ). • One or more peers of each organization can endorse the transaction of type Y , thus the endorsement policy Y = (peer I ) ∨ (peer II ) ∨ ... (peer N ). Endorsement policies are validation checks enshrined in the architecture of how the blockchain system handles transactions. The main advantage of this approach is that it allows developers to increase the privacy of data access stored on the blockchain. 3.2.1.2 Consensus Algorithm Hyperledger Fabric employs a “pluggable” consensus algorithm; which means that the target use case application determines the algorithm to be used [8]. However, due to the inherent problems of distributed message passing such as nodes crashing and node collusion, validating peers in v1.0 run a hybrid of the Practical Byzantine Fault Tolerance (PBFT) as the consensus algorithm to verify transactions [5]. Ideally, transactions are validated through the replicated execution of the smart contracts and the underlying assumption of Byzantine faults. It is assumed that among n peers, f < n/3 are faulty and may act arbitrarily to give false values but the rest execute the smart contract correctly [5]. The main advantage PBFT has over other distributed consensus algorithms such as PoW is that they have minimal latency and 28 3. Comparative Analysis can process numerous transactions per second, however, they do not scale easily in terms of nodes [8]. As any other blockchain system, the notion of consensus in Hyperledger Fabric refers to the agreement of the order of verified transactions written to the block. But most importantly, consensus also implies that a transaction has met all the checks that are imposed on it as the transaction completes the life cycle. As already stated, these checks include the check against endorsement policies set in the blockchain system and the check to prevent the double spending problem that might pose a threat to data integrity. 3.2.2 Membership Services and Identity Management Hyperledger Fabric uses identities to manage network participants in the blockchain ecosystem, because of its private mode of operation. Ideally, these network par- ticipants include peers, client applications, and transaction orderers. Hyperledger Fabric supports a Membership Service Provider (MSP) that contains the security infrastructure for authentication and authorization of network participants. Strictly speaking, identity management is achieved through the use of digital certificates. In particular, enrollment and transaction authorization is performed using Public Key Infrastructure (PKI) while confidentiality for smart contracts is achieved through homomorphic encryption. When connecting to the network, a peer obtains an enrollment certificate from the enrollment certificate authority. This cer- tificate is used to authenticate the peer by the MSP. Upon authentication, a peer obtains a transaction certificate to enable it to issue transactions. The transaction certificate can be issued several times to the same peer allowing it to be pseudony- mous. In addition, channels use symmetric encryption to provide confidentiality of the smart contracts and blockchain state. 3.3 Comparison This section describes the key similarities and differences between the public block- chain implementation of Ethereum and the permissioned distributed ledger of Hy- perledger project, called Fabric. 3.3.1 Similarities Both Ethereum and Hyperledger Fabric share the same advantages that all of the blockchain solutions provide. Recording transactions through blockchain virtually eliminate errors caused by humans while at the same time protects the data from 29 3. Comparative Analysis prospective tampering. However, the fundamental value of a blockchain is that it enables a database to be directly shared without a central administrator. Both platforms use a consensus mechanism to ensure the nodes participating in each net- work stay synchronized. Therefore, neither Ethereum nor Hyperledger Fabric uses a central entity to verify the transaction taking place on their platforms. In addi- tion, both systems support the full development and deployment of smart contracts. Thus, there is no need for third-party mediators or intermediaries for both platforms. Besides the time reduction in transactions, they both offer a reliable fault-tolerant network which is able to withstand malicious attacks, due to their decentralized nature. 3.3.2 Differences The operational differences between Ethereum and Hyperledger Fabric stem from the target uses of the two flavors of blockchain systems [9]. Hyperledger Fabric was typically developed to be a modular blockchain that extends various use case applications. On the other hand, Ethereum seeks to provide a generic platform for all sorts of applications and modularity is not a key objective. Table 3.1 presents a summary of the key differences between Ethereum and Hyperledger Fabric. Characteristics Ethereum Hyperledger Fabric Description Generic blockchain Modular Distributed platform Ledger Technology (DLT) Network operation Public (permissionless) Private (permissioned) Type of transactions Transparent Confidential Consensus algorithm Mining based on PoW Various Algorithms (Proof-of-Work) (Depending on target application) Smart contracts Solidity (C++, Go, Python) Chaincode (Go, Java) System currency Ether None Mining reward Yes None Table 3.1: Differences between Ethereum and Hyperledger Fabric. 3.3.2.1 Network operation This is perhaps the most notable difference as it dictates the target use cases of the two blockchain systems. As already noted in Chapters 1 and 2, Hyperledger Fabric is a private or permissioned blockchain while Ethereum is a public or permissionless blockchain. This difference borders on how network participants are treated in the respective blockchain systems. Consequently, this difference plays a major role in how consensus is reached in these two blockchain implementations [9]. 30 3. Comparative Analysis 3.3.2.2 Consensus algorithm In Ethereum, mining based on proof-of-work is used by all the peers to agree on the order in which transactions appear in the blockchain. As already noted, the main idea behind PoW as a distributed consensus algorithm is to limit the rate at which blocks are created by solving cryptographic puzzles. PoW suits the public nature of Ethereum due to the fact that any peer can participate in the mining process. If an adversary controls less than half of the total computing power present in the network, PoW prevents the adversary from creating new blocks faster than honest participants, thus inherently addressing the Sybil attack that is famous in anonymous networks [8]. However, PoW suffers from the performance of transaction processing when compared to other distributed consensus algorithms such as Byzan- tine Fault Tolerance (BFT) algorithms. This performance degradation arises from the need for all network participants to agree upon a common ledger and because the computational effort of PoW is both time and energy consuming [9]. In addi- tion, ledger records are accessible by all network participants in Ethereum, which is problematic for use case applications that have strong privacy requirements. In contrast, Hyperledger Fabric follows a novel approach to agree on the order in which transactions must appear on the blockchain. Typically, Hyperledger Fabric uses execute-order-validate scheme, which allows transactions to execute before the blockchain can reach an agreement on the order of the transactions. As already noted, Hyperledger Fabric uses a “pluggable” consensus algorithm but the most common is the hybrid Practial Byzantine Fault Tolerance (PBFT) algorithm. As opposed to Ethereum, nodes in the Hyperledger Fabric system assume different roles such as orderers and endorsement peers to help reach consensus. By separating the roles of nodes in this manner, Hyperledger Fabric is flexible enough to add an extra layer of permission by leveraging the blockchains identity management system thereby increasing the privacy of recorded data. 3.3.2.3 Smart contracts Another key difference between Ethereum and Hyperledger Fabric is the use of smart contracts [4]. Ethereum smart contracts are written in a high-level contract- oriented language called Solidity. Smart contracts written in Solidity are compiled to bytecode that is executable on the EVM. Solidity allows developers to write dis- tributed applications (dApps) that implement self-enforcing business logic inside smart contracts. Moreover, Solidity is statically typed, supports inheritance, li- braries and complex user-defined types among other features. Ethereum supports also a Python-like language called Serpent, and a Lisp-like Language called LLL respectively. Conversely, Hyperledger Fabric introduces another type of smart contracts, called “chaincode”, which typically handles business logic agreed upon by members of the network, so it may be considered as a smart contract [5]. Every peer in the 31 3. Comparative Analysis Hyperledger Fabric network executes the chaincode, access the data stored in the distributed ledger and endorses new transactions. Hyperledger Fabric also offers an SDK for Node.js, Java and Go, mainly aiming in large integration projects. Chaincodes are written in Go, Javascript and Java and it is considered to be more flexible than a closed smart contract programming language, such as Solidity. 3.3.2.4 System currency Section 3.1.2 describes how Ethereum uses ether as the built-in crypto-currency. It is used to pay nodes that take part in the consensus process as well as pay transaction fees whenever a smart contract is executed. Consequently, distributed applications that require monetary transactions can be built by taking advantage of this crypto-currency. On the other hand, Hyperledger Fabric does not require a built-in cryptocurrency as consensus is not achieved using the mining process. However, because chaincode is Turing complete, it is possible to create a native crypto-currency to operate in the Hyperledger Fabric ecosystem [9]. 3.3.3 Conclusion Ethereum and Hyperledger Fabric seek to solve the same problem i.e to provide a truly distributed way of recording transactions that enables trust in a trustless environment without the need for an intermediary. However, the two blockchain systems sit at different ends of the spectrum. Ethereum’s public mode of operation allows it to be a strong candidate for transparent transactions but it sacrifices per- formance, scalability, and privacy. It is impossible to track or restrict the access to the blockchain, since the participants in public blockchains (such as Ethereum) are anonymous and they can join and leave the network whenever they want. Ethereum smart contracts make Ethereum blockchain extremely competent to the the business- to-consumer (B2C) market. On the other hand, Hyperledger Fabric uses its private mode of operation and modular architecture to solve privacy issues in the network system. Hence, it can provide solutions to sectors that require knowledge of who the members of the network are and who is accessing specific data. Furthermore, this modular architecture allows Hyperledger Fabric to have pluggable components such as the consensus algorithm to suit the requirements of the target application. Specifically, the commonly used BFT algorithm scales better than other consensus algorithms used in public blockchain and it allows the developer to increase the privacy of the application. 32 4 Implementation In this chapter, we describe a Proof of Concept (PoC) implementation, consisting of a smart contract and distributed application (dApp), that allows a landlord and a tenant to make an agreement on a residential property. First, we define the basic rules and operations of the smart contract, according to the paper leasing contract. Thereafter, we describe the implementation of the smart contract and the dApp that handles the smart contract operations, using two different blockchain infrastructures, Ethereum and Hyperledger Fabric respectively. 4.1 Design and Specification A paper contract is a legally binding arrangement between two or more parties that is enforceable by law as a binding legal agreement. Every contract must contain a detailed description (the terms of the contract) which specifies the obligations that parties have to each other. In order for the parties to agree on the terms of the contract, they have to sign it by giving their consent. Moreover, apart from the basic properties, a contract can have clauses, which can be either specific provisions or distinct articles within a contract. The role of contract clauses is to address a specific aspect related to the overall subject matter of the agreement. Contract clauses simply define the duties, rights, and privileges that each party has under the contract terms. Any contract concerning the law must go through several middlemen and third parties, thus paper contracts can take significant time and cost to become legally enforceable. In order to implement a smart contract that corresponds to a paper contract, the terms of the contracts should be defined. The smart contract holds all the necessary information of the residential lease agreement and supports multiple operations that can be used by the two parties: landlord and tenant. In this PoC implementation, we assume that the person that deploys the smart contract becomes the landlord of the contract. However, we provide more fine-grained implementation details in Sections 4.2 and 4.3 respectively. Once the contract is deployed on the blockchain, its state is set to “Created”. In addition, the terms of the contract are clearly specified and proposed by the property owner. 33 4. Implementation 4.1.1 System Description The PoC implementation defines a contract between a landlord and a tenant. The contract stipulates that upon agreement, a tenant will have to pay an agreed amount on a monthly basis to the landlord as rent. Payments that are remunerated later than the agreed date attract a penalty fee as a percentage of the rent amount. Our PoC implementation has two participants in the CRE business network, Tenant and Landlord, while Houses are the assets of this business network. Land- lords own the houses that tenants seek to rent. We assume that tenants have searched for a house and the contract agreement marks the first entry transaction in the process flow. In addition, tenants and landlords are assumed to be authenti- cated as real players in the business network in the case of Hyperledger Fabric. The following are the functional requirements of the PoC implementation: 1. The landlord should create a contract that a tenant should review until an agreement is reached. 2. A tenant should be able to read the terms of the contract. Once agreed upon, only the parties purview to this agreement must retain access to the information generated as a result of the contract execution. 3. The tenant must remunerate the agreed rent amount. This transaction is modeled as a transfer of ether in Ethereum or transfer of an assumed account balance in Hyperledger Fabric. 4. The contract penalty should be adhered to once a late payment is received. The penalty fee is 5% of the principal rent amount unless otherwise negotiated. Furthermore, an event must be created notifying the landlord when a payment is missed by the tenant. Ethereum applies also extra fees (gas) for the smart contract execution, regardless of the extra fee for the penalty. 5. The tenant should be able to open negotiations on the terms of the contract during the validity of the contract and any new changes agreed to must be enforced on the blockchain. 6. Tenants must not be purview to contracts that do not concern them. These requirements also encompass the terms of the contract. However, blockchain target requirements and assumptions will be exemplified in Section 4.2 and Sec- tion 4.3 respectively. 34 4. Implementation 4.1.2 Design of the Smart Contract Figure 4.1 illustrates the deployment of a smart contract by the landlord and the signing of the contract by the tenant. The smart contract can be in one of the four different states: Created, Initiated, Terminated, or underReview. After the creation of the smart contract, the state is initialized to the Created state and the tenant is able to read the contract terms. Figure 4.1: The deployment and the signing of the smart contract. However, the tenant can propose new terms as a way of negotiating. The negotiating process moves the contract into the underReview state. This state puts the contract on hold until an agreement is reached between the negotiating parties. Similarly, after the agreement, the contract changes to the Initiated state and the lease operation is initiated. Consequently, the smart contract is now active and the parties involved are expected to follow the terms of the contract. Figure 4.2: The payment process and the transfer of digital money. Figure 4.2 illustrates the payment process initiated by the smart contract as the collection of the rent amount and transfer of the money from the tenant’s account to the landlord’s account. During this process, the two parties can use their blockchain addresses in order to transfer the money. In Ethereum, the built-in currency is used as a medium of exchange. On the other hand, participants in Hyperledger Fabric are modeled with an assumed account balance to achieve this functionality. 35 4. Implementation Figure 4.3: The termination of the agreement by the landlord. Figure 4.3 illustrates the termination of the smart contract by the landlord. When the two parties have decided to end the agreement, or the tenant violated one of the terms, the landlord sets the smart contract status to Terminated and the contract is no longer active. The tenant is no longer able to interact with the smart contract or make any payments at all. After the smart contract is terminated it will continue to exist on the blockchain, but payments can not be made anymore, and the state will remain the same. Role Function Description Landlord readTerms() Read the description of the house and the terms of the contract terminate() Terminate the lease of the contract Tenant readTerms() Read the description of the house and the terms of the contract signContract() Sign the contract and be obliged to the terms payRent(month,year) Pay the rent corresponding to a specific month into the year Table 4.1: Smart contract basic operations for landlord and tenant. Table 4.1 lists the four basic leasing operations implemented in the smart con- tract. After the smart contract deployment, the implemented functions become available on the blockchain. In order to read the description of the house and the terms of the contract, someone can call the function readTerms(). Signing the contract is achieved by calling the signContract() function. The smart contract then is linked with his/her blockchain address and they are the only ones that can pay the rent using the function payRent(). The landlord can also terminate the smart contract using the function terminate(), and the tenant is no longer able to interact with the smart contract. For the purpose of this thesis we left out the case of the contract termination by the tenant, but it can added in the future work. 36 4. Implementation 4.1.3 Design of the Negotiation Mechanism Figure 4.4 illustrates the negotiation of the contract terms between the landlord and the tenant. The state of the smart contract should be underReview, in order for someone to propose any changes to the terms. First, one of the two participants makes a proposal and then the other one reads the proposed terms and either accepts or declines the changes. In this case, there are two potential scenarios: the tenant makes a proposal after reading the initial terms and then the landlord reviews the proposed terms or the opposite. Figure 4.4: The smart contract negotiation process initiated by the tenant. In order to distinguish these two scenarios, the smart contract also tracks the state of the negotiation process using two states: tenantProposed and landlordProposed. Once someone has accepted the new terms, the smart contract automatically adapts to the new terms and lease of the contract initiates. Thus, the state of the smart contract changes to Initiated. The negotiation library can be considered as a piece of code that can be called by other contracts, without the need to deploy it again. Role Function Description Landlord proposeNewTerms() Propose one or a few changes in the terms of the contract /Tenant readNewTerms() Read the terms that have been proposed declineNewTerms() Decline the proposed terms acceptNewTerms() Accept the proposed terms Table 4.2: Smart contract functions used for negotiations of the terms. Table 4.2 lists the four functions implemented in the smart contract which are used for the negotiation process. Each of these function calls the appropriate func- tion implemented in the negotiations library, thus any modifications the library does will be saved in the main smart contract’s own storage. After the tenant has read the 37 4. Implementation initial terms, it is possible to make a proposal for one or more changes in the terms of the contract using the function proposeNewTerms(). The landlord then, can review the terms proposed, by the tenant by calling the function readNewTerms() and either accepts or declines the changes using the function acceptNewTerms() or declineNewTerms() respectively. If the landlord accepts the new terms the state of the contract changes to Initiated, while if they decline the proposed terms, the state changes to Terminated. The negotiation process can also be executed from the landlord’s side, where they makes the proposal and the tenant can accept or decline the new terms. 4.1.4 Role-based Access Control Model The related work of this thesis (section 2.5) includes two implementations for access control [27, 28] which are IoT-based systems operating on the blockchain technology. Additionally, Cruz et al. [29] proposed an RBAC system based on the Bitcoin network to provide an irrefutable proof of the role of the users. In order to implement a smart contact that restricts access to specific participants in the contract, we need to define an RBAC model that indicates the level of access each member has been given. State: Created Role readTerms() signContract() payRent() terminate() Landlord X 7 7 X Tenant X 7 7 7 Rest X 7 7 7 State: Initiated Role readTerms() signContract() payRent() terminate() Landlord X 7 7 X Tenant X 7 X 7 State: Terminated Role readTerms() signContract() payRent() terminate() Landlord X 7 7 7 Tenant X 7 7 7 State: underReview Role readTerms() signContract() payRent() terminate() Landlord X 7 7 X Tenant X X 7 7 Table 4.3: Access control list for the smart contract basic operations. Table 4.3 shows the authorization of each party to execute the basic operations of the smart contract, while also includes the rest of the nodes on the network (state = Created) only for the case of the Ethereum blockchain (public). Each member has specific authorization to the functions implemented in the smart contract, according 38 4. Implementation to their role. The landlord and the tenant are able to read the terms at any time, but once the smart contract is initiated no other party is able to do so. To initiate the lease of the contract someone except the landlord has to sign the contract. The tenant, which is the party that has signed the contract, is the only one that is allowed to execute the payment of the rent. Negotiation: landlordProposed Role proposeNewTerms() readNewTerms() accept() decline() Landlord 7 X 7 7 Tenant X X X X Negotiation: tenantProposed Role proposeNewTerms() readNewTerms() accept() decline() Landlord X X X X Tenant 7 X 7 7 Table 4.4: Access control list for the terms negotiation functions. Table 4.4 describes the authorization of each party to execute the functions of the smart contract terms negotiation. After the deployment of the contract by the landlord the state of the negotiation process is initialized to landlordProposed and allows the tenant to make a request of one or more changes to the contract terms, which the landlord can accept or decline. Thus, both parties can initiate negotiations (two-way) but there is a restriction of who can accept or decline the proposal. Although, they both can read the new terms at any time. 4.2 Hyperledger Fabric Implementation The implementation of the PoC makes use of Hyperledger Composer (from here on referred to as Composer), which is a rapid collaborative framework for developing applications that make use of Hyperledger Fabric. Composer is an open source project consisted of a modeling language called Composer Modelling Language, a user interface to quickly configure and test the business network called Composer Playground and Command Line Interface (CLI) tools to integrate Composer with an existing Hyperledger Fabric blockchain. The chaincode or Smart contracts are developed using JavaScript to house the transaction logic of the business network. Furthermore, the access control definition is written in a simplistic language. All these tools are bound together into a Business Network Definition (BND) archive and deployed on the Hyperledger Fabric blockchain. 39 4. Implementation 4.2.1 System Setup Figure 4.5 shows a simplified business model and the various resources of the CRE business network. The network is made up of assets and participants. In business terms, an asset is anything that is deemed to have value and can be exchanged in a business network. In the Hyperledger Fabric PoC implementation, the assets include the houses, contracts and contract terms that tenants and landlords have access to. The contract asset is the center of the business relation between the participating parties. It also relates the landlord, tenant, and contract to the terms that govern the relationship. A participant is a legitimate member of a business network. In the CRE network, participants include tenants that look to rent houses and landlords that own the property. Figure 4.5: Simplified CRE business network model in Hyperledger. The CRE network was modeled and tested using Composer Playground run- ning in browser-only mode with no validating blockchain. The mock blockchain resides in the browser’s history and allows the developer to test the transaction logic and access control list rules. Playground runs in a