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

fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2018.2888929, IEEE Access

Date of publication xxxx 00, 0000, date of current version xxxx 00, 0000.
Digital Object Identifier 10.1109/ACCESS.2017.DOI

Design and Implementation on

Hyperledger-based Emission Trading
System
PU YUAN1 , XIONG XIONG1 , LEI LEI2 AND KAN ZHENG1 (Senior Member, IEEE)
1
Intelligent Computing and Communication (IC2 ) Lab, Key Lab of Universal Wireless Communications, Ministry of Education, Beijing University of Posts &
Telecommunications, Beijing, China, 100876
2
College of Science & Engineering, James Cook University, Australia
Corresponding author: K.ZHENG (e-mail: [email protected])

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

VOLUME 4, 2016 1

2169-3536 (c) 2018 IEEE. Translations and content mining are permitted for academic research only. Personal use is also permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2018.2888929, IEEE Access

P.YUAN et al.: HyperETS: A Permissioned Blockchain based Emission Trading SystemS

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

the permissionless blockchain, the permissioned blockchain Ċ

maintains private ledgers among the trusted participating

Trader
nodes to provide more intimate service and has higher system
throughput [18], [19]. Hyperledger Fabric is an open source 1 6
permissioned blockchain program aiming to provide a basic
3
framework for enterprise-grade applications [20]. It owns
a highly modular and configurable architecture, support- 5

ing pluggable consensus protocols and Membership Service

Provider (MSP). Hyperledger Fabric secures the interactions Environmental 4 Trading
among a group of authorized entities, in order to preserve the Agency Center
2
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

Approver
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
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. Au- service for both traders and approvers. Registered
thorized polluters can submit trading applications and trade traders can submit corporation/project applications and
emission permits at different organizations through a web obtain the status of all applications here, while ap-
application. All transactions created by polluters are stored as provers can accept or reject processing applications
blocks in the blockchain, which persist in an immutable and and retrieve the signing records through this organiza-
append-only way. In addition, specific consensus protocol is tion.
developed to make sure that all trusted organizations main- 4) Trading Center. Only registered traders can access the
tain the same ledger in a distributed way, which enhances the service provided by this organization. They can check
convenience of data sharing between several organizations. the status of projects that accepted by approvers. Buy-
HyperETS is developed based on Hyperledger Fabric v1.1 ers can view all selling emission permits and initiate
and its performances are evaluated by examining the system a transaction, while sellers can check the transactions
throughput under different kinds of operations and system of their projects and decide to accept or reject these
configurations. transactions. To complete a emission trading process,
The rest of this paper is organized as follows. Section these entities should follow the steps shown in Fig.1.
II introduces the application scenario and the overall ar-
• Step 1: The registered trader has to submit a
chitecture of HyperETS. Then, we present the design and
corporation application which contains a list of
implementation of the system in detail in Section III. Next,
necessary materials (e.g., corporate certificate) at
performance evaluation in term of system throughput is given
environmental agency.
in Section IV. Finally, we conclude this paper in Section V.
• Step 2: The approver of environmental agency
checks the validity of these materials.
II. SYSTEM OVERVIEW • Step 3: Once the application is accepted by the
A. APPLICATION SCENARIO approver, the trader can submit a project applica-
The application scenario of the proposed emission trading tion based on this permitted corporation identity.
system is illustrated in Fig.1. Four entities are included as Project application includes details of emission
follows, i.e., trading (e.g., type of project: buy/sell, amount of
1) Trader. Users who want to trade emission permits. Be- trading emission permits).
fore acquiring the privilege to trade emission permits, • Step 4: The approver checks the validity of project
traders have to submit corporation and project applica- application.
tions. The details of the process will be 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.
taken by the staff of the environmental agency. Only
2 VOLUME 4, 2016

2169-3536 (c) 2018 IEEE. Translations and content mining are permitted for academic research only. Personal use is also permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2018.2888929, IEEE Access

P.YUAN et al.: HyperETS: A Permissioned Blockchain based Emission Trading System

B. SYSTEM ARCHITECTURE is the fundamental element of Hyperledger Fabric net-

