# A Blockchain Self-Sovereign Identity for Open Banking Secured by the Customer's Banking Cards
## 7 Discussion and Evaluation
### Performance Analysis
#### 7.4.1 Throughput and Latency  
The throughput and time per transaction achieved for different sets of recorded customers, from 100 to 500, are shown in Figure 9. In addition, the performance when sending a concurrent set of calls, of 10, 25, 50, and up to 300 transactions per second, was assessed, as presented in Figures 10 and 11. To test the throughput performance, we used sets of customers of 100, 200, and up to 500 as a small-scale implementation. The send rate varied from 10 to 300 transactions per second. The signing operation by the Java Card depends on the speed of APDU command exchange and the chip characteristics to process the SECP256K1 signing function. For the sample card used for our testing, we observed an average time for the card crypto-operation of \(\sim\)3.2 s. The broadcasting, mining, and publishing to the Blockchain are all included in the transaction time duration. We were able to measure the time including the signing by the card for the case of one transaction at a time, while for stress testing, we pre-signed a set of 10, 25, 50, and up to 300 transactions to assess the performance. It was observed that key generation on the card takes a relatively long duration, of about 10 s; however, it is done only once during the registration phase for each customer, and hence it is still acceptable behavior. The observed behavior for sending rates of 10, 25, 50, and up to 300 transactions per second (tps) for Create_VC calls, which in terms of Blockchain access is a write operation, is shown in Figure 10, which indicates the throughput is relatively increasing. However, after 125 tps the throughput starts to slightly decrease, then significantly increases at 200 tps, before gradually decreasing again. The average throughput of write transactions is 53.07 tps. The latency increases up to the sending rate of 175 tps, then drops at 200 tps, before the trend gradually increases again. The observed average latency for the write operation was 2.55 s.  
Figure 10: Latency (**left** side) and throughput (**right** side) for Create_VC (write operation) under different sending rates of 10, 25, 50, and up to 300 tps. Figure 9: Transaction processing time (**left** side) and throughput (**right** side) for create and verify operations for different recorded sets of customers. For Verify_VC calls, which are read operations, as shown in Figure 11, the transaction throughput increases until starting to decrease after 125 tps; furthermore, it oscillates and relatively increases at 200 tps and 275 tps, and then the trend goes down. The average throughput of read transactions was 60.69 tps. The transaction latency increased with higher sending rates up to 175 tps, then dropped at 200 tps, before the trend gradually increased again, although it started to decrease after 250 tps. The observed average latency for the read operation was 1.93 s.  
Throughput significantly varies depending on the function performed, such as Create_VC, which implies smart contracts; the throughput is much lower than that of read operations such as Verify_VC. We tested the performance with a set of customers ranging from 100 to 500 and sending rates of 10, 25, 50, and up to 300 tps. The latency and throughput for this testing show that optimum performance happened at 200 tps, with a throughput of 82 tps in writing operations and 93 tps in reading operations, while the latency observed was 2.2 s for writing and 1.9 s for reading. However, these preliminary evaluation metrics are highly impacted by the capacity and Blockchain setup configuration, such as the size of the network and the number of nodes, in addition to the expected load (transaction sending rate). Although the system showed a stable throughput, which complies with our preliminary proof-of-concept implementation, it does not satisfy the real-world banking use case. The customer expects a much faster transaction.