## 7 Discussions  
Although scalability is a major concern in decentralized peer-to-peer blockchain networks, yet researchers paid little attention till the date. The existing solutions addressed this problem in different directions: pruning out the old historical data to reduce data size in the network and in the blockchain [21], improving consensus algorithm as a way to improve latency and throughput [22], categorizing nodes in the network with predefined functionalities and enabling them to work in a distributed manner [7], etc. All the above-mentioned approaches although solve the scalability issue to some extent, however their applicability is limited to specific application domains only. For example, the proposal in [21] is designed very specifically for cryptocurrency and generation needs all historical records, whereas the proposal in [22] is mainly concentrated on the consensus algorithm, showing that improvement in scalability of the blockchain protocol is possible to the point where the consensus latency is limited solely by the network diameter and the throughput bottleneck lies only in node processing power. This is to observe that the scope of Bitcoin-NG differs from ours in the sense that we have mainly concentrated to blockchain network structure, from mesh to hierarchical, and the abstraction of the transaction-records. A recently published work in march 2019 [28] differs from our proposal in many ways: (1) The work focus exclusively in IoT systems that prefer to keep user's key information, and hence may not fit to other scenario in general. (2) They discriminate the participants, categorizing into device-layer, fog-layer and cloud-layer nodes, with a varying computational capabilities. The task of each layer nodes are predefined. For Example, the fog-layer nodes which lie in between device-layer and cloud layer, act as security manager to record and verify transactions that include key management information in this respective domain. Although the proposal is suitable for cross domain communications respecting privacy issues, it does not address any scalability issue in presence of large-scale nodes in the peer-to-peer network. Therefore, this is indeed interesting to see if the combination of these two improves the individual results. This is our future plan. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline \multirow{2}{*}{\(\delta\)} & **Trans. Rate** & \multirow{2}{*}{**No. of Inputs for Verification**} & \multicolumn{2}{c}{**Verification Results in**} & \multicolumn{2}{c}{**Verification Results in**} \\  & & & **Concrete Blockchain(CB)** & \multicolumn{2}{c}{**Abstract Blockchain**} \\ \cline{3-8}  & & & **No. of Inputs** & **Exists in CB?** & **\% of FDR** & **\% of PDR** \\ \hline \multirow{4}{*}{2} & 0.8 & 500 & 250 & _True_ & 25.2 & 46 \\  & & & 250 & _False_ & 20.2 & 48.8 \\ \cline{2-8}  & 1 & 500 & 250 & _True_ & 20.2 & 48.8 \\ \cline{2-8}  & 1.25 & 500 & 250 & _True_ & 13.4 & 49.6 \\ \hline \multirow{4}{*}{5} & 0.8 & 500 & 250 & _True_ & 19 & 48 \\  & & & 250 & _False_ & 14.2 & 49.4 \\ \cline{2-8}  & 1.25 & 500 & 250 & _True_ & 17.2 & 49.8 \\ \hline \multirow{4}{*}{7} & 0.8 & 500 & 250 & _True_ & 18.2 & 48.8 \\  & & & 250 & _False_ & 12.8 & 49.2 \\ \cline{2-8}  & 1.25 & 500 & 250 & _True_ & 9.2 & 50 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Verification results: Concrete vs. Abstract. The hierarchical model proposed in this paper can be seen a generic model where the number of levels in the hierarchy and the levels of abstractions can easily be varied based on the application need. As we already mentioned before that the approach scale the system, alongside such partial views towards higher levels of the hierarchy also facilitate to control the access of blockchains (and hence blockchain records) differently to different groups of people or processes as per their access rights. In fact, the support of policy specification deployed through smart contract can make this model more powerful.