Received November 8, 2018, accepted December 15, 2018, date of publication December 20, 2018,

date of current version January 16, 2019.

Digital Object Identifier 10.1109/ACCESS.2018.2888929

Design and Implementation on Hyperledger-

Based Emission Trading System
PU YUAN1 , XIONG XIONG1 , LEI LEI 2 , (Senior Member, IEEE),
AND KAN ZHENG 1 , (Senior Member, IEEE)
1 IntelligentComputing and Communication Lab, Key Lab of Universal Wireless Communications, Ministry of Education, Beijing University of Posts and
Telecommunications, Beijing 100876, China
2 College of Science and Engineering, James Cook University, Douglas, QLD 4814, Australia

Corresponding author: Kan Zheng (zkan@bupt.edu.cn)

This work was supported in part by the China Natural Science Funding under Grant 61671089 and in part by the Beijing University of
Posts and Telecommunications Excellent Ph.D. Students Foundation under Grant CX2016314.

ABSTRACT Emission trading policy provides a new approach using economic incentives to control the
environmental pollution efficiently. Legal polluters can trade emission permits with each other through a
trusted trading system that lacks security and credibility due to its centralization nowadays. Permissioned
blockchain utilize a decentralized way to store private data immutably, providing new approaches to
solve those defects of the existing centralized systems. In this paper, we propose a Hyperledger-based
Emission Trading System (HyperETS) on the permissioned blockchain. Using Hyperledger Fabric as the
implementation platform, HyperETS integrates the fine-grained access control, distributed ledger, and
consensus protocol, aiming to provide credible trading service for polluters. We achieve the business logic by
designing the particular ledger structures and smart contract in blockchain. HyperETS stores all transactions
immutably in a chain and makes it easy to share the data between organizations. Finally, several experiments
are conducted to evaluate the performances of the proposed demonstration system.

INDEX TERMS Emission trading, permissioned blockchain, smart contract, hyperledger fabric.

I. INTRODUCTION
Emission trading is a large-scale attempt to use economic
incentives in environmental policy [1]. It has proposed a new
market-based approach to control pollution. The government
sets an overall limit on emissions for participants so that those
legal polluters can trade emission permits with each other.
Authorized markets handle transactions and save the records
in databases. Various organizations have adopted such a trad-
ing system because of its high efficient in mitigating climate
change by reducing emissions of pollutants [2].
A typical emission trading system needs many independent
organizations to collaborate with each other. In addition,
trusted and secured service should be provided for them.
However, current trading systems usually use a centralized
architecture with traditional database to record transactions
and share data between organizations, which leads to several
problems in emission trading. First of all, centralized trading
system is governed by a single trusted center, which makes
the system lack of high reliability. Secondly, data sharing
between different organizations with independent databases
is inconvenient. Thirdly, traditional databases are vulnerable
to data tampering and data leakage [3]. Due to these disad-
vantages, a new system with high confidence and security is
demanded by emission trading markets.
To solve those issues mentioned above, the blockchain
technology originated from Bitcoin [4] is considered as a
new approach to provide trusted service [5]. As a transparent
and verifiable system, the blockchain uses a distributed and
immutable approach to record all valid transactions in blocks.
It provides decentralized service for participants and applies
Smart Contract (SC) to achieve the business logic [6]. Thus,
the systems based on blockchain have been widely accepted
by several applications such as Internet of Things (IoT) [7],
[8] and energy trading [9]. For vehicular systems [10], [11],
the blockchain provides a decentralized way for trust man-
agement [12]. A blockchain-based platform for insurance
processing has been proposed to offer fine-grained access
control among trusted participants [13]. Moreover, many
researches focus on integrating blockchain for private data
accessing and data sharing [14], [15]. Nowadays, blockchain
has been implemented in several ways such as permis-
sionless blockchain (e.g., Ethereum [16]) and permissioned

2169-3536
2018 IEEE. Translations and content mining are permitted for academic research only.
VOLUME 7, 2019 Personal use is also permitted, but republication/redistribution requires IEEE permission. 6109
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
 P. Yuan et al.: Design and Implementation on HyperETS

blockchain (e.g., Hyperledger Fabric [17]). Compared with

