An Efficient and Fair Map-Data-Sharing Mechanism for Vehicular Networks

Abstract

With the rapid advancement in artificial intelligence, autonomous driving has emerged as a prominent research frontier. Autonomous vehicles rely on high-precision high-definition map data, necessitating timely map updates by map companies to accurately reflect road conditions. This paper proposes an efficient and fair map-data-sharing mechanism for vehicular networks. To encourage vehicles to share data, we introduce a reputation unit to resolve the cold-start issue for new vehicles, effectively distinguishing legitimate new vehicles from malicious attackers. Considering both the budget constraints of map companies and heterogeneous data collection capabilities of vehicles, we design a fair incentive mechanism based on the proposed reputation unit and a reverse auction algorithm, achieving an optimal balance between data quality and procurement costs. Furthermore, the scheme has been developed to facilitate mutual authentication between vehicles and Roadside Unit(RSU), thereby ensuring the security of shared data. In order to address the issue of redundant authentication in overlapping RSU coverage areas, we construct a Merkle hash tree structure using a set of anonymous certificates, enabling single-round identity verification to enhance authentication efficiency. A security analysis demonstrates the robustness of the scheme, while performance evaluations and the experimental results validate its effectiveness and practicality.

1. Introduction

The rapid increase in urban vehicles has exacerbated traffic congestion and road safety issues. Autonomous driving systems can minimize collisions and improve traffic efficiency through vehicle-to-infrastructure coordination. Their potential has made them a pivotal research focus in intelligent transportation [1,2]. As infrastructure-based perception enhancers, high-definition maps enable autonomous vehicles to access real-time and accurate traffic data via continuously updated spatiotemporal information. The advent of technologies such as 5G and big data has enabled the development of maps for autonomous vehicles that are capable of supporting updates at hourly or even minute-level resolutions [3]. Consequently, the freshness and security of map data directly impact the reliability of autonomous driving systems. In complex urban traffic scenarios, delays or inaccuracies in data updates may result in critical errors in decision-making. This emphasizes the critical necessities for secure, efficient, and equitable mechanisms for sharing map data, thereby establishing their development as a pivotal priority for next-generation transportation networks.

Figure 1 illustrates the architecture of the map-data-sharing system, which comprises four entities: vehicle administration (VA), map company (MC), RSU, and vehicles. The MC transmits data requests to RSUs, which in turn disseminate collection tasks to proximate vehicles. Vehicles participating are equipped with sensors that capture environmental data and then upload it to the RSUs. The RSUs then forward the data to the MC for map updates and distribute rewards to the participating vehicles.

A map-data-sharing system enables an MC to access traffic information collected by vehicles. Whilst traditional centralized cloud platforms offer significant advantages in terms of storage and computational resources, their reliance on a centralized architecture introduces issues of concentrated trust, which can lead to security vulnerabilities and single points of failure [4,5,6,7,8,9]. In contrast, blockchain technology, with its decentralized structure and inherent auditability, provides a reliable technical foundation for the secure storage and tamper-proof verification of vehicle-shared data [10,11,12,13]. Within this framework, blockchain is utilized to record transaction information pertaining to data sharing, while smart contracts are responsible for enforcing the associated data-sharing rules. This approach serves to enhance the system’s robustness while ensuring the verifiability of data. The motivation behind this paper is to propose a blockchain-based decentralized architecture for map data sharing. However, during the process of map data sharing, ensuring the accuracy and reliability of the shared data remains a critical challenge that needs to be addressed.

Challenge 1: Low Sharing Willingness. In vehicle-data-sharing systems, newly joined vehicles are often filtered out due to a lack of historical interaction records, leading to a cold-start problem [14,15]. Furthermore, the conflict between the MC’s limited budget and the energy expenditure required for data retrieval discourages vehicle participation [16]. The abovementioned reasons, in conjunction with issues of trust, have resulted in a mere $30\%$ of users being willing to share vehicle information [17]. The existing solutions propose incentive mechanisms, such as [11], which employs smart contracts to allocate rewards based on transaction data, and [18], which utilizes smart contracts to evaluate data quality and automate reward distribution. However, these approaches overlook the practical challenge of the MC’s budget constraints. Additionally, while they attempt to mitigate the cold-start issue through data quality assessment, this method is ineffective in our context as the data provided by honest vehicles is inherently trustworthy. Consequently, resolving the cold-start dilemma and incentivizing honest vehicles under budget constraints is critical to enhancing data-sharing participation.

Challenge 2: Data Accuracy. Accurate map data ensures high availability of updated map information. The security and sharing efficiency of map data directly affect its accuracy. While encryption-based solutions are highly effective in preventing data tampering and eavesdropping, they cannot ensure the legitimacy of data providers. In order to address this issue, researchers propose a solution that would require vehicles to undergo anonymous mutual authentication with RSUs using cryptographic protocols. This approach not only serves to filter out malicious vehicles but also facilitates the identification of entities that are submitting erroneous data. However, to achieve comprehensive map coverage, vehicles situated within overlapping RSU zones are required to submit sensor data to both RSUs, consequently leading to redundant authentication processes. This redundancy has been shown to have a significant impact on the efficiency of sharing, particularly in the context of real-time map data, which requires frequent updates. The existing research has advanced solutions for vehicle-to-vehicle (V2V), single-domain vehicle-to-infrastructure (V2I), and cross-domain V2I authentication [19,20,21]. Unfortunately, sequential dual-authentication schemes in overlapping regions exhibit efficiency bottlenecks due to repeated cryptographic operations, such as duplicated signature validations.

In order to address these challenges, this study proposes an efficient and fair map-data-sharing scheme for vehicular networking. In order to address the issue of cold start, a dynamic reputation unit has been developed. This unit has two functions: firstly, it assigns an initial reputation value to new vehicles in order to encourage data sharing; secondly, it incorporates a penalty term and a trust term, which serve to dynamically update the reputation values of vehicles. The effect of these functions is to restrict low-reputation vehicles from providing shared data. The present study proposes a reverse auction-based incentive mechanism to address the budget constraints of the MC and the limited data collection capabilities of vehicles. In order to guarantee the security of the data, mutual authentication is implemented between RSUs and vehicles. Specifically, RSUs construct a Merkle hash tree (MHT) using anonymous certificates, enabling multiple data-sharing sessions with a single mutual authentication among vehicles in overlapping regions, thus improving sharing efficiency. The core contributions of this paper can be summarized as follows:

(1)

Fair Data-Sharing Mechanism. We design a dynamic reputation unit to resolve the cold-start issue for new vehicles while revoking access rights for malicious vehicles. Furthermore, we develop an incentive mechanism based on reverse auction to balance the MC’s budget constraints with vehicular data collection capacity limits.

(2)

Data Security. We propose a mutual authentication mechanism between vehicles and RSUs to prevent unauthorized vehicles from sharing data and to detect vehicles that provide malicious data during the sharing process. In order to enhance the efficiency of sharing, a MHT is employed for the storage of vehicles’ anonymous certificates, thus addressing the redundant authentication issue in overlapping RSU regions. This approach facilitates single authentication for multiple data-sharing sessions.

(3)

Provable Security and Performance Evaluation. A security analysis demonstrates that the proposed scheme ensures anonymity, confidentiality, and unlinkability. A performance evaluation further confirms its practical effectiveness.

The paper is organized as follows: Section 2 reviews the related works, while Section 3 formulates the problem statement. In Section 4, a proposal is put forward for a scheme. Section 5 is concerned with the analysis of security measures. The results of the simulation experiments are presented in Section 6. Section 7 is concerned with a case study. Finally, Section 8 concludes the paper.

2. Related Works

Data sharing serves as a critical enabler for facilitating data development, exchange, and collaborative innovation, significantly accelerating technological progress and enabling novel applications. This mechanism demonstrates substantial utility across multiple domains, with particularly prominent applications in vehicular networks. Currently, data sharing systems primarily employ two distinct architectural paradigms: centralized cloud-based frameworks and decentralized blockchain-based infrastructures. As illustrated in

Table 1. Comparison of schemes.

	Centralized Scheme					Decentralized Scheme
Scheme	[5]	[6]	[8]	[7]	[9]	[10]	[12]	[13]	[11]	Our work
Single Point of Failure	√	√	√	√	√	×	×	×	×	×
Dynamic Incentive	×	√	×	×	√	×	×	×	√	√
Anonymity	√	√	√	√	×	√	√	√	×	√
Data Privacy	√	√	√	√	×	√	√	√	×	√
Unlinkability	×	×	√	×	×	√	√	√	×	√
Traceability	×	×	√	√	×	√	×	×	×	√

