# Blockchain-Based Authentication in Internet of Vehicles: A Survey
## 6 Future Research Directions and Open Challenges
### Efficient Design of Blockchain-Assisted IoV Authentication  
Despite the many advantages that blockchain technology has brought to the field of IoV authentication represented by a decentralized, autonomous, fault-tolerant, and more secured authentication protocols which are all properties that are required by any efficient authentication process, many challenges also arise with blockchains when being employed for authentication in environments with high performance expectations and critical security requirements such as the IoV. Most of these challenges are associated with the consensus mechanisms used by the blockchain, as different consensus protocols show uneven levels of support for the various IoV requirements such as scalability, fault tolerance, power consumption, as well as real-time response. 1. Scalability: The scalability of a consensus mechanism depends on its way of reaching the consensus, whether it is Proof-based or Vote-based approach. Since Proof-based consensus protocols such as PoW and PoS do not require all the network entities to submit their individual decisions on the information to be verified, their scalability is not affected with more nodes being added to the network as at the end of the day they allocate the role of announcing the conclusions of all the participating nodes about the information to a single node. Thus, they can be suitable for large-scale networks such as the IoV environment. However, the huge amount of power consumed by these Proof-based consensus approaches undermines their efficiency and their suitability for all IoV environments especially the resource constrained ones. On the other hand, the Vote-based blockchain consensus making approaches such as the PBFT consensus mechanism exhibit negligible power consumption, yet their scalability is restricted to small-scale networks with limited number of nodes since all the nodes in the network are engaged in transaction verification and should submit their individual votes in order to reach consensus. For such a trade-off that is faced by the existing consensus mechanisms when employing blockchain for IoV, the challenge is represented in how to tune and improve these mechanisms in the future to be able to support efficient authentication in the highly scalable resource constrained IoV environments. 2. Fault tolerance: the different blockchain consensus mechanisms have uneven capabilities in terms of how many faulty nodes each can tolerate while still being able to ensure the integrity of the participants and data in the network. In such wide and publicly opened environments as IoV where a variety of attacks can be encountered in which attackers impersonate the authentic nodes, high fault-tolerant consensus protocols should be adopted to ensure that the integrity of the communicated data can still be guaranteed even if the authenticity of a considerable percentage of participants is compromised. Some existing consensus protocols such as PoW can offer the high fault tolerance required for IoV environments; however, as discussed before it exhibits a large power consumption which can be an issue when used for authentication in some resource constrained IoV platforms. Thus, the need appears for developing new consensus making approaches that can guarantee high fault tolerance for the vulnerable IoV arrangements while maintaining an acceptable level of power consumption. Alternatively, mitigating the power consumption effect of the already existing blockchain consensus protocols by finding other solutions such as the charge-as-go solution represented by providing mobile charging units to charge the vehicles' batteries as they move to be able to tolerate the high power consumed during the authentication is a challenging proposal to be explored in the future. 3. Communication mode: Due to the two types of communication used by the different consensus mechanisms which are synchronous and asynchronous communication modes, different time responses are expected.