Fig.2 depicts the overview of system architecture. The pro- work and it can hold multiple ledgers and SC. Ledgers
posed HyperETS consists of three parts as follows, i.e., immutably record all the transactions generated by SC
such as applications submitted by traders. In addition, a
peer can play multiple roles in the network. Committing
Submit Sign Buy Confirm peers receive blocks of valid transactions and commit
Application Application Permits Transaction
them to ledgers while endorsing peers can endorse for
ĊĊ ĊĊ ĊĊ ĊĊ
App for Environmental Agency App for Trading Center
SC proposals before updates are committed to ledgers.
• Trading Center. As an organization, the trading center
has the same architecture as environmental agency. It
Client Client
also owns a local CA and a set of peers to guarantee
resource persistence and provide access control policy.
HTTP Server
These two organizations communicate with each other
through a specific channel.
• Channel. Channel provides a private bridge for a set
Peer Channel Peer of peers and applications to communicate with each
SC SC
1~n 1~n other within a network where data and transactions are
isolated. A special channel is established in our network
CA CA to connect environmental agency and trading center.
Orderer CA
Peers from those two organizations join this channel
Environmental Agency Order Trading Center to maintain a consistent ledger, which makes the data
Hyperledger Fabric Network sharing more convenient.
FIGURE 2: System Architecture • 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
1) Blockchain Network
logic of emission trading. We design these functions
HyperETS integrates the following features,i.e., distributed according to the organization that invokes them. After
and chained storage for transaction records, fine-grained ac- instantiating SC on target channel, all the peers that have
cess control based on identity authentication and pluggable installed the SC can invoke those functions to interact
consensus protocols for ordering service. As a typical im- with the ledger.
plementation for Hyperledger Fabric, the network contains
many essential components as follows.
2) Client Application & HTTP Server
• Order. Hyperledger Fabric network is administered by Application provides the emission trading service for both
a collection of organizations, which contribute resources traders and approvers. It can interacts with the background
such as peers to the network. The order can be regarded blockchain network via the RESTful APIs provided by the
as a special organization without peers. Moreover, the HTTP server. HTTP server in HyperETS plays a role of mid-
order can have its own Certificate Authority (CA) to dleware. Besides receiving and processing HTTP requests
issue certificates instead of using a public one. The order from applications, HTTP the server has to interact with the
is aimed at providing ordering service for the network. blockchain network directly to achieve the business logic
When receiving ledger updates proposals (e.g., approver by invoking specific SC. By this way, the HTTP server can
accepts corporation applications) on a particular chan- decouple applications and the blockchain network.
nel, the order arranges these requests into a well-defined
sequence and packages them into blocks. Once a valid
III. IMPLEMENTATION OF HYPERETS
block has been generated, it is delivered to all leader
A. BLOCKCHAIN NETWORK
peers belonging to this particular channel through the
gossip protocol. Based on Hyperledger Fabric, HyperETS implements a ro-
• Environmental Agency. This entity, which is men- bust and scalable permissioned blockchain network. With
tioned in the application scenario above, is imbedded the fine-grained ledger structure and well-defined SC, it can
into an individual organization defined in the Hyper- achieve the business logic of emission trading efficiently. In
ledger Fabric framework. A typical organization can the rest of this section we present the design and implemen-
host a local Fabric CA and a set of peers. Fabric CA tation of the blockchain network in details. In addition, we
issues certificates for users, peers and orderers to enable open source the code of this part on github 1 .
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. Peer 1 https://github.com/xisiot/HyperETS

VOLUME 4, 2016 3

2169-3536 (c) 2018 IEEE. Translations and content mining are permitted for academic research only. Personal use is also permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2018.2888929, IEEE Access

P.YUAN et al.: HyperETS: A Permissioned Blockchain based Emission Trading SystemS

1) Ledger Design TABLE 1: Design of States

