Sandi Gec, Vlado Stankovski, Dejan Lavbič and Petar Kochovski. 2023. A Recommender System for Robust Smart Contract Template Classification, Sensors, 23(2).

Abstract

IoT environments are becoming increasingly heterogeneous in terms of their distributions and included entities by collaboratively involving not only data centers known from Cloud computing but also the different types of third-party entities that can provide computing resources. To transparently provide such resources and facilitate trust between the involved entities, it is necessary to develop and implement smart contracts. However, when developing smart contracts, developers face many challenges and concerns, such as security, contracts’ correctness, a lack of documentation and/or design patterns, and others. To address this problem, we propose a new recommender system to facilitate the development and implementation of low-cost EVM-enabled smart contracts. The recommender system’s algorithm provides the smart contract developer with smart contract templates that match their requirements and that are relevant to the typology of the fog architecture. It mainly relies on OpenZeppelin, a modular, reusable, and secure smart contract library that we use when classifying the smart contracts. The evaluation results indicate that by using our solution, the smart contracts’ development times are overall reduced. Moreover, such smart contracts are sustainable for fog-computing IoT environments and applications in low-cost EVM-based ledgers. The recommender system has been successfully implemented in the ONTOCHAIN ecosystem, thus presenting its applicability.

Keywords

smart contract, classification, cluster, recommender system, inheritance

1 Introduction

The Internet of Things (IoT) is a modern technology that allows various devices to exchange information over the Internet. These devices aid their users in facilitating their everyday routines and automate them via digitalization. Typical IoT environments comprise many components, such as sensors, gateways, computing, and storage nodes in the Edge-to-Cloud continuum. Despite the enormous benefits the IoT has introduced to domains, such as smart and safe construction, Industry 4.0, smart cities, and IoT solutions are generally based on centralized architectures. Essentially, a single point of failure in such scenarios, where the server goes down, can significantly reduce the Quality of Service (QoS) and the Quality of Experience (QoE), decrease trust in the system, and place its IoT data in danger. However, these problems in IoT can be overcome by implementing blockchain and its core technologies (i.e., immutable ledgers, smart contracts, and smart oracles) (Atlam et al. 2020). Thus, the usage of smart contracts in IoT environments not only benefits from the implicit blockchain benefits but enables the implementation of comprehensive functionalities that may significantly increase the distribution and overall trust of the IoT environment.

A smart contract is a digital variation of a traditional contract stored as programs on a blockchain that is ordinary used to automate the execution of an agreement without any intermediary’s involvement. The base purpose of each smart contract is to automate workflows by triggering specific actions when conditions are met. Our work relies on the first publicly released smart contract, enabling ledger Ethereum with built-in fully fledged Turing-complete programming language Solidity. Nevertheless, the operational cost and speed limitations in block generation times using native Ethereum ledgers cannot always satisfy the requirements of many use case domains, including IoT. For this reason, new solutions using the Ethereum ledger core computational engine called the Ethereum Virtual Machine (EVM) launched their own ledger. The primary purpose of these ledgers is to increase sustainability and overall performances. Since general blockchain reseach studies strive to improve general requirements such as the optimization of query processing (Wang et al. 2022; Wu et al. 2022) and many others, the smart contract is more likely to investigate how to cover new use cases from the cloud to the edge using the development of more performant blockchain ledgers~. Moreover, on-chain operations started interacting with off-chain data within the Smart Oracle mechanism available in smart contracts.

The development process of smart contracts in Solidity language is a very challenging task. For example, the documentation is limited, the community of developers is limited, and the language does not follow standardized design patterns, etc. Since the principles of smart contracts do not allow updating or deleting a smart contract once deployed, the functionalities have to be extremely well written and tested to ensure security, as outlined by Zou et al. (2021).

The high-level goal of our work is to decentralize fog-based IoT architectures with the integration of smart contracts on the fog layer using low-cost EVM-enabling ledgers. To reach the goal, we propose a recommender system that provides the developer with robust, reusable smart contract templates based on the fog architecture characteristics and requirements. Our approach can be summarized as follows. First, we obtain production-ready and secure smart contract templates (e.g., OpenZeppelin1 and ChainLink2) and classify them according to the interactions that occur among them and the actual purpose of the contracts. Afterward, we define our fog architecture in a standardized TOSCA format (Brogi, Soldani, and Wang 2014). Then, we use our TOSCA-defined fog architecture and requirements as the input data of our recommender system. As a result, we obtained a list of the relevant smart contract templates that can be used in our system directly or in an extended manner to fulfill all use-case-specific requirements and workflow. By providing such templates, we implicitly promote secure smart contracts by design and strive to follow good practices provided as ready-to-use functions or interface function standards. Hence, the development time of the developers is reduced. By upgrading fog architecture with smart contracts, it is possible, for example, to provide a pricing policy among end users that want to provide the hardware and/or software resources within the fog environment using cryptocurrencies or tokens. A main benefit for the system is either a reduction in the operational cost and/or the increase in the system’s revenue. To summarize, we provide the following contributions in the paper:

  • We propose a classification of smart contracts built upon the characteristics of the contracts and the inheritance relationship among them.
  • We develop a recommender system algorithm for smart contract template selection in fog architectures.
  • We introduce a novel architecture for recommender system that proposes robust smart contract templates based on the fog architecture and system requirements input data.

