A Blockchain-Centric IoT Architecture for Effective Smart Contract-Based Management of IoT Data Communications

Abstract

The exponential growth of the Internet of Things (IoT) is being witnessed nowadays in different sectors. This makes IoT data communications more complex and harder to manage. Addressing such a challenge using a centralized model is an ineffective approach and would result in security and privacy difficulties. Technologies such as blockchain provide a potential solution to enable secure and effective management of IoT data communication in a distributed and trustless manner. In this paper, a novel lightweight blockchain-centric IoT architecture is proposed to address effective IoT data communication management. It is based on an event-driven smart contract that enables manageable and trustless IoT data exchange using a simple publish/subscribe model. To maintain system complexity and overhead at a minimum, the design of the proposed system relies on a single smart contract. All the system operations that enable effective IoT data communication among the different parties of the system are defined in the smart contract. There is no direct blockchain–IoT-device interaction, making the system more useable in wide IoT deployments incorporating IoT devices with limited computing and energy resources. A practical Ethereum-based implementation of the system was developed with the ability to simulate different IoT setups. The evaluation results demonstrated the feasibility and effectiveness of the proposed architecture. Considering varying-scale and varying-density experimental setups, reliable and secure data communications were achieved with little latency and resource consumption.

1. Introduction

The advent of the Internet of Things (IoT) represents a paradigm shift that drives innovations in different domains such as healthcare, industry, and agriculture. It connects a vast array of physical objects, including sensors, actuators, and intelligent devices, to the Internet. This technological evolution has the potential to revolutionize several sectors by facilitating real-time monitoring [1], smart control [2], and automation [3]. Accordingly, a revolutionary deployment of a broad range of smart IoT applications has been widely seen recently. Example applications are smart grids [4], e-health [5], and smart cities [6]. Consequently, there has been an exponential growth in the total number of IoT-connected devices. As indicated by the forecast reported in [7], the total number of IoT devices that will be Internet-connected by 2030 will reach more than 30 billion. This would expand the IoT market to generate high figures in revenue. As estimated in [8], a figure of USD 3.9–11.1 trillion can be achieved by 2025.

However, the widespread adoption of IoT presents several critical challenges such as data privacy, security, and interoperability [9]. The growing use of IoT systems in our daily life would open the doors for critical security attacks and privacy breaches. The potential damages as a result of these threats would lead to IoT system collapses with probably complete data communication disruption. As reported earlier, security attacks cost USD 400–500 billion in 2015, whereas the cost incurred in 2016 was approximately USD 2–3 trillion [10]. All these vital considerations demonstrate the importance of addressing more advanced IoT solutions with effective security and privacy support. Without such an orientation, wide deployments of IoT in many domains would be effectively hindered. Security and privacy support are vital to reviving the potential of IoT for different real-world applications.

A feasible approach to enrich security effectiveness is incorporating advanced technologies into IoT systems. One of these technologies that offer enormous potential to enhance IoT development is blockchain. After its great success in enabling new financial models, blockchain is emerging as an effective solution for improving different aspects in many research areas [11]. Developing IoT systems based on blockchain becomes a potential solution for addressing critical IoT challenges such as secure access control [12], manageable data sharing [13], and effective identity management [14]. That is, integrating blockchain technology can add to the efficiency of IoT solutions due to different considerations. It addresses the limitations of conventional centralized IoT models such as availability, transparency, and security by enabling more distributed IoT architectures. It also provides data integrity, decentralized processing, activity traceability, and cryptographic support. In addition, blockchain enables smart contract development, which makes transactions traceable, transparent, and irreversible.

In IoT systems, smart contracts can be effectively utilized to manage interactions among the different parties of IoT systems and enforce data communication protocols. They facilitate the automation of IoT system operations in a trustless environment. The operations can be transformed into programming functions run by self-executing and self-enforcing smart contracts. Then, the system entities can invoke these functions by making a transaction with the corresponding contract. This approach would enable running IoT system operations with adequate security and privacy support. To realize this in a lightweight and transparent design, however, the challenge of having IoT devices with limited computing resources in typical IoT deployments needs to be considered.

In this paper, a generic and easy-to-manage blockchain-based IoT architecture is proposed. It has a systematic and simple design that facilitates effective and secure IoT data communication. It is based on a blockchain-centric publish/subscribe mechanism to enable efficient data communication management. This helps the architecture to guarantee data security, integrity, and availability in a manageable and effective manner. The proposed architecture mainly relies on an event-driven smart contract to facilitate efficient and secure data communication in a trustless and distributed environment. The smart contract defines all the operations to enable the exchange of IoT data among IoT devices and clients. However, the design of the system ensures that IoT devices have no direct interaction with the blockchain. This is deemed important to increase the system usability for IoT systems with resource-limited IoT devices. The proposed architecture is designed to operate with a single smart contract to reduce system complexity and minimize communication and processing overhead. The system was implemented based on Ethereum and the development of a simulation tool to simulate different IoT setups in a practical and simple manner. The evaluation results demonstrated the feasibility and effectiveness of the proposed architecture. Considering varying-scale experimental setups, reliable and secure data communications were achieved with little latency and resource consumption.

A four-fold contribution is provided by this research work. First, it provides a novel lightweight blockchain-centric IoT architecture for effective data communication management. Second, it defines a generic smart contract that enables manageable and seamless IoT data exchange based on a simple publish/subscribe mechanism. Third, it addresses a scalable blockchain-based design that is applicable to wide IoT deployments incorporating IoT devices with very limited computing and energy resources. Fourth, a practical Ethereum-based implementation with the ability to simulate varying-scale IoT scenarios is provided.

The following section, Section 2, presents a research overview of the related work. Section 3 provides an overview of the proposed architecture and presents its architectural design and operational workflow. In Section 4, the implementation of the proposed system is detailed. Section 5 explains the testing setups, and Section 6 discusses the evaluation results. Section 7 concludes the paper and indicates future plans.

2. Related Works

With the substantial development of IoT, more effective IoT architectural systems become vital to drive further adoption growth globally. Addressing such a key IoT consideration with the support of critical aspects such as security, privacy, usability, and simplicity would contribute to the greater success of IoT. There have been many attempts towards the development of advanced IoT systems that incorporate innovative technologies. Examples are cloud computing-integrated and artificial intelligence-enabled IoT systems [15,16,17].

