Blockchain: Research and Applications 1 (2020) 100004

Contents lists available at ScienceDirect

Blockchain: Research and Applications

journal homepage: www.journals.elsevier.com/blockchain-research-and-applications

Short Communication

Blockchains for constrained edge devices

Antonyo Douglas a, Richard Holloway b, Jonathan Lohr a, Elijah Morgan b, Khaled Harfoush a, *
a
Department of Computer Science North Carolina State University Raleigh, NC, 27606, USA
b
Department of Electrical and Computer Engineering North Carolina State University, Raleigh, NC, 27606, USA

A R T I C L E I N F O A B S T R A C T

Keywords: Today’s networks are seeing a large influx of Internet connected devices that reside primarily on the edge of the
Blockchains network. Many of these devices, such as Internet of Things (IoT) devices, are resource constrained both by storage
Internet of Things capacity and power requirements that limit a device’s Internet availability. Several interesting architectures have
Wireless Communication
been proposed to address security, device management, configuration, and multi-party interaction concerns using
blockchain technology. These architectures require a trusted intermediary to interact with the blockchain on
behalf of the edge device. This introduces a single point of failure in trust and security. This paper proposes a
novel adaptation of blockchain technology to enable these edge devices to interact and participate with a
blockchain without requiring a trusted intermediary. The proposed architecture provides a flexible and extensible
framework that enables multi party interactions to take place at the edge of the network. The efficacy of the
proposed design is demonstrated through theoretical analysis and by an application to a network of resource
constrained IoT devices.

1. Introduction existing blockchains were designed for cryptocurrencies.

In recent years, the number of devices connected to the Internet has
exploded. It is anticipated that there will be 21 billion Internet of Things
(IoT) devices by 2025 [1]. IoT devices are manufactured for a variety of
applications and with a wide variety of capabilities. For many applica-
tions, IoT devices are constrained in their processing, memory and power
resources. This makes it difficult to create a single network connectivity
model and/or a single security model applicable to all systems and leaves
manufacturers to make up their architecture as they go.
In the meantime, the use of blockchains for non-cryptocurrency ap-
plications has grown in popularity in recent years [2–7]. Blockchain as a
technology provides multiple benefits, the most important of which is its
decentralized trust (any one can participate even if they are not fully
trusted), its immutability (blocks within the chain cannot be changed
without breaking the chain), its auditability (anyone can verify that the
history of the entire chain is correct), and its distributed nature (removes
the possibility of a single point of failure). These advantages make
blockchains attractive for many applications, and IoT applications are no
exception. There are a plethora of IoT applications that can benefit from
blockchain technology including supply chain logistics, device configu-
ration, and device management. These applications struggled, because
A variety of approaches were adopted to accommodate devices with
constrained resources in blockchain systems. One proposal is to split
devices based on their resources into classes (miner nodes, full nodes and
light nodes). The contribution of a device to the blockchain system de-
pends on its class. Miners are responsible for creating and verifying new
blocks. Full nodes do not perform mining, but download every block,
verify every transaction and maintain an accurate state database of the
blockchain network. Light nodes only perform enough tasks in the
network to create and verify the validity of the transactions it cares
about. Participation in a blockchain network, even as a light node, re-
quires significant computational capability, a large amount of non-
volatile storage, and a constant and high-bandwidth Internet connection.
A second approach to accommodate constrained devices in block-
chain networks is to have them rely on Trusted Interme-diaries (TI) [4,5].
The TI interacts with the blockchain as a full or light node on behalf of the
constrained edge devices. Edge devices must trust this intermediary,
which creates a single point of failure and negates many of the benefits
that a blockchain provides by breaking the decentralized trust, immu-
tability, and distributed model.
Another approach that is promising more lightweight blockchain
operations, which can benefit constrained devices is to rely on Proof-of-

* Corresponding author.
E-mail addresses: adougla@ncsu.edu (A. Douglas), rphollow@ncsu.edu (R. Holloway), jclohr2@ncsu.edu (J. Lohr), ejmorga2@ncsu.edu (E. Morgan), kaharfou@
ncsu.edu (K. Harfoush).

