Executable Models and Instance Tracking for Decentralized Applications - Towards an Architecture Based on Blockchains and Cloud Platforms

Abstract

The execution of decentralized applications on blockchains is limited today by technical and organizational 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

• eol>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 efect, 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 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 instance 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 infrastructures 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 coordination 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 infrastructures 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 ofchain voting, or role-based access control.

In combination of the concepts, decentralized applications can be based on executable models 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, blockchainbased 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 instancelevel 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 diferent trade-ofs. 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 distribution 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 E.g. Web Application

Executable

Model

Instance Tracking E.g. Web Application

InISsntItSsnaattSstnaatetctnaaeetcneece append

Instance

Protocol transition update event addresses

Blockchain API – E.g. Metamask and web3.js deploy run / terminate update state trigger state transition transition event get metadata / account Cloud Platform

Execution Engine E.g. AWS Step Functions, Camunda register model / instance / state / transition

Blockchain API E.g. AWS Lambda register model / instance / state / transition register account Smart Contract

Blockchain

Platform

Blockchain operate Network

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 usercontrolled 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.

<<SmartContract>>

ModelInstanceStateTracking + accounts : mapping(address => bytes32) + models : bytes32[] + instances : mapping(bytes32 => bytes32) + states : mapping(bytes32 => bytes32) + transitions : mapping(bytes32 => bytes32) + descriptors : mapping(bytes32 => ModelInstanceDescriptor) + registerAccount(userID : bytes32) + registerModel(modelHash : bytes32, ownerAccount :

address, metadata : bytes32) + registerInstance(modelHash : bytes32, instHash : bytes32,

ownerAccount : address, metadata : bytes32) + registerState(instHash : bytes32, stateHash : bytes32) + registerTransition(instHash : bytes32, preStateHash : bytes32,

postStateHash : bytes32) - emitTransitionEvent(instHash : bytes32, preStateHash :

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) 1 1

<<event>>

TransitionEvent instance : bytes32 indexed 0..* preState : bytes32 postState : bytes32

<<struct>>

ModelInstanceDescriptor 0..* metadata : bytes32 ownerAccount : address blockTimestamp : uint

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 update 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 ofer 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 prototype 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 modelbased representations.

Acknowledgments

This work is partially supported by the Swiss National Science Foundation project DomainSpecific Conceptual Modeling for Distributed Ledger Technologies [196889]. 1Available from https://github.com/fhaer/Itrex. 2Transactions can be seen at address 0x2300646ca8e90ecb87144432eb975a395e02b7ec, e.g. at https://etherscan.io/ address/0x2300646ca8e90ecb87144432eb975a395e02b7ec. [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.

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 Organisationen . 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 Organizations (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 BlockchainBased Business Process Execution and Asset Management , in: 16th International Conference 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 blockchainaware 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 Enterprise 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. čeponienė, R. Butkienė, 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 Nature 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 .