Load balancing in decentralized smart grid trade system using blockchain

Abstract

This paper presents a distributed Load Balancing Trade Framework (LBTF) with focus on demand response and Advanced Metering Infrastructure (AMI) security in smart grid. This comprehensive energy market model LBTF framework can achieve good balance in demand response in two ways. First way is utility-grid contract, which introduced a simple reward policy using distributed proof-of-work (PoW) consensus algorithm in Blockchain to motivate consumer to use less energy in peak hours. Through this policy consensus algorithm reward electric units to the consumers in peak hours. And in second way scheme introduce Micro-grid contract, which is a peer to peer (P2P) trade in global market. Those consumer (prosumer) who can generate energy using renewable resources can sell their surplus energy to other consumer through this contract. Furthermore, hash functions, public key encryption and digital signatures have been used to provide privacy preserving to the consumers and integrity to the stored data.

Keywords

Blockchain smart grid demand response security framework

1 Introduction

Nowadays, demand of electric energy consumers has been increased because of huge increment in new electronic devices and machines such as smart phones, hybrid vehicles etc. This causes crucial impact on environment and unbalance in demand response. However, conventional framework architectures of smart grids are not efficient and reliable in balancing demand response [1]. Therefore, in order to ensure efficiency and reliability demand response management (DRM) is very important in smart grid, e.g managing energy consumption of consumers in peak hours. In advanced smart grids, two way communications between utility companies and consumers are enabled by distributed communication infrastructure (e.g smart meter, AMI (Advanced Metering Infrastructure) networks) and protocols will increase capability of DRM in whole system [2]. AMI is a key segment of smart grid and a smart meter is a basic component of AMI network. Most of the AMI architectures are based on centralized meter data management systems (MDMS) or remote terminal units (RTU) with centralized key distribution center (KDC), through which utility companies maintain their data. These centralized system perform all computation, and face issues such as single point of failure, security and privacy. Furthermore, smart grid is directly linked to people’s daily lives, to sort out security and privacy concern is essential [3 –5]. Ruj and Nayak in [5] proposed decentralized framework using homomorphic encryption for smart grid. Furthermore, they created a distributed KDC to provide security and keep the whole aggregated data safe, which makes key management complex and expensive. Later, in [6] A. Mohammadali et al. presented novel identity-based key establishment protocol (NIKE), which used ellipctic curves at its core. However, their main goal was to introduce light weight encryption for AMI system.

To overcome aforementioned issues, this paper presents a distributed load balancing trade framework architecture using consortium blockchain for trade in smart grid. Our first contribution in this article is that we perform demand response management in two methods. In the first method, we propose AMI system in the form of utility-grid contract. Utility-grid contract handles two way communication between utility companies and consumers. Furthermore, our consensus algorithm gives reward to consumers on the basis of simple policy using consensus algorithm in peak hours. The main purpose of giving reward to the consumers is to motivate them to use less energy in peak hours. In the second method, we propose micro-grid contract, in which P2P (peer to peer) trade is possible between prosumer and consumer in the global market. In this way, prosumer and consumer will participate in utility to balance the overall load. Second contribution is that we introduce a distributed and anonymous trade network which provides integrity to the stored data by using simple public key encryption, PoW consensus algorithm and digital signatures. There is no third body involved in this complete trade.

The rest of paper is organized as follows. We present related work in Section 2. In Section 3 we describe the basic concepts of blockchain, consensus algorithm, and proof of work. We present our smart grid load balancing trade framework in Section 4 and discuss block structure in Section 4.2, utility-grid contract procedure in Section 4.4.1 and micro-grid contract procedure in Section 4.4.2. Section 5 described discussion and security analysis on presented scheme. Section 6 concludes the paper.

2 Related work

