BLOCKCHAINS FOR SCALABLE IOT MANAGEMENT, ACCESS, AND
ACCOUNTABILITY
Blockchain for Managing Heterogeneous Internet of Things: A Perspective Architecture
Lewis Tseng, Liwen Wong, Safa Otoum, Moayad Aloqaily, and Jalel Ben Othman
Digital Object Identifier:
10.1109/MNET.001.1900103
12
Abstract
IoT has the potential to transform the way we
think about information and communication tech-
nology. IoT has been studied extensively across
many disciplines such as the networking, com-
munication, security, business, and management
communities. However, many unsolved challeng-
es, especially in managing heterogeneous IoTs,
remain to be discussed. Recent studies propose
using blockchain, an emerging technology that
enables decentralized coordination, to address
inherent challenges in IoT. This article presents a
preliminary study on an architecture that imple-
ments blockchain in managing heterogeneous IoT
systems. We start by pointing out the limitations
of prior IoT systems and the difficulties of integrat-
ing IoT and blockchain. Then we outline an archi-
tecture to manage a large-scale heterogeneous
IoT system. Our main goal is to stimulate further
effort and cross-disciplinary collaboration by pro-
viding guidance and reference for future studies.
Introduction
In recent years, we have observed various Internet
of Things (IoT) systems, consisting of devices, net-
works, technologies, and human resources, deliv-
er exciting results across numerous sectors and
applications including business, intelligent trans-
portation, tracking and monitoring, smart health,
and smart home, among others. In IoT systems,
the information is sent from a device to the cloud
in which the received data is processed using ana-
lytics procedures and sent back to the IoT device.
IoT management is a daunting task due to numer-
ous joined devices and complicated interaction
among devices. Moreover, in a highly scalable
and large-scale IoT system, weak and unsecured
points will unavoidably be detected and exploited
[1]. Therefore, there is a strong need for efficient,
scalable, and secure management of IoT systems
with heterogeneous devices.
With the growth of IoT in the research and
industry fields, security and privacy weaknesses
have arisen. Unfortunately, a number of securi-
ty and privacy techniques are unsuitable for IoT,
mainly due to devices’ resource constraints and
its decentralized and unmediated topology that
allows devices to constantly share critical infor-
mation back and forth over the Internet [2]. This
makes IoT a prime target for malicious third par-
ties, which leads to autonomous decision making.
Plentiful security weaknesses have been acknowl-
edged in connected devices [3–6]. The work in
Lewis Tseng and Liwen Wong are with Boston College; Safa Otoum is with Zayed University; Moayad Aloqaily is with Al Ain University and xAnalytics Inc.; Jalel Ben
Othman is with L2S lab CNRS Centrale Supélec, University Paris Sud, and University of Paris 13.
0890-8044/19/$25.00 © 2019 IEEE
[4] proposed a distributed capability-based access
control method for sensitive information access;
however, their proposed work compromises user
privacy. On the other hand, the work proposed in
[5] aimed to provide authentication and privacy
for IoT, but the proposed method is inappropriate
for resource-limited IoT devices.
Blockchain, an emerging technology with
great success in cryptocurrencies, has gained
interest for its use in many application domains.
The foremost advantage of blockchain is its inher-
ent security guarantees and resistance to various
attacks [7]. The other important advantage is a
tamper-resistant mechanism to enable decentral-
ized coordination and storage without the need
for a trusted third party. Fundamentally, IoT shares
some common problems with cryptocurrencies.
For example, in an IoT system, there are many
entities such as nodes, gateways, and users that
do not automatically trust each other when per-
forming connections [8]. Hence, several prior
works have proposed using blockchain to address
various issues in IoT (e.g., [7–9]).
In spite of its desirable advantages, blockchain
has its own disadvantages, as pointed out in [9],
for example, scalability issues, encryption process-
ing time and power, and high storage overhead.
In addition to these technical limitations, we iden-
tify and categorize unsolved challenges that have
to be addressed in blockchain-based IoT. The goal
of this article is to outline our design to address
these challenges. Specifically, we propose a per-
spective architecture to support and manage a
large-scale heterogeneous IoT system by seam-
lessly integrating IoT and blockchain. Further-
more, by having a modular and easy-to-configure
architecture, we hope to stimulate further effort
and cross-disciplinary collaboration.
The article is structured as follows. In the fol-
lowing section, we briefly discuss IoT applications
and state-of-the-art IoT systems. Then we present
an overview on blockchain and related applica-
tions. Following that, we identify key unsolved
challenges in managing heterogeneous IoT sys-
tems, pointing out that it is nontrivial to integrate
blockchains and IoT systems. Finally, we outline
a novel architecture that addresses the identified
challenges.
Blockchain: Features and Applications
Interest in blockchain technology gradually devel-
oped after Bitcoin was introduced in 2008, and
has grown exponentially as Bitcoin became a
household name in 2017.
IEEE Network • January/February 2020
 While Satoshi Nakamoto’s work [10] eventu-
