# A Comprehensive Review on Blockchains for Internet of Vehicles: Challenges
and Directions

Brian Hildebrand  Mohamed Baza  Tara Salman  Fathi Amsaad  Abdul Razaqu and
Abdullah Alourani  Brian Hildebrand is with GameAbove College of Engineering
and Technology, Eastern Michigan UniversityMohamed Baza is with the department
of computer science at College of Charleston, Charleston, SC 29424Tara Salman
is with Department of Computer Science, Texas Tech UniversityFathi Amsaad is
with School of Information Security and Applied Computing (SISAC), Eastern
Michigan University (EMU), MI 48197 USA

###### Abstract

Internet of Vehicles (IoVs) consist of smart vehicles, Autonomous Vehicles
(AVs) as well as roadside units (RSUs) that communicate wirelessly to provide
enhanced transportation services such as improved traffic efficiency and
reduced traffic congestion and accidents. IoVs, however, suffer from issues of
security, privacy and trust. Blockchain technology has been emerged as a
decentralized approach for enhanced security without depending on trusted
third parties to run services. Blockchain offers the benefits of
trustworthiness, immutability, and mitigates the problem of single point of
failure and other attacks. In this work, we present the state-of-the-art of
Blockchain-enabled IoVs (BIoV) with a particular focus on their applications
such as crowdsourcing-based applications, energy trading, traffic congestion
reduction, collision and accident avoidance and infotainment and content
cashing. We also present in-depth applications federated learning (FL)
applications for BIoVs. The key challenges resulted from the integration of
Blockchain with IoV is investigated in several domains such as edge computing,
ML, and FL. Lastly, a number of open issues and challenges as well as future
opportunities in the area of AI-enabled BIoV, hardware-assisted security for
BIoV and quantum computing attacks on BIoV.

###### Index Terms:

Blockchain, Federated Learning, Vehicular Network, Internet of Vehicles (IoV),
Autonomous Vehicles, Security, Privacy, Smart Contracts

##  1 Introduction

Over, the last two decades, Internet of Vehicles (IoV) have been emerging as
enabling cornerstone to the Intelligent Transportation Systems (ITSs) [1].
Internet of Vehicles (IoV) comprise of smart vehicles and roadside units
(RSUs) that communicate wirelessly to provide enhanced transportation services
and capabilities such as traffic congestion reduction, accident avoidance and
infotainment [2]. This service are provided because vehicles contribute with
data to an traffic management center and with each other to build a spatio-
temporal view of the traffic state [3, 4].

Vehicles in IoV exchanges essential security messages to allow many novel
applications such as crash avoidance, changing traffic routes, dynamic route
selection, crisis cautioning, traffic data, entertainment and content cashing,
etc [5, 6, 7]. RSUs are set adjacent to the streets. They can provide street
safety, routing, and administration to the other vehicles. However,
traditional IoV follows the traditional centralized model. In this model,
vehicles as well RSUs need to communicate directly with a central server to
run the services mentioned earlier. This model is susceptible to single point
of failure attacks. Also, raw data could be intercepted and modified by
adversary during transmission. Moreover, the central server can be compromised
by many cyberattacks including DOS attacks [8, 9].

Blockchain is a decentralized technology that has recently emerged to enable
secure and trusted operations in cryptocurrency (Bitcoin) and financial
applications. Blockchain has several beneficial properties such as
immutability, transparency, and high efficiency which could be harnessed to
enhance the security and preserve the privacy, integrity, and confidentiality
of IoV applications [10, 11]. Due to its flexible and decentralized data
structure, blockchain is not prone to a SPOF and is protected against
centralized attacks. Other features of blockchain include immutability,
transparency, and high efficiency. Immutability allows the blockchain
participating parties to establish mutual trust between communicating nodes in
a decentralized blockchain network. Further, blockchain frameworks have
evolved beyond cryptocurrencies to support smart contracts. Smart contracts
are self-executing and self-enforcing programs that run on the blockchain
without being administered by a trusted authority. Smart contracts provide a
good avenue for implementing needed self-executing actions like managing
blockchain updates for data exchange between vehicles and across the network
[12].

The greater efficiency afforded by blockchain will also benefit IoVs since
real-world transportation scenarios require decisions or actions to be made in
real time. Failure in this could result in vehicular accidents or deaths.
Therefore, this survey aims to present the state of the art of IoVs that
employ blockchain for various applications. We also discuss AI and machine
learning applications for BIoVs. The Main contributions of this survey are
summarized as follows.

  * •

We provide a comprehensive survey of the techniques for the integration of
Blockchain and IoV to build a future intelligent transportation system,
starting with a background that includes the Blockchain technology, and IoV.

  * •

We present the state-of-the-art research efforts and in depth discussion on
the adoption of Blockchain for IoV scenarios, with the focus on applications
such as energy trading, ride sharing, smart parking, vehicle platooning,
accident avoidance and traffic congestion avoidance.

  * •

Blockchain-enabled IoV architectures are presented, including the integration
of Blockchain, edge computing, automotive vehicles, and privacy preserving
approaches.

  * •

The key challenges resulted from the integration of Blockchain with IoV is
investigated in several domains such as edge computing, and FL.

  * •

Finally, the paper highlights a number of open issues and challenges as well
as future opportunities in the area of Blockchain, AI, Hardware security and
Quantum Computing.

TABLE I: Comparison of Blockchain-Based IoVs/IoV Surveys | Covered Topics |  Future Opportunities & Directions |  Covered Period of Reviewed Articles
---|---|---|---
|  Blockchain-Based IoVs/IoV Applications | Machine Learning |  |
|  Energy Trading |  Ride Sharing |  Smart Parking |  Vehicle Platooning |  Infotainment |  Congestion Reduction |  Collision Avoidance |  AV |  Content Caching |  FL |  |
[13] | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ |  (1) Sharing road safety information (2) Content caching (3) Secure offload of block validation (4) Implementing PKI & differential privacy in Blockchain IoVs | 2017-2020
[14] | ✗ | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ |  (1) Integrate Blockchain with FL (2) Energy-saving consensus | 2015-2020
[15] | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |  (1) Increased throughput & latency introduced by Blockchain (2) Trust between vehicles (3) Cyber attacks (4) Scalability (5) Authentication (6) Connectivity | 2018-2021
[16] | ✓ | ✓ |  | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |  (1) Consensus amongst vehicles (2) Detecting malicious vehicles (3) Privacy of participating vehicles (4) Trust between vehicles | 2016-2021
[17] | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ |  (1) Increased energy consumption, resource use & response time introduced by Blockchain (2) Lightweight Blockchain | 2016-2020
[18] | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ |  (1) Scalability (2) Privacy (3) IoV prototyping & simulation (4) Attacks on blockchain | 2016-2021
Our Survey | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |  (1) Untraceable & unexplainable AI decisions (2) AI data & model privacy (3) Hardware security related attacks (4) Quantum computing attacks | 2008-2022

Related Surveys. There exist several surveys that focus on Blockchain-based
IoVs. Table 2 summarizes these surveys and the main differences between them.
The work by [13] covers articles over a three year period beginning in 2017
and covers most of the Blockchain-based IoV applications such as energy
trading, ride sharing, smart parking and vehicle platooning. The survey by
Dibaei et al. [14] focuses primarily on securing communication technologies in
IoVs, including using ML and Blockchain defense mechanisms. Zuhair et al. [15]
provides an overview of architectures, characteristics and applications in IoV
and provides a taxonomy for IoV attacks and possible countermeasures. The
authors suggest that Blockchain can be used to enhance the security and
privacy of IoV. However, they do not go too much into detail about Blockchain-
based applications in IoV, providing reviews of a few articles on smart
parking and vehicle platooning. Karger et al. [16] provides a systematic
literature review of Blockchain’s role in mobility and transportation in smart
cities. The survey by Khoshavi et al. [17] focuses primarily on operation and
security improvement aspects that Blockchain could provide for connected and
autonomous vehicle (CAV) transportation systems. The authors discuss in detail
Blockchain IoVs applications for energy trading, ride sharing, smart parking,
vehicle platooning and collision avoidance. They also cover some aspects of
AVs and ML. There also exist surveys on blockchain applications in smart
cities [19], the energy sector [20] and privacy management in social IoVs
[21]. Lastly, Baldini et al. [22] provides a survey of the use of distributed
ledgers in transportation.

In summary, many of the preexisting surveys cover some of the Blockchain-based
applications in IoV. Our survey provides detailed review to recent
achievements on using Blockchain to secure IoV as well as focusing on
incorporating ML and FL for Blockchain-based IoV. A related survey to us [14]
that discusses ML and FL applications for Blockchain-based IoVs but does not
go depth as our work and also our work provides recent published works till
2022 . To fill in the gaps in the research, our survey presents more details
on Blockchain-based applications in IoV and discusses detailed Blockchain
implementations of artificial intelligence (AI) or federated learning (FL)
applications in IoV.

Organization of Paper. The rest of this paper is organized as follows. Section
2 provides an overview of Blockchain implementations for IoV, including an
overview of relevant Blockchain consensus algorithms. Section 3 presents an
overview of Blockchain-based applications in IoV such as energy trading, ride
sharing, vehicular cloud computing, and vehicular edge computing. Section 4
provides an overview of federated learning (FL) followed by Blockchain
enhanced implementations of FL. Section 5 outlines challenges and future
directions for Blockchain-based IoVs and this is followed by a conclusion in
section 7.

##  2 Background

In this section we provide an overview of IoV including the IoV architecture
and IoV applications and the advantages of IoV. We also provide an overview of
Blockchain technologies, including consensus algorithms relevant to IoVs.

###  2.1 IoV Architecture and Overview

Figure 1: Typical IoV Infrastructure

IoV is a vehicular ad hoc network (VANET) that has been connected to the
Internet [23]. VANETs are a type of mobile ad hoc network (MANET) comprised of
smart vehicles and roadside units (RSUs) that communicate wirelessly, sharing
information such as vehicle speeds and positions [24]. IoVs can also be
supplemented with AI and ML technologies to create an Intelligent
Transportation System (ITS). Figure 1 illustrates a typical IoV infrastructure
where vehicles communicate with other vehicles using vehicle-to-vehicle (V2V)
communication and communicate with RSUs using vehicle-to-RSU (V2R)
communication. IoV is a vehicle-specific implementation of IoT that focuses
primarily on connecting vehicles to the network infrastructure, other devices
and the Internet. IoT refers to the networking of everyday objects such as
home appliances equipped with sensors and computing capabilities with the goal
of embedding technology into the background of everyday life.

By sharing important traffic information such as road conditions and traffic
congestion between vehicles on the network, IoVs are capable of improving
traffic efficiency and reducing traffic congestion and accidents [25, 26, 27,
28]. In addition to safety-related applications, IoVs may also be designed to
support other applications such as autonomous driving, infotainment, payment
services, and vehicle usage tracking for calculating insurance rates [29, 24].

The primary advantages of IoV include improved traffic and fleet management,
improved road safety, and better allocation of resources such as energy and
fuel consumption. Implementing an IoV infrastructure would also increase the
effectiveness and efficiency of autonomous driving applications. These
advantages would also provide tangential benefits such as the reduced cost of
goods and services that depend on our transportation system. For example,
greater efficiency and better energy or fuel savings have the potential to
lower the costs of food and products sold in stores since the price of such
products takes into account delivery costs.

###  2.2 Overview of Blockchain Technology

Figure 2: Illustration of a Blockchain structure, where transactions are
packed into blocks that are linked to previous blocks.

A typical Blockchain system can be expressed as a collaboration of devices or
nodes. However, the nodes do not necessarily trust one another. Together, the
nodes maintain a set of shared global states and perform transactions that may
modify the states. Blockchain is a special type of data structure that is
capable of storing historical states and transactions. All nodes in the system
agree on the transactions and their order. Blockchain has been evolved to
support smart-contracts which are considered an autonomous computer programs
that can run on a Blockchain network and its terms can be pre-programmed with
abilities such as self-enforcement without the interference from trusted
authorities.

####  2.2.1 Security Services of Blockchain

Figure 2 depicts a Blockchain data structure. Each block in this structure is
linked to its predecessor by way of a cryptographic pointer. The first block
in the structure is called the genesis block. Due to this design, Blockchain
is characterized as being a distributed ledger. Each block in Blockchain
contains a roothash or Merkle root that contains the hashes of all
transactions [30]. The transaction lifecycle is depicted in Fig. 2 To add a
block to Blockchain, a miner must successfully solve the computationally
difficult puzzle of finding the right nonce for a block header. Blockchain
offers several key features such as:

Figure 3: Illustration of a Blockchain Transaction Lifecycle. (1) A user A
generates a transaction for user B. (2) Transaction is stored in memory pool
along with other unconfirmed transactions. (3) A miner validates transactions
from memory pool and computes block. Note that Transaction 2 was not valid so
miners did not select it to add to block. (4) Valid block is added to
Blockchain.

  * •

Decentralized data management. Every peer in the system has the authority to
add data to the ledger, which is referred to as making a transaction. In this
way, no one peer owns the Blockchain system more than another. IoVs would
benefit from decentralization since it would remove obvious problems related
to reliance on a central authority such as the potential for a single point of
failure.

  * •

Data security, tamper-proofness, anti-forgeability and data integrity.
Blockchain is designed to store data in an immutable and tamper-proof fashion.
The decentralized nature of Blockchain makes it is inordinately challenging
for attackers to modify the ledger. Immutability would benefit IoVs in many
ways such as providing immutable proof of vehicle transactions related to
energy trading, ride sharing, smart parking and payment for leading a platoon.

  * •