There are many studies on DRM related to energy market in smart grids. In [1] the authors designed a Stackelberg game model, which allows utility companies to finds optimal electricity price, and consumers learn their optimal power consumption in a network. In [7] the authors categorized demand side management over time to improve the efficiency of grid. In [8] H. Pourbabak et al. created a distributed consensus algorithm in which they allowed coordination of local agents (consumer and distributed generators) to solve power mismatch issue. A. Pouttu et al. presented P2P trade in [9], for distributed energy sources. Furthermore, there are a few studies on smart grid using blockchain. In 2014, M. Mihaylov et al. presented a digital currency NRGcoin in [10] to perform energy trade. They made blockchain based network protocol on which they not only perform trade but also exchange NRGcoin into fiat currency through exchange market. In [11], the authors designed a machine to machine electricity market using blockchain. They presented a scenario where two energy providers show their bids and one consumer buy energy from one of them in blockchain network. E. Menegelkamp et al. [12] presented a case study about Brooklyn microgrid market, which is a local energy market implemented using blockchain in New York, USA by a private company. The aim of this project is to implement neighbor to neighbor sales of solar energies. Later, E. Menegelkamp et al. presented their own local energy market (LEM) in [13] using blockchain to utilize distributed renewable energy sources. Their main focus was to design a trade system in which consumers and prosumer can do trade locally.

However, our approach is to present the first framework using blockchain, which gives incentives to consumers to balance demand response utility. Furthermore, prosumer can do trade with consumer using P2P network in the global market instead of local one.

3 Background

3.1 Blockchain

Blockchain is a digital public ledger that was first introduced in 2009 by Nakamoto Satoshi [14]. It was first used as a public ledger in Bitcoin, which is a digital currency. In blockcahin, a block is used to securely store data in the form of transactions. A block in Bitcoin consists of header and body. A block header includes block version, merkle tree root hash, timestamp, nonce and previous block hash. A block body consists of transactions. Blockchain is basically a chain of block. Chaining is done by adding the hash of previous block to the current block. A hash value is used to authenticate data. Different consensus algorithms (Proof of work, Proof of Stake (PoS), etc.) are used to provide integrity to the data. Blockcahain relies on two cryptographic methods, that is, digital signatures and cryptographic hash function. There are three kinds of blockchains: public, consortium and private blockchains, explained as follows [15]:

3.1.1 Public blockchain

It is a blockhain where each node could take part in the consensus algorithm process, and all stored information is public in this blockchain.

3.1.2 Consortium blockchain

It is a blockchain where pre-selected number of nodes could participate in the consensus process. Data stored could be public or restricted, depending on application.

3.1.3 Private blockchain

It is a blockchain where one organization holds control of nodes, and only those organization node could participate in the consensus process. It is regarded as centralized network since it’s controlled by one organization [16].

The presented scheme in this paper uses consortium blockchain, where we define a set of selected distributed nodes. Stored data by these nodes could be public or restricted, but in our case data is public. The node who solves the puzzle first will make the block, but once a node finds the hash, the block cannot be changed without redoing all processes again. Sometimes fork condition occurs, which means two nodes calculate hash almost at same time. To solve this fork issue, the longest chain path concept is proposed. In longest chain path, for example forking occurs between two nodes A and B, some full nodes validate A’s block and start mining next block. And some full nodes will validate A’s block and start mining next block on it. And some other full nodes will mine on validated B’s block. Now, if the next block appears mined on A’s block, the consensus algorithm will consider A’s block valid as it has a longer chain path than the chain based on B’s block. Therefore B have to make its PoW computation again to make its block valid.

3.2 Proof of Work (PoW)

Consensus algorithm used in this article is proof of work, which is the same as in Bitcoin. PoW basically is a puzzle game, which is expensive to solve, although all input values are known. In PoW, a target value t is given to generate a block. A node gathers a number of transactions, chooses a random value called nonce, and iteratively calculates the hash value of this data set using the SHA 256 hash function along with other data. In each iteration, a nonce is changed and a hash function produces a number as a result. This process is repeated until it results in a hash value that is less than or equal to target value. The target basically is a 256 bit number with k significant digits of zeros, which construct the difficulty of this puzzle game. This process normally takes on average ten minutes and 2^k attempts to solve this puzzle [14 –17]. The probability of finding nonce of proof H for a given target t is: % $P (H \leq t) = t / 2^{256}$

4 Proposed Load Balancing Trade Framework (LBTF)

