Blockchain-Based Detection of Invalid Vehicle Numbers While Preserving Privacy

Abstract

A blockchain-based framework is proposed for secure vehicle registration and real-time authenticity verification in vehicular networks. To mitigate the risks of fake and stolen license plates, vehicle identification data is protected using a modular arithmetic-based cryptographic mechanism and indexed within an on-chain hash table structure. Role-based access control ensures system integrity by restricting all registration and modification operations to authorized government entities, while enabling public verifiers to validate vehicle legitimacy through privacy-preserving verification. Experimental evaluation demonstrates that the system achieves low verification latency, minimal storage overhead, and stable throughput. Furthermore, scalability and denial-of-service (DoS) resilience analyses confirm consistent performance under high verification demand. This framework offers an efficient and privacy-preserving solution for the secure and real-time verification of vehicle legitimacy in vehicular networks.

1. Introduction

The rapid development of vehicular ad hoc networks (VANETs) has significantly enhanced road safety, traffic efficiency, and emergency response by enabling real-time information exchange among vehicles and road infrastructure, including data such as speed, position, and potential hazards [1].

Despite these advancements, the reliability of VANET ecosystems fundamentally depends on the assumption that each participating vehicle possesses valid and trustworthy identification. However, this assumption is increasingly challenged. The growth of counterfeit, cloned, stolen, and expired license plates has become a pervasive global threat, exploited daily to evade electronic tolls, bypass congestion-charging zones, avoid speed camera penalties, commit hit-and-run crimes, smuggle contraband, and facilitate human trafficking across borders.

Moreover, these techniques can be leveraged to conceal vehicles involved in organized crime and terrorist operations [2,3]. Although law enforcement agencies in major urban regions intercept thousands of vehicles with forged plates annually, the actual scale of undetected cases is widely believed to be significantly higher, thereby creating a substantial blind spot in current traffic monitoring and public safety infrastructure.

As illustrated in Figure 1, conventional vehicle registration and verification systems rely on centralized databases maintained by government transport authorities. While effective for initial registration and periodic update systems, the revocation of compromised or fraudulent license plates often experiences delayed propagation across jurisdictions, enabling adversaries to exploit these temporal gaps. Furthermore, existing roadside verification mechanisms frequently disclose excessive sensitive information, including the owner’s identity, residential address, and full vehicle identification number (VIN), thereby exposing users to risks such as identity theft, unauthorized tracking, and surveillance.

To address these limitations, decentralized approaches, particularly blockchain-based solutions, have gained increasing attention due to their transparency, immutability, and tamper-resistance. Recent studies have explored blockchain for applications such as lightweight V2I handover authentication, secure V2X communication, pseudonym management, and a conventional centralized approach to vehicle ID validation [4]. However, existing approaches exhibit several limitations: they often depend on off-chain components, primarily focus on communication-level security, or fail to provide persistent and instantly revocable registration status with efficient, lightweight verification at scale.

In addition, current solutions are insufficient to provide a unified framework that simultaneously ensures real-time vehicle legitimacy verification, immediate revocation capability, strong privacy preservation, and efficient on-chain validation. To bridge this gap, this paper proposes a blockchain-based framework that integrates smart contracts with efficient cryptographic verification mechanisms. The proposed approach enables near-constant vehicle legitimacy verification while preserving data privacy and eliminating unnecessary exposure of sensitive data.

1.1. Contributions

The main contribution of this work can be summarized as follows:

• A dedicated on-chain vehicle legitimacy verification service capable of detecting fake, stolen, cloned, or expired vehicle identifiers using irreversible modular exponentiation and efficient hash table lookup, without revealing raw vehicle data.
• A trust-minimized smart contract framework is designed to perform verification in a stateless manner, eliminating reliance on trusted authorities (TAs) or consortium-controlled entities.
• The resilience of the proposed system against denial-of-service (DoS) attacks is evaluated, demonstrating significantly minimal delay compared to baseline approaches.
• A fully functional Ethereum-compatible prototype is implemented, and a comprehensive performance analysis is conducted, including verification latency, throughput, gas consumption, and scalability.

1.2. Paper Organization

The remainder of this paper is structured as follows. Section 2 reviews the existing blockchain-based vehicle registration and verification mechanisms in VANETs. Section 3 and Section 4 present the system and design objectives. Section 5 details the proposed privacy-preserving on-chain vehicle verification framework. Section 6 provides the security analysis. Section 7 presents implementation and experiments, and Section 8 shows the performance evaluation. Finally, Section 9 concludes the paper.

2. Related Work

Research in vehicular networks has focused primarily on two areas: (i) authentication in vehicular communication and (ii) vehicle identity management systems. While both domains emphasize security and privacy, they address different aspects of the system, namely communication security and vehicle-related data handling.

2.1. Authentication in Vehicular Communication

Securing vehicular communication has been widely studied through authentication, pseudonym management, and Sybil attack mitigation mechanisms. Shrestha et al. [1] proposed a regional blockchain architecture to improve resilience against majority attacks in VANETs. Khatri et al. [2] introduced a blockchain-based proof-of-location mechanism to mitigate Sybil attack, while Ahmed et al. [3] developed a secure protocol for emergency message dissemination.

To ensure message integrity and sender legitimacy, various authentication schemes have been proposed. He et al. [5] presented an identity-based conditional privacy-preserving authentication approach, and Azees et al. [6] proposed an efficient anonymous authentication scheme for VANETs. Tzeng et al. [7] introduced an identity-based verification scheme that improves efficiency by aggregating multiple signature verifications, though it relies on bilinear pairing operations. Ali et al. [8] introduced a certificate-based authentication framework, while Lu et al. [9] utilized blockchain for secure certificate management. Zhou et al. [10] proposed a blockchain-based conditional privacy-preserving authentication protocol that leverages smart contracts to enable secure and efficient message authentication in VANETs while preserving user anonymity. Deng et al. [11] proposed PAS, a privacy-preserving authentication scheme based on software-defined networking (SDN) to enhance scalability and security in VANETs. Other approaches, such as CREASE [12] and ESIA [13], focus on pseudoym management and scalable identity authentication.

Recent research has also explored improvements in system efficiency and architectural design. Haider et al. [14] proposed a blockchain-driven authentication framework to enhance trust and security in Internet of Vehicles (IoV) communication. Rahayu et al. [15] developed an integrated Kerberos-based authentication server that combines blockchain with centralized ticket management to improve authentication efficiency. Similarly, Juárez Cádiz et al. [16] introduced a hashgraph-based approach to optimize authentication performance in vehicular networks. In addition, lightweight and decentralized designs have been proposed to improve scalability. Specifically, Son et al. [17] presented a blockchain-based V2I handover authentication protocol to reduce authentication overhead during infrastructure transitions. In addition, scalable authentication schemes such as B-DSPA [18] focus on improving verification efficiency through batch processing and blockchain-assisted mechanisms. In parallel, threshold- and committee-based approaches, such as RIC-SDA [19] and Ghajar et al. [20], employ distributed trust across multiple entities.

Despite these advancements, existing approaches primarily focus on securing vehicular communications through message authentication, sender verification, session establishment, pseudonym management, and mitigation. Their primary objective is to ensure communication integrity and trustworthiness among the participating vehicles and infrastructure entities.

2.2. Vehicle Identity Management Systems

In addition to communication-level security, prior work also explored the use of blockchain for vehicle identity management, registration, and tracking. Benamar et al. [21], Rifat et al. [22], and Das et al. [23] developed frameworks to ensure data integrity and prevent tampering in vehicle identity records. Alharbi et al. [24] integrated license plate recognition with blockchain for automated identification, while Chen et al. [25] proposed a blockchain-based vehicle history tracking system. In addition, Rak et al. [26] explored VIN-based digital identity frameworks for forensic validation, Singh and Kim [27] proposed a blockchain-based vehicle data sharing framework to enable secure and decentralized access to vehicular information, while Zhang et al. [28] introduced a vehicle life cycle management system for tracking ownership and historical records in IoV environments. Although these approaches improve data integrity, traceability, and decentralized management, they primarily rely on complete record storage, ownership history tracking, or reputation-based validation mechanisms.

