Privacy-Preserving Charging Coordination Scheme for Smart Power Grids Using a Blockchain

Abstract

With the rapid emergence of smart grids, charging coordination is considered the intrinsic actor that merges energy storage units (ESUs) into the grid in addition to its substantial role in boosting the resiliency and efficiency of the grid. However, it suffers from several challenges beginning with dependency on the energy service provider (ESP) as a single entity to manage the charging process, which makes the grid susceptible to several types of attacks such as a single point of failure or a denial-of-service attack (DoS). In addition, to schedule charging, the ESUs should submit charging requests including time to complete charging (TCC) and battery state of charge (SoC), which may disclose serious information relevant to the consumers. The analysis of this data could reveal the daily activities of those consumers. In this paper, we propose a privacy-preservation charging coordination scheme using a blockchain. The blockchain achieves decentralization and transparency to defeat the security issues related to centralized architectures. The privacy preservation will be fulfilled using a verifiable aggregation mechanism integrated with an aggregated signing technique to identify the untrusted aggregator and assure the data source and the identity of the sender. Security and performance evaluations are performed, including off-chain and on-chain experiments and simulations, to assess the security and efficiency of the scheme.

1. Introduction

Recently, smart grids have received much attention in industrial, academic, and technological societies. They are considered the smart surrogate for aging power grids. They have considerable potential to provide smart services since they amalgamate several technologies such as the internet of things (IoT), big data, cloud computing, etc [1]. The energy storage units (ESUs) are the prime actors in a smart grid, which could be a home battery or electric vehicle (EV) [2]. They can store energy in case of energy overflows and supply it to the grid in case of difficulties equalizing the energy demand and supply, which can boost the smart grid’s endurance [3]. In addition, ESUs contribute to the growing popularity of green energy and sustainable development by hoarding the energy overcapacity from renewable energy generators [4]. This hoarded energy could be supplied to powerhouses and charge EVs during high-demand intervals, which improves grid reliability. Furthermore, ESUs introduce an economical advantage in that they allow consumers to avoid purchasing electricity during high-tariff periods, which, in turn, reduces electricity bills [5].

In spite of their advantages, there are considerable challenges that could affect the efficient integration of ESUs into the power grid. Particularly, the concurrent tsunami of unscheduled charging requests could cause an imbalance between the incoming charging requests and the supplied energy, which can produce a thorough failure of the smart grid [6]. For instance, most EV owners charge their vehicles after returning to their homes. To address these impacts, there is an essential demand for a charging coordination technique to avoid the collapse of the energy distribution system and avoid mass blackouts [7].

Although several studies have developed charging coordination techniques [8,9], they suffer from several limitations. Firstly, their centralized architectures make them vulnerable to a single point of failure or denial-of-service (DoS) attack. Secondly, several techniques assume that the ESP is fully trusted and schedules charging requests fairly. Thirdly, the existing charging coordination techniques normally require the ESUs to send data to the ESP; these data are used to determine the charging priority of the ESUs, and by analyzing the data provided by the ESUs, sensitive information may be disclosed such as the locations of the EVs and their driving distances and the daily activities of the houses’ inhabitants [10]. The analysis of this information enables the attacker to obtain a lot of details related to the client’s life patterns such as their work address, health condition, income level, etc. [11].

Motivated by the aforementioned limitations of the literature, in this paper, we propose a privacy-preserving charging coordination scheme using a blockchain. With a blockchain in place, the system can be implemented in a decentralized and transparent fashion, which tackles the previously mentioned security issues relevant to the present centralized approaches [2,12]. The use of a blockchain decentralizes the charging coordination technique making it robust against a single point of failure and other attacks that threaten the availability of the system [13]. However, a blockchain does not provide privacy, and therefore we introduce an aggregated masking scheme as a feasible solution for balancing data utilization and privacy preservation in smart grids. Specifically, ESUs report individual masked charging requests including $SoCs$ and $TCCs$ alongside individual signatures periodically to a validator (local aggregator). In turn, the validator blindly aggregates the incoming charging requests to compute the aggregated charging request $C{R}_{agg}$. In order to prevent the local aggregator from returning an invalid result, we use a verification method conducted by another validator (verifier) to ensure the integrity of the aggregation process [14]. In addition, an efficient authentication mechanism is necessary to prove the trustworthiness of the data sources and check the identity of the data sender [15]. Then, the local aggregator broadcasts $C{R}_{agg}$ so that each $ESU$ can calculate the charging schedule locally. If the total charging demand exceeds $K_{max}$, a subset of ESUs with high priority charge without exceeding the available energy for charging.

The remainder of this paper is organized as follows. Section 2 presents the related works. Section 3 introduces the network model, threat model, and design goals. The preliminaries and necessary background information are provided in Section 4. The proposed scheme is demonstrated in Section 5. The security and performance evaluations are discussed in Section 6 and Section 7. Finally, the conclusions are given in Section 8.

2. Related Works

In this section, we survey some relevant works in two main parts. First, we discuss the problem of charging coordination in the smart grid. Subsequently, we discuss several works on privacy-preservation schemes in the smart grid.

Charging coordination in smart grids has gained a lot of interest recently. Ota et al. [16] introduced a distributed vehicle-to-grid ($DV2G$) control model to coordinate the charging of EVs, whereas in [17], a smart charging method for the charging coordination of plug-in hybrid electric vehicles (PHEVs) was introduced. This method intended to reduce the everyday overall charging fees by combining the grid-to-vehicle ($G2V$) and the vehicle-to-grid ($V2G$) methods using real-time tariffs (RTTs) in parking lots, which were managed by different aggregators. This enhancement method was merged with the smart charging scheduling algorithm (SCSA) to determine the appropriate charging fees and times. In addition, in [18], a new charging scheduling mechanism was proposed based on a double-purpose improvement algorithm to enhance efficiency and reduce fees. The authors applied other charging solutions such as the vehicle-to-vehicle ($V2V$) and charging-station-to-vehicle ($CS2V$) methods.

In [19], an energy management mechanism was proposed to motivate EV owners to participate in the energy trading process through a game-theoretical scheme. The same topic was introduced in [20], where an energy optimization and auxiliary service scheduling mechanism was proposed to maximize the gain of EVs, introduce more resilience, minimize the peak load to the ESP, and lower the costs for consumers.

Kang et al. [21] developed a consortium blockchain-based decentralized electricity trading system to charge $V2V$. They applied an optimization mechanism named iterative double auction to improve the charging costs, as well as the amount of commercial power exchanged between EVs. In addition, in [22], another decentralized charging coordination mechanism for EVs was proposed, which formulated charging coordination for EVs as an optimal control problem using the flexibility of EV loads to charge during power consumption valley periods.

