## 6 Implementation and Experimental Results  
We have implemented our proposal considering a simple two-level hierarchy of blockchain-networks, where three local networks \(N_{1}\), \(N_{2}\) and \(N_{3}\) at level-1 are communicating with level-2 network \(N_{a}\). A pictorial view of the system is depicted in Figure 11. We have used Ethereum client get to build these networks where each network maintains its own blockchain separately. We have chosen a set of leaders (labelled with \(L\)), one from each local network \(N_{i}\) (\(i\in 1\ldots 3\)). The task of a leader is to listen a set T of its local transactions over \(\delta\) wait-time and to initiate an abstract transaction \(t_{a}\) (which contains abstraction of T) in the network \(N_{a}\). Since our prime objective is to show the effectiveness of abstractions as a way to improve scalability, in this experiment we have considered transactions consisting of numerical values in the form \(\langle transaction_{id},value\rangle\) pair. For abstraction, we have considered the Galois connection between numerical values domain and interval abstract domain. The functionality of leader is implemented using JavaScript which interacts with two kinds of smart contracts, one for level-1 networks \(N_{i}\) and other for level-2 network \(N_{a}\). The responsibilities of these smart contracts are to initiate transactions in their respective networks and to return state information to the leader script in order to assist the abstraction process. The action performed by the leader script is depicted in Algorithm 1. Steps 5-8 are executed after every \(\delta\) wait-time as per the condition specified in step 4. Observed that step 8 determines whether there exist some concrete transactions in the concrete blockchain (maintained by \(N_{i}\)) whose abstract form yet to take place in the abstract blockchain (maintained by \(N_{a}\)). Steps 6 and 7 extract information from concrete and abstract blockchains respectively with the help of their respective smart contracts. Steps 9 and 10 are responsible to apply abstraction on unattended concrete transactions and to initiate abstract transaction in \(N_{a}\). \begin{table}
\begin{tabular}{c c c c} \hline \hline \multirow{2}{*}{**Cases**} & **Data Exists in** & **Data Exists in** & **Wheather Possible or Not?** \\  & **Concrete Blockchain?** & **Abstract Blockchain?** & **Wheather Possible or Not?** \\ \hline
1 & _True_ & _True_ & _Yes_ \\
2 & _False_ & _False_ & _Yes_ \\
3 & _True_ & _Maybe_ & _Yes_ \\
4 & _False_ & _Maybe_ & _Yes_ \\
5 & _False_ & _True_ & _No_ \\
6 & _True_ & _False_ & _No_ \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Various Cases of Search Operation in Blockchain. Figure 11: Prototypical Setup. For the experiment purpose, we have added more than 40,000 transactions (with values ranging from 100 to 2000) generated randomly in each local network at level-1. Table 2 depicts the experimental results which indicate the variation of blockchain-size both in concrete and abstract domains w.r.t. different wait-time (\(\delta\)) for leaders and different transaction-rate in local networks. The values indicate an average taken over 60 min of observation. This is important to note that since we automate the creation of local transaction randomly, there is a slight variation in the number of blocks and data-size for a given transaction-rate. The results in column 9 clearly show a significant reduction of the data-size and the number of blocks in the abstract domain w.r.t. its concrete counterpart, as we increase \(\delta\). This is because, as leader waits for larger \(\delta\), more number of local transaction-records are being abstracted into a single transaction. The amount of the gas consumption in the execution of both smart contracts (local and abstract agents) are shown in columns 5 and 8 respectively.