4650 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO.

3, JUNE 2019

A Scalable Blockchain Framework for

Secure Transactions in IoT
Sujit Biswas , Graduate Student Member, IEEE, Kashif Sharif , Member, IEEE, Fan Li , Member, IEEE,
Boubakr Nour , Graduate Student Member, IEEE, and Yu Wang , Fellow, IEEE

Abstract—Internet of Things (IoT) and blockchain (BC) devices by 2020 [2], and will generate trillions of transactions
technologies have been dominating their respective research every day. Currently most of communication is performed
domains for some time. IoT offers automation at the finest level based on a client–server model. In a centralize communica-
in different fields, while BC provides secure transaction process-
ing for asset exchanges. The capability of IoT devices to generate tion model, the system administrator may disclose sensitive
transactions prompts their integration with BC as the next logical data (e.g., health care, finance, etc.) due to insider attacks [3].
step. The biggest challenges in this integration are the scalability Furthermore, the conventionally centralized computing model
of ledger and rate of transaction execution in BC. On one hand, favors several large-sized distributed data centers which cre-
due to their large numbers, IoT devices will generate transac- ates a huge burden for computing, storage, and networking
tions at a rate which current block chain solutions cannot handle.
On the other hand, implementing BC peers onto IoT devices is resources [4]. However, using traditional centralized commu-
impossible due to resource constraints. This prohibits direct inte- nication models for such large scale data communication,
gration of both technologies in their current state. In this paper, storage, and analysis, from billions of devices is next to
we propose a solution to address these challenges by using a impossible. Although cloud and edge/fog architectures [5]
local peer network to bridge the gap. It restricts the number of do provide virtually unlimited storage and processing capac-
transactions which enters the global BC by implementing a scal-
able local ledger, without compromising on the peer validation ity, the bandwidth required to upload transactions creates a
of transactions at local and global level. The testbed evaluations bottleneck in the network.
show significant reduction in the block weight and ledger size on IoT networks and the embedded devices in them have
global peers. The solution also indirectly improves the transaction drastically increased, which presents new dimensions to var-
processing rate of all peers due to load distribution. ious threats related to security and privacy. Considering the
Index Terms—Blockchain (BC), Internet of Things (IoT), limitations of existing client–server and cloud technologies,
ledger size, scalability, security, transaction rate. combined with rapid scalability of IoT, many researchers
have suggested using blockchain (BC) as a potential solu-
tion for security and privacy issues. The prime motivation for
I. I NTRODUCTION this stems from Bitcoin [6] (a public BC for cryptocurrency
transaction), to address the challenges of IoT security.
NTERNET of Things (IoT) provides a platform for con-
I necting daily use smart devices to gather, share, and
forward information. Many of these exchanges are financial A. BC Fundamentals
transactions which will dominate the future Internet archi- BC was first introduced as Bitcoin [6] in 2009. As pub-
tecture. The upcoming 5G technology will provide special lic BC, Bitcoin is the first trust-less peer-to-peer electronic
support for machine-to-machine [1] communications, which cash which has approximately 28.5 million [7] electronic wal-
will allow unprecedented growth for IoT. Some estimates lets. Many others electric cash (e.g., ether [8], XRP [9], etc.)
approximate that 50 billion devices will be registered as IoT have been introduced since, and the number of wallets have
Manuscript received May 31, 2018; revised September 9, 2018; accepted increased multifold. BC allows value exchange (i.e., transac-
September 27, 2018. Date of publication October 4, 2018; date of cur- tions) without the need of trust authority from a central entity.
rent version June 19, 2019. The work of F. Li was supported by the These transactions are stored in a ledger which is maintained
National Natural Science Foundation of China under Grant 61772077, Grant
61370192, and Grant 61432015. The work of Y. Wang was supported in by a group of connected computers (i.e., peers), unlike a cen-
part by the U.S. National Science Foundation under Grant CNS-1343355, tralized entity like a bank database. BC system performs an
in part by the National Natural Science Foundation of China under Grant autonomous verification (i.e., endorsement) before approving
61572347, and in part by the U.S. Department of Transportation Center
for Advanced Multimodal Mobility Solutions and Education. (Corresponding the transaction which plays a key role in ensuring security.
authors: Kashif Sharif; Fan Li.) The specialty of BC is that it is designed in such a way that
S. Biswas, K. Sharif, F. Li, and B. Nour are with the School of Computer no trust is needed, and security and reliability are obtained
Science and the Bejing Engineering Research Center of High Volume
Language Information Processing and Cloud Computing Applications, Beijing via special mathematical functions or code. Till 2016, most
Institute of Technology, Beijing 100086, China (e-mail: [email protected]; of the BC networks have been used for cryptocurrency trans-
[email protected]; [email protected]; [email protected]). actions. Recently BC uses have gone beyond cryptocurrency
Y. Wang is with the Department of Computer Science, University of North
Carolina at Charlotte, Charlotte, NC 28223 USA (e-mail: [email protected]). and are beginning to be utilized in other application domains
Digital Object Identifier 10.1109/JIOT.2018.2874095 (e.g., IoT, AI, etc.).
2327-4662 c 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
BISWAS et al.: SCALABLE BC FRAMEWORK FOR SECURE TRANSACTIONS IN IoT 4651