In [23], a real-time charging station selection mechanism using large-scale $GPS$ data mining was introduced. The mechanism aimed to select the most convenient charging station for EVs using their historical charging events and real-time $GPS$ data streams. In addition, Cao et al. [24] proposed a regular updating technique for choosing the appropriate charging station in order to solve the problem of EVs not reaching the planned charging stations on time. Xu et al. [25] introduced a mathematical model of the ideal charging plan using an analysis of the previous charging behaviors of EVs.

Several papers in the literature have investigated security and privacy preservation in smart grids. Akula et al. [26] introduced a secure approach to smart grid power injection. In the proposed approach, the incoming masked bids sent by ESUs are aggregated and submitted to the ESP. The objective of this work was to enable the ESP to learn the total amount of power that can be injected by the ESUs in a confidential method. In addition, several reliable aggregation schemes based on secure matrix multiplications over encrypted data were proposed in [27]. These schemes applied the k-nearest neighbor (kNN) similarity mechanism.

In [28], a data obfuscation method was used in an $AMI$ network to develop protected and operative mechanisms to distribute obfuscated data. Li et al. [29,30] introduced an anonymous and authenticated mechanism to preserve the privacy of the stored energy reported from EVs. Then, they developed an optimal authentication method to secure the location of the EVs.

In [31], a consortium blockchain-based data aggregation and regulation scheme for smart grids was introduced. This scheme is concerned with multidimensional data collection and multi-recipients in the consortium blockchain. In [32], a blockchain and fog-computing-based privacy-preserving charging mechanism for EVs was proposed. Fog computing was used to reduce the overload on the server side and introduce local computing services. In addition, the blockchain system was deployed on the distributed fog-computing nodes (FCNs), introducing a decentralized and secure storage media. The security of the communication between EVs and $FCNs$ was achieved using a mutual authentication scheme.

In [9], two privacy-preserving and collusion-resistant charging coordination approaches for smart grids were discussed. The first was a centralized approach in which ESUs authenticated their charging requests anonymously using anonymous and unlinkable tokens obtained from a centralized server operated by the electrical utility. Moreover, ESUs sent multiple charging requests with random TCC and SoC data in a truncated normal distribution to prevent linking the charging requests sent by an $ESU$ to preserve privacy. Furthermore, in the decentralized approach, secret masks are shared among proxy ESUs to thwart collusion attacks. Wang et al. [33] introduced an identity-based verifiable aggregator’s oblivious encryption scheme for smart grids. They proved the aggregator obliviousness and unforgeability through the smooth projective hash function and computational Diffie–Hellman presumption. In addition, they developed an identity-based aggregation protocol for smart grids based on their proposed encryption scheme.

In [34], a lightweight data aggregation scheme for smart grids was proposed. The scheme is suitable for devices with limited resources, such as smart meters and task schedulers that perform only lightweight computations, whereas complex operations are performed by scalable processing units. Another lightweight privacy-preserving data aggregation scheme for smart grids was proposed in [35]. The scheme is suitable for devices with limited resources and thwarts collusion attacks for up to ($n-1$) users.

Although several studies have developed charging coordination techniques [8,9], they suffer from several limitations. Firstly, the current techniques often have a centralized architecture that makes them vulnerable to a single point of failure, i.e., they depend on a single server to manage and coordinate incoming charging requests. If a successful denial-of-service (DoS) attack is launched on the energy service provider (ESP), the entire system fails. Secondly, the existing techniques assume that the ESP is fully trusted and schedules charging requests fairly. Specifically, there is no guarantee that the charging coordination technique is executed precisely. Thirdly, the existing charging coordination techniques normally require the ESUs to send data to the ESP such as time to complete charging (TCC) and battery state of charge (SoC). In particular, these data are used to determine the charging priority of the ESUs, and then the ESUs with the highest priority charge first without exceeding the maximum available power $\left(K_{max}\right)$, whereas the charging of the other ESUs is deferred to the next time intervals. Therefore, by analyzing the data provided by ESUs, sensitive information may be disclosed such as the locations of the EVs and their driving distances and the daily activities of the houses’ inhabitants [10]. The analysis of this information enables the attacker to obtain a lot of details related to the client’s life patterns such as their work address, health condition, income level, etc. [11]. In some cases, this information could be sold or exchanged for commercial purposes. In other cases, the charging requests sent by EVs could determine whether an EV owner is at home, how long he/she will stay there, and how frequently he/she drives. For instance, if a home battery is not charged for an extended period, this indicates that the residents are not at home or are traveling and, consequently, this house could be broken into [36].

3. Network/Threat Models and Design Goals

In this section, we first introduce the network model of our proposed scheme, followed by the threat model, and finally, the design goals of the scheme.

3.1. Network Model

As illustrated in Figure 1, the network model of our scheme involves three main entities: the key management center (KMC), energy storage units (ESUs), and blockchain network.

• The Key Management Center (KMC): The $KMC$ is a trusted party. It can be a governmental authority such as the Ministry of Electricity and Energy, which is the administrator of the whole system. It is responsible for the initialization of the entire system including the registration of all terminals.
• Energy Storage Units (ESUs): An $ESU$ can be either a home battery or EV. It is the fundamental unit in the smart grid, which is deployed in one community named group and connected to the blockchain network through the validator (local aggregator).
• The Blockchain Network: The blockchain is the heart of our proposed scheme. It is responsible for receiving and scheduling incoming charging requests without exceeding the maximum energy capacity or accessing individual charging requests. The blockchain consists of nodes named validators. Each validator acts as either an aggregator or a verifier. The local aggregator receives n masked signed charging requests from $nESUs$ in one group. It computes the aggregated charging request $\left(C{R}_{agg}\right)$. Finally, the aggregation results and proof of correct aggregation are forwarded to a verifier to start the verification process. The verifier uses the reported verification parameters to check the correctness of the aggregated result. In addition, due to the nature of the blockchain, it is a common assumption that more than $50\%$ of the blockchain validators are honest. In this paper, we implement our proposed scheme using a private blockchain. A private blockchain is selected because each verifier belongs to a different utility and every utility is considered a node in the blockchain network. In addition, a private blockchain provides higher throughput with more acceptable latency than a public blockchain.

3.2. Threat Model

The $KMC$ is a trusted party since it is supervised by a governmental authority that is concerned with the security of the entire system. The blockchain network is a conceptual trusted party that is designed for data immutability and transparency but not for privacy preservation [37]. The blockchain validators could misbehave with the aggregated data or try to infer sensitive information. In this paper, we assume that blockchain validators (local aggregators) are curious to obtain information about ESUs’ owners. In addition, some of these validators may be malicious and they do not perform the computations honestly. Moreover, the attackers may passively snoop on the communications between ESUs and the local aggregator to infer sensitive information such as whether inhabitants of a house are currently traveling, their return home time, and other daily activities.