The success of blockchain technology in finance has attracted considerable scientific interest in extending its efficiency to other technological research areas. Recently, there has been wide research interest in the development of advanced integrated IoT architectures incorporating blockchain capabilities. The potential of blockchain technology to address different challenges in IoT environments was analyzed in many extensive review studies. In [18,19], several inherent blockchain qualities which can add considerably to the effectiveness of IoT systems were highlighted. These included decentralization, smart contracts, built-in trust, peer-to-peer structure, transparency, and asymmetric encryption. Such properties make blockchain prevalence provide great support to IoT systems in regard to system security [20], data privacy [21], decentralized identity management [22], access control [23], reliable data sharing [24], and trust management [25]. In addition, the study in [26] pointed out the feasibility of blockchain smart contract-based solutions in addressing IoT access control, authentication, integrity assurance, data protection, and secure key management.

There have been ongoing research efforts toward the development of more blockchain-based solutions for enhancing such functional aspects in IoT systems. Focusing on IoT data communication management, a variety of research activities have been performed to approach this aspect using different blockchain-centric solutions. In [27], a basic blockchain-based IoT architecture was proposed to secure data communication in a trustless environment. IoT devices directly interact with the blockchain to maintain their communications with a defined level of security support and identity verification. Based on its capabilities, an IoT device can join the blockchain network with one of multiple specified access modes. In [28], an IoT architecture for managing secure data communication using blockchain was proposed. It encompassed the IoT system in different gateways interconnecting multiple IoT devices while being connected to a cloud server. The exchange of IoT data is managed through the cloud server via which the system is connected to the blockchain network.

A different IoT communication management approach that considers incorporating multiple blockchain layers was introduced in [29]. It was based on a theoretical model that defines a hierarchical multi-blockchain design of a single global blockchain connecting multiple regional blockchains. A similar approach was adopted in [30] to develop a secure IoT data communication system. It has a hierarchical design based on a public blockchain network and several local private blockchain networks. In addition, the system has a global cloud storage to which multiple local storage units are connected. The IoT devices are grouped into different clusters with each cluster connected to a local blockchain network and local storage. The research work in [31] proposed a blockchain-based IoT authentication and secure communication scheme using a hybrid cryptosystem with lightweight cryptographic functions. The system is set up with multiple system clusters to which IoT devices can join once connected and authenticated through the blockchain. Only communications among IoT devices within the same cluster are addressed, whereas inter-cluster communications are not supported.

In [32], IoT devices act as nodes in the blockchain network in addition to being sensor data collectors. Each device transmits the collected data to a cloud server after the data are encrypted. A searchable reference to the data is created and then mined to the blockchain network. The proposed work in [33] was based on realizing computable blockchain-based IoT data communications based on ciphertext computation. For successful IoT communication, IoT data collected by IoT devices need to be firstly encrypted using fully homomorphic encryption on an edge server before being signed using a signature algorithm on a cloud server. To access the data, clients send computation requests to the cloud server which then returns the ciphertexts required to retrieve the data from the blockchain. In [34], a new blockchain-based IoT data-sharing scheme incorporating federated learning was introduced. It was based on leveraging federated learning to build and share data models instead of the original IoT data for improving communication privacy. The system needs to incorporate a federated learning module that is run locally to train a global data model upon any data communication request. In [35], a blockchain-centric publish/subscribe scheme for managing IoT data communication was proposed. It was based on a blockchain-based broker that coordinates data publishing and client subscription.

Other research proposals made effective use of smart contract development, facilitated by blockchain technology, to further improve the robustness of IoT systems. Several smart contract-based solutions addressing different aspects of IoT systems were proposed. Focusing on data communication and sharing, smart contracts provide an effective approach to managing and automating the interaction among the different parties of the IoT system in a trustless and secure manner. The proposed IoT data-sharing system in [36] utilizes a smart contract to administrate certain functionalities such as client registration, device identification, data storage, and task management. This requires all the system parties including IoT devices, servers, and clients to establish direct interaction with the blockchain. Another smart contract-based solution that incorporates a paring-free proxy re-encryption mechanism was proposed [37]. The system creates runtime dynamic smart contracts to enable the exchange of available IoT data. In [38], a smart contract-based IoT data-sharing architecture with a business-oriented model was proposed. Transactions are executed via a smart contract defining the data-sharing terms and conditions in terms of the rental fee and amount of data. It enabled monetizing IoT data communication by requiring clients to pay for establishing IoT communication.

However, other approaches considered the deployment of multiple smart contracts to optimize different operations of the system. In [39], the proposed IoT system defines three different smart contracts to manage the communications among the IoT devices and system clients. These contracts were designed for device information retrieval, policy management, and client authentication. In [40], the proposed IoT system incorporates two different smart contracts to manage the processes of data storage and sharing. The research work in [41] proposed a smart contract-based IoT solution to enable policy-based IoT data sharing. It required a different smart contract to be deployed for each owner of IoT devices to maintain data security and privacy.

These contributions indicate the feasibility of adopting blockchain technology to address the challenge of effective IoT data communication management. However, certain design limitations which would be a limiting factor for practical IoT implementation were imposed, as indicated in

Table 1. Summary and comparison of the relevant literature.

Ref.	Theme	Direct Blockchain– Device Interaction	Architectural Complexity	Computational Overhead	Intra-Cluster Communications Only
[27]	Dynamic blockchain architecture	√	×	√	×
[28]	Cloud-integrated blockchain architecture	×	√	×	×
[29]	Hierarchical multi-blockchain design	×	√	×	×
[30]	Hierarchical multi-blockchain design	×	√	√	×
[31]	Hybrid cryptosystem-based blockchain architecture	×	√	×	√
[32]	Cloud-integrated blockchain architecture	√	×	√	×
[33]	Cloud-integrated blockchain architecture	×	×	√	×
[34]	Federated learning-integrated blockchain architecture	×	×	√	×
[35]	Publish/subscribe scheme with blockchain-based broker	×	√	×	×
[36]	Smart contract-based solution	√	×	√	×
[37]	Smart contract-based solution	×	×	√	×
[38]	Smart contract-based solution	×	√	√	×
[39]	Smart contract-based solution	×	√	×	×
[40]	Smart contract-based solution	×	√	√	×
[41]	Smart contract-based solution	×	√	×	×
This Study	Smart contract-based solution	×	×	×	×

