Design and implementation on Hyperledger-based Emission Trading System

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_{Intelligent Computing 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 ([email protected])

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 mitigattrad-ing 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

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.

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 systems. With the customized ledger structures and access controlled smart contract, HyperETS provides polluters with a more credible and secure service for emission trading. Authorized polluters can submit trading applications and trade emission permits at different organizations through a web application. All transactions created by polluters are stored as blocks in the blockchain, which persist in an immutable and append-only way. In addition, specific con-sensus protocol is developed to make sure that all trusted organizations maintain the same ledger in a distributed way, which enhances the convenience of data sharing between several organizations. HyperETS is developed based on Hyperledger Fabric v1.1 and its performances are evaluated by examining the system throughput under different kinds of operations and system configurations.

The rest of this paper is organized as follows. Section II introduces the application scenario and the overall archi-tecture of HyperETS. Then, we present the design and implementation of the system in detail in Section III. Next, performance evaluation in term of system throughput is given in Section IV. Finally, we conclude this paper in Section V.

II. SYSTEM OVERVIEW

A. APPLICATION SCENARIO

The application scenario of the proposed emission trading system is illustrated in Fig.1. Four entities are included as follows, i.e.,

1) Trader. Users who want to trade emission

per-mits. Before acquiring the privilege to trade emis-sion permits, traders have to submit corporation and project applications. The details of the process will be described later.

2) Approver.Users who have the privilege to accept or

reject a corporation/project application according to the relevant policies. For example, such role can be

FIGURE 1. Application scenario.

taken by the staff of the environmental agency. Only approved projects have the rights to trade emission permits.

3) Environmental Agency. This organization provides

service for both traders and approvers. Registered traders can submit corporation/project applications and obtain the status of all applications here, while approvers can accept or reject processing applications and retrieve the signing records through this organiza-tion.

4) Trading Center. Only registered traders can access

the service provided by this organization. They can check the status of projects that accepted by approvers. Buyers can view all selling emission permits and ini-tiate a transaction, while sellers can check the trans-actions of their projects and decide to accept or reject these transactions. To complete a emission trading process, these entities should follow the steps shown in Fig.1.

• Step 1: The registered trader has to submit a cor-poration application which contains a list of neces-sary materials (e.g., corporate certificate) at envi-ronmental agency.

• Step 2: The approver of environmental agency

checks the validity of these materials.

• Step 3: Once the application is accepted by the

approver, the trader can submit a project applica-tion based on this permitted corporaapplica-tion identity. Project application includes details of emission trading (e.g., type of project: buy/sell, amount of trading emission permits).

• Step 4: The approver checks the validity of project application.

• Step 5: If the project is accepted by approver, it can be seen in trading center.

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.

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) LEDGER DESIGN

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 appliappli-cation 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.

TABLE 1.Design of states. (a) Corporation application. (b) Project. (c) Transaction.

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

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 applicacorpora-tion 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 1Purchase

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 buyerIdandsellerId;

2: GetbuyerProject(bP) andsellerProject(sP) by generated keys;

3: ifbP.status=sP.status=0_accepted0then 4: ifbP.remainandsP.remain>=amountthen 5: generate newtransactionwithtsId

6: bP.status,sP.status⇐0trading0

7: bP.processing,sP.processing⇐tsId

8: end if

9: end if

Algorithm 2Confirm

Input:

transactionId(tsId): UUID of transaction; option: accept or reject this transaction;

Output:

null;

1: Generate composite keytransactionKeybytsId;

2: Gettransaction(ts) bytransactionKey;

3: Get buyerProject(bP) and sellerProject(sP) by ts.buyerIdandts.sellerId;

4: ifoption=0accept0then 5: ts.status⇐0_accepted0

6: bP.remain⇐bP.remain−ts.amount

7: sP.remain⇐sP.remain−ts.amount

8: ifbP.remain=0then 9: bP.status⇐0done0

10: end if

11: ifsP.remain=0then 12: sP.status⇐0done0

13: end if

14: else

15: ts.status⇐0rejected0

16: end if

17: bP.processing,sP.processing⇐null;

18: bP.complete,sP.completeaddtsId

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,2i.g., a minimal and flexible Node.js web application framework is used to implement basic HTTP

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,3an 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/}

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.

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,’’ inProc. Int. Conf. Remote Sens., Environ. Transp. Eng., Nanjing, China, 2011, pp. 3206–3210.

[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,’’ inProc. 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,’’ inProc. 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

XIONG XIONG received the B.S. degree from the Beijing University of Posts and Telecommu-nications, China, in 2013, where he is currently pursuing the Ph.D. degree. His research interests include radio resource management and security in the Internet of Things networks.

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.