Transparency. A shared public list of transactions or exchanges of data
provides every peer in the network access to every transaction ever made on
the system. Therefore, the system is transparent. IoVs would particularly
benefit from the transparency of exchanges in the context providing all
parties and insurance companies transparent access to shared vehicular
accident data.

  * •

No central point of failure. The lack of a centralized storage system
eliminates the possibility of losing data stored on the system by an attack of
one node. This feature is particularly important in the context of IoV since
failure of the system could result in accidents, loss of human life and
economic losses.

  * •

High efficiency. Checking balances and completing transactions in a Blockchain
system can, in theory, be instantaneous. High efficiency is particularly
important in the context of IoV due to the dynamic and fast changing nature of
vehicles on the road.

####  2.2.2 Consensus Algorithms

The content of Blockchain’s distributed ledger consists of historical and
current states. Any updates made to the ledger must be agreed upon by all
parties. This agreement is referred to consensus. Several consensus algorithms
exist for Blockchain. These algorithms can be characterized as computation-
based or communication-based. Computation-based algorithms use proof of
computation to randomly select a node and that node decides the next
operation. In communication-based algorithms, each node has an equal vote and
it takes multiple communication rounds to reach consensus. Bitcoin utilizes
the Proof-of-Work (PoW) consensus algorithm, which is a purely computation-
based. Practical Byzantine Fault Tolerance (PBFT) is an example of a purely
communication-based consensus algorithm [31]. Other consensus algorithms such
as Proof of Elapsed Time (PoET), Proof of Authority (PoA) fall somewhere
between computation-based and communication-based. Table II provides an
overview of the primary consensus algorithms relevant to IoVs.

In PoW [32], the miner that expends the most amount of work or effort solving
the hash puzzle is chosen to propose the new block. Therefore, in Blockchain
systems that utilize PoW, miners that have greater computation power have a
greater chance of being selected to propose a new block. Proof of Stake (PoS)
was first introduced by Sunny King and Scott Nadel [33] in 2012 as a more
scalable and energy efficient alternative to Bitcoin’s PoW. In PoS, the
ability to validate blocks is based on how many coins or network tokens the
user has. PoS helps protect the Blockchain system from malicious users who
wish to take over the majority of validation by requiring the malicious user
to acquire a large amount of tokens in order to launch an attack on the
system. Proof of Authority (PoA) [34] is a modified version of PoS that uses
the validator’s identity in lieu of a user’s stake. In PoA, transactions and
blocks are validated by approved accounts known as validators. Under PoA,
individuals must earn the right to become a validator based on their
reputation. Individuals are motivated to support the transaction process to
retain their reputation and status as a validator. Proof of Elapsed Time
(PoET) [35] was designed to be more efficient and use less resources and
energy than conventional PoW. PoET also makes use of a fair lottery system to
ensure efficient consensus process. The lottery system provides every
participant a chance of being selected by spreading this chance equally
amongst participants. Dan Larimer [36] first proposed Delegated Proof of Stake
(DPoS) in 2014 as a faster and more energy efficient replacement for Bitcoin’s
PoW consensus algorithm. DPoS protects Blockchain better than PoW by employing
an election process that ensures transactions receive better representation
within the system. Users vote for delegates or witnesses who are responsible
for generating and validating blocks. The primary difference between PoS and
DPoS is that in PoS, users vote on the validity of blocks, while in DPoS,
users elect delegates to validate the blocks.

Another notable Blockchain consensus algorithm is RAFT [37], which stands for
"Reliable, Replicated, Redundant And Fault-Tolerant." RAFT is based on the
Paxos [38, 39] and was developed with the primary goal of increasing
understandability and providing a better foundation for building practical
systems. To make Blockchain consensus more understandable, RAFT separates the
key elements of consensus such as leader selection, log replication and
safety. RAFT also enforces a stronger degree of coherency in order to reduce
the number of states that must be considered. In addition, RAFT affords
enhanced safety using a mechanism for changing cluster membership to overlap
majorities.

Byzantine Fault Tolerant Consensus Algorithms. Byzantine Fault Tolerance (BFT)
refers to the ability of a system to resist failures resulting from the
Byzantine Generals’ Problem [40]. The Byzantine Generals’ problem is a logical
dilemma first conceived of in 1982 where a number of generals must come to a
consensus with the decision to retreat or attack. Communications between
generals can be delayed, lost or destroyed or a general may act maliciously by
sending fraudulent messages to bemuse other generals. With respect to
Blockchain, generals refer to the different nodes or participants on
Blockchain which may send false information or their communications may be
delayed, lost or destroyed. A number of BFT-based algorithms have been
proposed for Blockchain consensus such as Practical BFT (PBFT) [31], Redundant
BFT (RBFT) [41], Delegated BFT (dBFT) [42] and BFT Delegated Proof of Stake
(BFT-DPoS) [43].

Castro and Liskov [31] designed Practical Byzantine Fault Tolerance (PBFT) for
asynchronous systems to preserve liveness and safety while providing increased
performance. Liveness means that clients receive replies to their requests
while safety means that the replicated service satisfies linearizability [44,
45]. Concurrent operations are considered linearizable if they perform in a
way that is equivalent to sequential operation. PBFT operates under the
assumption that the maximum number of malicious nodes is no greater than or
equal to one-third of all nodes on the system. Thus, as the number of nodes on
the system increases, the system becomes more secure. Aublin et al. [41]
designed Redundant Byzantine Fault Tolerance (RBFT). RBFT achieves better
performance during occasions where faults occur achieve this, RBFT executes
multiple instances of BFT in parallel. RBFT is similar to PBFT but has an
added procedure for transaction verification called "PROPAGATE".

Another consensus is called Byzantine Fault Tolerant Delegated Proof of Stake
(BFT-DPoS) which is a combination of BFT and DPoS [43]. Like DPoS, BFT-DPoS
participants that hold tokens vote on block producers. The algorithm
supplements traditional DPoS with BFT by allowing all producers to sign all
blocks as long as no producer signs two blocks using the same timestamp or
same block height. In addition to cryptocurrency, BFT-DPoS has been employed
by authors such as [46, 47] for Blockchain-based vehicular networks, which are
discussed in Section 3.5 below.

TABLE II: Overview of Consensus Algorithms used in Blockchain. Notice that public and permissionless Blockchains using PoW, PoS and DPoS have high scalability, low throughput and high confirmation times. In contrast, permissioned Blockchains using PBFT and RAFT have low scalability, low confirmation time and high throughput. Properties |  PoW |  PoS |  DPoS |  PBFT |  RAFT
---|---|---|---|---|---
Blockchain Type | Permissionless | Permissionless | Permissionless | Permissioned | Permissioned
Participation Cost | Yes | Yes | Yes | No | No
Trust Model | Untrusted | Untrusted | Untrusted | Semi-trusted | Semi-trusted
Scalability | High | High | High | Low | Low
Throughput |  $<$ 10 |  $<$ 1,000 |  $<$ 1,000 |  $<$ 10,000 |  $>$ 10,000
Byzantine Fault Tolerance | 50% | 50% | 50% | 33% | -
Crash Fault Tolerance | 50% | 50% | 50% | 33% | 50%
Confirmation Time |  $>$ 100s |  $<$ 100s |  $<$ 100s |  $<$ 10s |  $<$ 10s

Finally, Table II provides a summary of the most prominent consensus
algorithms employed in Blockchain. Overall, PoW provides good scalability but
worse performance while BFT-based procotols such as PBFT offer good
performance and limited scalability [48]. PoS requires less energy than PoW
and therefore is more befitting for large-scale Blockchain applications like
IoT and IoV [49]. Permissionless Blockchains that use PoW, PoS and DPoS offer
high scalability but have low throughput and high confirmation times. On the
other hand, permissioned Blockchains that use PBFT and RAFT offer little
scalability but have high throughput and low confirmation time. The basic
distinction between permissionless and permissioned Blockchains is that
permissionless Blockchain allows anyone to participate in the Blockchain while
permissioned Blockchain requires prior approval to participate.

##  3 Blockchain-based IoV Applications

Energy TradingCrowd SourcingVehicle PlatooningInfotainment Traffic Congestion
Reduction Collision & Accident Avoidance [50] Aggarwal (2020)[51] Long
(2020)[52] Hassija (2020)[53] Pustisek (2016)[54] Knirsch (2018)[55] Su
(2018)[56] Kang (2017)[57] Huang (2019)[58] Li (2020)[59] Wang (2020)[60] Baza
(2019)[61] Li (2019)[62] Al-Jaroodi (2019)[9] Badr (2021)[63] Wagner
(2018)[64] Ying (2019)[65] Chen (2020)[66] Li (2021)[67] Kim (2021)[68] Li
(2018)[26] Liu (2019)[25] Yang (2020) [69] Westerlund (2020) [70] Singh (2020)
[47] Fu (2020) [71] Buzachis (2018)[71] Buzachis (2019) [72] Dai (2020) [73]
Qian (2020) [74] Zhang (2019)Machine LearningQ-LearningSVM[75] Shen
(2020)AV[76] Qui (2018)[47] Fu (2020)[77] Pokhrel (2020)[78] Kumar
(2021)content caching[79] Wu (2022)[80] Li (2022) Figure 4: Applications of
Blockchain-Enabled IoV

In this section, we review the primary applications of Blockchain-based IoVs.
Figure 4 summarizes the current achievements in BIoV applications.

###  3.1 Energy Trading

With the advancement and increase in the number of electric vehicles (EVs),
vehicle-to-grid (V2G) networks have been developed that are capable of
providing a two-way flow of electrical energy between EVs and charging
stations within smart grids [50]. Energy trading is the mechanism used by V2Gs
that permits charging and discharging of EVs and other entities and serves to
manage energy demand [81]. In an V2G network, EVs can act as either energy
consumers by charging their batteries at charging stations or energy producers
by discharging surplus electricity back into the system. In this way, energy
trading in V2G networks can serve to enhance overall energy efficiency and
greater sustainability [51, 82].

Traditional V2Gs, however, rely on a central server, which is susceptible to
SPOF. Therefore, a number of researchers have proposed implementing V2Gs using
Blockchain [50, 51, 52]. In addition to solving the centralization problem,
Blockchain can be utilized to enhance security and privacy of EVs as well as
offering the Blockchain benefits of decentralization, security, immutability
and transparency. However, there are several Challenges to integrate
Blockchain in V2G networks for energy trading (See Table III) that include
securing the identity and location privacy of EVs during energy trading while
at the same time ensuring the efficient distribution of energy amongst V2G
entities. Another challenge to integrate Blockchain in V2G networks used for
energy trading is ensuring the scalability of the V2G network to support the
dynamic nature of EVs over the network, including the increasing number of
transactions on the network.

TABLE III: Challenges for Blockchain-Based V2G Networks for Energy Trading

Challenge |  Description |  Blockchain-Based Solutions
---|---|---
Identity privacy |  Preventing leakage of EV identity information during communication between V2G entities |  [50, 83, 84, 85, 86]
Location privacy |  Prevent leakage of EV location information during communication between V2G entities | [87, 88, 89, 90, 91, 92, 51, 93, 94, 95]
Scalability |  Supporting dynamic nature of EVs on network including increasing number of transactions on network | [52, 83]
Competitive bidding for energy prices |  Supporting competitive bidding for energy trading prices over network | [53, 54, 56, 55, 57]

To solve the problem of identity privacy, the authors in [50] proposed a
Blockchain-based efficient authentication scheme for V2G networks designed to
preserve the identity of EVs. Merkle Root Hash (MRH) is used to verify and
validate transactions before adding new blocks to the Blockchains. The scheme
also provides for a reward mechanism for EVs for participating in the
regulatory and managing process. A major drawback with this scheme is that it
is not fully decentralized as it requires utility company to act as the third
party to maintain the Blockchain and validate transactions. In another works
[83, 96], the authors have proposed using pseudonyms to preserve privacy,
however because EVs are anonymous, a dishonest EV may abuse such anonymity by
pretending as multiple non-exiting EVs to submit multiple reservations/offers
without committing to them. To address this problem and a common prefix
linkable anonymous authentication scheme have been used so that if an EV
submits multiple reservations/offers at the specific timeslot, the Blockchain
nodes can identify and reject such submissions. In another works [84, 85, 86],
Blockchain has been used to enable Dynamic wireless charging of EVS to enable
the exchange of power between a mobile EV and the electricity grid via a set
of charging pads (CPs) deployed along the road. To ensure EVs anonymity and
data unlinkability, group signature technique is used to enable EVs to send
charging requests anonymously. However, there is no implementation to measure
the scalabilty and performance issues of using Blockchain technology in the
case of dynamic wireless charging of EVS.

To address location privacy, techniques employed in the research include
obfuscation [87, 97], differential privacy [88, 89, 90, 98, 99], K-anonymity
[91, 92, 51, 100, 101] and pseudonym exchanges [93, 94, 95] and combination of
all these techniques [102]. For example, K-anonymity is a measure of anonymity
of entities within a dataset where methods such as suppression or
generalization of data within that dataset are used to ensure the individuals
or entities within that dataset cannot be reidentified [103]. Such
reidentification can be either directly or indirectly by inference by
comparing the individual’s data to data within another dataset [103]. It is
referred to as K-anonymity because there must be at least k other entities
that share the same set of identifiable attributes for the entity to be
considered k-anonymous. Methods for increasing K-anonymity include removing,
hiding or encrypting identifiable attributes for the entity within the
dataset. The authors in [51] suggest that K-anonymity best serves vehicle
identity privacy in the context of Blockchain-based V2G networks. In this
work, the authors propose a P2P EV energy trading scheme that makes use of
consortium Blockchain and K-anonymity based on an undirected graph to protect
the location privacy of EVs. EVs within the network can be visualized as nodes
or vertices and the connections between the EVs as edges. In this work, not
all EVs share connections with all other EVs. When an EV makes an energy
trading request, it collects the locations and identities of all other EVs on
the network and sends the locations and identities of all these EVs in the
request along with its own. By including all EVs within each request, an
adversary would have a difficult time identifying which EV made the actual
request.

