# Decentralizing Private Blockchain-IoT Network with OLSR
## 5 Evaluation  
### Experiment Setup  
In our evaluation, we deployed four RPi4 nodes on the fifth floor of the first building in the Faculty of Engineering, Chiba University, with the topology shown in Figure 2. The distances between nodes are illustrated in the figure. The figure also illustrates the distances between the nodes. The hardware configurations of each RPi and software are listed in Table 3. Since RPi4 is capable of mining blocks, a centralized, powerful mining node is not necessary in this case. The wireless adapters were configured in the ad hoc mode to run the OLSR protocol. We adopted the OLSR implementation from the OLSRd package ([[http://www.olsr.org/mediawiki/index.php/Releases](http://www.olsr.org/mediawiki/index.php/Releases)]([http://www.olsr.org/mediawiki/index.php/Releases](http://www.olsr.org/mediawiki/index.php/Releases)) (accessed on 21 June 2021)). In each RPi node, the OLSRd module was configured with the default Willingness value (equalling 3), indicating the willingness to become an MPR. The nodes ran the Ethereum client, the unmodified version of Geth ([[https://getheureum.org/downloads/](https://getheureum.org/downloads/)]([https://getheureum.org/downloads/](https://getheureum.org/downloads/)) (accessed on 22 June 2021)), to form a private blockchain that starts with a custom genesis file in Geth. The Nova PM Sensor SDS011 air quality sensor was used, which can detect the 0.3-10 \(\upmu\)m particle concentration in the air. The output data of Nova Sensor include the PM2.5 and PM10 indexes. The sensor could be programmed with the sds011-client module ([[https://github.com/ivkos/sds011-client](https://github.com/ivkos/sds011-client)]([https://github.com/ivkos/sds011-client](https://github.com/ivkos/sds011-client)) (accessed on 21 June 2021)) for Node.js. We allowed the sensor work to be in active or query mode. In the former, the sensor actively released data as soon as they were available, while, in the latter, the sensor passively responded to requests at a periodic pace. We conducted the experiments over RPi4 nodes as the following. First, we deployed a smart contract to the blockchain, which recorded PM2.5 and PM10 data as state variables. Moreover, the contract emitted events when any of them exceeded a pre-defined value. Second, the sender RPi4 ran a script (with sds011-client library) requesting PM data every second. It then wrapped the data into transactions and submitted them to the blockchain with the Web3 library via Remote Procedure Call (RPC) to the local Ethereum client. The transactions were automatically disseminated to any reachable blockchain peers. Third, the receiver collected propagated transactions and mined them into blocks. Once a block was accepted, the block's inside transactions were executed. Then, the state variables were modified in the smart contract. If the state variable exceeded the pre-defined value, the blockchain emitted an event logged in the block header. The receiver listened to the event with Web3 library and readied an alert. Finally, we synchronized the system time of the RPi4 nodes for more accurate latency measurements with the ntpdate utility (i.e., using Network Time Protocol). In the experiment environment, the sender was out of the receiver's communication range. Hence, they could not communicate with each other without a relaying or forwarding node (e.g., an access point or an MPR node). When the OLSR protocol was enabled in the network, Nodes 1 and 4 discerned the reachable one-hop neighbors, Nodes 2 and 3, with HELLO messages. They selected one of them as an MPR node to transmit data and control packets. After forming a reachable path, they could build a blockchain connection via Links 1 and 3 (marked as Path 1) or Links 2 and 4 (marked as Path 2). Since there are two available paths, the blockchain connection could recover from the MPR node failure by selecting a new MPR node following the procedure of OLSR routing protocol. Figure 2: Evaluation topology.