See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/339999202

Survey on Blockchain-based Applications in Internet of Vehicles

Article  in  Computers & Electrical Engineering · June 2020

DOI: 10.1016/j.compeleceng.2020.106646

CITATIONS READS
24 903

3 authors:

Léo Mendiboure Mohamed Aymen Chalouf

Université Gustave Eiffel Université de Rennes 1
12 PUBLICATIONS   75 CITATIONS    53 PUBLICATIONS   236 CITATIONS   

SEE PROFILE SEE PROFILE

Francine Krief
Laboratoire Bordelais de Recherche en Informatique
197 PUBLICATIONS   824 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Diaforus View project

Cognitive radio ad hoc networks View project

All content following this page was uploaded by Léo Mendiboure on 18 March 2020.

The user has requested enhancement of the downloaded file.

Survey on Blockchain-Based Applications in Internet of
Vehicles
Leo Mendibourea,∗, Mohamed Aymen Chaloufb , Francine Kriefc
a
LaBRI Lab, University of Bordeaux, Bordeaux, France
b
IRISA Lab, University of Rennes 1, Lannion, France
c
LaBRI Lab, Bordeaux INP, Bordeaux, France

Abstract
The vehicular networks are evolving towards a new paradigm, the Internet
of Vehicles (IoV). With Internet of Vehicles, vehicles should be able to com-
municate with each other and with other devices using heterogeneous access
technologies. To enable the advent of Internet of Vehicles, security, privacy,
cooperation and trust establishment in vehicular networks should be consid-
ered. Blockchain (BC), a popular distributed ledger technology, could be a
way to overcome these challenges and to improve the vehicular communica-
tion architecture. That is why the integration of this technology within the
vehicular networks is currently under study. The aim of this survey is to
provide directions for future work in the area of Blockchain-based vehicular
networks. To do so, existing research works based on this technology and
aiming to overcome some vehicular challenges (security, privacy, cooperation,
trust) are presented and compared in terms of scheme, Blockchain solution
and limitations. Moreover, different requirements (storage, latency, compu-
tation, etc.) related to the deployment of Blockchain-based applications in
vehicular networks are identified and analysed. Finally, different challenges
related to the integration of the Blockchain technology within the vehicu-
lar networks and the future of the vehicular networks (Artificial Intelligence,
edge computing, etc.) are discussed.
Keywords: Internet of Vehicles, Blockchain, Security, Privacy, Trust,
Incentive

∗
Corresponding author
Email address: leo.mendiboure@labri.fr (Leo Mendiboure)

Preprint submitted to Computers and Electrical Engineering March 18, 2020

1. Introduction
The Internet of Vehicles (IoV) will enable the advent of the connected and
autonomous vehicles. Within this paradigm, the vehicles will be able to com-
municate with each other and with their environment: pedestrians, commu-
nication infrastructure, devices, traffic signs, etc. Thus, efficient road safety
and global traffic efficiency applications will be developed and deployed, re-
ducing the traffic causalities [1]. Moreover, the marketing potential of the
vehicular networks will be improved thanks to multimedia and advertisement
applications.
The IoV architecture aims to improve the standardized vehicular com-
munication architecture [2] through the integration of different technologies.
These technologies are Software Defined Networking (SDN), Network Func-
tion Virtualization (NFV), edge computing and Artificial Intelligence (AI).
Their combination should enable a higher Quality of service (QoS), respon-
siveness, flexibility and automation [3].
However, so far, the IoV architecture is still facing different issues, in
particular, security, trust establishment and privacy issues. Indeed, in a
distributed environment with an increasing number of vehicles different chal-
lenges have been identified [4]: security (authentication, availability, in-
tegrity, non repudiation and confidentiality), trust establishment [5] and user
privacy protection. Moreover, the integration of open source technologies
within the IoV architecture, such as SDN or NFV, could also lead to impor-
tant security problems [6].
The Blockchain technology (BC), a distributed ledger technology, could
be an efficient way to deal with these different challenges. Indeed, BC could
provide a transparent, secured, scalable and privacy preserving environment
without a trusted central authority [7]. Therefore, this promising technology
could be used to design security, privacy preserving and trust establishment
services for the vehicular networks at low cost. Moreover, BC can also be
attached to the idea of cryptocurrency and could be a way to tackle another
important open issue, vehicles cooperation, through incentive mechanisms
[8].
Different survey papers have already focused on the integration of the
BC technology within the vehicular networks and the applications of this
technology[9, 10, 11, 12]. Nevertheless, some of these papers, [9, 10, 11]
not only focus on Internet of Vehicles but also on Internet of Things and
smart cities (Internet of Energy, Internet of Cloud, Internet of Healthcare

2
Things). Thus, the vehicular networks are just a part of the content of these
papers and are not discussed in detail. That is why these papers could be
useful to understand the benefits of the use of the BC technology in vehicular
environments but not to understand how this technology could be applied in
this environment and what are the main challenges related to this integration.
Similarly, in [12], the authors focus on trust establishment in Social IoV, a
subgroup of IoV and different solutions are presented: BC, edge computing,
etc. Thus, BC solutions are not specifically analysed. Moreover, the security,
privacy preservation and cooperation issues are not discussed. That is why,
compared with the existing survey papers, our work present several new
aspects. The main contributions of this paper are:

• A comprehensive comparison of the BC-based applications in vehicular

networks aiming to improve security, privacy, trust and cooperation;

• An analysis of the basic needs of the BC-based vehicular applications,

as well as a comparison of the existing solutions enabling to meet these
requirements;

• A presentation of the open challenges and future directions in the field

of BC-based vehicular networks.

The rest of this paper is organized as follows: Section 2 offers a brief

introduction of the IoV architecture and IoV applications. Moreover, BC
principle, BC benefits and the existing BC technologies are presented. Then,
in Section 3, the state-of-the-art applications (trust, security, privacy, incen-
tive) of BC for IoV are presented and analysed. Lastly, some of the main BC
and IoV remaining challenges are discussed in Section 5.

2. Background
In this section are introduced the main concepts needed to better under-
stand the issues covered by this survey. The background information focuses
on the IoV architecture and applications, on one hand, and BC technologies
and benefits on the other hand.

2.1. Internet of Vehicles

IoV is a new paradigm, bringing smartness into the vehicular environ-
ment and aiming to overcome the main limitations of the Vehicular Ad Hoc

3
 Figure 1: Different types of vehicular communications

Networks ([1]): scalability, interoperability, Quality of Service, data process-

ing, etc. With IoV, many types of applications should be enabled : trans-
port management (traffic management, parking slot booking, etc.), vehicle
management (personal assistance, remote assistance, etc.), infotainment and
advertising (multimedia applications, augmented reality, etc.), road safety
(cooperative collision warning, intersection coordinator, etc.), driver assis-
tance (ADAS, parking assistant), health monitoring (fatigue detection, user
comfort, etc.).
The advent of IoV is based on two main ideas: new types of communi-
cations [13] and new technologies. Indeed, with IoV, vehicles should be able
to exchange data with each other (vehicle-to-vehicle: V2V), with wireless
infrastructure (vehicle-to-infrastructure: V2I), with base stations (Vehicle-
to-Network: V2N), with pedestrians (Vehicle-to-Pedestrian: V2P) and with
other devices (Vehicle-to-Devices: V2D) [14] (Fig. 1). Moreover, new tech-
nologies should be integrated into the vehicular communication architecture
to improve the performances of the vehicular networks: SDN, NFV, edge
computing, artificial intelligence, etc. Every technology should bring added
value [3]: programmability and flexibility (SDN), scalability and faster de-
ployments (NFV), automation and intelligent decision making processes (ar-
tificial intelligence) and high responsiveness and network off-loading (edge
computing).
Nevertheless, the current IoV architectures do not focus on privacy, trust
and security. Thus, the main trust, security and privacy limitations of the
vehicular networks are still present ([4]): efficient authentication, vehicles’
trust management, privacy-preservation, access control, etc. Moreover, the
integration of different open source technologies within the vehicular com-

4
 Figure 2: Presentation of the Blockchain technology

munication architecture could lead to other issues [3], [7]. Finally, vehicles
cooperation to enable an efficient data transmission or resource sharing is still
an open issue and efficient incentive mechanisms are required ([8]). Thus,
the definition of new mechanisms ensuring security, privacy and trust for
vehicular networks in a scalable and reliable way is essential. Similarly, the
definition of incentive mechanisms must be considered.

2.2. Blockchain
Currently, BC is one of the most studied distributed ledger technologies.
It is built upon a Peer-to-Peer (P2P) network. This network is used to main-
tain a consistent database among all members, the BC ledger, as shown in
Fig. 2. In BC is stored an ordered list of chained blocks containing trans-
actions (Txs) (currency, data, certificate, etc.). Records of all the exchanges
between the different BC members are kept in this distributed ledger. All
the network members have the same copy of BC and therefore modifying BC
cannot be accomplished without the agreement of most network members
(51%). Therefore, BC aims to provide a transparent, secured and scalable
environment.
BC is popular because it has been the first approach enabling different
nodes to exchange data and cryptocurrencies without a trusted central au-
thority. Resolving the Byzantine general problem, or double spending prob-
lem, BC enables members to exchange cryptocurrencies without a financial

5
institution. The agreement of the networks members is called the consen-
sus process. The first consensus algorithm was the Proof-of-Work (PoW)
algorithm developed by the Bitcoin developers ([15]). Nevertheless, this al-
gorithm presents different limitations (energy efficiency, 51% attack [16], etc.)
and other algorithms have been developed: Proof-of-Stake (PoS), Delegated
Proof-of-Stake (DPoS), Proof-of-Elaspsed-Time (PoET), Proof-of-Authority
(POA), etc.
Even if BC was firstly designed to enable the exchange of cryptocurren-
cies, it has evolved and different uses of this technology are possible today.
The automatic and immutable smart contracts are one of the main evolution
of BC. Smart contracts are software, BC applications, enabling two parties
to negotiate the terms of an agreement, to verify fulfillment and to execute
the agreed terms without a third party [7]. Thus, smart contracts, computer
codes stored in the blockchain, could be used to deploy many types of services
in a distributed, scalable and secured environment: security services (Public
Key Infrastructure, data protection, etc.), advertisement services (ads remu-
neration, etc.) or infotainment services (multimedia applications, resources
sharing, etc.).
Moreover, to meet users’ needs, different types of BC have been devel-
oped: public BC and private or consortium BC. The public BC is a public
distributed ledger: everyone can join the network, analyse transactions, ex-
changes currencies and interact with smart contracts. To ensure a higher
level of security, the private or consortium BC are handled by companies
or group of companies: the administrators decide who can join the network
and the transactions are viewed only by BC users or authorized sub-group of
users. In a public BC, the nodes participating in the consensus process can
be remunerated and therefore money is the main motivation of these nodes
called miners. With a private BC, all participants have a same goal, ensuring
the security of their network and their information, and, therefore, security
is their main motivation.

