Challenges and Solutions for Vehicular Ad-Hoc Networks Based on Lightweight Blockchains

Abstract

Current research with Vehicular Ad-hoc Networks (VANETs) has focused on adapting an efficient consensus mechanism and reducing the blockchain size while maintaining security. Care must be taken when implementing blockchains within VANET applications to leverage the chains’ strengths while mitigating their weaknesses. These chains can serve as distributed ledgers that provide storage for more than financial transactions. The security provided by longer blockchains constitutes a nearly immutable, decentralized data structure that can store any data relevant to the applications. However, these chains must be adapted to the ad-hoc, resource-constrained environments found in VANETs. In the absence of abundant resources and reliable network connections, chain operation and maintenance must address the challenges presented by highly mobile nodes in novel ways, including situations such as emergency messaging that require real-time responses. Researchers have included different mechanisms to realize lightweight blockchains, such as adding reputation to existing consensus mechanisms, condensing the consensus committees, using geographical information, and monitoring a nodes behavior in attempts to adapt blockchains to these domains. This paper analyzes the challenges and gives solutions for these different mechanisms to realize lightweight blockchains for VANETs.

1. Introduction

The developments in computational power and communication capabilities have materialized novel technologies. Blockchain is one such application that has become extremely popular in the last decade. Blockchains provide secure, public, tamper-resistant ledgers for recording transactions among a chain’s users. They operate with a centralized authority in permissioned chains and without one in permissionless chains [1]. They have found uses in a range of applications, including finance, education [2], industrial Internet of Things (IIoT) [3], etc.

The growth of urban populations makes traffic congestion, accident reduction, and environmental impact mitigation increasingly challenging. In traditional traffic management systems, these demands often lead to wasted time, increased pollution, and compromised safety. A smart city is a solution to this problem. By leveraging technology and data, smart cities can create more efficient and sustainable urban environments. Enhancing traffic management is a crucial aspect of smart city development. By utilizing real-time data, predictive analytics, and intelligent infrastructure, cities can optimize traffic flow, reduce congestion, improve safety, and minimize the environmental footprint of transportation systems. Vehicular ad-hoc networks (VANETs) [4] can play a vital role in transforming the way vehicles interact with each other and their surroundings. Through VANETs it is possible to share data in real time, avoid collisions, optimize traffic flow, achieve quick emergency response, cooperative vehicle maneuvers, etc., contributing to more efficient traffic management in smart cities.

VANETs are networks of connected vehicles (CVs) and the devices with which they communicate as shown in Figure 1 [5]. Because CVs may freely leave and join VANETs, a VANET’s inter-nodal connections are typically ephemeral and dynamic and their topologies are in constant flux. These changes in topology create additional problems for VANET routing algorithms, due in part to the need to route high-priority communications such as emergency event messages to all of a VANET’s vehicles.

A VANET can contain many nodes. The VANET’s connected vehicles (CVs), the most dynamic of these nodes, use on-board units (OBUs) to process information and connect to networks. While CVs are highly mobile, their paths through a VANET are constrained by the host network’s roadways. As roads often travel in one direction, a network can often predict a vehicle’s location from its current roadway and rate of speed. To improve their manageability, VANETs commonly include roadside units (RSUs): static nodes that serve as anchor points for VANET-to-CV communications. RSUs are assumed to be more powerful than the OBUs, RSUs can provide services that OBUs cannot provide, such as traffic monitoring. RSUs send the data to the traffic management centers (TMCs) to monitor traffic.

VANET communications take one of three forms. Vehicle to Vehicle (V2V) communication, the dominant form of VANET communication, is highly ephemeral, as both vehicles could be travelling in opposite directions at high speeds. Vehicle to Infrastructure (V2I) communication occurs between RSUs and OBUs, and RSUs and TMC provides slightly fewer routing difficulties due to the RSU acting as a stationary node. Finally, Vehicle to Everything (V2X) refers to communications between OBUs and any non-RSU/OBU device, such as pedestrians and bicyclists with connectable devices. Although many non-vehicle nodes may be mobile, their speeds do not match the connected vehicle speeds. This provides a more difficult routing problem than the V2I communication but is less difficult than V2V when vehicles are traveling in opposing lanes [6]. Traditional routing algorithms struggle to adapt to these dynamically changing configurations. The movement of the vehicles cause connectivity issues that can impact the routing decisions. Furthermore, the emergency messages are crucial for rapid emergency responses. These emergency messages have to be prioritized over other vehicular messages and communicated with high reliability and security. An adversary can capture and manipulate the information, resulting in false decisions by the TMC and the RSUs. In addition, the identity of the CVs can be known, compromising the security of the passengers. Many solutions have been proposed in recent years for enhancing the security of VANETs. Certificate-based authentication techniques that use public keys have been reported, but they are inefficient due to the large database of public keys. Group signature-based techniques are also based on keys, but the keys need to be frequently updated. Identity-based authentication schemes are too centralized to maintain secrecy of private keys; on the other hand, pseudonym-based schemes suffer from huge overhead. Certificateless schemes are more efficient but lack security. Furthermore, the OBU is resource constrained and cannot perform huge computations efficiently and quickly.

