Task Offloading of Parked Vehicles Edge Computing Based on Differential Privacy Hotstuff

Abstract

The integration of blockchain into parked vehicle edge computing (PVEC) has emerged as a promising approach to mitigate the inherent trust challenges in distributed and untrusted computing environments. However, during task offloading and consensus, vehicles are vulnerable to location information disclosure, leading to privacy leakage. To address this problem, we propose a location differential privacy-enabled blockchain PVEC (DBPVEC) framework to protect location information during offloading and consensus. Specifically, we design a location differential privacy mechanism based on the Laplace mechanism and theoretically prove that it satisfies ε-differential privacy. This mechanism perturbs vehicles’ locations, and a privacy-preserving offloading strategy is designed to enhance the Hotstuff consensus and protect location privacy in edge computing. Subsequently, we formulate a joint optimization problem, considering system energy consumption, latency, and privacy strength. To solve it, we design a two-layer deep reinforcement learning (DRL) algorithm, with a Deep Q-Network (DQN) as the upper layer and a Deep Deterministic Policy Gradient (DDPG) as the lower layer, to determine the optimal offloading strategy. The experimental results demonstrate that our scheme achieves significant reductions compared to the two baseline methods: the total cost decreases by 68.31% and 63.25%, energy consumption by 9.96% and 16.27%, and delay by 31.46% and 18.07%, respectively. Moreover, it effectively preserves vehicle location privacy during task offloading and consensus while maintaining favorable performance in energy consumption and latency.

1. Introduction

Parked vehicles (PVs) provide abundant communication and computing resources for vehicle edge computing (VEC), significantly alleviating the shortages of computing, communication, and storage resources that are inherent in traditional VEC, thereby forming the paradigm of parked vehicle edge computing [1]. Task offloading, a key technology in PVEC, leverages the abundant idle resources of PVs by transferring computational tasks from terminal devices to them. This approach enables rapid task execution and conserves device battery power while enhancing the overall system performance [2], thereby providing users with low-latency and high-efficiency computing services.

However, because task offloading and transactions in VEC are conducted in open wireless environments, ensuring transparency, immutability, and overall system security for multi-party resource transactions becomes challenging in complex scenarios [3]. This inherent vulnerability gives rise to significant trust and security challenges in task offloading for PVEC. To address these issues, researchers have introduced blockchain into task offloading to establish a trusted offloading environment. Blockchain and PVEC share a common distributed network architecture and possess comparable storage and computing capabilities [4], which naturally facilitate the integration of blockchain into PVEC task offloading. Through its transparent and tamper-proof consensus mechanism, blockchain ensures data integrity and immutability, thereby enhancing trust among participants [5,6].

Despite the trust guarantees provided by blockchain, the privacy of participating vehicles remains vulnerable in wireless environments. In particular, location information can be leaked during both the task offloading phase and the consensus phase. For example, an adversary could deploy rogue roadside units to monitor wireless signals and infer a vehicle’s location by analyzing the timing and power of the transmitted messages [7]. Alternatively, by observing which PVs consistently participate in consensus rounds in a given geographic area, an attacker can track their movement patterns, even if the transaction content is encrypted. Such location leakage can lead to serious consequences like physical tracking or targeted attacks.

Several existing studies have attempted to integrate privacy-preserving mechanisms with blockchain in vehicular networks. However, these works either focus on identity privacy or data confidentiality and do not specifically address location privacy during task offloading [8,9]. More importantly, they treat privacy protection as an independent module, neglecting its impact on system performance metrics such as latency and energy consumption. The additional noise injected for privacy inevitably degrades the communication quality (e.g., Signal-to-Interference-plus-Noise Ratio, SINR) among consensus nodes, which in turn affects the consensus efficiency. To the best of our knowledge, no prior work has jointly optimized the privacy strength and system performance in a blockchain-based task offloading framework for PVEC.

Beyond privacy concerns, the architectural design of existing blockchain-based task offloading frameworks also poses scalability challenges. Most of them adopt a single-chain architecture deployed on Roadside Units (RSUs), which handle all consensus tasks. As the number of vehicles grows, the consensus overhead on RSUs increases dramatically, leading to higher latency and communication bottlenecks. Moreover, to optimize offloading decisions under dynamic environments, recent studies have employed DRL algorithms. However, these algorithms typically use a single-layer network that struggles with the inherent mixed discrete-continuous action space. The single network must simultaneously handle both types of actions, resulting in high computational complexity, slow convergence, and poor sample efficiency—issues that are particularly critical in resource-constrained vehicular environments. Therefore, designing a scalable and computationally efficient framework that jointly addresses privacy, security, and performance remains an open challenge.

To overcome the aforementioned issues, a DBPVEC offloading framework is proposed. Compared with traditional blockchain-based PVEC, this framework incorporates parked vehicles as consensus nodes and forms a dual-chain structure with RSUs, thereby enhancing the scalability. In addition, location differential privacy is employed during the user offloading process to protect users’ location privacy. Moreover, during the Hotstuff consensus process, the locations of PVs are perturbed by adopting the location differential privacy mechanism to ensure that their location information is not divulged. Then, a two-layer DRL algorithm is developed to perform joint optimization of the system energy consumption, latency, and privacy strength, striking a balance between the system performance and security. The primary contributions of this study are listed as follows.

• We propose a novel BPVEC task offloading framework with location differential privacy. In this framework, parked vehicles are introduced as consensus nodes and, together with RSUs, form a dual-blockchain architecture. This architecture establishes a trusted task offloading environment while improving scalability. In addition, it incorporates the location differential privacy to protect the location privacy of both users and consensus nodes, thereby effectively ensuring the security of task offloading.
• We design a location differential privacy mechanism based on the Laplace mechanism. Considering the impact of location perturbation on the wireless communication quality, we leverage the low communication complexity of the Hotstuff consensus. We then integrate the location differential privacy mechanism with the Hotstuff consensus to construct a novel location privacy-enhanced Hotstuff consensus algorithm. Specifically, before the parked vehicle consensus nodes execute the Hotstuff consensus, their locations are perturbed with a consideration of the consensus energy consumption and latency to mitigate the impact on system performance.
• We build a joint optimization problem based on the system energy consumption, latency and privacy strength. By adopting DQN as the upper layer and DDPG as the lower layer, a two-layer DRL model is established to determine the optimal offloading to roadside unit ratio, privacy budget, number of consensus nodes and block size.
• We conduct simulation experiments to evaluate the performance of our proposed scheme. The results demonstrate that our approach not only preserves the vehicle’s location privacy during task offloading and consensus, but also achieves favorable performance in terms of energy consumption and latency.

The rest of this paper is organized as follows. Section 2 reviews the recent related work on blockchain-based task offloading and privacy-preserving task offloading. Section 3 introduces the principle of differential privacy protection. The system model of DBPVEC is designed in Section 4. Section 5 discusses the joint optimization problem of system energy consumption, latency, and privacy strength. Section 6 designs the location differential privacy Hotstuff consensus algorithm and establishes a two-layer DRL model. In Section 7, we evaluate the performance of the proposed scheme, based on the experimental results. Finally, Section 8 concludes this paper.

2. Related Work

2.1. Blockchain for Task Offloading

