A Mapping Review on Cyber-Physical Smart Contracts: Architectures, Platforms, and Challenges

Smart contracts are software systems that monitor, automate, and control the execution of a process, react to violations, and enforce process terms and conditions. There is tremendous interest in developing smart contract applications in banking, finance, insurance, government, and supply chain markets. Many of these applications operate in a cyber-physical environment and adopt architectures based on Internet-of-Things (IoT) and blockchain technologies to support monitoring and ensure data integrity. To investigate how cyber-physical smart contracts are realized for compliance monitoring, together with associated challenges and research opportunities. A mapping review of the literature that surveys underlying architectures and their evaluation. The publications considered came from four databases (Scopus, Web of Science, IEEE Xplore, and Google Scholar), supplemented by manual snowballing. All publications considered are peer-reviewed, written in English, and published in non-predatory venues. A total of 368 publications were considered, with a final selection of 50 papers (all published between 2018 and 2023) that were analyzed along three dimensions: Cyber-physical architectures, infrastructure failures, and technical challenges. Blockchain technologies are the most commonly used platform for smart contracts as they provide decentralized architectures deploying interesting communication patterns, as well as multiple technologies to simplify communication for producing and consuming events. Moreover, such architectures can lead to many types of infrastructure failures including sensor/actuator attacks, network outages, and hardware/software failures, resulting in five important technical challenge areas related to security, availability, robustness, privacy, and legal aspects. Key insights and directions for future research are also reported. This review will inform readers about how cyber-physical smart contracts are being built and deployed and the challenges that are faced by their builders and users.


FIGURE 1.
Bird's eye view of a typical cyber-physical system architecture.
on CPSCs, while section III covers the methodology used in this mapping review. Then, section IV presents the architectures that have been proposed for CPSCs and shows different patterns and components involved in interacting with their environment to receive and process events. As CPSC architectures may experience infrastructure failures and other challenges, section V highlights such failures and mitigations thereof. Section VI further describes technical challenges while section VII provides explicit answers to the research questions that scoped this study and discusses threats to validity. Finally, section VIII concludes and provides insights into possible future research.

II. BACKGROUND A. CYBER-PHYSICAL SYSTEMS
The foundational idea behind the concept of CPS is to keep an eye on and exert control over the physical world by incorporating cyber world capabilities (e.g., computation and communication) into aggregations of hardware [8], often composed of IoT devices. Thus, CPSs can be considered as an integration of physical elements, computing systems, and networks within a larger system where they can be controlled and monitored intelligently. Fig. 1 shows a typical CPS architecture in its most abstract terms.
CPS applications include energy systems, smart systems, automotive systems, aerospace systems, robotic systems, industrial systems, IoT applications, and many more. Each of these applications is expected to adapt to changes that come from the outside world and react differently based on the requirements in a safe, secure, efficient, and (ideally) realtime manner [8].
Typically in CPSs, the cyber and physical worlds are exposed to each other through the use of application programming interfaces (API) where the physical devices contain sensors that report actions and states of the environment being monitored [2], [9].

B. SMART CONTRACTS AND BLOCKCHAINS
The term ''smart contract'' was first proposed by Szabo in the mid-90's [10]. It represents the contractual terms of a legal agreement in the real world, but in a completely digital way. These terms are translated and embedded in smart contracts in the form of code that dictates what can and cannot be done, and that is executed automatically based on the terms of the contract. The general goal here is that smart contracts will self-enforce these terms and minimize the need for (trusted) third parties between transnational or transorganizational parties, while obtaining better monitoring and verification where terms must be satisfied [10].
Smart contracts often represent terms or conditions of a legal agreement using functions and events [1], possibly with rule-based patterns to recognize those events [11]. For example, if a contract's terms specify that if the shipment exceeds the expected arrival date, then fees must be triggered against the shipping company, then the arrival of the shipment on a given date must be a recognizable event.
As observed by Niya et al. [7], blockchain is the decentralized ledger technology most commonly used in recent years. Blockchain is a peer-to-peer technology that enables storing and monitoring data in a distributed and decentralized manner [12]. The venue of blockchain platforms has revived the concept of smart contract (Fig. 2) while providing decentralized execution and additional benefits such as immutability and transparency.
Smart contract implementations have capabilities for storing, sending, and receiving data [13]. Implementations can rely on a trusted centralized, decentralized, or some hybrid model [14], [15]. Buterin [16] created a leading DLT platform, called Ethereum 2 ), that features smart contract capabilities allowing the creation of distributed applications in many areas. Bitcoin, 3 which is the first and likely the best-known blockchain platform, supports smart contracts that can process simple transactions. In contrast, Ethereum and other blockchain platforms such as Hyperledger Fabric 4 can process complex transactions and store records of any data.
There are different types of smart contracts that exist on such decentralized platforms, and they are often developed using different languages: 1) Bitcoin-style smart contracts: Use simple instructions as the Bitcoin platform features limited support for conditions, basic arithmetics, logical operations, and cryptography operations (e.g., for verifying digital signatures) on the blockchain [17]. 2) General-style smart contracts: Use advanced scripts, written in common high-level languages, which are hosted on virtual machines (e.g., deployed using Docker) in order to support the execution of smart contracts on the blockchain. For example, a smart contract for the Hyperledger platform can be written in Java, JavaScript (Node.js), or Go [18]. 3) Domain-specific smart contracts: Use programming languages that exploit domain-specific knowledge to support contract-related concepts. For example, Ethereum supports Solidity, which features a Turing-complete scripting language for a variety of smart contract applications [19], as well as many other domain-specific programming languages (e.g., LLL, Serpent, and Vyper). Furthermore, many approaches [20], [21], [22] have introduced new specification languages for modeling smart contracts. There are also three types of blockchain-based ledgers: private, public, and consortium. These differ on the ability of parties to read and write from a ledger, the ability of nodes to join the blockchain network, the ability of nodes to validate and publish a block, and the type of consensus mechanism. For example, only assigned nodes can join the network and validate transactions in a private ledger. However, in a public ledger, anyone can enter the network and publish a new block. Consortium ledgers are in between private and public ledgers [12], [19], [21]. Both Bitcoin and Ethereum are examples of public blockchains, and their respective ledger is available to anyone. Hyperledger Fabric is an example of a private blockchain where the ledger is kept concealed and access is restricted [19].