TABLE I
1) Crypto BC: These are mainly intended for crypto cur- BASIC P ROPERTIES OF BC
rencies, which only allows virtual money transactions as
a replacement of physical money. The transaction struc-
ture is fixed which only carries information regarding the
amount of currency being traded. These are usually pub-
lic chains to improve transparency, but lately private crypto
chains have also become available. A miner is used for
transaction security, which solves a complex mathemati-
cal puzzle to ensure the security of blocks as well as
transactions.
2) Business BC: In contrast to previous ones, this newer
smart contract-based BC is being considered for a variety of
transaction types ranging from ubiquitous devices, real-time-
based operation management for industrial productions, and
intra-application data transfer including financial trades, etc.
These are mostly private or permissioned chains. Moreover,
instead of a miner, an orderer is used for ensuring delivery
guaranties and block creation.
For adoption of business BC with new application cases,
significant modifications are necessary to the generic BC
protocol.
In light of this, a new permissioned BC, Hyperledger has
been developed for a variety of networks. Hyperledger [10]
introduces six business frameworks: 1) Fabric [11]; 2) Burrow;
3) Iroha; 4) Sawtooth; 5) Indy; and 6) Quilt. Depending
on technological requirements and wide variety of consen-
sus algorithm [12], different frameworks can be utilized.
Hyperledger Fabric can be used as a foundation for developing
BC solutions targeted for IoT network. The basic compo-
nents of a permissioned BC architecture has been shown in Fig. 1. Permissioned BC: component interaction.
Fig. 1. BC network is formed through interconnection of peers,
where peers are independent servers. They are responsible
for validation and endorsement of transactions, and maintain risk of collusion and tampering); 2) reduced costs (remove
the distributed ledger. Validation and endorsement process are overhead associated with middlemen and intermediaries); and
mostly dependent on smart contract (chaincode) which must 3) accelerated transaction rate (reduced settlement time).
be installed on every endorsing peer. Basically, smart contract In order to merge IoT and BC, it is important to understand
is a programmatic code to define the transaction rule or policy how BC networks are formed. There can be two models for
in between sender and receiver. Successfully endorsed trans- IoT devices.
actions are stored as a block into a common ledger which is 1) Each IoT device becomes part of the BC network by
integrated with peers. Many transactions may fit into a single implementing a peer client on itself.
block which must be linked with the last block of the ledger by 2) A number of devices are grouped together (through a
hash value, which makes a chain of blocks. Quantity of trans- well defined mechanism), and use a single peer in global
actions per block and block forming time varies depending on BC to represent them.
orderer’s batch timeout configuration. Ordering is intended to The first solution cannot be used, as the resources (processing,
provide an atomic broadcast ordering service for consumption memory, etc.) required to become a peer, are not available in
by the peers. Orderer and membership service provider (MSP) most IoT devices. However, some devices such as automated
provide block creation and user services, respectively, to all machines, robots, etc., may have such capabilities and can
the peers in a business BC. Table I lists the key principles of become peers, but this would be a subset of all IoT devices.
BC system. The second solution is more plausible, but current BC net-
works do not implement such a mechanism. Even if such a
mechanism is provided, the scalability of existing BC net-
B. IoT and BC works is a major challenge. In order to get an understanding
It can be expected that the technology behind BC can of the scale, assume that 50 billions IoT devices generate on
serve as a basis to keep a ledger of IoT device’s transaction an average 5 transactions per day, which is well below what
logs and communications. IoT structure for device-to-device may happen in reality. The volume of transactions will be
(D2D) [13] systems, has been discussed in literature, hence approximately 250 billion per day. In a more realistic example,
extending it with BC will provide three key benefits: 1) trust assume a city municipality intends to run a central BC net-
(build trust between parties and devices and reduce the work for different governmental agencies (parking services,
4652 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 3, JUNE 2019

toll payment, etc.) in the city. Assume the number of agen- endorsement or a well defined device identification mecha-
cies is 50, and each agency has at least 10 peers, where each nism. Certain use cases may require a permission mechanism
peer controls 1000 devices or users. Hence, if every user or for such query mechanism. Moreover, the design puts extra
device generates 10 transactions per day, then from only one burden of transaction fee processing on manager node for mil-
agency there will be 105 transactions, and a total of 5 million lions of transactions per day, while being an external entity to
transactions per day from all agencies. BC network.
In light of this, there are two major issues in existing BC A lightweight scalable BC for IoT [16] is available
solutions: 1) transaction per second (TPS) and 2) ledger stor- online (unpublished) which introduces a centralized manager
age requirements. BC is fundamentally not designed for high known as block manager (BM), similar to hub, which pro-
transaction rates, as they will be in IoT. TPS issue has been vides a shared key among home devices and controls all
addressed to some extent with the release of Hyperledger incoming and outgoing transactions requests. Moreover, it
Fabric 1.0, as developers are allowed to customize their stores all the transactions locally. This paper does not elab-
endorsement policy and ordering services according to their orate how the transactions will be synchronized between
network requirements. But in any customized situation, gen- local BM and overlay BM. The storage and scalability
erated block will be added to the all peers. If the BC creates issues at higher levels are also not addressed. In [11],
single block for every 500 transactions then, it requires 23 GB IBM researchers show 3500 TPS in Hyperledger imple-
memory per day or ≈ 8.4 TB per year, where wight of a single mentation experiment. They also describe block size varia-
block with single transaction is at least 4.6 kB (based on our tion from 0.5 to 4.0 MB (depending on configuration and
experimental analysis). As the ledger data cannot be deleted endorsement policy). Although this paper does not discuss
or altered, hence this problem is magnified over time. In order reducing the overhead of block size, storage, and control-
to reap the security benefits of BC in IoT, the challenge of ling ledger scalability, it does show the need of improve-
efficient ledger size management and transactions per second ment in TPS, which is one of the objectives of this
scalability must be addressed. paper.
In this paper, we propose a BC-based framework for IoT, There are a handful of research works available which
for inter and intra organizational transactions where all IoT address the usage of BC in IoT, mostly as an applica-
devices have an association to an organization, through a regis- tion use case. In [17] a distributed BC-based secure SDN
tration process enabled by a local certification authority (CA). architecture for IoT has been proposed, to enable high-
In addition, rather than using a peer which is part of the global performance availability flow-rule tables in distributed BC.
BC network, we propose a local peer (Lpeer) structure to inter- It primarily discusses how IoT communication can benefit
act with an associated anchor peer in the global network. This from BC technology. Li et al. [18] proposed satellite chains
framework aims to solve two main issues: 1) indirect increase method for improving the transaction rate. Slock [19] explores
in TPS for the global BC network and 2) limit the geomet- how to address security, identity, coordination, and privacy
rical increase of ledger storage requirements at each peer. across millions of devices by making them autonomous
By using a localized peer for intraorganizational transaction without a middleman. BC-based intelligent transportation sys-
(while maintaining peer validation), the framework limits the tem [20], although not an IoT solution, discusses a seven
ledger size, and distributes it between Lpeer and anchor peer. layers conceptual model using BC, for large scale vehicu-
Interorganizational transactions are validated through global lar networks. Similarly, [21] proposes use of BC in smart
BC peer network, with 100% peer validation. grid for secure transactions. A Security framework for inte-
grating BC technology with smart devices has been proposed
in [22]. Filament [23] has proposed an open technology
stack that enables devices to discover, communicate, and
II. R ELATED W ORKS interact with each other autonomously and in a distributed
BC technology was designed and has been primarily lim- manner. In provenance [24], a proof of existence and trans-
ited to cryptocurrency solutions (e.g., Bitcoin, Ethereum, etc.). parency has been implemented in supply chain management
Hyperledger [10] aims to expand BC technology into business through BC.
networks. Fabric v0.6 for public use had scalability issues Work in [25] presents a proposal for ITU to build a decen-
which to some extent have been alleviated by Fabric v1.0. tralized framework for BC of things. This is an ongoing study,
It allows the transaction rate to reach 104 TPS, as peers can which highlights scalability, interoperability, and distributed
execute transactions in parallel [14]. In certain application sce- ledger as high level requirements. In order for different con-
narios, this increase may be satisfactory. But with the sheer sensus mechanisms to work, the IoT network as a whole
number of IoT devices, a much higher transaction rate is should be able to implement BC solution efficiently. It is
required. Moreover, the storage requirement of ledger is still important to note that most of the existing research related
an open research issue. to IoT and BC integration does not focus on scalability of
The work in [15], proposes a decentralized access man- ledger or improving the transaction rate. The prime motiva-
agement system for IoT, where access control information tion of this paper is to create a framework, which can be
is stored and distributed using a BC. By using a gateway implemented in IoT networks (irrespective of application sce-
called management hub, IoT is connected to BC network. The nario), and is scalable with respect to the number of IoT
architecture allows the IoT node to query BC node without devices.
BISWAS et al.: SCALABLE BC FRAMEWORK FOR SECURE TRANSACTIONS IN IoT 4653