Blockchains, with their decentralized architecture, are a viable option for VANET applications. The tamper resistant nature of blockchain ensures that once the data is recorded on the blockchain it cannot be altered, making it ideal for VANETs. However, public blockchains require considerable energy and processing time, putting additional storage requirements on the network nodes. Thus, it is unsuitable for VANET applications, where the entities have limited computational power, with stringent real-time requirements. Lightweight blockchains are intended for nodes with limited resources, without compromising the security [7]. Lightweight blockchains provide mechanisms to reduce a traditional blockchain’s overhead. This can take the form of making less energy-dependent consensus mechanisms or reducing network and storage overhead when transferring the chain between nodes. Lightweight blockchains can be adapted to networks where resources (computational, network, storage, etc.) are restrained due to the network’s nature. These chains can bring blockchain abilities to networks traditionally not capable of traditional blockchain implementations. However, many chain adaptations are application-specific and may not easily transfer to other applications. These adaptations require additional research to generalize their operation. Lightweight chains require further research to prove their abilities match traditional chain networks where applicable. They can be of tremendous utility for VANETs, where the entities are constantly moving, have stringent real-time requirements, and with a need for strong security and authentication features. The number of published articles on blockchain is obtained from the Scopus database, illustrated in Figure 2.

The publication records in Figure 2 clearly indicate that blockchain technology is widely adopted for various applications, but not very popular for VANETs. Moreover, research on lightweight blockchains is still in nascent stages and its adoption for VANETs is miniscule. Thus, there is a need to study lightweight blockchains for VANETs, identify the challenges and propose probable solutions, which will be the subject matter of this work. A brief comparison of various survey papers on blockchains for VANETs is given in

Table 1. Existing reviews on blockchain for VANETs.

Reference	Discussion of Security with VANET Blockchains	Discussion of Computation Reduction within VANET Blockchains	Discussion of Network Requirement Reduction within VANET Blockchains	Discussion of Storage Requirement Reduction within VANET Blockchains	Discussion of Lightweight Blockchains within VANETs and Their Effects
[8]	✕	✕	✓	✓	✕
[9]	✕	✓	✕	✕	✕
[10]	✓	✓	✓	✓	✕
[11]	✓	✕	✕	✓	✕
[12]	✓	✕	✕	✕	✕
[13]	✓	✓	✓	✓	✕
[14]	✓	✕	✕	✓	✕
[15]	✓	✓	✓	✓	✕
[16]	✓	✓	✕	✕	✕
[17]	✓	✓	✓	✓	✕
This survey	✓	✓	✓	✓	✓

that compare the studies based on their discussion of security, network usage, storage and computational requirements. Table 1 demonstrates various techniques intended to create a lightweight blockchain. Various aspects of using blockchains within resource-constrained networks are discussed in these studies. Chain operation within resource-restrained environments creates problems due to the overhead required in traditional chains. This overhead comes from the consensus method requirements alongside storage, security, and network requirements. The previously mentioned works did not provide a view of creating a lightweight chain to tackle computational and network/storage issues. This study explores these works to formulate criteria to create lightweight blockchains within VANETs and to provide the foundation for generalizations within future work. This table further justifies the novelty and demonstrates the contributions of this work.

The existing surveys mostly focus on blockchains for VANETs, but none of them discuss the importance and use of lightweight blockchains for VANETs, which is the important contribution of this survey.

The remaining sections of the paper are organized as follows: an overview of blockchain technology is given in the second section. Additionally, a description of different consensus mechanisms is given, followed by the discussion on lightweight blockchain for VANETs in Section 3. Section 4 presents the challenges and possible solutions in the parlance of this topic. The last section presents the conclusion of the review on the prospect of a lightweight blockchain.

2. Overview of Blockchain

Blockchain is a decentralized ledger for recording transactions in a secure and transparent manner. It does not need any central authority for record-keeping and is maintained by a network of participants called “nodes”. Each node in the blockchain network has a copy of the entire ledger or the blockchain that has the record of all the transactions. Thus, it prevents a single entity from controlling the information, thereby, providing transparency and security. The transactions and chain-related information are stored in the blockchain in a series of blocks [18]. Every block in the chain has a reference (hash value) to the previous block forming a chain. Figure 3 illustrates a generic blockchain. The chains that bind these blocks are created by a cryptographic hash function that converts any input (data) into a fixed-size string of characters called the digest. This hash function has several important properties: it is deterministic (the same input always produces the same output), irreversible (you cannot derive the original input from the hash), and any minor change in the input produces a significantly different hash. This makes it incredibly difficult to alter data in a blockchain without detection. Blockchains commonly use the SHA-256 hashing algorithm, which outputs 32-byte digests. Users interpret the digests as 64-character hexadecimal strings that can be interpreted as integers.

With one exception, each of a chain’s blocks contains the previous block’s hash in its metadata. In place of a hash, a chain’s first (genesis) block contains some preconfigured data. Because of this linkage, a block’s hash affects the hash of all blocks that follow it. If any block’s data changes, its hash will also change, invalidating the hashes of all blocks that follow it with a probability of close to 1, creating a need to rehash all blocks that trail it to restore the chain’s integrity.

2.1. Transactions in a Blockchain

