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.

Full text

Citation: Aldribi, A.; Singh, A.
Blockchain Empowered Smart Home:
A Scalable Architecture for Sustainable
Smart Cities. Mathematics 2022,10,
2378. https://doi.org/10.3390/
math10142378
Academic Editor: Daniel-Ioan Curiac
Received: 27 May 2022
Accepted: 27 June 2022
Published: 7 July 2022
Publisher’s Note: MDPI stays neutral
with regard to jurisdictional claims in
published maps and institutional affil-
iations.
Copyright: © 2022 by the authors.
Licensee MDPI, Basel, Switzerland.
This article is an open access article
distributed under the terms and
conditions of the Creative Commons
Attribution (CC BY) license (https://
creativecommons.org/licenses/by/
4.0/).
mathematics
Article
Blockchain Empowered Smart Home: A Scalable Architecture
for Sustainable Smart Cities
Abdulaziz Aldribi 1, * and Aman Singh 2,3,4,*
1Department of Computer Science, College of Computer, Qassim University, Buraydah P.O. Box 52571, Saudi Arabia
2Prince Faisal bin Mishaal Artificial Intelligence Chair, Qassim University, Buraydah P.O. Box 52571, Saudi Arabia
3Higher Polytechnic School, Universidad Europea del Atlántico, C/Isabel Torres 21, 39011 Santander, Spain
4
Department of Project Management, Universidad Internacional Iberoamericana, Campeche C.P. 24560, Mexico
*Correspondence: aaldribi@qu.edu.sa (A.A.); aman.singh@uneatlantico.es (A.S.)
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.
Keywords:
blockchain; sustainable smart city; Internet of Things (IoT); smart home; smart contract;
sensors and fog computing
MSC: 68P20; 68M18
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
Mathematics 2022,10, 2378. https://doi.org/10.3390/math10142378 https://www.mdpi.com/journal/mathematics

Mathematics 2022,10, 2378 2 of 22
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 con-
tributes to designing robust and secure future smart homes.
•
The proposed blockchain-inspired decentralized architecture for smart cities con-
tributes 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.
1.
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

Mathematics 2022,10, 2378 3 of 22
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 architec-
ture 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.
2.
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 sustain-
ability [
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].
3.
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 infor-
mation, 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 2illustrates the structure of a blockchain.
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

