# A Robust Sharding-Enabled Blockchain with Efficient Hashgraph Mechanism for MANETs
## 7 Performance Evaluation
### Security Analysis  
The attack prevention and properties of the proposed scheme are analyzed as follows. * Sybil attack  
The Sybil attack is resisted through the historical behavior records of nodes and inter-sharding consensus. The node applies to join a shard by submitting its historical behavior records. Only if the records are validated by all involved shards, and the reputation value calculated from these records is greater than threshold \(th1\), is the node allowed to participate in the consensus of the shard and data sharing in the shard. \(th1\) can be \(\{rep|rep.rank=2/3\}\). It means when the reputation values of nodes within the shard are sorted in descending order, \(rep\) is ranked as \(2/3\) of all values. The behavior records of the node in involved shards cannot be reused to generate multiple identities. In line 11 of Algorithm 2 and (8), _a cross-shard exited transaction_, \(cTx^{e}\), is generated, where \(preH=cTx^{j}.H.\ cTx^{e}\) refers to \(cTx^{j}.\ cTx^{j}\) and \(cTx^{e}\) are sent to involved shards. It means when the node is removed from a shard, its \(cTx^{e}\) is updated to the graphs of all involved shards, referring to \(cTx^{j}\). In other words, if there is not a latest _cross-shard exited transaction_ after a latest _cross-shard joined transaction_ of the requester in involved shards, the requester is working in a shard. The state of the requester becomes _working_, and honest nodes are aware of its state. Its behavior records are locked and cannot be used as sharding requests. It is hard to decouple the behavior records of the requester to generate multiple identities or launch whitewashing attacks. First, the behavior records of the requester cannot be decoupled into discontinuous parts. For a node, its \(cTx^{j}.preH\) indicates the hash value of its previous _cross-shard exited transaction_. The two transactions belong to different behavior records and may be recorded in graphs of different shards. The chain of records is defined as (11), where \(beSet\) is the behavior records of the request, \(be_{k}\) is the previous behavior record of \(be_{i}\), \(be_{i}.preH=cTx^{j}_{i}.preH\), and \(be_{k}.eH=cTx^{e}_{k}.H\). Each record has a relevant pair of _cross-shard joined transactions_ and _cross-shard exited transactions_. Hence, the behavior records are in the chain structure depicted in Figure 7. In (12), \(be_{k}\) is determined to be the previous behavior record of \(be_{i}\), where \(be.eTs=cTx^{e}.ts\) and \(be_{0}\) as a genesis record. Nodes in the \(target\)_shard check whether the behavior records in the application meet (11). If it does not meet the requirement, the participating application is not approved. \[\{be_{i}|\forall be_{i}\in beSet\ \&\ be_{i}.preH=be_{k}.eH\} \tag{11}\] \[s.t.\{be_{k}|(be_{k}\in beSet^{\prime}\ \&\ be_{k}.eTs=max(beSet^{\prime}.be.eTs))\ ||\ be_{k}=be_{0}\}\] (12) \[\{beSet^{\prime}|beSet^{\prime}\subset beSet\ \&\ beSet^{\prime}.be.eTs<be_{i}.eTs\}\]Second, the records of the requester within a shard can not be decoupled. The behavior records that are valid and include all records of the requester in the shard are defined as (13), where \(CTX^{e}\) and \(CTX^{j}\) are the set of _cross-shard exited transactions_ and _cross-shard joined transactions_ of the requester in the shard. \(f1\) means that \(beSet_{y}\_be.nBl\) is the number of the accusation transactions with \(timesetamp\in[beSet_{y}\_be.jTs,beSet_{y}\_be.eTs]\). Nodes in an involved shard check whether the behavior records in the application meet (13). If they do not meet the requirement, the participating application is not approved. \[\begin{array}{ccccc}\{beSet_{y}|beSet_{y}\subseteq beSet\ \&\ \forall cTx^{e}\in CTX^{e}\ \&\ \&\  
node's request of joining a new shard is rejected, or it is removed from the shard in the shuffling of nodes. * Adaptability  
The shard is dynamically adaptive in terms of consensus nodes and reconfiguration epochs.