. These include the direct blockchain–device interaction [27,32,36], the need for additional entities [35], and the support of only local intra-cluster communications [31]. Other considerations are the complexity introduced by the cloud-based blockchain communication [28], multi-blockchain architecture [29,30], cloud-based ciphertext computation [33], federated learning-integrated approach [34], and multi-smart contract design [39,40,41]. It is evident that there is still notable room for further research and development in this emerging area. Considering all these limitations while developing a lightweight and effective IoT data communication management architecture is a major objective of this research work. The proposed architecture is based on a blockchain-centric publish/subscribe mechanism, similar to [35] but without imposing any additional entities in IoT systems. Being an effective approach to realizing trustless data communication management as indicated in [36,37,38,39,40,41], smart contract-based design is adopted for the proposed architecture.

3. System Design

This section provides an overview of the proposed architecture and describes its main components. In addition, it elaborates on the workflow and presents an operational overview of the system.

3.1. Architecture

The proposed architecture consists of different entities that provide a blockchain-based IoT data communication system. Figure 1 illustrates the main architectural entities of the architecture, namely IoT devices, gateways, blockchain network, clients, device discovery, and registry. The system also features a unique smart contract deployed in the blockchain network. The system defines two main types of users: system admin and client user. The system admin is responsible for managing the system, authorizing client access, maintaining the blockchain network, and deploying/updating the smart contract. Any remote user device can be utilized as a client given that it is able to read/write data in the blockchain network. In this subsection, a functional description of each component is provided.

3.1.1. IoT Device

IoT devices are typically small-sized and constrained physical devices with limited processing, storage, and power resources. They are embedded with sensing and communication modules to provide the functionality of IoT data collection and transmission. They form the main source of data which can be obtained via different types of sensors for enabling certain IoT applications such as environmental monitoring, smart industry, and e-health. IoT devices can be any IoT-enabled physical objects or IoT-customized devices such as microcontrollers with sensors and actuators, smart wearables, and wireless cameras. As IoT devices are resourced-limited devices, the system prevents them from being deployed as part of the blockchain system or even having direct interaction with the blockchain network. Instead, they only communicate with the gateway entity, which typically has more durable resources. In addition, varying-scale deployment of IoT devices is supported by the system. IoT networks are established among the IoT devices to maintain their interconnectivity using wide options of communication technologies. These include WiFi and 4G as well as IoT-oriented ones such as LoRaWAN and NB-IoT. Moreover, the architecture requires the IoT devices to be uniquely and globally identified in the blockchain system. A unique identifier is assigned to each device to simplify identity management across the system.

3.1.2. Gateway

The gateway in our architecture is a multifunctional device that is non-constrained in terms of computing, storage, and power capabilities. The functionality of the gateway includes device registration, identity management, verifying IoT device transactions, smart contract invocation, and data encryption/decryption. In addition, the gateway entity manages device–blockchain interaction and enables IoT data communication via the blockchain. It interconnects IoT devices and provides them with secure access to the blockchain network. All the communications with the blockchain are handled by the gateway on behalf of the IoT devices. It invokes and listens to smart contract events to handle secure data communication among IoT devices and clients. The architecture allows the deployment of multiple gateways and requires assigning a unique ID for each. It also enables a gateway to interconnect a varying number of IoT devices and allows a blockchain node to connect to one or multiple gateways.

3.1.3. Blockchain Network

The blockchain network is a key component of the architecture for maintaining decentralized communication and data integrity. It physically consists of multiple interconnected nodes in a peer-to-peer network. It provides the main functionality of miners, distributed ledgers, and smart contracts. The blockchain network in our architecture can be private or public. It is utilized for managing resource sharing, client access, and data communication. The architecture requires the blockchain system to support smart contract development, which is one of its key design components. In our architecture, the blockchain entity contains the following main modules:

○

Registration module: to enable associating an IoT device with a unique identifier that represents its blockchain address.

○

Verification module: to enable verifying client access to the different resources of the system.

○

Mining module: to enable processing of all the blockchain transactions by the miner nodes.

○

Smart contract module: to enable deploying a smart contract and handling all the triggered events.

3.1.4. Device Discovery

The device discovery module is responsible for retrieving information on specific resources requested by clients. Resource discovery is a key process in maintaining availability and utilization at a low complexity level. It is based on requesting information about certain available resources in the system and providing sufficiently detailed responses to make the lookup operation effective. It enables the clients to easily search for and find the available and required resources in the system. This is an important design consideration to simplify resource discovery and utilization, particularly for large-scale deployments. To enable such a functionality, it is required to make system resources discoverable with sufficiently detailed information to improve system usability. Therefore, at an early stage, a new resource is initially processed in the registry to add its information in an informative manner. For example, information about the IoT devices that support environmental monitoring in a specific location needs to be made available for any relevant request issued by a client. In response to the resource requests, the device discovery module replies with the IDs of all the available devices that can fulfill the request.

3.1.5. Registry

The registry is incorporated as a local storage module for storing the information of IoT devices and enabling simple management of the physical resources of the system. It can be implemented considering any storage facility such as single/multiple database servers and standalone files. To maintain the complexity of blockchain interaction at a low level, the architecture has the registry as an external module. The gateway entity frequently interacts with the registry for adding, updating, and removing resource information. Information can be organized in different ways such as grouping certain devices under specific groups or categorizing resources into different categories for better device characterization and resource allocation.

3.1.6. Clients

Any remote user device can be utilized as a client given that it can read/write data in the blockchain network. Clients interact with the system to access its resources and establish data communications with IoT devices. For example, an industry user can use a laptop to monitor the status of multiple IoT-enabled machines by accessing the relevant IoT data in the blockchain at a certain period of time. A remote server, remote gateway, or any IoT-enabled object can act as a client. The client accesses the system via the blockchain to ensure reliable, secure, and decentralized data communication. Client communications are handled through the smart contract module of the blockchain.

