Blockchain Empowered Smart Home: A Scalable Architecture for Sustainable Smart Cities

Abstract

Emerging growth in technology has rapidly changed our homes and cities. Present homes and cities will be upgraded to smart homes and smart cities in the near future. Various solutions used to build the smart-city network demand a scalable and decentralized solution. This study proposes a blockchain-empowered decentralized and scalable solution for a sustainable smart-city network. The Internet of Things (IoT), fog nodes, permissioned trust chain, smart contract, blockchain, and InterPlanetary file system (IPFS) are deployed to construct a scalable and decentralized solution for a sustainable smart city. Three main public sector departments, i.e., electricity, water supply, and health care, are studied over the proposed solution. The proposed solution is implemented over constrained application protocol (CoAP) and Ethereum blockchain. The performance of the proposed model is evaluated for 1500 devices and over 10,000 records. A total 77.44% improvement is registered during performance evaluation over a scalable environment. The performance evaluation of each case study and collaborative performance evaluation concludes the improvised performance of the proposed solution for scalable and distributed applications. Better performance, scalability, and the distributed nature of the presented model make it suitable for the sustainable smart-city network.

1. Introduction

The Internet of Things (IoT) is one of the fastest-growing sectors across the world, with a prediction of 18 billion IoT devices used by 2022 [1]. The IoT footprints can easily be observed in all domains of life, including home, education, finance, health, transportation, agriculture, etc. The contemporary growth in IoT has foreseen the liveliest future of IoT [2]. Gradually, IoT is expanding from sophisticated industrial applications to basic home applications. IoT-based smart homes make cities and countries smarter. Real-time data acquisition, processing, and storage become possible under IoT scenarios. Data monitoring, processing, and management under IoT scenarios are conceivably more dynamic and sustainable [3]. Fog, edge, and cloud computing are the primitive technologies used for data processing and storage in IoT environments [4]. Besides the emerging growth in IoT, the hierarchical structure based on the centralized data process used in most of the IoT applications is becoming a challenge for future scalable IoT applications [5]. The usual occurrence of a bottleneck for real-time scalable IoT applications is another contrary aspect of centralized controlled architecture [6]. Smart cities, smart driverless transportation, smart agriculture, smart healthcare, smart education, and industrial IoT (IIoT) are some of the scalable (IoT application) areas that require some alternative solutions for effective data processing and storage [7]. IoT and IIoT have many security issues due to the low processing and storage capabilities of IoT devices [8]. In this research, we present a novel architecture especially for scalable IoT solutions. The proposed architecture is suitable for all sorts of scalable IoT solutions including smart transport, smart agriculture, smart healthcare, etc. To abridge an understanding of the proposed architecture a case study of future smart cities has been considered. The proposed architecture focuses on blockchain-based decentralized solutions for scalable IoT applications. Further, the distributed IoT devices (wireless sensor networks) installed at various geographical locations of a smart city are accessed, controlled, and processed over a blockchain-based simulated environment. In contrast to the centralized architecture for scalable IoT applications, the proposed blockchain-based decentralized architecture brings the following advantages for future smart cities:

• The decentralized approach allows the dynamic management of IoT devices over blockchain, which minimizes the occurrence of sleeping patterns.
• The involvement of blockchain allows effortless cross-platform communication.
• The IoT devices connected over different smart home networks can be managed by a single blockchain in a distributed manner, which increases the scope of scalability in smart cities.
• The involvement of public and private blockchain in the proposed architecture makes the overall architecture more transparent and secure.
• Less modification in smart city IoT infrastructure leads to easy integration of proposed distributed blockchain architecture over present architecture.
• The real-time multiple access management increases the usability of IoT devices with limited capabilities.

Further, the smart homes and smart cities will be the new face of every country; hence, this study is contributing a lot to designing that will be helpful in the implementation of future smart homes and smart cities. The major contributions of this study are listed below:

• The IoT-, fog-, and cloud-empowered proposed architecture for smart homes contributes to designing robust and secure future smart homes.
• The proposed blockchain-inspired decentralized architecture for smart cities contributes to designing a scalable architecture for sustainable smart cities.
• The use of private trust chain and public blockchain architecture proposed in this study will improve the security and authentication process in future smart cities.
• The connectivity of the smart home wireless sensor network and smart city network through manageable hub will improve the efficiency of the overall smart city network.
• The blockchain implementation using the InterPlanetary file system contributes to improving the network communication over the larger geographical area of scalable smart-city networks.

Specifically, the proposed research contributes to designing a novel blockchain-based decentralized architecture for future smart cities. The minimal integration modification increases the usability of the presented architecture. A single smart contract for public blockchain reduces the communication overhead between various blockchain nodes [9]. Manageable smart contracts for public blockchain increase the flexibility and security of personal smart homes [10]. In summary, the integration of a decentralized blockchain in the proposed architecture registers better results in comparison with the current centralized solution for scalable IoT applications, including smart cities, smart healthcare, and smart agriculture, etc. For a basic understanding of various technologies involved in the research, the subsequent portion of this section describes the brief introduction of the following leading technologies involved, including IoT, fog, and cloud computing (IFC); smart cities; and blockchain technology.