III. RESEARCH METHODOLOGY
A mapping review is designed to provide an overview of the literature relevant to research questions by exploiting academic research databases and complementary search approaches, selecting and analyzing the relevant articles, and synthesizing answers to the research questions. A mapping review also helps identify research gaps and is more oriented towards answering questions than a scoping review, the latter being usually more topic-based and used to scope and characterize the existence of the literature.
To provide explicit and reproducible systematic literature reviews (including mapping reviews), Okoli [23] defined a four-phase methodology that this mapping review follows: 1) Planning: Planning the review by identifying the review purpose and the research questions. 2) Selection: Searching and screening the literature for relevant studies. 3) Extraction: Extracting from the papers the data that is relevant to the research questions, and appraising their quality. 4) Execution: Answering the research questions by synthesizing answers from the extracted data and reporting the results. Fig. 3 illustrates the phases involved in the performed mapping review. Also, as done in most literature reviews, a PRISMA diagram [24], [25] is used to summarize the results of various inclusion and exclusion steps of the selection and extraction phases.

A. PLANNING PHASE
This review aims to describe the state-of-the-art for CPSCs. Towards this purpose, the following four research questions have been framed: • RQ1: What are the current platforms that support the implementation of CPSCs for event-based monitoring?
• RQ2: How do CPSCs produce and consume events from/to the outside world for monitoring?
• RQ3: What are current techniques for mitigating CPSC execution failures in event-based monitoring?
• RQ4: What are the main technical challenges faced in the development of CPSCs for event-based monitoring?

B. SELECTION PHASE
To answer the four review questions, an abstract search query that composes the four essential concepts related to this review (smart contract, CPS, monitoring, and event) and their synonyms/variants was designed to find relevant academic papers. The * truncation operator enables matching different variants of a keyword (e.g., for plural forms).
''smart contract * '' AND ( architectur * OR cyberphysical OR ''cyber-physical" OR "cyber physical'' OR CPS OR platform * ) AND monitor * AND event *  This abstract query was tailored for several databases presented in Table 1. Scopus and Web of Science were included as they are broad-scope, curated databases that cover over 100 million records, and IEEE Xplore (which contains many CPS and smart contract papers) and Google Scholar (again, very broad in scope) were included for their full-text search capabilities.
The concept of ''event'' in the query was too restrictive when limited to title/abstract/keyword information for Scopus and Web of Science. Therefore, ''events'' was removed from their query, and a manual full-text search for ''events'' was conducted. However, as IEEE Xplore supports full-text search, ''events'' was kept in the full-text search field. For Google Scholar, given the severe limitations of its search engine, a simpler query containing the main keywords was used, and its results were only considered up to a predetermined depth based on Scholar's ranking of the papers' relevance.
The review followed an automatic search from the four databases mentioned in Table 1. Additionally, several relevant papers have been found by exploring the referenced works through a complementary backward snowballing strategy (as suggested by Mourão et al. [26]).
The literature search was performed in April 2023. The retrieved papers were first screened using Covidence [27] based on the inclusion and exclusion criteria shown in Table 2. For that part of the screening, title, keywords, abstract, introduction, and conclusion of each papers were reviewed. Articles that met any of the exclusion criteria were excluded and the reasons were noted.
Although there are related patents that exist in that space, e.g., for general contract monitoring [28], smart contract compliance monitoring [29], or the monitoring of smart  contracts themselves [30], patents were not included as they are not peer-reviewed according to scientific criteria.

C. EXTRACTION PHASE
After completing the first screening iteration mentioned earlier, a second iteration that combined screening and data extraction was conducted, this time using a full-text review. Some articles were excluded based on the quality assessment conducted by the first author. Only articles coming from a non-predatory source of information and meeting at least one of the following assessment criteria were included: 1) Clarified the architecture(s) where the smart contract can be used for event-based monitoring. 2) Clarified how smart contracts interact, consume, and produce events. 3) Discussed infrastructure failures.

4) Discussed challenges faced by developers when
embedding smart contracts in CPSs. 5) Evaluated the architecture(s). Many studies were excluded because there was neither a clear description of a proposed architecture nor a discussion related to failures or challenges. Some of these papers are however cited in the previous sections and in the discussion as they still provided some useful information to support the content of the review.
A PRISMA diagram [24] summarizing the selection results is presented in Fig. 4.
The analysis was done using Microsoft Excel and is available on Zenodo. 5 A table was created with different columns used to extract relevant data, including the article information (title, authors, year); the location of the smart contract, its data, and its events in the architecture (onchain, off-chain, hybrid); the platform used; the deployment technology; the smart contract languages used; the overall approach to event production and consumption; the types of infrastructure observed; and the types of technical challenges faced.

D. EXECUTION PHASE
Answers to the research questions were synthesized by manually clustering the extracted data into different categories related to architecture, failures, and challenges, which are presented in the next sections.
The results overview, presented in Fig. 5, shows that the research on CPSCs started in 2018 with its first publications, and that the highest number of selected publications was in 2022. Note that the queries were run in April 2023, so the results from 2023 are partial.

IV. ARCHITECTURE
In this section, the first and second research questions are answered. The answer to RQ1 on platforms is spread over sections IV-A and IV-C while the answer to RQ2 on events is provided in section IV-B. The first question demands a detailed description of existing architectures for CPSCs, while the second question demands details on how data and events from the environment are produced and consumed while monitoring for compliance.

