# A Comparison of Blockchain Recovery Time in Static and Mobile IoT-Blockchain Networks
## 4 Methodology
### Evaluation Methodology
#### 4.2.2 Recovery Evaluation
More specifically, BATMAN implements route translation based on the number of OGM packets in the sliding window range. BATMAN switches routes immediately when the number of OGM packets received from another next-hop is even one more than that of the OGM packets obtained from the current selected best next-hop. Equation (3) shows the recovery time of BATMAN. \[T_{recovery}=T_{switch\_next\_hop}+T_{pure\_blockchain}, \tag{3}\]  
where \(T_{switch\_next\_hop}\) means the time for the sender to switch the best next-hop to the receiver. It changes into the range between \(OGM\_INTERVAL\) and \(WINDOW\_SIZE\times OGM\_INTERVAL\). When there is no blockchain connection, we can first have ICMP packets transmitted between them by a sender pinging the receiver. This is followed in a manner that causes temporary communication failure between the receiver and the sender mentioned above. Using the Wireshark tool, we can see that the sender keeps sending ICMP request packets but it cannot receive ICMP response packets from the receiver during communication failure. However, when the routing protocol resumes communication, the sender can receive ICMP response packets again. So, we consider that the time interval between when the sender does not receive the ICMP response packet and when this packet is received again is ad hoc routing recovery time. In addition to the time it takes for the ad hoc routing protocol to recover the route, the blockchain itself also takes time to recover. We obtain the recovery time for the entire IoT-blockchain system as follows: We let the sender send one transaction per second and the transaction is quickly broadcast to the receiver device. The synchronization of transactions between them can be said to be timely. However, when the IoT-blockchain system fails, as described above, some transactions sent by the sender cannot be broadcast to the receiver promptly. At this point, the number of transactions queued in the sender's txpool continues to increase, while the number of transactions queued in the receiver's txpool remains unchanged. Once the routing protocol updates the routing table, the device can learn the new topology of the network, then the sender and receiver can communicate again. Once routing and blockchain are restored, then the IoT-blockchain system's communication resumes. At this point, the sender re-broadcasts all previously unsynchronized transactions in its txpool to the receiver and the receiver conveniently resumes synchronization of transactions with the sender. We consider the interval between the time when the receiver is unable to synchronize transactions and the time when transactions are resumed again as the recovery time. We calculate the recovery time based on the detail information and corresponding timestamps in the get log of the receiver. For better understanding, we describe the method of obtaining the recovery time in the IoT-blockchain system in the flowchart in Figure 1.  
In [33], the authors define the workflow when broadcasting transactions between a blockchain node and its peer nodes. When a sender node sends a transaction file that can trigger a smart contract, the transaction is submitted to the sender's txpool and queued for validation. At this point, the sender's get log will record \"Submitted transaction\", indicating that the sender has uploaded a transaction to its txpool and is waiting to be validated and broadcast. When the transaction is successfully verified, the sender will broadcast it to all peer nodes. When the peer node receives the broadcast transaction, the transaction is still stored in its txpool and queued for validation. At this point, the peer enters the \"Promoted queued transaction\" phase, and this message is recorded in the peer's get log. According to the above workflow, we focus on the timestamp corresponding to the \"Promoted queued transaction\" message in the receiver's get log.