Automating BPMN to Smart Contracts
Automating BPMN to Smart Contracts
Research Article
A R T I C L E I N F O A B S T R A C T
Keywords: Research on blockchains addresses multiple issues, with one being the automated creation of smart contracts.
Blockchain Developing smart contract methods is more difficult than mainstream software development as the underlying
Business processes modeling notation (BPMN) blockchain infrastructure poses additional complexity. We report on a new approach to developing smart con-
Discrete event (DE) modeling
tracts with the objective of automating the process to increase developer efficiency and reduce the risk of errors
Finite state machine (FSM)
Hierarchical state machines (HSM)
introduced by software developers. To support industry adoption, we use Business Process Model and Notation
Smart contract (BPMN) modeling to describe an application while targeting applications in the trade vertical. We describe a
Off-chain computation system that transforms a BPMN model into a multi-modal model that combines Discrete Event (DE) modeling for
Privacy concurrency with Hierarchical State Machines (HSMs) to represent application functionality. Then, further
Smart contract interoperability transformations are used to transform the DE-HSM model into methods in smart contracts. The system lets the
modeler decide which of the independent patterns should be transformed into methods of a separate smart
contract that is deployed on a sidechain for the purpose of (i) reducing processing costs and/or (ii) providing
privacy so that other participants in the smart contract do not have visibility into the processing of the pattern. We
also briefly describe a proof-of-concept tool we built to demonstrate the feasibility of our approach.
* Corresponding author.
E-mail addresses: Peter.Bodorik@dal.ca (P. Bodorik), Chris.Liu@dal.ca (C.G. Liu), Dawn.Jutla@gmail.com (D. Jutla).
https://doi.org/10.1016/j.bcra.2022.100115
Received 7 December 2021; Received in revised form 26 September 2022; Accepted 9 November 2022
2096-7209/© 2022 The Authors. Published by Elsevier B.V. on behalf of Zhejiang University Press. This is an open access article under the CC BY-NC-ND license
(http://creativecommons.org/licenses/by-nc-nd/4.0/).
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
environment, privacy of recorded transactions, and compatibility issues no concrete proposals, and (ii) Mendling et al. [15] described challenges
across smart contracts of different blockchains. Comprehensive literature arising when analyzing the blockchain technology using Business Process
review papers on these other issues have been published with examples Management (BPM) lifecycle as a framework. They also identified a
being [5-13]. number of issues beyond the BPM lifecycle management. Their analyses
In developing smart contracts, blockchains have complex constraints led them to present seven major research directions that will emerge in
for applications, one being the maintenance of smart contracts that is the future.
challenged by their immutable storage. These constraints mean that it is Weber et al. [16] proposed an architecture for creating smart con-
even more important to use software and security engineering best tracts from a distributed application specified as a BPMN model. The
practices in new approaches and methods for introducing efficiencies, as transformation process has two phases: design and execution. In the
also recommended in Ref. [9]. We first review research on the develop- design phase, the BPMN model is analyzed and transformed into a
ment of smart contracts that is closest to our work. We then describe our distributed application that uses a blockchain smart contract. There are
goal and outline further sections. two components to the system, an off-chain component that accepts input
from the external application and transforms it into the calls to the
1.1. Smart contract development methods of a smart contract, and the on-chain component that includes
the smart contract methods and a run-time monitor/mediator that
Smart contracts and their development and maintenance received manages the choreography of task activities represented by BPMN ele-
much attention from the research and development communities, as can ments. From this work, there were two significant follow-up projects,
be seen by the literature surveys in Refs. [5–13]. Research on smart Caterpillar [17] and Lorikeet [18].
contracts has concentrated on (a) the analysis and verification of con- Caterpillar has been further augmented with the ability to bind actors
tracts that are written already and (b) approaches to create smart con- to roles dynamically using a proposed policy specification language
tracts from some higher-level model. In Ref. [7], research on smart based on Petri net semantics [19,20]. The proposal has been incorporated
contracts is classified into categories of (i) smart contract testing, (ii) into the Caterpillar project software, and the approach was evaluated
smart contract code analysis, (iii) smart contract code metrics, (iv) smart with positive results. The policy specification is transformed into
contract security, (v) application performance measurements, and (vi) methods of smart contracts used for enforcement. Di Ciccio et al. [21]
blockchain applications. Since blockchains are immutable and smart also supported model-driven engineering using BPMN for the generation
contracts are stored on the blockchain, fixing blockchain bugs in smart of the methods of smart contracts, and for demonstration of feasibility,
contracts easily is an open issue. Hence, we observe a lot of research in they used the Caterpillar [17] and Lorikeet [18] projects.
the categories listed above that concentrates on analyzing existing smart Loukil et al. [22] also started with a BPMN model, but one of their
contracts for security, vulnerabilities, correctness, and the presence of requirements is to address the issue of smart contract immutability and
errors. hence require the creation and deployment of a new contract any time
Khan et al. [6] surveyed and classified research on blockchain smart new updates are required. Thus, instead of generating a compiled version
contracts into two broad categories: improvement and usage. The usage of a smart contract from a BPMN model, they advocated the creation and
category reviews how blockchains are used by applications of various deployment of one generic smart contract that invokes predefined
types, while the improvement category includes research and tools to functions. They proposed a system architecture that has three layers:
improve smart contracts either when writing them or once they exist. Conceptual, Data, and Flow layers. The conceptual layer performs a set of
Approaches listed in the survey on the writing of smart contracts rely on activities that invoke functions of the data layer.
defining a programming language, for instance, domain-specific or Lu et al. [23] used business process modeling to support fungible and
contract-oriented, that facilitates the creation of smart contracts with non-fungible asset management. In addition to BPMN modeling, their
desirable properties. These approaches, although successful in that they architecture also includes asset registry modeling for each fungible and
lead to smart contract programs with formally proven safety properties, non-fungible asset. For evaluation, they used Lorikeet for BPMN
have not been adopted in practice as they exhibit perceived “complexity” modeling of selected use cases from government and industry, wherein
by developers who ultimately determine how well-accepted a program- the use cases include fungible/non-fungible asset registration, escrow for
ming language is. conditional payment, and asset swap.
An extensive literature survey of close to 200 papers on formal In a research report [24], the authors took a different approach to
specification and verification of smart contracts was provided in transforming a BPMN model into a smart contract. Instead of starting
Ref. [13], in which formalism taxonomy was used to classify work into with a BPMN collaboration represented by a BPMN diagram, as does
contract-level and program-level categories, depending on the level of most of the other research on transforming BPMN models into smart
abstraction used in modeling and analyses. Further classification was contracts, they started with a BPMN choreography, which describes
performed depending on the type of abstraction used for the analysis. The conversations amongst the participants but not the details of messages
contract-level category was further classified into methods using (i) exchanged during the conversation. BPMN conversations within a cho-
process algebras, (ii) state transition systems, and (iii) set-based methods. reography are not deterministic, as there may be many collaborations
Furthermore, the program-level category was classified into (i) abstract within a conversation that satisfy the conversation specification. Thus,
syntax trees, (ii) byte code, (iii) control-flow graphs, and (iv) program the research work focuses on optimizing each conversation and its
traces. synthesis.
The literature survey in Ref. [11] reviewed existing Model Driven We also mention work in Refs. [25,26], in which a smart contract is
Engineering (MDE) approaches to the creation of smart contracts. One of first modeled as a Finite State Machine (FSM) created using a graphical
the classifications offered was based on modeling techniques that editor. The FSM is transformed into a set of methods of a smart contract,
included Unified Modeling Language (UML), Business Process Modeling and then each method is examined using their FSolidM tool to amend it
Notation (BPMN), Entity-Relationship Diagram (ERD), DEMO modeling with security code to plug the known security holes. Furthermore, the
tool, ArchiMate modeling tool, and Eclipse Modeling Framework (EMF). security code cannot be amended by the developer. The issue is that the
Our work is closest to research that uses BPMN for business process smart contract needs to be represented as a single FSM first, which limits
modeling, which is then transformed into a smart contract. Early work the usefulness of the approach. However, once the smart contract
included (i) Bragagnolo et al. [14] described how UML, BPMN, and ER methods are created, the FSolidM tool can be used to plug the security
models could be used to model blockchain-based applications but offered holes.
2
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
1.2. Goal and approach sidechain may be one of Quorum (Ethereum-EVM sidechain) or the
Hyperledger Fabric channel.
The main goal of our research is to transform a business application, 5. The use of DE-HSM modeling led to automated support for sidechain
expressed by a BPMN model, into a set of methods of smart contract(s). processing that is used (i) to reduce the cost of processing by moving
The main distinction of our approach to other work that transforms computation from the mainchain to a cheaper sidechain and (ii) to
BPMN to a smart contract is that we use Discrete Event–Hierarchical achieve privacy in collaboration, wherein data required for use in a
State Machine (DE-HSM) modeling, in which concurrency is modeled pattern that is processed on a sidechain is private and hence is inac-
using Discrete Event (DE) modeling and functionality is expressed using cessible to actors who do not participate in collaborating on that
Hierarchical State Machine (HSM) modeling. As HSM is a form of an pattern.
FSM, one of the basic modeling techniques in computer science, there is
rich theory and many tools that have been developed to reason about 1.4. Outline
FSMs.
However, most importantly, using DE-HSM modeling enabled us to In Section 2, we provide background. Section 3 overviews our ar-
create methods that identify patterns, DE-HSM sub-models, that are chitecture and also presents assumptions and the BPMN modeling fea-
suitable to be processed on sidechains. We exploit this property to tures that our system currently supports. Section 4 describes (i) the
facilitate: transformation of a BPMN model into a DE-HSM model and then (ii) the
creation of DE-FSM sub-models. Section 5 describes how the DE-HSM
Cost reduction by allowing the modeler to select patterns, identified model is transformed into the methods of a smart contract(s) and how
as DE-HSM sub-models, to be processed on sidechains that are the modeler is provided with the choice of deploying sub-models for
cheaper than the mainchain. processing off-chain to (i) decrease the cost of processing by performing
To achieve privacy by processing specific collaboration activities on a work off-chain where processing is less costly and/or (ii) provide privacy.
sidechain where data are visible only to the collaboration participants Section 6 describes our proof-of-concept (PoC) system, the TABS tool,
as opposed to all actors accessing the smart contract. and its evaluation. Section 7 offers concluding remarks.
2. Background
1.3. Related work and contributions
In this section, we first briefly review the trade finance use case and
Closest to our work is the research on transforming a BPMN model its properties. We then describe DE-FSM multi-modal modeling that
into methods of a smart contract with minimal intervention from the combines DE modeling for concurrency with FSM modeling. We
developer [16–23] that was already discussed in a previous subsection. conclude with an overview of BPMN elements.
They transformed a BPMN model into a set of tasks that are executed
under the control of a monitor/mediator, which is a part of the smart 2.1. Trade finance applications
contract deployed on a blockchain. The off-chain part of the system
transforms the application's input into calls to a smart contract. Input is Blockchains and their smart contracts are not suitable for all types of
parsed to determine application's input, and choreography (not BPMN applications. Smart contracts are not suitable for applications that exhibit
terminology) is used to determine which task is to be executed. Incorrect heavy computational requirements, as the execution of smart contract
sequences of input form “non-conformant” input streams that need to be transactions requires validation involving all or a number of the block-
identified by the system, while correct sequences should result in the chain nodes. As their name implies, smart contracts are particularly
execution of correct tasks. suitable for applications that involve the collaboration of different actors,
We depart from the related work in several major aspects that also possibly of different organizations, with varying requirements on infor-
form our contributions: mation availability, security, and privacy, amongst others. And trade
applications involve activities that exhibit those properties and thus
1. We use DE-HSM multi-modal modeling that transforms a BPMN should be suitable for blockchain applications, as is confirmed by the
model into a DE-HSM model in which sub-models are FSMs and DE much higher adoption of blockchains in trade, which also includes
modeling is used to model time. finance in trade and hence also Decentralized Finance (DeFi). Thus, trade
2. We support the automatic transformation of selected DE-FSM sub- and finance applications are our target area, which is a broad area
models into the methods of a smart contract. The choreography of involving third parties for the purposes of efficient processing of trans-
collaboration tasks is represented by a DE-HSM model consisting of actions by participants, such as banks, customs, shippers, and insurance
DE-FSM sub-models. companies.
3. Furthermore, the DE-HSM model representation of the BPMN model
into individual DE-FSM sub-models is such that each individual 2.2. FSMs, Hierarchical State Machines, and Nested Multi-modal
model is an independent component, also referred to as a pattern, Modeling
with a desirable property that once the pattern execution starts, it is
localized until execution leaves that pattern. This property is exploi- FSM modeling has been used frequently in the design and imple-
ted to facilitate off-chain processing of such patterns and to support mentation of software. Adaptations of FSM modeling techniques were
privacy. proposed to expand the applicability of FSMs to modeling applications.
4. The modeler provides information on the patterns/sub-models and For instance, a guard along an FSM transition is used to specify a Boolean
selects those to be processed off-chain. The Transforming Automati- condition on the state's variables that must be true for the transition to
cally to Blockchain Smart Contracts (TABS) system transforms the DE- take place. In the late 1980s, FSMs were extended to address the issue of
HSM model into smart contracts, one deployed and executed on the reuse of patterns with the concept of hierarchy, leading to HSMs that may
mainchain and the other deployed and executed on a sidechain (we contain states that are themselves other FSMs. Harel [27] showed that
currently support off-chain processing on sidechains only). The FSMs can be combined hierarchically: A single hierarchical state at one
mainchain contract invokes the methods of the sidechain contract level can be considered to be in several states concurrently, as repre-
that implements the patterns that were selected by the developer to sented by an FSM(s) in a lower level of the hierarchy, and FSMs may also
be executed on a sidechain. The mainchain may be either one of be combined, leading to concurrent FSMs.
Ethereum (private or public) and Hyperledger Fabric, while the An HSM can be defined using induction as follows (due to Ref. [28]
3
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
and also described in Refs. [27,29], and others): In the base case, an FSM 2.3.1. Flow objects
is a hierarchical machine. Suppose that M is a set of HSMs. If F is an FSM They include Events, Activities, and Gateways.
with a set of states, S, and there is a mapping function f: S-> M, then the
triple (F, M, f) is an HSM. Each state, s ∊ S, that represents an HSM is Events: There are three types of events: Start, Intermediate, and End.
replaced by its mapping f (s). HSMs recognize the same language as their Start and End events are special in that they denote the start and end
corresponding flattened FSM. However, HSMs do not increase the of an activity or a business process. Intermediate events include many
expressiveness of FSMs, only succinctness in representing them. different types with examples that include message timer, timer,
Girault et al. [28] described how HSM modeling can be combined conditional, escalation, and multiple parallels. Each type has a special
with the concurrency semantics of a number of concurrency models, symbol with an icon having special markings to indicate properties,
including communicating sequential processes [30] and DEs [31]. They such as throwing or catching, interrupting and non-interrupting, and
described how an HSM model can represent a module of a system under a boundary. Some of the throwing events are connected to catching
concurrency model that is applicable only if the system is in that state. events with sequence flow to show the flow of control.
This enables the representation of a subsystem using a particular Activities: As the name implies, activities represent work performed
concurrency model that may be nested within a hierarchical state of a in a business process flow, activities that include Tasks, Sub-processes,
higher-level FSM. This may be used in multi-modal modeling, in which and Call Activities. Call activities allow the re-use of Tasks and Sub-
different (hierarchical) states may be combined with different concur- processes and thus enable their nesting. An activity may be per-
rency models that are best suitable for modeling concurrent activities for formed once or many times, in which case it is a looped activity. A
that particular state. We exploit the concept of multi-modal modeling to looped activity is a specified activity that is intended to be performed
allow the designer to model concurrent but independent activities by on each element of a set of objects that may be viewed as input to the
concurrent FSMs at the lower level of hierarchy in order to avoid the state looped activity. The looped activity may be either Standard, wherein
explosion that may arise in such situations [28]. In Refs. [32,33], we the specified activity is executed sequentially once for each object in
showed that a multi-modal model that combines DE modeling with FSM the input set of objects. Or it may be a Multi-instance activity, in
modeling may be used to model trade finance applications; such a which case the activity is executed concurrently on each object in the
combination of models is referred to as DE-HSM multi-modal modeling. set of objects.
We also showed that it is possible to automatically transform a DE-HSM Task is an activity that is independent of other activities or BPMN
model of such an application into methods of a smart contract deployed elements.
on a blockchain. Sub-process is a compound activity that can be represented by other
A DE-HSM has external inputs, and it produces outputs. The model elements of which the scope is limited to the sub-process itself. A
represents how external inputs form inputs to sub-models and how those sub-process may be defined further as a transaction, in which case
sub-models are interconnected to produce the final output. However, if the sub-process must be supported by a special protocol that en-
the sub-model's interconnection is such that there are no loops, then the sures that all of the transaction activities have been completed
model can be viewed as a zero-delay model [29], in which the individual successfully and that all activities completed partially by a sub-
DE queues may be combined into one DE queue. process are “undone” by performing compensating activities.
Feedback loops in a DE-HSM arise due to feedback loops in the BPMN Compensating activities are shown using a Compensating
model from which the DE-HSM model is derived. None of the approaches association.
to producing smart contracts from a BPMN model that were discussed in Gateways: They are used to represent the flow of a business process.
the introductory section addressed the issues of the feedback loops in a A gateway may (i) have one or more incoming/converging flows to
BPMN model. Feedback loops cause various difficulties, such as deter- form a join/merge gateway and (ii) have one or more outgoing/
ministic semantics, and will be discussed further in a later section. diverging sequence flows, in which case it is a split/fork gateway. If a
In modeling, the term DE-FSM modeling refers to a model for which it gateway has multiple incoming and multiple outgoing sequence
is known that it does not contain hierarchical states. flows, then it is both a converging and a diverging gateway.
A diverging exclusive gateway, which may have conditions speci-
2.3. BPMN overview fied on the outgoing paths and permit a default outgoing path, al-
lows only one outgoing execution at a time.
BPMN is viewed as a de facto standard for describing business pro- An inclusive diverging gateway allows many outgoing sequence
cesses. It was developed by the OMG organization with the objective of flows to be active. If an outgoing flow has an associated condition,
BPMN to be understandable by all business users, from business analysts, then that condition must evaluate to be true at run-time in order for
through technical developers implementing the processes, to people a flow to proceed along that path.
managing those processes. That it has been adopted in practice is A parallel converging gateway does not have conditions on its path:
demonstrated by many available software platforms that provide for the Each incoming sequence must receive a token (an incoming flow
modeling of business applications with the objective of automatically must arrive on a path) before triggering the outflow. Once an
creating an executable application from the BPMN model. outflow is triggered, all outgoing paths are activated and proceed in
For instance, Oracle Corporation uses the Oracle Business Process parallel if the gateway is also diverging.
Analysis Suite to model business processes using BPMN and transform a An inclusive converging gateway passes the token only if a token
BPMN diagram into a blueprint for executable Business Process Execu- has arrived on each of the enabled incoming paths; otherwise, there
tion Language (BPEL) processes [34], wherein the blueprint represents is a wait until the tokens do arrive.
the logic of the application in terms of concurrent processes and their
interactions, while details of individual tasks are supplied by imple- 2.3.2. Data
mentors. Another example is the Camunda software platform, which is Included are Data Objects that provide information about what data
also used to develop a BPMN model that is then transformed automati- activities use or produce. A Data Object is used to represent either an
cally into a Java application. Our approach is similar, but instead of object or a set of objects. Data Input provides input information to pro-
targeting BPEL or Java as the ‘target’ for creating executable applica- cesses, while Data Output is used to receive information from processes. A
tions, we target smart contracts executing on blockchains. Data Store use is self-explanatory.
The BPMN standard categorizes its elements into five basic cate-
gories: (i) Flow objects, (ii) Data, (iii) Connecting objects, (iv) Swimlanes, 2.3.3. Connecting objects
and (v) Artifacts. Connecting objects are used to indicate the sequence of execution.
4
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
Connecting objects can be (i) Sequence Flows, (ii) Message flow, (iii) instance, Dijkman et al. [35] analyzed the semantics of the BPMN model
Associations, and (iv) Data Associations. and identified a number of issues arising due to the inexact nature of the
semantics in the BPMN specifications. And one of the issues identified
Sequence flows show the normal flow. In addition, there are was difficulties arising due to the uncertain semantics of the BPMN
specialized types of sequence flows, namely Conditional flow that has specification for feedback loops. We do support a limited form of looping
a condition that is evaluated at run-time to determine if the flow may in BPMN diagrams, wherein the limitation is that a loop is defined only
proceed and Default and Exception flows that are self-explanatory. for patterns, that is, portions of a BPMN diagram, that can be represented
Message flow shows the flow of messages. by sub-processes. That is, the BPMN elements of a pattern are connected
Association, such as Text association, is used to link information and to the rest of the diagram only by two connecting objects, such that one is
Artifacts with BPMN graphical elements. incoming and one is outgoing. In effect, such a portion/pattern of the
BPMN diagram can be represented by a sub-process, as it also has only
2.3.4. Swimlanes one incoming and one outgoing connecting object. In fact, the way we
A swimlane represents a participant in a business process. There are handle such a pattern with a feedback loop is by transforming it into a
two types of swimlanes: Lanes and Pools. A pool with lanes represents an looping sub-process, but with limitations on the looping conditions, as
organization; while lanes within a pool represent individual participants shall be described under the looping sub-process description below.
within that organization. Only message flows can cross pools; no other Interestingly, none of the other approaches to producing smart contracts
BPMN elements can do so. from a BPMN model, which we discussed in the introductory section,
made any mention of how loops in a BPMN model were handled.
2.3.5. Artifacts We support sub-processes in a straightforward way by replacing each
They are used as a form of documentation to provide additional in- sub-process with its BPMN model of core elements (BPMN diagram of the
formation about a process. The two standardized Artifacts are Group and expanded sub-process) before transforming a BPMN model into its DE-
Text Annotation, but modelers are free to add as many Artifacts as HSM representation. We also support limited forms of parallel and loop-
necessary. Group provides a graphical representation of a collection of ing sub-processes.
elements. Text Annotation is used to provide additional textual infor- Parallel sub-process: Our approach is to replace a BPMN sub-process
mation to a BPMN diagram element. with its elaboration in terms of its activities expressed using the indi-
In version 2.0.2, OMG introduced choreography in BPMN to represent vidual BPMN elements when the sub-process is expanded. To support
the way business participants coordinate their interactions through parallel streams for parallel execution, our approach needs to know the
conversations. Choreography is a concept at a higher level of abstraction maximum number of parallel activities in a process, as we need to create
than the core BPMN elements. It hides many details that are required for the required number of streams, one for each parallel activity, before the
the elaboration of a BPMN model into an executable application, smart contract deployment. Before transforming the DE-HSM model into
regardless of whether it is blockchain-based or not. In a BPMN model, a smart contract, the modeler needs to specify the maximum number of
choreography focuses on showing message exchanges amongst the par- parallel streams for a parallel sub-process. That information is then used
ticipants, however, without providing the details on the messages to create the maximum number of parallel streams, which exist in the
exchanged or their content. In a BPMN choreography, instead of showing smart contract whether they are used or not. Thus, we do not fully sup-
detailed message exchange, commands of higher-level abstraction are port the BPMN semantics in that there may be an arbitrary number of
used to represent the exchange of messages using a single request-reply separate parallel streams that are used to process a collection input into a
type element, and the BPMN choreography is thus unsuitable for sub-process, wherein the collection has an arbitrary number of elements
modeling an application to be transformed into a smart contract. that results in an arbitrary number of parallel streams, each one to pro-
cess one element of the collection. However, this issue arises generally
3. System architecture with handling looping mechanisms in deterministic systems, such as
systems expressed in FSM or HSM modeling.
Although we discuss our assumptions throughout the paper, we Looping sub-process: We do support a limited form of a looping sub-
enumerate them collectively in this section. They include assumptions on process, wherein the limitation is that the maximum number of iterations
the BPMN model and which BPMN elements we support. We then pro- is known before the start of the execution of a looping sub-process. We
vide a high-level overview of the architecture that consists of two com- model a sub-process without its looping property, and we accommodate
ponents: One used in the design phase to transform a BPMN model into the looping after modeling, before the creation of a smart contract in a
the methods of smart contract(s) and one used during the run-time phase way that is similar to the usual for-loop programming construct. Trans-
to monitor and manage the smart contract deployed on a blockchain. formation prepares inserts the script for a looping variable just before
Each phase is briefly overviewed and then described in more detail in entering the looping sub-process, with the looping variable initialized
subsequent sections. based on the size of the input collection. Furthermore, the translator
inserts the script at the end of the looping sub-process to increment the
3.1. Assumptions looping variable and check whether to perform the loop again.
We first describe assumptions we make regarding a BPMN model and b) Assumptions on converging gateways
then assumptions made on the system architecture and its
implementation. Converging gateways may be parallel, in which case for a token to be
passed, a token must have arrived on each of the incoming edges of a
3.1.1. Assumptions on the BPMN models converging gateway.
These assumptions deal primarily with loops, sub-processes, However, the converging gateway may also be inclusive, in which
converging gateways, model preprocessing, and which BPMN elements case the BPMN semantics state that when a token arrives on an incoming
we currently support in the TABS tool. edge to an inclusive converging gateway, the token can be passed only if
a token has arrived on each of the incoming pathway that is enabled;
a) Assumptions on parallel and looping sub-processes otherwise, there is a wait for the remaining tokens arriving on such
enabled pathways. However, we make a simplification for an inclusive
That loops in BPMN models cause difficulties with BPMN semantics converging gateway in that we simply pass the token; we check the other
has been recognized and examined by a number of researchers. For pathways neither for enablement nor for a token arrival.
5
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
c) Assumptions on BPMN model preprocessing we impose limits on looping and parallel sub-processes and arbitrary
loops in BPMN diagrams.
Once a BPMN model is created and expressed using its standard XML
representation [35], we assume that the model is transformed into an 3.1.2. Other assumptions
equivalent BPMN model that is well-formed, wherein the well-formed
BPMN model is defined as in Ref. [35]: A BPMN model is well-formed a) No support for long-term trade transactions
in it satisfies the following conditions: (i) there is only one start event;
(ii) there is only one end event; (iii) fork/split decision gateways have BPMN has the concept of a transaction defined on a sub-process, and a
one incoming flow and more than one outgoing flow; (iv) join/merge blockchain also supports transactions. That is, a sub-process can be
gateways have one outgoing flow and more than one incoming flow; and defined in BPMN as an atomic transaction in that the whole sub-process
(v) there are no data-based splits/forks or joins/merges—they are needs to be either completed entirely or none of its effects, such as up-
expressed using equivalent gateway constructs. The above conditions are dates to the state variables, be recorded on the blockchain. Any activity
not restrictive as any BPMN model can be transformed into an equivalent that was performed by a sub-process that was subsequently aborted must
well-formed BPMN model as described in Ref. [35]. be “undone” by compensating activities. Blockchains also have trans-
The proposed TABS tool, described in this paper, allows users to actions of which semantics are defined in terms of blocks of transactions.
compose a BPMN diagram directly on the canvas by invoking an API Furthermore, trade applications also have the concept of a transaction,
provided by Camunda [36]. The model is saved by the tool in the BPMN wherein transactions may be defined for a group of activities that may
XML representation [37] and then transformed into a DE-HSM model by span long periods of time and may apply to data that is a subset of the
our TABS tool. The BPMN model may contain participants (Pool and data processed by a trade application. The problem is that these three
Lane), activities (tasks, sub-processes, and transaction), gateways, and concepts of a transaction, one for the trade vertical, one for BPMN, and
events (default, start, end, message, and timer) [38]. Fig. 1 shows the one for blockchains, are mismatched as they do not align, which is akin to
symbols that our TABS tool supports, albeit as noted in Section 3.1.1(a), the impedance mismatch between the relational and object-oriented DBs
Fig. 1. BPMN (business process model and notation) symbols supported by TABS (transforming automatically to blockchain smart contracts).
6
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
[39]. We do not address this mismatch amongst the BPMN, blockchain, hash code of an object.
and trade transactions in this work, but we do plan on doing so in our
near-future work. c) BPMN task element
b) Off-chain storage The BPMN task element represents a self-contained task. However,
our system does not provide the script for the task element, the developer
It is well known that storing objects or data on a blockchain is does. Our system does prepare the method skeleton, including the
expensive, particularly for a public blockchain, such as Ethereum. It is method's signature and the method's invocation, while the developer is
thus a standard practice to store large objects/data off-chain and store on asked to supply the code for each task before deployment. This approach
the mainchain only the hash code of the data stored off-chain. Further- is standard when creating applications from a BPMN model. For instance,
more, the hash code of an object is used any time the object is retrieved Oracle Corporation uses the same approach in its Oracle Business Process
by a smart contract to ensure the immutability property of an object Analysis Suite when transforming a BPMN diagram into a blueprint for
stored off-chain. Thus, we also assume that any objects are stored off- executable BPEL processes [41], and a similar statement also applies to
chain. An exception to that is any object used in support of the monitor the Camunda platform, which also asks the modeler to provide the script
of the architecture shown in Fig. 2. We facilitate off-chain storage by for each of the PBMN model's tasks.
using IPFS. IPFS is a distributed system for storing and accessing files,
websites, applications, and data [40]. It is resilient and has decentralized
3.2. Architecture Overview
control. Due to its resiliency, decentralized control, and content
addressing using a hash code, it is particularly suitable as off-chain
The architecture of the system is shown in Fig. 2, which shows two
storage for blockchains. IPFS storage is, content addressable using the
major phases: Design and Deployment/Installation phase, and the
7
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
Execution/run-time phase. In the first phase, the BPMN diagram is first o The monitor analyzes the output produced by the FSM's firing and
transformed into the DE-HSM model and then into the methods of a smart may perform one or more of the following actions:
contract. However, besides the creation of the smart contract methods Invoke one of the tasks
with supporting run-time management information, the transformation Queue an event into the DE queue
also prepares API methods to be used by a Distributed Application Respond to the smart contract invocation
(DApp) to interact with the methods. Once the smart contract is pre- Cause a signal to be delivered to the DApp
pared, it is deployed in the Design and Deployment/Installation phase,
which deploys the smart contract on the blockchain and also installs the
3.3. Design and Deployment/Installation phase
API and associated methods in a network node so that a DApp is able to
communicate with the smart contract. The smart contract includes a
The design phase consists of the following main steps:
monitoring module with run-time management information stored in the
data structures prepared during the design phase. They include the DE
1. Initialization and transformation of the BPMN model into the DE-
queue of events and FSM definitions corresponding to the DE-FSM sub-
HSM multi-modal model.
models and FSMs to support concurrent processing within individual DE-
2. Transformation of the DE-FSM sub-model into a set of methods of a
FSM sub-models.
smart contract.
After the smart contract deployment and installation of API methods,
3. Deployment and installation: Deploy the smart contract(s) and install
run-time processing involves the user interacting with the DApp that
the API-SCmethods and the DApp API.
invokes appropriate API methods in response to user input. This input is
examined by the API-SCmethods module that translates it into an invo-
As was already indicated in the previous section, our architecture is
cation of an appropriate smart contract method.
similar to that of Refs. [16–18], and for the sake of comparison, we use
A smart contract method input is passed to the Monitor that:
the same terminology as in Ref. [16], which has also been used in other
work. Fig. 3 shows a BPMN model to be transformed by a Translator of
Accepts inputs from a smart contract method, analyzes them, and
the Design phase into a DE-HSM model, which is followed by producing
queues an appropriate event into the DE queue as a response to the
the smart contract methods. Similarly, the run-time phase involves a
input.
mediator/monitor that takes external events/triggers, which the DApp
Removes events from the DE queue one at a time, and for each event:
delivers to the run-time methods as parameters when calling them. The
o Analyzes an event's information and invokes an appropriate FSM
response is delivered to the DApp via output parameters upon return.
while passing it input derived from the event's information.
In the initialization of the design phase, data structures are prepared
o The invoked FSM takes the input, examines its state, and fires
for the subsequent design steps that will include the information that is
causing a transition while generating output that is returned back
used during the execution phase. After initialization, transformation
to the monitor.
from the BPMN model into the DE-HSM model deals with determining
Fig. 3. A BPMN (business process model and notation) model for supply chain example.
8
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
which parts of the BPMN model should be represented by which of the that uses its Analyzer sub-module to examine the input parameters and
DE-FSM sub-models. Each of the DE-FSM sub-models includes a DE use them to queue an appropriate event into the DE queue. When that
model to represent concurrency and an FSM model to represent func- event reaches the head of the queue, it is dequeued and passed to the
tionality. Choreography (not a BPMN term), which orchestrates the appropriate FSM for firing. The FSM receives its input, checks the current
execution of activities in possibly concurrent processes, is represented by state, and fires; that is, it makes a transition while generating output. The
a DE-HSM model that represents the control flow amongst the DE-FHM transition's output indicates if a task or a sub-process, associated with the
sub-models, as will be described later. Furthermore, each DE-FSM new FSM state, needs to be performed. For instance, if the transition was
model may also have internal parallel activities if the BPMN collabora- to a state that represents a task calculate demand, then a task created for
tion it represents has parallel or inclusive gateways. that purpose is invoked. As a part of the FSM transition, the smart con-
In addition to the smart contract methods and information for the tract analyzes the returned output from a transition, and consults infor-
run-time Monitor, the design phase also prepares API methods to be mation on tasks and sub-processes, and determines which of the
invoked by the DApp. The API methods presented to the DApp are following should be performed: (i) schedule another event by queueing it
focused on activities amongst actors and thus roughly correspond to the into the DE queue; (ii) prepare output parameters and return them to the
flows of objects between either pools or swimlanes. As a consequence, smart contract method that invoked them; (iii) produce output and cause
when input is received via a message from one actor to another, receiving a DAapp signal to be generated; and (iv) invoke another smart contract
a message will result in a call to the API with input being the content of method.
the received message. The Design phase prepares appropriate informa-
tion for the API-to-SCmethods translator that assists in determining 3.5. Example
which of the smart contract methods should be invoked and which input
parameters to the API should be included as input to the smart contract Consider the BPMN diagram in Fig. 3 and assume that processing has
method invocation. progressed successfully and that (i) the manufacturer has sent a message
The last steps are relatively straightforwards, as they include to the middleman with an order for parts; (ii) the message with the order
deployment of the smart contract methods and installation of the DApp has just been received by the DApp, and that the DApp just invoked the
API and API-to-SCmethods modules on network nodes. API with information about the received message. The API method takes
the information from the API method and packages it as input to the API-
3.4. Execution phase to-SCmethods component together with information on the source and
destination of the message flow object. The component consults its in-
The execution phase includes two phases: Initialization and formation, invokes an appropriate smart contract method while passing
Execution. its input parameters, and then waits for the response from the smart
Initialization deals with issues, such as the authentication of the ac- contract method.
tors, also referred to as participants. Once the smart contract is deployed, The smart contract method passes its information to the Analyzer
execution is managed by the Monitor module. component of the Monitor. The Analyzer checks its management infor-
It should be noted that the activities described above need to be mation and transforms the smart contract input information into an
performed by any approach that generates smart contract methods from a event, which includes parameters that are stored in the DE queue. The
BPMN model. Consequently, parts of the architecture for the run-time component then removes an element from the head of the DE queue,
phase are similar to other architectures, such as the architecture in processes it, and repeats until the queue is empty. In this example case,
Refs. [16–18]. For that reason, we use the same or similar terminology, there is only one element that is dequeued from the DE queue, an element
including terms of monitor/mediator and triggers. Fig. 2 shows, for the representing the reception of the message containing the order.
run-time phase, an off-chain DApp API module that provides an API to When the event, which represents the reception of an order, is
the DApp. The module also shows an API-to-SCmethods component that dequeued from the DE queue, it is processed by the Analyzer by (i)
transforms an API call into a call to a smart contract method. In other determining which of the FSMs is to be fired to process the dequeued
research, this component is called “triggers”, but we feel that the event; (ii) preparing the input parameters for the FSM; and then firing the
API-to-SCmethods name is more appropriate than triggers. FSM, i.e., causing the FSM's transition. The FSM takes the input, the
The DApp API methods correspond to information flow across pools current FMS state, and determines the transition while producing output
or swimlanes, and when a connecting object crosses a pool or a lane, that contains the message content and also information about the new
information about the origin and destination of the connecting object is state that corresponds to a task ProcessOrder. Since that state has been
included in input parameters to the API-to-SCmethods component to reached and it represents the ProcessOrder task, the corresponding task is
determine which smart contract method is to be invoked. invoked that produces output from the transition that includes the pro-
A smart contract, at times, needs to inform external actors of certain cessed order. As the output from the task, the processed order, is passed
events to which a user should react. For instance, a contract may go to the next element, it is returned to the Analyzer as the transition's
through computation along different paths that eventually meet, at output. The Analyzer then examines the output from the transition and
which point a user(s) may need to be informed of the results before the checks the new state, which sends a message to the manufacturer, and it
computation proceeds. Our systems facilitate this by the API, which is off- determines that the new state is still a part of the same FSM. Conse-
chain, having a process that invokes a special API method (in Fig. 2, the quently, Analyzer creates a new event with input containing the pro-
process is shown as the Wait for SC to DApp Signals process) that in turn cessed order and queues it into the event queue, and the process repeats.
invokes a smart contract method that waits for a “wakeup” event that
may be generated by another smart contract method. When a smart 4. Transforming a BPMN model into a DE-HSM multi-modal
contract needs to signal the external DApp, it raises a “wakeup” event model and its DE-FSM sub-models
that releases the method waiting for a wakeup event, and it can thus
return to the DApp information about an event that has occurred within To better understand the transformation process, we briefly review
the execution of the smart contract. the key properties of the DE-HSM modeling. As our system transforms a
When a DApp makes a call to the DApp API, the call information with BPMN model into a DE-HSM model, we need to identify the DE-HSM sub-
its parameters is provided to the API-to-SCmethods module that de- models and their interconnections. However, before we proceed, we need
termines which smart contract method is to be invoked, and then it in- to be aware of the model semantics and their implications for modeling.
vokes the smart contract method and waits for its response. Furthermore, we also explain some of the more subtle points on how
The smart contract method provides its information to the Monitor certain BPMN elements are represented in the transformation process.
9
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
Only then do we describe the transformation process itself. connecting objects, the system asks the modeler to provide the code to be
executed by each individual task. Each task has a single input and a single
4.1. DE-HSM modeling semantics and loops output, wherein each may be a complex object. The tasks are incorpo-
rated by the system into the smart contract methods so that they can be
We use DE modeling for concurrency combined with HSM modeling executed according to the control flow as specified by the BPMN model.
for functionality, wherein the modeling is applied hierarchically. As an
example, Fig. 4 shows a system that contains two sub-models. 4.3. Representing BPMN elements for DE-HSM modeling
Fig. 4(a) shows a DE-FSM master model containing two DE-FSM sub-
models, A and B, and their interconnection. Each of the master and two The transformation of a BPMN model into a DE-HSM model is based
sub-models has its own queue of events for DE modeling and an FSM for on a graph representation of a BPMN model given its BPMN diagram
functionality modeling. It should be noted that we referred to the model description using XML. For the DE-HSM modeling and the transformation
as a DE-FSM model as the subsystems have FSMs and not HSMs. process, we use a Directed Acyclic Graph (DAG) representation of the
In semantics for DE-HSM models, adopted from Ref. [28], an FSM BPMN diagram. In the DAG representation, each BPMN flow element/
system appears to the DE system as a zero-delay participant/actor. Under object is represented using a graph vertex, while connecting objects, that
the assumption of zero-delay semantics, a system with sub-models is such is, sequence and message flows, are represented by edges in which the
that the FSM of a child subsystem is the first to fire, that is, it performs the flow control is indicated by the edge direction.
transition on inputs and produces output that is timestamped with the For most of the BPMN flow object elements, the flow-control graph
same timestamp as input (hence zero-delay), and only then does the representation is straightforward in that it can be represented by a graph
parent system react and make a transition that causes its output. vertex, with one or more input flows and with one or more output flows.
Furthermore, without loops, we can use one global queue of events For instance, the task and sub-process BPMN elements belong to the
instead of each subsystem having a separate queue of events [28]. category of activities of BPMN symbols that are represented by graph
However, loops cause difficulties under the assumed zero-delay se- nodes, each with one incoming and one outgoing flow object. A gateway
mantics. Consider Fig. 4(b) and the two subsystems A and B. There is a can also be represented by a graph node with one or more incoming or
loop because output from A forms input to B, and there is another loop in outgoing edges. Events, which also belong to the category of activities,
which B's output is input to A. Such loops cause difficulties, and we are not as obvious and shall be discussed here in more detail in terms of
cannot apply zero-delay semantics in such a case, as execution may never how they are represented in a DAG used for DE-HSM modeling.
terminate. Consequently, representing a BPMN model using DE-HSM There are three types of events: Start, Intermediate, and End. The Start
modeling, we wish to avoid such feedback loops due to the semantic and End events are special in that they occur at the very beginning and
difficulties described above. In Section 3.1, we already assumed that a the very end of a process, respectively; hence, they are specialized cases
BPMN model does not include any loops that cannot be represented by a of the flow of control. Events have a Dimension attribute that describes
looping sub-process. Furthermore, the mechanism for a looping sub- the type of an event, which may be one of message, timer, cancel,
process is implemented as a part of the transformation from the DE- compensation, conditional, link, signal, terminate, multiple, and parallel.
FSM model into the methods of a smart contract that occurs after the Out of this list, we currently support the following events: message,
DE-HSM model is created from a BPMN model. timer, conditional, and signal, as shown in Fig. 1. We are in the process of
incorporating the support for the rest of the BPMN elements. We first
4.2. Initialization (in design phase) discuss how intermediate events are represented and then discuss the
representation of the begin and end events.
In the initialization phase, the translator first transforms a given Intermediate events that are not boundary have explicit connections,
BPMN model into an equivalent model that is well-formed, as described represented by connecting objects between the corresponding throwing
in Section 3.1. and catching events. Thus, they can be represented by vertices connected
In general, a BPMN specification does not require the modeler to by edges that represent the connecting objects. A boundary event does
provide a description of all the information, which is associated with the not have an explicit connection via a connecting object to its counterpart,
BPMN model that is required for execution. However, since our objective such as which signal in a task/sub-process is handled by which of the
is to produce executable smart contracts, the TABS system must obtain boundary catch events. An explicit connection between the rise of an
such information from the modeler. Thus, in the initialization phase, the event and its consequence, however, needs to be established, which is
software interacts with the modeler to ensure that the transformation has done at the conclusion of the modeling process when the modeler is
information about all data flowing along the edges of a BPMN graph to asked by the transformation process to provide details on the flow of
ensure that the transformation has all the necessary information about inputs and outputs along the edges of the graph. For each boundary catch
guards on gateways and the content of messages. During initialization, event, the modeler is asked to identify, by using labels, which of the
we ask the modeler to annotate the BPMN graph accordingly using data signal events caused the catch event by matching the labels of the throw
associations. The issue is that the BPMN specification does not insist on event firing and it is catching it as a boundary event. Thus, each event
the modeler providing such information, and hence, all approaches that does have at least one incoming and one outgoing edge. A boundary
strive to create an executable smart contract from a BPMN model need to catch event, such as catching a signal event, is represented by a graph
seek information from the modeler if it is missing in a BPMN model [36]. node that is connected to its corresponding throw signal event, within the
Once the modeler supplies information on the data flowing along the activity to which it is attached (as a boundary event), by an incoming
10
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
edge from the vertex representing throwing the corresponding event. If 4. For each S^i, i ¼ 1, 2, …, n^, vertices in S^i are vertices of a subgraph G'i
the boundary activity is also interrupting, the state of execution for the ¼ {S'i, E'i}, which is a subgraph of G, G'i ⊆ G, such that S'i ¼ S^i, i.e.,
interrupted activity is ended. However, if it is not interrupting, in vertices of G^i and G'i are the same, and the set of edges E'i includes all
essence, two concurrent activities will proceed, one to continue with the those edges e ¼ (sx, sy) 2 E, where sx, sy 2 S^i and S^i ¼ S'i; i.e., sx, sy 2 S^i
execution of the activity with the boundary condition, and one due to the and the edges are internal to G'i.
catching of the boundary non-interrupting event and processing it. 5. ([ S^i, i ¼ 1, 2, …, n^) ¼ S: Union of all S^i is S, i.e., each vertex in S
A boundary begin event is a throwing event. If a boundary begin event appears in exactly one of the S^i.
is on a boundary of an activity, i.e., a sub-process or a task, that is, a graph 6. The following properties apply to the sets of edges in E:
node B, the boundary event is represented, on the DAG representation of o E^ \ ([ E^i, i ¼ 1, 2, …, m^) ¼ ∅; i.e., E^ intersect (union of all edges
the BPMN model, by inserting an inclusive gateway on the incoming edge E'i) is empty. Edges in E^ form interconnections amongst the sub-
to node B, as identified via label numbers between the boundary start graphs G'i, where each subgraph G'i represents a DE-FSM sub-
event and the label of its corresponding catch event as provided by the model.
modeler. In other words, boundary throwing events are fired/thrown at o Each edge e 2 E is either in E^ or in the union of all edges in E'k, k ¼
the beginning of an activity, and if it is non-interrupting, then two pro- 1, 2, …, m^.
cesses proceed concurrently during execution, one for the boundary start-
event activity and one for the uninterrupted activity represented by In other words, each S^i is a set of vertices of a subgraph G'i ¼ (S'i, E'i),
vertex B to which the boundary start event is attached. where S'i ¼ S^i forms a set of vertices of a sub-model of the DE-HSM
A boundary end event is a catching event, and it is represented in the model, and edges in E'i are all those edges (sx, sy) 2 E that are internal
DE-HSM model in the usual way by a graph node with the incoming edge edges of the subgraph G'i. Thus, each S^i 2 S^ identifies a DE-HSM sub-
that is also an outgoing edge from the corresponding throwing event, as model and edges in E^ represent the interconnection of the DE-HSM sub-
represented by the labeling of events. models. Furthermore:
4.4. Transformation of a BPMN model into a DE-HSM multi-modal model o G'i must be a connected graph.
o As a sub-model must have only one entry and one exit node to be
The DE-HSM model, which we are seeking and that represents a represented by an HSM or an FSM, its subgraph can only have one
BPMN graph, is an interconnection of DE-HSM sub-models, where each entry and one exit vertex.
sub-model is a child model for the parent model. Furthermore, each of
the sub-models may itself be a DE-HSM sub-model, i.e., it may be 4.4.2. Finding a DE-HSM multi-modal model
modeled as an interconnection of its child models. As described in a Given a BPMN diagram, we represent it by a DAG G¼ (S, E) for which
previous subsection, the TABS system represents a BPMN model using a we wish to find its equivalent DAG G^ ¼ (S^, E^) in which each node S^i,
DAG, and then it determines the DE-HSM model as an interconnection of S^i 2 S^, represents a subset of nodes of S that are members of a subgraph
the sub-models, wherein each sub-model is represented without further G'i ¼ (S'i, E'i), such that:
sub-models: The topic of this section. However, once we do find the sub-
models, we also need to describe how to build each sub-model, which is 1. Each G'i represents a sub-model G'i ¼ (S'i, E'i) of G^ and hence G'1, G'2,
the topic of the next section. …, G'^n are such that
Starting with a BPMN diagram, we first describe how we represent a o G'i ⊂ G, S'i ⊂ S
BPMN model as a DAG and then how we approach defining the problem o S'i \ S'k, i 6¼ k, i.e., the sets S'i, i ¼ 1, 2, …, n^, are mutually exclusive
of finding a DE-HSM model for a given DAG. To find a DE-HSM model, we o S ¼ [ S'i, i ¼ 1, 2, …, n^; vertices in subgraphs cover the whole graph
use the concept of independent subgraphs and their variations, which are S
described next. We then present an algorithm to find a DE-HSM model o For each edge e ¼ (sx, sy) 2 E:
that is an interconnection of DE-FSM sub-models, i.e., sub-models that do e 2 E^, i.e., it is one of the interconnections of the sub-models, or
not have hierarchical states. e 2 E'i, for some i and where E'i \ E^ ¼ ∅, i ¼ 1, 2, …, n^, i.e.,
intersection of the set of edges that interconnects the sub-models
4.4.1. DAG representation of a given BPMN graph with any of edges of the subgraphs is empty
At execution time, a DE-FSM sub-model contains a DE queue of events 2. G'1, G'2, …, G'n are such that for G'i and G'j, where G'i and G'j are both
and an FSM, and processing within a sub-model proceeds by dequeuing subgraphs G', are either
an event from the DE queue and then using it to form an input that is o disconnected, i.e., not connected to each other directly (but con-
given to the FSM. Upon input, the FSM fires and produces output. The nected indirectly via transitivity through some other Gk 2 G'), or are
main property of the DE-FSM sub-model, however, is that it accepts in- o connected by one edge e ¼ (sx, sy), where sx 2 Si' and sy 2 S'k, i 6¼ k
puts that are fed to an FSM, and outputs produced by the FMS firing 3. Each sub-model has exactly one entry point and exit point with the
produce the output out of the sub-model. Thus, a sub-model consumes following two exceptions:
one set of inputs and produces one set of outputs. o The subgraph that contains the Start event node of the original
We represent a BPMN model as a DAG G ¼ (S, E), where S is the set of BPMN graph does not have any entry node, as there is no incoming
vertices and E is a set of edges. For a given BPMN diagram, vertices in S edge from the subgraph's external nodes to any of the subgraph's
represent the BPMN non-connecting objects, while edges represent the internal nodes.
connecting objects, that is, sequence flows or message flows. We use a o The subgraph that contains the End event node of the original
DAG G^ ¼ (S^, E^) to represent a DE-HSM model that we find, i.e., a model BPMN graph does not have any exit node, as there is no outgoing
in which: edge from any of the subgraph's nodes to any of the subgraph's
external nodes.
1. For each element S^i 2 S^ ¼ {S^i, i ¼ 1, 2, …n^}, S^i is a subset of
vertices in S, S^i ⊆ S. The conditions in (i) ensure that the subgraphs are mutually exclusive
2. For each element e^k 2 E^ ¼ {e^k, k ¼ 1,2, …, m^ }, e^k is an edge in E, and that they cover the whole BPMN graph. Condition (ii) states that
such that each edge e^k ¼ (sx, sy) corresponds to an edge (sx, sy) 2 E, each subgraph is connected to some other subgraph by exactly one edge.
wherein sx 2 S^i, sy 2 S^k, i 6¼ k, i ¼ 1, 2, …, n^ and k ¼ 1, 2, …, m^ The last condition, condition (iii), is due to the fact that each DE-HSM
3. S^i \ S^k ¼ ∅, i.e., S^i and S^k are mutually exclusive. sub-model accepts input fed to its FSM that produces output upon
11
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
12
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
edges in E that represents interconnections of the sub-models represented edges of the form (sx, s), where sx 2 G.
by the subgraphs. Recall from Section 3.1.1, which dealt with the preprocessing of the
BPMN graph, that the preprocessing replaces any gate that is both a join
4.4.5. Algorithm to find LSI subgraphs gate and a fork gate with an equivalent representation by one merge gate
The previous sections dealt with formalities and abstractions suitable and one fork gate, wherein the merge gate has one or more incoming
for the presentation of the concepts of independent and LSI subgraphs. edges but only one outgoing edge that is also the only incoming edge to a
We now provide a pseudocode of an algorithm to find LSI subgraphs for a fork gate that has more than one outgoing edge.
given DAG G that represents a BPMN model. The algorithm, called Before we proceed with the presentation of the algorithm to find LSI
findLSIsubgraphs, has as its input a global DAG G ¼ (S, E), which repre- subgraphs, we make a few observations about LSI subgraphs:
sents a BPMN diagram. The method results in a DAG G^ ¼ (S^, E^), such
that E^ represents edges and each S^i 2 S^ represents a subset of nodes S'i a) With the exception of the entry or exit nodes, there is no vertex that
of the graph G'i, where the nodes of Si^, i ¼ 1, 2, …, n^, form a subgraph Gi' has both incoming and outgoing degrees greater than one.
¼ (S'i, E'i), where S'i ¼ S^i is a set of nodes representing an LSI subgraph b) If a vertex has an incoming degree of more than one, then it is a
that is an FSM sub-model. Furthermore, Ei’ represents interconnections of merge/join gate with one outgoing edge. In such a case, the vertex
the nodes in S'i, wherein each edge e ¼ (sx, sy) is an internal edge to S'i, may only be an exit node from an LSI subgraph.
i.e., where sx 2 S'i and sy 2 S'i. Thus, each S^i defines an LSI subgraph G' ¼ c) If a vertex has an outgoing degree of more than one, then it is a fork/
(S'i, E'i), while the set of edges E^ of G^ form interconnections amongst the split gate with an incoming degree of one. In such a case, the vertex
LSI subgraphs. may only be an entry node to an LSI subgraph.
The method uses a global variable G ¼ (S, E) to mark the nodes with d) An internal node of an LSI subgraph has an incoming degree and an
information on vertices' incoming and outgoing degrees, where the outgoing degree that are exactly one.
outgoing degree of a vertex s is the number of directed edges of the form
(s, sx), for some vertex sx 2 G, and an incoming degree is the number of The algorithm/method findLSIsubgraphs, shown in Fig. 6, has a DAG G
13
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
¼ (S, E) as its input. Recall that the Start event has only one edge, which is If the s.inDegree is equal to 1 (line 27), then the node's out-degree is
an outgoing edge. Each node s 2 S is assumed to have the following checked.
attributes: o If the out-degree of the vertex s is zero (line 28), then the vertex s
represents the BPMN End node, and consequently, the LSI subgraph
s.inDegree … the number of edges that are incoming into the vertex s identified by the entry and exit nodes s.root and s, respectively, is
s.outDegree … the number of edges outgoing out of the vertex s returned as an LSI subgraph G' that will be added to the set of LSI
s.root … reference to a node that may be an entry of an LSI subgraph subgraphs G^ (lines 29–31).
to which the node s may belong o If the out-degree of the vertex s is equal to one (line 32), then it
cannot be determined as yet whether the node s is or is not an exit
The method findLSIsubgraphs() uses the following auxiliary methods: node of an LSI subgraph. The vertex s could be an exit node such
that there is only a single path to the node s, while the outgoing
vertex x ¼ nextInSearchOrder (G) … the method facilitates a breadth- edge from s, edge (s, sy), leads to a node that has an out-degree
first search traversal of the connected DAG G, in which that vertex s 2 greater than one and hence be the entry node of another LSI sub-
S that represents the BPMN Start event is the start of the traversal. graph, in which case the node s is an exit node from an LSI sub-
Each of the other nodes has at least one incoming edge and one or graph. If the out-degree of the node sy is one, then the node s is not
more outgoing edges, with the exception of the vertex that represents an exit node from an LSI subgraph, as the node sy could be safely
the BPMN End event, which does not have any outgoing edges. added to the LSI subgraph identified by the vertices s.root and s
Calling the method nextInSearchOrder(G) repeatedly results in the without violating the LSI subgraph properties. Thus, to determine
method returning a reference to the next node in the breadth-first whether or not s is an exit node, we must examine the out-degree of
search traversal of G and returning null once all vertices have been the node sy, where sy is the destination node of the outgoing edge
traversed. from s (line 33):
LSIsubgraph G'i ¼ isLSIsubgraph (s, d) … given vertices s and d, the - If the out-degree of the vertex sy is greater than zero (line 34),
method determines whether the vertices s and d identify an LSI sub- then the vertex sy, where sy is the destination vertex of the out-
graph by checking the cases that are discussed below. If it does going edge from s, i.e., the edge (s, sy), is the entry node of the
discover an LSI subgraph, it is returned by the method; otherwise, the next LSI subgraph, and hence, the node s is the exit node of the LSI
method returns null. We first discuss the special cases that exist for subgraph. The found LSI subgraph is added to the set of LSI
the vertices that represent the BPMN Start and End event elements. subgraphs that are output (lines 35–37).
o If the in-degree of the vertex, say s, is zero, then the vertex repre- - If the out-degree of the vertex sy is equal to 1 (line 39), then the
sents the BPMN Start element, and hence cannot be an exit node. vertex s is neither an exit nor an entry node, and the s.root
The s.root attribute is set to s as it will be the entry node of an LSI attribute is set to refer to the s.root attribute of the vertex that has
subgraph, which is also the root node of the subgraph. an outgoing edge that points to s.
o If the out-degree of the vertex is zero, then the vertex represents the - As a note, if the out-degree of the vertex sy is equal to 0, then sy
BPMN End event element. It is treated as an exit vertex of an LSI represents the BPMN End element, in which case nothing needs to
subgraph. be done as the node sy will be processed on a subsequent iteration
vertex sx ¼ pointedToBy(s) … The method returns null if the vertex s of the while loop.
does not have any incoming edges or if it has more than one incoming
edge. Otherwise, it returns that vertex sx that is the source for the only Once all nodes are processed, the algorithm performs a post-
edge leading to s, i.e., it returns that vertex sx for which there exists an processing step that ensures that any LSI subgraphs that were discov-
edge e ¼ (sx, s). ered and added to the set G^ and that have the same entry and exit nodes
are combined into one LSI subgraph. For instance, if the algorithm out-
The algorithm uses a breadth-first search traversal of the DAG G, puts two separate independent subgraphs G1 and G2, where G1 and G2
starting with graph node s that represents the BPMN Start event element, are:
while its output has been described already. We now discuss the details of
the findLSIsubgraphs() algorithm that is shown in Fig. 6. 1. G1 ¼ {v11, v12, v21, sex} and E1 ¼ {(sen, v11), (v11, v12), (v12, sex), (sen,
The first part of the algorithm deals with initialization that sets the v21), (v21, sex)}
attributes of each node of the DAG G, namely, s.inDegree, s.outDegree, 2. G2 ¼ {v21, v31, v32, v33, sex} and E2 ¼ {(sen, v21), (v21, sex), (sen, v31),
and s.root. Following that, there is a while loop that is used to determine (v31, v32), (v32, v33), (v33, sex)}
whether the node s, returned by the nextInSearchOrder (G), is an exit node
of an LSI subgraph and whether that node identifies an LSI subgraph, Then the post-processing step combines all independent subgraphs
which has been found and should be included in the set of LSI subgraphs that have the same entry and exit nodes into one subgraph. For the
output by the method, or whether it is some other case and how it should example of G1 and G2, the post-processing step combines the two sub-
be handled. These cases are now discussed by making specific references graphs into one, as shown in Fig. 5.
to the lines of the algorithm presented in Fig. 6. The significance of decomposing the BPMN model into DE-HSM sub-
Line 18 within the while loop checks the in-degree of the vertex s. If models that satisfy the property of LSI subgraphs is that the LSI subgraphs
the in-degree of the vertex s is zero, then the vertex s represents the BPMN lead to sub-models that can be modeled directly by a DE-FSM model, i.e.,
Start element, and hence it is an entry node of an LSI subgraph. If it is, they do not need any further decomposition into sub-models.
then the s.root attribute is set to s as it will become a root node of an LSI
subgraph. The while iteration exits and another iteration starts (lines 4.4.6. Example
24–26). Note that for the vertex representing the BPMN Start element, its Consider the sample supply chain BPMN model shown in Fig. 3 that
out-degree cannot be greater than one, as only a fork gate can have an was also used in Refs. [16–18]. Applying the algorithm findLSIsub-
out-degree greater than one. graphs() results in the LSI subgraphs, listed by the method foundSubgraph,
which are shown in Fig. 7 and are shown below.
If the s.inDegree >1 (line 23), then the vertex s is an exit node, an LSI
subgraph has been discovered and added to the set of LSI subgraphs S1 This subgraph contains INIT, buyer send offer, manufacturer
G^, and the loop is exited (lines 24–26). receive order, calculate demand, manufacturer place order, and
middleman receive order.
14
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
S2 This subgraph contains forward order, order transport, supplier node of the next LSI subgraph, and hence the node s is the exit node of the
receive order, produce, order transport, prepare transport, carrier subgraph. Consequently, the statements in lines 35–37 are executed and
receive order, supplier receive request, and request details. an LSI subgraph, with the entry node being the vertex representing the
S3 This subgraph contains provide details, provide waybill, receive INIT element and the exit node being the Middleman receive order BPMN
details, and receive waybill. element.
S4 This subgraph contains carrier deliver order, manufacture receive
order, report start of production, manufacturer deliver product, buyer
receive product, and SUCCESS. 4.5. Building DE-FSM sub-models and their interconnection
To explore how the algorithm works, consider its execution after its Thus far, we have described how to determine a DE-HSM model, that
initialization, when the while loop is executed. The breadth-first search is, how to find a DE-HSM model for which each of its sub-models does not
traversal returns the INIT node as the first node. Thus, the node s in the contain any further sub-models. In this section, we describe how to build
while loop refers to the INIT node, which represents the BPMN Start each of the DE-FSM sub-models and interconnect them.
element, on the first iteration of the loop, at which point s.root ¼ s, which
represents the fact that the node s will be the entry node of the LSI 4.5.1. Building a DE-FSM submodel
subgraph that will be discovered. Following the first loop, subsequent The previous section described how to find a DE-HSM model for a
loops retrieve nodes: Prepare Order, buyer send order, manufacturer given graph G that represents the BPMN model. The DE-HSM model is
receive order, and Calculate Demand. All the listed vertices have exactly represented by a graph G^ ¼ (S^, E^), such that each S^i ⊂ S^ represents a
one incoming and one outgoing edge and thus cannot be exit nodes of an subset of nodes of the graph G, where the nodes of S^i, i ¼ 1, 2, …, n^, are
LSI subgraph. As a result, their processing by the while statement will set also the nodes of a subgraph G'i ¼ (S'i, E'i) of G, where S'i ¼ S^i is a set of
the attribute s.root to refer to the vertex representing the INIT node, as set nodes representing an LSI subgraph that is an FSM sub-model.
by line 39; that the vertex will become a root of an LSI subgraph. Given an LSI subgraph G' ¼ (S', E') that represents a DE-FSM sub-
Assume that all nodes from the node INIT to Calculate Demand have model, we build its model using a breadth-first search traversal of its
been processed by the while loop, and now the reference to the node graph G'i ¼ (S'i, E'i), starting at its entry node sen. Recall that each sub-
Manufacturer Place Order has been returned by the method in the while model represents a DE-FSM model that uses one DE queue, which is
statement while s ¼ ((nextInSearchOrder (G)) 6¼ nil) do, and that the shared by all sub-models, and an FSM that represents functionality. Also
reference to that vertex has been stored in the variable s. Since both the recall from the previous section that described how to find the DE-HSM
in-degree and out-degree are one for the node s, lines 33–40 of the model that a fork gate denotes an entry node of an LSI subgraph, while a
method in Fig. 6 are executed next. As the out-degree of the node sy, merge gate is an exit node/vertex from an LSI subgraph. However, an LSI
where the vertex sy is the destination vertex of the edge (s, sy), is also 1, subgraph is such that each of its vertices, that is, neither the entry nor the
the vertex s is neither an entry node nor an exit node, and hence the exit vertex of the subgraph has exactly one incoming and one outgoing
attribute s.root is set to s.root ¼ (pointedToBy(s)).root ¼ s, as was done edge. Thus, with the exception of its entry or exit nodes, there are no
by while loop processing of the previous vertices. other vertices that represent a gate. As a consequence, the translator
In the next iteration of the while loop, the node returned by the creates the sub-model in two phases.
breadth-first search method is the node s that represents the Middleman The first phase corresponds to the flow control entering the sub-
receive order BPMN element. As both the in and out degrees are equal to model during the execution phase; that is, when the flow control rea-
1, lines 33–40 are executed. As the out-degree of the node sy, where the ches the subgraph's entry node. Depending on the type of the entry node,
vertex sy (represents the forward order BPMN element) is the destination further execution may proceed as one processing stream for an exclusive
vertex of the edge (s, sy), is greater than 1, then the vertex sy is the entry fork gate or more than one processing stream in the case of an inclusive
fork gate. Note that an exclusive or inclusive fork gate may have a guard
15
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
along each outgoing edge, wherein a guard along an outgoing edge the sub-model represents, and the transformation into a sub-model de-
represents the constraint that the FSM's input must satisfy for the pends on whether the BPMN element is not a gate, is an exclusive fork
execution to proceed along that edge. Of course, for an exclusive gate, gate, or is an inclusive fork gate:
guard constraints must be such that only one evaluates to true at any one
time. Thus, an inclusive fork gate also covers a parallel fork gate when all The entry node is not a gate. The processing within the sub-model is
guards are set to true. represented by a single stream with the functionality represented by
If the entry node of the LSI subgraph represents an exclusive fork gate an FSM. The translator builds the root of the FSM, with the rest of the
BPMN element, then in the first phase, the root of the FSM is created. For FSM states created by examining each of the nodes of the subgraph as
an exclusive fork gate, in addition to the root of the FSM, additional states described below in the main phase that builds the FSM transitions.
are appended for a binary search that will result in identifying a path that The entry node is an exclusive fork gate. The processing within the
represents the control flow along each of the paths from the entry node to sub-model is represented by a single stream with the functionality
the exit node. For instance, if there are four outgoing edges from an represented by one FSM. The translator builds the root of the FSM,
exclusive fork gate with the guards being A, B, C, and D, then Fig. 8 shows and then it inserts states that check the input and perform a binary
the vertices added to the FSM in order to identify the path for each of the search using guards of the exclusive gateway to determine on which
outgoing edges to the exit node. In the second phase, in each iteration of path, from the entry node to the root, is a new transition inserted (as
the search, a new state is added on a path for which the input satisfies the shown in Fig. 8).
guards. In short, there is one FMS for an entry node that represents an The entry node is an inclusive fork gateway. The processing within
exclusive fork gate, such that the FSM's root is followed by transitions the sub-model is represented by multiple concurrent streams by
that result in n paths, one path for each of the outgoing streams from the creating one concurrent FSM for each of the outgoing concurrent
gate. In the subsequent phase, state transitions are built along the out- streams outgoing from the entry node that represents the inclusive
going paths, each one representing functionality for one of the guards on fork gate BPMN element. In addition, the translator also generates the
the exclusive fork gate. control FSM that is used to direct input coming into the sub-model
If the entry node represents an inclusive fork gate BPMN element, into an appropriate FSM for an outgoing flow-control stream deter-
then the translator creates nþ1 FSMs if there are n outgoing streams out mined by examining the input to the FSM using constraints repre-
of the inclusive fork gate. In addition, one FSM, referred to as a control sented by the guards on outgoing edges of the BPMN gateway. As in
FSM, is created to determine at the execution time, to which of the the previous case of an exclusive gateway, the translator inserts into
outgoing streams from the fork gate does the input to the FSM belongs the controlling FSM states that check the input using Boolean ex-
when an FSM fires, i.e., when it receives input to which it needs to react. pressions appearing in the guards of the gate that the node represents,
The controlling FSM is used in the execution phase to determine to which as shown in Fig. 9.
of the FSMs should the input be directed depending on the evaluation of
the guards; the identification of the FSMs for which guards evaluate to b) Main phase
true is the output of the controlling FSM's firing. In addition, when the
exit from the firings of the controlling FSM is reached, the flow of control In the main phase, subgraph vertices are processed, vertices that have
is directed towards each of the concurrent FSMs for which the guard is exactly one incoming and one outgoing edge. Such vertex results in a new
evaluated to be true. This is achieved by the monitor component at run- FSM state and transition to be added to an FSM. For an inclusive fork
time by creating a DE event for each of the guards that evaluates to true. gateway, the new state, and its transition are added to the appropriate
For each one, the monitor inserts a DE event that causes it to fire and concurrent FSM, while for the exclusive fork gateway, the new state and
hence causes execution of the firing of the corresponding concurrent FSM its transition are added to the appropriate path of the one FSM that has
when the event reaches the head of the queue. Fig. 9 shows the inclusive one path, from the subgraph's entry node to its exit node, for each of the
fork gate and the resulting control FSM and the concurrent FSM. outgoing edges out of an inclusive fork gateway.
Once the FSMs are prepared, a breadth-first search of the nodes of the
subgraphs is used to build the transition states of the concurrent FSMs. 4.5.2. Connecting the sub-models
For an exclusive fork gate, all transitions are in the one FSM along the Once the sub-models are built, the overall model is built by finding
paths from the root to the exit node, wherein the initial vertices are the subgraph that contains the node that represents the BPMN Start
created by the translator in the initial phase to guide the input to the event—call it the start subgraph. The overall model is now built by
appropriate path using the guard conditions. For an inclusive fork gate, interconnecting the sub-models. The exit node of the start subgraph is
for each node of the breadth-first search, the translator first determines to connected to the entry nodes of LSI subgraph i, for which there is an
which of the FSMs the node belongs, and then the translator augments outgoing edge from the exit node of the start subgraph that leads to the
the corresponding FSM with the state transition for the node. Both phases entry node of the LSI subgraph i. For each such interconnection, the
are now described. translator takes the output from the FSM of the exit node and creates a DE
event that is queued into the DE queue, with the event being targeted for
a) Initial phase—Entering a sub-model processing by the FSM that represents the functionality of the LSI sub-
graph i. This process repeats for each of the LSI subgraphs.
The translator examines the BPMN element that the entry vertex of
Fig. 8. Entry node that represents an exclusive fork gate and FSM transitions as paths of FSM.
16
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
Fig. 9. Entry node that represents an inclusive fork gate and control FSM, and one FSM for each of the concurrent process streams.
5. Transforming a DE-HSM model into methods of a smart 5.2. Sidechain processing for privacy and cost reduction
contract
After the BPMN model is transformed into a DE-HSM model and in-
In the following subsections, we overview the transformation of the dividual sub-models are developed, but before the transformation into
DE-HSM model into the methods of a smart contract. We only perform an the methods of a smart contract, the developer is offered a design choice
overview, as our approach has been described in Refs. [32,43,44] and, in to deploy a part of the smart contract for processing on a sidechain for the
some respects, is similar to the work of others. However, we differ in purposes of privacy, reducing the processing cost, or both. To make that
providing the developer with the functionality to deploy parts of the decision, sub-models are presented to the developer to select those that
smart contract to be processed on a sidechain for the purposes of should be deployed on a sidechain. Actually, as a part of testing and
reducing the cost and/or increasing privacy, and those are the aspects before the final deployment, two versions of the smart contract are
that we highlight in more detail. developed and deployed: In one, the sub-models selected by the devel-
oper are deployed and executed on a sidechain, while in the second
5.1. Creating and deploying smart contract methods version, all smart-contract methods are deployed and processed on the
mainchain. Delays are measured for both versions, and the results are
During the contract execution phase, user participants and their sys- provided to the developer so that she/he can compare the cost of the
tems interact with a DApp that, in turn, makes calls to the DApp API that smart contract execution, on the mainchain-only versus on the mainchain
our system provides. At run-time, once a smart contract method is with sidechain processing of sub-models selected by the developer. The
invoked, its input is analyzed, and it is used to create an appropriate developer has information on the incurred delays in both cases, and if the
event that is queued into the DE queue. The DE queue contains events mainchain or sidechains use Ethereum EVM, such as Quorum does, cost
that are continuously dequeued and processed. Processing of a DE event estimates in ETH gas are also provided to the developer.
includes (i) analysis of the DE event that determine which FSM is to fire We first describe our system architecture for the run-time phase with
and prepares input for that FSM; (ii) input is given to the FSM; (iii) FSM sidechain processing. We then describe how we assist the developer in
fires and produces output; and (iv) FSM output is transformed into a determining which parts of the smart construct are suitable for sidechain
response to the smart contract method invocation. This is all performed processing, either for privacy or for reducing cost. Examples of the use of
under the control of the monitor/mediator, using information prepared sidechains are provided in the following section that describes our PoC,
during the design phase. the TABS tool.
Thus, the run-time architecture of the system is similar to other ap-
proaches in the way the system interacts with the DApp and performs 5.2.1. System architecture with sidechain processing
mapping of the DApp interactions with the API into calls to the methods Fig. 10 shows the system architecture at run-time for the mainchain
of smart contracts and how the system responds to DApp requests. Where and for the sidechain. The internal architecture for sidechain processing
we depart is in how the flow control is managed. is in large part similar to that for the mainchain, which is shown in Fig. 2.
The internal representation of the state of the system is based on the Interoperability between the mainchain and the sidechain is achieved in
DE-HSM model that determines the flowcontrol between the FSM sub- part by a mainchain contract method calling a smart contract method on
models that represent the state of computation of individual DE-FSM a sidechain. There are, however, additional issues involved, as our
sub-models. We faithfully model the BPMN graph using a DE-HSM sidechain contract is really an integral part of the mainchain contract, but
model that is used to channel input into the appropriate sub-model, it is executed on a sidechain. When smart contract methods are moved
where the input is provided to the sub-model's FSM that fires and pro- from the mainchain to a sidechain, of course, they have to be invoked
duces output. Depending on the DE-HSM model, the output produced by from the mainchain. When there is a call on a mainchain to a smart
the FSM may be used as input to another sub-model and the process contract that is deployed on a sidechain, the mainchain method must
repeats, or the output is analyzed and provided as output for the call to redirect the call to the sidechain. However, difficulties arise when state
the smart contract method, which in turn provides its returned parame- variables are accessed during a method executed on a sidechain—a
ters to the DApp method that invoked the DApp API. The channeling of method deployed on a sidechain does not have access to any state vari-
outputs produced by sub-models is according to the interaction between ables stored on the mainchain. For that reason, they need to be fetched
the sub-models as defined by the DE-HSM model, while the function of from the mainchain and stored on a sidechain, which acts as a cache.
each sub-model is represented by an FSM, or a group of FSMs if the sub- Consequently, on the first call to a method deployed on a sidechain, in
model has concurrent processing indicated by the inclusive fork gates, addition to the call parameters, also included are the blockchain data that
which also faithfully models a part of the BPMN graph that is a BPMN LSI will be accessed by the method. At the design time, static analysis of the
subgraph. sidechain code is used to determine which data is provided on the first
We also depart from the work of others in that we facilitate off-chain call to a method so that it would populate the cache on a sidechain. Of
processing on a sidechain, which is described next. course, there will still be cache misses due to the sidechain method
referencing objects dynamically.
17
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
5.3. Sidechain processing: what, when, how 5.3.2. When to process on a sidechain (deciding to process a pattern off-
chain)
To process a part of the smart contract off-chain, the following de- Sidechain processing may be cheaper and may be used to decrease the
cisions need to be made: cost of processing a pattern. However, processing a pattern on a sidechain
causes overhead due to interaction between the mainchain and the
What should be processed off-chain, that is, which parts, referred to as sidechain. Thus, from the cost perspective only, sidechain processing
patterns, of smart contracts should be processed off-chain? should be used only if its cost, including the overhead cost, is less than
When should the processing be performed off-chain, that is, under processing the pattern on the mainchain. We determine the cost of pro-
which conditions should sidechain processing be used? cessing on a sidechain that also includes the overhead cost by actually
How to achieve sidechain processing? doing a live test of running the DApp when (a) the smart contract is
deployed on the mainchain only and (b) the pattern is deployed on the
sidechain and thus measuring all delays, including delays due to over-
5.3.1. Identifying patterns suitable for sidechain processing head. If processing on a mainchain or a sidechain involves an EVM, the
The concept of independent subgraphs, which was used to determine cost is also estimated in Eth for each of the smart contract methods and is
the DE-HSM model given a BPMN model, is useful in determining which provided to the modeler.
patterns are suitable for processing off-chain. Processing patterns off- However, another reason to process a pattern on a sidechain may be
chain causes overhead, some of which is due to the sidechain not hav- privacy. A smart contract deployed on the mainchain is such that all
ing access to the mainchain. Consequently, if a pattern interacts with the participants can explore all data stored on the blockchain by the smart
main chain methods, the overhead cost of communication between the contract; hence, there is no privacy that can be provided so that some
mainchain and sidechain arises. For that reason, a pattern moved to the collaborations are private, that is, confidential to other actors.1 For
sidechain should be independent from the other methods of smart con- instance, a subset of actors performs a local collaboration represented by
tract executing on the main chain. And independent LSI subgraphs have a pattern, and that collaboration should be private in that its details (its
the property in that once the flow of control enters the LSI subgraph, the blockchain data) should not be visible to the other participants in the
flow of control does not exit that subgraph until the computation in that smart contract who do not participate in that collaboration. In such a
subgraph is completed when the flow of control exits the subgraph. Thus, case, we should process the pattern on a sidechain, which will provide
if the LSI-subgraph processing is deployed on a sidechain, with the privacy, and the other actors will not be privy to the pattern's processing
exception of the main chain contract passing the application's input as details. Of course, all smart contract participants will be able to see any
parameters to the sidechain, there is no processing on the mainchain data returned by the sidechain computation that is stored on the
until the execution exits from the independent subgraph executed on a mainchain.
sidechain. As the design phase uses the concept of LSI subgraphs to find
the DE-HSM model, each sub-model is represented by an LSI subgraph,
and hence, deploying parts of the smart contract to a sidechain is
1
equivalent to deploying DE-HSM sub-models on the sidechain. The It should be noted that our statements made about privacy were of general
developer is thus provided with the choice of which DE-HSM sub-models nature and that there are blockchains that do provide for privacy. For instance,
should be selected for processing on a sidechain. the Hyperledger Fabric enables defining certain data to be private and not
visible to all participants.
18
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
5.3.3. How to process off-chain responsibility for determining which patterns to process on a sidechain to
Once it is determined which pattern is to be processed off-chain, the the modeler/developer. The tool displays the list of LSI patterns of the
next question is how to facilitate it. A pattern is a set of smart contract smart contract, DE-HSM sub-models, to the developer, who determines
methods such that they are invoked either due to a signal from the DApp which pattern is or is not processed on a sidechain. For informed
API or because they collaborate and invoke each other but “within” the decision-making regarding the cost of processing on mainchain vs. side-
pattern. A smart contract method executing on a sidechain is likely to chain, we deploy the smart contract with and without the pattern
need to know the state of execution and other information stored on the executing on a sidechain to determine their costs/delays and present
blockchain; however, a method on the sidechain does not have access to them to the developer to assist in the decision-making. An example will
the mainchain and its data. Consequently, when transitioning to off- be provided in the next section that describes the TABS tool.
chain execution of a smart contract method, in addition to the parame-
ters passed to the method, the system also needs to find, retrieve, and 6. Tabs tool and evaluation
deliver to the off-chain processing of any mainchain data that the
methods on a sidechain read. Similarly, upon execution returning back to We developed a tool, called Transforming Automatically BPMN
the mainchain, any writes to the blockchain that was performed by the Models into Smart Contracts (TABS), as a PoC that our approach is
off-chain execution of the pattern need to be collected and handed off, feasible and to discover any issues that may arise when a designed system
together with transition outputs, for recording on the blockchain. Finally, undergoes implementation. We first describe the tool and then its
upon completion of a method executed off-chain, before the blockchain is evaluation.
updated with the new state and data values written by the off-chain
method, the results of off-chain execution must be reviewed and 6.1. TABS tool for transforming automatically BPMN models into smart
approved/attested by each of the participants affected by the off-chain contracts
computation. As a consequence of the above, we provide interfaces for
the following three phases when methods of a pattern are deployed on a Transformation starts with a BPMN model specification expressed in
sidechain: XML as per BPMN specifications [37]. The TABS tool invokes the
Pattern start: Upon the first invocation of an off-chain pattern Camunda software platform [36], whichis used by the developer to
method, our software tool prepares appropriate data structures to sup- create a BPMN model and store it in XML format. Fig. 11 shows a partial
port on-chain/off-chain interaction. The most important is a cache for screen of the tool when creating a BPMN model for the supply-chain
mainchain data accessed by the pattern executed off-chain. Off-chain application. Once the modeler creates a BPMN model and stores it in
code uses a local cache for reading and writing blockchain data; its data an XML format, it is used as input to transformations using tabs appearing
structure needs to be prepared. On a cache miss, data are retrieved from under the title. The first two tabs deal with BPMN modeling, one for a
the main blockchain and then stored in the off-chain cache using a getter BPMN choreography, and one for a model expressed in core BPMN ele-
method prepared just for that purpose to retrieve the data from the ments. Note that the term choreography here refers to the BPMN concept
mainchain. For the cache, we use IPFS as a distributed system for storing of choreography that shows “conversations” that eventually need to be
and accessing temporary files and data. When blockchain needs to access elaborated upon by the modeler into a model expressed using BPMN's
or examine the data in the cache, TABS allocates a data resource stored core elements. Thus, the term “choreography”, as used in BPMN, is not to
on the IPFS by tracking the content address of the corresponding data be confused with the term choreography as used in previous work on
stored on the IPFS [39]. transforming BPMN models into smart contracts, in which the term refers
As mentioned before, a simple static analysis of the pattern methods is to the choreography of processes into which a BPMN model is trans-
used to determine which state variables, that is, blockchain data, should formed and wherein the choreography is a major part of the job media-
be passed to the sidechain with the first invocation of the pattern so that tor's job of the system architecture of Fig. 2.
the cache could be populated with them. Of course, any dynamically Once the BPMN model is developed, the modeler's interaction with
accessed data may result in a cache miss. the tool consists of (i) guiding the transformation of the BPMN model into
Pattern middle: After the first invocation, the interaction between the a smart contract using tabs and (ii) supplying the template methods for
off-chain and on-chain communications is concerned with the provision BPMN tasks with code. We facilitate the creation of a smart contract and
and return of appropriate parameters and data for methods executed off- sidechain smart contract(s) either for Ethereum or Hyperledger Fabric
chain. Also, on a cache miss to the off-chain cache, data need to be blockchains. However, the tool does not facilitate the automated creation
retrieved from the main chain using a getter method to service the cache of the underlying blockchain Fabric itself. In fact, the tool supports using
fault. two blockchain types: (i) Hyperledger Fabric and (ii) Ethereum or EVM-
Pattern end: Upon completion of the last method that is executed off- based blockchain such as Quorum. Either type can be used for the
chain, which occurs upon a transition from the off-chain pattern execu- mainchain or for a sidechain(s), wherein the mainchain smart contract
tion to the on-mainchain execution, in addition to the returned param- invokes methods of the smart contract deployed on a sidechain.
eters, the results produced by the off-chain computation that were saved Fig. 12(a) shows a screenshot after the supply-chain BPMN model, as
in a cache are collected and are provided to the attestation procedure shown in Fig. 3, was transformed into the DE-HSM model having the four
executed on the mainchain. Furthermore, once the results are approved LSI subgraphs. It shows the BPMN graph and its LSI subgraphs that have
by attestation, they are recorded on the mainchain. Our default attesta- been identified by the TABS tool. Fig. 12(b) was not generated by the tool
tion is to deliver the results of sidechain processing to each of the par- but was included to show the BPMN representation of the corresponding
ticipants collaborating on the sidechain processing, including the hash of LSI subgraphs of Fig. 12(a).
the results, and receive from each actor the digitally signed hash code of The modeler/developer is also involved in the decision-making on
the result (signed by the private key), thus signifying that the actor ac- which of the independent subgraph patterns should be deployed on a
cepts the results. If the results are not accepted by an actor, an exception sidechain in the form of a separate smart contract that interacts with the
is raised. Of course, the default attestation method may be replaced by an main contract deployed and executed on the main blockchain. The
attestation method provided by the developer. modeler then selects which of the Ethereum or Hyperledger Fabric is to
be used for each of the mainchain and a sidechain—for testing purposes,
5.4. Sidechain processing control we have local blockchains, one for each of the Ethereum and Hyperledger
Fabric. On Hyperledger Fabric, we also have channels prepared that are
As sidechain processing may be used for either cost reduction or used for the deployment of smart contracts for both the mainchain and
privacy, our tool, described in the next section, delegates the sidechains. For sidechains compatible with Ethereum, we use the
19
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
Fig. 11. TABS tool invoking the Camunda platform to create a BPMN model of the supply chain application.
Quorum sidechain. useful to the modelers. The cost for the case when Hyperledger Fabric is
Once the selection is made by the developer, the model is transformed used depends directly on the cost of the underlying blockchain infra-
into the methods of smart contract(s) that are deployed and executed. structure, and we have not tackled yet how to derive it. As in the case of
The modeler can examine the generated system by stepping through the public Ethereum blockchain, blockchain as a service for Hyperledger
execution message-by-message, while the tool shows the progress Fabric is not cheap, and it depends on the blockchain configuration in
graphically by showing the change to states of the individual FSMs rep- terms of the network nodes, network bandwidth, etc.
resenting the DE-FSM sub-models. This feature is helpful in testing and
manual verification. Delays are also shown as execution proceeds step by 6.2. Evaluation
step.
To evaluate the latency and cost of the overall execution, the tool As mentioned above, we developed the TABS tool as a PoC so that our
facilitates the execution of each method while measuring its latency and approach is feasible and to explore its properties, such as latency and
cost. It should be noted that we show the USD cost of execution in Wei (or cost. We first outline our evaluation method and then discuss the use
GWei) [45] for Ethereum or EVM-based blockchains/sidechains only. cases we tested, transformation correctness, latency, and cost.
Latency and costs are calculated for two cases: (i) when all methods of
smart contracts are deployed on the mainchain only, and (ii) when 6.2.1. Evaluation method
execution proceeds on the mainchain with the selected patterns deployed The TABS tool is a typical two-tier application. The frontend was
on a sidechain. Thus, the developer can compare the latency and costs mainly written in NodeJS, which focuses on tasks such as:
when execution is on the mainchain only and when the selected patterns
are processed on a sidechain. Fig. 13 exhibits a screenshot showing the a. Establish a distributed message channel with backend IPFS nodes.
cost of execution on a local Ethereum mainchain and a local Quorum b. Provide the canvas to the user for composing the BPMN diagram; this
sidechain, where the cost of execution is in GWei and is derived by was implemented by BPMN.io [47].
adding the cost of individual Solidity instructions of the smart contract c. Transform the BPMN diagram to DE-HSM mode. This part was
methods using Web3.js [46]. As far as the cost is concerned, for Ether- powered by the GraphViz JS library [48].
eum, we estimate the cost in GWei units using Web3.js, which is certainly
20
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
Fig. 13. Stress testing smart contract method execution of bulk business processes.
d. Provide the Ethereum Solidity abstract interfaces and Hyperledger The evaluation process of a use case starts with BPMN modeling. At
NodeJS abstract interfaces for smart contract transformation. The the end of modeling, TABS automatically transforms the BPMN model to
interfaces were coded in Solidity and NodeJS, respectively [49,50]. a DE-HSM model during the design phase. The modeler then provides the
e. Compile the smart contract with Ethereum powered by NodeJS code for the tasks of the BPMN elements. The DE-HSM model is presented
worker threads [51]. to the modeler together with information on the cost of execution on the
f. Compile the smart contract with IBM blockchain platform developer mainchain only and on the mainchain with sidechain processing of the
tools [52]. selected subgraphs. The modeler uses this information to select which of
g. Deploy the Ethereum smart contract with EtherJS and Web3.js [46, the LSI subgraphs are to be deployed and processed on a sidechain, and
53]. then chooses which of the Ethereum Solidity and Hyperledger chainc-
h. Deploy the Hyperledger Chaincode with the Microfab API [54]. odes are to be used for the smart contract generation on the mainchain
i. Establish the IPFS message channel with the IPFS API [55]. and a sidechain. The generated code for the smart contract(s) may be
j. Implement evaluation and simulation process with NodeJS [56]. reviewed by the developer.
Once the compiled smart contracts are deployed on blockchain net-
We use three cloud servers provided by DigitalOcean cloud [57]. Each works, the modeler can choose which evaluation process should be used
server is equipped with 2 CPUs, 4 GB memory, and 80 GB disk space. The for the run-time phase. The modeler can observe the invocation of the
operating system running on the servers is Ubuntu. We installed, smart contract methods. The TABS tool allows the modeler to evaluate
configured, and ran Ganache-CLSI on each server with different param- the deployed model by an input stream that simulates the expected input
eters to emulate a realistic working environment. The mainchain block- from the DApp as it would be submitted by the DApp to the DApp
chain was configured with different parameters for block time, endorsers, interface. Measured are delays per smart contract call, for completion of
and block size, but with values that are close to the public Ethereum executing a sub-model, or per execution of the DApp application (on the
blockchain, while the sidechain networks were configured as Quorums BPMN diagram, from the Start event to the End event).
for Ethereum smart contract and Microfab for Hyperledger Chaincode.
Moreover, our TABS tool allows testers to deploy smart contracts on 6.2.2. Use cases
actual public Ethereum and Ropsten sidechains as long as users have For our evaluation purpose, we used three different use cases.
sufficient cryptocurrency on those blockchains [58]. Furthermore, each
server is an IPFS node located in a preconfigured IPFS private cluster so 1. Supply Chain: This use case was adopted from Ref. [16] and was
that each participant has dedicated access to the corresponding IPFS discussed throughout this paper as a running example (see Figs. 3 and
node and data space. 7). The model has ten tasks and four gateways. The supply chain use
21
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
case begins with the buyer issuing a new order. Once the manufac- a) Latency
turer receives the order, she/he calculates demand and places an
order with a middleman. The middleman concurrently sends the The TABS tool can measure various latencies, ranging from one FSM
order to the supplier, and orders are transported from the carrier. The state transition, through latency for executing a sub-model or a smart
producer fabricates the product and prepares it for transport. The contract method, to latency for the whole DApp. Fig. 16 shows the delays
carrier, upon receiving the request from the middleman, requests in milliseconds for each use case execution and for each Ethereum and
details from the supplier. The supplier provides the details to the Hyperledger Fabric. Due to the more complex consensus algorithm,
carrier and then prepares and provides the waybill to the carrier. Ethereum exhibits much higher delays than Hyperledger.
Upon receiving details about the product and the waybill, both from
the supplier, the carrier delivers the order to the manufacturer. Upon b) Cost
receiving the order, the manufacturer starts the production, and when
that is finished, it delivers the product to the buyer, who receives the Costs per method and the overall cost can also be estimated auto-
order. matically through TABS by using web3.js [46], which enables the
2. Order Process: This process is adopted from Ref. [59], and its BPMN calculation of the cost for each instruction. The cost in GWei for each of
diagram is shown in Fig. 14(a). It is a relatively straightforward use the three use cases is shown in Table 1 for each of the three use cases. The
case with five tasks and two gateways. The use case starts with the table also shows the cost, in USD at rates prevailing at the time of mea-
customer preparing an order that is delivered to order handling. surements, of one application workflow for each use case for the public
Order handling checks the order and then concurrently (i) confirms Ethereum. As the Hyperledger Fabric is a private blockchain, the cost is
the order with the customer and (ii) initiates shipment preparation by primarily due to hardware and network costs.
the shipper. The shipper prepares the order for shipment and then
sends it to the customer. Upon receiving the order confirmation and 6.2.4. Correctness (non-conforming vs. conforming traces)
the order from the shipper, the customer accepts the order, which In published research on transforming BPMN models to smart con-
completes the workflow. Fig. 14(b) shows the BPMN diagram with tracts, reporting was done on the correctness of the smart contract by
the three found LSI subgraphs identified by the colored rectangles. recognizing conforming and non-conforming traces, wherein a trace is an
3. Trade: We reported on this use case in some detail in our previous input stream from the DApp. A conforming trace represents input from
research [43]. The use case was adopted from Ref. [60], and it con- the DApp that is correct in terms of the correctness of the input provided
tains 19 tasks and five gateways. As the BPMN diagram of the by the DApp at appropriate points of a smart contract execution. The
application would be too busy, we show in Fig. 15 its state diagram smart contract should recognize incorrect input provided by the DApp.
representation with some of the independent subgraphs also shown. We tested the smart contract implementation and reported that 100%
The model shows that the product is posted for sale, and after the accuracy was achieved in recognizing conformant and non-conformant
offer is made, the buyer and seller negotiate the price. Once an input sequences/traces. This is not surprising—after all, the smart con-
agreement is reached on the price, a contract is prepared and signed tract is built through DE-HSM modeling that transforms the BPMN model
that stipulates escrow deposit and the matter of delivery. Once the into a DE-HSM model that, in essence, is formed by a 1-to-1 mapping
buyer makes a deposit to an escrow account, the shipment proceeds to between the BPMN model and the DE-HSM model as a collection of DE-
the port. The shipment includes crossing borders, and hence, involves FSM sub-models, wherein each sub-model corresponds directly to the
customs. Afterwards, the shipment is loaded on a ship, delivered to a BPMN diagram when viewed as a DAG. Thus, in the absence of errors in
port, and then processed at the destination customs. It is then the TABS tool, the recognition of correct and incorrect sequencing in
unloaded from ship to port, picked up by the buyer, payment terms input should be 100%.
are executed, and finally, the escrow deposit is returned.
6.2.5. Sidechain processing
6.2.3. Latency and cost One of the distinguishing features of our approach is that we can
We now report on the evaluation of the three use cases in terms of move blockchain patterns, represented as individual DE-HSM sub-
latency and cost. However, the cost is derived only for Ethereum using models, to the sidechain for either of the following two purposes or their
Web3.js [46], which estimates the cost of each instruction in a smart combination: (i) reducing the cost of processing and (ii) privacy.
contract in Wei. In this section, we simply report observed values as we
are unable to do a comparison with the other reported work because a) Sidechains for cost reduction
hardware and software configurations and environments vary greatly.
We report observed values for each case when Ethereum is used and Deploying patterns for processing on a sidechain for the purposes of
when the Hyperledger Fabric is used. We comment on our observations reducing the cost of processing is useful only when sidechain processing
when sidechains are used for off-chain processing in the next subsection. is cheaper in comparison to mainchain processing. This is important for
Fig. 14. BPMN diagram for the Order Proces use case (adopted from Ref. [60]).
22
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
Fig. 15. State transition diagram for the trade business use case (adopted from Ref. [44]).
Fig. 16. Latency for each of the three use cases for Ethereum and for Hyperledger Fabric.
23
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
Fig. 17. Ethereum cost of processing on mainchain only vs. processing on mainchain with sub-models on a sidechain.
sidechain, as long as it (sidechain blockchain) is cheaper than the process and provides the necessary information to the tool, such as the
mainchain. code for template methods implementing BPMN task elements or infor-
For each use case, we calculated the cost of processing one execution mation on which parts of the smart contract should be deployed on a
of a smart contract. For each use case, Fig. 17 shows the cost of processing sidechain. In addition, the modeler/developer can use the tool to explore
on the Ethereum mainchain only and then when a Quorum sidechain is the execution properties of the methods of the smart contract. Currently,
used with the mainchain. When sidechain processing is used, for each use our tool provides the creation and deployment of contracts for either
case, we select all sub-models to be processed on a sidechain. The Ethereum or Hyperledger blockchains.
selected sub-models are identified by either colored or dashed rectangles The following two features are the major differences from the work
in Figs. 7, 12 and 15. Fig. 19 shows that because the Quorum cost of reported by others.
processing is much lower than the cost of professing on the mainchain,
processing off-chain is very advantageous. We analyze the BPMN diagram and use DE-HSM modeling to identify
We also compare the latency of processing, which is shown in Fig. 18, patterns, referred to as LSI subgraphs, that are localized in that once
for the mainchain processing on Ethereum and for the mainchain with execution of the pattern starts, it remains local to the pattern until
sidechain processing on Quorum for each of the use cases. Latency is also there is an exit from that pattern. Furthermore, each pattern has only
reduced by sidechain processing. Similarly, we used sidechain processing one “entry” and one “exit” point. Such patterns naturally lend
for Hyperledger Fabric by deploying the main smart contract on one themselves to decomposition purposes that our approach exploits. We
Hyperledger channel and a sidechain on another channel of the same use such patterns for forming the sub-models, wherein the function-
Hyperledger Fabric blockchain. Not surprisingly, latency with sidechain ality of each sub-model is represented by an FSM or concurrent FSMs.
processing is higher than just processing on the mainchain only, as shown The choreography (not a BPMN term) of processes, that is, the
in Fig. 19. Sidechain processing on a Hyperledger is achieved by using workflow determining which sub-models are executed in which
another Hyperledger channel that incurs the same cost as processing on sequence, is guided by the interconnections amongst the sub-models,
the mainchain, which is also a Hyperledger channel. Due to the overhead while the functionality of each sub-model is represented by an FSM,
to facilitate sidechain processing, latency is higher when sidechain is or possibly a number of concurrent FSMs. The interconnection of the
used. sub-models is represented by the DE-HSM model. Consequently, as
the DE-HSM is a model that is an equivalent representation of a BPMN
b) Sidechains for privacy model, the correctness of representing the BPMN model using the DE-
HSM model is assured.
As discussed already, sidechains may also be used for privacy. In more We provide for the transformation of sub-models, selected by the
complex smart contracts, such as the trade use case, certain parts of the modeler, into a separate contract that is deployed and executed on a
contract should not be visible to all participants of the smart contract. For sidechain, while the main smart contract interacts with the DApp and
instance, after the buyer and seller agree on the price, the price should invokes these sidechain methods as is appropriate. Sidechain pro-
not be visible to some of the other actors. By choosing to deploy and cessing may be chosen by a modeler (i) to reduce the cost of pro-
execute an independent subgraph pattern, i.e., a sub-model, on a side- cessing if sidechain processing is cheaper than processing on a
chain, privacy is also provided, as only the actors who participate in the mainchain (e.g., processing on a Quorum sidechain in conjunction
sidechain sub-model execution can observe all data pertaining to that with the main contract being deployed on the public Ethereum
sidechain processing, while the other actors do not have access to that blockchain) or (ii) to support privacy by processing a pattern on a
data. However, all actors have access to the results of computation that sidechain.
are stored on the mainchain. As was already noted before, the above
statements are subject to privacy features of individual blockchains, as We made several simplifying assumptions on the BPMN model, such
some blockchains, such as Hyperledger Fabric, do support private data on as limited looping/repeating or parallel sub-processes, and no feedback
a channel that is not visible to other participants. loops in the BPMN model that cannot be expressed as looping or con-
current sub-processes that need to be addressed. The tool's limitation is
7. Concluding remarks that, prior to the execution of a looping sub-process, the number of it-
erations needs to be known. The assumption on the parallel sub-processes
This paper contributes to the research on generating smart contracts is more restrictive in that the maximum number of parallel streams to
from a BPMN model. As in previously reported research, we minimize the execute a parallel sub-process needs to be known at the time of trans-
modeler's interaction with the system in that once the BPMN model is forming the BPMN model into the methods of a smart contract. We are
input, the modeler simply guides the tool in the generation of the smart investigating approaches to reduce or remove these limitations.
contract methods. The modeler guides the tool in the transformation The BPMN standard defines a transaction on a sub-process, in which
24
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
Fig. 19. Hyperledger latency of processing of all on one channel vs.sub-models on the Quorum sidechain. processing sub-models on another channel.
case the whole sub-process must be completed or any activity of the sub- Declaration of competing interest
process must be undone by a compensating transaction if the sub-process
is unable to be completed successfully. As was already discussed before, a The authors declare that they have no known competing financial
blockchain also has a transaction that is defined as any set of ledger interests or personal relationships that could have appeared to influence
updates made by the execution of a single smart contract method. How- the work reported in this paper.
ever, a trade transaction is long-term and may include many activities,
activities performed by a subset of the application participants on a References
subset of data used by the application. And these three different concepts
do not align. How to support long-term trade transactions, which span a [1] J. Eberhardt, S. Tai, On or off the blockchain? Insights on off-chaining computation
and data, in: F. De Paoli, S. Schulte, E. Broch Johnsen (Eds.), Service-Oriented and
number of calls to the smart contract methods, is still an open question Cloud Computing, Springer, Cham, 2017, pp. 3–15, https://doi.org/10.1007/978-
that we are currently addressing. There are also some of the BPMN ele- 3-319-67262-5_1.
ments, such as error, escalation, and multiple parallel attributes, that our [2] J. Poon, V. Buterin, Plasma: Scalable Autonomous Smart Contracts, 2017. https://p
lasma.io/plasma.pdf. (Accessed 12 November 2020).
TABS system does not support, but we are working on their incorporation [3] D. Yang, C. Long, H. Xu, et al., A review on scalability of blockchain, in: Proceedings
into the system. of the 2020 the 2nd International Conference on Blockchain Technology
Currently, we provide a demo and limited-term online access to the (ICBCT'20), ACM, 2020, pp. 1–6, https://doi.org/10.1145/3390566.3391665.
[4] Shard Chains | Ethereum.Org. ethereum.Org, 2021. https://ethereum.org/en/eth
tool upon request that can be made by emailing Chris.Liu@dal.ca. In the 2/shard-chains/. (Accessed 26 March 2022).
near future, we plan to prepare appropriate documentation to facilitate [5] P.J. Taylor, T. Dargahi, A. Dehghantanha, et al., A systematic literature review of
future potential collaborations. blockchain cyber security, Digit. Commun. Netw. 6 (2) (2020) 147–156, https://
doi.org/10.1016/j.dcan.2019.01.005.
Of course, our current implementation is only a PoC, and many issues
[6] S.N. Khan, F. Loukil, C. Ghedira-Guegan, et al., Blockchain smart contracts:
still need to be addressed. For instance, as contract execution consists of applications, challenges, and future trends, Peer-to-Peer Netw. Appl. 14 (2021)
the removal of events from the DE queue and processing them, issues of 2901–2925, https://doi.org/10.1007/s12083-021-01127-0.
efficiency and scalability need to be addressed. The use of a global logical [7] A. Vacca, A. Di Sorbo, C.A. Visaggio, et al., A systematic literature review of
blockchain and smart contract development: techniques, tools, and open challenges,
clock to timestamp events, which are stored in the timestamp-priority J. Syst. Software 174 (2021), 110891, https://doi.org/10.1016/j.jss.2020.110891.
ordered queue DE queue, may also lead to scalability issues that need [8] R. Belchior, A. Vasconcelos, S. Guerreiro, et al., A survey on blockchain
to be investigated. We note that the properties of trade applications are interoperability: past, present, and future trends, ACM Comput. Surv. 54 (8) (2021)
168, https://doi.org/10.1145/3471140.
such that the speed of processing is not a priority as the transactions in [9] K. Saito, H. Yamada, What's so different about blockchain? — Blockchain is a
this vertical are relatively long-term. The issue of scalability may arise probabilistic state machine, in: Proceedings of the 2016 IEEE 36th International
due to the increase in the complexity of applications and in the number of Conference on Distributed Computing Systems Workshops (ICDCSW), IEEE, 2016,
pp. 168–175, https://doi.org/10.1109/ICDCSW.2016.28.
applications that need to be supported. [10] J.A. Garcia-Garcia, N. Sanchez-G omez, D. Lizcano, et al., Using blockchain to
improve collaborative business process management: systematic literature review,
Author contributions IEEE Access 8 (2020) 142312–142336, https://doi.org/10.1109/
ACCESS.2020.3013911.
[11] C. Lauster, P. Klinger, N. Schwab, et al., Literature review linking blockchain and
All three authors participated in research and writing of this paper. business process management, Proc. 15th Int. Conf. Wirtschaftsinformatik..GITO.
(2020), https://doi.org/10.30844/wi_2020_r10-klinger.
25
P. Bodorik et al. Blockchain: Research and Applications 4 (2023) 100115
[12] O. Levasseur, M. Iqbal, R. Matulevicius, Survey of model-driven engineering International Conference on Engineering and Emerging Technologies (ICEET),
techniques for blockchain-based applications, in: Proceedings of the 14th IFIP WG IEEE., 2021, pp. 1–7, https://doi.org/10.1109/ICEET53442.2021.9659771.
8.1 Working Conference on the Practice of Enterprise Modelling (PoEM’21 Forum), [34] L. Dikmans, Transforming BPMN into BPEL: why and how. https://www.oracle.
CEUR., 2021, pp. 11–20. com/technical-resources/articles/dikmans-bpm.html, 2008. (Accessed 26 March
[13] P. Tolmach, Y. Li, S.-W. Lin, et al., A survey of smart contract formal specification 2022).
and verification, ACM Comput. Surv. 54 (7) (2021) 148, https://doi.org/10.1145/ [35] R.M. Dijkman, M. Dumas, C. Ouyang, Semantics and analysis of business process
3464421. models in BPMN, Inf. Software Technol. 50 (12) (2008) 1281–1294, https://
[14] S. Bragagnolo, H. Rocha, M. Denker, et al., SmartInspect: solidity smart contract doi.org/10.1016/j.infsof.2008.02.006.
inspector, in: Proceedings of the 2018 International Workshop on Blockchain [36] Camunda Modeler, Design business processes and decision models. https://cam
Oriented Software Engineering (IWBOSE), IEEE, 2018, pp. 9–18, https://doi.org/ unda.com/platform/modeler/. (Accessed 29 March 2022).
10.1109/IWBOSE.2018.8327566. [37] Flowable Open Source Documentation, BPMN 2.0 introduction. https://www.flow
[15] J. Mendling, I. Weber, W.M.P. van der Aalst, et al., Blockchains for business process able.com/open-source/docs/bpmn/ch07a-BPMN-Introduction. (Accessed 29 March
management - challenges and opportunities, ACM Trans. Manag. Inf. Syst. 9 (1) 2022).
(2018) 4, https://doi.org/10.1145/3183367. [38] BPMN 2.0 Symbols: a complete guide with examples. https://camunda.
[16] I. Weber, X. Xu, R. Riveret, et al., Untrusted business process monitoring and com/bpmn/reference/. (Accessed 28 October 2021).
execution using blockchain, in: M. La Rosa, P. Loos, O. Pastor (Eds.), Business [39] Object–relational impedance mismatch. Wikipedia. https://en.wikipedia.org/w
Process Management, Springer, Cham, 2016, pp. 329–347, https://doi.org/ iki/Object%E2%80%93relational_impedance_mismatch. (Accessed 26 March
10.1007/978-3-319-45348-4_19. 2022).
[17] O. Lopez-Pintado, L. García-Ba~ nuelos, M. Dumas, et al., Caterpillar: a business [40] M. Steichen, B. Fiz, R. Norvill, et al., Blockchain-based, decentralized access control
process execution engine on the Ethereum blockchain, Software Pract. Ex. 49 (7) for IPFS, in: Proceedings of the 2018 IEEE International Conference on Internet of
(2019) 1162–1193, https://doi.org/10.1002/spe.2702. Things (iThings) and IEEE Green Computing and Communications (GreenCom) and
[18] A.B. Tran, Q. Lu, I. Weber Lorikeet, A model-driven engineering tool for blockchain- IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data
based business process execution and asset management, in: Proceedings of the (SmartData), IEEE., 2018, pp. 1499–1506, https://doi.org/10.1109/Cybermatics_
Dissertation Award and Demonstration, Industrial Track at BPM 2018, CEUR, 2018, 2018.2018.00253.
pp. 56–60. [41] What is BPMN?. https://bpmn.gitbook.io/bpmn-guide/what-is-bpmn. (Accessed 26
[19] O. Lopez-Pintado, M. Dumas, L. García-Ba~ nuelos, et al., Dynamic role binding in March 2022).
blockchain-based collaborative business processes, in: P. Giorgini, B. Weber (Eds.), [42] C.G. Liu, FSM for Modeling for Off-Blockchain Computation, MS Thesis. Dalhousie
Advanced Information Systems Engineering, Springer, Cham, 2019, pp. 399–414, University, Halifax, Nova Scotia, Canada, 2021.
https://doi.org/10.1007/978-3-030-21290-2_25. [43] P. Bodorik, C.G. Liu, D. Jutla, Using FSMs to find patterns for off-chain computing:
[20] O. Lopez-Pintado, M. Dumas, L. García-Ba~ nuelos, et al., Controlled flexibility in finding patterns for off-chain computing with FSMs, in: Proceedings of the 2021 the
blockchain-based collaborative business processes, Inf. Syst. 104 (2022), 101622, 3rd International Conference on Blockchain Technology (ICBCT ’21), ACM, 2021,
https://doi.org/10.1016/j.is.2020.101622. pp. 28–34, https://doi.org/10.1145/3460537.3460565.
[21] C. Di Ciccio, A. Cecconi, M. Dumas, et al., Blockchain support for collaborative [44] C. Liu, P. Bodorik, D. Jutla, A tool for moving blockchain computations off-chain,
business processes, Informatik-Spektrum 42 (2019) 182–190, https://doi.org/ in: Proceedings of 2021 3rd ACM International Symposium on Blockchain and
10.1007/s00287-019-01178-x. Secure Critical Infrastructure (BSCI’21), ACM, 2021, pp. 103–109, https://doi.org/
[22] F. Loukil, K. Boukadi, M. Abed, et al., Decentralized collaborative business process 10.1145/3457337.3457848.
execution using blockchain, World Wide Web 24 (2021) 1645–1663, https:// [45] C. Tardi, What is gwei? The cryptocurrency explained.
doi.org/10.1007/s11280-021-00901-7. https://www.investopedia.com/terms/g/gwei-ethereum.asp. 2022. (Accessed 29
[23] Q. Lu, A.B. Tran, I. Weber, et al., Integrated model-driven engineering of blockchain March 2022).
applications for business processes and asset management, Software Pract. Ex. 51 [46] web3.js - Ethereum JavaScript API. https://web3js.readthedocs.io/. (Accessed 26
(5) (2021) 1059–1079, https://doi.org/10.1002/spe.2931. March 2022).
[24] L. Spalazzi, F. Spegni, A. Corneli, et al., Blockchain Based Choreographies: the [47] bpmn.io ⋅ GitHub, 2022. https://github.com/bpmn-io. (Accessed 26 March 2022).
Construction Industry Case Study. Concurrency and Computation: Practice and [48] Graphviz. https://graphviz.org/. (Accessed 29 March 2022).
Experience, 2021, e6740, https://doi.org/10.1002/cpe.6740. [49] Solidity 0.8.13 documentation. https://docs.soliditylang.org/en/v0.8.13/.
[25] A. Mavridou, A. Laszka, Designing secure Ethereum smart contracts: a finite state (Accessed 29 March 2022).
machine based approach, in: S. Meiklejohn, K. Sako (Eds.), Financial Cryptography [50] Hyperledger fabric SDK for Node.js. https://hyperledger.github.io/fabric-sdk-node/
and Data Security, Springer, Berlin, Heidelberg, 2018, pp. 523–540, https:// . (Accessed 29 March 2022).
doi.org/10.1007/978-3-662-58387-6_28. [51] Worker threads | Node.js v17.7.1 Documentation. https://nodejs.org/api/worker
[26] A. Mavridou, A. Laszka, Tool demonstration: FSolidM for designing secure _threads.html. (Accessed 26 March 2022).
Ethereum smart contracts, in: L. Bauer, R. Küsters (Eds.), Principles of Security and [52] IBM cloud docs. https://cloud.ibm.com/docs/blockchain?topic¼blockchaindevel
Trust, Springer, Cham, 2018, pp. 270–277, https://doi.org/10.1007/978-3-319- op-vscode. (Accessed 26 March 2022).
89722-6_11. [53] ethers. Documentation. https://docs.ethers.io. (Accessed 26 March 2022).
[27] D. Harel Statecharts, A visual formalism for complex systems, Sci. Comput. [54] IBM-Blockchain, Microfab is a containerized Hyperledger Fabric runtime for use in
Program. 8 (3) (1987) 231–274, https://doi.org/10.1016/0167-6423(87)90035-9. development environments. https://github.com/IBM-Blockchain/microfab.
[28] A. Girault, B. Lee, E.A. Lee, Hierarchical finite state machines with multiple (Accessed 26 March 2022).
concurrency models, IEEE Trans. Comput. Aided Des. Integrated Circ. Syst. 18 (6) [55] IPFS cluster consistency model. https://discuss.ipfs.tech/t/ipfs-cluster-consistenc
(1999) 742–760, https://doi.org/10.1109/43.766725. y-model/6666, 2019. (Accessed 26 March 2022).
[29] M. Yannakakis, Hierarchical state machines, in: J. van Leeuwen, O. Watanabe, [56] Node.js. https://nodejs.org/en/. (Accessed 29 March 2022).
M. Hagiya, et al. (Eds.), Theoretical Computer Science: Exploring New Frontiers of [57] DigitalOcean – the developer cloud. www.digitalocean.com, 2020. (Accessed 26
Theoretical Informatics, Springer, Berlin, Heidelberg, 2000, pp. 315–330, https:// March 2022).
doi.org/10.1007/3-540-44929-9_24. [58] etherscan.io. TESTNET ropsten (ETH) blockchain explorer. https://ropsten.ethe
[30] C.A.R. Hoare, Communicating sequential processes, Commun. ACM 21 (8) (1978) rscan.io/. (Accessed 29 March 2022).
666–677, https://doi.org/10.1145/359576.359585. [59] A. Fleischmann, W. Schmidt, C. Stary, (Re-)Justifying BPM: a quest for the
[31] C.G. Cassandras, Discrete Event Systems: Modeling and Performance Analysis, interaction turn reviewing subject-oriented BPM, in: Proceedings of the 2013 IEEE
Irwin, Homewood IL, 1993. 15th Conference, IEEE, 2013, https://doi.org/10.1109/CBI.2013.40.
[32] C. Liu, P. Bodorik, D. Jutla, Blockchain Privacy, Scalability, and Separation of [60] A. Asgaonkar, B. Krishnamachari, Solving the buyer and seller's dilemma: a dual-
Concerns Using Multi-Modal Modeling, 2021. Access, https://web.cs.dal.ca/~ga deposit escrow smart contract for provably cheat-proof delivery and payment for a
ng/ICBTA/. (Accessed 26 March 2022). digital good without a trusted mediator, in: Proceedings of the 2019 IEEE
[33] C. Liu, P. Bodorik, D. Jutla, From BPMN to smart contracts on blockchains: International Conference on Blockchain and Cryptocurrency (ICBC), IEEE, 2019,
transforming BPMN to DE-HSM multi-modal model, in: Proceedings of the 2021 pp. 262–267, https://doi.org/10.1109/BLOC.2019.8751482.
26