Hybrid-IoT: Hybrid Blockchain Architecture for Internet of Things - PoW

Sub-blockchains

Gokhan Sagirlar∗ , Barbara Carminati∗ , Elena Ferrari∗ , John D. Sheehan† , Emanuele Ragnoli†
∗ University Of Insubria, Italy {gsagirlar, barbara.carminati, elena.ferrari}@uninsubria.it
† IBM Research - Ireland {john.d.sheehan,eragnoli}@ie.ibm.com

Abstract—From its early days the Internet of Things (IoT) cloud for processing and analysis, it would be instrumental
arXiv:1804.03903v3 [cs.DC] 5 Jul 2018

has evolved into a decentralized system of cooperating smart to improve security and privacy of the managed data [2], and
objects with the requirement, among others, of achieving it would lead to concerted and autonomous operations. For
distributed consensus. Yet, current IoT platform solutions are example, in smart home environments [3], IoT devices have
centralized cloud based computing infrastructures, manifest- to autonomously exchange and process data, assure data
ing a number of significant disadvantages, such as, among security, operations accountability, device identification and,
others, high cloud server maintenance costs, weakness for last but not least, to collectively and autonomously execute
supporting time-critical IoT applications, security and trust smart homes operations. This, from a distributed systems
issues. Enabling blockchain technology into IoT can help to point of view, means achieving distributed consensus.
achieve a proper distributed consensus based IoT system that A promising decentralized platform for IoT is block-
overcomes those disadvantages. While this is an ideal match, chain. Blockchain is the concept of a distributed ledger
it is still a challenging endeavor. In this paper we take a first maintained by a peer-to-peer network. Its data structure
step towards that goal by designing Hybrid-IoT, a hybrid consists of bundled data chunks called blocks, where peers
blockchain architecture for IoT. In Hybrid-IoT, subgroups in a blockchain broadcast blocks by exploiting public-key
of IoT devices form PoW blockchains, referred to as PoW cryptography. Blocks are recorded in the blockchain with
sub-blockchains. Then, the connection among the PoW sub- exact ordering. Briefly, a block contains: a set of transac-
blockchains employs a BFT inter-connector framework, such tions (exchange and transfer of information); a timestamp;
as Polkadot or Cosmos. In this paper, we focus on the PoW a reference to the preceding block that identifies the block’s
sub-blockchains formation, guided by a set of guidelines based place in the blockchain; an authenticated data structure
on a set of dimensions, metrics and bounds. In order to prove
(e.g., a merkle tree [4]) to ensure block integrity.1 Modern
blockchain protocols, such as Ethereum2 , possess scripting
the validity of the approach we carry on a performance and
systems that allow the coding and execution of computing
security evaluation.
programs on the blockchain itself, referred to as smart
Index Terms—Blockchain, Internet of Things (IoT), architec- contracts [5]. Different blockchain protocols may employ
ture, distributed consensus, Proof of Work (PoW). different methodologies to achieve consensus. For example,
some blockchains use Proof of Work (PoW) [6], while others
Byzantine Fault Tolerant (BFT) [7]. In PoW blockchains,
1. Introduction peers, referred to as block miners, have to use their hardware
resources and energy to solve a cryptographic puzzle as
Internet of Things (IoT) technology is heterogeneously proof of their work, in order to be authorized to generate a
applied to several environments: buildings, automotive, man- new block. Notably, PoW blockchains are able to maintain
ufacturing, cities, etc., with the potential to make them a relative low throughput while scaling to thousands of
smarter, more connected, profitable, and efficient. This typi- nodes in achieving consensus, while BFT blockchains can
cally requires the connection, concerted operation and man- maintain a relative high throughput with only few nodes.
agement of a distributed large number of loosely coupled Other consensus protocols are emerging, for example Proof
smart devices [1], that need to identify and trust each other. Of Stake (PoS) [5], but for the scope of this work we
While this should ideally map to a decentralized hardware consider mature and well implemented protocols like PoW
and software platform, current solutions are mostly based and BFT.
on centralized infrastructures. The disadvantages of that are, When it comes to IoT, blockchain can be used to store
among others: high maintenance costs; low interoperability critical machine-to-machine communications, sent as block-
due to restricted data aggregation with other centralized in- chain transactions, ensuring accountability and security of
frastructures; single point of failures (SPOF) against security
threats. 1
Block structure varies in different blockchain protocols, here we list
Decentralization, if achieved, would have the advantage the most common elements.
to reduce the amount of data that are transferred to the 2
ethereum.org