Ledger in peer includes a world state and a blockchain. The (a) Corporation Application
world state is a database that holds the current values of a
Prefix CORP_APPLICATION
set of ledger states, while the blockchain is a transaction Key Composite(prefix, [id])
log which recalls all the changes that determine the world {
state immutably. All those states are expressed as key-value id: UUID,
applicant:‘user_one’,
pairs, which have a great interactivity with JavaScript Ob- name:‘corp_one’,
Value
ject Notation (JSON). Fig.3 plots the relationship between certificate: ‘description’,
word state entities. It shows that the user associates with status:‘processing’/‘accepted’/‘rejected’,
project_id: null
several corporation applications and projects through specific }
relation tables, which enable SC to execute flexible queries.
What’s more, a project can hold multiple transactions with (b) Project
different status. To maintain this relationship, project has to
Prefix PROJECT
record the ids of related transactions in its value field. Key Composite(prefix, [id])
{
id: UUID,
1:1
User2Corp 1:n
CorpApplication
corp_application_id: application_one_id,
· corpApp_ids · id applicant: ‘user_one’,
· ... · certificate name: ‘project_one’,
· ...
type: ‘buy’/‘sell’,
User initial_emission_permits: 5000,
Value
· username target_emission_permits: 3000,
· password remain_emission_permits: 3000,
· ... completed_transactions:[‘ts_one_id’ ‘ts_two_id’],
processing_transaction: ts_three_id,
User2Project Project status: ‘processing’/‘accepted’/‘rejected’/
· project_ids · id ‘trading’/‘done’
1:1 · ... 1:n · type
}
· ...
1:n
(c) Transaction
Transaction Prefix TRANSACTION
· id Key Composite(prefix, [id])
· status {
· ...
id: UUID,
sell_project_id: project_one_id,
FIGURE 3: Illustration of Ledger Structure Value buy_project_id: project_two_id,
transaction_emission_permits: 1000,
status:âĂŹacceptedâĂŹ/âĂŹrejectedâĂŹ/âĂŹtradingâĂŹ
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 denied. If there is a processing transaction waited to be
key for each application. The generated key consists of a confirmed by seller, the status is ‘trading’, which can lock this
unique prefix string and a list of attributes. By this way, project until the related transaction is confirmed. Finally, if
we can retrieve all states whose key matches giving prefix the ‘remain_emission_permits’ field decreases to 0, the status
and attributes conveniently. In the value field, an Universally will change to ‘done’ to close this project. Table 1(c) shows
Unique Identifier (UUID) is generated to identify a unique the structure of transaction. A transaction is created when
application. The ‘status’ field indicates the signing result buyer buys emission permits from a project with ‘accepted’
from approver and the ‘project_id’ field associates this ap- status. Only the seller can update the ‘status’ field, by which
plication with the project based on it. Once an application is the transaction can be confirmed and the related projects can
created by trader or updated by approver, it can append a new be updated.
block to the blockchain. Besides those ledger structures mentioned above, we also
Table 1(b) depicts the structure of a typical project in design a particular key-value pair to store information for
HyperETS. A project can be submitted by traders based on an registered traders. Moreover, two relation tables are built
accepted corporation application. The value field uses ‘type’ to associate traders with the corporation/project applications
to indicate its identity in trading and record transactions that submitted by them.
related to this project by saving their ids. Moreover, five
statuses are used to represent the stage of a project. ‘Pro- 2) Smart Contract Design
cessing’ means this project has not been signed by approver, In HyperETS, we implement the SC in Node.js and install
âĂŸacceptedâĂŹ indicates that the project is validated and them on all peers in the channel, aiming to provide specific
ready to trade, while âĂŸrejectedâĂŹ means it has been service for environmental agency and trading center. Because
4 VOLUME 4, 2016

2169-3536 (c) 2018 IEEE. Translations and content mining are permitted for academic research only. Personal use is also permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2018.2888929, IEEE Access

P.YUAN et al.: HyperETS: A Permissioned Blockchain based Emission Trading System

those functions are invoked by diverse organization, the SC Algorithm 2 Confirm