A. OVERVIEW
Typically, CPSCs consist of several physical (IoT) components that are responsible for collecting data from the outside world and controlling the environment. IoT devices are usually deployed as IoT components that include multiple devices and come in some sort of architecture. These components are networked and controlled by cyber components (e.g., by smart contracts) [2]. Fig. 6 illustrates such physical components, cyber components, and the network. The physical components are usually sensors and actuators [9]. The sensors collect and transmit sensor data through a wired/wireless network to the cyber components. Such an architecture enables compliance monitoring and helps check the enforcement of predefined terms of the contract impacting the physical world [1].
Implementations of CPSCs that have been published in the literature are shown in Table 3. They are presented along different architectural characteristics, including smart contract location and data location (on-chain, off-chain, hybrid), platforms, deployment technologies, implementation languages for the smart contract, and the methods used for producing and consuming events. These implementations utilize blockchains as their underlying back-end infrastructure, with the system's operations and business logic encoded in smart contracts. When events or sensor data from the physical world are reported, the smart contract is invoked, and its predetermined terms and rules are executed automatically [9]. In recent years, relatively few studies have focused on the development of smart contracts for centralized systems, compared to decentralized ones [2], as using decentralized blockchain-based architectures offers desirable immutability and transparency features [9].
Blockchain is also employed as a back-end storage solution for storing sensor data and events or for keeping pointers to data stored in another layer of the architecture (off-chain). Storing information on a blockchain is however costly in terms of time, space, energy, and money. Accordingly, some studies have utilized off-chain storage options such as the Interplanetary File System (IPFS) [31], [32], [33], [34], Swarm [32], or Couch DB [11], [35], [36]. These off-chain storage systems allow for more cost-effective and faster alternatives.
Smart contracts are created using either specialized languages like Solidity or general-purpose programming languages like Java, Go, or JavaScript. In the conducted review, Solidity was found to be the most frequently-cited language among the selected papers, as shown in Fig. 7.
Additionally, smart contracts can be deployed on top of centralized (off-chain) or decentralized (on-chain) platforms [2]. However, some recent studies have demonstrated that smart contracts can also be implemented on both VOLUME 11, 2023  centralized trusted third-party and decentralized platforms (hybrid), where a smart contract running on a decentralized platform can trigger another smart contract on a centralized platform, depending on the execution process [14], [15]. Fig. 8 illustrates the current trend of smart contract implementation platforms. Also, among the selected papers, Ethereum and Hyperledger Fabric are the leading blockchain platforms used for the implementation of smart contracts.
Furthermore, generated events play a crucial role in the implementation of smart contracts for monitoring compliance in the physical world. They are used by smart contracts to record or report violations. Event hubs or logs are available in the cyber components of the CPSC, which run on centralized or decentralized platforms and provide access to the events generated by smart contracts to the physical components of the system.
Several studies employ different protocols -such as constrained application protocol (CoAP) and message queuing telemetry transport (MQTT) -to facilitate communication between physical and cyber worlds in regard to sensor data and events [37]. MQTT is the most frequently-cited protocol in the selected studies, which is used for storing, publishing, and aggregating sensor data and events and transmitting them to smart contracts. Section IV-B provides a more detailed description of how smart contracts produce and consume sensor data and events from and to the physical world.
By examining the published literature on the implementation of CPSCs, we have arrived at a partial answer to the first research question regarding existing architectures for CPSCs, as summarized in Table 3.

B. PATTERNS TO INTERACT WITH THE PHYSICAL WORLD
Having gained insight into the programming languages and platforms involved in constructing CPSCs for compliance monitoring, it is time to address the second research question by providing details on how smart contracts produce and consume events generated from the physical world. This section provides a general overview of the commonly used patterns and components in the literature for maintaining the connection between smart contracts and the physical world.
The ability of smart contracts to enforce contract terms depends on receiving events and data from the physical world. However, on-chain smart contracts cannot interact directly with the physical world; extra components (e.g., data carrier) must be used to maintain the connection between smart contracts and the physical world [42]. This is due to the fact that some DLTs are designed to run smart contracts in isolation to be disconnected from the outside world, offering secure and reliable sharing of contractual agreements of event-driven monitoring [42], [45]. For instance, Ethereum does not allow smart contracts to query data directly from the outside world, but Hyperledger Fabric does [46]. However, a hybrid blockchain has been suggested by Falazi et al. [58] as a way for smart contracts to directly access off-chain data. Regardless, data carriers may still be necessary for any blockchain-based smart contracts to ensure a deterministic behavior of smart contracts in monitoring CPSs [46].
Single-board computers like Raspberry Pi are also used to facilitate communication between the outside world and blockchain-based smart contracts. The Raspberry Pi boards gather sensor data from external sources (e.g., cloud, IoT devices) and execute the relevant function within the smart contract [13], [37]. This causes the smart contract to initiate events to record the new data or contract violations.
Additionally, REST servers offer several REST APIs to connect the outside world to blockchain-based smart contracts [9]. These servers allow web applications or physical components to interact with smart contracts to access monitored data and events. Similarly, Ethereum provides several APIs (known as Web3 APIs) for calling back events monitored by smart contracts from the physical world [13].
Furthermore, an oracle acts as a data carrier or a mediator to establish a secure connection between blockchain-based smart contracts and external components such as APIs, IoT devices, cloud providers, and more [38], [39], [42], [43], [44], [45], [46], [47], [49], [59]. Fig. 9 illustrates the basic architecture of an oracle in conjunction with smart contracts and Table 4 provides a description of the function of each type besides other patterns that enable physical components and smart contracts to communicate with each other in interconnected ways.
Based on the reviewed literature, all of the above-mentioned technologies can be leveraged in centralized, decentralized, or hybrid models for CPSCs, except for the Web3 API, a builtin functionality provided by the Ethereum blockchain that can be utilized on either decentralized or hybrid models.