• IoT, Fog, and Cloud Computing (IFC): The IoT, fog computing, and cloud computing are some of the main technological integrations used in many IoT-based commercial solutions [11]. In IFC, IoT is deployed for real-time data acquisition; preprocessing, classification, and predictive algorithms are implemented over the fog nodes; and lastly, for secure storage of data cloud, computing platforms are employed. The use of different technologies for their specific specialized task makes this integration more efficient in contrast with the individual technology used [12]. The proposed architecture uses the IoT and fog integration for data acquisition and preprocessing; instead of the cloud, the proposed model recommends the use of distributed blockchain architecture for data storage. Blockchain-based Internet of Things is a new face of secure IoT [13,14]. The IFC architecture is illustrated in Figure 1.
• Smart City, a network of smart urban technology: A smart city is a network of smart homes, smart offices and buildings, smart transportation, smart agriculture, and many other smart urban technologies located in a particular geographical area. Under smart cities, digital data and technology are deployed for effective use of resources, economic development of the city, improvement in lifestyle, and enhancing sustainability [15]. London, Singapore, Toronto, San Francisco, Stockholm, and Vienna are the leading smart cities in the world [16]. IoT, artificial intelligence (AI), autonomous vehicles (AV), big data, 5G, robotics, open data, and blockchain are the ultramodern technologies used for smart-city infrastructure [17]. Blockchain-based decentralized IoT empowered smart home and smart city networks are the future of the smart city and smart urban technologies which are prone to cyberattacks [18].
• Blockchain technology: Satoshi Nakamoto first introduced blockchain as Bitcoin’s public ledger [19]. Bitcoin was the first legally accepted cryptocurrency. Subsequently, many other cryptocurrencies based on similar structures were introduced, including Ethereum, Litecoin, Cardano, Polkadot, Bitcoin Cash, Stellar, Chainlink, Binance Coin, Tether, and Monaro. Grounding blockchain, the other concepts like smart contracts, smart certificates, smart citizenship, smart properties, etc., have evolved over time. Decentralized control, data transparency, auditability, distributed information, decentralized consensus, and security are some of the key advantages of blockchain technology [20]. Numerous efficiency enhancement capabilities including security, transparency, decentralization, scalability, and autonomous capabilities make blockchain a suitable companion for scalable IoT solutions. Typically, a blockchain is a set of blocks where the first block is hardcoded into software and known as the genesis block and the other blocks are connected in a sequence with a unique hash [21]. Proof of work (PoW), proof of stake, proof of storage, proof of burn, and proof of capacity are some of the validity mechanisms used for the validity of a block in blockchain [22]. A brief introduction of widely used blockchain validity mechanisms is presented in Table 1. Only after the validity of a new block is it allowed to hash the current block to become part of a blockchain. Figure 2 illustrates the structure of a blockchain.

Figure 1. Three-layer architecture for IoT–fog–cloud (IFC) ecosystem.

Figure 1. Three-layer architecture for IoT–fog–cloud (IFC) ecosystem.

Table 1. Consensus Protocol. PoW—proof of work; PoS—proof of stake; PoET—proof of elapsed time; BFT—Byzantine fault tolerant.

Characteristics	PoW	PoS	PoET	BFT and Variants	Federated BFT
Blockchain Type	Permissionless	Both	Both	Permissioned	Permissionless
Transaction Finality	Probabilistic	Probabilistic	Probabilistic	Immediate	Immediate
Transaction Rate	Low	High	Medium	High	High
Token	Yes	Yes	No	No	No
Cost	Yes	Yes	No	No	No
Scalability	High	High	High	Low	High
Trust	Untrusted	Untrusted	Untrusted	Semi-trusted	Semi-trusted

Table 1. Consensus Protocol. PoW—proof of work; PoS—proof of stake; PoET—proof of elapsed time; BFT—Byzantine fault tolerant.

Characteristics	PoW	PoS	PoET	BFT and Variants	Federated BFT
Blockchain Type	Permissionless	Both	Both	Permissioned	Permissionless
Transaction Finality	Probabilistic	Probabilistic	Probabilistic	Immediate	Immediate
Transaction Rate	Low	High	Medium	High	High
Token	Yes	Yes	No	No	No
Cost	Yes	Yes	No	No	No
Scalability	High	High	High	Low	High
Trust	Untrusted	Untrusted	Untrusted	Semi-trusted	Semi-trusted

Figure 2. Blockchain Structure; PoW—proof of work.

Figure 2. Blockchain Structure; PoW—proof of work.

To maintain the security and privacy of a smart home in a smart city, the accumulated data from IoT sensors are classified into two sets: public dataset (PuDS) and private dataset (PvDS). The private dataset (PvDS) is maintained by the homeowner over a trust chain platform, whereas the public dataset (PuDS) is maintained by the smart city authorities over a blockchain platform. The conceptual framework of smart homes and their respective implementation to make a network of smart homes, i.e., a smart city, are illustrated in Figure 3 and Figure 4, respectively. The rest of the paper is organized into four different sections. Section 2 discusses the materials and methods; it also elaborates on the proposed model. The subsequent section, Section 3, illustrates the results of the performance evaluation and the related discussion. The last section of this article, Section 4, concludes the article with its future applications.

2. Materials and Methods

System architecture, system interface, and system interactions are discussed in this section. The conceptual models illustrated in Figure 2 and Figure 3 are elaborated under system architecture utilizing layered structure and its components. System interface defines the smart contracts used by blockchain architecture along with the mathematical acceptance policy of a manageable hub. The detailed elaboration of all the system components is given in the following subsections:

2.1. System Architecture

