## 3 Problem Formulation  
The system model of the proposed system is shown in Figure 2.  
The proposed system combines blockchain, smart contract, and zk-SNARK to achieve secure data communication and the privacy-preserving of individuals and vehicles. Four major elements are involved in this system model: (i) Vehicles, (ii) CA, (iii) RSU, and (iv) blockchain. Their functions are described as follows:  
* Vehicles: CAV acts as a prover in this system who wants to share data with RSU or any other CAV. The prover requests the registration identity from the certification authority to take part in valid data sharing/communication.
* CA: is mainly a trusted Government organization that is responsible for issuing registration identities to vehicles and users. CA is also responsible for the specification of the requirements/function within the smart contract that needs to be fulfilled by the CAV before allowing it to start data sharing with another CAV.
* RSU: major roadside infrastructure that is responsible for authorizing the identity of CAV and signaling all other CAVs, allowing for the authenticity of a particular CAV before allowing it to start data sharing.
* Blockchain: stores smart contracts which are rules/requirements/functions to be fulfilled by any communicating CAV. It is also responsible for storing the communication between CAVs as transactions and is distributed over the blockchain network.  
A vehicle (prover) requests CA for registration and sends the identity information such as the registration number of the vehicle to CA. CA is responsible for the initialization of the system and the proof verification that allows a CAV to enter the network and start communicating with other CAVs. Once the registration identity has been received by the prover, it sends the request along with a proof '\(\pi\)' to CA, for verification of its identity and asks for permission to allow communication. The smart contract approves/rejects the requests for the vehicle by matching them with the information stored in the Merkle tree by the CA and responds to CA and also nearby RSU. RSU then signals all neighboring vehicles and RSUs about the status of the prover and also allows the prover to start communicating with other CAVs if its status is verified. The prover starts communicating with neighboring CAVs and the communication is monitored and saved by the nearby RSU. That communication is then stored on blockchain as a transaction which is then distributed over the Blockchain network for all the nodes to save/update the record. List of acronyms is provided in Table 1.  
The following design goals are to be realized under our proposed model:  
Goal (1) Anonymity and Unlinkability: The privacy of vehicles needs to be preserved, which means the vehicles must be anonymous such that any malicious RSU/vehicle or the cyber attacker may not trace the real identity of vehicles. In addition to this, the driving trajectory, driving history, and driving aptitude must not be traced by any malicious entity such that the location of a particular vehicle may not be inferred.  
Goal (2) Security against Single Point of Failure: The proposed system must resist a single point of failure attacks.  
Goal (3) Security against DDoS and Eclipse Attacks: The proposed system must resist DDoS and Eclipse attacks.  
Goal (4) Tracing Malicious Entity: Vehicles are more concerned about their privacy and not just security when they require entering some network. Anonymity is required to protect the real identities of CAVs so that specific vehicle may not get hit. However, a malicious CAV needs to be detected, which creates a challenge for the proposed system.  
Figure 2: Security and privacy using zk-SNARK over blockchain-proposed architecture.