# A Robust Sharding-Enabled Blockchain with Efficient Hashgraph Mechanism for MANETs
## 7 Performance Evaluation
### Experimental Evaluation
#### 7.2.2 Experimental Results
In addition, in Figure 9b, the gap between our scheme and [24] is stable, since both are based on hashgraph. Figure 8: The changes of event throughput and network traffic throughput with the increase of consensus nodes. For example, in our scheme, 46 nodes can achieve fault tolerance for 15 Byzantine nodes. [PERSON] et al. [23], [PERSON] et al. [24]. Figure 10 presents the changes in event delay and data dropped rates with the increase of consensus nodes. In Figure 10a, with the increase of consensus nodes, the changes of delay are not monotonic. The reason is that the major factors affecting delay include the number of hops, network congestion, channel competition and the number of isolated nodes. The increase of nodes has a negative impact on the delay via the first three factors, while it has a positive impact on the delay via the fourth factor. The delay of our scheme is better than that of traditional hashgraph, because our scheme selects honest neighbors to propagate events, and fewer transmitted events mitigate the competition of wireless channels. For a similar reason, the data dropped rates of our scheme are less than those of the traditional hashgraph in Figure 10b. In Figure 10b, with the increase of consensus nodes, data dropped rates increase as well. It is because more data packets are generated to achieve consensus on an event, and some of them are dropped in opportunistic communications of the MANET. Therefore, our scheme using hashgraph and the blacklist is efficient in a MANET-based blockchain. * Inter-sharding consensus Scenario 1: Two shards are deployed, and each shard contains \(four\) nodes. Node _node_100 moves from shard1 to shard2. The cross-shard transactions are generated by nodes in shards continuously. Figure 10: The changes of event delay and data dropped rates with the increase of consensus nodes. Figure 11 shows the throughput of cross-shard transactions when _node_100 dynamically leaves shard1 and joins shard2. _Interval_ indicates the generation interval of transactions, and _size_ is the size of transactions. Nodes in shard2 can only receive the transactions between 1 m 32 s and 2 m 35 s, since _node_100 arrives at the overlap region of shard1 and shard2 at that time, relaying the transactions. Hence, dynamically joining and leaving shards contributes to inter-sharding consensus. When the transaction size is larger, its throughput drops, because _node_100 has limited resources and becomes the bottleneck. When the generation interval of transactions increases, the throughput increases as well. Hence, smaller sizes of cross-shard transactions, more frequency of nodes joining a shard and relatively fewer cross-shard transactions can improve the throughput of cross-shard transactions. Scenario 2: Six shards (shard1, shard2, shard3, shard4, shard5 and shard6) are deployed, and each shard contains 3 nodes. Node _node_100 moves from shard1 to shard2. In order to join shard2, _node_100 generates the request of a _cross-shard joined transaction_ involving shard2 and shard1, the request involving shard2, shard1 and shard3, the request involving shard2, shard1, shard3 and shard4, the request involving shard2, shard1, shard3, shard4 and shard5, or the request involving shard2, shard1, shard3, shard4, shard5 and shard6. Figure 12 shows the delay of the cross-shard transaction update in the number of different involved shards. Serial transaction validation means that before the cross-shard transaction updated, it is validated by involved shards one by one. Parallel transaction validation means that before the cross-shard transactionis updated, it is validated by related shards in parallel and then by shard2. The delay of valid cross-shard transactions in our scheme is better than that in serial transaction validation and parallel transaction validation, because our scheme is asynchronously tree-assisted and the delay is only related to shard2 _node_100 joining.