252 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 13, NO.

2, MARCH/APRIL 2020

Groupchain: Towards a Scalable Public

Blockchain in Fog Computing of
IoT Services Computing
Kai Lei , Maoyu Du , Jiyue Huang, and Tong Jin

Abstract—Powered by a number of smart devices distributed throughout the whole network, the Internet of Things (IoT) is supposed to
provide services computing for massive data from devices. Fog computing, an extension of cloud-based IoT-oriented solutions, has
emerged with requirements for distribution and decentralization. In this respect, the conjunction with Blockchain provides a natural
solution for decentralization, as well as potentially helps fog computing overcome some deficiencies such as security and privacy then
consequently expand the application scope of IoT. However, one of the key challenges of blockchain’s integration with fog computing is
scalability. To end this, this work proposes Groupchain, a novel scalable public blockchain of a two-chain structure suitable for fog
computing of IoT services computing. Groupchain employs the leader group to collectively commit blocks for higher transaction efficiency
and introduces bonus and deposit into the incentive mechanism to supervise behaviors of members in the leader group. Our security
analysis shows that Groupchain retains the security of Bitcoin-like blockchain and enhances defense against attacks such as
double-spend and selfish mining. We implement a prototype of Groupchain and conducted experiments. The experimental results
demonstrate that Groupchain achieves optimization on transaction throughput and confirmation latency which are argued in Bitcoin.

Index Terms—Public blockchain, two-chain, leader group, scalability, internet of things (IoT) service

1 INTRODUCTION
computing has recently witnessed an increasing overloads the Internet in both terms of efficiency and scal-
S ERVICES
number of applications across heterogeneous fields,
ranging from cloud computing, digital economy, Internet-
ability [9].
Fog computing is a distributed extension of IoT-oriented
of-Things (IoT), etc. A notable example is the IoT that cloud-based solutions for service computing, distributing
enables more effective control over the physical world cloud computation and storage gradually to the edge net-
through interconnected smart devices, including the sectors work [10]. Each fog node locates close to the IoT devices at
of manufacturing [1], healthcare [2] and energy [3]. Despite the edge network and provides different capacities of com-
its potential, there are some problems to be solved to make puting, storage and networking to support the execution of
IoT services wide its application. There are various loosely service applications. As a result, fog computing relies on fog
coupled and distributed smart devices in IoT systems that nodes to create cloud services that are distributed across
require connection, concerted operation and management edge domains. However, fog computing architecture still
[4], hence, identification and trust between each other are suffers the risk of trust-based and centralized management
essential. Traditional cloud-based IoT [5], [6] trusts some when cross-domain sharing and collaborative utilization of
centralized servers to address this problem and to process data have become an urgent demand, which brings concerns
the massive data from those devices limited by computa- on data security and privacy [11]. Data in an individual
tional resources [7], [8]. However, this kind of centralized domain can’t transfer directly between each other and must
services computing completely abandons the computational rely on trusted intermediaries to achieve data exchange. But
power of IoT devices themselves, moreover, the data trans- the administrators may disclose sensitive data, e.g., health-
mission through the Internet to the cloud is expensive that care, finance, etc., due to insider attacks. For a more scalable
and secure large-scale IoT network, it is supposed to

K. Lei, M. Du, and J. Huang are with the Shenzhen Key Lab for Information exchange and process data autonomously in a trustless envi-
Centric Networking & Blockchain Technology (ICNLAB), School of ronment and a better mechanism is required for data security
Electronics and Computer Engineering (SECE), Peking University, and privacy. It is time to consider decentralization for future
ShenZhen 518055, China, and also with the PCL Research Center of IoT services computing, and importantly, a decentralization-
Networks and Communications, Peng Cheng Laboratory, Shenzhen 518066,
China. E-mail: [email protected], {mydu, huangjiyue}@sz.pku.edu.cn. achieved system calls for distributed consensus to ensure

T. Jin was with the Shenzhen Key Lab for Cloud Computing Technology data consistency.
and Applications, School of Electronic and Computer Engineering, Peking Blockchain technology introduced by Bitcoin [12] pro-
University, ShenZhen 518055, China. E-mail: [email protected].
vides a solution for trustful peer-to-peer transactions under
Manuscript received 31 Mar. 2019; revised 2 Sept. 2019; accepted 10 Oct. the decentralized and trustless environment, tackling the
2019. Date of current version 15 Apr. 2020.
(Corresponding author: Kai Lei.) above problems of fog computing. The massive use of cryp-
Digital Object Identifier no. 10.1109/TSC.2019.2949801 tography, a key characteristic of blockchain networks, brings
1939-1374 ß 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See ht_tps://www.ieee.org/publications/rights/index.html for more information.

Authorized licensed use limited to: Kyunghee Univ. Downloaded on November 15,2020 at 03:57:26 UTC from IEEE Xplore. Restrictions apply.
LEI ET AL.: GROUPCHAIN: TOWARDS A SCALABLE PUBLIC BLOCKCHAIN IN FOG COMPUTING OF IOT SERVICES COMPUTING 253