Transactions’ contents vary depending on the blockchain’s application. In general, each transaction requires an input and an output. These parameters are often some forms of currency but can also be data. When a node in the blockchain network initiates a transaction, it is broadcasted over the network. The transaction can be financial, energy-related or consist of any other data. The other nodes in the network validate the transaction using pre-defined rules, such as verification of digital signatures, etc. To verify the identity of a transaction’s creator, a transaction should be signed using asymmetric key encryption. Using two keys, a private and a public key, a node can sign-encrypt a document with their private key and distribute their public key. Then, any other node with that public key can authenticate that transaction’s user by decrypting the signature.

Blockchains operate on networks of nodes—users’ devices—that maintain and expand the blockchain. Two types of nodes have special status. One, a full node, stores the entire chain, ensuring its validity. The other, a publisher node, collects a network’s transactions, creates blocks that document these transactions, and then attempts to publish the blocks, i.e., add them to the chain. A publisher node publishes a block by sending it to its peer nodes. Those peer nodes verify the block, then add it, if valid, to their blockchain and relay them to their peers. Eventually, a valid block will propagate to all a network’s nodes. A newly added block’s transactions are not immediately accepted as confirmed. For a network to confirm a block’s transactions, a certain number of additional blocks must first be added to the chain. This policy is meant to minimize disruptions due to possible overwrites in the blocks that immediately precede a newly added block.

As a rule, chains have multiple publisher nodes, which compete to publish blocks. A consensus model determines a blockchain’s behavior, including which nodes may publish blocks, how conflicts related to block publication are resolved, and how often the network adds new blocks to the chain. Consensus mechanisms ensure that all nodes in the network agree on the state of the blockchain. Different mechanisms, such as proof-of-work (PoW), proof-of-stake (PoS), and delegated proof-of-stake (DPoS), use various approaches to achieve this agreement while considering factors such as security, energy efficiency, and decentralization. Whenever a block is added to the chain, its hash is linked to the previous block’s hash. The result is a chain of blocks, each pointing to its predecessor. Because of the cryptographic hashing properties, it is extremely difficult to alter any past transaction without changing subsequent blocks. Therefore, the data on the blockchain is practically unchangeable.

2.2. Consensus Mechanisms for Blockchains

The distributed nature of blockchain operation creates potential issues for a network’s integrity. For a blockchain network to function properly, its nodes must agree on its content. One issue is trust: the ability of one node to confirm that another node acts non-maliciously. Within permissioned chains, the network must authenticate and authorize all nodes, which establishes trust, to participate with the network. Permissionless chains lack this trust-establishing step.

Another issue, bifurcation, is the concurrent addition of two different blocks to a chain by different nodes. Bifurcation creates inconsistent versions of the chain within the network. Nodes can reference either version of the chain when publishing new blocks, which leads to nodes possibly rejecting a valid block if the block does not reference the blockchain branch that node is using.

Consensus protocols assure network integrity by establishing policies for achieving agreement about the network’s current, valid state. For example, a common solution to the bifurcation problem is for nodes to adopt the longest chain after a certain time. The authentication and authorization step used by permissioned chains avoids problems with trust, while permissionless chains use consensus mechanisms to inspire trust through sacrifices of non-trivial resources, e.g., time, power, or currency. A node is said to be mining when it participates in the consensus mechanism. These mechanisms are often called Proof-of-X, where X characterizes the consensus mechanism’s behavior.

2.2.1. Proof-of-Work

Three-fifths of all blockchains, including the Bitcoin blockchain, use the PoW consensus mechanism [19]. PoW requires publisher nodes to compete to solve a computationally intense but easily verifiable mathematical puzzle [20]. For example, for Bitcoin, this puzzle’s challenge is finding a digest with more leading zeros than the current network difficulty target. In other words, if a publisher node interprets its block’s digest as an integer and this integer is smaller than the difficulty target determined by the network, the node can publish that block. Nodes solve puzzles by repeatedly changing a special metadata field, known as a nonce, and recomputing their own digests until they find a value that solves the puzzle. The unpredictable nature of the SHA-256 algorithm constitutes the challenge: as the target decreases in value, nodes will require more “work” to find a suitable digest.

While every publishing node can technically publish blocks, most are published by nodes with the most processing power. In theory, the resources expended in this work should deter malicious activity. While the publication puzzle is computationally feasible, malicious users should find the puzzle financially infeasible to solve, assuming most of the network contains non-malicious nodes.

The difficulty target fluctuates due to network participation. Bitcoin’s blockchain adjusts its difficulty target every 2016 blocks to ensure it adds one block to the blockchain every ten minutes. The network lowers the target value—thereby raising the difficulty—for networks with many nodes and raises it—lowering the difficulty—for networks with few nodes. Adjustments occur as nodes join and leave the network for various reasons, e.g., maintenance, power outage, and disinterest in network participation.

The “work” performed in PoW has drawbacks. Due to the amount of energy needed to solve these puzzles, PoW blockchains consume considerable power. According to Schinkus et al. [21], a single transaction can power 20 U.S. homes daily, and Bitcoin’s entire network uses a similar amount of electricity annually as Austria. Ethereum, another blockchain that used a less resource-intensive PoW algorithm prior to summer 2022, required the annual energy consumption of Kenya. Users will place publisher nodes near cheap electricity due to the potential cost reduction and profit increase. As these blockchains grow, their environmental impact will continue to increase.