The proposed architecture for sustainable smart cities introduced a novel decentralized access management system over blockchain technology. The proposed architecture used blockchain technology to store and distribute access control information. The proposed system recommends the IoT, fog, and blockchain integration for sustainable smart-city networks. The acquired data, with the help of various IoT sensors, are managed over the local fog nodes and distributed to the nearest local trust point (LTP). The local trust point(s) are used for the permissioned blockchain architecture or trust chain architecture. Various LTP(s) are used to classify data entities and store the respective data entity in its respective global blockchain. To manage the storage issue of a local trust point, the temporary immutability method is deployed to manage the removable blockchain [23]. The classified information is further stored and managed by their respective departments over blockchain and IPFS. The various components of the proposed system that make the framework concrete are listed below:

• Smart Home-Wireless Sensor Network (SH-WSN).
• Manageable Hub (MH)
• Local Fog Nodes (LFN).
• Local Trust Point (LTP).
• Removable Trust Chain (RTC).
• Blockchain (BC).
• Smart Contract (SC).
• InterPlanetary File System (IPFS).

The subsequent portion of this section, explains the detailed illustration of these components, starting from the components associated with smart homes to the components associated with smart cities and smart governance, respectively.

• Smart home wireless sensor network (SH-WSN): SH-WSN is the component associated with smart home networks. Various smart home IoT-enabled devices, sensors, and actuators together build the smart home wireless sensor network. The real-time information acquired from various sensors and actuators is stored over the local fog nodes (LFN). The IoT devices, sensors, and actuators have small storage capacity and small processing powers in comparison with the local fog nodes (LFN) [24]. One IoT device may be associated or connected with many LFN(s) utilizing a manageable hub (MH). The manageable hub (MH) connects the IoT device to the nearest available LFN. Introducing the manageable hub between SH-WSN and LFN makes the communication faster and avoids unnecessary delays in communication.
• Manageable hub (MH): MH connects many smart home IoT devices to many nearby LFN(s). This type of relationship forms the m:1:m (many-to-one-to-many) relationship. The manageable hub helps to connect IoT devices to the nearest available LFN and establishes a 1:1 (one-to-one) relationship for communication. The manageable hub stores the information about all the available LFN(s). The IoT devices send the request for connection to a manageable hub. From the available information about the nearest available LFN, the manageable hub checks the nearest available LFN concerning the request and provides the address of the nearest available LFN. To find the nearest available LFN, the manageable hub uses Algorithm 1. The communication and workings of manageable hub (MH) are illustrated in Figure 5.
• Local fog nodes (LFN): Local fog nodes have comparable large data storage and processing capabilities. LFN are used for data filtering and preprocessing. While receiving data for a smart home wireless sensor network, the chances of falsified-data communication are possible. LFN(s) are deployed to filter such falsified entries. The data received at various local fog nodes are further communicated to the local trust point. Further, the local trust point uses the trust chain, which is the permissioned blockchain. To keep the structure of all blockchain entries identical, the LFN(s) are deployed to preprocess the data. LFN(s) status for availability is stored and updated by MH. As per the availability of LFN, the communication channel for IoT device communication is established through the manageable hub. Algorithm 2 illustrates the process of data filtering and the preprocessing steps executed by the local fog node.
• Local trust point (LTP): LTP is the first smart-city component associated with the proposed architecture. The local trust point issues the unique crypto user ID to all the smart house owners. Further, the LTP is also responsible for storing the information about all the users and the IoT devices associated with their respective users. This information is further used to identify authorized and suspicious users. The local trust point is also used to classify the data and transmits the same to their respective blockchain. Further, the respective blockchain transmits the data to their respective IPFS block. The IPFS block is connected with the concerned departments. The main objective of the local trust point is to authenticate the users’ requests and to classify and transmit the data to their respective blockchains. Algorithms 3 and 4 illustrate the authentication and classification process followed by the local trust point, respectively.
• Removable trust chain (RTC): It is a permissioned blockchain working on a temporary immutability mechanism [25]. RTC is connected with LTP; it is the second smart-city component. As all the LFN(s) are connected with LTP and transmit the information over RTC, it needs a huge data storage capacity for populated smart cities. To manage the storage concern, temporary immutability is deployed over the trust chain. It follows the age matrix to remove the old age transaction block from the trust chain. The temporary immutability trust chain manages the storage concerns without loss of information. The RTC is connected with all the departmental blockchains and transmits the data associated with their respective department as per the classification algorithm. Algorithm 4 illustrates the classification algorithm.
• Blockchain (BC): The various public sector services, including drinking water, food, electricity, health care, education, supply chain, etc., in a smart city are governed by the respective public sector departments. In the proposed architecture, dedicated blockchain is used for dedicated public sector departments. This type of blockchain structure is easily managed and useful for information segregation. The decentralized nature of blockchain makes it useable for scalable smart-city networks. To make this model simple for experimental use, only three public sector services are incorporated in this architecture, i.e., water supply, electricity, and health care. Three different blockchain(s) are used for these departments; WS-BC (water-supply blockchain), E-BC (electricity blockchain), and HC-BC (health care blockchain) are deployed for their respective departments.
• Smart contract (SC): Smart contract is a unique transaction authentication system. All the possible operations on a dedicated blockchain are defined with the help of a dedicated smart contract and are triggered by the respective blockchain transactions. Whenever any operation performed over a blockchain is triggered through a transaction after being authenticated by a smart contract, the available miners keep the information about the respective transaction [26]. The smart contract, once generated, cannot be deleted from the system and is used to authenticate every transaction. Once the miners authenticate any transaction, it is globally accessible by all the blockchain nodes [27]. The operations mentioned under the smart contract are also globally accessible. The smart contracts are defined by the respective departments. Further, the new policies are also incorporated in the smart contracts only by the respective department. As for experimental work, the proposed study uses three different blockchain(s); hence, concerning each blockchain, three different smart contracts are proposed for this study.
• InterPlanetary file system (IPFS): For more flexibility and scalability, IPFS is used for the smart city [28]. The geographical locations of different departments may differ in a smart city, therefore the use of IPFS will improve data accessibility. Different departments’ IPFS(s) are connected for necessary information exchange or some collaborative analysis. IPFS allows decentralized access to information [29] if any Department A needs the information about a specific transaction executed in another Department B. However, the distance between Departments A and B is larger than the third Department C, which has a copy of the same transaction. Therefore, instead of accessing the information from Department B, Department A will access that information from Department C. This type of easy access of information makes the proposed model more flexible and scalable. The example illustrated in this section is diagrammatically represented in Figure 6.