authoritativeness behind all the interactions in the network achieves a throughput of over 800 TPS with a small leader
[13]. In addition to public-announced transactions across the group size. Moreover, even in a leader group size of 100,
whole blockchain network, the consensus algorithm drives where the whole blockchain network size is 350, Group-
untrusted parties to agree on a common state. The conver- chain still presents the performance of close to 600 TPS.
gence of fog computing and blockchain can potentially build Our key contributions are as follows:
better IoT services computing. Blockchain can serve as a pub-
lic ledger of data where all the operations are immutably
We propose Groupchain that employs the leader
recorded. By enabling each individual node to participate in group with a small size to reach consensus on blocks
the data maintain, blockchain achieves data exchange and to achieve high transaction efficiency and guarantee
facilitate value flow in an open trustless network [14]. As for dynamic membership under the public environment.
data consistency, the consensus algorithm of Bitcoin-derived To make up forks while preserving efficient transac-
blockchain guarantees eventual consistency [15]. tion processing, Groupchain is enhanced with a two-
However, fog computing comes at scalability challenges if chain structure.
straightforwardly conjunct with blockchain. The transaction
We introduce the bonus and deposit into incentive
efficiency in the blockchain, of which key metrics are mechanism for Groupchain to regulate behaviors of
throughput and confirmation latency, is much too limited leader groups, effectively prevent malicious nodes
for fog computing. This is the scalability problem in general from joint attacks.
blockchains. Although parameter tuning can be used to scale
We perform the security analysis to demonstrate the
blockchains, there exists a trade-off between block size and correctness of our solution and find that Groupchain
block interval which actually is the trade-off between system preserves Bitcoin security and mitigates attacks
performance and data consistency. When it comes to fog against Bitcoin blockchain such as selfish mining.
computing, the scalability problem also involves support for
We conduct the evaluation of Groupchain with a pro-
a large number of fog nodes, and both system performance totype implementation, demonstrating that Group-
and data consistency are important for fog computing. More- chain achieves optimization on Bitcoin’s transaction
over, due to computational resource constraints, Proof-of- throughput of times and supports lower transaction
Work (PoW) is already heavy for some fog nodes, not to men- confirmation latency of only 1 blockchain generation
tion once blockchain forks occur, additional computational time.
power is required to resolve the inconsistency. In current
cloud-and-blockchain-based IoT systems, the Consortium 1.2 Structure of the Paper
Blockchain where the consensus is executed by small sets of The remainder of this paper is structured as follows:
authorized entities is the main blockchain structure. Indeed, The related works on blockchain consensus optimization
using a Byzantine Fault Tolerant (BFT) -based [15] protocol, and blockchain-enabled IoT are summarized in Section 2.
such as Practical Byzantine Fault Tolerant (PBFT) [17], with a Section 3 provides the background of blockchain and Naka-
small number of pre-designated trusted entities, can avoid moto consensus, as well as Bitcoin-NG. We outline the sys-
the problem of the low computational power of some IoT tem architecture for our research scenario and introduce the
devices and achieve higher transaction efficiency [18]. But system model in Section 4. Section 5 describes the Group-
consortium blockchains abandon open membership under a chain design in detail. In Section 6, we conduct security anal-
trust model of stronger assumptions, and it only allowed ysis for the system. Sections 7 and 8 presents a prototype
fixed devices to mine, not considering that some other devi- implementation of Groupchain, and illustrates experimental
ces are computationally capable. Although the fog nodes results and corresponding discussions to validate our solu-
have more computing power than normal IoT devices, if the tion, respectively. Finally, Section 9 draws the conclusion
decentralization and security advantages of the public block- with future research discussion.
chain are to be preserved in fog computing, the challenges of
scalability and transaction efficiency must be addressed.
2 RELATED WORK
1.1 Contributions The consensus protocol is always one of the most important
In this paper, we present Groupchain, a scalable public optimization spots to scale the blockchain. By simply improv-
blockchain of two-chain structure that is suitable for fog ing the Nakamoto consensus, the GHOST [19] protocol opti-
computing of IoT services computing. Built on the principle mizes the longest chain algorithm of origin Bitcoin with the
of reducing consensus size to achieve high transaction effi- heaviest chain algorithm, which is able to run on flexible
ciency, Groupchain employs the leader group with a small block size and achieves much higher TPS than Bitcoin. The
size to collectively commit blocks. In public/permissionless problem it brings is that miners with weaker computing
setting, the members of the leader group are dynamic and power have the chance to use selfish mining strategy to
elected via Bitcoin’s PoW under the untrusted environment. obtain benefits that are not fair to their computing power.
The idea from Bitcoin-NG of decoupling leader election and Bitcoin-NG [20] introduces high generation frequency of
transaction serialization further inspires Groupchain to microblocks for transaction commitment that facilitates high
reduce transaction confirmation latency. We improve the transaction throughput. However, the solution for forks via
chain structure and finally derive the two-chain structure. the longest chain brings security risk in its chain structure
To regulate behaviors of leader groups, bonus and deposit compared with that of Bitcoin. Other attempts [15], [21], [22]
are introduced into the incentive mechanism. Experiments hoping to replace Nakamoto consensus with classical Byzan-
with a prototype implementation show that Groupchain tine fault-tolerant (BFT), maintain relatively high throughput

Authorized licensed use limited to: Kyunghee Univ. Downloaded on November 15,2020 at 03:57:26 UTC from IEEE Xplore. Restrictions apply.
254 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 13, NO. 2, MARCH/APRIL 2020

3.1 Blockchain and Nakamoto Consensus

Bitcoin [12] has garnered much attention as a peer-to-peer
cryptocurrency, bringing its underlying technology block-
chain into popularity. Blockchain is a consensus-driven and
tamper-proof decentralized ledger of transactions [32]. The
transactions are publicly verified and stored in a block and
shared among the nodes in a peer-to-peer network. Fig. 1
illustrates the data structure of a blockchain. Each block
Fig. 1. Simple data structure of a blockchain. includes the hash of the previous block in its own hash,
effectively forming a growing chain of irreversible blocks.
Nakamoto consensus defined and implemented by Bit-
and strong consistency but are limited on the number of coin takes miners to manage the state of a public/permission-
nodes in the blockchain network. Lamport et al. [16] propose less blockchain. All the miners compete for the leader by
the Byzantine Generals Problem and promote the research on trying to solve a difficult computational problem to create a
distributed fault-tolerant consensus algorithm. The Practical candidate block, of which process is called proof-of-work
Byzantine Fault Tolerance (PBFT) [17] protocol is one of the (PoW). The candidate block is broadcasted to all the other
pioneering solutions for Byzantine fault and supports a faulty participants and the miner is the elected leader. If multiple
rate at about 1=3. Other BFT-based tolerance consensus pro- miners generate blocks with the same valid preceding block,
tocols such as [23], [24], [25], try to scale the number of Byzan- there comes a fork as other miners may subsequently add
tine nodes in the entire system and reduce communication new valid blocks to any of these generated blocks. To
overhead [26]. resolve such inconsistencies (forks), in Nakamoto consen-
To address the scalability problem for the integration of sus, participants accept the longest chain that containing
blockchain in IoT, a variety of research works have been greatest PoW as the main chain to resolve forks, that is, all
proposed. To address the scalability problem for the inte- the miners add new blocks to the longest chain of which
gration of blockchain in IoT, a variety of research works they know.
have been proposed. [27] introduces Overlay Block Manag-
ers (OBMs) as block generators and proposes the Distrib- 3.2 Bitcoin-NG
uted Throughput Management (DTM) mechanism to keep Bitcoin-NG [20] is a scalable blockchain protocol based on
block interval within an IoT-acceptable range for higher the same trust model as Bitcoin. As pointed out in Bitcoin-
TPS. However, in its use case of smart home, the OBMs are NG, block generation in Bitcoin serves as a random way for
in fact external entities out of blockchain network and bur- leader election then transaction serialization, so Bitcoin-NG
dened by massive transaction processing. Furthermore, [28] introduces two types of blocks to decouple these two opera-
tries to scale blockchain in terms of ledger size and transac- tions of leader election and transaction serialization. Key-
tion rate by isolating IoT devices directly from blockchain blocks are generated via PoW to choose a leader, keeping the
network via an intermediate entity, which brings extra pro- same block interval as in Bitcoin. A leader is allowed to
cess such as device registration and transaction flow. In generate microblocks without PoW. Microblocks contain
LightChain [29], the authors conduct decentralized allevia- transactions and their generation rate is much higher than
tion from multiple perspectives including consensus, stor- keyblocks. High frequency of microblocks facilitates transac-
age and propagation, but the defensive capability remains tion commitment, enabling Bitcoin-NG to achieve high trans-
to be further proved. At the same time, more and more action throughput.
attention has been paid to the applications of blockchain- However, Bitcoin-NG still retains the consistency draw-
based IoT. For example, Li et al. [30] enhance the efficiency back of Bitcoin. A fork in Bitcoin exists until the next block
of computing-resource trading with a credit-based pay- generated, leaving the whole system inconsistent at least
ment, maximizing economic benefits while preserving pri- until the next block generation, during which time the cur-
vate information. [31] proposes a novel algorithm that rent leader has the chance to intentionally fork the block-
offloads computation-intensive blockchain mining tasks to chain. Due to this kind of inconsistency, Bitcoin requires
the edge servers, considering data processing and mining in k-confirmation to guarantee transaction security in case of
the blockchain networking at the same time. attacks such as double-spend and selfish-mining, which
Different from simply consensus improvement or specific brings longer transaction confirmation delay. As for inten-
blockchain-based use cases, our work towards a scalable tional microblock fork, Bitcoin-NG relies on poison transactions
public blockchain focusing on both architecture proposal to demotivate such a behavior, but this kind of disincentive
and consensus optimization, for inspiration of blockchain- is not always a binding agreement if the reward for keyblocks
enabled general IoT services computing. is high enough.

