© 2020 IEEE. Personal use of this material is permitted.

Permission from IEEE must be obtained for all other uses, in any current or future media, including
reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or1lists, or reuse
of any copyrighted component of this work in other works.

Blockchain at the Edge: Performance of

Resource-Constrained IoT Networks
Sudip Misra, Senior Member, IEEE, Anandarup Mukherjee, Student Member, IEEE, Arijit
Roy, Student Member, IEEE, Nishant Saurabh, Yogachandran Rahulamathavan, and
Muttukrishnan Rajarajan, Senior Member, IEEE

y
nl
Abstract—The proliferation of IoT in various technological challenges of connectivity, address reuse, energy

O
realms has resulted in the massive spurt of unsecured data. The efficiency, and mobility. Typically, due to the chal-
use of complex security mechanisms for securing these data is lenging issues of massive deployments, the pres-
highly restricted owing to the low-power and low-resource nature ence of constrained networks, and often charac-

se
of most of the IoT devices, especially at the Edge. In this work, teristically constrained nature, IoT devices them-
we propose to use blockchains for extending security to such
selves, the ensuing IoT ecosystem has inherent
IoT implementations. We deploy a private Ethereum blockchain
consisting of both regular and constrained devices connecting
vulnerabilities. A majority of the present-day IoT
lU solutions are plagued by vulnerabilities, which are
to the blockchain through wired and wireless heterogeneous
networks. We additionally implement a secure and encrypted challenging and which make them prone to easy
networked clock mechanism to synchronize the non-real-time manipulation and disruption. Some of the common
vulnerabilities are weak or hardcoded passwords,
na

IoT Edge nodes within the blockchain. Further, we experimen-

tally study the feasibility of such a deployment and the bottle- insecure network segments, poorly protected inter-
necks associated with it. We study the effects of network latency, faces and data access mechanisms, insecure data
increase in constrained blockchain nodes, data size, Ether, and transfer mechanisms, and others. Furthermore, the
so

blockchain node mobility during transaction and mining of data massive deployments of IoT devices often make it
within our deployed blockchain. This study serves as a guideline
impossible for a network administrator to track-
for designing secured solutions for IoT implementations under
down malicious or compromised devices amongst
er

various operating conditions such as those encountered for

static IoT nodes and mobile IoT devices.
the deployed devices.
The issue of designing practical solutions for
rP

Index Terms—Internet of Things, blockchain, Edge nodes, securing IoT data, especially in terms of speed-
Ethereum, Constrained-networks

1 I NTRODUCTION
Fo

The major challenge associated with IoT-based sys-

tems is the issue of ensuring the security of data
being handled by such systems, besides the regular
S. Misra and A. Mukherjee are with the Department of Computer
Science and Engineering at Indian Institute of Technology Kharagpur,
India
A. Roy is with the Advanced technology Development Center at
Indian Institute of Technology Kharagpur, India
N. Saurabh is with the Department of Electronics and Communica-
tion Engineering at National Institute of Technology Patna, India
Y. Rahulamathavan is with the Institute for Digital Technologies,
Loughborough University London, UK
M. Rajarajan is with the Information Security Group, School of Fig. 1: An outline of a typical IoT-based Industrial
Engineering and Mathematical Sciences, City University London,
London, UK ecosystem.
 2

ily ensuring trust, integrity, and non-repudiation, also perform necessary blockchain functions such as
hinges on the nature of the devices, its energy verification, mining, and transactions. In this work,
efficiency, and mobility associated with it. The na- we deploy a private Ethereum blockchain consisting
ture of the devices in IoT, especially at the Edge of IoT Edge devices as its nodes and experimentally
is vastly heterogeneous. As the Edge IoT devices verify the performance of this approach to usher-
mainly focus on ensuring low-power connectivity in a low-power and mobile blockchain-based IoT
and basic computation, a significant chunk of these ecosystem. Architecting a blockchain-based solu-
Edge devices making up this paradigm does not tion for IoT systems at the Edge requires addressing
possess sufficient processing power or resources the following challenges:
to host conventional network security mechanisms.
• More the number of Edge devices in the
Typically, IoT Gateways are popularly associated
IoT ecosystem that is part of the blockchain,
with providing security to the IoT devices/nodes
more is the work-load of each of these
under its operational purview. The current state-
blockchain nodes. The generally constrained
of-the-art IoT infrastructure relies on a centralized

y
nature of the network associated with the IoT
Gateway to process and aggregate data from IoT
systems/devices further makes it challeng-

nl
devices [1]. The centralized Gateway plays a vital
ing for the devices to partake in network-
role in ensuring the security of the sensed data.
based blockchain operations reliably.

O
However, the next generation of mobile com-
• Blockchains require real-time synchroniza-
munication technology is enabling device-to-device
tion between its nodes. Most of the con-
communication where billions of IoT devices are
strained IoT Edge devices do not have an

se
expected to exchange sensed data with each other
internal clock for time synchronization, mak-
in cities, industries, homes, and other ecosystems.
ing it necessary to come up with solutions to
These devices not only sense and transmit data but
address this lacuna.
also perform actuation based on the data received
lU
• The resource-constrained nature of most of
from other IoT devices. This trend clearly shows
the Edge IoT devices require mechanisms to
that the existing centralized approach cannot be
handle processing-heavy blockchain-based
scalable and will soon become a bottleneck. There-
na

operations.
fore it is inevitable to use distributed technologies
to replace the role of the Gateway as this approach
often leaves the IoT nodes under the domain of 1.1 An IoT-based Industrial Ecosystem Applica-
so

a Gateway, quite open to security breaches such tion Scenario

as unauthorized access to data directly from the We envision a real-life use case of an IoT-based in-
Edge devices. Additionally, the dilution of hard dustrial ecosystem for motivating the applicability
er