1
the stored data. It can also provide identity and proof of ? A set of PoW blockchain-IoT integration metrics to
provenance of IoT devices with its cryptographic functions. measure performance.
While the literature offers some examples of blockchain ? A measurement study of the performance of PoW
technology in IoT, such as [8], [9], [10], up to now there is blockchains in IoT.
no de facto standard solution. ? A hybrid blockchain architecture for IoT.
Indeed, one of the biggest challenges in the integration Structure. The remainder of this paper is organized
of blockchain into IoT is scalability. In fact, due to the mas- as follows. Section 2 discusses the related work. We de-
sive number of devices and resource constraints, deploying fine PoW blockchain-IoT integration metrics in Section 3.
blockchain in IoT is particularly challenging. The optimal In Section 4, we extensively evaluate PoW blockchain-
blockchain architecture has to scale to many IoT devices IoT integration and define sweet-spot guidelines for sub-
(they become the peers on the blockchain network), and it blockchain generation. We detail the design of Hybrid-IoT
should be able to process a high throughput of transactions. in Section 5. In Section 6, we evaluate performance of the
Hybrid-IoT, the platform designed in this work, exploits sub-blockchains. Security of our approach is discussed in
both PoW blockchains and BFT protocols. First, PoW block- Section 7, whereas Section 8 concludes the paper.
chains are used to achieve distributed consensus among
many IoT devices, the peers on the blockchain. To measure
and qualify that, we define a set of PoW blockchain-IoT 2. Related Work
integration metrics, and we evaluate the performance of
Hybrid-IoT subject to varying blockchain block sizes and In the literature, there are few instances of application
block generation intervals, device locations, and number of of blockchain to IoT. One application of blockchain to IoT
peers. Since we first observed that PoW blockchains contain- is [8], where a blockchain platform for industrial IoT (BPI-
ing few hundreds of geographically close IoT devices have IoT) has been proposed. BPIIoT exploits smart contracts
high performance (i.e., high transaction throughputs) and to develop a decentralized manufacturing applications of
low block propagation delays, the first step in Hybrid-IoT cloud based manufacturing (CBM). Smart contracts have
consists of generating multiple PoW blockchains. Those are also been exploited in [9] in order to manage smart meter
generated according to a set of rules, referred to as sweet- data. Likewise, in [10] a blockchain based system has been
spot guidelines, that combine best practices in designing proposed to manage firmware updates of IoT devices. [11]
sub-blockchains. As a second step, Hybrid-IoT leverages on exploits blockchain to store access control data, as a data
a BFT inter-connector framework ,such as Polkadot3 and storage system in a multi-tier IoT architecture. In [12],
Cosmos,4 in order to achieve interoperability among sub- blockchain and smart contracts are used to secure authoriza-
blockchains. In this work, we only deal with the first step, tion requests to IoT resources. The above mentioned works
that is, analyzing the performance and security of the PoW make use of blockchain to either execute smart contracts or
sub-blockchain setting. perform application specific tasks, but not to decentralize
Furthermore, in Hybrid-IoT we define three roles for IoT systems and achieve autonomous application execution.
IoT devices according to their capabilities, and test the [13] proposes a blockchain architecture for IoT con-
performance of the system with a set of experiments and taining two layers, namely: smart home layer (centrally
simulations. Moreover, we extensively test security of our managed private ledgers) and a overlay layer (public block-
approach by acknowledging that generating sub-blockchains chain). Resource constrained devices form private ledgers
may generate security vulnerabilities. in smart home layer, that are centrally managed by con-
We stress that, in this work, we make extensive use stituent nodes. Group of constituent nodes select a cluster
of Bitcoin clients and a Bitcoin simulator to conduct the head operating in the overlay network. On one hand, this
performance analysis. The Bitcoin client approach is used to proposal has some similarities with Hybrid-IoT as it includes
test the Hybrid-IoT architecture and design. The real focus multiple blockchains. It relies on distributed trust algorithms
here is the PoW sub-blockchains design with the sweet-spot to eliminate computational overhead from IoT devices due to
guidelines and the type of tests and analysis performed here PoW solving task. However, the proposed architecture does
would not differ with other types of PoW protocols that not help with the decentralization of IoT. In fact, IoT devices
allow smart contracts (this would affect only the types of are centrally managed and connected to one constituent node
transactions submitted to the peers). that does not take part in the distributed consensus.
In the literature, there are few papers targeting ap- Differently from previous works, the Tangle5 protocol
plication of blockchain to IoT (cfr. Section 2). However, implements a global distributed ledger for IoT by using
application of blockchain to IoT has been mainly limited to Directed Acyclic Graph generated by transactions as a
application specific tasks (e.g. firmware updates of IoT de- blockchainless approach. Tangle is designed as a cryptocur-
vices [10]), whereas the goal of this paper is to decentralize rency for IoT to make micro-payments possible, it does not
IoT by exploiting blockchain. provide an architecture or data structure to decentralize IoT
Contributions. Our main contributions are: and it is not Turing complete to allow scripting and smart
contracts.
3
polkadot.network
4 5
cosmos.network iota.org/IOTA_Whitepaper.pdf

2
3. PoW Blockchain-IoT Integration Metrics Dimensions Metrics
Scalability  Maximum no of IoT devices as peers
We identify five relevant dimensions that an optimal  Maximum transaction throughput
blockchain PoW implementation for IoT should be sub- Security  Maximum work in the blockchain
ject to: scalability, security, decentralization, efficiency as 90% block propagation time
observed metrics, and network bandwidth as a controlled Decentralization  ≤1
block generation interval
parameter. In what follows, we analyze those dimensions
Efficiency  Stale block generation rate ≈ 1%
(see Table 1 for a summary).
Scalability. Scalability in IoT is the capacity to be Network bandwidth  Avg network traffic of a device ≤ 250 Kbps
changed in size or scale in terms of number of devices,
hardware characteristics and functional and non-functional Table 1: PoW Blockchain - IoT Integration Metrics
requirements, while maintaining quality of performance. For
blockchain, this translates to have a peer to peer network that LTE Cat M1 and LTE Cat 0 standards it is 1 Mbps. In this
can scale up in terms of number of peers and throughput, work, in order to avoid network overloads and consequent
as number of transactions per unit of time. bottlenecks with high information traffic, we set an upper
Security. Security is a critical dimension in IoT, espe- bound of 250 Kbps as total of uplink and downlink rates.
cially considering recent large scale attacks ,like Mirai and
WannaCry.6 While in this work we do not deal with device 4. PoW Blockchain-IoT Integration Evalua-
intrusions, the issue of data integrity for IoT devices is an
important problem to be solved [14]. While data integrity tions
is by design preserved by a PoW blockchain, the issue of
the longer chain attack still exists [15]. In order to measure In this section, we evaluate the performance of the inte-
this, we consider the maximum amount of total work in the gration of PoW blockchains in IoT, subject to the dimensions
PoW sub-blockchain as a metric. and metrics defined in Section 3. To this end, we use and fur-
Decentralization. Decentralization in IoT is critical to ther extend (by adding different device location setups) the
improve security and privacy and achieve autonomous ex- Bitcoin simulator8 presented in [15], (see Section 4.1). We
ecution, as noted in Section 1. In peer-to-peer overlay net- perform three evaluations (see Section 4.2): one by varying
works, like blockchains, decentralization is measured by the block size and block generation intervals (see Section 4.2.1);
number of properly functioning peers [16]. In a blockchain, one by varying device location (see Section 4.2.2); one by
a peer needs to be up to date with the most recent block varying the number of IoT devices (see Section 4.2.3). We
before generating a new block to be accepted by blockchain present results as an average of 5 experimental runs. We use
consensus. Hence, we define the metrics for measuring the findings of this section to define the concept of sweet-
decentralization as the number of functioning peers on the spot guidelines that drives the generation of sub-blockchains
network. We also define a lower bound of functioning peers, (see Section 4.3).
to be 90% of the total, to guarantee proper functionality of
the blockchain for its IoT application. 4.1. Simulator Setting
Efficiency. Efficiency in IoT can be defined as an opti-
mal utilization of hardware resources and energy. Therefore, The Bitcoin simulator is built on ns-3 discrete-event
in order to achieve that, the IoT devices on the blockchain network simulator. It allows to model a Bitcoin network
should optimally utilize resources and energy to maintain with a set of consensus and network parameters such as:
and progress the blockchain. Among others, an obstacle to block generation interval; block size; number of nodes.
that is the issue of forks and stale blocks in PoW blockchains Connections between nodes are established using point-to-
[15]. Specifically, stale blocks do not contribute to the se- point channels, by considering latency and bandwidth as
curity of the blockchain and transactions in stale blocks are the two main characteristics (cfr. [15] for further informa-
considered as unprocessed by the network, requiring wasted tion). We have extended the simulator with three different
effort to generate them.7 Hence, we define our metrics for device location setups, namely the Netherlands, Europe, and
efficiency as the stale block generation ratio and we establish World, by adopting real world network latency data.9 In
a upper bound for performance to be ≈1%. the Netherlands setup, devices are located in six cities of
Network bandwidth. Network bandwidth is a one to the Netherlands: Alblasserdam, Amsterdam, Dronten, Eind-
one map between the IoT network and its corresponding hoven, Rotterdam and The Hague. In the Europe setup,
blockchain network. It is defined by the the IoT devices devices are located in six European cities: Brussels, Athens,
downlink and uplink rates. For example IEEE 802.15.4 and Barcelona, Izmir, Lisbon and Milan. Finally, in the World
NarrowBand-IoT standards set 250 Kbps data transfer peak setup devices are located in 7 globally distributed cities:
rates for machine to machine communication, whereas in Dhaka, Hangzhou, Istanbul, Lagos, Melbourne and San
Diego. We equally distribute regular and miner among the
6
siliconrepublic.com/machines/iot-devices-botnets-autonomous-cars cities in the respective setups.
7
In Ethereum blockchain they are included to the blockchain as uncle
8
blocks, however they do not count towards total difficulty of the blockchain github.com/arthurgervais/Bitcoin-Simulator
9
[15]. wondernetwork.com/pings