the permissionless blockchain, the permissioned blockchain
maintains private ledgers among the trusted participating
nodes to provide more intimate service and has higher system
throughput [18], [19]. Hyperledger Fabric is an open source
permissioned blockchain program aiming to provide a basic
framework for enterprise-grade applications [20]. It owns
a highly modular and configurable architecture, support-
ing pluggable consensus protocols and Membership Service
Provider (MSP). Hyperledger Fabric secures the interactions
among a group of authorized entities, in order to preserve the
privacy and confidentiality. Recent experiments conducted by
IBM have shown that the throughput of Hyperledger Fabric
can reach 2000 Transaction Per Second (TPS) at most [21].
By using those ready-made docker images and integrated
SDKs provided by Hyperledger Fabric, developers can easily
build up their own blockchain network. FIGURE 1. Application scenario.
In this paper, we propose a permissioned blockchain based
emission trading system named HyperETS to solve the
taken by the staff of the environmental agency. Only
central trust and data security problems existing in current
approved projects have the rights to trade emission
systems. With the customized ledger structures and access
permits.
controlled smart contract, HyperETS provides polluters with
3) Environmental Agency. This organization provides
a more credible and secure service for emission trading.
service for both traders and approvers. Registered
Authorized polluters can submit trading applications and
traders can submit corporation/project applications
trade emission permits at different organizations through a
and obtain the status of all applications here, while
web application. All transactions created by polluters are
approvers can accept or reject processing applications
stored as blocks in the blockchain, which persist in an
and retrieve the signing records through this organiza-
immutable and append-only way. In addition, specific con-
tion.
sensus protocol is developed to make sure that all trusted
4) Trading Center. Only registered traders can access
organizations maintain the same ledger in a distributed way,
the service provided by this organization. They can
which enhances the convenience of data sharing between
check the status of projects that accepted by approvers.
several organizations. HyperETS is developed based on
Buyers can view all selling emission permits and ini-
Hyperledger Fabric v1.1 and its performances are evaluated
tiate a transaction, while sellers can check the trans-
by examining the system throughput under different kinds of
actions of their projects and decide to accept or reject
operations and system configurations.
these transactions. To complete a emission trading
The rest of this paper is organized as follows. Section II
process, these entities should follow the steps shown
introduces the application scenario and the overall archi-
in Fig.1.
tecture of HyperETS. Then, we present the design and
implementation of the system in detail in Section III. Next, • Step 1: The registered trader has to submit a cor-
performance evaluation in term of system throughput is given poration application which contains a list of neces-
in Section IV. Finally, we conclude this paper in Section V. sary materials (e.g., corporate certificate) at envi-
ronmental agency.
• Step 2: The approver of environmental agency
II. SYSTEM OVERVIEW
checks the validity of these materials.
A. APPLICATION SCENARIO
• Step 3: Once the application is accepted by the
The application scenario of the proposed emission trading approver, the trader can submit a project applica-
system is illustrated in Fig.1. Four entities are included as tion based on this permitted corporation identity.
follows, i.e., Project application includes details of emission
1) Trader. Users who want to trade emission per- trading (e.g., type of project: buy/sell, amount of
mits. Before acquiring the privilege to trade emis- trading emission permits).
sion permits, traders have to submit corporation and • Step 4: The approver checks the validity of project
project applications. The details of the process will be application.
described later. • Step 5: If the project is accepted by approver, it can
2) Approver. Users who have the privilege to accept or be seen in trading center.
reject a corporation/project application according to • Step 6: The traders start trading emission permits
the relevant policies. For example, such role can be with each other based on those validated projects.

6110 VOLUME 7, 2019