Traditional PVEC adopts edge servers or cloud servers to centrally manage vehicle information and transactions during task offloading, making the system prone to single-point failures and vulnerable to data tampering. To address this, researchers have integrated blockchain into edge computing. For instance, the literature [10] combined blockchain with edge computing to tackle the user trust management issue, protecting the information privacy of user vehicles in the offloading process and resolving the bottleneck problem caused by a single edge computing node. Similarly, the works in [11,12] deployed blockchain on edge servers to achieve cross-regional identity recognition and trust management. While these works effectively utilized blockchain for identity authentication, they stopped short of leveraging it to build a fully trusted network for secure task offloading and transactions. To build a trusted network, Ren et al. [13] integrated Software-Defined Networking (SDN) into a traditional network architecture, where a consortium blockchain served as the infrastructure to share network topology information across SDN controllers, establishing a trusted offloading environment. The study in [14] proposed a blockchain-based vehicle edge computing (BEVEC) framework to construct a trusted offloading network; this framework relied on DPoS to ensure data accuracy and integrity, and designed a system utility function to measure the performance of BEVEC. Despite establishing trust, these frameworks often overlooked the challenge of user selfishness. To incentivize resource sharing while ensuring user information security, reference [15] adopted multi-step smart contracts for secure resource sharing and devised a BFT-based PoS consensus. However, this approach lacked joint optimization of system performance. To further enhance the system performance and blockchain efficiency, Liang et al. [16] developed a blockchain-based decentralized task offloading framework that adopts a multi-factor score to dynamically allocate tasks among computing nodes. The PoS consensus and smart contract-based dynamic pricing were combined to incentivize participation and balance workloads, leading to reduced latency and improved system efficiency. This work represented a step towards joint optimization, but its focus remained primarily on offloading efficiency. A more comprehensive integration was presented in [17] with the FBMTO framework, which explicitly balanced the costs and benefits of offloading. The consensus mechanism is a key factor affecting the blockchain performance. Therefore, improving the efficiency of the consensus mechanism is crucial for enhancing the system performance. The literature [4,18] improved PBFT and conducted joint optimization to enhance system performance. Considering the impact of parking, Huang et al. [19] utilized blockchain technology to implement decentralized PVFC, modeling and solving the optimal smart contract design problem to minimize the total payment amount for users, with similar studies in [20,21]. However, the aforementioned studies lack consideration of the information leakage of vehicles during the offloading and consensus processes, which greatly threatens vehicle security.

2.2. Differential Privacy for Task Offloading

To protect the privacy of user data during task offloading, the works in [22,23] focused on the data privacy of offloading tasks, applying differential privacy to protect offloaded data and realizing task offloading while safeguarding user data privacy. In light of the features of user offloaded data, Tchaye-Kondi et al. [24] utilized differential privacy to let edge devices perturb sensitive data features with random noise before transmission to untrusted central servers, which effectively preserved the privacy of sensitive information. While effective for the data content, these methods did not protect the contextual privacy of the task offloading. In [25], the authors leveraged deep learning to optimize task offloading while incorporating differential privacy to safeguard parameter privacy during deep learning execution. The literature [26] employed a histogram-driven local differential privacy algorithm and proposed the k-neighbor joint optimization algorithm (K-NJTA) for task offloading and resource allocation to optimize the global latency of task execution. Although these studies integrated privacy, they treated it as an external constraint, rather than an integral part of the optimization objective. Aimed at the security, latency, and overhead concerns in mobile edge computing, Zhang et al. [27] adopted differential privacy to perturb users’ location information before task offloading. This mechanism prevented malicious edge servers from accessing user privacy, while the performance of the edge computing system was also taken into consideration. Similar efforts have been made in references [28,29]. However, the above studies focused on location privacy protection in single-edge server scenarios. In multi-server environments, the study in [30] introduced an innovative location privacy-preserving offloading framework, where each user perturbs their actual location in a reasonable perturbation region and was provided with differential privacy guarantees. To realize the dynamic adjustment of location perturbation, the works in [31,32] introduced reinforcement learning on the basis of the aforementioned work, designing a DQN-DP task scheduling strategy to dynamically select offloading strategies and location perturbation strategies, effectively reducing the selection of high-risk state-action pairs. Nonetheless, the aforementioned studies applied differential privacy to locations with the distance between the server and the user as a metric, instead of directly describing the user’s location.

As shown in

Table 1. Comparative summary.

Study	Blockchain	Privacy Mechanism	Optimization Technique	Limitations
[10,11,12]	Consortium Blockchain	None	None	Only focuses on identity authentication
[13]	Consortium Blockchain	None	None	Complex network architecture
[14]	DPoS	None	DRL	Lacks incentive mechanism
[15]	BFT-based PoS consensus, Smart Contract	None	Contract-Based Approach	Lacks joint optimization of system performance
[16,17]	PoS consensus, DPoS	None	DQN	Ignores the impact of consensus
[4,18]	Improved PBFT	None	DRL	Ignores information leakage during consensus
[19,20,21]	Smart Contract, PBFT, PoW	None	Game Theory, DRL	Ignores sensitive information privacy leakage
[22,23,24]	None	Differential Privacy	None	Only protects data content
[25]	None	Differential Privacy (Deep Learning Parameters)	DRL	Treats privacy as an external constraint
[26]	None	Local Differential Privacy (Histogram-Driven)	K-NJTA	Treats privacy as an external constraint
[27,28,29]	None	Differential Privacy (Geographic Location Perturbation)	WOPP, RL	Only focuses on location privacy in single-edge server scenarios
[30,31,32]	None	Differential Privacy	DRL	Does not directly describe user location

, existing works lack a BPVEC task offloading scheme that protects the location privacy of users and parked consensus nodes while ensuring offloading performance. To address this gap, this paper designs a DBPVEC offloading framework, which achieves secure offloading and transactions while protecting the location privacy of both users and parked consensus nodes. In addition, we jointly optimize differential privacy and system performance.

3. Differential Privacy Mechanism

Differential privacy is a method for protecting data privacy. It perturbs the original data by adding noise, ensuring that the impact of any single record on the output is always below a certain threshold, thereby preventing attackers from inferring sensitive information through differential analysis. Based on different parameter configurations, differential privacy is classified into ε-differential privacy and (ε, δ)-differential privacy. This paper employs ε-differential privacy, so the principle of ε-differential privacy is introduced below.

Definition 1

(ε-differential privacy definition [33]). Let D₁ and D₂ be adjacent datasets, and let M denote the randomized query mechanism. Then, the algorithm and all possible output sets $Y\subseteq Rang(\mathcal{M})$ satisfy

$$\mathrm{Pr}[\mathcal{M}(D_1)\in Y]\le e^{\epsilon }\times \mathrm{Pr}[\mathcal{M}(D_2)\in Y]$$

(1)

Where ε denotes the privacy budget. Rang(M) denotes the set of all possible outputs of the randomized mechanism M, and Pr[∙] represents the probability of an event.

Definition 2

(Global Sensitivity [33]). For any query function f: $\mathcal{D}\to R^d$, the global sensitivity of f is defined as

$$\mathsf{\Delta }f=\underset{D_1,D_2\in \mathcal{D}}{\max }‖f(D_1)-f(D_2)‖$$

(2)

Definition 3

(Laplace Mechanism [34]). For an arbitrary function f: $\mathcal{D}\to R^d$, let $\mathcal{M}$ be the query mechanism. Given a privacy budget ε > 0, the Laplace mechanism is defined $\mathcal{M}(D)=f(D)+(Y_1,Y_2\dots ,Y_k)$.