2.3. Blockchain for IoV: why

As shown in subsection 2.1, to enable secured, private and trusted com-
munications and cooperation in the vehicular environment new mechanisms
(reliable, scalable, ect.) must be developed. Because of its features, BC could
be an attractive way to solve these challenges:

• Decentralization: BC is based on a decentralized architecture without a

6
 central entity and could be an efficient way to provide scalable security
solutions;
• Availability: as BC is decentralized, there is not a single point of failure.
Therefore, the system security and availability is enhanced;
• Cryptocurrency: many BC ledgers provide cryptocurrency exchanges’
services. It could be an efficient way to develop efficient, secured and
automated (smart contracts) incentive mechanisms improving the ve-
hicles cooperation;
• Transparency: all the nodes involved in a BC are able to access to BC
content;
• Immutability: data stored in the BC ledger cannot be modified. There-
fore, BC provides a simple and efficient way to store secured data;
• Anonymity (pseudonymity): with BC, each user is linked with a pseudony-
mous address. This pseudonymity could be a way to deploy efficient
privacy services.
• Exchanges automation: with smart contract, the exchanges between
devices and vehicles can be automated. Thus, data exchange or re-
source sharing services could be automatically deployed without human
intervention.
Because of these different features, the idea of BC-based solutions (se-
curity, privacy, trust, incentive) for vehicular network has been developed
in different research papers. The existing BC technologies are presented in
the next Subsection. Then, the state-of-the-art solutions are presented and
compared in terms of the adopted BC technology: Ethereum, Bictoin, Hy-
perledger, etc.

2.4. Existing blockchains

As described in Subsection 2.2, different consensus algorithms (PoW, PoS,
PoA, etc.) with different approaches (public, private, consortium) and dif-
ferent applications (currency, smart contract, etc.) have been developed.
Thus, each BC technology is characterized by different features (application,
type, consensus, etc.). Some of these technologies (Bitcoin, Ethereum, Hy-
perledger) have already been applied in the vehicular environment (Section
3) and are compared in this subsection as shown in Table 1.

7
 Table 1: Comparison of different BC technologies applied to vehicular networks
Hyperledger
Characteristic Bitcoin Ethereum
Fabric
Type Public Public/Private Private
Permissionless/
Permission Permissionless Permissioned
Permissioned
pBFT
Consensus PoW Pow; PoS
Pluggable
Capacity
7 15 3500
(transac./sec.)
Currency Bitcoin ETH -
Smart contracts Golang Solidity Golang
Blockchain
No Yes Yes
platform
Currency
Low volumes Higher Volumes No
exchange
Public data
No Low volumes High volumes
exchange
Private data
No Low volumes High volumes
exchange

Bitcoin [15] is the oldest BC technology, developed since 2008. This tech-
nology is designed to enable cryptocurrency exchanges in a public tamper-
resistant distributed ledger. Using Bitcoin it is also possible to design smart
contracts in order to automate the exchanges of cryptocurrencies under cer-
tain conditions. Nevertheless, the capacity of this technology is low (7 trans-
actions per second) and the underlying consensus algorithm (PoW) implies a
high computational complexity. Thus, this technology would only be useful
for low volumes of transactions of cryptocurrencies in vehicular networks.
Ethereum [17] is another public BC technology enabling cryptocurrency
exchanges and smart contracts’ definition with a higher capacity (15 trans-
actions per second). Moreover, Ethereum can also be used as a blockchain
platform to store and transmit data in a public (permissionless) or private
(permissioned) BC network. Finally, Ethereum aims to provide different con-
sensus algorithms, Pow, but also PoS, improving the performances and lim-

8
iting the computational complexity. Thus, for applications requiring higher
volumes of transactions and environments with limited computational capa-
bilities, Ethereum could be a more efficient solution than Bitcoin. Neverthe-
less, the capacity of the Ethereum and Bitcoin BCs is really low compared to
traditional systems such as VISA (2000 transactions per second on average).
Hyperledger Fabric [18], a third BC technology, aims to provide a more
efficient system enabling an important number of transactions per second
(3500). This BC technology provides a private BC ledger and is based on a
pluggable consensus layer. Thus, different algorithms can be implemented:
practical Byzantine Fault Tolerance (pBFT), PoW, PoS, etc. Moreover, Hy-
perledger Fabric provides simple access control mechanisms. Thus, this tech-
nology could be used for different types of services generating high data
volumes and for security and privacy-preserving services requiring access
control. However, contrary to Bitcoin and Ethereum, Hyperledger Fabric
is not natively designed to exchange cryptocurrencies. Moreover, a private
ledger cannot be used to make public transactions and to design incentive
mechanisms.
To go further and to provide efficient BC-based solutions, adapted to the
vehicular environment (density, mobility, limited computational and storage
capabilities), it could be interesting to consider other BC technologies in
future works ([11]): IOTA, Byteball, etc.

2.5. Industrial use cases

BC is a promising technology that could revolutionize the automotive
industry. That is why major car manufacturers and automotive companies
have already joined different BC-based projects such as the R3 CEV Consor-
tium (Renault, Toyota)1 , the Hyperledger Project (Daimler AG)2 , the XAIN
project (Porsche)3 or the Car eWallet project (ZF Friedrichshafen)4 . Six
main use cases can be identified:

• Supply chain: BC could be a way to enable transparent exchanges

between suppliers, carriers and manufacturers and to coordinate their
actions.

1
R3 Website: https://www.r3.com/
2
Hyperledger Website: https://www.hyperledger.org/
3
XAIN Website: https://www.xain.io/
4
Car eWallet Website: https://car-ewallet.de/

9
 • Manufacturing: inventory management, ownership issues, product trace-
ability and quality-inspection records, all these processes could be im-
proved using the BC transparency.

• Insurance: storing different pieces of information in a secured BC ledger

such as position, acceleration and braking behaviors, vehicle speed, it
could be possible to efficiently manage insurance claims.

• Fleet management: with BC, secured pieces of information could be ex-

changed between fleet managers, owners, operators and drivers. With
this system, route scheduling, payments or vehicles maintenance, for
example, could be automated.

• Vehicles tracking: transparent vehicles information, automotive title

transfer or car leasing could be securely managed thanks to the BC
technology

• Internet of Vehicles: vehicles and surrounding devices (smartphones,

road signs, etc.) should exchange different pieces of information with
BC these devices could be authenticated and these exchanges secured.

In Section 3, different research works based on the BC technology and

aiming to improve the performances of the vehicular networks are presented
and compared.

3. Blockchain-based application for IoV

As explained in Section 2, BC technology presents many benefits, includ-
ing, decentralization, availability, cryptocurrency, immutability, anonymity
and exchanges automation. Thus, BC could be an efficient way to improve
the vehicular networks and to transform this ecosystem into a trustworthy,
secured and privacy-preserving environment. Based on this technology and
these benefits, as show in Fig. 3, four main types of applications of BC tech-
nology have already been considered in the vehicular environment: security
(transparency, immutability, etc.), trust establishment (exchanges automa-
tion, transparency, etc.), incentive (cryptocurrency) and privacy-preservation
(anonymity).

10
Figure 3: Blockchain-based applications in IoV

11
 Table 2: Comparison of the existing incentive mechanisms
Application Services Approach Limits BC techno. BC nodes
Incentive Time locking Evaluation
VDTN [8, 20] Bitcoin Cloud/RSUs
(credit-based) Multi-signatures Security
Incentive Implementation
VCC [21] Utility function Bitcoin Vehicles
(credit-based) Security
Intersection
Incentive Feasability
management Trust index Own Vehicles
(reput.-based) Benefits
[22, 23]
Incentive Consensus Keys
Crowdsourcing (credit-based) protocol management
Own Cloud/RSUs
[24] Privacy Threshold ring Overhead
preservation signature Cost

3.1. Incentive mechanisms

The whole functioning of the vehicular networks is based on the idea
of vehicles cooperation. For example, when a vehicle detects an abnormal
situation (accident, lane change, etc.), this information must be transmitted
to the surrounding vehicles to improve the road safety. Thus, to enable
an efficient data forwarding, V2V communications are essential. Moreover,
thanks to the computational and storage capabilities of the vehicles, it could
be possible to improve data management through different techniques such as
Vehicular Cloud Computing [19]. However, malicious nodes of selfish nodes
could disturb the whole network functioning by degrading data transmission
or by not making available their computational and storage resources.

3.1.1. Existing incentive mechanisms

Credit-based incentive mechanisms could be an efficient way to encour-
age vehicles to share their computational, storage and network capabilities.
Indeed, a vehicle improving the vehicular network operating could receive
credits. The BC technology enabling to automatically exchange cryptocur-
rencies in a secured and scalable environment could be a way to design these
incentive mechanisms. That is why, based on this technology, different credit-
based incentive mechanisms have already been proposed in the vehicular en-
vironment.
In Vehicular Delay Tolerant Networks (VDTNs), vehicles are used to
store, carry, and forward data between independent and non-connected road
side devices. Thus, this system is based on the vehicles’ cooperation. That
is why, the authors of [8, 20] proposed a secured incentive scheme to improve
cooperation using an existing BC, the Bitcoin. According to the authors, the
choice of a BC technology instead of a financial institution presents different

12
benefits: low cost, trust, decentralization and pseudonymity. In VDTNs,
a vehicle will be rewarded if it transports data from a Base Station (BS)
A to a BS B. However in a normal Bitcoin transaction, money is directly
taken from the sender (BS A) and transmitted to the recipient (vehicle).
Thus, even if the vehicle does not forward data to BS B, it would receive
money. To deal with that, the authors of these papers define a solution
based on time-locked conditions and multi-signatures. With this solution, a
vehicle will be paid only if data is correctly forwarded and if both sender and
recipient BSs sign the transaction enabling the vehicle to receive its reward.
On the contrary, if the vehicle does not transmit data in a given period of
time (the time-lock), the emitting BS will be able to get its money back.
This solution using multi-signatures and time-locking enables to deal with
conditional rewarding using the Bitcoin BC, overcoming the limits of this
technology. Moreover, this approach could be extended to other scenarios
such as carpooling, products delivery, etc. Finally, in this system, vehicles
are only considered as BC clients and the BC ledger management should not
be a problem. Nevertheless, this paper only presents the functioning of the
solution and an evaluation would be necessary. In addition, according to the
authors, pseudonymity could be a way to provide partial anonymity but it
cannot be considered as a real solution [25]. Finally, the relevance of the
choice of the Bitcoin BC to automate exchanges, as smart contracts are still
not fully supported by this technology [26], could be discussed.
Cooperation in Vehicular Cloud Computing (VCC) is another important
issue. Indeed, VCC aims to use the available computational and storage ca-
pabilities of the vehicles to store and download content, complementing the
existing cloud computing systems. Nonetheless, this system is based on the
cooperation of the vehicles. That is why, to encourage them to cooperate,
a credit based incentive approach for V2V cooperation in VCC is defined
in [21]. In the proposed solution, nearby vehicles are grouped into clusters
collecting and processing data for Intelligent Transportation System (ITS)
services. A cluster head is elected using a routing protocol and transmits the
data received from the other vehicles of the cluster to a conventional cloud
service. Each vehicle of this cluster transmitting data is rewarded according
to a utility function taking into account the quantity of data transmitted, the
commission rate and the elapsed time. Thus, the authors of this paper also
aim to design a conditional rewarding mechanism. However, the implemen-
tation of this system over the Bitcoin BC is not described and transactions
scripts must be defined [8, 20]. Moreover, in this approach, the vehicles are

