# A Decentralized Blockchain-Based Trust Management Framework for Vehicular Ad Hoc Networks
## 3 Simulation Results and Discussion
### Results
As depicted in Figure 8 for both frameworks the average trust metric of malicious vehicles decreases when the percentage of malicious vehicles increases. This result is expected since the percentage of non-reliable alert messages increases. Nevertheless, the proposed BC-TMF outperforms NBC-TMV mainly in the case of a high percentage of malicious vehicles. It is obvious that it is about 0.1 for BC-TMF for 25% of malicious vehicles while it is 0.2 for NBC-TMV. This result is due to the aggregation process in BC-TMF that avoids overestimating the trust metric of malicious vehicles. Another reason behind the outperformance of the proposed BC-TMF is the update of the trust metrics performed in miner vehicles compared to the NBC-TMV framework where it is performed in the RSUs. However, RSUs are not deployed everywhere on the road, so the aggregation process and block creation may be delayed in NBC-TMV, consequently, the trust metrics are not updated timely. Figure 9, portrays the variance of the global trust metric for the non-malicious vehicles as a function of addBlockTimer for different speed and sendTransTimer values. It is obvious from Figure 9 that the variance does not exceed 0.01 in all scenarios, which confirms the consistency of the obtained trust metrics presented in Figures 4 and 5 shown above. Similarly, Figure 10 portrays the variance of the global trust metric of malicious vehicles as a function of PM, it is computed as in Equation (4) below:  
\[variance_{Malicious}=\frac{\sum_{i=1}^{N}(TM(i)-AvgM)^{2}}{M} \tag{4}\]  
where \(M\) is the total number of malicious vehicles, \(AvgM\) is the average global trust metric for malicious vehicles, and \(TM(i)\) is the global trust metric of the malicious vehicle \(i\). We observe in Figure 10 that the variance does not exceed 0.18. It passes from around 0.18 for PM = 0.1 to around 0 for PM = 1 and addBlockTimer = 350 s. Additionally, it is obvious that addBlockTimer slightly affects the variance. It passes from 0.18 for addBlockTimer  
Figure 10: The variance of the trust metrics for malicious vehicles vs. PM, sendTransTimer = 100 s.  
Figure 9: The variance of the trust metrics for non-malicious vehicles vs. addblockTimer (s). equal to 350 s to around 0.15 in the case of PM = 0.1. The value of addBlockTimer = 150 s seems to be the most appropriate to get lower trust metrics for malicious vehicles. This result confirms once again, the excellent capability of BC-TMF to compute exact and consistent trust metrics for malicious vehicles. Let us now consider Figure 11 where we portray the fraction of malicious vehicles that reach a trust metric TM = 0.8 as a function of PM denoted _PS_(8) and computed as shown in Equation (5) below:  
\[PS(8)=\frac{\text{Number of vehicles (PM }>0\text{ and TM }\geq 0.8)}{\text{Total number of malicious vehicles}} \tag{5}\]  
This metric (_PS_(8)) is interesting because it will be considered later as selection criteria of the miners. Let us recall that in the current work, the miners are a randomly selected set of vehicles. In Figure 11, the results computed using BC-TMF are compared to the results computed using EDTCP [15] where each vehicle has many local trust metrics saved in its monitors, no aggregation or sharing techniques are used. We remark in Figure 11 the huge difference between the results obtained for the proposed BC-TMF compared to EDTCP mainly for PM \(\geq\) 0.7. Particularly, _PS_(8) is less than 0.02 for BC-TMF. However, it goes to 0.5 for EDTCP, which means that for EDTCP about half of the malicious vehicles having (PM = 1) reaches a trust metric higher than 0.8. Again BC-TMF computes accurate trust metrics, particularly for malicious vehicles.