Where $Y_i\stackrel{i.i.d.}{\sim }Lap(0,\mathsf{\Delta }f/\epsilon )$. Let β = Δf/ε. The Laplace distribution Lap(0,β) with β > 0 has the probability density function (pdf) [30]:

$$f_{Lap}(x;0,\beta )=\frac{1}{2\beta }{e}^{-{\displaystyle \frac{\left|x\right|}{\beta }}},x\in R$$

(3)

Theorem 1 

([34]). The Laplace mechanism preserves ε-differential privacy.

On the basis of the Laplace mechanism, an ε-differential privacy mechanism dedicated to location privacy protection is developed in this paper.

4. System Model

4.1. DBPVEC Offloading System Framework

To ensure task offloading security and to protect users’ and PVs’ location privacy in the task offloading of PVEC, the DBPVEC task offloading framework is proposed. The system block diagram is shown in Figure 1. The proposed framework involves multiple entities, namely user vehicles, PVs, RSUs, as well as VEC servers connected to RSUs. Among these entities, the RSUs and their connected servers form the main chain, while the PV network constitutes the sub-chain, together forming a dual-blockchain architecture. User vehicles can offload computing tasks either to RSUs or to PVs, thereby enabling distributed computation offloading and transaction processing.

When a user demands computing services, it sends a request message to an RSU or a PV. After the request legitimacy is verified by the RSU or PV, the computing task is offloaded by the user. To safeguard the user’s location privacy, location differential privacy is adopted to perturb the user’s location throughout the entire offloading process. After receiving the computing task, the RSU and PV conduct service transactions. They then form blocks containing task offloading and transaction records through a consensus mechanism and upload them to the blockchain. To prevent storage desynchronization in the sub-chain caused by the departure of PVs, the sub-chain uploads its blocks to RSUs after each consensus execution. To protect the location privacy of PVs during the consensus process, location differential privacy is used to perturb the locations of PVs, and the Hotstuff consensus mechanism is combined to complete the operation of the blockchain. To balance the system performance, consensus performance, and privacy security, a two-layer DRL structure is designed for optimization. Accordingly, this paper mainly focuses on integrating location differential privacy with the consensus mechanism to implement distributed task offloading with privacy protection, while maintaining a satisfactory system performance. For ease of reference, the key notations are summarized in

Table 2. Explanation of notations.

Notations	Explanation
$C_{pk}^{exe},C_{rj}^{exe}$	CPU cycles per unit task size required for RSU and PV computing
d0	Wireless far-field reference distance
$d_{i,j}^d,d_{i,k}^d$	Distance from perturbed PV to the receiving vehicle and the interfering vehicle
Dqi	Task size for useri
DBv	Block size
DKL	Kullback–Leibler (KL) divergence of differential privacy
$E_{total}^B$	Consensus energy consumption
Epai, ERSUi	RSU and PV energy consumption for computational tasks
Etotal	Total energy consumption of the system
fpk, frj	Computational capacity of PVk and RSUj
N0	Noise power of the wireless channel
Pt	Wireless transmission power
Ri,j	Communication transmission rate after location perturbation
Ttotal	Total delay of the system
Tpai, TRSUi	PV and RSU delay for processing computational tasks
Wb	Wireless communication bandwidth
α	Path loss factor
σ	CPU cycles required for generating or verifying signatures
φRSUi	Proportion of task offloading to RSU by useri
η	Transceiver decision factor
θ	CPU cycles required for generating or verifying the Message Authentication Code (MAC)
κv, κr	Capacitive switching coefficients for vehicles and RSUs
ϖ	Average transaction size of blockchain

.

4.2. Network Model

We divide time, T, into sufficiently small time slots, t. For each slot t, the communication topology between vehicles has no variation. Assume that there are U users in the region, and let U = {1, 2, …, U} denote the set of users with task offloading requests, S RSUs and P PVs, $𝒮$ = {1, 2, …, S} and $𝒫$ = {1, 2, …, P} denote their set, respectively. Then, according to references [35,36], the Signal-to-Interference-plus-Noise Ratio (SINR) of RSU or PV received from other vehicles is expressed as follows:

$$SIN{R}_i(t)={\displaystyle \frac{P_t\eta {(d_0/d_i^s(t))}^{\alpha }}{N_0+{\displaystyle {\sum }_{j=1,j\ne i}^N[P_t\eta {(d_0/d_{i,j}^s(t))}^{\alpha }]}}}$$

(4)

wherein P_t is the transmission power; η is the transceiver determination coefficient; d₀ and $d_i^s(t)$ represent the far-field reference distance and the distance from the RSU or PV to the receiving vehicle, respectively; $d_{i,j}^s(t)$ is the distance from the RSU or PV to the interfering vehicle; N₀ is the noise power; and α is the path loss coefficient.

4.3. Location Differential Privacy Model

Based on the Laplacian differential privacy mechanism, this section designs the location differential privacy model. Specifically, based on the two-dimensional Laplace mechanism, a location Laplace mechanism is defined, which serves as an unclipped location perturbation mechanism. Since the range of the two-dimensional Laplace mechanism is (−∞, +∞), a clipping function is introduced to confine the location range within [0, lmax].

Definition 4. 

Let two adjacent locations be denoted as p₁ = (u₁, v₁) and p₂ = (u₂, v₂), respectively. Then, the global sensitivity of the location data is defined as the maximum value of the L₁ distance between adjacent locations:

$$\mathsf{\Delta }{f}_L=\underset{{\mathit{p}}_1,{\mathit{p}}_2}{\max }(\left|u_1-u_2\right|+\left|v_1-v_2\right|)$$

(5)

Definition 5.

Unclipped location perturbation mechanism $ℳ$′:$\mathcal{D}\to R^2$ is defined as

$${\mathcal{M}}^{\prime }(\mathit{p})=\mathit{p}+\mathit{\eta }$$

(6)

In Equation (6), η = (η_x, η_y), ${\eta }_x,{\eta }_y\stackrel{i.i.d.}{\sim }Lap(0,\beta )$, $\beta =\mathsf{\Delta }{f}_L/\epsilon$, the pdf of mechanism $ℳ$′ is

$$f_{M^{\prime }}(\left.\mathit{q}\right|\mathit{p})={\displaystyle \frac{1}{4\beta }}\exp \left(-{\displaystyle \frac{\left|x-u\right|+\left|y-v\right|}{\beta }}\right),\mathit{q}=(x,y)\in R^2$$

(7)

Definition 6.

Location differential privacy mechanism $ℳ$_L: $\mathcal{D}\to \mathcal{D}$ is defined as the composite function of the unclipped mechanism and the clipping function, ${\mathcal{M}}_L=clip\circ {\mathcal{M}}^{\prime }$, i.e., for the input location p = (u,v) ∈ D:

$${\mathcal{M}}_L(\mathit{p})=clip({\mathcal{M}}^{\prime }(\mathit{p}))=(clip(u+{\eta }_x),clip(v+{\eta }_y))$$

(8)

Lemma 1 ([34]).

If mechanism $ℳ$ satisfies ε-differential privacy, then the mechanism obtained by performing any deterministic mapping on its output also satisfies the ε-differential privacy.

Theorem 2.