2.2.2. Proof-of-Stake

The Proof-of-Stake (PoS) consensus model uses a probabilistic algorithm to select what node, at any given time, may act as the next publishing node. The PoS model relies on the idea that staked users are trustworthy and will be invested in the blockchain’s well-being [22]. PoS assumes that a network’s nodes can use cryptocurrency to buy a non-returnable heightened probability of publishing blocks. The incentive to publish a block becomes the fees charged during transactions instead of block creation-based rewards. PoS, in effect, enables users to increase their chances of publishing blocks by buying probabilities instead of better computer hardware, as in PoW. PoS systems may include voting systems. In one version, the network randomly chooses staked nodes to create blocks, then allows them to vote on which block to publish next. The network determines votes’ weights through how much the node has staked, similarly to stockholders within a publicly owned company that cannot sell their shares. Yaga et al. [1] refers to these systems as Byzantine fault tolerance PoS’s.

Another PoS voting system uses delegates to create blocks. This system allows staked nodes to vote on which nodes should publish. Voting occurs continuously, spawning competition between potential publishing nodes. Trust in the scenario comes from the punishment of publishing nodes. If a node behaves maliciously, the network can vote out the misbehaving node from its publishing position.

2.3. Smart Contracts

In addition to descriptions of interactions involving two nodes, blocks can contain smart contracts, which are collections of code and data that a network’s nodes can execute [23]. Not every blockchain can implement smart contracts. For those that can, publishing nodes attach smart contracts to blocks, similar to regular transactions. This code’s output must be the same for all nodes (deterministic) and is recorded to the chain.

A smart contract’s operation must depend strictly on the information that that contract receives from its user. Moreover, all nodes within the network must agree on the outcome of a smart contract’s operation. These requirements limit a smart contract to one of two sources of information: that contract’s host network or stable sources of outside information. If a smart contract uses information outside of the network, it is called an oracle. The oracle must assure that their information is easily obtainable so that nodes can validate outputs. Publishing a smart contract on a blockchain renders it largely immutable and tamper-resistant. These properties allow nodes to trust the contract’s actions, treating it as a trusted third party. Smart contracts can provide services to a blockchain’s nodes, e.g., storing data, exposing information publicly, performing calculations, and redistributing resources among a chain’s users. Contracts act as functions and an output ledger of that function. Smart contracts have built-in protection mechanisms to defend against certain attacks. One, a timeout function, guards against denial-of-service attacks by stopping a smart contract’s operation after a certain period of time. A second function, a fee to execute, may be required of smart contracts in permissionless blockchains. This dissuades attackers by requiring resources to stage their attack. An attack must participate within a network through honest behavior to gain these resources. This takes time that an attacker may not have. In permissioned blockchains, the risk of a malicious node is lower, due to the nodes requiring permission to operate within the network. These blockchains may forgo execution fees entirely. However, the vulnerabilities in smart contracts are still being exploited to attack the blockchain network. Formal methods such model checking, theorem proving, symbolic verification and run-time verification can be used to minimize the vulnerabilities of smart contracts [24,25].

3. Lightweight Blockchain in VANETs

The architecture of a blockchain for VANETs depends on the application and on the resource constraints. Two prominent architectures are available in the literature: the use of blockchain at the RSUs, and the use of blockchain at the OBUs [26,27]. Both the architectures are depicted in Figure 4.

A blockchain can run on a cluster of OBUs or RSUs, as shown in Figure 4. OBUs are more resource-constrained, and the blockchain running on OBUs must be efficiently designed compared to the blockchain implemented on RSUs. Furthermore, the mobile nature of the OBU compared to the static nature of the RSU makes blockchain implementation challenging for this architecture. There are many methods to deploy a lightweight blockchain, which are illustrated in Figure 5:

• Efficient Trust Evaluation: lightweight trust evaluation schemes can reduce the computational overhead of the blockchain by identifying the malicious nodes that generate false data to overburden the target node [28]. By involving only those trusted nodes, the blockchain can be made lighter. However, the mobile nature of the nodes makes it difficult to implement these lightweight trust evaluation schemes.
• Lightweight Consensus Mechanism: a lightweight blockchain can be achieved by simplifying the consensus mechanism, reducing computational costs. PoS, delegated PoS (DPoS), Direct Acyclic Graph (DAG), etc., are some of the lightweight consensus mechanisms. However, the maintenance of network synchronization, and preventing attacks can still be challenging using these lightweight mechanisms.
• Pruning: pruning is the process of deleting data from the blockchain that is no longer required to validate new transactions. This technique can help reduce the size of the blockchain, making it more lightweight. In VANETs, pruning can be used to remove transaction data no longer relevant to the current traffic scenario. However, in VANETs, historical data can be important in predicting patterns and pruning may remove this data that can be important in future.
• Limiting the Number of Nodes: in VANETs, it is possible to include only those nodes (OBUs) within a given geographical area, as there is a greater probability of interaction between them than in another geographical area. This can make the blockchain light. The mobile nature of the traffic makes it difficult to implement this strategy.
• Sharding: sharding involves breaking up the blockchain into smaller, more manageable pieces called shards. This can help reduce the computational requirements for each node and increase the scalability of the blockchain. The dynamic nature of movement and communication constraints makes its implementation difficult.
• State Channels: state channels are off-chain channels between a group of nodes (OBUs), allowing them to conduct many transactions without recording them on the main blockchain, reducing the load and making it lightweight. State channels may not be suitable for communicating emergency transactions.
• Data Compression: compressing the data stored on the blockchain can help reduce the size of the blockchain. This can be achieved using compression algorithms that reduce the data size without affecting its integrity. This technique can be used in conjunction with other methods mentioned above. However, the real-time requirements of VANETs and the limited processing power of the OBUs puts constraints on the data compression techniques.

