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, di erent challenges 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 speci c to the use case.
Since the invention, blockchain technology has been the subject of
exploration from academics and industries. The technology that stands behind
Bitcoin initially was the focus of cryptocurrency industries [
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 de nes 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 evaluation of the solution is presented in section 6 along with discussion and future works.
Blockchain is a decentralized-distributed append-only database that enables
storing of the immutable set of transactions, organized in a hash tree
(MerkleTree) [
Blockchain network: The blockchain network is an extensive set of devices
that communicate in a peer-to-peer mode (P2P). The nodes are
computersservers that are geographically distributed, and they contain the same copy of
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 [
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 [
Immutability: The transactions added on the blockchain are
cryptographically 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
current changed block with other blocks from other nodes that contain the same
blockchain [
Non-repudiation: The properties of immutability and data integrity, enforces
the properties of non-repudiation [
Availability: The blockchain network maintains the availability, even if some
nodes fails to response [
On-Chain vs O -Chain: The design properties of the blockchain allows
storing a limited amount of data on chain. These data are the most signi cant
information, transaction and meta-data (hash values) referenced from large les
that are stored o -chain [
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
contrary, for accessing permissioned blockchain, nodes are required to have
permission by the administrator of the blockchain network [
Smart Contract (SC): is a stand-alone program that is executed when
certain conditions are ful lled. It might execute asset transfers, execute another
contract, ful ll the conditions from any business process [
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 [
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 [
Entities: Consortium and Organization. HF de nes di erent entities
regarding the participants involved in the project. The HF network is managed by
a group of organizations gathered into a consortium. Each organization should
manage its nodes and should have at least one Certi cation Authority (CA)
node, and one Orderer node [
Nodes, Peer, Orderer, CA and Client. HF de nes 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 di erent SC over each channel1.
Orderer nodes ensure the consensus of the HF blockchain network and keep
the peer's ledgers consistent [
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 [
Amongst the main SC main concepts that are necessary for any kind of
application on HF:
{ Participant refers to a user that is de ned in the SC. For handling di erent
users in our application, we extend the \Participant" type [
Events are broadcasted on channels and can be caught by an external
application that has access rights to listen to the desired channel [
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. 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 recon gure 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 di cult to recon gure 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.
Cross-references: From the enterprise modeling perspective, involving several SC and cross communication to perform high-level tasks, still, exposes the same problems. Figure 2, shows the issues of logic ows 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.
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 speci c threshold, a set of
users should be noti ed based on the pre-de ned condition in a particular use
case, e.g., transporting dangerous goods, that is sensitive to a temperature degree
[
Detailing the features of this SC, it has three core functionalities. The rst 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 de ne 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.
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 managing 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.
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" [
We propose a new way of managing SC in a dynamic way by providing a prominent solution for permissioned blockchains.
We present an approach that allows de ning SC, speci c 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 transactions. We propose the usage of the blockchain technological features to store data, which further enables the possibility to store \dynamic parameter" (DynParam2) 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).
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/de ned, 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 speci c SC is called for updating its value, then globally it turns to be dynamic for long-time point of view. 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.
The enterprise based model is showed on Figure 4, and for the
implementation is completed by using the Hyperledger Composer3 v0.20.4 over HF v1.4.1
This solution is accessible on GitHub [
We evaluated our proposed solution by comparing it with the Satellite design
pattern proposed on [
The methodology is the following: 1) We implemented the satellite pattern
over ETH framework by using Tru e 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 [
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 transactions, the total weight of all transactions gathered into blocks, and nally, 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 technical di erences 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 xed 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 Tru e 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. 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 e ects are measured in the metrics, e.g., how many real transactions are applied for one requested logical update.
The gure 5 is composed of four di erent 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 e cient. The graph in A shows the total time needed to execute both solutions. The results from A, proof that ETH is around ve-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 di erence 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).
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 de nition 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 de ned 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.,
ETH, this transaction must be restricted to the owner of the SC or a speci c 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 di erent blockchain frameworks
i.e., Quorum [