The location differential privacy mechanism $ℳ$_L satisfies the ε-differential privacy.

Proof. 

Let p₁ = (u₁, v₁) and p₂ = (u₂, v₂) be any two adjacent locations. For any q = (x,y) ∈ R², we have the following:

$${\displaystyle \frac{f_{M^{\prime }}(\left.\mathit{q}\right|{\mathit{p}}_1)}{f_{M^{\prime }}(\left.\mathit{q}\right|{\mathit{p}}_2)}}=\exp \left({\displaystyle \frac{\left|x-u_2\right|+\left|y-v_2\right|-\left|x-u_1\right|-\left|y-v_1\right|}{\beta }}\right)$$

(9)

Based on the triangle inequality, we have

$${\displaystyle \frac{f_{M^{\prime }}(\left.\mathit{q}\right|{\mathit{p}}_1)}{f_{M^{\prime }}(\left.\mathit{q}\right|{\mathit{p}}_2)}}\le \exp \left({\displaystyle \frac{\left|u_1-u_2\right|+\left|v_1-v_2\right|}{\beta }}\right)\le \exp \left({\displaystyle \frac{\mathsf{\Delta }{f}_L}{\beta }}\right)=\exp \left(\epsilon \right)$$

(10)

Therefore, $ℳ$′ satisfies the ε-differential privacy. According to Definition 6, the mechanism $ℳ$_L is the composition of $ℳ$′ and a deterministic clipping function. On the basis of Lemma 1, $ℳ$_L also satisfies the ε-differential privacy. □

In addition, according to [37], we use the KL divergence as a measure of the privacy strength of differential privacy, see Formula (11).

$$D_{KL}={\displaystyle {\mathbf{\int }}_0^{l_{max}}{\displaystyle {\mathbf{\int }}_0^{l_{max}}f(x,y\left|u_1,v_1\right.)}}\ln {\displaystyle \frac{f(x,y\left|u_1,v_1\right.)}{f(x,y\left|u_2,v_2\right.)}}\mathit{dxdy}$$

(11)

4.4. Task Offloading Model

To protect the vehicle’s location privacy during task offloading, before the user performs offloading, the user’s location is perturbed, using a location differential privacy mechanism to obtain the communication transmission rate after location perturbation:

$$R_{i,j}(t)=W_B\cdot {\log }_2\left(1+{\displaystyle \frac{P_t\eta {(d_0/d_{i,j}^d(t))}^{\alpha }}{N_0+{\displaystyle {\sum }_{k=1,k\ne i,k\ne j}^N[P_t\eta {(d_0/d_{i,k}^d(t))}^{\alpha }]}}}\right)$$

(12)

where W_B is the wireless communication bandwidth and $d_{i,j}^d(t)$ and $d_{i,k}^d(t)$ denote the distance from the perturbed PV to the receiving vehicle and the distance from the perturbed PV to the interfering vehicle, respectively.

Throughout the user request procedure, the computing task of the user can be implemented either on the PV or on the edge server connected to the RSU. Let φ_RSUi(t) be the proportion of task offloaded by the user to the RSU. The delays generated by offloading to the RSU and the PV for the computing service are described in Formulas (13) and (14), respectively.

$$T_{\mathit{pai}}(t)=\underset{k}{\max }\left({\displaystyle \frac{(1-{\phi }_{\mathit{RSUi}}(t))D_{\mathit{qi}}{C}_{\mathit{pk}}^{\mathit{exe}}}{f_{\mathit{pk}}(t)}}+{\displaystyle \frac{(1-{\phi }_{\mathit{RSUi}}(t))D_{\mathit{qi}}}{R_{i,k}(t)}}\right)$$

(13)

$$T_{\mathit{RSUi}}(t)=\underset{j}{\max }\left({\displaystyle \frac{{\phi }_{\mathit{RSUi}}(t)D_{\mathit{qi}}{C}_{\mathit{rj}}^{\mathit{exe}}}{f_{\mathit{rj}}(t)}}+{\displaystyle \frac{{\phi }_{\mathit{RSUi}}(t)D_{\mathit{qi}}}{R_{i,j}(t)}}\right)$$

(14)

wherein I ∈ U, j ∈ R, k ∈ P. f_rj(t) and f_pk(t) represent the computing capabilities of RSUj and PVk, respectively. D_qi is the total task size of useri. $C_{pk}^{exe},C_{rj}^{exe}$ represent the CPU cycles consumed by the PV and RSU for processing a unit task size, respectively. Both R_i,k(t) and R_i,j(t) are the transmission rates after location perturbation.

Therefore, the energy consumption generated by useri offloading tasks to the RSU and PV for processing are as follows, respectively:

$$E_{\mathit{pai}}(t)={\displaystyle \sum _{k=1}^P\left({\kappa }_v{f}_{\mathit{pk}}{(t)}^2(1-{\phi }_{\mathit{RSUi}}(t))D_{\mathit{qi}}{C}_{\mathit{pk}}^{\mathit{exe}}+P_t\frac{(1-{\phi }_{\mathit{RSUi}}(t))D_{\mathit{qi}}}{R_{i,k}(t)}\right)}$$

(15)

$$E_{\mathit{RSUi}}(t)={\displaystyle \sum _{j=1}^R\left({\kappa }_v{f}_{\mathit{rj}}{(t)}^2{\phi }_{\mathit{RSUi}}(t)D_{\mathit{qi}}{C}_{\mathit{rj}}^{\mathit{exe}}+P_t\frac{{\phi }_{\mathit{RSUi}}(t)D_{\mathit{qi}}}{R_{i,j}(t)}\right)}$$

(16)

κ_v and κ_r are the capacitance switch coefficients of PV and RSU, respectively, and P_t is the transmission power.

4.5. Blockchain Model

During the consensus process, the PV consensus nodes communicate with each other using the transmission rate after location perturbation. Assume that PVs require σ and θ CPU cycles to generate or verify a signature and MAC, with B PV nodes participating in the consensus. The primary node is Bl, and replica nodes are Bm, where Bl, Bm ∈ B = {1, 2, 3, …, B}, and there are F Byzantine nodes. Meanwhile, let D_Bv(t) and ϖ denote the block size and average transaction size, respectively. The perturbed transmission rate is used as the communication rate for the Hotstuff consensus, which is divided into five phases. Therefore, the time delay required for each phase during the Hotstuff consensus is as follows.

New-view phase: In this phase, the replica nodes generate a QC message and a signature, which are sent to the primary node for verification. Meanwhile, the primary node is required to verify the transactions and signatures from the users. Therefore, the number of CPU cycles for primary is as follows: $O_{\mathit{Bl}}^{\mathit{new}}(t)={\displaystyle \frac{D_{\mathit{Bv}}(t)(\sigma +\theta )}{\varpi }}+\sigma +(2F+1)\theta$. The number of CPU cycles consumed by the replica nodes to generate messages and signatures is $O_{\mathit{Bm}}^{\mathit{new}}(t)=\sigma +\theta$. The sizes of the QC and signatures from the replica nodes are much smaller than that of the block, and thus the transmission delay can be ignored. The time delay generated in this phase is as follows:

$$T_{\mathit{new}}^c(t)={\displaystyle \frac{O_{\mathit{Bl}}^{\mathit{new}}(t)}{f_{\mathit{pBl}}(t)}}+\underset{\mathit{Bm}\in \mathcal{B}\backslash \mathit{Bl}}{\max }\left\{{\displaystyle \frac{O_{\mathit{Bm}}^{\mathit{new}}(t)}{f_{\mathit{pBm}}(t)}}\right\}$$

(17)

Prepare phase: After verifying the messages in the new-view phase, the primary node generates a new block on the secure branch of HighQC, signs it, and distributes the block to the replica nodes via a proposal message for verification. The replica nodes need to verify the user transactions and the new block, vote and sign the proposal message, and send them to the primary node. Therefore, the number of CPU cycles required in this phase is $O_{Bl}^{pre}(t)=\sigma +\theta$ and $O_{\mathit{Bm}}^{\mathit{pre}}(t)=2\sigma +2\theta +{\displaystyle \frac{D_{\mathit{Bv}}(t)}{\varpi }}(\sigma +\theta )$. The computing delay can be expressed as follows:

$$T_{\mathit{pre}}^c(t)={\displaystyle \frac{O_{\mathit{Bl}}^{\mathit{pre}}(t)}{f_{\mathit{pBl}}(t)}}+\underset{\mathit{Bm}\in \mathcal{B}\backslash \mathit{Bl}}{\max }\left\{{\displaystyle \frac{O_{\mathit{Bm}}^{\mathit{pre}}(t)}{f_{\mathit{pBm}}(t)}}\right\}$$

(18)

Pre-commit phase: During this phase, the primary node verifies the voting signatures from the replica nodes, aggregates them into a new signature, generates and stores a prepare-QC locally, and then broadcasts it to the replica nodes in the form of a pre-commit message. Therefore, the primary node CPU cycles require $O_{\mathit{Bl}}^{\mathit{pre}\_\mathit{com}}(t)=2\sigma +(2F+1)\theta$, and the replica nodes need to verify, vote and sign the pre-commit message, so $O_{Bm}^{pre\_com}(t)=2\sigma +2\theta$. The computing delay is

$$T_{\mathit{pre}\_\mathit{com}}^c(t)={\displaystyle \frac{O_{\mathit{Bl}}^{\mathit{pre}\_\mathit{com}}(t)}{f_{\mathit{pBl}}(t)}}+\underset{\mathit{Bm}\in \mathcal{B}\backslash \mathit{Bl}}{\max }\left\{{\displaystyle \frac{O_{\mathit{Bm}}^{\mathit{pre}\_\mathit{com}}(t)}{f_{\mathit{pBm}}(t)}}\right\}$$

(19)

Commit phase: Analogous to the pre-commit phase, the primary node verifies the votes and broadcasts the pre-commit QC to the replica nodes in the form of a commit message. Therefore, the number of CPU cycles of the primary node is $O_{Bl}^{com}(t)=2\sigma +(2F+1)\theta$, and the replica nodes’ is $O_{Bm}^{com}(t)=2\sigma +2\theta$. The computing delay is given by

$$T_{\mathit{com}}^c(t)={\displaystyle \frac{O_{\mathit{Bl}}^{\mathit{com}}(t)}{f_{\mathit{pBl}}(t)}}+\underset{\mathit{Bm}\in \mathcal{B}\backslash \mathit{Bl}}{\max }\left\{{\displaystyle \frac{O_{\mathit{Bm}}^{\mathit{com}}(t)}{f_{\mathit{pBm}}(t)}}\right\}$$

(20)

Decide phase: The primary node combines the commit-vote votes received from the replica nodes into a commitQC, places it on the decide message, and broadcasts it. After obtaining the commitQC from the deciding message, the replica nodes regard the current proposal as confirmed and start a new phase. Thus, the CPU cycles for the primary node are $O_{Bl}^{dec}(t)=2\sigma +(2F+1)\theta$, while those for the replica nodes can be ignored. The computing delay is as follows.

$$T_{dec}^c(t)={\displaystyle \frac{O_{Bl}^{dec}(t)}{f_{pBl}(t)}}$$

(21)

In summary, the transmission delay of the consensus process mainly comes from the last four phases:

$$T_{\mathit{totalpa}}^{\mathit{tr}}(t)=4\times \left(\underset{\mathit{Bm}\in \mathcal{B}\backslash \mathit{Bl}}{\max }\left\{{\displaystyle \frac{D_{\mathit{Bv}}(t)}{R_{\mathit{Bl},\mathit{Bm}}(t)}}\right\}+\underset{\mathit{Bm}\in \mathcal{B}\backslash \mathit{Bl}}{\max }\left\{{\displaystyle \frac{D_{\mathit{Bv}}(t)}{R_{\mathit{Bm},\mathit{Bl}}(t)}}\right\}\right)$$

(22)

The total computational delay in the consensus process is

$$T_{totalpa}^c(t)=T_{new}^c(t)+T_{pre}^c(t)+T_{pre\_com}^c(t)+T_{com}^c(t)+T_{dec}^c(t)$$

(23)

Therefore, the total delay of the consensus process is

$$T_{totalpa}^B(t)={\displaystyle \frac{U}{D_{Bv}(t)/\varpi }}(T_{totalpa}^c(t)+T_{totalpa}^{tr}(t))$$

(24)

In addition, the energy consumption for transmission and computation can be expressed as

$$E_{\mathit{totalpa}}^{\mathit{tr}}(t)=4\times \left({\displaystyle \sum _{\left\{\mathit{Bm}\in \mathcal{B}\backslash \mathit{Bl}\right\}}\frac{D_{\mathit{Bv}}(t)}{R_{\mathit{Bm},\mathit{Bl}}(t)}}+{\displaystyle \sum _{\left\{\mathit{Bm}\in \mathcal{B}\backslash \mathit{Bl}\right\}}\frac{D_{\mathit{Bv}}(t)}{R_{\mathit{Bl},\mathit{Bm}}(t)}}\right)\bullet P_t$$

(25)

$$\begin{array}{l}{E}_{\mathit{totalpa}}^c(t)={\kappa }_v{f}_{\mathit{pBl}}{(t)}^2\left(O_{\mathit{Bl}}^{\mathit{new}}(t)+O_{\mathit{Bl}}^{\mathit{pre}}(t)+O_{\mathit{Bl}}^{\mathit{pre}\_\mathit{com}}(t)+O_{\mathit{Bl}}^{\mathit{com}}(t)+O_{\mathit{Bl}}^{\mathit{dec}}(t)\right)\\ \begin{array}{cc}& \end{array}+{\displaystyle \sum _{\left\{\mathit{Bm}\in \mathcal{B}\backslash \mathit{Bl}\right\}}{\kappa }_v{f}_{\mathit{pBm}}{(t)}^2\left(O_{\mathit{Bm}}^{\mathit{new}}(t)+O_{\mathit{Bm}}^{\mathit{pre}}(t)+O_{\mathit{Bm}}^{\mathit{pre}\_\mathit{com}}(t)+O_{\mathit{Bm}}^{\mathit{com}}(t)\right)}\end{array}$$

(26)

For the transaction of task offloading of U users, the total consensus energy consumption is

$$E_{\mathit{totalpa}}^B(t)={\displaystyle \frac{U}{D_{\mathit{Bv}}(t)/\varpi }}(E_{\mathit{totalpa}}^{\mathit{tr}}(t)+E_{\mathit{totalpa}}^c(t))$$