However, the literature on lightweight blockchain for VANETs has not fully explored all these various methods. Lightweight consensus mechanisms have been adopted to simplify the blockchain.

3.1. Efficient Trust Evaluation

Autonomous Vehicles (AVs) have complex operating requirements due to their need for safe and secure operation. Researchers have used machine learning techniques to address some of these requirements [29], e.g., to train in-vehicle applications to identify pedestrians and detect attacks against AV software. These applications’ operations can be improved by training them with more data [30]. Provided this data is representative of real conditions, its point of origin is immaterial.

Sharing data on environmental conditions can meet this need for improving AV operations. Sharing, however, poses risks to user privacy and safety. Training data may contain identifiable information, including location images, trajectory information, and credit card information. If vehicles were to share their datasets, a malicious user could identify and track a user’s whereabouts or disseminate faulty data to decrease the accuracy of certain critical tasks.

In [31], the authors present a novel, private blockchain-based method to share machine learning models and datasets safely and securely. The architecture features a low-overhead, scalable consensus mechanism, which, in experiments with 16 GB of RAM and an Intel i7 8th generation processor, showed an increase in transaction verification time from 400 ms to 500 ms when the number of transactions increased from 200 to 2000.

The architecture creates a blockchain that can function effectively in a resource-constrained vehicle edge network. The chain uses a new consensus method to defend against attacks involving false models (Byzantine attacks). This method, named Proof of Vehicular Services-Byzantine Fault Tolerance (PoVS-BFT), uses a small, ratings-based, tenure-specific consensus committee to reduce the complexity of traditional consensus algorithms. Semi-trusted RSUs act as publishing nodes in this chain. Here, trustworthiness denotes how well an RSU meets its operating requirements. The network determines an RSU’s trust rating by measuring how often vehicles interact with that node and how efficiently an RSU satisfies application-specific Quality of Service (QoS) requirements. An RSU that services many vehicles over time and fulfils network delivery requirements efficiently benefits the network and is treated as trustworthy.

A road network’s vehicles act as nodes that make transactions and forward them to an RSU. The vehicles collectively help determine an RSU’s rating by sending an evaluation of a recently used RSU to a certificate authority (CA). CAs grant pseudonyms to users to provide privacy while remaining identifiable within the network, which is a reason to trust the CA’s ratings. The CA gathers these ratings and distributes them across the network.

In order to publish a block, an RSU must be on the publishing committee. PoVS-BFT’s committee selection process chooses RSUs through two phases. The first elimination phase uses K-means clustering to separate potential publishing candidates into two groups. The network calculates each group’s average service rating and identifies the highest-rated group as the next potential group. The validation phase removes candidates from the potential group through Euclidean distances and outlier detection. These phases decrease the committee’s size while limiting membership to the most trusted and efficient RSUs. After this point, the network follows traditional BFT procedures, selecting the consensus leader round-robin style.

Another data-sharing scheme based on the Practical Byzantine False Tolerance (PBFT) consensus mechanism is proposed in [32]. This consensus mechanism is not lightweight, but is more robust to falsifying information. However, in the event of malicious attacks, the PBFT rejects some of the information based on the reputation of the nodes, thereby reducing the computational overhead. Similarly, in [33], the neuro-fuzzy machine learning method has been used to detect and filter out false requests, thereby decreasing the overall size of the blockchain. A lightweight trust evaluation scheme has been proposed in [34] to identify the malicious nodes, and it is observed that the scheme’s performance matches that without any attackers.

The authors of [35] present a discussion on reputation and trust management systems within many fields, VANETs included, backed by blockchains. One of the propositions discussed was using a lightweight, scalable blockchain with lightweight consensus mechanism and throughput mechanism specifically for cyberphysical systems, such as a VANET. These mechanisms tend to be specific to the applications as these can vary in requirements.

3.2. Lightweight Consensus Mechanisms

PoW is a popular blockchain consensus mechanism that can also be extended for lightweight consensus mechanisms in VANETs. Even though it is highly secure, it consumes a lot of energy and replacing PoW would be optimal for reducing a chain’s network load. With PoS, even though it is more energy efficient than PoW and is suitable for lightweight consensus in VANETs, achieving fair participation of the nodes involved is challenging. DPoS and proof-of-authority (PoA) are other blockchain consensus mechanisms that can also be used for lightweight consensus, as they involve only selected nodes for participating in transaction validation. They are energy efficient and fast, but the dynamic nature of VANETs makes its implementation challenging. In the literature, researchers have reported other lightweight consensus mechanisms for VANETs. In [36], the authors made the nodes calculate matrix operations for a machine-learning algorithm. Although this is not necessarily lightweight, it matches the ideas of lightweight as the work is not reduced but made useful. If this work can help train a model used for traffic management, this can further increase the efficiency of the roadway and the network. However, this is not the case in most applications, and an alternative consensus mechanism can be used [37].