3 BACKGROUND 4 PRELIMINARIES
In this section, we first briefly describe the emerging block- In this section, we shed light on the fundamental architec-
chain technology and Nakamoto consensus that is intro- ture in fog computing of IoT services computing and princi-
duced by Bitcoin. Subsequently, we discuss Bitcoin-NG ples for building the consensus protocol, and introduce the
which is one of the inspiring building blocks for our pro- system model for nodes in the fog computing to enable
posed Groupchain. decentralized distributed network based on blockchain.

Authorized licensed use limited to: Kyunghee Univ. Downloaded on November 15,2020 at 03:57:26 UTC from IEEE Xplore. Restrictions apply.
LEI ET AL.: GROUPCHAIN: TOWARDS A SCALABLE PUBLIC BLOCKCHAIN IN FOG COMPUTING OF IOT SERVICES COMPUTING 255

Fig. 2. Blockchain-enabled architecture in fog computing of IoT services computing.

4.1 System Overview
Scalability: Scalability of the blockchain consensus

We consider a blockchain-enabled architecture in fog comput- itself includes two important metrics: 1) throughput
ing of IoT services computing as shown in Fig. 2, which is and 2) transaction confirmation latency. For fog com-
divided into three layers. The end device layer and fog layer puting of IoT services computing, scalability of con-
form the edge network where fog nodes directly process and sensus protocol should consider the future growth in
store the data that is from end devices but has no need to put the number of devices as well.
into the cloud, which reduces the pressure of the cloud layer
Security: Security is one of the fundamental condi-
and lowers the data transmission latency to the cloud. Fog tions of a distributed architecture. Blockchain pro-
nodes will offload their computing or storage workloads from vides some security on the data, but it is essential to
the local to the cloud when they are of insufficient resources. make a trade-off when security meets scalability. For
To enable a scalable and secure blockchain-based infra- example, although a fixed small-scale consensus pro-
structure in fog computing, we have to take the following cess can increase the transaction throughput, the
principles into consideration in terms of the consensus transaction reliability is not that high than conduct-
protocol: ing consensus in the whole network.

Open Membership: Considering the demand for cross- 4.2 System Model
domain sharing and collaborative utilization of data We propose to enable a decentralized distributed network
in future IoT network, it is necessary to establish based on blockchain for nodes in and above the fog layer,
public/permissionless blockchain to support the that is, the nodes in the fog layer and cloud layer. Specifi-
nodes joining or leaving at any time. cally, the whole network is comprised of a set of N nodes

Efficiency: Fog computing itself is to meet the proc- under the public/permissionless setting, where there is no
essing requirements of massive IoT data in a more trusted public key infrastructure and any node can join or
efficient way. Therefore, the consensus protocol for leave at any time. Each node i 2 N has a public/private
blockchain-based fog computing is supposed to be key-pair ðpki ; ski Þ. Each individual node i has a limited
efficient. amount of computational
P power pi  0 of the entire net-

Fault Tolerance: With the growing of IoT network, it is work, where i2N pi ¼ 1. Assume that all nodes are well
hard to accurately and efficiently identify malicious connected in a peer-to-peer network.
nodes under the public/permissionless setting, and Blockchain nodes in both the fog layer and cloud layer
the fault tolerance of consensus protocol can alleviate are either honest or Byzantine. Byzantine nodes are the ones
security issues in such a large-scale network. who do not follow the consensus protocol, either

Authorized licensed use limited to: Kyunghee Univ. Downloaded on November 15,2020 at 03:57:26 UTC from IEEE Xplore. Restrictions apply.
256 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 13, NO. 2, MARCH/APRIL 2020

from the generation time of several blocks (6 in Bitcoin) to

only one.

Algorithm 1. Consensus Protocol on Blocks

Input: A candidate block b comprised of serialized transactions,
a key-pair of the leader pkleader , skleader
Output: A verified block
1: function VERBLOCK (b, pkleader , skleader )
2: sign b with skleader
Fig. 3. Consensus process among leader group members. 3: broadcast the signed bs
4: for each Member M do
accidentally or maliciously, that is, they might fail to join the 5: check validity of each transaction T in bs
consensus or collude to attack the whole network. The num- 6: if any T is invalid then
ber of Byzantine nodes is f and N  3f þ 1. 7: rs invalid
8: Abort
9: else
5 GROUPCHAIN DESIGN 10: rs valid
In this section, we describe Groupchain design in detail, 11: sign rs with skM
including both protocol and incentive mechanism. 12: for each Member M then
13: check rs from other members
14: if any rs is invalid then
5.1 Leader Group
15: bs invalid
Build on the principle of reducing consensus size to achieve 16: Abort
high transaction efficiency, we introduce the leader group to 17: else
participant consensus on blocks. A leader group is a small 18: bs valid
committee of n rolling consensus nodes that collectively 19: bsM sign bs with skM
commit transactions via new blocks on the blockchain, and 20: collect signature from each individual member M
at most f ¼ bn13 c of them are Byzantine nodes. 21: if sumðbsM Þ  2/3 then
In a leader group, only one primary node of these commit- 22: bs valid
tee members serves as the leader, who proposes candidate 23: bsc sign bs with collective signature
blocks consisting of a batch of serialized transactions. Each 24: broadcast bsc
consensus round on a candidate block driven by the leader is 25: return
based on voting among all members of the leader group.
As shown in Fig. 3, assume that Member0 is the leader, For the purpose of open participation and security under
Member3 is faulty. The consensus process contains the fol- the setting of a public/permissionless blockchain, we pre-
lowing steps: serve Bitcoins proof-of-work (PoW) mining to win the mem-
bership of a leader group dynamically and randomly, which
1) The leader generates a block b packed with serialized
currently appears to be the most secure consensus protocol
transactions and broadcasts it to the other members.
for the public blockchain, albeit with a little waste of compu-
2) Upon receiving a candidate block from the leader,
tational resource. In order to gain membership, a miner must
each other member M verifies the proposed transac-
show a PoW. Keeping the leader group at a given fixed size
tions in this block, then broadcasts the verification
n  3f þ 1, when a miner gives a new PoW, the members of
result rs with its own signature to each other members.
the leader group will change. The new PoW finder joins the
3) All the members collect signed verification result rs
leader group while the oldest PoW finder loses the member-
from each other and compare it with that of its own.
ship of the current leader group. More details on the leader
If the block is considered as a valid one, member M
and membership of a leader group will be described in
signs the candidate block b and sends the signed
Section 5.3.
block bs to the leader.
4) If the leader obtains signed block bs from a two-
thirds supermajority, which means that the members 5.2 Group Blocks and Vice Blocks
agree on the proposed block data, it will send the col- The employment of the leader group mitigates transaction
lectively signed block to all members for storage. confirmation delay to a block interval instead of several
Algorithm 1 illustrates how to verify a candidate block ones, but the interval, e.g., 10 minutes in Bitcoin on average,
via VerBlockðÞ. Instead of reaching consensus for block still seems too long for IoT services computing to commit
data across the whole network in Bitcoin, Groupchain car- transactions.
ries out the consensus process in leader group members, To further bridge the gap and improve transaction
which greatly reduces the consensus latency. Moreover, throughput, build on the idea of Bitcoin-NG, Groupchain
since a valid block is not unilaterally submitted by a sin- introduces two types of blocks to decouple the functions of
gle leader, but is collectively confirmed by all the mem- transaction verification from block mining: 1) group blocks for
bers of a leader group, a transaction is considered as the membership of leader group and 2) vice blocks that con-
security once the block containing it is committed on the tain transactions. Miners generate groupblocks via PoW to
blockchain. This reduces transaction confirmation delay compete for the membership of a leader group. After the

