1. Introduction
Distributed renewable energy sources, such as solar panels and wind turbines, are drastically changing the way electricity is generated and consumed [
1,
2]. Energy
prosumers, i.e., energy consumers producing their own electrical power, are rapidly proliferating. Advanced smart grid technologies enable these prosumers to trade surplus energy with other peer prosumers through peer-to-peer (P2P) energy trading [
3]. P2P energy trading is expected to be one of the most important elements of next-generation power systems [
1]. It can provide numerous benefits, such as increasing the overall efficiency of power systems and reducing power outages. For customers, it may create a competitive energy market and allow access to alternative energy sources according to their individual preferences [
1].
In many ongoing trials, P2P energy trading is being facilitated by blockchain technology through blockchain’s distributive nature and capacity to run smart contracts [
3,
4]. Such trading systems cannot be fully independent of the existing infrastructure, but the integration of new systems into conventional centralized energy systems is crucial [
4]. An electric power system requires two fundamental components: the physical system for electricity transmission and the information system for settlement, balancing, and billing. In the P2P trading context, a blockchain can provide a partial solution for the latter, such as matching and contracting between sellers and buyers and recording all transactions in an immutable way. However, the physical functionality must be provided by the existing infrastructure. For example, even when two peers agree on an energy trade between them, there is no way to physically exchange energy if they are away from each other but not mobile. This situation is entirely different from data transmission in a communication system because power routing in dynamic routing configurations is very challenging in comparison with data-packet routing [
1]. Therefore, prosumers must use the power-distribution lines connected to an existing utility company. Furthermore, considering that most renewable energy sources are intermittent, prosumers may still want the stable power source from the utility company, as well as the renewable sources.
In this situation, a utility company serves as both a distribution system operator (DSO), renting transmission and distribution lines to prosumers for P2P trading, and a load serving entity (LSE) (i.e., a power retailer providing stable electricity in a traditional way). According to a recent survey conducted in Reference [
3], prosumers preferred established authorities, such as energy suppliers and the local council, to less stable parties, such as blockchain energy start-ups, as P2P scheme organizers because P2P trading between prosumers requires numerous safeguards. In addition, although the type of technology running the scheme was not important to the prosumers, the mention of Bitcoin [
5] caused a significant negative reaction, which was likely due to its extreme price instability [
3]. Therefore, it would be desirable that a means for financially settling the energy transactions is established outside a blockchain. A desirable feature of this approach is that a prosumer’s credit for produced energy and debit for consumed energy through P2P trading can be managed together with the energy consumption from the legacy line on a single billing account registered to the utility company, while a prosumer can remain anonymous to other prosumers. Nevertheless, a blockchain is still an attractive platform for peer matching and trade negotiations as blockchain transactions are transparent and cannot be manipulated even by the utility company. We remark that transparency was valued as the most important characteristic of a local energy trading network in another recent survey [
6]. However, using a blockchain in this way can pose a potential threat to the security of the utility company. The blockchain will contain all the details of the transactions mediated by the company, which can reveal a significant portion of the trade secrets of company, such as the size and pattern of transactions and the company revenue through mediation fees. Even if a private/permissioned blockchain is used, as in many previous works in relevant literature [
3,
4,
7], every node participating in the blockchain will learn confidential information about the company.
To address these issues, we aimed at achieving two main goals that, at a first glance, may seem to conflict with each other: transparency of the peer matching procedure and confidentiality of the matching information. For this purpose, we proposed a P2P energy trading system on a private Ethereum blockchain, where all bids are encrypted and peer matching is performed on the encrypted bids by a functional encryption (FE)-based smart contract. The system guarantees that the information encoded in the encrypted bids is protected from blockchain nodes, although the peer matching transactions are performed by the nodes in a publicly verifiable manner through smart contracts. The prosumers remain anonymous to each other, whereas the utility company knows their identity for accounting and billing purposes. Moreover, matching peers cannot repudiate their bids after the matching is complete. Accounting and billing are settled outside the blockchain. We verify the feasibility of the proposed system by implementing a prototype composed of smart meters, a DSO server, and a private Ethereum blockchain. According to the experimental results, the entire procedure for encrypting a bid, uploading this bid to the blockchain, and matching peers on the blockchain were completed in real time (i.e., in a few seconds). A part of this paper appeared at [
8].
5. Simulation and Performance Analysis
In this section, we verify the feasibility of the proposed system by implementing a prototype. To simulate the system illustrated in
Figure 1, we implemented a DSO, private Ethereum blockchain, and smart meter. The DSO was implemented on a desktop server with an Intel Core i7-7700 CPU (3.60 GHz) and 16 GB RAM, and the private Ethereum blockchain was implemented on a desktop server with the same configuration. To simulate a smart meter, we used a Raspberry Pi 2 with an ARM Coretex-A7 quad-core CPU (900 MHz) and 1 GB RAM. The software for the DSO and smart meter was implemented in the C
programming language, and the blockchain codes were implemented in the Solidity and Go languages.
Figure 5 illustrates the internal components of the DSO, blockchain, and smart meter. The DSO contains storage module to store the open parameter
, secret key
,
pairs, and contract results to calculate the charges associated with users. The blockchain nodes provide storage to maintain two encrypted heaps
and
. The smart meter contains a storage module to store
,
, permanent
, smart contract address, and the session information including the one-time identifier
, bid
, and the randomizers
for hiding
and
. The smart meter must be equipped with a measurement module. Because the smart meter feeds and receives energy, it should be bi-directional. However, we did not equip the smart meter with the actual power measurement module in our implementation as power measurement was not a primary concern in our experiment. Finally, each party contains an FHIPE module to perform cryptographic operations and a network module to communicate with others.
Figure 5 also shows the data flows between the internal components in each stage. The data flows in the setup stage, bidding and matching stage, and the trading stage are shown as blue, red, and green lines, respectively. Most of the data flows depicted in
Figure 5 are straightforward according to the protocol description in the previous section. Therefore, we focus on the data exchange involving the FHIPE modules below.
Because the cryptographic operations performed by the three parties are different, their FHIPE modules contain different algorithms. Specifically, the DSO performs
in the setup stage (
Figure 2), producing
. The DSO also performs
and
for the verification of encrypted bids in the trading stage (
Figure 4). Its FHIPE module takes
and
as input and produces
and
to be compared with those received from the blockchain in the bidding and matching stage. The FHIPE module in the smart meter performs
and
operations for generating its encrypted bid
in the bidding and matching stage (
Figure 3) and verifying the counterpart’s bid
in the trading stage (
Figure 4). The FHIPE module in the blockchain repeatedly performs
, i.e.,
, for the
and
operations in the bidding and matching stage (
Figure 3). The
operation requires pairing computation
e. We used an optimal Ate pairing [
53] with a pairing-friendly Barreto-Naehrig (BN) curve [
54], as defined by Ethereum.
According to
Section 2.3, the
,
, and
operations performed by the DSO and smart meter require the implementation of group operations on
and
. To be precise, these operations are point operations on a pairing-friendly BN curve because
and
are BN curve groups that enable pairing operations on the blockchain. To implement the group operations, we also must implement the underlying finite field operations and big number operations. We used the pairing-based cryptography library (MCL) [
55], for elliptic curve operations, the GNU Multiple Precision Arithmetic Library (GMP) [
56], for big number arithmetic operations, and the library for doing number theory (NTL) [
57], for operations over a finite field, vector, and matrix. The MCL library supports optimizations for BN curves in two layers. First, it supports the generalized lazy reduction technique and the new squaring formula proposed in Reference [
58] for the underlying finite field. Second, in a higher layer, it supports an efficient scalar multiplication method using the skew Frobenius map on BN curves [
59]. For the smart meter, we implemented the FHIPE module, applying these optimization methods. For the DSO, we adopted the FHIPE module in Reference [
60], where the above optimization methods, as well as parallel processing, were applied. For the
operation performed by the blockchain, we used the pre-compiled contract provided by Ethereum.
Now, we present our experimental results.
Table 1 summarizes the performance of FHIPE operations by each party for
= 10, 20, 30, 40, and 50, where
is the number of possible choices for power price per unit, i.e., the dimension of the left and right vectors. The values in the table are the averages of 1000 iterations for each parameter combination. We observed that the smart meter required significantly more time than the DSO for performing the same operations, i.e.,
and
. For example, when
,
in the smart meter required 62.040 milliseconds, but the same operation in DSO was performed in 0.120 ms, which is 0.19% of the time consumed by the smart meter.
consumed 351.538 ms in the smart meter and 0.566 ms in the DSO. The DSO required only 0.16% of the time required by the smart meter because the smart meter resource is very constrained compared to the DSO, and an additional optimization method, i.e., parallel processing, was applied to the DSO. However, it must be noted that all operations were completed in less than 2 s, even in the smart meter.
Next, we analyzed the performance of the proposed protocol. First, we evaluated the bidding and matching stage by measuring the transaction throughput, where a transaction covers the following portion of
Figure 3: the smart meter’s encrypting a bid into
, computing the commitment
c, and sending
, and
c to the blockchain, and a blockchain node’s mining a block containing the execution of
and
procedure, and sending the result back to the smart meter. In the experiment, we considered two setups. For the first setup, we measured the throughput with a single smart meter. The second and third columns in
Table 2 present the experimental result in two units: transactions per second (tps) and kilobits per second (kbps). The values are the averages for 1000 bids, where the bid values were randomly selected from
P, and the intent to either buy or sell was also randomly selected for each bid. The results indicate that an entire transaction is completed in roughly a second when
and in a little more than 4 s even when
.
The second setup is for multiple smart meters. Recall that in the first setup, the measured time covered the operations for both the smart meter and the blockchain. However, in a more realistic situation, the blockchain does not have to wait until a smart meter completes its task. Instead, it is reasonable to assume that many smart meters generate encrypted bids in parallel, and the blockchain continues its transactions without stalling. Therefore, to simulate this situation, we pre-generated 1000 bids and fed them to the blockchain. According to the experimental results presented in the fourth and fifth columns of the table, when
, the throughput was doubled compared to the single smart meter case. When
, the throughput increased by 41%. For reference, we also presented the measured throughputs when the bid protection was not applied, i.e., the bids were not encrypted. The last two columns of
Table 2 show that the transactions were performed up to
times faster when the bidding and matching stage was implemented without encryption.
We also analyzed the Ethereum gas consumption in the bidding and matching stage of the proposed protocol. In the protocol, the two dominant operations that consume gas are heap node creation and
operation. First, when an encrypted bid is inserted into an encrypted heap according to Algorithm 1, a new leaf node containing
is created, which requires non-negligible memory, thereby consuming gas. Second, according to the specification of go-ethereum [
61], which is an EVM implemented with the Go language, a combined pairing operation involving an
n-dimensional vector consumes 80,000
n + 100,000 gas [
62]. In our case, a
operation requires a combined pairing operation with
and some additional operations. The
operation is used to manage two encrypted heaps,
and
, i.e., it is repeatedly used for the
and
procedures, as shown in Algorithm 1 and Algorithm 2. Although we did not demonstrate an explicit algorithm, the REMOVEMIN procedure also repeatedly calls
.
Table 3 details the gas consumption of these two dominating operations. We measured the consumed gas for 100 iterations, and the values presented in the table are the averages. It can be inferred from the experimental result that the gas consumption of heap node creation increased by a similar amount each time
was increased by 10. For example, the difference in gas consumption between
and
was 1,334,272, and the difference between
and
was 1,334,236. We also observe that the gas consumption of
was slightly greater than 80,000
100,000.
Regarding the performance of the trading stage, the dominant operations for this stage are
and
operations of the DSO and two smart meters, because other operations, such as hash computation, are negligible. As the operations of the two smart meters are independently performed in parallel, the time required for this stage is roughly
(DSO’s left and right encryption time) + (smart meter’s left and right encryption time). It is roughly 415 ms for
and 1.88 s for
according to
Table 1.
For an objective evaluation of the performance of the proposed system, we compare it with the performance of previous blockchain-based privacy-perserving applications. Because these applications were not for P2P energy trading, direct comparison with the proposed system is not possible. However, they can be the reference for the performance of our system. First, we examine Zerocash [
22] that ensures user anonymity for cryptocurrency transfer. The main cryptographic primitive of Zerocash is zero-knowledge Succinct Non-interactive Arguments of Knowledge (zk-SNARKs), which are composed of
,
, and
algorithms. In Reference [
22], the following six functions for Zerocash were defined by using these algorithms; Setup, CreateAddress, Mint, Pour, VerifyTransaction, and Receive. Among them, the Pour function actually transfers cryptocurrency. According to the experimental results on an Intel i7-4770 @ 3.40 GHZ CPU and 16 GB RAM, the
algorithm needed 2 min 2 s, while the
algorithm needed only 5.4 ms [
22]. Because the dominant operation of the Pour function is
, a Pour operation needed 2 min 2 s. In contrast, the dominant blockchain operation in the proposed system is
, which is based on the similar operation to the underlying operation of
of Zerocash. We already verified in
Table 1 and
Table 2 that
is completed in tens of milliseconds and an entire transaction is completed in a few seconds.
Next, we examine the performance of Hawk [
24]. Hawk is a more general framework for building privacy-preserving smart contracts. As in Zerocash, the
,
and
algorithms were defined for zk-SNARKs, and they were used to design Pour, Freeze, Compute, and Finalize operations. Among the applications of Hawk presented in Reference [
24], we may refer to the auction application. This application is composed of user-side and manager-side operations. According to the experimental results on Amazon EC2 r3.8xlarge virtual machines in a 27 GB, 4-core environment, the manager-side Finalize operation for selecting a winner required 469.7 s for 100 participants. According to
Table 2, the proposed system requres only
s for 100 transactions when
and
s when
.
7. Discussion
In this paper, we proposed a P2P energy trading system on a blockchain where peer matching is performed on the encrypted bids by a functional encryption-based smart contract. We also verified the feasibility of the proposed system by implementing a prototype composed of smart meters, a DSO, and private Ethereum blockchain. However, the system could be improved in several ways. First, we only considered the case where new encrypted bids are inserted into the heap. However, it would be desirable if there were a mechanism to remove a bid when it expires. Second, the dimension of the vectors encoding bid values is proportional to the range of possible bid values. If we can use a more compact encoding, e.g., a binary encoding, we can significantly reduce the time and gas consumption for bid generation and peer-matching. Finally, the smart meter performance can be improved by adopting more implementation optimization. We shall address these issues in future research.
The proposed method provides the means to hide the electricity price and amount contained in a bid, but it does not tell a prosumer what price to bid. Many relevant studies have been conducted to improve the energy management and optimize the costs. Various techniques, such as fuzzy logic [
63], cooperative game theory [
64], genetic algorithms [
65], and deep recurrent neural networks [
66], have been proposed. Specifically, a reinforcement learning-based strategy (Fuzzy Q-learning) was recently proposed to improve the decision-making process of P2P power trading [
67]. These strategies may be combined with our privacy-enhancing method.
Furthermore, the proposed system may be combined with other privacy-preserving techniques for smart grids. In recent years, extensive research on smart meter data obfuscation has been conducted to prevent the leakage of smart meter readings [
37,
38,
39]. However, these methods are adding noise to the measurements; thus, they affect the billing and control functionalities [
68]. Therefore, many studies have proposed the use of batteries to mask the energy-consumption statistics [
68,
69,
70]. The advantage of using batteries is that they not only improve privacy but also reduce energy costs when charging and discharging are cleverly controlled. For this purpose, multiobjective optimization methods have been proposed to simultaneously minimize privacy leakage and energy cost [
69,
70]. However, these proposals assume that energy prices are set up by the utility company, and the prosumer’s active pricing mechanism with P2P trading has not been considered. Therefore, it would be very interesting if we combined the proposed system with these battery-enabled data protection methods. This may ensure privacy in two aspects: protection of power-consumption and P2P transaction data.