C. LAYERED ARCHITECTURE OF CPSC
From the literature listed in Table 3 and according to Governatori et al. [61], there are three main approaches for applying smart contracts for compliance monitoring in CPSCs: The smart contract is managed by a third-party server, the contract's terms and conditions are monitored/carried out off-chain, and contract-related data and events are stored off-chain.
• Decentralized (blockchain implementation)(on-chain): The smart contract is deployed on the blockchain, the contract's terms and conditions are monitored/carried out on-chain, and contract-related data and events are stored on-chain.
• Hybrid (off/on-chain implementation): The smart contract can be divided where a part of the smart contract is placed on-chain, while the other part remains offchain. Some of the contract's terms and conditions are monitored/carried out off-chain, while the rest is monitored on-chain. Some contract-related data and events are stored off-chain, and the rest is stored on-chain. Based on the reviewed literature, different architecture implementations were chosen by developers based on criteria such as privacy and scalability [15]. However, blockchain-based architectures were the most cited ones among selected papers. Few studies investigate off-chain and hybrid architectures.  Several design concepts have been proposed for using smart contracts to monitor compliance by utilizing sensor data and events generated by IoT devices. Part of the literature suggests a monitoring architecture that includes a front-end monitoring application to observe sensor data and events produced by the physical world [7], [13], [33]. Typically, external applications initiate smart contracts to monitor and enforce contract terms, while smart contracts store sensor data and record related events. In their architecture, smart contracts are deployed, installed, and instantiated on every node on the blockchain network, which serves as a back-end storage and processing infrastructure.
Hasan et al. [1] proposed a blockchain-based smart contract for monitoring product shipments, defined by business rules and risk thresholds. The physical world's IoT-enabled containers and sensors are used to track the movement of the product and perform self-checks of various measurements, comparing them to predefined conditions. An MQTT server is employed to store, aggregate, and regularly publish sensor readings. If there is a violation, the container will initiate a call to the smart contract, triggering and registering an event in the events log. A similar approach was proposed by Lockl et al. [13]; however, the main difference is that a monitoring dashboard application is available to end-users, allowing them to monitor sensor data and related events and register components. Additionally, the blockchain is used as a light node, storing only the hash of blocks rather than the entire blocks. In another similar approach proposed by Hang and Kim [9], smart contracts are utilized to store sensor data and keep track of the configuration of physical components. The contracts trigger events when predefined monitoring conditions are met or violations occur. A client application can send a request via REST APIs to the smart contract to either register a new component for monitoring or access stored sensor data and events. CoAP is employed by the server to transmit sensor data from devices to smart contracts in realtime.
Furthermore, a four-layered architecture for CPSCs was proposed by Tahmasebi et al. [33], consisting of application, service management, gateway, and physical layers. The gateway layer collects and saves the sensor data from the real world in off-chain storage. Smart contracts are triggered by the aggregated data and executed accordingly. An implementation of two smart contracts on the blockchain monitors the execution and registration of IoT devices. The sensor data produced by these devices is stored in off-chain storage using IPFS. Bagozi et al. [31] also presented a CPSC in a four-layered architecture that includes the acquisition, gateway, blockchain, and application layers. However, they use smart contracts to provide anomaly detection services based on the sensor data and related events from monitored devices.
Zhou et al. [40], Lopez-Pintado et al. [32], and Kochovski et al. [49] propose decentralized architectures for CPSCs similar to the architecture of the abovementioned literature, including physical, gateway, distributed (blockchain), and application layers. It is worth mentioning that some studies have combined some layers or used different terminology. For instance, Lopez-Pintado et al. [32] proposed a three-layered architecture of CPSCs for compliance monitoring consisting of storage, access, and processaware layers. Zhou et al. [40], Lopez-Pintado et al. [32], and Kochovski et al. [49] differ from the above literature by adding an extra layer for off-chain events monitoring. Zhou et al. [40] introduced a witness model to report violations and monitor off-chain events stored in the cloud. In contrast, Lopez-Pintado et al. [32] added an off-chain event monitoring model to retrieve and monitor on-chain events stored on an event log. On their side, Kochovski et al. [49] added a decision-making layer with a decision-making mechanism, a monitoring system, and an orchestration system for off-chain monitoring.
The literature highlights the importance of various components such as devices, event management, off-chain storage, communication interface, off-chain monitoring systems, and client applications that are connected using decentralized, centralized, or hybrid architectures. Fig. 10 presents a typical tier architecture for compliance monitoring of CPSCs, obtained from the reviewed literature. CPSCs can have multiple independent layers that developers can modify. However, the minimum requirements for building CPSCs are displayed in the figure and described as follows: 1) Physical tier: This layer contains physical devices (e.g., sensors and actuators), data storage, communication protocols, and so on. Physical devices collect sensor data and events from the physical world and pass them to the next tier. 2) Delivery, Aggregation, and Control tier: This tier is composed of data carriers that validate and verify the data generated from the physical world before sending it to the service tier. It may also contain monitoring agents that process the data received from sensors for compliance monitoring and trigger the appropriate smart contract function in the service tier. Each of them has communication capabilities to communicate with the service tier. 3) Service tier: This is the tier where the smart contracts are placed to pull information from the physical world to apply the agreed policy from the agreed legal contract. Also, in this tier, events are generated based on the compliance monitoring rules specified by smart contracts. All events, sensor data, and device information are stored in this tier as well. Fig. 10 shows three main options, where SC execution and monitoring can occur on-chain, off-chain, or both on-chain and off-chain. 4) Application tier: This tier provides many services, such as monitoring the execution of the physical world (e.g., a monitoring dashboard), allowing users to interact with the data, or performing analysis on them. Additionally, based on the reviewed literature, there are several options for storing collected sensor data and events generated by the physical world, where smart contracts can access data/events through the control layer for compliance monitoring purposes. Table 5 lists various data storage options where sensor data and events are being consumed from and produced for the physical world.

