Blockchain-Enabled Transactive Home Energy Management Systems in Distribution Networks

As home energy management systems (HEMSs) are implemented in homes as ways of reducing customer costs and providing demand response (DR) to the electric utility, homeowner's privacy can be compromised. As part of the HEMS framework, homeowners are required to send load forecasts to the distribution system operator (DSO) for power balancing purposes. Submitting forecasts allows a platform for attackers to gain knowledge on user patterns based on the load information provided. The attacker could, for example, enter the home to steal valuable possessions when the homeowner is away. In this paper, we propose a framework using a smart contract within a private blockchain to keep customer information private when communicating with the DSO. The results show the HEMS users' privacy is maintained, while the benefits of data sharing are obtained. Blockchain and its associated smart contracts may be a viable solution to security concerns in DR applications where load forecasts are sent to a DSO.


I. INTRODUCTION
Energy consumption in commercial and residential buildings accounts for more than 70% of electricity usage, profoundly impacting the power grid's operation.Approximately 100 million single-family homes in the United States account for 36% of the electricity load, and often they determine the peak system load, especially on hot summer days when residential air-conditioning use is high [17].Futuristic smart cities equipped with smart home energy management systems (HEMSs) have the auspicious potential to play a pivotal role in reducing global energy consumption while maintaining economic, reliable, and secure power grid operations.A HEMS is a smart home automatic control system that can optimally control residential appliances to serve multiple objectives (e.g., electricity cost minimization, peak load minimization) of residential customers while maintaining the customer's thermal comfort in the presence of uncertain weather and electricity consumption [1,18,19].From the perspective of the utility, widely distributed HEMSs in residential areas can serve as demand response (DR) providers, which shift the load to non-peak hours and minimize voltage violations and line congestions [1,2].From the perspective of homeowners, HEMSs are developed to optimize forward-looking schedules for a residential home's appliances, such as heating, ventilation, and air-conditioning (HVAC), refrigerator, water heater (WH), rooftop solar, energy storage (ES), lighting, and electric vehicle (EV).Although HEMS devices reduce customer electricity costs, cyber-attacks, and privacy concerns may lead to reduced customer engagement in DR programs [20].
The realization of HEMS requires wireless communication via Zigbee or Wi-Fi, which can be hacked, eavesdropped, and compromised, providing intruders additional ways to invade homeowners' privacy.In transactive distribution systems with a high penetration of HEMSs [17], homeowners are required to submit load forecasts and potentially price bids to the distribution system operator (DSO) for power balancing purposes [3].The electricity consumption data are sensitive information that can infer a user's habits and lifestyle [4,5].The privacy leak and potential misuse of user-provided data could cause loss of a homeowner's physical property and additional susceptibility to cyber-attack.The submitted load forecast provides an attack surface for malicious intruders to predict whether a HEMS user is home or not.Furthermore, a long-term eavesdrop will increase the chances of a correct prediction, which makes HEMS users vulnerable to a sneaky burglar.Therefore, we propose using a smart contract within a private blockchain to keep customer's information private.Blockchains are distributed ledgers that are tamper-evident and tamper-resistant [6,7].Transactional data are saved to the blockchain in an evergrowing record list, called blocks.Each block also contains a timestamp and a hash related to the previous block.A blockchain-based smart contract refers to the code that is automatically executed when specific actions occur in the blockchain [7].Fig. 1 depicts how the blockchain will be used to provide secure data transfer between residential homes and the DSO.
As HEMS research is so new, an investigation into the data security is rarely found in the literature.Authors in [8] indicate the importance of data security within HEMS, but do not address solutions for the issue.The advantage blockchain has over other security methods is that it does not need a trusted third party.Authors in [9,10], to name a few, propose the use of blockchain to preserve the privacy of homeowners when aggregating real-time, smart meter data, but do not extend their model to a HEMS case.However, forecasted data is potentially more important to protect rather than realtime data, as one can use the forecasted data to predict future user behavior better.Researchers in [14] investigate blockchain for use in smart homes in the context of Internet of Things (IoT) within the home.To the best of our knowledge, security practices for day-ahead or hour-ahead forecasted load data in a HEMS framework have not been investigated.
The goal of this paper is to provide a framework for applying blockchain to HEMSs for secure data transfer with the DSO.Through the use of smart contracts, we intend to ensure privacy for homeowners when participating in demand response activities, and therefore encourage user participation in DR activities.In the first stage, we use a smart contract to keep the homeowner's identity private when sending future demand forecasts to the DSO.For power balancing purposes, the DSO only needs to know the aggregated load in a single bus and not individual homeowner information.Therefore, the proposed smart contract aggregates the total load in a bus and sends this information to the DSO through the blockchain-maintaining user privacy.After the DSO solves the power balancing problem and determines the energy allocated to each homeowner, the second stage of our smart contract sends this information to each homeowner's HEMS device.The HEMS device will then use this information to enable and disable the correct home appliances to stay below the allowed energy for the next timeslot.This process is repeated for every timeslot.The range of each timeslot is determined beforehand and typically ranges from 15 minutes to an hour.This paper combines blockchain technology and smart contracts with HEMS devices to ensure user privacy and secure data transfers with the DSO.
The rest of this paper is organized as follows.In Section II, we provide background on the blockchain and smart contract technology.In Section III, we outline our smart contract procedure to ensure user privacy.We present simulation and results of deploying our smart contract in Ethereum in Section IV.We conclude and discuss future work in Section V.

