This article has been accepted for publication in a future issue of this journal, but has not been

fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TII.2019.2897805, IEEE
Transactions on Industrial Informatics

Performance Optimization for Blockchain-Enabled

Industrial Internet of Things (IIoT) Systems: A
Deep Reinforcement Learning Approach
Mengting Liu, F. Richard Yu, Fellow, IEEE, Yinglei Teng, Member, IEEE,
Victor C. M. Leung, Fellow, IEEE, and Mei Song

Abstract—Recent advances in industrial Internet of things cost and delay [8]–[11]. Therefore, data security and efficiency
(IIoT) provide plenty of opportunities for various industries. become critical concerns for IIoT [12].
To address the security and efficiency issues of the massive
To address the above issues, Blockchain is widely con-
IIoT data, blockchain is widely considered as a promising
solution to enable data storing/processing/sharing in a secure sidered as a promising solution, which can build a secure
and efficient way. To meet the high throughput requirement, this and efficient environment for data storing/processing/sharing
paper proposes a novel deep reinforcement learning (DRL) based in IIoT [13], [14]. Blockchain, firstly used as a peer-to-peer
performance optimization framework for blockchain-enabled (P2P) ledger for Bitcoin economic transactions [15], can guar-
IIoT systems, the goals of which are three-fold: 1) providing
antee data security and efficiency by enabling anonymous and
a methodology for evaluating the system from the aspects of
scalability, decentralization, latency and security; 2) improving trustful transactions and removing all kinds of intermediaries.
the scalability of the underlying blockchain without affecting Although blockchain technology brings significant benefits, it
the system’s decentralization, latency and security; 3) designing is challenging for traditional blockchain systems to provide the
a modulable blockchain for IIoT systems, where the block scalability necessary to meet the high transactional throughput
producers, consensus algorithm, block size and block interval can
requirement of IIoT.
be selected/adjusted using the DRL technique. Simulations results
show that our proposed framework can effectively improve the In fact, scalability has become a key issue that prevents
performance of blockchain-enabled IIoT systems and well adapt blockchain from being used as a generic platform for d-
to the dynamics of IIoT. ifferent services and applications [16]. Bitcoin, the first-
Index Terms—Blockchain, industrial internet of things (IIoT), known blockchain-based cryptocurrency, can only confirm
performance optimization, deep reinforcement learning an average of about 3-4 transactions per second (TPS) [17]
while Ethereum improves the throughput to about 14 TPS
I. I NTRODUCTION [18], which is still not enough to deal with high frequency
transactions scenarios such as IIoT. Recently, a number of
As an emerging technology, the industrial Internet of things teams are working on realizing general, scalable and deploy-
(IIoT), a.k.a. industrial Internet, has received great attention able blockchain platforms, which can be divided into two
in various industrial sectors such as manufacturing, logistic- categories. One is through on-chain scaling solutions, such
s, retailing, environmental monitoring, security surveillance, as adjusting the block size and interval (e.g., BitcoinCash
energy/utilities, aviation, healthcare, etc. [1]–[5]. With the [19]), shifting the process of issuing blocks (e.g., Bitcoin-NG
advances in wireless communication and sensor network tech- [20]), introducing new consensus mechanisms like Proof of
nologies, more and more smart objects are being involved in Stake (PoS), Delegated Proof of Stake (DPoS) and Practical
IIoT, where massive raw data is captured and processed to Byzantine Fault Tolerance (PBFT) (e.g., Cardano [21], EOS
support decision making [6], [7]. Nowadays, most IIoT appli- [22]), using Sharding technique (e.g., Zilliqa [23]), etc. The
cations rely on centralized servers for data storing/processing other is through off-chain scaling solutions that aim at reduc-
and intermediaries for data transmission, which exposes the ing the redundancy on the main blockchain using Sidechains
data to security risks and also introduces high operational (e.g., Plasma [24]), Multi-chains (e.g., Cosmos [25], AION
This work was supported in part by the National Key R&D Program
[26]), Lightning network [27], Payment channels (e.g., Raiden
of China (No. 2018YFB1201500), in part by the National Natural Science network [28], TeeChan [29]), etc.
Foundation of China under Grant No. 61771072, in part by the Beijing Nevertheless, these emerging blockchain platforms are stil-
Natural Science Foundation under Grant No. L171011, in part by the
Beijing Major Science and Technology Special Projects under Grant No. l facing significant challenges when applied in IIoT. For
Z181100003118012, and in part by the scholarship from China Scholarship example, most emerging blockchain platforms only focus
Council under Grant No. 201706470059.(Corresponding author: Yinglei Teng) on increasing transactional throughput by sacrificing other
M. Liu, Y. Teng and M. Song are with Beijing Key Laboratory of Space-
ground Interconnection and Convergence, Beijing University of Posts and important performance measures, such as decentralization,
Telecommunications, Beijing, 100876, China. security or latency1 . There is a well-known Trilemma in
F. R. Yu is with the Department of Systems and Computer Engineering, blockchain: a blockchain system can only at most have two
Carleton University, Ottawa, ON K1S 5B6, Canada.
V. C. M. Leung is with the Department of Electrical and Computer
Engineering, The University of British Columbia, Vancouver, BC V6T 1Z4, 1 In this paper, latency refers to “time to finality” that measures the time
Canada. used for a transaction to be finalized/confirmed (specified in Section II-B).

1551-3203 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TII.2019.2897805, IEEE
Transactions on Industrial Informatics