on their application scenario. CA provides with authentica-

tion and registration of devices/users (device certification and
associated smart contracts) in the network. Lpeer works as a
localized peer for the organization, and provides interaction
with an anchor peer in the global BC network. It is impor-
tant to note that Lpeer and anchor peer are separate entities
with different functionality. This structure indirectly increases
the transaction rate of peers in BC, and directly improves the
ledger scalability of anchor peer.
3) Blockchain Network: In the global BC network, peers
are interconnected and every peer maintains its own ledger
and holds related smart contracts (chaincode). In the pro-
posed structure, the Lpeer communicates with a corresponding
peer in core (referred to as anchor peer) on behalf of appli-
cations (already authenticated by CA). The working of the
core BC remains the same. The anchor peer is responsible
for communicating with other peers (which may be working
as anchor peers for other organizations). As shown in Fig. 2,
Peer0 acts as an anchor peer and communicates with Lpeer.
Interorganizational transactions are done through the core net-
Fig. 2. Lpeer-based network model. work of anchor peers. It is also possible that the core BC peer
are directly connected to clients, and work as generic peers.

III. S CALABLE BC F RAMEWORK FOR I OT B. Local Peer Network: Design Details

The main objective of the framework is to enable BC scala- Implementation details of Lpeer and associated system ele-
bility in terms of ledger size and transaction rate. The overall ments is shown in Fig. 3. As described earlier, a single
goal is to save BC ledger from extra burden of millions of application instance represents an individual device which can
local transactions within enterprises or home networks. generate transactions. Anchor peer is part of the global BC
network. The rest of figure represents the complete Lpeer net-
work. Lpeer network is implemented at organizational level.
A. Working Principle and Network Model Although IoT devices are capable of D2D communication, but
The fundamental principle of the proposed scheme is that they cannot function without an association to some organi-
IoT devices should not be connected to a peer directly. By zation. For example, parking meters installed in a community
using an intermediate entity between devices and BC peers, can be IoT devices (and can generate transactions), but with-
the flow of transactions can be controlled. Moreover, all IoT out a parking services organization to maintain, collect data,
devices must have an association with an organization. This authenticate, etc., they will not function. Keeping this example
organization implements an Lpeer network, that segregates in perspective, the Lpeer network has the following elements.
transactions which remain within the network, from the ones 1) Certificate Authority: Certificate authority (CA) server is
which have to be processed by global BC. In the proposed a fully trusted entity and supports a range of credential certi-
framework, this principle is implemented by dividing the fication architectures. It is an integral part of the architecture,
network into three parts, as shown in Fig. 2. as there is no other entity in a BC network to provide cer-
1) Application: In global IoT infrastructure, billions of sen- tificates, signatures, and keys. It generates all certificates for
sors, actuators, and smart IoT devices are interconnected via administrator including certificates for user registration. All
Internet. These devices are controlled and managed by appli- user applications connect to CA for obtaining their encryp-
cations, either in the form of firmware or gateway applications. tion keys and signatures. Furthermore, it provides credential
In this model, we consider the application as a representation validation, signature generation and verification, and TLS-
of a thing. It is responsible to provide front-end interaction secured connections between all components of blockchain.
support with other network elements. As the format and struc- However, it is not responsible for access control directly.
ture of data generated by different applications is different, we Devices/applications have to implement that solution, and
assume that each application is capable of using a BC stan- many request it for signature verification only.
dard development kit (SDK) to create transactions and smart 2) Local Peer: Lpeer only works for the organizational
contracts. IoT devices. In the proposed framework, we divide the
2) Local Peer Network: In order for an organization to use Lpeer into Lpeer0 , Lpeer1 , to LpeerN , where Lpeer0 is the
BC, it must have at least one peer as part of the global BC net- main instance while all others are secondary instances geo-
work. Hence, we propose an Lpeer network, which comprises graphically distributed to remove a single point of failure.
of a CA and an Lpeer. The Lpeer network is implemented at Moreover, application scenarios where more than one peer is
organizational level, and groups a number of devices based desired for consensus in local transactions, secondary Lpeers
4654 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 3, JUNE 2019