Figure 5. Communication through manageable hub (MH) and M:1:M (many-to-one-to-many relationship) between different architectural components.

Figure 5. Communication through manageable hub (MH) and M:1:M (many-to-one-to-many relationship) between different architectural components.

Algorithm 1: To find the nearest available LFN through manageable hub.

All 8 components discussed so for in this section are integrated into Figure 7. The integration of IoT, manageable hubs, fog nodes, permissioned trust chain, blockchain, and IPFS makes this architecture suitable for the sustainable smart city. The SH-WSN ensures real-time data acquisition from the smart-home network. Further, the MH makes the network communication faster and also helps control traffic over the wireless sensor network. Data filtering and preprocessing are managed by various local fog nodes. The deployment of LTP safeguards the authentication process, consequently RTC manages the storage issues in the smart-city network. Blockchain, smart contract, and IPFS confirm the secure storage and sustainability quality services in smart cities.

Algorithm 2: Local Fog Node Data Filtering and Preprocessing.

Figure 6. IPFS communication.

Figure 6. IPFS communication.

Algorithm 3: Local Trust Point (LTP) User Authentication Process.

Algorithm 4: Local Trust Point (LTP) User Classification Algorithm.

Figure 7. Components of proposed layered structure for smart city.

Figure 7. Components of proposed layered structure for smart city.

2.2. System Interface

The interfaces used by different smart contracts and manageable hubs are discussed in this section. The detailed explanation of various operations is defined under various smart contracts used by different departments and discussed first, followed by the manageable hub query policies.

2.2.1. Smart Contract

In this study, three different departments are considered for experimental work. The case studies elaborated under this section are department oriented. The three case studies are explored as under:

Case Study 1: Under Case Study 1, the electricity department is considered. Electricity is one of the major components of a smart-city network. All 8 components of the proposed architecture discussed in the preceding section are in some way or other dependent upon electricity; therefore, electricity is one of the major components of sustainable smart cities [30]. E-BC is the blockchain dedicated to handling various operations related to the electricity department. To manage the various components concerning the electricity department, the following smart contract definition is used in this case study.

• E-BC smart contract: E is defined as the set of public keys used by each manager (m) of the electricity department, D is defined as the set of public keys used by IoT devices (i), PE is defined as the set of policies used to access resource r with device i; mathematically it is indicated as $P{E}^{i\to i_r^{\prime }}$. This policy is defined as the policy used by device i to device i′ over the resource r. Mathematically, these sets are defined as:

  $$E=\left\{E{\left(m\right)}_1,E{\left(m\right)}_2,E{\left(m\right)}_3,E{\left(m\right)}_4, \dots \dots \dots , E{\left(m\right)}_{\alpha }\right\}$$

  (1)

  where α is total no. of managers for electricity department

  $$D=\left\{D{\left(i\right)}_1,D{\left(i\right)}_2,D{\left(i\right)}_3,D{\left(i\right)}_4, \dots \dots \dots , D{\left(i\right)}_k\right\}$$

  (2)

  where k is total no. of devices for all the departments

  $$PE=\left\{P{E}_1^{i\to i_r^{\prime }},P{E}_2^{i\to i_r^{\prime }},P{E}_3^{i\to i_r^{\prime }},P{E}_4^{i\to i_r^{\prime }}, \dots \dots \dots , P{E}_{\vartheta }^{i\to i_r^{\prime }}\right\}$$

  (3)

  where ϑ is the total no. of policies defined under electricity department.

The various operations defined under the E-BC smart contract are listed below:

$$* Departmen{t}^{’}s new manager registration \left(E_m\right); E^{\prime } \leftarrow E \cup E_D \forall devices \left(D\right)and \forall policies \left(PE\right)$$

$$* New device registration \left(E_m,D_i\right); D^{\prime } \leftarrow D \cup D_i \forall \mathit{managers} \left(E\right) \mathit{and} \forall \mathit{plicies} \left({\mathit{PE}}_i\right) \mathit{where} \left({\mathit{PE}}_i\right) \mathit{is} \mathit{the} \mathit{allowed} \mathit{policies} \mathit{for} \mathit{device} i \in \mathit{PE}, \mathit{Return} \mathit{the} \mathit{touple} \left(D_{\mathrm{i}},Dept\_crypto\_id\right) \mathit{to} \mathit{LTP}$$

$$* \mathit{Add} \mathit{new} \mathit{policy} \left({\mathit{PE}}_{\vartheta +1},D_i\right); {\mathit{PE}}^{j\to j_r^{\prime }} \leftarrow {\mathit{PE}}_{\delta }^{j\to j_r^{\prime }} \cup \mathit{PE} \forall \mathit{devices} \left(D_l\right) \mathit{where} \left(D_l\right) \mathit{is} \mathit{the} \mathit{set} \mathit{of} \mathit{associate} \mathit{devices} l \in D, \mathit{Return} \mathit{the} \mathit{touple} ({\mathit{PE}}_{\vartheta +1}, D_j, Dept\_crypto\_id) \mathit{to} \mathit{LTP}$$