3
 In order to use the simulator for our evaluations we blocks. This is due to bandwidth exhaustion of devices.
categorize IoT devices within two roles: miners and regular Therefore, according to the bounds of security metric, using
devices. The number of connections per miner device and small blocks (e.g., 10 KB) in short block generation intervals
regular device follows the distribution as in [17]. Regular (e.g., 5s) is more appropriate to increase number of genuine
devices only check and propagate the blocks they receive, blocks.
whereas miner devices also generate new blocks. The ratio Decentralization. According to the decentralization
of miner over number of nodes is set to ca 7%, with the metric’s bounds, 90% block propagation time should be
remainder taking the role of regular devices. This is justified lower than block generation interval. Due to their restricted
by some Bitcoin statistics [17] and by the fact that we bandwidth capabilities, IoT devices have to spend more
consider only a small subset of IoT devices to have enough time to propagate big blocks, and that in turn breaches the
resources to take part in the mining process. 90% block propagation time bound. In parallel, we observe
Network latency plays a critical role in performance that, when using big blocks (e.g., 10 MB), block generation
due to the intrinsic nature of peer to peer information interval should be long enough (e.g., 10m) to satisfy the
propagation (i.e., block and transaction). Hence, to evaluate decentralization lower bound. For example, when small
how geographical locations of the devices affect network blocks (e.g. 10 KB) are used, the decentralization bound can
latency, we exploit the Netherlands, Europe, and World be satisfied with shorter block generation intervals (e.g., 5s).
device location settings of the simulator. Therefore, in order to achieve decentralization, block sizes
Bandwidth capacities of IoT devices obviously affect and block generation intervals should be set carefully.
information propagation time in the blockchain. To have a Efficiency, scalability. Short block generation intervals
realistic bandwidth setup, we adopt the bandwidth bench- and/or using big blocks leads to higher stale block rates,
marks of Raspberry Pi devices.10 Hence, we adopt an up- as bandwidth resources of IoT devices are exhausted in
per bandwidth limit of 100 Mbps (variations within that propagating the blocks. In order to achieve low stale block
limit are allowed due to connection type) and we realisti- rates, with a short block generation interval setup, only
cally simulate bandwidth capacities with a distribution from small blocks can be used. Bigger blocks (e.g., 1 MB) can
testmy.net.11 That results in a varying download bandwidth be used with long block generation intervals. The bigger
between 0.1 Mbps and 100 Mbps with a 5 Mbps average, the block is, the longer block generation should be used to
and a varying upload bandwidth between 0.02 to 20 Mbps satisfy the low stale block generation bound. Moreover, we
with a 1Mbps average. observe that block sizes bigger than 1 MB are not suitable
for IoT, since it leads to high stale block rates, even with
4.2. Evaluation Results a long block generation interval setup. Achieving a low
stale block rates positively impacts transaction throughput.
4.2.1. Evaluation I: Block sizes and block generation In our experiments the highest throughput achieved is 30.1
intervals. We evaluate the effect of block sizes and block transaction per second in using 500 KB blocks with 1 minute
generation intervals with the simulator with the Netherlands block generation interval setting with 1.71% stale block rate.
setup. We adopt a six block generation cycle with the follow- Findings: blocks smaller than 1 MB should be used;
ing intervals: 10 minutes, 5 minutes, 1 minute, 30 seconds, block generation intervals should be as short as possible;
10 seconds, and 5 seconds. For every block generation cycle, block size and block generation intervals should be set
we vary block sizes as: 10 KB, 50 KB, 100 KB, 500 KB, carefully to ensure low stale block rates and high decen-
1 MB, 5 MB, 10 MB. We fix the number of IoT devices tralization.
to 250, with 18 devices with miner roles, according to the
7% ratio in Section 4.1. Experiment results are presented in 4.2.2. Evaluation II: Device Locations. We evaluate the
Table 2. effect of device locations by varying the network latency
Network bandwidth. Not surprisingly, using bigger among IoT devices. In order to simulate that, we use the Bit-
blocks and/or having short block generation intervals in- coin simulator with three location settings (the Netherlands,
crease the average network traffic. In that, big blocks (e.g., Europe, and World), as in Section 4.1. Since from Evaluation
5 MB) comply with the network bandwidth metric’s bound I, the optimal block size should be less than or equal than 1
when block generation interval is long enough (e.g., 5m), MB, the block size is fixed at 500 KB on average. We adopt
whereas for small blocks (e.g., 10 KB) even short block a six block generation cycle with the following intervals: 10
generation intervals (e.g., 5s) are suitable. minutes, 5 minutes, 1 minute, 30 seconds, 10 seconds, and
Security. Obviously, using shorter block generation in- 5 seconds. We fix the number of IoT devices to 250, where
tervals increases the number of blocks generated. However, 18 of them are miners. Experiment results are presented in
we observe that this is not proportional, especially when the Table 3.
block size is bigger than 100 KB. Similarly, in experiments Network bandwidth, security. For all location setups,
with 1 minute or shorter block generation interval settings, in each block generation interval setting, average network
increasing the block size decreases the number of generated traffic per device and number of generated genuine blocks
are highly correlated. Particularly, only 1 minute or longer
10
pidramble.com/wiki/benchmarks/networking block generation intervals comply with the bound for the
11
testmy.net/country the network bandwidth metric (the average network traffic

4
 Block Block. Total Stale Genuine Stale 90% Avg Thrghpt Block Sce. Total Stale Genuine Stale Mean Avg Thrghpt
Size Gen. Blocks Blocks Blocks Rate Prop. Traffic (TX/s) Gen. Blocks Blocks Blocks Rate Delay Traffic (TX/s)
Intrvl(s) Delay(s) (Kbps) Intrvl(s) (s) (Kbps)
10m 10.8 0.43 10.4 3% 360 276 69.3 N 9.6 0 9.6 0% 7 13 3.2
5m 18.8 0.9 17.9 8.83% 755 723 119.5 10m E 9.9 0 9.9 0% 16 13 3.3
10 MB 1m 45.6 16 26.93 35.07% 2162 21215 197.5 W 9.9 0 9.9 0% 20 13 3.3
30s 51.2 26.6 24.6 47.99% 2412 49520 164.1 N 18.6 0 18.6 0% 6 26 6.2
10s 57.7 41.2 16.5 71.38% 2560 151046 110.2 5m E 16.4 0 16.5 0% 13 27 5.5
5s 64.2 48.2 16 75.00% 2665 273777 107.1 W 15.5 0 15.5 0% 17 27 5.2
10m 10.2 0.26 9.9 2.6% 168 134 33.1 N 92.1 1.6 90.5 1.71% 17 136 30.1
5m 19.9 1 18.9 5.3% 180 288 63 1m E 93.6 4.8 88.8 5.14% 18 140 29.6
5 MB 1m 67.3 12.1 55.2 17.99% 1888 8718 184 W 96.5 7.9 88.6 8.22% 20 140 29.5
30s 73.4 26.8 46.6 36.52% 2105 28528 155.5 N 165.2 9.2 156 5.56% 18 639 52
10s 84 56.5 27.5 67.18% 2472 100255 92 30s E 170.5 21.9 148.6 12.87% 38 527 49.5
5s 91.4 68.5 22.9 74.91% 2512 190671 76.4 W 169.5 23.9 145.6 14.11% 52 592 48.5
10m 12.3 0 12.3 0% 31 26 8.2 N 346.6 101.4 245.2 29.25% 314 14762 81.7
5m 22.3 0 22.3 0% 32 53 14.9 10s E 314 104.6 209.4 33.31% 355 15237 69.8
1 MB 1m 92.4 3.4 89 3.71% 37 438 59.3 W 331 136.8 194.2 41.34% 392 16777 64.7
30s 165.9 8.5 157.4 5.15% 818 3243 104.9 N 350.7 161.2 189.5 45.96% 815 41378 63.2
10s 219.6 94.1 125.5 42.86% 1812 30259 83.7 5s E 301.2 156 145.2 51.80% 918 43931 48.4
5s 232.5 128.7 103.8 55.37% 2183 69059 69.2 W 303.3 161.1 142.2 53.12% 1000 45021 47.4
10m 9.6 0 9.6 0% 15 13 3.2
5m 18.6 0 18.6 0% 15 26 6.2 Table 3: Evaluation II: Device Locations
500 KB 1m 92.1 1.6 90.5 1.71% 17 136 30.1
30s 165.2 9.2 156 5.56% 18 639 52
10s 346.5 101.4 245.1 29.25% 1665 14762 81.7 No of Block Total Stale Genuine Stale 90% Avg Thrghpt
5s 350.6 161.1 189.5 45.96% 1972 41378 63.2 Miners/ Gen. Blocks Blocks Blocks Rate Delay Traffic (TX/s)
10m 9.3 0 9.3 0% 3.2 2 0.6 Total Intrvl(s) (s) (Kbps)
5m 23 0 23 0% 3.2 5 1.5 6/83 3m 29.9 0 29.9 0% 7 44 9.9
100 KB 1m 99 0 99 0% 3.2 27 6.6 12/166 1.5m 76.7 1.3 75.4 1.9% 8 88 25.1
30s 186.4 4.4 182 2.35% 3.2 54 12.1 18/250 1m 92.1 1.6 90.5 1.71% 17 136 30.1
10s 537.3 22.8 514.5 4.25% 3.4 447 34.3 36/500 30s 177.7 15.6 162.1 8.8% 41 1168 54
5s 954.5 124.5 830 13.04% 99 7249 55.3 54/750 20s 237.2 32.9 204.3 13.87% 147 3485 68.1
10m 11 0 11 0% 1.6 1 0.4 72/1000 15s 216.5 39.4 177.1 18.2% 291 5791 59
5m 18.6 0 18.6 0% 1.6 2 0.6 90/1250 12s 212 47.5 164.5 22.43% 498 8265 54.8
50 KB 1m 96.3 0 96.3 0% 1.6 14 3.2
30s 187.0 0.7 186.3 0.35% 1.6 28 6.2 Table 4: Evaluation III: Number of IoT Devices - Experi-
10s 562.0 10.2 551.8 1.82% 1.7 84 18.4
5s 1120.4 43.4 1077 3.87% 1.8 931 35.9 ment (A): Fixed difficulty setting
10m 10.3 0 10.3 0% 0.4 0.3 0.1
5m 21.6 0 21.6 0% 0.4 0.7 0.2
10 KB 1m 101 0 101 0% 0.4 3.5 0.7
30s 193.3 0 193.3 0% 0.4 7 1.3 4.2.3. Evaluation III: Number of IoT devices. We evalu-
10s 598.6 0 598.6 0% 0.4 21 4 ate the effect of varying the number of IoT devices with two
5s 1166.3 19.9 1146.4 1.71% 0.4 42 7.6
experiment types: experiment (A): we fix the PoW difficulty;
Table 2: Evaluation I: Block sizes and block generation experiment (B): we fix block generation interval. Each setup
intervals is run for 100 minutes. In both types we vary the number
of IoT devices from 83 to 1250 and assumed a fixed block
size of 500 KB. In PoW blockchains, the block generation
should be less than 250 Kbps) for all location settings. interval depends on the ratio of the difficulty of the PoW
Hence, a 1 minute block generation interval is the most puzzle over the total mining power of the system [6]. Hence,
suitable according to the security metric bound, since it has with the PoW difficulty fixed, we vary the block generation
the highest number of genuine blocks. With those, every intervals inversely proportionally to the number of miners.
locations setup shows a similar behavior. On the other hand, with a fixed block generation interval
Scalability, decentralization, efficiency. For any setup of 1 minute, the difficulty of the PoW puzzle is varied
that we tried the outcome with shortest block propagation proportionally to number of miners (the difficulty of the
delays, lowest stale block rates, and highest transaction PoW puzzle is α for 6 miners and 15α for 90 miners).
throughputs is the Netherlands setup. For example, with 1 Experiment (A). Results are in Table 4.
minute block generation interval, a PoW blockchain using Metrics. Having more IoT devices with shorter block
the Netherlands setup achieves a throughput of 30.1 per generation intervals leads to generate more blocks, leading
second and complies with the efficiency bound (stale block to an increase in throughput and average network traffic per
rate is 1.71%) and decentralization bound (90% block prop- device. That causes extensive bandwidth consumption that
agation time is 17 seconds). Whereas, in Europe and World generates long block propagation delays, which leads to high
settings, the block generation interval needs to be at least stale block rates. Hence, experimental variations containing
5 minutes to satisfy the same bounds. With those, both the 83, 166 and 250 devices satisfy the efficiency, network
Europe and World setups can only achieve a throughput of bandwidth, and decentralization bounds. When it comes
5 transaction per second. to scalability and security bounds, scenario containing 250
Findings: blockchains containing IoT devices that are devices is the optimal setups as it produces more genuine
geographically close to each other achieve higher throughput blocks, and achieves the highest throughput and scales to
with low stale block rates. more devices.