Fig. 3. Lpeer network: subcomponent interaction.

can participate. Selective secondary Lpeers also maintain a SDK to format the data and transactional information from a
replica of ledger. All devices must register with Lpeer0 . variety of applications into a standard format.
It authenticates each device through CA and maintains 6) Smart Contract: Smart contract is a digital contract
an active list of users, their credentials, and smart con- which defines the terms and conditions of a transaction
tracts. Lpeer0 is the only instance which is allowed to between two devices. It is implemented in the form of chain-
read/write blocks into the ledger. Moreover it is also respon- code based on business model and asset definitions. This paper
sible for interacting with anchor peer for interorganizational uses the smart contract as they are defined for global BC
transactions. networks [26].
3) Orderer and Ordering Services: Orderer provides order-
ing services and may handle transactions of several Lpeers (if C. Transaction Structure and Processing
any). The main responsibility of orderer is to receive trans- 1) IoT Device Registration: In order to become part of
actions from the different applications/devices and fit into a the system, each IoT device must be registered with CA and
block according to the ordering algorithm’s batch instructions. Lpeer0 , in the sequence shown in Fig. 4(a). The registration
It stores a copy of all CA generated certificates and signa- with CA is the first step, where CA will provide the devices
tures. When any user invokes a transaction, orderer uses its with a unique signature, and encryption key pairs.
own certificates and signature for validation. It is important to The CA is responsible to create different certificates (i.e.,
note that orderer is not a miner. Orderer’s responsibilities are TLS CA, eCert, etc.), signature, public–private keys, and gives
specific to collecting transaction and creating blocks. Miner them to the device. Using these, it then registers with Lpeer0 ,
usually works in crypto currency blockchains for establishing which verifies the identity of requester from CA. During
reliability through proof-of-work consensus algorithms. the verification stage, Lpeer0 stores all credentials of devices
4) Ledger: It is a tamper-resistant and serialized record (i.e., TLS, CA certificates, and signatures) for future use of
of all transactions. Transactions are a result of chaincode verification. This process ensures that only authorized IoT
invocations submitted by participating parties within the orga- device can be part of the local BC network. Furthermore,
nization. Ledger is associated to Lpeer0 , who has permissions as the IoT device will also be part of the global BC net-
to read/write to it. Secondary peers may maintain an auto- work, where Lpeer0 registers devices with the anchor peer. The
updated replica of the ledger, which is used only if Lpeer0 local registration process follows Algorithm 1 to complete the
is out of service. In this paper, both Lpeer and BC use state device registration process. CA primarily generates and stores
database for maintaining logs for verification of successful the signature and cryptographic materials (e.g., certificates)
transactions. as response to device registration request (only if accepted).
5) SDK: In BC, SDK serves as a shim package to pre- When the device di is linked with Lpeer0 , then registration
pare the transaction proposal into well defined format by using ID for the device becomes Peerid . Deviceid , which is used for
user’s cryptographic credentials. In this proposal, we use the later transactions.
BISWAS et al.: SCALABLE BC FRAMEWORK FOR SECURE TRANSACTIONS IN IoT 4655

Fig. 4. (a) IoT device registration process. (b) Generic transaction format of Hyperledger.

Algorithm 1: Device Registration Algorithm 2: Device Authorization/Verification