ally served as the foundation upon which block-
chain has been studied and adopted, his work
focuses on blockchain in the context of an alter-
native currency and store of value rather than in
non-currency settings such as land registration,
constituent voting, and supply chain traceability.
Blockchain can be better thought of as an amal-
gamation of several existing technologies: peer-
to-peer (P2P) networking, cryptographic hashing
functions, trusted timestamping, and digital sig-
natures. We give a short overview on blockchain
below.
Intuitively, blockchain (or so-called distributed
ledger, DLT) is a decentralized database designed
to enable multiple independent participants in the
network to reach consensus about changes to the
state of the shared data without needing a trusted
third party. Blockchain is a subset of DLT, in which
a special data structure bundles transactions into
blocks with a unique hash code and broadcasts
them to every node. Consensus models such as
“proof of work” and “proof of authority” allow
the determination of which node has the right
to publish the next block. Participants reach an
agreement over transactions and records through
a consensus mechanism (e.g., proof of work,
proof of stake, or PBFT), ensuring that each par-
ty’s view of the shared database is consistent with
that of all other parties. This eliminates the need
to trust other participants who may have differ-
ent motives or malicious behaviors. Through the
consensus mechanism, any tampering or improp-
er modification of the data will be independent-
ly detected and rejected by honest participants.
As a result, digital assets and records cannot be
forged once they are recorded on the blockchain,
or transferred, without the participants’ consent in
the form of a digital signature.
In order to explore the potential application
of blockchain in IoT, it is important to first under-
stand the features of blockchains, in particular
how blockchains help in solving the challenges
posed above. In the rest of this section, we dis-
cuss the main features of blockchain as well as its
applications.
Structure of Blockchains
A blockchain consists of a chain of blocks that
contain details of stored transactions within the
network (Fig. 1). Each block contains a header
and a body. The first block of the chain is also
called the “genesis” block. The header contains
the identifier, which is obtained by taking the
cryptographic hash of the previous block, among
other fields, whereas the body consists of stored
transactions that are being broadcast. Details of
the transactions can be regarded as a kind of
data exchange or the transfer of tokens that takes
place in a network. The blocks are connected in
a chain, and can be thought of as a linked list.
Immutability refers to the linking of each block
to a previous block. Should any participant with-
in the network attempt to alter or tamper with
the contents of a past block, the block’s identifi-
er would no longer be valid. Consequently, this
labels the subsequent block hashes as invalid.
Features of Blockchains
Blockchains offer attractive features, mainly
IEEE Network • January/February 2020
FIGURE 1. Representation of blockchain’s structure: each block of the chain con-
tains a header and a body, where the header includes the identifier of the
previous block, and the body contains stored transactions in a Merkle tree.
decentralization, fault tolerance, and immutability.
Blockchain has the potential to ensure transparen-
cy by reducing the need for trust between multi-
ple parties, reducing dependence on intermediary
service providers, building a secure value transfer
system (of assets and of information), streamlin-
ing business processes, and increasing regulatory
practices and ease of auditing.
Decentralization: Blockchain is built on top of
a P2P network where every entity can join it at
will; that is, if the blockchain is permissionless.
Fault Tolerance/Security: Blockchain is
designed to tolerate malicious behavior as long
as a certain threshold of participants are correct
(typically the majority). All participants in the
blockchain hold identical copies of the ledger.
Any tampering with the data will be detected and
rejected by blockchain peers. This verification sys-
tem, built on consensus algorithms, eliminates the
“double-spending” problem and is one of the key
benefits of using blockchain.
Immutability: Blockchain’s core idea is based
on a chain of immutable blocks that contains
important data (e.g., transaction details in Bitcoin).
Since all transactions that take place in the block-
chain are verified with the consensus mechanism,
the blockchain is tamper-resistant given that any
changes in the blockchain would easily be detect-
ed. In order to alter any previous and existing
records, an attacker would have to attempt to
compromise all nodes within the network.
Auditability/Privacy: Since all participants hold
a replica of the blockchain, network participants
have access to all transaction records. This trans-
parency in records allows participants to look
up desired blockchain addresses. However, the
blockchain does provide a sense of pseudo-ano-
nymity. It is difficult to use blockchain transaction
records to trace back to the parties involved in
the transactions.
Types of Blockchain
Public: Public blockchains are also called per-
missionless blockchains. Public blockchains are
decentralized; anyone is allowed to maintain a
replica of the blockchain and engage in validating
new blocks. Bitcoin [10] and Ethereum are a type
of public or “open” blockchain.
Private: The terms “private,” “closed,” and
“permissioned” are often used interchangeably.
Permissioned or closed blockchains refer to those
whose access is restricted to a specific set of vet-
ted participants. The permission model is built on
13