(27)

Formulas (24) and (27) are the energy consumption and delay generated by PVs executing the Hotstuff consensus, and RSUs use the same form. Therefore, the energy consumption and delay for the consensus can be expressed as follows.

$$E_{\mathit{total}}^B(t)=(E_{\mathit{totalpa}}^B(t)+E_{\mathit{totalRSU}}^B(t))$$

(28)

$$T_{\mathit{total}}^B(t)=(T_{\mathit{totalpa}}^B(t)+T_{\mathit{totalRSU}}^B(t))$$

(29)

5. Optimization Problem Form

As can be seen from the above, the delay and energy consumption factors of offloading and blockchain need to be considered, and the location differential privacy strength also needs to be guaranteed. Therefore, this chapter constructs an optimization problem aimed at minimizing system delay and energy consumption while ensuring location differential privacy strength. In the system, the privacy budget controls the strength of location perturbation noise, which affects the quality of wireless communication, and subsequently influences both task offloading and blockchain consensus. Meanwhile, the block size and the number of consensus nodes directly impact the performance of the consensus mechanism, but both are constrained by the offloading ratio, which determines the distribution of computational tasks between RSUs and parked vehicles. A larger number of tasks leads to more transactions, thereby affecting the consensus overhead. However, the optimal offloading ratio depends on the channel quality and the strength of the privacy noise. Therefore, the offloading decisions, block size, number of consensus nodes, and privacy budget are mutually coupled. Optimizing any single variable in isolation cannot achieve the global optimum. It is necessary to jointly optimize the offloading decisions, block size, number of consensus nodes, and privacy budget to improve the system performance. Using the model presented above, the total system energy consumption is given by the following:

$$E_{\mathit{total}}(t)={\displaystyle \sum _{i=1}^U\left(E_{\mathit{pai}}(t)+E_{\mathit{RSUi}}(t)\right)}+E_{\mathit{total}}^B(t)$$

(30)

Similarly, the total delay of the system is as follows:

$$T_{\mathit{total}}(t)=\max \left\{\underset{i}{\max }{T}_{\mathit{pai}}(t),\underset{i}{\max }{T}_{\mathit{RSUi}}(t)\right\}+T_{\mathit{total}}^B(t)$$

(31)

The system needs to simultaneously optimize energy consumption, latency, and privacy strength, although the three objectives are often conflicting. To eliminate differences in dimensions and magnitudes among these metrics, normalization is required to ensure that the weighted sum is physically comparable. Therefore, aiming to balance energy consumption, latency, and privacy strength, the optimization problem is formulated as follows:

$$\underset{B(t),D_{\mathit{Bv}}(t),{\mathsf{\Phi }}_{\mathit{RSU}}(t),\epsilon (t)}{\min }{\displaystyle \frac{1}{U}}\left(w_1{E}_{\mathit{total}}(t)+w_2{T}_{\mathit{total}}(t)\right)+w_3{D}_{KL}(t)$$

(32)

$$\mathrm{s}\mathrm{.}\mathrm{t}\mathrm{.}{T}_{pai}(t),T_{RSUi}(t)\le T_{maxi}$$

(33)

$$E_{pai}(t),E_{RSUi}(t)\le E_{maxi}$$

(34)

$$0\le \epsilon (t)\le 1$$

(35)

$$0\le {\phi }_{RSUi}(t)\le 1$$

(36)

wherein w₁, w₂ and w₃ are weight coefficients representing the weight of system delay, energy consumption and privacy strength in the optimization objective, respectively, and satisfy w₁ + w₂ +w₃ = 1. Furthermore, w₁, w₂ and w₃ allow for flexible prioritization of energy consumption, latency, and privacy strength. Intuitively, a larger w₃ imposes a higher penalty on the privacy loss D_KL(t), steering the optimizer toward a smaller ε(t) and stronger location perturbation. Conversely, larger w₁ or w₂ incentivize the optimizer to sacrifice privacy for better performance. The above optimization problem is a nonlinear and nonconvex optimization problem. To solve this problem while adapting to the dynamic IoV environment, we construct a two-layer DRL scheme to dynamically make decisions on offloading ratios, privacy budgets, and other parameters. ${\mathsf{\Phi }}_{\mathit{RSU}}(t)=\left\{{\phi }_{\mathit{RSUi}}(t),\forall i\in \mathcal{U}\right\}$ is the proportion of the task size of each user offloaded to the RSU. Constraint conditions (33) and (34) limit the maximum values of delay and energy consumption, condition (35) ensures the range of the privacy budget, and condition (36) ensures that the offloading proportion of each user is less than one.

6. DBPVEC Task Offloading Strategy

6.1. Location Differential Privacy Hotstuff Algorithm

To protect the location privacy of PV consensus nodes during consensus, we combine the location differential privacy with the Hotstuff consensus algorithm, using the mechanism designed in Section 3 to perturb the locations of PVs and executing the consensus based on the perturbed locations, as shown in Algorithm 1.

Algorithm 1. Location differential privacy Hotstuff algorithm
Input:   Block size DBv; Privacy budget ε; Sample number N;   PV true position (xpa,ypa); PV number P.
Output:   PV consensus energy consumption $E_{totalpa}^B;$   PV consensus delay $T_{totalpa}^B.$
1:	Initialize the energy consumption weight a1 and delay weight a2.
2:	for i = 1:N do
3:	for j = 1:P do
4:	Obtain perturbed position (xpert(j), ypert(j)) by Formula (8).
5:	end for
6:	Compute SINR of PV by perturbed position (xpert, ypert), using Formula (4)
7:	Select consensus nodes by SINR, parking time and computing capability.
8:	Compute $E_{totalpa}^B(i)$ and $T_{totalpa}^B(i)$ based on Hotstuff model.
9:	Calculate $u(i)=a_1{E}_{totalpa}^B(i)+a_2{T}_{totalpa}^B(i)$
10:	end for
11:	Select the index of min(u)
12:	Return $E_{totalpa}^B=E_{totalpa}^B(index),$$T_{totalpa}^B=T_{totalpa}^B(index).$

In Algorithm 1, the locations of all PVs are perturbed by adding noise according to Formula (8); then, the SINR of each node is calculated according to Formula (4). When selecting consensus nodes, the node’s SINR, parking duration and computing capability are comprehensively considered for selection. After calculating the consensus energy consumption and consensus delay, the minimum value in the samples is chosen as the perturbed location. As can be seen from Algorithm 1, the location differential privacy mechanism merely adds noise to the location of each consensus node, and therefore has no impact on the correctness or security of the Hotstuff consensus. If B consensus nodes participate in the consensus, the complexity of the Hotstuff is O(B), while the complexity of Algorithm 1 is O(N × B).

6.2. Two-Tier DRL Task Offloading Algorithm

To achieve privacy security with low energy consumption and delay, the optimization problem is constructed as a Markov Decision Process (MDP), with its state space, action space, and reward function clearly defined. Considering the coexistence of discrete variables (block size, number of consensus nodes) and continuous variables (offloading ratio, privacy budget), a two-layer DRL model is developed, where DQN optimizes the discrete parameters and DDPG determines the continuous ones.

6.2.1. State Space