3.2. Conceptual Design Overview

The proposed architecture is based on a hierarchical design of multiple conceptual layers. It provides a systematic and simple design that can facilitate effective and secure data communication. The architecture was developed with only four hierarchical layers: IoT devices, edge, blockchain, and application layers. Each layer is designed to provide certain distinctive functionalities of the IoT system. Figure 2 presents an overview of the architectural multi-layered design of the proposed architecture. An overview of these layers is provided as follows:

○

IoT-Device Layer: IoT devices are deployed at the physical layer located at the bottom of the architecture. This layer provides IoT device management and network connectivity in addition to IoT data collection, acquisition, and transmission. It also includes handling communication with the IoT devices via the gateway. Due to mostly having devices of limited capabilities, this layer is maintained in a simple form with basic functionality.

○

Edge Layer: Different main components of the system are located at the edge layer to maintain multiple key operational aspects. One is managing the interconnectivity of IoT devices with the system via the gateway entity. This requires establishing IoT-based wired/wireless connectivity among the IoT devices and the gateways. The established connections then enable the gateways to receive and forward collected IoT data at the bottom layer to the relevant clients. At this layer, device registration and identity management are performed to enable effective device characterization and resource allocation. In addition, this layer maintains the device discovery process to provide effective control of client access to the different resources of the system. It also maintains different functionalities such as data encryption, user authentication, and access authorization. Moreover, the interaction of the system with the blockchain network is only handled at this layer. This enables the system to abstract its complexity at this core layer and makes it modular enough to be implemented with more advanced capabilities.

○

Blockchain Layer: The blockchain layer contains all the operations that provide the different decentralized functionalities of the blockchain system. These include identity management, access control, consensus, distributed ledger, miners, event management, and smart contract. This layer enables event-triggered smart contract-based IoT data communication among data producers and IoT clients in a trustless environment. Actions performed on the IoT data are validated and processed as transactions in the blockchain system at this layer. The design of this layer enables the system to encompass and abstract the functionality of the blockchain modules. This is a key design aspect for facilitating effective integration of the blockchain system into the architecture.

○

Application Layer: The different application-related aspects are managed at the application layer. These include defining client access, resource lookup, data request, and service subscription. This layer comes at the top level of the architecture to maintain direct interaction with IoT application users. IoT data are requested and received at this layer for a specific IoT application such as environmental monitoring or remote surveillance. The data are then processed to provide smart application-oriented services.

3.3. Smart Contract

The system features the smart contract module as part of the blockchain network. Different processes of the system are executed via the smart contract to enable controlled and secured access to the IoT devices. These include device discovery, client subscription/unsubscription, and data publishing. The system requires the deployment of a unique integrated data-sharing smart contract in the blockchain. This would simplify the process in the blockchain network and lead to a reduction in the communication overhead among the blockchain nodes. Being integrated into the blockchain would keep it tamper-proof and immunized from being removed. The smart contract needs to be deployed by the admin user into the blockchain network. Once deployed, its address is returned to the admin user to be then exchanged with any gateway and client that successfully connected to the system. The device discovery module is also configured with the address of the smart contract. This allows these entities to interact with the smart contract for triggering and detecting the blockchain events of the system.

The smart contract of the system is a piece of code deployed in a decentralized network of blockchain nodes. Any request or execution of a smart contract is translated into a transaction on the blockchain. As explained in

Table 2. List of the Smart Contract Operations.

Operation	Parameters	Description	Events
GetResList	ResType, DDAddr	A client queries a resource	GetResListEvent (ResType, DDAddr, ClientAddr)
ResListRes	ResType, ClientAddr, ResList	The device discovery responses to a client query	ResListResEvent (ResType, DDAddr, ClientAddr, ResList)
Subscribe	DevAddr	A client subscribes to a specific device	SubscribeEvent (DevAddr, ClientAddr)
SubscribeAck	CleintAddr, StatusCode	A gateway acknowledges client subscription	SubscribeAckEvent (DevAddr, ClientAddr, StatusCode)
Publish	ClientAddr, message	A gateway publishes data from IoT devices to subscribers	PublishEvent (DevAddr, ClientAddr, Message)
PublishAck	DevAddr, TransactionHash	A client acknowledges a published message	PublishAckEvent (DevAddr, ClientAddr, TransactionHash)
Unsubscribe	DevAdd	A client unsubscribes to a specific device	UnsubscribeEvent (DevAddr, ClientAddr)
UsubscribeAck	ClientAddr, StatusCode	A gateway acknowledges client unsubscription	UnsubscribeAckEvent (ClientAddr, DevAddr, StatusCode)

, the smart contract of the system defines a set of operations that enable its different smart contract-based processes. These govern the IoT resource access and data sharing which are triggered by blockchain transactions. The system admin is the only entity that has the right to manage the smart contract. For simplifying the interaction with the blockchain, the system is based on an event-driven smart contract. Any operation performed via the smart contract causes a relevant blockchain event to be released. The smart contract defines the following main operations: GetResList, ResListRes, subscribe, subscribeAck, Unsubscribe, UnsubscribeAck, publish, and PublishAck. Accordingly, the events that can be triggered are defined in the system as follows: GetResListEvent, ResListResEvent, subscribeEvent, subscribeAckEvent, UnSubscribeEvent, UnSubscribeAckEvent, publishEvent, and PublishAckEvent.

Table 3. Smart Contract Event Registration.

Component	Event Registration
Gateway	SubscribeEvent, PublishAckEvent, UnsubscribeEvent
Device discovery	GetResListEvent
Client	ResListResponseEvent, SubscribeAckEvent, UnsubscribeAckEvent

illustrates the smart contract events to which each component should be registered.

3.4. System Workflow

Figure 3, Figure 4 and Figure 5 provide an operational overview and explain the different stages of the system. At the initial stage, the smart contract needs to be developed and then deployed by the admin user into the blockchain network. The admin user also adds the local addresses of the authorized clients in the registry using the system operation addclient as shown in Figure 3. This enables the system to control the access of the clients and allow only authorized access to the system resources. New clients can be added and existing clients can be removed by the user admin as required. This process is kept simple for minimizing system complexity while staying extendable with additional authentication and authorization mechanisms.