Note: √ denotes presence, × denotes absence.

, a comparison is made between the centralized solution and the decentralized sharing scheme.

2.1. Cloud-Based Centralized Data Sharing

In centralized data-sharing architectures, data providers submit their datasets to cloud-based sharing platforms leveraging the high-performance storage and computing capacities of cloud servers. Data requesters retrieve data by submitting access requests directly to these centralized platforms. However, security concerns persist over identity leakage and biased incentive allocation given the inherent reliance on semi-trusted cloud intermediaries. To address these issues, researchers have proposed enhancing security and fairness through cryptographic mechanisms. For example, Coruh et al. introduced a rapid revocation protocol for vehicular ad hoc networks using V2V-based authenticated keyed-hash message authentication codes to verify the revocation status of onboard units [5]. Choi et al. designed a pseudonym generation method where vehicles create pseudonym sets using trusted authority-issued seeds, with RSUs distributing short-term pseudonyms to minimize acquisition latency [6]. Lin et al. proposed an identity-based group signature scheme for vehicular networks, enhancing traditional algorithms to achieve anonymous authentication while preventing identity traceability [7]. Yang et al. introduced a privacy-preserving aggregated authentication scheme enabling fog nodes to encrypt and batch-decrypt signed traffic messages from vehicles [8].

Despite their advantages in implementation simplicity, operational efficiency, and scalability, centralized architectures face critical challenges that include single points of failure, privacy vulnerabilities, and subjective fairness definitions. Ensuring data privacy and establishing equitable incentive mechanisms remain significant challenges, even when advanced technical solutions are implemented after data is stored on cloud servers.

2.2. Decentralized Data Sharing Based on Blockchain

Blockchain technology has gained extensive adoption in data sharing due to its decentralized architecture, tamper-resistance, and traceability. Blockchain enables the establishment of transparent data-sharing platforms where providers upload data via smart contracts and requesters access authorized data post-consensus. However, the inherent transparency of blockchain raises identity privacy concerns, prompting scholars to propose anonymous authentication schemes. Liu et al. devised an unlinkable blockchain-based authentication framework where service managers in each domain operate as consortium blockchain nodes, forming a distributed system for vehicular registration data [10]. Vehicles generate multiple pseudonyms through homomorphic encryption to ensure unlinkability during authentication, with smart contracts verifying pseudonym validity and ownership. Lu et al. proposed a blockchain-based privacy-preserving authentication scheme for vehicular ad hoc networks, storing vehicle certificates on-chain [12]. Vehicles maintain anonymity using scenario-specific certificates, with encrypted certificate–identity linkages disclosed only during disputes to balance anonymity and malicious vehicle traceability. Feng et al. developed an efficient privacy-preserving authentication model employing asynchronous accumulators to enhance blockchain-enabled rapid membership verification, alongside a mutual authentication protocol achieving anonymity and unlinkability in semi-trusted RSU environments [13]. Blockchain’s transparency also inspires fair data-sharing solutions. Bajoudah et al. proposed a blockchain-based data trading scheme where participants periodically submit transaction records to smart contracts for incentive allocation and dispute resolution [11]. Hu et al. leveraged smart contracts to evaluate data quality, enabling automated price negotiation and reward distribution [18]. Huang et al. implemented a two-stage Stackelberg game to optimize profit-sharing ratios between data producers and distributors [22]. Chen et al. designed a consortium blockchain-based reverse auction mechanism where cloud servers employ quality-driven auction models to determine winners and payments [9].

Despite addressing single-point failures in centralized systems, blockchain-based data sharing faces efficiency challenges due to inherently low throughput. While numerous studies have optimized anonymous authentication for V2V and V2I interactions, identity authentication in overlapping regions remains unaddressed. High-density overlapping areas experience efficiency degradation from redundant authentication processes despite high individual authentication speed. Although transparent incentive schemes promote high-quality data provision, designing appropriate incentive mechanisms still requires in-depth analysis of the specific needs of both data requesters and providers. Furthermore, the existing incentive frameworks fail to distinguish between malicious data submissions and accidental errors in vehicular data collection, potentially leading to an unfair reward distribution.

3. Problem Statement

3.1. System Model

When a map company initiates a data-sharing request, RSUs relay the request to legally identifiable vehicles within their jurisdiction. Vehicles encrypt collected data and transmit it to the RSU, which forwards the data to the map company and distributes rewards. However, it has been observed that newly joined vehicles encounter a problem with cold start. In order to address this issue, the solution authorizes the VA to calculate the vehicle’s reputation, identifies its type, and filters out malicious vehicles. For incentive fairness, the scheme deploys an incentive algorithm within a smart contract, with transparent rule disclosure. The reputation unit directly triggers the incentive algorithm by submitting computed results to the contract. Furthermore, the implementation of the aforementioned scheme is contingent upon the mutual authentication of identity between the RSU and the vehicles. The proposed scheme operates within a vehicular network environment based on the IEEE 802.11p/DSRC communication protocol. As illustrated in Figure 2, the system model comprises five entities. The specific descriptions are as follows:

• Vehicle Administration (VA): The VA operates as a Trusted Third Party responsible for (1) system initialization via cryptographic credential issuance (public–private key pairs and digital certificates) to newly registered RSUs/vehicles, and (2) dynamic trust management through adaptive vehicle classification and automated isolation of low-trust vehicles based on predefined reputation thresholds.
• Roadside Unit (RSU): RSUs are fixed nodes with integrated storage/compute capabilities deployed across infrastructure, utilizing wireless networks to communicate with covered vehicles, authenticate identities, and process data requests.
• Map Company (MC): The MC delegates data collection tasks to RSUs. These RSUs aggregate vehicle-generated data, relay it to the MC, and disburse MC-funded incentives to participating vehicles.
• Vehicle: Vehicles collect data as required by MCs, equipped with on-board units (OBUs) integrating advanced communication devices and computational modules. These OBUs enable inter-vehicle and vehicle-to-RSU communication while providing sufficient computational resources for lightweight data processing tasks.
• Blockchain: Blockchain co-maintenance by vehicular networks, RSUs, MCs, and the VA integrates incentive-calculation smart contracts that allocate rewards according to vehicular data contribution metrics and the MC’s budgetary parameters.

Before sharing map data, vehicles, the MC, and the RSU must complete identity registration with the VA. Subsequently, the MC sends a data-sharing request to the RSU and publicizes the budget for this round of data collection and the required reputation threshold for vehicles. Upon receiving the request, the RSU first verifies its source and integrity. After successful verification, the RSU generates a data request announcement and broadcasts it to all vehicles within its coverage area. Once a vehicle successfully completes mutual identity authentication with the RSU, it submits its bid to the blockchain. The VA filters eligible vehicles based on the initial reputation and uploads their reputation to the blockchain. The smart contract then computes the reward for each selected vehicle based on its bid, reputation, and the MC’s budget. After the vehicle uploads the collected map data to the RSU, the RSU aggregates the data and forwards it to the MC. Upon confirmation of a successful data upload, the RSU triggers the smart contract to distribute the corresponding rewards to the qualified vehicles.

3.2. Design Goals

In accordance with the requirement for data accuracy in map data sharing, the proposed scheme still needs to achieve the following design goals:

• Data Security. To ensure data security, the proposed scheme can defend against data leakage and tampering attacks. This guarantees the confidentiality of map data throughout its entire lifecycle, including collection, transmission, storage, and sharing. Meanwhile, only the VA can identify vehicles providing malicious data.
• Efficiency. Optimize the authentication process between RSUs and vehicles by adopting lightweight protocol design, particularly for vehicles located in overlapping coverage areas of multiple RSUs. This reduces authentication latency and improves throughput.
• Fairness. Implement a transparent and fair incentive allocation mechanism to address the dynamic cold-start problem for new vehicles while also enforcing data-sharing privilege revocation for untrustworthy vehicles.

3.3. Threat Model

In map-data-sharing scenarios involving insecure communication channels and semi-trusted vehicles and RSUs, the proposed scheme faces three critical threats:

• Identity Tracking Attack. Attackers can infer the true identity of a vehicle by observing its communication behavior over a long period of time, which can lead to privacy leakage.
• Linkage Attack. Attackers can identify the behavioral patterns of specific vehicles by comparing data features across multiple sharing sessions, thereby inferring sensitive information.
• Data Leakage Attack. Attackers can intercept map data, thereby exposing vehicle location trajectories or environmental information.