Mathematics 2022,10, 2378 4 of 22
Mathematics 2022, 10, x FOR PEER REVIEW 4 of 25
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
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 da-
taset (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 author-
ities over a blockchain platform. The conceptual framework of smart homes and their re-
spective implementation to make a network of smart homes, i.e., a smart city, are illus-
trated 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 perfor-
mance evaluation and the related discussion. The last section of this article, Section 4, con-
cludes the article with its future applications.
Figure 1. Three-layer architecture for IoT–fog–cloud (IFC) ecosystem.
Mathematics 2022, 10, x FOR PEER REVIEW 4 of 25
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
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 da-
taset (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 author-
ities over a blockchain platform. The conceptual framework of smart homes and their re-
spective implementation to make a network of smart homes, i.e., a smart city, are illus-
trated 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 perfor-
mance evaluation and the related discussion. The last section of this article, Section 4, con-
cludes the article with its future applications.
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
Figures 3and 4, respectively. The rest of the paper is organized into four different sections.
Section 2discusses 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.

Mathematics 2022,10, 2378 5 of 22
Mathematics 2022, 10, x FOR PEER REVIEW 5 of 25
Figure 3. A conceptual framework for IoT and blockchain-empowered smart home.
Figure 4. A conceptual framework for IoT and blockchain-empowered smart city.
Figure 3. A conceptual framework for IoT and blockchain-empowered smart home.
Mathematics 2022, 10, x FOR PEER REVIEW 5 of 25
Figure 3. A conceptual framework for IoT and blockchain-empowered smart home.
Figure 4. A conceptual framework for IoT and blockchain-empowered smart city.
Figure 4. A conceptual framework for IoT and blockchain-empowered smart city.

Mathematics 2022,10, 2378 6 of 22
2. Materials and Methods
System architecture, system interface, and system interactions are discussed in this
section. The conceptual models illustrated in Figures 2and 3are 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:
1. Smart Home-Wireless Sensor Network (SH-WSN).
2. Manageable Hub (MH)
3. Local Fog Nodes (LFN).
4. Local Trust Point (LTP).
5. Removable Trust Chain (RTC).
6. Blockchain (BC).
7. Smart Contract (SC).
8. 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.
1.
Smart home wireless sensor network (SH-WSN): SH-WSN is the component associ-
ated 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 avail-
able LFN. Introducing the manageable hub between SH-WSN and LFN makes the
communication faster and avoids unnecessary delays in communication.
2.
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.

Mathematics 2022,10, 2378 7 of 22
3.
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.
4.
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.
5.
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.
6.
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.
7.
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 trans-
action 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 acces-
sible. 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.

Mathematics 2022,10, 2378 8 of 22
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.
8.
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.
Algorithm 1: To find the nearest available LFN through manageable hub.
Mathematics 2022, 10, x FOR PEER REVIEW 9 of 25
Algorithm 1:
To find the nearest available LFN through manageable hub
1
𝐷𝑖𝑣
_
𝑖𝑑
←
𝐷𝑒𝑣𝑖𝑐𝑒𝐼𝐷
,
𝐺𝑢𝑝
_
𝑖𝑑
←
𝐺𝑟𝑜𝑢𝑝
𝐼𝐷
,
𝐿𝐹𝑁
_
𝑖𝑑
←
𝐿𝑜𝑐𝑎𝑙𝐹𝑜𝑔𝑁𝑜𝑑𝑒𝐼𝐷
,
𝐷𝑖𝑣_𝑖𝑛𝑓𝑜 ← 𝐷𝑒𝑣𝑖𝑐𝑒𝐼𝑛𝑓𝑜𝑟𝑚𝑎𝑡𝑖𝑜𝑛,
𝑅𝑒𝑞_𝑖𝑑 ← 𝑅𝑒𝑞𝑢𝑒𝑠𝑡𝐼𝐷,
𝐿𝐹𝑁_𝑆𝑡𝑎𝑡𝑢𝑠 ← 𝑢𝑛𝑎𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒,
min
_
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒
←
∞
,
𝑁𝑒𝑎𝑟𝑒𝑠𝑡
_
𝐿𝐹𝑁
←
−
1
2
𝒊𝒇
𝑅𝑒𝑞
_
𝑖𝑑
=
𝑎𝑐𝑡𝑖𝑣𝑒
𝒕𝒉𝒆𝒏
3
𝐺𝑒𝑡
𝐷𝑖𝑣
_
𝑖𝑑
4
𝐺𝑒𝑡
𝐺𝑢𝑝
_
𝑖𝑑
5
𝒘𝒉𝒊𝒍𝒆
𝐿𝐹𝑁
_
𝑖𝑑
𝒅𝒐
6
𝐶
ℎ
𝑒𝑐𝑘
𝐿𝐹𝑁
_
𝑆𝑡𝑎𝑡𝑢𝑠
7
𝒘𝒉𝒊𝒍𝒆
𝐿𝐹𝑁
_
𝑆𝑡𝑎𝑡𝑢𝑠
=
𝑎𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒
𝑑𝑜
8
𝒊𝒇
min
_
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒
<
min
_
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒
(
𝐿𝐹𝑁
_
𝑖𝑑
)
𝒕𝒉𝒆𝒏
9
min
_
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒
=
min
_
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒
(
𝐿𝐹𝑁
_
𝑖𝑑
)
𝑁𝑒𝑎𝑟𝑒𝑠𝑡
_
𝐿𝐹𝑁
=
𝐿𝐹𝑁
_
𝑖𝑑
10
𝒆𝒏𝒅
11
𝒆𝒏𝒅
12
𝒊𝒇
min
_
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒
=
𝑥
𝒕𝒉𝒆𝒏
13
𝐺𝑒𝑛
𝑁𝑒𝑥𝑡
𝑁𝑒𝑎𝑟𝑒𝑠𝑡
𝐺𝑢𝑝
_
𝑖𝑑
14
𝑐𝑜𝑛𝑡𝑖𝑛𝑢𝑒
15
𝒆𝒍𝒔𝒆
16
𝑠𝑒𝑡
𝑐𝑜𝑚𝑚𝑢𝑛𝑖𝑐𝑎𝑡𝑖𝑜𝑛
_
𝑐
ℎ
𝑎𝑛𝑛𝑒𝑙
=
𝑁𝑒𝑎𝑟𝑒𝑠𝑡
_
𝐿𝐹𝑁
17
𝐶𝑜𝑚𝑚𝑢𝑛𝑖𝑐𝑎𝑡𝑒
(
𝐷𝑖𝑣
_
𝑖𝑛𝑓𝑜
)
𝑡𝑜
𝑁𝑒𝑎𝑟𝑒𝑠𝑡
_
𝐿𝐹𝑁
18
𝒆𝒏𝒅
19
𝒆𝒏𝒅
20
𝒆𝒍𝒔𝒆
21
𝒆𝒏𝒅
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 net-
work communication faster and also helps control traffic over the wireless sensor net-
work. Data filtering and preprocessing are managed by various local fog nodes. The de-
ployment 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.

Mathematics 2022,10, 2378 9 of 22
Mathematics 2022, 10, x FOR PEER REVIEW 8 of 25
new policies are also incorporated in the smart contracts only by the respective de-
partment. As for experimental work, the proposed study uses three different block-
chain(s); hence, concerning each blockchain, three different smart contracts are pro-
posed for this study.
8. 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 de-
partments’ IPFS(s) are connected for necessary information exchange or some collab-
orative analysis. IPFS allows decentralized access to information [29] if any Depart-
ment A needs the information about a specific transaction executed in another De-
partment 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 infor-
mation from Department C. This type of easy access of information makes the pro-
posed model more flexible and scalable. The example illustrated in this section is di-
agrammatically represented in Figure 6.
Figure 5. Communication through manageable hub (MH) and M:1:M (many-to-one-to-many rela-
tionship) between different architectural components.
Figure 5.
Communication through manageable hub (MH) and M:1:M (many-to-one-to-many rela-
tionship) between different architectural components.
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.
Mathematics 2022, 10, x FOR PEER REVIEW 10 of 25
Algori
thm 2:
Local Fog Node Data Filtering and Preprocessing
1
𝐷𝑖𝑣
_
𝑖𝑛𝑓𝑜
←
𝐷𝑒𝑣𝑖𝑐𝑒𝐼𝑛𝑓𝑜𝑟𝑚𝑎𝑡𝑖𝑜𝑛
2
𝒘𝒉𝒊𝒍𝒆
(
𝐷𝑖𝑣
_
𝑖𝑛𝑓𝑜
)
𝒅𝒐
3
𝐺𝑒𝑡
𝐷𝑖𝑣
_
𝑖𝑑
(
𝐷𝑖𝑣
_
𝑖𝑛𝑓𝑜
)
4
𝐺𝑒𝑡
𝐷𝑎𝑡𝑎
(
𝐷𝑖𝑣
_
𝑖𝑛𝑓𝑜
)
5
𝒊𝒇
𝐷𝑎𝑡𝑎
=
𝐹𝑎𝑙𝑠𝑖𝑓𝑦
_
𝐷𝑎𝑡𝑎
𝒕𝒉𝒆𝒏
6
𝐺𝑒𝑡
𝑁𝑒𝑥𝑡
𝐷𝑖𝑣
_
𝑖𝑛𝑓𝑜
7
𝑐𝑜𝑛𝑡𝑖𝑛𝑢𝑒
8
𝒆𝒍𝒔𝒆
9
𝑅𝑒𝑠𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒
𝐷𝑎𝑡𝑎
(
𝐷𝑖𝑣
_
𝑖𝑑
)
𝑎𝑠
𝑝𝑒𝑟
𝑠𝑝𝑒𝑐𝑖𝑓𝑖𝑒𝑑
𝑓𝑜𝑟𝑚𝑎𝑡
10
𝐶𝑜𝑚𝑚𝑢𝑛𝑖𝑐𝑎𝑡𝑒
𝑅𝑒𝑠𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒𝑑
𝑑𝑎𝑡𝑎
𝑡𝑜
𝐿𝑜𝑐𝑎𝑙
𝑇𝑟𝑢𝑠𝑡
𝑃𝑜𝑖𝑛𝑡
11
𝒆𝒏𝒅
12
𝒆𝒏𝒅
Figure 6. IPFS communication.

Mathematics 2022,10, 2378 10 of 22
Mathematics 2022, 10, x FOR PEER REVIEW 10 of 25
Algori
thm 2:
Local Fog Node Data Filtering and Preprocessing
1
𝐷𝑖𝑣
_
𝑖𝑛𝑓𝑜
←
𝐷𝑒𝑣𝑖𝑐𝑒𝐼𝑛𝑓𝑜𝑟𝑚𝑎𝑡𝑖𝑜𝑛
2
𝒘𝒉𝒊𝒍𝒆
(
𝐷𝑖𝑣
_
𝑖𝑛𝑓𝑜
)
𝒅𝒐
3
𝐺𝑒𝑡
𝐷𝑖𝑣
_
𝑖𝑑
(
𝐷𝑖𝑣
_
𝑖𝑛𝑓𝑜
)
4
𝐺𝑒𝑡
𝐷𝑎𝑡𝑎
(
𝐷𝑖𝑣
_
𝑖𝑛𝑓𝑜
)
5
𝒊𝒇
𝐷𝑎𝑡𝑎
=
𝐹𝑎𝑙𝑠𝑖𝑓𝑦
_
𝐷𝑎𝑡𝑎
𝒕𝒉𝒆𝒏
6
𝐺𝑒𝑡
𝑁𝑒𝑥𝑡
𝐷𝑖𝑣
_
𝑖𝑛𝑓𝑜
7
𝑐𝑜𝑛𝑡𝑖𝑛𝑢𝑒
8
𝒆𝒍𝒔𝒆
9
𝑅𝑒𝑠𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒
𝐷𝑎𝑡𝑎
(
𝐷𝑖𝑣
_
𝑖𝑑
)
𝑎𝑠
𝑝𝑒𝑟
𝑠𝑝𝑒𝑐𝑖𝑓𝑖𝑒𝑑
𝑓𝑜𝑟𝑚𝑎𝑡
10
𝐶𝑜𝑚𝑚𝑢𝑛𝑖𝑐𝑎𝑡𝑒
𝑅𝑒𝑠𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒𝑑
𝑑𝑎𝑡𝑎
𝑡𝑜
𝐿𝑜𝑐𝑎𝑙
𝑇𝑟𝑢𝑠𝑡
𝑃𝑜𝑖𝑛𝑡
11
𝒆𝒏𝒅
12
𝒆𝒏𝒅
Figure 6. IPFS communication.
Figure 6. IPFS communication.
Algorithm 3: Local Trust Point (LTP) User Authentication Process.
Mathematics 2022, 10, x FOR PEER REVIEW 11 of 25
Algorithm 3:
Local Trust Point (LTP) User Authentication Process
1
𝑅𝑒𝑞
_
𝑖𝑑
←
𝑅𝑒𝑞𝑢𝑒𝑠𝑡𝐼𝑑
,
𝑈𝑠𝑒𝑟
_
𝑆𝑡𝑎𝑡𝑢𝑠
←
𝑆𝑢𝑠𝑝𝑖𝑐𝑖𝑜𝑢𝑠
𝑈𝐷𝐷𝐵
←
𝑈𝑠𝑒𝑟
𝑜𝑟
𝐷𝑒𝑣𝑖𝑐𝑒𝐷𝑎𝑡𝑎𝑏𝑎𝑠𝑒
𝑃𝑃𝑇𝐿
←
𝑃𝑒𝑛𝑎𝑙𝑡𝑦
𝑃𝑜𝑖𝑛𝑡
𝑇
ℎ
𝑟𝑒𝑠
ℎ
𝑜𝑙𝑑
𝐿𝑖𝑚𝑖𝑡
2
𝒘𝒉𝒊𝒍𝒆
(
𝑅𝑒𝑞
_
𝑖𝑑
)
𝒅𝒐
3
𝐺𝑒𝑡
𝑈𝑠𝑒𝑟
_
𝑐𝑟𝑦𝑝𝑡𝑜
_
𝑖𝑑
(
𝑅𝑒𝑞
_
𝑖𝑑
)
4
𝐺𝑒𝑡
𝐷𝑒𝑣𝑖𝑐𝑒
_
𝑖𝑑
(
𝑅𝑒𝑞
_
𝑖𝑑
)
5
𝐺𝑒𝑡
𝑃𝑒𝑛𝑎𝑙𝑡𝑦
_
𝑃𝑜𝑖𝑛𝑡
(
𝑈𝑠𝑒𝑟
_
𝑐𝑟𝑦𝑝𝑡𝑜
_
𝑖𝑑
)
6
𝒊𝒇
𝑃𝑒𝑛𝑎𝑙𝑖𝑡𝑦
_
𝑃𝑜𝑖𝑛𝑡
≥
𝑃𝑃𝑇𝐿
𝒕𝒉𝒆𝒏
7
𝑈𝑝𝑑𝑎𝑡𝑒
𝑈𝑠𝑒𝑟
_
𝑆𝑡𝑎𝑡𝑢𝑠
=
𝑆𝑢𝑠𝑝𝑖𝑐𝑖𝑜𝑢𝑠
8
𝐴𝑙𝑙𝑜𝑐𝑎𝑡𝑒
𝑃𝑒𝑛𝑎𝑙𝑡𝑦
_
𝑃𝑜𝑖𝑛𝑡
(
𝑈𝑠𝑒𝑟
_
𝑐𝑟𝑦𝑝𝑡𝑜
_
𝑖𝑑
)
9
𝐷𝑒𝑛𝑦
𝐷𝑎𝑡𝑎
𝐴𝑐𝑐𝑒𝑠𝑠
10
𝒆𝒍𝒔𝒆
11
𝒊𝒇
𝑀𝑎𝑡𝑐
ℎ
𝑓𝑟𝑜𝑚
𝑈𝐷𝐷𝐵
(
𝑈𝑠𝑒𝑟
_
𝑐𝑟𝑦𝑝𝑡𝑜
_
𝑖𝑑
,
𝐷𝑒𝑣𝑖𝑐𝑒
_
𝑖𝑑
)
=
𝑇𝑟𝑢𝑒
𝒕𝒉𝒆𝒏
12
𝑈𝑝𝑑𝑎𝑡𝑒
𝑈𝑠𝑒𝑟
_
𝑆𝑡𝑎𝑡𝑢𝑠
=
𝐴𝑢𝑡
ℎ
𝑒𝑛𝑡𝑖𝑐
13
𝐴𝑙𝑙𝑜𝑐𝑎𝑡𝑒
𝑅𝑒𝑤𝑎𝑟𝑑
_
𝑃𝑜𝑖𝑛𝑡
(
𝑈𝑠𝑒𝑟
_
𝑐𝑟𝑦𝑝𝑡𝑜
_
𝑖𝑑
)
14
𝐴𝑙𝑙𝑜𝑤
𝐷𝑎𝑡𝑎
𝐴𝑐𝑐𝑒𝑠𝑠
15
𝐺𝑒𝑡
𝑁𝑒𝑥𝑡𝑅𝑒𝑞
_
𝑖𝑑
16
𝑐𝑜𝑛𝑡𝑖𝑛𝑢𝑒
17
𝒆𝒍𝒔𝒆
18
𝑈𝑝𝑑𝑎𝑡𝑒
𝑈𝑠𝑒𝑟
_
𝑆𝑡𝑎𝑡𝑢𝑠
=
𝑆𝑢𝑠𝑝𝑖𝑐𝑖𝑜𝑢𝑠
19
𝐴𝑙𝑙𝑜𝑐𝑎𝑡𝑒
𝑃𝑒𝑛𝑎𝑙𝑡𝑦
_
𝑃𝑜𝑖𝑛𝑡
(
𝑈𝑠𝑒𝑟
_
𝑐𝑟𝑦𝑝𝑡𝑜
_
𝑖𝑑
)
20
𝐷𝑒𝑛𝑦
𝐷𝑎𝑡𝑎
𝐴𝑐𝑐𝑒𝑠𝑠
21
𝒆𝒏𝒅
22
𝒆𝒏𝒅
23
𝒆𝒏𝒅

Mathematics 2022,10, 2378 11 of 22
Algorithm 4: Local Trust Point (LTP) User Classification Algorithm.
Mathematics 2022, 10, x FOR PEER REVIEW 12 of 25
Algorithm 4:
Local Trust Point (LTP) User Classification Algorithm
1
𝑅𝑒𝑞
_
𝑖𝑑
←
𝑅𝑒𝑞𝑢𝑒𝑠𝑡𝐼𝐷
,
𝐷𝐷𝐷𝐵
←
𝐷𝑒𝑝𝑎𝑟𝑡𝑚𝑒𝑛𝑡
𝑜𝑟
𝐷𝑒𝑣𝑖𝑐𝑒𝐷𝑎𝑡𝑎𝑏𝑎𝑠𝑒
,
𝑅𝑒𝑠
_
𝐷𝑎𝑡𝑎
←
𝑅𝑒𝑠𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒𝑑𝐷𝑎𝑡𝑎
,
𝐷𝑒𝑝𝑡
_
𝑐𝑟𝑦𝑝𝑡𝑜
_
𝑖𝑑
←
𝐷𝑒𝑝𝑎𝑟𝑡𝑚𝑒𝑛𝑡𝐶𝑟𝑦𝑝𝑡𝑜𝐼𝐷
2
𝐺𝑒𝑡
𝑈𝑠𝑒𝑟
_
𝑆𝑡𝑎𝑡𝑢𝑠
=
𝐶𝑎𝑙𝑙
𝐴𝑙𝑔𝑜𝑟𝑖𝑡
ℎ
𝑚
3
(
𝑅𝑒𝑞
_
𝑖𝑑
)
3
𝒊𝒇
𝑈𝑠𝑒𝑟
_
𝑆𝑡𝑎𝑡𝑢𝑠
=
𝑆𝑢𝑠𝑝𝑖𝑐𝑖𝑜𝑢𝑠
𝒕𝒉𝒆𝒏
4
𝐴
𝑐𝑐𝑒𝑠𝑠
𝐷𝑒𝑛𝑦
5
𝒆𝒍𝒔𝒆
6
𝐺𝑒𝑡
𝐷𝑖𝑣
_
𝑖𝑑
(
𝑅𝑒𝑞
_
𝑖𝑑
)
7
𝑈𝑠𝑒
𝐷𝐷𝐷𝐵
𝑎𝑛𝑑
𝐺𝑒𝑡
𝐷𝑒𝑝𝑡
_
𝑐𝑟𝑦𝑝𝑡𝑜
_
𝑖𝑑
(
𝐷𝑖𝑣
_
𝑖𝑑
)
8
𝐺𝑒𝑡
𝑅𝑒𝑠
_
𝐷𝑎𝑡𝑎
(
𝑅𝑒𝑞
_
𝑖𝑑
)
9
𝑈𝑝𝑑𝑎𝑡𝑒
𝑅𝑒𝑠
_
𝐷𝑎𝑡𝑎
=
𝑅𝑒𝑠
_
𝐷𝑎𝑡𝑎
+
𝐷𝑒𝑝𝑡
_
𝑖𝑑
10
𝐴𝑝𝑝𝑟𝑜𝑣𝑒
𝑇𝑟𝑢𝑠𝑡𝐶
ℎ
𝑎𝑖𝑛𝑆𝑡𝑜𝑟𝑎𝑔𝑒𝑃𝑒𝑟𝑚𝑖𝑠𝑠𝑖𝑜𝑛
(
𝑅𝑒𝑠
_
𝐷𝑎𝑡𝑎
)
11
𝑆𝑒𝑛𝑑
𝑅𝑒𝑞𝑢𝑒𝑠𝑡
𝑓𝑜𝑟
𝑆𝑚𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑎𝑐𝑡𝐴𝑢𝑡
ℎ
𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑖𝑜𝑛
(
𝐷𝑒𝑝𝑡
_
𝑐𝑟𝑦𝑝𝑡𝑜
_
𝑖𝑑
,
𝑅𝑒𝑠
_
𝐷𝑎𝑡𝑎
)
12
𝒆𝒏𝒅
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 man-
ageable hub query policies.
Mathematics 2022, 10, x FOR PEER REVIEW 12 of 25
Algorithm 4:
Local Trust Point (LTP) User Classification Algorithm
1
𝑅𝑒𝑞
_
𝑖𝑑
←
𝑅𝑒𝑞𝑢𝑒𝑠𝑡𝐼𝐷
,
𝐷𝐷𝐷𝐵
←
𝐷𝑒𝑝𝑎𝑟𝑡𝑚𝑒𝑛𝑡
𝑜𝑟
𝐷𝑒𝑣𝑖𝑐𝑒𝐷𝑎𝑡𝑎𝑏𝑎𝑠𝑒
,
𝑅𝑒𝑠
_
𝐷𝑎𝑡𝑎
←
𝑅𝑒𝑠𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒𝑑𝐷𝑎𝑡𝑎
,
𝐷𝑒𝑝𝑡
_
𝑐𝑟𝑦𝑝𝑡𝑜
_
𝑖𝑑
←
𝐷𝑒𝑝𝑎𝑟𝑡𝑚𝑒𝑛𝑡𝐶𝑟𝑦𝑝𝑡𝑜𝐼𝐷
2
𝐺𝑒𝑡
𝑈𝑠𝑒𝑟
_
𝑆𝑡𝑎𝑡𝑢𝑠
=
𝐶𝑎𝑙𝑙
𝐴𝑙𝑔𝑜𝑟𝑖𝑡
ℎ
𝑚
3
(
𝑅𝑒𝑞
_
𝑖𝑑
)
3
𝒊𝒇
𝑈𝑠𝑒𝑟
_
𝑆𝑡𝑎𝑡𝑢𝑠
=
𝑆𝑢𝑠𝑝𝑖𝑐𝑖𝑜𝑢𝑠
𝒕𝒉𝒆𝒏
4
𝐴
𝑐𝑐𝑒𝑠𝑠
𝐷𝑒𝑛𝑦
5
𝒆𝒍𝒔𝒆
6
𝐺𝑒𝑡
𝐷𝑖𝑣
_
𝑖𝑑
(
𝑅𝑒𝑞
_
𝑖𝑑
)
7
𝑈𝑠𝑒
𝐷𝐷𝐷𝐵
𝑎𝑛𝑑
𝐺𝑒𝑡
𝐷𝑒𝑝𝑡
_
𝑐𝑟𝑦𝑝𝑡𝑜
_
𝑖𝑑
(
𝐷𝑖𝑣
_
𝑖𝑑
)
8
𝐺𝑒𝑡
𝑅𝑒𝑠
_
𝐷𝑎𝑡𝑎
(
𝑅𝑒𝑞
_
𝑖𝑑
)
9
𝑈𝑝𝑑𝑎𝑡𝑒
𝑅𝑒𝑠
_
𝐷𝑎𝑡𝑎
=
𝑅𝑒𝑠
_
𝐷𝑎𝑡𝑎
+
𝐷𝑒𝑝𝑡
_
𝑖𝑑
10
𝐴𝑝𝑝𝑟𝑜𝑣𝑒
𝑇𝑟𝑢𝑠𝑡𝐶
ℎ
𝑎𝑖𝑛𝑆𝑡𝑜𝑟𝑎𝑔𝑒𝑃𝑒𝑟𝑚𝑖𝑠𝑠𝑖𝑜𝑛
(
𝑅𝑒𝑠
_
𝐷𝑎𝑡𝑎
)
11
𝑆𝑒𝑛𝑑
𝑅𝑒𝑞𝑢𝑒𝑠𝑡
𝑓𝑜𝑟
𝑆𝑚𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑎𝑐𝑡𝐴𝑢𝑡
ℎ
𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑖𝑜𝑛
(
𝐷𝑒𝑝𝑡
_
𝑐𝑟𝑦𝑝𝑡𝑜
_
𝑖𝑑
,
𝑅𝑒𝑠
_
𝐷𝑎𝑡𝑎
)
12
𝒆𝒏𝒅
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 man-
ageable hub query policies.
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.

Mathematics 2022,10, 2378 12 of 22
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 pro-
posed 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
PEi→i0
r
. This policy is defined as the policy used by
device i to device i0over the resource r. Mathematically, these sets are defined as:
E={E(m)1,E(m)2,E(m)3,E(m)4, . . . . . . . . . , E(m)α}(1)
where αis total no. of managers for electricity department
D={D(i)1,D(i)2,D(i)3,D(i)4, . . . . . . . . . , D(i)k}(2)
where kis total no. of devices for all the departments
PE =nPEi→i0
r
1,PEi→i0
r
2,PEi→i0
r
3,PEi→i0
r
4, . . . . . . . . . , PEi→i0
r
ϑo(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:
∗Department’s new manager registration (Em);E0←E∪ED∀devices (D)and ∀policies (PE)
∗New device registration (Em,Di);D0←D∪Di∀managers (E)and ∀plicies (PEi)where (PEi)is the allowed policies
for device i ∈PE,Return the touple (Di,De pt_crypto_id)to LTP
∗Add new policy (PEϑ+1,Di);PEj→j0
r←PEj→j0
r
δ∪PE ∀devices (Dl)where (Dl)is the set of associate devices l ∈D,
Return the touple PEϑ+1,Dj,De pt_crypto_idto LTP
∗Remove registered manager (Em);E0←E∩ED∀devices (D)and ∀policies (PE)
∗Remove registered device (Em,Di);D0←D∩Di∀managers (E)and ∀plicies (PEi)
where (PEi)is the all owed pol icies f or device i ∈PE,Return the tou pl e (Di,De pt_crypto_id)to LTP
∗Remove existing policy (PEϑ−1,Di);PEj→j0
r←PEj→j0
r
ϑ∩PE ∀devices (Dl)where (Dl)is the set of associate devices
l∈D,Return the touple PEϑ−1,Dj,De pt_crypto_idto LTP
∗Access request (Di,r);Return the touple (Di,s)
where {s∃set o f ser vices ∀resource (r)}
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

Mathematics 2022,10, 2378 13 of 22
devices (i), PW is defined as the set of policies used to access resource r with device i;
mathematically it is indicated as
PWi→i0
r
. This policy is defined as the policy used by
device i to device i0over the resource r. Mathematically, these sets are defined as:
W=W(m)1,W(m)2,W(m)3,W(m)4, . . . . . . . . . , W(m)β(4)
where βis total no. of managers for electricity department
PW =nPWi→i0
r
1,PWi→i0
r
2,PWi→i0
r
3,PWi→i0
r
4, . . . . . . . . . , PWi→i0
r
δo(5)
where δis the total no. of policies defined under electricity department.
Dis already defined under Equation (2)
The various operations defined under the W-BC smart contract are listed below:
∗Department’s new manager registration (Wm);W0←W∪WD∀devices (D)and ∀policies (PW )
∗New device registration (Wm,Di);D0←D∪Di∀managers (W)and ∀plicies (PWi)where (PWi)is the allowed policies
f or devic e i ∈PW,Return the touple (Di,Dept_crypto_id )to LTP
∗Add new policy PWδ+1,Dj;PWj→j0
r←PWj→j0
r
δ∪PW ∀devices (Dl)
where (Dl)is the set o f associate devices l ∈D,Return the tou ple PWδ+1,Dj,Dept_crypto_id to LTP
∗Remove registered manager (Wm);W0←W∩WD∀devices (D)and ∀policies (PW )
∗Remove registered device (Wm,Di);D0←D∩Di∀managers (W)and ∀plicies (PWi)
where (PWi)is the all owed po licie s f o r device i ∈PW,Return the tou ple (Di,Dept_crypto_id )to LTP
∗Remove existing policy PWδ−1,Dj;PWj→j0
r←PWj→j0
r
δ∩PW ∀devices (Dl)
where (Dl)is the set o f associate devices l ∈D,Return the tou ple PWδ−1,Dj,Dept_crypto_id to LTP
∗Access request (Di,r);Return the touple (Di,s)
where {s∃set o f services ∀resource (r)}
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
PHi→i0
r
. This policy is defined as the policy used by
device i to device i0over the resource r. Mathematically, these sets are defined as:
H={H(m)1,H(m)2,H(m)3,H(m)4, . . . . . . . . . , H(m)γ}(6)
where γis total no. of managers for electricity department
PH =nPHi→i0
r
1,PHi→i0
r
2,PHi→i0
r
3,PHi→i0
r
4, . . . . . . . . . , PHi→i0
r
µo(7)
where µis the total no. of policies defined under the electricity department.
Dis already defined under Equation (2)
The various operations defined under the HC-BC smart contract are listed below:
∗Department’s new manager registration (Hm);H0←H∪HD∀devices (D)and ∀policies (PH)
∗New device registration (Hm,Di);D0←D∪Di∀managers (H)

Mathematics 2022,10, 2378 14 of 22
and ∀plicies (PHi)
where (PHi)is the all owed po licie s f o r device i ∈P H,Return the touple (Di,Dept_crypto_id )to LTP
∗Add new policy PHµ+1,Dj;PHj→j0
r←PHj→j0
r
µ∪PH ∀devices (Dl)where (Dl)is the set of associate devices l ∈D,
Return the touple PHµ+1,Dj,Dept_cry pto_idto LTP
∗Remove registered manager (Hm);H0←H∩HD∀devices (H)and ∀policies (PH)
∗Remove registered device (Hm,Di);D0←D∩Di∀managers (H)and ∀plicies (PHi)
where (PHi)is the a llowed pol icies f or de vice i ∈PH,Return the tou ple (Di,Dept_crypto_id )to LTP
∗Remove existing policy PHµ−1,Dj;PHj→j0
r←PHj→j0
r
µ∩PH ∀devices (Dl)where (Dl)is the set of associate devices
l∈D,Return the touple PHµ−1,Dj,Dept_cry pto_idto LTP
∗Access request (Di,r);Return the touple (Di,s)
where {s∃set o f services ∀resource (r)}
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 −Pu→ir
.
Dept-crypto-id is defined as the set of department crypto ID(s). Mathematically, these sets
are defined as:
D_cry pto_id ={D_crypto_id(c)1,D_crypto_id(c)2, . . . . . . . . . , D_crypto_id(c)k}(8)
where ∀divice D ∃a unique D_crypto_id
U_cry pto_id ={U_crypto_id(u)1,U_crypto_id(u)2, . . . . . . . . . , U_cry pto_id(u)ω}(9)
Access_P=nAccess_Pu1→ir
1,Access_Pu2→ir
2, . . . . . . . . . , Access_Puω→ir
ωo(10)
where
Access_Puω→ir
ω
is a set of access permissions for user
ω
to access resource rwith
device i.
Dept_crypto_id ={Dept_crypto_id(d)1,Dept_crypto_id(d)2, . . . . . . . . . , Dept_crypto_id(d)ρ}(11)
The access permissions and authentication managed by LTP under the removable
trust chain (RTC) are listed below:
∗New device registration (Di,De pt_crypto_id(d));D0←D∪Di∃Dept_cry pto_id(c)and ∃AccessP(P),
Return the touple (Di,Dept_crypto_id(d),Dept_crypto_id(c),AccessP(P))
to DD_DB,where DD_DB is de partment,device database.
∗Add new policy Pµ+1,Dj,Dept_crypto_id;Pj→j0
r←Pj→j0
r
µ∪P∀devices (Dl)∃Dept_crypto_id where (Dl)is the
set o f associate devices,l∈D
∗Remove registered device (D