Scalability of the V2G network is another challenge to integrating Blockchain
in V2G network for energy trading. To address the scalability challenge, the
authors in [52] proposed using a lightweight Blockchain-based protocol called
directed acyclic graph that uses an IOTA ledger with a tangle data structure
to record transactions securely and in a scalable manner. The authors uses
IOTA ledger as is more suitable for recording and processing a large number of
micro-transactions. Also, IOTA networks are less susceptible to distributed
denial of service (DDoS) attacks since no single node retains the unique
privilege to create or maintain the data structure. The work developed a tip
selection algorithm that allows the addition of new transactions without the
need of miners, thereby decreasing the amount of computation power needed.
Here, a tip refers to a transaction that has yet to be approved. Game theory
is used to allow EVs negotiate with the grid for the best price and match EVs
with the most optimal grid.

In energy trading one of the concerns is to select an EV with the best bid
price. Authors in [53], has used smart contract to select the most appropriate
bid price dynamically among all the charging station where Blockchain is used
to maintain information about the EV route, car battery status and the
preference of driver. After getting updated information from Blockchain,
charging stations broadcast their desired price to the EV network from where
EV selects the best one though the underlying payment system is still one of
the limitations of their proposed scheme. In [54], a hidden commitment is sent
to the Blockchain by the EV for reserving a place in the charging station with
the best price though management of this system is not good as the charging
station does not aware about the reservation until the EV reaches the definite
charging station. Also, authors do not mention about the payment system along
with the privacy protection of the EVs as well as this proposed scheme is
prone to Sybil attacks and denial of service (DoS) attack. Optimization for
the electricity consumed and its price is also a concern issue in energy
trading which is mentioned in [56] where authors have proposed a decentralized
electricity trading system based on consortium Blockchain by using iterative
double auction optimization method or V2V charging. In energy trading it is
also needed to maximize the operator's profit while to give the EV best
service price. To make the operator's benefit maximum, authors in [55], has
proposed a contract theory with integration of Byzantine fault tolerance
consensus algorithm to reach the consensus in the permissioned energy
Blockchain. Another scenario to maximize user's benefit along with the
minimizing the cost has been proposed in [57], where authors have utilized a
double- objective optimization model for constructing this optimal charging
scheduling algorithm that considers both V2V and CS2V.

Wu et al. [79] discuss how to keep a P2P energy trading secure and reliable as
new roles and players such as EVs are injected into energy systems. They also
discuss how to improve the cooperation between regulated energy system players
such as utility companies and non-traditional players such as EVs. The authors
suggest that blockchain and multi-scale flexibility services can serve as an
key enablers for solving issues of security, reliability and trust and better
coordination between traditional and non-traditional energy-trading roles.
Smart contracts can be employed as self-regulating and self-executing
mechanisms for matching energy producers with consumers for energy trading.
Smart contracts can also be implemented to automate flexibility processing,
including the clarification of energy trading roles (providers and suppliers)
and responsibilities. One drawback to their proposal is that it is not
completely decentralized as they suggest professional players and decision
makers should play the role of regulating the energy system.

As mentioned, EVs can sell energy in exchange for rewards or payment. However,
a malicious server may attempt to develop behavior profile for an EV, which
poses a privacy issue. To solve this issue, one could apply a private data
sharing scheme similar to the one proposed by [80]. Although this proposal
focuses on securing private data on IoT devices in general, a similar scheme
could be applied to EV private data concerning energy trading. The authors
proposed a blockchain-based privacy preserving and rewarding private data
sharing scheme for IoT. The authors make use of deniable ring signature and
Monero to implement behavior profile building prevention with non-
frameability. The proposal also uses licensing technology executed by smart
contracts to ensure flexible access control for multi-sharing.

###  3.2 Crowdsourcing-based applications

Crowdsourcing is a novel model in which customers as well as organizations
obtain goods or services. Examples of Crowdsourcing includes ride sharing and
smart parking systems. During ride sharing one of the major concerns is to
protect the privacy for both riders and drivers and riders as for accessing
this service they need to share their personal information such as location.
To solve this problem, the work in [58] has proposed a Blockchain-based zero-
knowledge proof protocol by which a rider can his service from a verified
driver that will be done by the peer nodes in the Blockchain. Tough this
problem does not address the problem associated with the attacker disguised as
the rider and also due to presence of a central authority for issuing the
keys, this model is not fully decentralized.

Computational overhead is a common drawback in BIoV during ridesharing. To
solve this issue, in [59], authors have proposed consortium Blockchain which
uses attribute-based proxy re-encryption algorithm for guaranteeing the
security and privacy of the shared data. The DPoS (Delegated Proof of Stake)
is used here for storing the block and verifying it for traceability if
needed. On the other hand, fog computing is used in [61], to match drivers
with the passengers locally which can lessen the computational overhead.
Authors here used a private proximity test with location information for
generating a unique secret key which is used between passenger and driver. A
private Blockchain has also been introduced for keeping the record of
ridesharing. Here, hash value is stored in Blockchain whereas encrypted data
is stored in cloud.

To address security and privacy issues in ride sharing, In [60], Baza et. al
have proposed a privacy-preserving ride sharing scheme using the
permissionsless Blockchain. The main idea of the proposed scheme is to that
riders hide their exact pick-up and drop-off location information by cloaking
their location information. The authors also addressed the problem of
malicious behaviour of drivers and riders using the open and permissionsless
Blockchain. The main idea is that dishonest drivers and riders are published
by paying an initial deposit before the beginning of the trip. Then, using
zero-knowledge proof, drivers have to prove to the Blockchain their good
willing by submitting the pick-up location. The Blockchain can verify that the
driver lies in a set of predefined pick-up locations without knowing the exact
pick-up location to preserve privacy. The proposed techniques use the IoV
infrastructure so RSUs verify the driver’s pick up location before submitting
it to the Blockchain. In another work by [9], and instead of the cloaking
technique, the authors proposed to represent the ride sharing area into
overlapping grids so nearby riders/drivers can share rides. Then, for privacy-
preservation, drivers/riders should encrypt their requests/offers using a
lightweight cryptosystem, and then the Blockchain matches the encrypted offers
and requests to find the best nearby driver/rider.

Another sourcing models including smart parking system to enable individuals
to share available parking slots to drivers. Because the number of vehicles in
the IoV is increasing exponentially which leads to a fast-growing problem of
finding vacant parking slots. Latest parking system have several privacy and
security vulnerabilities such as they are centralized which cause single point
of failure. They also do not consider the privacy issue of the drivers [104,
105, 106, 107]. It is also needed to share the location information for this
smart parking, and it is a big concern to provide location privacy during
traffic data sharing or ridesharing [108, 109, 110, 111]. Blockchain is key to
solve these problems regarding security and privacy. Authors in [62, 112],
proposed a Blockchain based smart parking system which can preserve the
driver’s location by using the private information retrieval (PIR) technique.
A short randomize signature is used to allow the drivers to put parking
reservation request anonymously without exposing their real identities.
Payment system here utilizes time locked criteria anonymously by exploiting
smart contract and Blockchain between drivers and parking station.

###  3.3 Vehicle Platooning

The ever-increasing number of vehicles on the road has led to increased
pollution [113] and traffic congestion [114, 115]. One potential solution to
these problems is to utilize vehicle platooning. In a vehicle platoon system,
a leader vehicle transmits its velocity and acceleration to other vehicles
that follow it in the platoon. Based on the information transmitted from the
platoon leader, the follower vehicles will, in turn, adjust their velocity and
maintain a safe distance between themselves [116, 117, 118, 119]. Figure 5
illustrates a typical vehicle platoon system. In essence, the vehicles act
similar to a train where the leader can be likened to a locomotive and the
followers to the cars it pulls. Advantages of vehicle platooning include
improved traffic capacity, traffic congestion reduction, reduced energy
consumption and improved driving experience for platoon followers [120, 121,
65]. For the platoon to successfully function, reliable and low-latency V2V
communications between the vehicles are required. However, V2V communications
can suffer from security and privacy issues. The security and privacy features
offered by Blockchain could be used to solve such issues. Issues regarding
implementing Blockchain in a vehicle platooning system include encouraging
vehicles to serve as platoon leader, ensuring platoon leaders are paid for
leading, and the handling the dynamic nature of vehicles entering and leaving
platoons during their journey.

Proposals for integrating Blockchain into vehicle platooning systems exist as
early as 2018. Wagner and McMillin [63] were the first to discuss Blockchain’s
potential role in vehicle platooning. The article’s main focus is on securing
IoVss using Blockchain but they discuss vehicle platooning as a use case and
they provide a novel proposal for validating integrity of vehicles
participating in the platoon. Ying et al. [64] proposed a Blockchain-based
platoon management system for autonomous vehicles. To increase the overall
safety of the system, their proposal limits communication outside of the
platoon to the platoon leader. The proposal also makes use of smart contracts
for paying the platoon leader. The authors in [65] proposed a vehicle
platooning system that employs both smart contract and Blockchain for secure
payment of platoon followers to the platoon leader. The authors’ proposed
system is designed to handle the dynamic nature of vehicles entering and
leaving platoons throughout their journey. Their proposal utilizes path
information to match the vehicles and elects platoon leaders based on their
recorded reputation. The authors in [66] proposed a truck platooning system
with a location-aware and privacy-preserving verification protocol based on
zero-knowledge proof and permissioned Blockchain. Their proposed system
provides lower latency and communication overhead by performing the
verification process within a spatially-local area defined by the platoon.

Figure 5: Vehicle Platooning. Lead vehicle transmits its velocity and
acceleration to follower vehicles so that they can match the leader vehicle
and maintain a safe distance between themselves

###  3.4 Traffic Congestion Reduction

IoV implementations of IoVs can serve to reduce traffic congestion on roads
and highways. Information regarding traffic congestion can be shared between
vehicles [122, 123]. Vehicles who have yet to approach the congested area can
use this information to alter their routes and avoid the congestion. This, in
turn, will help reduce the congested area. However, the trading of road
congestion information raises security and privacy concerns especially in
terms of revealing the location information of vehicles. Features of
Blockchain could be utilized to solve these security and privacy concerns
[124, 125].

Li et al. [68] proposed a trust management protocol called CreditCoin which
makes use of an incentive mechanism to encourage vehicles to share traffic
information. Under authors’ proposal, RSUs and official public vehicles make
use of authors’ proposed BFT-based consensus mechanism, which repeats a voting
process until an agreement is reached. Advantages of authors’ proposal include
low computation time and the ability to defend against Sybil attacks.
Drawbacks to authors’ proposal include limited scalability and privacy leakage
concerns. Although BFT-based consensus provides overall good performance, it
only provides limited scalability [48]. Privacy leakage concerns exist in
authors’ proposal because the system combines credits with transactions and
transactions are accessible by everyone. Liu et al. [26] proposed a
Blockchain-based trust management model with a conditional privacy-preserving
announcement scheme for IoVs. The system uses an anonymous aggregate
announcement protocol to allow vehicles to send messages such as traffic
information anonymously and thereby guarantee the privacy of the vehicles in
an untrusted IoVs. Similarly, Yang et al. [25] proposed a decentralized trust
management system for IoVs using Blockchain where vehicles can validate
messages containing information such as traffic information from other
vehicles using a Bayesian Inference Model. Vehicles rate each vehicle using
this model and upload their ratings to RSUs, which are responsible for
calculating the trust value for each vehicle and packaging such values into a
block in Blockchain. Their system makes use of a combination of PoS and PoW
consensus algorithms. One drawbacks to this work includes the potential for
privacy leakage related to the fact that authors’ proposal uses vehicle
identity number and a malicious entity could use this information to discover
the identity of the vehicle. The authors suggest a future work could make use
of public key encryption to solve this problem.

Though our current traffic can be turned into decentralized by adding
Blockchain, then this system will face a new challenge associated with data
integrity and data privacy during the incorporation of connected vehicle data
into real traffic system because of the transparency advantage in Blockchain.
In [126], authors propose a location aware traffic management with addition of
non-interactive zero knowledge range proof protocol (ZKRP) and permissioned
modular Blockchain which is based on Hyperledger fabric platform and
Hyperledger Ursa cryptographic library. This data management which has also a
gateway that authenticates each incoming vehicle. Instead of providing the
incoming vehicle’s identity, it will send a ZKRP encrypted message to the
gateway for validation where the gateway acts as the verifier and the incoming
vehicle acts as the prover. This model can stand against spoofing attack,
eavesdropping attack and tampering but it requires high running time required
as Hyperledger Ursa does not compute in parallel and this model doesn’t
provide any scenario if the gateway encounters more than one request at a time
in multiple region scenario.