requirements for devices to be static or mobile in of this work. Fig. 1 shows the significant physi-
an IoT ecosystem, further complicates issues as cal and infrastructural components of an industrial
rP

customized solutions for one cannot be used for the complex. We choose an industrial complex primar-
other. Rather than focusing on traditional security ily because of the massive density of deployed Edge
solutions, which rely majorly on remotely hosted devices, and the constrained nature of the network
security mechanisms such as at Cloud or cen- arising due to the high density of these devices
Fo

tralized Gateways, the requirements of IoT-based and challenging areas of implementation – prone
systems necessitate distributed solutions [2]. These to interference and noise from the environment.
distributed solutions primarily focus on the IoT Furthermore, industrial complexes are an excellent
devices at the Edge [3] or even utilize hardware- example of the use of heterogeneous networks,
based security [4]. which take care of functions starting from process
Towards this objective, we analyze the perfor- monitoring, security, tracking, logistics, to even reg-
mance and feasibility of using blockchains – a ular communication with the outside world.
promising distributed security paradigm for en- The networks on the factory floors are typi-
suring data security for IoT-based systems [5]. To cally wired and resource-constrained. Constraints
secure the data generated and exchanged between to network and device capabilities are automatically
IoT devices in a distributed manner, we propose the induced in such ecosystems due to the presence of
use of low-power IoT Edge nodes as the blockchain dedicated automation and control systems working
nodes. These nodes are not only capable of contin- with new as well as legacy infrastructures. It is
uing their regular sensing and actuation tasks, but common to see both wireless and many variants
 3

of wired connections for communication in indus- incorporate network heterogeneity in our imple-
trial ecosystems. In continuation, the heterogeneity mentation by making use of both fixed Ethernet-
in devices in terms of their mobility, processing based network connections as well as including
abilities, and energy consumption also makes it a WiFi-based connections. The inclusion of network
challenging environment for implementing secure heterogeneity allows us to include the feature of
IoT systems. mobility in some of the IoT Edge nodes, while the
The amounts of data generated and flowing rest of the nodes in the blockchain remain static.
through the network in an IoT-enabled industrial The static nodes are connected to an Ethernet-based
ecosystem are quite massive. However, most of the network, whereas the mobile nodes connect to the
data and systems – typically Edge devices – are blockchain through WiFi, as outlined in Fig. 2. We
insecure and open to unauthorized access and ma- undertook this work to fill in this gap by evaluating
nipulation. Here, we envision the use of blockchain the various interactions of constrained IoT devices
to provide a layer of security to the connection and with blockchain networks, even when they have
communication between all the devices within an heterogeneity in their connection and/or are mo-

y
industrial setting. The use of blockchain introduces bile. Besides, typical device and blockchain perfor-

nl
the features of transparency and traceability to the mance measures, we also evaluate the performance
IoT data generated within the industrial ecosystem. of various encryption algorithms such as the RSA
Additionally, the distributed nature of Blockchains

O
and 256-bit AES along with the blockchain to secure
prevents single-point-of-failures for the whole net- our implemented IoT network further.
work under severe working conditions, typically

se
associated with industries. Both constrained IoT 1.3 Related Work
Edge nodes, as well as regular computing stations,
There have been several efforts in the past to use
can be incorporated within this setting. In our ex-
blockchain with IoT devices. Wu et al. demon-
perimental evaluation, we fashion the blockchain
lU
strate a system comprising of private and public
nodes as such that they consist of both regular com-
blockchain for secure and efficient storage of data
puting platforms such as PCs as well as constrained
[6]. The private blockchain ensures the accuracy of a
IoT Edge nodes consisting of Raspberry Pi boards
na

transaction, whereas the public blockchain ensures

(refer to Table 1). In such scenarios, our proposed
its data integrity. Similarly, Wu et al. propose the
evaluation provides critical insights into the chal-
inclusion of an additional device to check for certain
lenges and limitations of deploying a decentralized
so

characteristic features in the received messages [7].

blockchain-based provision of security for the IoT-
The results of the verification are saved on the
based systems and devices.
blockchain, which ensures that even in the case of
loss of key to unscrupulous entities, the unautho-
er

1.2 Contributions rized hijacking of IoT devices is prevented.

The constrained nature of the devices at the Edge
rP

is the main reason for the lack of decisive security TABLE 1: blockchain node specifications for our
schemes and measures for protecting communica- implementation
tion integrity at the Edge or within the operational
Features Node-1 Node-2 Node-3 Node-4
range of IoT gateways. The nature of the data plays
Fo

Device Raspberry Raspberry Dell Raspberry

a decisive role in evaluating the requirements of se- Pi3-B+ Pi3-B+ Power Pi3-B+
curity and privacy to be used at the IoT devices. For Edge
example, the requirements of security and privacy T410
server
are very high for healthcare IoT data. In contrast, the
Processor Quad Quad 16x4 Quad
requirements are moderate to low for data originat- Core 64 Core 64 Core 64 Core 64
ing from general sources, say, agriculture or traffic. bit ARM bit ARM bit at bit ARM
However, the integrity of data is an irrefutable need cortex at cortex at 2.67 GHz cortex at
1.2 GHz 1.2 GHz 1.2 GHz
for all IoT data types and needs, which is ensured
RAM 1 GB 1 GB 32 GB 1 GB
by the private blockchain. Network Ethernet Ethernet Ethernet WiFi
In this work, we incorporate the heterogene- connection
ity of IoT devices by including both small nodes
– constrained, with fewer resources and process- Dorri et al. demonstrate the efficient use of
ing power – and large nodes – nodes with abun- Blockchains in IoT systems by replacing the proof-
dant resources and processing power. Further, we of-work (POW) by a distributed trust algorithm
 4

[8]. This effort has resulted in substantial energy

