=Paper=
{{Paper
|id=Vol-2586/paper1
|storemode=property
|title=Model of Dynamic Smart Contract for
Permissioned Blockchains
|pdfUrl=https://ceur-ws.org/Vol-2586/paper1.pdf
|volume=Vol-2586
|authors=Adnan Imeri,Jonathan Lamont,Nazim Agoulmine,Djamel Khadraoui
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/ImeriLAK19
}}
==Model of Dynamic Smart Contract for
Permissioned Blockchains==
https://ceur-ws.org/Vol-2586/paper1.pdf
Model of Dynamic Smart Contract for
permissioned Blockchains
Adnan Imeri1,2 , Jonathan Lamont1 Nazim Agoulmine2 , and Djamel
Khadraoui1
1
Luxembourg Institute of Science and Technology (LIST),
adnan.imeri@list.lu,
https://www.list.lu/
2
Université of Évry Val d’Essonne, Evry, France
Abstract. The blockchain technology and smart contract capabilities
encourage scholars and retailers on investigating the new conceptual
modeling and technological opportunities for redesigning the current and
future business processes. The emerge of blockchain technology indicates
the new era in designing and developing the business process mainly by
using smart contracts. Along with these opportunities, different chal-
lenges are presented in the current state of blockchain technology and
smart contracts. Among them, the emphases cases are the alignment of
the new changes on the requirements from the business process, to the
smart contracts. We present a new way of modeling a smart contract
that impacts on the maintainability of the enterprise blockchain-based
solution. This paper shows a new approach that allows smart contracts
acting dynamically over lift time changes on the business process logic
specific to the use case.
Key words: Enterprise modeling, Smart Contract, Immutability, Main-
tainability, Design Pattern, Hyperledger Fabric
1 Introduction
Since the invention, blockchain technology has been the subject of explo-
ration from academics and industries. The technology that stands behind Bit-
coin initially was the focus of cryptocurrency industries [1]. Further, it has
been extended in different domain of application, and many governmental, non-
governmental, industrial organization are exploring the technological design of
the blockchain to improve their activities, business process, etc., [2][3]. The first
generation of blockchain, i.e., Bitcoin comes with limited technological capa-
bilities in terms of designing complex business processes [1]. The emerging of
the Ethereum (ETH) blockchain framework, with the possibility of deploying
smart contract (SC), enabled a new way of execution of application over the
blockchain network [4]. The combination of blockchain and SC enabled a new
market for a decentralized application that provides a new level of automation
of many business processes [7]. Simultaneously, with the opportunities offered by
Copyright © 2020 for this paper by its authors. Use permitted under
Creative Commons License Attribution 4.0 International (CC BY 4.0).
Copyright © 2020 for this paper by its authors. Use permitted under
Creative Commons License Attribution 4.0 International (CC BY 4.0).
Copyright © JJJJ for this paper by its authors. Use permitted under
Creative Commons License Attribution 4.0 International (CC BY 4.0).
2 Adnan Imeri et al.
blockchain and SC, there are various concerns to considers for blockchain-based
applications. These issues are on designing a blockchain-based application that
should behave as intended by the end-user. Further, the security and privacy
issues, performance issues, and programmable issues and maintainability of al-
ready running blockchain solutions are amongst the most highlighted concerns
when considering designing a blockchain-based application [8]. The research and
industrial communities already faced before-mentioned problems, and for over-
coming these issues, there are discovered several design patterns as the best
practices from the community, that help researchers and developers on design-
ing reliable smart contracts (SC) [9]. Through this research, we intend to provide
a new model for improving SC designing and execution. The research problem
discussed in this paper is related to the maintainability of immutability feature
of SC. Indeed, the code of a SC cannot be modified due to the blockchain im-
mutability property once it is deployed. For any required modification on the
existing SC, the deployment of this SC into a blockchain, meaning to have a
new reference of this SC on the blockchain. This leads to complicated mainte-
nance tasks according to the number of contracts to update, the eventual static
cross-references. Our goal is to enable a way to integrate a dynamic behavior
into SCs without deploying them again.
Regarding this research, we implemented a proof of concept, for a particular
use case, and it is accessible on a public Git.
The rest of the paper is organized as follows. Section 2 presents an extensive
study over the blockchain technology and exploration of Hyperledger Fabric as
the selected blockchain framework for this study. Section 3 defines the study
problem and a use case. In section 4 we present related works studies. Section 5
shows our conceptual approach and proof-of-concept implementation. The eval-
uation of the solution is presented in section 6 along with discussion and future
works.
2 Background: Blockchain Technology
Blockchain is a decentralized-distributed append-only database that enables
storing of the immutable set of transactions, organized in a hash tree (Merkle-
Tree) [10] [11]. The transactions present any kind of data such as financial data,
textual or numeric data, that are encapsulated on transactions by users [12] [13].
These transactions are gathered together into a candidate block by miners that
compete with each other intending to validate this new block [11]. Miners are
high-performance computers that is allowed to add a new block on the chain of
blocks. The block, besides transactions root it contains other significant compo-
nents such as timestamp, block header, mathematical difficulty puzzle usually
called as “nonce”, the hash of the previous block, thus forming a chain of blocks
or ”blockchain” [14].
Blockchain network: The blockchain network is an extensive set of devices
that communicate in a peer-to-peer mode (P2P). The nodes are computers-
servers that are geographically distributed, and they contain the same copy of
Dynamic Smart Contract for permissioned Blockchains 3
the ledger. The consensus algorithm that allows these notes to agree on the state
of the data, removes the need for a trusted third party, thus making blockchain
entirely decentralized [11].
Consensus protocol: For agreeing on the state of the data, blockchain uses a
consensus mechanism, e.g., Proof-of-Work, Proof of Stake, etc. Once the miner
solves a computational mathematical puzzle, it distributes the “nonce” to the
other miners. All the miners verify the solution of the puzzle by applying the
”nonce”, then they approve the adding of the new block in the chain of blocks,
and all nodes are updated by adding a new block [14].
Immutability: The transactions added on the blockchain are cryptographi-
cally signed. Once the transactions appear in blockchain they remain immutable.
Any tendency to change them will change the transaction root of Merkle Tree,
and the consensus algorithms will deny this change by comparing the cur-
rent changed block with other blocks from other nodes that contain the same
blockchain [13].
Non-repudiation: The properties of immutability and data integrity, enforces
the properties of non-repudiation [11].
Availability: The blockchain network maintains the availability, even if some
nodes fails to response [1].
On-Chain vs Off-Chain: The design properties of the blockchain allows stor-
ing a limited amount of data on chain. These data are the most significant
information, transaction and meta-data (hash values) referenced from large files
that are stored off-chain [15]
Permission-less and permissioned blockchains: For the permission-less blockchains,
there is not required any authorization for accessing the main network of the
blockchain, mining transactions and exploring the executed transactions. In con-
trary, for accessing permissioned blockchain, nodes are required to have per-
mission by the administrator of the blockchain network [13]. The permissioned
blockchain, such as Hyperledger Fabric [6] and the SCs are subject of this study.
2.1 The semantic of smart contract
Smart Contract (SC): is a stand-alone program that is executed when cer-
tain conditions are fulfilled. It might execute asset transfers, execute another
contract, fulfill the conditions from any business process [16] [17]. At the high-
est level it is expressed by sort of object-oriented programming language, e.g.,
Solidity [16], JavaScript, Go, and Java. The encoding of SC is sourced from nat-
ural language, legal contracts, business agreements, and other domain-specific
sources. The enforcement of the agreements that are reached between parties
involved, are further translated into SC programming code and added on the
blockchain [18]. Nowadays the most prominent SC-enable technology is ETH
[19], and another blockchain platform such as Hyperledger Fabric is providing
high-level programmable SC. By design, SC has some technological features. SC
remains immutable once it is deployed on the blockchain, by contract transac-
tion. Among the main design principles of the SC are [20]:
4 Adnan Imeri et al.
– SC address (ID), a hash value, that identifies the SC on the blockchain.
– Owner ID, a 256bit hash value, which indicates the owner of the SC.
– Internal storage, the SC has its private storage, it holds its execution code
with pre-defined parameters, some amount of virtual currency (own balance
of the SC).
– Execution costs, for the blockchain platforms, what need digital coins to per-
form a transaction mining, the execution of the SC has its own costs.
– Enforcement, the contractual obligation that is expressed in the terms of SC,
e.g., transfer assets once the goods are received, are automatically performed
as contractual obligations and enforced by SC.
– Invoke another SC, by sending a transaction to the SC address.
– Autonomous, the predefined parameter on the SC code allow the SC to change
the state of on blockchain if executed successfully.
– Self-Execution, the SC is a set of autonomous executable agents that are trig-
ger by predefined parameters on the SC code or executed from environments
parameters.
– Event/Method are set of instruction that are executed in the SC for fulfilling
intended task.
SC are invoked by users, by sending the transaction to the contract address,
e.g., some amount on it and parameters to execute the targeted SC [17][18][20].
Furthermore, an SC can call synchronously another SC and also as synchronously
off-chain service [17]. SC supports an ordered logic that follows the ordering
rules if this than that (IFTTT). This semantic is called event ordering logic (or
order-execute), and SC events (function invocation) are executed as they are
placed. Under this logic, if the current order passes then, continue on the second
order, otherwise, throw an exception [19]. This logic is present in almost all SC
enabling blockchain platforms, expect in Hyperledger Fabric, which is one of the
main focus in this study and it is explained in detail in the following section 2.2.
2.2 Hyperledger Fabric
Hyperledger Fabric (HF) is an open-source blockchain that allows designing
and developing private or consortium blockchain-based solutions with a focus on
the business-oriented use cases [6][21][22]. HF has a modular and configurable
architecture that allows users to adopt blockchain technology for their use case.
HF is implemented in the GoLang programming language and supports users
with different tools. HF provides Software Development Kits (SDK) for vari-
ous programming languages [25] such as GoLang, Java, NodeJS, and Python
[21][22]. HF allows writing of SC in general-purpose programming, which is be-
yond domain-specific language i.e., “Solidity for ETH”.
2.2.1 HF Overview and functionalities
Entities: Consortium and Organization. HF defines different entities regard-
ing the participants involved in the project. The HF network is managed by
a group of organizations gathered into a consortium. Each organization should
Dynamic Smart Contract for permissioned Blockchains 5
manage its nodes and should have at least one Certification Authority (CA)
node, and one Orderer node [21][22].
Nodes, Peer, Orderer, CA and Client. HF defines four types of nodes. The
main type of node is Peer nodes which manage the blockchain mechanisms.
Peers can join channels, and they can host different SC over each channel1 .
Orderer nodes ensure the consensus of the HF blockchain network and keep
the peer’s ledgers consistent [21][22]. Each peer must be connected to an Orderer
node. They also execute SC requests in the case where Orderer gives agreement
(after checking permissions) [21][22]. Certification Authority nodes ensure
identity delivery via digital certificates, typically required by each organization
to enroll new members. CA is a private root Certification Authority provider
which can manage digital identities of participants [21][22]. Client nodes can
connect to and interact with peers deployed over the network [21][22]. All node
types are provided as docker containers [23].
2.2.2 Smart Contract (SC) or Chaincode in HF
In the HF jargon, a SC is referred to as “chaincode”. Chaincode, or SC, is
the blockchain embedded application which is typically a running script inside a
peer. Every SC that is executed maintains its database, to store data or the state
of the code execution. This database is called WorldStateDB. This is a database
local to each channel and SC whose values are continuously kept up-to-date by
reading assets, values changes from the ledger blocks. The ledger keeps all value
changes in blocks, while the WorldStateDB keeps the last current value for each
asset [21][22].
Amongst the main SC main concepts that are necessary for any kind of
application on HF:
– Participant refers to a user that is defined in the SC. For handling different
users in our application, we extend the “Participant” type [21][22];
– Asset expresses every kind of valuable thing that can be exchanged between
persons (i.e. participant), and therefore changes its ownership [21][22];
– Transaction is a way to exchange the ownership of the asset.
– Event is the only way to communicate data outside the blockchain network.
Events are broadcasted on channels and can be caught by an external appli-
cation that has access rights to listen to the desired channel [21][22].
3 Problem definition: The issues of maintaining the
immutability of the SC
Immutability: For permissionless or permissioned blockchain, an SC remains
immutable once it is deployed on the blockchain. This means, all the terms and
the logic implemented behind the SC, remains unchanged over time. Thus, in
1
A channel can be considered as a independent sub-blockchain.
6 Adnan Imeri et al.
case we need to make some changes in the logic of the SC (add or remove events),
we should redeploy it, and a new hash will generate as an ID for that SC. From
the user, that needs to use this SC, they are obliged to know the newest address
of SC, before being able to invoke it. Otherwise, the user will call the old one,
since its hash value is already mapped on the current SC. Figure 1 is illustrating
these issues by showing changes to the SC address.
The new address of the contract should be distributed to all stakeholders
that are invoking this smart contact. The concern is that all the other smart
contracts that have invoked this SC (now with new hash address) should be
changed. That means that we have to reconfigure the entire system (i.e., all
objects need to have the new address). For instance, if there are thousands
of contracts that call the same SC, then, this would be extremely difficult to
reconfigure it (cf. maintenance), and the performance will become a concern
for the blockchain-based applications. Furthermore, this implies the automation
capability of the process decreases in this sense.
This problem is a concern for enterprises that are intending to move some of
their business logic over the blockchain. Indeed, to keep the maintainability, we
need modularity, which means that a complex problem should be divided into
several minor problems further, to solve them much more easily. Just as using
code libraries, using several inter-connected SCs becomes useful for high-level
business processes. Thus, we can assume a complex system using several SC
with cross-references and automation. However, using static addresses for the
contracts that are hardcoded in the contract logic is leading to uncomfortable
maintenance, as explained above.
Fig. 1. The basic problem of immutability of smart contracts.
Cross-references: From the enterprise modeling perspective, involving several
SC and cross communication to perform high-level tasks, still, exposes the same
Dynamic Smart Contract for permissioned Blockchains 7
problems. Figure 2, shows the issues of logic flows for cross-reference SC. In
case of a SC logic update, either from the caller side, either from the executor
side, there will be another SC address to know. For instance, considering two
SC, where SC1 calls SC2, and if we only update SC2 (to SC20 ), then we must
change SC2 address reference into SC1 to point to SC20 . That implies also to
change SC1 to SC10 . These sidesteps are not ideal for a system in production
due to heavy infrastructure maintenance. However, this case, it’s even worse
when we have cross-references, i.e., if SC1 calls SC2 and SC2 calls SC1, then we
fall into a deadlock situation because SC1 and SC2 have a hardcoded address
of the other by exchange. That comes from the fact that we cannot guess the
address of a future SC to hardcode it in advance in the logic. Thereby, here
there no workaround to do, except avoiding bidirectional cross-references for
maintainability.
Fig. 2. The problem of cross-references for smart contract.
3.1 Use case of temperature checking. The issues of SC in a dynamic
environment
Temperature checking: Considering that we have a SC which aims to check the
temperature that are collected by one IoT sensor, storing its data directly into
the blockchain. This SC is checking on demand the current temperature (from
the IoT device), and if this temperature exceeds a specific threshold, a set of
users should be notified based on the pre-defined condition in a particular use
case, e.g., transporting dangerous goods, that is sensitive to a temperature degree
[24].
Detailing the features of this SC, it has three core functionalities. The first
one is to collect the temperatures provided from an IoT sensors. This IoT
device is authenticated and transmitting its data directly in the blockchain. The
second functionality of this SC is to set and change the temperature threshold
of detection. The third functionality is to notify all involved stakeholders when
the temperature threshold is exceeded, for taking the necessary actions need to
avoid any possible consequences.
The issue is regarding the threshold and the set transactions. The common
approach is to define the threshold as a static constant into the SC code (i.e.
as an hardcoded and immutable variable). Certainly, we will need to update
the contract each time when the constant need to be changes, and this exposes
enormous problems as we mentioned above.
8 Adnan Imeri et al.
This use-case doesn’t deal explicitly with cross-references because there is
only one SC, but the mechanism of the solution remains the same. Indeed, for
both two SCs, by storing the target SC address as a variable (in place of the
threshold ) that allows to dynamically change that address and then unlock the
deadlock situation. For overcoming these issues we propose a new way of manag-
ing the SC, by storing the threshold constant as a variable into a SC asset. The
SC asset is an editable variable that allows to update it dynamically (as required
by the use case), and avoiding the change of the code of SC. In the following
section 4, we present some related works towards designing maintainable SC,
and further in section 5, we present the model of dynamic SC for permissioned
blockchain.
4 SC designing, modeling and development: Related
Works Studies
SC is the subject of many studies from academia, research organizations
and also from industry. Designing SC is one of the main challenges highlighted
recently by scholars and industry. The literature review shows that there are
presented several design patterns for supporting the best practices for designing
a SC. Mainly these design patterns are on “security of SC” [25], “structural pat-
terns” [26], “privacy issues” [27], “performance issues” [25, 28, 29]. The research
from [35], proposes an upgradable SC by using a proxy pattern. Research from
[26] summarizes SC design patterns based on the existing SC and further apply
some of the design patterns in a real work blockchain-based application for trace-
ability. There are presented different classifications of patterns for designing SC
such as “action and control”, “authorization”, “lifecycle”, “maintenance”, “se-
curity” are presented in [30]. Within certain classes of the design patterns for
SC, our research is essentially linked to the maintenance pattern, and intend to
improve the current way of maintaining SC. The main related design patterns
proposal satellite and contract relay [30], are the essentially related to our
research works. The satellite pattern is using two SC: satellite and base [30]. It
enables to update a variable from base by calculating the value from the satel-
lite thanks to the address reference of the satellite held into base. This allows us
to dynamically change the value of the variable by just upgrading the satellite
contract with the newest calculus and updating the satellite address in the base
contract. In the contrary to this solution, we do not use the second SC, but
rather the asset notion from HF which can be compared to a internal variable
into ETH (requiring the only update by transaction call). Further, the contract
relay pattern is using two contracts: base and relay. The relay contract serves
as an entry point in order to provide the latest version/address of the base con-
tract, and then forward any call to it. This is a proxy enabling to upgrade the
base contract without upgrading the user entry point (relay). Nevertheless, the
drawback that the newer data storage needs to be consistent to avoid data cor-
ruption. These two design patterns propose solutions including good practices
for maintenance issues that well fit public blockchains. It requires sophisticated
Dynamic Smart Contract for permissioned Blockchains 9
programming skills in order to implement it correctly, and further maintain it.
In our case, we are focused on permissioned blockchain, particularly HF as one
of the main blockchain framework used by enterprises [31]. To the best of our
knowledge, none of the studies mentioned above does consider the dynamicity
of the SC based on the parameters of its functions (class methods), nor the
applicability of these SC design patterns on permissioned blockchain, e.g., HF.
Furthermore, our study measures in section 6 that there are issues of scalability
with satellite patterns in case there is a large number of transactions.
We propose a new way of managing SC in a dynamic way by providing a
prominent solution for permissioned blockchains.
5 Dynamic SC for permissioned blockchain based on
dynamic parameterization
5.1 Dynamic parameterization
We present an approach that allows defining SC, specific to a use case, that
will have a static code deployed on the blockchain, but it will run dynamically.
Mainly the dynamic part of these SC remains the parameters of their trans-
actions. We propose the usage of the blockchain technological features to store
data, which further enables the possibility to store “dynamic parameter” (Dyn-
Param2 ) into it. That is considered a variable or an asset following the HF
terminology. This variable leads on relying the SC code on that internal data
(i.e. constant) in order to have a dynamic behavior for the cases when in the
case when the DynParam is updated, in an SC that has immutable (static code).
Emphasizing that providing this DynParam as arguments of the SC transactions
is an external input (e.g., from the external API call, a.k.a. “Oracle” in the ETH
community).
5.2 State machine representation
In Figure 3 we show how DynParam is working for the two functionalities
Set and DoSmth that the SC has. Set corresponds to the ability to set (if
doesn’t exist) or update (if exist) the dynamic parameter that will be stored
in the blockchain. That variable can be of any type, even though it is usually
string or integer. And the DoSmth transaction can be of any purpose while it is
using this DynParam to adapt the behavior of the code according to its value.
Further, if the DynParam is not set/defined, the SC cannot run (cf. Locked
state). If DynParam is set, we can run the DoSmth functionality, which will
be one behavior (or let’s say state 1). If we update by setting another value
in DynParam, then the DoSmth transaction will change in consequence (i.e.
2
The dynamic parameter term presents a constant (which is static for the time being)
and it will change when a specific SC is called for updating its value, then globally
it turns to be dynamic for long-time point of view.
10 Adnan Imeri et al.
behavior/state 2, 3, ... N), still based on the same static code/logic. This solution
assumes that the DynParam is given by one authorized user from the outside of
the blockchain and checked by the transaction itself to accept or revoke it.
Moreover, for automation purposes, we can easily extend that solution by
substituting the user by an automated call of the SC to an external database
to getting back the new value for the DynParam while the user identity is still
known and allowed by the contract.
Fig. 3. State machine representation of the solution
5.3 Use case implementation
The enterprise based model is showed on Figure 4, and for the implementa-
tion is completed by using the Hyperledger Composer3 v0.20.4 over HF v1.4.1
This solution is accessible on GitHub [32]. On the left side of the model, there
are presented “On Chain” components of the model, while in the right part of
the model, there are presented components that supports blockchain solution.
For developing this model, three SC for performing the necessary functionalities
expressed in transactions, e.g., Collect (TX1), Set (TX2), and Notify (TX3).
The DynParam and Temperature are defined as assets and also Temperature-
Exceeded as an event to notify stakeholders when the temperature threshold is
exceeded. The Collect transaction serves to collect the last temperature value
from the sensor. Set is used to define and change the needed dynamic constants.
In our case, it is unique and named “Threshold Tabc”, which is hardcoded in
the Notify transaction code to avoid users the need to know the name of this pa-
rameter. The Notify transaction serves to check if the temperature is exceeded
the threshold (DynParam) defined by the Set transaction. In the case where
that happens, Notify will generate and send the TemperatureExceeded event to
alert the stakeholders allowed to read that event. Thus, Notify is illustrating
the usage of the dynamic constant through access to “Threshold Tabc”. So, an
update of the threshold does not require an update of the Notify thanks to the
Set transaction and the use of assets.
3
Composer is now deprecated but still usable, next tools getting the succession and
doing quite the same are named Convector & Hurley.
Dynamic Smart Contract for permissioned Blockchains 11
Fig. 4. The conceptual solution for the illustrated use case.
6 Evaluation and discussion
We evaluated our proposed solution by comparing it with the Satellite design
pattern proposed on [30] and previously presented in section 4. The satellite
pattern has three main transactions: the first one is used to update the address
referring to the satellite deployed, the second transaction serves to process and
calculate the value of the variable relaying to intermediate call of a satellite, and
the third one serves to use the calculated result stored in a variable in order to
adapt the contract behaviour by doing “something” indent by user, based on
that variable. So, each satellite is dedicated to do one single thing, which implies
that we need to deploy another satellite when the calculation has to change, but
we can still reused a old one if that calculation has already been defined and
deployed. Compare with satellite pattern, our approach uses two transactions:
the first one serves to update the internal variable whose the value is provided as
argument of the transaction, and the second one uses that value as intended by
user. In our approach we assume the calculation for any variable is performed
off-chain, as presented in 4.
The methodology is the following: 1) We implemented the satellite pattern
over ETH framework by using Truffle and Ganache tools; 2) We implemented
our solution using HF by using Convector and Hurley tools; 3) We executed both
scripts for testing both test-cases [32], in order to collect empirical data, and for
being able to compare both metrics. It worth noting that our scripts are running
sequentially, meaning that, it start new transaction only if the previous has been
12 Adnan Imeri et al.
completed. Also, to avoid distorting the results, we reinitialize the network after
each calculated point (i.e. a group of transactions). Moreover, time spent by the
setup and deployment of the network and contracts is not taken into account,
as global running time on metrics results, as we intend to evaluate the required
time for updating a constant/parameter.
The observed metrics are the number of the transaction resulting over the
blockchain. For each update of the variable, the time spent to process all trans-
actions, the total weight of all transactions gathered into blocks, and finally,
the number of blocks created. Our scripts process the following set of input
transaction4 : 2, 4, 8, 10, 20, 30, 40, 50, 100, 200, 500, 1000. Mainly the techni-
cal differences between both test-cases are: 1) observed networks (a local ETH
versus a local HF); 2) Blockchain settings regarding the blocks creation: ETH
builds a block each 15 seconds where its size is fixed to 1KB, whereas HF builds
a block each 2 seconds or if there are more than 10 transactions per block or if
the block size exceeds 99MB); 3) Benchmark scripts for test-cases (NodeJS for
ETH through Truffle against Bash for HF). The tests are performed by using
the same set of updating transactions, and we use the same processing power
environment: a 64bits GNU/Linux 4.15 Virtual Machine running Ubuntu 18.04.3
LTS, with 8GB of RAM and 3x 3.40GHz.
Fig. 5. Results comparing our solution against satellite pattern
4
Inputs are grouped by a set of N updates resulting to obtain one point for each set.
Here, the input set named “update” refers to the number of updates we want for the
internal variable, independently of the test-case implementation. In other terms, for
one update of the variable the effects are measured in the metrics, e.g., how many
real transactions are applied for one requested logical update.
Dynamic Smart Contract for permissioned Blockchains 13
The figure 5 is composed of four different graphs and shows the results of
this study. The x-axis of the graphs shows the number of updating transaction
batches. Reminding that for the satellite pattern for one input transaction leads
to three applied transactions (showed in orange colors in all graphs), whereas for
our solution that results in exactly two transactions (showed in blue color in all
graphs). The graph on B shows these evidences and in our quantify our solution
as more efficient. The graph in A shows the total time needed to execute both
solutions. The results from A, proof that ETH is around five-time slower than
HF. Next ascertainment, the graph on C shows the number of created blocks.
The two curves are superposed. There is a two factor between input and output
(i.e. one update leads to two created blocks). However there is a difference that
cannot be seen on the graph, HF is still using two blocks in addition to the double
inputs. This is due to the need for HF to create the variable before being able to
update it (where ETH needs to create the Satellite before using it). Moreover,
the number of the created block may vary in a real network where transactions
might be provided by peers in the meantime following a distributed way (against
the sequential way used here for test-cases). Finally, the graph on D exposed the
total blockchain weight resulting in comparison to the input sets. We can see
that ETH is eight times lighter than HF. This is due to the default block size
and the sequential execution of transactions. In fact, HF has in average blocks of
8KB and 1KB for ETH. And because of the sequentially processing, we do not
exploit the storage of several transactions in each block. One update for ETH
gives 2 blocks (with 1+2 transactions), on the other side, one update for HF
gives 2 blocks (with 1+1 transaction).
6.1 Discussions
This approach impacts directly the quality of the blockchain-based solution.
In this paper, we propose a solution that facilitates the maintenance tasks with
a focus on SC. Our approach is enabling the definition of dynamic parameters
stored as an asset (cf. HF) instead of being hard-coded in the SC logic, as any
classical constants/parameter. The use of assets allows updating the value of this
variables through a transaction without the need to upgrade the SC itself. For
the proposed approach, a proof of concept (PoC) is developed for supporting our
conceptual solution and providing access to this solution regarding our defined
use case.
The modeling part of this approach allows extending on other use cases, e.g.,
legal reasoning use case. Since the laws are subject to change, they might be
seen as obstructions for developing a sustainable blockchain-based solution. By
employing our approach, the “law articles” might be saved on the assets and
they might be change-over-time without disturbing the entire system.
Regarding the security, this exposed set transaction causing changes must be
restricted to some of the stakeholders who are responsible for maintaining the
system. For the case of permission blockchain, e.g., HF, the stakeholder must be
an authenticated and authorized user. In the case of a public blockchain, e.g.,
14 Adnan Imeri et al.
ETH, this transaction must be restricted to the owner of the SC or a specific
list of the authorized users hard-coded in the contract.
For future works, we intend to extend the current approach and investigate
the possibility of implementing our solution in different blockchain frameworks
i.e., Quorum [33] and Corda [34].
References
1. Satoshi Nakamoto. Bitcoin - A Peer-to-Peer Electronic Cash System,2008. URL:
https://bitcoin.org/bitcoin.pdf
2. Blockchain Survey: Blockchain gets down to business,
https://www2.deloitte.com/content/dam/insights/us/articles/2019-global-
blockchain-survey/DI 2019-global-blockchain-survey.pdf, Retrieved 18 October
2019
3. Golosova, J., Romanovs, A.: The Advantages and Disadvantages of the Blockchain
Technology. In the 6th Workshop on Advances in Information, Electronic and Elec-
trical Engineering (AIEEE), IEEE, pp.1-6, (2018)
4. Vitalik Buterin. A next generation smart contract and decentralized ap-
plication platform, http://blockchainlab.com/pdf/Ethereum white paper-
a next generation smart contract and decentralized application platform-vitalik-
buterin.pdf. 2016. Retrieved 19 October 2019
5. Nick Szabo. Smart Contract, http://www.fon.hum.uva.nl/rob/Courses/ Infor-
mationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/
smart contracts 2.html. (1996). Retrieved 19 October 2019
6. Hyperledger - URL: https://www.hyperledger.org/. Retrieved 19 October 2019
7. Mendling, J., Weber, I., Aalst, W.V.D., Brocke, J.V., Cabanillas, C., Daniel, F.,
Debois, S., Ciccio, C.D., Dumas, M., Dustdar, S. and Gal, A.: Blockchains for
business process management-challenges and opportunities. ACM Transactions on
Management Information Systems (TMIS), (2018)
8. Alharby, M., van Moorsel, A.: Blockchain-based smart contracts: A systematic
mapping study. arXiv preprint arXiv:1710.06372. (2017)
9. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of
Reusable Object-Oriented Software Addison-Wesley. Reading, MA, (1995)
10. What is a merkle tree? beginner’s guide to this blockchain component,
https://blockonomi.com/merkle-tree/. Retrieved 19 October 2019
11. Zheng, Z., Xie, S., Dai, H. N., Chen, X., Wang, H.: Blockchain challenges and
opportunities: A survey. International Journal of Web and Grid Services, 14(4),
pp.352-375. (2018)
12. Tasca, P., Tessone, C. J.: Taxonomy of blockchain technologies. Principles of iden-
tification and classification. arXiv preprint arXiv:1708.04872.(2017)
13. Xu, X., Weber, I., Staples, M., Zhu, L., Bosch, J., Bass, L., Pautasso, C. and Rimba,
P.: A taxonomy of blockchain-based systems for architecture design. In IEEE In-
ternational Conference on Software Architecture (ICSA). pp. 243-252. (2017)
14. Antonopoulos, A. M.: Mastering Bitcoin: Programming the open blockchain. ”
O’Reilly Media, Inc.” (2017)
15. Xu, X., Pautasso, C., Zhu, L., Gramoli, V., Ponomarev, A., Tran, A. B., Chen,
S.: The blockchain as a software connector. In 2016 13th Working IEEE/IFIP
Conference on Software Architecture (WICSA). pp. 182-191. (2016)
Dynamic Smart Contract for permissioned Blockchains 15
16. Solidity — Solidity 0.5.12 documentation, https://solidity.readthedocs.io/en/v0.5.12/.
Retrieved 21 October 2019
17. Kolluri, A., Nikolic, I., Sergey, I., Hobor, A., Saxena, P.: Exploiting the laws of
order in smart contracts. In Proceedings of the 28th ACM SIGSOFT International
Symposium on Software Testing and Analysis. pp. 363-373. ACM. (2019)
18. Mik, E.: Smart contracts: terminology, technical limitations and real world com-
plexity. Law, Innovation and Technology, 9(2), pp.269-300. (2017)
19. Home — Ethereum, https://ethereum.org/. Retrieved 21 October 2019
20. Luu, L., Chu, D. H., Olickel, H., Saxena, P., Hobor, A.: Making smart contracts
smarter. In Proceedings of the 2016 ACM SIGSAC conference on computer and
communications security (pp. 254-269).(2016)
21. (2019). Buildmedia.readthedocs.org, https://buildmedia.readthedocs.org/media/pdf/hyperledger-
fabric/latest/hyperledger-fabric.pdf. Retrieved 21 October 2019
22. Introduction to Hyperledger Fabric, https://hyperledger-fabric.readthedocs.io
/en/latest/blockchain.html.Retrieved 21 October 2019
23. Docker - Website. URL: https://www.docker.com/.Retrieved 19 October 2019
24. Imeri, A., Khadraoui, A., Khadraoui, D.: A Conceptual and Technical Approach for
Transportation of Dangerous Goods in Compliance with Regulatory Framework.
12(9), (pp.708-721). Journal of Software (JWS). (2017)
25. Wohrer, M., Zdun, U.: Smart contracts: security patterns in the ethereum ecosys-
tem and solidity. In 2018 International Workshop on Blockchain Oriented Software
Engineering (IWBOSE) (pp. 2-8).(2018)
26. Liu, Y., Lu, Q., Xu, X., Zhu, L., Yao, H.: Applying design patterns in smart
contracts. In International Conference on Blockchain (pp. 92-106).Springer, Cham.
(2018)
27. Alharby, M., van Moorsel, A.: Blockchain-based smart contracts: A systematic
mapping study. arXiv preprint arXiv:1710.06372.(2017)
28. Frantz, C. K., Nowostawski, M.: From institutions to code: Towards automated
generation of smart contracts. In 2016 IEEE 1st International Workshops on Foun-
dations and Applications of Self* Systems (FAS* W) (pp. 210-215). (2016)
29. Michiel Mulders: Smart contract safety: Best practices and design patterns,
https://www.sitepoint.com/smart-contract-safety-best-practicesdesign-patterns/,
Retrieved 19 October 2019
30. Wöhrer, M., Zdun, U.: Design patterns for smart contracts in the ecosystem. In
2018 IEEE International Conference on Internet of Things (iThings) and IEEE
Green Computing and Communications (GreenCom) and IEEE Cyber, Physical
and Social Computing (CPSCom) and IEEE Smart Data (SmartData) (pp. 1513-
1520). (2018)
31. Top Blockchain Platforms of 2019 for Blockchain Application:
https://www.leewayhertz.com/blockchain-platforms-for-top-blockchain-
companies/. Retrieved 22 October 2019
32. Gr4pha/hyperledger-dynamic-smart-contract.. GitHub.: from
https://github.com/Gr4pha/hyperledger-dynamic-smart-contract. Retrieved
22 October 2019
33. Quorum - jpmorganchase/quorum: A permissioned implementation of supporting
data privacy. https://github.com/jpmorganchase/ quorum. Retrieved 22 October
2019
34. Corda: An open source blockchain platform for businesses https:
//www.corda.net/. Retrieved 22 October 2019
35. Clearmatics/smart-contract-upgrade, https://github.com/clearmatics/smart-
contract-upgrade. Retrieved 25 October