=Paper=
{{Paper
|id=Vol-2581/emls2020paper3
|storemode=property
|title=Maintenance of Long-Living Smart Contracts
|pdfUrl=https://ceur-ws.org/Vol-2581/emls2020paper3.pdf
|volume=Vol-2581
|authors=Matthias Lohr,Sven Peldszus
|dblpUrl=https://dblp.org/rec/conf/se/LohrP20
}}
==Maintenance of Long-Living Smart Contracts==
https://ceur-ws.org/Vol-2581/emls2020paper3.pdf
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.