# Resource Management and Secure Data Exchange for Mobile Sensors Using Ethereum Blockchain
## 4 Methodology
### Validation of MS Identity
The proposed scheme uses a consensus mechanism to retain the sequence of operations within a network with the Ethereum blockchain in a decentralized manner. Adopting the consensus method assists in confirming the appropriate accounting of blocks to mitigate trust-related issues. The proposed scheme adopts a fault-tolerant consensus method to incorporate adaptiveness in blockchain operations, especially in the case of the N2S mode of communication [56]. According to the consensus mechanism, more entities are involved, known as slaves, auxiliaries, and masters. The following discussion details the entities engaged in the implemented consensus methods:  
* _Slave Node:_ This node is set to silently monitor the system's actual states, followed by responding to the request from either the master node or the auxiliary node. Slave nodes refrain from participating in the election process of the master node directly; however, they can become auxiliary nodes if acknowledgment is not received from the master node after a certain period of timeout. The primary task of the slave node is to maintain sync with the master node by replicating its actions. * _Auxiliary Node:_ This node actively participates in transactions as a master node. The adopted consensus method [56] permits the selection of the master node based on arbitrary timeout instances. If the slave node does not hear from the master node within a specific cut-off time, the slave node changes to the auxiliary node state and initiates the election process. During the election process, the auxiliary node forwards requests from other nodes present within the system. If an auxiliary node receives votes in prominent numbers, it acts as a new master node. * _Master Node:_ The master node is primarily responsible for replica management associated with the log entries in the blockchain network. The master node processes requests generated from the client coordinates the complete consensus method, and transmits the updates to the slave nodes to retain the status of the master node. Notably, the master node is the pivotal contact point for the write operations in the Ethereum blockchain. Based on implementing this consensus mechanism, the proposed model considers the AP to be initially represented by a slave node. However, the AP changes to an auxiliary node if it does not hear from the master or auxiliary nodes. The Ethereum blockchain is managed by the master node elected by the auxiliary node in each operational cycle. The acquired set of information is transformed into blocks by the master node, and this information is disseminated to every remaining node. The system approves the generated block, and the timestamp is subjected to verification. Therefore, according to the proposed scheme, the access point \(AP_{j}\) plays the role of a slave, auxiliary, and master in the preliminary point of operation if there is no response and if it receives a majority of the consensus. Each user device equipped with sensor \(s_{j}\) must furnish the identity information to the gateway node, GN, where the identity information consists of a unique index of the user sensor, i.e., \(s(iden_{j})\) and timestamp \(s(t_{j})\). An arbitrary number \(\pi_{j}\) is generated by GN, which plays the role of the sensor's private key, \(s\big{(}priv_{j}\big{)}\). This means that once the system obtains the request message, a private key is generated, i.e., \(s\big{(}priv_{j}\big{)}\longleftarrow\pi_{j}\), where the suffix \(j\) represents all mobile sensors. Based on Equation (3), the proposed scheme incorporates the reference variable \(\Omega\) to include a finite field while generating a public key. The generation of an incognito coefficient is obtained using Equation (6).