Input : Device id di = (d1 , d2 , d3 .....dn ) Input : Requested (Peerid .did )
Output: Peerid .Deviceid Output: True or False
1 Set deviceid ← di 1 if [Peerid .did ]prefix ≡ Lpeer then
2 Set Peerid ← Lpeer
0 2 if sign(Lpeeradmin ) and sign(di ) is verified then
3 Request sign & certificates of di → CA 3 return True
4 if di (sign & certificates) then 4 else
5 di → Lpeer0 (sign(di ), di ) 5 return False
6 if Lpeer0 (sign(di )) then 6 end
7 Comment: Device di registered with Lpeer 7 else
8 return Peerid .Deviceid = Lpeer0 .di 8 return False
9 else 9 end
10 di sign or certificates is not valid
11 end
12 else
will sign a message Mi,j . di creates one private key integer
13 Request Cancel
dpi ∈ (1, n − 1) and one public key Q = dpi × G. Here, G
14 end
is a generator of the elliptic curve with large prime order n.
di choose any a random integer k ∈ (1, n − 1) and calculate
e = Hash(Mi,j ) and calculates the curve point as (x1 , y1 ) =
2) Transaction Processing: For every transaction received k × G where left most bit of e is z. Calculate r = x1 mod n
by Lpeer0 , it verifies if the transaction is coming from a valid and s = k−1 (z + rdpi ) mod n where r = 0 and s = 0. Finally,
user. If the devices is registered, then Algorithm 2 is used for the signature is the pair (r, s).
verification. Lpeer verifies and accepts the signature initially as valid,
Transaction proposal as message TPi,j (Mi,j ) is for- if (r, s) ∈ (1, n − 1), otherwise rejects. For validating, calcu-
warded from device (di ) to Lpeer PLpeer , where i = late Hash(m) with SHA − 1 algorithm and convert its result
1, 2, 3, . . . , n express the devices and j = 1, 2, 3, . . . , n to an integer e and w = s−1 mod n. Lpeer’s signature is
represents messages from each di . sk and pk denote pri- acknowledged as Lpack sign = (x1 , y1 ) = u1 G + u2 Q where
vate and public keys of device di , respectively. Similarly, u1 = z × w mod n and u2 = rw. Here, z is the left most
Lppk denotes public key and Lpsk the private key bit of e. The signature of di is accepted as valid if r ≡ x1
of Lpeer. Transaction proposal is created as TPi,j = (mod n). The signature (r, s) must be invalid if (r, s) = 0.
Encrypt(Lppk )[Signdi , SignAd (di ), Hash(Mi,j )] where Ad 3) Transaction Flow: In BC-based IoT, there are two
denotes admin of connected device in peer. Peer verifies the types of transaction from device perspective: 1) transactions
transaction proposal messages TPi,j and decrypts by the pri- among devices registered with same Lpeer and 2) transactions
vate key. After decrypting, it verifies the signature of device among devices registered with different Lpeers. The overall
Sign(di ) and Lpeer admin SignAd (di ) including all certificates. transaction flow is illustrated in Fig. 5. The proposed frame-
When all verifications are positive, Lpeer signs and sends a work is independent of transaction formats. Generic formats
positive response to the source application. of Hyperledger (with example) are shown in Fig. 4(b) for
Signature is the key security element of this registration reference.
processing mechanism. For generating and verifying the digital In the first scenario, where both devices are registered with
signature, it follows the following processes. Assume the di same Lpeer, intraorganizational transaction processing takes
4656 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 3, JUNE 2019

Fig. 5. Transaction information flow.

place. The transaction request from source is forwarded to ledger for transactions processed by the global network.
Lpeer0 through SDK along with the chaincode ID, where it is Hence, the division does not affect the working or trust
authenticated and evaluated. Transaction result is produced by among peers in BC.
executing chaincode and response values are set (as read/write • Ledger maintained by Lpeer is not private, but rather per-
value). These values and signature of endorsing peers are sent missioned. If an outside entity needs to obtain a specific
as proposal response, back to the application. The application organization’s internal transactions, they can access them
verifies the signatures of endorser and proposal responses and through the anchor peer. Only functional logic needs to
forwards the transaction to ordering service to be added to be implemented in peers to enable it.
the next available block. The orderer may receive endorsed • Lpeer0 is the only Lpeer which is allowed to write into
transactions from different applications concurrently. All con- the ledger. LpeerN can only be part of endorsement pro-
current transactions are added to a block according to the cess. The purpose of having multiple instances is to
orderer environment configuration variables. Orderer sends the enable scalability inside organizations, and have backup
block to the committing peers (Lpeers) to be added in their in case of Lpeer0 failure. All Lpeer instances cannot be
ledger, and a notification message to the application. allowed to write to a single ledger, as it will create syn-
In the second scenario, as the devices are not registered with chronization problems. Moreover, all of them should not
same Lpeer, hence anchor peer is used for global endorsement. have individual ledgers, otherwise the problem of global
The interorganizational transactions will follow generic core blockchain scalability will trickle down to organizational
BC network endorsement solution. Once the Lpeer determines level, defeating the main purpose.
that it should not endorse such a transaction request, it notifies • Unauthorized transactions might be performed in two
the source application, and forwards the request to anchor peer. ways: a) adding illegal peers or device in the network
Complete endorsement process is followed (similar to earlier or b) a legitimate device becoming rouge. For the first
case, but at global BC level), and result is returned directly case, we use a CA within the organization to tightly
to the application. A special scenario can occur where one monitor the addition of users (Algorithm 1), where as
of the devices does not conform to the proposed Lpeer struc- the addition of Lpeer is a controlled process by the net-
ture, or both devices do not conform. In either case, as the work administrators. Compromising an Lpeer does not
endorsement will be done at the global BC level, no special work for the benefit of hacker, as the BC principle of
processing is required by Lpeer. consensus involves multiple peers. Similarly, a legitimate
4) Design Implications: Before delving into the implemen- user going rogue, also cannot issue illegal transactions as
tation and evaluation details, here we elaborate on some of the Lpeer consensus will not approve them.
technical implications of the design.
• Transaction requests are divided between anchor peer and
Lpeer, which significantly reduces the load on peers (in IV. I MPLEMENTATION AND E VALUATION
global BC) both in terms of endorsement time required The objective of this paper is to enable BC scalability in IoT.
and ledger size. Moreover, CA and secondary Lpeers This is primarily done through better transaction execution rate
provide an additional safety net. and smaller ledger size at the peers. It is very important to
• Compared to traditional mechanism the ledger is now understand that, BC is an evolving technology, and so is IoT.
divided. This division is only for the transactions asso- The architectures of platforms available are rapidly changing,
ciated to the Lpeer organization. As far as global BC and will affect the evaluations. In the following section, we
peer network is concerned, anchor peer has the complete provide all possible details of the testbed used to evaluate the
BISWAS et al.: SCALABLE BC FRAMEWORK FOR SECURE TRANSACTIONS IN IoT 4657

transaction proposal at application level. By increasing the