savings during the process of mining within the
blockchain. Another work, by Fan et al. proposes
the use of a delegated proof-of-stake (DPOS) instead
of POW to ensure adequate provision of privacy
in Blockchains [9]. Other approaches use proof-of-
authority (POA) such as the one demonstrated by
Angelis et al. [10]. Similarly, the extra use of smart
contracts in large IoT Blockchains requiring time
synchronization has been proposed by Huh et al.
[11], whereas Cha et al. demonstrate the use of smart
contracts with blockchain hosted in an IoT Gateway
for enabling IoT Blockchains [12]. Rahulamathavan Fig. 2: The representative network architecture of
et al. proposed an advanced encryption technique

y
our implemented IoT blockchain.
for IoT networks to enable fine-grained access and

nl
verification necessary for ensuring privacy in the
blockchain [13]. 2.1 Incorporating blockchain for IoT

O
Blockchains have found beneficial use in sev-
eral application areas such as smart cities [14], Fig. 2 outlines the representative network architec-
healthcare [15], crowd-sourcing [16], and others. ture of our implemented IoT blockchain. The net-
work can be considered to consist of heterogeneous

se
Blockchain-based solutions to extremely critical
domains such as healthcare are making use of nodes (N1-N4). These nodes may consist of large
Blockchains to store patient’s data securely and pri- static devices such as servers and PCs, or they
may be small and portable consisting of Raspberry
vately [17], and through smart contracts, the need
lU
for seeing the data is also done away with [15]. Pi boards. All these devices act as nodes in the
blockchain. A switch connects an external backbone
network to the internally formed network. The net-
na

work connections from the switch may be either

2 S YSTEM M ODEL used for connecting physically to the IoT nodes
In this work, we implement an Ethereum-based through Ethernet or wirelessly through a wireless
so

blockchain on heterogeneous IoT nodes, some of access point. An external encrypted time server is
which connect to the blockchain over an Ethernet- also used to provide network time synchronization
based connection, whereas the others connect to the IoT devices, which are mostly non-real-time.
er

through a WiFi-based connection, forming a hybrid

TABLE 2: Specifications of our private blockchain
network connection as shown in Fig. 2. Further,
rP

adding to the device heterogeneity, the devices blockchain specifications Values

themselves have different specifications and pro- Gas limit (in Hexadecimal) 0x47b760
cessing capabilities, as outlined in Table 1. Gas limit (in Decimal) 0x4700000
Difficulty 0x1
IoT nodes have unique “ENODE” values and
Fo

Consensus Engine used Clique - proof of authority

connect using these values. The “ENODE” value Time (in sec) each block takes 5 seconds
consists of a public key, an IPv4 address, and a Number of accounts on each 1
port number. Simulating a real-life IoT implemen- node
Accounts which are allowed Accounts of all the nodes
tation, we have incorporated heterogeneous IoT to seal
nodes, some with low processing power and re- HomesteadBlock 1
duced energy requirements (i.e., Raspberry Pi) and EIP150 Block 2
some with high processing power and more sig- EIP155 Block 3
EIP158 Block 3
nificant energy requirements (i.e., server, PC). The Gasprice for node 1 3 × 1055 wei
Raspberry Pi-based nodes connecting over WiFi are Gasprice for nodes 2, 3, 4 3 × 1028 wei
considered as mobile and treated as such during Syncmode full
the performance evaluation of our setup. However,
these IoT nodes in our blockchain are capable of We implement a private blockchain to account
independently handling their transactions as well for the low-processing capabilities of the imple-
as mining. mented IoT nodes, as well as keeping the data and
 5

transactions localized within an application area. 2.2 Encrypted Time Synchronization

Each of these nodes runs an Ethereum framework, A significant part of our private blockchain con-
the specifications of which are outlined in Table sists of non-real-time systems such as Raspberry
2. Each of these nodes has an account associated Pi, which necessitates the need for a centralized
with it over the Ethereum framework and uses a time synchronization mechanism. Operations such
“CLIQUE- Proof of Authority (PoA)”, instead of as mining rely heavily on the synchronization of
regular “ETHASH- Proof of Work (PoW)” to re- time and its maintenance between the nodes of
duce mining times and reduce the average energy the blockchain. Our implementation requires the
consumed by the nodes. The transaction of Ethers communication of an encrypted time string to a
and data are performed based on the “ENODE” node joining the blockchain for the first time or
values of each node, which are subsequently mined every time it is powered on. This provision has
by intended nodes. Post successful completion of been kept mainly because of the absence of Real-
a transaction, Ether balance is updated to a receiver Time Clocks (RTC) in the resource-constrained IoT
node’s account by the same amount it gets deducted

y
devices. Every time these devices power-up, the
from the sender’s account. The Ether balance with internal clock resets to the default value, which is

nl
the sender node was initially logged at 7.519 wei, unlike personal computers or machines with RTCs.
the whole of which gets transferred to the receiver Further, unless the sender and receiver nodes have a

O
upon completion of a transaction. Unlike public common system time, network security provisions
blockchains, which deal with unknown and trust- prevent them from communicating reliably, espe-
less systems, the private blockchains do not need cially for blockchains.

se
an incentive-based mechanism to work. Additionally, any external efforts to include a
We automate the process of an IoT node joining network-based time synchronization should be se-
the blockchain, generating data, and performing cure enough to ensure long-lasting and interference-
transaction and mining operations. Algorithm 1
lU free membership of the IoT nodes to the blockchain.
highlights this automation process. On power-up, In case the time server or any message generated
each IoT node boots into a startup file containing from it is compromised or altered, the IoT nodes
the multi-threaded instructions and commands for forming the blockchain will get dissociated, result-
na

time synchronization using the encrypted network- ing in the breakdown of the blockchain. To avoid
broadcasted time string and initialization of the any such eventuality, we additionally implement
node’s Genesis file. Subsequently, each of the ac- the use of an encrypted time string from a cen-
so