of the following three properties: decentralization, scalability to academic. [8] describes how the integration of IIoT and
and security. Therefore, these properties should be carefully blockchain will improve the security and efficiency of various
considered in designing blockchain-enabled IIoT systems. industrial sectors such as supply chain, autonomous vehicle
To address the above challenges, this paper proposes a and manufacturing plant equipment. Based on blockchain
performance optimization framework for blockchain-enabled technology, the authors of [9] present a trusted and resilient
IIoT systems to improve the performance of data security and communication architecture for IIoT applications, which can
efficiency, where the scalability/throughput can be optimized achieve data assurance, resilience and accountability. To ensure
while taking into account of system decentralization, security the security and privacy of trading data and consumption in the
and latency. In addition, to handle the dynamic and large- smart grid energy trading scenario, blockchain is used together
dimension characteristics of IIoT systems, a deep reinforce- with several other technologies including multi-signatures, and
ment learning (DRL) approach is adopted, which shows its anonymous encrypted messaging streams in [10]. Besides, a
superiority in dealing with dynamic and complicated problems blockchain-based platform architecture is proposed for IIoT
[30], [31]. The main contributions of this paper are listed as in [11], to provide trust between the participants and control
follows. over the distribution of resources. All of the above works
• To our best knowledge, we are the first to present have pointed out that the scalability is a major concern of
a performance optimization framework for blockchain- blockchain-enabled IIoT systems. However, the performance
enabled IIoT systems to improve the performance of of blockchain systems (scalability, decentralization, security or
data security and efficiency, where the four-way trade-off, latency) hasn’t been well investigated in these works.
i.e., scalability, decentralization, security and latency, is
considered.
• In order to facilitate performance optimization, we quan-
B. The Four-way Trade-off of Blockchain Systems
tify the performance of blockchain systems from the as- Similar to the CAP (Consistency, Availability, tolerance to
pects of scalability, decentralization, latency and security. network Partitions) theorem of robust distributed systems [32]:
• To handle the dynamic and large-dimension characteris- “A robust distributed system can only simultaneously provide
tics of IIoT systems, we design a DRL-based algorithm to two out of the three properties”, the challenge of scaling the
dynamically select/adjust the block producers, consensus blockchain systems can be considered as a four-way trade-off,
algorithm, block size, and block interval to improve the which involves the following four properties:
performance. Scalability: The scalability issue refers to the ability for
• Simulation results show that the proposed performance the blockchain systems to process transactions. To make the
optimization framework can well address the scalability blockchain technology more pervasive, the system should be
issue for blockchain-enabled IIoT systems while guaran- able to handle the increasing volume of transactions in a wide
teeing other performance, and can facilitate a wide range range of applications [33].
of applications in blockchain-enabled IIoT systems. Decentralization: Decentralization reflects the fragmenta-
The rest of this paper is organized as follows. We present the tion of control over the whole system, which allows the
related works in Section II. Section III describes the system system to achieve other goals: censorship resistance, open
model. The performance analysis for blockchain systems is participation, immunity from certain attacks, and elimination
carried out in Section IV. In Section V, the proposed DRL- of single points of failure [34].
based algorithm is presented. Section VI discusses the simu- Security: The blockchain systems should guarantee the
lation results. Finally, Section VII concludes the paper. immutability of the ledger, which is reflected by its general
robustness to attacks such as 51% attack, Sybil attack, dis-
II. R ELATED W ORKS tributed deny of service (DDoS), etc. [35].
Latency: The latency of the blockchain is measured by time
In this section, we present some related works concerning
to finality (TTF) that is defined as the time for transactions to
blockchain-enabled IIoT systems and the four-way trade-off of
be finalized/confirmed and become irreversible [36].
blockchain systems to provide some necessary backgrounds.
Most existing blockchain systems can only achieve part of
these four properties but sacrificing others. We give some
A. Blockchain-enabled Industrial Internet of Things (IIoT) examples that are in line with this observation as follows.
Recent years have witnessed the rapid development of Permissionless PoW systems (e.g., Bitcoin, Ethereum 1.0)
IIoT, which is reshaping various industrials such as agricul- can achieve good decentralization and security while suffer
ture, environmental monitoring, and security surveillance [1]. poor scalability and finality. Centralized block production
Meanwhile, blockchain technology can enable the storing, pro- systems (e.g., Cardano, EOS) attempt to achieve scalability by
cessing and sharing of the data captured from the IIoT devices sacrificing the decentralization of block producers. Meanwhile,
using a distributed, decentralized and shared ledger [16], thus multi-chains systems (e.g., Cosmos, AION) gain scalability,
can overcome some obstacles of IIoT like security risks, high decentralization and fast TTF at the expense of undertaking
operational cost and frequency delay. In this sense, the con- additional attack risks. Therefore, this motivates us to design
vergence of IIoT and blockchain can facilitate the realization a performance optimization framework for blockchain-enabled
of IIoT, which has also attracted great attention from industry IIoT systems to address the four-way trade-off issue.

1551-3203 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TII.2019.2897805, IEEE
Transactions on Industrial Informatics

in a trustless and secure manner. The models of these two parts

Blockchain system are presented as follows.
Block Block Block Block Block Block ĊĊ
IIoT Node A. IIoT Network
Block
Block producer
ator)
(Validator)
In IIoT networks, smart devices (e.g., industrial equipment,
vehicles, drones, surveillance, etc.) are capable of using sen-
Reach consensus
sors to collect ambient data or using embedded cameras to
capture the images or videos, which should be captured and
P2P network stored/processed in a secure manner. Meanwhile, it’s likely
that the collected data needs to be shared between different
Transaction: industrial sectors for efficient decision making. Therefore, we
Transaction: Transaction: data storing/processing
data storing/processing data storing/processing consider two kinds of transactions2 (data storing/processing
and data sharing) continuously created by the smart devices.
Aviation
Smart Afterwards, these transactions are relayed to blockchain sys-
grid
tems for storing/fetching the data into/from the distributed
Transaction:
data sharing Security ledger, i.e., the underlying blockchain.
surveillance
ingg
Manufacturing
Transaction: Transaction:
Transaction:
data sharing
data sharing data sharing
Environmental
B. Blockchain System
Healthcare
monitoring
Transaction:
To handle the transactions generated from the IIoT network,
Transaction: data sharing the block producers need to complete the following steps: i)
Smart house data sharing
Generate a block: collect, validate and package the transac-
IIoT network
Robotics tions into a block. ii) Append the block to the blockchain:
Logistics broadcast the generated block to other block producers, and
add the block to their local blockchain after a consensus is
reached on the new block [22]. Therefore, there are two key
Fig. 1: Illustration of blockchain-enabled IIoT systems.
factors, the block producers (a.k.a. validators) , the models of
which are given as follows.
1) Block Producers:
C. Performance Analysis of Blockchain Systems In this paper, we assume that there are N IIoT nodes
Some attempts have been made to measure the performance and K block producers in the blockchain system. The set of
of blockchain systems. In [37], performance analysis of two nodes is denoted as ΦS = {z1 , z2 , . . . , zN }, and the stake
private blockchains, i.e., Ethereum and Hyperledger Fabric, is and computational resource of node zn , n = 1, . . . , N are
carried out in terms of average execution time, latency and represented by Υn (in token) and cn (in GHz), respective-
throughput. However, the performance analysis is obtained ly. For clarity, we use Υ = {Υ1 , Υ2 , . . . , Υn } and c =
through simulation while explicit quantitative measurement is {c1 , c2 , . . . , cn } to denote the set of stakes and computational
absent. [38] presents a comparative assessment of decentral- resources. Note that these K block producers, represented by
ization for Bitcoin and Ethereum by several metrics includ- ΦB = {zb1 , . . . , zbk , . . . , zbK } , ΦB ⊆ ΦS , are selected out of
ing provisioned bandwidth, network structure, distribution of ΦS according to certain rules (specified in Section V-C). As-
mining power, mining power utilization and fairness, where sume the block producers are gathered at independent random
explicit quantification of these factors is still unaddressed positions in R2 according to an inhomogeneous Poisson point
and this assessment method only works for PoW systems. process (PPP) with density λ (x) [40], where the location
Besides, [35] and [39] provide a quantitative measurement of node zn is represented by the two-dimension coordinate
for PoW blockchains, where the decentralization, security xn ∈ R2 and x = {xn } is the location set. ∫∫ The density λ (x)
and latency are evaluated by the number of block producers, is defined such that E {N um (A)} = A λ (x)dx for any
orphaning/fork probability and propagation time, respectively. A ⊆ R2 , where N um (A) is the number of nodes in area A.
Although providing some insights for performance analysis of In the blockchain-enabled IIoT system, we assume that these
blockchain systems, these works lack of comprehensiveness K block producers take turns to produce blocks with block
and generality. Therefore, this motivates us to design a com- size S B (in MB) and block interval T I (in seconds).
prehensive and general evaluation methodology to facilitate 2) Consensus Models:
the performance optimization of blockchain systems. It’s noted that there’s no one-size-fits-all protocol consider-
ing varying system conditions [41]. This motivates us to design
an adaptive consensus algorithm where a set of consensus
III. S YSTEM M ODEL protocols (i.e., PBFT [42], Zyzzyva [43], Quorum [44]) are
As is shown in Fig. 1, we consider a blockchain-enabled considered as candidates. The most suitable consensus mech-
IIoT system, which consists of two parts, i.e., the IIoT network anism is dynamically selected according to the requirements
that generates transactions of data storing/processing and data 2 A transaction is defined as an instance of changing ownership of tokens
sharing, and blockchain system that deals with the transactions through digital signing portion of data and broadcasting it to the network [10].

1551-3203 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TII.2019.2897805, IEEE
Transactions on Industrial Informatics

Order Speculative
Request Pre-prepare Prepare Commit Reply Request
Client Client request reply

Primary 0 Primary 0

Replica 1 Replica 1

Replica 2 Replica 2

Replica 3 Replica 3
t1 t2 t3 t4 t5 t1 t2 t3

(a) One-phase (Fast case)

