=Paper=
{{Paper
|id=Vol-2646/23-paper
|storemode=property
|title=Towards Reusable Smart Contracts for Trustworthy Collaborative Processes
|pdfUrl=https://ceur-ws.org/Vol-2646/23-paper.pdf
|volume=Vol-2646
|authors=Ada Bagozi,Devis Bianchini,Valeria De Antonellis,Massimiliano Garda,Michele Melchiori
|dblpUrl=https://dblp.org/rec/conf/sebd/BagoziBAGM20
}}
==Towards Reusable Smart Contracts for Trustworthy Collaborative Processes==
https://ceur-ws.org/Vol-2646/23-paper.pdf
Towards Reusable Smart Contracts for
Trustworthy Collaborative Processes
(Discussion Paper)
Ada Bagozi1 , Devis Bianchini1 , Valeria De Antonellis1 , Massimiliano Garda1 ,
and Michele Melchiori1
University of Brescia, Dept. of Information Engineering
Via Branze 38, 25123 - Brescia (Italy)
a.bagozi@unibs.it, devis.bianchini@unibs.it,
valeria.deantonellis@unibs.it, m.garda001@unibs.it,
michele.melchiori@unibs.it
Abstract. In collaborative environments, where enterprises interact each
other’s without a centralised authority that ensures trust among them,
the ability of providing cross-organisational services must be enabled
also between mutually untrusting participants. Blockchain platforms and
smart contracts have been proposed to implement trustworthy collabo-
rative processes. However, current solutions are constrained to a spe-
cific blockchain technology and deployed on-chain the whole process,
thus increasing the execution costs of smart contracts on permissionless
blockchains. In this paper, we propose an approach that includes criteria
to identify trust-demanding objects and activities in collaborative pro-
cesses, a model to describe smart contracts in a technology-independent
way and guidelines to deploy them on a blockchain. To this aim, a three-
layered model is used to describe: (i) the collaborative process, repre-
sented in BPMN, where the business expert is supported to add annota-
tions that identify trust-demanding objects and activities; (ii) Abstract
Smart Contracts, based on trust-demanding objects and activities only
and independent from any blockchain technology; (iii) Concrete Smart
Contracts, that implement abstract ones and are deployed over a spe-
cific blockchain. Flexibility and cost reduction brought by approach are
discussed in the context of a case study on remote monitoring services
for the digital factory.
Keywords: blockchain, smart contract, collaborative processes
1 Introduction
In collaborative environments enterprises provide cross-organisational services to
deliver integrated offerings of products and services, ensuring additional value
Copyright c 2020 for this paper by its authors. Use permitted under Creative Com-
mons License Attribution 4.0 International (CC BY 4.0). This volume is published
and copyrighted by its editors. SEBD 2020, June 21-24, 2020, Villasimius, Italy.
also between mutually untrusting organisations. A real-world example is given
by anomaly detection services for remote monitoring of Cyber Physical Systems
in the digital factory. The Original Equipment Manufacturer (OEM) supplies the
anomaly detection service, based on data streams collected from the machines
of clients. In case anomalies have been identified before breakage events occur,
the clients may be notified to avoid expensive repair operations, as well as costly
down-times. Furthermore, insurance agencies may offer additional services to the
OEM in order to limit the costs of maintenance operations under warranty, and
external suppliers may know in advance scheduled maintenance interventions
to prepare required spare parts. In this scenario, collected sensor data, used
for monitoring and providing advanced services, must be immutable and not
repudiated by clients and the implementation of anomaly detection services must
be transparently shared among all participants involved in the process.
1.1 Related Work
Blockchain platforms and smart contracts have been proposed to implement
collaborative processes [1, 4, 5]. In a recent research, the Caterpillar system [5]
introduces an abstraction layer over the Ethereum blockchain [7] in order to
support the execution of collaborative processes, represented in BPMN. Note-
worthy, a process in Caterpillar is fully executed on the blockchain, coded as
smart contracts, and all the states of the process instance are recorded on-chain.
Moreover, the proposed solution is technology-dependent. In [3] the focus is on
the benefits from the introduction of blockchain and smart contracts for the
supply chain. However, the explanation about how smart contracts have been
deployed is reported in a coarse-grained manner. Recent efforts also focused on
the importance of conceptual modelling to demonstrate how business artefacts
leverage the data-centric nature of blockchain [4] and to provide a user-centric
framework to design rules deployed in smart contracts [1].
Main limitations in the current approaches are that they are technology-
dependent and focus on the implementation of collaborative processes as a mono-
lithic solution, where the whole process is deployed on-chain. This increases the
execution costs on the blockchain and reduces the reuse of designed smart con-
tracts.
1.2 Paper contribution
In [2] we proposed an approach to identify trust-demanding objects and activities
in collaborative processes, a model to describe smart contracts in a technology-
independent way and guidelines to deploy them in a blockchain. To this aim,
a three-layered model is used to describe: (i) the collaborative process, repre-
sented using BPMN, where the business expert is supported to add annotations
that identify trust-demanding objects and activities; (ii) Abstract Smart Con-
tracts based on trust-demanding objects and activities only and independent
from any blockchain technology; (iii) Concrete Smart Contracts, that implement
abstract ones and are deployed over a specific blockchain, enabling the creation
of a repository where a single abstract contract is associated with multiple im-
plementations. The introduction of Abstract Smart Contracts also increases the
Annotated Collaborative Process
Insurance Agency
Anomaly Receive Refund Accept/Refuse
[Read] Request Refund Request
Summarised Data Refund Request
Anomaly Detection Service [Read] [Update]
{
{ “isTrustDemanding”: True } “isTrustDemanding”: True,
Summarised Data
“isDataIntensive”: True
[Create] }
Summarise and Identify Refund Request
identify relevant warning/error [Create]
{ data events
“isTrustDemanding”: False,
“isDataIntensive”: True {
} “isTrustDemanding”: True,
Collected Data Anomaly “isDataIntensive”: False
}
[Create] [Create]
OEM
Yes Create Receive
Maintenance Division
Refund Insurance
Request decision
Setup components to Receive anomaly Calculate Fees and Receive Schedule
be monitored, feature Collect Data Create Maintenance Can a request of
detection events Client Maintenance
spaces, features limits Incrementally Intervention proposal refund be issued?
decision Intervention
Maintenance
Maintenance No Maintenance
Setup Data Setup Data Intervention Proposal Intervention Proposal Intervention Proposal
[Create] [Read] [Create] [Read] [Update]
Yes Accept
Setup Data
[Udate] Intervention
Yes Accept setup
data
Receive Receive Maintenance
Client
Accept/Refuse? Accept/Refuse?
setup data Intervention proposal Maintenance
Refuse setup Intervention Proposal
No data [Update]
Anomaly Summarised Data Refuse Intervention
Setup Data [Read] [Read] No and motivate
[Udate]
Abstract Smart Contracts
Legend
ASC 1 ASC 2 … ASC N Input
Output
A Activity
Concrete Smart Contracts
ASC Abstract Smart Contract
CSC Concrete Smart Contract
CSC 1 CSC 2 …
CSC N … Annotation
CSC 3
Fig. 1. Three-layered approach overview. On the top level, is reported the BPMN of
the remote monitoring services case study (only a subset of annotations is reported
here).
flexibility of the approach, providing a repository of reusable software compo-
nents. Furthermore, only trust-demanding activities are considered to be de-
ployed on-chain, thus saving costs and increasing process performances.
In the following, Section 2 introduces the three-layered approach; the ap-
proach architecture will be presented in Section 3; preliminary experiments will
be described in Section 4; finally, Section 5 closes the paper.
2 Three-layered approach overview
Figure 1 shows the three-layered approach proposed in this paper. Specifically,
a collaborative process for Remote Monitoring Services (RMS) in the digital
factory is presented. Participants of the process are the OEM, one of its clients
and the insurance agency, corresponding to three different BPMN pools. The
OEM pool has been further organised in two sub-partitions, Maintenance Divi-
sion lane and Anomaly Detection Service lane. In our model, we do not consider
trust issues between participants associated with lanes within the same pool.
Annotated collaborative process layer. At the top layer, BPMN annota-
tions are used in order to highlight trust-demanding objects and trust-demanding
activities. The former ones are associated to data objects (e.g., activities in-
puts/outputs), that are shared across different participants, and therefore trans-
actions (i.e. Create, Read, Update, Delete actions) performed on these objects
should be immutable and not repudiated by any participant. In our approach,
trust-demanding objects are candidates to be permanently stored within a block-
chain. Trust-demanding activities correspond to automated activities whose busi-
ness logic must be non-repudiated and transparently shared among all the par-
ticipants of the process. In our approach, they represent the candidates to be
deployed as smart contracts within a blockchain.
Abstract Smart Contracts layer. In the middle layer, annotations are used
to generated Abstract Smart Contracts (ASC). An ASC is described by: (i) a
name; (ii) a set of state variables, that can be either primitive data types or
objects, on which contract functions operate; (iii) a set of participants (i.e.,
users registered on the blockchain or other contracts) that are allowed to inter-
act with the ASC by invoking its functions; (iv) a set of functions expressed as
f unctionN ame(INf ) : OU Tf , where INf and OU Tf are the inputs and outputs
of the function. Among ASC participants, also the BPMN engine is considered,
since it is in charge of invoking activities implemented as smart contracts. An
ASC is generated for each BPMN activity annotated as trust-demanding. In
this case: (i) the ASC name is obtained from the activity name; (ii) the set of
ASC variables contains the activity inputs/outputs definitions; (iii) the set of
ASC participants contains the participant of the activity and the BPMN engine;
(iv) the function represents the activity, its name corresponds to the activity
name, its inputs (resp., outputs) correspond to the activity inputs (resp., out-
puts). An ASC is generated also for each trust-demanding object as follows:
(i) the ASC name is obtained from the object name; (ii) the set of ASC vari-
ables contains the object definition; (iii) the set of ASC participants contains the
participant of the activity that reads the object and the BPMN engine; (iv) func-
tions are generated according to the CRUD actions on the object. Among trust-
demanding objects we distinguish those characterised by high volume and acqui-
sition speed, denoted as data-intensive. Transactions on such objects, if stored
within a blockchain, may require increased costs. In order to strike a trade-off be-
tween costs and tamper-proofness, the full data intensive object is kept off-chain,
on top of an external Distributed File System (DFS) such as the InterPlanetary
File System (IPFS), while a link to it is stored on-chain. An example of ASC is
given by the trust-demanding activity Identify Warning/Error Events in Fig-
ure 1, where: (i) name = “Identif yW arningErrorEventsSC”; (ii) variables =
{summarisedDataHash, Anomaly}; (iii) participants = {AnomalyDetection−
Service, BP M N engine}; (iv) f unction = {identif yW arningErrorEvents−
F unc([summarisedDataHash]) : [Anomaly]}. The summarisedDataHash input
is a hash code pointing to an external DFS on which summarised data is saved.
Other ASC examples are given in [2].
https://ipfs.io
Concrete Smart Contracts Layer. At the lower layer, ASC are deployed as
Concrete Smart Contracts (CSC) over a specific blockchain. The development of
CSC starting from ASC is in charge of the developer, who has the skills to deploy
CSC over a specific blockchain. The developer provides the necessary code in or-
der to implement the CSC functions. A single ASC descriptor may be associated
with multiple CSC implementations, developed for different blockchain technolo-
gies. Moreover, it separates the role of business experts, who are in charge of
designing the collaborative process and being supported during the identifica-
tion of trust-demanding objects and activities, and the role of developers, who
possess development skills for the specific blockchain technology on which CSC
will be deployed.
Example. In the multi-party collaborative process of Figure 1, proper smart
contracts have been identified.
Monitoring Setup Smart Contracts (MS). Setup data is created by the Main-
tenance Division and read by the client, who is also in charge of accepting or
declining by modifying the Setup Data object, that therefore is identified as
trust-demanding. Therefore, an ASC is generated for the Setup Data trust-
demanding object and all activities (associated with the Maintenance Division or
the Client) that create or modify such objects are recognised as trust-demanding,
bringing to the generation of corresponding ASC.
Anomaly Detection Smart Contracts (AD). Anomaly Detection Service is in
charge of summarising the collection of Collected Data objects and applying
relevance evaluation in order to identify relevant data only, generating a collec-
tion of Summarised Data objects. Both Collected Data and Summarised Data
objects are generated at high volumes, and for this reason can be considered as
data-intensive. Summarised Data is then used by the Anomaly Detection Service
to identify warning or error events, generating an Anomaly object. Considering
that Summarised Data and Anomaly objects are read by the Client and by the
Insurance Agency, both are recognised as trust-demanding. Therefore, two ASC
are generated, one for Summarised Data object and one for Anomaly object.
Moreover, all activities that create or modify such objects are recognised as
trust-demanding, bringing to the generation of corresponding ASC.
Maintenance Intervention Preparation Smart Contract (MIP). The Main-
tenance Intervention Proposal object is created by the Maintenance Divi-
sion and modified by the Client to accept/decline it. Therefore, it is identified as
trust-demanding. The same considerations hold for Refund Request object. All
activities that create and modify these objects are denoted as trust-demanding.
3 Approach Architecture
The approach architecture is shown in Figure 2. At the bottom the architec-
ture includes the real blockchain, on which CSC are deployed. For example, on
an Ethereum network, all deployed CSC can be replicated on each client node,
which hosts an Ethereum Virtual Machine (EVM). A Log Repository is used to
store the results of every CSC execution in order to implement a communication
BPMN Modelling and Smart Contract
Business Annotation Module Blockchain Developer IDE
Modeller Developer
Web Portal
Trust-demanding
BPMN Engine CSC Code Template Deployment Module
objects and activities ASC Generator
Generator
detector
BPMN repository ASC Repository CSC Repository
Off-Chain
Smart
Contracts
IPFS repository
Log
Repository
Blockchain
Decentralized Storage On-Chain
Fig. 2. Approach architecture.
channel from the smart contracts on the blockchain and external services of the
collaborative process. In fact, smart contracts have no way to call external ser-
vices. However, contracts can write information on a log space that is visible to
external applications. A distributed storage (e.g., the above mentioned IPFS) is
also considered in order to store data-intensive information without impacting
on the blockchain costs.
Off-chain modules in figure implement the identification of trust-demanding
objects and activities, ASC and CSC code templates generation and deployment.
The BPMN is stored within the BPMN repository. The ASC Generator extracts
ASC descriptors and stores them into the ASC Repository. The CSC Code Tem-
plate Generator is in charge of generating templates, after choosing a specific
blockchain platform. Templates are provided to the developer who completes
them with code insertion. Developed CSC are stored within a CSC Repository
and deployed on the blockchain by the Deployment Module. ASC/CSC reposito-
ries will contribute to increase the reuse of generated contracts. The middle layer
also includes the BPMN Engine, that has to execute the collaborative process
and must be able to invoke some activities as CSC deployed on the blockchain.
Finally, the architecture comprises a set of Web components, provided to the
business modeller and the developer for editing BPMN processes, confirming
or discarding suggested annotations, and editing CSC starting from the gener-
ated code templates, respectively. These, components use functionalities made
available by other modules at the middle layer through RESTful APIs.
4 Preliminary Experiments
Our approach has been validated in the context of Remote Monitoring Services
in the digital factory described in Section 2 and using Ethereum permissionless
blockchain. However, our approach is technology-independent, and can be im-
plemented also as a permissioned blockchain [6]. Indeed, future experiments will
be focused on comparing different concrete implementations of the blockchains.
Here we validated permissionless blockchain, considering that it takes more time
Fig. 3. Gas value required to execute all the functions of the smart contracts generated
for each service in the considered case study.
to write and confirm transactions and the execution of a smart contract and the
validation of a new transaction are performed by nodes that are rewarded with
a fee paid by the node that initiates the transaction. Since, to the best of our
knowledge, there are no collaborative processes datasets to compare our imple-
mentation with similar efforts, we performed here a cost analysis, in order to
evaluate the economic effort in using a permissionless blockchain. In Ethereum-
based blockchains, the cost is expressed in gas, which is a value established for
every basic operation invoked from within the smart contract. Then, the fee paid
for a transaction is expressed as the product between the gas used to process
the transaction and the gas price, which is the amount that the node initiating
the transaction is willing to pay for each gas unit.
Figure 3(a) illustrates the average time (in seconds) to confirm the transac-
tion for each smart contract by varying the gas price, relying on the simulator
provided by ETH Gas Station. As expected, the more gas price a user is willing
to offer, the faster the transaction will be added to the blockchain. Figure 3(b)
reports the cost per transaction required to execute each of the smart contracts
implemented for the Remote Monitoring Services case study, using an Ethereum
simulator. Generally, reducing the cost of the collaborative process deployment
on a permissionless blockchain can be obtained by decreasing the performances
of smart contract execution or limiting the elements that are deployed on the
blockchain to trust-demanding objects and activity only. Indeed, our approach
reduces the execution costs on the blockchain thanks to the deployment of a
limited set of BPMN elements, only if necessary. In fact, only trust-demanding
objects and activities will be converted in smart contracts to be deployed on
the blockchain. According to the cost analysis learned by the application of our
approach to the Remote Monitoring case study, as shown in Figure 3(a), from
a certain amount of gas price (4.5 Gwei ) the average confirmation time remains
quite the same. Assuming that the participants have access to IPFS nodes, there
is no extra cost, in terms of gas, associated with storing data-intensive objects.
However, for the same application scenarios such as the anomaly detection one
considered in the case study, promptness in identifying warning/error events is an
https://ethgasstation.info/calculatorTxV.php (accessed: July 2019)
testrpc: https://github.com/trufflesuite/ganache-cli
important feature of the supplied services. Therefore, this issue can be addressed
by limiting the number of elements to be deployed on-chain. The proposed ap-
proach described in this paper is to meet these requirements by excluding non
trust-demanding objects and activities.
5 Concluding Remarks
In this paper, we proposed a three-layered model to describe: (i) the collaborative
process, represented in BPMN, where the business expert is supported to add
annotations that denote trust-demanding objects and activities; (ii) Abstract
Smart Contracts, based on trust-demanding objects and activities only and in-
dependent from any blockchain technology; (iii) Concrete Smart Contracts, that
implement abstract ones and are deployed over a specific blockchain technology.
The introduction of Abstract Smart Contracts increases the flexibility of the
approach, providing a repository of reusable software components. Furthermore,
only trust-demanding activities are considered to be deployed on-chain, thus
saving costs and increasing process performances. Future efforts will be focused
on the ASC/CSC repository. In particular, advanced matchmaking techniques
(e.g. adapting Semantic Web technologies to smart contracts) will be studied to
reuse existing ASC at design time or to reconciliate similar ASC. Furthemore,
at runtime similar techniques will be investigated to select the proper CSC for a
given ASC, depending on the cost policies implemented in different blockchains.
References
1. Astigarraga, T., Chen, X., Chen, Y., Gu, J., Hull, R., Jiao, L., Li, Y., Novotny,
P.: Empowering business-level blockchain users with a rules framework for smart
contracts. In: Int. Conf. on Service Oriented Computing (ICSOC 2018). pp. 111–
128. Hangzhou, China (2018)
2. Bagozi, A., Bianchini, D., De Antonellis, V., Garda, M., Melchiori, M.: A three-
layered approach for designing smart contracts in collaborative processes. In: 27th
Int. Conf. on Cooperative Information Systems (CoopIS 2019). pp. 440–457. Rhodes,
Greece (2019)
3. Casado-Vara, R., Prieto, J., De la Prieta, F., Corchado, J.M.: How blockchain im-
proves the supply chain: case study alimentary supply chain. Procedia Computer
Science 134, pp. 393–398 (2018)
4. Hull, R., Batra, V., Chee, Y., Deutsch, A., Health, F., Vianu, V.: Towards a shared
ledger business collaboration language based on data-aware processes. In: Int. Conf.
on Service Oriented Computing (ICSOC 2016). pp. 18–36. Banff, Canada (2016)
5. López-Pintado, O., Garcı́a-Bañuelos, L., Dumas, M., Weber, I., Ponomarev, A.:
Caterpillar: A business process execution engine on the ethereum blockchain. Soft-
ware: Practice and Experience 49(7), pp. 1162–1193 (2019)
6. Staderini, M., Schiavone, E., Bondavalli, A.: A requirements-driven methodology for
the proper selection and configuration of blockchains. In: IEEE 37th Symposium on
Reliable Distributed Systems (SRDS 2018). pp. 201–206. Salvador, Bahia, Brazil
(2018)
7. Wood, G.: Ethereum: A secure decentralised generalised transaction ledger.
Ethereum project yellow paper 151, pp. 1–32 (2014)