V. INFRASTRUCTURE FAILURES
After reviewing existing architectures for CPSCs, and the way events are generated and consumed in the environment that is being monitored, we focus here on RQ3. Specifically, we study possible infrastructure failures and summarizes existing approaches to alleviating these failures. Fig. 11 shows the risks that are identified from the reviewed literature and the corresponding mitigation approaches.
The first noticeable risk is that sensor data and related events that are generated by the physical world are not sent directly to the smart contracts; rather, they are stored and transmitted through a third party (i.e., data carrier) that resides on a centralized architecture. This approach is particularly vulnerable because it consists of a single point of failure [47]. Taghavi et al. [47] suggest utilizing multiple data carriers to feed the data to smart contracts from the outside world as a mitigation approach.
Another risk is that CPSCs rely on centralized services (e.g., cloud, fog node, MQTT, and CoAP servers) for storing  physical device information and performing operations on them. However, a disadvantage here is, again, a single point of failure for such services [9]. The suggested mitigation approach is to combine centralized storage with distributed storage, such as blockchains [9]. This concern is exemplified by the Atlanta Ransomware Attack 6 in 2018, where a 6 https://l8.nu/qh9M 65882 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply. ransomware incident targeted the centralized infrastructure of the city, causing disruptions to critical services. This incident serves as a stark reminder of the risks associated with relying solely on centralized services in CPSCs. To enhance resilience and mitigate the impacts of such infrastructure failures, it becomes crucial to explore decentralized and distributed storage solutions, such as blockchains, to ensure the availability and integrity of CPSC operations [9].
Additionally, monitoring processes that involve multiple agents entails the risk of failures resulting from agents not following the agreed protocol of execution. Shukla et al. [2] propose CPSCs that monitor process execution and detect anomalous executions (centralized or decentralized). For instance, the Binance Smart Chain exploit in 2022 serves as a relevant example. 7 In this incident, an attacker exploited a vulnerability in the Binance Smart Chain's infrastructure, manipulating a smart contract's code to steal a significant amount of ''FOO'' tokens. Such incidents emphasize the importance of implementing robust security measures and conducting careful code reviews to prevent unauthorized access and manipulations of smart contracts.
Moreover, running a CPSC on a single node can result in system failure if the node fails. Hang and Kim [11] utilize blockchain as back-end storage for compliance monitoring. However, their system runs on a single node, which makes it fault-intolerant. The authors do point out that the usage of a single (solo) node is suitable for running smart contracts for testing purposes only. However, for production purposes, they suggest using clustering nodes for implementation, such as those used by Kafka 8 or Raft 9 to avoid system failures.
Furthermore, components that reside off-chain are vulnerable to tampering. In this context, Lopez-Pintado et al. [32] suggest the use of distributed data storage, such as blockchain, to store sensor data and related events. This mitigation approach provides reliable and secure storage, so all compliance monitoring processes happen on-chain.
Typically in CPSs, IoT contains multiple sensors that are responsible for producing and exchanging massive quantities of data. Such sensors are themselves vulnerable to cyberattack and hence compromise the integrity of the data. IoT/DLT integration is suggested as a paradigm to handle such attacks [9].
Intercepting and altering the order of received data is another risk that can cause major losses. IoT/DLT integration can provide a level of authenticity of IoT devices, such as actuators, to ensure the integrity of transmitted data [9].
Finally, good network connectivity is crucial for IoT devices to perform properly and transmit sensor data to the smart contract; failure to do so can result in significant losses of sensor data and events [9]. 7 https://l8.nu/qhbw 8 https://kafka.apache.org/ 9 https://raft.github.io/

VI. TECHNICAL CHALLENGES
On the basis of our mapping review, five main challenges were identified as an answer to RQ4, as shown in Fig. VI: Security, availability, robustness, privacy, and legal and regulatory aspects.