tivated nodes checks for transaction data (to send tralized time server (refer Fig. 2), which can be
or receive), which is then mined and submitted read only by the member nodes of the implemented
accordingly. Blockchain contracts can also be de- blockchain as outlined in Algorithm 2. The time
er

ployed similarly. Irrespective of a node’s processing server has a record of all the member nodes of
capabilities, the nodes are self-sufficient to carry the blockchain along with their “ENODE” values.
out mining operations on their own. It is prudent
rP

The IP of each node corresponding to its “ENODE”

to mention that in the absence of proper time value gets periodically updated at this time server.
synchronization, the connection between nodes is For our encryption, we adopt a different node –
interrupted, resulting in association and disassoci- different encryption policy [13], which adds an ad-
Fo

ation with the blockchain. This drop in connection ditional level of security to our IoT blockchain. The
results in a significant increase in mining times at synchronizing encrypted time string is customized
the affected nodes. according to each of the registered member nodes,
which can only be decrypted by the target IoT node
Algorithm 1 Node automation
using its “ENODE” value as the private key. Any
while DEVICE POWER ON do attempts to falsify or manipulate the IP address of
Locate node blockchain automation file the node or the ENODE address will result in a clash
Initialize Genesis file in the records at the server, alerting the network ad-
Start mining ministrator of this attempt. As the server broadcasts
if (Transaction Data == TRUE) then the time strings over the blockchain network, all
Submit the transaction and generate receipt the nodes can see the encrypted message, but only
end if the designated node with the proper “ENODE”
end while value can decrypt it. The mapping of IP addresses
and ENODE values also prevents the duplication of
 6

ENODE values by malicious nodes. Further, the en- time synchronizing signals avoids both of the above
crypted time string meant for a node will be relayed scenarios.
multiple times, similar to a typical networking sce- Further, now, if someone outside our blockchain
nario, if the time server is not directly connected to tries to receive the encrypted string and try to
the target node. extract the information out of the encrypted string,
our algorithm has ensured that even if they receive
Algorithm 2 Time Synchronization the encrypted string by forcefully setting their IP
same as that of the IP of the true node of our
SERVER blockchain, it can receive the encrypted string but
n ← number of nodes not been able to decrypt it.
message ← time string Concerning a Man-in-the-Middle Attack for
Replicate EN ODE and IP of all the nodes in the modifying the time, the encrypted time server (refer
time server Fig. 2) is tasked with periodically updating the map-
for i = 1 to n do ping of ENODE and IP addresses of the participants

y
IP [i] ← IP of ith node in the private blockchain. As the ENODE values
end for

nl
are unique to each blockchain node, these ENODE
for i = 1 to n do values can be uniquely mapped to the nodes’ IP
key[i] ← EN ODE addresses. Even if there is a change in the node’s

O
Encrypt time string using EN ODE → IP address, the periodic check by the time server
EN ODE(message)[i] ensures its update in the mapping repository. Once
for all i do

se
a node with the proper IP address receives the en-
send IP [i] ← EN ODE(message)[i] crypted time string meant for it, only it can decode
end for it using its unique ENODE value. The mapping of
end for
lU IP addresses and ENODE values also prevents the
RECEIVER (intended node) duplication of ENODE values by malicious nodes.
T IM E ← original time of the node In the event of a faulty time server sending
During node startup DO different timestamps to different nodes, there can
na

Copy EN ODE → file.txt be two cases – 1) all nodes will receive different
Receive encrypted time Tep timestamps, 2) some targeted nodes will keep on
Auto decrypt using EN ODE of the node Tdp receiving faulty time stamps. In the first case, if all
so

Set T IM E = Tdp the nodes in the blockchain receive different times-

tamps, which are not similar to each other, the nodes
This mechanism additionally implies that the will not be able to join the blockchain. This will be
er

nodes in the blockchain do not need to depend easily flagged as an error to the network administra-
on each other for maintaining trust, which is quite tor. Further, in the second case, if some of the nodes
are sent different times in the blockchain, they will
rP

useful as the nodes (IoT nodes) are typically low-

resource ones and are susceptible to hijacking or not be able to take part in the blockchain, which
alterations. In the event one of the nodes in our will again be flagged as an error to the network
blockchain is somehow compromised, its effect administrator. Although, our implementation of the
Fo

would not flow over to the other nodes of the time server may seem like a good candidate for
blockchain. Elaborating this scenario, consider all the Byzantine failure, but the problem mentioned
IoT nodes in the blockchain network receive a com- above (if occurring) can be easily localized during
mon encrypted/open time synchronization signal. the initial phase itself.
If the synchronization signal is open, it is effortless
to modify it and take down the blockchain, poten- 3 P ERFORMANCE E VALUATION
tially resulting in severe economic and operational In this work, we establish a private Ethereum
losses. Similarly, if the same encrypted time signal blockchain with four nodes, following the archi-
is used for all the nodes in the blockchain, and in tecture outlined in Fig. 2, the exact specifications
the event that one of the nodes is compromised, of which are briefly outlined in Table 1. Two of
the infected node might be used to forward wrong these nodes (nodes 1 and 2 in Table 1) are non-
time signals to the nodes in the blockchain, again real time, static systems with constrained processing
interrupting its operation. Therefore, our approach power and energy, and which join the blockchain
of using a node-specific encryption key for sending network through the Ethernet. The third node (node
 7

(a) Average network latencies (b) Average CPU usage vs. num- (c) CPU usage before mining (d) CPU usage during min-
across nodes ber of connecting nodes ing

Fig. 3: Network and node performance characteristics for our implemented IoT blockchain.

y
3) has significant processing resources and does resource-constrained nodes (Nodes- 1 and 2), even
not have any energy constraints as it draws power when connected over the same Ethernet-based con-