$$* Remove registered manager \left(E_m\right); E^{\prime }\leftarrow E \cap E_D \forall devices \left(D\right)and \forall policies \left(PE\right)$$

$$* Remove registered device \left(E_m, D_i\right); D^{\prime }\leftarrow D \cap D_i \forall managers \left(E\right)and \forall plicies \left(P{E}_i\right)$$

$$where \left(P{E}_i\right) is the allowed policies for device i \in PE, Return the touple \left(D_{\mathrm{i}}, Dept\_crypto\_id\right) to LTP$$

$$* \mathit{Remove} \mathit{existing} \mathit{policy} \left({\mathit{PE}}_{\vartheta -1},D_i\right); {\mathit{PE}}^{j\to j_r^{\prime }} \leftarrow {\mathit{PE}}_{\vartheta }^{j\to j_r^{\prime }} \cap \mathit{PE} \forall \mathit{devices} \left(D_l\right) \mathit{where} \left(D_l\right) \mathit{is} \mathit{the} \mathit{set} \mathit{of} \mathit{associate} \mathit{devices} l \in D, \mathit{Return} \mathit{the} \mathit{touple} ({\mathit{PE}}_{\vartheta -1}, D_j, Dept\_crypto\_id) \mathit{to} \mathit{LTP}$$

$$* Access request \left(D_i, r\right); Return the touple \left(D_i, s\right)$$

$$where \left\{s \exists set of services \forall resource \left(r\right)\right\}$$

Case Study 2: Under Case Study 2, the water supply department is considered. Water is the most common and necessary commodity for life. Issues in the sustainable water supply are rising with the increasing population in smart cities. Water conservation through emerging technology is one of the main concerns of every smart-city administration. WS-BC is the blockchain dedicated to handling various operations related to the water supply department. To manage the various components concerning the water supply department, the following smart contract definition is used in this case study.

• WS-BC Smart Contract: W is defined as the set of public keys used by each manager (m) of the water supply department, D is defined as the set of public keys used by IoT devices (i), PW is defined as the set of policies used to access resource r with device i; mathematically it is indicated as $P{W}^{i\to i_r^{\prime }}$. This policy is defined as the policy used by device i to device i′ over the resource r. Mathematically, these sets are defined as:

  $$W=\left\{W{\left(m\right)}_1,W{\left(m\right)}_2,W{\left(m\right)}_3,W{\left(m\right)}_4, \dots \dots \dots , W{\left(m\right)}_{\beta }\right\}$$

  (4)

  where β is total no. of managers for electricity department

  $$PW=\left\{P{W}_1^{i\to i_r^{\prime }},P{W}_2^{i\to i_r^{\prime }},P{W}_3^{i\to i_r^{\prime }},P{W}_4^{i\to i_r^{\prime }}, \dots \dots \dots , P{W}_{\delta }^{i\to i_r^{\prime }}\right\}$$

  (5)

  where δ is the total no. of policies defined under electricity department.

D is already defined under Equation (2)

The various operations defined under the W-BC smart contract are listed below:

$$* Departmen{t}^{\prime }s new manager registration \left(W_m\right);W^{\prime }\leftarrow W \cup W_D \forall devices \left(D\right)and \forall policies \left(PW\right)$$

$$* New device registration \left(W_m,D_i\right);D^{\prime }\leftarrow D \cup D_i \forall managers \left(W\right)and \forall plicies \left(P{W}_i\right) where \left(P{W}_i\right)is the allowed policies$$

$$for device i \in PW, Return the touple \left(D_{\mathrm{i}},Dept\_crypto\_id \right)to LTP$$

$$* Add new policy \left(P{W}_{\delta +1},D_j\right); P{W}^{j\to j_r^{\prime }}\leftarrow P{W}_{\delta }^{j\to j_r^{\prime }} \cup PW \forall devices \left(D_l\right)$$

$$where \left(D_l\right) is the set of associate devices l\in D , Return the touple \left(P{W}_{\delta +1},D_j,Dept\_crypto\_id \right)to LTP$$

$$* Remove registered manager \left(W_m\right);W^{\prime }\leftarrow W \cap W_D \forall devices \left(D\right)and \forall policies \left(PW\right)$$

$$* Remove registered device \left(W_m,D_i\right);D^{\prime }\leftarrow D \cap D_i \forall managers \left(W\right)and \forall plicies \left(P{W}_i\right)$$

$$where \left(P{W}_i\right)is the allowed policies for device i \in PW, Return the touple \left(D_{\mathrm{i}},Dept\_crypto\_id \right)to LTP$$

$$* Remove existing policy\left(P{W}_{\delta -1},D_j\right); P{W}^{j\to j_r^{\prime }}\leftarrow P{W}_{\delta }^{j\to j_r^{\prime }} \cap PW \forall devices \left(D_l\right)$$

$$where \left(D_l\right) is the set of associate devices l\in D, Return the touple \left(P{W}_{\delta -1},D_j,Dept\_crypto\_id \right)to LTP$$

$$* Access request \left(D_i,r\right);Return the touple \left(D_i,s\right)$$

$$where \left\{s \exists set of services \forall resource \left(r\right)\right\}$$

Case Study 3: Under Case Study 3, the health care department is considered. By introducing contemporary technology in the healthcare sector, a robust and sustainable healthcare system is provided in a smart city. HC-BC is the blockchain dedicated to handling various operations related to the health care department. To manage the various components concerning the health care department, the following smart contract definition is used in this case study.