Authorized licensed use limited to: Kyunghee Univ. Downloaded on November 15,2020 at 03:57:26 UTC from IEEE Xplore. Restrictions apply.
LEI ET AL.: GROUPCHAIN: TOWARDS A SCALABLE PUBLIC BLOCKCHAIN IN FOG COMPUTING OF IOT SERVICES COMPUTING 257

lth member is the new leader Lðg; v0 ¼ v þ 1Þ, where

l ¼ ðg þ v0 Þ%n.

Algorithm 2. Leader Election & Membership

1: function CHKMEMBERSHIP
2: while true do
3: if any miner finds a PoW then
4: ðg; vÞ ðg0 ¼ g þ 1; 0Þ
5: the leader is the miner of the PoW
Fig. 4. Two-chain structure of Groupchain.
6: Lðg; vÞ Lðg0 ¼ g þ 1; 0Þ
7: else
leader group confirmed, each member is allowed to generate 8: if failure then
new viceblocks every few seconds without PoW, containing 9: ðg; vÞ ðg; v0 ¼ v þ 1Þ
transactions to be committed. The viceblock frequency is 10: the leader is l ¼ ðg þ v0 Þ%n
much higher than groupblock. The viceblocks generated by 11: Lðg; vÞ Lðg; v0 ¼ v þ 1Þ
any member of the leader group must be collectively signed
by the remaining group members before recognizing it as To summarize, in Groupchain, there are two ways of
valid and appending on the blockchain. leader election for different situations: 1) PoW for leader
Since Groupchain forces consensus on each viceblock competition outside the current leader group; 2) round-robin
under the supervision of all the members in a leader under stable leader group members. Groupchain forces a
group, unlike Bitcoin-NG, it prevents a Byzantine leader mandatory view-change to the new leader whether it is
from exclusively tampering ledger history during its lead- elected by generating groupblocks or taking turns.
ership period. In addition, the members are easy to per-
ceive a Byzantine leader due to supervision, and election 5.4 Forks
for a new leader will be required if the current leader is As mentioned in Section 5.2, there are two chains in Group-
Byzantine. chain. We now discuss the solution for forks in these two
Moreover, we enhance Groupchain with a structure of chains, respectively.
two-chain to avoid forks on vice blocks, as shown in Fig. 4. Bitcoin-NG suffers short forks on almost every leader
The groupblock chain is a chain of historical leader groups, switch as microblocks are issued at a high frequency with-
consisted of mined groupblocks for leader group member- out PoW. Bitcoin-NG preserves these forks as in Bitcoin,
ship. A leader group collectively generates vice blocks and until a new key block arrives at a node to switch to the new
then linked to the viceblock chain. leader. Moreover, Bitcoin-NG disincentives the next leader
from accidentally or maliciously forking the microblocks
via a dedicated ledger entry called poison transaction. How-
5.3 Leader Election and Membership ever, in Groupchain, remember that the leader is uniquely
To present the leader and membership of a leader group, we determined in a leader group. Since the viceblocks are com-
refer to the concept in PBFT and consider that the leader mitted after voting among the honest supermajority of
group moves through a succession of changes on the leader leader group members, forks in the viceblock chain have no
called views. View changes are carried out when leader change chance to happen as long as the leader group is unique
happens in a leader group. across the whole network.
We consecutively number both leader groups and views. Therefore, forks in the groupblock chain are the most
Let each member M maintains a leader group-view tuple important problem that needs to consider as it affects the
ðg; vÞ, and a leader Lðg; vÞ is associated with the tuple, where g membership and uniqueness of the leader group, which
and v is the number of current group and view, respectively. guarantees the security of viceblocks. Unlike Bitcoin, if min-
Note that g is actually the height of a leader group in the ers randomly decide to follow one of the valid blocks when
groupblock chain. Each member M runs ChkMembershipðÞ forks happen in Groupchain, it will lead to liveness inter-
as in Algorithm 2 to respond to membership changes: ruptions on the leader group. To address this, the core idea
of solving forks is that when there are multiple group blocks

When receiving a new groupblock generated by generated to compete for the membership of the leader
PoW, the members of the leader group will change. group, only one of them can be accepted as valid instantly.
Member M sets the tuple from ðg; vÞ to ðg0 ¼ g þ 1; 0Þ We use a simple and efficient solution for forks, considering
and now supports the miner of the new groupblock both determinacy and randomness.
as leader Lðg0 ¼ g þ 1; 0Þ. The oldest member will be When required a block decision among k conflicted
out of the new leader group. group blocks bi where i 2 f0; 1; . . . ; kg, each Groupchain

When no miner finds a PoW, the members of leader node concatenates all k block header hash strings Hðbi Þ
group remain stable. But upon detecting failure from low to high and get
including timeout or malicious behavior from the
current leader Lðg; vÞ, member M changes its tuple
from ðg; vÞ to ðg; v0 ¼ v þ 1Þ and use a deterministic Hðbk Þ ¼ HashðHðb0 Þ þ Hðb1 Þ þ    þ Hðbk ÞÞ; (1)
algorithm to compute the lth member of the current
group, by the order they join the committee. The via another hash operation.

Authorized licensed use limited to: Kyunghee Univ. Downloaded on November 15,2020 at 03:57:26 UTC from IEEE Xplore. Restrictions apply.
258 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 13, NO. 2, MARCH/APRIL 2020

6.1 Fault Tolerance