nl
directly from the grid. This node also takes part in nection. These relatively higher latencies incurred
the blockchain through a dedicated Ethernet-based due to the resource-constrained nodes (Nodes-1 and

O
connection and is deemed a static node. Finally, 2) is attributed to the time taken by them to process
the last node is yet another non-real-time, resource, the packets. In continuation, the significantly higher
and energy-constrained node similar to nodes 1 latencies at Node-4 can be attributed both to its

se
and 2, but takes part in the blockchain through a resource-constrained nature, requiring more time to
wireless connection (WiFi) as it is mainly mobile. process the packets, as well as its mobility, which
It is to be noted that both the Ethernet and WiFi- causes it to have unstable network characteristics.
based networks are not established dedicatedly for
lU These latencies are crucial in estimating the perfor-
this evaluation, but are part of a single institutional mance of our implemented IoT blockchain and act
network over which a significant number of users as the network performance baseline.
na

communicate simultaneously at any time of the day.

To establish the quality of the network, we es- 3.2 Effect of Increase of Node on CPU Usage
timate the latencies encountered by each of these Fig. 3(b) shows the average CPU usage (denoted in
different nodes connecting to the network through
so

%) for a randomly selected constrained node in our

heterogeneous means. We observe an average la- blockchain network. We observe that as the number
tency of 0.4 ms to 0.7 ms on each of the nodes 1, of network connections to that node increases, the
2, and 4 while they receive information/ connec- nodes’ average CPU usage goes up to maintain the
er

tion requests from other nodes. However, node 3 connections to and from it. An important takeaway
connecting to the network through a WiFi-based from this observation is that resource-constrained
rP

connection encountered average latencies of around nodes support only a limited number of simulta-
13 ms to 50 ms when receiving messages from the neous network connections, which necessitates the
other nodes. Similarly, nodes 1, 2, and 4 observe use of distributed security solutions for reliable use
average network latencies of up to 24ms to 33ms, of such nodes.
Fo

when receiving messages from node 3. Further, Fig. 3(c) represents the CPU usage at
each of the four implemented nodes before joining
the blockchain, whereas Fig. 3(d) represents the
3.1 Effect of Network Latency
CPU usage in the same nodes during mining in
Considering the network architecture discussed the blockchain. From Figs. 3(c) and 3(d), we observe
previously, Fig. 3(a) shows the comparison between that the three constrained nodes (Raspberry Pi) in-
network latencies while sending ping packets from cur almost 5-8 times the CPU usage as compared to
each node to every other node (designated as Tar- the regular node (server). Additionally, the mobile
gets 1 -3) in the network. We observe that for ping constrained node (connected to the WiFi), incurs
queries over the Ethernet-connected nodes, the re- further resource usage (CPU usage) as compared to
sponse time is significantly lower than that of the the constrained nodes connected to the Ethernet.
one connected over WiFi. Additionally, we observe We further observe that being part of the
that the response time for ping from Node-3 (server) blockchain and performing its operations induces
is relatively lower than the responses from the a massive increase in CPU usage of the devices by
 8

(a) Average mining time (b) Average transaction time (a) Average mining time (b) Average transaction time

Fig. 4: Variation in blockchain performance with the Fig. 5: Variation in blockchain performance with the
variation in data size. amount of Ethers transferred.

almost 10 times as compared to when the devices which we again attribute to fluctuating network

y
are operating on their own (refer Figs. 3(c) and conditions. As the plot in Fig. 4(b) shows the aver-
3(d)). For resource-constrained nodes, the percent- age behavior, considerable fluctuations in network

nl
age CPU usage is about 5 to 7 times more as conditions tend to disturb the norm, which for most
compared to that for the node with ample stor- of the cases, is reasonably consistent.

O
age and high processing power. As in our imple-
mented blockchain, nodes 1, 2 and 4 are resource- 3.4 Effect of Ether
constrained, we observe their average CPU usage to Fig. 5 shows the effect of Ethers on the IoT

se
be around 31.686%, 35.323%, 43.704% respectively, blockchain operations of our implemented system
while node 3 which is a server accounts for about from the perspective of the static nodes transacting
6.536% of CPU usage during blockchain mining a data of 100 bytes over the blockchain. Fig. 5(a)
lU
operations. shows the variation in mining time on varying
the number of Ethers transacted while keeping the
3.3 Effect of Data Size data size fixed to 10 bytes, between pre-determined
na

senders and receivers. We transact 1 wei, 105 wei,

Fig. 4 shows the effect of data size on the IoT
and 1010 wei in our blockchain for over 30 times in
blockchain operations of our implemented system
each case. We observe that the variations in mining
from the perspective of the static nodes. Fig.4(a)
so

time remain almost the same for all cases except

shows the variation in mining time when the size of
for some unexpected random fluctuations because
the data used for transacting over the blockchain is
of varying network conditions, which is evidenced
varied while the amount of Ethers transacted is kept
er

from the apparently high error bar in the plots.

fixed at 750 wei. The sender and receivers involved
in the transaction are also kept fixed. We evaluate
rP

the performance of mining in our implemented IoT

blockchain by using transaction data packets of size
10 bytes, 50 bytes, and 100 bytes. We observe the
same variation in mining time for different data
Fo

sizes over 30 repetitions of this exercise for each

data size. Except for some random cases where
mining time may show an increased deviation from (a) Average mining time (b) Average transaction time
the norm (as can be seen for the 50 byte data packet
in Fig. 4(a)), the mining time for all these data sizes Fig. 6: Variation in blockchain operation times with
remains reasonably consistent. We attribute these respct to various nodes
random unexpected values to unstable and con-
gested network behavior and the induced latency Similarly, Fig. 5(b) shows the variation in trans-
thereof. action time for the same exercise as described above.
Similarly, Fig. 4(b) shows the variation in trans- For each of the three cases, i.e., for 1 wei, 105 wei,
action time for the same repeat of the exercise and 1010 wei, we observe almost the same type
outlined above. Similar to the observed behavior in of variations as reported previously. We attribute
mining time, the transaction operation also reports this randomness in behavior to unstable network
some unaccounted-for surge in transaction time, conditions. The randomness distorts the norm of
 9