A. SECURITY
Smart contracts cannot directly access off-chain data accumulated by monitoring the outside world. Instead, access needs to be provided by a third-party data carrier [38], [39], [42], [43], [45], [46], [47], [49], [59]. This is because smart contracts have been designed to operate in a closed environment, disconnected from the outside world for security reasons [19], [42], [45]. Oracles have been used as a data carrier solution to fetch data from different data sources, verify them, and send them to the smart contract [42], [44], [45], [46], [47]. However, the trustworthiness of oracles and the integrity of provided data have become challenging. Therefore, the lack of trusted data carriers and the absence of a robust environment of reliable data sources impede the applicability of CPSCs.
Another concern is the lack of security measures for the communication between physical and cyber components used to link smart contracts with the outside world [63]. For example, the communication between REST APIs and physical components (e.g., IoT) [11], [37], [50]. Similarly, as more heterogeneous physical and cyber components and services become connected to cyber-physical smart contract systems, more security risks, insecure connections, and bugs are expected to happen [64].
To deal with those smart contract vulnerabilities and take advantage of the CPSC paradigm, blockchain-based smart contracts have been proposed as a solution because they provide distributed security with their cryptographic mechanisms, especially when sensor data and events are collected and shared among different physical and cyber components [64]. Additionally, security analysis tools for contract vulnerabilities are constantly being developed to find potential security bugs and check compliance and potential violation of contract behavior. VOLUME 11, 2023 Two relevant open source audit tools are Securify 10 and Manticore. 11 Securify is a security audit tool for Ethereum smart contracts. It uses symbolic analysis on the dependency graph of the contract to obtain accurate semantic details from the code, and then it checks whether the smart contract behaves according to what is intended. Manticore is another symbolic execution tool capable of tracing smart contract transaction inputs to detect potential violations.
Furthermore, an Intrusion Detection System has been developed to handle other vulnerabilities and cyber and physical attacks as a result of the increasing incorporation of cyber and physical components where sensor data and events are collected and used to monitor different features of a CPSC [31], [34], [62], [63], [65]. An Intrusion Detection System is a software tool that can be used to detect attacks automatically using machine learning, deep learning, or other techniques [34]. It is responsible for detecting attacks, triggering warnings, or taking action [34]. For example, Bagozi et al. [31] developed an anomaly detection service to monitor sensors and check if identified measures of sensor data are above or about to reach pre-identified thresholds during a transportation journey. Kumar et al. [34] propose a scalable blockchain-based smart contract for secure data transmission. Also, A deep learning architecture combining Deep Sparse AutoEncoder with Bidirectional Long Short-Term Memory is proposed for intrusion detection in a healthcare network. Kumar et al. [63] discuss IoT-based zero-touch networks for secure data sharing. They also suggest a deep learning approach for intrusion detection. Kumar et al. [62] suggest a two-level approach for data security. The first level uses blockchain and smart contracts to ensure secure data exchange, while the second level utilizes deep learning to encode data into a new format that prevents attacks. Kumar et al. [65] suggest a new framework for secure data sharing in Intelligent Agriculture that utilizes deep learning and smart contracts enabled by the Internet of Things to detect intrusions.
Note that the above technological solutions to security concerns are those that focus on cyber-physical smart contracts, as scoped by our research questions and search query. Other solutions to security vulnerabilities targeting other types of systems can be found in the work of Leka et al. [5].

B. AVAILABILITY
Availability in cyber-physical smart contracts relates to the capacity of smart contracts to maintain their state and be accessible to entities and physical and cyber components, regardless of the circumstances, e.g., power outages, network outages, attacks, or resource limitations [13]. For example, using Wireless Sensor Networks as a network infrastructure constitutes a risk because of limitations with respect to connectivity, data stream, energy, storage, and capacity [33]. Also, the current CPSC paradigm relies on transmitting 10 https://github.com/eth-sri/securify2 11 https:https://github.com/trailofbits/manticore sensor data and events to off-chain centralized servers that represent single points of failures before delivering them to smart contracts for compliance monitoring [13].
Maintaining CPSC availability is challenging, especially in scenarios where it is critical to ensure data is always available. For instance, such scenarios include monitoring sensor data and events in healthcare systems or food supply chains, which can be addressed by ensuring continuous functioning of both cyber and physical components even if some of them are damaged, and by implementing solutions to handle potential single points of failure [13].
To tackle the challenges related to availability, the CPSC paradigm can integrate various recommended methods, such as redundancy and load-balancing capabilities. An IoT/DLT architecture has often been used as a back-end infrastructure as it maintains redundancy [13]. Blockchain-based architectures allow cyber and physical components to be distributed over multiple nodes handling the same tasks; there is no single point of failure. Thus, when one node fails, the other nodes can take over [37]. Another approach is to use load-balancing, which allows deploying physical and cyber components over different resources to avoid overloads [49].

C. ROBUSTNESS
Smart contract robustness is crucial for maintaining contact with the physical world via actuators and sensors. Currently, there is a significant rise in the adaptation of physical components such as IoTs due to their capabilities to provide real-time data and enable networking among various CPS applications [66]. Also, the amount of generated real-time data by IoTs is increasing, which requires massive storage, processing techniques, and networks allowing them to interact with other physical and cyber components and exchange data for compliance monitoring conducted by smart contracts [66]. Thus, since CPSCs involve growing cyber and physical components and data, it is hard to maintain robustness and expect how the systems can react to different conditions, e.g., power constraints, network outages, IoTlimited resources, and so on. Also, such systems adopt a centralized architecture that is exposed to data loss at any given time, as such architecture is not fault-tolerant [66].
To address these challenges, many studies, such as [13] and [66], report on architectures that achieve fault-tolerance through redundancy, which ensures that if one component stops responding for any reason, other components can carry out. Another robust mechanism is the use of artificial intelligence and expert systems to make decisions about an CPSC's behavior and take actions accordingly, e.g., redistribute resources to avoid overwhelming IoT devices of the monitored environment [66].

D. PRIVACY
As indicated earlier, many CPSCs studied in the literature adopt an IoT/DLT architecture. However, maintaining sensory data on-chain is expensive. Therefore, several studies have turned to alternate hybrid approaches for storing sensor data and physical device information. Such practices are prone to privacy violations, particularly in terms of data privacy for smart contracts and the privacy of data carriers that contain sensitive data concerning the monitored process [13], [51].
Currently, public blockchains represent a real challenge as they do not support access control, resulting in unrestricted access to contract-related data and sensor data, as access to sensitive data can not be prevented. Thus, a variety of solutions have been suggested, such as (1) zero-knowledge proofs [34], [56], [67], (2) homomorphic encryption [57], and (3) secure multi-party computation [57]. Kosba et al. [67] proposed a model called Hawk that allows developers to write a privacy-preserving smart contract using zero-knowledge proofs that can keep its privacy to prove the validity of transactions to contract parties without exposing its content. Also, Kumar et al. [34] suggested a privacy-preserving scheme to protect and prevent data leakage during the transmission of data from/to smart contracts. This privacy-preserving scheme involves verifying IoTs using zero-knowledge proofs. Hewa et al. [56] utilized zero-knowledge proof to maintain anonymity of identities stored in blockchains. Other privacy-preserving primitives suggested by Zhang et al. [57] include homomorphic encryption and secure multi-party computation. Homomorphic encryption keeps data confidentiality by conducting operations on encrypted data [38], whereas secure multi-party computation is another type of encryption that allows parties to come together to conduct computation on off-chain functions without disclosing their data [15].
For Data carriers, they do not all have the same level of privacy and data access because sensor data and events are collected and shared among different off-chain data sources in CPSs. Therefore, the privacy and integrity goals of data carriers are challenging. Town Crier [68] is an approach that provides controlled access to off-chain data provided by different data carriers.
It is worth noting that these privacy-preserving approaches are resource intensive in a cyber-physical smart contract environment full of IoT devices with limited capacity.