Kumar et al. [78], employ Blockchain along with deep learning to address
security and privacy vulnerabilities in a cooperative intelligent
transportation system (C-ITS). The proposed framework addresses security
issues using Blockchain and deep learning modules. The Blockchain module is
used to securely transmit data between AVs, RSUs and traffic command centers.
The module uses a smart contract-based enhanced PoW (ePoW), a consensus
algorithm first proposed by Keshk et al. [127], which is more energy-efficient
alternative to PoW and PoS and is designed to authenticate data records and
prevent data poisoning. ePoW estimates its proof based on the number of
records in the dataset. Lastly, the proposal by Kumar et al.’s [78] has a deep
learning module that uses a Long-Short Term Memory-AutoEncoder (LSTM-AE) to
encode C-ITS data to prevent inference attacks. The authors propose an
Attention-based RNN (A-RNN) to analyze the encoded data and detect intrusive
events on the C-ITS.

###  3.5 Collision and Accident Avoidance

AVs use non-linear controllers in order to maneuver through the dynamic and
ever-changing nature of vehicles on the road [128]. Vehicle-to-everything
(V2X) communication can be harnessed to share information gleaned from on-
board sensors with other vehicles and alert them of objects or persons on the
road and other hazardous road and environment conditions so that vehicles can
take appropriate actions to avoid collisions with objects or persons or
accidents [129]. The increased connectivity and reliability provided by IoV
can further improve this feature. V2X refers to communications between vehicle
and things within its environment such as traffic lights, pedestrians and
other vehicles. As such, V2X is also an all-encompassing term that includes
other communications such as vehicle-to-infrastructure (V2I), vehicle-to-RSU
(V2R), vehicle-to-onboard-sensors (V2S) and vehicle-to-vehicle (V2V)
communications. The increased connectivity and reliability provided by IoV can
provide faster and more efficient delivery of V2I communications regarding the
road environment to vehicles which, in turn, can serve to enhance vehicle
localization. Localization refers to the method by which an IoV determines the
accurate location of a vehicle. However, with such increased localization also
arise concerns of security and privacy of vehicle location. One should also
consider the security and privacy of other entities participating over IoV.
The security and privacy features of Blockchain could be harnessed to solve
such issues.

Robin Westerlund [69] proposed an Ethereum Blockchain-based system where AVs
use smart contracts to reserve and exchange road spaces for travel. According
to author, this system could be used to ensure AVs do not try to occupy the
same spaces and maintain a safe distance from one another so as to prevent
accidents and collisions. Through a simulation, the author demonstrated that
the proposed system provides a high level of security and reliability.

Another approach is to apply the concept of swarm robotics to the cooperation
of AVs within the context of IoVss and IoV. Under swarm robotics, robots
communicate and share information with the goal of coordinating actions for a
common goal. Based on this concept, Singh et al. [70] proposed a Blockchain-
based framework using PoA as an efficient consensus mechanism for swarm
robotics. A similar swarm technique could be explored in the context of AVs
within a IoVs or IoV. Swarm coordination of AVs secured by Blockchain could be
used to coordinate the movement of vehicles on the road to prevent collisions
and, in particular, the coordination between AVs crossing through an
intersection.

IoV can also be harnessed to reduce collisions resulting from improper lane
changing decisions and those caused by failure to identify vehicles,
particularly smaller vehicles such as motorcycles, approaching a vehicle from
its blind spot. The authors in [47] proposed a Blockchain-based collective
learning (BCL) framework for the secure and efficient lane changing of
connected and autonomous vehicles (CAVs). BCL adopts federated learning (FL).
Using FL in lieu of a central server solves the problem of reliance on a
central server and single-point-of-failure (SPOF) attacks and allows vehicles
to take advantage of the collective intelligence of all vehicles on the
network. Using consortium Blockchain to store the collective learning
regarding lane-changing behavior further secures the learning process and
helps prevent false information sharing.

Buzachis et al. [71] proposed an autonomous intersection management system
that uses Hyperledger Fabric permissioned Blockchain and smart contracts to
securely manage AVs as they cross through intersections. AVs use V2I
communication to relay information such as vehicle identity, speed and
position to an intersection management agent. To ensure only valid AVs make
crossing requests with the intersection management agent, AVs are required to
send their requests using digitally signed messages using public key
encryption. The intersection management agent deploys a smart contract with
the AV how to safely cross the intersection and records each crossing in
Blockchain. In the case of multiple requests from different AVs to cross an
intersection, the system uses a first-come first-serve (FCFS) algorithm to
determine the order of intersection crossings. One drawback for authors’
proposal is that it is not completely decentralized as intersection management
agents are assumed to be under the auspices of public traffic authorities.

In a later work, Buzachis et al. [130] propose a similar intersection
management system based on the agreement between AVs through V2V communication
rather than relying on an intersection management agent. Similar to [71], the
system makes use of Hyperledger Fabric permissioned Blockchain and the first-
come first-serve algorithm. However, in this proposal, AVs host the Blockchain
ledgers and conduct smart contracts. Based on simulations, however, the
authors concluded that the relay of information between AVs was too slow to
provide reliable real-time intersection passing decisions. Future research can
be done to decrease communication latency and make the system more scalable
with a larger amount of AVs requesting passage.

###  3.6 Infotainment and Content Cashing

Implementing a IoVs using IoV improves better Internet connectivity for
vehicles and this increased connectivity can serve to improve the delivery of
in-vehicle infotainment to vehicles such as music and video content for
passengers. Such content will enhance the experience and enjoyment of drivers
and passengers. However, this connectivity raises concerns regarding the
security and privacy of the content delivered to vehicles. The increased
security and privacy provided by Blockchain could be used to solve these
concerns. Kim and Ryu [67] proposed a system called autoCoin designed to
encourage smart vehicles to exchange infotainment securely. Their system makes
use of a scalable Blockchain architecture and smart contracts to exchange
infotainment contents in a peer-to-peer fashion rather than rely on a third-
party to deliver infotainment content. In addition, autoCoin makes use of a
variant of PoS called Proof-of-Stake Deposit (PoSD) as a consensus mechanism
and includes a reward mechanism to encourage vehicles to share content.

Some propositions for IoV utilize a cognitive engine to perceive content
requirements of users and match them with content providers and thereby
improve the content caching hit rate. Figure 6 illustrates a traditional
cognitive IoV (CIoV) infrastructure. A CIoV infrastructure consists of three
layers: (1) vehicular layer, (2) edge layer, and (3) remote-cloud-based
content providers and cognitive engine layer. In the vehicular layer, vehicles
collect data using onboard sensors and send them to the cloud for data
analysis by the cognitive engine. Vehicles in this layer also communicate with
each other using V2V communication. In the edge layer, vehicles communicate
with RSUs using vehicle-to-RSU (V2R) communication. In the remote-cloud-based
content provides and content cognitive engine layer, a cognitive engine
percieves the needs of vehicles using deep learning and ML.

Figure 6: Traditional CIoV Infrastructure

####  3.6.1 CIoV Challenges and Solutions

There are several issues with CIoV [131, 132, 133]. Table IV summarizes the
various challenges to implementing an effective CIoV infrastructure. First,
the process used by a CIoV introduces privacy and security issues. Contents
requesters may submit data such as points of interest or other private data
that could be leaked. Also requesters may receive data from untrusted parties.
Other problems with traditional CIoV include limited transaction time for
obtaining contents, the cognitive engine cannot accurately determine true
content requirements, the content stored on nearby RSUs may not meet the needs
of a requester, and the constant broadcast of content

TABLE IV: Challenges for Traditional CIoV Infrastructures Challenge |  Description
---|---
Privacy |  Content requesters may submit private data that could be leaked such as points of interest.
Security |  Content requesters may receive data from untrusted parties.
Limited Transaction Time |  Limited transaction time for obtaining contents
Failure to accurately determine content requirements of requestors |  Cognitive engine may not accurately determine the true content requirements of content requesters
Failure to store proper contents on nearbye RSU |  CIoV framework may not store content on nearby RSUs that meet the needs of the content requesters
Constant broadcast of contents |  Requiring content be constantly broadcasted imposes high storage and communication costs

In response to these problems, the authors in [73] proposed a Blockchain-based
privacy-aware content caching architecture in CIoV. Figure 7 shows the
architecture of the proposed scheme. The work aims to improve the cache hit
ratio by designing the cognitive engine to perceive the content requirements
of requesters using ML or deep learning and sending such perceived content
requirements to RSUs ahead of time. Vehicles receive content by downloading it
when RSUs and vehicles broadcast it. Since content requester vehicles just
receive the broadcast, rather than sending an individual request that contains
the requested content, the requested content is private. A cognitive engine is
responsible for detecting when content requesters connect to providers by V2R
or V2V communication and record the transaction. Providers in authors’ scheme
need to collaborate together to provide content because transient vehicle
requesters may not always be in range of any one provider. When a provider
provides content, it receives a reward and after the transaction is complete,
the cognitive engine will record it in Blockchain.

Figure 7: Blockchain-based Privacy-Aware Content Caching Architecture. There
are four phases: (1) cognitive engine data analysis in which the cognitive
engine sends recommended content sets to vehicles. The cognitive engine uses
data analysis and AI techniques to update the content caching and improve the
content caching hit ratio. (2) Vehicle registration phase in which each
vehicle chooses a role as either content requester or content provider. A
provider can also change its role to requester when it wants to request
content (3) content broadcasting and acquisition in which a provider
broadcasts content and the required download time for the content. and (4)
content transaction in which each completed content sharing transaction is
recorded by the RSU and stored in the Blockchain.

AI and ML technologies can also be employed to enhance and optimize the
delivery of infotainment to vehicles for Blockchain-enabled IoVs. For example
cognitive engines can be employed to intelligently perceive content
requirements of users, match them with content providers and cache them at
RSUs. Qian et al. [73] proposed a Blockchain-based privacy-aware content
caching architecture that records content sharing transactions in Blockchain.
They also designed a cognitive engine for their proposal that utilizes ML to
perceive content requirements and store them in RSUs ahead of time. Similarly,
Dai et al. [72] proposed a Blockchain-empowered distributed caching framework
where content is cached in participating vehicles. Base stations serve to pair
caching requesters to caching providers and use AI to predict V2V transmission
ranges and connection duration between content requesters and providers.

###  3.7 Summary Remarks

In this section, several BIoV applications have been discussed in details.
Blockchain is a promising solution to solving many of the problems security of
V2V communications in energy trading, crowdsourcing, traffic congestion and
collision avoidance, vehicle platooning and infotainment applications. Trust
management systems that utilize Blockchain are a promising solution to solving
issues related to the security and privacy of vehicles when sharing traffic-
congestion information. The reputation of vehicles sending accurate traffic
information can be stored in Blockchain and used to limit the possibility of
vehicles sending false traffic information and such systems can be
supplemented with incentive mechanisms to encourage the sharing of traffic
information. Future work needs to be done to solve the issues of privacy
leakage and selecting the most efficient consensus mechanism that is both
capable of handling the dynamic nature of the road and ensuring scalability of
the IoVs.

Using Blockchain and smart contracts can be utilized to aid vehicles to
securely coordinate their positions and share information about road hazards.
ML and AI technologies can be harnessed to supplement the system, giving
vehicles access to collective learning of all vehicles to help them make more
intelligent decisions with regard to lane changing decisions. One of the main
issues is scalability and performance issues of using Blockchain technology in
the case of dynamic wireless charging of EVS. As we discussed, dynamic
wireless of EVs enables the exchange of power between a mobile EV and the
electricity grid via a set of charging pads (CPs) deployed along the road.
Using Blockchain can be used to provide secure dynamic wireless charging of
EVs, however because of scalability and performance issues of current
Blockchains, there is more research is required to provide scalable and fast
charging using Blockchain.

##  4 Federated Learning for BIoV

Federated Learning (FL) is a distributed machine learning (DML) approach that
has garnered recent increased interest due to ability to learn from data
without sharing the data. However, some challenges for FL include defending
against poisoning and member inference attacks and centralization and loyalty
issues. In response to these challenges, there have been a number of proposals
to enhance traditional FL with Blockchain.

In this section, we first distributed learning followed by an an overview of
FL. Then, we discuss challenges with existing FL approaches, how blockchains
can resolve these challenges, and existing blockchain-based FL for IoV
applications. Finally, we summarize of the applications of Blockchain in FL
for vehicular networks and some of the existing challenges in these
approaches.

###  4.1 Overview of Distributed Learning & Federated Learning

In traditional ML, a single computer or central server trains using locally
stored data [134, 135, 136, 137, 138, 139, 140]. This approach lacks
scalability, consumes more time and is not feasible for big and distributed
data applications that require real-time decisions [135, 141]. Scalability is
the ability to manage increases in computation load or in the number of users
[137]. If the ML training data gets too large, it may exceed the memory and
computational resources of the central server [141]. A good training model
requires a great deal of training data. Failure to obtain a sufficient amount
of training data could result in an inaccurate global model.

In response to these limitations, DML was developed, where learning models can
be trained on subsets of data distributed across several nodes [141, 136]. The
primary motivation behind DML arises from the need to share resources, such as
the computing abilities of multiple computers [137] and the distributed nature
on current networking applications. The advantages for training across
multiple nodes include greater scalability and efficiency. Parallel execution
of learning tasks across multiple nodes leads to reduced training time. DML
provides a higher degree of availability, which is the measure of the
proportion of time a system is available for use[137]. The distributed nature
of the nodes solves problems associated with running out of computing, storage
and memory resources on a central server.