https://doi.org/10.1016/j.bcra.2020.100004
Received 27 August 2020; Received in revised form 12 December 2020; Accepted 12 December 2020
2096-7209/© 2020 The Authors. Published by Elsevier B.V. on behalf of Zhejiang University Press. This is an open access article under the CC BY-NC-ND license
(http://creativecommons.org/licenses/by-nc-nd/4.0/).
A. Douglas et al.
Stake (PoS) rather than Proof-of-Work (PoW). Both PoS and PoW are
consensus mechanisms used to validate transactions that take place on a
blockchain, without the need for a third party. In PoW [8–10],
transactions are validated by miners through brute-force (trial-and-
error) to solve complex cryptographic puzzles. The first miner that solves
the puzzle is rewarded. Solving these complex puzzles requires high-end
computational resources, leads to high energy consumption and long
delays before blocks are committed to a blockchain. Furthermore, PoW
leads to a fairness problem as the miner with the most resources will
likely be the one rewarded. Also, there is a chance for one entity to
control more than 51% of the total mining power, enabling this entity to
make changes to blockchain blocks. Unlike PoW, in PoS systems [11–14],
validator nodes put at stake (on hold) some number of system coins and
earn a transaction fee for a validated block probabilistically in proportion
to the fraction of system coins they have at stake.
The more you stake the more likely you earn. The validation step is
not as complex as in the PoW case (no trial-and-error) and thus validation
is more time-efficient and more energy-efficient. While miners with
higher stake are likely to earn more (the rich gets richer), the probabi-
listic PoS model is more fair that the PoW model and an entity with high
stake cannot monopolize the network.1 PoS blockchain systems are thus
more suitable for constrained IoT devices than PoW systems.
In this paper, we make the following contributions: We introduce a
PoS Blockchain suitable for Constrained edge Devices (BCD). In BCD,
constrained devices do not rely on a TI and are able to get data from the
blockchain in a verifiable manner and the trust model rests solely on the
blockchain. The assurance provided by the blockchain is well studied
[15,16] and can be proven. The BCD solution reduces the load on edge
devices and enables edge devices to query the blockchain at will without
having to snoop on blocks for relevant transactions. This is particularly
important for IoT devices that are primarily constrained by power con-
sumption related to transceiver on time. For these devices a 50%
reduction in overhead could represent months of additional operation
time. In general, BCD adds to the overhead of blockchain full nodes and
to the blockchain storage needs in order to reduce the overhead at the
constrained edge nodes when downloading relevant transactions. Ex-
periments results reveal the potential savings for constrained devices
attained by BCD over Tendermint and Cosmos [14], state of the art
blockchain solutions for IoT devices.
The rest of this paper is organized as follows: In Section 2, we survey
research efforts aimed at supporting IoT setups with blockchains. In
Section 3, we provide background information about building blocks
used in the BCD proposal. In Section 4, we introduce the details of the
proposed BCD model. In Section 5, we compare the performance of BCD
to a vanilla Tendermint/Cosmos setup. In Section 6, we discuss BCD
limitations and challenges. We finally conclude in Section 7.
2. Related work
Efforts aimed at supporting the IoT using Blockchains vary in their
contributions. In Ref. [17], Dinh et al. compare the performance of slow
PoW blockchains to more efficient blockchains based on Byzantine
consensus. In Ref. [18], Danzi et al. study the problem of efficiently
disseminating authenticated blockchain information from blockchain
nodes (servers) to IoT devices, by multicasting block headers together
with the signatures of servers. Through a wireless base station (BS).
This proposal is based on the observation that if devices are connected to
the same blockchain network, they are likely to be interested in receiving
the same information (blocks or block headers). In Ref. [19], Niya et al.
extend BAZO [20], a PoS based blockchain, to better meet the demands
1
Monopolizing the network would not make financial sense since increasing
an entity’s stake will end up costing the entity more than it can gain from the
attack. Also, once malicious behavior is detected, the malicious node will lose all
its stake.
2
Blockchain: Research and Applications 1 (2020) 100004
of IoT setups. Specifically, they propose to use sharding techniques [21]
to validate transactions in parallel, reduce the signature size, and rely on
one signature to commit multiple packets in the same transaction. In
Ref. [22], Katende relies on a distributed Proof-of-Authority (PoA)
consensus to validate IoT transactions. Trusted validators, distributed in
the network, are responsible for keeping the network decentralized and
secure. In Ref. [23], Han et al. study the performance of consortium
blockchains such as Hyperledger Fabric (HLF) [24] and Ripple [25]
using the Byzantine Fault Tolerant (BFT) State Machine Replication
(BFT-SMaRt) [26] and Ripple consensus [27] protocols and motivate the
need for a scalable variant of the classic Byzantine consensus problem in
blockchains supporting IoT setups. Their results show that the perfor-
mance of blockchains degrades significantly with the increase in the
number of devices, a prominent characteristic of IoT setups.
The idea behind the proposed BCD architecture is orthogonal to
existing proposals and can complement them to further enable blockchain
support for IoT setups without straining constrained IoT devices and
without sacrificing system security. Specifically, BCD further reduces the
load and the on time of edge devices for consortium blockchains, which
are characterized by a relatively small number of validators [28,29].
3. Building blocks
3.1. Byzantine Fault Tolerance
A Byzantine fault is a condition of a system where components
may fail and there is imperfect information on whether a compo-
nent has failed. The term takes its name from the Byzantine Generals
Problem used to describe a situation in which, in order to avoid
catastrophic failure of the system, the system’s actors must agree on a
concerted strategy, but some of these actors are unreliable. BFT [30]
is an efficient partially synchronous consensus algorithm able to
tolerate 1/3 of the nodes behaving arbitrarily. In BFT, each node has
the same weight.
3.2. Merkle proofs
Merkle proofs are used to prove the inclusion of a data element in a
data set without revealing either the set or the element. Merkle proofs
make use of one-way cryptographic hashing, and arrange hashes of data
elements into a Merkle tree in which a leaf node represents the hash
value of an element, and an internal node represents a hash of the con-
catenation of the values of its children – Refer to Fig. 1 for an example.
Let Ti be a data element (blockchain transaction), Hi be the corresponding
hash value, and Hij be a hash to of a concatenation of Hi and Hj. In order to
identify whether T5 is included in a data set (blockchain block) storing
the transactions T1 through T8, a device is provided, in addition to H5,
with H6, H78, H1234, and H12345678 (Merkle root value). The device starts
by computing values for H56, then H5678, then H12345678 and matches the
result to the given Merkle root value. If they match, then T5 is assumed
included in the block. Demonstrating that a leaf node is a part of a given
binary hash tree requires computing a number of hashes proportional to
the logarithm of the number of leaf nodes of the tree; this contrasts with
hash lists, where the number is proportional to the number of leaf nodes
itself.
3.3. Tendermint
Tendermint [14] is a consensus engine together with an API used to
build blockchain applications. As opposed to classical BFT, in Tender-
mint, nodes have a non-negative, possibly different amount of voting
power, and nodes with positive voting power are called validators. Val-
idators are identified by their public key and participate in the consensus
protocol by broadcasting cryptographic signatures, votes, on block
headers to agree on the next block in a blockchain. The main benefit of
Tendermint over traditional BFT is that Tendermint has a simplified
A. Douglas et al. Blockchain: Research and Applications 1 (2020) 100004

Fig. 1. Merkle tree example.

underlying structure where transactions are batched into blocks and

blocks must commit in order. The batching of transactions into blocks
allows for regular Merkle-hasing of the application state, rather than
periodic digests as with BFT's checkpointing scheme. This allows for
faster provable transaction commits for light-clients and faster inter--
blockchain communication.
A Tendermint block contains in addition to a header, the signatures of
the validators on the block header and a list of transactions – Refer to
Fig. 2. The block header contains the Merkle root for the transactions in
this block.
Voting for consensus on a block proceeds in rounds. Each round has a
round-leader or a proposer, who proposes a block. The validators then
vote, in stages, on whether to accept the proposed block or move on to
the next round. Voting for a block by a validator is basically signing the
block header which contains a Merkle root for the transactions. Ten-
dermint relies on super-majority ( > 2/3) voting for consensus; i.e.,
1/3
voting power must be byzantine to pose a security risk.
Light-nodes are required to listen for blocks in the same manner as
full-nodes. The major difference is the amount of data the light-client is Fig. 2. Tendermint block.
expected to save. A light-node device is only expected to deal with a block
when it contains a transaction of interest to the device instead of
handling every transaction in every block. When a block contains a
transaction that the light-client needs it downloads the transaction in ad-
dition to the block header, which contains the Merkle root, the signatures
of the validators on the block header, the hashes that are part of the
Merkle proof. With this information at hand, a light-node can validate the
transaction by first verifying the validators’ signatures on the block
header, then carrying the Merkle proof. If the computed Merkle root
matches the Merkle root provided in the block header then the trans-
action is considered valid.
Tendermint’s API is known as the Application BlockChain Interface
(ABCI) and allows the application to be written in the language of the
designers’ choosing, not just Go, which is the language Tendermint Core
is written with, and enables the application to determine the weight of a
validator’s vote.
Fig. 3. Cosmos network. Hasing of the application state, rather than periodic
digests as with BFT’s checkpointing scheme. This allows for faster provable
3.4. Cosmos transaction commits for light-clients and faster inter-blockchain communication.
BFT: Byzantine Fault Tolerance, BCD: Blockchain suitable for Constrained
Cosmos [14] is a network of independent parallel blockchains that are edge Devices.
each powered by consensus algorithms like Tendermint. The first
blockchain in the Cosmos network is the Cosmos hub, which connects to 4. BCD model
the other blockchains (or zones) – Refer to Fig. 3. The Cosmos hub tracks
numerous token types and keeps track of the total number of tokens in The BCD model aims at harnessing the benefits of blockchain tech-
each zone. With the help of the hub, tokens can be transferred between nology and expands its practicality to a new class of devices, mainly to
zones without the need for a liquid exchange. The Cosmos architecture constrained IoT devices. BCD leverages the Tendermint consensus, PoS
promotes scalability and interoperability. algorithm, and intersects well with Tendermint and Cosmos. As such,
BCD would be a zone of Cosmos for devices requiring its low overhead.

3
A. Douglas et al. Blockchain: Research and Applications 1 (2020) 100004

The BCD architecture is shown in Fig. 4.

At its core, BCD adds the following features compared to vanilla
Tendermint: (1) Validators sign each transaction in each block, rather
than just sign block headers. Fig. 5 provides an example of a transaction
signed by validators. (2) Edge devices can query the blockchain network
using a BCD API and a BCD addressing scheme to download the trans-
actions of interest, rather than snoop on committed blocks to identify
relevant transactions. We next describe more details about the func-
tionality of validators and edge devices in BCD.
While the additional transaction signatures make the blocks heavy, it
is not a significant problem for server-like devices with near infinite
power and bandwidth, and as we further elaborate in Section 5, this
feature reduces the size of the packets that are downloaded by edge
devices from the blockchain without incurring extra processing overhead
to the edge devices. Weight is added both in terms of the additional in-
formation being passed around the network, as well as adding additional
computational burden to sign the transactions. The full nodes are still
required to listen for and validate the pre-commit block votes, but prior
to committing the block they also have the responsibility of concate-
nating the signatures associated with each transaction – Fig. 5.
Edge devices are pre-populated with the public keys of validators, and
through the BCD API and addressing scheme, can download a transaction
together with the set of signatures of the validators on the transaction,
rather than the block header, the signatures on the header and the Merkle
hashes in Tendermint. A downloaded transaction can be validated by
checking whether at least 2/3 of the validators have signed the trans-
action, without exercising a Merkle proof test. Furthermore, validators
can be audited. Any entity can begin requesting blocks from the block-
chain from the genesis block to the current one. This entity can inde-
pendently verify and audit that each transaction has been correctly
verified and all rules are followed. This enables an enterprise partici-
pating in the blockchain to verify that all validators are acting according
to the contract they signed. If a validator is caught acting maliciously
they can be penalized by being dropped from the list of viable validators
and/or pursued outside of the confines of the blockchain network – Refer
to Section 6. This limits the ability of an attacker to disrupt the block-
chain. As such, validators are semi-trusted parties in BCD.
In a traditional Tendermint, an edge device is required to listen for
every block to determine if any of the transactions it contains affects its
state. In BCD, an edge device can retrieve relevant transactions (docu-
ments/code) at any time without the need to keep up with every block
being exchanged in the network. This enables IoT devices to sleep for
longer periods and reduces their on time. This method provides the
added benefit of allowing edge device managers to send signed trans-
actions to an edge device at regular intervals. These features combine to
give the device control over when and how to use its battery. The
retrieval of relevant transactions relies on BCD’s API and addressing
scheme, which we discuss next.
Fig. 4. BCD overall system view. IoT: Internet of Things, BCD: Blockchain
suitable for Constrained edge Devices.
Fig. 5. A transaction signed by validators.
BCD includes a notional design for a lightweight API that constrained
devices can utilize. The API is designed with the lowest end device in
mind, but also so that it can scale to be used for enterprise level appli-
cations. The API consists of simple GET/PUSH methods to request data at
a specific blockchain address and to post a transaction to a specific
blockchain address. Towards this end, the blockchain has two types of
addresses, entities and data. An entity is a public-private key pair with
the hash of the public key acting as the address. Data is a generic type of
address that could be used to store binary data or a smart contract. The
entity address is used to store certain types of information, such as cur-
rent balance, contact information, etc. The BCD code is available to
download from Ref. [31].
To recap, BCD benefits edge devices by offering direct access to
transactions of interest and by dealing with smaller packet sizes, at the
cost of larger block sizes to be maintained by the blockchain and higher
block voting cost. We next quantify the differences between BCD and
vanilla Tendermint.
5. Performance evaluation
In this section, we compare the performance of BCD to vanilla Ten-
dermint through theoretical analysis and actual experiments. The ex-
periments rely on a Go application in a Cosmos zone running on
Tendermint, and aim at measuring the overhead incurred by the BCD
network, and the performance gain and reduction in overhead for edge
devices. Edge devices have a download rate of 16 kbps, which is repre-
sentative of an LTE Cat NB1 under somewhat poor conditions or a general
low power/low bandwidth device. A device of this caliber and the micro-
controller that drives it draws 55 mA combined. The collected metric
values are averages over more than 1000 runs of the application.
Terminology. Let v be the number of validators, n be the number of
transactions per block, z be the transaction size in bytes, and s the size of a
signature in bytes. Let h is the size of the block header in bytes, and is
typically 632 bytes. Each signature by a validator is an Ed25519 and thus
s ¼ 64 bytes. Furthermore, let x be the number of bytes needed to store
the hash value of a transaction needed for a Merkle proof. Assuming
SHA256, then x ¼ 32 bytes. Note that log2 n transaction hashes are
needed to carry the Merkle proof.
Block Size. Let bT and bB be the block sizes in bytes in the case of
Tendermint and BCD, respectively. bT and bB can be expressed as

4
A. Douglas et al.
bT ¼ h þ nz þ υs (1)
bB ¼ h þ nz þ υs þ nυs (2)
B T
The extra nvs term in b compared to b represents the extra overhead
in the size of each block in the BCD case where each validator also signs
each transaction, and contributes to the overall blockchain size with the
overhead growing as the numbers of blocks in the blockchain grows.
Fig. 6(a) plots bB/bT for different number of (power of two) validators, v,
and for different values of the transaction sizes, z, when n ¼ 1024
transactions per block. The trend from the figure is clear: BCD contributes
to larger block sizes on the blockchain network, and this overhead in-
creases as v increases. The relative overhead in block size is more pro-
nounced for smaller transaction size, z.
Block Voting Time. Let tT and tB be the time in secs for the validators
to verify the transactions in a block and vote for (sign) the block in
Tendermint and BCD, respectively. In the Tendermint case, each vali-
dator only signs the block header; while in the BCD case, it also signs each
transaction in the block. tT and tB are thus proportional to the number of
signatures that need to be computed and can be expressed as follows
tT / υ (3)
t B / ðυ þ nυÞ (4)
We conducted experiments to measure the time it takes a validator to
Fig. 6. Comparison between BCD (Blockchain suitable for Constrained edge
Devices) and Tendermint block (a) and packet sizes (b), for different number of
(power of two) validators, v, and different transaction sizes, z, with n ¼ 1024
transactions per block.
5
Blockchain: Research and Applications 1 (2020) 100004
vote on (verify transactions and sign) a block header. The time to verify a
transaction is negligible and it takes a validator on average 72 μs to sign a
block on a PC (Intel Core i3-4130/3.40 GHz CPU). BCD adds overhead to
voting and instead of having a validator sign just the block header, the
validator will also sign each transaction in the block.
Packet Size. Let pT and pB be the size of the packets in bytes down-
loaded by edge devices in Tendermint and BCD, respectively. In the
Tendermint case, a packet consists of (1) a block header which includes
the Merkle root, (2) the signatures of the validators on this header, (3) a
transaction of interest, and (4) the transaction hashes need for the Merkle
proof. In the BCD case, a packet only consists of (1) a transaction of in-
terest and (2) the signatures of the validators on this transaction. pT and
pB can be expressed as
pT ¼ h þ z þ υs þ xlog 2 n (5)
pB ¼ z þ υs (6)
Fig. 6(b) plots pB/pT for different numbers of validators, v, and for
different values of the transaction sizes, z, when n ¼ 1024 transactions
per block. BCD leads to much smaller packet sizes than Tendermint, a
reduction of 50% in packet size relative to Tendermint can be seen when
n ¼ 1024 and z ¼ 512. The reduction in packet size becomes evident for
small transaction size (an expected feature of IoT devices). As the number
of validators increases, the gain from BCD fades. However, there is a clear
space where BCD can excel. The reduction in packet size benefits con-
strained IoT devices and allows them to conserve their energy by sleeping
for longer periods of time.
Packet Processing Time. Let T T and T B be the time it takes edge
devices to (1) download a packet, (2) parse the packet to extract the
signatures, and (3) verify the signatures for Tendermint and BCD,
respectively. The download time depends on the size of the packet and
the download rate. The parsing time depends on the hardware used, the
parser selected and the size of the objects being parsed. The time to verify
signatures depends on the hardware being used. Still, T T and T B are
proportional to the number of signatures that need to be validated and
can be expressed as follows
TT / υ (7)
TB / υ (8)
T
Note that signature verification time in T is consumed in validating
the v signatures on the block header and in the Merkle proof to validate
the transaction enclosed in the packet, while T B is consumed in verifying
the v signatures on the transaction of interest as BCD does not perform
the Merkle proof at edge devices.
In order to understand how packet parsing and signature verification
contribute to the overall packet processing time and to identify whether
these operations are viable to run on a constrained micro-controller, we
ran experiments to capture baseline values for the parsing time and the
signature verification time. A lightweight parser, JSMN (pronounced
“jasmine”), was selected [32]. JSMN is written in C and is intended to be
minimalistic which is ideal for many micro-controllers. A JSMN imple-
mentation was used to parse JSON objects with different numbers of
transaction/signature pairs, where the transactions size is z ¼ 1000 bytes
and the signature size is s ¼ 64 bytes. The parsing function was enclosed
in a loop and executed 10,000 times and the average time to parse 16
signatures were found to be 13.15 μs. In our experiments, a signature
verification takes on average slightly less than 1 s and as much as 3 s in
some cases, depending on the specific micro-controller, what algorithm is
used, and whether hardware acceleration is utilized. Similar results were
found in Ref. [33] although with some outliers on the order of 6 s. The
experiments in Ref. [33] we carried on Cortex-M ARM processors which
offer limited CPU and memory capabilities. For a base comparison, we
use 1 s as the average time to verify one signature. Furthermore, In order
to assess the computational burden of a Merkle proof in Tendermint, we
A. Douglas et al.
downloaded a reference implementation and a five-level (height is 4)
Merkle tree was specified. The code to build the Merkle tree was put into
a loop that executed 100,000 times. The average time to execute the
Merkle proof was approximately 8 μs.
These results highlight the fact that packet download time and the
signature verification time are the dominant factors in packet processing
time, and that the cost of parsing and executing the Merkle proof is
relatively small. This leads to almost matching signature parsing and
verification times for both Tendermint and BCD. However, the packet
download time in BCD is significantly smaller than in Tendermint, which
is critical for many low-power IoT devices.
Many micro-controllers require on the order of 5 milliamps in full
operational mode. A small RF receiver could easily require 50 milliamps.
For example, from Fig. 6(b), with a reduction of 50% in packet size
relative to Tendermint, a receiver for Tendermint would need to remain
on 0.46 s longer than a BCD receiver. With a receive current of 50 mil-
liamps, this would be a differentiator of 23 milliamp-seconds for each
transaction. If, for example, there is one transaction every hour this
would result in 552 milliamp-seconds per day or more than one
milliamp-hour per week. For many low power, battery-operated devices,
this is significant because of their limited energy resources. Also recall
that as opposed to vanilla Tendermint, BCD allows a device to query
transactions from the chain when it wants to without the need to listen
for blocks as they are broadcast through the network, which saves the
device both receiver on time and processing time.
6. Limitations and challenges
The results shown in Section 5 provide insights into the characteris-
tics of the blockchain networks that can benefit from BCD to support IoT
setups. BCD’s main advantage is to reduce the size of the packets dealt
with at edge devices, without increasing the processing cost. However,
this advantage holds for a relatively small number of validators (not
exceeding 128). The larger the number of validators the larger the BCD
packet sizes and the packet processing time. The impact of the trans-
action size, z, is less critical as one would expect IoT devices to tolerate
the size of the transactions that they are interested in. This means that
BCD is a good fit for consortium blockchains with a small number of
validators, and is not beneficial for generic blockchains with potentially
thousands of validators without appropriate adaptation. One possible
approach to incorporate BCD in public blockchains is by grouping vali-
dators into different zones while arranging zones in a hierarchy. Zone
validators are only responsible for validations of transactions related to
their zone.
Also, in the BCD model, edge devices are pre-provided with vali-
dators’ keys. It is reasonable to assume that the list of validators will
change over time, and thus it is important to consider ways to dynami-
cally synchronize the most recent list of validators with edge devices.
One way to handle this case is by allowing validators to join/leave the
system as transactions, which need to be validated by other system val-
idators. This enables the list of validators to change and the edge devices
to be informed of the changes.
Furthermore, a large number of malicious users may impact the
blockchain integrity. However, this is a known problem to consensus-
based systems and the design of optimal consensus algorithms is an
active area of research [34,35]. On the other hand, a misbehaving vali-
dator detected by a blockchain node can trigger a transaction to remove
him from the list of validators and the consensus algorithm validates the
transaction as usual. If validators are not anonymous, as in the case of
consortium blockchains, malicious validators can be further pursued le-
gally outside the confines of the blockchain.
7. Conclusions and future work
Our BCD proposal extends the trust model of blockchains to con-
strained IoT devices without the need for trusted intermediaries.
6
Blockchain: Research and Applications 1 (2020) 100004
Theoretical analysis and experimental results demonstrate that BCD
outperforms vanilla Tendermint’s solutions in accommodating the needs
of constrained devices, reducing their on time and extending their life-
time. This comes at the cost of more storage and computational overhead
for the powerful blockchain full nodes. Creating and testing full-blown
IoT applications on the Tendermint/Cosmos architecture will be part of
our future endeavors.
Declaration of competing interest
The authors declare that they have no known competing financial
interests or personal relationships that could have appeared to influence
the work reported in this paper.
References
[1] S. Symanovich. reportThe Future of IoT: 10 Predictions about the Internet of Things.
Technical Report, (Norton), 2019.
[2] K. Christidis, M. Devetsikiotis, Blockchains and smart contracts for the Internet of
Things, IEEE Access 4 (2016) 2292–2303.
[3] A. Damianou, C.M. Angelopoulos, V. Katos, An architecture for blockchain over
edge-enabled IoT for smart circular cities, in: 2019 15th International Conference
on Distributed Computing in Sensor Systems (DCOSS); 29-31 May 2019; Santorini,
Greece, IEEE, Piscataway, NJ, USA, 2019, pp. 465–472.
[4] T. Dasaklis, F. Casino, Improving vendor-managed inventory strategy based on
Internet of Things (IoT) applications and blockchain technology, in: 2019 IEEE
International Conference on Blockchain and Cryptocurrency (ICBC); 14-17 May
2019; Seoul, Republic of Korea, IEEE, Piscataway, NJ, USA, 2019, pp. 50–55.
[5] S. Huh, S. Cho, S. Kim, Managing IoT devices using blockchain platform, in: 2017
19th International Conference on Advanced Commu- Nication Technology (ICACT);
19-22 Feb 2017; PyeongChang, Republic of Korea, IEEE, Piscataway, NJ, USA,
2017, pp. 464–467.
[6] O. Novo, Blockchain meets IoT: an architecture for scalable access management in
IoT, IEEE Internet of Things Journal 5 (2) (2018) 1184–1195.
[7] X. Xu, C. Pautasso, L. Zhu, et al., The blockchain as a software connector, in: 2016
13th Working IEEE/IFIP Conference on Software Architecture (WICSA); 5-8 Apr
2016; Venice, Italy, IEEE, Piscataway, NJ, USA, 2016, pp. 182–191.
[8] Bitcoin Cash, Available on, https://www.bitcoincash.org/.
[9] Litecoin, Available on, https://litecoin.org/.
[10] S. Nakamoto, Bitcoin: A Peer-To-Peer Electronic Cash System, Available on, https://bitc
oin.org/bitcoin.pdf, 2009.
[11] Bitshares, Available on, https://bitshares.org/.
[12] Dash, Available on, https://www.dash.org/.
[13] Neo, Available on, https://neo.org/.
[14] J. Kwon, E. Buchman, Cosmos: a network of distributed ledgers, Accessed: 27/08/
2020; Available on, https://cointhinktank.com/upload/cosmos-ATOM-2018. pdf,
2018.
[15] M. Muzammal, Q. Qu, B. Nasrulin, Renovating blockchain with distributed
databases: an open source system, Future generation computer systems 90 (2019)
105–117, 01.
[16] E. Safak, A.F. Mendi, T. Erol, Hybrid database design combi- nation of blockchain
and central database, in: 2019 3rd International Symposium on Multidisciplinary
Studies and Innovative Technologies (ISMSIT); 11-13 Oct 2019; Ankara, Turkey,
IEEE, Piscataway, NJ, USA, 2019, pp. 1–5.
[17] T.T.A. Dinh, J. Wang, G. Chen, et al., BLOCKBENCH: a framework for analyzing
private blockchains, in: Proceedings of the 2017 ACM International Conference on
Management of Data, SIGMOD ’17; 14-19 May 2017; Chicago, IL, USA, IEEE,
Piscataway, NJ, USA, 2017, pp. 1085–1100. Association for Computing Machinery.
[18] P. Danzi, A.E. Kalor, C. Stefanovic, et al., Repeat- authenticate scheme for
multicasting of blockchain information in IoT systems, in: 2019 IEEE Globecom
Workshops (GC Wkshps); 9-13 Dec 2019; Waikoloa, HI, USA, IEEE, Piscataway, NJ,
USA, 2019, pp. 1–7.
[19] S.R. Niya, E. Schiller, I. Cepilov, et al., Adaptation of proof-of-stake- based
blockchains for IoT data streams, in: 2019 IEEE International Conference on
Blockchain and Cryptocurrency (ICBC); 14-17 May 2019; Seoul, Republic of Korea,
IEEE, Piscataway, NJ, USA, 2019, pp. 15–16.
[20] S.R. Niya, B. Stiller, Technical Report: BAZO: A Proof-Of-Stake (PoS) Based
Blockchain. Technical Report MSU-CSE-06-2, University of Zurich, Switzerland,
2019.
[21] Y. Gao, H. Nobuhara, A Proof of Stake Sharding Protocol for Scalable Blockchains,
in: Proceedings of the Asia-Pacific advanced network; 26 Aug-1 Sep 2017; APAN,
Dalian, China, 44, 2017, pp. 13–16.
[22] M. Katende, Combining MQTT and blockchain to improve data security, in: 3rd
International Workshop on Emerging Trends in Software Engineering for
Blockchain (WETSEB); 13 Jul 2020; Online, ICSE, 2020.
[23] R. Han, V. Gramoli, X. Xu, Evaluating blockchains for IoT, in: 2018 9th IFIP
International Conference on New Technologies, Mobility and Security (NTMS);
26–28 Feb 2018; Paris, France, IEEE, Piscataway, NJ, USA, 2018, pp. 1–5.
[24] Hyperledger Fabric, Available on, https://www.hyperledger.org/use/fabric.
[25] Ripple, Available on, https://ripple.com/.
A. Douglas et al.
[26] A. Bessani, J. Sousa, E.E.P. Alchieri, State machine replication for the masses with
BFT-SMART, in: 2014 44th Annual IEEE/IFIP International Conference on
Dependable Systems and Networks; 23–26 Jun 2014; Atlanta, GA, USA, IEEE,
Piscataway, NJ, USA, 2014, pp. 355–362.
[27] D. Schwartz, N. Youngs, A. Britto, White reportPaper: the Ripple Protocol
Consensus Algorithm. Technical Report, Ripple Labs Inc, 2014.
[28] O. Dib, K. Brousmiche, A. Durand, et al., Consortium blockchains: overview,
applications and challenges, International Journal on Advances in
Telecommunications 11 (1&2) (2018) 51–65. Available on, https://hal.arch
ives-ouvertes.fr/hal-02271063.
[29] G. Vizier, V. Gramoli, Comchain, Bridging the gap between public and consortium
blockchains, in: 2018 IEEE International Conference on Internet of Things (iThings)
and IEEE Green Computing and Commu- Nications (GreenCom) and IEEE Cyber,
Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData); 30
Jul–3 Aug 2018; Halifax, NS, Canada, IEEE, Piscataway, NJ, USA, 2018,
pp. 1469–1474.
Blockchain: Research and Applications 1 (2020) 100004
[30] M. Castro, B. Liskov, Practical Byzantine fault tolerance, in: Proceedings of the
Third Symposium on Operating Systems Design and Implementation, OSDI ’99; Feb
1999; New Orleans, LA, USA, 1999, pp. 173–186. USENIX Association.
[31] BCD, Blockchains for constrained edge devices, Available on, https://www.csc.
ncsu.edu/people/kaharfou.
[32] JSMN, Available on, https://zserge.com/jsmn/.
[33] H. Tschofenig, M. Pegourie-Gonnard, Performance of state-of-the- art cryptography
on ARM-based microprocessors, NIST Lightweight Cryptography Workshop; 20-21
Jul 2015; Gaithersburg, MD, USA, 2015.
[34] E. Semsar-Kazerooni, K. Khorasani, Optimal consensus algorithms for cooperative
team of agents subject to partial information, Automatica 44 (11) (2008)
2766–2777.
[35] Q. Wang, Z. Duan, J. Wang, Distributed optimal consensus control algorithm for
continuous-time multi-agent systems, IEEE Transactions on Circuits and Systems II:
Express Briefs 67 (1) (2020) 102–106.