Consortium blockchains are used as a synchronized distributed database, keeping track of data
exchanges between consortium network participants. While these blockchains provide faster latency
in transactions and more auditability, they are not completely decentralized.
Category Challenges
Layer of integration
Energy constraints
Integration
Supportability and compatibility
Heterogeneity
Failure recovery
Management/deployment Monitoring and auditability
Extensibility and flexibility
TABLE 1. Challenges of blockchain-based IoT.
three key types of permission configurations that
can be used when setting up a blockchain, giving
permission to those who can:
• Read: access the ledger and see transactions
• Write: generate transactions and see transac-
tions
• Commit: update the state of the ledger
Unlike public blockchains, private blockchains do
not require processing fees. Hyperledger [11] is
one popular private chain.
Consortium: Consortium blockchains (also
dubbed federated blockchains) are similar to pri-
vate blockchains in that they are permissioned
networks. Consortium blockchains are used as a
synchronized distributed database, keeping track
of data exchanges between consortium network
participants. While these blockchains provide fast-
er latency in transactions and more auditability,
they are not completely decentralized.
Applications of Blockchain
The public and private sectors have been explor-
ing blockchain use cases in recent years. To name
a few applications that are being examined:
1. Secure decentralized applications with trust-
ed hardware and blockchains
2. Decentralized markets
3. Private digital currencies and closed payment
communities
4. Payment regulation
5. Automation for high-assurance smart con-
tracts
6. Voting applications
7. Identity system to secure government records
8. Land registration and real estate transactions
The system presented in this article is most rel-
evant to application 1 above. As we point out, the
proposed framework is sufficiently different from
prior works due to our focus on addressing chal-
lenges in IoT ecosystems. Specifically, our system
is useful for managing multiple IoT systems in an
autonomous and scalable fashion.
Key Challenges
In this section, we identify key categories of
unsolved challenges. Some of them are inherent
challenges of heterogeneous IoT systems that are
not addressed in prior studies, and can be solved
by novel components based on blockchain. Other
challenges are due to the difficulty of integrating
blockchain and IoT. We summarize two catego-
14
ries of challenges below and in Table 1.
Integration: Since IoT and blockchains are
developed by different communities with dis-
tinct design goals, technical issues arise during
the attempt to integrate the two systems into one
coherent design seamlessly.
Management/Operation: As pointed out ear-
lier, many different standards and designs exist
for IoT systems. Moreover, large-scale practical
applications are likely to use multiple IoT devic-
es, possibly from different vendors, at the same
time. Managing such an IoT system is a nontriv-
ial task. Additionally, IoT is a fast-evolving area;
most IoT devices are fragile and resource-con-
strained. Hence, deploying and operating IoT
systems smoothly is an important element to be
addressed.
In the following section, we present a novel
architecture that addresses all the challenges iden-
tified in this section.
Integration Challenges
Layer of Integration: As mentioned previously,
IoT is a complex system consisting of many com-
ponents: devices, networks, technologies, and
human resources. To define a common interface
for different components, the Internet of Things
World Forum (IoTWF) proposed a seven-layer
IoT reference model [12], which includes the
following layers: Physical Devices & Control-
lers, Connectivity, Edge (Fog) Computing, Data
Accumulation, Data Abstraction, Application, and
Collaboration & Processes. Figure 2 presents the
seven-layer reference model.
To keep the architecture clean and simple, it is
tempting to treat a blockchain-based system as a
blackbox and plug it in at certain layers in the IoT
reference model. In fact, many blockchain-based
IoT systems surveyed in [13] adopt this method.
However, such a blackbox method has two main
issues:
• From a technical point of view, such a meth-
od is prone to downgrades in performance.
• From a business point of view, following a
common reference model is necessary so
that different vendors can work together
with minimal coordination efforts.
Regarding the first issue, observe that, as men-
tioned previously, blockchains in their simplest
form are commonly viewed as a distributed led-
ger or a distributed database. Naturally, block-
chains can be used as a blackbox interacting with
layers 3 (edge/fog computing) and 4 (data accu-
mulation) since these layers are related to storing
and exchanging data. Using this vanilla design,
however, will hinder performance. This is due to
the fact that in layers 3 and 4, the conceptual
model is “data-in-motion” [14], where data is gen-
erated or captured in continuous streams at high
data transfer rates. In fact, typical blockchains are
not able to deal with this kind of scenario due
to its strong immutability constraint. In short, we
need to have a different blockchain design to deal
with data-in-motion. Otherwise, blockchain should
be integrated with IoT differently, possibly in a
different layer or as an auxiliary system.
Energy Constraints: Most IoT devices come
with limited battery power because of cost con-
straints. Most popular blockchain-based systems
use proof of work (PoW) [10] (e.g., Bitcoin and
IEEE Network • January/February 2020
Ethereum) or Practical Byzantine Fault Tolerance
(PBFT) [15] (e.g., Hyperledger [11]) to achieve
coordination. Unfortunately, these protocols
require heavy communication and/or compu-
tation. Therefore, they are not adequate for IoT
devices since energy consumption is positively
correlated to communication and computation
overhead. To have a practical blockchain-based
IoT system, energy consumption needs to be
reduced at each IoT device.
Supportability and Compatibility: It is unlikely
to deploy an entirely new IoT system all at once
due to its scale and intricate interaction with
other components. Therefore, it is not practical
to roll out a completely new design that requires
all devices to support blockchain and/or a new
architecture. Instead, a system must support IoT
devices with different designs, and particularly be
comparable to out-of-date devices that may not
have enough computation power and/or battery
to participate in a blockchain protocol.
Heterogeneity: In a practical setting, it is com-
mon to deploy multiple types of devices from
different vendors. From a design perspective, it
suffices to define common communication pro-
tocols or interfaces to coordinate multiple devic-
es. The IoTWF reference model [12] portrays FIGURE 2. Seven-layer IoT reference model proposed by IoTWF [12].
this effort. However, in terms of operation, it is
quite challenging due to different reliability guar-
antees, communication protocols, and levels of and devices so that deploying new protocols and
computation power. If we treat all devices as the changing its configuration can be completed with
same entity and require them to participate in the minimal human intervention.
blockchain, the resulting performance and reli-
ability would likely be poor. Hence, we need to Our Perspective Architecture
take heterogeneity into account and design a flex- In this section, we present our novel block-
ible architecture. This is another reason why using chain-based design for managing heterogeneous
blockchain as a blackbox is not the most effective IoT. Particularly, our system allows users and
method. administrators to organize and locate IoT devices,
monitor and maintain the health of the devices,
Management/Deployment Challenges configure the devices, and integrate multiple IoT
Failure Recovery: Most blockchain-based sys- subsystems. Due to space limits, we do not pres-
tems ensure immutable chains of data. It is not an ent the details of these functions, since these are
easy task to remove state of transactions that are relatively easy to implement on top of the pro-
generated in the blockchain due to unfortunate posed architecture. Instead, we focus on how our
events, for example, frequent communication architecture addresses the challenges identified
failures, devices’ transient failures, configuration above. The key components and features are
error, and so on. As a result of this inconsistency, summarized in Table 2.
some devices might not be able to operate cor-
rectly. Therefore, we need to address the issue of Architecture Overview
recovering from such erroneous state. We implement our system in layers 3, 4, and 5 of
Monitoring and Auditability: An administrator the IoT reference model of IoTWF [12], as shown
must learn to deal with the complexity of config- in Fig. 3.
uration and provision. To perform these two tasks Layer 3 (Edge/Fog Computing) is where the
effectively, the administrator needs to accurately device collects data. We interact this layer with
monitor the system’s health and performance with the cloud in order to offload important data and
different granularity. Additionally, to ensure securi- decide when to collect it.
ty, the administrator will need to audit the behav- Layer 4 (Data Accumulation) is where the sys-
ior of the devices to identify potentially malicious tem converts data-in-motion into data-in-rest, that
behavior or devices with degraded performance. is, the system determines whether to persist data,
Extensibility and Flexibility: One might think and decides where to store and organize such
blockchains are autonomous and self-stabilizing data. This layer requires coordination among dif-
due to their decentralizing nature. However, ferent devices and IoT subsystems to obtain data
blockchains usually require human intervention to from different sources and deliver it to different
ensure their operations run smoothly. For exam- destinations. We propose using blockchain in this
ple, Bitcoin relies on a human’s decision in deter- layer to achieve coordination and store different
mining the puzzle’s level of difficulty (also related types of data (both data-in-motion and data-in-
to hash and transaction rates), block size, and so rest).
on. For a large-scale IoT system, such fine-grained Layer 5 (Data Abstraction) is where the sys-
human operation is not practical. We need a sys- tem aggregates important information and dis-
tem that is flexible and supports future protocols cards unnecessary data. In other words, the