Despite the many advantages DML provides, it still suffers from issues in
heterogeneity, security, and failure handling and it needs improvements to its
scalability [137]. DML suffers from heterogeneity: A DML may find it difficult
to train across multiple diverse nodes each with differing memory, storage and
computation abilities and resources [137]. Security and privacy issues arise
when vehicles transmit raw data collected from their sensors [142]. For
example, raw data may contain private information such as the location or
destination of a vehicle. DML also suffers from failure handling, requiring
measures to manage situations when one node fails [137].

In response to above concerns, researchers at Google Inc. [143] proposed and
developed FL as a new approach to DML. FL involves training distributed local
models on local devices or vehicles (referred to as clients or participants)
in a federated fashion [143]. FL consists of three primary phases:
initialization, aggregation, and update. Based on general descriptions in the
literature, we created an illustration of traditional FL framework shown in
Figure 8. During initialization, FL participants download a global model from
a central aggregator. Each participant uses this global model as the basis for
training their own new local model using locally collected data. When finished
training their local model, the participants upload a local model update to
the central aggregator which is responsible for aggregating the local models
of all participants to form a new global model. Only the local model update
are transmitted. The training data itself remains with the participant. After
aggregation, the participants download and begin training on the new model.
This process repeats for multiple iterations until the global model reaches a
preset accuracy or optimal convergence.

The primary difference between FL and DML is that DML focuses on harnessing
parallel computation while FL concerns training models locally on each client
[144]. DML assumes that datasets are distributed in identical sizes across all
nodes. In FL, however, the size of the datasets for each node can be
heterogeneous or of differing sizes [145]. FL offers greater privacy than the
traditional ML on a central server. Participants train locally using their own
collected data. FL provides greater privacy by only requiring participants
share local model updates with the central server rather than raw data [142].
Due to the advanced privacy offered by the FL approach, many researchers have
adopted FL for applications such as healthcare data [146, 147], medicine
[148], smart city sensing [149], smartphone next-word prediction [150], and
improving Google keyboard suggestions [151].

Figure 8: Traditional Federated Learning Framework

###  4.2 Challenges for Traditional Federated Learning

Despite the privacy enhancements FL offers, FL suffers from challenges such as
centralization, loyalty, vulnerability to single-point-of-failure (SPOF),
poisoning and membership inference attacks, and communication efficiency [152,
153, 154, 155, 156, 157, 158, 159, 160, 161, 162]. Table V provides a summary
of these challenges and discussed in details as follows.

  * •

Centralization Issues. This problem exists because FL relies on a central
server to aggregate local model, i.e., the aggregator [152]. If the aggregator
malfunctions or is compromised e.g., by a SPOF attack, the entire FL system
could fail. A single-point-of-failure attack is an attack designed to take
down any network element, such as a central server in FL, that would cause the
entire network to fail.

  * •

Lack of loyalty mechanism. Traditional FL also lacks a loyalty mechanism for
encouraging participants to share their local learning models. Some works,
such as [153], have suggested using a contract theory approach to design an
incentive mechanism to encourage participants to participate in FL. Also, the
authors of [154] utilize a trading market process to stimulate the sharing of
learning models.

  * •

Poisoning Attack. This attack occurs when a participant submits false or low-
quality model updates that "poison" the FL model, which can result in a less
accurate global model or cause the global model to outright fail [155].

  * •

Membership inference attack. This attack occurs when an adversary utilizes
reverse engineering techniques to gain access to a participant’s local model
updates from the central server and uses this information to steal the local
dataset of the participant [156, 155].

  * •

Communication efficiency. Communication remains a critical bottleneck in FL
networks [158]. The vast number of devices or vehicles on an FL network
combined with their limited resources such as bandwidth, energy, and power can
slow down communication across the FL network. For example, vehicles with
greater computation resources would still have to wait on those with less
resources. To address this challenge, many researchers have focused on
reducing the number of communication rounds [143, 163] or decreasing the
transmission payload size [162, 164, 165, 166]. According to [161], these
approaches assume a noise-free communication scenario and focus primarily on
ML design that trades off computation and communication. More recent works
focus on communication system design in lieu of ML design [159, 160, 161]. For
example, Wei and Shen [161] investigated how to improve communication
performance when communication occurs over noisy channels or those that
contain communication errors.

TABLE V: Challenges for Traditional FL

Challenge |  Description
---|---
SPOF attack (centralization) |  FL relies too heavily on central server. Any attack on central server may cause entire network to fail.
Lack of loyalty mechanism |  FL lacks loyalty mechanism to encourage participants to share their local models.
Poisoning attacks |  Participant submits false or low-quality model updates that "poison" FL model. Can result in a less accurate global model or cause the global model to fail
Membership inference attack |  Adversary gains access to a participant’s local model updates from central server and uses this information to steal the local dataset of the participant
Communication efficiency |  Large number of devices or vehicles on FL network combined with their limited resources such as bandwidth, energy, and power can slow down communication across FL network

###  4.3 Federated Learning in IoV Enhanced by Blockchain

Blockchain’s distributed and decentralized features have the potential to
solve the challenges of traditional FL. For example, replacing traditional
FL’s central server with Blockchain solves the centralization problem and
protects against SPOF attacks. Verification Procedures can be implemented into
Blockchain aggregation to help protect against data poisoning attacks. To
solve problems with loyalty, procedures can be implemented into Blockchain
such as providing rewards for vehicles or miners for supplying good model
updates.

Figure 9 illustrates a general implementation of Blockchain in FL for
vehicular networks. A task publisher supplies a FL task, an initial global
model, and a testing dataset to the blockchain system. Participant vehicles
download the global model from the blockchain system and use it as a basis for
training a local model using its own local dataset. After training its local
model, a participant vehicle adds its local model update to the blockchain.
Some frameworks such as [152] also utilize miners to collect local model
updates and add them to Blockchain. Then either using a central aggregator
that is a blockchain node or within the blockchain process, a node retrieves
the local model update and aggregates all local models to form a new global
model. After aggregation, the vehicle participants download the new global
model and the process repeats for multiple iterations until the global model
reaches a preset accuracy or optimal convergence.

Figure 9: Typical Blockchain-Enabled Federated Learning Framework for
Vehicular Networks

####  4.3.1 Blockchain-Based FL for Autonomous Vehicles

In [152], authors propose a Blockchain-based FL system for autonomous vehicles
(AVs). The framework is composed of miners and AVs. Miners could be nodes on
the network edges such as cellular base stations or AVs with high computing
capabilities for the mining process. The authors use Blockchain in lieu of a
central server to solve the centralization problem and develop a loyalty
mechanism to reward AVs for providing good learning model updates. The reward
amount is based on the usefulness of the data sample sizes. The framework also
rewards miners who win the mining race. The mining reward is based in the
miner’s mining power, which is calculated by the number of useful data samples
they collect from AVs.

Under the authors framework, AV’s obtain latest global model from Blockchain.
Based on this model, AVs perform local learning and send a local model updates
to a nearby miner. Since each AV maintains their best ML model, they are
capable of making intelligent decisions even when they lose connectivity. All
miners verify the local model updates, execute proof-of-work (PoW) and then
generate a block to record the validated local model updates. The aggregation
of the local models is added to this block as a new transaction. To address
the additional delays associated with Blockchain management, the authors
conducted an accumulated end-to-end delay analysis that took into
consideration PoW, communication delays and computation delays. Authors used
this analysis to minimize the overall delay of the system by dynamically
adjusting block arrival rate.

####  4.3.2 Blockchain-Based FL for Vehicular Networks Enhanced by Model
Update Verification & Local Differential Policy

In [156], the authors proposed a secure FL framework that takes advantage of
the capabilities of Blockchain smart contracts to protect a 5G Network FL
framework from poisoning attacks. The authors supplement their framework with
local differential privacy (LDP) technologies that add Gaussian noise to a
participants local model updates to protect a participant from membership
inference attacks [167][168]. The authors in [155] borrowed this approach to
implement a privacy-preserving Blockchain-based FL for traffic flow
prediction.

To develop their privacy-preserving Blockchain-based FL for traffic flow
prediction, the authors in [155] utilized consortium Blockchain in lieu of a
central server in FL to protect against SPOF attacks. They also utilized a
modified version of dBFT as a consensus algorithm. The dBFT consensus
algorithm is similar to PBFT except that it allows for the flexible changing
of miners rather than requiring a fixed miner group. The authors supplemented
dBFT with mechanisms to protect against security attacks. For example, they
added model update verification to ensure only qualified model updates from
participant vehicles are aggregated by the aggregator. In model update
verification, each miner RSU uses a testing dataset provided by the task
publisher to judge whether a local model update is qualified for aggregation.
Only qualified local updates with than a given threshold (set by the task
publisher) are presented for aggregation. This process helps the system defend
against poisoning attacks that would taint the global model during
aggregation. Inspired by [156], the authors in [155] also use LDP to protect
the vehicle participants from membership inference attacks. When a participant
vehicle uploads a model update, Gaussian noise is added to disturb the
location information of the participant.

####  4.3.3 Blockchain-Based Galaxy Federated Learning for Vehicular Networks

In [169], the authors propose a Blockchain-based FL framework called Galaxy
Federated Learning (GFL). GFL’s storage system is composed of two parts: (1)
Ethereum Blockchain and (2) InterPlanetary File System (IPFS). Ethereum is a
decentralized open source Blockchain first conceived by Vitalik Buterin [170]
with built-in smart contract capabilities [171]. IPFS is a decentralized P2P
file storage system based on Blockchain [172].

GFL utilizes an innovative algorithm designed by the authors called Ring
decentralized FL algorithm (RDFL) [169]. RDFL uses Ring-allreduce algorithm in
distributed ML, consistent hash algorithm, and knowledge distillation. When
training across multiple nodes, each node would normally have to wait for all
other nodes to finish their training during each training iteration. The Ring-
allreduce algorithm solves this communication efficiency problem by arranging
all nodes in a circle or ring where each node receives data from its left
neighbor and transmits data to its right neighbor [173]. During the scatter-
reduce step, nodes exchange data so that every node on the ring receives a
chunk of the final result. During the allgather step, the nodes exchange those
chunks so that all nodes receive the final result. GFL’s RDFL uses a
customized version of this algorithm, which is described in more detail below.
Knowledge distillation involves compressing a large model into a smaller,
distilled model [174]. Distilling the dataset greatly reduces the amount of
data that needs to be transmitted, improving overall communication efficiency
and reducing communication pressure. GFL also uses an encryption mechanism to
improve transmission efficiency and ensure the security of the transmitted
information. GFL uses both asymmetric encryption and symmetric encryption to
encrypt every piece of information in Blockchain.

RDFL makes full use of a networks bandwidth and improves GFL’s security and
robustness under malicious node attacks. Under RDFL, after each node completes
local training, each untrusted node, according to the consistent hash
algorithm, sends its model parameters to the first trusted node in a clockwise
fashion. By using the consistent hash algorithm, RDFL transfers model
parameters of untrusted nodes to different trusted nodes, which reduces
communication pressure. Also, each trusted node uses Ring-allreduce algorithm
(modified for RDFL) to pass model parameters to the next trusted node in a
clockwise fashion. This process repeats until eventually all nodes have the
model parameters of all nodes and all nodes reaches a stable state. Ring-
allreduce helps maximize bandwidth utilization for model parameters between
nodes. After all nodes reach a stable state, RDFL uses knowledge distillation
to transfer knowledge (contained in the model parameters) to its locally
trained model parameters.

Using IPFS also helps GFL reduce communication pressure since IPFS transmits a
46-byte IPFS hash of the model parameters in lieu of sending the actual model
parameters. RDFL uses model parameter synchronization, which reduces
communication congestion. RDFL also provides better bandwidth, which helps
solve the communication efficiency problem. To solve the model security
problem, RDFL reduces the influence of malicious nodes by not allowing
untrusted nodes to access model parameters from other nodes. In addition, RDFL
encrypts IPFS hash of model parameters to avoid exposure on Blockchain and
protect information security. Lastly, GFL solves the aggregation performance
problem by using knowledge distillation and dynamic polarization ratio to
improve generalization of model while ensuring safety of the model. According
to the authors, knowledge distillation has greater accuracy than FedAvg as an
aggregation method for non-IID data.

####  4.3.4 Hybrid Blockchain Framework with Asynchronous FL for Vehicular
Networks

In [175], authors propose a hybrid Blockchain framework with asynchronous FL
that addresses challenges such as the computing efficiency, shared data
reliability, delays associated with FL, and heterogeneity. Due to the
heterogeneous communication and computing capabilities of vehicles
participating in FL, there may be different learning rates for each and this
slows down the learning iteration to the speed of the slowest participant
vehicle. By making the system asynchronous, authors’ framework resolves this
heterogeneity problem by not requiring the system to wait on the slowest
participant.

To enhance data security, training efficiency, and accuracy, the authors
design a hybrid Blockchain mechanism called PermiDAG. PermiDAG is composed of
two hybrid components: (1) Main permissioned Blockchain and (2) local Directed
Acyclic Graph (DAG). DAG is a directed graph data structure that uses
topological order and has been used to improve the efficiency and scalability
of traditional Blockchain such as in IoT [176] and 5G beyond networks [177].
DAG also uses a more efficient cumulative PoW in lieu of traditional PoW.

In PermiDAG, RSUs maintain main permissioned Blockchain while vehicles share
data using DAG. Main permissioned Blockchain is responsible for global
aggregation while local DAG is responsible for asynchronous local training.
Under PermiDAG, vehicles train their local models based on the global model
retrieved from main Blockchain. They also retrieve verified local models from
other vehicles from local DAG. They execute local aggregation to improve their
own local model and then add that model to local DAG. After several iterations
of local training and aggregation, delegate RSUs collect the current local
models from local DAG and perform global aggregation. The global model is then
broadcasted to all delegates. All global models are collected into a block by
a rotating delegate leader and the candidate block is appended to the
permissioned Blockchain after verification.