P. Yuan et al.: Design and Implementation on HyperETS
B. SYSTEM ARCHITECTURE
Fig.2 depicts the overview of system architecture. The
proposed HyperETS consists of three parts as follows, i.e.,
FIGURE 2. System architecture.
1) BLOCKCHAIN NETWORK
HyperETS integrates the following features,i.e., distributed
and chained storage for transaction records, fine-grained
access control based on identity authentication and pluggable
consensus protocols for ordering service. As a typical imple-
mentation for Hyperledger Fabric, the network contains many
essential components as follows.
• Order. Hyperledger Fabric network is administered by
a collection of organizations, which contribute resources
such as peers to the network. The order can be regarded
as a special organization without peers. Moreover,
the order can have its own Certificate Authority (CA) to
issue certificates instead of using a public one. The order
is aimed at providing ordering service for the network.
When receiving ledger updates proposals (e.g., approver
accepts corporation applications) on a particular chan-
nel, the order arranges these requests into a well-defined
sequence and packages them into blocks. Once a valid
block has been generated, it is delivered to all leader
peers belonging to this particular channel through the
gossip protocol.
• Environmental Agency. This entity, which is men-
tioned in the application scenario above, is imbedded
into an individual organization defined in the Hyper-
ledger Fabric framework. A typical organization can
host a local Fabric CA and a set of peers. Fabric CA
issues certificates for users, peers and orderers to enable
MSP, in order to achieve the access control policy.
For example, only administrator identity which has
been enrolled by Fabric CA can install SC on peers.
VOLUME 7, 2019
Peer is the fundamental element of Hyperledger Fab-
ric network and it can hold multiple ledgers and SC.
Ledgers immutably record all the transactions gener-
ated by SC such as applications submitted by traders.
In addition, a peer can play multiple roles in the network.
Committing peers receive blocks of valid transactions
and commit them to ledgers while endorsing peers can
endorse for SC proposals before updates are committed
to ledgers.
• Trading Center. As an organization, the trading center
has the same architecture as environmental agency.
It also owns a local CA and a set of peers to guarantee
resource persistence and provide access control policy.
These two organizations communicate with each other
through a specific channel.
• Channel. Channel provides a private bridge for a set
of peers and applications to communicate with each
other within a network where data and transactions are
isolated. A special channel is established in our network
to connect environmental agency and trading center.
Peers from those two organizations join this channel
to maintain a consistent ledger, which makes the data
sharing more convenient.
• Smart Contract (SC). Smart Contract is a program that
implements a prescribed interface, it can manage the
ledger states through transactions. In HyperETS, a col-
lection of functions are provided to achieve the business
logic of emission trading. We design these functions
according to the organization that invokes them. After
instantiating SC on target channel, all the peers that have
installed the SC can invoke those functions to interact
with the ledger.
2) CLIENT APPLICATION & HTTP SERVER
Application provides the emission trading service for both
traders and approvers. It can interacts with the background
blockchain network via the RESTful APIs provided by the
HTTP server. HTTP server in HyperETS plays a role of mid-
dleware. Besides receiving and processing HTTP requests
from applications, HTTP the server has to interact with the
blockchain network directly to achieve the business logic
by invoking specific SC. By this way, the HTTP server can
decouple applications and the blockchain network.
III. IMPLEMENTATION OF HYPERETS
A. BLOCKCHAIN NETWORK
Based on Hyperledger Fabric, HyperETS implements a
robust and scalable permissioned blockchain network. With
the fine-grained ledger structure and well-defined SC, it can
achieve the business logic of emission trading efficiently.
In the rest of this section we present the design and imple-
mentation of the blockchain network in details. In addition,
we open source the code of this part on github.1
1 https://github.com/xisiot/HyperETS
6111
 P. Yuan et al.: Design and Implementation on HyperETS

1) LEDGER DESIGN TABLE 1. Design of states. (a) Corporation application. (b) Project.
(c) Transaction.
Ledger in peer includes a world state and a blockchain. The
world state is a database that holds the current values of a
set of ledger states, while the blockchain is a transaction
log which recalls all the changes that determine the world
state immutably. All those states are expressed as key-value
pairs, which have a great interactivity with JavaScript Object
Notation (JSON). Fig.3 plots the relationship between word
state entities. It shows that the user associates with several
corporation applications and projects through specific rela-
tion tables, which enable SC to execute flexible queries.
What’s more, a project can hold multiple transactions with
different status. To maintain this relationship, project has to
record the ids of related transactions in its value field.

FIGURE 3. Illustration of ledger structure.

The structures of quite a few essential states in HyperETS