IEEE Network • January/February 2020 15

 Feature/Component
Hierarchical system
Sleep and Wake-up
Off-loading
Configurable consensus and
reputation system
Chain selection
Daemon
Monitoring service
Roll-back, garbage collection
Modular and flexible design
TABLE 2. Features of the design.
FIGURE 3. Representation of the seven-layer IoT reference model by IoTWF,
implemented with proposed designs.
16
Challenges addressed
Layer of integration, energy constraint, heterogeneity
Energy constraint, heterogeneity
Layer of integration, energy constraint, heterogeneity
Layer of integration, energy constraint, heterogeneity
Layer of integration, heterogeneity
Energy constraint, supportability and compatibility, heterogeneity
Monitoring and auditability
Failure recovery
Energy constraint, heterogeneity, extensibility and flexibility
system needs to consolidate data and reconcile
potential conflicts. A “selection protocol” is need-
ed to select data that ensures consistent seman-
tics from the underlying blockchain(s).
Our system also has three auxiliary compo-
nents: the cloud, monitoring service, and roll-back
service. The cloud is simply Internet cloud-based
storage that handles the offloaded data from layer
3, thereby reducing the workload and storage
overhead of IoT devices. The second and third
components are based on a public blockchain.
Depending on the need, one can configure these
components in such a way that they interact with
layer 4 or layer 5. These details are discussed
later.
The main reason to integrate blockchains in
layers 3 to 5 is that our system has the “right
amount of relevant information” in these three
layers. Layers 1 and 2 have too much raw data
that is irrelevant to users and applications, and
too little system-specific information (e.g., amount
of available data storage) for optimizing perfor-
mance. Layers 6 and 7 have too much program
logic, which would make low-level storage and
processing difficult. Moreover, these two layers
are application-specific and hence lack the glob-
al view with respect to the whole system, which
makes performance tuning tough.
One of our major design choices is to adopt
the modular and hierarchical architecture. Since
both IoT and blockchain are young ecosystems
whose technology, demand, and service are
evolving rapidly, it is unrealistic to implement a
holistic system that addresses all the issues. Our
proposed framework allows experts in different
domains to innovate, and as long as the interface
is well defined, we can integrate different compo-
nents together cleanly.
Design and Analysis
Here, we present the functionality and salient fea-
tures of each component, along with the design
rationale. Specifically, we point out how each
component addresses the challenges summarized
in Table 1.
Hierarchical System: Our architecture adopts
a hierarchical design. Its foundation consists of an
IoT subsystem based on private chains, namely
core IoT. Several core IoTs jointly participate in
a public blockchain and are used to exchange
data, achieve coordination, and realize import-
ant features of our systems (i.e., monitoring and
roll-back). Each core IoT interacts with the cloud
to perform offloading. The overall structure is
presented in Fig. 4. Note that each core IoT is
based on the seven-layer model in Fig. 2, where
our components reside in layers 3, 4, and 5 (Fig.
3). For simplicity, Fig. 4 only shows one public
blockchain for both monitoring and roll-back. If
needed, one can deploy separate public chains.
The hierarchical design improves the integra-
tion of blockchain and IoT, given that different
types of blockchains are appropriate for different
purposes. Moreover, heterogeneous IoT devices
can choose the most appropriate parameters for
the protocols to interact with each other, helping
to reduce computation and communication over-
head and energy consumption.
Sleep/Wake-up: Small-scale IoT devices with
limited battery only participate in the protocol
intermittently based on a sleep/wake-up protocol,
and only store meta-data (or no data at all). The
edge/fog servers at layer 3 (edge/fog computing)
will need to “wake up” devices if computation
power or votes are not enough to ensure the cor-
rectness of the consensus protocol in the private
chain for core IoT. Such an on-demand design
allows devices to save energy compared to the
always-on design. Moreover, this design addresses
the heterogeneity issue as different devices have
different responsibilities in the system.
Offloading: Offloading stored states onto
the cloud periodically is a common technique,
given that IoT devices usually have limited storage
space. In our system, an offloading mechanism
is coupled with the sleep/wake-up protocol to
ensure low energy consumption. Different IoT
devices will offload different amounts of data
and states at different rates depending on their
resources and the desired trade-off between per-
formance and energy consumption.
The reason that we choose to implement
the offloading component in layer 3 (edge/fog
computing) is because most existing solutions
for efficient edge and fog are an integral part of
IEEE Network • January/February 2020
the cloud. Therefore, integrating offloading in this
layer reduces the complexity of development,
for example, taking care of data discrepancy and
meta-data mismatch due to the different design
choice and program logic in other layers or com-
ponents.
Consensus Protocol: Consensus protocol is
the foundation of blockchain-based systems, and
affects performance, scalability, and provided
guarantees of the system. Our system deploys
blockchains to two places: i) the public chain
for monitoring and roll-back services, and ii) the
private chain for core IoTs. Our public chain is
based on common blockchains like Hyperledg-
er [11], and the private chain is based on our
novel blockchain. For core IoT, we propose a
new blockchain called DAG-blockchain, where
DAG stands for directed acyclic graph. In con-
trast to traditional blockchains that maintain a sin-
gle chain, DAG-blockchains may have multiple
branches simultaneously. The term DAG refers
to the fact that these branches do not contain
any cycle. The relaxation on the guarantee allows
higher throughput and scalability. Recall that we
use a private blockchain in layer 4 (data accumu-
lation), where data is still in motion. Therefore,
there is no reason to enforce strong consistency
(e.g., a single consistent chain). We rely on the
selection protocol in layer 5 (data abstraction) to
resolve the conflict and find the “correct” branch
for aggregating useful data. This also follows the
guideline of IoTWF, where data-in-motion is con-
verted into data-in-rest in layers 4 and 5.
DAG-blockchain is based on PoS and PBFT
consensus protocols, which follow the assump-
tion that the membership is known in our sys-
tem. Since core IoT is using a private chain (i.e.,
a permissioned blockchain), this is a reasonable
choice. Additionally, PoS and PBFT are more effi-
cient and scalable because they do not need to
solve computation puzzles to ensure correctness.
We reduce PBFT’s communication overhead by
adopting a weighted voting approach. Generally
speaking, reliable IoT devices with sufficient com-
putation power have a vote that carries heavi-
er weight. When a certain threshold is achieved,
consensus can be achieved despite the fact that
some devices may fail.
Concretely, our PoS and PBFT protocols use
the following approaches to address concerns
regarding heterogeneity:
• Devices with higher levels of reputation,
computation power, and energy should have
a higher stake (or more votes) in our consen-
sus protocol.
• Our system has a reputation protocol that
takes the following criteria into account:
devices’ past interaction record, company’s
history, and known bugs and security threats.
We envision that the second and third part
can either be maintained by a third-party
database or government, or be built on a
separate interacting subsystem.
• Based on new information, stake (in PoS) or
votes (in PBFT) will be recalculated. This can
be done periodically by an administrator or a
background protocol.
Chain Selection: To aggregate data for
upper-level applications (layer 6), one needs to
perform a graph traversal algorithm on multiple
IEEE Network • January/February 2020
FIGURE 4. Hierarchy in our architecture.
We have implemented a novel aggregation mechanism that provides useful application semantics
such as read-my-write and eventual consistency using DAG-blockchain and an efficient chain selection
protocol. A preliminary evaluation demonstrated that it achieved 2 to 5 performance improvement
over the original PoW-based mechanism in various scenarios.
branches of DAG-blockchain (in layer 4) to deter-
mine which data to use, and to resolve any per-
taining conflict. The exact mechanism to select
the “branch” of data and resolve conflict depends
on the application semantics. In most cases, the
Last-Write-Win rule, which picks the data with the
most recent timestamp, would work reasonably
well. Note that layer 5 (data abstraction) shares
the knowledge of application semantics, which
allows us to integrate chain selection efficient-
ly and seamlessly. Moreover, depending on the
device constraints, one can choose how deep the
graph traversal should be performed, allowing a
flexible trade-off between performance and pro-
vided guarantees.
We have implemented a novel aggregation
mechanism that provides useful application
semantics such as read-my-write and eventual
consistency using DAG-blockchain and an effi-
cient chain selection protocol. A preliminary eval-
uation demonstrated that it achieved 2 to 5
performance improvement over the original PoW-
based mechanism in various scenarios (e.g., dif-
ferent network communication quality and PoW
quality).
Daemon: A daemon is a standard tool in
operation systems, which is a long-running back-
ground process that handles some core services
for other processes To make our system back-
ward compatible, we need a mechanism for old
or small devices that lack the technology to par-
ticipate in blockchain-based systems. Our idea is
to have multiple daemon processes running on
each of the larger-scale devices with more com-
putation power and battery, where each daemon
will interact with blockchains on behalf of one
other device.
Should a case arise where no daemon is idle,
old and small devices may find themselves unable
to interact with blockchain. This leads to two con-
sequences:
1. The system enters an erroneous state due to
unexpected behaviors.
2. Some state is lost and cannot be stored in
the blockchain.
Case 2 is fine, since devices can wait until
some daemon becomes available, and we only
lose some efficiency. We rely on the roll-back ser-
vice (discussed below) to handle case 1.
Monitoring Service: In our design, each core
17