The remainder of the paper is split into seven sections. Section 2 places our work within the context of other related works. Section 3 describes the baseline scenario. Section 4 analyzes reusable smart contract templates by using classification and clustering methods to propose fog-oriented classification. Section 5 proposes the recommender system of the classified smart contract templates for fog architectures. Section 6 presents an experimental evaluation of the proposed recommender system, and Section 7 draws the conclusion.

3 Baseline scenario

Typical IoT applications are composed of many different components such as sensors, gateways, computing, and storage nodes that are often not owned by the application developer but implemented as pay-per-use services by third-party resource providers. Due to the immense diversity of IoT environments, they often differ because of their specific requirements. Moreover, applying blockchain as a technology in such complex environments can cause lengthy development, reduce scalability, and increase complexity due to incompatible standards.

The baseline scenario (see Figure 3.1) of our solution is motivated by the above-elaborated problems and envisions the implementation and utilization of a novel blockchain recommender system that will perform the following:

  1. compose smart contract templates that are based on the application’s specification, following good practices and design patterns;
  2. facilitate the blockchain implementation by providing the IoT developers with reliable, standardized smart contracts for their use cases;
  3. accelerate the overall development and implementation of smart contracts in IoT environments.
Outline of the baseline scenario.

Figure 3.1: Outline of the baseline scenario.

Moreover, it will enable peer-to-peer (P2P) transactions between the application’s developers and the resource providers. In other words, the scenario currently targets two essential groups of potential users: the IoT application developers and the resource providers. The complete workflow is composed of five consecutive steps:

  1. The application developer defines IoT’s available application quality requirements (e.g., data access, accesibility, scalability, etc.) and baseline cloud–fog specifications for application deployment using a TOSCA standard.
  2. The Recommender System receives the requirements and specifications as input and assembles a set of smart contract templates, which will be further selected by the application developer and further implemented in a comprehensive fully functional dedicated smart contracts.
  3. The Application Developer is offered the opportunity to approve or modify the smart contracts. Once the smart contracts are approved, they are deployed on the blockchain.
  4. When the smart contracts are deployed on the blockchain, different entities in the system (e.g., resource providers) can interact with them according to the democratic voting that takes places amoung the system’s stakeholders and resource providers. For instance, by interacting with the smart contract, the resource providers enable access to their resources (i.e., computing, storage resources, and IoT data) for third parties and obtain direct incentives from that interaction.
  5. When the interaction with the smart contracts results in new records on the blockchain, the application’s developer (i.e., the IoT application) is allowed to interact with the providers’ resources based on the policy agreed in the previous step.

4 High-level classification of reusable smart contracts

This section presents a classification of reusable smart contracts based on hierarchical analysis. First, we offer the main domains in the ONTOCHAIN environment. Then, we select the most currently advanced library for reusable smart contracts and describe them by their base properties and predefined modules. By the topology of smart contracts and inheritance among the smart contracts and in contrast to ONTOCHAIN domains, we propose a classification of smart contracts. Since tokenomics represents one of the most important categories, we present the token standards and summarize the fundamental properties.

4.1 Pillar domains in the ONTOCHAIN ecosystem

The next-generation ONTOCHAIN framework is a modular blockchain framework that leads to a more human-centric Internet that supports the values of openness, decentralisation, inclusiveness, and the protection of privacy (Papaioannou et al. 2021). It delivers various real-world solutions, such as trustworthy web and social media, trustworthy crowdsensing and reputation management, distribution logistics, data management, and similar solutions via the use of multiple ledger and semantic technologies. Its main goal is to further expand as an ecosystem that will address and complement different use cases using the ONTOCHAIN protocols and its different blockchain and semantic components.

Figure 4.1 depicts the high-level multi-layer architecture of the ONTOCHAIN framework. The blockchain layer provides a distributed execution environment that enables access to multiple distributed ledger networks that the ecosystem stakeholders can utilise. The ontologies layer comprises novel ontologies that can be managed in a trusted and secure manner. The application and core protocols and services enable seamless interaction between the framework’s layers. Namely, these interoperability protocols offer identity management, reputation management, data provenance, market mechanisms, and other functionalities that the applications of the ecosystem can exploit.

ONTOCHAIN high-level architecture.

Figure 4.1: ONTOCHAIN high-level architecture.