Fig. 2: Protocol communication pattern of PBFT.
Order Speculative
Request Commit Reply
Client request reply

of applications and the system conditions. In the following, Primary 0

we first give a brief introduction of these three consensus
Replica 1
protocols, and then describe the assumptions of the consensus
model adopted in this paper. Replica 2

• A Brief Introduction of Consensus Protocols Replica 3

t1 t2 t3 tr t4 t5
(i) PBFT (b) Two-phase
PBFT is a well-known and widely-used consensus protocol,
which is adopted by EOS, Hyperledger, etc. It’s considered as Fig. 3: Protocol communication pattern of Zyzzyva.
a very robust protocol since an consensus can be achieved as
long as more than a fraction (2/3) of replicas are honest [42].
Although enjoying strong robustness, PBFT suffers significant Request Reply
Client
performance drawbacks. This is mainly because the whole
consensus process includes five phases: Request, Pre-pare, Replica 0
Prepare, Commit and Reply, as shown in Fig 2. The message Replica 1
exchanging among the replicas is time-consuming, which
causes a long consensus latency. Besides, each replica has Replica 2
to validate the messages from most of the other replicas, Replica 3
which sets high demand for computing resources, such that t1 t2
one replica can’t handle to many requests at one time.
(ii) Zyzzyva Fig. 4: Protocol communication pattern of Quorum.
Zyzzyva is a speculative BFT protocol where the client
sends a request to a replica (a primary) and then this primary
replica forwards it to other replicas [43]. These replicas requests at one time use batching while Quorum is not able
execute the request speculatively and send their replies back to support batching.
to the client. Same with BPFT, the consensus can be reached
• Consensus Model Assumptions
if there are no more than 1/3 faulty replicas, but the difference
is that there is no message exchanging between replicas for In the blockchain system, we consider the block producer
Zyzzyva. The performance of this protocol varies for different that generates a new block as the client zbc , c = 1, 2, . . . , K,
cases, as is shown in Fig. 3. In fast case, i.e., all the replicas and the other block producers are regarded as replicas zbi , i =
are honest, the replies that client received from all the replicas 1, 2, . . . , K, i ̸= c. In other words, the client issues a block
match with each other. In this case, the consensus can be with a number of transactions and broadcasts it to other
reached in a very short time. In another case, if there’s any validators to reach a consensus. During the consensus process,
faulty replica, complex recovery phases will be launched and there is one replica that is designated as the primary. In this
a recovery time tr is required, thus the performance may be paper, we consider a Byzantine failure model where several
significantly deteriorated. assumptions are made: 1) The client and the primary is correct
(iii) Quorum and there are f faulty replicas. 2) The faulty replicas can
Quorum is widely considered as the “fastest” BFT protocol, behave arbitrarily, such as sending incorrect messages, sending
where only one-phase message pattern is involved, as is shown the correct messages too slowly, or sending messages too
in Fig. 4: a client broadcasts its request to all the replicas, and quickly to introduce overhead. 3) The consensus system is
the replicas send their replies back [44]. The simple consensus an asynchronous network where synchronous intervals occur
process brings a short consensus latency as well as a high infinitely. During a synchronous interval, any message sent is
throughput. However, it’s extremely vulnerable to attacks since delivered within a timeout T . 4) The correct replicas schedule
the consensus can’t be reached once any replica is malicious. messages from other replicas in a round-robin fashion [45].
Besides, both PBFT and Zyzzyva can process a number of Note that the consensus process mainly involves exchanging

1551-3203 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TII.2019.2897805, IEEE
Transactions on Industrial Informatics

and verifying messages [41]. For the message exchanging, To measure the decentralization of blockchain systems,
we model the time-varying transmission links as finite-state we utilize Gini coefficient, which was well studied as a
Markov channels (FSMC). Let Rbi ,bj (t) denote the data measurement for the inequality of wealth or income [46]. Due
transmission rate of the link connecting validator zbi and to its advantages in evaluating “inequality”, Gini coefficient
validator zbj , i, j = 1, 2, . . . , K, i, j ̸= c, which is partitioned has been widely used in many fields, such as capturing “system
and quantized into L levels, i.e., r = {r1 , r2 , . . . , rL }. fairness” [47], “contrast intensity” [48], “resource difference
Then the L × L transition probability matrix w.r.t. Rbi ,bj (t) degree” [49], etc.
is [defined as p (t) = [pm (t)]L×L] , where pm (t) = In this paper, we focus on the decentralization of block pro-
Pr Rbi ,bj (t + 1) = y2 Rbi ,bj (t) = y1 and y1 , y2 ∈ r. For ducers and consider two typical factors (i.e., stakes distribution
message verification, we only consider the computing cost and geographical locations)3 . To describe the decentralization
of the cryptographic operations as in [45], which includes w.r.t. stakes distribution, the Gini coefficient of the block
verifying signatures, generating message authentication codes producers’ stakes can be calculated by (2). The details of Gini
(MACs), and verifying MACs, requiring α, β, and β CPU coefficient are given in Appendix A.
cycles, respectively. ∑ ∑ ∑ ∑
|Υbi−Υbj | |Υbi−Υbj |
zb ∈ΦB zb ∈ΦB zb ∈ΦB zb ∈ΦB
i j i j
G (Υ) = ∑ ∑ = ∑ ,
2 Υbi 2K Υbi
IV. P ERFORMANCE A NALYSIS zb ∈ΦB zb ∈ΦB
i j
zb ∈ΦB
i
(2)
In this section, we first use transactional throughput to
measure system’s scalability. Then the other properties, i.e., For the decentralization w.r.t. geographical locations, we re-
decentralization, latency and security, are served as the scala- call that the assumption that the block producers are distributed
bility constraints to address the four-way trade-off issue. according to an inhomogeneous PPP with density λ (x) at
x ∈ R2 . Since the density distribution λ (x) is a continuous
function of x, the Gini coefficient can be calculated in terms
A. Scalability of integration as follows [48].
∫ ∫ ∫ ∫
Literally, blockchain refers to a chain of blocks, where Ξ∫
|λ(x)−λ(y)|dydx |λ(x)−λ(y)|dydx
G (λ) = Ξ ∫ = Ξ Ξ
, (3)
2 Ξ Ξ λ(x)dydx 2K
each block contains a number of transactions. In blockchain
systems, scalability can be evaluated by transactional through- where the density set is λ = {λ (x)} , x ∈ Ξ, and the block
put, which directly depends on two performance-related pa- producers are scattered in region Ξ ⊆ R2 .
rameters: block size and block interval. one is block size, Note that the values of Gini coefficient are within [0, 1],
i.e., the number of bytes can be contained in each block, where 0 and 1 denote the highest decentralized and the highest
which determines how many transactions can be included in centralized, respectively. In other words, the more uniform
one block. The other is block interval, i.e., the average time or decentralized the distribution of stakes/locations, the closer
required for the block producer to produce a new block, which the coefficients are to 0. To guarantee the decentralization of
captures the block release rate. Considering these two factors, block producers from the aspects of stakes distribution and
the transactional throughput can be calculated by geographical locations, the following constraints should be
( ) ⌊S B /χ⌋ satisfied.
Ω SB , T I = T I , (1)
G (Υ) ≤ ηs , (4)
where S B represents the block size (the number of bytes can and
be contained in each block), T I is the block interval (the G (λ) ≤ ηl . (5)
average time required for the block producer to produce a
new block), and χ denotes the average size of transactions. where ηs , ηl ∈ [0, 1] are the thresholds of decentralization w.r.t.
Observing (1), we can find an intuitive way to improve the stakes distribution and geographical locations, respectively.
on-chain transactional throughput is to increase the block size 2) Latency/Time to Finality (TTF):
or to cut down the time interval between blocks. However, We evaluate the latency of the blockchain system by TTF,
since the generated blocks have to be verified among the i.e., time to finality, which measures how long it takes to
validators based on a consensus mechanism, the selection of receive a reasonable guarantee that the transaction written
validators and consensus algorithm is also of great importance. in blockchain is irreversible, or in other words, is finalized.
As revealed by the four-way trade-off, the scalability of Recall that the transaction processing includes two phases,
blockchain systems is affected by the other three factors, i.e., generate a block and reach a consensus on the generated
i.e., decentralization, latency and security, which also means block among the validators. In this sense, the TTF for the
that the adjustment should not be conducted arbitrarily for transactions includes the block generation time (i.e., block
the block size, block interval, selection of block producers, interval) and the time for the block to be validated, which
and consensus algorithm. In the following, we quantify these is denoted by
factors in blockchain systems. T F,δ = T I + T C,δ , (6)
where T C,δ is the consensus latency, i.e., the time cost for the
B. Scalability Constraints 3 This method can be easily extended to measure the system’s decentraliza-
1) Decentralization: tion from other aspects.