The proposed LBTF framework is explained in this section. LBTF framework not only makes demand response balance possible, but also provides a secure distributed AMI for utility billing services. In this LBTF network, every consumer and prosumer can take electricity utility connection with available companies. Furthermore, if any consumer also has renewable energy resources to generate energy, then he can join as a prosumer and sell his surplus energy in P2P network. Blockchain is the main component of this framework, through which this framework maintains all the record of consumed energy in electric units (1 unit = 1 kilowatt hour (kWh)) in a secure distributed network manner. This framework provides integrity to data by using the proof of work consensus algorithm by Bitcoin. The rewarding rule of the consensus algorithm, however, is different from Bitcoin, which is explained in Section 4.3. Basically in Bitcoin, the node which makes PoW computation will get the reward, but in LBTF, reward will be given to consumers or prosumers instead of the full node(miner). Notations used in this paper have been explained in Table 1.

Table 1
Notations

Notation Description

B A set of blockchain nodes

C A set of consumer nodes

P A set of prosumer nodes

F A set of full nodes

UC A set of utility companies nodes

t Target value for PoW

H Output of hash function in PoW

T Threshold for reward policy

ID _{c
_i} Identity of a consumer node

ID _{p
_i} Identity of a prosumer node

ID _{uc
_i} Identity of a utility company node

ID _{f
_i} Identity of a full node

PK _{c
_i} Public key of a consumer node

PK _{p
_i} Public key of a prosumer node

PK _{uc
_i} Public key of a utility node

PK _{f
_i} Public key of a full node

SK _{c
_i} Private key of a consumer node

SK _{p
_i} Private key of a prosumer node

SK _{uc
_i} Private key of a utility node

SK _{f
_i} Private key of a full node

Sig _{c
_i} Signature of a consumer

Sig _{p
_i} Signature of a prosumer

Sig _{uc
_i} Signature of a utility

D _{c
_i} Aggregated consumer meter data

D _{p
_i} Aggregated prosumer meter data

D _{f
_i} Aggregated full node data

m _{c
_i} Consumer charged money by utility

m _{p
_i} Prosumer charged money by utility