Each time slot t, the system state includes the average energy consumption and delay generated by consensus, privacy strength D_KL, and the system’s average energy consumption and delay. Among them, the average energy consumption of consensus $E_{avg}^B(t)={\displaystyle \frac{1}{U}}{E}_{total}^B(t)$ and the average delay $E_{avg}^B(t)={\displaystyle \frac{1}{U}}{E}_{total}^B(t)$ are used as the state input of the upper-layer DQN, while the system’s average energy consumption $E_{avg}(t)={\displaystyle \frac{1}{U}}{E}_{total}(t)$ and average delay $T_{avg}(t)={\displaystyle \frac{1}{U}}{T}_{total}(t)$ serve as the state input of the lower-layer DDPG. D_KL is the common input of the two layers. Therefore, the state space of the system is defined as $s_t=\{s_t^B,s_t^L\}$, and the state space is divided into $s_t^B=\{E_{\mathit{avg}}^B(t),T_{\mathit{avg}}^B(t),D_{KL}(t)\}$ and $s_t^L=\{E_{\mathit{avg}}(t),T_{\mathit{avg}}(t),D_{KL}(t)\}$, which represent the state inputs of the upper and lower layers, respectively.

6.2.2. Action Space

Similarly, the action space of the system is divided into the upper-layer DQN action space and the lower-layer DDPG action space, corresponding to discrete variables and continuous variables, respectively. Therefore, the action space of the system is $a_t=\{a_t^B,a_t^L\}$, where $a_t^B=\{B(t),D_{\mathit{Bv}}(t)\}$ is the discrete action space for handling blockchain parameter decisions, and $a_t^L=\{{\mathsf{\Phi }}_{\mathit{RSU}}(t),\epsilon (t)\}$ is the continuous action space for determining user offloading decisions and privacy budgets.

6.2.3. Reward Function

In DRL, the agent obtains a reward after taking an action, according to the environment, where the reward value is determined by the reward function. The larger the reward, the better the action. However, the optimization objective is to minimize the average energy consumption, average delay and privacy strength. Therefore, it is necessary to design the reward function as the negative value of the optimization objective. In addition, because the orders of magnitude of the average energy consumption, average delay and privacy strength values are different, normalization is required when designing the reward function. Hence, we use the function $F(x)=1-\log (1+x)/\log (2+x)$ to realize the normalization of the reward function.

DQN reward function: As the upper-layer agent, DQN handles the decisions of the consensus process, and the reward function is composed of the average energy consumption, the average delay generated by the consensus process and the privacy strength. Therefore, the reward function can be designed as follows:

$$r_t^B=a_{1}F(E_{\mathit{avg}}^B(t))+a_{2}F(T_{\mathit{avg}}^B(t))+a_3(1-D_{KL}(t))$$

(37)

DDPG reward function: As the lower-layer agent, this determines the user task offloading proportion and differential privacy budget, and needs to balance the system’s average energy consumption, average delay and differential privacy strength. Hence, the reward function is expressed as follows:

$$r_t^L=w_{1}F(E_{\mathit{avg}}(t))+w_{2}F(T_{\mathit{avg}}(t))+w_3(1-D_{KL}(t))$$

(38)

6.2.4. Algorithm Design

The number of consensus nodes and the block size are discrete variables. Therefore, DQN is employed to optimize these parameters of the consensus mechanism. The structure of DQN consists of an evaluation network and a target network, as shown in Figure 2. The evaluation network gives the value of the action $a_t^B$ under the state $s_t^B$:

$$a_t^B=\underset{a_t^B}{\mathrm{argmax}}Q(s_t^B,a_t^B;\chi )$$

(39)

χ represents the weight of the evaluation network. After the agent executes the action, a reward value $r_t^B$ is returned, and the system transitions to the state in the next slot. In each slot, <$s_t^B$,$a_t^B$,$r_t^B$,$s_{t+1}^B$> stores in the experience replay buffer, then elements in <$s_t^B$,$a_t^B$,$r_t^B$,$s_{t+1}^B$> randomly samples from the experience replay buffer, and the Q value generates through the target network, that is as follows:

$$y_t=r_t^B+\underset{a_{t+1}^B}{\max }Q(s_{t+1}^B,a_{t+1}^B;{\chi }^{-})$$

(40)

where χ⁻ belongs to the weight of the target network. In the training phase, the update of the evaluation network is achieved by minimizing the loss function, which is formulated as below:

$$L(\chi )={(y_t-Q(s_t^B,a_t^B;\chi ))}^2$$

(41)

Unlike DQN, DDPG is an actor–critic DRL algorithm designed for continuous action decision problems, e.g., offloading ratio and privacy budget. It adopts two evaluation networks and two target networks, with each pair composed of an actor network and a critic network. Let μ, μ⁻ be the weights of the evaluation actor network and target actor network, and κ, κ⁻ be those of the evaluation critic network and target critic network, respectively. Then, the evaluation actor network generates corresponding actions by changing relevant parameters, which are as follows: $a_t^L=\pi (s_t^L;\mu )$. Subsequently, the evaluation critic network evaluates the generated actions. The critic network approximates the Q-value function by minimizing the loss function, which can be formulated as follows:

$$L(\kappa )={\displaystyle \frac{1}{T}}{\displaystyle \sum _{t=1}^T{(y_t-Q(s_t^L,a_t^L;\kappa ))}^2}$$

(42)

In Equation (42), y_t is the approximate value function of the target network, given by (43):

$$y_t=r_t^L+\gamma Q(s_{t+1}^L,\pi (s_{t+1}^L;{\mu }^{-});{\kappa }^{-})$$

(43)

In the above formula, γ represents the discount factor, and $\pi (s_{t+1}^L;{\mu }^{-})$ is the action selected by the target actor network under the state $s_{t+1}^L$. The actor network uses the critic network to generate a deterministic policy. Therefore, to minimize the value function, the weight μ of the evaluation actor network is updated by using the gradient descent method, that is as follows:

$${\nabla }_{\mu }J\approx {\displaystyle \frac{1}{T}}{\displaystyle \sum _{t=0}^T{\nabla }_{a_t^L}Q(s_t^L,a_t^L;\kappa )}{\nabla }_{\mu }\pi (s_t^L;\mu )$$

(44)

Under the structure of the two-layer DRL, the agents of DQN and DDPG cooperate with each other to complete the system’s task offloading, and the algorithm is shown in Algorithm 2. Since there are U user vehicles and the sizes of the hidden layers in both the action network and the critic network are fixed, the complexity of action generation can be expressed as O(U). During the training process, the complexity per step is also O(U). If the number of training steps within a time interval is N_t, then the time complexity of the algorithm within one time interval is O(N_t × U).

Algorithm 2. Two-layer DRL-based DBPVEC offloading strategy algorithm
Input:    Upper-layer state $s_t^B;$ Lower-layer state $s_t^L;$    Episode count Nk; Step count Nt.
Output:    Optimized policy for task offloading φRSUi;    Privacy budget ε; Block size DBv;    Number of PV consensus nodes B.
1:	Initialize DQN and DDPG networks parameters
2:	for k = 1:Nk do
3:	Reset environment and obtain initial states $s_0^B,$ $s_0^L.$
4:	for t = 1:Nt do
5:	Select a random number ρ
6:	If ρ < ζ
7:	Choose $a_t^B$ by Formula (35)
8:	else
9:	Choose a random action
10:	endif
11:	Take action in the environment, observe the next state st and the reward $r_t^B,$ $r_t^L$
12:	Put the experience <st, at, $r_t^B,$ $r_t^L,$st+1> into replay buffer
13:	Select a batch sample from upper-layer replay buffer randomly
14:	Calculate target Q-values by Formula (36)
15:	Update χ by minimizing loss L(χ)
16:	χ− ← τχ + (1−τ)χ−
17:	Sample random batch from lower-layer replay buffer
18:	Compute target actions and target Q-values
19:	Update κ by minimizing loss function L(κ)
20:	Compute policy gradient by Formula (40)
21:	Update μ using gradient ascent
22:	μ− ← τμ + (1−τ)μ−
23:	κ− ← τκ + (1−τ)κ−
24:	end for
25:	end for