can be divided into two parts as follows: Input:
transactionId(tsId): UUID of transaction;
a: Application Contract (AC) option: accept or reject this transaction;
The environmental agency manages the process of corpora- Output:
tion and project application through AC that installed on its null;
inner peers. Functions in AC provide three mainly types of 1: Generate composite key transactionKey by tsId;
operations on those applications: create, update and query. 2: Get transaction(ts) by transactionKey;
Firstly, passing essential parameters to the specific function, 3: Get buyerP roject(bP ) and sellerP roject(sP ) by
traders can create applications and append data blocks to the ts.buyerId and ts.sellerId;
blockchain. Secondly, AC enables approvers to update the 4: if option = 0 accept0 then
‘status’ field in applications to represent the signing result. 5: ts.status ⇐ 0 accepted0
Thirdly, AC implements several functions to provide flexible 6: bP.remain ⇐ bP.remain − ts.amount
query service on ledger, e.g., traders can query applications 7: sP.remain ⇐ sP.remain − ts.amount
based on the ‘applicant_user’ field while approvers can re- 8: if bP.remain = 0 then
trieve data with specified status or unique id. In addition, 9: bP.status ⇐ 0 done0
query operations can be executed on peers directly without 10: end if
sending proposals to the orderer nodes. Thus, they cost less 11: if sP.remain = 0 then
time than create and update operations which have to fulfill 12: sP.status ⇐ 0 done0
the endorsement policy. 13: end if
14: else
b: Trading Contract (TC)
15: ts.status ⇐ 0 rejected0
TC achieves the business logic of emission trading in Hyper- 16: end if
ETS. Multiple functions collaborate to provide the trading 17: bP.processing, sP.processing ⇐ null;
service for registered traders. As mentioned before, when 18: bP.complete, sP.complete add tsId
buyers choose a selling project to start a transaction, a new
key-value pair is generated and appended to the blockchain.
Sellers can retrieve all processing transactions related to their 3) System Configuration
projects and confirm them through TC. Algorithm 1 and 2
As mentioned in Section II, the blockchain network in Hyper-
depict the workflow of purchase and confirm in detail. Algo-
ETS consists of several essential parts such as order, channel
rithm 1 shows the restrictions of trading projects. The status
and peer, etc. This system is scalable due to the adjustable
field must be ‘accepted’ and the ‘remain_emission_permits’
peer designing and deploying strategies. In HyperETS, we set
needs to be more than trading amount. Algorithm 2 indicates
up a typical network with an orderer node, one channel and
that when a transaction is settled, multiple fields in related
two organizations that represent the environmental agency
projects should be updated according to the trading amount
and trading center respectively. The ordering service adopts
and sellerâĂŹs option.
solo consensus protocol. Each organization includes a local
Algorithm 1 Purchase Fabric CA and a single peer. This single peer installs well-
designed SC and holds a distinct ledger which uses LevelDB
Input:
as the state database. As the only peer of the organization,
buyerId: UUID of buyer project;
it integrates both commitment and endorsement functions.
sellerId: UUID of seller project;
Thus, when an update proposal is sent to this peer, it can
amount: amount of trading emission permits;
endorse this transaction and then commit it to the ledger. The
Output:
channel in network is established to connect two organiza-
null;
tions and provide a mechanism for private communications
1: Generate composite key buyerKey and sellerKey by
and data sharing. In addition, all those system nodes (e.g.,
buyerId and sellerId; peer, order, CA) are implemented in the form of running
2: Get buyerP roject(bP ) and sellerP roject(sP ) by gen-
docker containers.
erated keys;
3: if bP.status = sP.status = 0 accepted0 then B. CLIENT APPLICATION & HTTP SERVER
4: if bP.remain and sP.remain >= amount then As shown in Fig.4, a web application is provided for users
5: generate new transaction with tsId to access the HyperETS service. The HTTP server connects
6: bP.status, sP.status ⇐ 0 trading 0 application with the background blockchain network. For
7: bP.processing, sP.processing ⇐ tsId applications, Express, 2 i.g., a minimal and flexible Node.js
8: end if web application framework is used to implement basic HTTP
9: end if
2 http://expressjs.com/

VOLUME 4, 2016 5

2169-3536 (c) 2018 IEEE. Translations and content mining are permitted for academic research only. Personal use is also permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2018.2888929, IEEE Access

P.YUAN et al.: HyperETS: A Permissioned Blockchain based Emission Trading SystemS

server functions and provide a series of RESTful APIs. For a low median response time at beginning until the arrival
blockchain network, the server needs to interact with several rate reaches about 300 RPS. Then, the throughput increases
parts via supported SDKs. Firstly, the server has to access slowly and the median response time rises rapidly before
the Fabric CA as a client in order to enroll the admin- it reach the saturation point at about 340 RPS. After the
istrator identity and set user context. Secondly, by using saturation point, higher arrival rates may cause the lower
APIs provided by Fabric SDK, the server is able to invoke throughput due to the server bottleneck.
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 Throughput
350
set by server previously can be used to sign all the requests Median of Response Time
10000
invoked by APIs. Furthermore, all the data retrieved from

Median of Response Time (ms)

300
ledger can be returned to applications in JSON format. Thus,

Throughput (RPS)
8000
the procedures of our HTTP server can be summarized as 250
follows, i.e.
6000
• Step 1: Using Fabric CA SDK to enroll the admin 200