II. BACKGROUND
Blockchain was initially designed as a distributed, peerto-peer database in 2008 [16].The motivation for blockchain was to trade electronic cash without the assistance of a financial institution or third-party.Therefore, financial transactions between two parties are not based on trust but rather cryptographic proof.Traditionally, transactions are recorded in the blockchain by using a proof-of-work consensus mechanism, which is computationally impractical to change if the majority of the nodes are honest.Miners solve complicated verification tests of the block to publish the block to the blockchain.The number that solves this test is called the nonce.A unique hash value is created to define all the information in a block.A single change in the block creates an entirely different hash.This hash value includes the hash of the previous block, so the blocks are linked in a cryptographic hash tree, which is stored in each block.The state of the system is updated when nodes reach consensus on previously published blocks.The most popular use of blockchain is Bitcoin, a cryptocurrency service [16].
Public and private keys can further protect the data in the blockchain.Public and private keys create an avenue by which users can interact using encryption and decryption techniques.Public keys ensure users are addressable in the blockchain, while private keys enable the user to be seldom identified.Privacy can still be maintained by keeping public keys anonymous.Private keys are used as a digital signature when a user approves data to be recorded in the blockchain.The user's public key is then used by others to verify the information before it is added to the blockchain.Also, information can be privately shared using the receiver's public key to encrypt the data.The receiver can then decrypt the data using its private key.Private, or permissioned, blockchains can add another level of privacy as only verified users are allowed access to the blockchain.As public blockchains allow user access without verifying trustworthiness, complex and computationally-intensive consensus mechanisms, i.e., proof-of-work, are required to ensure a trusted environment.These are energy-intensive and slow compared to the lightweight mechanisms typically used in a trusted, private blockchain, such as proof-of-authority.
A smart contract is an automated computer code that is publicly embedded in the blockchain forever.These are publicly viewable, and therefore, transparent agreements that are guaranteed to execute automatically when certain conditions occur within the blockchain or the contract's functions are called.Intended initially for trustless financial markets, blockchain and smart contract research has expanded into various other applications, and recently expanded into electrical power applications [21,22].