13
considered as BC nodes and the deployment of the Bitcoin BC in this en-
vironment could be complex. Finally, the data transmitted by a vehicle in
not controlled and not correlated with the data transmitted by the other
vehicles. Thus, a vehicle could easily transmit useless data to be rewarded.
The authors of [22, 23] focus on two main issues: trust establishment
and incentive mechanism. Their objective is to define a framework enabling
secured communications in the vehicular environment without a central au-
thority. The authors present a new BC ledger. This BC ledger should allow
each vehicle to generate a unique identifier called Bit Trust. Moreover, to en-
sure security, BC is used to store the communication’s history of each vehicle.
To get a reward and to improve its Bit Trust, a vehicle should contribute to
the proper functioning of the vehicular networks. For example, if a vehicle is
involved in the management of an intersection, computing the crossing order
of this intersection, it will get a reward, increasing its Trust Bit. However,
questions still arise. Indeed the authors of this paper aim to design a dis-
tributed system to deal with trust management in vehicular networks. This
is an ambitious objective and the approach described in this paper, based on
hashes and public/private keys management is similar to existing BC tech-
nologies. Moreover, the system guaranteeing the security of the exchanges
using this BC technology is not fully presented. Thus, the feasibility of this
solution should be evaluated.

3.1.2. Existing privacy-preserving incentive mechanisms

To deploy efficient incentive mechanisms, privacy-preservation is an im-
portant point. As noticed in [20], thanks to the pseudonimity offered by
the BC technology, a basic level of privacy can be guaranteed. Nevertheless,
to define a system ensuring a high level of privacy, unlinkability is essential
[25]. That is why the authors of [24] defined an incentive mechanism aim-
ing to improve crowdsourcing systems while preserving the users’ privacy.
This solution uses a new announcement protocol. When a vehicle detects
an abnormal situation, it will ask the surrounding vehicles to confirm this
information. Then, this information is transmitted to distant vehicles, allow-
ing them to adjust their behavior depending on the current road conditions.
Thanks to a threshold ring signature, the privacy of the vehicles taking part
into an announcement protocol is protected. Indeed, this system enables the
indistinguishability of the cooperating vehicles. This privacy-preserving an-
nouncement protocol is also linked to an incentive mechanism in this paper.
For example, if a vehicle wants to get traffic condition’s information in a cer-

14
 Figure 4: Implementation of the Blockchain technology in vehicular networks

tain area, it will provide a reward for any information transmitted by vehicles
located in this area. The proposed system is composed of three main parts:
announcement protocol, privacy-preservation and incentive mechanism. To
deal with information verification, the authors consider that designing a new
BC ledger is required. However, in contrast with the previous papers, differ-
ent points are considered in this solution: setup, transactions management
and consensus protocol. Thus, this approach might be a deployable solution.
Nevertheless, as noticed by the authors, the key management and coin bal-
ance system could be improved. Moreover, the implementation and the cost
of this system could be discussed.

3.1.3. Discussion
As the BC technology was firstly designed to enable cryptocurrencies’
exchanges, it is an interesting way to deploy incentive mechanisms in the
vehicular environment. Indeed, the cooperation between vehicles, sharing
information or computational, storage and communication resources is essen-
tial. Different use cases including VDTN ([8, 20]), cooperation in VCC ([21]),
intersections management ([22, 23]) and crowdsourcing ([24]) have already
been addressed. Some of these papers aim to deploy and improve existing BC
ledgers thanks to different mechanisms based on time-locking, signatures and
utility functions management ([8, 20, 21]) while some others aim to define
new BC ledgers and new consensus protocols dealing with the constraints of

15
the vehicular environment ([22, 23, 24]). Nevertheless, many of these propo-
sitions are only at the proposal stage and the evaluation of their relevance is
not yet possible. In addition, in [21], vehicles are considered as BC nodes, as
shown in Fig. 4. The feasibility of deploying existing BC ledgers (Bitcoin) in
such an unstable environment should be evaluated. Similarly, the interesting
use cases for BC-based incentive mechanisms should be defined. Indeed, for
some safety applications, ultra low latency (around 10ms) is necessary [27]
and BC could be an inadequate solution. Improving the performances of the
BC technology to deal with these performances will be an important chal-
lenge. Finally, the idea of decentralized cloud systems and BC-based cloud
systems using the available storage and computational resources of the users
is a hot topic. For example, in device-to-device networks, the authors of [28]
proposed to define a BC-based fair computational resources sharing system
using incentive mechanisms. Considering the important storage and compu-
tational capabilities of the vehicles and the important number of vehicles, as
well as the emergence of different paradigms such as Vehicular Cloud Com-
puting or Vehicular Fog Computing, it would be interesting to develop such
systems in the vehicular environment.

3.2. Trust establishment

The vehicular networks are composed of different types of nodes includ-
ing vehicles, road side units, base stations and even objects: smartphones,
connected traffic signs or connected billboard. These heterogeneous nodes
could be connected through different types of communication technologies:
cellular network, Wifi, Lifi, Bluetooth, etc. Using these communication chan-
nels, these nodes will be able to exchange data. Establishing trust between
these nodes for data transmission and data processing is essential to ensure
road safety. Indeed, if a node reports an accident, this information must
be verified and certified. Similarly, if a node is used as a relay, or to store
and process data, trust is necessary. Thus, controlling the behavior of the
different nodes is an important point.

3.2.1. Existing trust establishment mechanisms

As BC technology ensures the data immutability and enables to automate
the exchanges between nodes, different trust models, based on this technology
have already been proposed. Moreover, the idea of cryptocurrency could also
be used to design trust models. The higher the node’s credit score is, the

16
higher the trust level of this node will be. Thus, using these credit scores, it
is possible to identify trusted and non trusted users.
To provide efficient road safety services, the vehicular networks are based
on the idea of messages broadcasting. When a vehicle detects an abnormal
situation (traffic jam, obstacle, collision, etc.), it transmits this information
to the surrounding vehicles. However, this system is facing different kind of
attacks, including, message spoofing and ballot stuffing attacks. To deal with
that, the authors of [29, 30] proposed a BC-based system to improve trust in
the vehicular environment. When a vehicle receives a message from surround-
ing vehicles, a Bayesian Inference Model is used to assess the credibility of
this message (depending on the messages received from other vehicles). Then
this information is transmitted to the nearby Road Side Unit (RSU). All the
RSUs form a BC network analysing the credibility of the messages trans-
mitted by each vehicle during a certain period of time. Depending on that,
they increase or decrease the trust index of each vehicle. As this system is
decentralized and requires a global consensus, malicious RSUs will not be
able to modify the trust index of a given vehicle without the approval of
the majority of the RSUs. Thanks to that, a vehicle will be able to know
the trust index of the surrounding vehicles and to determine which are the
trusted vehicles. Thus, the system described in this paper should provide an
efficient way to manage ratings and trust values. However, the security level
of the BC-based solution raises questions. Indeed, the BC ledger should be
modified by the RSUs, uploading the new trust index of the vehicles. There
does not seem to be any mechanism to ensure that the uploaded data is valid.
Thus, the consensus protocol of this solution should be improved to provide
a secured solution. Moreover, each vehicle is supposed to request the trust
index of the surrounding vehicles to the nearby RSU, in a dense environment
and highly mobile environment, the scalability of such a system should be
evaluated and other approaches should be considered if needed.
In [31], a mechanism enabling the evaluation of nodes’ and messages’
trustworthiness in the vehicular environment is also described. To enable
that, the idea of Proof of Location is presented: the location of a given
vehicle is certified by the nearby RSU controlling the identity of this vehicle.
When a vehicle transmits a message to other vehicles, using the BC ledger,
these vehicles will consider this message only if they are located in the same
area as the sender vehicle (Proof of Location). Depending on the timestamp
of the packet, these vehicles will validate the content of the message if it
corresponds to the current road conditions. According to that, the trust

17
 Table 3: Comparison of the existing trust establishment mechanisms
Application Services Approach Limits BC techno. BC nodes
Messages Inference Scalability
Trust
broacasting model Own RSUs
(nodes)
[29, 30] Consensus Security
Proof of
Exchanges Scalability
Trust location
trustworthiness Own Vehicles
(nodes) Multilayered
[31] Interactions
BC
Proof of
Exchanges Security
Trust event
control Own RSUs
(messages) Multilayered
[32] Scalability
BC
Data provider
Trust selection Latency
Exchanges
(nodes) Reputation RSUs
control Own
scheme Vehicles
[33]
Authentication Key Implementation
Management
Trust Reputation Information
Platooning
(nodes) scheme control
control Own Vehicles
Data Local Information
[34]
availability BC dissemination
Trust BC-based Security
Messages
(nodes) distribution
distribution Own Vehicles
Data Local Latency
[35]
availability BC Scalability
Content Permissioned
Centric Trust BC Scalability RSUs
Hyperledger
Networks (nodes) Messages Security Vehicles
[36] Verification
SDN Trust AI based Interactions
applications (applications) analysis
Ethereum RSUs
control Access Credentials Scalability
[7] control management Latency
Trust Proof of Scalability
Exchanges
(nodes) presence Security
control Own RSUs
Privacy Certificates Centralised
[37]
preservation management system

