# A Decentralized Blockchain-Based Trust Management Framework for Vehicular Ad Hoc Networks
## 2 Methods  
### Overview of BC-TMF  
The proposed framework aims to compute, store, and publish the trust metrics of the vehicles based on the credibility of their messages. Each vehicle will have only one global trust metric at a given time, shared between all the vehicles in the network. This will avoid the cold start problem and expedite the authentication of the reported events in real-time. Moreover, due to the integrity provided by blockchain technology, the trust metrics will be stored in a secure and reachable ledger. In the context of safety applications in VANETs, each vehicle traveling on the road disseminate and forward periodic alerts about the encountered events like traffic crowds and accidents. These alerts will fluidize the traffic, make far vehicles aware of the road state and allow drivers to make timely decisions [2]. Nevertheless, some malicious vehicles may deliberately disseminate forged alerts about non-existing events or alter the content of alerts reporting the real events. In the current model, two types of vehicles are distinguished: malicious and non-malicious vehicles. The probability for vehicle \(v\) to be malicious is denoted PM(v). It is a value in the interval (0-1). All malicious vehicles have their PM strictly greater than 0: PM > 0. However, non-malicious vehicles have PM = 0. On one hand, if a malicious vehicle perceives an event on the road, it may alter the alerts reporting this real event with probability PM. Similarly, it may alter all the forwarded alerts with the same probability. On the other hand, a malicious vehicle may forge alerts about non-real events with probability PM. The primary objective of the proposed framework is to compute the trust metrics of malicious and non-malicious vehicles. These trust metrics should reflect the real behavior of the vehicles. A malicious vehicle should never reach the highest trust level. In the same way, a non-malicious vehicle must have high trust metrics. In the proposed BC-TMF, two trust metric types are considered: a local trust metric and a global trust metric. The local trust metric is a subjective value computed by a monitor about a target vehicle based on its own experience with it. The global trust metric is an aggregated trust metric computed by the miner about each vehicle based on local trust metrics received from the monitors, it is stored in the blockchain. The local trust metric of vehicle v, calculated by vehicle m, noted \(Tm(v)\) is defined as a value in the interval (0-1). The local trust metric of \(v\) relies on the credibility of its messages sent to m. Besides, the trust metric evaluation is based on direct experiences with target vehicles. Each vehicle asses the trust metric of its neighbors based on the received alerts subjectively. It is worth noting that the local trust metrics are asymmetric: \(Tm(v)\) is different and independent from \(Tv(m)\). In the proposed BC-TMF, blockchain technology is used to store the trust values of vehicles and make them reachable by all other vehicles in the network. Contrary to many existing frameworks where the RSUs serve as miners [18, 22], in the proposed approach, a public blockchain is considered, where the miners are a set of vehicles elected randomly on the road. Actually, it is not very practical to build the framework on RSUs because it is very expensive to deploy many RSUs along the roads, particularly in rural scenarios. More importantly, the RSUs are vulnerable to physical attacks. As illustrated in Figure 1, the proposed BC-TMF goes through three main phases. In the first phase, the local trust metrics of the vehicles are evaluated by their neighbors. In the second phase, the obtained local trust metrics are shared with the miners, which are responsible for the aggregation to compute a global trust metric for each vehicle in its neighborhood. In the third phase, the miners generate and validate their blocks, then compete to add them to the blockchain. The following sections describe the different phases of the framework.