The hierarchical design of our proposed model improves the integration of blockchain and IoT.
Moreover, heterogeneous IoT devices can choose their own protocols to interact with each other,
helping to reduce computation and communication overhead and energy consumption.
IoT subsystem is based on a private blockchain
where the identity of all entities (or devices) in the
chain is known. This makes our monitoring possi-
ble. Since many IoT devices have limited battery
and storage, our monitoring does not rely on a
common mechanism that uses a log-based data
structure. Instead, a special process that resides in
larger devices will randomly and periodically poll
other devices to ask whether something malicious
or unexpected has been observed. The polling
results will be uploaded and collected in an auxil-
iary blockchain, and are later examined to ensure
that the record is consistent.
This design might not catch a malicious event
instantaneously. However, by using the poll-
ing-based mechanism with the failure recovery
service (discussed next), it is possible to identify
malicious behavior and roll back to a correct state
eventually. Such a design choice is motivated by
the fact that battery and storage resources are
potential bottlenecks in most IoT deployment.
The adjustment of the polling period also allows
our system to explore the trade-off between the
time it takes for detection and the resources con-
sumed.
The auxiliary blockchain is a public blockchain
because in some extreme cases, most devices in
the same core IoT might be corrupted, and all the
prior correct records would be lost or tampered.
Hence, we rely on the fact that it is harder to cor-
rupt enough core IoTs to ensure the reliability of
the public blockchain. Note that our monitoring
service supports auditability by the administrator.
Roll-Back Service: To make the system self-sta-
bilizing, we need to record the state of the system
(i.e., checkpoint) and be able to “roll back” to
the most recent correct state. In our design, we
use an auxiliary blockchain to store relevant state
information, including states from both daemons
and devices in core IoT. Then periodically, a “mas-
ter” process residing in the auxiliary blockchain
performs the investigation procedure. If it finds an
erroneous state, it performs the following steps:
• Scan prior states and identify a snapshot that
is consistent with all interacting systems and
daemons using a well established distributed
snapshot algorithm.
• Notify the daemons and devices to roll back
to the previous snapshot of states.
• Identify affected devices and perform a
recovery procedure.
• Perform “garbage collection” to archive old
state information.
The master process is implemented using a
long-lived smart contract in the blockchain. Note
that our roll-back service is external to the block-
chain, whose main purpose is to roll back data
and states at daemons and IoT devices. It does
not revert the operations in the blockchain, as
this will violate the typical immutability guaran-
tee at blockchain. Archiving old state information
improves the performance, because the master
process does not need to revisit this information
18
to identify a consistent snapshot in the future.
Modular and Flexible Design: First, our design
follows the IoTWF recommended reference
model as closely as possible; hence, integrating
new devices with the system should require mini-
mal effort. Second, our system is modular, and the
interaction logic between components are clean.
Consequently, each component can adopt a dif-
ferent design as long as it follows the predefined
interface and interaction logic. Third, we provide
several “tuning knobs” to explore the trade-off
between performance and reliability, which allows
the system to be flexible enough to accommo-
date different needs. Fourth, each core IoT can be
flexibly configured. Depending on the need (e.g.,
performance, reliability, ease of management),
each core IoT can contain a different set of devic-
es and protocols. Some criteria include vendor,
device location, type of data collected, power
consumption, and so on. Fifth, the monitoring ser-
vice allows the administrator to obtain the current
status, and could use the information to better
tune the knobs.
Conclusion
The integration of blockchain and IoT is influ-
ential; blockchain achieves the desired resilient,
distributed peer-to-peer networks, as well as the
ability to interact with others in an auditable
manner. In this article, we present a preliminary
study on an architecture that uses blockchain to
manage heterogeneous IoT systems. We also dis-
cuss the challenges in integration and develop-
ment. The hierarchical design of our proposed
model improves the integration of blockchain and
IoT. Moreover, heterogeneous IoT devices can
choose their own protocols to interact with each
other, helping to reduce computation and com-
munication overhead and energy consumption.
Furthermore, the adoption of the failure recovery
service helps our system to maintain stable perfor-
mance under transient failures.
References
[1] G. Ho et al., “Smart Locks: Lessons for Securing Commod-
ity Internet of Things Devices,” Proc. 11th ACM Asia Conf.
Computer and Commun. Security, 2016, pp. 461–72.
[2] I, Al Ridhawi et al., “A Profitable and Energy-Efficient Coop-
erative Fog Solution for IoT Services,” IEEE Trans. Industrial
Informatics, 2019.
[3] M. Amoozadeh et al., “Security Vulnerabilities of Connected
Vehicle Streams and Their Impact on Cooperative Driving,”
IEEE Commun. Mag., vol. 53, no. 6, June 2015, pp. 126–32.
[4] A. F. Skarmeta, J. L. Hernandez-Ramos, and M. V. More-
no, “A Decentralized Approach for Security and Privacy
Challenges in the Internet of Things,” Proc. 2014 IEEE World
Forum on Internet of Things, Mar. 2014, pp. 67–72.
[5] H. Gross et al., “Privacy-Aware Authentication in the Internet
of Things,” M. Reiter and D. Naccache, Eds., Cryptology and
Network Security, 2015, Springer, pp. 32–39.
[6] B. Cao et al., “When Internet of Things Meets Blockchain:
Challenges in Distributed Consensus,” IEEE Network, 2019.
[7] M. Salimitari and M. Chatterjee, “An Overview of Blockchain
and Consensus Protocols for IoT Networks,” 2018.
[8] T. M. Fernndez-Carams and P. Fraga-Lamas, “A Review
on the Use of Blockchain for the Internet of Things,” IEEE
Access, vol. 6, 2018, pp. 32979–33001.
[9] A. Banafa, “IoT and Blockchain Convergence: Benefits and
Challenges; https://iot.ieee.org/newsletter/january-2017/
iot-and-blockchain-convergence-benefits-and-challenges.
html, accessed Feb. 13, 2019.
[10] S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash Sys-
tem,” bitcoin.org, Oct. 2008.
[11] The Linux Foundation, “Hyperledger Architecture, Volume
1: Introduction to Hyperledger Business Blockchain Design
Philosophy and Consensus”; https://www.hyperledger.
IEEE Network • January/February 2020
 org/wp-content/uploads/ 2017/08/Hyperledger Arch WG