18
level of the message will be incremented or decremented. The trust level
of a vehicle corresponds to the average trust level of the different messages
transmitted by this vehicle. With this system, the authors aim to provide
local BCs controlling the behavior of the nodes located within a given area.
This approach present different benefits. First of all, the Proof of Location
could be an efficient way to improve the security of the system. Nevertheless,
the implementation of a BC-based system enabling to share this information
only with surrounding vehicles could be complicated. The scalability of such
a system should be evaluated. Moreover, the proposed solution is based on a
multilayered BC ledger: local BC and global BC. The interactions between
these different BCs and the security of these interactions should be discussed.
The authors of [32] also aim to provide a solution ensuring trust in ve-
hicular communications to enhance road safety. Focusing on message trust-
worthiness, they defined a new consensus algorithm called Proof-of-Event
(PoE). This PoE consensus is a two-pass threshold-based event validation
mechanism. First of all, each RSU collects the CAMs (Cooperative Aware-
ness Messages) from the surrounding vehicles and evaluates the trust level
of the received messages. Then, it transfers this message to the surrounding
vehicles in order to verify the information. If this information is validated
by a majority of vehicles, the CAM message is considered to be trusted. To
accelerate data dissemination, the authors of [32] also propose a two-phase
consecutive transaction in BC. Thanks to that, a given information is trans-
mitted to the surrounding RSUs located within the same region, improving
and simplifying data dissemination process. To demonstrate the benefits of
this approach, the authors compared the PoE with existing consensus algo-
rithms (PoA, PoW) and also measured the security of the system in terms of
false event success rate. The PoE and the Proof of Location [31] are similar
ideas. However, in this paper [32], the RSUs manage the message verification
and message distribution. Thus, a malicious RSU could disturb the network
functioning. Thus, the security of the proposed PoE mechanism should be
discussed. For its part, the multilayered BC could improve and accelerate
the message dissemination. However, the scalability of such a system, storing
all the events noticed by the vehicles could be an important challenge.
With these different approaches ([31, 29, 30, 32]), RSUs have a major
role as they control data. In [33] is introduced a vehicle-centric system.
Indeed, in the proposed architecture, the RSUs will only be used as BC nodes
storing data and the vehicles will be responsible of trust establishment and
trust management. In addition, to define a secured data sharing environment

19
based on a distributed consensus protocols, the authors describe a reputation
management mechanism. This mechanism is based on the idea of subjective
logic. Each vehicle will be able to determine whether or not a neighbor
vehicle can be trusted. The vehicles’ opinion is based on three main factors:
interaction frequency, event timeliness and trajectory similarities. Using this
subjective logic and global recommended opinions stored in the BC ledger,
each vehicle can determine which neighbor vehicle provides trustworthy data.
With this system, all the data is exchanged through the BC ledger, ensuring
a higher level of security than previous solutions [32]. Moreover, each vehicle
can select trusted data providers using the BC ledger and the reputation
scheme. However, the scalability and the latency of such a system should
be evaluated. In addition, to provide an implementable solution, a realistic
implementation of the reputation scheme system should be designed.
The authors of [34] go even further and describe a system aiming to pro-
vide security in vehicular networks in the absence of RSUs. To do so, the
BC ledger is stored inside the vehicles and updated thanks to the exchanges
between the vehicles. To demonstrate the benefits of this approach, a pla-
tooning use case is presented. The vehicles in this platoon will form a BC
network. The behavior of each vehicle will be analysed and stored in this BC
ledger. Thanks to that the trust index of each vehicles will be increased or
decreased depending on its actions. Nevertheless, even if this system is at-
tractive and could be a way to establish trust within the vehicles of a platoon
without any external help, there are still questions. Indeed, contrary to the
previous solutions, RSUs are not considered in this solution to manage global
information. Thus, with this approach, managing global trust index could
be complex. Similarly, inter-platoons exchanges or platoon reconfiguration
should also be considered. Moreover, the reputation management scheme is
not as developed as those described in [31, 29, 30, 32].
In [35], a similar system is described. Indeed, the authors also aim to
provide security and trust in a decentralized vehicular environment without
RSUs. The authors mainly focus on the idea of a BC-based message distribu-
tion and describe BC-based format of different kind of emergency messages:
emergency brake, line changing, intersection movement and collision warn-
ing. Storing these messages in the BC ledger, and analysing these messages,
the authors also aim to manage the trust level of the different vehicles. With
this solution all the messages should be exchanged through the BC ledger.
This could improve security but the proposed solution should face the same
challenges as those described in [34]: system scalability, global BC update

20
and latency. Moreover, vehicles could easily be integrated to the BC ledger
using a simple key management mechanism. A malicious vehicle could easily
disturb the network, modifying and transmitting wrong data.
In Content Centric Networks, estimating the reliability of the source is
also an important challenge. In [36], the authors try to demonstrate the ben-
efits of permissioned BC to improve trust in vehicular environments. Indeed,
with permissioned BC it could be possible to securely control the behavior of
the different nodes and to improve scalability. In this system all the messages
exchanged between the vehicles are send to the BC ledger. Then, this infor-
mation is controlled by the surrounding vehicles. If this information is valid,
a trusted validator adds the transaction to BC ledger. Compared to the PoE
[32] and Proof of Location [32], the approach described in this paper presents
different limitations. Indeed, the position of the sender is not verified and the
message is transmitted to all the vehicles, not only the surrounding vehicles.
Thus, this approach could present different limitations in terms of security,
scalability and energy consumption. However, permisioned BC, as described
in this paper, could be an efficient way to deal with local and efficient mes-
sage transmission. Thus, it could be an efficient way to implement realistic
BC solutions for vehicular networks.
In virtualized environment, such as Software Defined-IoV (SD-IoV, [38]),
it will also be important to control the behavior of the applications. Indeed,
in a SDN environment, applications are able to request resources to SDN
controllers, modifying the behavior of the data plane (reserving resources or
modifying communication path). With SD-IoV, these applications will be
able to request resources to different controllers, potentially, heterogeneous
controllers. Thus, defining an environment enabling heterogeneous SDN con-
trollers to control the behavior of SDN applications is an important point.
That is why, the authors of [7] defined a mechanism enabling the trust es-
tablishment between the SDN applications and the SDN controllers. To do
so, they introduced the ideas of Application-Trust Index, and Application
Identity. In this system, BC acts as a Public Key Infrastructure (PKI) au-
thenticating and certifying the SDN applications exchanging with the SDN
controllers. All the requests sent by the SDN applications are stored in
BC and the resources used by these applications are frequently controlled.
Thanks to that, when a SDN controller detects an abnormal behavior, this
information will be shared with the other SDN controllers and the concerned
application will not be able to send other requests to the different controllers.
Nevertheless, with this solution, SDN controllers are considered as trusted

21
nodes. Thus, malicious nodes could easily disturb the entire network and
modify the Application Trust Index. Moreover, Artificial Intelligence tech-
niques are supposed to be used to evaluate the behavior of the SDN applica-
tions. The interactions between this AI-based behavior evaluation and the
BC ledger should be discussed.

3.2.2. Existing privacy-preserving trust establishment mechanisms

To guarantee the system trustworthiness, the above described works use
the BC ledger to store information about the vehicles: packets sent, trust in-
dex, etc. Thus, the corresponding systems could suffer from tracking attacks.
That is why the authors of [37] proposed a privacy-preserving trust mech-
anism based on the BC technology: a Blockchain-based Anonymous Repu-
tation System (BARS). To enable that, the authors defined an architecture
composed of different entities (Certificate Authority, Law Enforcement Au-
thority, RSUs, vehicles) and different BC ledgers (for certificates, for revoked
public keys, for messages). Thanks to the Law Enforcement Authority and
the Certificate Authority, each vehicle will be able to request a new public
key. Thus, it will be impossible to track a vehicle, ensuring its privacy. The
reputation score of a vehicle is attached to its current certificate, enabling the
surrounding vehicles to determine which are the trusted vehicles. To manage
this reputation score a reputation evaluation algorithm based on different
factors (level of alter, vehicles’ density, senders’ sequence) and the type of
behavior is defined by the authors. This system, using an efficient certifi-
cates management mechanism, should be able to guarantee the privacy of
the vehicles. Nevertheless, the proposed system is based on an external Law
Enforcement Authority and an external Certificate Authority reducing the
benefits of a decentralized approach. It could be interesting to design BC-
based privacy-preserving systems. For its part, the BC-based mechanism
enabling to control the position of a vehicle and to authenticate this vehicles
is more complete than those described in previous papers. Nevertheless, it
could be improved considering a multilayer BC as described in [31]. Finally,
deployment complexity of such an ecosystem could be discussed.

3.2.3. Discussion
BC aims to enable untrusted nodes to securely exchange data. Trust
management for vehicles is a really important question. Indeed, independent
vehicles will be able to share data and broadcast messages to the surround-
ing vehicles. Controlling these messages and verifying the relevance of these

22
pieces of information is important to guarantee the road safety and to prevent
malicious behaviors. That is why different authors have already proposed
systems enabling to control the messages’ trustworthiness ([32]) or the mes-
sages’ trustworthiness and the vehicles’ trustworthiness ([29, 30, 31, 36, 33])
while preserving the users’ privacy ([37]). For most of these works, RSUs
are used to manage trust and to store BC ledger thanks to their important
storage and computational capabilities and their stable location. However,
the idea of fully decentralized systems working in the absence of RSUs have
been described in [34, 35]. With these systems, vehicles will act as BC nodes
storing and updating their own BC ledger. Even if this solution seems to be
a promising way to enable trust establishment in vehicular networks, there
are different challenges remaining: scalability, BC ledger updates, etc. Thus,
determining whether or not vehicles could be used to manage global trust
systems, without external devices such as RSUs, is an interesting question.
To enable trust establishment, the behavior of the vehicles must be con-
trolled. Therefore, different consensus algorithms have already been designed
for vehicular networks, enabling to check whether or not the information
shared by a vehicle is correct. Scalability for these systems is a really im-
portant point and the idea of multilayered BC with local and global data
exchanges have already been proposed. Thanks to these systems, surround-
ing vehicles should be able to control the behavior of an emitting vehicle
and more distant vehicles should only receive valid data. To do so, the ideas
of Proof of Event and Proof of Location have been introduced [31, 32]. As
described in [36], permissioned BC could be a way to implement such sys-
tems and this point should be tackled. Moreover, the performances of these
multilayered BC should be assessed to evaluate their relevance. Thereafter,
in these systems, RSUs are considered as trusted nodes. However, to ensure
the security of the communications, the behavior of these RSUs should also
be controlled by the BC network. Finally, as shown in [22, 23], trust estab-
lishment and incentive mechanisms are correlated and designing BC-based
systems enabling trust establishment while providing incentive mechanisms
could be an efficient way to improve data dissemination.

3.3. Security and privacy

Regardless the type of application, security and privacy are essential
points. Indeed, to design a secured network enabling the deployment of road
safety applications different security services should be considered. First of
all, the emitter of the message must be known (authentication). Then, the