####  4.3.5 Hierarchical Blockchain-Enabled FL for Knowledge Sharing in IoV

In [154], authors propose a hierarchical Blockchain framework for IoV which
utilizes their proposed hierarchical FL algorithm for knowledge sharing.
Knowledge sharing [178] involves vehicles learning environmental data through
ML methods and sharing that learned knowledge with each other [154]. The
authors design their framework to be hierarchical by performing consensus at
Ground Chains and a Top Chain level. For each region, RSUs perform consensus
for vehicle learning models. At the Top Chain level, base stations perform
consensus for the models from each region. According to the authors, this
multi-model approach is more feasible for knowledge sharing in large scale
vehicular networks. Using a hierarchical approach, authors’ framework can more
easily manage vehicular networks composed of multiple regions and where each
region has its own varying local characteristics.

The authors’ work is primarily focused on addressing the two primary problems
of implementing knowledge sharing in vehicular networks: (1) ensuring the
security and reliability of knowledge shared during the sharing process (i.e.,
prevent poisoning attacks) and (2) privacy issues involved in storing
aggregated knowledge in the central server (i.e., centralization issue and
SPOF attacks). Authors framework also addresses loyalty challenge by utilizing
a trading market process that stimulates the sharing of learning models.

To address security and reliability in knowledge sharing, the authors enhance
FL with Blockchain. They propose a Proof-of-Knowledge (PoK) consensus
mechanism that is light-weight and more efficient than traditional PoW. PoK
combines machine learning (ML) with Blockchain consensus by replacing the hash
puzzle of PoW with a ML process. Unlike PoW, which selects the fastest solver
of the hash puzzle to propose a new block, PoK is designed to select the best
solver that achieved the most accurate ML result. During Ground Chain
consensus, RSUs verify the training accuracy of vehicles using a test set. To
address the centralization issue and protect against SPOF attacks, the authors
replace the central server of FL with Blockchain.

###  4.4 Summary Remarks

This section discussed a new line of work that combines AI and blockchain for
IoV. Specifically, we discussed blockchain-based FL for IoV. We first
presented an overview of FL, their challenges, and how blockchain can be used
to solve these challenges. Then, we discussed recent studies that had build FL
for BIoV, along with thier approaches and major differences. Table VI outlines
the various approaches to enhancing traditional FL for vehicular networks with
Blockchain and how such approaches address issues such as poisoning,
membership inference and SPOF attacks. It describes how each approach
addresses issues related to loyalty and communication efficiency.

It should be noted that Blockchain-based FL for IoV is a recent trend that has
gone out in the last two years. Thus, there exist several challenges with
these techniques and several associated future direction. We will discuss
those briefly in section 5.2

TABLE VI: Blockchain-Enhanced Federated Learning Applications for Vehicular Networks |  Consensus |  Poisoning Attacks |  Membership Inference Attacks |  SPOF Attacks |  Incentive Mechanism |  Communication Efficiency
---|---|---|---|---|---|---
[152] | PoW | ✗ | ✗ |  Use Blockchain in lieu of central server to protect against SPOF attacks |  Loyalty mechanism that rewards AVs for providing good learning model updates. Reward amount based on usefulness of the data & sample sizes. |  To address delays associated with Blockchain management, authors conducted accumulated end-to-end delay analysis taking into account PoW, communication delays, and computation delays. Used this analysis to minimize overall delay of system by dynamically adjusting block arrival rate.
[155] | dBFT |  Model update verification mechanism in consensus to ensure only qualified model updates are aggregated |  LDP adds Gaussian noise to participant local model updates to protect against membership inference attacks |  Use consortium Blockchain in lieu of central server to protect against SPOF attacks | ✗ | ✗
[169] | RDFL |  RDFL reduces influence of malicious nodes by not allowing untrusted nodes to access model parameters from other nodes |  Use encryption mechanism to ensure security of transmitted information |  Use Ethereum Blockchain in lieu of central server to protect against SPOF attacks | ✗ |  Encryption mechanism helps improve transmission efficiency. IPFS & RDFL consistent hash algorithm help reduce communication pressure Ring-allreduce algorithm helps maximize bandwidth utilization for model parameters between nodes.
[175] |  Hybrid: modified DPoS & PermiDAG | ✗ | ✗ |  Use permissioned Blockchain in lieu of central server to protect against SPOF attacks | ✗ |  Asynchronous system resolves problem of having to wait on slowest participant.
[154] | PoK |  During consensus, RSUs verify training accuracy of vehicles using a test set | ✗ |  Use Blockchain in lieu of central server to protect against SPOF attacks |  Trading market process used to stimulate sharing | ✗

##  5 Challenges and Future Opportunities in BIoV

In this section, we discuss the challenges and future opportunities in BIoV.
In Section 5.1, key issues in BIoV are highlighted. In Section 5.2, we review
challenges and opportunities in integrating FL for BIoV.

###  5.1 BIoV-specific Challenges and Opportunities

BIoV offers security and mitigates data manipulations due to data immutability
brought by Blockchain. However, due to openness nature of the Blockchain, it
cannot directly guarantee several issues such as security, trust, and privacy
explained as follows.

Ensuring Trust among entities in IoVs. Trust and privacy is major issue in IoV
as it is hard to believe any entity in IoVs due to the possibility of
malicious behavior as well as to keep one’s private identity during
communicating with other vehicles. The limitations of the centralized trust
management system can be solved through distributed approach using Blockchain
but there still major concerns regarding the trust, privacy and scalability in
operation among the participants in our vehicular network system. Authors in
[26] propose a conditional privacy preserving announcement scheme integrated
with Blockchain to solve these problems where proof of work and PBFT are used
to make the consensus to reduce the cost. Another work by [25], that proposes
to check the validity of the messages using Bayesian Interference model and
each vehicle with the source message is given a rating by the message
receiver. Based on the rating provided by vehicles, RSU calculate trust and
make a block using those data and then RSUs add their blocks in the Blockchain
where both PoW and PoS are used. However, privacy is not well addressed which
mitigates vehicles from sharing their information.

Security and Privacy in BIoV. All the vehicles connected in IoV, share
enormous amount of data for communication and making decision. For this, it is
really important to provide security and privacy to these shared data which
can be achieved through Blockchain. Due to openness of public Blockchain, it
is hard to achieve this privacy. Vehicular social network (VSN) [179] is also
a part of IoV where a lot of small IoT devices are connected so it is
important to make the encryption scheme for lightweight for reducing
communication overhead [180] as well as introduce better consensus algorithm
for consortium Blockchain [181]. Privacy can also be compromised when any of
the transaction made though BTC, link certain identities to their pseudonyms
that is known as linking problem. To solve the problems related to bitcoin
another kind of cryptocurrency Altcoin is introduced. It can provide firm
privacy with its advanced security features that need to be focused in future
[182]. Recently, Intel software guard extension (SGX) has been integrated with
the Blockchain based IoV to solve the existing limitations related to security
and privacy. But the consensus algorithm used in SGX such as PoET [35] suffer
from stale of chip problem which eventually creates centralization of rights
that need to be solved for better performance [183].

Edge Computing for BIoV challenges and Opportunities. Fog/edge computing is
also required for computing the data in IoV where it is required to keep the
data integrity which can be improved by a proper combination of Blockchain, AI
and ML [184, 185, 186]. In IoV, dynamic access control is required in
decentralized system, but it costs high energy consumption as well as at the
same time it is needed to provide a secured and trusted environment. For
solving this problem, authors [187], propose to leverage Fog/Edge computing to
ensure scalability with energy efficiency and use the edge nodes (RSU) as the
mediator between the sensor nodes (vehicles or end devices) and edge
computing. In this system, ledger entity (RSU) hosts the Blockchain and with
the help of trusted node it will update the trust value for the to be trusted
node (TBTN). This model has only focused on the trust for the entities not the
messages they share as well as it also suffers from privacy problem and prone
to false praise attacks.

###  5.2 FL for BIoV Challenges and Opportunities

Despite the many benefits provided by Blockchain-enabled FL implementations
for IoV, these implementations still suffer from several challenges [188].
Table VII summarizes these challenges and it is discussed as follows.

Forking. Forking happens because of network delays, a vehicle may not always
have the most recent block and consequently create a different chain that
branches or "forks" from the main one [152]. Forking reduces throughput since
only a single chain survives. Forking creates a situation where some vehicles
may utilize wrong global update in the next iteration of local model update.
The work on [152] analyzed forking issues and its impact on FL on BIoV. Based
on the analysis results, the forking depends on two factors; block arrival
rate and block propagation delay. The work also developed a mathematical model
have been developed to to capture the FL parameters such as the retransmission
limit, block arrival rate, block size and the frame sizes so as to capture
their impact on the system-level performance.

Aggregation node selection. The process of uploading and downloading model
updates to FL could take a lot of time especially in complex models with many
model parameters. Thus, the selection of the node responsible for aggregation
and impact of that selection should been discussed. The work in [169] uses the
amount of data as the indicator for the selection of aggregation nodes in FL.
However, other factors such as the number of computing resources of the data
provider, current power, network conditions and other factors could also be
used to improve the selection of aggregation nodes. Future research work could
use methods such as model quantization and model distillation to compress
model parameters to improve FL speed and efficiency.

Uncooperative Vehicle Training. This challenge happens because of some
vehicles are not willing to cooperate in the training phases in the FL.
Vehicles need to cooperate to build a high-quality global model and at the
same time take into consideration communication resource allocation. The
authors in [189] address this issue in the realm of mobile devices and MEC.
They propose a cooperative FL framework for the MEC system which they call
CFLMEC, where devices transmit local models in a relay fashion with the goal
of maximizing the admission of data at the edge server or nearby device. A
similar framework could be incorporated into a Blockchain-based FL framework
in vehicular networks to solve the uncooperative training strategy challenge.
Another approach is exploring reputation and incentives systems to motivate
all vehicles to to cooperate in the training phases in the FL. However, using
reputation systems requires real identity of vehicles and this leads to
another serious problem because vehicles will be reluctant to cooperate in the
training phases because of private information may be revealed because of
adversarial attacks such as model inversion attacks [190, 191] and membership
inference attacks [192, 193].

TABLE VII: Summary for FL challenges in BIoV Challenge | Description
---|---
Forking |  Vehicle fails to receive most recent block due to network delay and consequently creates a different chain that "forks" from the main one.
Aggregation Node Selection |  Insufficient factors used for selecting nodes for aggregation.
Uncooperative Vehicle Training |  Vehicles use an uncooperative training strategy.
Communication and computation Efficiency |  Using iterative optimization techniques, which require many rounds of communication between local devices (e.g., vehicles) and the central serve.r
Security & Privacy |  Vehicles are reluctant to share models results because of cyberattacks such as eavesdropping and spoofing attacks.

Communication and computation Efficiency. Current FL methods involve training
models using iterative optimization techniques, which require many rounds of
communication between local devices (e.g., vehicles) and the central server.
This tends to lead to bottleneck issues and increased communication costs. To
address this issue, the authors in [194] proposed a one-shot FL approach,
where the initial global model can be learned from data on the network in only
one round of communication between devices and the central server. Zhou et al.
[195] proposed distilled one-shot FL (DOSFL), which combines the ideas behind
data distillation [196] and one-shot FL. Data distillation involves
compressing a large dataset with thousands of images into a few synthetic
training images[196]. Realizing that using this compression method could help
reduce communication cost in FL, Zhou et al. [195] apply distillation to one-
shot FL. Under DOSFL, Each device distills their private dataset and uploads
synthetic data to the central server instead of sending bulky ML gradients or
weights. The central server then interweaves the distilled data together and
uses it to train the global model. A similar approach could also be applied to
Blockchain-based FL for vehicular networks.

Security and Privacy of FL for BIoV. Vehicles needs to exchange information
during the FL training. Sharing this data shall be secure against different
types of security and privacy-leakage attacks. The work in [195] designed
their FL to be secure against eavesdropping attacks since an eavesdropper
cannot reproduce the global model with leaked distilled data without knowing
the exact initial weights distributed by the server. However, there may still
exist security risks from other attacks such as data poisoning attacks. Future
work could explore the potential attacks resulted from using Blockchain to
secure FL frameworks against such attacks. Privacy techniques have been
proposed to aggregate the model updates, however, an untrusted aggregator can
maliciously modify the aggregated result to produce a biased FL model.

###  5.3 Performance Issues

Performance is major issue when using Blockchain to secure IoV. Performance
can be due to several issues explained as follows.

Scalability. Blockchain solves the limitations existed in centralized IoV
system though it lags behind due to its poor performance when the number of
vehicles and Blockchain nodes increases significantly [104, 105]. Factors that
affect scalability includes but not limited to block size, number of
transactions, total amount of connected nodes and consensus protocols used
[106]. Blocks with huge data packets cost much storage which leads a poor
scalable system [107]. Due to high volume of data, it also results processing
delay and communication delay which eventually degrade the performance of BIoV
as most of the devices connected are resource constrained [109]. In BIoV,
vehicles have to make transactions which need to be verified and synchronized
such as in Ethereum it is required to validate each transaction part by part
which causes slow speed and scalability challenges in the whole system [110,
111, 62]. Some works have discussed using zero-knowledge proves (ZKP) to solve
security and privacy issues in BIoV. However, zero-knowledge proof (ZKP) can
lead to computation intensity and Scalability issues due to its multiple round
verification and limited throughput [197, 198, 9]. With the increasing of
number connected vehicles in BIoV, latency is also incremented because of more
computational requirement and affects throughput in BIoV [199, 200]. Thus,
there are few recent protocols to address Scalability issues in BIoV but it
lead to an increase in latency at the expense of high scalability [201].