3.3. Design Goals

We demonstrate that our proposed scheme fulfills the following substantial objectives:

• Decentralization and resiliency: Our proposed scheme should not rely on any central party to perform the charging coordination. As mentioned previously, centralized schemes are vulnerable to single-point-of-failure and other attacks and suffer from a lack of transparency. Therefore, our proposed scheme considers that no entity in the entire system has complete central authority to control the charging coordination process.
• Privacy-preserving charging scheduling: Our proposed charging scheduling scheme should compute the charging schedules without exceeding the $K_{max}$ and without disclosing any sensitive information about the clients.
• Resistance to replay attacks: Our proposed scheme should counter replay attacks, i.e., if an attacker tries to record a charging request and sends it later, it should be rejected.
• Data integrity and authenticity: Our proposed scheme should guarantee the integrity and authenticity of incoming charging requests and also the authenticity of the ESUs’ identity.

4. Preliminaries

In this section, we introduce the essential background for this paper including bilinear pairing, the computational Diffie–Hellman problem, the key agreement protocol, the deterministic random generator, and the blockchain. All notations used in this paper are presented in

Table 1. Notations.

Notation	Description
$ES{U}_i$	Energy Storage Unit
ESP	Energy Service Provider
${\mathbb{P}}_i$	$ES{U}_i$ priority
${\mathbb{S}}_i$	$ES{U}_i$SoC
${\mathbb{T}}_i$	$ES{U}_i$TCC
$\{G_1,G_2,G_T,g_1,g_2,\widehat{e},p,H_1,H_2,\lambda ,{\rm Y}\}$	Public Parameters
$\langle (\lambda ,{\rm Y}),\eta \rangle$	$KM{C}^{\prime }s$ master public values, master secret key
$\delta$	Common State Value
$I{D}_i$	The Identity of $ES{U}_i$
$K_{pub}{}_i,K_{priv}{}_i$	$ES{U}_i$ Public Key and Private Key Pair
$\langle {\chi }_i,{\mathsf{\Lambda }}_i\rangle$	$ES{U}_i$ Private Key
$C{R}_i$	$ES{U}_i$ Charging Request
$C{R}_{agg}$	Aggregated Charging Request
${\gamma }_1$,${\gamma }_2$	The Equation Weights
$L_m$	Priority Label
$Ts$	Temporal Charging Slot
$\pi$	$24/Ts$
$R_i$	Proof Value
$P{V}_i$	$ES{U}_i^{\prime }s$ Public Value
${\Gamma }_i$	$ES{U}_i^{\prime }s$ Masked Charging Request
$u_{ij}$	Shared Seed Value Between $ES{U}_i$ and $ES{U}_j$
$\langle W_i,N_{i1},N_{i2},C\rangle$	$ES{U}_i^{\prime }s$ Signature Credentials
${\sigma }_i=(V_i,W_i)$	$ES{U}_i^{\prime }s$ Signature
$\rho$	Correctness Proof of The Aggregated Value
$\mathbf{V}$	Aggregated V
$\mathbf{W}$	Aggregated W
$\sigma$	Aggregated $\sigma$
$K_{max}$	Maximum Available Power
$PO{W}_L{}_m$	The Power Assigned to The $ESU$ In Terms of Priority Labels

.

4.1. Bilinear Pairings

Let ${\mathbb{G}}_1$, ${\mathbb{G}}_2$, and ${\mathbb{G}}_T$ are bilinear groups with prime order p, in which $g_1$, $g_2$ are the generators of ${\mathbb{G}}_1$ and ${\mathbb{G}}_2$, respectively.

Definition 1.

A pairing $\widehat{e}:{\mathbb{G}}_1\times {\mathbb{G}}_1\to {\mathbb{G}}_T$ has the following properties:

• Non-degeneracy: $\widehat{e}(g_1,g_1^{\prime })\ne 1$.
• Bilinearity: $\widehat{e}(\nu g_1,\iota g_1^{\prime })=\widehat{e}{(g_1,g_1^{\prime })}^{\nu \iota }$ $\forall g_1,g_1^{\prime }\in {\mathbb{G}}_1$ and $\nu ,\iota \in {\mathbb{Z}}_p^{*}$ where ${\mathbb{Z}}_p^{*}$ is a finite field of order p.
• Computability: There is an efficient algorithm to compute $\widehat{e}(g_1,g_1^{\prime })\forall g_1,g_1^{\prime }\in {\mathbb{G}}_1$.

Definition 2.

A pairing $\widehat{e}:{\mathbb{G}}_1\times {\mathbb{G}}_2\to {\mathbb{G}}_T$ has the following properties:

• Non-degeneracy: $\widehat{e}(g_1,g_2)\ne 1$.
• Bilinearity: $\widehat{e}(g_1^{\nu },g_2^{\iota })=\widehat{e}{(g_1,g_2)}^{\nu \iota }\forall g_1\in {\mathbb{G}}_1,g_2\in {\mathbb{G}}_2$ and $\nu ,\iota \in {\mathbb{Z}}_p^{*}$ where ${\mathbb{Z}}_p^{*}$ is a finite field of order p.
• Computability: There is an efficient algorithm to compute $\widehat{e}(g_1,g_2)\forall g_1;g_2\in {\mathbb{G}}_1,{\mathbb{G}}_2$.

4.2. Computational Diffie–Hellman (CDH) Problem

Let ${\mathbb{G}}_1$ be a cycle additive group of prime order p, $g_1$ is a generator of ${\mathbb{G}}_1$, $\forall \nu ,\iota \in {\mathbb{Z}}_p^{*}$, given $\langle g_1,\nu g_1,\iota g_1\rangle$, compute $\langle \nu \iota g_1\rangle \in {\mathbb{G}}_1$. It is assumed that the CDH problem is very hard.

4.3. Key Agreement Protocol

A key agreement protocol $\left(KAP\right)$ involves a set of algorithms as follows:

• $KAP.ParmGen:\left(\epsilon \right)\to \left(PubParm\right).$ The algorithm takes the security parameter $\epsilon$ as input and produces public parameters $({\mathbb{G}}_1,g_1,p,H_1)$, where ${\mathbb{G}}_1$ is a group with a prime order p, where $p>2^{\epsilon }$, and $H_1$ is a hash function.
• $KAP.KeyGen:\left(PubParm\right)\to (K_{priv}{}_i,K_{pub}{}_i)$ using public parameters, the terminal i could generate its private∖public key pair $KAP.KeyGen\left(PubParm\right)\to ({\eta }_i,g_1^{{\eta }_i})$, in which ${\eta }_i{\in }_r{\mathbb{Z}}_p^{*}$ represents the private key of terminal i and $g_1^{{\eta }_i}$ is the corresponding public key.
• $KAP.KeyAgree:(K_{pub}{}_i,K_{priv}{}_i)\to \left(u_{ij}\right).$ Using the private key of terminal i, the public key of terminal j, and the $KAP.KeyAgree$ algorithm, such as the Diffie–Hellman key agreement protocol, the two terminals could generate a shared key $u_{ij}.$