5
 No of Total PoW Stale Genuine Stale 90% Avg Thrghpt
Miners/ Blocks Puzzle Blocks Blocks Rate Delay Traffic (TX/s) are peers on the blockchain. Sub-blockchains are generated
Total Difficulty (s) (Kbps) according to the sweet-spot guidelines defined in Section
6/83 96.1 α 0,8 95.3 0.85% 13 135.76 31.7 4.3. In order to connect the sub-blockchains, Hybrid-IoT
12/166 96.3 2α 1.8 94.5 1.19% 14 133.37 31.1
18/250 92.1 3α 1.6 90.5 1.71% 17 136 30.1 uses a BFT inter-connector framework (e.g., Polkadot and
36/500 93.03 6α 3.99 89.04 4.29% 26 122.99 32.86 Cosmos) that guarantees inter-blockchain transactions.
54/750 93.41 9α 4.49 88.92 4.8% 28 102.03 29.64
72/1000 93.03 12α 4.42 88.61 4.75% 28 102.99 29.53
System execution. The transaction flow in Hybrid-IoT
90/1250 92.77 15α 4.98 87.78 5.36% 39 107.01 29.26 is as follows: transactions on the PoW sub-blockchains are
processed and included in blocks that are added to their
Table 5: Evaluation III: Number of IoT Devices - Experi- respective sub-blockchain upon PoW consensus; when a
ment (B): Fixed interval setting transaction among two distinct sub-blockchains happens,
that is picked by the BFT inter-connector framework; the
Experiment (B). Results are in Table 5. BFT inter-connector framework checks the transaction cor-
Metrics. In all the experimental variations, 90% block rectness and authenticity; after a positive response, the
propagation times are less than 1 minute block generation in- BFT inter-connector framework transfers the transaction
terval, thus satisfying the decentralization bound. Similarly, to the target sub-blockchain’s transaction pools that hold
average network traffic per device is less than 250 Kbps, sat- unprocessed transactions; last, the transaction is processed
isfying the network bandwidth bounds for all experimental and included in a newly generated block in the respective
variations. However, only experimental variations containing sub-blockchain, upon PoW consensus. The reasons for the
83, 166 and 250 devices satisfy the efficiency bound with choice of a BFT inter-connector framework lies in the
low stale block rates. Among them, experiment containing intrinsic capability of BFT consensus protocols to achieve
250 devices is the optimal setup according to the security high throughput with a low number of peers.12 Hence, that
and scalability bounds, as it achieves the highest throughput should allow to connect few sub-blockchains with an ad-
and scales to more devices. equate throughput for inter-blockchain transactions. More-
Findings: PoW blockchains containing few hundreds over, by maintaining low latency in the transmission of inter-
of IoT devices achieve higher transaction throughput; the blockchain transactions, the BFT inter-connector framework
optimal number of IoT devices as blockchain peers is around allows the connection of a new sub-blockchain without
250. deferring application execution. An example of Hybrid-IoT
architecture containing two sub-blockchains is shown in
4.3. Sweet-spot Guidelines Figure 1.
Consensus participation. Blockchains can be catego-
After Evaluations I,II and III, we can conclude that PoW rized into two groups subject to the type of peer access
blockchains containing few hundreds of IoT devices in close control: permissioned and permissionless blockchains [18].
geographical proximity achieve the highest performance. In permissionless blockchains, all peers can take part in the
Therefore, in order to design a blockchain architecture for consensus, whereas in permissioned blockchains, only pre-
IoT, we propose to deploy multiple PoW blockchains as defined peers can take part in the consensus process. Hybrid-
sub-blockchains for IoT, organized according to pools of IoT is a permissioned blockchain system. This is particularly
IoT devices. We adopt the following guidelines, referred to important since the sub-blockchains are based on PoW and
as sweet-spot: the nature of IoT devices can easily lead to malicious cases
• Sub-blockchains should contain few hundreds of IoT of majority attack [19]. Indeed, specialized mining hardware
devices. could be easily masked as an IoT device and gain enough
• Sub-blockchains should contain IoT devices that are block mining power to control the PoW blockchain.13
geographically close and frequently communicating with Security. While the permissioned nature of Hybrid-IoT
each other. can mitigate the risk of longer blockchain attacks [18], IoT is
• Block size and block generation intervals should be set still prone to those, since device capture and device cloning
to ensure low stale block rates, and high decentralization and attacks are not a rare occurrence [20]. Usually that would
scattering of mining power. be mitigated by the difficulty of the PoW puzzle. Indeed,
• Blocks smaller than or equal to 1 MB should be used. in PoW blockchains, for a fixed block generation interval,
• Block generation interval should be as short as possi- the difficulty of the PoW puzzle is set proportionally to the
ble. total mining power [6]. While the Hybrid-IoT PoW sub-
In the next section, we design the architecture of Hybrid- blockchains would have PoW puzzles with low difficulty
IoT, based on the sweet spot guidelines, by leveraging on (there could be only a relatively small number of IoT devices
multiple PoW sub-blockchains.
12
For example, Tendermint protocol used by Cosmos network is able
5. Hybrid-IoT: Hybrid Blockchain Architec- to process thousands of transactions per second [7], whereas PoW sub-
blockchains are able to process few dozens of transactions according to
ture for IoT our evaluations presented in Section 4.
13
In the example case of Bitcoin, Raspberry Pi has 0.2 MH/s mining
Hybrid-IoT consists of multiple PoW sub-blockchains power, whereas a specialized mining device AntMiner S has 14 TH/s
that achieve distributed consensus among IoT devices that mining power.

6
 Figure 1: Hybrid-IoT

that mine), by keeping a high block generation rate, security number of light peer devices in the full peers’ device subnet
vulnerabilities can be prevented (see Section 7). is set according to its mining power to guarantee fair block
Anomaly resilience. An important issue to consider is generation rates.
the so called blockchain anomaly, presented in [21]: "a long • Light peer role. IoT devices that have limited capa-
enough delay on the delivery of messages could lead to bilities and computing power, such as Arduino Yun, take
having the miners to seemingly agree separately on different the light peer role. They have basic operating systems
branches containing more than k blocks each, for any k∈N". like Alpine Linux, and can connect and participate in the
While this is theoretically possible, in practice, in a decen- blockchain by performing simple tasks, such as sending
tralized blockchain, like Bitcoin, it has never materialized transactions. Light peer devices send transactions to the
in more than few blocks for many years.14 Hence, in order blockchain transaction pool and to the full peer that acts
to prevent the anomaly in Hybrid-IoT, we adopt the same as a gateway. This allows all the full peers to be aware of
degree of decentralization and scattering of mining power all the transactions in the sub-blockchain. This acts as a
as in Bitcoin. That is assured by the sweet-spot guidelines double-check in case a full peer is subject to a malicious
and it can be further reinforced by the findings in [16]. attack.
Remediations. Unlike specialized PoW mining hard- • Outsider role. IoT devices that have very limited
wares for cryptocurrencies, such as ASICs and GPUs, IoT capabilities by being able only to act as basic sensors, take
devices have limited hardware resources and they are widely the outsider role. They are not peers on the blockchain, but
energy-constrained devices [22]. As such, IoT devices do they can connect to full peers for further data fusion (such
not have enough hardware or energy resources to solve very as data aggregation). Raw data generated by an outsider is
complex PoW puzzles.15 In Hybrid-IoT, the difficulty of the not stored the blockchain to prevent data overload.
PoW puzzle is set according to the hardware constraints of
IoT devices. Therefore, IoT devices can still perform their
application specific tasks, such as data processing, while
6. Performance Evaluation
concurrently continue to mine blocks.
Roles of IoT devices. IoT devices have heterogeneous In Hybrid-IoT, as per Section 5, light peer devices send
capabilities, and their roles should reflect their capabilities. transactions to full peer devices, and those will include
Therefore, in Hybrid-IoT, we define three different roles for them in the newly generated blocks. Hence, full peers need
IoT devices as peers on the blockchain: full peer roles; light to process an heavy transaction loads. Therefore, the first
peer roles; and outsider roles. performance test for Hybrid-IoT is a stress test, in which,
• Full peer role. IoT devices that have enough capac- set of light peers repeatedly sends transactions to full peers
ity and computing power to perform complex operations, (see Section 6.1). Then, we shift the focus to the different
like a Raspberry Pi 3, take the full peer role. They have sized PoW sub-blockchains, where full peers take part in
high resources and run full-fledged operating systems like the consensus process. Sub-blockchains can be generated
Raspbian. Hence, as peers on the blockchain, they mine with different number of full peers, which affects the time
blocks and take part in the consensus process in the PoW required to achieve consensus and the way in which the
sub-blockchains. In addition to that, full peer devices act full peer manages its resources. Hence, the second type of
as gateway devices to connect set of light peer devices to performance test is done by varying sub-blockchain sizes
the blockchain network, referred as full peer device subnet. and measuring the time needed to achieve consensus and
Hence, blocks formed by a full peer device contain its own the full peers’ resource usage (see Section 6.2).
transactions and transactions sent by its device subnet. The
14
6.1. Performance Evaluation I: Stress test
We crawled orphan blocks through all of the Bitcoin orphan blocks
presented in blockchain.info/orphaned-blocks.
15
As of late 2017, it would require more than 1000 years for a Raspberry We design a DDoS attack simulation for the stress test:
Pi to mine a single block in Bitcoin. 20 light peers take the role of attackers; a full peer takes the