the readings for all three cases, as is evident from the network quality available to this node when
the significantly larger error bar in the plots. it is mobile, we perform two network-based tests
– 1) check the network response time when the
3.5 Effect of Node Characteristics mobile node queries an address over the network
during mining operation, and 2) check the network
Fig. 6(a) shows the variation in mining time at node-
response time when a static node queries the mobile
1 with the change of receiver nodes while keeping
node’s address during mining operation.
the data size fixed at 100 bytes and the number
Fig. 7(a) shows the network latencies witnessed
of Ethers at 750 wei. The make of the nodes is
by node-4 during the first test. Whereas, Fig. 7(b)
described in Table 1. We observe that there is almost
shows the network latencies witnessed by a static
no difference in mining time when nodes 2 and 3 –
node during the second test. It is to be noted that
connected to the blockchain over an Ethernet-based
the static node connects to the network through a
connection – act as receivers of the data. However,
fixed Ethernet-based connection. We observe that
there is a significant rise in mining time when node-
there is a considerable variation in the recorded

y
4, which connects to the blockchain over WiFi, is
network latencies as node-4 moves through regions
made the receiver of data from node-1. The error

nl
of weak and strong WiFi signal strengths. This
bar for the plot of mining time at node-4 indicates
mobility and fluctuations in signal strength further
a massive fluctuation of values, indicating unstable

O
give rise to intermittent connectivity issues such as
network connection.
Similarly, Fig. 6(b) shows the variation in trans- the unavailability of the network (as seen in Fig.
action time for transactions between node-1 and the 7(a) between instances from 33 to 46). The network

se
other three nodes under the same operating condi- stays unreachable until the mobile node enters into
tions, as mentioned earlier. Here we observe that a zone of good signal strength. As a result of this
there is an increase in the average transaction times behavior, there is an induced lag in mining times
lU
whenever mobile nodes connect to the blockchain
at node-1 when the transactions are performed be-
tween it and nodes 2-4. The increase in transaction over constrained networks.
time at nodes 3 and 4 are caused due to random Fig. 8(a) shows the variation in mining time for
two different data sizes, i.e., 10 bytes and 100 bytes
na

variations in network latencies due to intermittent

network connections, as evidenced by the relatively while transacting between a static and a mobile
higher error bars in the plots for these two nodes. node in our implemented blockchain. The consider-
able variations in mining times, as evidenced by the
so

error bars, are a result of unstable network connec-

tions when the mobile node traverses through zones
of good and bad signal strengths. Considering equal
er

network variations during the transference of the

two data blocks, we observe that the norm for
rP

100 bytes is higher than that for 10 bytes of data,

indicating higher mining time incurred for more
(a) Mobile node to a static (b) Static node to a mobile significant data sizes.
node node Similarly, Fig. 8(b) shows the variation in trans-
Fo

action time for the two selected data sizes, i.e., 10

Fig. 7: Network latency encountered during ping
bytes and 100 bytes while transacting between a
operation.
static and a mobile node in the network. We again
observe the average transaction time of 100 bytes
data packet to be slightly higher than that for 10
3.6 Effect of Node Mobility bytes data packets, which is due to the increase in
In contrast to the static node analysis until Section time required to transmit and process the data. The
3.5, in this section, we evaluate the performance of variations and increased values of the error bars
the network as well as the implemented blockchain signify intermittent network connectivity, resulting
from the perspective of a mobile node. The mobile in higher transaction times for the mobile node.
node under consideration is node-4, which connects Further, Fig. 8(c) shows the variation in mining
to the blockchain through a WiFi-based connection, time for three different amounts of transacted Ether,
which gives it the ability to relocate without chang- viz. 1 wei, 105 wei, and 1010 wei while transacting
ing any physical configurations quickly. To estimate from the static node to the mobile node in the
 10

(a) Average mining time vs (b) Average transaction time vs (c) Average mining time vs (d) Average transaction time vs
data size data size Ethers used Ethers used

Fig. 8: Evaluation of parameters during transmission of data from static to mobile IoT nodes.

blockchain. Here, we consider the bar for 105 wei that although the energy consumed for executing

y
to be the standard baseline as its error bars are rel- each of the four algorithms (AES, RSA, AES256(BC),
atively much lesser than that of the other two bars. and RSA(BC)) is significantly small, the RSA and

nl
The increased error bars for 1 and 1010 wei indicate AES256(BC) have a high variance for data sizes
an increase in network-based disturbance, which ranging from 10B to 1000B .

O
affects the mining operation, even for increased Gas
prices.
Similarly, Fig. 8(d) shows the variation in trans-

se
action time for the three different amounts of trans-
acted Ether, viz. 1 wei, 105 wei and 1010 wei, when
they transfer from a static node to a mobile node
of our blockchain. As compared to the mining time,
lU
the transaction time experiment witnesses relatively
lesser network disturbances, as evidenced by the (a) Percentage of CPU usage (b) Energy consumed (in nJ)
smaller error bars for 1 wei and 105 wei.
na

Fig. 9: Performance of various security measures on

a resource-constrained IoT node.
3.7 Effect of Encryption Algorithms
so

We evaluate the effect of additional security and

privacy measures, which are integrated on the
same constrained IoT nodes, which are part of the 3.8 Discussion
er

blockchain operations. The data being forwarded In our evaluation, we observe that the blockchain
on the blockchain is encrypted using two algo- performance is significantly dependent on the net-
rP

rithms – RSA and the 256-bit AES. We analyze the work quality – more unstable the network more is
standalone effect of these algorithms on the CPU the time taken for mining and transaction opera-
usage and energy consumption of the resource- tions over it. This effect becomes more pronounced
constrained devices, as shown in Fig. 9. We have when the blockchain nodes are both constrained as
Fo

