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 collaborative processes. However, current solutions are constrained to a speci c 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 processes, a model to describe smart contracts in a technology-independent way and guidelines to deploy them on a blockchain. To this aim, a threelayered model is used to describe: (i) the collaborative process, represented in BPMN, where the business expert is supported to add annotations 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 speci c 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.
In collaborative environments enterprises provide cross-organisational services to deliver integrated o erings of products and services, ensuring additional value Copyright c 2020 for this paper by its authors. Use permitted under Creative Commons 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 identi ed before breakage events occur, the clients may be noti ed to avoid expensive repair operations, as well as costly down-times. Furthermore, insurance agencies may o er 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
Blockchain platforms and smart contracts have been proposed to implement
collaborative processes [
Main limitations in the current approaches are that they are technologydependent and focus on the implementation of collaborative processes as a monolithic solution, where the whole process is deployed on-chain. This increases the execution costs on the blockchain and reduces the reuse of designed smart contracts. 1.2
In [
yecng A cean r sun I no i s i v i D ceaenn t n i a M ec i v r e S no it c tee {
lya } m no M A E O {“isTrustDemanding”:True} Summarised Data [Create] Summarise and identify relevant data Col ected Data [Create] Identify warning/error events Anomaly [Create] } { } { “isTrustDemanding”:True, “isDataIntensive”:True “isTrustDemanding”:True, “isDataIntensive”:False ilten seRteucpedivaeta C
Setup components to be monitored, feature spaces, features limits Setup Data [Create]
Col ect Data Incremental y Setup Data [Read]
Receive anomaly detection events
Calculate Fees and Create Maintenance Intervention proposal
Receive Client decision
Maintenance Intervention Proposal [Create]
Maintenance Intervention Proposal
[Read]
Setup Data Yes Accept setup [Udate]
data
Accept/Refuse? No
Refuse setup data
Setup Data [Udate]
Receive Maintenance Intervention proposal Anomaly Summarised Data [Read] [Read]
Refuse Intervention No and motivate Yes
Accept
Intervention Accept/Refuse? Maintenance
Intervention Proposal
[Update] ASC 1
ASC 2 …
ASC N Anomaly [Read] Summarised Data [Read]
Receive Refund
Request
Accept/Refuse Refund Request
Refund Request
[Update] Refund Request [Create]
Yes Create
Refund
Request Can a request of refund be issued? No
Receive Insurance decision
Schedule Maintenance Intervention
Maintenance Intervention Proposal [Update]
Legend Input
Output A Activity ASC Abstract Smart Contract CSC Concrete Smart Contract … Annotation CSC 1
CSC 2
CSC 3 …
CSC N 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 inputs/outputs), that are shared across di erent participants, and therefore transactions (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 blockchain. Trust-demanding activities correspond to automated activities whose business logic must be non-repudiated and transparently shared among all the participants 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
interact 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 de nitions; (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.,
outputs). 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
variables contains the object de nition; (iii) the set of ASC participants contains the
participant of the activity that reads the object and the BPMN engine; (iv)
functions are generated according to the CRUD actions on the object. Among
trustdemanding objects we distinguish those characterised by high volume and
acquisition speed, denoted as data-intensive. Transactions on such objects, if stored
within a blockchain, may require increased costs. In order to strike a trade-o
between costs and tamper-proofness, the full data intensive object is kept o -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
Figure 1, where: (i) name = \Identif yW arningErrorEventsSC"; (ii) variables =
fsummarisedDataHash; Anomalyg; (iii) participants = fAnomalyDetection
Service; BP M N engineg; (iv) f unction = fidentif yW arningErrorEvents
F unc([summarisedDataHash]) : [Anomaly]g. The summarisedDataHash input
is a hash code pointing to an external DFS on which summarised data is saved.
Other ASC examples are given in [
https://ipfs.io Concrete Smart Contracts Layer. At the lower layer, ASC are deployed as Concrete Smart Contracts (CSC) over a speci c blockchain. The development of CSC starting from ASC is in charge of the developer, who has the skills to deploy CSC over a speci c blockchain. The developer provides the necessary code in order to implement the CSC functions. A single ASC descriptor may be associated with multiple CSC implementations, developed for di erent blockchain technologies. Moreover, it separates the role of business experts, who are in charge of designing the collaborative process and being supported during the identi cation of trust-demanding objects and activities, and the role of developers, who possess development skills for the speci c blockchain technology on which CSC will be deployed.
Example. In the multi-party collaborative process of Figure 1, proper smart contracts have been identi ed.
Monitoring Setup Smart Contracts (MS). Setup data is created by the Maintenance Division and read by the client, who is also in charge of accepting or declining by modifying the Setup Data object, that therefore is identi ed as trust-demanding. Therefore, an ASC is generated for the Setup Data trustdemanding 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 collection 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 Maintenance Intervention Proposal object is created by the Maintenance Division and modi ed by the Client to accept/decline it. Therefore, it is identi ed 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 architecture 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 Business BAPnMnNotaMtioodneMlinogdualned Model er Trust-demanding objects and activities detector
ASC Generator
CSC GCeondeeraTetomrplate
Deployment Module BPMN repository
ASC Repository
CSC Repository
Smart Contracts Blockchain
Log Repository Web Portal
BPMN Engine Off-Chain
IPFS repository Decentralized Storage
On-Chain 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 services. 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.
O -chain modules in gure implement the identi cation 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 Template Generator is in charge of generating templates, after choosing a speci c 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 repositories 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, con rming or discarding suggested annotations, and editing CSC starting from the generated 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
implemented also as a permissioned blockchain [
Figure 3(a) illustrates the average time (in seconds) to con rm the transaction 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 o er, 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 con rmation 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 approach 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 independent from any blockchain technology; (iii) Concrete Smart Contracts, that implement abstract ones and are deployed over a speci c blockchain technology. The introduction of Abstract Smart Contracts increases the exibility 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 e orts 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 di erent blockchains.