1551-3203 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TII.2019.2897805, IEEE
Transactions on Industrial Informatics

validators to authenticate the generated block, which depends V. DRL- BASED P ERFORMANCE O PTIMIZATION
on the adopted consensus algorithm. We use δ = 0, 1, 2 to F RAMEWORK
denote three different consensus protocols, i.e., PBFT, Zyzzy- To handle the dynamic and large-dimension characteristics
va, Quorum, respectively. For simplicity, we divide the whole of IIoT systems, we resort to the DRL approach. The DR-
validation process into two parts, i.e., messages delivering L framework [50] contains an offline deep neural network
and messages verification (verifying signatures, generating and (DNN) construction phase that can approximate the action-
verifying MACs). Therefore, we can calculate the consensus value function with corresponding states and actions, and an
latency by online dynamic deep Q-learning phase for action selection,
T C,δ = T D,δ + T V,δ , (7) system control, and dynamic network updating. To implement
where the derivation of message delivery time T D,δ and the the DRL-based algorithm, we identify the state space, action
validation time T V,δ for these three consensus protocols δ = space and reward function as follows.
0, 1, 2 are given in Appendix A.
In IIoT networks, the smart devices usually expect to receive A. State Space
the finality of transactions within a short time. In order to We define the state space at decision epoch t (t = 1, 2, . . .)
meet the delay requirement of IIoT networks, we assume that as a union of the transaction size χ, stakes distribution Υ,
one block should be issued and validated within a number of geographical location of IIoT nodes x, computing capability
consecutive block intervals, i.e., ω (ω > 1) block intervals4 . of IIoT nodes c = {ck }, and the date transmission rate of the
Specifically, the TTF satisfy the following constraint. links between each pair of IIoT nodes R = {Ri,j }, which is
denoted as
T F,δ ≤ ω × T I , δ = 0, 1, 2. (8) (t)
S (t) = [χ, Υ, x, c, R] . (10)
3) Security:
For security, the first generation blockchain consensus al- B. Action Space
gorithm (PoW, PoS, DPoS) can only offer high probability of In order to maximize the throughput, several parts of the
security. In theory, someone could use enough (> 51%) mining blockchain system should be adjusted to adapt to the dynam-
power/stake to mine/mint an alternative “longer” blockchain ic environment, which includes the block producers a, the
that goes all the way back to genesis [35], [39]. However, consensus algorithm δ, block size S B and block interval T I .
for the BFT-type protocols, unambiguous finality can be Formally, the action space at decision epoch t is expressed by
reached under all network conditions as long as a fraction [ ](t)
of participants are honest [42]. Therefore, the loyalty of the A(t) = a, δ, S B , T I , (11)
validators are very critical for BFT-type consensus algorithms. where the block producers indicator is a = {an } , an ∈
To guarantee the security of blockchain systems with consen- ∑
N
sus algorithm δ, the number of malicious validators f should {0, 1} , an = K, zn ∈ ΦS with an = 1 representing
n=1
be restricted by the following constraint. node zn is chosen as a block producer while an = 0
otherwise. Besides, the action w.r.t. consensus algorithm s-
f ≤ F δ , δ = 0, 1, 2, (9)
⌊ ⌋ election is denoted by δ = {0, 1, 2}, which means PBFT,
where F 0 = F 1 = K−1 3 and F 2 = 0 represent for the Zyzzyva, and Quorum is selected as the consensus protocol,
maximum tolerable number of malicious validators. {
respectively. Additionally, }
using limited fractional methods,
It can be observed from (1) and (8) that the effects of block size S B ∈ 0.2, 0.4, . . . , Ṡ and block interval T I ∈
{ }
block size and block interval act in two ways. For one thing, 0.5, 1, . . . , Ṫ with block size limit Ṡ and maximum block
increasing block size or reducing block interval can bring an
improvement of transactional throughput, as is illustrated in interval Ṫ .
(1). For another, the time for the transactions to be finalized
(i.e., TTF) increases with larger block size since there are C. Reward Function
more transactions to be validated at a time. Meanwhile, as The reward function is defined to maximize the transactional
shown in (8), the decrease of block interval imposes a stricter throughput while guaranteeing the decentralization, finality
constraint on consensus delay. Additionally, the consensus and security of the blockchain system, i.e., a decision should
delay is closely related to the chosen validators and the be made in each epoch to solve the following problem.
adopted consensus algorithm, which is restricted by (4), (5)
and (9). Therefore, the adjustment of block size and block P1: max Q (S, A)
A
interval or the selection of block producers and consensus C1 : G (Υ) ≤ ηs , G (λ) ≤ ηl , (12)
algorithm should be conducted elaborately, in order to reach C2 : T F,δ ≤ ω × T I , δ = 0, 1, 2,
the four-way trade-off. C3 : f ≤ F δ , δ = 0, 1, 2.
where Q (S, A)
[ ∞is the action-value function calculated by
]
∑ t (t) ( (t) (t) )  (0)
4 This
paper assumes that the transactions should be finalized within a Q (S, A) = E µR S ,A S = S, A = A
(0)
number of consecutive block time, which is in line with the concept of EOS t=0
[22]. More general case will be considered in future works. with the discount factor µ ∈ (0, 1] that reflects the tradeoff

1551-3203 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TII.2019.2897805, IEEE
Transactions on Industrial Informatics

between the immediate and future rewards, and we define the TABLE I: SIMULATION PARAMETERS
immediate reward as
{ Parameter Value
( (t) (t) ) ⌊S B /χ⌋
R (t)
S ,A = TI
, if C1 − C3 are satisf ied, The geographical coverage area of nodes 1km×1km

0, otherwise. The number of nodes, N 100

(13) The number of block producers, K 21
Note that if constraints C1 − C3 can’t be satisfied, it Average transaction size, χ 200B
means that the modulated blockchain system has a poor The stake of node zn , Υn 1-50 token
performance in decentralization, TTF or security. Therefore, The computing resource of node zn , cn 10-30GHz
we set the reward to be 0 for this case to avoid this invalid The data transmission rate of node zn , Rn 10-100Mbps
situation. Finally, we formally present the proposed DRL- Block size limit Ṡ 8MB
based performance optimization framework in Algorithm 1. Maximum block interval Ṫ 10s
The threshold of decentralization w.r.t. stakes distri-
0.2, 0.3
bution and geographical locations, ηs , ηl

Algorithm 1: DRL-based Performance Optimization The number of intervals that a new block should be
6
validated, ω
Framework for Blockchain-enabled IIoT systems
The computing cost for verifying signatures and
2MHz/1MHz
1 Offline DNN construction: generating/verifying MACs, α, β
2 1) Load the historical state transition profiles and The batch size, M 3
Q (S, A) value estimates in experience memory D;
3 2) Pre-train the DNN (main Q network) with input pairs ×105
(S, A) and the corresponding estimated Q (S, A). 2.4

