## 4 Simulation Experiments and Data Analysis
### Analysis of Experimental Results  
In order to verify the efficiency of the proposed algorithm, it will be compared with the traditional algorithms from three perspectives: the number of CPU cycles required for (average energy consumption, average delay, and average overhead) tasks, the amount of data, and the number of tasks. Figures 4-6 show the relationship curves between the number of CPU cycles required for the task and the average energy consumption, average latency, and average overhead in the system for five different schemes when processing the same task. It can be seen that all three metrics increase with the number of CPU cycles required for the task for all schemes. Due to the limited CPU resources of the local devices, the devices need to run at full capacity for a long time, resulting in a more significant increase in the curves for the locally executed scenarios. In contrast, the optimization scheme proposed in this paper has a relatively flat curve growth and, at the same time, yields lower energy consumption, latency, and overhead compared to the other schemes. The reason for this is that when the CPU cycle tasks are high, they are prioritized to be assigned to idle and efficient nodes, which achieves a globally optimal balance. When the number of CPU cycles required by a task reaches 1900 Megacycles, the average energy consumption obtained by the optimization scheme proposed in this paper is 81.1%, 48.2%, 24.8%, and 8.6% lower than the local execution scheme, average offloading scheme, FOX scheme [38], and PLO scheme, respectively; the average latency is 83.9%, 53.7%, 53.7%, 53.7%, 53.7%, 53.7%, 28.2%, and 9.7%, and the average overhead is reduced by 86.1%, 59.7%, 39.7%, and 24.6%, respectively. Therefore, this result shows that the scheme in this paper is able to maintain low energy consumption, latency, and overhead as the number of CPU cycles required for a task increases. The effect of task data volume on average energy consumption, average delay, and average overhead under different scenarios is shown in Figures 7-9. The average energy consumption, average delay, and average overhead within the system all show a linear growth trend with the increase in data volume. The relatively flat growth of the local execution scheme is due to the fact that the local scheme avoids the uncertainty associated with network communication, making the performance metrics dependent on the fixed parameters of the local device. Moreover, it can be observed that the proposed scheme in this paper is optimal in terms of reducing energy consumption, delay, and overhead. \begin{table}
\begin{tabular}{l l} \hline
**Parameters** & **Numerical** \\ \hline Data size of the task \(D_{m}\) & [0.5–1.5] MB \\ CPU cycles required for the task \(C_{m}\) & [1000–2000] Megacycles \\ Transmitting power of the vehicle \(P_{m}\)[28] & 46 dBm \\ Computing power of the vehicles \(f_{m}^{LOC}\)[29] & 2.0 GHz \\ Computing power of the MEC server \(f_{m}^{DEC}\)[30] & 8.0 GHz \\ Radius of communication coverage of RSUs \(R\)[31] & 500 m \\ Gaussian channel white noise \(B_{0}\)[32] & \(-147\ dBm\) \\ Subchannel bandwidth \(B_{m}\)[33] & 2 MHz \\ Weighting of latency \(\eta\) & 0.8 \\ Weighting of energy \(\gamma\) & 0.2 \\ CPU cycles required for signature \(\alpha\)[34] & 1 Megacycles \\ CPU cycles required for MAC \(\beta\)[34] & 10 Megacycles \\ Average deal size \(S_{p}\)[35] & 200 B \\ Average computing power of RSUs \(f_{cons}\)[36] & 3 GHz \\ Average transmission power of RSUs \(P_{cons}\)[37] & 1000 mW \\ Number of blockchain nodes \(n\) & 6 \\ Number of blockchain consensus nodes \(K\) & 4 \\ Constant speed \(v\) & 40 Km/s \\ \hline \end{tabular}
\end{table} 
Table 1: Simulation parameters.