are shown in Table 1. Table 1(a) depicts the structure of
corporation application that submitted by traders. We use
a special function named Composite to create a composite
key for each application. The generated key consists of a
unique prefix string and a list of attributes. By this way,
we can retrieve all states whose key matches giving prefix
and attributes conveniently. In the value field, an Universally
Unique Identifier (UUID) is generated to identify a unique
application. The ‘status’ field indicates the signing result
from approver and the ‘project_id’ field associates this appli-
cation with the project based on it. Once an application is
created by trader or updated by approver, it can append a new
block to the blockchain.
Table 1(b) depicts the structure of a typical project in
HyperETS. A project can be submitted by traders based on
an accepted corporation application. The value field uses
‘type’ to indicate its identity in trading and record transac-
tions related to this project by saving their ids. Moreover,
five statuses are used to represent the stage of a project.
‘Processing’ means this project has not been signed by
approver, ‘accepted’ indicates that the project is validated and
ready to trade, while ‘rejected’ means it has been denied.
If there is a processing transaction waited to be confirmed
by seller, the status is ‘trading’, which can lock this project
until the related transaction is confirmed. Finally, if the
‘remain_emission_permits’ field decreases to 0, the status
will change to ‘done’ to close this project. Table 1(c) shows
the structure of transaction. A transaction is created when
buyer buys emission permits from a project with ‘accepted’
status. Only the seller can update the ‘status’ field, by which
the transaction can be confirmed and the related projects can
be updated.
Besides those ledger structures mentioned above, we also
design a particular key-value pair to store information for
registered traders. Moreover, two relation tables are built
to associate traders with the corporation/project applications
that submitted by them.
2) SMART CONTRACT DESIGN
In HyperETS, we implement the SC in Node.js and install
them on all peers in the channel, aiming to provide spe-
cific service for environmental agency and trading center.

6112 VOLUME 7, 2019

P. Yuan et al.: Design and Implementation on HyperETS
Because those functions are invoked by diverse organization,
the SC can be divided into two parts as follows:
a: APPLICATION CONTRACT (AC)
The environmental agency manages the process of corpora-
tion and project application through AC that installed on its
inner peers. Functions in AC provide three mainly types of
operations on those applications: create, update and query.
Firstly, passing essential parameters to the specific function,
traders can create applications and append data blocks to the
blockchain. Secondly, AC enables approvers to update the
‘status’ field in applications to represent the signing result.
Thirdly, AC implements several functions to provide flexi-
ble query service on ledger, e.g., traders can query applica-
tions based on the ‘applicant_user’ field while approvers can
retrieve data with specified status or unique id. In addition,
query operations can be executed on peers directly without
sending proposals to the orderer nodes. Thus, they cost less
time than create and update operations which have to fulfill
the endorsement policy.
b: TRADING CONTRACT (TC)
TC achieves the business logic of emission trading in
HyperETS. Multiple functions collaborate to provide the
trading service for registered traders. As mentioned before,
when buyers choose a selling project to start a transac-
tion, a new key-value pair is generated and appended to
the blockchain. Sellers can retrieve all processing transac-
tions related to their projects and confirm them through
TC. Algorithm 1 and 2 depict the workflow of purchase
and confirm in detail. Algorithm 1 shows the restrictions of
trading projects. The status field must be ‘accepted’ and the
‘remain_emission_permits’ needs to be more than trading
amount. Algorithm 2 indicates that when a transaction is
settled, multiple fields in related projects should be updated
according to the trading amount and seller’s option.
Algorithm 1 Purchase
Input:
buyerId: UUID of buyer project;
sellerId: UUID of seller project;
amount: amount of trading emission permits;
Output:
null;
1: Generate composite key buyerKey and sellerKey by
buyerId and sellerId;
2: Get buyerProject(bP) and sellerProject(sP) by generated
keys;
3: if bP.status = sP.status = 0 accepted 0 then
4: if bP.remain and sP.remain >= amount then
5: generate new transaction with tsId
6: bP.status, sP.status ⇐ 0 trading0
7: bP.processing, sP.processing ⇐ tsId
8: end if
9: end if
VOLUME 7, 2019
Algorithm 2 Confirm
Input:
transactionId(tsId): UUID of transaction;
option: accept or reject this transaction;
Output:
null;
1: Generate composite key transactionKey by tsId;
2: Get transaction(ts) by transactionKey;
3: Get buyerProject(bP) and sellerProject(sP) by
ts.buyerId and ts.sellerId;
4: if option = 0 accept 0 then
5: ts.status ⇐ 0 accepted 0
6: bP.remain ⇐ bP.remain − ts.amount
7: sP.remain ⇐ sP.remain − ts.amount
8: if bP.remain = 0 then
9: bP.status ⇐ 0 done0
10: end if
11: if sP.remain = 0 then
12: sP.status ⇐ 0 done0
13: end if
14: else
15: ts.status ⇐ 0 rejected 0
16: end if
17: bP.processing, sP.processing ⇐ null;
18: bP.complete, sP.complete add tsId
3) SYSTEM CONFIGURATION
As mentioned in Section II, the blockchain network in
HyperETS consists of several essential parts such as order,
channel and peer, etc. This system is scalable due to the
adjustable peer designing and deploying strategies. In Hyper-
ETS, we set up a typical network with an orderer node, one
channel and two organizations that represent the environ-
mental agency and trading center respectively. The ordering
service adopts solo consensus protocol. Each organization
includes a local Fabric CA and a single peer. This single peer
installs well-designed SC and holds a distinct ledger which
uses LevelDB as the state database. As the only peer of the
organization, it integrates both commitment and endorsement
functions. Thus, when an update proposal is sent to this peer,
it can endorse this transaction and then commit it to the ledger.
The channel in network is established to connect two organi-
zations and provide a mechanism for private communications
and data sharing. In addition, all those system nodes (e.g.,
peer, order, CA) are implemented in the form of running
docker containers.
B. CLIENT APPLICATION & HTTP SERVER
As shown in Fig.4, a web application is provided for users
to access the HyperETS service. The HTTP server connects
application with the background blockchain network. For
applications, Express,2 i.g., a minimal and flexible Node.js
web application framework is used to implement basic HTTP
2 http://expressjs.com/
6113