number of concurrent transactions issued by applications, the
average TPS (proposal to acknowledgment) drops below 1 s.
In comparison, it takes approximately 1 h in bitcoin network
to complete the transaction.
Fig. 6 shows overall transactions (Tx) completion time
against increasing number of IoT devices and concurrent trans-
actions. The batch timeout (block closing) is set to 1 s for TPS
evaluation in this scenario. It is important to understand that
an IoT device with 5Tx per second makes 5 concurrent Tx.
Similarly, 50 IoT devices make 500 concurrent Tx (10Tx per
device per second). As mentioned in Section III, Lpeer is the
sole authority to separate the transaction path.
According to Fig. 6, for single IoT device, 1Tx takes
Fig. 6. Transaction scalability. ≈20 ms while for 10 transactions requires ≈57 ms. Likewise,
from 20 IoT devices, 20–200 concurrent transactions takes
≈75–222 ms, respectively. With 20 times rise of concurrent
proposed framework. It is necessary to discuss the technical transactions, the time requirement increases at a very slow
details, as minor configuration changes drastically change the pace. Finally, with 30–50 devices, network handles 30–500
performance in BC. concurrent transactions where it takes lowest ≈77 ms and
maximum ≈337 ms. We observe that the increase of trans-
A. Hyperledger Testbed Setup action completion is not sharp. The main reason is the Lpeer
structure which efficiently handles the volumes of Tx.
We have tested our proposal using Hyperledger Fabric
Once the transaction proposal has been generated, the aver-
(v1.0.2). The testbed comprises of two machines with fol-
age transaction time in Lpeer network is ≈1–10 ms, whereas
lowing specifications for emulating the topology: 1) 2.7 GHz,
in the global BC network it is ≈2–56 ms. We closely observe
Intel i-7, 16 GB 1600 MHz DDR3 and 2) 3.0 GHz, Intel i-5, 8
that transaction completion time (only BC and Lpeer level
GB 1600 MHz DDR3. The first machine emulates the Lpeer
excluding application level) is ≈1–56 ms.
network, while the second emulates the global BC. Ubuntu
TPS is highly dependent on proper setting of environment
container-based virtualization technique has been used to run
variables, which are dictated by the volume of transactions,
the peers. Node-red-based application generates continuous
size of individual transaction, log level, etc. During the exper-
transactions in JSON payload messages to Lpeer via smart
imentation it was observed that the processing time is impacted
contract. The Lpeer has one orderer and one peer organization
even by the trivial misconfiguration, example of which is, by
associated with it, with one channel and kafka ordering ser-
leaving the log visibility mode on for Hyperledger, the average
vice. For the global BC network, we have created four peers,
processing time increased from 20 to 32 ms.
with two controlling organizations. There is an ordering ser-
vice which connects to kafka-Zookeeper. Configtxgen tool has
been used for the creation of genesis block (first block of BC
without any hash for previous block), one channel (broadcast- C. Block Weight and Ledger Scalability Analysis
ing transaction to the orderer), and one anchor peer associated BC maintains a continuously growing list of ordered trans-
to the Lpeer. We also point to the location of MSP path for actions called blocks in the ledger. Each block number is
every member. Orderer defines configuration or structure of unique and is assigned sequentially starting from zero. Each
the transaction as, number of transactions per block, maximum block is linked with the previous block except genesis block.
size of a block, and maximum time to wait for transactions. In Every block has three sections: 1) header; 2) transaction
this setup for Lpeer, we adjust these values according to exper- information; and 3) metadata.
imental requirements (described later). We have used kafka
1) Individual Block Weight: The weight of the block refers
consensus algorithm for BC network.
to the memory required to store it. This is different than the
size of a block, which refers to the number of transactions
B. TPS Observations enclosed in a block. Furthermore, the contents of a block are
With billions of IoT devices generating transactions, the stored as a string (i.e., 4-byte integer may take more memory
rate of processing transactions has to be extremely fast at when converted). In our analysis, we have observed the actual
the peers. By design, the proposed framework isolates the weight of the ledger stored on the peer nodes, in order to obtain
organization-based local transactions, hence reducing the num- the real memory requirement. After a number of experiments,
ber of requests per peer. From experimentation we observed, on average the block weight observed was ≈4.6 kB with a
that for Lpeer network, time for generating each certificate for single transaction, endorsed by a single peer. This value is
user requires ≈3 ms. Although, for completion of a transaction highly dependent on the weight of transaction itself, number
(proposal to acknowledgment) it required ≈3 s. Close obser- of transactions in a block, and the number of endorsing peers
vations reviled that most of the time is consumed in generating for each transaction. As each endorser’s signature is added to
4658 IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 3, JUNE 2019

Fig. 7. Block weight for concurrent application transactions. Fig. 8. Scalability of ledger memory.