Theorem 1. The leader group in Groupchain guarantees fault
tolerance, if the number of Byzantine members in a leader group
3 c, i.e., n  3f þ 1.
is no more than f ¼ bn1
Proof. If Byzantine nodes want to attack the system, they
try to change the system status. Assume that the consen-
sus nodes in a leader group consist of three different sets
G ¼ H1 [ H2 [ B; (3)

Fig. 5. Deposit for leader group members. where H1 and H2 are all honest nodes and set B are of
Byzantine nodes in cooperation.
The sequence number of final winner group block is If nodes in B want to do evil, they can propose the con-
sensus process with participants in either H1 or H2 and
i ¼ Hðbk Þ:substringð0; kÞ mod ðk  1Þ; (2)
immediately broadcast blocks, then propose a second con-
where substringðÞ is the string truncation operator from sensus with the same nodes. In this way, malicious nodes
length 0 to k. are able to gain agreement from 2/3 of nodes in the sys-
tem, ignoring members of the other one part. To win the
5.5 Incentive game, it requires
In Groupchain, the leader group has great power to commit jH1 j þ jBj  n  f (4)
transactions and blocks. Since the size of the leader group is
relatively small, to regulate leader groups more strictly, we jH2 j þ jBj  n  f: (5)
introduce deposit and bonus into the incentive mechanism
Take jBj ¼ f at the worst case, then we get (6) and (7)
in Groupchain.
The deposit is to effectively prevent malicious nodes from jH1 j  n  2f (6)
conducting joint attacks and constrain behaviors of the leader
group members from beginning to end. Since viceblocks do jH2 j  n  2f (7)
not require mining, a leader can conduct Denied-of-Service according to (4) and (5). So
(DoS) [33] attacks by continuously generate invalid vice-
blocks. In addition, a leader group with small size is entitled jH1 j þ jH2 j  2n  4f: (8)
to serialize transactions, which reduces consensus overhead
while making computational attacks easier. To address this Note that jH1 j þ jH2 j þ jBj ¼ n, i.e.,
problem, we need the new leader to deposit to historical
members after completing PoW for membership. The deposit jH1 j þ jH2 j ¼ n  f: (9)
will be refunded only if the member behaves honestly during
Hence, (8) and (9) can be simplified as
a sufficiently long ”inspection period”, which means the
member is much less motivated to sign invalid transactions or n  3f: (10)
generate invalid group blocks, otherwise it is paid to the his-
torical members. Our prerequisite is n  3f þ 1, which contradicts with
An example of the process for deposit delivery is as fol- (10). Therefore, the leader group in Groupchain is able to
lows. Let the new groupblock is b, and its header hash is HðbÞ. provide fault tolerance if the number of Byzantine mem-
The miner intercepts g (or g mod 255 if g  256) bits of HðbÞ 3 c.
bers in a leader group is no more than f ¼ bn1 u
t
from low to high and hashes the result into Hðbg Þ, where g is
the number of current leader group. The deposit is paid to the 6.2 Leader Group Size
members of leader group Hðbg Þ mod g. Take Fig. 5 as an exam- To get the required size n of a leader group, we model the
ple. The new generated groupblock is b50d and the hash value security of leader group membership as a random sampling
of its last 50 bits is Hðbg50d Þ. Since Hðbg50d Þ mod 50 ¼ 6, the problem with two possible outcomes, i.e., honest and Byz-
miner must deposit to the members of leader group 6. antine, like in [34]. Let p be the probability of a miner is Byz-
To motivate more miners to participate in the Group- antine and consider that mining is a fair game, which
chain network and fully use the lost viceblocks in forks, we means the probability that a node is Byzantine is roughly
introduce a bonus. The remuneration in Bitcoin and Bitcoin- equal to the mining power of the miner. As mentioned in
NG is comprised of two parts: mining reward and transac- Section 6.1, the leader group guarantees fault tolerance as
tion fee. Groupchain remains these two remunerations, and long as it picks less than c ¼ bn13 c Byzantine nodes as mem-
additionally, gives a bonus to the groupblock miners who bers. Thus, using the cumulative binomial distribution, the
lost in the competition of leadership. security probability of a leader group is
X c  
n k
6 SECURITY ANALYSIS AND DISCUSSION P ½X  c ¼ p ð1  pÞnk : (11)
k¼0
k
In this section, we provide security analysis and discussion
on our Groupchain, presenting the security defense against Fig. 6 shows the results for the evaluation of (11), where
attacks and some details about the leader groups. the probability p of a Byzantine node varies from 0.1 to 0.3.

Authorized licensed use limited to: Kyunghee Univ. Downloaded on November 15,2020 at 03:57:26 UTC from IEEE Xplore. Restrictions apply.
LEI ET AL.: GROUPCHAIN: TOWARDS A SCALABLE PUBLIC BLOCKCHAIN IN FOG COMPUTING OF IOT SERVICES COMPUTING 259

Fig. 7. Simple structure of the groupblock chain.

In Groupchain, any node simply checks the collective

signature of a viceblock, in which a supermajority of the
leader group members permits its validity. In this respect,
0-confirmation services can be provided to clients in a secure
way because it’s not required for additional blocks to confirm
validity and immutability of the transactions. Moreover,
Fig. 6. Security under different adversarial miner probability. since the viceblock chain is under the supervision of leader
groups instead of a single leader, a double-spend attacker
Keep the leader group size under 100, we can observe will have no chance to generate an alternate chain. On one
that it cannot reach an ideal security probability ( 0:99) hand, any invalid viceblock proposed even by a malicious
when p ¼ 0:25 or p ¼ 0:3. In Bitcoin, the recommended leader, will not be accepted by other members. On the other
6-confirmation is calculated when p ¼ 0:1 and security level hand, new leader election via view change will happen in
 0:99. If following the same adversary probability and secu- Groupchain when detecting faults on the current leader.
rity level as Bitcoin, a leader group ensures security as soon as
its size reaches to 13. Obviously, Bitcoin needs a time of gener- 6.5 Selfish Mining
ating 6 blocks (about 60 minutes) to guarantee transaction Selfish mining [36] is a strategy for a miner to keep its discov-
security, but Groupchain employs collective commitment to ered blocks private, thereby intentionally forking the chain,
lower the time at only one block generation time. to obtain more revenue than its ratio of the total mining
power. Assume a selfish miner already finds the next PoW
6.3 Sybil Attacks but temporarily withhold it. At the same time, honest miners
Sybil attacks [35] allow a malicious participant to subverts a are still mining on the current block. When it comes to
peer-to-peer network by creating a large number of pseu- Groupchain, no matter the selfish miner is of the current
donymous identities in order to appear and function as leader group or not, it will have more chance to take the seat
multiple distinct nodes. In a public/permissionless setting, in the next committee than its fair share of mining power.
this kind of attack can trivially break the voting-based pro- However, this kind of attack strategy does not benefit a
tocol of which assumes that at most f out of 3f þ 1 members lot in Groupchain. Unlike Bitcoin which solves fork via the
are Byzantine. longest chain, Groupchain immediately solves the group-
By using PoW for membership of a leader group, Group- block fork as described in Section 5.4, and the selfish miner
chain has a natural ability to resist Sybil attacks. Recall that cannot guarantee its block to be the final accepted one. A
only the members of a leader group are entitled to serialize selfish miner has a higher probability to fail in the competi-
transactions via blocks once it becomes the leader. In order to tion than that in Bitcoin, and gains nothing from withhold-
join the leader group, a new member must solve a difficult ing its group block, only wasting computational resources.
computational problem known as PoW. Even in the robin-
round leader election fashion when no new PoW is found,
7 IMPLEMENTATION
the new leader is still elected among previous PoW contribu-
tors. PoW raises the cost of creating a new identity which We implemented the key Groupchain elements that are sig-
requires processing power to contribute. Different from one- nificant for performance analysis in the absence of an adver-
CPU-one-vote where the majority could be subverted by sary, by extending the Bitcoin Simulator [37].
anyone able to allocate many IPs, in PoW, the majorities are The Bitcoin Simulator is built on a discrete-event network
essentially based on one-CPU-one-vote. Although PoW- simulator of NS-3, and distinguishes between two node
based election wastes some computational resources, it miti- types: 1) regular nodes and 2) miners. For regular nodes, the
gates Sybil attacks, of which security property is inherited by geographical location is simulated, as well as bandwidth and
Groupchain. network latency according to its location. To model miners,
the mining pool distribution from blockchain.info1 is consid-
6.4 Double-Spend Attacks ered, and accordingly distributed the mining pools public
To achieve double-spend, an attacker tries to generate an node to the respective region. It can generate Bitcoin network
alternate chain faster than the honest chain. The probability topology based on the data of realistic download speed,
of such an attack to be successful is modeled as a Gambler’s latency and bandwidth distribution. Furthermore, in the orig-
Ruin problem in the original Bitcoin paper. The recipient of a inal paper of Bitcoin Simulator, the authors devise optimal
new transaction needs to wait for k  1 additional blocks adversarial strategies for double-spending and selfish min-
before being sufficiently certain the transaction is immutable, ing, and propose double-spend value vd and relative reward
which leads to long transaction confirmation time. In Bitcoin, rrel for selfish mining to capture the security PoW-based
the transaction confirmation time is for 6 block intervals,
about 60 minutes on average. 1. https://blockchain.info