• HC-BC smart contract: H is defined as the set of public keys used by each manager (m) of the health care department, D is defined as the set of public keys used by IoT devices (i), PH is defined as the set of policies used to access resource r with device i; mathematically it is indicated as $P{H}^{i\to i_r^{\prime }}$. This policy is defined as the policy used by device i to device i′ over the resource r. Mathematically, these sets are defined as:

  $$H=\left\{H{\left(m\right)}_1,H{\left(m\right)}_2,H{\left(m\right)}_3,H{\left(m\right)}_4, \dots \dots \dots , H{\left(m\right)}_{\gamma }\right\}$$

  (6)

  where γ is total no. of managers for electricity department

  $$PH=\left\{P{H}_1^{i\to i_r^{\prime }},P{H}_2^{i\to i_r^{\prime }},P{H}_3^{i\to i_r^{\prime }},P{H}_4^{i\to i_r^{\prime }}, \dots \dots \dots , P{H}_{\mu }^{i\to i_r^{\prime }}\right\}$$

  (7)

  where μ is the total no. of policies defined under the electricity department.

D is already defined under Equation (2)

The various operations defined under the HC-BC smart contract are listed below:

$$* Departmen{t}^{\prime }s new manager registration \left(H_m\right);H^{\prime }\leftarrow H \cup H_D \forall devices \left(D\right)and \forall policies \left(PH\right)$$

$$* New device registration \left(H_m,D_i\right);D^{\prime }\leftarrow D \cup D_i \forall managers \left(H\right)$$

$$and \forall plicies \left(P{H}_i\right)$$

$$where \left(P{H}_i\right)is the allowed policies for device i \in PH, Return the touple \left(D_{\mathrm{i}},Dept\_crypto\_id \right)to LTP$$

$$* \mathit{Add} \mathit{new} \mathit{policy} \left({\mathit{PH}}_{\mu +1},D_j\right); {\mathit{PH}}^{j\to j_r^{\prime }} \leftarrow {\mathit{PH}}_{\mu }^{j\to j_r^{\prime }} \cup \mathit{PH} \forall \mathit{devices} \left(D_l\right) \mathit{where} \left(D_l\right) \mathit{is} \mathit{the} \mathit{set} \mathit{of} \mathit{associate} \mathit{devices} l \in D, \mathit{Return} \mathit{the} \mathit{touple} ({\mathit{PH}}_{\mu +1}, D_j, Dept\_crypto\_id) \mathit{to} \mathit{LTP}$$

$$* Remove registered manager \left(H_m\right);H^{\prime }\leftarrow H \cap H_D \forall devices \left(H\right)and \forall policies \left(PH\right)$$

$$* Remove registered device \left(H_m,D_i\right);D^{\prime }\leftarrow D \cap D_i \forall managers \left(H\right)and \forall plicies \left(P{H}_i\right)$$

$$where \left(P_{Hi}\right)is the allowed policies for device i \in PH, Return the touple \left(D_{\mathrm{i}},Dept\_crypto\_id \right)to LTP$$

$$* \mathit{Remove} \mathit{existing} \mathit{policy} \left({\mathit{PH}}_{\mu -1},D_j\right); {\mathit{PH}}^{j\to j_r^{\prime }} \leftarrow {\mathit{PH}}_{\mu }^{j\to j_r^{\prime }} \cap \mathit{PH} \forall \mathit{devices} \left(D_l\right) \mathit{where} \left(D_l\right) \mathit{is} \mathit{the} \mathit{set} \mathit{of} \mathit{associate} \mathit{devices} l \in D, \mathit{Return} \mathit{the} \mathit{touple} ({\mathit{PH}}_{\mu -1}, D_j, Dept\_crypto\_id) \mathit{to} \mathit{LTP}$$

$$* Access request \left(D_i,r\right);Return the touple \left(D_i,s\right)$$

$$where \left\{s \exists set of services \forall resource \left(r\right)\right\}$$

All smart contract policies are managed only by the department’s managers; no other blockchain node will alter these policies. However, this smart contract is acquiescently available for all the minors and it is the spin of a blockchain security mechanism. In addition to the above-mentioned policies and operations defined under the smart contract, the authentication process executed by LTP complements some additional authentication permissions and operations. The permissions and operations executed by LTP are defined in the subsequent portion of the section.

2.2.2. Removable Trust Chain (RTC)

D-crypto-id is defined as the set of device crypto ID(s), and U-crypto-id is defined as the set of user crypto ID(s). Access-P is defined as the set of access permissions granted to user u, for access resource r with device i; mathematically it is indicated as $Access-P^{u\to i_r}$. Dept-crypto-id is defined as the set of department crypto ID(s). Mathematically, these sets are defined as:

$$D\_crypto\_id=\left\{D\_crypto\_id{\left(c\right)}_1,D\_crypto\_id{\left(c\right)}_2, \dots \dots \dots , D\_crypto\_id{\left(c\right)}_k\right\}$$

(8)

where ∀ divice D ∃ a unique D_crypto_id

$$U\_crypto\_id=\left\{U\_crypto\_id{\left(u\right)}_1, U\_crypto\_id{\left(u\right)}_2, \dots \dots \dots , U\_crypto\_id{\left(u\right)}_{\omega }\right\}$$

(9)

$$Access\_P=\left\{Access\_P_1^{u_1\to i_r}, Access\_P_2^{u_2\to i_r}, \dots \dots \dots , Access\_P_{\omega }^{u_{\omega }\to i_r}\right\}$$

