=Paper=
{{Paper
|id=Vol-3298/BES-5
|storemode=property
|title=Executable Models and Instance Tracking for Decentralized Applications - Towards an Architecture Based on Blockchains and Cloud Platforms
|pdfUrl=https://ceur-ws.org/Vol-3298/paper_BES_8048.pdf
|volume=Vol-3298
|authors=Felix Härer
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/Harer22
}}
==Executable Models and Instance Tracking for Decentralized Applications - Towards an Architecture Based on Blockchains and Cloud Platforms==
Executable Models and Instance Tracking for
Decentralized Applications - Towards an Architecture
Based on Blockchains and Cloud Platforms
Felix Härer1
1
Digitalization and Information Systems Group, University of Fribourg, Bd de Pérolles 90, 1700 Fribourg, Switzerland
Abstract
The execution of decentralized applications on blockchains is limited today by technical and orga-
nizational barriers, including scalability and the high complexity to specify execution correctly for
developers as well as for domain experts in organizations. Overcoming these limitations could allow for
decentralized coordination beyond data, where distributed parties rely on higher-level abstractions for
coordinating their actions using decentralized applications, not limited to organizations. Towards this
goal, the paper at hand proposes executable models as high-level abstraction that can be observed and
tracked by distributed parties. In particular, it is investigated how executable models on cloud platforms
can be coupled with smart contracts for tracking their execution, concluding with an architecture as
exploratory research result towards supporting scalability and decentralized coordination.
Keywords
Blockchain, Decentralized Applications, Executable Models, Instance Tracking, Serverless Computing
1. Introduction
In recent years, blockchains have introduced novel technical infrastructures for exchanging
transactions and executing applications online. They establish ledgers for transactions [1, 2, 3],
e.g. using tokens as a unit of account for payments or goods [3], and allow involved parties to
track and validate transactions without trusted third parties. In effect, end users or businesses
can interact through verified transactions and track the flow of tokens by attaching them
to goods or any physical or digital item without centralized coordination. These scenarios
are enabled by decentralized applications executing smart contract programs on blockchains,
where data processing and transactions are verifiably executed according to the source code [4].
While blockchains enable verifiable transactions and execution, there remain technical and
organizational barriers for the design of decentralized applications.
In particular, current challenges concern scalability on a technical level, limited by the
processing capabilities and consensus algorithms of today’s blockchains when also pursuing
security and decentralization [5]. Secondly, for organizational adoption, domain experts are
essential in operations and would be involved in designing decentralized applications in addition
PoEM’2022 Workshops and Models at Work Papers, November 23-25, 2022, London, UK
$ felix.haerer@unifr.ch (F. Härer)
https://www.unifr.ch/inf/digits/en/group/team/haerer.html (F. Härer)
0000-0002-2768-2342 (F. Härer)
© 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
to developers. Thus, the technically complex development of smart contracts becomes even
more challenging in an organizational context, given that technical implementations need to
execute correctly according to business, domain, and technical requirements.
Model-based representations could address these challenges when applied for the execution of
decentralized applications. Using executable models as higher-level representations, distributed
parties could potentially coordinate their actions using decentralized applications. Not limited
to organizations, models could provide more formality, meaningful and modular abstractions,
and interactivity, as demonstrated recently in low-code and no-code development [6].
Towards applying executable models for decentralized coordination, the paper at hand
pursues the research question of how executable models and their instances can be coupled
with decentralized applications using smart contracts. It builds on an existing concept for
instance tracking [7, 8, 9] and contributes a dedicated architecture for executable models on
cloud platforms coupled with smart contracts for tracking execution. Through exploratory
research, this architecture has been constructed for scalability while allowing distributed parties
to track execution steps for coordinating their actions without centralized entities.
The remainder of this paper is structured as follows. Section 2 introduces related work,
identifying characteristics missing in present approaches. Section 3 introduces execution and in-
stance tracking concepts and concludes with an architecture and smart contract implementation.
Section 4 concludes.
2. Related Work
This section introduces related work on blockchains, decentralized coordination, and their
utilization in model-based approaches.
Blockchains are a class of technologies permitting the decentralized storage and processing
of data. Blockchain platforms such as Bitcoin [1] and Ethereum [2] achieve decentralization, the
coordination without a centralized entity [10, 9], through data structures verifiable for integrity
and distributed nodes in a network storing, processing, and verifying data through consensus
algorithms. Decentralized applications are executed, at least in part, through data processing
on the blockchain, e.g. using smart contracts interpreted by the Ethereum Virtual Machine [4].
On this basis, decentralized coordination concepts beyond the level of data are explored.
Decentralized autonomous organizations (DAO) [11] are an example of realizing governance
by their participants on a technical level, e.g. through voting mechanisms in smart contracts.
On a business level, the concept of DAOs has been applied for establishing decentralization
in businesses in a model-based approach [7, 8, 9]. It supports designing business systems
with processes and the tracking of their instances; however, not involving execution on the
blockchain. Business process execution has been introduced before in [12]; however, not
involving the design of business systems or processes on the blockchain. Generally, business
process management (BPM) using blockchains has since been recognized [13] and implemented
primarily for business process monitoring and execution [14]. Implementations rely often on
model-based approaches, such as Lorikeet and Caterpillar [15, 16] using the BPMN 2.0 modeling
language [17]. Further approaches subsequently followed, primarily for interorganizational and
collaborative processes [18, 19, 20]. In enterprise modeling and conceptual modeling, a custom
blockchain for models in enterprises with permission mechanisms [21] has been suggested as
well as an approach for the attestation of conceptual models on the Ethereum blockchain [22].
Concerning model-based execution approaches, existing works support this concept on the
blockchain in combination with execution engines. Notably, the Camunda workflow engine
for BPMN 2.0 [16] and state machine implementations [23] have been proposed. While these
approaches build on specific languages, the model-based execution could also be generalized and
coupled with execution engines on cloud platforms, e.g. supporting serverless computing [24],
for combining decentralization and scalability. The paper at hand proposes an architecture
towards this vision through the concept of instance tracking.
3. Instance Tracking Architecture for Executable Models
For the instance tracking of executable models, this section introduces the relevant concepts,
establishes an architecture, and demonstrates a smart contract implementation.
3.1. Concepts
The concepts for executable models and instance tracking are introduced first, leading to the
architecture.
3.1.1. Executable Models
Executable models are the basis and primary representation for users, e.g. end users or businesses,
to design and specify execution for decentralized applications. In contrast to specifying source
code, executable models are used as an abstraction representing the execution specification.
The relevant concepts encompass:
• Executable Models. An executable model is a representation that abstracts from the
specification by source code and can be executed by software on execution engines.
Examples are state machines [25] or executable BPMN models [17].
• Execution Engines. Execution engines support standardized modeling languages, e.g.
the Camunda Workflow Engine for executing BPMN 2.0 models [26], or domain-specific
models such as specialized state machine models, e.g. on cloud platforms such as AWS [25].
In addition, modeling tools might provide an execution engine, e.g. AnyLogic 8 for
modeling simulations [27]. For decentralized coordination, the execution engine must
support distribution and scalability.
• Decentralized Applications. Applications relying on non-centralized technical infras-
tructures and coordination principles can be considered decentralized applications [8].
Non-centralized technical infrastructures operate abstract from individual infrastructure
components that could represent single points of failure, while non-centralized coordina-
tion concerns operating without trusted third parties, e.g. by sharing responsibilities and
control over development, usage, and governance aspects.
For example, decentralized web applications might realize non-centralized technical infras-
tructures by distributed file systems [28], blockchains, or cloud services where programs or
functions are specified independent of servers or virtual machines by serverless computing [25].
Non-centralized coordination can be achieved, e.g., through smart contracts, on-chain or off-
chain voting, or role-based access control.
In combination of the concepts, decentralized applications can be based on executable mod-
els that utilize cloud-based execution engines together with blockchain and smart contract
components. In this way, distributed users rely on a shared representation of the execution.
3.1.2. Instance Tracking
Instance tracking is a concept for monitoring the execution of business process models by
decentralized users on a blockchain [7, 9] that can be generalized and applied to decentralized
applications.
• Instance Tracking. In terms of conceptual modeling [29], instances are manifestations
of models at run-time, representing objects or data of the abstract concepts defined by
a model. Instance tracking refers to the observation of instances over time, either by
recording discrete states of instances at run-time, or by recording state changes.
• Instance Protocol. An instance protocol records for a specific model the creation of
instances, the discrete states or state changes for each instance, and the termination of
instances. In the case of discrete states, initial, expected, and final states can be defined
if relevant for the domain. In the case of state changes, a state transfer function or
operations resulting in state changes can be defined. Additionally, the protocol might
store metadata, such as involved users or blockchain addresses.
By registering models and tracking their instances with a smart contract over time, blockchain-
based instance protocols can be created. Distributed users can track state changes and verify the
consistency to the models, allowing for decentralized coordination using models and instance-
level data, and data analysis for distributed applications. While this approach is not limited to
specific application areas, it could be applied to track the state of, e.g., decentralized organizations
or processes [9], tokens in financial applications, marketplaces or supply chains, as well as
data-intensive applications such as for distributed IoT devices, vehicles, industrial machines, or
distributed sensor data.
3.2. Architecture
This section establishes an architecture for the decentralized instance tracking of executable
models by identifying required components, discussing their behavior, and instance protocols
for tracking and verifying relevant execution steps.
The following requirements for components of a dedicated architecture address instance
tracking by blockchains, adapted from [7, 9], and execution according to the respective concepts.
1. Recording of models and instances: Design aspects of an execution represented in models
must be distinguished from instances and their states and transitions. While instances
might be created by any distributed party and change over time, an instance state is a
representation captured at one point in time, following from a transition. For tracking,
an instance protocol can record models, instances, and instance states over time.
2. Blockchain platform: Distributing models, instances, and instance states can be separated
from securing their integrity using a blockchain. For distribution, model repositories can
be used, e.g. based on git [9]. When using cloud-based platforms, they might accomplish
distribution, however, with different trade-offs. For securing the integrity of models,
hash values are calculated from models, instances, and instance states and recorded
with metadata on a blockchain platform. A smart contract implementing corresponding
registrations and tracking functions is required.
3. Execution engine: Models must be executed on an execution engine that supports dis-
tribution and scalability. For supporting not only models related to organizations, no
restrictions are made on execution engines, e.g. including business process management
systems and cloud platforms. For the interaction with the blockchain platform, an API is
required; possibly implemented on a cloud platform also performing execution.
4. Client application: A client application must support users, e.g. end users and businesses,
the interaction with cloud platforms for deploying and running models, as well as the
interaction with the blockchain through a suitable API. Interactions encompass controlling
the execution in addition to instance tracking by listening to state changes through the
blockchain platform such that they become visible to the user. In the context of cloud
platforms, web applications may be used together with an API, e.g. web3.js with the
MetaMask web browser plugin [4].
Technically, an architecture fulfilling these requirements can be realized as shown in Figure 1.
Client Application
E.g. Web Client
Execution Control Instance Tracking
E.g. Web Application E.g. Web Application
Executable Instance
Instance append Instance
Instance
State
Model State
State Protocol
transition update
event addresses
Blockchain API – E.g. Metamask and web3.js
deploy run / update trigger state transition get metadata /
terminate state transition event account
Cloud register Blockchain
register account
Platform Execution Engine model / Platform
E.g. AWS Step Functions, Camunda instance / Smart Blockchain
state / Contract operate Network
register model / Blockchain API transition
instance / state / E.g. AWS Lambda
transition
Figure 1: Architecture for executable models with instance tracking.
The client application implements execution control for deploying, running, and terminating
an executable model on a cloud platform. Models are registered with the smart contract through
the blockchain API component, including metadata and a hash value for each model in order
to identify models based on their content. When the execution control component initiates
running a model on an execution engine, an instance is registered with the corresponding model
hash value and a hash value of the instance.
Changes to the instance are subsequently triggered through the execution engine by user-
controlled components or by the engine itself, resulting in new instance states. State changes
are captured by the registration of their hash values that reflect and identify new instance states.
The pre- and post-state of a transition is thus registered by the corresponding hash values.
With each transition, the smart contract will emit a transition event on the blockchain
network, received by the instance tracking component of each party involved in the execution.
There, the event triggers an update of the local state such that state changes can be observed
and verified by all parties involved. Each transition and state append the instance protocol,
including additional metadata received from the blockchain such as timestamps, owner accounts,
or further model-specific data. The result is an instance protocol containing an entry with
identifiers for each transition together with the pre- and the post-state, identifiers for the
corresponding instance and model, as well as the metadata attribute values.
3.3. Smart Contract
For evaluating implementation feasibility, the smart contract has been implemented as shown
in the class diagram in Figure 2.
<>
ModelInstanceStateTracking
+ accounts : mapping(address => bytes32) <>
+ models : bytes32[] TransitionEvent
+ instances : mapping(bytes32 => bytes32) instance : bytes32 indexed
+ states : mapping(bytes32 => bytes32) 1 0..* preState : bytes32
+ transitions : mapping(bytes32 => bytes32) postState : bytes32
+ descriptors : mapping(bytes32 => ModelInstanceDescriptor)
+ registerAccount(userID : bytes32)
+ registerModel(modelHash : bytes32, ownerAccount :
address, metadata : bytes32)
+ registerInstance(modelHash : bytes32, instHash : bytes32, <>
ownerAccount : address, metadata : bytes32) ModelInstanceDescriptor
+ registerState(instHash : bytes32, stateHash : bytes32)
+ registerTransition(instHash : bytes32, preStateHash : bytes32, 1 0..* metadata : bytes32
postStateHash : bytes32) ownerAccount : address
- emitTransitionEvent(instHash : bytes32, preStateHash : blockTimestamp : uint
bytes32, postStateHash : bytes32)
+ getTransitionHash(preStateHash : bytes32, postStateHash :
bytes32) : bytes32
+ getAccount(hash : bytes32) : (account : address, userID : bytes32)
+ getMetadata(hash : bytes32) : bytes32
+ delegate(hash : bytes32, ownerAccount : address)
Figure 2: Class diagram of the smart contract for the registering and tracking of models and instances.
Models, instances, states, and transitions are registered through functions interacting with
the smart contract component according to the architecture, including the storage by their
hash values. Mapping data structures implement storage with additional metadata present in
the ModelInstanceDescriptor. In practice, the metadata might depend on the model and
modeling tool, e.g. issuing an identifier or name for each model.
Furthermore, an owner account is stored for each model and instance in order to restrict
the creation of instances as well as instance states and transitions to the respective owner.
Accordingly, functions for retrieving the account and for delegating access rights exist.
With each registered transition, the client-side component is notified with a
TransitionEvent according to the architecture. The event triggers a client-side up-
date by transmitting the instance with the pre- and the post-state hash values. Given these
values, the client-side component might retrieve the corresponding states and transitions
together with metadata descriptors. The implementation is available online1 . The smart
contract has been deployed and executed on the Ethereum blockchain2 .
4. Discussion and Outlook
For decentralized applications, the research question of coupling executable models with their
instances to smart contracts has been initially raised by this paper. As a result, requirements with
a corresponding architecture and a smart contract have been constructed through exploratory
research. The architecture shows, in principle, executable models can be coupled with smart
contracts for a decentralized coordination of the execution when using cloud platforms that offer
distribution and scalability independent of individual programs or virtual machines. Serverless
computing approaches are well suited for this purpose and allow for data processing involving,
e.g., decentralized organizations, processes, tokens, IoT devices, compute-intensive applications
such as machine learning, or databases and data-intensive applications.
The feasibility of implementing the architecture with a smart contract is confirmed by a proto-
type for the Ethereum blockchain, showing the registration of instance states on-chain through
hash values and metadata together with an event-based mechanism for updating instance states
at the client side. While feasibility could be shown in principle by the architecture, it is a first
step towards a model-based approach for executable models in decentralized applications.
In future research, further analysis of the requirements, implementation, and an extended
evaluation are foreseen, aiming at the realization of decentralized coordination through model-
based representations.
Acknowledgments
This work is partially supported by the Swiss National Science Foundation project Domain-
Specific Conceptual Modeling for Distributed Ledger Technologies [196889].
1
Available from https://github.com/fhaer/Itrex.
2
Transactions can be seen at address 0x2300646ca8e90ecb87144432eb975a395e02b7ec, e.g. at https://etherscan.io/
address/0x2300646ca8e90ecb87144432eb975a395e02b7ec.
References
[1] S. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. URL: https://bitcoin.
org/bitcoin.pdf, accessed on 2022-08-28.
[2] V. Buterin, Ethereum: The Ultimate Smart Contract and Decentralized Application
Platform, 2013. URL: http://web.archive.org/web/20131228111141/http://vbuterin.com/
ethereum.html, accessed on 2022-08-28.
[3] M. di Angelo, G. Salzer, Tokens, types, and standards: Identification and utilization in
ethereum, in: 2020 IEEE International Conference on Decentralized Applications and
Infrastructures (DAPPS), IEEE, 2020, pp. 1–10. doi:10.1109/DAPPS49028.2020.00001.
[4] A. M. Antonopoulos, G. Wood, Mastering Ethereum: Building Smart Contracts and DApps,
O’Reilly Media, 2019.
[5] Q. Zhou, H. Huang, Z. Zheng, J. Bian, Solutions to scalability of blockchain: A survey,
IEEE Access 8 (2020) 16440–16455. doi:10.1109/ACCESS.2020.2967218.
[6] S. Curty, F. Härer, H.-G. Fill, Blockchain application development using model-driven
engineering and low-code platforms: A survey, in: Enterprise, Business-Process and
Information Systems Modeling, EMMSAD 2022, Springer, 2022, pp. 205–220. doi:10.1007/
978-3-031-07475-2_14.
[7] F. Härer, Decentralized Business Process Modeling and Instance Tracking Secured By a
Blockchain, in: Proceedings of the 26th European Conference on Information Systems
(ECIS), AIS Electronic Library (AISeL), Portsmouth, UK, 2018. URL: https://aisel.aisnet.org/
ecis2018_rp/55.
[8] F. Härer, Integrierte Entwicklung und Ausführung von Prozessen in dezentralen Organ-
isationen. Ein Vorschlag auf Basis der Blockchain, University of Bamberg Press, 2019.
doi:10.20378/irbo-55721.
[9] F. Härer, Process Modeling in Decentralized Organizations Utilizing Blockchain Consensus,
Enterprise Modelling and Information Systems Architectures (EMISAJ) 15 (2020). doi:10.
18417/emisa.15.13.
[10] H. A. Simon, H. Guetzkow, G. Kozmetsky, G. Tyndall, Centralization vs. Decentralization
in Organizing the Controller’s Department.: A Research Study and Report Prepared for
Controllership Foundation, Inc, Series A-1 Controllership: Contracts, Organization. Report,
No. 4, Controllership Foundation, New York, 1954.
[11] C. Santana, L. Albareda, Blockchain and the emergence of Decentralized Autonomous Or-
ganizations (DAOs): An integrative model and research agenda, Technological Forecasting
and Social Change 182 (2022) 121806. doi:10.1016/j.techfore.2022.121806.
[12] I. Weber, X. Xu, R. Riveret, G. Governatori, A. Ponomarev, J. Mendling, Untrusted Business
Process Monitoring and Execution Using Blockchain, in: 14th International Conference,
Business Process Management (BPM 2016), Springer, 2016, pp. 329–347. doi:10.1007/
978-3-319-45348-4_19.
[13] J. Mendling, I. Weber, W. V. D. Aalst, J. V. Brocke, C. Cabanillas, F. Daniel, S. Debois,
C. D. Ciccio, M. Dumas, S. Dustdar, A. Gal, L. García-Bañuelos, G. Governatori, R. Hull,
M. L. Rosa, H. Leopold, F. Leymann, J. Recker, M. Reichert, H. A. Reijers, S. Rinderle-Ma,
A. Solti, M. Rosemann, S. Schulte, M. P. Singh, T. Slaats, M. Staples, B. Weber, M. Weidlich,
M. Weske, X. Xu, L. Zhu, Blockchains for Business Process Management - Challenges and
Opportunities, ACM Transactions on Management Information Systems 9 (2018) 4:1–4:16.
doi:10.1145/3183367.
[14] J. A. Garcia-Garcia, N. Sánchez-Gómez, D. Lizcano, M. J. Escalona, T. Wojdyński, Using
Blockchain to Improve Collaborative Business Process Management: Systematic Literature
Review, IEEE Access 8 (2020) 142312–142336. doi:10.1109/ACCESS.2020.3013911.
[15] A. B. Tran, Q. Lu, I. Weber, Lorikeet: A Model-Driven Engineering Tool for Blockchain-
Based Business Process Execution and Asset Management, in: 16th International Confer-
ence on Business Process Management (BPM 2018), Demonstration Track, CEUR Workshop
Proceedings, volume 2196, CEUR-WS, 2018.
[16] O. López-Pintado, L. Garćıa-Bañuelos, M. Dumas, I. Weber, A. Ponomarev, Caterpillar: A
business process execution engine on the Ethereum blockchain, Software: Practice and
Experience 49 (2019) 1162–1193. doi:10.1002/spe.2702.
[17] Object Management Group (OMG), Business Process Model and Notation (BPMN), Version
2.0.2, 2014. URL: http://www.omg.org/spec/BPMN/2.0.2, accessed on 2022-09-30.
[18] G. Falazi, M. Hahn, U. Breitenbücher, F. Leymann, Modeling and execution of blockchain-
aware business processes, SICS Software-Intensive Cyber-Physical Systems 34 (2019)
105–116. doi:10.1007/s00450-019-00399-5.
[19] F. Corradini, A. Marcelletti, A. Morichetta, A. Polini, B. Re, E. Scala, F. Tiezzi, Model-driven
engineering for multi-party business processes on multiple blockchains, Blockchain:
Research and Applications 2 (2021) 100018. doi:10.1016/j.bcra.2021.100018.
[20] F. Loukil, K. Boukadi, M. Abed, C. Ghedira-Guegan, Decentralized collaborative business
process execution using blockchain, World Wide Web 24 (2021) 1645–1663. doi:10.1007/
s11280-021-00901-7.
[21] H.-G. Fill, F. Härer, Knowledge Blockchains: Applying Blockchain Technologies to Enter-
prise Modeling, in: 51st Hawaii International Conference on System Sciences (HICSS-51),
ScholarSpace, 2018. doi:10.24251/HICSS.2018.509.
[22] F. Härer, H.-G. Fill, Decentralized Attestation of Conceptual Models Using the Ethereum
Blockchain, in: 2019 IEEE 21st Conference on Business Informatics (CBI), IEEE, 2019, pp.
104–113. doi:10.1109/CBI.2019.00019.
[23] M. Jurgelaitis, L. čeponieṅe, R. Butkieṅe, Solidity Code Generation From UML State
Machines in Model-Driven Smart Contract Development, IEEE Access 10 (2022) 33465–
33481. doi:10.1109/ACCESS.2022.3162227.
[24] V. Yussupov, G. Falazi, U. Breitenbücher, F. Leymann, On the Serverless Na-
ture of Blockchains and Smart Contracts, 2020. URL: http://arxiv.org/abs/2011.12729,
arXiv:2011.12729 [cs].
[25] Amazon, Aws step functions documentation, 2022. URL: https://docs.aws.amazon.com/
step-functions/index.html, accessed on 2022-09-30.
[26] Camunda, The Camunda BPM Manual, 2022. URL: https://docs.camunda.org/manual/,
accessed on 2022-09-30.
[27] A. Borshchev, I. Grigoryev, The big book of simulation modeling: multimethod modeling
with AnyLogic 8, AnyLogic North America, 2020.
[28] Y. Psaras, D. Dias, The InterPlanetary File System and the Filecoin Network, in: 50th
IEEE/IFIP International Conference on Dependable Systems and Networks, IEEE, 2020.
doi:10.1109/DSN-S50200.2020.00043.
[29] E. J. Sinz, On the evolution of methods for conceptual information systems modeling,
in: The Art of Structuring, Bridging the Gap Between Information Systems Research and
Practice, Springer, 2019, pp. 137–144. doi:10.1007/978-3-030-06234-7_13.