the transaction, hence the weight grows with the number of requires significantly less memory resources. Furthermore, as
endorsing peers. all the peers in BC network maintain copies of the same ledger,
2) Block Weight Versus Concurrent Transactions: As dis- hence the overall consumption is proportional to number of
cussed earlier, IoT devices will generate transactions at a much peers. With Lpeer, as there is only one ledger per organization,
higher rate as compared to current cryptocurrency transac- it becomes more scalable across different IoT domains.
tions. Hence, we analyze the effect on weight of block against
increasing number of concurrent transactions from applica- V. C ONCLUSION
tions. The batch timeout is 50 s (block closing time). This
Rapid spread of IoT devices has prompted a renewed
value is too high for production level systems, but it allows
search for security and privacy solution for data and users.
us to study the higher number of transactions in a block. The
Similarly, BC technology has emerged as a candidate for
maximum messages per batch is 2K and maximum weight per
secure transaction-based communications. In this paper, we
batch is 100 MB. The preferred maximum number of bytes
show that IoT and BC cannot be integrated, unless scalabil-
per message is set to 512 kB.
ity issues are addressed. The proposed framework creates an
Fig. 7 shows the graph for block weight against number
Lpeer network in order to allow BC ledger to scale across
of transactions issued by applications. The red line represents
all peers. The results obtained from implementation testbed
traditional BC architecture, and it almost grows sequentially
show that significant improvement in TPS and ledger weight
with the increase. The other two lines represent the block
can be achieved. This will allow better scalability of large
weights in the proposed framework generated by Lpeer and
scale business transactions in IoT, and will address the memory
anchor peer. It is important to note that the probability of
requirement issue to store the blocks. The current implementa-
transaction to be intraorganizational is 0.7. This probability
tion and evaluation has been done in part an virtual machines,
is realistic, as a parking meter is more likely to generate a
where the application is implemented in Node-red. As future
transaction with other parking service devices, and less likely
work, we plan to implement the solution in real world situa-
to exchange data with a temperature sensor. The block weight
tion, and evaluate using real time transactional data. Moreover,
increases for Lpeer and anchor peer, but not at the rate of
the solution proposed focuses only an scalability and resource
traditional BC architecture. Based on transacting parties, the
conservation, and uses existing transaction structures without
transactions are divided among Lpeer and anchor, hence reduc-
any optimization to them. It will be an interesting direction to
ing the block weights. Moreover the block weight for Lpeer
have either a unified transaction structure which is optimized
is relatively higher than that of anchor due to significantly
for different types of business chains, or specialized structures
more transactions per block. Although the anchor peer gets
but with interoperability among multiple chains.
less transactions to process, but validation by four peers adds
to the block weights. In production environments more peers
will be present hence increasing the weight of block for anchor R EFERENCES
peer. [1] J. Huang, C.-C. Xing, S. Y. Shin, F. Hou, and C.-H. Hsu, “Optimizing
3) Scaling of Ledger: Fig. 8 represents scalability of ledger M2M communications and quality of services in the IoT for sustainable
smart cities,” IEEE Trans. Sustain. Comput., vol. 3, no. 1, pp. 4–15,
in both frameworks. As blocks are added in sequential order, Jan./Mar. 2018.
hence block height refers to the number of blocks added to [2] Amy Nordrum. Popular Internet of Things Forecast of 50 Billion
Devices by 2020 Is Outdated. Accessed: May 31, 2018. [Online].
ledger. The memory shown is cumulative. Block 0 is the gene- Available: https://spectrum.ieee.org/tech-talk/telecom/internet/popular-
sis block and takes approximately 12 kB in most cases. Block internet-of-things-forecast-of-50-billion-devices-by-2020-is-outdated
[3] E. Luo, “PrivacyProtector: Privacy-protected patient data collection in
1 holds only instantiated data and contains 1 transaction. In IoT-based healthcare systems,” IEEE Commun. Mag., vol. 56, no. 2,
traditional BC network, from block 2 to block 11 memory pp. 163–168, Feb. 2018.
[4] J. Pan and J. McElhannon, “Future edge cloud and edge computing for
size increase is sharp. On the other hand, for the same num- Internet of Things applications,” IEEE Internet Things J., vol. 5, no. 1,
ber of transaction and blocks, proposed framework BC ledger pp. 439–449, Feb. 2018.
BISWAS et al.: SCALABLE BC FRAMEWORK FOR SECURE TRANSACTIONS IN IoT 4659