4. Fair and Efficient Map-Data-Sharing Scheme

The notations used in this scheme are summarized in

Table 2. Notations.

Notations	Description
$RS{U}_k$	The k-th RSU
$v_i^k$	The i-th vehicle managed by $RS{U}_k$
$I{D}_R^k$,$I{D}_{v_i}^k$	Identifier of $RS{U}_k$ and $v_i^k$
$d_i^k$,$E{d}_i^k$	The plaintext and ciphertext of map data.
$Cer{t}_{v_{i}k}^j$	The j-th certificate of $v_i^k$
$D{L}_{v_{i}k}^j$	Validity period of $Cer{t}_{v_i^k}^j$
$p{s}_{v_{i}k}^j$	The j-th pseudonym of $v_i^k$
$Reqinfo$	Data-sharing request
$Anno$	Data request announcement
$r_{v_i}^k,r_{MC},r_{R_k},r_{R_{k+1}}$	Random value used to generate the session key
$ke{y}_{A-v_{i}k}$	Registration phase session key encrypts VA-$v_i^k$ communication
$ke{y}_{v_{i}k-R_k}$	Authentication phase session key encrypts $v_i^k$-$RS{U}_k$ communication
$ke{y}_{v_{i}k-R_{k+1}}$	Authentication phase session key encrypts $v_i^k$-$RS{U}_{k+1}$ communication
$ke{y}_{v_{i}k-MC}$	Session key encrypts map data between $v_i^k$ and $MC$
${\mathsf{\Omega }}_i^k$	The auxiliary path
$R_0$	Initial reputation value
$RG$	The reputation gain
$P_i^j$	Penalty term for the j-th sharing of $v_i^k$
$T_i^j$	Trust terms for the j-th sharing of $v_i^k$
$Re{p}_i^j$	Reputation of $v_i^k$ after the j-th sharing
$Re{p}_0$	Reputation threshold
$HR$	Accumulated historical reputation
B	Budget for sharing data
$bi{d}_i^k$	$v_i^k$’s bid
$c_1,c_2,c_3,c_4,c_5$	Challenge

.

4.1. Main Idea

In order to ensure data security, a mutual identity recognition approach is employed. However, conventional authentication schemes necessitate dual authentication for vehicles in RSU overlapping areas, resulting in considerable time overhead. To address this, we introduce an MHT to optimize the authentication process. The $RS{U}_k$ constructs the MHT using vehicle-anonymous certificates. In the event of a vehicle entering an RSU overlapping area, it is only required to submit a verification request containing the MHT auxiliary path subsequent to the completion of the initial authentication. The $RS{U}_k$ reconstructs the Merkle root hash using the auxiliary path and verifies it against the stored root hash, thereby enabling identity authentication without the need to repeat the entire process. In order to enhance vehicles’ willingness to participate in map data sharing, the scheme introduces a reputation unit for the VA and assigns an initial reputation value to new vehicles in order to address the cold-start problem. The proposed scheme is designed to dynamically update each vehicle’s reputation score based on its behavior. In light of the capacity of vehicle equipment to collect data and the constraints imposed by MC budgets, this scheme employs the resource-constrained reverse auction algorithm (RRA) to formulate the incentive model. The proposed incentive model is deployed on a smart contract, which selects eligible vehicles based on the MC’s budget, the reputation threshold, the vehicle’s reputation, and its bid.

4.2. Detailed Protocol Design

4.2.1. Registration

The VA initializes the system by generating an additive cyclic group $G_1$ and a multiplicative cyclic group $G_2$, both of order q, where q is a large prime and P is the generating element of $G_1$. It selects a bilinear mapping $e:G_1\times G_1\to G_2$ and defines three hash functions: $H_1:{\{0,1\}}^{*}\to G_1$, and $H_2:{\{0,1\}}^{*}\times G_1\to Z_q^{*}$, where $Z_q^{*}=[1,2,\dots ,q-1]$. The VA then generates its private–public key pair by randomly selecting a private key $s{k}_A\in Z_q$ and computing the corresponding public key as $p{k}_A=s{k}_A·P$. The VA publishes the public parameters of the system $\{G_1,G_2,e,P,p{k}_A,H_1,H_2\}$. For member registration, the scheme implements three distinct procedures: vehicle registration, RSU registration, and MC registration. The vehicle registration process is shown in Figure 3.

(1)

Vehicle registration

$v_i^k$ selects $s{k}_{v_i}^k\in Z_q^{*}$, computes $p{k}_{v_i}^k=s{k}_{v_i}^k·P$, and chooses random key agreement parameter $r_{v_i}^k\in Z_q^{*}$. It calculates $r_{v_i}^k·P$, picks $c_1\in Z_q$, and encrypts message as $M_{v_{i}k-A}=E{n}_{p{k}_A}(I{D}_{v_i}^k,p{k}_{v_i}^k,r_{v_i}^k·P,c_1)$. Finally, it sends $M_{v_{i}k-A}$ to VA.

Upon receiving $M_{v_{i}k-A}$, the VA decrypts it to obtain $(I{D}_{v_i}^k,p{k}_{v_i}^k,r_{v_i}^k,c_1)$. It selects j random values $r_j\in {[0,1]}^{*}$, computes pseudonyms $p{s}_{v_{i}k}^j=H_1(I{D}_{v_i}^k\Vert r_j)$ for $v_i^k$, and generates anonymous certificates $Cer{t}_{v_{i}k}^j$ using the BLS signature algorithm:

$$\begin{array}{c}\hfill Cer{t}_{v_{i}k}^j=Si{g}_{s{k}_{vA}}\left(H_1(p{s}_{v_{i}k}^j,p{k}_{v_i}^k,D{L}_{v_{i}k})\right)\end{array}$$

(1)

where $D{L}_{v_{i}k}$ denotes the validity period of the certificate. VA then computes the session key $ke{y}_{A-v_{i}k}=s{k}_A·r_{v_i}^k·P$ and encrypts $(\{p{s}_{v_{i}k}^j,Cer{t}_{v_{i}k}^j\},c_1)$ as $M_{A-v_{i}k}=E{n}_{ke{y}_{A-v_{i}k}}(\{p{s}_{v_{i}k}^j,Cer{t}_{v_{i}k}^j\},c_1)$, stores the mapping $(p{s}_{v_{i}k}^j,p{k}_{v_i}^k,Cer{t}_{v_{i}k}^j)$, and sends $M_{A-v_{i}k}$ to $v_i^k$.

Upon receiving the ciphertext $M_{A-v_{ik}}$, $v_i^k$ computes the session key $ke{y}_{A-v_{i}k}=r_{v_i}^k·p{k}_A$, decrypts the message to obtain $(\{p{s}_{v_{i}k}^j,Cer{t}_{v_{i}k}^j\},c_1)$, and verifies the $c_1$. If valid, $v_i^k$ stores $(p{s}_{v_{i}k}^j,Cer{t}_{v_{i}k}^j)$. Otherwise, the registration fails.

(2)

RSU and MC registration

The registration process for $RS{U}_k$ and MC is similar to the vehicle registration. Upon success, $RS{U}_k$ receives $(p{k}_{R_k},s{k}_{R_k})$, and an MC receives $(p{k}_{MC},s{k}_{MC})$, where $p{k}_{R_k}=H_1\left(I{D}_{R_k}\right)$, $s{k}_{R_k}=s{k}_{VA}·p{k}_{R_k}$, $p{k}_{MC}=H_1\left(I{D}_{MC}\right)$, and $s{k}_{MC}=s{k}_{VA}·p{k}_{MC}$.

4.2.2. Request Data

MC selects random value $r_{MC}\in Z_p$ and generates data request $ReqInfo=\left\{req\right|\left|timestamp\right|\left|si{g}_{MC}\right\}$, where $req$ includes the data requirements, reward R, key negotiation parameters $kp=r_{MC}·P$, and $Si{g}_{MC}$ is the digital signature of $req$ and timestamp:

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill X& =x·p{k}_{MC}\hfill \\ \hfill Y& =(x+H_2\left(req\right|\left|timestamp\right))·s{k}_{MC}\hfill \\ \hfill Si{g}_{MC}& =(X,Y)\hfill \end{array}\end{array}$$

(2)

