## 6 Evaluation
### Performance Evaluation
#### 6.1.2 Scalability and Throughput  
Scalability remains one of the key reasons we selected Polkadot as our blockchain platform. An evaluation was carried out for the two main blockchain operations, adding a product and product verification, which are discussed in the sequence diagram in Figure 4. The scalability test evaluated how the developed model performs under incremental workloads. The system performance for the _add_product_ function can be observed from Figure 5. As the number of transactions increases from 1 to 50, the transaction completion times require an average of 168.5 ms, with a minimum and maximum spread from 151.8 ms to 262.7 ms, respectively. This suggests stable performance under lighter loads. Between 50 and 250 transactions, transaction times are reduced as compared to the prior transaction counts. This demonstrates the ability of the implementation to handle higher request loads. At 500 transactions, there is an unexpected dip in the average response time to 174.8 ms, which arises due to system optimisation or variability in load handling between 250 and 500 transactions. For transaction counts above 500, the service starts to degrade, with significantly higher transaction times. The saturation point for this model is thus estimated to be at approximately 500 transactions. An additional 60 s was given for transaction counts above the saturation point, after which tests were terminated to avoid system crashes. The verification process has two parts: the first involves retrieving the MP reference from Polkadot, and the second involves retrieving the MP itself as a file from the IPFS. Table 3 presents data on the performance of the system handling concurrent requests from 1, 5, and 10 users. The _fetch chain average_ column shows the average time taken to fetch data from the blockchain, and the _ipfs average_ column shows the average time to retrieve MP from the IPFS. The _Requests (incl. authentication)_ column measures the throughput of the system in terms of the number of requests, including authentications processed per second. For one user, as the number of transactions per user increases from 1 to 500, the average fetch time from the blockchain increases, showing a slight degradation in performance as the number of transactions grows. The IPFS retrieval time remains relatively stable, even slightly decreasing as the number of transactions increases, suggesting that IPFS retrieval may benefit from some form of caching or is less affected by increased transaction volume. The request rate per second is highest at 100 transactions per user, indicating an optimal load under which the system performs best for a single user. When the number of users \begin{table}
\begin{tabular}{l l l l} \hline \hline
**Functions** & **Input** & **Output** & **Gas Fee * \\ \hline grant\_roles & userID, role & Success/fail & 0.11363819 \\ \hline revoke\_roles & userID & Success/fail & 0.11363819 \\ \hline check\_roles & userID & Role of the user & No \\ \hline get\_participants & — & List of participants & No \\ \hline add\_product & product\_id, & userID, & Transaction & 0.11363829 \\  & MP\_hash & details & \\ \hline transfer\_product & product\_id, userID, previous transaction details & Transaction & 0.11363829 \\ \hline get\_MP & product\_id & MP & No \\ \hline get\_owner & product\_id & userID & No \\ \hline get\_pro\_details & product\_id & Product info & No \\ \hline get\_pro\_history & product\_id & List of previous owners & No \\ \hline \hline \end{tabular}  
* Gas estimates only include partial fees. Full transaction fees can only be calculated in the production environment.  
\end{table} 
Table 2: Cost evaluation of functions [8]. increases to 5 and then to 10, the average times for both fetching from the blockchain and IPFS retrieval increase significantly. This indicates that the system is experiencing additional strain under the weight of managing multiple parallel sessions.