6.1 Challenges about smart contracts

1.1 Monitoring transparency To improve the transparency of compliance checking, especially in the case of multi-party business processes, smart contracts hold a crucial role. In fact, based on the information that can be made accessible through oracles and on the relevant transactions mined in the blockchain, a smart contract can analyze the current status of the process enactment and verify if the control flow (in the case of orchestrated processes) or the message exchange (in the case of a choreographed process) behaves as expected. As the code composing the smart contract is executed on all the blockchain clients to reach consensus, it is extremely hard for a single party to alter it in order to counterfeit the result. As a consequence, the logic that drives compliance becomes publicly available to all the parties interested in the soundness of the process, even if they are not directly involved in the enactment (e.g., auditors). Especially in multi-party business processes, information about the obligations involving the parties can be produced and observed with smart contracts. For example, given the process in Sect. 3, if each of the three sub-processes modeled in the pools in Fig. 1 is implemented as a smart contract, M, S and C agree on how the process should be carried out. As the constraints become public, none of them can complain t they expected the process to be executed differently. Moreover, if the parties agree that the visibility should be limited only to the protocol governing the message exchange, then the smart contract will reflect only the choreography. The transparency offered by the smart contracts heavily impacts on the monitoring platform. On the one hand, it increases the trust in process execution. On the other hand, it requires careful implementation of the monitoring and trust layers in order not to undermine the control that participants have on the data being provided to the platform, which is required to address R3. In particular, it requires smart contracts to be properly designed in order to rely only on the information that could be made available to external actors [10]. Moreover, the ability for a smart contract to verify possible deviations in the process enactment is strictly related to the monitoring data that are available through the oracles. As a consequence, the availability of proper data sources that can be accessed by the smart contract is fundamental. With single-partybusinessprocesses,thisissuecanbelesscritical, as the party is responsible for designing the smart contracts and the oracles, as well as for choosing the necessary data sources.Multi-partybusinessprocesses,instead,mayrequire an agreement that includes the possibility to make some of the data about the process and artifact status available to the other involved parties. This opens an additional issue about the accessibility of those data. For instance, to determine if the process portion carried out by S is correctly performed, S should expose the information on the position and speed of its trucks. 6.1.2 Observability Smart contracts and the invocations of their methods are stored in the blockchain. Their execution can thus be performed and analyzed by any participant. Additionally, most blockchainsrequiresmartcontractstoexplicitlydefinemethods to retrieve their state information. In other words, variablesthatareusedbysmartcontractsmaybemadeaccessibleonlybythesmartcontractitself,unlessmethodstomake their contents available are explicitly defined in the smart contracts [2,40]. Observability issues in smart contracts could arise when implementing the auditing layer to distribute monitoring data to the process auditors, in order to address R5. Indeed, auditors may be unable to access valuable monitoring information, if mechanisms to access this information were not explicitly designed when the smart contracts were put in place. As a consequence, before putting in place a blockchain-based monitoring platform, care should be taken defining which information can be retrieved from the smart contract. For example, suppose that, to monitor the process in Sect. 3, a smart contract is implemented that has an internal representation of the process and of the status of each activity. That smart contract may expose a function to check whether the process conforms to the model or not, without providing information on the activities. As a consequence, although the smart contract internally knew that, e.g., Ship container is running and Attach container to truck is complete, it would lack a way to communicate this information to other smart contracts or other participants, who cannot rely on it to determine the status of the process and its activities. 6.1.3 Lack of reactivity A smart contract lacks the capability of independently making calls or invocations to endpoints outside the blockchain upon the verification of certain conditions [13,62]. When implementing the auditing layer to keep the processstakeholdersinformedontheprocessexecution(inorder to address R5), this limitation may significantly impact the monitoringplatform.Indeed,especiallyincaseofdeviations, it would be desirable that the process owner and the involved parties could promptly react to such a deviation. However, due to the lack of reactivity in smart contracts, it is not possible for a smart contract to automatically and autonomously trigger any off-chain counteraction to process deviations. For example, suppose that the smart contract monitoring the process in Sect. 3 detects that activity Inspect container was performed while the container was being shipped. In light of the above, it cannot autonomously contact S off-chain to request a justification for that action. 6.1.4 Execution cost The execution of a smart contract is generally more computationally intensive than the execution of code deployed as a centralized, stand-alone application [1]. The higher expensiveness is due to several reasons. First, the code that the smart contract consists of must be executed by multiple participants in order for them to reach consensus. Second, a new blockcontainingoneormoresmartcontractinvocationsmust be created for its effects to be persisted on the blockchain. Finally, the changes in the state of the blockchain caused by the invocation of a smart contract must be propagated and applied by all participants. As a consequence, the inner complexity of a smart contract is amplified by the way in which it is meant to be executed. In particular, loops and function invocations within a smart contract can significantly increase its complexity, which translates to higher execution costs in terms of hardware utilization and, consequently, actual money. In addition, to avoid a single invocation to consume all the available resources and lock-up the whole blockchain, the number of instructions executed within a single smart contract invocation is typically bound to a threshold value (e.g.,thegaslimitinEthereum).Ifthatthresholdisexceeded, the corresponding invocation is terminated and any change made by that invocation on the blockchain is discarded. When implementing the trust layer to analyze the events that occur during process execution (in order to address R1) andtointegratethemwithcontextualinformation(inorderto address R4), the potentially high and bounded cost of smart contract execution may force participants to either simplify the monitoring logic or offload it to external oracles. Therefore, care should be taken when designing smart contracts in order to balance their complexity and the guarantees that on-chain code execution provides. 6.2 Challenges about oracles 6.2.1 Time management Among the several aspects that are interesting to monitor about a business process, one of the most pivotal ones is checking if an activity is performed on time. Unfortunately, a blockchain lack the notion of absolute time, with the partial exception of the coarse-grained block time [39,54,71]. As a consequence, smart contracts are not readily suitable for checking that an execution occurs within a given timestamp. Although a blockchain sorts the transactions, it cannot deal with timers. This is due to the fact that the expiration of a timer, or more simply a clock-ticking event, would be an actionthatoriginatesfromthesmartcontractitself.However, as a smart contract can only perform actions that are externally invoked, such actions cannot be performed without the help of an external entity. This limited support for time management becomes an issue for the trust layer. Indeed, to promptly detect issues during process execution, the monitoring smart contract may require accurate time information among the contextual information needed to address R4. For instance, considering the process in Sect. 3, a smart contract should not be employed to notify a delay if activity Ship container is not completed within 24 hours from its start. That smart contract cannot determine that activity Ship container took longer than a day until it receives a notification that the activity was completed, unless it is actively polled by an external entity. For this reason, time has to be managed externally to the blockchain by means of specific oracles, which must be configured by the smart contract to send a trigger whenever a timeout expires. It is also important to consider that those oracles are external to the blockchain by definition, hence outside the chain of trust managed by the blockchain. Therefore, when designing a time oracle, the situation in which the oracle experiences a failure or produces fake data (e.g., it goes out of sync) has to be taken into due account. 6.2.2 Reliability Thegoalofanoracleistoallowthesmartcontractstoacquire information from the real world. Thus, oracles are required to guarantee the correctness of the data they emit. However, this may not be the case for two reasons. First, the oracle may deliver data that are wrong or even forged (e.g., by a manin-the-middle attack) before being sent to the smart contract. Second, the oracle may not be reliable and the data produced could be accidentally inexact [42]. Both circumstances hamper the trust in the gathered data. Reliability issues in oracles become particularly relevant for the trust layer, as it requires to trust events related to the process (in order to address R1) and contextual information (inordertoaddressR4).Indeed,incorrectdataprovidedbyan unreliable oracle may lead to misleading monitoring results. For instance, considering the process in Sect. 3, if the truck’s GPS receiver is breached or broken, the related oracle could send incorrect information on its location. Althoughthisissuecouldbepartiallyaddressedbyrelying on multiple oracles [7] to obtain information about a phenomenon occurring in the real world, it may not always be feasible or affordable, especially when monitoring humanbased activities. 6.2.3 Flexibility Adoptingoraclestoallowsmartcontractstocheckthebehavior of a process implies that all the phenomena relevant for monitoring should be exposed through oracles. The smart contract should know in advance the addresses of the oracles providing the needed data then. However, this could result in a lack of flexibility. Adding new oracles after the monitoring hasbeendesignedcouldturnouttobeworthless,ifthereisno possibility to inform the smart contract about their existence [11]. When implementing the trust layer, the impossibility to change at runtime the oracles providing off-chain data could significantly impair the flexibility of the monitoring platform. Indeed, supporting changes in the involved stakeholders would be required to address R2, and the inability to change the sources providing event data and contextual information could impair the fulfillment of, respectively, R1 and R4 For example, suppose that the monitoring platform relied initially on manual notifications to determine when the container was filled in, and references to that oracle were hard-coded in the smart contracts. If later on containers are equipped with scales to automatically infer if they are full or empty, it is not possible for the platform to rely on that information, unless smart contracts are redesigned and deployed anew. Mechanisms for enabling late binding of oracles to smart contracts are thus desirable for a proper design. Notice that, without that mechanism in place, an oracle that is no longer available could not be replaced. 6.2.4 Alignment As the blockchain alone has no visibility on the events that occur off-chain, and it is the oracle’s responsibility to notify such events, a misalignment between the off-chain world state and its on-chain representation may occur. In particular, such a misalignment may affect the oracles responsible for reporting events related to the process execution (in order to address R1) and the ones that provide contextual information (in order to address R4) to the trust layer. Consequently, as stated in [38], such a misalignment may lead to misleading monitoring results, especially when multiple events have to be combined in order to detect changes in the execution of the process. 6.3 Challenges about monitoring data management 6.3.1 Data quality Information sources queried by the oracles could be inaccurate or untrustworthy. In particular, if the data sources being used in the monitoring layer to provide events related to the execution of the process (in order to address R1), or the data sources that provide contextual information to the trust layer (in order to address R4) are poor quality ones, the monitoring platform may provide misleading results. For instance, in the case of a manual activity, e.g., the oracle is not connected to any automatic sensor thus the notification of status change for the activity is manually inserted by the operator. Consequently, the operator could mislead the system by declaring that an activity is concluded even though it is not yet the case, or by delaying the notification as an end-of-the-day operation, in which all the notifications are batched together [16]. We remark that this is a well-known problem in business process monitoring, and even the utilization of a blockchain may not be beneficial to solve it. In fact, if erroneous data are stored in the blockchain, they can be amended only by appending the correct information, as the blockchain does not allow for the alteration of data in a mined block. 6.3.2 Data size In a blockchain, the larger the amount of stored data is, the more expensive the transaction gets. This simple rule has a significant impact on monitoring costs. Indeed, initial approaches for process data extraction [36,54] assume that the necessary information is entirely stored on-chain. To reduce the costs, though, care should be taken in the design of the smart contracts to minimize the amount of on-chain information to the sole data that are required to enable monitoring and provide a handle to external sources for deep-diving into richer information. As a consequence, this limitation impacts on the way events related to the process execution and contextual information should be handled by the trust layer (and, consequently, could hinder the fulfillment of R1 and R4). 6.3.3 Side effects Most blockchain platforms are prone to soft forks, i.e., branches in the chain of blocks caused by two or more blocks pointing to the same predecessor [9]. To solve ambiguities, blockchain clients such as those of Bitcoin and Ethereum consider the longest chain as the valid one (that is, they retain theonehavingthehighestnumberofsubsequentblocksoriginating from the point of forking). From a monitoring standpoint, this lack of information consistency is an issue, since valid monitoring data may not be considered as the block containing them happen to lie on a discardedpost-forkbranch.Asaconsequence,softforksmay have a negative impact on the trust layer. In particular, they may cause the monitoring platform to have a partial view on the events related to the process and on the contextual information, which could hinder the fulfillment of, respectively, R1 and R4. Aside from soft forks, public blockchains such as Ethereum are also prone to so-called hard forks [48]. In case a change in the consensus protocol is made—for either technical or political reasons—some participants may not accept it. Unlike soft forks, hard forks cause a split in the blockchain network, which hampers interoperability. From the monitoring standpoint, hard forks may have a negative impact on the trust layer. In particular, they may break the platform if some participants decide not to migrate to the new protocol. Also, they may prevent participants that use different branches of the fork from joining the platform, thus affecting the pluggability of participants, which is required for R2. 6.3.4 Data erasability By design, the blockchain impedes nodes to erase or alter data already stored in it [65]. This infrastructural characteristic allows for tamper-proof monitoring solutions, which is particularly valuable when disputes between participants arise, or when the processes must be assessed by external auditors. However, the inability for participants to decide when monitoring information should no longer be accessible by the platform may become an issue that affects the trust layer by hindering the fulfillment of R3. Indeed, some monitoring applicationsrequireolddatatobepurgedoncetheirretention period is over. For example, the GDPR regulations explicitly state that any sensitive information belonging to a person should be permanently destroyed on request by that person, once the trade obligations are over [35]. In these scenarios, the inability to erase information would be a serious issue. Therefore, a trade-off between the immutability of monitoring information and the so-called right-to-be-forgotten is necessary. 6.4 Challenges about interoperability among blockchains 6.4.1 Migration As the blockchain ecosystem is in continuous evolution, a considerable number of blockchain and DLT platforms have beenproposedsofar.Someofthemhavegainedlittlesuccess, and thus they have been abandoned by the community of developers and users alike. Therefore, it may happen in the future that the blockchain adopted for the trust layer of the monitoring platform will eventually no longer be supported. This will have a negative impact on the trust layer, as the lack of support may prevent other participants from joining the platform, thus hindering the fulfillment of R2. Thus, to avoid a monitoring solution to be locked-in to a platform that is no longer used, a strategy to easily migrate the solution over adifferent blockchain should be defined when designing that solution [5]. Defining such a migration strategy is not trivial, as each blockchain may implement its own consensus algorithm, block structure, data representation, and smart-contract languagesattimes.Therefore,atransitiontoadifferentplatform canrequirearefactoringofseveralcomponentsintheoriginal architecture, potentially involving not only software connectors and gateways but also the business logic itself. 6.4.2 Bridging A blockchain considers as trusted only those data and smart contracts that are internal to its own environment. It is then unable to directly invoke smart contracts or access data that reside on a different deployment [64]. This limitation may have a negative impact on the trust layer. Often, the execution of a process can trigger or influence the execution of other processes. Therefore, platforms that are responsible for the monitoring of interrelated processes should be able to communicate with one another. However, when monitoring information is stored in two different blockchain platforms, they cannot directly interact with each other, which is required to address R2. 7 Mitigation and applicability of challenges The challenges identified and discussed in the previous section can have higher or lower impact on the process monitoring solutions depending on the characteristics of the adopted blockchain. For instance, the lack of reactivity challenge affects only the blockchains with advanced programmability (e.g., Ethereum, HyperLedger Fabric and R3 Corda), while the observability affects a subset of them with accessibility as public (e.g., Ethereum and Corda). Yet, time management and reliability are relevant challenges when providing a blockchain-based business process monitoring platform, regardless of the specific adopted technology. In this section, we link the aspects used to classify the blockchain platforms as in Table 1 with the challenges identified in Fig. 5 and illustrate the strategies currently available in the literature to mitigate the effects, if any. Table 2 summarizes the results of our investigation. Being it at its early stages, the adoption of blockchain for supporting the monitoring activities in business process management does not provide a significant number of work available in the literature. Nevertheless, we hope that the proposed reference model and the identified challenges could provide a useful roadmap for researchers working in this topic. Access control mechanisms To address the challenge of controlling access to the blockchain and its assets, several solutions have been proposed [31]. However, most of them focus on on-chain access control mechanisms, as their main purpose is to prevent unauthorized users from storing data or invoking smart contracts. Unfortunately, they are scarcely effectiveformonitoringtransparency(Sect.6.1.1),asanyone whohasaccesstotheglobalstateoftheblockchaincanreconstruct the on-chain data. Conversely, off-chain access control mechanisms, such as the ones that are typically implemented in private blockchains, can effectively prevent unauthorized users from accessing on-chain information. However, the granularity of the on-chain information that can be protected is often either too coarse (e.g., a subset of the nodes) or too fine (e.g., a single transaction). Encryption Another alternative to address the challenge of monitoring transparency (Sect. 6.1.1) is represented by encryption [37]. By storing on-chain data in an encrypted form, and providing decryption keys only to the users who are authorized to access monitoring data, it is possible to protect them also when they are stored in a public blockchain. In addition, key exchanges can happen while the monitoring platform is running, as soon as a specific participant has to access monitoring data. However, this approach suffers from several limitations. First, encryption is limited to data, so the logic that governs the smart contracts remains publicly visible. Second, encrypted data can be stored and retrieved by smart contracts. However, for a smart contract to process them, they must be unencrypted first, either by passing the decryption key to the smart contract, or by decrypting them off-chain and then passing the unencrypted data to the smart contract. In both cases, anyone who has access to the blockchain can access monitoring data, as all the information required to decrypt them would be available on-chain. Finally, as on-chain data are permanently stored, in case the decryption key or the encryption algorithm gets compromised, a new encryption scheme cannot be applied to already stored monitoring data, nor data can be deleted or be made inaccessible. Thus, anybody could be able to decrypt and access all monitoring information that was stored before the encryption was changed. Transaction mining To address the challenge of smart contract observability (Sect. 6.1.2), process mining techniques canbeappliedtotracetheexecutionofeachtransactionsince when the deployment took place [19]. In this way, they can identify how the state of the smart contracts (i.e., the value of their internal variables) changes over time. The downside of this approach is that, even though it processes on-chain data, it has to be performed off-chain. Consequently, if the discovered information is required by a smart contract, this information must be provided off-chain, with consequent trust issues and the need to rely on an oracle. Also, this approach is only applicable for public blockchains, as it requires all transactions committed to the blockchain to be publicly announced. Outbound oracles To address the challenge of the lack of reactivity in smart contracts (Sect. 6.1.3), oracles conforming to the outbound pattern can be deployed [53]. Indeed, this pattern has been explicitly designed to provide on-chain information to the off-chain world. To do so, smart contracts should be designed to either expose public methods that can be periodically called by an oracle to retrieve information, or emit events and require the oracle to constantly monitor the blockchain in order to catch them as soon as they fire. Certified off-chain offloading To address execution cost (Sect. 6.1.4), a strategy could include the relocation of the most computationally expensive operations off-chain. In this way, the smart contract would solely trigger an off-chain computationandreceivetheresults.Toguaranteethattheoffchain computation is performed correctly, mechanisms such as zero-knowledge proof [22] can be adopted. In particular, zero-knowledge proofs allow for a quick verification of the correctnessoftheresultswithouttheneedtoredothecomputation. The downside of this approach is that its applicability and effectiveness depend on how the original computation is conducted. Alternatively, a mitigation strategy can resort to anoraclethatperformstheoff-chaincomputation.This,however,wouldbringthechallengesrelatedtooracles(Sect.6.2). Certification schemes for oracles To address the correct time management (Sect. 6.2.1) and the reliability of oracles (Sect. 6.2.2), a possible solution could be provided by the introduction of certification schemes for oracles. One of such schemes is the usage of a Public Key Infrastructure (PKI) to authenticate oracles and prove that they are reliable. However, such a scheme would require a manual, periodical verification.Consequently,itwouldnotenableapromptreaction in case an oracle gets compromised. Another alternative would be the usage of zero-knowledge proof to constantly verifythebehavioroforacles.However,thisschememaysuffer from the same issues we discussed for certified off-chain offloading. Also, it would require a dedicated protocol that publicly notifies the subscribers when an oracle gets compromised. A third option would be to rely on decentralized oracles [57], where several nodes composing the oracle perform the same operation, and common agreement is reached with voting mechanisms. With such a design, the effort to cheat on the smart contract would become significant as it would require to forge several independent nodes. Moreover, the voting mechanism can determine which nodes cannot be trusted—under the assumption that only a minority of them incurs into problems. Support for late binding of oracles To increase the flexibility in oracles’ invocations (Sect. 6.2.3), a possible solution is to decouple the oracle invocation logic from the off-chain data retrieval one. In this way, it would be possible to create a late binding between the on-chain logic and the oracle, similarly to what has already been proposed for resources [43]. Thereby, an oracle would become dynamically interchangeable while the monitoring platform is running. To that end, a possible approach would include two smart contracts: one for the invocation of the oracle (henceforth, router contract), and one for the actual data processing (henceforth, processor). In particular, the processor contains a reference to the router, which is invoked whenever off-chain data are required. Changing the oracle would require to change the reference to the router in the processor. The reference change would be performed at runtime without causing any service interruption, provided that the processor has been properly designed. The downside of this approach is that it is applicable only for blockchain platforms with advanced programmability. In addition, the complexity introduced by late binding mechanisms may have an impact on the cost of the platform, especially when remuneration is based on cryptocurrency. Invocation patterns for oracles To mitigate the issues related to the alignment between the off-chain world and its onchain representation (Sect. 6.2.4), onecan implement diverse strategies to interact with the blockchain in the oracles [38]. In this way, depending on the requirements of the monitoring application, it is possible to choose the strategy that provides the best trade-off between the need for timely off-chain data and the overhead (and consequent cost) to obtain them. Data quality smart contracts To mitigate data quality issues in the blockchain (Sect. 6.3.1), a possible solution is the implementation of data quality assessment mechanisms in smart contracts [12]. To increase flexibility, data quality mechanisms can be defined as library functions or as external smart contracts. Such libraries and contracts would be referenced or invoked, respectively, from within the smart contracts that are part of the monitoring platform. In this way, low-quality data can be identified and dealt with as soon as they are introduced in the platform. The limitations of this approach are its applicability, which is limited to blockchain platforms with advanced programmability, and the increased on-chain computational requirements that data qualitycontrolsrequire,whichareparticularlyrelevantwhen a blockchain relying on a cryptocurrency-based remuneration scheme is adopted. On-chain digest for off-chain data To address the challenges related to the size of monitoring data (Sect. 6.3.2) and their erasability (Sect. 6.3.4), care should be taken in the design of the smart contract to minimize the amount of on-chain informationtothesoledatathatarerequiredtoperformmonitoring [36]. To this aim, monitoring data can be left in an externally accessible storage such as IPFS[1], and only a reference to those data, together with their digest, be stored on-chain [51]. In this way, the authenticity of monitoring data is preserved. By computing their digest and comparing it against the hash code of the off-chain data, participants can determine if the monitoring data have been altered. Also, when the off-chain data have to be deleted, the digest alone cannot be used to reconstruct them, thus ensuring erasability. This approach alone can only detect if monitoring data were altered. Conversely, it cannot protect data against intentional or accidental corruption. Therefore, it should be combined with traditional techniques, such as distributed storage systems, Redundant Array of Independent Disks (RAID) or Error Correction Code (ECC). Another limitation of this approach is that it cannot rely on smart contracts to process monitoring data. Since smart contracts cannot retrieve and process off-chain data, those data must be first stored on chain, thus reintroducing all the issues related to data size and erasability. Blockchain gateways To address the challenges posed when migrating a blockchain-based monitoring platform (Sect. 6.4.1), a possible strategy is the use of blockchain gateways [23,29]. A gateway provides a blockchain-agnostic protocol to deploy and invoke smart contracts. Thereby, the monitoring application does not need to interact with the blockchain and to understand its protocols and smart contract languages, as those tasks are carried out by the gateway. The limitations of this approach are the need for participants to trust the gateway, and the impossibility for it to migrate data that have already been stored in a blockchain. Blockchain relays To mitigate the issue of accessing data acrossdifferentblockchains(Sect.6.4.2),relayschemeshave been introduced [25]. In particular, the relay acts as a bridge between two blockchain deployments, and the way relays work is similar to that of oracles. When a method is to be invoked or data is to be accessed, the blockchain deployment requesting that information emits an event. That event is then interceptedbytherelay,whichperformstherequestedoperation on the target deployment, and then sends the result to the source deployment via a callback mechanism. As for oracles, relays suffer from similar issues: guaranteeing their reliability and the possibility for them to be replaced at runtime is challenging. It is worth observing that, to the best of our knowledge, no approachhasbeenproposedthusfartomitigateissuesrelated to side effects caused by forks in public or permissionless blockchains (Sect. 6.3.3). Therefore, for a monitoring platform to be immune from the side effects caused by forks, the only solution currently applicable is to rely on a private permissioned blockchain, which is not subject to forks by design. 8 Related work Mendling et al. [49] outline the challenges and opportunities of applying blockchain technology to Business Process Management (BPM). García-García et al. [28] also discuss the benefits of adopting blockchains for BPM, and provide a thoroughreviewofthecurrentresearchworkinthatdirection. Concerning process monitoring, both papers see the challenge of integrating on-chain events related to the execution of a process with external data sources, in order to obtain complete and reliable event logs. They outline the advantages that a blockchain-based monitoring platform would bring too, especially when performing compliance and conformance checking of distributed business processes. Regardingtheimplementationofprocessmonitoringplatforms, to date, preliminary attempts have been proposed that can be the basis to be built upon for process monitoring in the blockchain. Smart contracts allow for the codification of business process logic on the blockchain, as shown in the seminal work of Weber et al. [74]. Later, a similar approach has been applied within the Caterpillar [45] and Lorikeet [72] tools, as well as by Madsen et al. [47] and by Corradini et al. [15]. As several modern BPMSs do, those approaches adopt a Model-driven Engineering (MDE) paradigm to let the process analysts provide graphical representations of the process and turn it into executable code enacting it [17]. López-Pintado et al. [44] propose a blockchain-based BPMS that relies on an interpreted process model. Instead of being transformedintoasmartcontract,theprocessmodelisparsed by existing smart contracts, as it would typically happen with a traditional BPMS. From the monitoring perspective, the efforts have been mostlydevotedtoeventdataloggingthusfar.Tothisaim,two complementary strategies have been proposed in the literature: (i) collecting events originating outside the blockchain to create on-chain execution logs, and (ii) creating off-chain execution logs by analyzing events that occurred on the blockchain. Concerning strategy (i), Meroni et al. [51] rely on the blockchain and on the IoT to collect information on the execution of multi-party processes. In particular, the smart objects in the process use the blockchain to communicate events on their own conditions with each other. Those events are then analyzed by off-chain monitoring techniques, such as artifact-driven monitoring. Similarly, Alves et al. [3] and Sturm et al. [67] extend a BPMS with a connector which stores the process state in the blockchain. Viriyasitavat et al. [73] exploit the blockchain to perform service selection by collecting Quality of Service (QoS) parameters. Asforstrategy(ii),themainrationaleistoextractandprocess the payload of transactions to turn them into event logs that are readily available for process mining tools. The ordering of events is based upon the ordering of the transactions in the ledger, whereas the attributes of the event (activity name, timestamp, resource, and the like) are identified based on the signature of the invoked function on the smart contract [54], a user-defined descriptor (manifest) [36], or the change of the smart contract’s attribute value [19]. Thereupon, process mining techniques (including conformance checking) are held to analyze the generated event logs. Otherapproacheshavebeenappliedtoanalyzeblockchainmediated communications among peers, such as GraphSense [30]. Filtz et al. [24] studied the graph of addresses in Bitcoin and thereby examined the transaction behavior of users, taking into consideration exchange rates between virtual and fiat currencies. Prybila et al. [63] focus in particular on the transposition of handovers of tasks in a process to Bitcoin transactions. With their software prototype, they are thus able to verify the execution flow of a process by tracking the transactions exchanged among peers. Concerning the impact of blockchain in the design of applications, Lo et al. [41] propose a guided method to identify whether blockchains fit the application requirements. Similarly, Xu et al. [80] define a taxonomy to classify blockchains and propose a model to guide the designers in choosing the blockchain that best meets their needs. In [6,21,78], design patterns are proposed to help software architects in designing blockchain-based applications. Müller et al. [55] provide a discussion on how the blockchain can improve trust in collaborative processes, and introduce design patterns specifically devised to increase trust. To our knowledge, save from our previous work [18], we are not aware of any other publication that specifically addresses the challengesandprovidedmitigationstrategiesforblockchainbased process monitoring. 9 Discussion and threats to validity Although the adoption of blockchain to achieve trusted BPM has been investigated by the scientific community and the industry for a few years, it has mostly focused on process execution. Conversely, few research works aiming at process monitoring exist. Therefore, this work is to our knowledge thefirsttoproposeareferencearchitecturefortrustedprocess monitoring, as well as to provide a systematic analysis of the challenges that blockchain introduces. However, this work is not immune from threats to validity. Taking inspiration from theseminalclassificationofZhouetal.[81],weacknowledge that the following ones apply to our work: Restricted time span: The inability of the researcher to anticipate relevant studies outside the time span defined and prepared in the planning phase. As the blockchain is acontinuously evolving technology, several new applications and technologies are introduced every day. Therefore, this article may have not taken into consideration some blockchain implementations or other studies that managed to mitigate or solve the challenges we identified, simply because they were not publicly available at the time of writing. Bias in study selection: The subjective conjecture that researchers have when selecting research work relevant for a publication. This may result in excluding research work that may be relevant for this publication, or in including unrelated research work. In particular, this may haveoccurredduetothedifferentknowledge,experience, and expectations that we have in the field of blockchain. To minimize this threat to validity, each finding was analyzed by all the authors of this paper and included only when general agreement was reached. Bias in data extraction: The subjective conjecture that researchers have when interpreting findings in the related work. Being most of the available blockchain implementations either described at a very high level for marketing purposes,oratverylowlevelfordeveloperstoimplement custom solutions, we may have missed some details or incorrectly understood them. As for bias in data extraction, this threat to validity was minimized by having all authors check all notions and concepts and include them only when all agreed on their description and categorization. Primary study generalizability: The impossibility for the research study to be applicable to contexts other than the onewherethestudywastaken.Thismayresultinthefindings of this publication to be inaccurate or irrelevant for a monitoring platform relying on a blockchain implementationdifferentfromtheonesanalyzedinthispublication. To minimize this threat to validity, we applied the following strategies. First, we verified that each identified challengeaffectedallthemostadoptedblockchainimplementations. Second, we verified for each challenge that no blockchain implementation specifically aiming at addressing that challenge exists. Lack of expert evaluation: Conclusions or results should be evaluated by an expert who understands and interprets the outcome. In this study, an evaluation by experts in academia and industry would be particularly valuable to assess the introduced concepts especially from two standpoints: verification (i.e., checking whether the proposals and notions are practically applicable and theoretically of factually supported) and validation (i.e., dictating whether challenges, constraints or alternative solutionswereoverlooked) [26].Todecrease theforeseeable impact of this threat to validity, we have followed an approach inspired by architecture design in software engineering [58]. We have based this study on the joint examination of the scientific literature in the fields of process monitoring and blockchain technologies and applications. We elicited the requirements from the characteristics a process-monitoring system should expose, and synthesized in an architecture blueprint the abstract system that would meet them resorting to the blockchain, also guided by the expertise of the authors of this article and the precious contribution by the reviewers in the process of writing and revising this paper. Nevertheless, the involvement of more experts is key and draws our plans for future work. 10 Conclusion In this article, we provided a thorough discussion on blockchain-based process monitoring, outlining its advantages and the research challenges it brings. In particular, we explained the need for process monitoring in distributed business processes, and we outlined the insights that a process monitoring platform should provide, together with the information they require. Starting from those elements, we discussed the advantages that blockchain would bring, and we designed a reference architecture for blockchain-based process monitoring. We then focused on the research challenges that a blockchain-based monitoring platform would face, and we discussed how existing research work can mitigate some of them under certain conditions. Future work will focus on how to address the research challenges we identified along two complementary directions. Firstly, we aim at extending the applicability of existing techniques to other blockchains. As we observed, the concept of smart contract is key in our setting and multiple blockchain platforms are evolving toward the support of highly expressive dedicated languages, including Algorand [14] and IOTA [59]. Secondly, we plan to propose entirely new techniques to mitigate or possibly solve the issues that have been currently not addressed yet. Also, we plan to validate the reference architecture by implementing a prototype monitoring platform that realizes it. We aim to highlight how existing blockchain-based monitoring platforms can be framed inside this architecture. This investigation will make it possible to quantify the overhead of a blockchain-based monitoring platform with respect to a traditional one, both in terms of costs and performance , and conduct an informed cost-benefit analysis for the adoption of the former. We hope that researchers and practitioners will become aware of the opportunities and challenges to be faced when designing a blockchain-based process monitoring platform, and of the currently available strategies to circumvent the hurdles or mitigate their effect. By taking inspiration from this article, they could discover and propose additional workarounds or highlight further issues that may arise from specific use cases. Similarly, we expect alternative architectures to be proposed in the future for blockchain-based process monitoring or new mitigation strategies that exploit future advancements both in blockchains and process monitoring. Domain experts in vertical sectors (e.g., logistics, healthcare, etc.) who may want to consider the adoption of a blockchaintosupportthemonitoringoftheirprocessescould alsobenefitfromthereadingofthisarticle.Indeed,bybecoming aware both of the advantages brought by the blockchain in process monitoring and of the challenges it presents, they could exploit these additional criteria to support their decision, which is often driven by strategic reasons and technology push. Acknowledgements The work of G. Meroni and P. Plebani was partly supported by the ITS Italy 2020 cluster under grant number “CTN01_00176_166195.” The work of C. Di Ciccio was supported by the MUR under grant “Dipartimenti di eccellenza 2018-2022” of the Department of Computer Science at Sapienza University of Rome and by the Sapienza research project SPECTRA. Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitteduse,youwillneedtoobtainpermissiondirectlyfromthecopyright holder. To view a copy of this licence, visit http://creativecomm ons.org/licenses/by/4.0/. References 1. Adler, F., Kitzmann, D., Jansen, M.: Analysis of costs for smartcontract execution. In: Prieto, J., Pinto, A., Das, A.K., Ferretti, S. (eds.) Blockchain and Applications, pp. 153–156. Springer, Cham (2020) 2. Ahrendt, W., Bubel, R., Ellul, J., Pace, G.J., Pardo, R., Rebiscoul,V., Schneider, G.: Verification of smart contract business logicexploiting a java source code verifier. In: Hojjat, H., Massink, M. (eds.) Fundamentals of Software Engineering-8th International Conference, FSEN 2019, Tehran, Iran, May 1–3, 2019, Revised Selected Papers. Lecture Notes in Computer Science, vol. 11761, pp. 228–243. Springer (2019). https://doi.org/10.1007/978-3-030- 31517-7_16 3. Alves, P.H.C., Paskin, R., Frajhof, I.Z., Miranda, Y.R., Jardim, J.G., Cardoso, J.J.B., Tress, E.H.H., da Cunha, R.F., Nasser, R., Robichez, G.: Exploring blockchain technology to improve multi-party relationship in business process management systems. In: Filipe, J., Smialek, M., Brodsky, A., Hammoudi, S. (eds.) Proceedings of the 22nd International Conference on Enterprise Information Systems, ICEIS 2020, Prague, Czech Republic, May 5–7, 2020, vol. 2, pp. 817–825. SCITEPRESS (2020). https://doi. org/10.5220/0009565108170825 4. Androulaki, E., Barger, A., Bortnikov, V., Cachin, C., Christidis, K., Caro, A.D., Enyeart, D., Ferris, C., Laventman, G., Manevich, Y., Muralidharan, S., Murthy, C., Nguyen, B., Sethi, M., Singh, G., Smith, K., Sorniotti, A., Stathakopoulou, C., Vukolic, M., Cocco, S.W.,Yellick,J.:Hyperledgerfabric:adistributedoperatingsystem for permissioned blockchains. In: Oliveira, R., Felber, P., Hu, Y.C. (eds.) Proceedings of the Thirteenth EuroSys Conference, EuroSys 2018, Porto, Portugal, April 23–26, 2018. pp. 30:1–30:15. ACM (2018). https://doi.org/10.1145/3190508.3190538 5. Bandara, H.M.N.D., Xu, X., Weber, I.: Patterns for blockchaindata migration. In: EuroPLoP’20: European Conference on Pattern Languages of Programs 2020, Virtual Event, Germany, 1–4 July, 2020, pp. 7:1–7:19. ACM (2020). https://doi.org/10.1145/ 3424771.3424796 6. Bartoletti, M., Pompianu, L.: An empirical analysis of smart contracts: platforms, applications, and design patterns. In: Brenner, M., Rohloff, K., Bonneau, J., Miller, A., Ryan, P.Y.A., Teague, V., Bracciali, A., Sala, M., Pintore, F., Jakobsson, M. (eds.) Financial Cryptography and Data Security-FC 2017 International Workshops, WAHC, BITCOIN, VOTING, WTSC, and TA, Sliema, Malta, April 7, 2017, Revised Selected Papers. Lecture Notes in Computer Science, vol. 10323, pp. 494–509. Springer (2017). https://doi.org/10.1007/978-3-319-70278-0_31 7. Basile, D., Goretti, V., Ciccio, C.D., Kirrane, S.: Enhancing blockchain-based processes with decentralized oracles. In: Enríquez, J.G., Debois, S., Fettke, P., Plebani, P., van de Weerd, I., Weber, I. (eds.) Business Process Management: Blockchain and Robotic Process Automation Forum-BPM 2021 Blockchain and RPA Forum, Rome, Italy, September 6–10, 2021, Proceedings. Lecture Notes in Business Information Processing, vol. 428, pp. 102–118. Springer (2021). https://doi.org/10.1007/978-3-030- 85867-4_8 8. Beyer, J., Kuhn, P., Hewelt, M., Mandal, S., Weske, M.: Unicornmeets chimera: Integrating external events into case management. In: Proceedings of the BPM Demo Track 2016 Co-located with the 14th International Conference on Business Process Management (BPM 2016), Rio de Janeiro, Brazil, September 21, 2016. CEUR Workshop Proceedings, vol. 1789, pp. 67–72. CEUR- WS.org (2016). http://ceur-ws.org/Vol-1789 9. Biais, B., Bisière, C., Bouvard, M., Casamatta, C.: The BlockchainFolk theorem. Rev. Financ. Stud. 32(5), 1662–1715. https://doi. org/10.1093/rfs/hhy095 10. Bowen, H., Yi, L., Li, F., Xinhua, D., Ping, C.: Blockchain-basedaccess control data distribution system. In: 2019 IEEE 5th International Conference on Computer and Communications (ICCC). pp. 1231–1236 (2019). https://doi.org/10.1109/ICCC47050.2019. 9064149 11. Breiki, H.A., Rehman, M.H.U., Salah, K., Svetinovic, D.: Trustworthy blockchain oracles: review, comparison, and open research challenges. IEEE Access 8, 85675–85685 (2020). https://doi.org/ 10.1109/ACCESS.2020.2992698 12. Cappiello, C., Comuzzi, M., Daniel, F., Meroni, G.: Data qualitycontrol in blockchain applications. In: BPM (Blockchain and CEE Forum), pp. 166–181 (2019) 13. Carminati, B., Rondanini, C., Ferrari, E.: Confidential businessprocess execution on blockchain. In: 2018 IEEE International Conference on Web Services, ICWS 2018, San Francisco, CA, USA, July 2–7, 2018. pp. 58–65. IEEE (2018). https://doi.org/10.1109/ ICWS.2018.00015 14. Chen, J., Micali, S.: Algorand: a secure and efficient distributedledger. Theor. Comput. Sci. 777, 155–183 (2019). https://doi.org/ 10.1016/j.tcs.2019.02.001 15. Corradini, F., Marcelletti, A., Morichetta, A., Polini, A., Re,B., Tiezzi, F.: Engineering trustable choreography-based systems using blockchain. In: Hung, C., Cerný, T., Shin, D., Bechini, A. (eds.) SAC ’20: The 35th ACM/SIGAPP Symposium on Applied Computing,onlineevent,[Brno,CzechRepublic],March30–April 3, 2020. pp. 1470–1479. ACM (2020). https://doi.org/10.1145/ 3341105.3373988 16. Denisov, V., Fahland, D., van der Aalst, W.M.P.: Unbiased, finegrained description of processes performance from event data. In: Business Process Management-16th International Conference, BPM 2018, Sydney, NSW, Australia, September 9–14, 2018, Proceedings. Lecture Notes in Computer Science, vol. 11080, pp. 139–157. Springer (2018). https://doi.org/10.1007/978-3-319- 98648-7_9 17. Di Ciccio, C., Cecconi, A., Dumas, M., García-Bañuelos, L.,López-Pintado,O.,Lu,Q.,Mendling,J.,Ponomarev,A.,BinhTran, A., Weber, I.: Blockchain support for collaborative business processes. Informatik Spektrum 42, 182–190 (2019). https://doi.org/ 10.1007/s00287-019-01178-x 18. Di Ciccio, C., Meroni, G., Plebani, P.: Business process monitoring on blockchains: Potentials and challenges. In: Enterprise, Business-ProcessandInformationSystemsModeling-21stInternational Conference, BPMDS 2020, 25th International Conference, EMMSAD 2020, Held at CAiSE 2020, Grenoble, France, June 8–9, 2020, Proceedings. Lecture Notes in Business Information Processing, vol. 387, pp. 36–51. Springer (2020). https://doi.org/ 10.1007/978-3-030-49418-6_3 19. Duchmann, F., Koschmider, A.: Validation of smart contracts usingprocess mining. In: ZEUS, pp. 13–16 (2019). http://ceur-ws.org/ Vol-2339/paper3.pdf 20. Dumas,M.,Rosa,M.L.,Mendling,J.,Reijers,H.A.:Fundamentalsof Business Process Management, 2nd edn. Springer, New York (2018). https://doi.org/10.1007/978-3-662-56509-4 21. Eberhardt, J., Tai, S.: On or off the blockchain? insights on offchainingcomputationanddata.In:Paoli,F.D.,Schulte,S.,Johnsen, E.B. (eds.) Service-Oriented and Cloud Computing-6th IFIP WG 2.14 European Conference, ESOCC 2017, Oslo, Norway, September27–29,2017,Proceedings.LectureNotesinComputerScience, vol. 10465, pp. 3–15. Springer (2017). https://doi.org/10.1007/ 978-3-319-67262-5_1 22. Eberhardt, J., Tai, S.: Zokrates-scalable privacy-preserving offchain computations. In: IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), iThings/GreenCom/CPSCom/SmartData 2018, Halifax, NS,Canada,July30–August3,2018,pp.1084–1091.IEEE(2018). https://doi.org/10.1109/Cybermatics_2018.2018.00199 23. Falazi, G., Breitenbücher, U., Daniel, F., Lamparelli, A., Leymann,F., Yussupov, V.: Smart contract invocation protocol (SCIP): a protocolfortheuniformintegrationofheterogeneousblockchainsmart contracts. In: CAiSE. Lecture Notes in Computer Science, vol. 12127, pp. 134–149. Springer (2020) 24. Filtz, E., Polleres, A., Karl, R., Haslhofer, B.: Evolution of the bitcoin address graph. In: Data Science—Analytics and Applications, pp. 77–82. Springer (2017) 25. Frauenthaler, P., Sigwart, M., Spanring, C., Schulte, S.: Testimonium: a cost-efficient blockchain relay. In: CoRR abs/2002.12837 (2020). arxiv:2002.12837 26. Frederiks, P., van der Weide, T.: Information modeling: the processandtherequiredcompetenciesofitsparticipants.DataKnowl.Eng. 58(1), 4–20 (2006). https://doi.org/10.1016/j.datak.2005.05.007 27. Fridgen, G., Radszuwill, S., Urbach, N., Utz, L.: Crossorganizational workflow management using blockchain technology-towards applicability, auditability, and automation. In: Bui, T. (ed.) 51st Hawaii International Conference on System Sciences, HICSS 2018, Hilton Waikoloa Village, Hawaii, USA, January 3–6, 2018, pp. 1–10. ScholarSpace/AIS Electronic Library (AISeL) (2018). http://hdl.handle.net/10125/50332 28. García-García, J.A., Sánchez-Gómez, N., Lizcano, D., Cuaresma,M.J.E., Wojdynski, T.: Using blockchain to improve collaborative business process management: systematic literature review. IEEE Access 8, 142312–142336 (2020). https://doi.org/10.1109/ ACCESS.2020.3013911 29. Hardjono, T., Lipton, A., Pentland, A.: Towards a designphilosophy for interoperable blockchain systems. In: CoRR abs/1805.05934 (2018). arxiv:1805.05934 30. Haslhofer, B., Karl, R., Filtz, E.: O bitcoin where art thou? Insightinto large-scale transaction graphs. In: SEMANTiCS (Posters, Demos) (2016). http://ceur-ws.org/Vol-1695/paper20.pdf 31. Iqbal, M., Matulevicius, R.: Comparison of blockchain-basedsolutions to mitigate data tampering security risk. In: Business Process Management: Blockchain and Central and Eastern Europe Forum-BPM 2019 Blockchain and CEE Forum, Vienna, Austria, September 1–6, 2019, Proceedings. Lecture Notes in Business Information Processing, vol. 361, pp. 13–28. Springer (2019). https://doi.org/10.1007/978-3-030-30429-4_2 32. Janiesch, C., Koschmider, A., Mecella, M., Weber, B., Burattin, A.,DiCiccio,C.,Gal,A.,Kannengiesser,U.,Mannhardt,F.,Mendling, J., Oberweis, A., Reichert, M., Rinderle-Ma, S., Song, W., Su, J., Torres, V., Weidlich, M., Weske, M., Zhang, L.: The internet-ofthings meets business process management: mutual benefits and challenges. IEEE Syst. Man Cybern. Mag. 6(4), 34–44 (2020). https://doi.org/10.1109/MSMC.2020.3003135 33. Kharbili, M.E., de Medeiros, A.K.A., Stein, S., van der Aalst,W.M.P.: Business process compliance checking: Current state and future challenges. In: Loos, P., Nüttgens, M., Turowski, K., Werth, D. (eds.) Modellierung betrieblicher InformationssystemeModellierung zwischen SOA und Compliance Management-27– 28, November 2008 Saarbrücken, Germany. LNI, vol. P-141, pp. 107–113. GI (2008). https://dl.gi.de/20.500.12116/23621 34. Kirrane, S., Di Ciccio, C.: Blockconfess: towards an architecturefor blockchain constraints and forensics. In: IEEE International Conference on Blockchain, Blockchain 2020, Rhodes, Greece, November 2–6, 2020, pp. 539–544. IEEE (2020). https://doi.org/ 10.1007/978-3-030-85867-4_8 35. Kirrane, S., Villata, S., d’Aquin, M.: Privacy, security and policies: areviewofproblemsandsolutionswithsemanticwebtechnologies. Semantic Web 9(2), 153–161 (2018). https://doi.org/10.3233/SW180289 36. Klinkmüller, C., Ponomarev, A., Tran, A.B., Weber, I., van derAalst, W.: Mining blockchain processes: Extracting process mining data from blockchain applications. In: BPM (Blockchain and CEE Forum), pp. 71–86 (2019). https://doi.org/10.1007/978-3- 030-30429-4_6 37. Köpke, J., Franceschetti, M., Eder, J.: Balancing privity andenforceability of bpm-based smart contracts on blockchains. In: Business Process Management: Blockchain and Central and EasternEuropeForum-BPM2019BlockchainandCEEForum,Vienna, Austria, September 1–6, 2019, Proceedings. Lecture Notes in Business Information Processing, vol. 361, pp. 87–102. Springer (2019). https://doi.org/10.1007/978-3-030-30429-4_7 38. Ladleif, J., Weber, I., Weske, M.: External data monitoring usingoracles in blockchain-based process execution. In: Business Process Management: Blockchain and Robotic Process Automation Forum, pp. 67–81. Springer, Cham (2020) 39. Ladleif, J., Weske, M.: Time in blockchain-based process execution. In: 24th IEEE International Enterprise Distributed Object Computing Conference, EDOC 2020, Eindhoven, The Netherlands, October 5–8, 2020, pp. 217–226. IEEE (2020). https://doi. org/10.1109/EDOC49727.2020.00034 40. Liu, B., Sun, S., Szalachowski, P.: SMACS: smart contract accesscontrol service. In: 50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, DSN 2020, Valencia, Spain, June 29–July 2, 2020, pp. 221–232. IEEE (2020). https:// doi.org/10.1109/DSN48063.2020.00039 41. Lo, S.K., Xu, X., Chiam, Y.K., Lu, Q.: Evaluating suitability ofapplying blockchain. In: 22nd International Conference on Engineering of Complex Computer Systems, ICECCS 2017, Fukuoka, Japan, November 5–8, 2017, pp. 158–161. IEEE Computer Society (2017). https://doi.org/10.1109/ICECCS.2017.26 42. Lo, S.K., Xu, X., Staples, M., Yao, L.: Reliability analysis forblockchain oracles. Comput. Electr. Eng. 83, 106582 (2020). https://doi.org/10.1016/j.compeleceng.2020.106582 43. López-Pintado, O., Dumas, M., García-Bañuelos, L., Weber, I.: Dynamic role binding in blockchain-based collaborative business processes. In: Advanced Information Systems Engineering-31st International Conference, CAiSE 2019, Rome, Italy, June 3–7, 2019,Proceedings.LectureNotesinComputerScience,vol.11483, pp. 399–414. Springer (2019). https://doi.org/10.1007/978-3-030- 21290-2_25 44. López-Pintado, O., Dumas, M., García-Bañuelos, L., Weber, I.: Interpreted execution of business process models on blockchain. In: 23rd IEEE International Enterprise Distributed Object Computing Conference, EDOC 2019, Paris, France, October 28–31, 2019, pp. 206–215. IEEE (2019). https://doi.org/10.1109/EDOC. 2019.00033 45. López-Pintado, O., García-Bañuelos, L., Dumas, M., Weber, I.,Ponomarev, A.: Caterpillar: a business process execution engine ontheethereumblockchain.Softw.Pract.Exper.49(7),1162–1193 (2019). https://doi.org/10.1002/spe.2702 46. Ly, L.T., Maggi, F.M., Montali, M., Rinderle-Ma, S., van der Aalst,W.M.P.: Compliance monitoring in business processes: functionalities, application, and tool-support. Inf. Syst. 54, 209–234 (2015). https://doi.org/10.1016/j.is.2015.02.007 47. Madsen, M.F., Gaub, M., Høgnason, T., Kirkbro, M.E., Slaats, T.,Debois, S.: Collaboration among adversaries: distributed workflow execution on a blockchain. In: FAB, pp. 8–15 (2018) 48. Mehar, M.I., Shier, C.L., Giambattista, A., Gong, E., Fletcher, G.,Sanayhie, R., Kim, H.M., Laskowski, M.: Understanding a revolutionary and flawed grand experiment in blockchain: the DAO attack. J. Cases Inf. Technol. 21(1), 19–32 (2019). https://doi.org/ 10.4018/JCIT.2019010102 49. Mendling, J., Weber, I., Aalst, W.V.D., Vom Brocke, J., Cabanillas,C.,Daniel,F.,etal.:Blockchainsforbusinessprocessmanagementchallenges and opportunities. ACM Trans. Manag. Inf. Syst. 9(1), 41–416 (2018). https://doi.org/10.1145/3183367 50. Meroni, G., Baresi, L., Montali, M., Plebani, P.: Multi-party business process compliance monitoring through iot-enabled artifacts. Inf. Syst. 73, 61–78 (2018). https://doi.org/10.1016/j.is.2017.12. 009 51. Meroni, G., Plebani, P., Vona, F.: Trusted artifact-driven processmonitoring of multi-party business processes with blockchain. In: Business Process Management: Blockchain and Central and EasternEuropeForum-BPM2019BlockchainandCEEForum,Vienna, Austria,September1–6,2019,Proceedings.LectureNotesinBusiness Information Processing, vol. 361, pp. 55–70. Springer (2019). https://doi.org/10.1007/978-3-030-30429-4_5 52. Mohanty, D.: R3 Corda for Architects and Developers: With CaseStudies in Finance, Insurance, Healthcare, Telecom, and Agriculture. Apress, Travel (2019) 53. Mühlberger, R., Bachhofner, S., Castelló Ferrer, E., Di Ciccio, C.,Weber, I., Wöhrer, M., Zdun, U.: Foundational oracle patterns: connecting blockchain to the off-chain world. In: Business Process Management:BlockchainandRoboticProcessAutomationForum, pp. 35–51. Springer, Cham (2020). https://doi.org/10.1007/978-3030-58779-6_3 54. Mühlberger,R.,Bachhofner,S.,DiCiccio,C.,García-Bañuelos,L.,López-Pintado, O.: Extracting event logs for process mining from data stored on the blockchain. In: BPM Workshops, pp. 690–703 (2019). https://doi.org/10.1007/978-3-030-37453-2_55 55. Müller, M., Ostern, N., Rosemann, M.: Silver bullet for all trustissues? blockchain-based trust patterns for collaborative business processes. In: Asatiani, A., García, J.M., Helander, N., JiménezRamírez, A., Koschmider, A., Mendling, J., Meroni, G., Reijers, H.A. (eds.) Business Process Management: Blockchain and Robotic Process Automation Forum-BPM 2020 Blockchain and RPA Forum, Seville, Spain, September 13–18, 2020, Proceedings. Lecture Notes in Business Information Processing, vol. 393, pp. 3–18. Springer (2020). https://doi.org/10.1007/978-3-030-58779- 6_1 56. Nakamoto, S.: Bitcoin: a peer-to-peer electronic cash system(2008). https://bitcoin.org/bitcoin.pdf. Accessed 07 Apr 2018 57. Nelaturu,K.,Adler,J.,Merlini,M.,Berryhill,R.,Veira,N.,Poulos,Z., Veneris, A.G.: On public crowdsource-based mechanisms for a decentralized blockchain oracle. IEEE Trans. Eng. Manag. 67(4), 1444–1458 (2020). https://doi.org/10.1109/TEM.2020.2993673 58. Perry,D.E.,Wolf,A.L.:Foundationsforthestudyofsoftwarearchitecture. SIGSOFT Softw. Eng. Notes 17(4), 40–52 (1992). https:// doi.org/10.1145/141874.141884 59. Popov, S.: IOTA: feeless and free. IEEE Blockchain TechnicalBriefs (2019) 60. Popov,S.,Saa,O.,Finardi,P.:Equilibriainthetangle.Comput.Ind.Eng. 136, 160–172 (2019). https://doi.org/10.1016/j.cie.2019.07. 025 61. Pourmirza, S., Peters, S., Dijkman, R.M., Grefen, P.: BPMS-RA: anovel reference architecture for business process management systems. ACM Trans. Internet Tech. 19(1), 13:1-13:23 (2019). https:// doi.org/10.1145/3232677 62. Praitheeshan, P., Pan, L., Doss, R.: Security evaluation of smartcontract-based on-chain ethereum wallets. In: Kutylowski, M., Zhang, J., Chen, C. (eds.) Network and System Security-14th International Conference, NSS 2020, Melbourne, VIC, Australia, November 25–27, 2020, Proceedings. Lecture Notes in Computer Science, vol. 12570, pp. 22–41. Springer (2020). https://doi.org/ 10.1007/978-3-030-65745-1_2 63. Prybila, C., Schulte, S., Hochreiner, C., Weber, I.: Runtime verification for business processes utilizing the bitcoin blockchain. In: FGCS (2017). https://doi.org/10.1016/j.future.2017.08.024 64. Schulte, S., Sigwart, M., Frauenthaler, P., Borkowski, M.: Towardsblockchain interoperability. In: Di Ciccio, C., Gabryelczyk, R., García-Bañuelos, L., Hernaus, T., Hull, R., Stemberger, M.I., Ko, A., Staples, M. (eds.) Business Process Management: Blockchain and Central and Eastern Europe Forum-BPM 2019 Blockchain and CEE Forum, Vienna, Austria, September 1–6, 2019, Proceedings. Lecture Notes in Business Information Processing, vol. 361, pp. 3–10. Springer (2019). https://doi.org/10.1007/978-3-030-30429- 4_1 65. Scriber, B.A.: A framework for determining blockchain applicability. IEEE Softw. 35(4), 70–77 (2018). https://doi.org/10.1109/ MS.2018.2801552 66. Soffer, P., Hinze, A., Koschmider, A., Ziekow, H., Di Ciccio, C.,Koldehofe, B., Kopp, O., Jacobsen, H., Sürmeli, J., Song, W.: From event streams to process models and back: challenges and opportunities. Inf. Syst. 81, 181–200 (2019). https://doi.org/10.1016/j. is.2017.11.002 67. Sturm, C., Szalanczi, J., Schönig, S., Jablonski, S.: A lean architecture for blockchain based decentralized process execution. In: Daniel, F., Sheng, Q.Z., Motahari, H. (eds.) Business Process Management Workshops-BPM 2018 International Workshops, Sydney, NSW, Australia, September 9–14, 2018, Revised Papers. Lecture Notes in Business Information Processing, vol. 342, pp. 361–373. Springer (2018). https://doi.org/10.1007/978-3-030-11641-5_29 68. Szabo, N.: Formalizing and securing relationships on public networks. In: First Monday, vol. 2(9) (1997). http://firstmonday.org/ htbin/cgiwrap/bin/ojs/index.php/fm/article/view/548 69. Tai, S.: Continuous, trustless, and fair: Changing priorities in services computing. In: Advances in Service-Oriented and Cloud Computing-Workshops of ESOCC 2016, Vienna, Austria, September 5–7, 2016, Revised Selected Papers. Communications in Computer and Information Science, vol. 707, pp. 205–210. Springer (2016). https://doi.org/10.1007/978-3-319-72125-5_16 70. Tasca, P., Tessone, C.J.: A taxonomy of blockchain technologies: principles of identification and classification. In: Ledger, vol. 4 (2019). https://doi.org/10.5195/ledger.2019.140 71. Tikhomirov, S., Voskresenskaya, E., Ivanitskiy, I., Takhaviev, R.,Marchenko, E., Alexandrov, Y.: Smartcheck: static analysis of ethereum smart contracts. In: 1st IEEE/ACM International Workshop on Emerging Trends in Software Engineering for Blockchain, WETSEB@ICSE 2018, Gothenburg, Sweden, May 27–June 3, 2018,pp.9–16.ACM(2018).http://ieeexplore.ieee.org/document/ 8445052 72. Tran, A.B., Lu, Q., Weber, I.: Lorikeet: a model-driven engineering tool for blockchain-based business process execution and asset management. In: BPM Demos, pp. 56–60 (2018). http://ceur-ws. org/Vol-2196/BPM_2018_paper_12.pdf 73. Viriyasitavat, W., Xu, L.D., Bi, Z., Sapsomboon, A.: Blockchainbased business process management (BPM) framework for service composition in industry 4.0. J. Intell. Manuf. 31(7), 1737–1748 (2020). https://doi.org/10.1007/s10845-018-1422-y 74. Weber, I., Xu, X., Riveret, R., Governatori, G., Ponomarev, A.,Mendling,J.:Untrustedbusinessprocessmonitoringandexecution usingblockchain.In:BPM,pp.329–347(2016).https://doi.org/10. 1007/978-3-319-45348-4_19 75. Wood, G.: Ethereum: a secure decentralised generalised transaction ledger (2018). https://ethereum.github.io/yellowpaper/paper. pdf. Accessed 07 Apr 2018 76. van der Aalst, W.M.P.: Business process management: a comprehensive survey. ISRN Softw. Eng. 2013(507984), 37 (2013). https://doi.org/10.1155/2013/507984 77. van der Aalst, W.M.P.: Process Mining-Data Science in Action, 2nd edn. Springer, New York (2016). https://doi.org/10.1007/9783-662-49851-4