4.4. The Deterministic Random Generator (DRG)

The $DRG$ is an algorithm for generating a sequence of numbers, whose characteristics are roughly similar to the characteristics of sequences of real random numbers. This generated sequence is not purely random since it is completely determined by an initial value called a seed. In our proposed scheme, the $DRG$ is loaded with an identical random seed of some constant length for every two units. It ensures that the generated value based on the random seed is computationally indistinguishable from an identical sampled element from the output space as long as the attackers can not compute this seed. In our proposed scheme, the $DRG$ plays the main role by generating random numbers that could be used in the masking operation.

4.5. Blockchain Technology

As illustrated in Figure 2, the blockchain manages a decentralized, verifiable, immutable, and distributed ledger that permits distrusted parties to transact securely and agree on a unified shared ledger without the need for a central entity [38]. It introduces impartiality, probity, and integrity, where the data of the shared ledger are arranged as a chain of blocks and administrated by a network of computers/servers and named miners/validators operating a peer-to-peer (P2P) protocol. Every block contains a set of transactions carried out by the network peers and is verified by all the network nodes according to a predetermined agreement mechanism (consensus algorithm) [39]. This consensus and other stimulant techniques of the blockchain help to support and fortify the reciprocal confidence among the network nodes. Typically, a blockchain has two main types [40], private and public. In private (permissioned) blockchains, access to reading/writing is allowed for authorized users but in public (permissionless) blockchains, access to reading/writing is permitted for anyone, and all users have the same reading/writing privileges. In this paper, we implement our proposed scheme using a private blockchain. A private blockchain is selected because each verifier belongs to a different electrical utility and every utility acts as a node in the blockchain network. In addition, a private blockchain provides a higher throughput with more acceptable latencey than a public blockchain.

5. The Proposed Scheme

This section provides a depiction of our proposed privacy-preserving charging coordination scheme using a blockchain. It consists of four sequential phases that begin with the system initialization phase, which occurs only once when the scheme is first deployed. It involves the generation of all cryptographic credentials and public parameters for the entire system. This phase is conducted by the $KMC$. Then, there is the submission of the charging request phase, which is conducted by the ESUs and includes two main sub-phases, preparing the charging requests and submitting them. This phase involves running the $KAP$ by the ESUs in the same community to compute the necessary seed to start the masking process, masking charging requests using a one-time mask technique, and individual signing operation, and then submitting them to the local aggregator. In addition, it creates the generic verification parameter (GVP) that is used by the verifier(s) to verify the correctness of the aggregation. Next, is the aggregation and verification of the charging requests phase, where the local aggregator aggregates the individually signed masked charging requests to produce the $C{R}_{agg}$. Thereafter, it checks the aggregated signature and computes the proof of the aggregation process that is sent to the verifier(s) to prove the integrity of the aggregation process. Finally, in the computing charging schedules phase, once the verifier checks the proof, the local aggregator broadcasts the $C{R}_{agg}$ to all of the ESUs. Each $ESU$ locally computes its charging schedule to determine whether it could charge in the present time slot or it has to send its charging request to the next time interval. All the exchanged messages in our proposed scheme are shown in Figure 3.

5.1. System Initialization

In this phase, the $KMC$ takes the security parameter $\epsilon$ as the input and then selects the bilinear group parameters. ${\mathbb{G}}_1$, ${\mathbb{G}}_2$, and ${\mathbb{G}}_T$ are bilinear groups with prime order p, where $p>2^{\epsilon }$. $g_1$ and $g_2$ are the generators of $G_1$ and $G_2$, respectively. Two cryptographic hash functions $H_1$ and $H_2$ are selected by the $KMC$, where $H_1:{\{0,1\}}^{*}⟶G_1$ and $H_2:{\{0,1\}}^{*}⟶{\mathbb{Z}}_p^{*}$. Then, the $KMC$ chooses $\eta \in {\mathbb{Z}}_p^{*}$ where $\eta$ is the master secret key of the $KMC$ and calculates two master public values $\lambda =\eta g_1$ and ${\rm Y}=g_2^{\eta }$. The $KMC$ publishes the following parameters $Param=\{G_1,G_2,G_T,g_1,g_2,\widehat{e},p,H_1,H_2,\lambda ,{\rm Y}\}$. The common state value $\left(\delta \right)$ is a stochastic size string picked up randomly by the $KMC$. It could be a date or any part of a common parameter [15,41].

$ES{U}_i$ sends a registration request to the $KMC$ by sending its $I{D}_i$; the $KMC$ verifies this $I{D}_i$ and then computes ${\theta }_i=H_1\left(I{D}_i\right)$. It also computes ${\mathsf{\Lambda }}_i=\eta {\theta }_i$ as a part of the private key of the $ES{U}_i$. The $ES{U}_i$ chooses a random value ${\chi }_i{\in }_R{\mathbb{Z}}_p^{*}$ and then it computes its corresponding public key $K_{pub}{}_i={\chi }_i{g}_1$ and also the corresponding private key $K_{priv}{}_i=\langle {\chi }_i,{\mathsf{\Lambda }}_i\rangle$. Eventually, $KMC$ publishes $(K_{pub}{}_i,I{D}_i,{\theta }_i)$.

The $KMC$ uses ${\mathsf{\Lambda }}_i$ to compute $R_i$, which is used as a proof by the local aggregator for correct aggregation, where $R_i=g_1^{(\eta +{\mathsf{\Lambda }}_i)}$, and creates a public value $P{V}_i=\widehat{e}(g_1^{{\mathsf{\Lambda }}_i},g_2)$. The $KMC$ sends $R_i$ to the local aggregator and sends $P{V}_i$ to the $ES{U}_i$.

5.2. Submission of Charging Requests

This phase consists of two main sub-phases, preparing a charging request and submitting it.

5.2.1. Preparing Charging Requests

All ESUs send their charging requests to the local aggregator and each $ESU$ computes its priority index ${\mathbb{P}}_i$ using the following equation:

$${\mathbb{P}}_i={\gamma }_1(1-{\mathbb{S}}_i)+{\gamma }_2\mathsf{\Phi }\left({\mathbb{T}}_i\right)$$

(1)