Consequently, verification often depends on retrieving stored records or performing additional off-chain evaluations, which may introduce latency and increase the exposure of sensitive vehicle-related information. Furthermore, these systems are not primarily designed for direct vehicle legitimacy verification by external sources. In contrast, the proposed framework addresses a different operational objective by enabling efficient blockchain-based validation of vehicle identifiers to detect fake, stolen, expired, or cloned vehicles while preserving privacy and avoiding access to the complete vehicle records.

Table 1. Comparison of Security Properties and Primary Functional Objectives of Existing VANET Approaches and the Proposed Framework.

Scheme	Privacy	Replay	DoS	Traceability	Blockchain	Message Authentication	Vehicle Legitimacy Verification
Vehicle Communication Authentication Schemes
[1] Shrestha (2020)	✓	Δ	×	Δ	✓	✓	×
[2] Khatri (2024)	✓	✓	Δ	✓	✓	✓	×
[3] Ahmed (2022)	Δ	Δ	×	Δ	✓	✓	×
[4] George (2021)	✓	✓	Δ	✓	✓	✓	×
[9] Lu (2019)	✓	✓	Δ	✓	✓	✓	×
[11] Deng (2022)	✓	✓	Δ	✓	×	✓	×
[14] Haider (2024)	✓	✓	Δ	✓	✓	✓	×
[17] Son (2022)	×	✓	×	Δ	✓	✓	×
[18] Li (2024)	✓	✓	Δ	✓	✓	✓	×
Vehicle Identity Management Systems
[21] Benamar (2021)	×	×	×	Δ	✓	×	×
[23] Das (2023)	✓	Δ	×	✓	✓	×	×
[24] Alharbi (2023)	×	×	×	Δ	✓	×	×
[25] Chen (2020)	×	×	×	Δ	✓	×	×
[26] Rak (2021)	✓	Δ	×	✓	✓	×	×
[28] Zhang (2021)	✓	×	Δ	✓	✓	×	×
[27] Singh (2017)	✓	×	×	Δ	✓	×	×
Proposed Scheme	✓	✓	✓	✓	✓	×	✓

✓ = supported, Δ = partially supported, × = not supported.

summarizes the functional objectives and security properties of existing approaches. It can be observed that prior studies primarily focus on either communication-level message authentication or vehicle identity management, whereas the proposed framework addresses vehicle legitimacy verification, such as detecting fake, stolen, expired, or cloned vehicle identities through direct identifier validation. Therefore, the performance comparisons presented in the subsequent sections are intended to provide architectural, computational, latency, and scalability perspectives rather than imply direct functional equivalence among the compared schemes.

3. System Design

The proposed work introduces a decentralized framework for vehicle number verification in dynamic vehicular environments. This framework leverages a private blockchain platform integrated with a smart contract and an on-chain hash table to enable efficient data storage and retrieval. The design emphasizes real-time validation while addressing critical challenges associated with forged, cloned, and stolen license plates.

To achieve this, the system includes a robust authentication mechanism that can withstand sophisticated attack strategies. Cryptographic techniques are used to protect data integrity and reduce the risks of data breaches and unauthorized access. In addition, the framework enhances operational efficiency by enabling rapid verification and response during high-demand or critical scenarios such as traffic enforcement and incident management. Furthermore, the proposed architecture employs an adaptive security paradigm to deal with evolving threats in vehicle networks. By eliminating centralized intermediaries, the system reduces single points of failure and strengthens resistance against insider and external attacks. Overall, the framework provides a secure, scalable, and privacy-preserving environment for vehicle legitimacy verification in dynamic VANET settings.

3.1. Participating Entities

The system architecture of the proposed framework, as shown in Figure 2, consists of multiple entities that collectively support secure vehicle legitimacy verification. The role of the principal entities are described below.

3.1.1. Vehicle Nodes

Vehicle nodes represent registered vehicles participating in the VANET environment. During the registration phase, vehicle information, including the license plate number and Vehicle Identification Number (VIN), is registered by the Government Authority. These inputs are securely processed and transformed before being recorded on the blockchain, ensuring that sensitive information is not exposed as plain text. In addition to the initial registration, vehicle nodes support life cycle-related actions, such as reporting theft or cloning events. Such updates are initiated by authorized entities and result in corresponding modifications to on-chain records without compromising data integrity. Overall, the vehicle nodes serve as data sources within the system, which ensures secure processing and privacy preservation.

3.1.2. Government Authorities

Government authorities are authorized regulatory entities responsible for vehicle registration, validation and life cycle management. Within a smart contract, there are administrative roles that enable the registration of new vehicles, record updates, and revocation of compromised identifiers. Each operation is recorded as an immutable blockchain transaction, thereby ensuring a complete audit trail and compliance with the regulatory requirements. Unlike traditional centralized systems, this approach eliminates delays in propagating updates across jurisdictions. Government Authority roles are assigned through a Role Assignment Authority ($RAA$) group, where a requesting user must satisfy the predefined threshold approval requirement before obtaining administrative privileges.

3.1.3. Smart Contract

The smart contract is a blockchain-resident program that autonomously enforces vehicle registration and verification rules. The smart contract functions as a decentralized and tamper-resistant registry for vehicle legitimacy verification. To preserve security and controlled participation, only pre-authorized nodes managed by governmental and law enforcement entities are permitted to interact with privileged contracts and functions. The smart contract is implemented in Solidity and encapsulates the registration and verification logic. Vehicle identifiers are stored exclusively in an on-chain hash table that maps the cryptographic representations of license plates and VINs to their corresponding validity statuses. The contract exposes restricted functions (enforced through role-based access control) for data insertion, modification, and revocation, along with public query functions that enable efficient verification and return only a Boolean legitimacy result. This architecture eliminates reliance on centralized databases, ensures rapid global consistency of updates, and prevents exposure of raw or reversible vehicle data, thereby providing a secure, scalable, and privacy-preserving solution for vehicle legitimacy verification.

3.1.4. Verifiers

Verifiers are Public Users who validate vehicle legitimacy through the blockchain interface. Upon observing a vehicle, the verifier extracts the visible license plate number and locally computes a blinded query using the public parameter of the smart contract. The generated query is submitted to the blockchain through the verification interface, where the smart contract performs a low-overhead verification and returns the legitimacy result. The query process does not reveal any raw vehicle data or vehicle identities. Although the originating Externally Owned Account (EOA) address may be observable at the network layer, the cryptographic information required to associate that address with a specific vehicle identity is neither published nor stored on-chain. This design ensures strong verifier privacy while preserving resistance to identity disclosure and tracking attacks.

4. Design Goals

The proposed framework was developed to achieve several key objectives, which ensure that the system provides a robust and efficient solution for verifying vehicle legitimacy, as detailed in the following subsections.

4.1. Tamper-Proof Registry

All registration and revocation events are permanently recorded on the blockchain, ensuring immutability and public auditability. No entity, including government authorities, can modify, delete, or falsify historical records without violating the underlying cryptographic guarantees of the system. This ensures transparency and trust in the integrity of vehicle identity records.

4.2. Real-Time Legitimacy Verification

The system enables any verifier (e.g., a vehicle or mobile device) to determine the legitimacy of an observed license plate in strict constant time with sub-second latency. This property remains stable even with large-scale deployments and high network loads. Efficient on-chain data structures are utilized to support rapid query processing without compromising performance.

4.3. Online Revocation

When a vehicle identifier is declared invalid (e.g., stolen, cloned, or expired) by an authorized government authority, revocation takes effect across the distributed architecture immediately after block confirmation. Using an online revocation model, the system eliminates the operational overhead of traditional revocation lists and avoids delays associated with manual propagation. This ensures automated and timely enforcement across all participating network entities as soon as the status is updated.

4.4. Verifier Anonymity

The system ensures that verification queries remain anonymous. No entity, including the blockchain network, compromised roadside infrastructure, or external observers, can associate a lookup query with a specific verifier identity. By isolating exposed network parameters from underlying vehicle identities, the system prevents tracking, profiling, and traffic analysis attacks, thereby preserving user privacy during lookup.

4.5. Target-Plate Privacy