Based on meticulous state-of-the-art analyses (Casino, Dasaklis, and Patsakis 2019; CBInsight. 2021), the ONTOCHAIN framework identified 15 domains that can deliver a plethora of core use-case applications that can complement the ecosystem and exploit the framework’s functionalities. Namely, the following application domains were identified: agrifood, art, construction industry, education and science, energy management, fashion and luxury, financing, healthcare, Industry 4.0, information fact-checking, insurance, logistics mobility, public administration, and tourism. Given the uniqueness and variety of different types of possible applications, their decentralisation and development of smart contracts can be complex and lengthy. Motivated by this, the following sections will introduce a categorization of smart contracts and a recommender system for smart contracts that aims to facilitate smart contract development and application decentralization.

4.2 Base categorization of smart contracts

Initially, smart contracts were represented in a low-level, assembly-like sequence of operands that demanded proper low-level programming knowledge and experience from developers. In March of 2018, the first version of Solidity-based, JavaScript-like programming language, smart contracts, was released and thus encouraged a more comprehensive range of developers to contribute to the Ethereum ecosystem. The development methodology did not fully follow standard processes due to the specifics in the life-cycle of Ethereum smart contracts (Sillaber and Waltl 2017). For example, it is impossible to update an instance of a smart contract by only redeploying it due to the tamper-proof implicit properties of the Ethereum ledger. Therefore, coding anomalies in the smart contracts, such as bugs, lack of validation, incompatible command sequence, and other issues, led to security vulnerabilities with usually severe consequences in communities using vulnerable smart contracts (Kushwaha et al. 2022b). This iterative learning process delivered coding guidance provided by various analysis tools (Kushwaha et al. 2022a) and design patterns in the form of smart contract templates. The latter covers different functionalities, standards (e.g., tokens), and good practices that may facilitate the development process of solidity-based smart contracts. Most companies providing production-ready smart contracts rely on security-audited smart contract templates by OpenZeppelin.

The library of modular, reusable, and secure smart contracts for Ethereum and other EVM-enabling ledgers consists, in the time of writing (library version 4.8.0), of 174 smart contracts. The actual number of operational ones is 155, defined by the base smart contract document definitions such as contract, abstract contract, interface, or library. By default, the smart contracts are organized into 11 main modules that may be summarized as follows:

  • The Access module supports basic, role-based, cross-chain, and other access control mechanism or policies: Ordinary, these policies are applied in the smart contract’s individual functions.
  • The Cross Chain module provides a component to improve cross-chain awareness of smart contracts via the Arbitrary Message Bridge (AMB) mechanism.
  • The Finance module roughly includes functionalities for financial systems on both types of assets, ETH or other EVM coins and tokens. The main two contracts provide splitting payments among multiple entities and the vesting of assets for a given beneficiary.
  • The Governance module consists of comprehensive on-chain governance smart contracts for use cases such as voting, governance control, and other time-lock-related functionalities.
  • The Interfaces module summarized the interfaces that may be implemented in smart contracts and thus provided dedicated functionality workflows.
  • The Meta-transactions module includes minimal extended ERC-2771 contract instance and a context variant with the ERC-2771 support to support gasless transactions.
  • The Proxy module defining a low-level set of contracts defining different proxy patterns: (i) not able to upgrade, immutable by default, and (ii) scalable using an upgradable proxy pattern.
  • The Security module aims to cover the security domain—more concretely, the good practices enhancing security.
  • The Tokens module includes the definition of fundamental ERC-based token standards that are presented and compared among them in the following subsection.
  • The Utilities module consists of miscellaneous contracts and libraries containing utility functions that facilitate the data management of new data types, security, and the safe use of low-level primitives.
  • The Vendor module includes smart contracts that enable work with the most common EVM-compliant chains (e.g., Arbitrum, Polygon, Optimism, etc.).

The main categorization based on the described modules above consists of smart contracts proposed by the library authors consisting of different types of smart contracts and smart contract quantitative coverage, as depicted in Figure 4.2. Our classification is derived from the main categories relying on inheritance levels and interconnections from the perspective of available functionalities, as presented in the following subsections.

OpenZeppelin main smart contract modules in relation to the contract types.

Figure 4.2: OpenZeppelin main smart contract modules in relation to the contract types.

4.3 Tokenomics

Tokenomics play a crucial part in the design of smart contract functionalities due to the possibility of providing advanced functionalities enabled by the token exchange and/or interaction throughout smart contracts. EVM-enabling ledger tokens, by design, run on a Layer-2 protocol that relies on Layer-1 for security and consensus. For example, all operations performed with tokens are fueled in the transactions by native cryptocurrencies, such as ETH in the Ethereum ledger. In the smart contract implementation of token functionalities, it is vital to understand the token standards, their methodology, capabilities, and limitations. Currently, there are five token standards officially approved by the Ethereum developer community in addition to the attempts that were not approved or finalized, such as ERC-223 and ERC-1337. The main comparison of the official ERC standards is summarized in Table 4.1.

The standards are mainly divided by fungible properties along with other specific properties. In our work, we will consider token standards that contrast with common use cases that may be applied to fog architectures.

4.4 Hierarchical analysis of smart contracts

