## 3 Design and Development of Blockchain-Based IoV
### Enhanced Hyperledger Fabric
#### 3.2.3 Transaction Handling  
After setting up and executing the channel, the system ensures that vehicles undergo the registration and enrollment phase with the CA and have cryptographic identities that are known for their authentication. The system also checks that the chain code is already written on all the vehicles and activated on the channel. The chain code is also given an endorsement scheme which requires that all the vehicles must endorse the message transaction. Let us suppose that vehicle (VA) wants to share the message to all the vehicles in that channel. In the first phase, VA initiates a transaction message (for example: about the road condition). A request is submitted in the channel by targeting all vehicles. Then, a transaction proposal is created. To create a transaction proposal, the vehicle uses a supported SDK. The proposal enables a chain code to be invoked with certain input parameters to read or update the ledger. The SDK envelopes the proposal of the message into a particular format and uses the user's account details to create a unique signature for it. The endorsement policy defines that all vehicles must endorse the transaction; hence, the request goes to all vehicles. Then, the endorsing vehicles verify that the transaction proposal has not been previously sent, to prevent a replay attack, and also check whether the signature is valid by using the MSP. Additionally, they confirm that the sender can execute this process on the channel. The transaction proposal inputs are transferred to the invoked chain codes by the endorsing vehicles. The chain code is run with Level DB to generate output that includes the answer-value, read-set, and write-set. At this point, ledgers are not updated. All of these values, in addition to the signatures of the endorsing vehicles, are returned as a proposal reply to VA.  
In the next phase, the sender verifies the signatures of all endorsing vehicles and ensures that the proposal responses from all the vehicles are the same. It verifies that the specified endorsement rules are achieved before submission. If the sender does not inspect responses and forwards messages without endorsement, then the endorsement rules are still imposed by other vehicles in the channel and upheld at the \"commit validation phase\". After verifying the responses and updating the ledger, it sends a message to the RSU (ordering service). The message proposal and endorsing reply are then bundled into a message and sent to the RSU by VA. The OS does not need to search the whole content of the message; however, it simply orders all of the transactions received from the channels, and generates blocks of transactions for each channel. In the next phase, the transaction blocks are delivered by OS to all vehicles on that channel. The endorsement rules are verified by validating the message within the block. The block's transactions are classified as \"valid\" or \"invalid\". Each vehicle adds the block to the channel's chain and, if the transactions are valid, then write sets are committed to Level DB. Each vehicle notifies VA that the message has been added to the chain, and whether the message was validated. Figure 2 shows the flow diagram of the enhanced Fabric.