7
 Metrics 20 peers 40 peers 100 peers 200 peers
role of victim; the attack is conducted for 45 minutes. All Avg CPU usage 6.7% 5.2% 2.8% 2.1%
the peers are are virtualized with LXC (Linux Containers)16 Avg Memory usage 115 MB 109 MB 109.1 MB 108.7 MB
containers and have the following configurations: Avg Ethernet traffic 7.9 KB/s 6.2 KB/s 3.6 KB/s 1.6 KB/s
Avg Ethernet packets 9.4/s 8.5/s 5/s 3.6/s
• Full peer: Ubuntu 14.04 (Trusty) O.S; 512 MB RAM Table 6: Perf Eva II: Performance Statistics
memory, 10% of one Intel Core i7 2.70 GHz CPU; 5
mbit/s ingress and egress network interface limit; bitcoind
version 14.02 Bitcoin protocol’s full node. We measure 6.2. Performance evaluation II: Sub-blockchain
CPU utilization, memory usage, and Ethernet activity with
nmon.17 size

• Light peer: Alpine Linux 3.6.0 O.S; 128 MB RAM In order to measure the sensitivity to sub-blockchain
memory, 2% of one Intel Core i7 2.70 GHz CPU, 1 mbit/s sizes, we design four sub-blockchain emulation scenarios
ingress and egress network interface limit; Java SE; JRE 8 (Emulation I,II,III and IV) by varying the number of full
update 131 environment; Bitcoin protocol’s thin client model peers in the sub-blockchains. In Emulation I the number of
developed with bitcoinj library. We monitor CPU usage, full peers is 20, in Emulation II 40, in Emulation III 100,
memory usage, and Ethernet activity with RRDtool.18 and in Emulation IV 200. Peers are connected to each other
We use Bitcoin regtest19 (regression test) network to execute in a round-robin way. All the full peers are virtualized with
the stress test. The DDOS attack is executed as follows: a LXC (Linux Containers)21 containers on an IBM Power 8
number of attackers, max 20, generate a load of identical server and have the following configurations:
and valid transactions of ca 225 bytes at varying frequency • Full peer: Ubuntu 14.04 (Trusty) O.S.; 512 MB RAM
(from ca 2tx/s to ca 9tx/s); once the victim receives the load memory; 5% of a single Power8 3.5 GHz CPU; 5 mbit/s
it checks the transactions validity add them to the transaction ingress and egress network interface limit; bitcoind version
pool. A load of 108960 transactions was generated with an 14.02 Bitcoin protocol’s full node. We measure CPU uti-
average of 5448 transactions per attacker. For the sake of lization, memory usage, and Ethernet activity (traffic and
brevity, in the figures, we show measurements only for the packets) with nmon.22
first 15 minutes and only for the CPU component (the other We use Bitcoin regtest (regression test) network to exe-
components have very similar trends). cute the emulations. The emulations are executed as follows:
Victim results. Figure 2(b)20 shows the CPU usage of in each emulation we submit 11.000 identical transactions
the victim: 90% of its CPU is exhausted by processing (225 bytes) to the network with one full peer; one peer sub-
the attackers’ load; a similar measurement and graph is mits to the remaining full peers the 5 blocks with 1 minute
observed for its Ethernet activity; memory usage is steady block generation interval; the full peers achieve consensus
around 150 MBs. The victim manages to receive and process on the submitted blocks. We measure resources utilization at
over 40 transactions per second from 20 attackers. We can the last peer of the round-robin from the moment at which
conclude that the victim successfully manages to perform the submitting peer proposes the first block of the five, till
its blockchain duties without crashing or halting under the the moment in which all the five blocks are recorded on the
heavy load from the attack (here heavy is attributed to the local blockchain copy of the last round-robin peer (we refer
fact that the attackers’ resources are exhausted). this as the consensus cycle in the rest of the paper). We note
that we do not employ light peers to generate loads. This
Attacker results. Figure 2(a) shows the CPU usage of is justified by the need of measuring consensus with heavy
one of the attackers: nearly 100% of the attacker’s CPU is transactions loads. All measurements are in Table 6 or in
exhausted (it is capable of processing ca 300 bit/s); there is the text below.
an increase in memory usage from 99 MB (before starting Results. We observe that the consensus cycle is longer
to attack) to 124 MB (during attack), utilizing all of its with sub-blockchains with more full peers as block and
memory. When one light peer takes the role of attacker, it transaction propagation takes longer. We show in Table 6,
manages a maximum of 9 transactions per second without that on average, emulation scenarios with more full peers
crashing. This should help to characterize the capabilities of use less resources. This is because, with sub-blockchains
a light peer to generate transaction loads, regardless of the with more full peers, resource utilization is averaged over
DDoS simulation performed. longer consensus cycles.