Authorized licensed use limited to: Kyunghee Univ. Downloaded on November 15,2020 at 03:57:26 UTC from IEEE Xplore. Restrictions apply.
260 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 13, NO. 2, MARCH/APRIL 2020

Fig. 8. Simple structure of the viceblock chain.

blockchain. Based on Groupchain protocol, we adjust the

parameter of these metrics to measure its security.
The implementation of the group block is similar to the
Bitcoin-NG but contains an additional transaction for
deposit. In order to maintain an average rate of the entire net-
work, Groupchain adjusts the block generation rate via the Fig. 10. Consensus latency with leader group size change.
target value in the group block header. Differently, a group
block has an identification of which leader group it belongs architecture on data propagation and simulate realistic
to. By including the hash values of all members of the previ- bandwidth, we adopt an upper bandwidth limit of 100
ous leader group, the group blocks in different leader groups Mbps.
form a groupblock chain. Fig. 7 shows a simple structure of
the groupblock chain.
8.1 Propagation Latency
As for vice blocks, we implement its basic data structure
In this and the following experiments, we simulate the pub-
and a simple structure of the viceblock chain is presented in
lic blockchain network with 30 percent of nodes are miners.
Fig. 8. The header of a vice block contains a reference to the
We refer to a percentage of 7 in some Bitcoin statistics [38]
previous viceblock, a cryptographic Merkle root value of the
and considers the fact that only a subset of IoT devices has
transaction entry, and a hash of the current leader. However,
we do not implement the message communication for vice- enough computational power to mine. We large the percent-
blocks among leader groups with a specific collective signa- age from 7 to 30 as the computational power of fog nodes
ture algorithm and signature check. In the experiments, we and cloud servers is much larger.
simulate collective signature and signature check by impos- In a blockchain network, blocks must be effectively propa-
ing a latency of 200 ms for every member of a leader group. gated and verified to achieve normal operation. Groupchain
makes a great change on the consensus and propagation of
blocks, which may influence the block propagation. In the
case of our public blockchain, the effect on block propagation
8 PERFORMANCE EVALUATION is much larger since processing power and location of devi-
We run all our experiments using the implementation men- ces vary widely. To verify Groupchain the validity of propa-
tioned in Section 7, and for Bitcoin we run the standard Bit- gation and observe how it affects the propagation efficiency,
coin Simulator. The machine used for evaluation has Intel we use a network of 45 nodes, which 30 percent is 13.5, reach-
Core i7-6700 CPU @ 3.4 GHz and 8 G RAM. Each result is ing the minimum security size of a leader group, to compare
averaged over 10 experiments. Bitcoin’s propagation properties in our system.
The location of a miner and the number of connections We perform experiments with different block sizes while
per miner and regular device are the default setting as Bit- keeping transaction throughput constant by changing the
coin Simulator, and we equally distribute the location of block interval. The result in Fig. 9 shows that the relationship
regular nodes all over the world. Consider the influence of between block size and propagation latency is still liner, simi-
bandwidth capacities of nodes in the fog computing lar to the observation in the Bitcoin network by [39], indicating
that our experimental setup and topology are of rationality.

8.2 Consensus Latency

Since transaction commitment is via viceblock in Group-
chain, for the consensus latency, we only consider the vice-
block commitment in a leader group. We simulate a public
blockchain network where all the nodes are allowed to mine
and note that the size of a leader group does not mean the
total number of miners in the network.
In Bitcoin, the Nakamoto consensus provides a probabilis-
tic consensus that means a block is considered as valid if more
than 50 percent of nodes receive it. Then consensus latency
is the time for at least 50 percent of nodes receive a block.
To see the scalability of Groupchain’s consensus process
in terms of the leader group size, we keep the viceblock size
at 1 MB that is the current Bitcoin’s maximum block size.
Fig. 9. Propagation latency with block size change. We also simulate PBFT with 0.25 MB block size, of which

Authorized licensed use limited to: Kyunghee Univ. Downloaded on November 15,2020 at 03:57:26 UTC from IEEE Xplore. Restrictions apply.
LEI ET AL.: GROUPCHAIN: TOWARDS A SCALABLE PUBLIC BLOCKCHAIN IN FOG COMPUTING OF IOT SERVICES COMPUTING 261

800. Even in the same network size of 350-node, the increase

is over 5 times and TPS is close to 600. But with Fig. 9, there is
a trade-off between throughput and propagation latency in
terms of the block size. We can observe that the throughput
decrease with leader group size increase does not follow a
linear relationship, and comprehensively analyze with Fig. 9
we can see Groupchain protocol does not sacrifice propaga-
tion efficiency.

9 CONCLUSION AND FUTURE WORK