identity. 4000
150
• Step 2: Starting the HTTP server to listen a specific port
and receive requests from applications. 2000
100
• Step 3: According to the diverse parameters of requests,
using Fabric SDK to invoke target SC to do some query 0
100 200 300 400 500 600 700
or update operations. Request Arrival Rate (RPS)
• Step 4: Returning data to applications in JSON format.
FIGURE 5: Throughput of Query Operation

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
FIGURE 4: Web UI for HyperETS 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.
IV. EXPERIMENTAL RESULTS AND ANALYSIS
The performance of HyperETS is evaluated by analyzing the TABLE 2: Experimental Parameters
system throughput of HTTP requests. A series of experiments
scriptsize
are performed on a aliyun cloud server with four Intel(R) Consensus Batch Message Block
Xeon(R) Platinum 8163 CPU @2.5GHz processors and 8 Number
Protocol Timeout (s) Count Size (KB)
GB RAM, running Ubuntu 16.04(64 bit). The throughput 1 Solo 2 1, 2, 5, 10, 20 512
2 Solo 2 30 8, 16, 32, 64
of HyperETS is evaluated by Requests Per Second (RPS),
the rate at which requests are completely processed. We use
Fig.6(a) plots the throughput curve over different message
Locust 3 , an open source load testing framework to evaluate
count. It indicates that with the increasing of message count
the system throughput over increasing request arrival rates.
in a single block, the stable point of system throughput
Two specific HTTP interfaces are chosen to execute query
increases rapidly at first. But when message count reaches
and create operations on peers, respectively.
5, the system throughput seems to reach a saturation point at
A. SYSTEM THROUGHPUT OF QUERY OPERATION
about 200 RPS. So we can draw the conclusion that before
message count reaches the critical point, the bottleneck of
Fig.5 shows the throughput and median response time of
our system is the ordering service. Fig.6(b) shows how block
query interface. It indicates that with the increasing of re-
size affects the system throughput. In general, the impact of
quests arrival rate, the throughput increases linearly with
block size on throughput is the same as message count. After
3 https://www.locust.io/ the block size exceeds 16k, continue to increase size can’t
6 VOLUME 4, 2016

2169-3536 (c) 2018 IEEE. Translations and content mining are permitted for academic research only. Personal use is also permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2018.2888929, IEEE Access

P.YUAN et al.: HyperETS: A Permissioned Blockchain based Emission Trading System

250 ACKNOWLEDGMENT
Message Count:1
This work was supported by the China Natural Science Fund-
Message Count:2
Message Count:5 ing under the grant 61671089, and BUPT Excellent Ph.D.
200
Message Count:10 Students Foundation under grant CX2016314.
Message Count:20
Throughput (RPS)

150 REFERENCES
[1] Wei Yan and Deshan Tang, “Incentives for environmental technological
innovation in emission trading,” 2011 International Conference on Remote
100
Sensing, Environment and Transportation Engineering, Nanjing, 2011, pp.
3206-3210.
[2] J. Huang et al., “An Experimental Study on Emission Trading Behaviors
50 of Generation Companies,” in IEEE Transactions on Power Systems, vol.
30, no. 2, pp. 1076-1083, March 2015.
[3] S. Imran and I. Hyder, “Security Issues in Databases,” 2009 Second Inter-
0 national Conference on Future Information Technology and Management
0 50 100 150 200 250 300 350 Engineering, Sanya, 2009, pp. 541-545.
Request Arrival Rate (RPS)
[4] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” White
(a) Impact of Message Count on Throughput Paper, 2008.
[5] YUAN Yong,WANG Fei-Yue. “Blockchain: The State of the Art and
Future Trends[J]”. Acta Automatica Sinica, 2016, 42(4): 481-494..
250
[6] Clack, Christopher & A. Bakshi, Vikram & Braine, Lee. (2016). “Smart
Block Size:8k
Contract Templates: essential requirements and design options.”
Block Size:16k
[7] S. Huh, S. Cho and S. Kim, “Managing IoT devices using blockchain plat-
200 Block Size:32k
form,” 2017 19th International Conference on Advanced Communication
Block Size:64k
Technology (ICACT), Bongpyeong, 2017, pp. 464-467.
[8] K. Christidis and M. Devetsikiotis, “Blockchains and Smart Contracts for
Throughput (RPS)