III. PROPOSED FRAMEWORK
Our proposed framework and smart contract should be implemented in a private blockchain, as we do not intend this blockchain to be open to the public.Only a certain number of people will need access to this blockchain, and their addresses will be whitelisted beforehand.The DSO's address will also be defined in a trusted manner.Upon user verification, HEMS users have permission to call user-related functions in the smart contract.We are assuming it is in all player's best interest to behave in an honest manner.
We consider an unbalanced distribution system, shown in Fig. 2, which serves a different number of homes in each phase of its three-phase nodes [23].Residential homes on every phase are of either regular or smart (HEMS-equipped) type.Here, a smart home has been considered to own PV panels coupled with ES, HVAC, WH, and non-controllable load (NCL) that are entirely controlled by its HEMS.Other appliances can be similarly included.To determine if there will be any congestion or voltage violation in the distribution network, we model the DSO to initially implement a reliability assessment by solving a first-stage optimization problem based on future nodal demand bids from loads as well as supply bids from distributed generation (DG), if any, at the three-phase feeder level, e.g., each of the 68 nodes in Fig. 2. The DSO can, however, solve its first stage optimization problem without any need for demand or supply bids, and can maximize the social welfare by dispatching as much power as demanded and allowed by the grid constraints.Distribution locational marginal price (DLMP), values that are composed of energy, losses, congestion, and voltage violation components of each node at each timeslot, are computed using the first-stage optimization solution and sensitivity analysis [15], [23][24][25].When congestion or voltage violation prices are shown, signaling the existence of an operational issue, the DSO immediately seeks flexibility service from HEMSs to alleviate the issues while maintaining three-phase power-balance at the substation node.By using DLMP components, DSO can send two price signals (a lower and an upper) to each HEMS and request a flexible demand range.
In the next step, each HEMS can compute and send back to the DSO the inquired demand range by incorporating the DSO's prices in its ADP-based stochastic optimization problem and finding optimal consumption amounts (demand) of its controllable appliances.In the second stage, by aggregating the flexibility ranges of all the participating HEMS, the DSO can determine an optimal dispatch point without any distribution system congestion or voltage violation and send it back to each HEMS.In its second stage, each HEMS sets the dispatch point as the maximum consumption for its controllable appliances.
The communication process between the HEMS users and DSO begins with the DSO submitting an upper and lower electricity price range for the next timeslot to the blockchain.The users can trust these price signals as the blockchain is immutable and tamper-evident.Therefore, users know an attacker did not modify the value sent.For each timeslot, HEMS devices will calculate the lower and upper bound of predicted load based on the published price from the DSO.Each user will securely submit this load prediction to a userdefined call in the smart contract.Users are encouraged to use a virtual private network or Tor, which enables users to communicate anonymously and protect their IP addresses, and thus, locations.
After all HEMS users have submitted their predicted load ranges, or after a certain amount of time has passed, the lower and upper range limits will be aggregated.The DSO can trust these values as the blockchain and smart contract functions are tamper-evident.In this case, the DSO can only read the summed value of predicted power consumption in a single node rather than the prediction values of each home.In the context of privacy, the personnel in the DSO and other HEMS users have no access to the encrypted predicted load of a given house without a password, and unauthorized users have no access to the private blockchain, so protection of HEMS users' information is verified.
After the utility gets the aggregated load forecast signal from the smart contract, the operator will solve the convex optimization power-balancing problem based on the lower and upper bound of the load range.The objective function minimizes the cost to the user by using the DLMP at each node.The global optimal solution indicator for allowable load for each HEMS user is captured in  and is sent to each HEMS device through the blockchain.From equation  we can see that  is a decimal number between zero and one, which is useless to the attacker unless they have knowledge of the lower (

𝑖
) and upper bounds (   ) of the forecast signal that each customer sent to the smart contract in the first stage, which is not possible without a private password as the data is encrypted.Here,  ℎ  is the allowed power to each HEMS, where  is each HEMS in the system.The DSO will submit  to the smart contract, and an event invocation will save the value in a block.Finally, the smart contract gives the dispatch information, , to each HEMS when requested by a user-defined function.The DSO shares one single  that applies to all HEMS users; therefore, the run time for this stage is extremely short.