Consensus performance can be ascertained through consensus delay and block processing time. Consortium blockchains and round robin consensus methods have been used to reduce these aspects [38]. These consortium blockchains combine multiple chains from different organizations into one environment. Separating the blockchains between OBUs and RSUs allows the more powerful RSUs to handle the bulk of computation while using OBUs for less computationally difficult problems. In [38], the authors could reduce the computation cost and consensus delay more than the methods. Moreover, a modification to PBFT can be seen in the works of Vishwakarma et al. using four states when finding consensus and a new leader election scheme reduced resource usage. The experimental results show an 85% computation cost reduction, 55% storge and communication overhead, and a 90% shorter consensus delay [39].

Message dissemination within VANETs requires secure operation within environments of untrusted nodes. These nodes possess limited computing capabilities and require a non-PoW consensus method [40]. Ayaz et al. in [40] proposed a novel blockchain consensus method, Proofof-Quality-Factor (PoQF), designed for Vehicular Edge Computing (VEC)-backed VANET environments. The authors treat vehicles as VANET’s mobile edge nodes and RSUs as its edge computing servers.

PoQF uses Quality Factors (QFs) to identify whether a node may publish a block in a network’s operation at a given instant. When a node receives a message (transaction proposal), it calculates its own QF. This value is the product of its signal-to-noise ratio and the probability that its distance from the transaction’s sender is above a certain threshold. This threshold must be chosen to ensure message delivery within the current network environment. QF ensures that a publishing node is close enough to an incident to ensure that this node can support its claims through onboard vehicle sensors.

After a node calculates its QF, it determines a message’s validity and QF to a voting message to send across the network. This node then waits for a period that depends on its QF before announcing its vote to its neighbors. This random wait period reduces the likelihood of packet collision and helps to ensure fairness by assigning shorter random wait periods to trustworthy nodes. Each node tallies the votes it receives from other nodes and uses this tally in the next step.

A node can publish a block when it meets two criteria. The node must have received an arbitrary number of votes matching its vote. Many nodes may meet this criterion. The second criterion resolves publication conflicts through QFs. A node can publish its block if it has the highest QF compared to the QFs found in the voting messages. If the node votes true and the votes it received match that vote, it relays the message through the network and publishes a block about the event. Similarly, if voted false by the node and the network, the node disregards the message and still publishes a block about the event. These two criteria ensure stronger security within PoQF. Using nearby nodes to validate transactions eliminates the need to validate transactions at every node, reducing overall power usage. Moreover, nodes farther away from the incident may be unable to validate transactions due to vehicle sensors not being within range of the incident.

Ayaz et al. tested OMNet++ by integrating it into the Simulation of Urban Mobility (SUMO) simulation of a VANET; PoQS’s validation time increases as the number of mining nodes increases. The number of malicious nodes within the network can affect this latency. As the malicious node percentage reaches 20% of the network and the network increases in size from 10 mining nodes to 40, validation times increase from 100 ms to about 450 ms. When that percentage reaches 60% of the network in that same situation, validation times increase from about 250 ms to 1000 ms. These messages, being emergency messages, must have a latency of at most 1 s. Otherwise, the network assumes the message is false and allows the node with the highest QF that voted false to publish a block about the event.

As more vehicles connect through VANETs, users can more efficiently use vehicular resources through sharing data. Ride sharing, the process of a driver providing transportation to a client at cost, allows access to transportation to people without a vehicle of their own. Many ride-sharing implementations use centralized servers to connect drivers to clients and process transactions. To engage in a transaction, clients and drivers must share secure data, including identifying information and credit card numbers. Peak usage times and server outages may delay these processes and reduce efficiency.

In [41], the authors modified the Proof-of-Reputation (MPoR) consensus method. Their proposed modification was to make the number of mining nodes variable to balance efficiency and accuracy through stochastic filtering and resource optimization. This was compared to Proof-of-Driving consensus and was demonstrated to resist network attacks when malicious nodes comprised less than one-third of total network nodes. This was due to Practical Byzantine Fault Tolerance used as the final consensus step. This reduces the total computation required for consensus.

Kudva et al. introduced a blockchain-based ride-sharing system to reduce fuel costs [42]. Their system uses a new consensus mechanism, Proof-of-Driving (PoD), and a method to reduce consensus committee sizes. PoD was designed to support universal accessibility, be fair to its users, support the computational economy, and resist attacks such as node collusion.

PoD is an extension of PBFT that uses PoW to limit a network’s set of potential publishing nodes. Transactions contain either a passenger’s request or a driver’s response to a passenger. Vehicles serve as the mining nodes and collect these transactions.

Vehicles and clients can make transactions, but only vehicles can mine blocks. Driving coins earned through miles travelled serving clients determine the likelihood that a vehicle will act as a potential mining node. The network computes the average vehicle’s driving coin amount to determine the difficulty of a puzzle that candidate nodes must solve. If a vehicle hashes its driving coin amount and that value is less than the average’s hash value, this node becomes a potential mining node.