Developing efficient consensus algorithms tailored for BIoV is an open issue
that can lead to improved Scalability. Delegated byzantine fault tolerance
(dBFT) [42] was first proposed by Da Hongfei and Erik Zhang for use in their
NEO Blockchain cryptocurrency framework. The dBFT determines validators based
on real-time Blockchain voting. This arrangement provides enhanced efficiency
such as faster block time and transaction confirmation. Participant holders of
a NEO token vote on a bookkeeper. The elected bookkeepers utilize BFT to reach
consensus and generate new blocks. dBFT has been employed by authors such as
[155] for Blockchain-based vehicular networks. Based on the discussion it is
tangible that throughput and latency ate the two major factors that put a
significant impact on the quality of experience (QoE) in BIoV that should be
improved in future research [202, 203]. The work in [204] uses the shard
Blockchain to reduce work loads in main Blockchain and smart contracts to make
it more feasible. The main idea is that RSUs are responsible for maintaining
and updating the trust of vehicles where proof of work consensus mechanism is
used. Both permissioned and permission less Blockchain is integrated in this
model for the main and shard Blockchain respectively. Though this model can
improve scalability, it is not fully decentralized as some operations are
controlled by Traffic Authority.

Computations Overheads. Performance of any BIoV depends on computation
required. Encryption, decryption, and signatures that are required for the
security purposes also require mining nodes with high computation. To utilize
the vacant resources outside of Blockchain network such as cloud/fog computing
by the evolutionary miners (E-miner) who are promoted from traditional miners
(T-miner) with additional abilities for providing extra computing services.

During mining, each vehicle or RSU gets reward but in PoW based Blockchain
networks sometimes miner acts as malicious node in incentive mechanism step
which cause a waste of distributed computing resources. Zero-determinant
strategy (ZD strategy) [205] is used to solve this challenge to encourage
cooperative mining [206]. Though it doesn’t take the trust value of the nodes
into consideration which need to be solved in future for secured performance.

Communication Overhead. In IoT a lot of devices are connected, and they
require frequent changes in the provenance data which causes enormous energy
consumption that leads to computation loads, delays, and bandwidth overhead.
With the increasing of the vehicles connected in IoV, energy needs are limited
[207]. That is why Blockchain network fails to provide good performance due to
more energy consumption, execution time and communication overhead that need
to be improved.

A selective compression scheme has been proposed to reduce communication
overheads using a checkpoint-chain that can prevent the accumulation of
compression. Enormous number of blocks can be verified with only a few updated
checkpoints and nodes with limited resources can reduce the storage volume for
the Blockchain ledger and achieve high verification capabilities [208]. A
message passing technology called HPBC has been implemented in a high
performance Blockchain consensus algorithm with byzantine nodes to solve the
resource overhead and long block confirmation delay [209] but it does not
consider privacy for the nodes as well as the malicious activities inside the
nodes which should be studied to make its performance better.

Designing Lightweight BIoV Protocols. Security protocols include but not
limited to user authentication, key management, access control/user access
control, and intrusion prevention/detection. All these BIoV Protocols uses
several cryptosystems that uses heavy algorithms with high communications,
computations and storage overheads. Some of the devices in BIoV such as
sensors are resource-constrained and lacks high communications computation,
and storage capabilities [210, 211]. Also, using Blockchain leads to extra
overheads when it requires such capabilities. Thus, using lightweight
cryptosystems can be helpful and more research is needed to provide
lightweight BIoV Protocols. Another issue is to develop efficient
cryptosystems such as certificateless signcryption [212] which can achieve
data confidentiality and authentication without relying on a trusted third
party to generate certificates. However, these cryptosystems comes with extra
commutation and communication overheads and thus more research is needed to
build lightweight schemes suitable for BIoV environments.

##  6 Future Research Directions in BIoV

This section focuses on a number of future research directions in integrating
Blockchain in AI, hardware security and Quantum computing.

###  6.1 AI

One future direction in the combination of AI and Blockchains is in the field
of explainable and responsible AI. A current challenge in AI systems that
hinder their adaptation in practice is that the decision made by these systems
are untraceable and not explainable to humans. One solution to resolve this
issue is to track the development of data flow and complex behaviors generated
by the system. An example in IoV is the explaining why a model has stated that
the traffic is congested. Such explanation can come from tracking data coming
sequentially from different roads in the system. However, providing a
traceable and transparent system that can provide such tracking without
breaking user privacy is challenging. Blockchains can be used to perform such
tasks by tracking every turn in the data-processing or decision-making chain.
Such tracking can understand and increase confidence in AI decisions.
Furthermore, tracking can be used by humans to trace back the decision process
and justify decisions based on prior history or development. Lastly, tracking
can provide insights into tuning AI systems to balance models'accuracy with
their explainabilities. Of course, data and model privacy concerns would rise
here, and so we do expect this direction to be directed toward applications
that require only user privacy.

Another direction is to use AI to design lightweight BIoV protocols. As
discussed in Section. 5.3, performance issues in BIoV is a major issue that
need to be addressed to develop scalable and efficient BIoV. The intelligence
from AI can help resolve these challenges by optimizing communication and
computation overhead and providing the required scalable and efficient BIoV .

In addition, while the integration of AI and Blockchains has many promises, it
comes with many challenges and open issues that have been discussed in section
5.2. Solving these challenges is a future direction to guarantee the success
of Blockchain-based AI solutions. First and foremost, as Blockchains support
transparency, the data stored in Blockchains is open and can be accessed by
other nodes. This enforces AI data or model privacy concerns, especially if
the data or model contain sensitive information. Note that the challenge here
is data privacy, or model privacy in the case of FL, rather than user privacy.
As discussed before, user privacy can be solved with the use of Blockchains.
Solutions to data or model privacy can use private Blockchains to resolve this
challenge. However, these solutions come with the limitations of providing
heterogeneous environments, sometimes necessary for IoV. While the work in
[156] and [155] have proposed privacy-preserving Blockchain solutions, these
solutions are still insufficient and at an early stage. Thus, a future
direction should focus on Blockchain and AI integration while keeping the AI
data or model private.

Another active research direction is the use of AI for Blockchains, i.e.,
building intelligent self-generated contracts, designing better AI-based
mining techniques, and detecting malicious behavior and threats in Blockchains
using AI techniques. This specific direction is a more general blockchain
systems future direction and not specific to BIoV. However, we believe that
such direction will revolutionize Blockchains and so it is important to be
mentioned as a future direction.

###  6.2 Hardware Security

The IoV relies on embedded hardware, real-time sensors, ECUs, and printed
circuit board (PCB), etc. to communicate critical information using the
internet efficiently. The modern supply chain allows for the IoV embedded
hardware to be designed, fabricated, assembled, and tested at different
locations across the globe involving multiple untrusted parties, making the
designed intellectual propriety (IP) inherently insecure. When the
intellectual property (IP) of the IoV embedded hardware is not entirely secure
and trusted, no security solution at a higher level of abstraction can protect
the entire system. In that case, an attacker may utilize a chip level
venerability to access the and retrieve critical information, i.e., the
owner’s personal information, vehicle data, route map, etc., or harm/steal
this information. Therefore, the protection of the IoV embedded hardware
against the evolving hardware attacks is becoming crucial.

At the hardware level, our future direction aims to cover novel security
approaches that integrate Physical Unalienable Functions (PUFs) and the state
of the art topic in hardware-based security with the Blockchain technology for
secure, trusted, and reliable BIoV embedded hardware. For example, recent
research proposes Hardware-Assisted Blockchain (PUFchain) for sustainable
simultaneous device and data security in the internet of everything (IoE)
[213]. The framework can be deployed in connected vehicles and autonomous
networks to employee PUF-based hardware security with multiple roles in the
BIoV, including enhanced low-cost authentication, lower latency, and
lightweight low energy consumption. Further, the integration of hardware-based
security will enable trust in IoV application at the hardware level and
countermeasure against physical and embedded systems attacks, reverse
engineering, hardware obfuscation, and hardware counterfeit detection and
prevention.

At the communication level, our future directions aim to integrate novel
hardware security solutions and Blockchain technology to strengthen IoV
Controller Area Network (CAN) security. Such secure solutions will ensure the
authenticity and reliability of the messages sent over the IoV network and
processes by CAN-based bus architecture [214, 215]. In this regard, hardware-
based security is helpful for key generation and message authentication,
including obtaining a robust, unique, and reliable hardware-based shared key
between ECUs, allowing all message paths to be securely encrypted.
Additionally, hardware security enable obtaining true random number generation
(TRNGs) used for robust a hash-based message authentication code (HMAC) system
with a counter to help protect the BIoV system against replay attacks and
message tampering attempts.

A hardware-assisted security technique proposed as a delay-based plug-in-
monitor for intrusion detection in IoV controller area network (CAN) topology
[216]. The proposed intrusion detection method prototype can be implemented
efficiently on re-configurable platforms, Filed Programmable gate Arrays
(FPGAs), and embedded micro-controllers that are part of the CAN bus shields.
Such a hardware-based BIoV scheme protects the integrity of the messages on
CAN buses leading to a further improve the security and safety of autonomous
vehicles. This future direction will address the delay-based hardware-assisted
security techniques against malicious hardware modifications, including remote
hardware Trojan (RATs) and fault injection attacks, stressing the need to
protect BIoV against such emerging hardware attacks.

###  6.3 Quantum Computing Attacks

Quantum computing is a field that is based on quantum theory which explains
the nature and behavior of energy and matter on the quantum (atomic and
subatomic) level. Quantum computers get their unique power through the ability
for bits to be in multiple states at one time, where tasks can be performed
using a combination of 1’s, 0’s and both a 1 and 0 simultaneously [217]. The
work in [218, 219] discussed how quantum computers may attack proof-of-stake
blockchains. The work has showed that PoW is safer than proof of stake because
hash functions are less vulnerable quantum computers. The work has showed also
attacks on PoS blockchains using both Grover's algorithm [220] and Shor's
algorithm [221]. The authors demonstrated that quantum computing algorithms
are capable of solving specific problems more efficiently than traditional
computing algorithms. The work has recommended quantum resilient signature
schemes to mitigate them. On the other hand, Blockchain uses one-way
cryptographic hashing to secure transactions. However, quantum computing
algorithms may one day be able to break blockchain’s one-way cryptography.
Thus, Quantum attacks has gained recently active attention from researcher
[222, 223], but BIoV network shall be well designed and be quantum-resistant
to be secure against 51% and byzantine attacks.

##  7 Conclusion

This survey paper presents the recent advances, developments and state-of-the-
art topics of BIoVs networks and their implementations for several life-
critical applications, including crowdsourcing, energy trading, traffic
congestion reduction, collision and accident avoidance, and infotainment and
content cashing. This paper focuses on an in-depth review of federated
learning (FL), future directions of blockchain-enabled hardware security and
trust and next-generation blockchain-based quantum and post-quantum computing,
emerging research areas that, to our knowledge, are not an integral part of
any current survey work in the existing BIoV research domain. For that,
Section 1 introduces and defines the BIoV architecture and applications. Also,
this section identifies the goals and motivations of our current survey paper.
Additionally, the applications, security and privacy challenges of the
existing BIoV schemes are summarized. The limitations of such existing work on
BIoV applications related to the topic of this survey are discussed to depict
the novelty and uniqueness of our survey article. Finally, the contributions
of the current paper are listed in a precise manner in the introduction
section.

Section 2 provides the needed background information on BIoV architectures and
applications. As shown in table I, our survey covers a wide range of
applications related to blockchain-based IoV and surveys a broader range of
emerging blockchain-based IoV articles. In particular, we provide additional
detailed and in-depth discussions on blockchain implementations on many
topics, including AI, machine learning and FL for BIoV. Lastly, our detailed
discussions on challenges and future opportunities offers a good starting
point for researchers to advance the study further. Section 3 presents in-
depth knowledge about the applications of blockchain-based IoVs such as energy
trading, crowdsourcing, vehicle platooning, traffic congestion reduction,
collision and accident avoidance and infotainment and content caching. Section
4 reviews the FL-based implementations for blockchain-based IoVs. This section
discusses the challenges, i.e., security and privacy issues, for traditional
FL and provides the emerging proposed research utilizing blockchain-enabled
frameworks and schemes to overcome these challenges. Section 5 presents the
current challenges for BIoVs followed by a presentation of and the
countermeasures against these challenges and future directions of BIoV 6.

