## 6 Performance Evaluation  
To evaluate the deployed HF-network, as described in Section 5, we have used the Hyperledger Caliper blockchain benchmark tool [42]. Caliper is an open-source benchmark tool, hosted by the Linux Foundation, that enables users to evaluate the performance of different blockchain platforms and consensus algorithms in a standardized environment. It provides a set of predefined use cases and performance metrics while allowing users to define custom scenarios and execute them in order to evaluate them and collect data such as transaction throughput, response time and resource consumption. Caliper functions as a benchmark tool of various blockchain platforms, such as Hyperledger Fabric, Sawtooth, and Ethereum. Caliper can also function under various workloads and configurations [43; 44]. Figure 12: Chaincode approved and committed on channel (step 7). Figure 13: Docker containers for the performance evaluation. In the context of this performance evaluation, we have assumed the test scenario where two peers are interconnected via a shared channel, as described in Section 5. These peers, which were developed in Section 5, are designed to correspond to the characteristics of two gateways within our proposed HF-based architecture. For the purpose of our performance evaluation, we have evaluated the network by collecting results in terms of latency (i.e., min (s), max (s), average (s)), send rate (i.e., transactions per second), throughput (i.e., transactions per second), and memory usage (MB). Regarding parameters, we measured network performance based on (i) \"assets\" (i.e., stored values) stored in the blockchain, and (ii) \"workers\" performing processes in parallel during the benchmark. The \"workers\" parameter in Caliper specifies the number of processes that will take place during the benchmark. Each \"worker\" process runs on a separate thread or CPU core, allowing the benchmark to use multi-core CPUs and distribute the workload across multiple threads. The use of multiple \"workers\" improves the benchmark's performance and scalability by allowing it to process transactions in parallel. However, it is worth noting that increasing the number of \"workers\" also increases memory usage. In general, the optimal number of \"workers\" for a given Caliper benchmark will depend on the specific blockchain network and workload being tested, as well as the available system resources. The selection of \"assets\" parameter for evaluating network performance allows us to test the network's efficiency as the number of stored objects increases. On the other hand, the quantity of \"workers\" directly relates to the scalability potential of the architecture, showcasing the network's ability to handle elevated transaction volumes simultaneously. As a result, as stored objects and parallel transactions significantly impact the performance of a HF network, the results of the performance evaluation are directly relevant to real-world scenarios involving HF-based architectures. The conclusions drawn from these results are highly applicable to real-world implementation. In our case, we have experimented with different values of the \"workers\" parameter on the network in order to evaluate the network and identify its optimal settings. We have experimented in instances of 1, 2, 5, 10, 15, and 20 \"workers\", while we have kept the number of the assets at 5. The \"asset\" parameter defines the number of assets (i.e., stored values) that are included in the ledger. We have experimented in instances of 5, 10, 25, 50, 75, 100, and 150 assets in each performance evaluation iteration, and we have maintained the number of \"workers\" at 4. We have tested the following two chaincode functions in the present evaluation: (i) _create_asset_ and (ii) _read_asset_. The _create_asset_ function creates an asset and appends it to the ledger according to a corresponding asset template. On the other hand, the _read_asset_ function reads the assets stored in the ledger.