# Blockchain-Based Lightweight Trust Management in Mobile Ad-Hoc Networks
## 4 Performance Evaluation
### Simulation Results
#### 4.2.3 Efficiency (Block Generation Latency)  
In the proposed scheme, the block generation time is much lower than that in other blockchain systems. Ethereum and Bitcoin block times are approximately 15 s and 10 min, respectively. In Figure 13, we demonstrate the lightweight features of the proposed scheme by presenting block latency based on the ratio of attack transactions in the network. Attack ratio is calculated based on Equation 7. To speed up the detection process, hello and TC messages in the OLSR protocol are used to piggyback validation messages and blocks to be transmitted through the network, respectively. For attack transaction validation, the detector node includes attack information in its hello message to receive validation from its two-hop neighbors. As shown in the hello message format (Figure 1), there is a free space called \"Reserved\" in the hello message, which is used to indicate an attack report. When the detector node includes an attack report for validation, the \"Reserved\" field is set to a value of one. If the one-hop neighbors of the detector receive a hello message with \"Reserved = 1\", this means that the receiver nodes must recognize that there is attack information and relay it to their one-hop neighbors (two-hop neighbors of the detector) to validate the attack report. The neighbors then send a reply message in the next hello message with \"Reserved = 1\". Therefore, it costs two hello message intervals (2 * 2 s = 4 s) to validate an attack transaction. In this case, the TVs of any other neighbors in the network will be sent by nodes above the threshold \(\theta\) to the delegate node via TC messages with \"Reserved = 1\" to indicate the additional included information. After collecting all transactions, a block will be generated by the delegate and disseminated in the next TC interval.  
Therefore, from attack transaction validation to block dissemination, the process requires approximately 10 s, as indicated in the Figure 13. Depending on the time at which an attacker is caught by a victim node, the latency could be a slightly lower or higher than 10 s. For example, if an attack detector node becomes the delegate, the communication time required to relay attack information to the delegate is reduced, leading to even better results in terms of block latency. Additionally, when colluding attacks occur in a network, the block time and transaction ratio are even lower. For example, if two different attackers launch an attack in different places simultaneously, two attack transactions will be included in a block and the effectiveness of the proposed scheme will increase.  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline - & **A** & **B** & **B** & **C** & **A** & **C** \\ \hline DCFM & O(\(n^{2}\)) & O(\(n^{2}\)) & O(\(n^{2}\)) & O(\(n^{2}\)) & O(\(n^{2}\)) & O(\(n^{2}\)) \\ Proposed Scheme & O(\(n^{2}\)) & O(\(n^{2}\)) & O(1) & O(\(n^{2}\)) & O(1) & O(1) \\ \hline \hline \end{tabular}
\end{table}
Table 4: Comparison of Computational Complexities for a Node.  
\[Attack\_ratio=\frac{number\_of\_attackers\_in\_the\_network}{number\_of\_nodes\_in\_the\_network} \tag{7}\]