## References

  * [1] K. Shah, S. Chadotra, S. Tanwar, R. Gupta, and N. Kumar, “Blockchain for iov in 6g environment: review solutions and challenges,” _Cluster Computing_ , pp. 1–29, 2022.
  * [2] L. Xu, X. Zhou, Y. Fu, G. Jiang, X. Yu, M. Yu, N. Kumar, and M. Guizani, “Accurate and efficient performance prediction for mobile iov networks using gwo-gr neural network,” _IEEE Internet of Things Journal_ , 2022.
  * [3] S. S. Musa, M. Zennaro, M. Libsie, and E. Pietrosemoli, “Mobility-aware proactive edge caching optimization scheme in information-centric iov networks,” _Sensors_ , vol. 22, no. 4, p. 1387, 2022.
  * [4] Z. Liu, H. Jia, R. Wu, J. Tian, and G. Wang, “Iov-based mathematic model for platoon give way to emergency vehicles promptly,” _IEEE Transactions on Intelligent Transportation Systems_ , 2022.
  * [5] L. Lin and L. Zhang, “Joint optimization of offloading and resource allocation for sdn-enabled iov,” _Wireless Communications and Mobile Computing_ , vol. 2022, 2022.
  * [6] L. Dong, H. Gao, W. Wu, Q. Gong, N. C. Dechasa, and Y. Liu, “Dependence-aware edge intelligent function offloading for 6g-based iov,” _IEEE Transactions on Intelligent Transportation Systems_ , 2022.
  * [7] S. U. Mageswari, C. Mala, and A. S. Vijayan, “A novel coherent architecture for traffic signal management in internet of things,” in _3rd EAI International Conference on Big Data Innovation for Sustainable Cognitive Computing_. Springer, 2022, pp. 37–47.
  * [8] D. S. Gupta, A. Karati, W. Saad, and D. B. Da Costa, “Quantum-defended blockchain-assisted data authentication protocol for internet of vehicles,” _IEEE Transactions on Vehicular Technology_ , 2022.
  * [9] M. M. Badr, M. Baza, S. Abdelfattah, M. Mahmoud, and W. Alasmary, “Blockchain-based ride-sharing system with accurate matching and privacy-preservation,” _2021 International Symposium on Networks, Computers and Communications (ISNCC)_ , pp. 1–8, 2021. [Online]. Available: https://doi.org/10.1109/ISNCC52172.2021.9615661
  * [10] J. Zhang, W. Lou, H. Sun, Q. Su, and W. Li, “Truthful auction mechanisms for resource allocation in the internet of vehicles with public blockchain networks,” _Future Generation Computer Systems_ , 2022.
  * [11] S. Alrubei, E. Ball, and J. Rigelsford, “A secure blockchain platform for supporting ai-enabled iot applications at the edge layer,” _IEEE Access_ , 2022.
  * [12] Y. Lu, Y. Li, X. Tang, B. Cai, H. Wang, L. Liu, S. Wan, and K. Yu, “Stricts: A blockchain-enabled smart emission cap restrictive and carbon permit trading system,” _Applied Energy_ , vol. 313, p. 118787, 2022.
  * [13] M. B. Mollah, J. Zhao, D. Niyato, Y. L. Guan, C. Yuen, S. Sun, K.-Y. Lam, and L. H. Koh, “Blockchain for the internet of vehicles towards intelligent transportation systems: A survey,” _IEEE Internet of Things Journal_ , vol. 8, no. 6, p. 4157–4185, Mar 2021. [Online]. Available: http://dx.doi.org/10.1109/JIOT.2020.3028368
  * [14] M. Dibaei, X. Zheng, Y. Xia, X. Xu, A. Jolfaei, A. K. Bashir, U. Tariq, D. Yu, and A. V. Vasilakos, “Investigating the prospect of leveraging blockchain and machine learning to secure vehicular networks: A survey,” _IEEE Transactions on Intelligent Transportation Systems_ , vol. 23, no. 2, pp. 683–700, 2022. [Online]. Available: https://doi.org/10.1109/TITS.2020.3019101
  * [15] M. Zuhair, P. Bhattacharya, A. Verma, and U. Bodkhe, “Blockchain-enabled secure internet of vehicles: A solution taxonomy, architecture, and future directions,” _Blockchain for Information Security and Privacy_ , pp. 133–153, 2021. [Online]. Available: https://doi.org/10.1201/9781003129486-7
  * [16] E. Karger, M. Jagals, and F. Ahlemann, “Blockchain for smart mobility& literature review and future research agenda,” _Sustainability_ , vol. 13, no. 23, 2021. [Online]. Available: https://doi.org/10.3390/su132313268
  * [17] N. Khoshavi, G. Tristani, and A. Sargolzaei, “Blockchain applications to improve operation and security of transportation systems: A survey,” _Electronics_ , vol. 10, no. 5, 2021. [Online]. Available: https://doi.org/10.3390/electronics10050629
  * [18] T. Alladi, V. Chamola, N. Sahu, V. Venkatesh, A. Goyal, and M. Guizani, “A comprehensive survey on the applications of blockchain for securing vehicular networks,” _arXiv_ , 01 2022. [Online]. Available: https://doi.org/10.48550/arXiv.2201.04803
  * [19] J. Xie, H. Tang, T. Huang, F. R. Yu, R. Xie, J. Liu, and Y. Liu, “A survey of blockchain technology applied to smart cities: Research issues and challenges,” _IEEE Communications Surveys Tutorials_ , vol. 21, no. 3, pp. 2794–2830, 2019. [Online]. Available: https://doi.org/10.1109/COMST.2019.2899617
  * [20] J. Bao, D. He, M. Luo, and K.-K. R. Choo, “A survey of blockchain applications in the energy sector,” _IEEE Systems Journal_ , vol. 15, no. 3, pp. 3370–3381, 2021. [Online]. Available: https://doi.org/10.1109/JSYST.2020.2998791
  * [21] T. A. Butt, R. Iqbal, K. Salah, M. Aloqaily, and Y. Jararweh, “Privacy management in social internet of vehicles: Review, challenges and blockchain based solutions,” _IEEE Access_ , vol. 7, pp. 79 694–79 713, 2019. [Online]. Available: https://doi.org/10.1109/ACCESS.2019.2922236
  * [22] G. Baldini, J. L. Hernández-Ramos, G. Steri, R. Neisse, and I. Nai Fovino, “A review on the application of distributed ledgers in the evolution of road transport,” _IEEE Internet Computing_ , vol. 24, no. 6, pp. 27–36, 2020\. [Online]. Available: https://doi.org/10.1109/MIC.2020.3023295
  * [23] J. Wan, J. Liu, Z. Shao, A. V. Vasilakos, M. Imran, and K. Zhou, “Mobile crowd sensing for traffic prediction in internet of vehicles,” _Sensors_ , vol. 16, no. 1, 2016. [Online]. Available: https://doi.org/10.3390/s16010088
  * [24] F. Sakiz and S. Sen, “A survey of attacks and detection mechanisms on intelligent transportation systems: Vanets and iov,” _Ad Hoc Networks_ , vol. 61, 03 2017.
  * [25] Z. Yang, K. Yang, L. Lei, K. Zheng, and V. C. M. Leung, “Blockchain-based decentralized trust management in vehicular networks,” _IEEE Internet of Things Journal_ , pp. 1–10, 2020.
  * [26] X. Liu, H. Huang, F. Xiao, and Z. Ma, “A blockchain-based trust management with conditional privacy-preserving announcement scheme for vanets,” _IEEE Internet of Things Journal_ , pp. 1–12, 2019.
  * [27] M. N. Mejri, J. Ben-Othman, and M. Hamdi, “Survey on vanet security challenges and possible cryptographic solutions,” _Veh. Commun._ , vol. 1, pp. 53–66, 2014.
  * [28] E. Eze, S.-J. Zhang, E.-J. Liu, and J. Eze, “Advances in vehicular ad-hoc networks (vanets): Challenges and road-map for future development,” _International Journal of Automation and Computing_ , vol. 13, no. 1, pp. 1–18, 01 2016.
  * [29] E.-K. Lee, M. Gerla, G. Pau, U. Lee, and J.-H. Lim, “Internet of vehicles: From intelligent grid to autonomous cars and vehicular fogs,” _International Journal of Distributed Sensor Networks_ , vol. 12, 09 2016\.
  * [30] K. Christidis and M. Devetsikiotis, “Blockchains and smart contracts for the internet of things,” _IEEE Access_ , vol. 4, pp. 2292–2303, 2016.
  * [31] M. Castro and B. Liskov, “Practical byzantine fault tolerance,” _OSDI_ , vol. 99, no. 1999, pp. 173–186, 1999.
  * [32] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” _Decentralized Business Review_ , pp. 1–9, 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf
  * [33] S. King and S. Nadal, “Ppcoin: Peer-to-peer crypto-currency with proof-of-stake,” _self-published paper_ , 2012.
  * [34] G. Wood, “Poa private chains,” _Ethereum Guide_ , 2015. [Online]. Available: https://github.com/ethereum/guide/blob/master/poa.md
  * [35] Intel Corporation, “Poet 1.0 specification,” _Intel_ , 2016. [Online]. Available: https://sawtooth.hyperledger.org/docs/core/releases/1.0/architecture/poet.html
  * [36] D. Larimer, “Dpos consensus algorithm-the missing white paper,” _Bitshare whitepaper_ , 2017. [Online]. Available: https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper
  * [37] D. Ongaro and J. Ousterhout, “In search of an understandable consensus algorithm,” _Proceedings of the 2014 USENIX Conference on USENIX Annual Technical Conference_ , pp. 305–319, Jun. 2014. [Online]. Available: https://www.usenix.org/conference/atc14/technical-sessions/presentation/ongaro
  * [38] L. Lamport, “The part-time parliament,” _ACM Trans. Comput. Syst._ , vol. 16, no. 2, p. 133–169, may 1998. [Online]. Available: https://doi.org/10.1145/279227.279229
  * [39] ——, “Paxos made simple,” _ACM SIGACT News_ , vol. 32, no. 4, 2001. [Online]. Available: https://lamport.azurewebsites.net/pubs/paxos-simple.pdf
  * [40] L. Lamport, R. Shostak, and M. Pease, “The byzantine generals problem,” _ACM Trans. Program. Lang. Syst._ , vol. 4, no. 3, p. 382–401, jul 1982\. [Online]. Available: https://doi.org/10.1145/357172.357176
  * [41] P.-L. Aublin, S. B. Mokhtar, and V. Quéma, “Rbft: Redundant byzantine fault tolerance,” _2013 IEEE 33rd International Conference on Distributed Computing Systems_ , pp. 297–306, 2013. [Online]. Available: https://doi.org/10.1109/ICDCS.2013.53
  * [42] Neo, “Consensus mechanism,” _neo_ , 2014. [Online]. Available: https://docs.neo.org/docs/en-us/basic/consensus/dbft.html
  * [43] EOSIO, “Eos.io technical white paper v2,” _EOS.IO_ , 2018. [Online]. Available: https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md
  * [44] M. P. Herlihy and J. M. Wing, “Axioms for concurrent objects,” _Proceedings of the 14th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages_ , p. 13–26, 1987. [Online]. Available: https://doi.org/10.1145/41625.41627
  * [45] M. Castro and B. Liskov, “A correctness proof for a practical byzantine-fault-tolerant replication algorithm,” _Technical Memo MIT/LCS/TM-590, MIT Laboratory for Computer Science_ , no. MIT-LCS-TM-590, Jun. 1999.
  * [46] Y. Fu, F. R. Yu, C. Li, T. H. Luan, and Y. Zhang, “Vehicular blockchain-based collective learning for connected and autonomous vehicles,” _IEEE Wireless Communications_ , vol. 27, no. 2, pp. 197–203, 2020. [Online]. Available: https://doi.org/10.1109/MNET.001.1900310
  * [47] Y. Fu, C. Li, F. R. Yu, T. H. Luan, and Y. Zhang, “An autonomous lane-changing system with knowledge accumulation and transfer assisted by vehicular blockchain,” _IEEE Internet of Things Journal_ , vol. 7, no. 11, pp. 11 123–11 136, 2020.
  * [48] M. Vukolić, “The quest for scalable blockchain fabric: Proof-of-work vs. bft replication,” _Open Problems in Network Security_ , pp. 112–125, 2016\. [Online]. Available: https://doi.org/10.1007/978-3-319-39028-4_9
  * [49] C. T. Nguyen, D. T. Hoang, D. N. Nguyen, D. T. Niyato, H. T. Nguyen, and E. Dutkiewicz, “Proof-of-stake consensus mechanisms for future blockchain networks: Fundamentals, applications and opportunities,” _IEEE Access_ , vol. 7, pp. 85 727–85 745, 2019. [Online]. Available: https://doi.org/10.1109/ACCESS.2019.2925010
  * [50] S. Aggarwal, N. Kumar, and P. Gope, “An efficient blockchain-based authentication scheme for energy-trading in v2g networks,” _IEEE Transactions on Industrial Informatics_ , pp. 1–11, 2020.
  * [51] Y. Long, Y. Chen, W. Ren, H. Dou, and N. Xiong, “Depet: A decentralized privacy-preserving energy trading scheme for vehicular energy network via blockchain and k - anonymity,” _IEEE Access_ , vol. 08, pp. 192 587–192 596, 2020.
  * [52] V. Hassija, V. Chamola, S. Garg, N. Dara, G. Kaddoum, and D. N. Jayakody, “A blockchain-based framework for lightweight data sharing and energy trading in v2g network,” _IEEE Transactions on Vehicular Technology_ , vol. 69, no. 6, pp. 5799–5812, 01 2020. [Online]. Available: https://doi.org/10.1109/TVT.2020.2967052
  * [53] M. Pustisek, A. Kos, and U. Sedlar, “Blockchain based autonomous selection of electric vehicle charging station,” _2016 International Conference on Identification, Information and Knowledge in the Internet of Things (IIKI)_ , pp. 217–222, oct 2016.
  * [54] F. Knirsch, A. Unterweger, and D. Engel, “Privacy-preserving blockchain-based electric vehicle charging with dynamic tariff decisions,” _Computer Science - Research and Development_ , vol. 33, p. 71–79, 2018.