(10)

where $Access\_P_{\omega }^{u_{\omega }\to i_r}$ is a set of access permissions for user ω to access resource r with device i.

$$Dept\_crypto\_id=\{Dept\_crypto\_id{\left(d\right)}_1, Dept\_crypto\_id{\left(d\right)}_2, \dots \dots \dots , Dept\_crypto\_id{\left(d\right)}_{\rho }\}$$

(11)

The access permissions and authentication managed by LTP under the removable trust chain (RTC) are listed below:

$$* New device registration \left(D_{\mathrm{i}},Dept\_crypto\_id\left(d\right)\right);D^{\prime }\leftarrow D \cup D_i \exists Dept\_crypto\_id\left(c\right)\mathrm{and} \exists Acces{s}_P\left(P\right),$$

$$Return the touple \left(D_{\mathrm{i}},Dept\_crypto\_id\left(d\right), Dept\_crypto\_id\left(c\right), Acces{s}_P\left(P\right)\right)$$

$$to DD\_DB, where DD\_DB is department, device database.$$

$$* Add new policy \left(P_{\mu +1},D_j,Dept\_crypto\_id\right); P^{j\to j_r^{\prime }}\leftarrow P_{\mu }^{j\to j_r^{\prime }} \cup P \forall devices \left(D_l\right)\exists Dept\_crypto\_id where \left(D_l\right) is the set of associate devices, l\in D$$

$$* Remove registered device \left(D_{\mathrm{i}},Dept\_crypto\_id\left(d\right)\right); D^{\prime }\leftarrow D \cap D_i\nexists D\_crypto\_id\left(c\right) and \nexists Acces{s}_P\left(P\right),$$

$$Remove the touple \left(D_{\mathrm{i}},Dept\_crypto\_id\left(d\right), D\_crypto\_id\left(c\right), Acces{s}_P\left(P\right)\right)to DD\_DB.$$

$$* Remove existing policy \left(P_{\mu -1},D_j,Dept\_crypto\_id\left(d\right)\right); P^{j\to j_r^{\prime }}\leftarrow P_{\mu }^{j\to j_r^{\prime }} \cap P \forall devices \left(D_l\right)\exists Dept\_crypto\_id where \left(D_l\right) is the set of associate devices, l\in D$$

$$* Access User Device \left( U\_crypto\_id{\left(d\right)}_{\omega }, D\_crypto\_id{\left(d\right)}_k\right); Acces{s}_{P_{\omega }^{u_{\omega }\to i_r}}\leftarrow Acces{s}_{P_{\omega }^{u_{\omega }\to i_r}}\in Acces{s}_P; access denay iff touple not available in U{D}_{DB},$$

where $UD\_DB$ is the $User Device Database.$

$$* \mathit{Access} \mathit{Department} Device \left( U\_crypto\_id{\left(u\right)}_{\omega }, D\_crypto\_id{\left(c\right)}_k\right); Access\_P_{\omega }^{u_{\omega }\to i_r}\leftarrow Access\_P_{\omega }^{u_{\omega }\to i_r}\in Access\_P \mathit{and}D\_crypto\_id{\left(c\right)}_k\in \mathit{Dept}\_crypto\_id; access denay iff touple not available in DD\_DB$$

2.3. Implementation

Proof of concept (PoC) is deployed to test and evaluate the system. This section is dedicated to the implementation of IoT devices, smart contracts, manageable hubs, and blockchain networks.

• IoT devices: A LibCoAP library is used to simulate SH-WSN. Constrained application protocol (CoAP) RFC 7252 is a special web transfer protocol used for IoT networks [31]. A Tinydtls framework is used over the LibCoAP library to ensure the transport layer security [32]. LibCoAP-generated codes were improved to generate public/private keys for IoT devices. A 20-bytes-long public/private key is used to uniquely identify various IoT devices over the SH-WSN. CoAP used the REST model for the IoT devices [33]. General GET, PUT, POST, and DELETE methods are used for client–server interaction. For secure encryption 3072-bit, RSA Keys are deployed; although, through quantum computing techniques it is even possible to break 4096-bit and 8192-bit RSA Keys. To keep the framework less complex and economical, 3072-bit RSA has been deployed, which may be upgraded in the future by some suitable techniques to counter quantum computing attacks [34,35].

  Table 2. Consensus.

  Component	Description
  Protocol	CoAP RFC 7252
  Model	REST
  Methods	GET, PUT, POST, and DELETE, etc.
  Integration	Application-agnostic-cross-protocol proxies
  Data Format	XML, JSON, CBOR, or any custom data format
  Inexpensive IoT nodes (microcontrollers)	Minimum 10 KiB of RAM and 100 KiB of code space
  Client/Server	CoAP Client/CoAP Server
  Secure	DTLS parameters (3072-bit RSA Keys)

  illustrates the LibCoAP for IoT Devices.
• Manageable hub: The CoAP server of the LibCoAP library is used as a manageable hub. CoAP clients at the IoT level are communicated over the CoAP server as a manageable hub. IoT devices connected over the SH-WSN create the CoAP request messages, and the CoAP server as manageable hubs are envisioned to respond over the CoAP request message.
• Smart contract: Three different smart contracts are used by the three different departments as mentioned in the previous section. Solidity programming language is deployed to implement these smart contracts. Three different data structures are deployed to store the different components of smart contracts such as device information, department information, manager information, permissions, policies, etc. Mapping structures are employed to define various smart contract data structures [36].
• Blockchain network: The scalable, programmable, decentralized, and secure nature of the Ethereum blockchain makes it usable for blockchain network implementation [37]. Further, the Ethereum blockchain is also suitable for the implementation of trust chain; hence, for the implementation of the blockchain network, Ethereum blockchain is used. To evaluate the proposed system, private Ethereum blockchain is used. The generic genesis block is employed for the prototyping of the private Ethereum blockchain. Initially, a prototype of a private Ethereum blockchain is recommended, however, at the time of actual implementation of the proposed system, public blockchain is necessary. However, the private blockchain provides us with substantially more accurate results in comparison to the public blockchain. However, it is difficult to deploy the real-life application over the private blockchain network because of its dynamicity.