The design of smart contracts follows standard object-oriented programming features, such as an extension of the functionalities of a program to encourage the development of individual ready-to-use modules in a comprehensive smart contract. For example, developers strive to more systematically separate codes, reduce the dependencies, import directives, increase the re-usability of existing programming code, and even enforce the proposed workflow (e.g., voting smart contract). In the initial OpenZeppelin analysis, 65 individual smart contracts and 90 smart contracts were involved in the inheritance. The inheritance is represented either as extended in a smart contract or defines the module’s fundamental behaviour, functions, or primitives, identifying four main clusters sorted by the ascending number of contracts in the interaction:

  1. The first cluster consists of two smart contracts designed for EVM-based dedicated chain Arbitrum. The hierarchy dictates interface contract (IInbox) extending standard Arbitrum events through the base interface (IDelayedMessageProvider) as shown in Figure 4.3 in the bottom left.
  2. The second cluster organizes the ERC-1820 standard defined in the contract ERC1820Implementer, extending the interface IERC1820Implementer and roughly defining a universal registry smart contract where the address policy is defined (e.g., an address can register which interface it supports and which smart contract is responsible for its implementation), as depicted in Figure 4.3 in the bottom upper left.
  3. The third cluster of seven contracts describes the proxy policy for different purposes (see Figure 4.3: bottom right).
  4. The fourth biggest cluster of ninety-nine contracts involves ERC token standards in conjunction with the modules such as governance, access, and others, as shown in Figure 4.3. The most dominant module in inheritance is token, followed by governance and utils (utilities). Deployable contracts are realized by inherited abstract contracts containing minimal business logic and interfaces that enforce function definitions, including global variables and events.
Inheritance of OpenZeppelin components containing contract types: (i) contracts, (ii) interfaces, and (iii) abstract contracts. Libraries have not been visualized. The most dominant classifiers are tokens, governance, and utilities.

Figure 4.3: Inheritance of OpenZeppelin components containing contract types: (i) contracts, (ii) interfaces, and (iii) abstract contracts. Libraries have not been visualized. The most dominant classifiers are tokens, governance, and utilities.