4 Online learning: 2.2

5 for each decision epoch t do 2

6 / ∗ ∗∗ Modulating the blockchain system ∗ ∗ ∗/ 1.8

Throughput (TPS)

7 1) A random action is selected ( with probability

) ε, 1.6
otherwise A(t) = arg maxAQ S (t) , A(t) where Q (•)
1.4
is estimated by the main Q network;
8 2) Execute A(t) to select the block producers and 1.2

consensus algorithm, and adjust the block size and 1

block interval; 0.8 Proposed scheme

9 / ∗ ∗ ∗ ∗∗ Updating ∗ ∗ ∗ ∗ ∗/ 0.6
Proposed scheme without CAS
Proposed scheme with fixed block size
10 1) Observe the reward R((t) and the next state S)(t+1) ; 0.4
Proposed scheme with fixed block interval

11 2) Store the experience S (t) , A(t) , R(t) , S (t+1) into 0 0.2 0.4 0.6 0.8 1.0
Episode
1.2 1.4 1.6 1.8 2.0
×104
the experience memory D;
12 3) Randomly sample a )mini-batch of state transitions
( (i) Fig. 5: Convergence performance of different schemes.
S , A(i) , R(i) , S (i+1) from experience memory D;
13 4) Calculate the target Q-value from (the target Q)
network by y (i) = R(i) + γmaxA′ Q S (i+1) , A′ . algorithm selection (CAS): the validators use the PBFT proto-
14 5) Update the target Q network with loss function
[ ( )]2 col to reach consensus. 2) Proposed scheme with fixed block
L (θ) = y (i) − Q S (i) , A′ ; θ every G steps. size: the blocks generated by the block producers in different
15 end intervals are with the same size (4M B). 3) Proposed scheme
with fixed block interval: the frequency of issuing blocks is
fixed (every 1 second). 4) Existing static scheme: the decisions
are determined by maximizing the immediate reward.
VI. S IMULATION R ESULTS AND D ISCUSSIONS
In the simulation, we consider a blockchain-enabled I-
A. Performance of Convergence
IoT system with 100 IIoT nodes and 21 block producers
scattering over a 1km-by-1km area. The DNN included in Fig. 5 shows the convergence performance of our proposed
the proposed DRL-based framework was implemented using DRL-based performance optimization scheme. From Fig. 5,
PyTorch, which is a fast and flexible deep learning framework we can observe that the transactional throughput is very low at
[51]. For the software environment, we utilized PyTorch the beginning of the learning process. However, as the number
0.4.0 with Python 3.6 in Window 10 system. For different of episodes increases, the throughput increases and reaches
simulation scenarios, we trained the DRL-based framework a stable state after around 4000 episodes, which verifies the
with different initial parameters. The parameters settings used convergence performance of our proposed scheme. Besides, it
in the simulations are summarized in Table I. can also be found that the proposed scheme can receive higher
For comparison, four baseline schemes are considered in throughput than that of the other three DRL-based baselines,
the simulation part: 1) Proposed scheme without consensus which shows the advantage of our proposed framework.

1551-3203 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TII.2019.2897805, IEEE
Transactions on Industrial Informatics

1
Line of ideal decentralization
×105
Cumulative Percentage of stakes/density
0.9 Lorenz curve w.r.t. stakes distribution 2.2
Lorenz curve w.r.t. geographical location Proposed scheme
0.8 Proposed scheme without CAS
Gini coefficient threshold = 0.1, 0.2, 0.5 Proposed scheme with fixed block size
0.7 2.0
Proposed scheme with fixed block interval
Existing static scheme
0.6

Throughput (TPS)
1.8
0.5

0.4
1.6
0.3

0.2 1.4
0.1

0 1.2
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Cumulative Percentage of Block Producers
(from lowest to highest stakes/density) 1.0
100 150 200 250 300 350 400 450 500 550
Average Transaction Size (B)
Fig. 6: Decentralization performance of block producers.
Fig. 8: Throughput vs. average transaction size.
5
×10
2.4
Proposed scheme
Proposed scheme without CAS
Proposed scheme with fixed block size
2.2 Proposed scheme with fixed block interval
Existing static scheme
10
Existing static scheme
Throughput (TPS)

Proposed scheme with fixed block interval

2.0
9 Proposed scheme with fixed block size
Proposed scheme without CAS
Proposed scheme
8
1.8
Average TTF (s)

1.6
6

1.4 5
2 4 6 8 10 12 14 16 18 20
Threshold of TTF ( ω block intervals)
4

Fig. 7: Throughput vs. threshold of TTF. 3

10 12 14 16 18 20 22 24 26 28 30
Aeverage Computational Resources of Validators (GHz)

B. Decentralization Performance Fig. 9: Finality latency vs. average computational resources of

Fig. 6 describes the decentralization performance of the validators.
blockchain system. Different from [35] and [39], where the
decentralization performance is measured by the number of
block producers, we use a more general metric, Gini coefficien-
t, to capture the decentralization of the blockchain system w.r.t.
10000
stakes distribution and geographical location. We can see that
as the threshold of Gini coefficient decreases, the Lorenz curve
9000
gradually approaches to the ideal decentralized one (the red
line), i.e., the blockchain system becomes more decentralized.
Throughput (TPS)

8000
It reveals that Gini coefficient is an effective metric that is
able to measure the decentralization of blockchain system from 7000
different aspects in a quantitative way.
6000

C. Performance Comparison with the Baselines Proposed scheme

Proposed scheme without CAS
5000
We explore the effects of different parameters on the per- Proposed scheme with fixed block size
Proposed scheme with fixed block interval
formance of the blockchain-enabled IoT network in Fig. 7 - Existing static scheme
4000
Fig. 10. Specifically, the performance of our proposed DRL- 1 2 3 4 5 6 7 8 9 10
Block Size Limit (MB)
based framework is compared with that of the baselines with
different thresholds of TTF, average transaction sizes, average
Fig. 10: Throughput vs. block size limit.
computational resources of validators, and block size limits.
We can make the following observations.

1551-3203 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TII.2019.2897805, IEEE
Transactions on Industrial Informatics

1) The effect of the threshold of TTF on the system’s

tractional throughput is depicted in Fig. 7. We can see that all 100%
the schemes gain a higher transactional throughput with the

Cumulative Percentage of Stakes