3. Results and Discussion

The performance of the proposed system under three different case studies is presented in this section. Further, the performance of the complete system is also discussed in this section. To simulate the real-life scenario of a smart city, 500 devices under each case study are considered. Initially, 500 devices dedicated to a specific department are evaluated under various performance evaluation parameters. Subsequently, the overall performance of all three proposed departments are together evaluated; a total of 1500 devices are evaluated. Performance evaluations concerned with the proposed case study are presented below:

Case Study 1: A total of 500 devices dedicated to the electricity department were considered for this case study. Initially, only 100 devices were considered, and subsequently, the next group of 100 devices was added for experimental evaluation; similarly, the performance of all the 500 devices was evaluated. The performance evaluation is further branded for device creation, sensor reading, and query processing. Figure 8a illustrates the performance evaluation for device creation, Figure 8b illustrates the sensor reading, and Figure 8c illustrates the performance evaluation of query processing. The three lines in these graphs indicate the minimum, average, and maximum time taken to create a set of devices. These lines also show the best-, average-, and worst-case performance of the proposed model for device creation. During Case Study 1 performed for 500 devices associated with the electricity department, 8.56933 milliseconds is the average time taken by each device for creating, 9.60867 milliseconds is the average time taken to read each sensor, whereas to process an individual query the proposed model takes only 0.109033 milliseconds. The average time taken for complete query processing, including device creation, sensor reading, and query response, is recorded as 18.28703 milliseconds.

Case Study 2: A total of 500 devices dedicated to the water supply department were considered for this case study. Data sets for evaluation are considered similarly as considered under Case Study 1. During Case Study 2, a slight increase in device creation, sensor reading, and query processing is observed. For device creation, sensor reading, and query processing, the average increase is recorded as 0.02 milliseconds, 0.014667 milliseconds, and 0.001033 milliseconds, respectively. The overall time taken to process an individual query for Case Study 2 is recorded as 18.32273 milliseconds, which shows the increment of 0.0357 milliseconds compared with Case Study 1. Figure 9a–c illustrate the performance evaluation for device creation, sensor reading, and query processing, respectively, for Case Study 2.

Case Study 3: A total of 500 devices dedicated to the health care department were considered for this case study. Data sets for evaluation are considered similarly as considered under Case Studies 1 and 2. During Case Study 3, further slight increases in device creation, sensor reading, and query processing are observed. The average time taken for device creating, sensor reading, and query processing is 8.592 milliseconds, 9.632667 milliseconds, and 0.110133 milliseconds, respectively. The average time taken for complete query processing, including device creation, sensor reading, and query response, is recorded as 18.3348 milliseconds. Case Study 3 recorded the maximum time, followed by Case Study 2, which is associated with the water supply department. Case Study 1, which is associated with the electricity department, recorded the minimum time for all the processes. Figure 10 illustrates the performance evaluation for Case Study 3.

The collaborative performance of all three departments’ understudy is illustrated in Figure 11. The three different sections in Figure 11, i.e., sections (a), (b), and (c), illustrate the performance evaluation for device creation, sensor reading, and query processing, respectively. A total of 1500 devices from all three departments are together evaluated during this study. Initially, 100 devices from each department form the first dataset of a total of 300 devices and, subsequently, 100 new devices from each department were added for the next dataset. In the end, all 500 devices from each department were considered to form a dataset of 1500 devices. Sensor reading takes the maximum time, followed by device creation. The query process takes the least time during the entire cycle. During collaborative performance evaluation, 1.45% improvement in device creation and 1.63% improvement in sensor reading are recorded. On the other side, query processing takes 0.16% more time during the collaborative performance. Improvement in device creation and sensor reading results from the improvement of 2.92% in the overall process of query processing. The collaborative effects of all 1500 devices and 10,000 records registered a remarkable improvement: 78.54%, 77.07%, and 76.71% average improvement is registered for device creation, sensor reading, and query processing, respectively.

4. Conclusions

The proposed blockchain-inspired smart city solution and three departmental-based case studies concluded that the proposed model is suitable for scalable decentralized applications. All three case studies considered for this research concluded that with the increase in scale the performance of the proposed model is improving. The collaborative performance evaluation of all three case studies concluded with a 78.54% improvement in device creation, 77.07% improvement in sensor reading, and 76.71% improvement in query processing. The overall improvement of 77.44% makes the proposed model suitable for scalable applications. The combined use of permissioned trust chain and permissionless blockchain in the model makes it secure and robust for smart cities. The security, scalability, and distributed nature of the proposed model make it suitable for many other sustainable applications, including sustainable supply chain management, sustainable banking, sustainable e-governance, sustainable education, sustainable agriculture and irrigation, sustainable health care system, and many more. Scalable applications such as banking, education, e-governance, etc., will deploy this model for secure and distributed management. The security of smart contracts and permissioned trust chain also make it suitable for sensitive applications such as defense, external affairs, and policymaking.