In this paper, we propose Groupchain, a novel scalable public
blockchain with a two-chain structure in fog computing of
IoT services computing. The employment of the leader group
reduces consensus size, including transaction throughput
Fig. 11. Throughput with block size change. and confirmation time. And the members of a leader group
are dynamic and elected via reliable PoW under public set-
consensus process is based on voting as well. We don’t use ting. Decouple functions of transaction serialization from
the same block size of 1 MB in PBFT as it cannot guarantee leader election further increases transaction throughput, and
basic running with the number of nodes growing to near we propose a chain structure of two-chain to make drawbacks
100. The experiment result on how consensus latency varies of such improvement. To regulate behaviors of leader groups,
from the leader group size, is shown in Fig. 10. Groupchain introduces bonus and deposit into incentive
For all the three kinds of consensus, the latency increases mechanism. Groupchain preserves Bitcoin’s security proper-
as the size of a leader group increases. We can see that the ties and enhances defense against attacks such as double-
consensus latency of Groupchain is relatively higher than spend and selfish mining. We implement a prototype of
Bitcoin because a node needs to send additional messages to Groupchain and experimental results illustrate that Group-
collectively sign the block. However, the collective signing chain is scalable and transaction-efficient.
allows the blocks that are committed on the blockchain to be The future work will focus on the Groupchain develop-
considered as valid immediately without k-confirmation, ment in real fog computing architecture and the improve-
which reduces the transaction latency into one block genera- ment of incentive mechanism. The network environment of a
tion time. When leader group size is less than 100, the latency public blockchain is complicated, and our deployment capa-
is acceptable and we do not see an obvious point at which bility is limited. Therefore, the experiments in this paper are
leader group size becomes latency bottleneck. Groupchain simulated in NS-3 instead of in real public blockchain net-
has better scalability than PBFT since even 1 MB block work. In order to evaluate Groupchain more accurately, it is
achieves much lower latency than the 0.25 MB block of necessary to conduct experiments in a real public blockchain
PBFT. Moreover, with the size increase, the latency increase network. On the other hand, the comparative evaluation on
in Groupchain compared to PBFT is more practical. Bitcoin is also in Bitcoin Simulator but not the standard Bit-
coin client. As for the incentive mechanism of Groupchain, it
8.3 Transaction Throughput is vital to make a more precise measure and more compre-
We also assume an average transaction size of 250 bytes. hensive consideration, such as the specific upper and lower
Although there is no transaction propagation, the transac- bound of deposit.
tions are implicitly captured within the block size.
The size of the leader group is set to 13 and 100, where 13 is ACKNOWLEDGMENTS
the minimum leader group size for 0.99 security level. The This work was financially supported by Shenzhen Key Lab-
experiment focuses on transaction throughput in a large-scale oratory Project (ZDSYS201802051831427) and the project
network, we ignore the competition for leader group mem- “PCL Future Regional Network Facilities for Large-scale
bership, thus set all the miners as leader group members. For Experiments and Applications”.
a leader group size of 13, we set 13 miners in a network of 45
nodes. To keep roughly the same ratio of the miner, the net-
work of which leader group is 100, has 350 nodes. For Bitcoin, REFERENCES
we set block frequency to 1 per 10 min and Groupchain’s [1] Z. Bi, L. D. Xu, and C. Wang, “Internet of Things for enterprise sys-
tems of modern manufacturing,” IEEE Trans. Ind. Informat., vol. 10,
groupblock frequency as the same. In theory, the frequency of no. 2, pp. 1537–1546, May 2014.
viceblock can be handled flexibly according to system [2] S. M. R. Islam, D. Kwak, M. H. Kabir, M. Hossain, and K. Kwak,
requirements. We keep the security measurement double- “The Internet of Things for health care: A comprehensive survey,”
spend value vd and relative reward of selfish mining rrel the IEEE Access, vol. 3, pp. 678–708, 2015.
[3] Z. Li, J. Kang, R. Yu, D. Ye, Q. Deng, and Y. Zhang, “Consortium
same in Bitcoin and Groupchain, to avoid infinitely reducing blockchain for secure energy trading in industrial Internet of
the viceblock interval. The resulting throughput is computed Things,” IEEE Trans. Ind. Informat., vol. 14, no. 8, pp. 3690–3700,
in transactions per second (TPS), as shown in Fig. 11. Aug. 2018.
With the same block size and smaller leader group size of [4] B. Carminati, P. Colombo, E. Ferrari, and G. Sagirlar, “Enhancing
user control on personal data usage in internet of things
13, Groupchain achieves throughput improvement than Bit- ecosystems,” in Proc. IEEE Int. Conf. Services Comput., Jun. 2016,
coin of 10 times on average, of which the highest TPS is over pp. 291–298.

Authorized licensed use limited to: Kyunghee Univ. Downloaded on November 15,2020 at 03:57:26 UTC from IEEE Xplore. Restrictions apply.
262 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 13, NO. 2, MARCH/APRIL 2020