where ${\mathbb{P}}_i$ is the priority of an $ES{U}_i$. SoC is denoted by ${\mathbb{S}}_i\in [0,1]$, in which if ${\mathbb{S}}_i=1$, it indicates that $ES{U}_i$ is fully charged and ${\mathbb{S}}_i=0$ indicates fully uncharged. The priority index increases as the SoC decreases (ESUs with lower energy have higher priority). ${\mathbb{T}}_i$ is the TCC$\in [0,1]$ and $\mathsf{\Phi }\left({\mathbb{T}}_i\right)$ is a decreasing function, where $\mathsf{\Phi }\left({\mathbb{T}}_i\right)=0$ for a long ${\mathbb{T}}_i$ and $\Phi \left({\mathbb{T}}_i\right)=1$ for a short ${\mathbb{T}}_i$, i.e., the priority increases as the TCC becomes shorter. ${\gamma }_1$ and ${\gamma }_2$ are weights to provide the relative significance for ${\mathbb{S}}_i$ and ${\mathbb{T}}_i$, with ${\gamma }_1$+${\gamma }_2$$=1$.

The priority index is categorized into labels, such as $\{L_1,L_2,\dots L_m\}$, so if we classify them on a scale of 1 to 10, they could be sorted as follows $L_1\in [0,0.1],L_2\in [0.1,0.2],\dots L_{10}\in [0.9,1]$. Every charging request is split into groups of bits, where each group represents a specific priority label and every $ESU$ provides its charging demand in the equivalent group to its priority label $L_i$. For example, if the $CR$ length is 500 bits and we have 10 priority labels, the message is divided into 10 groups, each of them with a length of 50 bits. When an $ESU$ submits its $CR$, it should store its charging demand in the equivalent group of its priority label and null in the other groups. As shown in Figure 4, the request from an $ES{U}_1$ named $C{R}_1$ and its corresponding priority label is $L_1$ so if the charging demand of $ES{U}_i$ is 10 KW, it could be presented as 10 in group 1 (the rightmost 50 bits) and null in the other groups. Therefore, when all $CRs$ are aggregated, to avoid arithmetic overflow, each group should be allocated an appropriate number of bits to prevent a carry to the next priority label group from occurring. Finally, the $C{R}_{agg}$ provides the total charging needs of all ESUs and each priority label [9].

5.2.2. Submitting Charging Requests

The day is divided into a number of temporal slots $\{1,2,\dots ,\pi \}$ with uniform periods $T_s$ that cover the entire 24 h of the day, where $\pi =24/T_s$. $ES{U}_i$ submits its $C{R}_i$ during a predefined temporal slot $T_s$ [5].

At the beginning of this phase, $ES{U}_i$ executes the $KAP$ with each of the other ESUs to procure several seed values according to the number of other ESUs. To reduce the overhead of computing the seeds, a seed value $u_{ij}$ is inputted to a $DRG$ to generate a random value that is used in the masking process. This technique is used to compute a one-time mask, $u_{ij},$ which is shared between every pair of ESUs i and j, where $(i\ne j)$, and the masks are used to hide the charging requests of the individual ESUs to preserve privacy. Each $ES{U}_i$ adds the masks shared with $ES{U}_j$ to $C{R}_i$$if(i<j)$, otherwise it subtracts it from $C{R}_i$ as follows:

$${\mathsf{\Gamma }}_i=C{R}_i+(\sum _{j=i+1}^{n}DRG\left(u_{ij}\right)-\sum _{j=1}^{i-1}DRG\left(u_{ij}\right))$$

(2)

The masking operation is carried out by $ES{U}_i$ to mask $C{R}_i$ and to create the generic verification parameter $GV{P}_i$ that is used by the verifier to verify the integrity of the $C{R}_{agg}$ [14]. $ES{U}_i$ uses $\delta$, $I{D}_i$ and the key pairs of the $ES{U}_i$ (public key, private key) $(K_{pub}{}_i,\langle {\chi }_i,{\mathsf{\Lambda }}_i\rangle )$ to sign its $C{R}_i$ as follows. First, $ES{U}_i$ chooses a random number $r_i{\in }_R{\mathbb{Z}}_p^{*}$ and then computes

$$\begin{array}{l}{W}_i=r_i{g}_1\\ N_{i1}=H_2(C{R}_i\Vert \delta \Vert I{D}_i)\\ N_{i2}=H_2(CR{}_i\Vert \delta \Vert K_{pub}{}_i)\\ C=H_1(\delta \Vert \lambda )\\ V_i=N_{i2}·{\mathsf{\Lambda }}_i+({\chi }_i·N_{i1}+r_i)·C\end{array}$$

Finally, $ES{U}_i$ obtains the signature ${\sigma }_i$, where ${\sigma }_i=(W_i,V_i)$. Then, $ES{U}_i$ reports its signed masked charging request $\left(ms{g}_1\right)$ to the local aggregator including the masked charging request ${\mathsf{\Gamma }}_i$, signature ${\sigma }_i$, and timestamp $\tau$ as follows:

$$ms{g}_1{}_i=\langle {\mathsf{\Gamma }}_i,{\sigma }_i,\tau \rangle$$

(3)

In this verification process, $ES{U}_i$ submits the second message $\left(ms{g}_2\right)$ to the verifier, where $ms{g}_2$ contains $GV{P}_i=P{V}_i^{{\mathsf{\Gamma }}_i}$ to be used by the verifiers to verify the integrity of the aggregation process that is carried out by the local aggregator.

5.3. Aggregation and Verification of Charging Requests

In this phase, there are two steps. The first step is the verifiable aggregation that is conducted by the local aggregator, and the second step is performed by the validators, called verifiers.

In the aggregation step, the aggregator receives n messages that need to be aggregated and verified to begin the next phase. All the charging requests are signed and masked using the common state value $\delta$. The local aggregator first checks the timestamp $\tau$ of each message to ensure that it matches the current time slot. The aggregator has a complete list of ${\left\{I{D}_i\right\}}_{i=1}^n$, ${\left\{{\theta }_i\right\}}_{i=1}^n$, the corresponding public keys ${\left\{K_{pub}{}_i\right\}}_{i=1}^n$, the equivalent signatures ${\sigma }_i=(W_i,V_i)\forall (1\le i\le n)$, and the masked charging request ${\mathsf{\Gamma }}_i\forall (1\le i\le n)$. The aggregator computes the aggregated charging request $C{R}_{agg}={\sum }_{i=1}^n{\mathsf{\Gamma }}_i$. In addition, it generates proof of the correctness of the aggregated value. Note that the local aggregator only calculates the $C{R}_{agg}$ and cannot compute the individual $CR$ of any $ESU$ to preserve privacy. Then, the aggregator verifies the signatures as follows. It first calculates $\mathbf{V}={\sum }_{i=1}^n{V}_i$ and $\mathbf{W}={\sum }_{i=1}^n{W}_i$ to produce the aggregated signature $\sigma =(\mathbf{W},\mathbf{V})$ for all received $CRs$, then the aggregator computes the following:

$$\begin{array}{l}C=H_1(\delta \Vert \lambda );\\ N_{i1}=H_2(C{R}_i\Vert \delta \Vert I{D}_i);\\ N_{i2}=H_2(C{R}_i\Vert \delta \Vert K_{pub}{}_i)\end{array}$$

Then, the aggregator applies the following equation to verify the aggregated signature, and if the equation holds, the signatures are accepted, or else they are rejected.

$$\widehat{e}(\mathbf{V},g_1)\stackrel{?}{=}\widehat{e}(\sum _{i=1}^n{N}_{i2}{\theta }_i,\lambda )\widehat{e}(\sum _{i=1}^n{N}_{i1}{K}_{pub}{}_i+\mathbf{W},C)$$

(4)

The proof of this equation is as follows:

$$\begin{array}{ll}\widehat{e}(\mathbf{V},g_1)& =\widehat{e}({\displaystyle \sum _{i=1}^n}(N_{i2}·{\mathsf{\Lambda }}_i+({\chi }_i·N_{i1}+r_i)C),g_1)\\ & =\widehat{e}({\displaystyle \sum _{i=1}^n}{N}_{i2}·{\mathsf{\Lambda }}_i+{\displaystyle \sum _{i=1}^n}({\chi }_i·N_{i1}+r_i)C,g_1)\\ & =\widehat{e}({\displaystyle \sum _{i=1}^n}{N}_{i2}·{\mathsf{\Lambda }}_i,g_1)\widehat{e}({\displaystyle \sum _{i=1}^n}({\chi }_i·N_{i1}+r_i)C,g_1)\\ & =\widehat{e}({\displaystyle \sum _{i=1}^n}{N}_{i2}·\eta {\theta }_i,g_1)\widehat{e}({\displaystyle \sum _{i=1}^n}({\chi }_i·N_{i1}+r_i)g_1,C)\\ & =\widehat{e}({\displaystyle \sum _{i=1}^n}{N}_{i2}·{\theta }_i,\lambda )\widehat{e}({\displaystyle \sum _{i=1}^n}{N}_{i1}{K}_{pub}{}_i+{\displaystyle \sum _{i=1}^n}{W}_i,C)\\ & =\widehat{e}({\displaystyle \sum _{i=1}^n}{N}_{i2}{\theta }_i,\lambda )\widehat{e}({\displaystyle \sum _{i=1}^n}{N}_{i1}{K}_{pub}{}_i+\mathbf{W},C)\end{array}$$

Once the aggregator computes $C{R}_{agg}$ and verifies the aggregated signature $\sigma$, it computes the proof of the correctness of the aggregation proof $\rho$. The aggregator sends the generated proof to the verifier to verify the aggregation results.

$$\rho =\prod _{i=1}^n{R}_i^{{\mathsf{\Gamma }}_i}\forall (1\le i\le n)$$

The verifier receives $\langle C{R}_{agg}={\sum }_{i=1}^n{\mathsf{\Gamma }}_i,{\left\{{\rho }_i\right\}}_{i=1}^n,{\left\{GV{P}_i\right\}}_{i=1}^n\rangle$ and executes the verification process to prove the following:

$$\widehat{e}(\rho ,g_2)\stackrel{?}{=}\widehat{e}(g_1^{C{R}_{agg}},{\rm Y}).\prod _{i=1}^{n}GV{P}_i$$

(5)

and the proof of this equation is as follows:

$$\begin{array}{ll}\widehat{e}(\rho ,g_2)& =\widehat{e}(g_1^{\eta {\sum }_{i=1}^n{\mathsf{\Gamma }}_i+{\sum }_{i=1}^n{\mathsf{\Lambda }}_i{\mathsf{\Gamma }}_i},g_2)\\ & =\widehat{e}{(g_1,g_2)}^{\eta {\sum }_{i=1}^n{\mathsf{\Gamma }}_i}·\widehat{e}{(g_1,g_2)}^{{\sum }_{i=1}^n{\mathsf{\Lambda }}_i{\mathsf{\Gamma }}_i}\\ & =\widehat{e}{(g_1^{C{R}_{agg}},g_2)}^{\eta }·{\displaystyle \prod _{i=1}^n}\widehat{e}{(g_1,g_2)}^{{\mathsf{\Lambda }}_i{\mathsf{\Gamma }}_i}\\ & =\widehat{e}(g_1^{C{R}_{agg}},{\rm Y})·{\displaystyle \prod _{i=1}^n}\widehat{e}{(g_1^{{\mathsf{\Lambda }}_i},g_2)}^{{\mathsf{\Gamma }}_i}\\ & =\widehat{e}(g_1^{C{R}_{agg}},{\rm Y})·{\displaystyle \prod _{i=1}^n}GV{P}_i\end{array}$$

5.4. Computing Charging Schedules

Once the aggregator computes the $C{R}_{agg}$, it verifies the signature $\sigma$ and receives approval from the public verifier, and broadcasts the $C{R}_{agg}$ to all the ESUs. Then, if the total amount of charging demand for all priority labels is less than or equal to the available energy for charging, all charging requests are met because there is enough energy to charge all ESUs. Otherwise, a charging coordination technique should be used to select a subset of ESUs to charge without exceeding the available energy for charging $K_{max}$.

Every $ES{U}_i$ individually performs a contrast operation between the assigned $K_{max}$ and $C{R}_{agg}^l$ according to the priority label $L_m$ (from the maximum to the minimum) until it reaches the threshold priority label that can satisfy ${\sum }_{l=L_m}^{L_{max}}C{R}_{agg}^l\le K_{max}$, where $L_{max}$ is the highest priority label.

In the case of ${\sum }_{l=L_m}^{L_{max}}C{R}_{agg}^l=K_{max}$, all ESUs with priority labels greater than or equal to $L_m$ charge in this time interval, and the other ESUs need to send charging requests in the next time period. However, if ${\sum }_{l=L_m}^{L_{max}}C{R}_{agg}^l<K_{max}$, then all ESUs with priority labels greater than or equal to $L_m$ charge the amount of energy they demand, and to avoid under-utilizing the available charging energy, the remaining energy is distributed to the ESUs with priority labels $L_{m-1}$, and their charging requests are as follows:

$$PO{W}_L{}_{m-1}=\mathsf{\Omega }\times \left(\frac{C{R}_L{}_{m-1}}{C{R}_{agg}^{L_{m-1}}}\right)$$

(6)

where $PO{W}_L{}_{m-1}$ is the power assigned to the $ESU$ with priority label $L_{m-1}$, $C{R}_L{}_{m-1}$ is the original charging demand of an $ESU$ with priority label $L_{m-1}$, $C{R}_{agg}^{L_m}$ is the aggregated charging demand of the ESUs with priority label $L_{m-1}$, and $\mathsf{\Omega }=K_{max}-{\sum }_{l=L_m}^{L_{max}}C{R}_{agg}^l$.

