## 5 Experimental Environment
### Experimental Results and Discussion
#### 5.2.1 Network Performance  
In this section, we investigated the scalability performance of our test network with increasing transaction load, ranging from 100 to 1100 transactions per round (i.e., a single iteration of testing), using the Hyperledger Caliper analysis tool. Scalability refers to the network's ability to handle growing transactions without significant performance degradation. The experiments ran five tests for each transaction load setting, and the latency metrics (maximum, minimum, and average) were recorded and analyzed. Figure 3 represents the maximum, minimum, and average latency observed across different transaction loads (100, 200, 300, 400, \(\ldots\), 1100). The plot illustrates how latency metrics change with increasing transaction volumes. Analyzing maximum, minimum, and average latencies helps identify performance trends and informs optimization strategies such as capacity planning, resource allocation, and workload distribution. The maximum latency metric indicates the peak response time observed during a round of transactions. It represents the upper bound of transaction execution times and is crucial for identifying potential performance bottlenecks or outliers. Conversely, minimum latency represents the fastest response time achieved during a round of transactions. It provides insights into the best-case performance scenario and highlights the efficiency of the blockchain network under optimal conditions. The average latency metric summarizes the network's overall performance by calculating the mean response time across all transactions in a round. It serves as a baseline indicator of transaction processing efficiency and system responsiveness. As transaction loads increase, latency metrics typically exhibit non-linear behavior. Initially, latency may remain relatively stable but can increase sharply beyond a certain threshold due to resource saturation or contention. Figure 4 illustrates the network throughput and send rate relationship across transaction volumes. The send rate refers to the rate at which transactions are submitted to the blockchain network. It corresponds to the frequency of transaction submissions during each experimental round. We systematically varied the transaction loads, ranging from 100 to 1100 transactions per round, to assess the network's scalability and performance under increasing workloads. As the number of invoked transactions increases (from 100 to 1100), the network throughput demonstrates a linear increase in Figure 4. This suggests the network's capacity to process transactions scales proportionally with transaction volume. Higher send rates (faster transaction submissions) correlate with increased network throughput, highlighting the importance of transaction rate management in optimizing network performance. Network throughput is proportional to latency. Network throughput tends to increase due to faster transaction processing and reduced queuing delays, while latency rises slower, as depicted in Figure 5.  
Next, we analyze the total execution time. The total transaction execution time is the cumulative duration required to process and commit all transactions within a given workload. It includes transaction initiation, endorsement, ordering, validation, and ledger  
Figure 4: Throughput paired with network send rate. Figure 5: Network throughput vs. transaction latency. Figure 3: Maximum, minimum, and average latency. update processes. Figure 6 illustrates the relationship between the total transaction execution time and the number of invoked transactions (ranging from 100 to 1100). As the number of invoked transactions increases from 100 to 1100, there is linear growth in the total transaction execution time. This suggests that transaction processing time scales proportionally with transaction volume, reflecting the network's ability to handle larger workloads. The linear increase in execution time indicates that the transaction volume influences the blockchain network's processing capacity.