7. Security Evaluation
16
linuxcontainers.org Despite having low difficulty puzzles, sub-blockchains
17
nmon.sourceforge.net
18 can prevent security vulnerabilities with high block genera-
oss.oetiker.ch/rrdtool
19
bitcoin.org/en/glossary/regression-test-mode
tion, as noted in Section 5. We evaluate this by simulating a
20
Legend for Figure 2; user: avg CPU utilization for Bitcoin client;
21
system: avg CPU utilization for kernel mode; wait: avg CPU utilization linuxcontainers.org
22
for I/O wait mode. nmon.sourceforge.net

8
 (a) Perf Eva I: CPU Utilization Light Peer (b) Perf Eva I: CPU Utilization Full Peer

Figure 2: CPU utilization of devices in Performance Evaluation I

set of scenarios in which six sub-blockchain setups are com- Block Simulated PoW Puzzle Block Genuine Stale Total
pared. This is done with the help of the Bitcoin simulator (as Size Scenario Difficulty Interval Blocks Rate PoW
Scenario I α 30s 198.6 1.2% 198.6α
in Section 4.3) and by measuring their total work. Total work Scenario II 2α 35s 162.6 1.56% 325.2 α
is defined as the multiplication of the number of genuine 100 KB Scenario III 3α 40s 133.2 1.7% 299.6α
blocks by the PoW puzzle difficulty. The sub-blockchains Scenario IV 6α 6m 15.2 1.49% 91α
are generated according to sweet-spot guidelines contain Scenario V 12α 7m 13.6 1.99% 163α
Scenario VI 24α 10m 9.2 1.9% 178α
subgroups of IoT devices that are geographically close to Scenario I α 50s 98 1.95% 98α
each other. Hence, we generate the following scenarios: Scenario II 2α 55s 74.1 1.2% 148.2α
• Scenario I: 83 peers of which 6 full peers. 500 KB Scenario III 3α 1m 90.5 1.71% 271α
• Scenario II: 166 peers of which 12 full peers. Scenario IV 6α 10m 10.4 1.98% 62α
Scenario V 12α 11m 9.7 1.89% 117α
• Scenario III: 250 peers of which 18 full peers. Scenario VI 24α 12m 8.4 1.96% 203α
The scenarios above are generated using the Netherlands Scenario I α 150s 37.5 1.3% 37.5α
setup. We also generate 3 more scenarios using the World Scenario II 2α 165s 34.6 1.2% 69.2 α
1 MB Scenario III 3α 3m 26.6 0% 79.8α
setup to have a baseline: Scenario IV 6α 10m 10.5 0.5% 63α
• Scenario IV: 500 peers of which 36 full peers. Scenario V 12α 12m 8.3 0% 99α
• Scenario V: 1.000 peers of which 72 full peers. Scenario VI 24α 13m 5.9 1.8% 141α
• Scenario VI: 2.000 peers of which 144 full peers.
Table 7: Security Experiments’ Results
We vary the difficulty of the PoW puzzle proportionally
to the number of full peers (see Table 7). We also assume
that all the peers have the same resources. In order to PoW puzzles than the former. Hence, we observe that with
evaluate the sensitivity to block size we vary the block size smaller blocks we can generate sub-blockchains with less
with values 100KB, 500KB and 1MB. We configure every full peers without sacrificing security. We finally observe
scenario with the shortest block generation interval, in order that, even with low difficulty PoW puzzles, sub-blockchains
to be compliant with the bounds of the metrics defined in generated according to the sweet-spot guidelines are able to
Section 3. We present the results in Table 7. have more or comparable total work than sub-blockchains
Results. As expected, Scenarios I, II and III are able with high difficulty PoW puzzles that do not adhere to those
to comply with the bounds of blockchain-IoT integration guidelines (the Netherlands scenarios have more work with
metrics with shorter block generation intervals than Sce- easier PoW puzzles than World scenarios with more difficult
narios IV, V, and VI, and thus they produce more genuine PoW puzzles).
blocks. This trend is more prominent with small block size
settings. In fact, with 100 KB blocks, total work of Scenario 8. Conclusions and Future Work
I sub-blockchain is more than the total work of Scenario
VI sub-blockchain, the latter with a twenty-four times more In this paper, we presented a novel hybrid blockchain
difficult PoW puzzles than the former. Whereas, with 1 MB architecture for IoT, referred to as Hybrid-IoT. In Hybrid-
blocks, due to a simulated limited bandwidth (inherited from IoT, subgroups of IoT devices become peers on PoW sub-
the need to replicate low bandwidth IoT), block generation blockchains, connected with a BFT inter-connector frame-
intervals are longer. With 1 MB block size, total work work. In this paper, we analyze the design of the PoW sub-
of Scenario II sub-blockchain is more than the Scenario blockchains. The performance evaluation proves the validity
IV sub-blockchain, the latter with six times more difficult of the PoW sub-blockchain design under the sweet-spot

