# A Comparison of Blockchain Recovery Time in Static and Mobile IoT-Blockchain Networks
## 5 Evaluation
### Emulated IoT-Blockchain  
#### 5.2.1 Static Scenario  
The previous evaluation provides insights into the simple IoT-blockchain system with the protocols. This section investigates a bigger system, as shown in Figure 6, where the IoT nodes form a 3 \(\times\) 3 grid topology. We chose the grid topology because it is a classic topology for investigating ad hoc routing protocols. In the system, each IoT device can have at least two neighbors and the ad hoc routing protocols have multiple choices of routing paths. Our topology has also been investigated in [34], where the authors built wireless sensor networks with a nine-node grid in an indoor environment. We consider placing the devices at different distances from each other because, in most cases, the network nodes are at different, or even very random, distances. In Figure 6, each IoT device is 50 m away from its neighbors in the horizontal direction and 30 m away from its neighbors in the vertical order. In Figure 6a, the black dotted line represents the ad hoc connection between each IoT device. Figure 6b shows the design of the blockchain network; the red dotted lines represent the blockchain connection. All IoT devices join the blockchain and are fully connected. The environment and software for constructing the system are listed in Table 6. We use Mininet-WiFi on an Ubuntu 20.04 machine, Ethereum, and the routing protocols are similar to the ones in the real IoT-blockchain system. Similar to the previous section, we first measure the system's network performance; the results are shown in Figure 7. Figure 7a,b shows the throughput and RTT between different nodes in the IoT-blockchain system, respectively. We investigated not only the performance of the two neighboring nodes' links, but also the link between the sender and the receiver. From the results, we can see that the performance of the emulated IoT-blockchain system is the same when the links have similar roles. The maximum throughput between a node and its one-hop neighbor node is about 7 Mbps, while the minimum RTT is about 0.5 ms. When the node has more hops (e.g., four hops between the sender and the receiver), the throughput value is lowest and the RTT value is highest, i.e., the average throughput is 2.695 Mbps, and the average RTT is 2.75 ms. \begin{table}
\begin{tabular}{c c} \hline \hline OS & Ubuntu 20.04.3 LTS \\ CPU & Intel Core i7-8565U [EMAIL_ADDRESS] GHz \(\times\) 8 \\ Mininet-WiFi & version 2.6 \\ \hline Ethereum & Geth 1.10.9-stable-eae3b194 \\ \hline OLSR & olsrd 0.9.9 \\ BATMAN & batman IV \\ BABEL & babeld 1.12.1 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Emulated environment. Figure 5: Recovery time of real IoT-blockchain in mobile scenario. (**a**) Recovery time; (**b**) Average recovery time with components. In our system, to interact with the smart contract, one of the IoT devices sends a transaction containing the fixed value. In this evaluation, IoT device4 acts as the sender sending the transaction file and IoT device9 acts as the receiver. When evaluating recovery performance, we must understand the routing path between the sender and receiver when using each routing protocol. We found that with OLSR, IoT device4 always chose the same route to propagate packets to IoT device9 (i.e., IoT device4-IoT device1-IoT device2-IoT device3-IoT device9). In the case of BABEL, IoT device4 also selects a fixed path to route to an IoT device9 like OLSR. However, BATMAN is different from the other two protocols. The routing path from IoT device4 to IoT device9 changes, but we find that IoT device4 frequently selects a route to IoT device9 (i.e., IoT device4-IoT device1-IoT device2-IoT device3-IoT device9). We shut down one of the relay nodes between the sender and the receiver to make the path fail. With OLSR and BATMAN, we shut down IoT device2 while the BABEL IoT device6's interface is down. We then evaluate and collect the communication recovery time of the IoT-blockchain system.