increase of the threshold of TTF. This is because the validators
can handle more transactions in one block with a more
relaxed latency constraint. Besides, it can be observed that our Line of ideal decentralization
proposed scheme can achieve higher throughput consistently
than the baselines. Meanwhile, it’s noted that the fixed block
size scheme acts better than the fixed block interval scheme in
the case of strict TTF constraints. A reasonable explanation is
A B
that the fixed block size scheme can adjust the block interval to
deal with the low TTF threshold situation. Moreover, we can Lorenz curve
find the existing static scheme shows the poorest performance,
0 100%
which reveals the superiority of DRL-based solutions. Cumulative Percentage of Block Producers
2) Fig. 8 examines the transactional throughput with dif- (from lowest to highest stakes)
ferent transaction sizes, which makes sense when considering
different types of transactions, such as the transactions of stor- Fig. 11: An illustration of decentralization (take stakes distri-
ing the data of a shipment and a vehicle may be different. One bution for example).
observation is that the throughput of the blockchain system for
all the schemes decreases with the increasing transaction size.
The reason behind is obvious that one block can hold less A PPENDIX A
number of transactions for larger-size transactions. Another G INI C OEFFICIENT
observation is that our proposed scheme can obtain the highest Gini coefficient was first introduced by Corrado Gini in
throughput with the variation of average transaction size, then 1912 [46], which was primarily used as a measurement for
follows the proposed scheme without CAS, the fixed block size the inequality of wealth or income. There are two commonly
scheme and the fixed block interval scheme, and the lowest is accepted versions for the definition of Gini coefficient.
the existing static scheme. Similar observations can be made The first version is based on the Lorenz curve, where Gini
from Fig. 9: it takes the least time (lowest average TTF) for area(A)
coefficient is defined as a ratio of the areas area(A+B) [47],
the proposed scheme to confirm transactions when compared [49] (an example is shown in Fig. 11). In this case, Gini
with the baselines. coefficient can be interpreted as the degree of derivation from
3) In Fig. 10, we discuss the impact of block size limit the line of ideal decentralization.
Ṡ on the throughput, which is also a controversial topic for In the second version, Gini coefficient is defined as half of
scaling blockchain. Fig. 10 shows that the blockchain-enabled the relative mean absolute difference, which is mathematically
IoT network can handle more transactions with the increase equivalent to the Lorenz curve definition [52]. Specifically,
of block size limit, which works for all the schemes except the mean absolute difference is calculated by the average
the fixed block size scheme. However, the throughput does absolute difference of all pairs of items of the population,
not increase infinitely since the TTF constraint restricts the and the relative mean absolute difference is the mean absolute
maximum number of transactions in one block. This also difference divided by the average. Hence, the expression of
provides some insights into the design of blockchain systems Gini coefficient is given by [48], [52]
in real scenarios that increasing the block size limit is not
∑
n ∑
n ∑
n ∑
n
always helpful considering the other properties such as latency. |xi −xj | |xi −xj |
i=1 j=1 i=1 j=1
G= ∑ ∑
n n = ∑
n , (14)
2 xi 2n xi
i=1 j=1 i=1
VII. C ONCLUSION
where xi is the wealth or income of person i, and the total
In this paper, we proposed a novel DRL-based performance
number of persons is n. In this paper, we use the second
optimization framework for blockchain-enabled IIoT systems,
definition to calculate the Gini coefficient in order to measure
where the scalability of the blockchain was improved while
the decentralization of block producers.
guaranteeing the system’s decentralization, latency and securi-
ty. In our proposed framework, we first provided a quantitative
measurement for the performance of blockchain systems. Then A PPENDIX B
the on-chain transactional throughput of the blockchain system P ERFORMANCE A NALYSIS OF C ONSENSUS P ROTOCOLS
was maximized by selecting the block producers and consen- To decide when to implement which protocol, we evaluate
sus algorithm, and adjusting the block size and block interval the performance of these three protocols (i.e., PBFT, Zyzzyva,
using the DRL technique. Simulation results demonstrated that Quorum) from the aspects of fault-tolerance and consensus
the proposed framework can achieve higher throughput than delay. Note that both PBFT and Zyzzyva can process a number
the baselines with various system parameters. Future work of requests at one time use batching while Quorum is not able
is progress to consider other consensus algorithms and the to support batching [41].
decentralization of blockchain systems from other aspects. (i) PBFT

1551-3203 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TII.2019.2897805, IEEE
Transactions on Industrial Informatics

10

⌊ ⌋ ⌊ ⌋
PBFT can tolerance at most K−1 3 faulty replicas [42]. Zyzzyva can also tolerate K−1 3 ⌊ faulty⌋ replicas to guaran-
As is shown in Fig. 2, there are five phases in the PBFT tee the system security, i.e., F 1 = K−1 3 . Similarly, we can
communication pattern. For example, in the Request phase, the also evaluate Zyzzyva protocol as follows.
client zbc sends a request for block validation to the primary As is shown in Fig. 3, in the fast case, the primary zbp
(zbp , p = 1, . . . , K, p ̸= c), then the primary verifies one needs to verify M signature and complete 2M + K − 1 MAC
MAC for each request. Note that each request contains one operations while replica zbi , (i ̸= c, p) requires to verify M
signature that requires verification for each replica (validator) signature and complete M +1 MAC operations for each batch.
during the consensus process. 1) In the Request phase, the In this sense, the computational load per batch for the primary
(1)
client zbc sends a request for block validation to the primary zbp and the replica zbi are Ob1p = M α+(2M + K − 1) β and
(validator zbp , p = 1, . . . , K, p ̸= c), then the primary verifies (1)
Ob1i = M α + (M + 1) β, respectively. Therefore, the valida-
one MAC for each request. Note that each request contains one (1) (1)
tion time T V,1 and message delivery time T D,1 { of each}
signature that requires verification for each replica (validator) (1)
(1)
1 Ob1
during the consensus process. 2) In the Pre-prepare phase, the request can calculated by T V,1 = max
M k=1,...,K;k̸
k
cbk ,
=c
primary processes a batch of requests (M validation requests and
for M generated blocks) in a single pre-prepare message (1)
1
and forwards this message to all the replicas. In this phase, T D,1  = (t1 + t2 + t3 ) { } 
{M
}
the primary generates K − 1 MACs to send the pre-prepare M SB M SB
 min Rbc ,bp , T + min i̸max Rb ,b , T  .
message and each replica needs to verify one MAC. 3) For = 1  { } =c,p p i 
the Prepare phase, each replica authenticates the pre-prepare M  B 
+ min max RMb S,b , T
message and generates K − 1 MACs to all the other replicas, i̸=c i c

and verifies K −2 MACs when they receive them. Meanwhile, ( ) (16)

the primary needs to verify K − 1 MACs received from all In two-phase case where there are f f ≤ F 1 faulty repli-
the replicas. 4) In the Commit phase, all the replicas including cas, the computational load per batch for the primary zbp
(2)
the primary exchange the message between each other, so the and the replica zbi are Ob1p = M α + (4M + K + f − 1) β
primary and any replica first send and then receive K − 1 and Ob1i
(2)
= M α + (3M + 1) β, respectively. There-
commit messages, which need to generate K − 1 MACs and fore, the the validation time T V,1
(2)
and message delivery
verify K − 1 MACs, respectively. 5) In the Reply phase, the time T D,1
(2)
request can calculated by T V,1
of{ each }
(2)
=
primary and each replica generates a final MAC for each Ob1
(2)
1
request in the batch to reply to the client. max
M k=1,...,K;k̸
k
cbk , and
=c
Therefore, we can conclude that for each batch with bath
(2)
1
size M , the primary zbp needs to verify M signatures and T D,1  = (t1 + t2 + t3 + tr +{t4 + t5 ) } 
complete 2M + 4 (K − 1) MAC operations. Meanwhile, the
M
{ B
} B

replica zbi , (i ̸= c, p) needs to very M signature and complete  min RMb S,b , T + min max RMb S,b , T + 
 { c p } i̸=c,p p i

M( + 4 (K )− 1) MAC operations. Concerning the case with   .
= 1  M SB
min max Rb ,b , T + tr + 
f f ≤ F 0 faulty replicas, a correct replica will process at M  
 { i̸=c i c
} { } 
most two messages from a faulty server per message. This  M SB B 
is because a correct replica processes messages from other min max Rb ,b , T + min max RMb S,b , T
i̸=c c i i̸=c i c

replicas in round-robin order, and the faulty replicas may send (17)
messages too quickly in order to introduce overhead and fur- (iii) Quorum
ther retard the consensus process [45]. Considering the worst The robustness of Quorum is poorest among these three pro-
case, the computational load per batch for the primary zbp tocols since it fails to reach consensus once there’s any faulty
and the replica zbi are Ob0p = M α + [2M + 4 (K + f − 1)] β replica, i.e., F 2 = 0. The consensus process only involves
and Ob0i = M α + [M + 4 (K + f − 1)] β, respectively. So two phases – Request and Reply. Note that there’s no primary
the validation time T V,0{of each } request can be calculated by replica and batching doesn’t work for Quorum. We can derive
1 Ob0 that the computational load per request for the replica zbk , k =
T V,0 = max k
.
M k=1,...,K;k̸ =c cbk 1, . . . , K, k ̸= c is Ob2k = α+2β. Therefore, the the validation
Recall that any message sent is delivered within a timeout time T V,2 and message delivery time of{each } request T D,1
(2)