E. LEGAL AND REGULATORY
As stated earlier in section II, a smart contract is a program created using a programming language, such as Go, JavaScript, or Solidity, that can independently enforce, verify and control the execution of a legal contract. However, a smart contract may not always be considered a completely enforceable legal contract, depending on how well it satisfies the requirements of laws and legal standards [69]. Thus, there could be an inconsistency between the legal contract and its corresponding digital representation, which may affect the codification of laws [69]. Recent research initiatives related to this matter [20], [21], [22] aim to enable the development and verification of legal contracts and their corresponding smart contracts through the use of domain-specific languages with various levels of formality.
There could also be legal issues with the data manipulated by smart contracts. For example, in European countries and in the US, people's medical data are protected under privacy protection regulations and governance [50], which allows individuals to ask for their personal information to be removed; this is the so-called ''right to be forgotten''. Such provision conflicts directly with the immutability feature of smart contracts that leverage blockchain technology.
In addition, the execution of smart contracts is a dynamic process that cannot occur in isolation, as it is often influenced by various factors and external forces [61]. These factors involve rules and regulations (the law in a particular jurisdiction) from other contracts and external events from IoT devices that may affect the contract's outcome.
Thus, legal and regulatory challenges include, but are not limited to: • Determining which legal rules and regulations would apply to transactions being executed in CPSC applications; • Deciding on a strategy for the modification and deletion of data from the blockchain (e.g., through access removal or blockchain forking), as required by applicable legislation; • Determining who takes responsibility for the consequences (disputes, claims, and financial penalties) when the contract's outcome does not align with the legal requirements that must be met.
Collaboration among legal experts, engineers, and stakeholders is essential to tackle the legal and regulatory aspects of smart contracts. Such collaborative effort can help ensure the integration of legal requirements into technical design and implementation, as well as help guarantee code correctness, compliance, and regulatory alignment during the deployment and execution of smart contracts. Approaches such as formal verification and others surveyed by Wang et al. [19] can help smart contracts become better aligned with existing jurisdictions.

VII. DISCUSSION
This section explicitly answers the four research questions identified in this mapping review, together with relevant threats to the validity of our work.

A. ANSWERS TO RESEARCH QUESTIONS
The review highlights a growing interest in using CPSCs to oversee contract execution and ensure contract compliance. Not all reviewed approaches deployed smart contracts to monitor legal contracts; instead, many have utilized smart contracts to monitor and control sensor data and events and react to violations. Here are the findings of each research question and some insights about the conducted mapping review: For RQ1 (What are the current platforms that support the implementation of CPSCs for event-based monitoring?): the findings of the literature review, which are reported in section IV, demonstrate that the development, deployment, and invocation of CPSCs involve a variety of platforms, development tools, and data carriers. Table 3 presents a summary of the CPSC literature with architectural characteristics themes. The centralized, decentralized, and hybrid platforms were proposed as different CPSC approaches for compliance monitoring. Few studies proposed and explored the hybrid and centralized architecture for CPSCs, with most studies using a decentralized implementation for distributed execution of smart contracts. The decentralized approach is favored because it offers the benefits of blockchain technology, such as transparency and immutability.
Also, the results of the review indicate that smart contract execution and monitoring can occur on the blockchain, while also some parts of the smart contracts may be executed offchain, and some monitoring procedures may remain off-chain as well. The prevalent method described in the literature for enforcing compliance is to conduct monitoring outside of smart contracts, where smart contracts can utilize feedback from external sources to respond to monitoring outcomes. In reality, monitoring using blockchain-based smart contracts can be challenging due to the high cost of execution and monitoring on the blockchain. Therefore, several approaches proposed for storing sensor data/events and conducting monitoring off-chain to reduce costs.
The literature also revealed that smart contracts are typically created manually and customized to fit the targeted programming language and platform, making their creation an exceedingly challenging task for developers in various CPS fields. Finally, the proposed layered architecture of CPSC, shown in Fig. 10, is based on a modular architecture that may consist of several distinct components, and it is the responsibility of the developers to remove, add, or modify them according to the requirements of the targeted field in CPSs.
For RQ2 (How do CPSCs produce and consume events from/to the outside world for monitoring?): the results from section IV show that smart contracts cannot access and monitor sensor data and events from the outside world directly. External components and technologies are needed to verify, consume, and produce these data and events for compliance monitoring. Tables 4 and 5, together with Figs. 9 and 10, summarize the needed components, technologies, and communication patterns for consuming and producing events. An oracle is used as a third-party agent to check the veracity of sensor data and events that cannot be accessed by the smart contract or cannot be reached by the physical world. Also, additional storage could be used as a conduit for consuming and producing sensor data and events, e.g., a cloud environment could store sensor data and events collected from an oracle. Sensor data and events are either made available to anyone to ensure transparency or are only accessible to certain parties in order to preserve privacy. Three methods are used to store sensor data and events, including storing them directly in the blockchain, in third-party storage (offchain), or dividing them between the blockchain and multiple third-party storage entities.
For RQ3 (What are current techniques for mitigating CPSC execution failures in event-based monitoring?): the results reported in section V show that the components and technologies needed for supporting CPSCs could come with multiple types of infrastructure failures. Fig. 11 summarizes failure types and corresponding mitigation approaches. Also, the existing literature focuses more on run-time smart contract execution failures than on infrastructure failures and solutions (e.g., limitations of IoT devices). This could be a significant barrier hindering the development of smart contracts in CPSs. Therefore, infrastructure failures require further research in order to better address challenges related to integrating smart contracts with CPSs in practice.
For RQ4 (What are the main technical challenges faced in the development of CPSCs for event-based monitoring?): the results presented in section VI reveal that the role of CPSCs in compliance monitoring brings multiple technical challenges. Multiple aspects need to be considered while making architectural decisions related to CPSCs. Important technical challenges relate to security, availability, robustness, privacy, and legal and regulatory aspects.