23
application must be accessible at any time (availability) and the messages
should not have been modified by a malicious node (integrity). Moreover,
a source should not be able to deny the authenticity of its signature (non
repudiation) and a non-authorized node should not be able to read a pri-
vate content (access control). Protecting the users’ privacy is also impor-
tant. The BC technology could provide these different services. Indeed, with
BC, a node must be identified to send messages (authentication), data can
be encrypted (confidentiality) and data immutability is ensured (integrity).
Moreover thanks to the decentralized architecture, data availability is guar-
anteed (availability) and access control mechanisms (confidentiality) as well
as privacy preserving mechanisms (privacy) can be defined. That is why dif-
ferent solutions based on the BC technology have already been proposed to
improve security and privacy in vehicular networks.

3.3.1. Authentication
Authentication is an important challenge in vehicular environments. In-
deed, enabling a quick authentication between fast moving vehicles is a com-
plex task requiring the design of new solutions. To authenticate users and
certify their identity, PKIs are a very common solution. Nevertheless, the
deployment of PKIs for vehicular networks would be expensive. Moreover,
centralized PKIs are suffering from different limitations ([39]): single point
of failure, privacy, trust, etc. That is why different BC-based PKIs have been
designed for the vehicular environments.

Existing authentication mechanisms. For example, the authors of [40] intro-

duced a BC-based system enabling an efficient authentication and revocation.
The proposed solution aims to avoid attacks against a Single Point of Failure
and to reduce the dependency on Certification Authority. To do so, a BC
ledger is shared between the RSUs, the Certification Authority and the Re-
vocation Authority. Thus, a mutual authentication between the RSUs and
the vehicles will be possible without requiring a verification from the Certifi-
cation Authority. However, to be efficient, this system should enable a quick
update of the shared ledger. Indeed, new revocations notifications should be
quickly shared with surrounding users. Thus, latency could be an important
limitation for this approach. A similar idea is described in [41] where a BC
network is also deployed at the RSUs’ level. With this system, different BC
ledgers are used to store the certificates, admission, authentication and re-
vocation lists. This could improve the latency performances of the system as

24
well as the required storage capabilities. This approach also aims to reduce
the verification overhead. Indeed, to simplify the authentication process, a
simple lookup function is used rather than a cryptography signature verifi-
cation. Nevertheless, the level of security provided by such a system should
be evaluated.
The Security Credential Management System (SCMS, [42]) is a special-
ized PKI system designed to secure the vehicular communications. To enable
the accountability of this system, improve transparency and reduce the need
for mutual trust, the authors of [43] proposed a BC-based SCMS using RSUs,
vehicles and Misbehaviour Authorities as BC nodes. This system is based
on a hierarchical consensus mechanism. Certified vehicles, forming a clus-
ter and a local BC network, must agree on pieces of information to send
to the nearby RSU. These pieces of information correspond to an abnormal
behaviour detected by these vehicles. Then, sub-groups of RSUs and Mis-
behaviour Authorities will validate this data and share it with the global
BC network. Thanks to that, the revocations lists can be globally managed.
Nevertheless, it is only a proposal paper and, to implement it, many points
should be considered, including, cluster formation and cluster management.
Moreover, the RSUs are supposed to upload data to the global BC and a
malicious RSU could share wrong data. Security should also be discussed.
The authors of [44] focus on key management in heterogeneous vehic-
ular communication systems managed by different security managers. In
traditional systems, central managers are used to enable key transfer be-
tween these security managers. Nevertheless, this system present different
limitations: central managers interoperability, single point of failure attacks,
transfer delay and computational complexity. That is why a distributed key
management enabling key transfer between different service managers using
BC technology is described in [44]. The proposed solution is based on two
main components. The first one corresponds to the key transfer handshake
scheme based on the BC ledger. The second one is the transaction collection
time, a metric enabling to optimize block generation and delays depending
on the key distribution. This solution is interesting as a handshake scheme is
proposed in a BC environment. Moreover, improving the transaction collec-
tion time could reduce the delays implied by the BC approach. Nevertheless
the performances of the proposed system in terms of computational time and
overhead in a realistic environment should be discussed. Finally, trust estab-
lishment between the different security managers in a decentralized system
should be considered.

25
Discussion. To design secured communications and to enable trust estab-
lishment, authentication is an important point. To deal with the limitations
of the traditional PKI infrastructures, different BC-based solutions have al-
ready been proposed [40, 41, 43]. As described in [40], the BC technology
could be a way to prevent against attacks on Certification Authorities and
to recude communication exchanges between Certification Authorities and
network devices (RSUs, vehicles). Going further, [41, 43] introduce multi-
layered BC to improve the performances of the existing systems: verification
overhead and accountability. BC could also be an efficient way to design new
handshake protocols [44] and solutions based on this idea could be explored.
Indeed, rather than improving existing Certification Authorities, BC could
be a way to design new authentication and certification protocols.

3.3.2. Access control

With the vehicular networks and the IoV, huge volumes of data will be
generated. Ensuring the access control of these pieces of information to pro-
tect the network security against some specific attacks (data analysis, track-
ing, etc.) is an important point. Thanks to access control, confidentiality
could be ensured. Indeed, unauthorized entities would not be able to access
protected content.

Existing access control mechanisms. The vehicles will produce huge volumes
of data. However, for a given application only part of this data will be
relevant. Accessing these fragments of data in a fast and efficient way is
an important challenge. That is why the authors of [45, 46] proposed a
Blockchain-Based Vehicular Data Management. In this architecture, the
RSUs are BC nodes, storing data produced by the vehicles and ensuring the
accessibility of these information for multiple applications. In this system the
applications can request some pieces of information from a given RSU. The
global system is able to balance the load between the different RSUs, limiting
packet loss rate. Moreover, a simple access control is defined by the authors.
Each BC block contains a policy header containing a list of applications
which are allowed to access to the content of this block. Thanks to that
the applications permissions can be controlled (read/write). Even if the
idea of designing efficient BC-based access control mechanism is attractive,
important questions are not tackled in these papers. A mechanism enabling
to authenticate the applications and to define their permissions should be
designed to provide a secured system. Moreover, the proposed solution, based

26
on a load balancing algorithm could suffer from Denial-of-Service attacks.

Discussion. As explained in [47], BC-based access control mechanisms could

present many benefits including transparency, distributed auditability, scal-
ability and low-cost deployment. Nevertheless, the idea of applying BC tech-
nology to improve access control in vehicular networks is in its early stages.
Indeed, even if the authors of [45, 46] demonstrated the benefits of this ap-
proach, complete solutions and implementations are necessary. Moreover, to
improve data management and to improve scalability as well as latency, sys-
tems based on multilayered permissioned BC could be imagined. Finally, as
shown in [48], a paper describing a BC-based access control for IoT devices,
BC could be a way to enable users to own and control their data. New use
cases and new applications based on BC technology could be imagined. For
example, decentralized access control mechanisms enabling users to exchange
their data in return for compensation could be designed.

3.3.3. Availability
Availability is one of the native benefits of a BC ledger. Indeed, as BC
is based on a peer-to-peer network, the single point of failure situation is
prevented and therefore, data availability is ensured. However in the vehic-
ular environment, a reliable and constant communication cannot be guar-
anteed. Indeed, vehicles will not be connected to RSUs at any time and
non-connected scenarios should be considered. That is why, the authors of
[34, 35] have proposed solutions based only on V2V communications to es-
tablish trust. Nevertheless, in such systems, scalability, latency and data
dissemination should be considered. Moreover, the communication resources
required by such systems should be improved in order to design realistic sys-
tems. Thus, even if availability is inherent in BC-based systems, availability
in vehicular environments is an important challenge.

3.3.4. Non repudiation and Integrity

Non repudiation and integrity are inherent in BC-based applications. In-
deed, only valid transactions are be added to the BC ledger. Moreover, this
BC ledger ensures the immutability of these transactions. Thus, integrity is
ensured natively. As these transactions are cryptographically signed, and as
each user is identifiable, non repudiation is also guaranteed. Nevertheless,
as explained in [49], a high level of integrity and non-repudiation could also
have a negative impact. Indeed, if illegal data, irrelevant or incorrect data

27
are stored in a BC ledger, the system will not be able to remove/modify this
content and these incorrect pieces of information will be indefinitely stored
and accessible in BC ledger. Thus, this question could be discussed. Fur-
thermore, while BC technology could ensure the integrity of the data stored
within BC ledger, the relevance and the correctness of the data uploaded to
BC ledger cannot be guaranteed. That is why, to improve the trust level
of the system and to ensure the correctness of the uploaded data, it could
be interesting to design solutions combining BC technology with solutions
guaranteeing the access control and integrity to secure-sensitive computa-
tion tasks such as data analysis. For example, the Intel Software Guard
Extensions (SGX) could be an interesting approach [50] and it could be a
way to complete the existing BC-based trust management systems.

3.3.5. Privacy
To avoid tracking attacks, protecting the users’ privacy is another im-
portant concern. As shown in Section 3.1.2, Section 3.2.2, different privacy-
preserving mechanisms have already been designed to improve incentive mech-
anisms [25, 24] and trust establishment mechanisms [37]. Nevertheless, privacy-
preservation could be useful for many other applications.

Existing privacy preserving mechanisms. For example, carpooling, a system

enabling users to share vehicles could lead to serious privacy issues. Indeed,
private information such as user location and user identity may be shared
with a central system. That is why the authors of [51] proposed an eFficient
and prIvacy-preserving CArpooling scheme (FICA) based on BC technol-
ogy deployed at the RSUs level. This paper presents two interesting ideas.
First of all a privacy-preserving location-aware one-to-many matching pro-
cess is proposed [52]. Then, an anonymous authentication scheme, based on
certificates management is defined. Nevertheless, while some solutions have
considered a distributed Trusted Authority, a centralized system is proposed
in this paper, limiting the benefits of the BC approach. Moreover, RSUs
have a central role in this system as they manage the carpooling requests.
A compromised RSU could disturb the network functioning and this point
should also be considered.
Ensuring the privacy of fast moving vehicles accessing fog vehicular ser-
vices is an important challenge. To deal with that and to provide a lightweight,
quick and privacy preserving authentication the authors of [53] proposed
BLA, a Blockchain-assisted Lightweight Anonymous authentication mecha-

