# A Comparison of Blockchain Recovery Time in Static and Mobile IoT-Blockchain Networks
## 4 Methodology
### Evaluation Methodology
#### 4.2.2 Recovery Evaluation  
We then focus on evaluating blockchain recovery under different scenarios. We define the recovery time as the time for the routing protocol to resume routing plus the time for blockchain transactions to continue synchronization in the IoT-blockchain system. When the system is static in both real and emulated IoT-blockchain systems, we fail the devices by the following methods: First, we use the tcptraceroute tool to query the routing table to find the relay nodes between the sender and the receiver. We find that OLSR and BABEL always choose a fixed routing path, while BATMAN switches routes due to the change in the number of OGM packets received. Therefore, when using OLSR and BABEL, we let the interface of a fixed relay node close to emulate the failure. When using BATMAN, we shut down a relay node that is frequently selected. As a result, the path between the sender and the receiver will lose connectivity and the ability to forward packets. In this case, the ad hoc routing protocols will re-update the routes to maintain the new network topology. Each routing protocol has a different process for finding new routes, as described below. OLSR needs to know and maintain the topology and routing changes of the whole network. When there is a problem with the relay node between the sender and the receiver, the MPR node selected by the sender can no longer perform its duty of delivering network topology information (i.e., TC packets). Therefore, the sender needs a new MPR node to be responsible for forwarding packets. As mentioned in the previous content, in the static IoT-blockchain system we shut down the sender's MPR. The sender needs to detect that it has lost connectivity with its neighbor node by sending multiple HELLO messages and then spending some time identifying a new MPR node. The movement of the receiver in a mobile IoT-blockchain system also causes a shift and re-selection of the sender's MPR. Finally, all nodes need to be aware of the new changes in the network topology before they completely resume routing. Based on the recovery process of OLSR, the recovery time with OLSR can be calculated as Equation (1) below:  
\[T_{recovery}=T_{MPR\_{ost}}+T_{NEIGHB\_{HOLD\_TIME}}+T_{pure\_blockchain}, \tag{1}\]  
where \(T_{MPR\_{ost}}\) means the time for the sender to realize its current MPR has lost; it is equal to three or four times the HELLO_INTERVAL. \(T_{pure\_blockchain}\) means the recovery time of the blockchain itself. BABEL is more flexible than OLSR in that it can mandatorily request routing information proactively when it knows that there is a problem with the routing path it has been choosing. But BABEL also needs some time to recover because, when a node detects its neighbors to build a route, it needs to send HELLO and IHU packets. BABEL also sends packets about updating neighbors when it has identified a new neighbor. Equation (2) represents the recovery time when using BABEL in the IoT-blockchain system. It is expressed as:  
\[T_{recovery}=T_{neighbor\_update}+T_{pure\_blockchain}, \tag{2}\]  
where \(T_{neighbor\_update}\) means the time for the sender to update its new neighbor. It equals three times the HELLO_INTERVAL. Several IHU packets and one updated packet are included in the time it takes for BABEL to realize that there is a problem with the current neighbor node and find a new relaying neighbor node. BATMAN detects its neighbors and builds a network route only by OMG packets. BATMAN does not require the sender to know the topology change of the whole network, but only the sender needs to know its best next-hop to the receiver. The sender selects the best next-hop by comparing the number of OGM packets received from different next-hop nodes. So when the current best next-hop has a problem, and the sender gets no more OGM packets from it, the sender will choose the new best next-hop once the number of OGM packets received from another next-hop exceeds that of the OGM packets received from the current best next-hop which has a problem.