At the stage of device setup, as shown in Figure 4, a newly joining IoT device needs to first initiate a connection and exchange its information with a nearby and available gateway. This is performed using the system operation Connect which enables exchanging DevInfo with the gateway. The device information includes its type, location, and available resources in addition to its credentials. Once it successfully receives and authenticates the access request, the gateway carries out the system operation CreateDevBCAdd to generate a unique global blockchain address for the device. Then, the device registration information is sent by the gateway to the registry using the system operation AddDev. Note that the registry stores the ID of the gateway, to which the device is currently connected, in addition to the device information and blockchain address.

Given that the information on all the devices and resources available in the system is stored in the registry, the device discovery process can be performed in the following stage as shown in Figure 4. The client initiates the process by sending the GetResList request to the blockchain address of the smart contract. The request indicates the requested resource type and relevant gateway address. Once it is received at the blockchain network, the request triggers the smart contract event GetResListEvent. The event is detected by the device discovery module, which receives the requested resource type, relevant gateway address, and client address. It then checks with the registry whether this is an authorized client. If so, the operation GetResLsit is handled by the registry, which then returns the request resource list if exists. A response is then sent back by the device discovery module to the address of the smart contract. As a result, the event ResListRepEvent is triggered, causing the client to receive the information of the requested resource.

As shown in Figure 5, the following stages include the different processes required to manage IoT data communications following a blockchain-based publish/subscribe mechanism. The smart contract defines all the operations and events to enable the exchange of IoT data among IoT devices and clients. Firstly, the client needs to initiate the subscription stage by sending a subscription request to the gateway. The client issues a blockchain transaction and invokes the smart contract operation subscribe. It specifies the device address DevAddr which was obtained during the device discovery stage. As a result, the gateway receives this request by intercepting the subscribeEvent event along with the client address. After successfully verifying the client, the gateway stores the client subscription information in the registry using the system operation RegisterClientSubscription. The information includes an association between the device and client addresses. Then, it sends back a subscription acknowledgment with the relevant code, as shown in

Table 4. SubscribeAck and UnsubscribeAck Event Status Codes.

Status Code	Code Description	Event
1	subscribed successfully	SubscribeAck
2	already subscribed	SubscribeAck
3	client is inactive	SubscribeAck
4	unsubscribed successfully	UnsubscribeAck
5	not subscribed	UnsubscribeAck

, to the client. This is achieved by running the smart contract method SubscribeAck. This triggers the smart contract event SubscribeAckEvent which is then received and processed by the client.

After that, the client becomes able to receive IoT data from the associated device during the data publishing stage. This starts with the IoT device periodically transmitting the collected IoT data to the gateway using the system operation Publish. Once the data are received, the gateway stores the data along with the device address and gateway ID in the registry. Then, it uses the GetAllDevSubscribers operation to request the address list of all the clients subscribed to the device. Upon obtaining the list, the gateway publishes the received data to the subscribers via the blockchain. This is performed by invoking the smart contract operation Publish for each subscribed client. A PublishEvent is then triggered and detected by the relevant clients subscribed to the data source. Then, the client responds by invoking the smart contract operation PublishAck to acknowledge the received message. It takes the parameters DevAddr, clientAddr, and TransactionHash which represent the reference of the published message in the blockchain. This triggers PublishAckEvent which is then processed by the gateway as an indicator of successful data communication.

For unsubscribing to an IoT device, the client sends an unsubscription request by making a blockchain transaction during the client unsubscription stage. This is performed by invoking the smart contract operation Unsubscribe indicating the device address. Once the request is received, the UnsubscribeEvent is triggered and intercepted by the relevant gateway. Then, the registry receives the unsubscription request from the gateway using the system operation RemoveClientSubscription. The request indicates the device and client addresses that need to be dissociated. As a result, the subscription information is removed from the registry, and the gateway invokes the UnsubscribeAck operation of the smart contract. This enables the client to receive UnsubscribeAckEvent, ensuring that the unsubscription is successfully completed. The unsubscription process is performed for unsubscribing from a specific device or a group of certain devices without affecting the client’s subscription to other devices at the same gateway.

3.5. Device Group Management

To improve the system efficiency, IoT devices can be grouped into different groups. This would be more effective than managing each IoT device individually. Different groups can be created with different numbers of IoT devices. The system allows an IoT device to be a member of multiple groups. In addition, there are no limitations on how a group is formed. Among many other considerations, each group can represent a different IoT application, geographical area, or device type. For example, a collection of IoT devices can be added to a specific group created for the application of environmental monitoring. In this case, interested clients only need to subscribe to this group for receiving the IoT application data from the devices. This group can also be more specific and only contain devices within certain geographical locations.

Group management is maintained at the gateway entity. The system enables configuring the gateway to add groups to the registry after assigning a blockchain address to every new group. This process is initiated by the admin user configuring a gateway to add a new group for a certain application. The gateway applies the configuration which specifies the group title and joining criteria. For simplicity, these criteria can only define what resources a device should have to join the group. For example, a group can be defined for a simple environmental monitoring application. In this case, the group would be created to contain all the devices equipped with relevant sensors such as temperature and humidity sensors. The corresponding gateway adds the group profile to the registry and then starts including the matching devices in it. If a gateway tries to add a group that already exists in the registry, the operation is denied and a notification message containing the address of the existing group is issued to the gateway.

The device discovery process is extended to enable a client to discover available groups. Instead of replying with the address of the devices of interest, the device discovery module includes the group address in its response. The system also enables clients to subscribe to a group rather than individual devices. During the client subscription stage, the client and gateway use the address of the group to complete the subscription process. In addition, data published by any device of a group are delivered by the gateway to the group subscribers.

Upon adding a new group, the registry issues a notification message to all the gateways connected to the system. The message contains all the information of the group, including its assigned address. Being aware of all the groups in the system, a gateway can add a device to any group created by another gateway. This makes the system flexible enough to allow devices connecting to different gateways to be members of the same group. Any data generated by a member of the group are forwarded by its gateway to all the subscribers. In the case of having a device join multiple groups, the data generated by the device are delivered by the gateway to all the subscribers of these groups. This is made easy and durable using the event-driven smart contract-based mechanism explained in the previous subsection. The gateway needs to only communicate the data with the smart contract module. This then triggers a global event that is intercepted by the intended clients along with the forwarded data.

