## 5 Discussion
### Key Challenges
* The architecture is a conceptual model; thus, it needs to be implemented. The implementation of this architecture would require dedicated dew servers and hotspot coverage antennae such as Wi-Fi or LoraWAN. The selection of the Wi-Fi module could be judiciously performed so that long range coverage can be facilitated with a higher bandwidth. However, such antennae should consume a low level of power for providing better sustainability. LoraWAN could be a great choice in this regard, however, the cost of antenna module could be high for very long-range coverage. * IoT devices should have Wi-Fi or LoraWAN connectivity to communicate to the nearby hotspots. Thus, a serious consideration should be made so that the cost of the IoT device does not go beyond a certain limit and so that the battery consumption can be minimized. * Hotspots need to be configured as miner nodes that should run on top of dew servers. Synchronization algorithms should be devised for making the internet independency more reliable. * Several LoraWAN platforms including TTN, Helium, LORIOT, ResIOT, SenRa, and ChirpStack can be considered while one is considering the internetwork backhaul. For Wi-Fi hotspots, a standard cellular backhaul may be used. * The type of blockchain should be devised. A hybrid approach can be beneficial in this aspect. An owner of a hotspot miner device can place it in their locality, to act as one of three types of hotspots, namely, full, light-weight, or data-only. The design specifications of each type of hotspot are different as their tasks are different. Complex, moderate, and simple hotspot hardware designs should be selected prior to deploying them in the real field of application. * Concise decisions should be made about the use of a PoC challenging aspect in this architecture. The PoC challenge rate, epoch size, and block time are important parameter that must be resolved a-priori. * One should consider the wallet type while aiming to connect their hotspot miner node with this network architecture. * A network consensus algorithm can be revisited to improve the reliability of the hotspot network. Target crypto token production per unit of time (e.g., month, quarter, half-yearly, or yearly) need to be accorded. * It is important to select a cryptocurrency that will be used in this architecture for rewarding the hotspot owners. It can be selected from existing standard cryptocurrencies or can be devised indigenously for a specific hotspot-distributed network architecture. \begin{table}
\begin{tabular}{p{128.0 pt} p{128.0 pt} p{128.0 pt} p{128.0 pt}} \hline \hline
\begin{tabular}{c} A malicious user aims to retrieve important packets while transmitted over LoRaWAN network \\ \end{tabular} & Malicious User \\ \hline \hline \end{tabular}
\end{table} 
Table 2: _Cont._* The structure of the block should be designed optimally. The number of transactions per block should be decided before using the blocks in reality. A decision should be made for fixing the transaction fees. The oracles should be carefully decided to specify the data credit conversion rate. The price of the selected crypto oracles must be aligned with the other blockchain networks. * The interoperability issues should be tackled so that this architecture can talk with other blockchains. * A trustless packet purchasing features should be formulated in order to allow higher coverage for the hotspot network. State channels and an organizationally unique identifier (OUI) should be implemented with proper care. * A reward scaling approach must be put in place for each epoch. In this aspect, it becomes important to specify who gets what, i.e., a hotspot shall earn as specific amount, as a reward. * The selection of a higher-grade Byzantine fault-tolerant protocol becomes inevitable when a blockchain is used. An asynchronous atomic broadcast protocol can be used with a consensus group which has known nodes. The threshold encryption technique may be deployed to improve the async behavior. * A procedure should be designed to elect a consensus group.