first used AES and RSA in a standalone mode to well as mobile. The mining and transaction times
encrypt data on the IoT node. Thereafter, both of are relatively consistent for data sizes up to 100
these encryption algorithms are used to encrypt bytes for both static and mobile nodes. We observe
data before it is put to the blockchain – the IoT a similar trend for the effect of Ethers, for the
node simultaneously runs one of these algorithms fixed number of nodes in our evaluation. The Ether
along with blockchain operations, which are de- balance with the sender node was initially logged at
noted as AES256(BC) and RSA(BC) in Fig. 9(a). 7.519 wei, the whole of which gets transferred to the
From the same figure, we observe that for vary- receiver upon completion of a transaction. Unlike
ing data sizes, the four algorithms have compara- public blockchains, which deal with unknown and
ble CPU usage (neglecting the intermittent outlier trustless systems, the private blockchains do not
behavior observed in some of the readings). We need an incentive-based mechanism to work. We
calculate the processing energy required for these also note that the blockchain operations cause the
security measures from the CPU utilization of each constrained Edge nodes to incur additional pro-
type of IoT device [18]. From Fig. 9(b), we observe cessing overheads due to the blockchain operations,
 11

which restricts the applicability of the Edge nodes R EFERENCES

to regular sensing and actuation operations.
[1] V. Thangavelu, D. M. Divakaran, R. Sairam, S. S. Bhunia,
Applications incurring heavy processing, such and M. Gurusamy, “DEFT: A Distributed IoT Fingerprint-
as computer vision and processing-intensive ing Technique,” IEEE Internet of Things Journal, vol. 6, no. 1,
learning-based tasks, might induce significant over- pp. 940–952, 2019.
heads if used at the Edge blockchain nodes. Sim- [2] O. Novo, “Scalable Access Management in IoT using
Blockchain: a Performance Evaluation,” IEEE Internet of
ilarly, tasks generating voluminous data such as Things Journal, 2018.
those associated with multimedia data are also [3] C. Xu, K. Wang, P. Li, S. Guo, J. Luo, B. Ye, and M. Guo,
detrimental to our present implementation’s perfor- “Making big data open in edges: A resource-efficient
mance. blockchain-based approach,” IEEE Transactions on Parallel
and Distributed Systems, vol. 30, no. 4, pp. 870–882, 2019.
[4] R. T. Tiburski, C. R. Moratelli, S. F. Johann, M. V. Neves,
E. de Matos, L. A. Amaral, and F. Hessel, “Lightweight
Security Architecture Based on Embedded Virtualization
4 C ONCLUSION and Trust Mechanisms for IoT Edge Devices,” IEEE Com-

y
munications Magazine, vol. 57, no. 2, pp. 67–73, 2019.
As a significant majority of IoT Edge devices and [5] O. Novo, “Blockchain meets IoT: An architecture for scal-

nl
IoT networks are resource-constrained, the provi- able access management in IoT,” IEEE Internet of Things
sion for incorporating reliable security measures Journal, vol. 5, no. 2, pp. 1184–1195, 2018.
[6] L. Wu, K. Meng, S. Xu, S. Li, M. Ding, and Y. Suo, “Demo-

O
is often not available for these devices. These re-
cratic centralism: A hybrid blockchain architecture and
strictions have resulted in an abundant presence its applications in energy Internet,” in IEEE International
of unsecured data propagating through IoT net- Conference on Energy Internet (ICEI). IEEE, 2017, pp. 176–

se
works and make the Edge devices susceptible to 181.
unauthorized access and tampering. In this work, [7] L. Wu, X. Du, W. Wang, and B. Lin, “An out-of-band au-
thentication scheme for internet of things using blockchain
we have proposed and analyzed the feasibility of technology,” in 2018 International Conference on Computing,
incorporating heterogeneous IoT Edge devices as
lU
Networking and Communications (ICNC). IEEE, 2018, pp.
functional blockchain nodes to extend the feature 769–773.
of decentralized security to resource-constrained [8] A. Dorri, S. S. Kanhere, and R. Jurdak, “Towards an
optimized blockchain for IoT,” in Proceedings of the Sec-
IoT deployments. We also implement an encrypted
na

ond International Conference on Internet-of-Things Design and

network-based time-synchronization mechanism to Implementation. ACM, 2017, pp. 173–178.
enable the non-real-time IoT Edge nodes to co-exist [9] K. Fan, Y. Ren, Y. Wang, H. Li, and Y. Yang, “Blockchain-
in the blockchain. based efficient privacy preserving and data sharing
so

scheme of content-centric network in 5G,” IET Communi-

We conclude that the feasibility of utilizing a cations, vol. 12, no. 5, pp. 527–532, 2017.
blockchain-based decentralized security cover at the [10] S. D. Angelis, L. Aniello, R. Baldoni, F. Lombardi,
IoT Edge devices itself is significantly high in terms A. Margheri, and V. Sassone, “PBFT vs proof-of-authority:
er

of restricting data repudiation and enforcing trust in applying the CAP theorem to permissioned blockchain,”
in Italian Conference on Cyber Security, January 2018.
the constrained deployment, which were previously [11] S. Huh, S. Cho, and S. Kim, “Managing IoT devices using
rP

susceptible to manipulation. However, the underly- blockchain platform,” in 19th International Conference on
ing connectivity of the network and the minimum Advanced Communication Technology (ICACT). IEEE, 2017,
processing capabilities of the blockchain nodes con- pp. 464–467.
[12] S.-C. Cha, J.-F. Chen, C. Su, and K.-H. Yeh, “A Blockchain
trol the blockchain performance, which further re-
Fo

Connected Gateway for BLE-Based Devices in the Internet

