## 9 Prototype Testing and Results
### Evaluation of Blockchain Performance  
For prototype testing, we configured two peer nodes of the Membership Service Provider (MSP)--the Census Bureau node and the NGO node. The Hyperledger Fabric chain code deployed Amazon Web Services (AWS) and utilized Amazon Lightsail [69] with the specification of 4 GB RAM, 2 CPUs, and 80 GB SSD. The IPFS was configured on infura.io [70], and the total amount of data stored was 128 MB for 265 sets of household information and 30 thumbprint files. The front-end application was deployed and run directly on the tablets with fingerprint SDK installed on it. Given the above, it is also important to mention that this was non-funded research work. The BINC-TAPS framework performance was evaluated using the latency and block size metrics, outlined as follows:  
* Latency: It is characterized as the delay occurring when one component of a system awaits a response from another system component. Within the blockchain network context, latency refers to the duration between the submission of a transaction to the network and the initial acceptance confirmation by the network. * Block size evaluation: The block size denotes the volume of data stored in a single block, with each block containing transaction data in the chain. The examination of block size involves analyzing the average increase in the size of files or the blockchain. The performance was assessed for three main functions: (i) creating a record, (ii) obtaining a record, and (iii) updating a record. These are the primary functions that occur in a national census system. We examined the record creation time to assess latency, as illustrated in Figure 10a. The random delays in the request execution times stemmed from the decentralized nature of the blockchain. With multiple nodes involved and no central system controlling the data, the variations in execution times occurred due to factors like individual node capacities, time-consuming and lengthy census forms, delays in transaction submission, local machine response times, machine speed, and internet bandwidth across the blockchain network. These elements contributed to latency variations across different servers. Figure 9: Evaluation of software usability. The function of creating a record was reiterated 5000 times, propelling the blockchain's expansion from 0.69 KB to 409 KB over 5000 blocks. Demonstrating an average size increase of 79 KB, Figure 9(b) highlights a consistent correlation between the quantity of blocks and the overall size of the blockchain. Notably, for recently mined blocks containing a substantial volume of transactions, the figure reveals a linear increase in file size, particularly evident between blocks 1012 and 1125. Throughout these processes, the development strategy abstained from specifying the number of transactions per block, resulting in nuanced size differences contingent on the nature of each operation. Regardless of blockchain performance, we tested this method with limited resources and within the neighborhood of one of the researchers (neighbor advocates around their neighborhood), primarily to validate the idea of improving the population coverage issue of national housing and population censuses. However, the entire system sizing had been performed well in another publication [71], as well as the assessment of the network's traffic (workload) and solution deployment architecture. To determine the peak workload value for the system, an estimation was made based on the Pakistan Census facts from 2017 and 2023. With 121,000 enumerators working 8 h a day for 30 days to enumerate 32,185,605 households, each enumerator collecting data on an average of 6.39 individuals per household, the total number of data points to be recorded would reach 237,752,338. Additionally, considering one thumbprint collected and stored on the IPFS for each household representative, the system's workload would involve handling approximately 16,511 transactions per minute or 275 transactions per second.