Sensitive vehicle information, including license plate numbers and VINs, is never stored or transmitted in plain text. Instead, only irreversible cryptographic representations are used during registration and verification. This approach guarantees that even if the on-chain data are exposed, they cannot be reversed to reveal the original identifier.

4.6. Scalability and Efficiency

The framework is designed to minimize on-chain storage overhead and computational cost. The storage requirements per vehicle remain minimal, and gas consumption for registration, revocation, and verification operations is optimized to support large-scale deployment. The system avoids reliance on off-chain components, thereby ensuring consistent performance and a simplified system architecture.

5. Proposed Privacy-Preserving On-Chain Verification System

5.1. Overview of the Architecture

The proposed solution is built on an Ethereum-compatible blockchain network, where a smart contract implements an on-chain cryptographic hash table for the deterministic validation of vehicle identities. The architecture is designed to enable real-time, privacy-preserving detection of invalid vehicle identifiers while maintaining an efficient mapping-based lookup performance for verification operations, even under large-scale deployment conditions. Vehicle identifiers, including the license plate and vehicle identification number (VIN), are transformed using a modular exponentiation-based cryptographic blinding mechanism prior to storage. This ensures that only irreversible cryptographic representations are recorded on-chain, thereby preventing the direct exposure of sensitive information.

During the verification phase, users locally generate blinded queries using publicly available system parameters. These queries are submitted to the smart contract, which reconstructs the corresponding key and performs validation, returning only a Boolean legitimacy result without revealing any underlying data. Additionally, the framework incorporates role-based access control to regulate system interactions, ensuring that only authorized entities can perform sensitive operations, such as registration, modification, and revocation. The decentralized nature reduces number of single points of failure and enhances the resilience of the system. Furthermore, the design guarantees target identifier privacy, ensuring that neither the verifier nor the vehicle identity can be inferred from on-chain interactions. Overall, the proposed architecture provides a scalable, secure, and efficient solution for real-time vehicle legitimacy verification in VANET environments.

5.2. On-Chain Hash Table Construction

To enable efficient storage and retrieval of vehicle records, the smart contract maintains an on-chain hash-indexed data structure. Within this structure, each vehicle record is represented as a key-value pair, where the key corresponds to the cryptographically transformed vehicle identifier, and the value encapsulates the associated vehicle record, including hashed attributes and a validity flag. This design ensures that no raw or reversible vehicle data is stored on the blockchain, thereby preserving data confidentiality and integrity.

The underlying structure is implemented using Solidity mapping, which behaves as a hash-indexed key-value store rather than a conventional table. This enables efficient insertion, lookup, and update operations. Figure 3 illustrates the proposed on-chain hash table structure. Each vehicle identifier is transformed into a cryptographic representation before storage, allowing efficient retrieval and status management while preventing exposure of sensitive vehicle information. This structure is designed to support high-frequency verification scenarios and large-scale deployments, where a substantial number of queries must be processed efficiently. As the number of registered vehicles increases, the system maintains stable performance with consistent response times due to the efficient access property of the mapping.

To preserve blockchain immutability and auditability, vehicle records are never deleted. Instead, a flagging mechanism is employed to update the status of an existing record. When a vehicle is identified as invalid due to theft, cloning, or expiration, the corresponding record is updated through a single on-chain transaction by modifying the status flag. This approach ensures immediate consistency across the network while preserving the complete history of state changes. Overall, the proposed hash-indexed storage design provides efficient state management, fast lookup performance, and strong data integrity guarantees, making it suitable for real-time vehicle verification applications.

5.3. Access Control

The proposed framework employs a Role-Based Access Control (RBAC) mechanism to regulate interactions with the smart contract. It leverages the OpenZeppelin Access Control model [29], where permissions are assigned to predefined roles rather than individual users. Access decisions are determined according to assigned roles and associated permissions. This design improves scalability, security, and maintainability by ensuring controlled access to sensitive operations, where a user is permitted to execute an operation only if the assigned role explicitly authorizes that operation. This RBAC design ensures a minimal attack surface by isolating state-changing privileges to authorized roles, thereby restricting unauthorized contract interactions.

As illustrated in Figure 4, the system defines two primary entities: the System Admin and the Government Authority. The System Admin (contract deployer) holds the $DEFAULT\_ADMIN$ role, which is responsible for permission management and governance. The Government Authority holds the $GOVERNMENT\_AUTHORITY$ role and performs all state-changing operations, such as storing and updating vehicle records. Public users are not assigned privileged roles and are restricted to read-only operations.

5.3.1. Operations and Permissions

Each role is associated with a well-defined set of permissible operations, ensuring that sensitive operations are restricted to authorized entities.

Table 2. Access Control Policy for System Operations.

Operation	Gov. Authority	Admin	Public
Store Vehicle Data	✓	×	×
Modify Vehicle Status	✓	×	×
Verify Vehicle (Read-only)	✓	✓	✓

summarizes the access control policy for different roles in the system. State-changing operations are exclusively restricted to the Government Authority, ensuring controlled data management. The System Administrator is limited to governance functions such as role assignment and revocation, while public users are constrained to read-only operations. This separation enforces the principle of least privilege and prevents unauthorized state transitions.

5.3.2. Access Enforcement Mechanism

Access control is enforced at the smart contract level by verifying the role membership of the transaction sender prior to executing any protected function. The contract evaluates whether the caller address $(msg.sender)$ possesses the required role using the $hasRole(role,account)$ function provided by the OpenZeppelin framework. Access to protected functions is enforced through conditional checks of the form: $require\left(hasRole\right(REQUIRED\_ROLE,msg.sender\left)\right)$; Internally, role assignments are maintained using a nested mapping structure defined as:

$$\mathtt{mapping}(\mathtt{bytes}\mathtt{32}=>\mathtt{mapping}(\mathtt{address}=>\mathtt{bool})$$

where the outer mapping corresponds to role identifiers and the inner mapping associates roles with account addresses. The boolean value indicates whether a given address is assigned a specific role.

As shown in Figure 5, the smart contract verifies role membership during access-control checks. If the role condition is satisfied, the requested operation is executed; otherwise, the transaction is reverted. This mechanism ensures system integrity and protects against unauthorized state modifications. Furthermore, the integrity of the on-chain registry is protected through strict access control enforcement. All state-modifying operations, including insertion and status updates of vehicle records, are restricted to entities holding the $GOVERNMENT\_AUTHORITY$ role. Unauthorized attempts are automatically rejected by the smart contract through role checks.

In addition, all interactions with data must occur through predefined smart contract functions that enforce access policies. Although smart contract logic remains immutable after deployment, role assignments can be dynamically updated by authorized administrators, enabling flexible and secure access management.

Moreover, all authorized updates are recorded as immutable blockchain transactions, providing traceability and an auditable history of vehicle record modifications.

5.3.3. Role Hierarchy and Administrative Control

The access control model follows a hierarchical structure in which each role is governed by an administrative role. By default, all roles are managed by the $DEFAULT\_ADMIN$, which has the authority to grant and revoke roles. This design ensures that only trusted entities can modify access permissions, thereby preventing unauthorized privilege escalation.

Role assignment and revocation are performed through administrative operations using $grantRole\left(\right)$ and $revokeRole\left(\right)$ functions, respectively. These operations dynamically update role membership without requiring contract redeployment, enabling flexible and scalable permission management. All role management actions emit blockchain events, providing an immutable audit trail for tracking permission changes. This ensures transparency, traceability, and accountability in access management.

5.3.4. Threshold-Based Role Assignment Scheme

The framework employs a threshold-based signature scheme to reduce the risk associated with compromised administrative credentials. In conventional single-key administrative environments, the compromise of a Government Authority (GA) private key can enable an adversary to perform unauthorized administrative actions, including the registration of cloned or fraudulent vehicle records.

To mitigate this risk, we introduce a new entity called Role Assignment Authority ($RAA$) to handle the issue of role assignment to a specific requesting user. We assume that there are n users in the $RAA$ group, and they know the condition to grant the role of government authority to a specific request already. By requesting a minimum number of permissions, in the form of signature, the smart contract can assign the role of $GOVERNMENT\_AUTHORITY$ to a requesting user securely. The role of $DEFAULT\_ADMIN$ is given only to the user who generated the corresponding smart contract, and all the remaining users will have the role of Public User. More detailed role assignment process is explained from now on.

Let n denote the total number of $RAA$ and m denote the minimum number of approvals required to assign the Government Authority role. Role assignment is approved only when the number of valid approvals, in the form of signatures, satisfies the threshold condition:

$$|S_v| \ge m,$$

(1)

where $S_v$ represents the set of valid approvals associated with the request. Accordingly, the role assignment decision rule can be expressed as a conditional evaluation function:

$$AssignRole\left(Req\right)=\left\{\begin{array}{cc}GovernmentAuthority,\hfill & |S_v| \ge m,\hfill \\ PublicUser,\hfill & |S_v| < m.\hfill \end{array}\right.$$

(2)

Each role assignment request is associated with a unique nonce and timestamp to ensure that only requests satisfying the threshold condition are permitted to obtain Government Authority privileges. After successful role assignment, the newly added Government Authority user is authorized to update vehicle records maintained within the contract registry. This record modification process is represented as:

$$UpdateRecord\left(U\right)=\left\{\begin{array}{cc}TRUE,\hfill & Role\left(U\right)=GA,\hfill \\ FALSE,\hfill & Role\left(U\right)\ne GA,\hfill \end{array}\right.$$

(3)

where $Role\left(U\right)$ denotes the role associated with user U. To enforce these rules when a new requester asks for administrative privileges, the system evaluates incoming digital signatures against a verified registry pool. The set of valid approvals $S_v$ collected from the raw signature packet $S=\left\{(i,{\sigma }_i)\right\}$ is mathematically constructed by checking that each signature corresponds to a $RAA$ and is cryptographically authentic:

$$S_v=\left\{U_i\in \mathcal{U}|\exists (i,{\sigma }_i)\in S\wedge Verify(p{k}_i,H\left(Req\right),{\sigma }_i)=TRUE\right\},$$

(4)

where $\mathcal{U}=\{U_1,\dots ,U_n\}$ represents the total pool of $RAA$ users registered under the system infrastructure, and Verify is the signature evaluation function executed against the corresponding public key $p{k}_i$ and the request token hash digest $H\left(Req\right)$. To evaluate the signature array and filter out invalid submissions, an indicator function $\mathbb{I}\left(U_i\right)$ is utilized to flag valid administrative signatures:

$$\mathbb{I}\left(U_i\right)=\left\{\begin{array}{cc}1,\hfill & \mathrm{if}{U}_i\in \mathcal{U}\wedge \exists (i,{\sigma }_i)\in S\mathrm{such}\mathrm{that}Verify(p{k}_i,H\left(Req\right),{\sigma }_i)=TRUE,\hfill \\ 0,\hfill & \mathrm{otherwise}.\hfill \end{array}\right.$$

(5)

Thus, the total approval count is calculated by the following summation:

$$|S_v|=\sum _{U_i\in \mathcal{U}}\mathbb{I}\left(U_i\right).$$

(6)

Consequently, the threshold condition $|S_v| \ge m$ can only be satisfied when m entirely distinct, $RAA$ users independently authorize the request by signing the request message. Compromising fewer than m $RAA$ user credentials remains structurally insufficient to bypass the system defenses. This system prevents unauthorized record modifications and the insertion of cloned plates, maintaining absolute data truth and operational integrity. Signature generation and verification can be done more efficiently using the approach of BLS threshold signature [30], and the efficient signature mechanism will be investigated further in our future work.

5.4. Registration and Verification Procedures

The interaction flow of the proposed vehicle registration and verification system is illustrated in Figure 6. In this framework, vehicle owners initiate registration through authorized channels, while the Government Authority validates and records vehicle information on the blockchain.

During registration, the Government Authority encodes vehicle identifiers using modular exponentiation-based transformations. Let $x_1,x_2\in {\mathbb{Z}}_q$ denote secret components derived from the vehicle identifier. The encoded values are computed as:

$$y_2=g^{x_2}modq,y=g^{x_1+x_2}modq.$$

(7)

These values serve as irreversible cryptographic representations of the original identifier, ensuring that sensitive data is never stored in plain text on the blockchain. Instead, only encoded values are recorded, preserving confidentiality. To ensure secure system operation, record modification privileges are restricted to authorized entities through role-based access control implemented within the smart contract. This prevents unauthorized manipulation of vehicle records. The computed values (y, $y_2$) are stored in an on-chain hash table indexed using a hash-derived key h($y_1)$, enabling efficient mapping-based lookup for insertion, update, and retrieval operations. Furthermore, the framework incorporates a flagging mechanism to manage vehicle status without deleting records. Instead of removing entries, the system updates a status flag to indicate whether a vehicle is valid, expired, or compromised, preserving historical data and ensuring blockchain immutability.

During verification, a querying entity generates masked query values using a fresh random nonce $t\in {\mathbb{Z}}_q$:

$$y_{1^a}=g^{t}modq,y_{1^b}=g^{t+x_1}modq.$$

(8)

The verifier submits $(y_{1^a},y_{1^b})$ to the smart contract without revealing any raw vehicle information. Upon receiving the query, the smart contract reconstructs the identifier component using:

$$y_1=y_{1^b}·y_{1^a}^{-1}modq.$$

(9)

The reconstructed value is then used to retrieve the corresponding record from the on-chain registry. If no valid entry exists, the request is rejected. Otherwise, the smart contract verifies consistency using:

$$y=y_1·y_{2}modq.$$

(10)

If the condition holds, the contract returns true, indicating a legitimate vehicle; otherwise, it returns false. The correctness of this condition is formally analyzed in Section 6. Since the verification process involves a small number of arithmetic operations and a single mapping-based lookup, This makes the proposed framework well-suited for real-time vehicle legitimacy verification in VANET environments.

6. Security Model

The security of the proposed scheme is analyzed from two complementary layers. First, we examine the cryptographic security of the identifier encoding and verification mechanism. Second, we ensure secure enforcement of access control and on-chain integrity.

6.1. System and Adversarial Model

Let q be a large prime, and $G\subset {\mathbb{Z}}_q^{*}$ be a finite cyclic group of order q generated by g, where g denotes the generator of the group. All cryptographic operations in the proposed framework are performed over the group G. Parameters $x_1$ and $x_2$ represent secret encoding associated with a registered identifier. The parameter $t\in {\mathbb{Z}}_q$ denotes a fresh random nonce generated independently for each verification request and is used to randomize query generation. The notation $H(·)$ represents a cryptographic hash function.

We consider a standard Probabilistic Polynomial-Time (PPT), adversary denoted by $\mathcal{A}$, with the following capabilities:

• Access to all publicly available on-chain data;
• Ability to generate arbitrary verification queries;
• Inability to break standard cryptographic primitives or alter on-chain state without authorization.

• Since verification is performed through read-only smart contract functions, the adversary is restricted to observation-based interactions and queries.

6.2. Cryptographic Security Properties

6.2.1. Assumption 1: Discrete Logarithm Hardness

Given a generator $g\in G$ and element $g^{x}modq$, no PPT adversary can efficiently recover x. This assumption underpins the security of the identifier encoding and verification procedures.

6.2.2. Assumption 2: One-Wayness of Hash Functions

Let $H(·)$ denote a cryptographic hash function. Given $y_1=H\left(\mathit{identifier}\right)$, it is computationally infeasible for any PPT adversary to recover the original identifier.

6.2.3. Identifier Encoding Security

The encoding defined in Equation (7) ensures that recovering the secret components $x_1$ and $x_2$ from the stored values y and $y_2$ reduces to solving the discrete logarithm problem. Therefore, encoded identifiers are computationally secure under the DLP assumption.

6.2.4. Verification Query Construction

The verification query defined in Equation (8) incorporates a fresh random nonce $t\in {\mathbb{Z}}_q$ for each request. The query consists of two components, denoted by $(y_{1a},y_{1b})$, where the a and b are labels used to distinguish the two query element. As a result, the generated values $(y_{1^a},y_{1^b})$ vary across different verification attempts, even for the same vehicle identifier. This randomness ensures that query values differ across verification attempts, making direct observation of the underlying identifier more difficult. From the adversary’s perspective, the query values appear as random group elements, preventing any meaningful inference about the underlying identifier.

6.2.5. Correctness of Verification

The correctness of the verification procedure defined in Equation (10) is established as follows.

During verification, the smart contract first reconstructs the identifier component using Equation (9):

$$y_1=y_{1^b}·y_{1^a}^{-1}.$$

Substituting the query values from Equation (8), we obtain:

$$y_1=g^{t+x_1}·g^{-t}=g^{x_1}.$$

Thus, the reconstructed value correctly recovers the identifier component $g^{x_1}$ corresponding to the registered vehicle.

The smart contract then verifies the consistency condition using Equation (10):

$$y\stackrel{?}{=}{y}_1·y_2.$$

Substituting the stored values from the registration phase (Equation (7)), we get:

$$y_1·y_2=g^{x_1}·g^{x_2}=g^{x_1+x_2}.$$

Since the stored value y is also defined as $g^{x_1+x_2}$, the equality holds for all legitimately registered vehicles. Therefore, the verification procedures returns true for valid vehicles, thereby ensuring correctness, while invalid or forged queries are rejected.

6.2.6. Replay Attack Resistance

An adversary observing a verification query pair $(y_{1^a},y_{1^b})$ cannot recover the secret component $x_1$ due to the presence of the random nonce t. Specifically, the values $y_{1^a}=g^t$ and $y_{1^b}=g^{t+x_1}$ are masked by t, and extracting $x_1$ from these expressions requires solving the discrete logarithmic problem (DLP) in G, which is computationally infeasible under standard cryptographic assumptions.

Furthermore, each verification query incorporates a fresh nonce t. producing distinct query pairs $(g^t,g^{t+x_1})$ are across different verification attempts. This randomness generates unique query values for each verification attempt and prevents identical query messages from being repeatedly generated. Consequently, the scheme provides resistance against replay attacks, since previously captured query pairs cannot be reused to gain unauthorized verification advantages.

6.2.7. Isolation of Externally Owned Account Network Addresses

The proposed framework protects vehicle identity privacy by separating blockchain-facing identifiers from real vehicle identities during verification operations. Within the architecture, each vehicle operates using two identifiers: an externally owned account (EOA) address used exclusively for blockchain interactions and a temporary vehicle pseudonym used for local communications within the VANET [2].

An adversary monitoring public blockchain activity may observe persistent EOA addresses and correlate multiple verification requests originating from the same address over time. However, vehicle-identifying information, including the license plate number and VIN, is never exposed on-chain. Furthermore, the cryptographic relationship between an EOA address, a vehicle pseudonym, and the corresponding real vehicle identity is neither publicly disclosed nor stored within the system. Consequently, although transaction continuity may be observable at the EOA level, the observed blockchain activity cannot be directly attributed to a specific vehicle identity.

When a vehicle interacts with the blockchain through nearby RSUs, both the active EOA address and the current temporary vehicle pseudonym may be observable within the local VANET environment. However, the pseudonym mechanism is designed to be short-lived and periodically updated. Even if an observer associates a temporary pseudonym with an active EOA address during a communication session, this association does not reveal the real vehicle identity. Since the pseudonym contains no information linked to the physical vehicle, the actual license plate number and VIN remain decoupled from operational identifiers, thereby preserving vehicle identity privacy throughout the verification process.

6.2.8. Resistance to Man-in-the-Middle Attack

The proposed framework mitigates man-in-the-middle attacks by protecting communication between vehicles and the blockchain infrastructure through RSU-mediated secure channels.

We assume that the RPC endpoint is deployed within RSUs infrastructure and all verification requests from the vehicles are forwarded. Communication between vehicles and RSUs is protected using PKI-based authentication, pseudonym certificates, and session key establishment. This design follows the security principles established by Raya and Hubaux [31] and incorporates modern vehicle-to-infrastructure authentication mechanisms proposed by Liu et al. [32]. These mechanisms provide message authenticity and integrity during transmission, preventing unauthorized interception and modification of verification requests. Since blockchain interaction occurs only after RSU-level authentication and validation, unauthorized entities cannot inject or modify verification requests through the communication channel.

6.2.9. Soundness and Inference Resistance

The proposed scheme ensures soundness by preventing invalid, expired, or unregistered vehicles from being falsely verified as legitimate. For any such vehicle, the corresponding on-chain record is either absent or marked as inactive through a flagging mechanism, leading to immediate verification failure during the lookup and consistency check process.

From a cryptographic perspective, forging a valid verification without knowledge of the secret component $x_1$ is infeasible. Any adversary attempting to construct a valid pair $(y_{1^a},y_{1^b})$ that satisfies the verification equation must implicitly solve the discrete logarithm problem, which is computationally hard. The reconstruction of $y_1=g^{x_1}$ during verification does not reveal secret $x_1$. Due to the one-way nature of exponentiation in cycle groups, extracting $x_1$ from $g^{x_1}$ is infeasible. Therefore, the scheme prevents any leakage of sensitive identifier information, ensuring strong resistance against inference attacks while preserving privacy.

6.2.10. Public Verifiability

The proposed framework supports public verification through read-only smart contract functions. Any entity can perform verification without requiring special privileges, while cryptographic protections ensure that such interactions do not compromise privacy and security.

6.2.11. Overall Security Guarantee

Under the discrete logarithm assumption and the one-wayness of the hash function, the proposed scheme ensures:

• Correctness verification of legitimate vehicles;
• Identifier privacy;
• Soundness against false positives;
• Resistance to inference and replay attacks.

• These guarantees follow directly from the stated assumptions and the security properties of the encoding and verification mechanisms.

6.3. Smart Contract Security Design

6.3.1. Language-Level Safety Mechanisms

The smart contract is implemented using Solidity version 0.8.20, which provides built-in protection against integer overflow and underflow. In Solidity versions 0.8.0 and above, arithmetic operations automatically revert upon detecting overflow or underflow conditions [33]. This eliminates the need for external libraries such as SafeMath and mitigates common arithmetic vulnerabilities at the language level. By leveraging these native safety features, the proposed framework enhances the reliability and robustness of on-chain legitimacy management, ensuring that unintended arithmetic errors do not compromise contract execution.

6.3.2. Role-Based Access Control

The proposed smart contract employs the Openzeppelin Access Control module [29] to enforce fine-grained role-based authorization. Distinct roles are defined using $bytes32$ identifiers, such as $GOVERNMENTAUTHORITY\_ROLE$, to regulate access to critical functions. Operations that modify legitimacy status, including registration, updates, and revocation, are protected using the $onlyRole$ modifier. As a result, any transaction initiated by an unauthorized entity is automatically reverted by the Ethereum Virtual Machine (EVM), thereby preventing unauthorized state modifications and preserving system integrity.

6.3.3. On Chain Integrity

All vehicle legitimacy records are stored on-chain within an immutable ledger. Once a record is written to the blockchain, it cannot be altered or deleted retroactively. Instead of removing entries, the framework adopts a flag-based status update mechanism to track changes in vehicle validity. Each state transition (e.g., valid, expired, revoked) is recorded as a new transaction, ensuring full traceability and auditability. Additionally, smart contract events are emitted for every state-changing operation, enabling transparent monitoring and accountability of administrative actions. This design ensures strong data integrity while preserving the complete historical record of all vehicle states.

6.4. Summary

• The security of the proposed scheme is evaluated through a comprehensive analysis of both its cryptographic foundations and smart contract-level protections. The objective is to ensure that the system provides strong guarantees in terms of correctness, privacy preservation, robustness against adversarial behavior, and secure on-chain execution.
• From a cryptographic perspective, the framework ensures that sensitive vehicle identifiers are never exposed in plain text form. Instead, identifiers are transformed into irreversible cryptographic representations prior to storage in the blockchain. This encoding mechanism prevents adversaries from reconstructing original vehicle information, even when full access to on-chain data is assumed. The security of this approach relies on the hardness of the discrete logarithm problem and the one-wayness of the employed hash function, ensuring that identifier privacy is preserved under standard cryptographic assumptions.
• The verification process is designed to maintain both correctness and privacy. Legitimate vehicle identifiers are consistently validated through deterministic reconstruction and matching of cryptographic components stored in the on-chain hash table. At the same time, the use of randomized query construction ensures that verification requests do not leak sensitive information. Each query incorporates a fresh nonce. As a result, query instances are statistically independent. This property prevents adversaries from linking multiple verification attempts to the same vehicle or verifier.
• The framework also provides inherent resistance to replay and forgery attacks. Since each verification request depends on a newly generated random nonce, previously observed query pairs cannot be reused to produce valid verification outcomes. Furthermore, generating a valid query without knowledge of the secret identifier components requires solving the discrete logarithm problem, which is computationally infeasible. This ensures that adversaries cannot impersonate legitimate vehicles or manipulate the verification process.
• In terms of system correctness and robustness, the proposed scheme guarantees that only valid and active vehicle records are accepted during verification. Invalid, expired, or revoked identifiers are detected through the absence of a corresponding active entry or through a flagging mechanism within the on-chain registry. This eliminates false positives and ensures reliable decision-making during real-time verification. The use of a flag-based update mechanism further ensures that revocation events are immediately reflected across the network while preserving historical records for auditability.
• The architecture guarantees high resilience against communication-layer vulnerabilities, specifically mitigating man-in-the-middle (MitM) attacks during query dissemination. By enforcing an RSU-mediated pipeline where vehicle nodes never connect directly to the exposed blockchain RPC endpoint, eavesdropping and malicious payload injection are effectively neutralized. The integrity of the transit channel is fully preserved via robust session keys and standard cryptographic architectures, preventing adversarial manipulation of the verification flow.
• The scheme preserves privacy during real-time verification by separating blockchain-facing identifiers from vehicle identities. Although EOA addresses are visible during blockchain interactions, the association between an EOA address, vehicle pseudonym, and physical plate number is not published on-chain. Therefore, blockchain observers cannot directly associate an exposed address with a real vehicle identity through publicly available data.
• Beyond cryptographic protections, the framework incorporates strong smart contract-level security mechanisms to safeguard on-chain operations. Role-based access control limits sensitive actions, such as vehicle registration information and status updates, to authorized entities. Any unauthorized attempts to modify contract state are automatically rejected by the Ethereum Virtual Machine, preventing malicious manipulation. Additionally, the immutability of blockchain data ensures that once a record is committed, it cannot be altered or removed, thereby guaranteeing data integrity and resistance to tampering. Overall, the integration of cryptographic protections, randomized verification, controlled access mechanisms, and immutable on-chain storage ensures that the proposed framework operates securely within a decentralized vehicular network environment. The system provides strong guarantees of privacy, correctness, and resistance to a wide range of adversarial attacks, making for real-time vehicle legitimacy verification at scale.

7. Implementation and Experimental Setup

The proposed vehicle legitimacy verification framework was systematically implemented and empirically evaluated using a blockchain framework. The core smart contracts were authored using Solidity (version 0.8.20) to ensure secure, optimized, and deterministic execution on the Ethereum Virtual Machine (EVM). The Hardhat framework [34] was utilized as the primary development suite for compiling, testing, and debugging the smart contracts locally prior to network deployment. Cryptographic field transformations and identity checking loops were established over a 256-bit prime field (q) using a generator (g) selected from ${\mathbb{Z}}_q^{*}$, with a standard keccak256 hashing implementation serving as the identity mapping function.

To evaluate the system under realistic network conditions and practical deployment constraints, the compiled smart contracts were deployed directly onto the Ethereum Sepolia testnet. This setup allowed our evaluation to capture actual remote procedure call (RPC) communication overheads, decentralized node state lookup, and wide-area network transport jitter. This deployment process was executed using asynchronous Node.js scripts leveraging the Ethers.js library, which interfaced with public Sepolia node gateways to commit the contract bytecode to the public ledger state.

The proposed framework supports role-based vehicular operations, including secure vehicle registration, status updates, and verification loops. The Government Authority (GA) initiates on-chain state-changing transactions to register vehicle records or update operational flags.

In contrast, public verifiers interact with the system through read-only smart contract calls to validate vehicle legitimacy without modifying blockchain state. These queries are executed locally on a node using $eth\_call$, enabling efficient state retrieval without requiring transaction mining or consensus confirmation, thereby supporting verification requirements in intelligent transportation systems.

To manage decentralized user interactions and transaction signing, MetaMask was used as the client-side wallet interface to sign and execute transactions on the Sepolia testnet. All experiments were conducted on a local machine running Microsoft Windows 11 Pro (Build 22631), equipped with an 11th Generation Intel^® Core^TM i7-11700 processor (2.50 GHz, 8 cores, 16 logical processors) and 64 GB RAM. This hardware configuration ensured a stable and reproducible environment for evaluating the performance and correct- 582 ness of the proposed framework.

7.1. Smart Contract Deployment

The vehicle registration smart contract was developed in Solidity and integrated with OpenZeppelin Access Control [29] to enforce role-based authorization. A dedicated assigned role, $GOVERNMENT\_AUTHORITY$, is defined using a hash-based identifier $keccak256$ (“$GOVERNMENT\_AUTHORITY$”). This role is granted by the contract administrator and restricts vehicle registration and update operations.

Although initial compilation and execution logic was verified locally within the Hardhat development suite, the main performance benchmarks—including latency scaling loops, network throughput profiles, and system-level saturation capacity boundaries—were captured from the live Sepolia testnet infrastructure. This experimental design isolates baseline EVM execution metrics such as gas consumption and system latency and throughput under varying transaction loads.

From an operational perspective, the contract leverages efficient $mapping$ structures to store cryptographic representations of vehicle identifiers, enabling deterministic address-based access for insertion, update, and verification operations. Additionally, the verification function $verifyPlate\left(\right)$ is implemented as a $view$ function, enabling read-only access to blockchain state. These queries are executed using $eth\_call$, which directly retrieves data from a local node without creating a blockchain transaction. This ensures a low-latency vehicle verification without requiring gas consumption or transaction mining Structural auditability is fully maintained across the decentralized framework via the programmatic emission of $VehicleStored$ and $VehicleDeactivated$ event logs during execution state transitions.

The overall execution flow of the proposed system is organized across an event-driven validation process. Initially, the Government Authority registers a vehicle through MetaMask, broadcasting the signed payload to the Ethereum Sepolia testnet. Upon arrival, the smart contract performs access control verification using the $GOVERNMENT\_AUTHORITY$ role before allowing execution. Following successful role clearance, the smart contract stores the encoded vehicle record in the mapping data structure, and the state is updated accordingly. Subsequently, event logs such as $VehicleStored$ are emitted to ensure auditability of state transitions. Concurrently, public verifiers communicate directly through a blockchain Remote Procedure Call (RPC) network endpoint to perform read-only queries using $eth\_call$ through the $verifyPlate\left(\right)$ function, checking the legitimacy status of the vehicle without incurring transaction costs or modifying the blockchain state.

7.2. Data Storage and Verification Mechanism

Vehicle records are stored on-chain using a Solidity mapping data structure, where each plate number serves as a unique key associated with a structured record. This record contains the cryptographically protected vehicle attributes along with a boolean validity flag indicating the current operational status of the vehicle.

The core contract functions include $storeVehicle\left(\right)$, $deactivateVehicle\left(\right)$, and $verifyPlate\left(\right)$, which manage vehicle registration, status updates, and legitimacy verification, respectively.

Initially, every registered vehicle is assigned an active status ($true$) within the ledger mapping layout. Upon identification of an expired, cloned, or malicious identifier, the Government Authority initiates an on-chain transaction to update the corresponding flag to ($false$). This flag-based mechanism provides an efficient online status tracking method, enabling immediate visibility of legitimacy updates across the network once committed to a block, without requiring computationally heavy data deletion or storage reorganization overheads.

The registration incorporates an automated existence check to prevent duplicate entries; a new record is initialized only if the corresponding key does not already exist within the active directory mapping, ensuring strict data consistency.

As shown in Figure 7, the system performs a deterministic lookup to verify whether a vehicle plate number exists in the on-chain registry. Each plate number identifier is first corresponding cryptographic representation and mapped to a storage slot using the Ethereum Virtual Machine (EVM) storage addressing mechanism based on $keccak256$. The resulting key is then used to query the Solidity mapping stored cryptographic values (y, $y_1$, and $y_2$) together with the validity flag. The validity flag is set to $true$, indicating that the queried vehicle record is currently active and legitimate. Importantly, the lookup process only confirms the existence and validity of a registered vehicle record and does not reveal sensitive vehicle information such as the actual plate number or VIN, thereby preserving user privacy while maintaining on-chain integrity.

During vehicle registration, the Government Authority initiates a state-changing write transaction through the client interface, as depicted in Figure 8. The transaction parameters are digitally signed using MetaMask and transmitted to the blockchain network for execution of the $storeVehicle\left(\right)$ function. After successful validation and block confirmation, the vehicle record is permanently committed to the distributed ledger state. In addition, corresponding blockchain events are generated, providing a complete and auditable history of registration activities.

For legitimacy verification, the read-only function $verifyPlate\left(\right)$ retrieves the corresponding mapping entry and evaluates the stored validity flag. If the queried record exists and the flag remains active, the function returns $true$, indicating that the vehicle is legitimate and operational. Furthermore, the combination of hash-based indexing combined with lightweight modular arithmetic enables efficient query execution resolutions while avoiding computationally expensive cryptographic operations.

7.3. Gas Consumption Analysis

To evaluate the cost of the proposed system, the gas consumption was measured for contract deployment, state-modifying operations, and query routines. Initial transactional baselines were collected during development, followed by full gas profiling executed across our Ethereum Sepolia testnet deployment infrastructure to ensure realistic measurement under production EVM parameters.

The initialization deployment of the smart contract required 1,084,257 gas units. This cost is primarily driven by bytecode initialization, constructor execution, and initial state storage allocation. As illustrated in Figure 9, the vehicle registration (insertion) operation consumes 91,624 gas. This operational cost is dominated by state initialization and storage write operations ($SSTORE$), which represent computationally heavy instructions within the Ethereum Virtual Machine.

The update operation, which modifies the operational flag of a registered vehicle identifier, consumes 24,516 gas units. This lower consumption profile directly reflects the efficiency of the flag-based state updates, since modifying an existing storage slot avoids the high cost of initializing empty memory records. The verification function is implemented as a stateless $view$ function invoked through ($eth\_call$). Since the operation does not modify the blockchain state, it does not require transaction submission, gas payment, or block confirmation during normal vehicle verification. Consequently, the verification latency is primarily determined by RPC communication and smart contract execution rather than transaction-processing overhead. To quantify the internal EVM execution cost, a transactional test wrapper function ($verifyPlateTx$) was used exclusively for profiling purposes. This allows the computational overhead of the verification logic to be measured in gas units while preserving the read-only behavior of the original verification routine. As illustrated in Figure 9, the verification operation consumes substantially less gas than state-changing functions because it is dominated by storage-read operations ($SLOAD$) and lightweight modular arithmetic computations rather than storage-update operations.

To evaluate whether registry growth affects verification cost, the transaction-based wrapper function $verifyPlateTx\left(\right)$ was evaluated across expanding registries containing 100, 1000, and 5000 stored vehicle records. The measured gas consumption is summarized in

Table 3. Impact of Registry Size on Verification Gas Consumption.

Stored Vehicle Records	Verification Gas (Units)
100	71,825
1000	71,825
5000	71,825

.

As shown in Table 3, the verification cost remained unchanged at 71,825 gas units across all evaluated registry sizes. No measurable increase was observed as the number of stored records increased. These results indicate that the mapping-based lookup mechanism introduces negligible lookup overhead within the evaluated range and maintains a stable verification cost profile.

8. Performance Evaluation

This section presents the experimental evaluation of the proposed framework in multiple performance metrics, including computational cost, latency performance, system scalability, and security resilience. To ensure a fair comparison, different baseline schemes are selected for each metric based on their relevance and the reported evaluation characteristics. This metric-specific benchmarking approach enables an accurate assessment of the proposed scheme under diverse operational conditions.

8.1. Storage and Registration Throughput

The storage efficiency is evaluated in terms of registration throughput, defined as the number of vehicle records processed per second as the registry size increases. Each vehicle insertion corresponds to a state-changing transaction executed via $eth\_sendTransaction$, which requires storage initialization and processing within the Ethereum Virtual Machine (EVM). Throughput was measured by executing sequential registration transactions and computing the average number of successful insertions per second.

As illustrated in Figure 10, the proposed scheme maintains consistent registration performance as the data registry grows. The evaluated workloads track an increasing number of registered vehicle entries and the corresponding cumulative blockchain storage allocation.

In the experimental setup, the registry scale was expanded from 1000 to 100,000 vehicle records, with larger registry volumes producing cumulative storage footprints scaling from 2 MB to 12 MB. This defines a predictable, linear database expansion model. Every unique vehicle entry consumes a compact, fixed ledger storage space. This footprint is achieved by mapping variable license plate and vehicle identification inputs into fixed-size 32-byte fields ($uint256$) combined with a 1-byte boolean operational status flag. The registration throughput decreases from 51 insertions/s at the initial registry scale 1000 records to 35 insertions/s as the registry reaches the maximum evaluated scale of 100,000 records, representing a gradual and controlled performance decline under an increasing storage load.

This stable behavior is primarily achieved by using direct key-based storage addressing instead of an iterative data structure. The system scales smoothly to large registries without introducing memory fragmentation or record-length tracking overheads.

The observed reduction in registration velocity reflects the standard processing overhead associated with expanding on-chain state depth, including EVM storage write functions ($SSTORE$) and state tree synchronization requirements. Despite these standard ledger constraints, the framework maintains a stable registration capacity, demonstrating its practical suitability for managing large-scale vehicle registries. The experimental results, compiled using our contract deployment framework, validate the efficiency of the storage layout and confirm that the system delivers predictable and scalable data management behavior across expanding database boundaries.

8.2. Computational Cost and Communication Analysis

The computational efficiency of the framework is analyzed by examining both the registration and verification procedures. During registration, the Government Authority computes cryptographic values $(y,y_1,y_2)$ derived from the encoded vehicle identifiers using modular arithmetic and hash-based transformations. These values serve as irreversible representations of the original identifiers and are stored inside the smart contract state. The computational cost of this phase is primarily dominated by modular exponentiation.

The verification procedure is composed of three sequential operations: reconstruction of an intermediate parameter, deterministic mapping lookup, and consistency validation. To initiate verification, the querying entity generates two blinded values ($y_1^a$, $y_1^b$) using a fresh random nonce combined with the underlying identifier components. Upon receiving these inputs, the smart contract reconstructs the required parameter using one modular inverse ($T_{inv}$) and one modular multiplication ($T_m$). An additional modular multiplication is required during the consistency verification, resulting in a total of $2T_m$ operations. The modular inversion, typically performed via binary exponentiation, constitutes the dominant cost in this step. The reconstructed value is then used for an efficient mapping-based lookup within the smart contract state. A summary of the computational cost is provided in

Table 4. Computational Cost Analysis.

Operation	Count
$T_{inv}$	1
$T_m$	2
$T_h$	1
Total Computational Cost	$T_{inv}+2T_m+T_h$

.

For computational analysis, the proposed scheme is compared with representative authentication-oriented approaches, including EBCPPA [10], PAS [11], and B-DSPA [18]. Since these schemes focus on message authentication, signature verification, and batch verification, whereas the proposed framework performs vehicle legitimacy verification through identifier validation, the comparison is intended to provide insight into computational overhead and scalability characteristics across different vehicular security architectures. The compared baselines rely on heavy, compute-intensive cryptographic primitives such as bilinear pairing and elliptic curve scalar multiplication to secure full message structures. Specifically, B-DSPA relies on bilinear pairing $\left(T_{bp}\right)$ and scalar multiplication $\left(T_{sm}\right)$, resulting in a processing cost of approximately 4.65 ms for a single verification routine. Similarly, PAS involves multiple pairing operations and modular transformations, leading to a higher computational cost of approximately 12.59 ms. Furthermore, EBCPPA involves pairing-based signature verification and hash computations, resulting in a reported computational overhead of approximately 17 ms. These evaluation markers confirm that pairing operations ($T_{bp}$) and heavy group operations are the primary processing bottlenecks in traditional authentication infrastructure.

In contrast, the proposed scheme avoids pairing-based cryptography or high-overhead group signatures entirely, employing lightweight field primitives such as cryptographic hashing $\left(T_h\right)$, modular multiplication $\left(T_m\right)$, and modular inversion $\left(T_{inv}\right)$. These primitives incur significantly lower processing costs, resulting in improved runtime efficiency. This deliberate architectural design choice is highly suited for real-world vehicular environments where low-latency verification is required to guarantee road safety. Figure 11 illustrates the comparative computational cost, highlighting the processing efficiency gained by replacing signature-heavy operations with lightweight modular arithmetic.

From a communication perspective, the framework introduces minimal and fixed overhead. During registration, three 256-bit values $(y,y_1,y_2)$ are transmitted, resulting in a total communication cost of 768 bits (96 bytes). In contrast, each verification request requires the transmission of two 256-bit parameters $(y_{1a},y_{1b})$, resulting in a total communication overhead of 512 bits ($64bytes$). The smart contract returns only a boolean result, incurring negligible response overhead. Importantly, the proposed scheme eliminates the need for auxiliary verification data such as certificates or digital signatures. As a result, the communication overhead remains constant and independent of the registry size, ensuring scalability and transit efficiency in large-scale vehicular network environments. The communication characteristics are summarized in

Table 5. Communication Overhead Analysis.

Phase	Communication Cost
Registration Phase	768 bits (96 bytes)
Verification Input	512 bits (64 bytes)
Verification Output	≈1 bit
Total (Verification Phase)	512 bits (64 bytes)

.

8.3. Latency Performance

The verification latency of the framework is evaluated under varying vehicle loads to assess its scalability and operational efficiency in vehicular environments. These empirical measurements are collected using the smart contract deployed on the Ethereum Sepolia testnet, where the query logic is executed via stateless read-only operations ($eth\_call$) to eliminate transaction mining delays and accurately isolate end-to-end response times.

Latency is defined as the total elapsed time between a verifier submitting a query and receiving the validation response from the smart contract registry. Since verification is handled via stateless call loops, the measured performance primarily reflects remote procedure call (RPC) network latency, wide-area transport delays, and internal smart contract mapping lookups. As illustrated in Figure 12, the average verification latency of the proposed framework remains exceptionally stable as the workload scales from 100 to 1000 vehicles. The measured latency primarily reflects RPC communication overhead, network delay, and smart contract execution time rather than block confirmation latency.

To provide additional architectural context, the observed performance is compared against the centralized, Kerberos-based authentication architecture proposed by Rahayu et al. [15]. The comparison is included to illustrate how different architectural designs behave under increasing vehicle loads and to evaluate scalability trends and latency stability. At the baseline workload of 100 vehicles, the centralized scheme exhibits lower authentication latency than the proposed framework. This difference is primarily attributed to the fixed RPC communication and network overhead associated with retrieving blockchain state from the Ethereum node. However, as the workload increases toward 1000 vehicles, the latency of the centralized architecture grows more rapidly, whereas the proposed framework maintains a relatively stable latency profile. This behavior is attributed to the use of direct address-based state indexing for verification operations, which minimizes lookup overhead and avoids centralized processing dependencies. Overall, the results demonstrate that the proposed framework maintains consistent verification latency under increasing vehicle workloads, indicating scalability for intelligent transportation environments.

8.4. Throughput Performance

The system’s operational capability is evaluated by measuring the verification throughput directly on the Ethereum Sepolia testnet. Throughput is quantified as the number of successfully processed verification requests per second (req/s) as the input workload scales progressively from 100 to 10,000 concurrent requests. This experimental setup naturally captures wide-area internet communication latency and network jitter.

As illustrated in Figure 13, the throughput scales from $102.89$ req/s to a peak of $231.80$ req/s at a workload of 1000 requests, driven by the use of asynchronous parallel request processing and connection pooling. Beyond this point, as the query density reaches 10,000 concurrent requests, the system enters a highly stable saturation plateau, maintaining a resilient processing bound between $215.12$ req/s and $224.77$ req/s. The proposed verification routine relies entirely on read-only smart contract invocations ($eth\_call$). Since these operations execute without state transitions, the measured throughput is predominantly influenced by RPC communication latency and smart contract execution performance. Therefore, the reported results reflect the efficiency of the verification mechanism itself rather than consensus, transaction propagation, mempool contention, or block confirmation processes.

8.5. DoS Resilience Under Flooding Attacks

The resistance of the proposed scheme against Denial-of-Service (DoS) attacks is evaluated under flooding conditions by analyzing the request processing delay as the concurrent request density scales. In this scenario, an adversary attempts to exhaust infrastructure resources by bombarding the verification interface with a massive volume of validation requests. Unlike signature-heavy protocols, the proposed approach focuses on lightweight verification, minimizing the computational footprint required per incoming query.

The request processing delay evaluated in this section represents the local execution time required to process a verification request at the node level and does not include end-to-end network communication latency.

For DoS resilience analysis, the proposed scheme is comparatively evaluated against representative vehicular security frameworks such as CBS [15] and B-DSPA [18], as these approaches explicitly document localized request processing bottlenecks under escalating workload stress. The reported delay reflects the computational processing time required to execute the verification routine. Therefore, the comparison is intended to illustrate processing scalability and workload resilience rather than establish direct functional equivalence among the evaluated schemes.

Despite these distinct operational profiles, tracking the processing delay reveals how different cryptographic designs handle traffic accumulation under stress. The B-DSPA scheme verifies vehicle messages using elliptic curve cryptography (ECC) batch signature verification, which introduces computationally intensive primitives such as bilinear pairing ($T_{bp}$) and scalar multiplication ($T_{sm}$) at the Roadside Unit (RSU) layers. As the flooding injection rate increases, its processing delay escalates linearly due to the compounding computational overhead of verifying complex group signatures for every incoming payload.

Similarly, the CBS baseline architecture proposed by Rahayu et al. [15] utilizes a centralized server infrastructure to process multi-stage Kerberos token distribution handshakes. While highly optimized under low-density traffic, it encounters queuing delays and processing overhead under adversarial flooding conditions. When the request injection density scales to higher concurrent dimensions, centralized session-table lookup, cross-site directory index congestion, and state synchronization demands introduce processing bottlenecks at the core processor, leading to a notable, non-linear increase in the verification processing delay.

As illustrated in Figure 14, both B-DSPA and CBS exhibit a steady escalation in request processing delays under flooding conditions due to their heavy computational and state-tracking dependencies. In sharp contrast, the proposed scheme maintains an exceptionally near-constant processing envelope, with the isolated execution delay remaining consistently below 3 ms across all dense concurrency intervals. Because our verification routine relies entirely on stateless field arithmetic ($2T_m+T_{inv}$) and $\mathcal{O}\left(1\right)$ deterministic address lookup resolved via read-only interface queries ($eth\_call$), individual executions do not trigger database lock contentions or transaction serialization bottlenecks. Consequently, the node resolves the cryptographic verification routines rapidly, preventing execution stalls at the processing layer and confirming the protocol’s structural resilience under dense traffic workloads.

9. Conclusions

This paper presented a privacy-preserving, blockchain-based vehicle legitimacy verification framework tailored for vehicular ad hoc networks (VANETs). By introducing a decentralized layout driven by an Ethereum smart contract, the system reduces the security risks and communication bottlenecks associated with traditional centralized intermediaries. The underlying cryptographic architecture optimizes on-chain access costs, enabling efficient mapping-based lookup that minimizes the exposure of sensitive vehicle identifiers and verifier-related information during verification. Experimental evaluations executed on a practical active Ethereum testnet demonstrate that the system maintains low end-to-end processing latency and stable throughput, validating its practicality, scalability, and resilience under verification workloads. Future research will focus on improving query unlinkability to prevent different verification requests from being correlated over time.