6. Security Analysis

Our scheme leverages several techniques such as bilinear pairing, verifiable privacy-preserving data aggregation, and verifiable data-aggregated signatures, as demonstrated in Section 4. We assume that these techniques are secure and their security is proved in detail in their papers. Based on this assumption, in this section, we explain how our scheme achieves the security objectives, as explained in Section 3.2.

Proposition 1.

Our proposed scheme preserves the privacy of ESUs using a masking-based data aggregation mechanism.

Proof. 

In our proposed scheme, neither the local aggregator nor any other $ESU$ could know the charging request of any individual $ESU$. This is fulfilled by using a one-time masking-based data aggregation mechanism. Due to using the aggregation mechanism, only the aggregated charging request $C{R}_{agg}$ could be known in order to compute the charging schedule. In addition, the aggregation mechanism prevents linking charging requests with the identities of the ESUs. This is because ESUs use different masking values in each request so that two charging requests with the same demands and belonging to the same $ESU$ are different. □

Proposition 2.

External eavesdroppers cannot infer any sensitive information about consumers.

Proof. 

In our proposed scheme, the SoC and TCC values are masked with random numbers generated by the $DRG$, and the seed of the $DRG$ is a secret value shared between two ESUs and is computed using the $KAP$ technique. Consequently, external eavesdroppers who intercept the charging requests submitted in our proposed scheme cannot obtain the SoC and TCC or the charging schedule of any $ESU$ because it is infeasible to compute the masked random values shared among the ESUs. □

Proposition 3.

Our proposed scheme thwarts collusion attacks.

Proof. 

Our proposed scheme can thwart collusion attacks since collusion between ESUs does not result in acquiring the SoC or TCC values of any $ESU$ due to the use of the different masking keys shared among the ESUs. On the other hand, the nature of the blockchain prevents any kind of collusion between the participants. □

Proposition 4.

Our proposed scheme does not suffer from a single point of failure.

Proof. 

Due to the decentralization nature of the blockchain network, our proposed scheme is robust and fortified against a single point of failure, which the centralized schemes suffer from. In addition, our charging coordination mechanism is executed by the ESUs in a decentralized way and, consequently, it is robust against the single point of failure. □

Proposition 5.

Our proposed scheme counters attacks targeting availability.

Proof. 

Our proposed scheme thwarts $DoS/DDoS$ attacks. In these attacks, the attacker tries to fully or partially suspend the charging coordination mechanism, e.g., by targeting a server or a central unit in the case of centralized systems. However, in order to successfully execute these attacks in our decentralized charging coordination mechanism, the attacker should target all ESUs or the majority of them, which is practically infeasible. □

Proposition 6.

Our scheme thwarts replay attacks.

Proof. 

In replay attacks, the attackers record messages submitted by the ESUs and replay them later, for example, to impersonate ESUs or launch $DoS$ attacks. In our proposed scheme, the charging request messages have a common state value and timestamp, which match a specific time interval. Therefore, if the aggregator finds out that one of them is unmatched, it is discarded. □

Proposition 7.

Our scheme counters impersonation, forgery, and data modification attacks.

Proof. 

All the messages in our proposed scheme are signed by ESUs to guarantee their integrity and prove that they are submitted by authorized clients. Consequently, impersonation, forgery, and data modification attacks are infeasible since to launch these attacks, the attackers need to know the secret keys of the ESUs to be able to compute the valid signatures. □

Proposition 8.

Our proposed scheme is secure against malicious aggregators.

Proof. 

In our scheme, malicious aggregators that want to infer sensitive information or report false aggregated values can be identified using a verifiable aggregation technique as follows. First, in our scheme, the aggregator cannot obtain an individual $CR$ and can only compute the $C{R}_{agg}$. Second, after the completion of the aggregation, the aggregator generates proof to ensure the correctness of the aggregation process and sends it to a validator (verifier) through the blockchain network. At the same time, each $ESU$ sends a $GV{P}_i$ to use in the verification process. Thus, it is practically impossible that the aggregator can infer any information relevant to the individual $CRs$ or manipulate the aggregation results. □

Proposition 9.

Our proposed scheme guarantees the integrity and transparency of the charging scheduling process.

Proof. 

Our scheme can ensure the integrity and transparency of the charging process because all charging requests of all ESUs are recorded in a shared and immutable ledger, whose contents are verified by the blockchain validators through a predetermined consensus algorithm and cannot be altered. □

7. Performance Analysis

In this section, we evaluate our proposed scheme. First, we implement the scheme and evaluate it in terms of communication and computation overheads and this evaluation is called off-chain. Then, in the second part of the evaluation, on-chain, we demonstrate a proof-of-concept implementation of the blockchain side in our proposed scheme and assess its feasibility

7.1. Off-Chain

In this subsection, we evaluate the performance of our proposed scheme in terms of communication and computation overheads.

7.1.1. Communication Overhead

In this subsection, we calculate the size of all packets in our scheme to measure the communication overhead. We consider that the masked value of a charging request is 16 bytes, the timestamp is 8 bytes, and the size of an individual signature is 112 bytes.

Table 2. Communication overhead of our proposed scheme.

Data	Size “Bytes”
Charging Demand	16
Timestamp	8
Individual Signature	112

summarizes the items sent from each $ESU$ to the blockchain validators and their sizes. The calculated sizes of all packets are very small, which means that the communication overhead is reasonable.

7.1.2. Computation Overhead

In this subsection, we evaluate the performance of our proposed scheme in terms of computational overhead. For the purpose of the experimental assessment, the simulation environment is set up to measure the computing time of the proposed scheme, in particular, the computing time for the composition of a charging request, the aggregation of the charging requests, and the verification of them. The details are as follows.

Environment setup: The simulation environment was set up in a Linux Ubuntu (64-bit) V20.04.3 LTS with an 11th gen intel(R) Core(TM) [email protected] GHz processor and 16.0 GB memory. We used a supersingular elliptic curve with an asymmetric type 3 pairing size of 224 bits (MNT224 curve) for bilinear pairing and an $SHA-2$ hash function.

Simulation: In the simulation, the computation overhead was mainly due to the computation of several cryptosystems. To introduce an estimation for the next performance evaluation, we focused on the computation overhead of some of the cryptographic operations.

Table 3. The time consumption of the fundamental cryptographic operations.

Function	Time “ms”
Pairing	3.25
Hashing	0.04
Multiplication	0.00
Exponentiation	0.38
Addition	0.00

summarizes the time consumption of the fundamental cryptographic operations in our proposed scheme such as the scalar multiplication $\left(M\right)$ in ${\mathbb{G}}_1$, pairing $\left(P\right)$, hash function $\left(H\right)$, exponentiation $\left(E\right)$, and addition operation $\left(A\right)$.