To further eliminate potential mining and publishing nodes, the network calculates the nodes’ trustworthiness based on the number of blocks generated in the past. This metric indicates a node’s willingness to participate in consensus and win publishing rights. This metric deters malicious nodes by forcing them to positively contribute to the network for an uneconomical amount of time. After the network determines the trust values, the network chooses the highest-rated nodes to maximize the consensus committee’s trustworthiness. The maximized value varies depending on the network environment.

Work has been completed on designing lightweight chains for IoT that support joining and leaving IoT nodes without large overheads for authentication using PBFT as a consensus mechanism. Using a Raspberry Pi 4B, they were able to demonstrate that encryption and decryption (both symmetric and asymmetric) times were able to reach microsecond levels. Ultimately, their work demonstrated that they were able to keep transaction generation and verification below 10 ms [43]. These may prove useful within VANET environments.

Directed Acyclical Graphs (DAGs) are another distributed ledger that works similarly to blockchains, except that they do not require storing the amount of information that traditional blockchains demand [44]. This allows DAGs to reduce the network and storage requirements of the network’s nodes, as seen in the Internet of Things [45]. DAGs can also increase the transaction throughput by processing transactions in parallel [46]. In [47], the authors created a PBFT-based DAG running within an Internet of Vehicles. This consensus mechanism contained methods to reduce the number of consensus nodes by sharding the network into smaller networks and adding weights to functions to incentivize a high reputation score. These authors improved the transactions per second, consensus success rate, and time of obtaining transactions while reducing dependence on RSUs [48].

In [49], a modified DAG consensus mechanism has been adopted to achieve lightweight operation. The DAG allows reaching consensus faster by allowing the transactions to be placed in the previous transaction, thereby helping the transactions to reach consensus parallelly. This results in a faster consensus. The mechanism was compared with other approaches, such as the standard PoW, PoS, DAG, Proof-of-Driving (PoD), and DPoS. It is found that the proposed DAG approach significantly reduces the block confirmation delay to less than 100 ms, compared to the 300 ms taken by the standard PoW mechanism. Similarly, a DAG scheme has been proposed in [50], combining a historical data-pruning method, and minimizing duplicates and the storage space. The method is scalable and has reported to save the storage space by 97.13%. In [51], a DAG-based blockchain called V-Lattice has been proposed that combines pruning. Instead of storing the full blockchains, the nodes store a partial blockchain based on the storage availability.

The authors in [52] use a multilayer system, one of which involved a blockchain using a dynamic Proof-of-Work (dPoW) consensus algorithm to authenticate nodes. Their solution reduced packet flows drastically compared to their baseline solution and used reduced computational overhead compared to other solutions. Despite being PoW-based, the authors concluded that instead of using the Bitcoin model (PoW), another network such as Tron could reduce resources consumed and increase transactional throughput.

3.3. Limiting Geographical Reach

A consensus mechanism’s power consumption can be limited by limiting the size of a blockchain network. Fewer nodes mean less competition and communication overhead. This limit, specifically in committee sizes, often comes from an arbitrary equation. Using node location to configure blockchains provides another avenue for limiting size arbitrarily. By increasing and decreasing the size of a blockchain’s local operating area, the network can increase or decrease the number of nodes operating on a chain, illustrated in Figure 6.

Shrestha et al. proposed a PoW-PoS hybrid blockchain to store safety event messages and track the participating nodes’ trustworthiness [52]. The authors’ network consists of vehicles, which serve as mining, transacting, and publishing nodes, and RSUs, which provide vehicle authentication services. Transactions involve sharing beacon messages, which inform other nodes of a node’s presence, and safety event messages. Within this system, vehicles obtain location certificates from RSUs. Nodes send transactions with these certificates to provide proof that those nodes were near the safety event message’s location. Using a trust rating and a transaction’s timestamp, other nodes can verify a message’s integrity and appropriately influence that node’s trust rating. A node’s trust rating is a function of the ratio of the number of valid messages it sends to the total number of messages it sends.

Shreshta et al. argued that the use of location-based chains could enable the use of augmented PoW-PoS hybrid consensus mechanisms in VANETs, although the chains could grow in size, ranging from 206.51 GB to 1548.82 GB per year when transactions ranged from 200 to 1500 transactions per second. Limiting the geographical range of a blockchain would limit the network’s power consumption and computational overhead while decreasing the communication overhead required for the chain to function. This approach aims to address the issue of scalability more effectively when compared to a global blockchain framework. Vehicles can accurately determine their positions by employing a location certificate system founded on the Proof of Location (PoL) principles, which can be used to create local blockchain networks. This localized blockchain infrastructure offers enhanced performance by substantially decreasing the data required for global processing and storage.

3.4. Pruning

Blockchain’s resource use can also be reduced through chain size reduction. The amount of blocks on the chain is proportional to the security of the chain. In resource-constrained environments, this unbounded length [53] can lead to storage and network issues, especially when nodes require a full download of the chain (bootstrapping). Pruning removes part of the chain to save resources as information becomes stale over time. Pruning can be used to shrink the size of the chain and reduce storage and network constraints. Pruned, bounded chains provide lower network and storage resources than unbounded chains [54]. The literature has embraced pruning to bound blockchain growth [55].

