Maintenance of Long-Living Smart Contracts Matthias Lohr Sven Peldszus CCRDMT, University of Koblenz-Landau University of Koblenz-Landau Koblenz, Germany Koblenz, Germany matthiaslohr@uni-koblenz.de speldszus@uni-koblenz.de Abstract—In recent years, blockchains became widely known to be bug free and feature complete starting from the first time for offering immutable and trust-free storage of arbitrary in- it is deployed on the blockchain. formation. Blockchains also leverage smart contracts, a concept While the two challenges of implementing bug free and for executing program code for modifying the blockchain state. While the characteristics of a blockchain, especially immutability, feature complete smart contracts could theoretically be solved enable reliability in a trust-free environment, it hinders the for very small and finalized functionalities, changes in the maintenance of smart contracts itself. environment might require a change in the software system With the increasing number, size, and lifetime of smart but can neither be foreseen nor planned. These environmental contracts, they could be considered to be long-living software. changes might include legal changes (e. g. GDPR [3]), changes Therefore, it might become necessary to apply common tech- niques from software engineering to maintain smart contracts. of underlying system (e. g. changes of how smart contracts are However, updating smart contracts residing within the immutable executed on the respective blockchain instance), new attacks blockchain data raises an interesting challenge. against security mechanisms that have been assumed to be In this work, we analyze whether the assumption of smart secure (e. g. DES [4]), etc. To keep the smart contract legal or contracts being long-living is true, study how immutable smart secure it has to be changed. contracts are maintained in practice and elaborate the challenges appearing due to these maintenance practices. In this work, we discuss the challenges in maintaining long- Index Terms—blockchain, smart contract, software engineer- living smart contracts. We first elaborate the assumption that ing, maintenance, security smart contracts can be considered as long-living software. We then discuss, which mechanisms are available to update smart I. I NTRODUCTION contracts and how developers can deal with the urge to update Blockchains are considered to offer an immutable storage smart contracts. for arbitrary data in a decentralized manner. In addition to The remainder of this work is structured as follows. At first, the widely known use case as crypto currency, it is also we provide a brief background on blockchain and smart con- possible to store the code and the result of executable programs tracts in Sec. II. In Sec. III, we discuss whether smart contracts called smart contracts. Due to the property of immutability of can be considered as long-living software, the update mecha- blockchains and thus also of the smart contracts stored, and nisms provided by the different smart contract platforms, and due to the determinism of the execution of smart contracts, it is how smart contracts are updated in practice. Afterwards, we possible to validate execution results, which is the underlying discuss related work in Sec. IV and conclude in Sec. V. concept of a blockchain. The immutable storage of smart con- tracts on a blockchain makes the contracts available forever. II. BACKGROUND The fact of smart contracts being available and executable For a better understanding of the concerns of this paper, forever might qualify them as long-living software. However, we provide some general and some blockchain environment a system is not necessarily long living only because of its specific background information on smart contracts. implementation being stored and executable over a long period of time. There are additional factors like maintenance and A. General Background on Smart Contracts active usage that have to be considered. In the context of blockchains, a smart contract is a software One of the biggest issues most long-living systems in program which is executed by several nodes participating in the software context have to deal with, is structural decay the respective blockchain network. A smart contract contains due to software aging [1] resulting in the formation of de- instructions on how the state of the blockchain should be sign flaws [2]. Usually, long-living systems are subject to modified depending on the set of provided input parameters. continuous changes due to bug fixes, adoption to changing Furthermore, depending on the actual implementation, it is environments, or extension with new features. When using also possible for a smart contract to trigger external actions the blockchain for storing smart contracts, resulting from the which are not observable by the blockchain. Since on-chain immutability property, it is not possible to update or delete state changes are observable by the blockchain, i. e. by all smart contracts. Therefore, there is no chance of fixing bugs participating nodes, each node can validate and accept or or adding new features once a smart contract is deployed to ignore proposed state changes if their own computation result the blockchain. However, this implies that a smart contract has equals or differs to the previously published result. Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). 250 35 One of the main properties utilized by smart contracts is the concept of being free of trust. As blockchains allow us to 30 trace everything that happened on a blockchain, there is no 200 need to trust someone as we can proof everything ourselves. Number of creates in thousands 25 There are different approaches for the implementation of Number of calls in million smart contracts. In this paper, we focus on the most important 150 blockchain platform in terms of market capitalization1 , the 20 Ethereum blockchain [5]. To give an impression about the 15 possible variety of implementations, we compare Ethereum 100 to Hyperledger Fabric [6], a blockchain concept which signifi- 10 cantly differs from Ethereum in several properties, but supports Turing-complete smart contracts as Ethereum does. 50 5 In the following subsections we give more background information about Ethereum and Hyperledger Fabric and de- 0 0 scribe identified properties regarding smart contract implemen- 0 200 400 600 800 1000 1200 1400 tation on blockchains. Days since the start of Ethereum B. Ethereum Smart Contracts Fig. 1. Number of calls (solid line) and creates (dashed line) over time Bitcoin[7], the crypto currency that made blockchains be- came widely known, already offered support for a simple set of rules for unlocking account balances. Ethereum [5] is the second most important public blockchain platform in terms of market capitalization after Bitcoin, but the most important one that offers support for Turing-complete smart contracts. In Ethereum, smart contracts can be written in Solidity2 which is compiled into bytecode. For deployment, the bytecode is writ- ten to the Ethereum blockchain (using a create transaction). A deployed smart contract can be identified by its address, which is calculated using a cryptographic hash function. Once a smart contract is deployed, Ethereum does not allow for modification or deletion of the smart contract code. However, according to the rules defined in the smart contract, it is possible to modify the state of the smart contract by invoking smart contract methods (using call transactions). Ethereum smart contracts can implement a selfdestruct method, which allows the owner to mark a contract as obsolete. Selfdestruction results in not Fig. 2. Contract size over time being able to use the smart contract anymore and is not reversible. When a user wants to call a smart contract method, he cre- started in July 2015 until end of October 2019 2,988,133 ates a call transaction with the address of the Smart Contract contracts have been deployed so far. According to Fig. 1 the and all input parameters. This transaction is published to the number of created and executed smart contracts per day has network and processed by so-called mining nodes, which will continuously increased. The same holds for the size of the execute transaction and create a new block with the outcome. smart contracts, which is visualized in Fig. 2. Since the order of the transaction and the bytecode of the smart contract is publicly known, everybody can validate the C. Hyperledger Fabric Smart Contracts transaction. For including the result into a new block, miners Hyperledger Fabric [6] is a framework for creating busi- have to execute the code. Besides the inherent consensus algo- ness grade permissioned blockchains. The main differences rithm of the Ethereum blockchain there is no need for conflict between permissioned and public blockchains are that a resolution for transaction results, since – assuming correct permissioned blockchain requires authorized access to the execution – each mining node will come to the same result. blockchain while public blockchains allow users to create This way, state changes are deterministic and unambiguous. an unlimited number of pseudonyms. In Hyperledger Fabric, The execution pattern of Ethereum is called Order-Execute. smart contracts can be written in any programming language For our analysis, we used Ethereum data dumps provided and run as standalone software. The code of a smart contract by Blockchair.com [8]. Since the Ethereum main network was is not part of the blockchain but can be developed and 1 CoinMarketCap Ranking – http://coinmarketcap.com [accessed Dec19] distributed using established software deployment and delivery 2 Solidity Documentation – http://solidity.readthedocs.io [accessed Dec19] architectures. When a smart contract program is started, it TABLE I C OMPARISON OF S MART C ONTRACT P LATFORM C HARACTERISTICS REGARDING E THEREUM AND H YPERLEDGER FABRIC Property Name Ethereum Hyperledger Fabric a) Programming Language specific arbitrary b) Code Deployment on-chain custom c) Code Distribution on-chain custom d) Executing Peers mining and validating nodes endorsing nodes e) Execution Environment Ethereum Virtual Machine arbitrary f) External Communication not possible possible g) Result Distribution on-chain on-chain listens to incoming transactions, calculates the result according d) Executing Peers: In a blockchain network, executing to the input parameters and the code and sends back the result smart contracts could be a bottleneck if all nodes are obliged to the blockchain infrastructure. to execute any smart contract, e. g. for verification. The whole When a user wants to call a smart contract, he creates a new network would have to wait for the slowest node. For this transaction containing the name of the smart contract and all reason, only a subset of nodes in a network is actually input parameters. This transaction is published to the network executing smart contract code. and processed only by nodes having access to the smart con- In Ethereum, since the smart contract code is part of the tract program (called endorsing nodes). All endorsing nodes publicly available blockchain data, any node could execute send their results to an ordering service, which defines the smart contracts. But only the one node, which “finds” a order in which the transactions are applied to the blockchain. new block is getting paid for executing smart contracts by After the transaction results have been ordered, each node in receiving transaction fees. Other nodes, which want to verify the network applies the outcomes following predefined policies the execution result can, but do not have to, execute the for that specific environment. These policies can define, how smart contract on their own. In Hyperledger Fabric, nodes can, many and which kind of nodes have to present a certain result depending on the smart contract, have the endorser role. Only before it gets accepted to be appended to the blockchain. endorsing nodes will execute smart contracts. However, before a node can become an endorsing node, the node operator has D. Smart Contract Platform Characteristics to get the smart contract code. We identified the following characteristics regarding smart e) Execution Environment: The execution environment contract execution. For a comparison between Ethereum and defines the limits in which a smart contract can run regarding Hyperledger Fabric see Table I. both functionality and resource consumption. a) Programming Language: Depending on the smart In Ethereum, smart contracts are executed in the Ethereum contract platform, smart contract developers are limited in Virtual Machine (EVM), which supports Turing-complete pro- choosing programming languages. grams provided, but with a limited subset of available libraries. For example, Solidity was influenced by existing program- Each bytecode instruction has an assigned cost value (Gas), ming languages like C++, Python and JavaScript, but is which has to be payed for executing the smart contract. designed for use with Ethereum only. In Hyperledger Fabric, a This way, the Ethereum Virtual Machine protects executing smart contract runs as individual application, so it is possible nodes from high computational load, since the execution will to use any programming language for software development. abort if the Gas limit is reached. In Hyperledger Fabric the b) Code Deployment: Code deployment denotes how the execution environment is not constrained. Nevertheless, smart blockchain network is informed about a new smart contract. contract code is usually executed in a virtual environment Other nodes can use this information for creating transactions (e. g. Docker) for protecting the host from possible malicious to request smart contract execution. actions. However, it is still possible to induce high loads to In Ethereum, this is done by creating a transaction which the host system, if the virtual environment is not properly contains the smart contract and registers it with the blockchain. configured for limiting available hardware resources. In Hyperledger Fabric, this is done by publishing some meta f) External Communication: Depending on the applica- information (smart contract name, smart contract version, ...) tion, a smart contract may need additional data, which is not to the network. The actual code is not part of this information. provided by the contract call. In this case, a smart contact c) Code Distribution: This property describes, how the needs access to external data sources (e. g. weather sensor). smart contract code is distributed to the nodes which want to In Ethereum, it is not possible to query off-chain data execute the smart contract. sources. Instead, it is possible to create so-called Oracles. In Ethereum, since the smart contract code is deployed An Oracle is a smart contract, which contains a certain to the blockchain, it is distributed along with the block information and can be updated from another source using data. In Hyperledger Fabric, distribution is up to the smart smart contract method calls. However, the process for updating contract operator, which can use common software distribution the information contained in the oracle can not be initialized by mechanisms (e. g. a website, package repository, etc.). a smart contract. In Hyperledger Fabric, since a smart contract is realized as a standalone software program, it can access any data source it wants to. Depending on the data source (e.g. random value generator) this might result in different results for multiple smart contract invocations with the same input parameters provided in the call transaction. Therefore, a method for result conflict resolution is required. g) Result Distribution: Smart contract execution would be useless if the execution results are ignored. Therefore, all blockchain environments known to us use the blockchain as a log for the results. On Ethereum, every node can validate the result since input parameters, code and result are written to the blockchain. In Hyperledger Fabric, predefined policies decide how consensus is reached if endorsing peers offer different possible results. III. D ISCUSSION In this section, we discuss the state of the art regarding the Fig. 3. Lifespan of smart contracts usage and update mechanisms of smart contracts. This covers an analysis whether smart contracts can be considered as long- living software and a summary of the update mechanisms provided by different smart contract platforms. From the state of the art and practical usage of update mechanisms we derive issues in the development of long-living smart contracts and discuss how software engineering can address those issues. A. Are Smart Contracts Long-Living Systems? As we described before, the immutability of the Ethereum blockchain seems to automatically result in every smart con- tract to be long-living as it cannot be removed or updated. However, only being stored on the blockchain does not nec- essarily imply longevity. In the context of smart contracts we consider longevity as the active use of a smart contract over a long period of time. However, even for traditional long- living software systems this period of time is not precisely defined [9]. As smart contracts are a comparably young technology we cannot consider the long period of usage in Fig. 4. Amount of contracts that have been redeployed x times terms of decades like e. g. the software used by financial institutes. For this reason, the goal is to study whether the current usage of smart contracts indicates a potential use creation and get inactive after a few days. The majority of similar to traditional long-living software. smart contracts has a lifespan between a couple and about 800 To study the usage and longevity of smart contracts we days. Nevertheless, there are still many smart contracts with a analyzed the Ethereum blockchain between its creation in mid lifespan higher than 800 days up to being alive for nearly the 2015 and end of October 2019 (in total 1,555 days) using entire time frame considered. Those smart contracts might be the data provided by Blockchair [8]. All in all, this time considered as long-living. frame covers the creation of 2,988,133 smart contracts of Also smart contracts which have been used for a short which 1,048,835 smart contracts have been called at least once. period of time could be considered as long-living if they 606,821 smart contracts have been called more than once. For are deployed multiple times, distributed over a longer period the following discussion, we excluded the smart contracts that of time. For this reason, we counted how often exactly the have never been called. same code is redeployed to the block chain. In fact, the To answer the question whether smart contracts are long- 2,988,133 smart contract creations considered only contain living, we calculated the lifespan of each contract created by 596,229 different smart contract implementations. From these, determining the time between the creation of the contract on 45,107 implementations have been deployed more than once the blockchain and its last execution. with exactly the same code. In Fig. 4 we show the number of In Fig. 3 we plotted how many smart contracts have been smart contracts with multiple redeployments. deployed that reach a certain lifespan (measured in days). We Due to the young age of the Ethereum blockchain the figures can see that many smart contracts are used immediately after presented are heavily biased by recently created contracts that created for single-use, and smart contracts which can be used multiple times with a single deployment. Deployment per use. In this case the recreation of the smart contract is part of the concept and allows to maintain the smart contracts code in between the single uses. While for smart contracts without changes a simple comparison of the byte code of an existing contract known to behave as expected is enough the updated contract has to be checked in detail. However, the same mechanism can be applied here as for a smart contract where no version known to be secure exists. Single deployment. It is possible to implement smart con- tract with some kind of session management to enable the use for multiple parallel sessions. Once the address of the smart contract is publicly known, users can be certain to commu- nicate with the same smart contract on each interaction. The redeployment of such a smart contract, which will technically result in a new smart contract with a new address, raises the Fig. 5. Relation between date of contract creation and lifespan of the contract issue of distributing the new address since the fixed address is part of the contract usage design. can not yet be considered as long-living. This gets even worse One approach to tackle this issue are centralized places due to the increase of contract creations per month as shown in for the exchange of the current address for a specific smart Fig. 1. To get a feeling about the distribution of the contracts contract. E.g. this can be smart contract market places, the lifespan in relation to the date of their creation, we plotted website of the contract deployer, or a client software used for the lifespan of contacts in relation to the date of their creation the execution of the smart contract. Each of these solution in Fig. 5. Early after the release of the Ethereum (at x=0) contains some kind of Single-Point-of-Failure. a few long-living and some only short living smart contracts To avoid the usage of the old deprecated smart contract have been created. For later creation dates more and more the deployer has to revoke the old one. This step might not be long smart contacts with higher lifespans are created. It is executed by the deployer due to various reasons, like expecting interesting that there are points of time where large amounts too high cost for the self destruct or due of laziness. If this of short, medium, and long lifespans have been created. The self destruct does not happen or is not possible, e.g. because two most obvious ones are after 200 and 600 days. required authentication data has been lost, users unaware of In summary, compared to the lifetime of the Ethereum the new smart contract might continue using the old one blockchain, a significant amount of smart contracts deployed containing bugs or security issues. to the Ethereum blockchain can be considered as long-living b) Proxy Smart Contracts: A pattern frequently used is within the Ethereum ecosystem. However, in relation to time to deploy a pair of smart contracts where one of the contracts frames traditionally considered for long-living software sys- functions as a proxy for the other smart contract. The proxy tems, it has to be observed if the future lifespan and usage pat- contract has a changeable variable containing the address of terns of smart contracts converge to the general understanding the actual smart contract doing the work. Whenever a newer of long-living software systems. Regarding this, our findings smart contract version is released, the value of this variable is indicate that smart-contracts might become long-living. For updated. If the proxy is called, it calls the newest version of the long-living smart contracts, we have to evaluate blockchain smart contract that has been released. While this pattern seems characteristics colliding with smart contract maintenance. to behave very well in practice, it violates the assumption that B. Update Patterns every time the same address is called with the same input, the smart contract at this address behaves the same. If a blockchain is used for smart contract deployment and As there is currently no update mechanism that provides a distribution, a smart contract can neither be updated nor trust-free redirect to the new smart contract, updates should deleted once it is deployed. However, most systems need be only performed for security critical changes and should be to provide update functionality e. g. to deal with changing well documented. environments. This holds especially for long-living systems which, according to the previous subsection, smart contracts C. Challenges and Future Work can be. We discovered two main patterns used to update smart Based on the previous discussions we identified challenges contracts on the Ethereum blockchain that should be tackled in the future. The overall challenge a) Redeployment: The simplest update pattern is the is how to tackle the maintenance problem of long-living creation of a new smart contract where all changes are applied. smart contracts. To deal with this challenge, we identified the Here, we have to distinguish between smart contracts that are subchallenges present in the following. While we have already been able to extract much informa- detection on the contracts available on the Ethereum block tion from the Ethereum blockchain there are still more things chain. A similar approach could be used by us to detect to be studied in detail. versions of contracts. At first, we have to provide a more precise definition of Bartoletti manually classified contracts published on the a long-living smart contract. In this work, we only discussed Ethereum blockchain into different categories [11]. Further- informally, based on quantitative data, if there exist long-living more, they studied which patterns have been implemented in smart contracts on the Ethereum blockchain. A more formal the contracts, e.g. an authentication. definition would allow to explicitly select the long-living smart Parizi et al. studied the effectiveness of open source security contracts and to study them in depth. testing tools for smart contracts on ten contracts taken from Second, we need more detailed information on the versions the Ethereum blockchain [12]. Effective tools for detecting of long-living smart contracts. In this work, we searched for issues early and avoiding them can help to also avoid the smart contracts that have been redeployed without changes. issues arising from the need to update already published smart However, we expect many contracts to be redeployed with contracts discussed in this work. small changes, reflecting an iterative development process. The While we discuss update patterns for smart contracts, challenge is to detect and analyze them. I.e., we have to study Wohrer et al. are discussing security patterns in their which changes have been made between different versions of a work [13]. They are presenting a collection of patterns de- smart contract. This can allow us to get a deeper understanding scribing solutions to typical issues. of the reasons for maintenance and allow us to reduce the Liu et al. discuss design patterns for smart contracts and amount of redeployments by developing best practices and even identified two patterns categorized as creational pat- tool support for reducing the probability for errors. terns [14]. Unfortunately, those creational patterns do not Extracting usage patterns from the smart contracts and consider maintenance and updates of the contract. studying their pros and cons is a first step for applying mature software engineering to smart contracts. While there is already V. C ONCLUSION some work on this issue, the challenge is still to get a deeper In this work we conducted an initial study of smart contracts understanding of good patterns for smart contracts. Also these deployed on the Ethereum blockchain and discussed whether usage patterns should be compared to the usage patterns of smart contracts can or should be considered to be long-living traditional software with the aim of a knowledge transfer. software. We show, that there is a conflict between the idea Another challenge is to search and identify more update pat- of having immutable smart contract code and the need for terns and to quantify their usage. While we already identified updates as part of a software’s life cycle. two update patterns there might be more that we are currently Despite lacking a formal definition of long-living smart not aware of. The open question is if we will find always contracts, we discovered that a significant amount of smart the same patterns to be used frequently or a larger variety contracts could be considered to be long-living. In general, of update patterns. Again, a deeper understanding on update long-living software needs the capability of updates, e.g. for patterns for smart contracts will increase the understanding on adoption to unforeseen changes in the environment. This also how smart contracts are deployed and developed. Furthermore, applies for software in blockchain context, like smart contracts. there are well-proven update patterns in traditional, non- For the smart contract code itself well known maintenance blockchain software systems. It has to be checked if these principles can be applied. However, we are currently not aware patterns could be applied to smart contracts stored on a of e. g. refactoring approaches for smart contracts [15]. blockchain. Particular attention should be payed to software More challenging is the secure update of the deployed smart systems providing the possibility to be updated while being contracts. While proxy smart contracts seem to work very well handle long-running transactions. in practice, it might raise the issue of smart contract address In general, one has to follow the Ethereum community distribution for securely informing clients about an updated discussions to learn in which direction smart contracts will smart contract version. The key principle of an identical evolve and which concepts should get part, e.g. of Ethereum, behavior per invocation might be violated by the use of proxy to allow maintenance of smart contracts. One solution to smart contracts. Unfortunately, for now we can not recommend ease the maintenance of smart contracts could be to allow a better solution if the contract should stay available under the the specification of additional information when executing same address. However, we see a high need for mechanisms to a selfdestruct, e.g. by adding a pointer which points to the update the code of smart contracts. For this reason, we want succeeding version of the smart contract to be destructed. to motivate discussions and research to address the conflict between reliable and and secure smart contract platforms and IV. R ELATED W ORKS the need for updating the smart contract code. Besides us also other researchers are studying the usage of As changes in long-living systems cannot always be pro- smart contracts. In this section we discuss their works and hibited and smart contracts can be long-living systems, smart relate them to our work. contracts platforms should provide transparent ways to update Chen et al. analyze the Ethereum blockchain for occurrences the code of smart contracts and allow everyone interested in of ponzi schemes [10]. For this purpose they utilize a pattern calling the contract to trace the changes. In our future work we are going to get a deeper under- [8] “Blockchair Database Dumps,” online, https://blockchair.com/dumps, standing on the versioning of smart contracts as well as in [accessed Feb 20]. update mechanisms. Based on this understanding we are going [9] J. Bürger, “Recovering Security in Model-Based Software Engineering by Context-Driven Co-Evolution,” Ph.D. dissertation, 2019. to develop best practices and additional tool support. [10] W. Chen, Z. Zheng, E. C. . Ngai, P. Zheng, and Y. Zhou, “Exploiting R EFERENCES Blockchain Data to Detect Smart Ponzi Schemes on Ethereum,” IEEE Access, vol. 7, pp. 37 575–37 586, 2019. [1] D. L. Parnas, “Software Aging,” in ICSE. IEEE, 1994, pp. 279–287. [2] S. Peldszus, G. Kulcsár, M. Lochau, and S. Schulze, “Continuous [11] M. Bartoletti and L. Pompianu, “An Empirical Analysis of Smart Detection of Design Flaws in Evolving Object-Oriented Programs using Contracts: Platforms, Applications, and Design Patterns,” in Financial Incremental Multi-pattern Matching,” in ASE, Sep. 2016. Cryptography and Data Security, 2017, pp. 494–509. [3] European Parliament and Council of the European Uninon, “Regulation [12] R. M. Parizi, A. Dehghantanha, K.-K. R. Choo, and A. Singh, “Empirical (EU) 2016/679 – General Data Protection Regulation (GDPR),” in Vulnerability Analysis of Automated Smart Contracts Security Testing Official Journal of the European Union, 2016. on Blockchains,” in CASCON, 2018, pp. 103–113. [4] E. Biham and A. Shamir, Differential Cryptanalysis of the Data Encryp- tion Standard. Springer Science & Business Media, 2012. [13] M. Wohrer and U. Zdun, “Smart Contracts: Security Patterns in the [5] G. Wood et al., “Ethereum: A Secure Decentralised Generalised Trans- Ethereum Ecosystem and Solidity,” in IWBOSE, 2018, pp. 2–8. action Ledger,” Ethereum Project Yellow Paper, 2014. [14] Y. Liu, Q. Lu, X. Xu, L. Zhu, and H. Yao, Applying Design Patterns in [6] C. Cachin, “Architecture of the Hyperledger Blockchain Fabric,” in Smart Contracts, Jun. 2018, pp. 92–106. DCCL, vol. 310, 2016. [7] S. Nakamoto et al., “Bitcoin: A Peer-to-peer Electronic Cash System,” [15] M. Fowler, Refactoring: Improving the Design of Existing Code. 2008. Addison-Wesley Professional, 2018.