## 4 Performance Evaluation  
In this part, we present the developed blockchain-MEC V2X system evaluated for various scenarios. The evaluation process was carried out over the NS-3 environment, with the highway mobility model. Simulation Urban Mobility (SUMO) is an open-source environment used to provide the required vehicle mobility, with synchronization and control of NS-3. TraCI API was used to build the module that achieves such integration. The trajectory files out of the SUMO were fed to NS-3 to define the nodes' mobility. The FastChian NS-3-based tool was used to implement the developed blockchain scheme, with the steps introduced in [41]. Table 2 provides the considered simulation parameters. There were seven MEC servers considered for the simulation process, with the specifications introduced in Table 2. The communication was assumed to be carried over the C-V2X Mode 4 interface. Vehicles were located randomly, with the specifications introduced in Table 2, over a four-lane bi-directional road of 5 km in length. Each vehicle was assigned a workload equivalent to the workload of real tasks. The considered workloads were UDP-based. The number of deployed vehicles, N, was assigned three values, as the system was simulated for 200, 400 and 600 vehicles to check the effect of the traffic increase on the performance of the developed blockchain-MEC V2X system. Moreover, three densities of vehicles were considered for the simulation process to evaluate the effect of the change in vehicle density, TD, on the overall system performance. The first performance metric considered in the evaluation process of the developed blockchain-MEC V2X was the communication overhead. Two systems were considered for such performance evaluation, system (I) and system (II). The first system, i.e., system (I), was a blockchain-MEC V2X system with no clustering priorities, as each vehicle was responsible for its communication. Thus, in this system, vehicles communicated individually. In system (II), there was a clustering priority, as nodes with common behavior, e.g., speed and direction, selected a cluster head to take the responsibility of the communication. Thus, in system (II), a limited number of vehicles, i.e., cluster heads (leader nodes), was responsible for communication. For system (I), the communication overhead was at a higher level than for system (II). Figure 3 presents the percentage of the communication overhead for system (II) compared to system (I), for three different cases of traffic density. As the traffic density increased, the communication overhead increased by an average of 13% for each 10% of traffic density increase. Furthermore, clustering reduced the communication overhead of the developed blockchain-MEC V2X system; however, when the percentage of cluster heads (leader nodes) reached 70% of all vehicles in the cluster, the clustering was efficient no more and the com  
munication overhead was the same as with no clustering. Figure 4 presents the percentage of the communication overhead with the number of cluster heads, for three different values of the average number of vehicles in the network. As the number of vehicles increased in the network, the average communication overhead increased. Moreover, to evaluate the effect of vehicle mobility on the developed blockchain-MEC V2X, the communication overhead was measured for different values of vehicle mobility. Figure 5 presents the communication overhead of system (II), compared to system (I), with the change in vehicle mobility; at cluster-head percentages of 10, 20 and 30 from the total number of cluster members, the communication overhead increased linearly till a mobility of 60 km/h, then the increase in vehicle mobility produced a higher increase in the communication overhead.