However, whether or not you can prune a chain depends on the data stored on the chain. Pruning becomes more complicated if the data requires all transactions to recreate the network state. If this information needs to be retained for non-sequential reasons (i.e., regulations), this data can be offloaded from the network’s nodes to edge-computing resources for long-term storage [56]. This offloading must be balanced with reducing security, tamper-proofing, and data provenance, as the attributes suffer when offloading [57].

Pruning and storage issues from the unbounded growth remain under-researched. In S. BelMannoubi et al., of the works surveyed, only 34% of these blockchain applications investigated storage issues, and only 43% addressed communication overhead [58]. Pruning provides a mechanism to manage these issues with a single technique.

4. Challenges and Solutions

Lightweight blockchains have the potential to bring significant benefits to VANETs; several challenges need to be addressed for their successful implementation. Some challenges in implementing lightweight blockchains for VANETs are:

• Scalability: VANETs generate a large volume of data, and a blockchain that cannot handle this data efficiently may result in significant performance issues. As the number of connected vehicles increases, the blockchain’s capacity to process transactions may become slower, impacting the desired transaction throughput. Solutions such as sharding or limiting the geographical area can help distribute the computational load and improve scalability.
• Security: VANETs require secure vehicle communication to prevent cyberattacks and ensure safe driving. The blockchain technology used in VANETs must be secure, tamper-proof, and able to handle malicious attacks such as sybil and double-spending attacks.
• Decentralization: the decentralization of the blockchain is crucial for ensuring that VANETs can operate autonomously without the need for a centralized authority. However, achieving true decentralization requires many nodes, which can be challenging to achieve in VANETs due to the high mobility of the vehicles.
• Interoperability: interoperability enables different vehicles and infrastructures to communicate effectively. The blockchain technology used in VANETs must be interoperable with other communication protocols and technologies.
• Privacy: VANETs generate many data, and ensuring the privacy of this data is crucial for maintaining user trust. The blockchain technology used in VANETs must provide a way to encrypt and anonymize data to ensure privacy and protect user data.
• Energy Efficiency: VANETs are typically powered by energy-limited resources with limited capacity. Future research can focus on developing new energy-efficient blockchain architectures and consensus algorithms to reduce the energy consumption of blockchain-based VANETs.
• Real-time Applications: VANETs are used in many real-time applications such as collision avoidance and traffic management. Future research can focus on developing new lightweight blockchain architectures and consensus algorithms that can provide real-time guarantees for these applications.
• Integration with AI and Machine Learning: VANETs can generate large amounts of data, which can be analyzed using AI and machine learning algorithms to provide insights into traffic patterns and driving behavior. Future research can focus on developing new blockchain-based architectures and consensus algorithms that can support AI and machine learning applications in VANETs. AI applications are already being developed for VANET with blockchains [59] and even using AI to determine which nodes can participate in the consensus method [60].

Overall, implementing lightweight blockchains for VANETs requires addressing the above challenges effectively. Addressing these challenges requires a deep understanding of VANETs and the blockchain technology used. Developing standards and protocols that enable interoperability, scalability, and security is crucial for successful implementation.

Solutions that can potentially improve the performance and efficiency of lightweight blockchains for VANETs are:

• Hybrid Consensus Mechanisms: hybrid consensus mechanisms can be used to combine the strengths of different consensus mechanisms and mitigate their weaknesses. A hybrid consensus mechanism can combine the efficiency of a lightweight consensus mechanism such as PoS or DPoS with the security of a more robust consensus mechanism such as PBFT.
• Network Partitioning: network partitioning can be used to improve the scalability of lightweight blockchains for VANETs. By partitioning the network into smaller sub-networks, the overhead of the consensus mechanism can be reduced, and the scalability can be improved. Network partitioning can also increase the robustness of the network by isolating faulty or malicious nodes.
• Size Reduction Techniques: size reduction techniques can be used to reduce the size of the blockchain and the amount of data that needs to be transmitted between nodes. This can be achieved by compressing transaction data or using techniques such as Merkle trees to reduce the size of the blockchain.
• Off-Chain Transactions: off-chain transactions can reduce the computational overhead of the blockchain by processing transactions off-chain and only submitting the outcome to the blockchain. This can be achieved using techniques such as state channels or payment channels.
• Light Client Protocols: light client protocols can be used to reduce the computational and storage requirements of nodes in the network. Using a lightweight protocol, nodes can participate in the network without downloading and storing the entire blockchain.
• IoT Blockchains: another possible solution is to employ the lightweight blockchains developed for Internet of Things (IoT) applications for VANETs, such as IOTA, BlockCloud, Atonomi, etc. [61,62].

These solutions can potentially improve the performance and efficiency of lightweight blockchains for VANETs, but further research is needed to evaluate their effectiveness and suitability for VANETs.

5. Conclusions

Artificial intelligence (AI) and high-speed communication networks will increase the number of connected vehicles. VANETs must be reliable and secure, where blockchain will play an important role in the next few years. The real-time and dynamic nature of traffic involved in VANETs makes the adoption of blockchain for VANETs feasible. This survey focuses on the use of lightweight blockchains for VANETs. Even in nascent stages, the research can impact the adoption of lightweight blockchain for practical applications in VANETs. Researchers have focused on developing lightweight consensus mechanisms and detecting and minimizing false requests before involving them in a transaction, thereby reducing the complexity. Future research can focus on developing efficient pruning methods.