IV. TESTING AND RESULTS
Our smart contract was implemented in Ethereum for testing.Fig. 4 presents a graphical representation of the procedure for this simulation.Ideally, this concept will be implemented in a private blockchain, but for the purpose of rapid testing, Ethereum is used through the Ropsten test network where user access is controlled.This test network allows functions to be called from several different addresses.Therefore, to test our concept, we used one address to act as the DSO and a minimum of two addresses acting as homeowners with HEMS devices.Note, in our proposed private blockchain framework, the DSO and users' addresses will be known and permissioned accordingly.As we are testing in a public network, addresses are assigned to each user and DSO through a claiming framework.To begin testing, we define which addresses are associated with the DSO and with the users.This procedure is implemented in Ethereum using function calls 'claimDSO()' and 'claimUser()', with each input being a unique address in the blockchain.Each type is allowed specific permissions within the smart contract.
Next, the DSO shares an upper and lower DLMP value to the blockchain by function call 'submitPrice()'.These values are used by each HEMS to optimize their load forecast schedule for the next timeslot based on this electricity price range.These values are obtainable by function call 'getPrice()'.Once this is completed, each homeowner submits a range of forecasted demand data for the next timeslot.Forecasts are formatted as a lower and upper bound of the forecasted demand and sent to the smart contract through function call 'submitRange()'.HEMS users must encrypt this data as it is publicly published on the blockchain.Prior to encryption, it would be published in the block in hexadecimal format, as depicted in Table I.The first eight hexadecimal characters in the "Input Data" section is the call to the 'submitRange()' function.The remaining data is the string parameter, the non-encrypted load forecast submission ('9,10' in this case), in hexadecimal.Here, the ellipsis in the input data are zeros and are removed to save space.After all HEMSs in a bus have submitted their load ranges, the DSO calls function 'getAgg()' in the smart contract to aggregate the decrypted total load range in a single bus.Fig. 3 provides the transaction event details of calling this function.The data displays only the sum of the users' forecasts and not individual load forecast values.Note, we did not include the time delay for load aggregation in testing.Ideally, the smart contract would operate after a certain amount of time, even if all users had not submitted their forecasts.Offline, the DSO calculates the optimized allowed demand to each home using the aggregated demand range.The DSO then submits the optimal allowed power signal () to the blockchain, using 'submitLambda()'.At each new timeslot, each homeowner requests this value through another function in the contract, called 'getLambda()'.The lambda value allows each HEMS owner to know their maximum allowable demand for the next timeslot.The DSO then clears all submitted values from the contract using 'clearPrice()', 'clearRange()', and 'clearLambda()' to prepare for the new submissions in the next timeslot.This process is repeated every timeslot.The pseudocode used for this simulation is provided in Algorithm 1.
Results show the homeowner's privacy is maintained as their load forecasts are encrypted, and the total forecasted load in a node is aggregated and sent to the DSO through the blockchain.The DSO is also able to communicate the allowable load to each homeowner for the next timeslot in a secure manner.

V. CONCLUSIONS AND FUTURE WORK
The proposed smart contract concept was verified through simulation and testing.All vulnerable information was securely transferred through the smart contract.A property of the blockchain itself protects the data, i.e., blockchains are immutable.The privacy-preserving aggregation is achieved using the smart contract.Compared to the commonly proposed aggregator method, in which the individual user's forecasted electricity usage is exposed to the DSO, the selfrunning smart contract provides an isolated data transfer network.The DSO will only obtain the aggregated forecasted data and have no clear information on individual homeowner activity.Currently, our simulation likely serves better as a framework as testing was run on a public blockchain environment in Ethereum.In the future, we plan to deploy our simulation in a private blockchain-based smart contract.In a private blockchain, nodes that are not involved in the smart contract will not have access to others' data [11].Related work on HEMS communication in a private blockchain shows this method has the capability to support up to 200 nodes [12].Multiple implementations of this contract should be enough capability for aggregated power systems proposed nowadays [13].Therefore, scalability would not be a concern for blockchain-based smart contracts to substitute power system aggregators.Future work will show the performance and results of running our proposed smart contract in a private blockchain environment such as Hyperledger.

Figure 1 .
Figure 1.Blockchain interaction with HEMS.In the first stage, users upload load forecasts.Then, users download the dispatch signal in the second stage.

TABLE I .
TRANSACTION DETAILS SUMMARY