Paper 1 Consensus.pdf, accessed July 2018.
[12] J. Green, “IoT Reference Model Whitepaper,” Costco, Nov.
2014; https://www.iotwf.com/resources/71.
[13] M. S. Ali et al., “Applications of Blockchains in the Internet
of Things: A Comprehensive Survey,” IEEE Commun. Surveys
& Tutorials, 2018.
[14] M. Hirzel et al., “IBM Streams Processing Language: Ana-
lyzing Big Data in Motion,” IBM J. R&D, vol. 57, nos. 3–4,
May 2013.
[15] M. Castro and B. Liskov, “Practical Byzantine Fault Toler-
ance,” Proc. Third USENIX Symp. Operating Systems Design
and Implementation, New Orleans, LA, Feb. 22–25, 1999,
pp. 173–86.

Biographies
Lewis Tseng [M] is an assistant professor with the department of
Computer Science, Boston College, Massachusetts. Prior to join-
ing Boston College, he was with Toyota Info Technology Center,
U.S.A. He has a Ph.D. in computer science from the University
of Illinois at Urbana-Champaign, 2010–2016, and a B.S. in com-
puter science and a B.S. in economics from the University of
Illinois at Urbana-Champaign, 2005–2010. His research interest
includes distributed computing/systems, fault-tolerant comput-
ing, blockchain-based systems, and applications in intelligent
traffic systems.