T . Hence, the message delivery time T D,0 of each request can O2

be derived as follows. can calculated by T V,2 = max bk
cbk and T D,2 =
1
{ }
k=1,...,K;k̸ = c { }
T D,0 
= (t1 + t2 + t3 + t4 + t5{) }  t1 + t2 = min max S B , T + min max S B , T .
M
{ B
} B Rb ,b Rb ,b
i̸=c c i̸=c c
min RMb S,b , T + min max RMb S,b , T +
i i
 
 { c p } i̸=c,p p i 
  .
= 1  min
B
max RMb S,b , T +  R EFERENCES
M  
 { j;i,j̸=c i j}
i̸ = { } 
 B B  [1] L. D. Xu, W. He, and S. Li, “Internet of things in industries: A survey,”
min max RMb S,b , T + min max RMb S,b , T IEEE Trans. Ind. Informat., vol. 10, no. 4, pp. 2233–2243, Nov. 2014.
i̸=j i j i̸=c i c
[2] J. Kang, R. Yu, X. Huang, M. Wu, S. Maharjan, S. Xie, and Y. Zhang,
(15) “Blockchain for secure and efficient data sharing in vehicular edge
(ii) Zyzzyva computing and networks,” IEEE Internet of Things, accepted, Nov. 2018.

1551-3203 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TII.2019.2897805, IEEE
Transactions on Industrial Informatics

11

[3] H. Liu, Y. Zhang, and T. Yang, “Blockchain enabled security in electric [28] “The raiden network,” 2015. https://raiden.network/; accessed on 7 Sept.
vehicles cloud and edge computing,” IEEE Network Magazine, vol. 32, 2018.
no. 3, pp. 78 – 83, May/June 2018. [29] J. Lind, I. Eyal, P. Pietzuch, and E. G. Sirer, “Teechan: Payment chan-
[4] J. Kang, R. Yu, X. Huang, S. Maharjan, Y. Zhang, and E. Hossain, nels using trusted execution environments,” [online] arXiv:1612.07766
“Enabling localized peer-to-peer electricity trading among plug-in hy- [cs.CR], Dec. 2016.
brid electric vehicles using consortium blockchains,” IEEE Trans. Ind. [30] Y. He, Z. Zhang, F. R. Yu, N. Zhao, H. Yin, V. C. M. Leung, and
Informat., vol. 13, no. 6, pp. 3154 – 3164, Dec. 2017. Y. Zhang, “Deep-reinforcement-learning-based optimization for cache-
[5] Z. Zhou, B. Wang, Y. Guo, and Y. Zhang, “Blockchain and computation- enabled opportunistic interference alignment wireless networks,” IEEE
al intelligence inspired incentive-compatible demand response in internet Trans. Veh. Tech., vol. 66, no. 11, pp. 10 433–10 445, Nov. 2017.
of electric vehicles,” IEEE Trans. on Emerging Topics in Computational [31] Z. Xu and et. al, “Experience-driven networking: A deep reinforcement
Intelligence, accepted, Nov. 2018. learning based approach,” [online] arXiv:1801.05757 [cs.NI], Jan. 2018.
[6] H. Wang, O. L. Osen, G. Li, W. Li, H.-N. Dai, and W. Zeng, “Big data [32] E. A. Brewer, “Towards robust distributed systems,” in Proc. the nine-
and industrial internet of things for the maritime industry in northwestern teenth annual ACM symposium on Principles of distributed computing.
norway,” in Proc. IEEE Region 10 Conf. Macao, Nov. 2015, pp. 1–5. Portland, Oregon, USA, July 2000, pp. 1–7.
[7] J. He, J. Wei, K. Chen, Z. Tang, Y. Zhou, and Y. Zhang, “Multitier [33] K. Zhang and H. Jacobsen, “Towards dependable, scalable, and pervasive
fog computing with large-scale iot data analytics for smart cities,” IEEE distributed ledgers with blockchains,” in Proc. IEEE 38th Int. Conf. on
Internet of Things Journal, vol. 5, no. 2, pp. 677–686, April 2018. Distributed Comput. Syst. (ICDCS). Vienna, July 2018, pp. 1337–1346.
[8] D. Miller, “Blockchain and the internet of things in the industrial sector,” [34] M. Snider, K. Samani, and T. Jain, “Delegated proof of s-
IT Professional, vol. 20, no. 3, pp. 15–18, May/Jun. 2018. take: Features & tradeoffs,” Mar. 2018, https://multicoin.capital/wp-
[9] X. Liang, J. Zhao, S. Shetty, and D. Li, “Towards data assurance and content/uploads/2018/03/DPoS-Features-and-Tradeoffs.pdf; accessed on
resilience in iot using blockchain,” in Proc. IEEE Military Commun. 7 Sept. 2018.
Conf. (MILCOM). Baltimore, MD, Oct. 2017, pp. 261–266. [35] U. Klarman, S. Basu, A. Kuzmanovic, and E. G. Sirer, “bloxroute:
[10] N. Z. Aitzhan and D. Svetinovic, “Security and privacy in decentralized A scalable trustless blockchain distribution network whitepaper v1.0,”
energy trading through multi-signatures, blockchain and anonymous BLOXROUTE LABS, WHITEPAPER, Mar. 2018.
messaging streams,” IEEE Trans. on Dependable and Secure Comput., [36] K. Samani, “Models for scaling trustless computation,”
vol. 15, no. 5, pp. 840–852, Sept./Oct. 2018. https://multicoin.capital/2018/02/23/models-scaling-trustless-computati
[11] N. Teslya and I. Ryabchikov, “Blockchain-based platform architecture on/; accessed on 7 Sept. 2018.
for industrial iot,” in Proc. 21st Conf. of Open Innovations Association [37] P. K. Sharma, M. Chen, and J. H. Park, “A software defined fog node
(FRUCT). Helsinki, Nov. 2017, pp. 321–329. based distributed blockchain cloud architecture for iot,” IEEE Access,
[12] Z. Li, J. Kang, R. Yu, D. Ye, Q. Deng, and Y. Zhang, “Consortium vol. 6, pp. 115–124, Sept. 2017.
blockchain for secure energy trading in industrial internet of things,” [38] A. E. Gencer, S. Basu, I. Eyal, R. van Renesse, and E. G. Sirer,
IEEE Trans. Ind. Informat., vol. 14, no. 8, pp. 3690 – 3700, Aug. 2018. “Decentralization in bitcoin and ethereum networks,” [online] arX-
[13] Z. Zheng, S. Xie, H. Dai, X. Chen, and H. Wang, “An overview of iv:1801.03998 [cs.CR], Mar. 2018.
blockchain technology: Architecture, consensus, and future trends,” in [39] Z. H. Xiong, Y. Zhang, D. Niyato, P. Wang, and Z. Han, “Edge
Proc. IEEE Int. Congress on Big Data (BigData Congress). Honolulu, computing resource management and pricing for mobile blockchain,”
HI, Jun. 2017, pp. 557–564. [online] arXiv:1710.01567v1 [cs.CR], Oct. 2017.
[14] W. Chen, M. Ma, Y. Ye, Z. Zheng, and Y. Zhou, “Iot service based [40] D. Stoyan, W. Kendall, and J. Mecke, “Stochastic geometry and its
on jointcloud blockchain: The case study of smart traveling,” in Proc. applications,” New York, NY, USA: Wiley, 1996.
IEEE Symposium on Service-Oriented Syst. Eng. (SOSE). Bamberg, [41] A. Singh, T. Das, P. Maniatis, P. Druschel, and T. Roscoe, “Bft protocols
Mar. 2018, pp. 216–221. under fire,” in Proc. 5th USENIX Symposium on Networked Systems
[15] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2009. Design and Implementation, Jan. 2008, pp. 1–16.
http://www.bitcoin.org/bitcoin.pdf; accessed on 7 Sept. 2018. [42] M. Castro and B. Liskov, “Practical byzantine fault tolerance and
[16] F. R. Yu, J. M. Liu, Y. He, P. B. Si, and Y. H. Zhang, “Virtualization for proactive recovery,” ACM Trans. Comput. Syst., vol. 20, no. 4, pp. 398–
distributed ledger technology (vdlt),” IEEE Access, vol. 6, pp. 25 019– 461, Nov. 2002.
25 028, April 2018. [43] R. Kotla, L. Alvisi, M. Dahlin, A. Clement, and E. Wong, “Zyzzyva:
[17] “Bitcion charts and graphs - blockchain,” https://www.blockchain.com/ speculative byzantine fault tolerance,” SIGOPS Oper. Syst. Rev., vol. 41,
zh-cn/charts; accessed on 7 Sept. 2018. no. 6, pp. 45–48, Oct. 2007.
[18] “Ethereum project,” https://www.ethereum.org/; accessed on 7 Sept. [44] R. Guerraoui, N. Knezevic, V. Quema, and M. Vukolic, “The next
2018. 700 bft protocols,” in Proc. 5th European conf. on Computer syst.
[19] “Bitcoincash: Peer-to-peer electronic cash,” https://www.bitcoincash. (EuroSys’10). New York, NY, USA: ACM, April 2010, pp. 363–376.
org/; accessed on 7 Sept. 2018. [45] A. Clement, E. Wong, L. Alvisi, and M. Dahlin, “Making byzantine
[20] I. Eyal, A. E. Gencer, E. G. Sirer, and R. V. Renesse, “Bitcoin-ng: fault tolerant systems tolerate byzantine faults,” in Proc. 6th USENIX
A scalable blockchain protocol,” in Proc. 13th USENIX Symposium on Symposium on Networked Systems Design and Implementation, April
Networked Systems Design and Implementation (NSDI). Santa Clara, 2009, pp. 153–168.
CA, March 2016, pp. 45–59. [46] C. Gini, “Variability and mutability,” Journal of The Royal Statistical
[21] A. Kiayias, A. Russell, B. David, and R. Oliynykov, “Ouroboros: Society, vol. 76, pp. 619–622, May 1913.
A provably secure proof-of-stake blockchain protocol,” Aug. 2017. [47] L. Dai, Y. Jia, L. Liang, and Z. Chang, “Metric and control of system
https://whitepaperdatabase.com/cardano-ada-whitepaper/; accessed on 7 fairness in heterogeneous networks,” in Proc. 23rd Asia-Pacific Conf.
Sept. 2018. on Commun. (APCC). Perth, WA, Dec. 2017, pp. 1–5.
[22] I. Grigg, “Eos - an introduction,” July 2017. https://eos.io/documents/ [48] Z. Lin, F. Wen, Y. Ding, and Y. Xue, “Data-driven coherency identi-
EOS-An-Introduction.pdf; accessed on 7 Sept. 2018. fication for generators based on spectral clustering,” IEEE Trans. on
[23] ZILLIQA, “The zilliqa technical whitepaper v0.1,” Aug. 2017. http- Industrial Informatics, vol. 14, no. 3, pp. 1275–1285, Mar. 2018.
s://docs.zilliqa.com/whitepaper.pdf; accessed on 7 Sept. 2018. [49] D. Wu, G. Zeng, L. Meng, W. Zhou, and L. Li, “Gini coefficient-based
[24] J. Poon and V. Buterin, “Plasma: Scalable autonomous smart contracts,” task allocation for multi-robot systems with limited energy resources,”
Aug. 2017. http://plasma.io/; accessed on 7 Sept. 2018. IEEE/CAA Journal of Automatica Sinica, vol. 5, no. 1, pp. 155–168,
[25] “Cosmos: Internet of blockchains,” 2017. https://cosmos.network/; ac- Jan. 2018.
cessed on 7 Sept. 2018. [50] I. Goodfellow, Y. Bengio, and A. Courville, “Deep learning,” Book
[26] “Aion: The internet, decentralized,” 2018. https://aion.network/; accessed in preparation for MIT Press, 2016, http://www.deeplearningbook.org/;
on 7 Sept. 2018. accessed on 7 Sept. 2018.
[27] J. Poon and T. Dryja, “The bitcoin lightning network: Scalable off- [51] A. Paszke, “Pytorch tutorials,” 2018, https://pytorch.org/tutorials/; ac-
chain instant payments,” Jan. 2016. https://lightning.network/lightning- cessed on 7 Sept. 2018.
network-paper.pdf; accessed on 7 Sept. 2018. [52] A. Sen, “On economic inequality,” Oxford: Oxford University Press,
1977.