28
nism. Contrary to the other solutions, with this system the user protects his
privacy by himself. Thanks to a distributed reauthentication phase, the user
of a vehicle can modify its pseudonym at any time. However the reliability
of such a system is consequently uncertain and the non-traceability must
be demonstrated. The approach described in this paper also introduces a
distributed model. Indeed, to improve scalability, regions are defined. Each
region, corresponding to a set of Vehicular Fog Datacenter, is managed by
a single Service Manager maintaining the BC ledger. Nevertheless, despite
the benefits of such a system, defining relevant service managers and guar-
anteeing the reliability and the trustworthiness of these managers could be
difficult. Thus, the feasability of this approach should be evaluated.
Similarly, the authors of [46] proposed a three step process enabling to au-
thenticate and ensure the privacy of a user exchanging with a service provider.
To do so, a Registration Service is used. When a vehicle aims to request ser-
vices from the service provider, this Registration Service generates a session
pseudonym enabling this user to exchange with the service provider while
protecting his privacy. In this system, the BC ledger is used to store the list
of authorized pseudonyms as well as their permissions and can be accessed by
the service providers, accelerating the authentication process. Moreover, this
solution, providing a new pseudonym for each new connection could provide
a higher level of privacy than the approach described in [53]. Nevertheless,
in this approach, a centralized Registration Service is used to manage the
registration phase and to generate the pseudonym of the vehicles, limiting
the benefits of the BC approach.

Discussion. Protecting the users’ privacy in the vehicular environment is an

important point. Indeed, huge volumes of data are generated and it could
be easy to track users. Different solutions have already been designed to
protect users’ privacy in carpooling ([51]), vehicular fog computing ([53]) or
cloud services ([46]) scenarios. In these papers are described three similar
approaches, enabling to generate pseudonyms guaranteeing the user privacy.
In [51], the proposed solution could also enable a privacy preserving locali-
sation based on the BC technology. Interesting ideas are also introduced in
[46, 53]. For example, to improve scalability, a BC nodes selection is pro-
posed in [53]. Similarly, in [46], a BC-based method enabling to generate
session pseudonyms is described. All these approaches provide partial BC-
based solutions. Indeed, none of these solutions define both an efficient and
decentralized system. Moreover, these different approaches raise questions

29
 Table 4: Comparison of the existing security and privacy preserving mechanisms
Application Services Approach Limits BC techno. BC nodes
Point of
Authentication Shared
failure Latency Own RSUs
(vehicles) ledger
[40]
Verification Lookup
Security
overhead Authentication function
Own RSUs
reduction (vehicles) Multiple
Scalability
[41] BC ledgers
Local
Clusters
PKI revocation
Authentication formation
accountability management Own RSUs
(vehicles)
[43] Multilayered
Security
BC
Handshake
Trust
Keys scheme
Authentication Overhead Cloud
management Transaction Own
(vehicles) Computation RSUs
[44] collection
time
time
BC-based
Data Access permission Security
management control management Own RSUs
[45, 46] (applications) Load Scalability
balancing
Anonymous
Private authentication Centralization
Privacy
carpooling scheme Own RSUs
preservation
[51] Anonymous Trust
localisation
Quick Users
Reliability
anonymous Privacy re-authentication RSUs
Own
authentication preservation Nodes Cloud
Complexity
[53] selection
Private BC-based
Centralization
services Privacy authentication RSUs
Own
access preservation Sessions Cloud
Scalability
[46] pseudonyms

related to the trustworthiness of the Certification nodes and this point should
be considered.

3.4. Comprehensive discussion

Because of the benefits of the BC technology, BC-based applications
mainly aim to improve trust, security, privacy and cooperation in vehicu-
lar network. Nevertheless, the vehicular communications are facing different
constraints including, limited throughput, storage and computational capa-
bilities, limited amount of available energy and latency. Thus, these chal-
lenges must be considered by the BC-based vehicular applications. Some
of these requirements have not been discussed yet, in particular energy ef-

30
ficiency and are presented in Section 4. However, for all other challenges,
solutions have already been proposed by the authors of the papers presented
above:

• Limited throughput capabilities: due to shadowing, fading and inter-

ference, the available throughput is limited in wireless communications
[54]. This limited available throughput could be an important limita-
tion for the deployment of BC ledgers as explained in [55]. Indeed, the
BC blocks must be exchanged between the different BC nodes, requir-
ing important throughput requirements. That is why different solutions
have already been proposed to design distributed ledgers meeting the
vehicular constraints. For example the authors of [41] proposed to split
the BC ledger into multiple BC ledgers managing different pieces of
information: certificates, admissions, authentications and revocations.
With this system, the vehicles should only manage two lighter BC
ledgers: authentications and revocations. It could reduce the amount
of data exchanged and, therefore, the required bandwidth. Another
solution, described in many papers, is to deploy the BC nodes at the
RSUs level. The communications between vehicles should not be dis-
turbed by the deployment of the BC technology. However, this could
not be a solution in the absence of RSUs. Thus, even if potential solu-
tions have already been considered, new solutions enabling to limit the
interactions between the BC nodes should be designed.

• Limited storage capabilities: the available storage capabilities within

the vehicles will be limited and as explained in [55], the size of a BC
ledger is constantly increasing. Thus, solutions are necessary to limit
the amount of storage resources required by the BC ledger. The so-
lution described in [41], enabling to deal with the limited throughput
could also be a way to reduce the storage requirements of the BC ledger
as this BC ledger is divided into multiple lighter BC ledgers. Another
approach, described in [53], is to limit the number of BC nodes. As
each BC node must store the BC ledger, limiting the number of BC
nodes will limit the amount of storage resources used by the BC net-
work. A third solution, introduced in [43] is to form clusters of vehicles
pre-processing data. With this system only relevant data are uploaded
to the BC ledger, limiting its size. Finally, a complementary solution
should be considered: Vehicular Cloud Computing. Indeed, Vehicular

31
 Cloud Computing could be a way to increase the amount of storage
space, simplifying the deployment and the management of BC ledgers.

• Limited computational capabilities: the traditional consensus algo-

rithms, such as Proof of Work, require important computational re-
sources [54] . They could not be efficiently deployed in vehicular en-
vironment, even considering the Vehicular Cloud Computing Technol-
ogy. Further existing algorithms, such as Proof-of-Stake, require less
resources. Nevetheless, these algorithms should be improved to deal
with the constraints of the vehicular environment: mobility, disconnec-
tions, etc. That is why, in many papers, new consensus algorithms,
considering the requirements of the vehicular environment, have al-
ready been proposed [32, 30, 31]. Nevertheless, so far, these algorithms
have not been deployed in realistic environment. Thus, designing and
implementing efficient consensus mechanism, enabling to deal with lim-
ited computational resources, is still an important challenge.

• Latency constraints: for many vehicular applications, including road

safety applications (cooperative collision warning, etc.), low data trans-
mission delays should be guaranteed. Thus, the performances of the
BC technology should be improved to deal with that. That is why the
authors of [44] defined a mechanism enabling to accelerate the block
generation process. This approach, using a mechanism monitoring the
transactions collection time, could be a way to reduce the latency re-
lated to the BC technology. Another solution, adopted in different
papers such as [31, 32], would be to define a multilayered BC network.
With this system, data is first of all transmitted to surrounding nodes
(vehicles, RSUs) forming a local BC network. As the number of BC
nodes is reduced, data is transmitted more rapidly. Moreover, only rel-
evant and local pieces of information are shared between these vehicles.

Thus, to deal with the constraints of the vehicular environment: latency

and computational, storage and communication limitations, different ap-
proaches have already been proposed. Nevertheless, none of these solutions
have been implemented and evaluated yet. Further work in this area is still
necessary and a global solution should be designed. Moreover, as described
in Section 4, other issues should be considered.

32
4. Open issues and future directions
As shown in Section 3, different BC-based applications have already been
designed and could improve the vehicular networks in terms of security, pri-
vacy, cooperation and trust establishment. Some requirements of the BC-
based applications have already been considered as shown in Section 3.4:
throughput, computational and storage capabilities as well as latency. How-
ever, to enable the integration of the BC technology within the vehicular
networks different points should still be considered. Moreover, due to the
evolution of the vehicular networks, future directions could be imagined.

4.1. Data-centric consensus

As noticed in [55], designing IoV-specific consensus mechanisms is also
an important challenge. Indeed, BC ledger aims to provide an efficient and
secured way to exchange data between users but the correctness of the data
sent by a user should be verified. Indeed, a malicious user could easily try to
upload incorrect data. The traditional consensus mechanism such as Proof
of Stake or Proof of Work have not been designed to deal with that. That is
why, as it has been shown in Section 3, different consensus algorithms, such
as [32, 31], have already been proposed to guarantee the data correctness.
Indeed, surrounding vehicles and historical data could be used to validate or
invalidate an information sent by a vehicle. Thanks to that, malicious nodes
should not be able to share information with the whole network. Neverthe-
less, these consensus algorithms still present different limitations, including
scalability and security. Therefore, to provide deployable solutions, they
must be improved.

4.2. Green Blockchain

The current BC technologies and consensus mechanisms present an im-
portant limitation: energy consumption. For example, the Proof-of-Work
algorithm requires important computational capabilities, implying an unnec-
essary use of energy [56]. Proof-of-Stake and Delegated Proof-of-Stake, other
well-known consensus protocols could be a way to reduce the computational
capabilities used by the consensus algorithm. However, the security level of
these mechanisms raises questions and improvements are still required [57].
Another important issue is related to the storage capabilities required by
the BC ledgers. Indeed, this also implies an important consumption due
to data transmission and data storage. That is why, lightweight BC-based

33
frameworks and lightweight BC-based ledgers are currently being designed
[58, 59]. Designing a lightweight BC solution is a necessary step to enable
the advent of this technology. That is why improving existing approaches
[58, 59] and designing new solutions is essential.

4.3. Blockchain platform management

As explained in Section 3.4, to deploy BC-based applications in vehicular
environment, different requirements should by considered: limited through-
put capabilities, limited storage capabilities, limited computation capabilities
and latency constraints. Indeed, as vehicles are mobile nodes with limited
resources, deploying BC applications and a BC network could be challenging
and a specific infrastructure should be designed [10]. That is why, to deal
with the constraints of the vehicular environment, different solutions are
being developed, including mobile BC enabling devices with limited com-
putation capabilities to access BC services [60] or sidechains [61] improving
the scalability of the network using local BCs. However, the deployment of
BC in mobile environment is still facing different issues such as BC ledger
update in mobile environments and resources management [62]. That is why,
to deploy BC networks in vehicular environments, an efficient management
of the updates of the BC ledger and an efficient deployment of the BC nodes,
considering the available resources, should be designed.

4.4. Performances evaluation

The integration of many technologies have already been proposed to im-
prove the performances of the vehicular networks (SDN, NFV, edge com-
puting, etc.) and BC technology is one of them. Nevertheless, for all these
technologies, designing and deploying a software enabling the evaluation of
their performances in an environment approaching as closely as possible the
real vehicular ecosystem is necessary. Indeed, the current performances eval-
uation of the proposed systems are mainly based on independent and specific
simulations and are not really meaningful. Thus, the feasability of these so-
lutions cannot be evaluated. That is why a benchmarking platform for the
vehicular networks would be necessary to compare and evaluate these solu-
tions, simulators based on the network simulator NS-3 are currently being
developed. Using this platform, it should also be possible to determine for
which kind of application each technology could be used. Indeed, for some
applications requiring low latency, high throughput or high responsiveness,
BC-based approaches may show some limits.