3.6. Use Case

Figure 6 presents an example use case of the proposed system considering a simple IoT application of smart parking. In this example, an IoT device enabled with the functionality of occupancy monitoring is deployed for each parking space. One option is having radar sensors installed on the surface to detect the availability of parking lots indoors and outdoors. Each IoT device is configured to only perform a single task after connecting it with a gateway in the initial setup. It only transmits the sensed data in the form of basic digital sensor data on a regular basis. The transmitted data contain basic information such as the occupancy state of a parking lot in a textual format.

In large-scale smart parking deployments, multiple gateways are installed to interconnect the IoT devices. Each gateway is configured to serve the IoT devices in a single parking zone or multiple parking zones. Interconnectivity is achieved using an IoT-based communication protocol such as LoRaWAN. This is an effective choice for such an application with wide-area deployments and probably no easy access to local LANs. To establish full IoT connectivity, each IoT device is equipped with a LoRaWAN communication module. This technology provides a maximum payload size of 242 bytes, which is sufficient to exchange parking occupancy information. Sensor data are collected and then sent by the IoT devices to their corresponding gateways using the established LoRaWAN connections at an average volume.

New-generation IoT gateways also have caching capabilities that can be utilized to implement the registry module. A local caching database can be created to store the registry information. Once a client subscription request is accepted by a gateway, the information is stored in its local cache database. When new IoT data are received from an IoT device, the gateway then obtains the list of subscribers from the database and starts publishing the data to the blockchain.

Each gateway is also configured to establish a permanent WiFi-based Internet connection to be used for blockchain communications. It is also set up with a specific blockchain address to interact with the smart contract. These configurations enable the gateway to issue transactions to the smart contract for carrying out the system operations. These mainly include data publishing and subscribe/unsubscribe acknowledging with the system servers. In addition, the gateways need to send blockchain requests for registering to the different events implemented by the smart contract.

The parking service provider installs and connects a set of remote smart parking servers to the system, acting as the clients in this example. Each server is set up to connect to the blockchain and interact with the smart contract. It uses the smart contract address to issue the required transactions for completing the subscription process. Initially, the servers are manually configured for registering to the system and subscribing to the available gateways. Further, the servers are set up to serve mobile apps with the different services of the systems. Each mobile app uses the required APIs to communicate with the servers and access information regarding the availability of parking spaces. Every time an update is received by the server, the mobile app is updated accordingly. For example, a server receiving new IoT data about an occupied parking space being available immediately makes this information accessible to the connected mobile apps. There are many options for interfacing with external clients, such as the mobile app in this example system, but this aspect is regarded as implementation-specific.

It is evident that the proposed system provides a simple approach for effective IoT data communication in complex IoT scenarios. There is no need for IoT devices to carry out heavy processing and blockchain interaction. Once set up, the gateways are only required to maintain IoT-based connectivity with the IoT devices and sustain permanent communications with the blockchain. They frequently interact with the smart contract to perform only one system operation and respond to two main events. Similarly, the clients are only required to use the smart contract for initially carrying out the subscription operation and then frequently detecting the data publishing event. On top of that, only a single smart contract defining a few system operations needs to be deployed to achieve effective communication of the IoT data in such a challenging scenario.

4. Implementation

A proof-of-concept implementation of the proposed architecture was developed as illustrated in Figure 7. Different technologies and tools were utilized and developed to implement the different components of the architecture. This section provides a thorough description of the current implementation.

4.1. Implementation of Components

4.1.1. Blockchain Network

The blockchain network in this work was implemented based on Ethereum, which was adopted due to its popularity and its effective support of smart contract development. To develop a simple Ethereum-based implementation of the proposed system, Ganache was utilized as it provides a user-friendly and cost-effective blockchain development framework. It enables building a local and private blockchain network with smart contract functionality. This can be achieved without the need for setting up an Ethereum client such as Geth. Ganache also provides an open-source tool that features the auto-mining of blockchain transactions with no incurred fees. It runs locally in a fast and customizable manner without the need for running an Ethereum node. It has a graphical user interface (GUI) that enables setting up tests, deploying blockchain-based applications, and creating smart contracts. Ethereum defines two types of accounts: externally owned accounts and contract accounts. The former are controlled by private keys, and the latter are controlled by contract code. Only the smart contract was implemented using a contract account, whereas the other entities of the system were created using externally owned accounts.

4.1.2. IoT Devices, Gateway, and Client

To simplify the implementation of the different entities, an effective web-based simulation tool was built using NodeJS. It provides a simple simulator to simulate a basic IoT device, gateway, and client. Effective simulation of these components can be easily realized considering different IoT setups with different configurations. It is based on an easy-to-use web interface that can be accessed using any browser.

The implementation of the IoT device entity is based on two main software modules. These are the NodeJS client and data transmission modules. When adding a new IoT device, the NodeJS client module requires defining some connection configurations such as the IP address and port number of the gateway to which the device should be connected. This information is then utilized to establish successful device–gateway communication. The device can then send IoT data messages to the gateway using its established connection. This can be configured to specify certain parameters such as data type and transmission interval. The simulation tool can simulate three formats of data, namely plain text, JSON, and images. Figure 8 presents the current web interface of the simulation tool with the IoT device configuration.

The gateway implementation is based on three main software modules. The first is a NodeJS server that listens for incoming requests from IoT devices. This requires specifying a unique IP address and a port number for each newly added gateway to the system. The second module is an event handler that listens for the Subscribe and Unsubscribe events of the smart contract to make the required blockchain transactions. The third module interacts with the smart contract by running the publish operation every time a new data message comes from a connected IoT device.

For implementing the client entity, only one software module is required to handle the interaction with the smart contract. Therefore, blockchain-related configurations are set up for each newly added client. These include a blockchain node address and port number, smart contract address, and application binary interfaces (ABIs). Once configured, the client starts making blockchain transactions and receiving smart contract events.