where $x\in Z_q^{*}$. The MC sends $ReqInfo$ to the corresponding $RS{U}_k$. Meanwhile, the MC uploads $Re{p}_0$ and B to the blockchain.

After receiving $ReqInfo$, $RS{U}_k$ verifies the signature $Si{g}_{MC}$ as follows:

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill y& =H_2\left(req\right|\left|timestamp\right)\hfill \\ \hfill e(Y,P)& \stackrel{?}{=}e(X+y·H_1\left(I{D}_{MC}\right),p{k}_{VA})\hfill \end{array}\end{array}$$

(3)

Then, the $RS{U}_k$ generates data sharing announcement $Anno$ based on $ReqInfo$. The $RS{U}_k$ signs it as $Si{g}_{R_k}=Si{g}_{s{k}_{R_k}}(Anno\Vert timestamp)$ as per Equation (2) and broadcasts the $(Anno,Si{g}_{R_k})$ to the vehicles within its jurisdiction.

4.2.3. Authentication

The proposed scheme employs an MHT to enable rapid authentication for vehicles in overlapping communication zones. As illustrated in Figure 4, consider vehicle $v_2$ located within the coverage areas of both $RS{U}_k$ and $RS{U}_{k+1}$.Vehicle $v_2$ submits its certificate $Cer{t}_2$ to $RS{U}_k$ for authentication. Upon validating $Cer{t}_2$, $RS{U}_k$ inserts it into the MHT and updates the root hash $h\left(r\right)$. The $RS{U}_k$ then transmits the auxiliary path ${\mathsf{\Omega }}_{Cer{t}_2}=<h\left(Cer{t}_1\right),h\left(d\right),h\left(b\right)>$ to $v_2$. When authenticating with $RS{U}_{k+1}$, $v_2$ provides $(Cer{t}_2,{\mathsf{\Omega }}_{Cer{t}_2})$. $RS{U}_{k+1}$ reconstructs the MHT, computes the derived root hash $h_r^{\prime }$, and verifies its equivalence to $h_r$. A successful match confirms the legitimacy of $Cer{t}_2$.

Authentication is divided into two processes: non-overlapping authentication and overlapping authentication. Figure 5 illustrates the detailed workflow.

(1) 

Non_Overlap_Auth

When vehicle $v_i^k$ operates within the coverage of $RS{U}_k$, it randomly selects an anonymous certificate $Cer{t}_{v_{i}k}^j$ for identity verification.

