## 4 Experiment Setup and Results  
Hyperledger Fabric was selected for the implementation of blockchain-based IoV. The designed network consists of three categories including peer nodes, ordering services, and law enforcement departments. First, we selected the database for Fabric, and selected the Level database (DB) for the state database. After selecting the database and organizations, the dual-headed certificate was adopted as the authority that involves two CAs. One TLS CA is responsible for secure communications and generating TLS certificates. The other CA is an organizational CA, which is responsible for generating the admin certificates of an organization. After deployment of CAs, the channels are deployed and configured for the privacy of transactions, so that members on the other channels cannot access the transactions. The use of firewalls is also necessary for the deployment of IoV because nodes that belong to an organization can require access to other organizations; thus, there is a need for the configuration of advanced networking. The docker is deployed for peer nodes and other entities on the laptop. Then, the volumes are mounted for external entities where the entities are placed. Due to limited space, we used one channel. Nonetheless, the resources must be monitored to ensure that there is sufficient space for the blockchain and the database. In Hyperledger Fabric, CA is the first entity that must be deployed because the certificates of the nodes must be created before creation of the nodes themselves to identify who is the admin of this node.  
The dual-headed CA is used based on different geographical locations. One CA is used for the MSP of the organization for enrollment of any node that is owned by that organization. This is also called the enrollment CA because it is responsible for enrolling nodes in the network. The other CA generates Transport Layer Security (TLS) certificates to secure communications. This CA is also known as a \"TLS-CA\". These certificates avoid attacks such as man in the middle attacks. Certificates of \"intermediate\" CAs are issued by a \"root CA\" or another intermediate CA that responds to a root CA. Intermediate CAs are useful because if the root CA is compromised then the entire network, including admins and peers, can be damaged. Then, Lightweight Directory Access Protocol (LDAP) is configured to manage identities. For three organizations, it is recommended to use at least three dual-headed CAs. One CA is responsible for ordering services, one CA is responsible for peers, and one CA is responsible for auditing departments.  
After creating the CAs, we can create certificates for the identities using these certificates. It is important to first register the admin before enrolling it. Creating the MSP is also necessary. The CA's admin will issue a username and password for the entity. After being issued to the identity, these credentials can be used for enrollment. Two certificates are generated by the CA. One public certificate is used by other members, and the private certificate is used to sign messages and identities. The CA generates the Membership Service Provider (MSP). This is a set of folders that contains the CA's public certificate androot of trust for the CAs. MSPs assign roles to the identities, i.e., the node is either a peer node, an orderer node, or a CA. The MSP is created after the creation of the node identity. After configuring the CAs and MSPs, peers and ordering nodes must be deployed. There are different ways to deploy the nodes but the configuration file must be configured before deployment. The peer's configuration file is called \"core.yaml\", and that of ordering nodes is \"orderer.yaml\". The roles of peers and orderers must be understood before deployment. The main difference between them is that the channel's \"ordering service\" comprises nodes that function together to form the OS.