Liwen Wong [S] is a senior at Boston College pursuing a dual

degree in computer science and economics. Her research inter-
ests include blockchain-based systems, applications in intelligent
transportation systems, and distributed computing/systems.

S afa O toum [M] received her M.A.Sc. and Ph.D degrees in

computer engineering from the University of Ottawa, Canada,
in 2014 and 2016, respectively. She is an assistant professor of
computer engineering in the College of Technological Innova-
tion, Zayed University, United Arab Emirates and a researcher
in the field of communications and network security. She was
a postdoctoral fellow at the University of Ottawa and has been
a data scientist in CheetahNetworks Inc. Ottawa since 2019.
Her research interests include network security issues, intrusion
detection and prevention, wireless sensor networks, and block-
chain solutions.

Moayad Aloqaily [S’12, M’17] received his M.Sc. degree in

ECE from Concordia University, Canada, in 2012, and his Ph.D.
degree in ECE from the University of Ottawa, Canada, in 2016.
In 2017, he was an instructor in the Systems and Computer
Engineering Department at Carleton University, Canada. He has
worked at Gnowit Inc. as a senior researcher and data scien-
tist since 2016. He is the managing director of xAnalytics Inc.,
Ottawa, Ontario, Canada. Currently, he is with the Faculty of
Engineering, Al Ain University, United Arab Emirates. His current
research interests include AI and ML, connected vehicles, block-
chain solutions, and sustainable energy and data management.

Jalel Ben Othman received his B.Sc. and M.Sc. degrees, both in
computer science, from the University of Pierre et Marie Curie
(Paris 6), France, in 1992 and 1994, respectively. He received
his Ph.D. degree from the University of Versailles, France, in
1998. He is currently a full professor at the University of Paris
13 where he has been since 2011 and a member of the L2S
lab at CentraleSupélec. His research interests are in the area of
wireless ad hoc and sensor networks, VANETs, IoT, performance
evaluation, and security in wireless networks in general.

IEEE Network • January/February 2020 19