In addition to running a simple scenario, the simulator allows for running more complex scenarios of multiple IoT devices, gateways, and clients with different configurations. This enables the effective implementation of different IoT scenarios and considering different experimental setups. Moreover, the tool lists all the available simulated components and provides full control of how they run when defining a new scenario, as shown in Figure 9. The simulation tool also shows a live log of each running action with a full description of its state. It also keeps a history of all the completed actions in a descriptive way. Figure 10 shows the live log of a client and indicates all the running and completed actions.

4.1.3. Smart Contract

The smart contract was implemented using Solidity, which is a contract-oriented programming language. It is a high-level Ethereum-customized programming language with the support of object-oriented programming for the effective development of smart contracts. To simplify the implementation, the Truffle framework was utilized on top of Solidity to seamlessly write and compile the smart contract. It provides an effective smart contract development environment in addition to facilitating smart contract deployment and migration in Ethereum. Two main functions of Truffle, namely truffle compile and truffle migrate, were utilized to compile and deploy the smart contract in Ethereum, respectively. Truffle makes the Ethereum address of the smart contract easily available and the ABIs for the smart contract effectively accessible. Figure 11 shows a code snippet of the current implementation of the smart contract and indicates the different events and operations implemented in the smart contract.

4.1.4. Registry

The registry was implemented as a simple local database module in the current implementation. A single MySQL local server was set up to store device and client subscription information. In the current implementation, only the gateway entity interacts with the server during the different stages of the systems. Each gateway was configured to communicate with the server once a new IoT device or client needs to be added to the system. It was also set up to query the database for the subscriber list during the data-publishing stage.

4.2. Functional Overview of the Implementation

At the initial stage, the smart contract was developed using Solidity considering all the operations listed in Table 2. The Truffle framework was then utilized to compile it using the truffle compile function, which converted it to an executable bytecode. Once developed and compiled, the smart contract was deployed using the truffle migrate function. The smart contract was stored as a bytecode in a block via an Ethereum transaction over an Ethereum virtual machine (EVM). Then, the address of the smart contract was obtained and made accessible in the system.

The simulation tool was implemented to connect newly created gateways or clients to certain blockchain nodes using WebSocket connections. There were configured to communicate with the smart contract’s address to run the different operations of the system by invoking the different functions listed in Table 2. When connecting to the blockchain node, they are registered to the relevant events of the smart contract to frequently listen for any triggered event. Gateways are registered to all events for their IoT devices’ addresses, whereas clients are registered to all events for only their addresses.

After a successful connection to the blockchain, a newly created client uses the IoT devices’ addresses provided by the user to the simulation tool to carry out the subscription process. It uses the operation Subscribe to register for the devices. The relevant gateway receives the request as a smart contract event. It then stores the client as a subscriber in the local database in the registry. The simulation tool can also be used to unsubscribe a client from a specific IoT device by submitting the device’s address. This runs the Unsubscribe operation which triggers the UnsubscribeEvent. Once the gateway receives the event, it removes the relevant subscription record from the local database. The log section of the simulation tool provides a live display of all the running operations and events.

A newly created IoT device was set up to communicate its information with a particular gateway determined during the device creation process. It sends a connection establishment request (ConnReq) to the server module running at the gateway. The request includes basic information about the device such as its address and type. Upon the reception of this information, the device registration module at the gateway starts the process of blockchain address generation for the IoT device using Ganache. It then runs RegisterIoTDevice to add the information of the IoT device along with its ID into the local database of the system. Finally, the gateway sets the device status as “connected” and responds with code 1 to indicate a successful connection (see Table 4 for the code list). When the IoT device closes the connection, its status is reset to “disconnected”.

Each IoT device is set up to communicate IoT data of a certain type with its gateway at a specific transmission interval. The simulation tool provides the ability to select different types of data. The NodeJS client module in the device sends the data to the NodeJS server at the gateway. Once the data are received, the gateway queries the database of all clients subscribed to this device. Upon retrieving the subscriber list, the gateway calls the Publish function of the smart contract for each client. As a result, the PublishEvent is triggered and then intercepted by the clients. All events are virtually visualized in the simulation tool to track the different activities of the system.

5. Experiment

The design of the evaluation methodology was based on experimenting with the current implementation of the system considering four simulated IoT scenarios. The main objective was to examine its performance under different experimental setups of varying-scale network topologies and varying complexity levels. The simulation tool was utilized to create different numbers of IoT devices and clients for each scenario as described in

Table 5. Overview of Simulation Scenarios.

Scenario	No. of IoT Devices	No. of Clients	No. of Data Messages
Scenario_1	2	1	2
Scenario_2	8	3	24
Scenario_3	30	5	150
Scenario_4	52	10	520

. These scenarios were formulated as follows:

• A simple smart home scenario: This was created as a simple IoT scenario considering the application of a smart home with two IoT devices and one client. Each IoT device was simulated to have a temperature sensor and humidity sensor transmitting periodical sensor reading data in a simple textual format. Very light IoT data communication was established between the IoT devices and the client. The client can be a smart app running on the smartphone of the smart home’s owner.
• A medium smart home scenario: The smart home setup in this scenario was based on eight IoT devices and three clients. Each two IoT devices were assumed to cover a specific space with a set of different sensors. Each sensor transmitted periodical sensor reading data in a simple textual format. During this scenario, only 24 data messages per second in total were exchanged between the IoT devices and clients. Similar to the previous scenario, the clients were assumed to be smart apps running on the smartphones of the family members.
• A smart farm scenario: A more complex medium-scale IoT setup was simulated in this scenario. It was assumed that there were ten greenhouses with each one having three different IoT devices, representing a total of 30 devices. Each device was fitted with different types of sensors to run different measurements. Each sensor transmitted periodical sensor reading data in a simple textual format. The data communication between the IoT devices and clients in this scenario resulted in 150 data messages per second. The setup also included five clients, and each could access a different set of devices.
• A smart parking scenario: This was set up to simulate a common IoT scenario at a relatively large scale. It was assumed that there were 50 car parking lots, each fitted with an IoT device equipped with sensors to monitor the occupancy of the parking lot. In addition, another two IoT devices had smart cameras to monitor the two main gates of the parking area. Each sensor transmitted periodical sensor reading data in a textual format, whereas the cameras sent images of small sizes. Ten clients were connected to administrate the system. The clients receive 520 data messages per second during this scenario.