• The $RS{U}_k$ selects a random number $c_2\in Z_q$ as the challenge and computes the key negotiate parameter $r_{R_k}·P$, where $r_{R_k}\in Z_q$. Subsequently, $RS{U}_k$ generates the signature $Si{g}_{R_k}$ by signing the message $(I{D}_R^k,c_2,r_{R_k}·P)$ using its private key $s{k}_{R_k}$ as per Equation (2). Finally, $RS{U}_k$ transmits the challenge $(I{D}_R^k,c_2,r_{R_k}·P,Si{g}_{R_k})$ to vehicles.
• $v_i^k$ verifies $Si{g}_{R_k}$ as per Equation (3). If valid, $v_i^k$ computes the session key $ke{y}_{v_{i}k-R_k}=s{k}_{v_i}^k·r_{R_k}·P$, selects $c_3\in z_q^{*}$, and generates $Si{g}_{v_{i}k}=Si{g}_{s{k}_{v_i}^k}(p{s}_{v_{i}k}^j,D{L}_{v_{i}k}^j,Cer{t}_{v_{i}k}^j,c_3)$ (Equation (2)), where j denotes $v_i^k$’s j-th pseudonym. Then, $v_i^k$ encrypts $c_2$ as $M_{v_{i}k-R_k}=E{n}_{ke{y}_{v_{i}k-R_k}}\left(c_2\right)$ and sends $(M_{v_{i}k-R_k},p{s}_{v_{i}k}^j,D{L}_{v_{i}k}^j,Cer{t}_{v_{i}k}^j,Si{g}_{v_{i}k},c_3)$ to the $RU{S}_k$.
• The $RU{S}_k$ checks $D{L}_{v_{i}k}^j$’s validity. If valid, it computes the session key $ke{y}_{v_{i}k-R_k}=r_{R_k}·p{k}_{v_i}^k$, decrypts $M_{v_{i}k-R_k}$ to obtain $c_2$, and verifies its validity. Next, $RU{S}_k$ validates $Cer{t}_{v_{i}k}^j$ using the pairing

  $$\begin{array}{c}\hfill e(p{k}_A,H_1(p{s}_{v_{i}k}^j,p{k}_{v_i}^k,D{L}_{v_{i}k}^j)\stackrel{?}{=}e(Cer{t}_{v_{i}k}^j,P)\end{array}$$

  (4)

  and verifies $Si{g}_{v_{i}k}$. If both checks pass, it inserts $Cer{t}_{v_{i}k}^j$ into the MHT, updates the root hash to $h_r$, and generates the auxiliary path ${\mathsf{\Omega }}_i^k$. It then computes $Si{g}_{R_k}^{\prime }=Si{g}_{s{k}_{R_k}}({\mathsf{\Omega }}_i^k,Cer{t}_{v_{i}k}^j)$ (Equation (2)), encrypts as $M_{R_k-v_{i}k}=E{n}_{ke{y}_{v_{i}k-R_k}}({\mathsf{\Omega }}_i^k,Cer{t}_{v_{i}k}^j,Si{g}_{R_k}^{\prime },c_3)$, and sends it to $v_i^k$.
• Upon receiving $M_{R_k-v_{i}k}$, $v_i^k$ decrypts it using $ke{y}_{v_{i}k-R_k}$ and verifies the validity of $c_3$ and $Si{g}_{R_k}^{\prime }$. If valid, $v_i^k$ stores ${\mathsf{\Omega }}_i^k$, completing the authentication. Otherwise, the authentication fails.

(2) 

Overlap_Auth

Assuming that $v_i^k$ is within the coverage of both $RS{U}_k$ and $RS{U}_{k+1}$, and has already completed identity authentication with $RS{U}_k$, $v_i^k$ utilizes the locally stored ${\mathsf{\Omega }}_i^k$ for authentication with $RS{U}_{k+1}$.

• The $RS{U}_{k+1}$ selects random numbers $c_4\in Z_q^{*}$ and $r_{R_{k+1}}\in Z_q^{*}$, computes the key negotiate parameter $r_{R_{k+1}}·P$, and generates the signature $Si{g}_{R_{k+1}}=Si{g}_{s{k}_{R_{k+1}}}(I{D}_{R_{k+1}},c_4,r_{R_{k+1}}·P)$ (Equation (2)). It then sends $(I{D}_{R_{k+1}},Si{g}_{R_{k+1}},c_4,r_{R_{k+1}}·P)$ to $v_i^k$.
• $v_i^k$ verifies $Si{g}_{R_{k+1}}$ (Equation (3)). If valid, it selects $c_5\in Z_q^{*}$, computes the session key $ke{y}_{v_i^k-R_{k+1}}=s{k}_{v_i^k}·r_{R_{k+1}}·P$, and encrypts the message as $M_{v_i-R_{k+1}}=E{n}_{ke{y}_{v_i-U_{k+1}}}(Cer{t}_{v_{i}k}^j,{\mathsf{\Omega }}_i^k,c_4)$. Finally, $v_i^k$ sends challenge $(c_5,M_{v_i-R_{k+1}})$ to the $RS{U}_{k+1}$.
• The $RS{U}_{k+1}$ computes the session key $ke{y}_{v_i^k-R_{k+1}}=r_{R_{k+1}}·p{k}_{v_i^k}$ and decrypts $M_{v_{i}k-R_{k+1}}$ to obtain $(Cer{t}_{v_{i}k}^j,{\mathsf{\Omega }}_i^{\prime },c_4)$. After verifying $c_4$, it calculates the MHT root hash $h\left(r^{\prime }\right)$ using ${\mathsf{\Omega }}_i^{\prime }$ and checks if $h\left(r\right)==h\left(r^{\prime }\right)$. If valid, $Cer{t}_{v_{i}k}^j$ is accepted. Finally, the $RS{U}_{k+1}$ encrypts $c_5$ as $M_{R_{k+1}-v_{i}k}$ and sends it to $v_i^k$.
• Upon receiving the ciphertext, $v_i^k$ decrypts it to obtain $c_5$ and verifies its validity. If valid, the authentication is completed; otherwise, it fails.

4.2.4. Reward

(1) 

Reputation Unit

To effectively distinguish between newly joined vehicles and malicious vehicles and to prevent new vehicles from suffering losses due to the cold-start problem, we introduce a reputation unit. This unit assigns an initial reputation value $R_0$ to each vehicle and calculates the reputation gain $R{G}_i^j$ by analyzing the vehicle’s historical sharing behaviors. The model identifies whether a vehicle is newly joined or malicious based on $R_0$ and $R{G}_i^j$. The $R{G}_i^j$ is quantified using a dual-component formula, consisting of a penalty term $P_i^j$ and a trust term $T_i^j$.

Penalty Term: Assume that a map update data collection task involves n vehicles. Let $\alpha$ represent the historical reputation influence factor. The accumulated historical reputation $H{R}_i^j$ can be expressed as

$$\begin{array}{c}\hfill \begin{array}{c}\hfill H{R}_i^j=\left\{\begin{array}{cc}\alpha ·H{R}_i^{j-1}+(1-\alpha )·Re{p}_i^j& j>0\\ R_0& j=0\end{array}\right.\end{array}\end{array}$$

(5)

where i denotes the vehicle number, j denotes the number of times the vehicle has interacted with the MC, and $Re{p}_i^j$ denotes the reputation value that the vehicle $v_i^k$ has obtained in the j-th sharing. According to Equation (5), it can be seen that, when a vehicle shares data for the first time, the vehicle’s historical cumulative reputation is $R_0$.

To penalize vehicles that provide unreliable data, the scheme introduces a penalty function:

$$\begin{array}{c}\hfill \begin{array}{c}\hfill PF\left(b\right)=1/(2·(e^{-b}+1))\end{array}\end{array}$$

(6)

where b denotes the number of consecutive times a vehicle provides unreliable shared data. The penalty function exhibits rapid growth in its initial phase, enabling prompt penalization of malicious vehicles. As b increases, the penalty function gradually converges to a stable constant, which facilitates effective differentiation between vehicles with distinct behavioral patterns. Furthermore, we introduce a penalty parameter $P{C}_i^j$ to prevent isolated instances of erroneous data sharing from triggering significant reductions in vehicular reputation.

$$\begin{array}{c}\hfill \begin{array}{c}\hfill P{C}_i^j=\left\{\begin{array}{cc}0& b=0\\ H{R}_i^{j-1}-1& b>0\wedge H{R}_i^{j-1}<\mu \\ H{R}_i^{j-1}& b>0\wedge H{R}_i^{j-1}\ge \mu \end{array}\right.\end{array}\end{array}$$

(7)

$\mu$ represents the reputation penalty threshold. When the reputation value of a vehicle’s most recent data-sharing interaction is low, we will review that vehicle’s data-sharing records. If $H{R}_i^{j-1}<\mu$, it indicates that the current sharing is an accidental error. In this case, the vehicle still has the opportunity to continue participating in data sharing, but its reputation will be affected. Conversely, if the vehicle’s reputation remains low, it will be regarded as a malicious vehicle. Based on the above analysis, the penalty term can be expressed as

$$\begin{array}{c}\hfill \begin{array}{c}\hfill P_i^j=PF\left(b\right)·P{C}_i^j\end{array}\end{array}$$

(8)

Trust Term: To incentivize sustained participation of vehicles in reliable data sharing, we construct a reputation sustainability function based on a normalized tangent function prototype. The formula is as follows:

$$\begin{array}{c}\hfill \begin{array}{c}\hfill s\left(a\right)=\left[arctan\right(a-\omega )-arctan\omega ]/[\pi /2+arctan\omega ]\end{array}\end{array}$$

(9)

a denotes the count of consecutive reliable data-sharing instances. This metric captures the persistence of high-quality data sharing behaviors. The trust term is $T_i^j=S\left(a\right)·H{R}_i^j$. The resultant reputation gain is then computed as

$$\begin{array}{c}\hfill \begin{array}{c}\hfill R{G}_i^j=P_i^j+T_i^j\end{array}\end{array}$$

(10)

Following data sharing, the vehicle’s reputation is updated based on the evaluation results. The reputation of the i-th vehicle after completing its j-th data sharing is expressed as

$$\begin{array}{c}\hfill \begin{array}{c}\hfill Re{p}_i=Re{p}_{i-1}+R{G}_i^j\end{array}\end{array}$$

(11)

(2) 

Incentive Model

In our model, each vehicle $v_i^k$ submits a bid $bi{d}_i^k=(c_i^k,q_i^k)$, where $c_i^k$ denotes the unit data collection cost and $q_i^k$ presents the maximum data capacity. The collective bid set of all participating vehicles is denoted as $BID=(bi{d}_i^1,...,b_i^n)$. The MC operates with a predefined total budget constraint B. To ensure data quality, MC establishes reputation threshold $Re{p}_0$, prohibiting vehicles with reputation scores below $Re{p}_0$ from participating in data sharing.

The RRA algorithm is implemented through smart contract deployment, with its operational workflow detailed in Algorithm 1. The algorithm takes the MC’s budget B, the set of vehicle bids $BID$, and the reputation threshold $Re{p}_0$ as inputs and outputs the reward allocation R and data volume requirement d for each vehicle. Specifically, the algorithm first filters out vehicles with a reputation score higher than $Re{p}_0$. Then, using a fixed pseudo-random seed, the vehicle set V is uniformly and randomly partitioned into two disjoint subsets $V_1$ and $V_2$, and the total budget B is evenly allocated between the two subsets. It then invokes the Optimal Omniscient Auction (OOA) algorithm to compute the estimated data volumes $D_{V_1}$ and $D_{V_2}$ for the subsets $V_1$ and $V_2$ using $Re{p}_0·D_{V_1},Re{p}_0·D_{V_2}$ as adjusted benchmarks. Subsequently, a First-Price Reverse Auction (FPA) mechanism is employed, where eligible vehicles within each subset are sequentially added to an auction queue based on predefined price thresholds, and bids are processed one by one. Finally, the auction results from $V_1$ and $V_2$ are aggregated to determine the final data volume requirement d and corresponding reward R for each participating vehicle. Detailed implementations of OOA and FPA are provided in Algorithm 2 and Algorithm 3, respectively.

Algorithm 1 Smart Contract-based RRA Algorithm.

Require: Vehicle set V, Budget B, Bid information $BID$, Initial reputation $Re{p}_0$ Ensure: Reward allocation R, Data volume d 1: Deploy contract with parameters ($V,B,BID,Re{p}_0$) 2: Verify vehicle credentials and reputation scores 3: Generate a random permutation $\pi$ of V using RANG(seed) 4: Split $\pi \left(V\right)$ into $V_1$ and $V_2$ by median index 5: Compute $D_{V1}\leftarrow OOA(V_1,B/2)$ 6: Compute $D_{V2}\leftarrow OOA(V_2,B/2)$ 7: Execute $FPA(V1,B/2,BID,Re{p}_0·D_{V1})$ 8: Execute $FPA(V2,B/2,BID,Re{p}_0·D_{V2})$ 9: Aggregate auction results from $V_1$ and $V_2$ 10: Compute final reward allocation R and data contribution d 11: Record allocation results in blockchain 12: return $(R,d)$

Algorithm 2 Smart Contract-based OOA Algorithm.

Require: Vehicle set V, Budget B, Bid information $BID$ Ensure: Optimal data allocation $D_V^{*}$ 1: Deploy contract with parameters ($V,B,BID$) 2: Sort vehicles in ascending order of unit cost c 3: Compute $l\leftarrow max\{i:v_i^k\in V,c_i^k·{\sum }_{j=1}^{i-1}{q}_j^k\le B\}$ 4: Calculate $D_V^{*}\leftarrow min\{B/c_l,{\sum }_{j=1}^l{q}_j\}$ 5: return$D_V^{*}$

Algorithm 3 Smart Contract-based FPA Algorithm.

Require: Vehicle set V, Budget B, Bid information $BID$, Data allocation $D_V$ Ensure: Reward allocation R, Data volume d 1: Initialize $R\leftarrow 0,d\leftarrow 0$; 2: Compute unit price $p_V=B/D_V$ 3: for each vehicle $v_i^k\in V$ do 4:    if $c_i^k\le p_V$ and $R>0$ then 5:      Calculate reward $R_i^k\leftarrow min\{B,p_V·q_i^k\}$ 6:      Compute data contribution $d_i^k\leftarrow R_i^k/p_V$; 7:      Update remaining budget $R\leftarrow R-R_i^k$ 8:      Record transaction in blockchain 9:    end if 10: end for 11: return$(R,d)$

4.2.5. Upload Data

The vehicle computes the symmetric key $k_{v_{i}k-MC}=s{k}_{v_i}^k·r_{MC}·P$ using $KP$ from $Anno$, gathers required map data $d_{v_i}^k$, and encrypts it as $E{d}_i^k=E{n}_{ke{y}_{v_{i}k-MC}}\left(d_{v_i}^k\right)$. It then signs the data and anonymous certificate as $Si{g}_{v_{i}k}=Si{g}_{s{k}_{v_i}^k}(E{d}_i^k\left|\right|Cer{t}_{v_{i}k}^j)$ and sends $(E{d}_i^k,Cer{t}_{v_{i}k}^j,Si{g}_{v_{i}k})$ to the $RS{U}_k$.

To ensure data $d_{v_i}^k$ legitimacy and vehicle $v_i^k$ anonymity, vehicles use anonymous certificates $Cer{t}_{v_{i}k}^j$ to communicate with RSUs. To maintain unlinkability between $d_{v_i}^k$ and $v_{i^k}$, each $v_{i^k}$ updates its anonymous certificate $Cer{t}_{v_{i}k}^j$ after every data-sharing round.

Upon receiving the data, the RSU forwards $(E{d}_i^k,Cer{t}_{v_{i}k}^j,Si{g}_{v_i^k})$ to the MC. The MC verifies $Cer{t}_{v_{i}k}^j$ and $Si{g}_{v_{i}k}$ using the following check:

$$\begin{array}{c}\hfill e(P,\sum Si{g}_{v_{i}k})\stackrel{?}{=}\prod e(p{k}_{v_i}^k,H_1(E{d}_i^k\left|\right|Cer{t}_{v_{i}k}^j\left)\right)\end{array}$$

(12)

If the verification succeeds, the MC computes the symmetric key $ke{y}_{v_{i}k-MC}=r_{MC}·p{k}_{v_i}^k$, decrypts the data, and updates the map. Finally, $RS{U}_k$ triggers smart contracts to send rewards to vehicles $v_i^k$ that contribute shared data.

5. Security Analysis

This section will demonstrate that the proposed scheme can satisfy the aforementioned security and privacy requirements. This is primarily due to the one-way property of the hash function, the unforgeable property of the signature scheme, and the IND-CCA property of the encryption scheme.

Theorem 1. 

Assuming the one-way property of the hash function holds, the vehicle is conditionally anonymous in data sharing.

Proof. 

When vehicle $v_i^k$ registers its identity with VA, VA randomly selects $r_j\in {\{0,1\}}^{*}$, generates pseudonyms $p{s}_{v_i^k}^j=H_1(I{D}_{v_i^k}\left|\right|r_j)$ for vehicle $v_i^k$, and generates a certificate for $p{s}_{v_i^k}^j$. When vehicle $v_i^k$ shares data with MC, it sends the pseudonym and the corresponding certificate to MC. The only thing that contains the identity information of $v_i^k$ is the pseudonym. If there is a $PPT$ adversary that can obtain the identity information of vehicle $v_i^k$ with a non-negligible probability, then the adversary has broken the one-way property of the hash function with a non-negligible probability, which contradicts the assumption.

The anonymity of the vehicles is not absolute because their pseudonyms and anonymity certificates are issued by VA, and the deanonymized trapdoor information $(I{D}_{v_i^k},r_j,p{s}_{v_i^k}^j)$ is kept by VA. Therefore, once the vehicle performs malicious behavior, VA can deanonymize it. □

Theorem 2. 

Assuming that the hash function $H_1$ is in the random oracle model, the data-sharing scheme is unlinkable.

Proof. 

Each vehicle $v_i^k$ shares data with MC, using a new pseudonym each time. Therefore, when MC uses two different pseudonyms, $p{s}_{v_i^k}^j$=$H_1(I{D}_{v_i^k}\left|\right|r_j)$ and $p{s}_{v_i^k}^j$=$H_1(I{D}_{v_i^k}\left|\right|r_j)$, it can be deduced that vehicle $v_i^k$ has used a new pseudonym in each case. In the event of a $PPT$ adversary being capable of correlating them with non-negligible probability, two scenarios can be postulated:

In the event of the adversary being capable of directly obtaining the identity information of vehicle $v_i^k$ from the pseudonym, the adversary has broken the one-way property of the hash function with a non-negligible probability.

If the adversary of PPT can correlate the output of $H_1(I{D}_{v_i^k}\left|\right|r_j)$, then the adversary can distinguish the output of $H_1$ with non-negligible probability. However, since the output of $H_1$ is independent and identically distributed under the random oracle model, such an adversary does not exist. □

Theorem 3. 

Assuming that the encryption algorithm satisfies the IND-CPA property, the scheme satisfies the confidentiality of the shared data.

Proof. 

Suppose there exists a probabilistic PPT adversary A that breaks the data confidentiality with non-negligible advantage $ϵ$. We construct a PPT adversary B that leverages A to violate the IND-CPA security of the encryption scheme as follows: B generates two equal-length messages $m_0$ and $m_1$ with $m_0\ne m_1$ and submits them to the IND-CPA challenger C. C randomly selects $b\in \{0,1\}$, computes challenge ciphertext $c^{*}\leftarrow \mathrm{Enc}\left(m_b\right)$, and returns $c^{*}$ to B. B forwards $c^{*}$ to A. A outputs a decrypted message $m^{\prime }$, which B compares with $m_0$. If $m=m_0$, then B outputs 0; otherwise, it outputs 1. The success probability of B satisfies $\left|Pr\right[b^{\prime }=b]-1/2|<ϵ$, where $ϵ$ exactly corresponds to A’s advantage in breaking confidentiality. This contradicts the IND-CPA assumption, thus completing the reduction. □

6. Performance Evaluation

6.1. Complexity Analysis

This section presents a comprehensive complexity analysis of the proposed scheme. The related operations are defined in

Table 3. Operational definitions.

Symbol	Description
$T_{mul}$	Point multiplication
$T_p$	Bilinear pairing
$T_{hash}$	Hashing
$T_{e\_1}$	Exponential operation on $G_1$
$T_{e\_2}$	Exponentiation on $G_2$
$T_{mtp}$	map-to-point operations

.

(1) 

Computational overhead

To evaluate the computational overhead during the authentication phase, we analyze the complexity of three key operations: key generation, signature/certificate generation, and signature/certificate verification. These results were then compared with those of our own scheme and with those of EAAP [23] and TAAP [24]. In the key generation phase, the proposed aspect requires only $T_{mul}$ for public key computation at the vehicle side, significantly reducing the initial cost compared to $3T_{mul}$ in EAAP and $5T_{mul}$ in TAAP. In the phase of signature/certificate generation, the present involves $3T_{mul}$ and $T_{mtp}$. In contrast, EAAP requires $7T_{mul}$, while TAAP involves $11T_{mul}$ and $T_{mtp}$. The proposed scheme involves additional computational overhead for constructing and updating the MHT, with $(2m-1)T_{hash}$ and $\left(logn\right)T_{hash}$, where n signifies the number of vehicles, and $m=2^{⌈lo{g}_{2}n⌉}$. However, once the vehicle registration process stabilizes, these overheads will significantly decrease. In the signature/certificate verification phase, we analyze the computational costs for both non-overlap and overlap regions separately. In non-overlap regions, the proposed scheme incurs $T_{mul}$, $T_{mtp}$, and $4T_p$. In overlap regions, the MHT-based certificate verification reduces to $T_{mul}+2T_p+\left(lo{g}_{2}n\right)T_{hash}$. This is lower than the $7T_{mul}$ and $2T_p$ required by EAAP, and the $10T_p$, $T_{mtp}$, and $T_{mul}$ required by TAAP. As illustrated in

Table 4. Authentication calculation overhead.

Scheme	Issue Key	Calculate Sign /Certificate	Build /Update MHT	Verify the Sign/Certificate
				Non_Overlap	Overlap
EAAP	$3T_{\mathrm{mul}}$	$7T_{\mathrm{mul}}$	–	$7T_{\mathrm{mul}}+2T_p$	$7T_{\mathrm{mul}}+2T_p$
TAAP	$5T_{\mathrm{mul}}$	$11T_{\mathrm{mul}}+T_{\mathrm{mtp}}$	–	$T_{\mathrm{mul}}+10T_p+T_{\mathrm{mtp}}$	$T_{\mathrm{mul}}+10T_p+T_{\mathrm{mtp}}$
Our Scheme	$T_{\mathrm{mul}}$	$3T_{\mathrm{mul}}+T_{\mathrm{mtp}}$	$(2m-1)T_{hash}$/ $\left(logn\right)T_{hash}$	$T_{\mathrm{mul}}+4T_p+T_{\mathrm{mtp}}$	$T_{\mathrm{mul}}+2T_p+lo{g}_{2}n\left(T_{\mathrm{hash}}\right)$

, a detailed comparison of the computational overhead is provided. The proposed scheme has the potential to reduce the computational complexity across all three key phases of the authentication process. The construction and updating of the MHT structure in the proposed scheme introduce additional overhead.

The computational overhead during data collection and upload in our scheme is primarily from the RSU’s verification of vehicle-generated data signatures. We evaluated this overhead by comparing single-vehicle and multi-vehicle signature verification with AAWB [25] and PED [26]. In our scheme, the RSU verifies each signature by performing $Thash$ and $2T_p$. In contrast, in PED, the data-sharing service provider must verify both the temporary anonymous certificate and the data signature, which involves $4T_{e_1}$, $1T_{e_2}$, and $2T_p$. In AAWB, the receiver needs to verify one anonymous certificate and one signature, requiring $6Thash$, $2T_{mul}$, and $2T_p$. When n vehicles are involved, the total computational cost is n times that of a single verification.

Table 5. Data acquisition and upload computational overhead.

Comparison Scheme	Single-User Overhead	Multi-User Overhead
PED	$4T_{e\_1}+T_{e\_2}+2T_p$	$4n{T}_{e\_1}+n{T}_{e\_2}+(n+1)T_p$
AAWB	$6T_{hash}+2T_{mul}+2T_p$	$6n{T}_{hash}+2n{T}_{mul}+2n{T}_p$
Our Scheme	$T_{hash}+2T_P$	$n{T}_{hash}+2n{T}_P$

shows the comparative computational overhead. In contrast to the methods employed by PED and AAWB, which require the transmission of temporary anonymous certificates for identity privacy, our scheme mandates only the transmission of data, pseudonyms, and signatures by vehicles. The RSU then verifies the signatures without the need for additional certificate validation, a process that further reduces computation costs. Our scheme has been shown to offer advantages in terms of computational efficiency and versatility, making it a suitable solution for a wide range of map-update data-sharing scenarios.

(2) 

Communication overhead

The communication overhead is defined as the total data transmission length during the identity authentication process. Let the sizes of elements in the cyclic group $G_1$, $Z_q$, and the timestamp T be denoted as $|G_1|$,$|Z_q|$ and $\left|T\right|$, respectively. We evaluate the communication overhead in both the key/pseudonym generation phase and the authentication phase.

The proposed scheme utilizes symmetric encryption for the transmission of authentication messages, thereby ensuring that the length of the ciphertext is equivalent to that of the plaintext. In the process of issuing a pseudonym and certificate, the VA transmits ciphertext message $M_{VA-v_{i}k}$ to the vehicle, which contains $p{s}_{vik}^j$,$Cer{t}_{vik}^j$ and $c_1)$, where $p{s}_{vik}^j,c_1\in Z_q$, and $Cer{t}_{vik}^j\in G_1$. Therefore, the communication overhead for this phase is $2|Z_q|+|G_1|$. During mutual authentication between the vehicle and the RSU, the vehicle transmits the message $(M_{v_{i}k-R_k},p{s}_{v_{i}k}^j,D{L}_{v_{i}k}^j,Cer{t}_{v_{i}k}^j,Si{g}_{v_{i}k},c_3)$, where $p{s}_{v_{i}k}^j,c_3,M_{v_{i}k-R_k}\in Z_q$, $Cer{t}_{v_{i}k}^j,Si{g}_{v_{i}k}\in G_1$. Hence, the communication cost in this phase is $3|Z_q|+2|G_1|+T$. In contrast, the scheme in EAAP transmits a key, ciphertext, and pseudonym during the issuance phase, resulting in a communication overhead of $3|G_1|$. During authentication, it sends data, a temporary public key, a signature, and a certificate, leading to a cost of $\left|m\right|+3|Z_q|+7|G_1|$. The scheme in TAAP sends a signature, ciphertext, and random number during the issuance phase, with a communication overhead of $|Z_q|+2|G_1|$. During authentication, it transmits an authentication message and a signature, resulting in a communication cost of $\left|m\right|+11|G_1|$. As shown in

Table 6. Authentication communication overhead.

Comparison Scheme	Issue Key and Pseudonym	Mutual Authentication
EAAP	$3|G_1|$	$\left|m\right|+3|Z_q^{*}|+7|G_1|$
TAAP	$|Z_q^{*}|+2|G_1|$	$\left|m\right|+11|G_1|$
Our Scheme	$2|Z_q^{*}|+|G_1|$	$3|Z_q^{*}|+T+2|G_1|$

, the comparison demonstrates that our scheme achieves lower communication overhead during identity authentication and offers better communication efficiency compared to the above schemes.

6.2. Simulation Results

All the experiments were conducted on a Windows 10 system equipped with an Intel(R) Core(TM) i5-7200U CPU @ 2.30 GHz. We implemented the simulation using both IDEA and Rexim platforms integrated with the Sepolia blockchain testnet. The implementation employed Java for algorithmic components and Solidity for smart contract development. Time measurements concentrated exclusively on application-layer delays, excluding physical-layer transmission delays governed by the underlying IEEE 802.11p/DSRC protocol. The simulation results for the incentive mechanism, authentication process, and proposed sharing mechanism are presented below.

The incentive mechanism in our scheme is implemented through a smart contract that collects bids from vehicles. The contract filters participants according to predefined reputation thresholds (i.e., $Re{p}_i\ge Re{p}_0$) and initiates a reverse auction process. In our experiments, the number of qualified vehicles ranges from 0 to 500. As shown in Figure 6, the computational time overhead of the RRA algorithm execution on the smart contract scales linearly with the number of participants while maintaining stable performance below 130 ms.

In order to verify the reproducibility of the proposed RRA algorithm, a comparative experiment was designed as follows: the budget of the MC was set to 1000, and the vehicle reputation threshold was set to 0.7. Specifically, a total of 10 test vehicles were involved in the experiment, with their bid values ranging from 1 to 5, data collection capabilities ranging from 20 to 100, and reputation values distributed between 0.4 and 1.0. In

Table 7. The reproducibility of RRA algorithm.

Round	Seed	Vehicle
1	42	$[v_0,v_1,v_3,v_5,v_6,v_9]$
2	42	$[v_0,v_1,v_3,v_5,v_6,v_9]$
⋮	⋮	⋮
100	42	$[v_0,v_1,v_3,v_5,v_6,v_9]$

Note: The reward allocation was consistent across all rounds as follows: $[135.52,121.2,96.57,102.28,301.15,103.95]$.

, the results of five independent runs of the RRA algorithm under a fixed random seed are presented. It is evident that, when constrained by the same random seed, the vehicle matching schemes and resource allocation results generated by the RRA algorithm over 100 iterations are identical. This finding suggests that the algorithm exhibits reproducibility.

In order to evaluate the stability of the RRA algorithm, the number of vehicles was increased to 20 while ensuring that vehicle bid, data collection capabilities, and reputation value ranges remained unchanged. The performance of the algorithm was evaluated across 11 random number seeds within the range [10, 110], as illustrated in Figure 7. The reward demonstrated a standard deviation of 13.16, indicating relatively high fluctuations but remaining within an acceptable range. Furthermore, the standard deviations of data volume and vehicle volume were 5.10 and 0.48, respectively, demonstrating significantly lower fluctuations. Collectively, these results confirm the algorithm’s stability in multi-vehicle scenarios.

We evaluated the impact of reputation thresholds on the proposed scheme, setting conditions of 50 vehicles and a budget of 2000. The vehicle reputation ranged from [0.4, 1] and reputation thresholds from 0.5 to 0.9 (with a step size of 0.1). The standard deviations of participant rewards, data volume, and vehicles were recorded. As demonstrated in Figure 8, as the reputation threshold rises from 0.5 to 0.9, the average reward decreases to 2000, 1999.81, 1992.84, 1564.63, and 862.93, respectively. This decline is characterized by an initial gradual decrease, followed by a pronounced drop. The corresponding data collection volumes are 1102.48, 1019.68, 998.33, 793.0, and 401.0, respectively. The results indicate that higher thresholds reduce budget consumption but limit the number of qualified vehicles and the overall scale of data acquisition. Conversely, although lowering the threshold increases vehicle participation, the improvement in data volume is limited, indicating that low-reputation vehicles contribute relatively little. Notably, when the threshold is set to 0.7, the reward standard deviation reaches 18.93, reflecting the algorithm’s tendency to prioritize high-trust, high-performance vehicles. At a threshold of 0.8, the reward fluctuation increases to 22.74, which can be attributed to the reduced number of participating vehicles and the resulting imbalance in reward allocation. When the threshold is raised to 0.9, the sustained decline in available vehicles leads to the reward standard deviation approaching zero. While the standard deviation of the data volume decreases with increasing threshold, the data volume also declines. This suggests that, while lower thresholds may enable higher data volume, the associated high standard deviation may lead to unstable outcomes. In summary, there is a significant trade-off among reward, data volume, and system redundancy with respect to the reputation threshold. Achieving a high threshold can result in reward savings, but there is also the risk of reduced data volume. Conversely, a low threshold may result in unstable outcomes. Therefore, a dynamic balance among these three factors should be established based on practical requirements.

In order to validate the fairness of the proposed scheme, a comparative experiment was designed with a shared data budget of 1,000 and a reputation threshold of 0.7. A total of 10 test vehicles (ID 1–10) were selected, with their reputation values ranging from 0.3 to 1.0. Vehicles 2, 6, 7 and 8 exhibited reputation scores that were below the established threshold of 0.7, while the remaining vehicles demonstrated scores that were above this threshold. MCWI [27], which employs a dual-layer reverse auction mechanism, aims to minimize costs while incentivizing participants to engage. The present experiment introduces a reputation-based evaluation dimension with which to compare with MCWI. As illustrated in Figure 9, the MCWI does not incorporate reputation into its allocation strategy. This may result in low-reputation vehicles participating in data sharing and receiving rewards. In contrast, the proposed scheme effectively mitigates the over-participation of low-reputation vehicles through its reputation threshold filtering mechanism. Quantitative analysis reveals that the Gini coefficient of reward distribution for the proposed scheme is 0.175, whereas the Gini coefficient for the MCWI scheme is 0.362. The results demonstrate that the proposed scheme exhibits superiority in terms of equitable resource allocation, attaining a more balanced trade-off between cost control and the distribution of benefits to participants in a more fair manner.

We analyze the time overhead of three phases: key issuance, signature/certificate computation, and signature/certificate verification. The number of anonymous certificates varies from 0 to 500 in increments of 100. Through experimental comparison with EAAP and TAAP, the proposed scheme validates the accuracy of our theoretical analysis.

Figure 10 compares the key issuance time overhead among EAAP, TAAP, and our proposed scheme for varying numbers of vehicles. The experimental results reveal that all three schemes scale approximately linearly with increasing vehicle numbers. However, TAAP demonstrates significantly higher overhead growth, reaching nearly double that of our scheme at 500 vehicles. The experimental data reveal that, while EAAP and the proposed scheme demonstrate similar linear growth patterns in time overhead, our solution consistently maintains a slight performance advantage over EAAP.

Figure 11 compares the computational time overhead for signature/certificate generation across EAAP, TAAP, and our proposed scheme with varying numbers of vehicles. The experimental results demonstrate that all three schemes exhibit linear scaling with increasing signature/certificate quantities. Notably, TAAP incurs significantly higher computational costs than both EAAP and our scheme. Furthermore, our proposed solution achieves marginally better performance than EAAP while maintaining efficient operation.

Figure 12 compares the time overhead of signature/certificate verification across EAAP, TAAP, and the proposed scheme for varying numbers of vehicles. While both EAAP and TAAP exhibit linear growth in time overhead, EAAP demonstrates less stable growth trends. The results show that the proposed scheme achieves significantly lower time overhead than TAAP and marginally higher overhead than EAAP while maintaining consistently low overall computational costs.

We evaluate the time overhead for both single-user and multi-user data-sharing scenarios. Figure 13 compares the time overhead of the PED, AAWB, and proposed schemes in a single-user setting. While PED exhibits slightly lower overhead than AAWB, our scheme demonstrates superior performance, outperforming both PED and AAWB.

Figure 14 presents the time overhead of the AAWB, PED, and proposed schemes in multi-user data-sharing scenarios. As the number of sharing users increases, the time overhead of our proposed scheme, PED, and AAWB grows linearly. However, PED incurs significantly lower time overhead than AAWB. Although our scheme’s time overhead is slightly higher than PED’s, it remains efficient, requiring only approximately 600 ms when the number of vehicle users sharing data reaches 500.

7. Case Studies: Map Data Sharing in Vehicular Platooning

Vehicles operate in platooning formations, dynamically sharing real-time position, velocity, and path planning information to ensure coordinated driving. In scenarios such as service areas or highway ramps, multiple RSUs exhibit overlapping coverage regions. The autonomous aerial vehicles (AAVs) act as relay nodes, expanding the communication range and dynamically filling coverage gaps of ground-based RSUs, thereby providing stable communication links for platoons. The lead vehicle utilizes non-orthogonal multiple access (NOMA) technology to simultaneously transmit distinct platooning control commands to all the following vehicles, enabling efficient coordination under high-density communication demands [28].

The vehicle $v_i^k$ resides within the management range of $RS{U}_k$. Upon receiving a data-sharing request, $RS{U}_k$ broadcasts an identity mutual authentication request via NOMA to all the vehicles within its coverage. This request includes a challenge random number c, a digital signature $Si{g}_{RS{U}_k}$, and a key generation variable $KP=r_{R_k}·P$. Upon receiving the request, the vehicle verifies the legitimacy of $Si{g}_{RS{U}_k}$. If valid, the vehicle computes the session key $ke{y}_{vik-R_k}$ based on $KP$. The vehicle then encrypts the challenge c using $ke{y}_{vik-R_k}$, generating the ciphertext $M_{v_{i}k-R_k}$. Vehicle $v_i^k$ returns the message $(M_{v_{i}k-R_k},p{s}_{v_{i}k}^j,D{L}_{v_{i}k}^j,Cer{t}_{v_{i}k}^j,Si{g}_{v_{i}k})$ to $RS{U}_k$. Upon receiving the message, $RS{U}_k$ verifies the legitimacy of $Si{g}_{v_{i}k})$. If valid, $RS{U}_k$ updates the MHT by inserting $Cer{t}_{v_{i}k}^j$ as a leaf node. The MHT’s root $h_{root}$ is then uploaded to the AAV. The AAV dynamically monitors the Merkle tree root hashes $h_{root}$ of all RSUs in overlapping zones and broadcasts these hashes to relevant RSUs via NOMA, ensuring cross-domain synchronization. When $v_i^k$ moves to $RS{U}_m$, it provides the Merkle auxiliary path ${\mathsf{\Omega }}_i^k$ derived from $Cer{t}_{v_{i}k}^j$. $RS{U}_m$ reconstructs the local root $h_{root}^{\prime }=MerkleRebuild(Cer{t}_{v_{i}k}^j,{\mathsf{\Omega }}_i^k)$. $RS{U}_m$ compares it with the AAV-synchronized $h_{root}$. Identity authentication is confirmed if $h_{root}^{\prime }==h_{root}$.

The MC publishes a data-sharing budget B and a reputation threshold $Re{p}_0$ for participating vehicles. After authentication, eligible vehicles submit their bid values $bid$. A smart contract matches suitable vehicles by evaluating $B,Re{p}_0,bid$, and the vehicle reputation $Re{p}_i^j$ provided by the VA. The smart contract calculates vehicle rewards and the required data size based on these parameters. Subsequently, the VA updates the reputation $Re{p}_i^j$ of vehicles according to the outcomes of their data-sharing contributions, ensuring dynamic credibility assessment and incentive alignment in the system.

8. Conclusions

This paper proposes an efficient and fair map-data-sharing scheme that accurately distinguishes between malicious fraud and accidental errors, implements fairness incentive mechanisms, and supports efficient anonymous authentication for vehicles in overlapping areas. Rigorous security verification, performance evaluation, and simulation experiments confirm the scheme’s security and feasibility.