7. Experimental Results and Analysis

To evaluate the performance of the proposed scheme, we conduct simulations on a desktop equipped with an NVIDIA GeForce RTX 5050 GPU, 32 GB of RAM, and an Intel i9-14900 CPU. MATLAB R2024b is used for simulation experiments. In the simulation, the PV parking duration data are from ACT Government Open Data Portal DataACT [38]. The simulation parameters are shown in

Table 3. Main simulation parameters.

Parameters	Value	Parameters	Value
$C_{pk}^{exe},C_{rj}^{exe}$	24 cycles/bit [39]	d0	100 m [35]
ϖ	1 KB	Wb	15 MB
Dqi	10–30 MB	θ	10 × 106 cycles [39]
DBv	4 MB	σ	1 × 106 cycles [39]
fpk	1–2.5 GHz	α	2 [35]
frj	4–6 GHz	η	1.63726 × 10−9 [35]
N0	1.2589 × 10 W [35]	κv	10−27 [40]
Pt	0.28183815 W [35]	κr	10−28

.

In the simulation, for the upper-layer DQN, we set two fully connected hidden layers with 128 and 64 neurons, respectively. The learning rate is set to 10⁻⁴, the discount factor to 0.99, the mini-batch size to 128, and the replay buffer size to 10⁶. For the lower-layer DDPG, both the actor network and the critic network contain two fully connected hidden layers, with 128 and 200 neurons, respectively. The learning rates are both set to 10⁻⁴, the discount factor to 0.99, the mini-batch size to 128, and the replay buffer size to 10⁵. Additionally, we set 8000 training episodes, each consisting of 100 steps. The total training time is 52 h and 29 min (with 100 user vehicles). The resulting trained model size is less than 1 MB, making it suitable for deployment in resource-constrained devices. Moreover, through testing, the average inference time per decision is 82.43 ms.

We studied the impact of different offloading proportions on system performance, as shown in Figure 3. As shown in the figure, the system comprehensive cost, delay, and energy consumption vary with the number of users, respectively. Among them, the comprehensive cost is calculated by the delay, energy consumption and D_KL. On one hand, with growth in the number of users, the volume of computation tasks increases, and thus the system comprehensive cost, delay, and energy consumption rise accordingly. On the other hand, a higher task offloading proportion to RSUs results in a decreasing trend in the comprehensive cost, delay, and energy consumption. This is attributed to the wireless communication provided by the PV network during task offloading, which raises the communication cost and accordingly increases the delay and energy consumption. Since the number of RSUs is limited, the computing and communication resources of RSUs become inadequate when the task load reaches a certain threshold, leading to a slight increase in the comprehensive cost, delay, and energy consumption.

Subsequently, the variation in system performance with the privacy budget under different offloading ratios is discussed in Figure 4. As mentioned above, when the offloading proportion increases, the comprehensive cost, delay and energy consumption all decrease. However, when the privacy budget continues to increase, the values change little, indicating that introducing location differential privacy to protect location information has almost no impact on the system performance.

Then, to further discuss the impact of differential privacy on the system, we compare our scheme with those without a differential privacy mechanism (non-DP), as illustrated in Figure 5. As shown in the figure, in contrast to schemes without differential privacy, our approach achieves the lowest levels in terms of cost, energy consumption, and delay, indicating that a well-designed differential privacy mechanism can mitigate its impact on system performance.

Next, the execution of the consensus mechanism generates additional energy consumption and delay, thereby affecting the system performance. Figure 6 shows the impact of different consensus mechanisms on the system’s comprehensive cost. The figure shows that the Hotstuff consensus mechanism used in this paper has the smallest impact on the system’s comprehensive cost compared with BLS_PBFT and PBFT. The reason is that the Hotstuff consensus mechanism utilizes one-to-many or many-to-one transmission, instead of many-to-many transmission like BLS_PBFT and PBFT during the consensus process. Therefore, wireless communication interference is greatly reduced, which in turn decreases the communication delay and energy consumption.

Next, we analyze how the number of PV consensus nodes affects the delay and energy consumption, as presented in Figure 7. As the number of PV consensus nodes increases, both the communication cost in consensus and the number of signatures and MACs to be verified increase, which raises the delay and energy consumption of the consensus mechanism and thus increases the overall system delay and energy consumption.

Furthermore, the proposed scheme is compared with the existing works, as shown in Figure 8. In the figure, Teng et al. [20] adopts a PVEC architecture but employs a single-chain PBFT consensus algorithm deployed on RSUs. Shi et al. [4] uses a VEC structure with a single-chain PBFT to construct the blockchain. It can be observed that, in contrast to these two schemes, our approach achieves the lowest consumption. Specifically, the average costs of the three schemes are 15.27, 13.17, and 4.84, respectively; the average energy consumption values are 6.21 J, 6.67 J, and 5.59 J; and the average delays are 24.07 ms, 20.13 ms, and 16.50 ms. Accordingly, our scheme achieves reductions of 68.31% and 63.25% in cost, 9.96% and 16.27% in energy consumption, and 31.46% and 18.07% in delay, respectively, demonstrating that the proposed architecture effectively enhances system performance.

Finally, the proposed two-layer DRL is compared with other optimization approaches, as shown in Figure 9. Figure 9a compares the proposed two-layer DRL with a single-layer baseline. The two-layer DRL achieves a significantly lower system comprehensive cost. This improvement is attributed to its architecture, which processes discrete and continuous actions through separate layers, thereby enhancing the reward optimization process. In Figure 9b, different traditional optimization methods, i.e., Simulated Annealing (SA), Genetic Algorithm (GA), and Particle Swarm Optimization (PSO), are compared with our scheme. As illustrated in the figure, the proposed two-layer DRL achieves the lowest system comprehensive cost among all the compared methods. The results demonstrate the superiority of the proposed approach over traditional optimization methods in handling the complex trade-offs among energy consumption, delay, and privacy preservation.

8. Conclusions

We propose a DBPVEC offloading framework to address the problem that location information is prone to leakage during the consensus and user offloading processes in BPVEC. To achieve this, we design a location differential privacy mechanism based on the Laplace differential privacy mechanism and prove that this mechanism satisfies the ε-differential privacy. Meanwhile, the designed location differential privacy mechanism is used to perturb the locations of users and PVs, which is combined with the Hotstuff consensus algorithm. On this basis, an optimization problem is established with the system’s energy consumption, delay and privacy strength as the optimization objectives, and a two-layer DRL algorithm is designed to solve the optimization problem. The experimental results show that the DBPVEC task offloading scheme ensures that the location privacy of users and PV consensus nodes is not leaked while guaranteeing energy consumption and delay.