## 5 System Construction
### System Setup
## 7 Discussion

Figure 5a,b shows that the proposed system incurs a steady packet delay with an increasing number of nodes whereas other models show sudden hikes in packet delay with more nodes being added. Particularly increasing nodes beyond 200 makes other models show greater delays. This is due to the fact that light-weight hash and Salt functions have been used to generate the proof only once for every node. The simulation results show that packets were quickly processed in a short time as compared to other models. From Figure 6a,b it is evident that the packet loss of the proposed system is much lower with the increasing number of nodes, although slight jumps have been observed between 300-400 but they turn to steady with further increases. On the other hand, the other benchmarks used do not perform well in their performance with an increasing number of nodes. This is because the zk-SNARK is generated once, reducing the time of computation and making the algorithm stronger against the attack. The other models are not strong nor capable enough to protect the network from a DDoS attack with the increasing number of nodes, although the result of all the compared models are almost same with a minor number of nodes. With the increase in the number of nodes, the decrease in the packet delivery is observed in the presence of a DDoS attack as shown in Figure 7a,b. This trend is found in general in all cases. However, we observed that rest of the models (used as benchmarks for performance comparison) had a limited number of nodes between 100-200. The simulation results, however, show an increasing number of nodes beyond 200, and the performance of other models show a steady decrease in average packet delivery. This communication channel becomes congested with both the malicious and valid nodes trying to transmit data across the network. A higher packet drop is observed in all the cases including ours once the number of nodes increases but this impact turns steady in our proposed model and the packets drop becomes lesser. This is because our zk-SNARK algorithm takes less time in computation and is less intense in calculations, which helped in reducing the packet delay and as a result results in higher packets delivery as compared to other models. The compared models showed a drastic slump in packet delivery when the number of nodes started increasing from 80, with their performance ultimately deteriorating, the justification being the algorithms used in the other models were not capable of protecting the communication channel with an increasing number of nodes in the presence of DDoS and, hence, resulted in a higher loss of packets. Most of the security models presented in the literature are based on assumptions, i.e., the majority of the nodes within the blockchain network, particularly RSU, are honest [33] and not compromised, but our model does not work on any sort of honest assumption. This helps in devising a broader threat model. Since blockchain is open for all the members on the blockchain network to view the transactions, it can reveal the privacy of users/vehicles and also help in tracking their location. The threat model for the proposed system is as follows:

Threat (1) Vehicles Showing Malicious Behavior: A vehicle may try to avoid authentication within the blockchain network and may attempt to send messages to other vehicles. Messages from a vehicle are sent along with the normal identification of the vehicle such as (VID), which is the registration number/vehicle plate number and digital signature of vehicle once they are rejected. The transmitted message should be concealed within the digital signature and must include the 'PK' of the vehicle and the proof '\(\pi\)' in order to be verified by the blockchain. Therefore, any message containing simply 'VID' concealed within the digital signature will be rejected straightaway. Malicious vehicles can also send messages containing 'PK' but missing the proof '\(\pi\)' concealed within the digital signature of the vehicle.