B. THREATS TO VALIDITY
As for any literature review, this mapping review is prone to several limitations and threats to validity, which are listed in Table 6 together with related mitigation strategies.
In addition, as this is a literature review, there was no experiment-based or empirical assessment of the various approaches discussed in the paper.

VIII. CONCLUSION AND FUTURE OPPORTUNITIES
This paper presented the findings of a mapping review on the use of CPSCs for compliance monitoring, with the aim to provide insights on existing architectures, patterns, infrastructure failure types, and technical challenges. To our best knowledge, this mapping review is the first literature review focused on smart contract development for event-based monitoring in cyber-physical systems.
The main conclusions of this mapping review are summarized below, together with corresponding suggestions for potential elements of solutions and future research opportunities: 1) Existing research on smart contract compliance monitoring in CPSs is limited to the blockchain as a dominant execution environment with back-end storage and a mediator for transferring sensor data and events because this architecture maintains secure, immutable, and redundant storage. In the future, research should be extended to cover other approaches to overcome the limitation of blockchains in terms of cost, speed, and power usage. For example, off-chain execution could be used as an alternative approach to blockchain for executing smart contracts [61], [69]. This strategy requires shifting data and/or smart contracts ''off'' the blockchain and to a different platform that performs better in terms of execution speed, storage, regulatory compliance, and so on. This approach can decrease blockchain costs and provide better scalability by improving transaction processing times and storage [61]. Off-chain execution, however, may jeopardize some of the benefits of security and transparency that come with using blockchain [61]. Another option to explore could involve Directed Acyclic Graph based Distributed Ledgers, which offer better scalability than blockchain at the expense of more limited security due to the absence of consensus algorithms [48]. 2) Regarding the lack of trusted data carriers, external data and events from the physical world are necessary for smart contracts execution and monitoring. The connection between the cyber and physical worlds is made possible by reliable data carriers (e.g., oracles) to verify the data generated by physical components and deliver them to smart contracts. However, the trustworthiness and security of data carriers are seen as major impediments to the use of smart contracts within CPSs. Therefore, a robust ecosystem of reliable data carriers is necessary to improve the implementation of CPSCs. Many potential solutions could be utilized to establish a robust ecosystem to ensure the accuracy of data and events that are roaming around several physical and cyber components in various CPSC applications, including but not limited to: • Data Provenance: Tracking the source of data, including its origin, usage, and history can help minimize data tampering. Blockchain provides an immutable data record where data origins can be traceable to ensure data accuracy and consistency [51].
• Data Protection: Taking necessary privacy and security measures to protect the shared ecosystem's data and events is also something to be considered. This involves applying measures such as preventing unauthorized access or other privacy and security practices described in section VI of this paper.
• Data Standardization: The use of standardized data formats would also facilitate the sharing of data and events while supporting interoperability amongst the smart contract and other systems [61]. 3) Few studies have focused on monitoring infrastructure failures; instead, most studies have focused on failures related to the execution of smart contracts. There is a need to extend the research on infrastructure failures of CPSs due to the increased adoption of IoT, cloud, and other technologies, which is crucial for the accurate and reliable monitoring and execution of smart contracts. As mentioned previously in section V, hardware failures can occur with actuators/sensors for a variety of reasons (e.g., attacks, damages, or degradation [9]), potentially resulting in major data loss. Potential solutions aiming to reduce the impact of hardware failures could involve the use of IoT/DLT integration that supports redundancy, e.g., distributing multiple actuators/sensors across various nodes such that if one fails, another can take over the task. Such solutions can help prevent single points of failure [9]. 4) For compliance monitoring, existing studies have often used an extra layer in the monitoring architecture between smart contracts and the external world, where usually the monitoring happens outside the smart contracts. Also, based on the monitoring decision, a suitable function within the SC will be called. There is however a need for a reference monitoring model of generated data and events to identify and deal with them efficiently. 5) The body of smart contract functions is often coded manually using languages such as Solidity, JavaScript, Go, and Java. There is no method for directly converting a real contract into an enforceable smart contract, which further increases the complexity of adopting smart contracts in other CPS areas. There has been some research on this matter, such as the use of domain-specific languages, template-based code generators, and verification. Template-based code generators provide templates to assist developers in creating smart contracts efficiently. These templates consist of predefined common smart contract constructs code, as proposed by Hamdaqa et al. [21]. Domain-specific languages can also represent a potential solution [20], [22], [70]. By using domain-specific languages, developers can use domain concepts, rules, and high-level coding abstractions related to contracts, which can simplify the process of creating smart contracts, hence reducing coding errors, development time, and overall complexity. Such languages can hence help address some of the challenges discussed in our review. Verification is another potential solution to address the complexity of coding smart contracts [19]. This usually involves the use of (formal) verification methods to ensure that a smart contract complies with its intended specification (including legal obligations) and can prevent vulnerabilities. These solutions have their own challenges in terms of additional time and domain expertise needed to exploit them properly [20], [21]. 6) Common CPSC challenges related to availability, robustness, privacy, and legal and regulatory aspects have not been investigated extensively yet, which again provides many opportunities for further research.