[5] S. Singh, Y.-S. Jeong, and J. H. Park, “A survey on cloud comput- [31] W. Chen, Z. Zhang, Z. Hong, C. Chen, J. Wu, S. Maharjan,
ing security: Issues, threats, and solutions,” J. Netw. Comput. Appl., Z. Zheng, and Y. Zhang, “Cooperative and distributed computation
vol. 75, pp. 200–222, 2016. offloading for blockchain-empowered industrial Internet of Things,”
[6] X. Sun, N. Ansari, and R. Wang, “Optimizing resource utilization IEEE Internet Things J., vol. 6, no. 5, pp. 8433–8446, Oct. 2019.
of a data center,” IEEE Commun. Surveys Tuts., vol. 18, no. 4, [32] Z. Li, J. Kang, R. Yu, D. Ye, Q. Deng, and Y. Zhang, “Consortium
pp. 2822–2846, Fourth Quarter 2016. blockchain for secure energy trading in industrial Internet of Things,”
[7] H.-L. Truong and S. Dustdar, “Principles for engineering IoT cloud IEEE Trans. Ind. Informat., vol. 14, no. 8, pp. 3690–3700, Aug. 2018.
systems,” IEEE Cloud Comput., vol. 2, no. 2, pp. 68–76, Mar./Apr. 2015. [33] X. Luo and R. K. Chang, “On a new class of pulsing denial-of-service
[8] L. Wang and R. Ranjan, “Processing distributed internet of things attacks and the defense,” in Proc. Netw. Distrib. Syst. Security Symp.,
data in clouds,” IEEE Cloud Comput., vol. 2, no. 1, pp. 76–80, 2005.
Jan./Feb. 2015. [34] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, and
[9] P. K. Sharma, M. Chen, and J. H. Park, “A software defined fog B. Ford, “OmniLedger: A secure, scale-out, decentralized ledger via
node based distributed blockchain cloud architecture for IoT,” sharding,” in Proc. IEEE Symp. Security Privacy, 2018, pp. 583–598.
IEEE Access, vol. 6, pp. 115–124, 2018. [35] J. R. Douceur, “The sybil attack,” in Proc. Int. Workshop Peer-to-Peer
[10] M. Chiang and T. Zhang, “Fog and IoT: An overview of research Syst., Oct. 2002, pp. 251–260.
opportunities,” IEEE Internet Things J., vol. 3, no. 6, pp. 854–864, [36] I. Eyal and E. G. Sirer, “Majority is not enough: Bitcoin mining is
Dec. 2016. vulnerable,” Commun. ACM, vol. 61, no. 7, pp. 95–102, Jun. 2018.
[11] G. Sagirlar, B. Carminati, E. Ferrari, J. D. Sheehan, and E. Ragnoli, [Online]. Available: http://doi.acm.org/10.1145/3212998
“Hybrid-IoT: Hybrid blockchain architecture for Internet of Things - [37] A. Gervais, G. O. Karame, K. W€ ust, V. Glykantzis, H. Ritzdorf, and
PoW sub-blockchains,” CoRR, vol. abs/1804.03903, 2018. [Online]. S. Capkun, “On the security and performance of proof of work
Available: http://arxiv.org/abs/1804.03903 blockchains,” in Proc. ACM SIGSAC Conf. Comput. Commun. Security,
[12] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2016, pp. 3–16.
2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf [38] A. Miller, J. Litton, A. Pachulski, N. Gupta, N. Spring, B. Bhattacharjee,
[13] K. Christidis and M. Devetsikiotis, “Blockchains and smart contracts and D. Levin, “Discovering bitcoins public topology and influ-
for the internet of things,” IEEE Access, vol. 4, pp. 2292–2303, 2016. ential nodes,” 2015. [Online]. Available: https://allquantor.at/
[14] Z. Zheng, S. Xie, H.-N. Dai, X. Chen, and H. Wang, “Blockchain blockchainbib/pdf/miller2015topology.pdf
challenges and opportunities: A survey,” Int. J. Web Grid Services, [39] C. Decker and R. Wattenhofer, “Information propagation in the
vol. 14, no. 4, pp. 352–375, 2018. bitcoin network,” in Proc. IEEE Int. Conf. Peer-to-Peer Comput.,
[15] C. Decker, J. Seidel, and R. Wattenhofer, “Bitcoin meets strong Sep. 2013, pp. 1–10.
consistency,” in Proc. 17th Int. Conf. Distrib. Comput. Netw., 2016,
pp. 13:1–13:10. [Online]. Available: http://doi.acm.org/10.1145/ Kai Lei received the BS degree from Peking
2833312.2833321 University, Beijing, China, in 1998, the MS degree
[16] R. S. Leslie Lamport and M. Pease, “The byzantine generals problem,” from Columbia University, Beijing, in 1999, and the
ACM Trans. Program. Lang. Syst., vol. 4, no. 3, pp. 382–401, Jul. 1982. PhD degree from Peking University, in 2015, all in
[17] M. Castro and B. Liskov, “Practical byzantine fault tolerance,” in computer science. He is an associate professor with
Proc. 3rd Symp. Operating Syst. Design Implementation, Feb. 1999, the School of Electronics and Computer Engineering
pp. 173–186. (SECE), Peking University, Shenzhen Graduate
[18] K. Croman et al., “On scaling decentralized blockchains,” in Proc. School, and director of the Shenzhen Key Lab for
Int. Conf. Financial Cryptography Data Security, 2016, pp. 106–125. Information-Centric Networking and Blockchain
[19] Y. Sompolinsky and A. Zohar, “Secure high-rate transaction proc- Technologies (ICNLab) and Center for Internet
essing in bitcoin,” in Proc. Int. Conf. Financial Cryptography Data Research and Engineering (CIRE). He also auth-
Security, 2015, pp. 507–527. ored a book titled Information-Centric networking and Named Data network-
[20] I. Eyal, A. Efe Gencer, E. G€ un Sirer, and R. van Renesse, “Bitcoin-NG: ing in Chinese with PKU press in 2015. His recent research interests include
A scalable blockchain protocol,” in Proc. 13th USENIX Symp. Netw. future Internet architecture, blockchain, NLP, AI, and Federated Learning.
Syst. Design Implementation, 2016, pp. 45–59.
[21] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena,
“A secure sharding protocol for open blockchains,” in Proc. ACM Maoyu Du received the BS degree in software
SIGSAC Conf. Comput. Commun. Security, 2016, pp. 17–30. engineering from the University of Electronic and
[22] R. Pass and E. Shi, “Hybrid consensus: Efficient consensus in the Technology of China, Sichuan, China. She is cur-
permissionless model,” in Proc. 31st Int. Symp. Distrib. Comput., rently working toward the MS degree with the focus
2017, pp. 39:1–39:16. on Blockchain tasks at Peking University, Shenz-
[23] R. Kotla, L. Alvisi, M. Dahlin, A. Clement, and E. Wong, hen, China. Her current research mainly focuses
“Zyzzyva: Speculative byzantine fault tolerance,” ACM SIGOPS on blockchain, including scalability and application.
Operating Syst. Rev., vol. 41, no. 6, pp. 45–58, 2007.
[24] J.-P. Martin and L. Alvisi, “Fast byzantine consensus,” IEEE Trans.
Dependable Secure Comput., vol. 3, no. 3, pp. 202–215, Jul./Aug. 2006.
[25] S. Liu, P. Viotti, C. Cachin, V. Quema, and M. Vukolic, “XFT: Prac-
tical fault tolerance beyond crashes,” in Proc. 12th USENIX Symp.
Jiyue Huang received the BS degree in electronic
Operating Syst. Design Implementation, 2016, pp. 485–500.
information engineering from Tianjin University,
[26] J. Zou, B. Ye, L. Qu, Y. Wang, M. A. Orgun, and L. Li, “A proof-of-
Tianjin, China. She is currently working toward the
trust consensus protocol for enhancing accountability in crowd-
MS degree with the focus on distributed machine
sourcing services,” IEEE Trans. Services Comput., vol. 12, no. 3,
learning methods and natural language process-
pp. 429–445, May/Jun. 2019.
ing tasks at Peking University, Shenzhen, China.
[27] A. Dorri, S. S. Kanhere, R. Jurdak, and P. Gauravaram, “LSB: A
In 2016, she studied with the City University of
lightweight scalable blockchain for IoT security and privacy,” J.
Hong Kong as an exchange student. Her current
Parallel Distrib. Comput., vol. 134, pp. 180–197, 2019.
research interests include distributed machine
[28] S. Biswas, K. Sharif, F. Li, B. Nour, and Y. Wang, “A scalable
learning and blockchain technology.
blockchain framework for secure transactions in IoT,” IEEE Inter-
net Things J., vol. 6, no. 3, pp. 4650–4659, Jun. 2019.
[29] Y. Liu, K. Wang, Y. Lin, and W. Xu, “LightChain: A lightweight Tong Jin received the MS degrees in computer science from Peking
blockchain system for industrial Internet of Things,” IEEE Trans. University, Beijing, China. She was with Shenzhen Key Lab for Cloud
Ind. Informat., vol. 15, no. 6, pp. 3571–3581, Jun. 2019. Computing Technology and Applications, School of Electronics and
[30] Z. Li, Z. Yang, S. Xie, W. Chen, and K. Liu, “Credit-based pay- Computer Engineering (SECE), Peking University, Shenzhen PR. China.
ments for fast computing resource trading in edge-assisted Inter- Her research interests include blockchain technology and named data
net of Things,” IEEE Internet Things J., vol. 6, no. 4, pp. 6606–6617, networking.
Aug. 2019.
" For more information on this or any other computing topic,
please visit our Digital Library at www.computer.org/csdl.

Authorized licensed use limited to: Kyunghee Univ. Downloaded on November 15,2020 at 03:57:26 UTC from IEEE Xplore. Restrictions apply.