[5] H. Sun, Z. Zhang, R. Q. Hu, and Y. Qian, “Wearable communications in Kashif Sharif (M’08) received the M.S. degree in
5G: Challenges and enabling technologies,” IEEE Veh. Technol. Mag., information technology from the National University
vol. 13, no. 3, pp. 100–109, Sep. 2018. of Sciences and Technology, Islamabad, Pakistan,
[6] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. Accessed: in 2004, and the Ph.D. degree in computing and
May 31, 2018. [Online]. Available: http://bitcoin.org/bitcoin.pdf informatics from the University of North Carolina
[7] A. Lielacher. (2018). How Many People Use Bitcoin? at Charlotte, Charlotte, NC, USA, in 2012.
Accessed: May 30, 2018. [Online]. Available: https://
He is an Associate Professor (Research) with
www.bitcoinmarketjournal.com/how-many-people-use-bitcoin/
[8] M. Beck. Into the Ether With Ethereum Class. Accessed: May 31, 2018. the School of Computer Science and Technology,
[Online]. Available: https://grayscale.co/wp-content/uploads/2018/ Beijing Institute of Technology, Beijing, China. His
03/Grayscale-Ethereum-Classic-Investment-Thesis-August-2017.pdf current research interests include wireless and sensor
[9] A. B. D. Schwartz and N. Youngs. The Ripple Protocol networks, network simulation systems, software-
Consensus Algorithm. Accessed: May 31, 2018. [Online]. Available: defined networks, data center networking, information centric networking, and
https://ripple.com/files/ripple_consensus_whitepaper.pdf blockchain technologies.
[10] Hyperledger. Hyperledger Business Blockchain Technologies. Accessed:
May 31, 2018. [Online]. Available: https://www.hyperledger.org/projects
[11] E. Androulaki et al., “Hyperledger fabric: A distributed operating sys-
tem for permissioned blockchains,” in Proc. 13th EuroSys Conf., 2018,
pp. 1–30. Fan Li (M’12) received the B.Eng. and M.Eng.
[12] C. Cachin and M. Vukolic, “Blockchain consensus protocols in
degrees in communications and information sys-
the wild,” CoRR, vol. abs/1707.01873, 2017. [Online]. Available:
http://arxiv.org/abs/1707.01873 tem from the Huazhong University of Science and
[13] C. Xu, C. Gao, Z. Zhou, Z. Chang, and Y. Jia, “Social network-based Technology, Wuhan, China, in 1998 and 2001,
content delivery in device-to-device underlay cellular networks using respectively, the M.Eng. degree in electrical engi-
matching theory,” IEEE Access, vol. 5, pp. 924–937, 2017. neering from the University of Delaware, Newark,
[14] M. Vukolić, “Rethinking permissioned blockchains,” in Proc. ACM DE, USA, in 2004, and the Ph.D. degree in com-
Workshop Blockchain Cryptocurrencies Contracts, 2017, pp. 3–7. puter science from the University of North Carolina
[15] O. Novo, “Blockchain meets IoT: An architecture for scalable at Charlotte, Charlotte, NC, USA, in 2008.
access management in IoT,” IEEE Internet Things J., vol. 5, no. 2, She is currently a Professor with the School of
pp. 1184–1195, Apr. 2018. Computer Science, Beijing Institute of Technology,
[16] A. Dorri, S. S. Kanhere, R. Jurdak, and P. Gauravaram, “LSB: Beijing, China. Her current research interests include wireless networks, ad
A lightweight scalable blockchain for IoT security and pri- hoc and sensor networks, and mobile computing.
vacy,” CoRR, vol. abs/1712.02969, 2017. [Online]. Available:
http://arxiv.org/abs/1712.02969 Dr. Li was a recipient of the Best Paper Award of IEEE MASS in 2013,
[17] P. K. Sharma, S. Singh, Y.-S. Jeong, and J. H. Park, “Distblocknet: A dis- IEEE IPCCC in 2013, ACM MobiHoc in 2014, and Tsinghua Science and
tributed blockchains-based secure SDN architecture for IoT networks,” Technology in 2015. She is a member of the ACM.
IEEE Commun. Mag., vol. 55, no. 9, pp. 78–85, Sep. 2017.
[18] W. Li, A. Sforzin, S. Fedorov, and G. O. Karame, “Towards scalable
and private industrial blockchains,” in Proc. ACM Workshop Blockchain
Cryptocurrencies Contracts, 2017, pp. 9–14.
[19] Slock: Secured Lock. Accessed: May 31, 2018. [Online]. Available: Boubakr Nour (GS’17) received the B.Sc. and
https://slock.it/technology.html M.Sc. degrees (with distinction) in computer sci-
[20] Y. Yuan and F.-Y. Wang, “Towards blockchain-based intelligent trans- ence from Djillali Liabes University, Sidi Bel Abbes,
portation systems,” in Proc. 8th Int. Conf. Intell. Transp. Syst., 2016, Algeria, in 2014 and 2016, respectively. He is
pp. 2663–2668. currently pursuing the Ph.D. degree in computer
[21] F. Gao et al., “A blockchain-based privacy-preserving payment mech-
anism for vehicle-to-grid networks,” IEEE Netw., to be published, science and technology at the Beijing Institute of
doi: 10.1109/MNET.2018.1700269. Technology, Beijing, China.
[22] K. Biswas and V. Muthukkumarasamy, “Securing smart cities using He has been a Visiting Researcher with Paris
blockchain technology,” in Proc. Int. Conf. High Perform. Comput. Descartes University, Paris, France, in 2016. His
Commun., Dec. 2016, pp. 1392–1393. current research interests include next-generation
[23] “Security overview: Networking devices at the edge of risk,” networking and Internet, information-centric net-
Reno, NV, USA, Filament, White Paper, 2017. Accessed: May 31, working, named data networks, mobile/edge computing, Internet of Things,
2018. [Online]. Available: https://filament.com/assets/downloads/ and wireless sensor networks.
Filament%20Security.pdf Mr. Nour was a recipient of the Excellent Student Award at the Beijing
[24] “Blockchain: The solution for transparency in product supply chains,” Institute of Technology in 2016 and 2017.
London, U.K., Provenance, White Paper, 2015. Accessed: May 31, 2018.
[Online]. Available: https://www.provenance.org/whitepaper
[25] X. Jia et al., “Framework of blockchain of things as decentral-
ized service platform,” Int. Telecommun. Union, Geneva, Switzerland,
ITU-T Recommendation SG 20-TD779, 2018. Accessed: Sep. 7,
2018. [Online]. Available: https://www.itu.int/md/T17-SG20-180506- Yu Wang (M’01–SM’10–F’18) received the B.Eng.
TD-GEN-0779/en and M.Eng. degrees in computer science from
[26] I. O. Kennedy, C.-K. Lin, and V. Venkateswaran, “A cross layer design Tsinghua University, Beijing, China, and the Ph.D.
and evaluation of IEEE 802.15.4 network with an enhanced sensor gate- degree in computer Science from the Illinois
way: Injecting hierarchy into wireless sensor networks,” in Proc. IEEE Institute of Technology, Chicago, IL, USA.
Int. Conf. Commun., Jun. 2013, pp. 1694–1699. He is a Professor of computer science with the
University of North Carolina at Charlotte (UNC
Charlotte), Charlotte, NC, USA. His research has
been continuously supported by federal agencies
including the U.S. National Science Foundation, the
Sujit Biswas (GS’17) received the M.Sc. degree U.S. Department of Transportation, and the National
in computer engineering from Northwestern Natural Science Foundation of China. He has authored or co-authored over
Polytechnical University, Xi’an, China, in 2015. 150 papers in peer-reviewed journals and conferences. His current research
He is currently pursuing the Ph.D. degree at the interests include wireless networks, mobile social networks, smart sensing,
Beijing Institute of Technology, Beijing, China. mobile crowd sensing, mobile computing, and algorithm design.
He is also an Assistant Professor with the Dr. Wang was a recipient of the Ralph E. Powe Junior Faculty Enhancement
Computer Science and Engineering Department, Awards from Oak Ridge Associated Universities in 2006, the Outstanding
Faridpur Engineering College, University of Dhaka, Faculty Research Award from the College of Computing and Informatics,
Dhaka, Bangladesh. His current research interests UNC Charlotte, in 2008, and the Overseas Young Scholars Cooperation
include IoT, blockchain, and mobile computing Research Fund from NSFC in 2014. He was also the recipient of four Best
security and privacy. Paper Awards. He is a Senior Member of the ACM.