9
guidelines. Furthermore, we demonstrate that the sweet-spot [19] G. O. Karame et al., “Misbehavior in bitcoin: A study of double-
guidelines also prevent security vulnerabilities. spending and accountability,” ACM Transactions on Information and
System Security (TISSEC), vol. 18, no. 1, p. 2, 2015.
Future work includes: analyze and stress data volumes
in Hybrid-IoT; identify a BFT inter-connector framework [20] R. Roman et al., “On the features and challenges of security and
privacy in distributed internet of things,” Computer Networks, vol. 57,
to test the current design; prove the correctness of Hybrid- no. 10, pp. 2266–2279, 2013.
IoT design with properly done security proofs; implement a
[21] C. Natoli et al., “The blockchain anomaly,” in Network Computing
crash fault tolerant algorithm for the light peers, to address and Applications (NCA), 2016 IEEE 15th International Symposium
the issue of a full peer subnet losing the connection to light on. IEEE, 2016, pp. 310–317.
peers in its subnet (due to several reasons, malicious or
[22] L. Da Xu et al., “Internet of things in industries: A survey,” IEEE
not); analyzing the energy footprint of PoW Hybrid-IoT; Transactions on industrial informatics, vol. 10, no. 4, pp. 2233–2243,
and design a PoW algorithm that is IoT energy friendly. 2014.