1551-3203 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TII.2019.2897805, IEEE
Transactions on Industrial Informatics

12

Mengting Liu received her B.S. degree from Minzu Yinglei Teng (M’12) received the B.S. degree from
University of China, Beijing, China, in 2013. She Shandong University, China, in 2005, and the Ph.D.
is currently pursuing the Ph.D. degree with Beijing degree in electrical engineering from the Beijing U-
University of Posts and Telecommunications (BUP- niversity of Posts and Telecommunications (BUPT)
T), Beijing, China. From Sept. 2017 to Sept. 2018, in 2011. She is currently an Associate Professor with
she was a visiting Ph.D. student with the Univer- the School of Electronic Engineering, BUPT. Her
sity of British Columbia, Vancouver, Canada. Her current research interests include UDNs and massive
current research interests include Blockchain, deep MIMO, IoTs and Blockchains.
reinforcement learning, and mobile edge computing.

Victor C. M. Leung (S’75-M’89-SM’97-F’03) is

a Professor of Electrical and Computer Engineering
and holder of the TELUS Mobility Research Chair
F. Richard Yu (S’00-M’04-SM’08-F’18) received at the University of British Columbia, Vancouver,
the PhD degree in electrical engineering from the U- Canada. He has co-authored more than 1200 tech-
niversity of British Columbia (UBC) in 2003. From nical papers in the areas of wireless networks and
2002 to 2006, he was with Ericsson (in Lund, Swe- mobile systems. Dr. Leung is a Fellow of the Royal
den) and a start-up in California, USA. He joined Society of Canada, the Canadian Academy of Engi-
Carleton University in 2007, where he is currently a neering and the Engineering Institute of Canada.
Professor. He received the IEEE Outstanding Service
Award in 2016, IEEE Outstanding Leadership Award
in 2013, Carleton Research Achievement Award in
2012, the Ontario Early Researcher Award (formerly
Premiers Research Excellence Award) in 2011, the
Excellent Contribution Award at IEEE/IFIP TrustCom 2010, the Leadership Mei Song received the B.E. and M.E. degrees from
Opportunity Fund Award from Canada Foundation of Innovation in 2009 and Tianjin University, China. She is currently a Pro-
the Best Paper Awards at IEEE ICNC 2018, VTC 2017 Spring, ICC 2014, fessor in Beijing University of Posts and Telecom-
Globecom 2012, IEEE/IFIP TrustCom 2009 and Int’l Conference on Net- munications. Her current research interests include
working 2005. His research interests include wireless cyber-physical systems, integrated design technology, VLSI&CAD system,
connected/autonomous vehicles, security, distributed ledger technology, and resource allocation and mobility management in
deep learning. heterogeneous and cognitive networks, cooperative
communication, and other advanced technology in
future communication networks.

1551-3203 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.