# Latency Analysis of Blockchain-Based SSI Applications +
## 3 The Proposed Evaluation Architecture Using Indy
However, the codes available at the Aries official repository allows for only 20 TXs/s; thus, we had to implement our own agent. We implemented Indy node scripts that are suitable to be run individually on different machines. That is, the available modules we found, at the official Indy repository, run four nodes on a single machine, and they were not ready for production. As a demonstration of the requirement of the network to control different nodes by different admins, we also utilized the Admin UI from the VON network repository, which we configured to connect to the created Indy network. All our implemented application components are containerized using Docker, which makes them easier to deploy for present and future works. Our implemented application is publicly available at Github ([[https://github.com/sed-szeged/IndyPerf](https://github.com/sed-szeged/IndyPerf)]([https://github.com/sed-szeged/IndyPerf](https://github.com/sed-szeged/IndyPerf)), accessed on 26 September 2022) (see Supplementary Materials), and its main management scripts are as follows:  
* indy_config.py: This file contains the configuration to run the Indy node, i.e., the name of the network and the installation parameters. * requirements.txt: This file contains system dependencies. We used Flask to create a web service, which displays the genesis file extracted from the container, according to which the admin application could connect. * indy-node-start.sh: This script starts the server.py in a container to create a BC node. * create_steward.py: This script can be used to add new stewards, thus adding new nodes to the system. * test_transactions.py: This script can be used to perform the experiments (to be detailed in the next section). It creates a connection with the BC network, and sends the specified TXs in multiple threads. We performed several scenario runs using our multi-threaded Aries agent with different TX arrival rates (1-250 TX/s) and different network sizes (4-8). Each scenario run was repeated 10 times, for a total BC height of 10-2500 blocks. This way, an average latency for different heights of the BC, with different network sizes, can be extracted. We measured the elapsed time for a TX to be sent, processed, and responded to. We have collected the minimum and maximum latency measures, and computed their average values. We separately examined the read and write speeds to guarantee the accuracy of our measurements. All nodes were deployed and run individually on different virtual machines, located in different regions of the Google Cloud Platform. We used E2-medium VMs (up to 3.8 GHz, 2 vCPUs, 4 GB memory) running Ubuntu 16.04 OS. Visualizations of the evaluation architecture and installation steps are provided in Figure 2.  
We also performed similar read and write latency measurements in a local Docker four-node environment, with increased TX arrival rates (1-500 TX/s), to be able to compare the results of a system with an optimal network performance with a more real-life scenario, where the nodes are in different regions. The architecture of the Indy ledger in the local Docker environment can be seen in Figure 3.