References
[1] B. Carminati et al., “Enhancing user control on personal data usage
in internet of things ecosystems,” in Services Computing (SCC), 2016
IEEE International Conference on. IEEE, 2016, pp. 291–298.
[2] G. Sagirlar et al., “Decentralizing Privacy Enforcement for Internet
of Things Smart Objects,” ArXiv e-prints, Apr. 2018.
[3] J. Wu et al., “R-osgi-based architecture of distributed smart home
system,” IEEE Transactions on Consumer Electronics, vol. 54, no. 3,
2008.
[4] R. C. Merkle, “A digital signature based on a conventional encryption
function,” in Conference on the Theory and Application of Crypto-
graphic Techniques. Springer, 1987, pp. 369–378.
[5] F. Tschorsch et al., “Bitcoin and beyond: A technical survey on
decentralized digital currencies,” IEEE Communications Surveys &
Tutorials, vol. 18, no. 3, pp. 2084–2123, 2016.
[6] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
[7] E. Buchman, “Tendermint: Byzantine fault tolerance in the age of
blockchains,” Ph.D. dissertation, 2016.
[8] A. Bahga et al., “Blockchain platform for industrial internet of
things,” J. Softw. Eng. Appl, vol. 9, no. 10, p. 533, 2016.
[9] S. Huh et al., “Managing iot devices using blockchain platform,” in
Advanced Communication Technology (ICACT), 2017 19th Interna-
tional Conference on. IEEE, 2017, pp. 464–467.
[10] B. Lee et al., “Blockchain-based secure firmware update for embed-
ded devices in an internet of things environment,” The Journal of
Supercomputing, pp. 1–16, 2016.
[11] S. H. Hashemi et al., “World of empowered iot users,” in Internet-
of-Things Design and Implementation (IoTDI), 2016 IEEE First
International Conference on. IEEE, 2016, pp. 13–24.
[12] O. Alphand et al., “Iotchain: A blockchain security architecture
for the internet of things,” in IEEE Wireless Communications and
Networking Conference, 2018.
[13] A. Dorri et al., “Lsb: A lightweight scalable blockchain for iot
security and privacy,” arXiv preprint arXiv:1712.02969, 2017.
[14] B. Liu et al., “Blockchain based data integrity service framework
for iot data,” in Web Services (ICWS), 2017 IEEE International
Conference on. IEEE, 2017, pp. 468–475.
[15] A. Gervais et al., “On the security and performance of proof of work
blockchains,” in Proceedings of the 2016 ACM SIGSAC Conference
on Computer and Communications Security. ACM, 2016, pp. 3–16.
[16] K. Croman et al., “On scaling decentralized blockchains,” in Inter-
national Conference on Financial Cryptography and Data Security.
Springer, 2016, pp. 106–125.
[17] A. Miller et al., “Discovering bitcoin’s public topology and influential
nodes,” et al., 2015.
[18] Z. Zheng et al., “An overview of blockchain technology: Architecture,
consensus, and future trends,” in Big Data (BigData Congress), 2017
IEEE International Congress on. IEEE, 2017, pp. 557–564.

10