Latency Assessment of Blockchain-based SSI Applications
Utilizing Hyperledger Indy
Hamza Baniata
1 a
, Tamas Pflanzner
1 b
, Zoltan Feher
and Attila Kertesz
1 c
Department of Software Engineering, University of Szeged,
Dugonics t
er 13, 6720, Szeged, Hungary
Blockchain, Self Sovereign Identity, Hyperledger Indy, Latency Analysis.
Blockchain is the core technology behind several revolutionary applications that require consistent and im-
mutable Distributed Ledgers, maintained by multi-party authorities. Examples of such applications in-
clude cryptocurrencies, smart contracts, Self Sovereign Identity (SSI) and Edge/Fog-enabled smart systems
(eHealth, IIoT, IoV, etc.). Hyperledger Indy and Aries are suitable open-source tools for permissioned
blockchain utilization in SSI projects. Those two frameworks have gained much attraction by researchers
interested in the topic, while continuously maintained under the umbrella of the Linux Foundation. However,
some SSI applications require specific upper bound of response time depending on their business model. In
this paper we aim at presenting a detailed latency analysis of Indy, on top of which Aries is typically built.
With such an architecture, researchers and practitioners of SSI applications can decide whether this framework
fulfills their application requirements. To realize our proposed architecture, we have developed a Python ap-
plication with containerized Indy and Aries components. Its scripts use and build on the official open-source
codes of the Hyperledger repositories. We have deployed our application on multiple virtual machines in the
Google Cloud Platform, and evaluated it with various scenarios. Depending on the transaction rate, we found
that the writing response latency of an Indy-based blockchain containing 4 and 8 nodes, ranges between 1–16
seconds, while the reading response latency with similar settings ranges between 0.01–5 seconds.
Blockchain (BC) (Nofer et al., 2017) is a technology
utilized for enhancing trust in Distributed Computing
applications and managing Distributed Ledgers (DL).
Applications integrated with permissionless BCs ben-
efit from high levels of security and trust, where BCs
provide fully-immutable log of transaction (TX) his-
tory without the control of a central authority. Simi-
larly, permissioned BCs utilize a Distributed Trusted
Third Party for providing services typically requested
from a Central Trusted Third Party. Permissioned
BCs are used in applications that require trusted BC
nodes, typically referred to as Miners, Minters, Ver-
ifiers or Validaters, to maintain a trusted and con-
sistent DL. Initially, those participants apply for be-
coming BC nodes to a committee that votes for
inclusion. Permissionless BC solutions have been
designed first for realizing digital cryptocurrencies
(Abraham et al., 2016), but nowadays they address a
wide variety of environments, such as document man-
agement (Karasek-Wojciechowicz, 2021), smart ap-
plications for eHealth (Transaction and MPI, 2016)
or Internet of Vehicles (Javaid et al., 2020). In such
access model, any party can join the BC network and
collaborate in validating and confirming new pieces of
data added to the DL, without a limit of network size.
Permissioned BC solutions, on the other hand, are
suitable for applications that require distributed yet
controlled Trusted Third Party, where a limited num-
ber of verifiers vote for appending data into the DL
and for accepting new verifiers. Examples of applica-
tions that require such BC model include distributed
voting (Bistarelli et al., 2019), Self Sovereign Identity
(SSI) (Kondova and Erbguth, 2020), and credential
management (Jirgensons and Kapenieks, 2018).
Specifically, classical internet applications lack an
identity layer (Tobin and Reed, 2016). Web applica-
tions, for instance, use usernames and passwords to
identify their clients, yet the use of these attributes is
typically limited to the specific contexts of individual
Baniata, H., Pflanzner, T., Feher, Z. and Kertesz, A.
Latency Assessment of Blockchain-based SSI Applications Utilizing Hyperledger Indy.
DOI: 10.5220/0011082300003200
In Proceedings of the 12th International Conference on Cloud Computing and Services Science (CLOSER 2022), pages 264-271
ISBN: 978-989-758-570-8; ISSN: 2184-5042
2022 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
applications. Such a framework is considered incon-
venient and implies several security issues (e.g. iden-
tity theft and fake users) (Thomas et al., 2019). Global
identity (Makri et al., 2021) providers, like Google or
Meta, attempt to develop their access framework to
enhance its usability. However, data leaks are still ar-
gued to remain as an open-issue (Boysen, 2021). Ad-
ditionally, the loss of clients’ control over their private
data, which is typically saved on centralized servers,
implies trust issues. Some solutions allow users to
request the deletion of their data, in order to comply
with the European General Data Protection Regula-
tions (GDPR), yet users have to also trust the provider
to delete them. SSI concepts enable users to anony-
mously identify themselves, and verify some private
attributes about them, while maintaining full control
and permissions over their private data.
Although permissioned BCs have shown unprece-
dented abilities to maintain DLs with high security
and trust measures, compared to non-BC based DLs,
they still suffer from high latency compared to cen-
tralized solutions. Furthermore, different permis-
sioned BC solutions are designed differently accord-
ing to their application and the different layering of
the solution. This usually causes a fluctuation of la-
tency measures among different permissioned BC so-
lutions and even for differently parameterized solu-
tion. Such issue mainly appears due to several sys-
tem properties and limitations, such as the minimum
time needed to reach a consensus on a piece of data
(i.e. Finality time), the average transmission delay be-
tween network entities, the total network size and the
average number of neighbors per miner (Kertesz and
Baniata, 2021). This being said, researchers and prac-
titioners tend to model their applications and test sev-
eral BC solutions for a decision to be made regarding
the deployment of a specific BC framework. As many
solutions are being continuously proposed, it must be
a burden to utilize and test several frameworks before
assuring the application requirements are fulfilled by
a selected BC framework.
As several recent works have utilized Hyperledger
Indy (Linux Foundation, 2020), and several projects
are currently investigating its deployment for their
SSI applications, the aim of this work is to anal-
yse Hyperledger Indy in terms of latency. To ap-
proach our objective, we propose a deployment ar-
chitecture using Indy and Aries suitable for SSI ap-
plications. We have developed a Python application
with containerized Indy and Aries components, build-
ing on the official open-source Hyperledger projects.
We have deployed our application onto multiple vir-
tual machines in the Google Cloud Platform, and per-
formed a detailed evaluation with different scenarios
varying the number of BC nodes and TX arrival rates.
The remainder of this paper is as organized as
follows: Section 2 provides a brief architectural and
technical background of Hyperledger Indy. Section 3
presents the research methods and design decisions.
Section 4 presents the results we obtained by running
our experiments, which are discussed in Section 5.
Section 6 discusses recent related works and, finally,
Section 7 concludes the paper.
Hyperledger Indy (Linux Foundation, 2020) is an
open source project, administered by the Linux foun-
dation, which aims at supporting Verifiable Credential
(VC) systems based on public-permissioned BC ap-
proach. The project implementation provides a plat-
form for Decentralized Identifiers (DIDs) rooted on
BCs, or other DLs, so that they are inter-operable
across administrative domains, applications, etc. and
usable for validating VCs. The project deploys pri-
vacy preserving mechanisms such as the Zero Knowl-
edge Proofs and Digital Signatures. Additionally,
Indy takes good care of what is saved on-chain, aim-
ing at the adherence with the GDPR. The Plenum
Consensus Algorithm is used in Indy, which is a spe-
cial purpose Redundant Byzantine Fault Tolerance
Consensus Algorithm (Aublin et al., 2013). A live
example of an Indy based solution is the Sovrin BC
(Windley, 2016) providing a general purpose, global
DID-supportive platform.
As depicted in Figure 1, Indy requires a small
group of miners that serves as a Distributed Trusted
Third Party. Indy miners, or validators, are computers
administered by publicly known parties, added by a
voting scheme between miners themselves. The min-
ers main purpose is to maintain the liveness and con-
sistency of the DL by accepting new TXs. Several
types of BCs consist of different types of TXs that
need to be saved on-chain. Three of those BCs are de-
picted in the figure which are the Domain TXs BC, the
Pool TXs BC and the Config TXs BC. On these BCs,
public data about admins of miners, TXs meta data
and network configurations are saved, respectively.
Indy miners are added to the system in a decen-
tralized fashion, if they fulfil certain conditions. Indy
allows that by a voting scheme, where available min-
ers accept or decline a new miner application. A stew-
ard miner is an authorized Indy node that is needed to
be able to add new nodes to the network. Only one
node can be added per steward, so an equal number
of stewards and miners need to be present. The avail-
Latency Assessment of Blockchain-based SSI Applications Utilizing Hyperledger Indy
Figure 1: Our proposed Blockchain architecture based on Indy.
able sample code at the official Indy repository creates
four steward nodes. To add the first four nodes of the
network, four wallets and four pairs of PKI keys need
to be created. However, a genesis block is created
along with the initial stewards DIDs at the initializa-
tion phase of the system. Here, the stewards data are
generated by seed defined by the developer. Then,
NYM requests are sent by the wallet admins to the
network of stewards who accept/reject the TXs. Once
accepted, a new wallet is created and a block is added
to the BC. Once a minimum of four miners are ac-
tive, the BC network can accept new DID and schema
TXs from end-users. Endorsers and agents are end-
user entities of the system that should be implemented
using the Aries scripts. The only main difference be-
tween these two types of end-users is that agents are
only authorized to read on-chain data while endorsers
are authorized to both read and write.
To realize the deployment of Indy and Aries nodes,
we have designed and developed a validation archi-
tecture as depicted in Figure 1. We implemented an
Aries agent that is capable of connecting to an Indy
network, and of generating sample data (i.e. TXs),
to be submitted to it. We extracted the initial codes
from the Indy-SDK repository, which is implemented
using Python. Our agent is capable of sending up to
250 TX requests per second, using a multi-threaded
approach, to examine the system’s read and write pro-
cessing speeds. The sample TXs are constructed simi-
larly to the standard TX formats generated by an Aries
agent. However, the codes available at the Aries of-
ficial repository allows for only 20 TXs/second, thus
we had to implement our own agent.
We have 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 demon-
stration of the network is needed to control different
nodes by different admins, we have 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
containarized using Docker, which makes them easier
to deploy for present, and future works. Our imple-
mented application is publicly available at Github
and its main management scripts are as follows:
indy This file contains the configura-
tion to run the Indy-node, i.e. the name of the
network and the installation parameters.
requirements.txt: This file contains system depen-
dencies. We used Flask to create a Web-Service,
which displays the genesis file extracted from the
container, according to which the admin applica-
tion could connect. This script starts the
in a container to create a Blockchain node.
CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science
Figure 2: Evaluation architecture and installation steps.
create This script can be used to add
new stewards, thus new nodes to the system.
test This script can be used to
perform the experiments (to be detailed in the
next section). It creates connection with the BC
network, and sends the specified TXs in multiple
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 is repeated 10 times, which gives
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 mea-
sured 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 mea-
surements. All nodes were deployed and run individ-
ually on different virtual machines, located in differ-
ent 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.
In this section, we present the latency measures we
obtained by deploying our scripts on multi-regional
cloud servers.
4.1 Four-node Measurements
Table 1 provides the detailed read and write latency
measures. We have computed those measures for an
Indy network that consists of four nodes. We found
that the size of data stored on-chain does not affect
the speed as the ten measures we have collected per
scenario were very close to each other. However, we
can see a proportional relation between the TX arrival
rate and the average latency for both read and write
TXs. It is also worth noting that the average write
latency fluctuates from 2.7 to 6.3 seconds per TX, de-
pending on the TX arrival rate. On the other hand,
the average read latency fluctuates from 0.088 to 1.56
seconds per TX
4.2 Eight-node Measurements
Table 2 provides the detailed read and write latency
measures. We have computed those measures for an
Latency Assessment of Blockchain-based SSI Applications Utilizing Hyperledger Indy
Table 1: Latency measures, in seconds, for read (R) and write (W) TXs where network size = 4.
TX Arrival rate (TXs/s)
type 1 50 100 150 200 250
Min (W) 1,1014 1,1014 1,1014 1,1014 1,1014 1,1014
Max (W) 2,9832 2,9138 2,9490 5,8131 6,8542 13,3811
Avg (W) 2,7388 2,5284 2,2197 4,4763 5,3511 6,3534
TX Arrival rate (TXs/s)
type 1 50 100 150 200 250
Min (R) 0,0108 0,0671 0,1058 0,0841 0,2469 0,0800
Max (R) 0,2160 1,1387 1,4655 2,2378 2,5302 4,7086
Avg (R) 0,0881 0,3961 0,5815 0,8964 1,1408 1,5562
Table 2: Latency measures, in seconds, for read (R) and write (W) TXs where network size = 8.
TX Arrival rate (TXs/s)
type 1 50 100 150 200 250
Min (W) 0,2614 1,7064 1,5032 1,3114 1,2914 1,5289
Max (W) 2,9949 2,9607 5,2011 8,5050 7,4365 16,9094
Avg (W) 2,6118 2,5993 2,5347 4,8506 5,5883 10,4323
TX Arrival rate (TXs/s)
type 1 50 100 150 200 250
Min (R) 0,0092 0,0567 0,0927 0,0667 0,0350 0,0219
Max (R) 0,7147 1,1744 1,4469 1,9189 2,4340 5,6863
Avg (R) 0,1203 0,3718 0,5430 0,8163 1,0652 2,4928
Indy network that consists of eight nodes. Here, we
have also found that the size of data stored on-chain
does not affect the latency. We can also see that in-
creasing the arrival rate increases the average latency
for both types of requests. It is observable in the ta-
ble that the average write latency fluctuates from 2.6
to 10.4 seconds per TX depending on the arrival rate.
On the other hand, the average read latency fluctuates
from 0.12 to 2.49 seconds per TX.
As we can observe in the results presented in the pre-
vious section, increasing the number of Indy nodes
and/or the arrival rate increase the average response
latency. These measures are important to consider
when Indy is considered as a framework for a given
BC-based application. The scenarios we tested, and
their results, shall help those who tend to utilize Indy
and Aries for a decision to whether adopt or exclude
this platform from their project. To further clarify the
results we obtained, we present our results in Figures
3 and 4.
In the case of read TXs, we can observe that the
average latency measurement is almost linearly pro-
portional to the arrival rate up to 200 TXs/s. After
that, the latency starts to increase according to the
number of nodes deployed. In the case of write TXs,
we can observe that the average latency measurement
is almost constant up to an arrival rate of 100 TXs/s.
After that, the latency starts to increase depending
on the system buffer size and the utilized processing
Furthermore, one can see that the average write la-
tency is generally higher when deploying more nodes
for different arrival rates. The read latency, on the
other hand, is generally lower when deploying more
nodes as more servers are available to process the re-
ceived TXs. A utilization example of these results
may be a latency-sensitive application that requires an
average write latency that is less than 2 seconds per
TX shall not adopt the Indy framework. Note that this
measurement is for the least number of Indy nodes
(i.e. 4 nodes). Adding more nodes shall increase the
write latency as discussed above.
During the implementation and deployment of
Indy and Aries nodes, we faced the following draw-
backs/challenges. DLs in Indy are maintained lin-
early, which implies that high DL consistency de-
pends on high block finality time (Baniata et al.,
2022). This causes additional write latency on top of
the latency required for reaching a consensus. Pro-
viding global information regarding what accredita-
tion bodies approve/disapprove, and on which refer-
ence criteria blocks are confirmed, cannot be done us-
CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science
Figure 3: Latency of write TXs (in seconds) measured with different Indy-based Blockchain network sizes (4 and 8) and
different arrival rates (1–250).
Figure 4: Latency of read TXs (in seconds) measured with different Indy-based Blockchain network sizes (4 and 8) and
different arrival rates (1–250).
ing the currently available open-source code of Indy
and Aries. The maximum recommended number of
nodes participating as BC miners is 25. Adding more
nodes is declared to introduce an inefficient system
with very high latency. The open-source code cur-
rently available allowed us to perform very limited
modifications, and we found that the deployment of
an enterprise Indy solution requires deep background
knowledge of its technicalities. For example, we tried
to deploy the Indy node codes on a recent version of
the Ubuntu OS but we could not because of very re-
strictive dependencies of the deployed libraries. We
have not found a clear and proactive trust model for
adding new Endorsers or Stewards. Thus, adding En-
dorsers does not necessarily mean they are accredited
in the associated legacy system.
and BCDiploma
are examples of services
built for providing VC supportive platforms utilizing
DIDs. The BC acts as the TTP where system enti-
ties save their data. However, the standard recom-
Latency Assessment of Blockchain-based SSI Applications Utilizing Hyperledger Indy
mendation of W3C
and the solutions following it did
not consider the issuer accreditation issue assuming
any entity should be able to own a DID and issue
any type of VCs. The BCDiploma platform directly
saves all issued VC hashes on the Blockchain which
means that they can never be deleted, and it uses a
PoW-based BC with linear DL model. Additionally,
issuer accreditation service is not provided. Specifi-
cally, EBSI utilizes the general purpose Hyperledger
which uses the Raft Consensus algorithm.
In (Sopek et al., 2018b) and (Raclawickie, 2019),
a BC-based data management system that could be
used for the Global Legal Entity Identifier System
(GLEIS) is proposed. For realizing this, the authors
utilized Hyperledger Indy and their previously pro-
posed GraphChain (Sopek et al., 2018a). The imple-
mentation and utilization model of the proposed solu-
tion were presented, in which some challenges were
faced such as the limited message size of Indy.
Bhattacharya et al. (Bhattacharya et al., 2020) ex-
amined certain scenarios of personal data disclosure
via credential exchanges between different identities
and the risks of man-in-the-middle attacks in a BC-
based identity system utilizing Hyperledger Indy. On
the basis of the findings, the authors proposed enhanc-
ing Indy with a novel attribute sensitivity score model
for SSI agents to ascertain the sensitivity of attributes
shared in credential exchanges. Additionally, they
proposed a method for mitigating man-in-the-middle
attacks between peer SSIs. Finally, they proposed a
novel quantitative model for determining a credential
issuer’s reputation based on the number of issued cre-
dentials in a window period, which is then utilized to
calculate an overall confidence level score for the is-
Prakash et al. (Prakash et al., 2020) work pro-
posed Indy and Aries agents that are implemented
and utilized to realize a connected vehicle information
network solution. The authors described several chal-
lenges they faced when utilizing those two projects,
including the high latency and scalability limitations.
However, the paper has not provided specific latency
measures and settled for a description of the solution.
Malik et al. (Malik et al., 2021) proposed an
architecture for decoupling identities and trade ac-
tivities on blockchain-enabled supply chains, namely
TradeChain. The authors demonstrated the feasibility
of TradeChain by implementing a proof of concept
implementation on Hyperledger Fabric and Indy. The
limited latency evaluations provided for this solution
are within the ranges we obtained by our experiments.
A detailed and comprehensive details related to
different BC platforms, including Indy and Aries are
presented in (Mohanty, 2018). Here, well docu-
mented tutorials and implementations can be found,
as well as descriptive methods and algorithms for dif-
ferent consensus and block confirmation approaches.
Additionally, architectural and low-level details have
been differentiated between the studied BC platforms.
Though these works investigate SSI issues with
Indy and Aries, none of them has performed detailed
latency analysis of them with different system settings
concerning network sizes and TX arrival rates.
In this paper, we proposed a deployment architecture
for SSI applications, and developed a Python appli-
cation with containerized components to realize it.
We evaluated our proposed architecture in terms of
latency by deploying its components in the Google
Cloud Platform, at different regions with individual
VMs. We executed several test scenarios to obtain av-
erage latency measures for different system settings,
namely different network sizes and different TX ar-
rival rates. For arrival rates between 1 and 250, we
found that the write response latency of an Indy-based
BC containing 4 and 8 nodes, ranges between 1 to 16
seconds, while the read response latency with simi-
lar settings ranges between 0.01 to 5 seconds. In the
future, we plan to enhance the scalability of our appli-
cation by dynamic, automated BC node addition and
The research leading to these results has received
funding from the national project TKP2021-NVA-09
implemented with the support provided by the Min-
istry of Innovation and Technology of Hungary from
the National Research, Development and Innovation
Fund, and from the UNKP-21-4 New National Ex-
cellence Program of the Ministry for Innovation and
Technology from the source of the National Research,
Development and Innovation Fund. The experiments
presented in this paper are based upon work supported
by Google Cloud.
Abraham, I., Malkhi, D., Nayak, K., Ren, L., and Spiegel-
man, A. (2016). Solidus: An incentive-compatible
CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science
cryptocurrency based on permissionless byzantine
consensus. CoRR, abs/1612.02916.
Aublin, P.-L., Mokhtar, S. B., and Qu
ema, V. (2013). Rbft:
Redundant byzantine fault tolerance. In 2013 IEEE
33rd International Conference on Distributed Com-
puting Systems, pages 297–306. IEEE.
Baniata, H., Anaqreh, A., and Kertesz, A. (2022). Dons:
Dynamic optimized neighbor selection for smart
blockchain networks. Future Generation Computer
Systems, 130:75–90.
Bhattacharya, M. P., Zavarsky, P., and Butakov, S. (2020).
Enhancing the security and privacy of self-sovereign
identities on hyperledger indy blockchain. In 2020 In-
ternational Symposium on Networks, Computers and
Communications (ISNCC), pages 1–7. IEEE.
Bistarelli, S., Mercanti, I., Santancini, P., and Santini, F.
(2019). End-to-end voting with non-permissioned and
permissioned ledgers. J. Grid Comput., 17(1):97–118.
Boysen, A. (2021). Decentralized, self-sovereign, consor-
tium: The future of digital identity in canada. Fron-
tiers in Blockchain, 4:11.
Javaid, U., Aman, M. N., and Sikdar, B. (2020). A scal-
able protocol for driving trust management in internet
of vehicles with blockchain. IEEE Internet of Things
Journal, 7(12):11815–11829.
Jirgensons, M. and Kapenieks, J. (2018). Blockchain and
the future of digital learning credential assessment and
management. Journal of teacher education for sus-
tainability, 20(1):145–156.
Karasek-Wojciechowicz, I. (2021). Reconciliation of anti-
money laundering instruments and european data
protection requirements in permissionless blockchain
spaces. Journal of Cybersecurity, 7(1):tyab004.
Kertesz, A. and Baniata, H. (2021). Consistency analy-
sis of distributed ledgersin fog-enhanced blockchains.
In European Conference on Parallel Processing.
Kondova, G. and Erbguth, J. (2020). Self-sovereign identity
on public blockchains and the gdpr. In Proceedings of
the 35th Annual ACM Symposium on Applied Com-
puting, pages 342–345.
Linux Foundation (2020). Hyperledger indy. hyperledger.
Makri, K., Papadas, K., and Schlegelmilch, B. B. (2021).
Global social networking sites and global identity: A
three-country study. Journal of Business Research,
Malik, S., Gupta, N., Dedeoglu, V., Kanhere, S. S., and Ju-
rdak, R. (2021). Tradechain: Decoupling traceabil-
ity and identity inblockchain enabled supply chains.
arXiv preprint arXiv:2105.11217.
Mohanty, D. (2018). Blockchain From Concept to Ex-
ecution: BitCoin, Ethereum, Quorum, Ripple, R3
Corda, Hyperledger Fabric/SawTooth/Indy, Multi-
Chain, IOTA, CoCo. BPB Publications.
Nofer, M., Gomber, P., Hinz, O., and Schiereck, D. (2017).
Blockchain. Business & Information Systems Engi-
neering, 59(3):183–187.
Prakash, N., Michelson, D. G., and Feng, C. (2020).
Cvin: Connected vehicle information network. In
2020 IEEE 91st Vehicular Technology Conference
(VTC2020-Spring), pages 1–6. IEEE.
Raclawickie, A. (2019). Legal entity identifier
blockchained by a hyperledger indy implemen-
tation of graphchain. In Metadata and Semantic
Research: 12th International Conference, MTSR
2018, Limassol, Cyprus, October 23-26, 2018,
Revised Selected Papers, volume 846, page 26.
Sopek, M., Gradzki, P., Kosowski, W., Kuziski, D., Tro-
jczak, R., and Trypuz, R. (2018a). Graphchain: a dis-
tributed database with explicit semantics and chained
rdf graphs. In Companion Proceedings of the The Web
Conference 2018, pages 1171–1178.
Sopek, M., Grakadzki, P., Kuzinski, D., Trojczak, R.,
and Trypuz, R. (2018b). Legal entity identifier
blockchained by a hyperledger indy implementation
of graphchain. In Research Conference on Metadata
and Semantics Research, pages 26–36. Springer.
Thomas, K., Pullman, J., Yeo, K., Raghunathan, A., Kelley,
P. G., Invernizzi, L., Benko, B., Pietraszek, T., Patel,
S., Boneh, D., et al. (2019). Protecting accounts from
credential stuffing with password breach alerting. In
28th {USENIX} Security Symposium ({USENIX} Se-
curity 19), pages 1556–1571.
Tobin, A. and Reed, D. (2016). The inevitable rise of self-
sovereign identity. The Sovrin Foundation, 29(2016).
Transaction, C. P. and MPI, M. P. I. (2016). Blockchain:
Opportunities for health care. CP Transaction.
Windley, P. J. (2016). How sovrin works.
Latency Assessment of Blockchain-based SSI Applications Utilizing Hyperledger Indy