150 the Internet of Things,” in 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
100 Messaging Streams,” in IEEE Transactions on Dependable and Secure
Computing, vol. 15, no. 5, pp. 840-852, 1 Sept.-Oct. 2018.
[10] K. Zheng, L. Hou, H. Meng, Q. Zheng, N. Lu and L. Lei, “Soft-defined
heterogeneous vehicular network: architecture and challenges,” in IEEE
50
Network, vol. 30, no. 4, pp. 72-80, July-August 2016.
[11] K. Zheng, H. Meng, P. Chatzimisios, L. Lei and X. Shen, “An SMDP-
Based Resource Allocation in Vehicular Cloud Computing Systems,” in
0 IEEE Transactions on Industrial Electronics, vol. 62, no. 12, pp. 7920-
0 50 100 150 200 250 300 350
Request Arrival Rate (RPS) 7928, Dec. 2015.
[12] Z. Yang, K. Yang, L. Lei, K. Zheng and V. C. M. Leung, “Blockchain-
(b) Impact of Block Size on Throughput based Decentralized Trust Management in Vehicular Networks,” in IEEE
Internet of Things Journal.
FIGURE 6: Throughput of Create Operation [13] M. Raikwar, S. Mazumdar, S. Ruj, S. Sen Gupta, A. Chattopadhyay and K.
Lam, “A Blockchain Framework for Insurance Processes,” 2018 9th IFIP
International Conference on New Technologies, Mobility and Security
(NTMS), Paris, 2018, pp. 1-4.
[14] X. Liang, J. Zhao, S. Shetty, J. Liu and D. Li, “Integrating blockchain for
improve the performance anymore. Moreover, it can see that data sharing and collaboration in mobile healthcare applications,” 2017
the highest throughput of HyperETS is about 200 RPS. IEEE 28th Annual International Symposium on Personal, Indoor, and
Mobile Radio Communications (PIMRC), Montreal, QC, 2017, pp. 1-5.
[15] A. Azaria, A. Ekblaw, T. Vieira and A. Lippman, “MedRec: Using
V. CONCLUSION Blockchain for Medical Data Access and Permission Management,”2016
2nd International Conference on Open and Big Data (OBD), Vienna, 2016,
In this paper we have proposed HyperETS: a emission trad- pp. 25-30.
ing system based on permissioned blockchain to solve the de- [16] Wood, Gavin. “Ethereum: A secure decentralised generalised transaction
fects of existing centralized systems. We have presented the ledger.” Ethereum project yellow paper 151 (2014): 1-32.
[17] Cachin, Christian. “Architecture of the hyperledger blockchain fabric.”
design and implementation of this system in detail, especially Workshop on Distributed Cryptocurrencies and Consensus Ledgers. Vol.
the ledger and smart contract. Extensive experiments have 310. 2016.
been conducted to evaluate the system performance. Those [18] W. Tsai, X. Bai and L. Yu, “Design Issues in Permissioned Blockchains for
Trusted Computing,” 2017 IEEE Symposium on Service-Oriented System
experiments analyze the system throughput of HTTP requests Engineering (SOSE), San Francisco, CA, 2017, pp. 153-159.
with different type of operations and different parameters [19] Qassim Nasir, Ilham A. Qasse, Manar Abu Talib, and Ali Bou Nassif,
of configuration. The results indicate that the throughput of “Performance Analysis of Hyperledger Fabric Platforms,” Security and
Communication Networks, vol. 2018, Article ID 3976093, 14 pages, 2018
query operations can reach 340 RPS while create operations
[20] Elli Androulaki, Artem Barger, Vita Bortnikov, et al,. 2018. “Hyperledger
only reach around 200 RPS due to the underlying consensus fabric: a distributed operating system for permissioned blockchains.” In
mechanism. As for the configuration, setting the appropriate Proceedings of the Thirteenth EuroSys Conference (EuroSys ’18). ACM,
parameters for ordering service has a great influence on New York, NY, USA, Article 30, 15 pages.
[21] Thakkar, Parth, Senthil Nathan, and Balaji Vishwanathan. “Performance
system performance and the specific value depends on the Benchmarking and Optimizing Hyperledger Fabric Blockchain Platform.”
real business logic. arXiv preprint arXiv:1805.11390 (2018).

VOLUME 4, 2016 7

2169-3536 (c) 2018 IEEE. Translations and content mining are permitted for academic research only. Personal use is also permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2018.2888929, IEEE Access

P.YUAN et al.: HyperETS: A Permissioned Blockchain based Emission Trading SystemS

8 VOLUME 4, 2016

2169-3536 (c) 2018 IEEE. Translations and content mining are permitted for academic research only. Personal use is also permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.