34
4.5. Designing new services
As explained in [63], using BC technology, the vehicle economy could be
enabled. Thanks to this technology, devices will be able to automatically ex-
change services and data. Moreover, without any financial institution, each
user will be able to manage its data, and to share this data as well as re-
sources (storage, computational, communication) in exchange of a financial
contribution [64]. That is why different kind of services, based on BC tech-
nology, have already been designed, including, autonomous electric vehicles’
refueling ([65]), fair edge services placement in multi-vendors scenarios ([66]),
post-accident analysis ([67]), liability attribution ([68]) and forensic investi-
gation ([69]). All these services still need to be improved. Moreover, based on
this technology and this environment new services and new use cases could
be imagined.

4.6. Integration in the future ecosystem

With IoV, different technologies should be integrated in vehicular net-
works: artificial intelligence, edge computing, Software Defined Networking
(SDN), etc. BC could also be complete and improve these technologies. As
shown in Section 3, BC could be a way to secure the SDN architecture [3].
Similarly, BC thanks to its transparency and its immutability could be a way
to improve IA, through decentralization for example [70], and to complete
AI techniques, to detect deepfake videos among other things [71]. BC could
also be a way to improve big data analytic [72] and could be associated to
Fog computing nodes [73] or could even improve the security of these nodes
as shown in Section 3 [53]. Thus, the applications of the BC technology are
numerous and this technology could be applied to different domains. That
is why it could be interesting to define relevant use cases combining BC and
other technologies which should be integrated in vehicular networks.

5. Conclusions
Security (authentication, access control, etc.), users’ privacy preserva-
tion and trust establishment are important challenges for the vehicular net-
works. Blockchain, a popular distributed ledger technology, aiming to pro-
vide a secured, trustworthy and scalable environment could be an efficient
way to satisfy these needs. That is why, in this paper, we presented and
compared the existing applications of the Blockchain technology trying to
improve security, privacy and trust in vehicular environments. Moreover,

35
using a Blockchain application, cryptocurrencies, the vehicles’ cooperation
and the inter-vehicles resources sharing (computational, storage, communi-
cation) could be improved in vehicular networks. Thus, the most impor-
tant Blockchain-based incentive mechanisms are introduced in this paper.
Moreover, for each Blockchain-based application (privacy, security, trust, in-
centive), we propose different improvements. Finally, the main challenges
related to the integration of the Blockchain technology within the vehicu-
lar networks (performances evaluation, vehicular networks constraints, etc.),
current and future directions, such as new services enabled by the Blockchain
technology, are discussed.

References
[1] O. Kaiwartya, A. H. Abdullah, Y. Cao, A. Altameem, M. Prasad, C.-
T. Lin, X. Liu, Internet of vehicles: Motivation, layered architecture,
network model, challenges, and future aspects, IEEE Access 4 (2016)
5356–5373 (2016).

[2] E. E. ETSI, 302 665 v1. 1.1: Intelligent transport systems (its), commu-
nications architecture, European Standard (Telecommunications Series)
(2010).

[3] L. Mendiboure, M. A. Chalouf, F. Krief, Towards a 5G

vehicular architecture, in: 14th International Workshop,
Nets4Cars/Nets4Trains/Nets4Aircraft 2019, Springer, 2019 (2019).

[4] S. Tanwar, J. Vora, S. Tyagi, N. Kumar, M. S. Obaidat, A system-

atic review on security issues in vehicular ad hoc network, Security and
Privacy 1 (5) (2018) e39 (2018).

[5] P. Wex, J. Breuer, A. Held, T. Leinmuller, L. Delgrossi, Trust issues

for vehicular ad hoc networks, in: VTC Spring 2008-IEEE Vehicular
Technology Conference, IEEE, 2008, pp. 2800–2804 (2008).

[6] M. C. Dacier, H. König, R. Cwalinski, F. Kargl, S. Dietrich, Security

challenges and opportunities of software-defined networking, IEEE Se-
curity & Privacy 15 (2) (2017) 96–100 (2017).

36
 [7] L. Mendiboure, M. A. Chalouf, F. Krief, Towards a blockchain-based
sd-iov for applications authentication and trust management, in: Inter-
national Conference on Internet of Vehicles, Springer, 2018, pp. 265–277
(2018).

[8] Y. Park, C. Sur, H. Kim, K.-H. Rhee, A reliable incentive scheme using
bitcoin on cooperative vehicular ad hoc networks, IT Converg. Pract 5
(2017) 34–41 (2017).

[9] F. Restuccia, S. D. Kanhere, T. Melodia, S. K. Das, Blockchain for the

internet of things: Present and future, arXiv preprint arXiv:1903.07448
(2019).

[10] M. A. Ferrag, M. Derdour, M. Mukherjee, A. Derhab, L. Maglaras,

H. Janicke, Blockchain technologies for the internet of things: Research
issues and challenges, IEEE Internet of Things Journal 6 (2) (2018)
2188–2204 (2018).

[11] J. Xie, H. Tang, T. Huang, F. R. Yu, R. Xie, J. Liu, Y. Liu, A survey

of blockchain technology applied to smart cities: Research issues and
challenges, IEEE Communications Surveys & Tutorials (2019).

[12] R. Iqbal, T. A. Butt, M. Afzaal, K. Salah, Trust management in so-

cial internet of vehicles: Factors, challenges, blockchain, and fog solu-
tions, International Journal of Distributed Sensor Networks 15 (1) (2019)
1550147719825820 (2019).

[13] X. Wang, S. Mao, M. X. Gong, An overview of 3gpp cellular vehicle-to-

everything standards, GetMobile: Mobile Computing and Communica-
tions 21 (3) (2017) 19–25 (2017).

[14] S. Chen, J. Hu, Y. Shi, Y. Peng, J. Fang, R. Zhao, L. Zhao, Vehicle-to-

everything (v2x) services supported by lte-based systems and 5g, IEEE
Communications Standards Magazine 1 (2) (2017) 70–76 (2017).

[15] S. Nakamoto, et al., Bitcoin: A peer-to-peer electronic cash system

(2008).

[16] A. Baliga, Understanding blockchain consensus models, in: Persistent,

2017 (2017).

37
[17] G. Wood, et al., Ethereum: A secure decentralised generalised transac-
tion ledger, Ethereum project yellow paper 151 (2014) 1–32 (2014).

[18] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis,

A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich, et al.,
Hyperledger fabric: a distributed operating system for permissioned
blockchains, in: Proceedings of the Thirteenth EuroSys Conference,
ACM, 2018, p. 30 (2018).

[19] M. Whaiduzzaman, M. Sookhak, A. Gani, R. Buyya, A survey on vehic-

ular cloud computing, Journal of Network and Computer applications
40 (2014) 325–344 (2014).

[20] Y. Park, C. Sur, K.-H. Rhee, A secure incentive scheme for vehicular
delay tolerant networks using cryptocurrency, Security and Communi-
cation Networks 2018 (2018).

[21] L. Alouache, N. Nguyen, M. Aliouat, R. Chelouah, Credit based in-

centive approach for v2v cooperation in vehicular cloud computing, in:
International Conference on Internet of Vehicles, Springer, 2018, pp.
92–105 (2018).

[22] M. Singh, S. Kim, Introduce reward-based intelligent vehicles communi-

cation using blockchain, in: 2017 International SoC Design Conference
(ISOCC), IEEE, 2017, pp. 15–16 (2017).

[23] M. Singh, S. Kim, Trust bit: Reward-based intelligent vehicle commina-

tion using blockchain paper, in: 2018 IEEE 4th World Forum on Internet
of Things (WF-IoT), IEEE, 2018, pp. 62–67 (2018).

[24] L. Li, J. Liu, L. Cheng, S. Qiu, W. Wang, X. Zhang, Z. Zhang, Cred-

itcoin: A privacy-preserving blockchain-based incentive announcement
network for communications of smart vehicles, IEEE Transactions on
Intelligent Transportation Systems 19 (7) (2018) 2204–2220 (2018).

[25] P. Isenberg, C. Kinkeldey, J.-D. Fekete, Exploring entity behavior on

the bitcoin blockchain, in: VIS 2017-IEEE Conference on Visualization,
2017, pp. 1–2 (2017).

38
[26] M. Bartoletti, L. Pompianu, An empirical analysis of smart contracts:
platforms, applications, and design patterns, in: International Confer-
ence on Financial Cryptography and Data Security, Springer, 2017, pp.
494–509 (2017).

[27] L. Mendiboure, M. A. Chalouf, F. Krief, A sdn-based pub/sub mid-

dleware for geographic content dissemination in internet of vehicles,
in: 88th IEEE Vehicular Technology Conference, VTC Fall 2019, USA,
September 22-25, 2019, IEEE, 2019 (2019).

[28] Z. Hong, Z. Wang, W. Cai, V. Leung, Blockchain-empowered fair com-

putational resource sharing system in the d2d network, Future Internet
9 (4) (2017) 85 (2017).

[29] Z. Yang, K. Zheng, K. Yang, V. C. Leung, A blockchain-based reputation

system for data credibility assessment in vehicular networks, in: 2017
IEEE 28th Annual International Symposium on Personal, Indoor, and
Mobile Radio Communications (PIMRC), IEEE, 2017, pp. 1–5 (2017).

[30] Z. Yang, K. Yang, L. Lei, K. Zheng, V. C. Leung, Blockchain-based

decentralized trust management in vehicular networks, IEEE Internet
of Things Journal (2018).

[31] R. Shrestha, R. Bajracharya, S. Y. Nam, Blockchain-based message dis-

semination in vanet, in: 2018 IEEE 3rd International Conference on
Computing, Communication and Security (ICCCS), IEEE, 2018, pp.
161–166 (2018).

[32] Y.-T. Yang, L.-D. Chou, C.-W. Tseng, F.-H. Tseng, C.-C. Liu,
Blockchain-based traffic event validation and trust verification for
vanets, IEEE Access 7 (2019) 30868–30877 (2019).

[33] J. Kang, R. Yu, X. Huang, M. Wu, S. Maharjan, S. Xie, Y. Zhang,

Blockchain for secure and efficient data sharing in vehicular edge com-
puting and networks, IEEE Internet of Things Journal (2018).

[34] M. Wagner, B. McMillin, Cyber-physical transactions: A method for

securing vanets with blockchains, in: 2018 IEEE 23rd Pacific Rim Inter-
national Symposium on Dependable Computing (PRDC), IEEE, 2018,
pp. 64–73 (2018).