% $m_{c_{i}}^{'}$ Paid money to utility by consumer

Addr _{uc
_i} Utility’s account information to receive payment of a utility company

Addr _{c
_i} Consumer’s account information to send payment of a consumer

Addr _{p
_i} Prosumer’s account information to send/receive payment of a prosumer

g _rp Retail price in global table

g _sp Sales price in local table

% $g_{rp}^{'}$ Paid money to prosumer by consumer according to global table rate

% $g_{sp}^{'}$ Paid money to prosumer by consumer according to local table rate

c _d Extra charges according to distance

Notation	Description
B	A set of blockchain nodes
C	A set of consumer nodes
P	A set of prosumer nodes
F	A set of full nodes
UC	A set of utility companies nodes
t	Target value for PoW
H	Output of hash function in PoW
T	Threshold for reward policy
ID _{c _i}	Identity of a consumer node
ID _{p _i}	Identity of a prosumer node
ID _{uc _i}	Identity of a utility company node
ID _{f _i}	Identity of a full node
PK _{c _i}	Public key of a consumer node
PK _{p _i}	Public key of a prosumer node
PK _{uc _i}	Public key of a utility node
PK _{f _i}	Public key of a full node
SK _{c _i}	Private key of a consumer node
SK _{p _i}	Private key of a prosumer node
SK _{uc _i}	Private key of a utility node
SK _{f _i}	Private key of a full node
Sig _{c _i}	Signature of a consumer
Sig _{p _i}	Signature of a prosumer
Sig _{uc _i}	Signature of a utility
D _{c _i}	Aggregated consumer meter data
D _{p _i}	Aggregated prosumer meter data
D _{f _i}	Aggregated full node data
m _{c _i}	Consumer charged money by utility
m _{p _i}	Prosumer charged money by utility
% $m_{c_{i}}^{'}$	Paid money to utility by consumer
Addr _{uc _i}	Utility’s account information to receive payment of a utility company
Addr _{c _i}	Consumer’s account information to send payment of a consumer
Addr _{p _i}	Prosumer’s account information to send/receive payment of a prosumer
g _rp	Retail price in global table
g _sp	Sales price in local table
% $g_{rp}^{'}$	Paid money to prosumer by consumer according to global table rate
% $g_{sp}^{'}$	Paid money to prosumer by consumer according to local table rate
c _d	Extra charges according to distance

4.1 Overview

In this section, an overview of the proposed framework is given. A complete architecture of LBTF network is shown in Fig. 1. The following entities will make the transactions and blocks in this framework:

Fig.1

Load Balancing Trade Framework (LBTF) Architecture.

Blockchain Node: It is a node in blockchain network. A set of blockchain nodes is denoted as B = {b₁, b₂,…., b_n}.

Consumer Node: A consumer node is a smart meter of a consumer. Every meter sends aggregate data to a full node after every 24 hours. A set of consumer nodes is denoted as C = {c₁, c₂,…., c_n}, c_i ∈ C, and C ⊂ B.

Prosumer Node: A consumer which not only consumes energy but sells is called a prosumer. This is a node which sends aggregated data of consumed energy to a utility company. Furthermore, it can make a contract to sell self-produced surplus energy in the P2P network. A set of prosumer nodes is denoted as P = {p₁, p₂,…., p_n}, p_i ∈ P, and P ⊂ B. Each prosumer defines the surplus energy and its corresponding bid price (retail price) in the energy market by making sales requests.

Utility Company: A utility company node is an outside node of a blockchain network, which makes utility bill transactions for their respective consumers or prosumers. A set of utility company nodes is defined as UC = {uc₁, uc₂,…., uc_n}.

Full Node: A node which maintains all transaction in the form of blocks is called a full node. A full node also generates rewards for every consumer who consumed less energy than the predefined threshold. A set of full nodes is denoted as F = {f₁, f₂,…., f_n}, F ⊂ B. The public keys of full nodes are available to all other nodes. A full node attaches its signature to blocks whenever making them public.

There are two kinds of contracts in this LBTF framework. One of them is utility-grid contract, where consumer and prosumer take electricity from a utility company and do monthly payment. This contract is to handle all information of AMI for utility companies. The second contract is micro-grid contract, where a consumer buys energy from a prosumer. The framework maintaining both contracts communication, as shown in Fig. 2 in the form of transaction flows. Consumers, prosumers and utility companies use public key encryption (that is, asymmetric encryption scheme) to communicate with full nodes. Furthermore, to vindicate transaction authentication, this framework uses digital signature.

Fig.2

Transactions Flow Chart.

As we can see on the right side of Fig. 2 after making a utility-grid contract with the relevant utility company, smart meters of consumers or prosumers send aggregated data to blockchain full nodes after a specific time period with the identity of the utility company which they registered in. Full nodes further aggregate data (for one month) and generates the corresponding reward. Every month, the utility company generates utility bills for consumers and prosumers after receiving the monthly aggregated data from the full nodes, which later paid by consumers and prosumers.

Left side of Fig. 2 shows the flow of micro-grid contract transaction, where we use a simple live auction bidding method for P2P trade. A full node in this LBTF network maintains two different bidding tables as depicted in Fig. 1: global and local tables. Every prosumer makes an offer of sales bids (retail price) g_rp request in the energy market. The full node maintains these retail prices in its global table. In the local table, the full node maintains sales price g_sp. In order to calculate the sales price, it takes retail price, add some extra amount c_d (connection infrastructure cost, cost of power lost due to the long distance of prosumer from the full node, etc.) g_sp = g_rp + c_d to it. The full node will charge the consumer the final sales price.

4.2 Proposed block structure

The proposed LBTF framework has a different block structure as compared to the blockchain of Bitcoin. For example, in Bitcoin, a block body contains reward transaction only for miner which is predefined number of Bitcoin (BC) per block which is 12.5 BC/block nowadays, but in LBTF, a block reward will be given to consumer and prosumer nodes instead of full node (miner). It can be given to more than one consumer or prosumer node in LBTF, therefore the reward transaction is totally different than Bitcoin. In LBTF, a block consists of block header and body. A block header consists of the block size, previous block hash, a random nonce and Merkle root. A block body consists of transactions and reward information.

Fig.3

Block Structure.

Merkle root computed through Merkle tree using hashes of all transactions is as shown in Fig. 3. Consumer, prosumer and utility company can make four kinds of transactions (that is, data store, utililty bill, utility payment and bids matched transactions) in a block in the LBTF framework. All transaction execution procedures are explained in Sections 4.4.1 and 4.4.2. The structure of the transaction is explained as follows:

4.2.1 Data store transaction

This transaction is generated by a consumer or a prosumer after joining the utility-grid contract in LBTF system. The structure of this transaction is shown in Fig. 3. It consists of identity of consumer/prosumer ID_{c
_i}/ID_{p
_i}, hash value of transaction, aggregated data of smart meter D_{c
_i}/D_{p
_i}, identity of the utility company ID_{uc
_i} and lastly signature of the consumer or prosumer Sig_{c
_i}/Sig_{p
_i} who performing this transaction.

4.2.2 Utililty bill transaction

This transaction is generated by a utility company for consumers and prosumers. This transaction consists of identity of the utility company ID_{uc
_i}, hash value of the transaction, money m_{c
_i}/m_{p
_i} according to the consumed electric units and last date to pay, identity of the consumer or prosumer and signature of the utility company Sig_{uc
_i} as shown on the right side of Fig. 3. Further element can be added as needed to this transaction according to underlying rules and regulation, because here we present a very simple scenario to explain the transaction.

4.2.3 Utility payment transaction

This transaction is generated mutually by the consumer or prosumer and the utility company to pay the monthly charges of the consumed energy. This transaction consists of identity of the consumer or prosumer ID_{c
_i}/ID_{p
_i}, hash value of transaction, paid money by the consumer or prosumer % $m_{c_{i}}^{'}$ / % $m_{p_{i}}^{'}$ , identity of the company ID_{uc
_i} and lastly signature made by both the consumer or prosumer Sig_{c
_i}/Sig_{p
_i} and the utility company Sig_{uc
_i}.

4.2.4 Bids matched transaction

This transaction occurs in a micro-grid contract, which is initiated by a consumer when finds the best price to buy energy. After paying the payment to his chosen prosumer, energy will be provided from the nearest grid station. This transaction consists of identity of the consumer ID_{c
_i}, paid money for a specific amount of energy(kWh) % $g_{rp}^{'}$ / % $g_{sp}^{'}$ and identity of the selling prosumer ID_{p
_i} and signature made by both the consumer Sig_{c
_i} and prosumer Sig_{c
_i} as shown in Fig. 3.

4.3 Reward Policy for consumers

The blockchain used in this framework is a consortium-type blockchain. All full nodes are private and work under the predefined rules through consensus algorithm. In this LBTF network, no full node will get reward, but they just take transactions fees. However, these full nodes provide reward to consumers or prosumers on the basis of a simple policy to motivate them to use less energy in peaks hours. The following scheme defines a reward policy:

In this framework, utility companies define a their own certain threshold value in electric units T, on which demand response will remain stable in peak hours.

If any consumer or prosumer consumes electric units less than the threshold T in peaks hours, then the involved utility company will reward certain percentage (this percentage will be defined by the utility company) of total consumed (in peak hours) units to the node.

In every block, consensus algorithm adjusts rewarded units according to the policy in every smart meter transaction. All those consumers or prosumers get their rewards. Their identities and rewarded units will be mentioned in the transaction as shown in Fig. 3.

4.4 Procedure

In this section, flows of transactions are explained in the case of both contracts. All consumer and prosumer make utility-grid contract with his own chosen utility company. Moreover, all consumer, prosumer and utility company will get their public and private keys when they join the LBFT network. These three entities use digital signature to validate the authenticity of a transaction. Procedures of both contracts are explained as follows:

4.4.1 Utility-grid contract transaction procedure

In this section, a procedure of transactions for the utility-grid contract case is explained as shown in Fig. 4:

A consumer node starts sending smart meter data by making store_data request. This consumer node encrypts the data using public key encryption. This encrypted message includes public key of the consumer PK_{c
_i}, identity of the consumer ID_{c
_i}, aggregated data D_{c
_i} and identity of the utility company ID_{uc
_i}, where the consumer node is registered, and the consumer node’s digital signature Sig_{c
_i}.

When a full node f_i receives the store_data request, it decrypts the message with SK_{f
_i}, and generates a random and unique hash value and check the reward for peak hours. If any consumer consumed less energy than the threshold, the full node will make reward transaction and adjust rewarded units in the same block. Rewarded amount of units will be a predefined percentage (by the utility company) of the total consumed units in peak hours. Let’s suppose that the threshold is T = 10 units for two peak hours, the percentage is 5% and a consumer c_i consumed 5 units = 5 kWh in these two peak hours in the second transaction of Fig. 4. Therefore, the consumer consumed 5 units < 10 units, and the reward will be % $\frac{5 \times 5}{100} = 0.25 units$ .

The consumer c_i sends the smart meter data for one month by making store_data request after every 24 hours and the full node will maintain each data in the transaction. After a specific duration (e.g one month), the utility company will request the one month aggregated data of consumer to the full node f_i. This request req_aggregated_data encrypted message using the public key of the utility company PK_{uc
_i} includes identity of the utility company ID_{uc
_i}, and identity of the consumer ID_{c
_i} whose data is required.

When a full node f_i receives the message after decryption, it then calculates one month aggregated data including rewards of aforementioned consumer c_i.

The full node f_i then responds by sending encrypted message res_aggregated_data using the public key of the utility company PK_{uc
_i}, which includes public key of the full node PK_{f
_i}, identity of the full node ID_{f
_i} and aggregated data D_{f
_{c
_i}} of the consumer c_i calculated by the full node f_i.

After receiving a response from the full node f_i, the utility company node decrypts the response. According to the aggregated data, the utility company calculates a utility bill. Then the utility node sends the encrypted message utility_bill to the full node including public key of the utility company PK_{uc
_i}, identity of the utility company, account information of the utility company addr_{uc
_i}, charged money m_{c
_i} for the consumed energy with submission date and digital signature Sig_{uc
_i} of the utility company for authenticity of the transaction.

After decryption of the received message, the full node f_i will generate a hash value and maintain this information in the form of transaction and sends the encrypted message req_payment to the consumer c_i, including public key of the full node PK_{f
_i}, identity of the full node, account information of the utility company addr_{uc
_i}, charged money m_{c
_i} for consumed energy with submission date.

When the consumer c_i receives the payment request, he will pay the utility bill on the received account information of the utility company and send res_payment to the full node including public key of the consumer PK_{c
_i}, paid payment information like addr_{c
_i} and paid money % $m_{c}^{'}$ , and attached digital signature for the authenticity of the transaction.

The full node f_i forwards paid money information to the utility company by sending the encrypted message req_verify which includes both public key of the full node PK_{f
_i}, identity of the full node ID_{f
_i}.

After receiving a message from the full node, the utility company verifies the payment and responds back to the full node by attaching the company’s digital signature.

After receiving the verification response from the utility company, the full node will generate a random hash value and maintain the payment information, identities and signatures of the consumer and the utility company in the transaction.

The procedure of prosumer p_i transactions is the same as the consumer c_i transactions in utility-grid contract transactions.

Fig.4

Utility-grid Contract Transaction Process.

4.4.2 Micro-grid contract transaction procedure

In this section, a procedure of transactions for the micro-grid contract case is explained as shown in Fig. 5. Micro-grid contract is basically a peer-to-peer trade concept. In this contract, first all prosumers make their sales request in the electric market with their retail price g_rp. All full nodes maintain two tables on the basis of this retail price. The first table is a global table, where full nodes maintain retail prices, and the second table is a local table. Every full node calculates each prosomer’s sales price g_sp = g_rp + c_d as mentioned in Section 4.1, which is defined according to the distance between the prosumer from to the specific full node. The consumer on the same full node f_i to which prosumer is connected takes energy on the basis of retail price g_rp. However, the consumer who connected with another full node f_j will buy according to the local table price g_sp (in which extra charged amount c_d included according to prosumer distance from that full node f_j).

Fig.5

Micro-grid Contract Transaction Process.

First of all, a consumer c_i checks the prices of available energy, then selects the prosumer according to his demand and price according to the global or local tables.

After selecting the prosumer, the consumer c_i sends the encrypted message req_buy to the prosumer including PK_{c
_i}, identity of consumer ID_{c
_i} with energy E_{c
_i} and price g_sp or g_rp depending on his location.

When a prosumer receives the buy request from the consumer, the prosumer node will decrypt and inform the nearest full node of the consumer f_i about the buy request by sending the encrypted message rcv_buy_req including PK_{p
_i}, identity of prosumer ID_{p
_i}, and account information addr_{p
_i} and consumer request.

When the full node f_i receives message from the prosumer, it will check the validity of energy from other full nodes to avoid double spending of energy. After receiving responses from all full nodes, the full node f_i sends the request req_payment to the consumer for the payment by forwarding the prosumer node’s account information.

Upon receiving payment request from the full node, the consumer node will make the payment and send res_payment by including PK_{c
_i}, identity of consumer ID_{c
_i}, information of his account information addr_{c
_i}, paid price % $g_{sp}^{'}$ or % $g_{rp}^{'}$ and lastly digital signature.

The full node forwards this response to the prosumer to verify the payment by making the request req_verify as shown in Fig. 5.

The prosumer node decrypts the verification request and verifies it by making the respond request back to the full node f_i by attaching his signature.

When the full node f_i receives verification, it will generate a random and unique hash value and make a transaction. After this, the full node distributes the transaction to other node and then update both the global and local tables according to the transaction.

5 Discussion and security analysis

First time in the field of smart grids, this article provide LBTF structure which balance the demand response through AMI and P2P energy trade in distributed manner using consensus algorithm and consortium blockchain. In proposed scheme a private full node which maintain all the data in form of transactions, this node controlled all data aggregation and communication.

In privacy and security point of view, this blockchain based LBTF network provides privacy preserving to the users using anonymous hash identities in both contracts. However, previously to perform aggregation with privacy preserving on data, AMI have been used cryptographic schemes which requires high number of computations such as homomorphic encryption. These high number of computations based cryptographic sachems are not suitable for AMI protocol, because it contain some devices which are resources constraint such as smart meter. In LBTF, PoW provides integrity to the smart grid data with the help of hashes, Merkle tree and digital signatures. Additionally, blockchain is an software based distributed data storage network, which controlled by software based predefined rules. Therefore, in LBTF network no third body involved in all communication and storage process. However, in conventional AMI protocols such as distributed server or centralized server third party involved (utility company management or server management etc) and have all control of data. Lastly, no single point of failure issue in LBTF network, because it is distributed in nature as mentioned in Table 2.

Table 2
Comparison of Blockchain based trade over other systems

Smart Grid System Using

Pros and Cons Blockchain System Distributed Server Centralized Server

Single Point of Failure No No Yes

Peer-to-Peer Trade Yes No No

Privacy Preserving Yes Yes Yes

Trust on Third Party No Yes Yes

Aggregation Yes Yes Yes

	Smart Grid System Using
Single Point of Failure	No	No	Yes
Peer-to-Peer Trade	Yes	No	No
Privacy Preserving	Yes	Yes	Yes
Trust on Third Party	No	Yes	Yes
Aggregation	Yes	Yes	Yes

6 Conclusion

This paper presents a proof-of-work consensus algorithm based on the LBTF network with a simple reward policy between utility and consumer’s and P2P trade between consumers and prosumers. This article evaluate the distributed economic market design LBTF using consortium blockchain, in which scheme balance the demand and response through utility and local market trade.

The architecture and detailed contract procedure of the proposed scheme have been illustrated. This scheme have some limitation, PoW consume energy for computation and set of full nodes are private. We infer that the real-life applicability and technological limitations of such blockchain-based market methods need to be resolved by further research.

Footnotes

Acknowledgments

This work was supported by the National Research Foundation of Korea (NRF) grant funded by the Korea government (MSIP) (No. 2017R1A2B4001801).

References

Maharjan

, Zhu

, Zhang

, Gjessing

and Basar

, Dependable demand response management in the smart grid: A stackelberg game approach, IEEE Trans Smart Grid4(1) (2013) 120–132.

Fan

, A distributed demand response algorithm and its application to phev charging in smart grids, IEEE Trans Smart Grid3(3) (2012) 1280–1290.

Ullah

, Faheem

and Kim

B.S.

, Energy and congestion-aware routing metric for smart grid AMI networks in smart city, IEEE Access5 (2017) 13799–13810.

, Liang

, Lu

, Lin

, Yang

and Shen

, EPPDR: An efficient privacy-preserving demand response scheme with adaptive key evolution in smart grid, IEEE Transactions on Parallel and Distributed SystemsPP(99) (2013) 1–10.

Ruj

and Nayak

, A decentralized security framework for data aggregation and access control in smart grids, IEEE Trans Smart Grid4(1) (2013) 196–205.

Mohammadali

, Haghighi

M.S.

, Tadayon

M.H.

and Nodooshan

A.M.

, A novel identity-based key establishment method for advanced metering infrastructure in smart grid, IEEE Transactions on Smart Grid (2016).

Palensky

and Dietrich

, Demand side management: Demand response, Intelligent Energy Systems, and Smart Loads, IEEE Tran on Industrial Informatics7 (2011) 381–388.

Pourbabak

, Luo

, Chen

and Su

, A novel consensusbased distributed algorithm for economic dispatch based on local estimation of power mismatch, IEEE Trans Smart Grid (2017). doi: 10.1109/TSG.2017.2699084.

Pouttu

., P2P model for distributed energy trading, grid control and ICT for local smart grids, IEEE Networks and Communications (EuCNC), 2017 European Conference. 2017.

10.

Mihaylov

, Jurado

, Avellana

, Van Moffaert

de Abril

I.M.

and Nowe

, Nrgcoin: Virtual currency for trading of renewable energy in smart grids, 11th International Conference on the European Energy Market(EEM), IEEE, 2014. pp. 1–6.

11.

Sikorski

J.J.

, Haughton

and Kraft

, Blockchain technology in the chemical industry: Machine-to-machine electricity market, Applied Energy195 (2017) 234–246.

12.

Mengelkamp

., Designing microgrid energy markets: A case study: The Brooklyn Microgrid, Applied Energy210 (2017) 870–880.

13.

Mengelkamp

, Notheisen

, Beer

, Dauer

and Weinhardt

, A blockchain-based smart grid: Towards sustainable local energy markets, Computer Science - Research and Development (2017), 1–8. doi: 10.1007/s00450-017-0360-9.

14.

Nakamoto

, Bilcoin: A peer-to-peer electronic cash system, 2008. https://bitcoin.org/bitcoin.pdf. Accessed 9 May 2017.

15.

Zheng

, Xie

, Dai

, Chen

and Wang

, An overview of blockchain technology: Architecture, consensus, and future trends, IEEE International Congress on Big Data (Big-Data Congress), 2017, pp. 557–564.

16.

Sankar

L.S.

, Sindhu

and Sethumadhavan

, Survey of consensus protocols on blockchain applications, in Advanced Computing and Communication Systems (ICACCS), 20174th International Conference, IEEE, 2017, pp. 1–5.

17.

Aitzhan

N.Z.

and Svetinovic

, Security and privacy in decentralized energy trading through multi-signatures, blockchain and anonymous messaging streams, IEEE Trans Depend Sec ComputPP(99) (2016).

	Smart Grid System Using
Pros and Cons	Blockchain System	Distributed Server	Centralized Server
Single Point of Failure	No	No	Yes
Peer-to-Peer Trade	Yes	No	No
Privacy Preserving	Yes	Yes	Yes
Trust on Third Party	No	Yes	Yes
Aggregation	Yes	Yes	Yes