# A Serious Gaming Approach for Crowdsensing in Urban Water Infrastructure with Blockchain Support
## 7 Results
### Blockchain  
The blockchain framework is evaluated to see if the proposed data storage solution is feasible for the entire architecture. As mentioned before, Hyperledger is a new joiner in the blockchain technology stack and provides many plug and play functionalities, tools and studies about its characteristics.  
According to [126], the performance of Fabric architecture is measured based on multiple metrics. All the tests were performed using a Hyperledger benchmark tool named Caliper [125] with the applied testing flow described in Figure 14.  
Figure 13: VCG load balancing; (a) average reward; (b) average number of assignments.  
To better understand the results, the following key terms were defined: SUT (System Under Test), Read Latency (time between sending the read request and receiving the read response), Read Throughput (number of reading operations finished in a defined period), Transaction Latency (time from sending a new transaction to blockchain until the transaction is inserted and available to be retrieved) and Transaction Throughput (number of transactions added into blockchain in a defined period). The type of actions that were evaluated are the following:  
* Write: creating a new transaction in the database (createAsset--single putState operation);
* Batch write: creating multiple batch transactions (createAssetsFromBatch--multiple putState operations);
* Read: get a transaction (getAsset--single getState operation);
* Batch read: get multiple transactions (getAssetsFromBatch--multiple getState operations).  
The configuration parameters for Hyperledger Caliper [127] include the number of worker nodes, workload specification and dimensions (e.g., asset size, batch size), experiment duration and rate control mechanisms (e.g., fixed rate, fixed load), of which the most relevant were selected to provide a performance evaluation in terms of read/write operations on the blockchain.  
Therefore, a fixed load rate controller was used with a specified constant load between 10 and 50 backlog transactions (i.e., pending confirmation), an asset size between 100B and 64 KB and a batch size between 1 and 50 to evaluate the proposed scenarios.  
For the evaluation of read performance shown in Figure 15a, the fixed load was evaluated in terms of average latency, while increasing the asset size and using 10 worker nodes with a fixed load of 50 backlog transactions. The batch read performance shown in Figure 15b was evaluated by increasing the batch size, using a predefined asset size of 8 KB and a fixed load of 20 backlog transactions. Similarly, the write performance shown in Figure 16a was evaluated using 5 worker nodes and a fixed load of 10 backlog transactions, and the batch write scenario shown in Figure 16b was configured with a fixed 8 KB asset size and a fixed load of 5 backlog transactions.  
According to the results in Figures 15 and 16, depending on the message size and the number of simultaneously read/write requests, the average time for retrieving/adding information from blockchain increases linearly with batch size and message size.  
Figure 14: Blockchain test framework.  
The results show good performance and scalability with regards to the number of simultaneous requests and the message size when considering the test environment. Further small-scale experiments that were run multiple times have confirmed the accuracy of the results in terms of the overall conclusions, while the entire simulation is extremely resource-intensive and was only performed once.