# A Robust Sharding-Enabled Blockchain with Efficient Hashgraph Mechanism for MANETs
## 5 Asynchronous Intra-Sharding and Inter-Sharding Consensus
### Work Process of a Dynamic Shard  
A dynamic shard is incurred by the addition and deletion of nodes. In addition to the tree-assisted inter-sharding consensus, hashgraph consensus is also used to update transactions first before confirming them. The asynchronous intra-sharding and inter-sharding consensus empower the security and efficiency of a dynamic shard via four steps:  
_Step 1: Request of an accounting node._  
When a node enters the geographical range of a shard, it can request to become an accounting node by submitting a _cross-shard joined transaction_ in (6). \(sig()\) is a signature function, \(sk\) is the secret key of the requester, and \(ts\) is the generation time of \(cTx^{j}\). Denote the shard in this application as _target shard_ whose ID is \(sId\). \(H\) is the hash value of \(cTx^{j}\), and \(preH\) is the hash value of the requester's previous valid transaction. \[cTx^{j} = sig(sk,ts,sId,H,preH,beSet) \tag{6}\] \[s.t.beSet = \{be_{1},be_{2},be_{3},...\}\] (7) \[be = <eH,preH,jTs,eTs,jSld,nBL>\]  
In (7), each element in \(beSet\) records the historical behaviors of the requester after given the timestamp \(ts_{0}\). Since these records are only updated when \(cTx^{j}\) is approved, each \(be\) has a relevant pair of \(cTx^{j}\) and the _cross-shard exited transaction_. \(jTs\) and \(eTs\) are the generation time of \(cTx^{j}\) and the _cross-shard exited transaction_, respectively. \(eTs>jTs>ts_{0}\). \(jSld\) is the ID of the shard related to the behaviors \(be\), and \(nBL\) is the number of the accusation transactions with \(timestamp\in[jTs,eTs]\). \(eH\) is the hash value of the _cross-shard exited transaction_, and \(preH=cTx^{j}.preH\). Nodes in _target shard_ check the records form a hash link to prevent the behavior records from decoupling, which is explained in the Performance Evaluation section. If \(cTx^{j}\) is approved, it is sent to the involved shards. Meanwhile, the requester downloads validated events and shard information in _target shard_. For example, shard information contains the geographical range and the member IDs of the shard. It acts as a relay to propagate gossip information via events with \(txList=null\), and it generates transactions for data sharing. It is worthwhile to note that these transactions can not be used until \(cTx^{j}\) is confirmed. Behaviors of the requester are accountable, because the False Event of \(cTx^{j}\) and False Free-riding Events can be recorded in the blacklist. _Step 2: 1 st validation of the request._ Nodes in involved shards check whether the behavior records of \(cTx^{j}\) are correct. In an involved shard, \(cTx^{j}\) is verified via the smart contract (see Algorithm 1). In line 1, the signature of the requester, and whether the requester is working in a shard, are checked. In line 4, \(|beS|\) is the number of elements in \(beS\), and \(|eSet|\) is the number of elements in \(eSet\). In lines 5-7, according to the graph, behavior records in \(beS\) are checked. Particularly, for each \(be\), if the _cross-shard exited transaction_ does not exist, or the hash value of the previous _cross-shard joined transaction_, the joined timestamp, the exited timestamp, or the number of accusation transactions is incorrect, False is returned. In line 8, joined transaction \(tx^{j}\) is generated to validate \(cTx^{j}\), where \(H\) is the hash value of \(tx^{j}\), \(jH=cTx^{j}.H\), \(ISId\) is the ID of the involved shard, \(sId\) is the ID of the _target shard_, \(sId=cTx^{j}.sId\), and \(ts\) is the generation time of \(tx^{j}\).