FIGURE 4. Web UI for HyperETS.
server functions and provide a series of RESTful APIs. For
blockchain network, the server needs to interact with several
parts via supported SDKs. Firstly, the server has to access
the Fabric CA as a client in order to enroll the administrator
identity and set user context. Secondly, by using APIs pro-
vided by Fabric SDK, the server is able to invoke specific
SC on target channel by assigning unique channel ID and
function arguments to requests, aiming to query and update
ledger on specified peers. The specific user context set by
server previously can be used to sign all the requests invoked
by APIs. Furthermore, all the data retrieved from ledger can
be returned to applications in JSON format. Thus, the proce-
dures of our HTTP server can be summarized as follows, i.e.
• Step 1: Using Fabric CA SDK to enroll the admin
identity.
• Step 2: Starting the HTTP server to listen a specific port
and receive requests from applications.
• Step 3: According to the diverse parameters of requests,
using Fabric SDK to invoke target SC to do some
query or update operations.
• Step 4: Returning data to applications in JSON format.
IV. EXPERIMENTAL RESULTS AND ANALYSIS
The performance of HyperETS is evaluated by analyzing
the system throughput of HTTP requests. A series of exper-
iments are performed on a aliyun cloud server with four
Intel(R) Xeon(R) Platinum 8163 CPU @2.5GHz processors
and 8 GB RAM, running Ubuntu 16.04(64 bit). The through-
put of HyperETS is evaluated by Requests Per Second (RPS),
the rate at which requests are completely processed. We use
Locust,3 an open source load testing framework to evaluate
the system throughput over increasing request arrival rates.
Two specific HTTP interfaces are chosen to execute query
and create operations on peers, respectively.
A. SYSTEM THROUGHPUT OF QUERY OPERATION
Fig.5 shows the throughput and median response time of
query interface. It indicates that with the increasing of
requests arrival rate, the throughput increases linearly with
a low median response time at beginning until the arrival
3 https://www.locust.io/
6114
P. Yuan et al.: Design and Implementation on HyperETS
FIGURE 5. Throughput of query operation.
rate reaches about 300 RPS. Then, the throughput increases
slowly and the median response time rises rapidly before
it reach the saturation point at about 340 RPS. After the
saturation point, higher arrival rates may cause the lower
throughput due to the server bottleneck.
B. SYSTEM THROUGHPUT OF CREATE OPERATION
Compared with query operations, create ones are more com-
plicated and time consuming due to the consensus mecha-
nism. The throughput of system is affected by the configura-
tion of ordering service. Hyperledger Fabric provides several
strategies to cut blocks, e.g., cut by message count and block
size. Extensive experiments have been conducted to analyze
the impact of different parameters on throughput with the
solo consensus protocol. Some of the important experimental
parameters are listed in Table 2. When adjusting the message
count for analyzing, we set a large value for block size so it
doesn’t affect the experiments and vice versa. Fig.6 shows the
experimental results.
TABLE 2. Experimental parameters.
Fig.6(a) plots the throughput curve over different message
count. It indicates that with the increasing of message count in
a single block, the stable point of system throughput increases
rapidly at first. But when message count reaches 5, the sys-
tem throughput seems to reach a saturation point at about
200 RPS. So we can draw the conclusion that before message
count reaches the critical point, the bottleneck of our system
is the ordering service. Fig.6(b) shows how block size affects
the system throughput. In general, the impact of block size
on throughput is the same as message count. After the block
size exceeds 16k, continue to increase size can’t improve the
performance anymore. Moreover, it can see that the highest
throughput of HyperETS is about 200 RPS.
VOLUME 7, 2019
P. Yuan et al.: Design and Implementation on HyperETS
FIGURE 6. Throughput of create operation. (a) Impact of message count
on throughput. (b) Impact of block size on throughput.
V. CONCLUSION
In this paper we have proposed HyperETS: a emission trad-
ing system based on permissioned blockchain to solve the
defects of existing centralized systems. We have presented the
design and implementation of this system in detail, especially
the ledger and smart contract. Extensive experiments have
been conducted to evaluate the system performance. Those
experiments analyze the system throughput of HTTP requests
with different type of operations and different parameters
of configuration. The results indicate that the throughput of
query operations can reach 340 RPS while create operations
only reach around 200 RPS due to the underlying consensus
mechanism. As for the configuration, setting the appropriate
parameters for ordering service has a great influence on sys-
tem performance and the specific value depends on the real
business logic.
REFERENCES
[1] W. Yan and D. Tang, ‘‘Incentives for environmental technological inno-
vation in emission trading,’’ in Proc. Int. Conf. Remote Sens., Environ.
Transp. Eng., Nanjing, China, 2011, pp. 3206–3210.
VOLUME 7, 2019
[2] J. Huang et al., ‘‘An experimental study on emission trading behav-
iors of generation companies,’’ IEEE Trans. Power Syst., vol. 30, no. 2,
pp. 1076–1083, Mar. 2015.
[3] S. Imran and I. Hyder, ‘‘Security issues in databases,’’ in Proc. 2nd
Int. Conf. Future Inf. Technol. Manage. Eng., Sanya, China, 2009,
pp. 541–545.
[4] S. Nakamoto, ‘‘Bitcoin: A peer-to-peer electronic cash system,’’
White Paper, 2008.
[5] Y. Yong and F.-Y. Wang, ‘‘Blockchain: The state of the art and future
trends,’’ Acta Autom. Sinica, vol. 42, no. 4, pp. 481–494, 2016.
[6] C. D. Clack, V. A. Bakshi, and L. Braine. (Dec. 2016). ‘‘Smart contract
templates: Essential requirements and design options.’’ [Online]. Avail-
able: https://arxiv.org/abs/1612.04496
[7] S. Huh, S. Cho, and S. Kim, ‘‘Managing IoT devices using blockchain
platform,’’ in Proc. 19th Int. Conf. Adv. Commun. Technol. (ICACT),
Bongpyeong, South Korea, Feb. 2017, pp. 464–467.
[8] K. Christidis and M. Devetsikiotis, ‘‘Blockchains and smart contracts for
the Internet of Things,’’ IEEE Access, vol. 4, pp. 2292–2303, 2016.
[9] N. Z. Aitzhan and D. Svetinovic, ‘‘Security and privacy in decentralized
energy trading through multi-signatures, blockchain and anonymous mes-
saging streams,’’ IEEE Trans. Dependable Secure Comput., vol. 15, no. 5,
pp. 840–852, Sep./Oct. 2018.
[10] K. Zheng, L. Hou, H. Meng, Q. Zheng, N. Lu, and L. Lei, ‘‘Soft-defined
heterogeneous vehicular network: Architecture and challenges,’’ IEEE
Netw., vol. 30, no. 4, pp. 72–80, Jul./Aug. 2016.
[11] K. Zheng, H. Meng, P. Chatzimisios, L. Lei, and X. Shen, ‘‘An SMDP-
based resource allocation in vehicular cloud computing systems,’’ IEEE
Trans. Ind. Electron., vol. 62, no. 12, pp. 7920–7928, Dec. 2015.
[12] Z. Yang, K. Yang, L. Lei, K. Zheng, and V. C. M. Leung, ‘‘Blockchain-
based decentralized trust management in vehicular networks,’’ IEEE Inter-
net Things J., to be published, doi: 10.1109/JIOT.2018.2836144.
[13] M. Raikwar, S. Mazumdar, S. Ruj, S. S. Gupta, A. Chattopadhyay, and
K. Lam, ‘‘A blockchain framework for insurance processes,’’ in Proc. 9th
IFIP Int. Conf. New Technol., Mobility Secur. (NTMS), Paris, France, 2018,
pp. 1–4.
[14] X. Liang, J. Zhao, S. Shetty, J. Liu, and D. Li, ‘‘Integrating blockchain
for data sharing and collaboration in mobile healthcare applications,’’
in Proc. IEEE 28th Annu. Int. Symp. Pers., Indoor, Mobile Radio
Commun. (PIMRC), Montreal, QC, Canada, Oct. 2017, pp. 1–5.
[15] A. Azaria, A. Ekblaw, T. Vieira, and A. Lippman, ‘‘MedRec: Using
blockchain for medical data access and permission management,’’ in
Proc. 2nd Int. Conf. Open Big Data (OBD), Vienna, Austria, Aug. 2016,
pp. 25–30.
[16] G. Wood, ‘‘Ethereum: A secure decentralised generalised transaction
ledger,’’ Ethereum Found., Cham, Switzerland, Ethereum Project Yellow
Paper 151, 2014, pp. 1–32.
[17] C. Cachin, ‘‘Architecture of the hyperledger blockchain fabric,’’ in Proc.
Workshop Distrib. Cryptocurrencies Consensus Ledgers. vol. 310, 2016,
pp. 1–4.
[18] W.-T. Tsai, X. Bai, and L. Yu, ‘‘Design issues in permissioned blockchains
for trusted computing,’’ in Proc. IEEE Symp. Service-Oriented Syst.
Eng. (SOSE), San Francisco, CA, USA, Apr. 2017, pp. 153–159.
[19] Q. Nasir, I. A. Qasse, M. A. Talib, and A. B. Nassif, ‘‘Performance anal-
ysis of hyperledger fabric platforms,’’ Secur. Commun. Netw., vol. 2018,
Sep. 2018, Art. no. 3976093, doi: 10.1155/2018/3976093.
[20] E. Androulaki et al., ‘‘Hyperledger fabric: A distributed operating
system for permissioned blockchains,’’ in Proc. ACM 13th EuroSys
Conf. (EuroSys), New York, NY, USA, 2018, Art. no. 30.
[21] P. Thakkar, S. Nathan, and B. Vishwanathan. (May 2018). ‘‘Performance
benchmarking and optimizing hyperledger fabric blockchain platform.’’
[Online]. Available: https://arxiv.org/abs/1805.11390
PU YUAN received the B.S. degree from the
Beijing University of Posts and Telecommuni-
cations, China, in 2017, where he is currently
pursuing the master’s degree with the Intelligent
Computing and Communication Lab, Key Lab of
Universal Wireless Communications, Ministry of
Education. His research interests include security
in the Internet of Things networks.
6115
 P. Yuan et al.: Design and Implementation on HyperETS

XIONG XIONG received the B.S. degree from KAN ZHENG (SM’09) received the B.S., M.S.,
the Beijing University of Posts and Telecommu- and Ph.D. degrees from the Beijing University
nications, China, in 2013, where he is currently of Posts and Telecommunications (BUPT), China,
pursuing the Ph.D. degree. His research interests in 1996, 2000, and 2005, respectively. He is cur-
include radio resource management and security rently a Professor with BUPT. He has rich experi-
in the Internet of Things networks. ences on the research and standardization of the
new emerging technologies. He is the author of
more than 200 journal articles and conference
papers in the field of the IoT, vehicular commu-
nication, security, and so on. He holds editorial
board positions of several journals and has organized several special issues,
including the IEEE COMMUNICATIONS SURVEYS AND TUTORIALS, the IEEE Com-
munications Magazine, and the IEEE SYSTEMS JOURNAL.
LEI LEI (SM’16) received the B.S. and Ph.D.
degrees in telecommunications engineering from
the Beijing University of Posts and Telecommu-
nications, China, in 2001 and 2006, respectively.
She is currently with the School of Science and
Engineering, James Cook University, Australia.
Her current research interests include the Inter-
net of Things and mobile cloud computing.

6116 VOLUME 7, 2019