The evaluation was based on different measures which provide effective indications of the overall performance of the proposed architecture. The focus was on investigating the latency during two main stages: connection setup and data communication. The former was based on calculating two different measures. The first was the average time taken to establish IoT device–gateway connections. In each scenario, the duration required for the connection request to be sent by each IoT device and then processed by the relevant gateway was calculated and averaged. The second measure was the average time taken for the clients to complete the subscription process with their gateways. Considering all the clients in one scenario, the total time spent from sending subscription requests until receiving successful subscription acknowledgments was calculated and averaged. For the data communication stage, the end-to-end delay was calculated for each data message communicated between a client and an IoT device, and the average of the total was then taken.

The simulation was carried out using a PC desktop equipped with an Intel Core i7-12700T (12th Gen) CPU @ 4.60 GHz and 32.00 GB of RAM. Each simulation run was set for a simulation duration of 15 min and was repeated ten times. The average was then calculated with a confidence interval of 95%.

6. Results and Discussion

The results presented in

Table 6. Device–Gateway Connection Setup and Client Subscription Results.

Scenario	Device–Gateway Connection Setup Delay (s)	Client Subscription Delay (s)
Scenario_1	0.002	0.039
Scenario_2	0.010	0.136
Scenario_3	0.014	0.297
Scenario_4	0.010	1.077

demonstrate the effectiveness of the proposed system in maintaining a satisfying system performance. In all the scenarios, the initial processes carried out for connecting to the system took approximately a second at most. For an IoT device to set up a direct local connection with a gateway, only less than 15 ms was required even in a high-density setup such as Scenario_4. Although it was performed via blockchain transactions, the client subscription process was achieved with very low latency. It took less than 300 ms in all the scenarios except for Scenario_4 in which the latency reached approximately a second.

It can be seen that increasing the setup size caused the system latency to rise. As the scenario density increased, the client subscription delay increased by more than 200% on average. For example, Scenario_4 was scaled up by more than 70% in the number of IoT devices and clients compared to Scenario_3. As a result, a noticeable increase of more than 250% in the average delay of the client subscription process was observed. This was due to the increases in the number of blockchain transactions issued by the clients to complete the subscription with the system. Each transaction needed to be added to a previously mined block in the blockchain. This also triggered the subscription event which required more time to be processed by the gateways.

However, the system experienced a reasonable increase in the latency of the process of the device–gateway connection setup. The latency rose by less than 40% as the scenario scale increased from Scenario_2 to Scenario_4. This reasonable increase was due to the process being performed via a local off-chain network. The system incurred no blockchain interaction overhead on IoT devices.

Figure 12 shows the average end-to-end delay of the data communications between the IoT devices and clients. Overall, the system maintained a satisfying performance, particularly in simple scenarios. Even in relatively medium-scale scenarios, the communication delay was almost a second on average. When the setup size and density increased, it can be seen that the delay increased by more than 200%. This was attributed to the Ethereum block mining process that runs during the data publishing operation. It was found that Ethereum caused a noticeable delay in completing this process for the smart contract transactions of the publish operation. It was also noticed that this time varied based on the current state of the blockchain network. However, the system showed a consistent performance as the scenarios scaled up. Increasing the setup scale in Scenario_3 and Scenario_4 resulted in similar relative increases of approximately 250% in the communication delay.

It is evident that the simplicity and efficiency of the proposed architecture resulted in a satisfying overall performance. All the different stages of the system can be completed with little delay and limited processing overhead. The local process of device–gateway connection setup was carried out with considerably low latency. The smart contract-based processes of client subscription and data communication took a reasonable time to be completed via the fairly slow Ethereum blockchain transactions. In addition, it can be seen that only the gateways and clients interact with the smart contract using a set of specified operations. Periodical IoT data sharing is achieved using a single smart contract operation run by the gateways.

Such a performance was maintained by the proposed architecture with a simple design. A few operations need to be run by the gateway and client entities only to manage IoT data communication via the blockchain. After the initial setup stage, the system requires the gateway entity to maintain permeant communications with the IoT devices to receive IoT data. It is also required to sustain its connection with the blockchain to perform only one smart contract operation and respond to two main events. The client entity only processes one smart contract operation and responds to one event. There is no need for the IoT devices to carry out heavy processing and blockchain interaction. All these considerations help the system limit the interaction with the blockchain while realizing manageable IoT data communication.

In addition, the proposed architecture system also supported intra- and inter-cluster communication based on a sub/pub mechanism without imposing any additional entity in the IoT system. The gateways manage the sub/pub process by controlling the client subscription and data publishing via the blockchain. To maintain its simplicity, the system was developed with a single blockchain layer and a single smart contract design. It was also based on no cloud integration and limited data processing overhead. It came with no heavy computational requirements as only a limited number of smart contract operations were defined to achieve successful IoT data communication management.

7. Conclusions

The integration of blockchain technology into IoT systems offers a promising solution to address significant challenges such as IoT data security and privacy which would limit the wide adoption of IoT. The proposed architecture provides a simple and secure blockchain-based IoT data communication system. It has an effective design that mainly relies on an event-driven smart contract to facilitate efficient and secure data communication in a distributed and trustless environment. The smart contract defines all the operations and events to enable a manageable and seamless exchange of IoT data based on a blockchain-centric publish/subscribe model. The practical implementation of the system provided an effective Ethereum-based simulation tool for experimenting with the system in a variety of different IoT setups. The evaluation results demonstrated the feasibility and effectiveness of the proposed architecture. Considering varying-scale experimental setups, the IoT device connection setup and client subscription were carried out in approximately a second or less. Even in a high-density simulated scenario, the proposed architecture was able to achieve reliable data communication with minimal latency and resource consumption. In general, the proposed architecture provided an effective blockchain-based solution to practically realize different IoT scenarios running with resource-constrained IoT devices.

In future work, integrating IoT-oriented data analytics using machine learning algorithms into the proposed architecture will be studied. Another consideration will be implementing and experimenting with the proposed architecture in a more realistic physical testbed. Moreover, examining the performance of the proposed architecture considering other real-life scenarios for different IoT applications such as smart cities and smart industries would be another research direction for the future.