We classified the most relevant smart contract functionalities from the base OpenZeppelin categorization and clustering derived from the inheritance among smart contracts. In addition, the ONTOCHAIN environment was considered in order to converge the categories into requirement-like descriptions on two levels (see Figure 4.4: (i) the base classifier and (ii) the detailed classifiers suitable in the process of the recommender system where the system requirements are more concrete.

Identified classifiers represented into two levels: (i) main and (ii) detailed classifiers.

Figure 4.4: Identified classifiers represented into two levels: (i) main and (ii) detailed classifiers.

5 Recommender system of reusable smart contracts for Fog architectures

In this section, we describe the recommender system’s methodology. First, we consider the fog environment’s data representation to represent the architecture’s base properties, such as components, end users, and relationships among them. Then, we propose a taxonomy of the input data described as fog architectures and related requirements defined by the stakeholders of the environment. At the end of the section, we propose the architecture of our recommender system.

5.1 Data descriptors

Fog architectures consist of many types of components that are represented in different formats and even different notations. In the cloud computing domain, this problem was addressed in 2014 with the establishment of a standard proposed by a nonprofit consortium OASIS8 named Topology and Orchestration Specification for Cloud Applications (TOSCA). The standard specifications defined the cloud architectures with components in YAML format. Furthermore, the research community also addressed other emerging domains, such as fog and edge, where Tsagkaropoulos et al. (2021) proposed extensions to the existing standard. In our work, the fog architectures are packed in TOSCA format to describe the interactions among the components and the involved entities (e.g., properties, capabilities, and relationship), as shown in Listing 1.

Listing 1: Example of a component with basic properties in TOSCA. 
tosca_definitions_version: alien_dsl_2_0_0
topology_template:
node_templates:
Componnet_A:
type: org.alien4cloud.fog.nodes.CustomFogNode
properties:
duration: 55
variation: 20
log_length: 2000
requirements:
- endpoint:
node: Component_B
capability: org.myFog.capabilities.FogComponentEndpoint
relationship: org.myFog.relationships.FogC_ConnectToComponent

5.2 Architecture of the recommender system

Fog architecture is becoming popular due to its possibility for offloading computational tasks and thus the components on the fog nodes that can be a part of cloud-dedicated data centres and infrastructure, provided by the end users (Mann 2021). The process of offloading includes end user provisioning services or resources in the fog environment and ordinarily demanded manual operations (e.g., agreement about the price and policy, registering a new provisioning component, etc.) that are often performed via centralized components. These manual operations can be defined in a dedicated smart contract following the requirements of the system and stakeholders. Developing such complex smart contracts is very difficult and requires an experienced smart contract developer. Therefore, the development can be facilitated since the recommender system provides, as a result, smart contract templates that are intended to be extended to follow the use case of the system jointly with smart contracts.

The architectural design of the recommender system, depicted in Figure 5.1, relies on two main inputs:

  1. fog architecture represented in standardized format TOSCA v. 2.0 and
  2. requirements provided as system requirements by the fog architect.
High-level architecture representing the pillar recommender system components with the main workflow.

Figure 5.1: High-level architecture representing the pillar recommender system components with the main workflow.

The recommender system engine analyzes the input data using the three following main steps:

  • The architecture reasoning step analyzes the topology of the fog architecture among the individual sets of components by focusing on the attribute, which defines the characteristics of the specific component, and the that provides the type of the connection (e.g., protocol, allowance such as command-line interface (CLI), etc.). Additional features are extracted from the fog environment’s high-level properties, such as the types and number of components where the component’s representation and the algorithm’s details are presented in the following section.
  • The requirement analysis step focuses on system requirements that can be either general or detailed. General requirements such as token support provide a wider range of smart contract template candidates, which include all types of tokens (fungible and non-fungible). The detailed requirements, on the other side, significantly narrow the smart contract template candidates.
  • The comprehensive check step unifies the results from the first two steps, particularly the cases of conflicting smart contract templates (e.g., ER-C20 and ERC-721) that cannot be defined in the same smart contract together. Therefore, the first and second steps are repeated, including scoring on each smart contract template candidate, where the one with a higher score is included in the component’s result list.

The algorithm of the recommender system engine is presented in the following section. Finally, the developer obtains a list of smart contract templates by matching the fog architecture’s typology and system requirements. The developer obtains ready-to-use smart contracts, abstract smart contracts that need to be extended, interfaces, and libraries implicitly via other contracts.

6 Experimental evaluation

6.1 Cost estimation of smart contracts

The long-term sustainability of smart contracts integrated with the fog environments is a significant property in developing dedicated smart contracts based on robust templates. The aim of this experimental study is cost estimation expressed with Ethereum network fees Gas by definition, which measure the amount of computational effort required to perform specific operations on Ethereum or other EVM-compliant ledgers. In our work, we will use Ethereum’s Gas represented with the unit Gwei or in nanoeth, which is represented as \(1\ ETH = 10^9\ Gwei\).

Cost estimation of the deployment process and available functions in deployable smart contracts.

Figure 6.1: Cost estimation of the deployment process and available functions in deployable smart contracts.

Our cost estimation methodology follows the following steps:

  1. deployment of smart contract in a local testnet environment,
  2. the execution of all available smart contract functions with dedicated gas estimation function or empirically execute complex functions (C. Li et al. 2020), and a
  3. summary of the operational cost obtained in the first and second steps.

We will use default the Gas parameters and TruffleSuite9 framework to simulate the EVM environment. The experiments were performed on deployable smart contracts of type contract where the simulation’s results are shown in Figure 6.1. The aim of the experiment is to prove the sustainability of smart contracts within the IoT fog environment.

6.2 Fog recommender system algorithm

The recommender system’s algorithmic basis on fog architectures that are used as baseline inputs obtained by the largest Cloud providers: Azure10 provides categorized cloud architecture references in our IoT case and Google Cloud11 in the cloud architecture center offers reference to IoT architectures with guidance, and Amazon AWS12 provides defined cloud-to-edge architecture applications. We composed our fog architectures from the cloud providers and available architectures that will be run on our algorithm 1 with different requirements. The algorithm is written in JavaScript programming language as REST API services where the time complexity of the algorithm is quadratic, \(O(n^2)\). In the worst-case scenario, the algorithm based on two nested loops has to perform \(n\) amount of operations per iteration of the outer loop making it a total of \(n \cdot n\) operations. Since the order of magnitude of up to 100 components per IoT fog architecture, this does not represent an issue. The base data (available components, classifications, and smart contract templates) are stored in the MongoDB database.

Algorithm 1: Recommender system algorihm represented in pseudocode

\[\begin{align*} & \textbf{procedure}\ \text{RECOMMENDER SYSTEM} \\ & \quad \textit{templates} \gets \text{dictionary of smart contract templates} \\ & \quad \textit{fogTOSCA} \gets \text{architecture represented in TOSCA format} \\ & \quad \textit{requirements} \gets \text{list of requirements} \\ & \quad \textit{resultList} \gets \text{result list of smart contract templates} \\ & \quad \textit{finished} \gets \text{false} \\ & \quad \textit{scoring} \gets \text{false} \\ & \quad \textbf{while}\ finished=false\ ||\ scoring=true\ \textbf{do} \quad //\ \text{while the results are not conflicting} \\ & \qquad \textbf{if}\ scoring == true\ \textbf{then} \\ & \qquad \quad //\ \text{loop through the}\ fogTOSCA\ \text{components and vote (relationship, capability, type)} \\ & \qquad \quad \textbf{if}\ \text{scoring results not equal}\ \textbf{then} \\ & \qquad \qquad \textbf{return}\ \text{resultList} \\ & \qquad \quad \textbf{end if} \\ & \qquad \quad \textbf{if}\ \text{scoring results are equal}\ \textbf{then} \\ & \qquad \qquad \textbf{return}\ \text{resultList and label conflicting templates} \\ & \qquad \quad \textbf{end if} \\ & \qquad \textbf{end if} \\ & \qquad \textbf{while}\ \text{iterate through}\ templates\ \textbf{do} \quad //\ \text{filter each contract based on the requirements} \\ & \qquad \quad \text{// if conflicting contract found set}\ scoring = \text{true} \\ & \qquad \textbf{end while} \\ & \qquad //\ \text{for each component, add weight scores about relationship, capability and component type to templates} \\ & \qquad \textbf{while}\ \text{iterate through}\ fogTOSCA\ \textbf{do} \\ & \qquad \quad \text{// if conflicts still occur set}\ scoring = \text{true} \\ & \qquad \textbf{end while} \\ & \quad \textbf{end while} \\ & \textbf{end procedure} \end{align*}\]

Moreover, to compose the fog architectures used in our experimental study, we defined each architecture in TOSCA v. 2.0 format by using a Web tool Alien4Cloud13, which provides a series of more than 90 representations of the standard definitions of cloud-to-edge components such as hypervisor, deployment, network, server, storage, management, service, gateway, and others. As outlined in the previous section for the main steps of the architecture, the algorithm extracts the key characteristics of the architecture, such as relationship, capability, and type. The algorithm mainly relies on the component’s type and relationship related to the three capability properties: feature, host, and scalable. These features are aligned with identified classifiers. Since there are no research baseline architectures to be used, we evaluated our recommender system’s algorithm with simulations.

We performed simulations of our recommender algorithm on three base architectures (Azure IoT reference architecture14, Intelligent Products Essentials reference architecture15 and Smart Metering for Water Utilities) using different requirements, as shown in Table 6.1. We did not include inherited contracts in the smart contract’s template results because they are implicitly included.

6.3 Smart contract development time evaluation

To evaluate the performance of the recommender system in the context of the smart contracts’ development time, in December 2022, we prepared a study with 50 participants with different levels of blockchain expertise. We targeted participants to whom we had direct access, such as undergraduate university students, researchers, and collaborators in the ONTOCHAIN project. Each participant had to develop four smart contracts, and each participant had to develop the smart contracts once without the help of the recommender system and also by using the recommender system. To maintain the moment of surprise, the order in which they received the assignments was random.

At the time of the result’s analysis, we excluded the participants who did not submit all four smart contracts, did not pass the unit tests for the developed smart contracts, or took more than two hours for development. As a result, we finalized the evaluation with the 36 participants passing the tasks, 27.8 % female and 72.2 % male, with ages ranging from 20 to 55 years old. In general, the participants were 36.1 % undergraduate students and 63.9 % non-students.

The results have shown that for the smart contracts that were developed without the help of the recommender system, the participants spent an average of 50 minutes on development. In comparison, for the smart contracts that were developed using the recommender system, they developed smart contracts with an average of 12 minutes, which reduced the development time by 76%.

7 Discussion and conclusion

In our work, we proposed a recommender system that will simplify and accelerate the development of decentralised IoT applications. The recommender system outputs smart contract templates based on the system’s requirements that the IoT developer defines during the development phase. In our experimental results, we focused on two key properties: sustainability and development time reduction.

Smart contracts initially interact with the EVM-based ledger first in the development process, which is the most costly operation. This is expected since the entire Dapp as a programming script has to be deployed on the ledger. Once deployed, the involved stakeholders of the system trigger functions that update the state of the variables, execute transactions, or other purposes. Functions are compared to the deployment of the contract, and they are significantly cheaper. Using a low-cost EVM-enabling ledger such as Polygon makes it possible to perform most functions for less than USD \(0.10\) per transaction. Thus, enabling smart contracts in fog environments is sustainable.

The quantitative results of our recommender system were addressed in the analysis of the results provided by the algorithm. The workflow of the algorithm considers the topology of the fog architecture with specified requirements. Based on our simulation of three heterogeneous IoT reference architectures, the system provided a set of relevant smart contract templates. These templates can be merged, extended, or modified to comply with the environment. The development process is simplified, and the overall smart contract preparation time is reduced.

Although this work addresses important challenges for building decentralised IoT applications by using smart contract templates proposed by the newly developed smart contract recommender system, there are still many challenges to be tackled in future. For instance, the recommendation results may be significantly improved if a reputation system is integrated into the recommender system. As such, the recommender system could also categorize the smart contracts and choose standards based on their reputation that can be based on various requirements (e.g., security, data safety, scalability, etc.). Another important challenge in decentralising IoT applications would be the management of decisions and service-level agreements in larger IoT systems, where various service providers play important roles in the provision of sensor data and in computing and processing resources. By expanding the recommender system functionalities, to update the smart contract templates based on democratic methods for reaching a consensus, the recommender system will evolve into a decentralised autonomous organization. This will allow seamless smart contract management operations in complex IoT scenarios, where all relevant stakeholders would be allowed to participate in smart contract management without having prior expertise in smart contract development. These challenges will be further researched within the scope of the ONTOCHAIN project, and the results will be presented in our future works.

Acknowledgments

The research and development reported in this paper received funding from the European Union’s Horizon 2020 Research and Innovation Programme under grant agreement no. 957338 (ONTOCHAIN: Trusted, traceable, and transparent ontological knowledge on the blockchain) and from the Research Agency of the Republic of Slovenia under the research programme P2-0426 Digital Transformation for Smart Public Governance 1/1/22-12/31/27.

References

Ahmadjee, Sabreen, Carlos Mera-Gómez, Rami Bahsoon, and Rick Kazman. 2022. “A Study on Blockchain Architecture Design Decisions and Their Security Attacks and Threats.” ACM Trans. Softw. Eng. Methodol. 31 (2). https://doi.org/10.1145/3502740.
Atlam, Hany F, Muhammad Ajmal Azad, Ahmed G Alzahrani, and Gary Wills. 2020. “A Review of Blockchain in Internet of Things and AI.” Big Data and Cognitive Computing 4 (4): 28.
Brogi, Antonio, Jacopo Soldani, and PengWei Wang. 2014. “TOSCA in a Nutshell: Promises and Perspectives.” In Service-Oriented and Cloud Computing, edited by Massimo Villari, Wolf Zimmermann, and Kung-Kiu Lau, 171–86. Berlin, Heidelberg: Springer Berlin Heidelberg.
Casino, Fran, Thomas K Dasaklis, and Constantinos Patsakis. 2019. “A Systematic Literature Review of Blockchain-Based Applications: Current Status, Classification and Open Issues.” Telematics and Informatics 36: 55–81.
CBInsight. 2021. “Banking Is Only the Beginning: 65 Big Industries Blockchain Could Transform.”
Chen, Xiangping, Peiyong Liao, Yixin Zhang, Yuan Huang, and Zibin Zheng. 2021. “Understanding Code Reuse in Smart Contracts.” In 2021 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), 470–79. https://doi.org/10.1109/SANER50967.2021.00050.
Di Angelo, Monika, and Gernot Salzer. 2020. “Assessing the Similarity of Smart Contracts by Clustering Their Interfaces.” In. https://doi.org/10.1109/TrustCom50675.2020.00261.
Freni, Pierluigi, Enrico Ferro, and Roberto Moncada. 2022. “Tokenomics and Blockchain Tokens: A Design-Oriented Morphological Framework.” Blockchain: Research and Applications 3 (1): 100069. https://doi.org/https://doi.org/10.1016/j.bcra.2022.100069.
Guo, Hao, Wanxin Li, Mark Nejad, and Chien-Chung Shen. 2022. “A Hybrid Blockchain-Edge Architecture for Electronic Health Record Management with Attribute-Based Cryptographic Mechanisms.” IEEE Transactions on Network and Service Management, 1–1. https://doi.org/10.1109/TNSM.2022.3186006.
Himeur, Yassine, Aya Sayed, Abdullah Alsalemi, Faycal Bensaali, Abbes Amira, Iraklis Varlamis, Magdalini Eirinaki, Christos Sardianos, and George Dimitrakopoulos. 2022. “Blockchain-Based Recommender Systems: Applications, Challenges and Future Opportunities.” Computer Science Review 43: 100439. https://doi.org/https://doi.org/10.1016/j.cosrev.2021.100439.
Isinkaye, F. O., Y. O. Folajimi, and B. A. Ojokoh. 2015. “Recommendation Systems: Principles, Methods and Evaluation.” Egyptian Informatics Journal 16 (3): 261–73. https://doi.org/https://doi.org/10.1016/j.eij.2015.06.005.
Kumar, Ajitesh, Akhilesh Kumar Singh, Ijaz Ahmad, Pradeep Kumar Singh, Anushree, Pawan Kumar Verma, Khalid A. Alissa, Mohit Bajaj, Ateeq Ur Rehman, and Elsayed Tag-Eldin. 2022. “A Novel Decentralized Blockchain Architecture for the Preservation of Privacy and Data Security Against Cyberattacks in Healthcare.” Sensors 22 (15). https://doi.org/10.3390/s22155921.
Kushwaha, Satpal Singh, Sandeep Joshi, Dilbag Singh, Manjit Kaur, and Heung-No Lee. 2022a. “Ethereum Smart Contract Analysis Tools: A Systematic Review.” IEEE Access 10: 57037–62. https://doi.org/10.1109/ACCESS.2022.3169902.
———. 2022b. “Systematic Review of Security Vulnerabilities in Ethereum Blockchain Smart Contract.” IEEE Access 10: 6605–21. https://doi.org/10.1109/ACCESS.2021.3140091.
Lakhan, Abdullah, Mazin Abed Mohammed, Ahmed N. Rashid, Seifedine Kadry, Thammarat Panityakul, Karrar Hameed Abdulkareem, and Orawit Thinnukool. 2021. “Smart-Contract Aware Ethereum and Client-Fog-Cloud Healthcare System.” Sensors 21 (12). https://doi.org/10.3390/s21124093.
Li, Chunmiao, Shijie Nie, Yang Cao, Yijun Yu, and Zhenjiang Hu. 2020. “Dynamic Gas Estimation of Loops Using Machine Learning.” In Blockchain and Trustworthy Systems, edited by Zibin Zheng, Hong-Ning Dai, Xiaodong Fu, and Benhui Chen, 428–41. Singapore: Springer Singapore.
Li, Jiwei, Zhe Peng, and Bin Xiao. 2016. “Smartphone-Assisted Smooth Live Video Broadcast on Wearable Cameras.” In 2016 IEEE/ACM 24th International Symposium on Quality of Service (IWQoS), 1–6. https://doi.org/10.1109/IWQoS.2016.7590439.
Lisi, Andrea, Andrea De Salve, Paolo Mori, and Laura Ricci. 2019. “A Smart Contract Based Recommender System.” In Economics of Grids, Clouds, Systems, and Services, edited by Karim Djemame, Jörn Altmann, José Ángel Bañares, Orna Agmon Ben-Yehuda, and Maurizio Naldi, 29–42. Cham: Springer International Publishing.
Mann, Zoltán Ádám. 2021. “Notions of Architecture in Fog Computing.” Computing 103 (1): 51–73. https://doi.org/10.1007/s00607-020-00848-z.
Papaioannou, Thanasis G, Vlado Stankovski, Petar Kochovski, Anthony Simonet-Boulogne, Caroline Barelle, Alberto Ciaramella, Marco Ciaramella, and George D Stamoulis. 2021. “A New Blockchain Ecosystem for Trusted, Traceable and Transparent Ontological Knowledge Management.” In International Conference on the Economics of Grids, Clouds, Systems, and Services, 93–105. Springer.
Sillaber, Christian, and Bernhard Waltl. 2017. “Life Cycle of Smart Contracts in Blockchain Ecosystems.” Datenschutz Und Datensicherheit - DuD 41 (8): 497–500. https://doi.org/10.1007/s11623-017-0819-7.
Tsagkaropoulos, Andreas, Yiannis Verginadis, Maxime Compastié, Dimitris Apostolou, and Gregoris Mentzas. 2021. “Extending TOSCA for Edge and Fog Deployment Support.” Electronics 10 (March): 737. https://doi.org/10.3390/electronics10060737.
Wang, Haixin, Cheng Xu, Ce Zhang, Jianliang Xu, Zhe Peng, and Jian Pei. 2022. “vChain+: Optimizing Verifiable Blockchain Boolean Range Queries.” In 2022 IEEE 38th International Conference on Data Engineering (ICDE), 1927–40. https://doi.org/10.1109/ICDE53745.2022.00190.
Wu, Haotian, Zhe Peng, Songtao Guo, Yuanyuan Yang, and Bin Xiao. 2022. “VQL: Efficient and Verifiable Cloud Query Services for Blockchain Systems.” IEEE Transactions on Parallel and Distributed Systems 33 (6): 1393–1406. https://doi.org/10.1109/TPDS.2021.3113873.
Zhang, Miranda, Rajiv Ranjan, Surya Nepal, Michael Menzel, and Armin Haller. 2012. “A Declarative Recommender System for Cloud Infrastructure Services Selection.” In Economics of Grids, Clouds, Systems, and Services, edited by Kurt Vanmechelen, Jörn Altmann, and Omer F. Rana, 102–13. Berlin, Heidelberg: Springer Berlin Heidelberg.
Zou, Weiqin, David Lo, Pavneet Singh Kochhar, Xuan-Bach Dinh Le, Xin Xia, Yang Feng, Zhenyu Chen, and Baowen Xu. 2021. “Smart Contract Development: Challenges and Opportunities.” IEEE Transactions on Software Engineering 47 (10): 2084–2106. https://doi.org/10.1109/TSE.2019.2942301.

  1. https://www.openzeppelin.com/↩︎

  2. https://chain.link/↩︎

  3. https://ethereum.org/↩︎

  4. https://www.bnbchain.org/↩︎

  5. https://polygon.technology/↩︎

  6. https://www.optimism.io/↩︎

  7. https://www.iota.org/↩︎

  8. https://www.oasis-open.org/↩︎

  9. https://trufflesuite.com/↩︎

  10. https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/↩︎

  11. https://cloud.google.com/architecture↩︎

  12. https://aws.amazon.com/architecture/well-architected/↩︎

  13. https://alien4cloud.github.io/index.html↩︎

  14. https://tinyurl.com/mrp8hjdd↩︎

  15. https://tinyurl.com/3m9vnpba↩︎