stricts the nature of the sensing and actuation tasks of Things,” IEEE Access, vol. 6, pp. 24 639–24 649, 2018.
that the Edge node can accommodate. In the future, [13] Y. Rahulamathavan, R. C. . Phan, M. Rajarajan, S. Misra,
we plan to design and develop methodologies to and A. Kondoz, “Privacy-preserving blockchain based IoT
ecosystem using attribute-based encryption,” in 2017 IEEE
incorporate processing-intensive tasks such as com- International Conference on Advanced Networks and Telecom-
puter vision with our implemented blockchain at munications Systems (ANTS), Dec 2017, pp. 1–6.
the Edge. [14] J. Sun, J. Yan, and K. Z. Zhang, “Blockchain-based sharing
services: What blockchain technology can contribute to
smart cities,” Financial Innovation, vol. 2, no. 1, p. 26, 2016.
[15] X. Yue, H. Wang, D. Jin, M. Li, and W. Jiang, “Health-
ACKNOWLEDGEMENT care data gateways: found healthcare intelligence on
blockchain with novel privacy risk control,” Journal of
This work is sponsored by the University Grants medical systems, vol. 40, no. 10, p. 218, 2016.
[16] M. Li, J. Weng, A. Yang, W. Lu, Y. Zhang, L. Hou, J.-N.
Commission (UGC)-UK India Education Research Liu, Y. Xiang, and R. Deng, “CrowdBC: A blockchain-
Initiative (UKIERI) Joint Research Programme based decentralized framework for crowdsourcing,” IEEE
(UKIERI-III) under project file No. 184-17/2017(IC). Transactions on Parallel and Distributed Systems, 2018.
 12

[17] Q. Xia, E. B. Sifah, K. O. Asamoah, J. Gao, X. Du, and Nishant Saurabh He has completed his
M. Guizani, “MeDShare: Trust-less medical data sharing B.Tech degree in Electronics and Com-
among cloud service providers via blockchain,” IEEE Ac- munication Engineering from National In-
cess, vol. 5, pp. 14 757–14 767, 2017. stitute of Technology, Patna, Bihar, India
[18] T. X. Tran and D. Pompili, “Joint task offloading and in June 2019. His research interest in-
resource allocation for multi-server mobile-edge comput- cludes a broad range of areas such as In-
ing networks,” IEEE Transactions on Vehicular Technology, ternet of Things, Microprocessors and Mi-
vol. 68, no. 1, pp. 856–868, 2018. crocontrollers, blockchain, VLSI, and oth-
ers, with the main focus on integrating the
blockchain with other technologies and creating a decentralized
and secure platform in other domains.

Sudip Misra (M’09–SM’11) He received

the Ph.D. degree in computer science from
Carleton University, Ottawa, ON, Canada.

y
He is a Professor with the Department
of Computer Science and Engineering, In-

nl
dian Institute of Technology Kharagpur, In- Yogachandran Rahulamathavan He is a
dia. Prior to this, he was associated with lecturer and a program director for MSc
Cornell University (USA), Yale University Cyber Security and Big Data program at

O
(USA), Nortel Networks (Canada), and the Loughborough University’s London Cam-
Government of Ontario (Canada). He possesses several years pus in the UK. His research interest is
of experience working in academia, government, and private on developing novel security protocols to
advance machine learning techniques to

se
sectors in research, teaching, consulting, project management,
architecture, software design, and product engineering roles. solve complex privacy issues in emerging
His current research interests include wireless ad hoc and applications e.g., patient’s healthcare data
sensor networks, Internet of Things (IoT), computer networks, sharing, biometric authentication systems, identity management
learning systems, and algorithm design for emerging communi-
lU in cloud, etc. He received his Ph.D. degree in Signal and In-
cation networks. formation Processing from Loughborough University in 2011
and then worked as an information security researcher at City,
University of London between 2011 and 2016. Currently, he is
coordinating UK-India project (worth of £200k) between Lough-
na

borough University London, IIT Kharagpur and City, University

of London.

Anandarup Mukherjee He is currently a

so

Senior Research Fellow and Ph.D. Scholar

in Engineering at the Department of Com-
puter Science and Engineering at the In-
dian Institute of Technology, Kharagpur.
er

He finished his M.Tech and B.Tech from

West Bengal University of Technology in
Muttukrishnan Rajarajan He received his
the years 2012 and 2010, respectively. His
rP

BEng and PhD degrees from City Univer-

research interests include, but are not lim-
sity London in 1994 and 1999 respectively.
ited to IoT, networked robots, unmanned aerial vehicle swarms,
From 1999 he worked at City University
and enabling deep learning for these platforms for controls and
London as a Research Fellow. In August
communications.
2000 he moved to Logica as a Telecommu-
Fo

nication Consultant. After a few years in the

industry Raj is now a Professor of Security
Engineering. He is also the Programme Di-
rector for the Engineering with Management and Entrepreneur-
ship programme. He is a senior member of IEEE, a member
Arijit Roy He is a Ph.D. scholar at the of IET and an associate member of the institute of information
Indian Institute of Technology, Kharagpur, security professionals (IISP) and a member of Technical Pro-
India. Prior to that, he received an MS (by gramme Committees for PIERS 2010, eHealth 2010, SECURE-
research) degree and B.Tech degree in In- COM2011, TrustBus 2011, Digital Economy 2012, IFIPTM 2012
formation Technology from the Indian Insti- and IFIP SEC 2012. He was also the General Chair of SE-
tute of Technology Kharagpur in 2015 and CURECOMM 2011 in London. He also sits on the Editorial
the West Bengal University of Technology boards of Springer/ACM Journal on Wireless Networks, Elsevier
in 2010, respectively. His research works Journal of Health Policy and Technology and Emerald Journal of
are published in different reputed SCI jour- Information Management and Computer Security.
nals (including IEEE/ACM Transactions) and in many reputed
conferences.