39
[35] M. Awais Hassan, U. Habiba, U. Ghani, M. Shoaib, A secure message-
passing framework for inter-vehicular communication using blockchain,
International Journal of Distributed Sensor Networks 15 (2) (2019)
1550147719829677 (2019).

[36] V. Ortega, F. Bouchmal, J. F. Monserrat, Trusted 5g vehicular networks:

Blockchains and content-centric networking, IEEE Vehicular Technology
Magazine 13 (2) (2018) 121–127 (2018).

[37] Z. Lu, W. Liu, Q. Wang, G. Qu, Z. Liu, A privacy-preserving trust

model based on blockchain for vanets, IEEE Access 6 (2018) 45655–
45664 (2018).

[38] C. Jiacheng, Z. Haibo, Z. Ning, Y. Peng, G. Lin, S. Xuemin, Software de-

fined internet of vehicles: architecture, challenges and solutions, Journal
of communications and information networks 1 (1) (2016) 14–26 (2016).

[39] M. Al-Bassam, Scpki: a smart contract-based pki and identity system,

in: Proceedings of the ACM Workshop on Blockchain, Cryptocurrencies
and Contracts, ACM, 2017, pp. 35–40 (2017).

[40] N. Malik, P. Nanda, A. Arora, X. He, D. Puthal, Blockchain based

secured identity authentication and expeditious revocation framework
for vehicular networks, in: 2018 17th IEEE International Conference On
Trust, Security And Privacy In Computing And Communications/12th
IEEE International Conference On Big Data Science And Engineering
(TrustCom/BigDataSE), IEEE, 2018, pp. 674–679 (2018).

[41] N. Lasla, M. Younis, W. Znaidi, D. B. Arbia, Efficient distributed ad-

mission and revocation using blockchain for cooperative ITS, in: 2018
9th IFIP International Conference on New Technologies, Mobility and
Security (NTMS), IEEE, 2018, pp. 1–5 (2018).

[42] W. Whyte, A. Weimerskirch, V. Kumar, T. Hehn, A security credential

management system for v2v communications, in: 2013 IEEE Vehicular
Networking Conference, IEEE, 2013, pp. 1–8 (2013).

[43] R. W. van der Heijden, F. Engelmann, D. Mödinger, F. Schönig,

F. Kargl, Blackchain: Scalability for resource-constrained accountable
vehicle-to-x communication, in: Proceedings of the 1st Workshop on

40
 Scalable and Resilient Infrastructures for Distributed Ledgers, ACM,
2017, p. 4 (2017).

[44] A. Lei, H. Cruickshank, Y. Cao, P. Asuquo, C. P. A. Ogah, Z. Sun,

Blockchain-based dynamic key management for heterogeneous intelli-
gent transportation systems, IEEE Internet of Things Journal 4 (6)
(2017) 1832–1843 (2017).

[45] R. Sharma, S. Chakraborty, B2vdm: Blockchain based vehicular data

management, in: 2018 International Conference on Advances in Com-
puting, Communications and Informatics (ICACCI), IEEE, 2018, pp.
2337–2343 (2018).

[46] R. Sharma, S. Chakraborty, Blockapp: Using blockchain for authenti-

cation and privacy preservation in iov, in: 2018 IEEE Globecom Work-
shops (GC Wkshps), IEEE, 2018, pp. 1–6 (2018).

[47] D. D. F. Maesa, P. Mori, L. Ricci, Blockchain based access control, in:

IFIP International Conference on Distributed Applications and Interop-
erable Systems, Springer, 2017, pp. 206–220 (2017).

[48] A. Ouaddah, A. Abou Elkalam, A. Ait Ouahman, Fairaccess: a new

blockchain-based access control framework for the internet of things,
Security and Communication Networks 9 (18) (2016) 5943–5964 (2016).

[49] M. Staples, S. Chen, S. Falamaki, A. Ponomarev, P. Rimba, A. Tran,

I. Weber, X. Xu, J. Zhu, Risks and opportunities for systems using
blockchain and smart contracts. data61 (2017).

[50] V. Costan, S. Devadas, Intel sgx explained., IACR Cryptology ePrint

Archive 2016 (086) (2016) 1–118 (2016).

[51] M. Li, L. Zhu, X. Lin, Efficient and privacy-preserving carpooling using

blockchain-assisted vehicular fog computing, IEEE Internet of Things
Journal (2018).

[52] Y. Zheng, M. Li, W. Lou, Y. T. Hou, Location based handshake and

private proximity test with location tags, IEEE Transactions on De-
pendable and Secure Computing 14 (4) (2015) 406–419 (2015).

41
[53] Y. Yao, X. Chang, J. Mišć, V. B. Mišć, L. Li, Bla: Blockchain-assisted
lightweight anonymous authentication for distributed vehicular fog ser-
vices, IEEE Internet of Things Journal (2019).

[54] T. Mekki, I. Jabri, A. Rachedi, M. ben Jemaa, Vehicular cloud networks:

Challenges, architectures, and future directions, Vehicular Communica-
tions 9 (2017) 268–280 (2017).

[55] X. Wang, X. Zha, W. Ni, R. P. Liu, Y. J. Guo, X. Niu, K. Zheng, Survey

on blockchain for internet of things, Computer Communications (2019).

[56] F. Saleh, Blockchain without waste: Proof-of-stake, Available at SSRN

3183935 (2019).

[57] I.-C. Lin, T.-C. Liao, A survey of blockchain security issues and chal-
lenges., IJ Network Security 19 (5) (2017) 653–659 (2017).

[58] A. Dorri, S. S. Kanhere, R. Jurdak, P. Gauravaram, Lsb: A

lightweight scalable blockchain for iot security and privacy, arXiv
preprint arXiv:1712.02969 (2017).

[59] Y. Liu, K. Wang, Y. Lin, W. Xu, Lightchain: A lightweight blockchain

system for industrial internet of things, IEEE Transactions on Industrial
Informatics (2019).

[60] Z. Xiong, Y. Zhang, D. Niyato, P. Wang, Z. Han, When mobile

blockchain meets edge computing, IEEE Communications Magazine
56 (8) (2018) 33–39 (2018).

[61] L. Kan, Y. Wei, A. H. Muhammad, W. Siyuan, G. Linchao, H. Kai,

A multiple blockchains architecture on inter-blockchain communication,
in: 2018 IEEE International Conference on Software Quality, Reliability
and Security Companion (QRS-C), IEEE, 2018, pp. 139–145 (2018).

[62] R. Yang, F. R. Yu, P. Si, Z. Yang, Y. Zhang, Integrated blockchain and

edge computing systems: A survey, some research issues and challenges,
IEEE Communications Surveys & Tutorials 21 (2) (2019) 1508–1532
(2019).

42
[63] B. Leiding, W. V. Vorobev, Enabling the vehicle economy us-
ing a blockchain-based value transaction layer protocol for ve-
hicular ad-hoc networks, URL: https://uploads-ssl. webflow.
com/5a4ea18a81f55a00010bdf45/5b69e53263e2a6076124ecbe Chorus-
Mobility-WP–v1. 0.1. pdf (2018).

[64] A. Suliman, Z. Husain, M. Abououf, M. Alblooshi, K. Salah, Monetiza-

tion of iot data using smart contracts, IET Networks 8 (1) (2018) 32–37
(2018).

[65] A. R. Pedrosa, G. Pau, Chargeltup: On blockchain-based technologies

for autonomous vehicles, in: Proceedings of the 1st Workshop on Cryp-
tocurrencies and Blockchains for Distributed Systems, ACM, 2018, pp.
87–92 (2018).

[66] H. Zhu, C. Huang, J. Zhou, Edgechain: blockchain-based multi-vendor

mobile edge application placement, in: 2018 4th IEEE Conference on
Network Softwarization and Workshops (NetSoft), IEEE, 2018, pp. 222–
226 (2018).

[67] M. Cebe, E. Erdin, K. Akkaya, H. Aksu, S. Uluagac, Block4forensic: An

integrated lightweight blockchain framework for forensics applications of
connected vehicles, IEEE Communications Magazine 56 (10) (2018) 50–
57 (2018).

[68] C. Oham, S. S. Kanhere, R. Jurdak, S. Jha, A blockchain based li-

ability attribution framework for autonomous vehicles, arXiv preprint
arXiv:1802.05050 (2018).

[69] M. M. Hossain, R. Hasan, S. Zawoad, Trust-iov: A trustworthy forensic

investigation framework for the internet of vehicles (iov)., in: ICIOT,
2017, pp. 25–32 (2017).

[70] K. Salah, M. H. U. Rehman, N. Nizamuddin, A. Al-Fuqaha, Blockchain

for ai: review and open research challenges, IEEE Access 7 (2019) 10127–
10149 (2019).

[71] H. R. Hasan, K. Salah, Combating deepfake videos using blockchain and

smart contracts, IEEE Access 7 (2019) 41596–41606 (2019).

43
[72] M. H. ur Rehman, I. Yaqoob, K. Salah, M. Imran, P. P. Jayaraman,
C. Perera, The role of big data analytics in industrial internet of things,
Future Generation Computer Systems 99 (2019) 247–259 (2019).

[73] R. Almadhoun, M. Kadadha, M. Alhemeiri, M. Alshehhi, K. Salah, A

user authentication scheme of iot devices using blockchain-enabled fog
nodes, in: 2018 IEEE/ACS 15th International Conference on Computer
Systems and Applications (AICCSA), IEEE, 2018, pp. 1–8 (2018).

Appendix

A.1 Acronyms
ADAS Advanced Driver Assistance System.

AI Artificial Intelligence.

BARS Blockchain-based Anonymous Reputation System.

BC Blockchain.

BS Base Station.

CA Certificate Authority.

DoS Denial-of-Service.

DPoS Delegated Proof-of-Stake.

FICA eFficient and prIvacy-presering CArpooling.

IoV Internet of Vehicles.

ITS Intelligent Transportation System.

NFV Network Function Virtualization.

44
 NS Network Simulator.

P2P Peer-to-Peer.
pBFT practical Byzantine Fault Tolerance.
PKI Public Key Infrastructure.
PoA Proof-of-Authority.
PoE Proof-of-Event.
PoET Proof-of-Elapsed-Time.
PoS Proof-of-Stake.
PoW Proof-of-Work.

QoS Quality of Service.

RSU Road Side Unit.

SCMS Security Credential Management System.

SD Software Defined.
SDN Software Defined Networking.
SGX Software Guard eXtensions.

V2D Vehicle-to-Device.
V2I Vehicle-to-Infrastructure.
V2N Vehicle-to-Network.
V2P Vehicle-to-Pedestrian.
V2V Vehicle-to-Vehicle.
VCC Vehicular Cloud Computing.
VDTN Vehicular Delay Tolerant Network.
VFC Vehicular Fog Computing.

45

View publication stats