In the system initialization phase, all the operations that were run in this phase were offline and occurred every long period (week or month) and sometimes only once. This phase is operated by the $KMC$ site and includes n exponentiation operations over $\mathbb{G}$ to compute $R_i$, calculating $P{V}_i$, which needs 2n exponentiation operations over $\mathbb{G}$ and n bilinear pairing operations $(3\times n\times E)+(n\times P)+(2\times n\times M)$. In the submission of charging requests phase, it is taken into consideration that all operations are carried out individually, and therefore, the overhead cost on the ESUs is $E+(2\times H)+(3\times M)$ to compute a $CR$ message. In the third phase, upon receiving the charging requests, the aggregator aggregates the incoming charging request, verifies the aggregated signature, and computes the proof of the correct aggregation. The aggregation process needs a simple summation operation and its computation time can be ignored, whereas the verification of the aggregated signature takes $(3\times P)+(2\times n\times M)+(n+1)\times H$ and the proof generation takes $(n\times M)+(n\times E)$, where n is the number of ESUs. In the final phase, the computing charging schedules phase, all operations in the phase can be ignored because they are offline.

Table 4. Computation overhead of our proposed scheme.

Phase	Entity	Total Operations	Computation Overhead “ms”
System Initialization Phase	$KMC$ (Off-line)	$3nE+nP+2nM$	$4.4n$
Submission Phase	$ESU$	$P+2H+3M$	0.47
Aggregation Phase	Aggregator	$3P+3nM+nE+(n+1)H$	$0.08+0.42n$
Computing Charging Schedules Phase	$ESU$	Simple Comparison	-

summarizes the computation overhead of our proposed scheme in terms of phases, and Figure 5 summarizes the time consumed in terms of the $ESU$ numbers for all phases.

In our proposed scheme we used VDAS, which performed well as the number of ESUs increased, as shown in Figure 5. In addition, we combined the VDAS scheme with a masking technique, which added a privacy layer by hiding the messages, with a negligible increase in the computation overhead.

Using the cryptographic operations and their computational times, we conveniently compared the computation time of several aggregate signature schemes’ “individual signing phase” [15,42,43,44,45,46]. Figure 6 shows that the aggregate signature schemes CSZ [44] and VDAS [15] achieved better performance than the other aggregate signature schemes. However, the performance of CSZ depended on the number of ESUs, whereas CSZ performed well when the number of ESUs was less than or equal to five; otherwise, its computation overhead increased significantly with the number of ESUs.

7.2. On-Chain Overheads

An overview of the proof-of-concept implementation of our proposed scheme was introduced using the hyperledger Caliper tool V0.3.2. For on-chain overheads, a chain code was implemented on the hyperledger fabric on an instance of Linux Ubuntu (64-bit) V20.04.3, and LTS was used on a DELL XPS 15 with a 2.20 GHz Intel Core i7 processor.

More specifically, we implemented a private blockchain that runs using different instances. Figure 7 shows the impact of varying the number of transactions $(\Delta )$ at different transactions per second $\left(tps\right)$ on the throughput and latency. First, in the read transactions in Figure 7a, it can be seen that as $tps$ increases, the throughput and latency remain fixed with $\Delta$ = 1000 (gray bar). However, with $\Delta =$ 5000 and 10,000 (green and black bars), respectively, the throughput and latency increase. The green bar achieves its maximum throughput and latency with $tps=200$ but the black bar achieves its maximum throughput and latency with $tps=300$. Secondly, in the write transactions in Figure 7b, it can be seen that the three bars vary as $tps$ increases, where with $tps=150$, the maximum throughput and latency are performed by $\Delta =1000$, whereas with $tps=200$, the maximum throughput and latency are performed by $\Delta =5000$. However, $\Delta$ = 10,000 achieves the maximum throughput and latency when $tps=300$. This means that our scheme provides high throughput with an acceptable range of latency with high $(\Delta )$ in both reading and writing transactions.

Figure 8 shows the impact of varying the number of transactions at different transactions per second on the blockchain’s error rates. Notice that when $\Delta =1000$, the error rate remains constant at different $tps$ in both read and write transactions. However, in the case of $\Delta =5000$, the error rate remains fixed until $tps=200$ in both read and write transactions. After that, the error rate increases slightly in read transactions and increases more in write transactions. When $\Delta$ = 10,000, the error rate remains fixed until $tps=200$ and increases sharply in both read and write transactions.

It is found that if $\Delta =1000$, any $tps$ can work because in read transactions, the throughput, latency, and error rate remain constant. However, in write transactions, the throughput and latency increase as $tps$ increases with a fixed error rate, whereas the throughput and latency perform better than other values with $tps=150$ in write transactions. For $\Delta =5000$, the maximum performance is achieved when $tps=200$ in both read and write transactions, with minimum error rates in both cases. If $\Delta$ = 10,000, the maximum throughput and latency are achieved with $tps=300$ but with maximum error rates in both read and write transactions. However, with $tps\le 200$, the throughput and latency achieve maximum values relevant to the other $\Delta$ in read transactions only. We can see that our scheme is efficient in both reading and writing transactions even with very a high number of $\Delta$ with an acceptable range of latency and very small error rates.

8. Conclusions

In this paper, a privacy-preserving charging coordination scheme using a blockchain has been proposed. The blockchain is used to create a secure and transparent system to prevent a single point of failure and thwart $DoS$ attacks. Privacy preservation is realized by a verifiable aggregation mechanism integrated with a masking technique and an aggregated signature technique to ensure the integrity of the received data and verify the identity of the ESUs. This verifiable aggregation mechanism enables the validator (local aggregator) to aggregate charging requests sent by the ESUs without knowing the individual charging requests to preserve privacy. Meanwhile, the correctness of the aggregation results can be checked by validators. In this way, malicious aggregators that send incorrect aggregation results can be identified. In addition, all messages sent by the ESUs are digitally signed to allow only the authorized ESUs to participate in the verifiable data aggregation process and the local aggregator to verify the integrity of the received data and authenticate the senders by verifying an aggregated signature instead of verifying the individual signatures to reduce the overhead. Security analysis, experiments, and simulations on both sides (off-chain and on-chain) were carried out to analyze the security of our scheme and evaluate its performance in terms of communication and computation overheads. The results confirm that the communication overhead in terms of message sizes is acceptable. We used a VDAS aggregate signature scheme, which was efficient, especially when increasing the number of ESUs. On the other hand, the on-chain experimental results indicated that our proposed scheme is efficient in both reading and writing transactions even with a very high number of transactions with acceptable latency and very small error rates. Finally, our proposed scheme preserves the privacy of consumers, the communication and computation overheads are acceptable, and the performance of the blockchain network is acceptable with a high number of ESUs.