Re: Some Burning Questions on Decentralized Identity/Self-Sovereign Identity - Please help? -- Nathan Aw from Singapore

>
> 1. Understand that Indy Node maintains a public permissioned distributed
> ledger and arrives at consensus via RBFT. In this ledger (rocksDB), it
> contains the transaction logs which are connection requests/proof request
> correct? Key-value store.
>

The ledger does use RocksDB for persistence.

Connection requests and proof requests are NOT stored on the ledger -- they
are just messages between two parties. Schemas (a description of the fields
that belong in a particular type of credential) and Credential Definitions
(an announcement of intent by a particular org to publish credentials with
a given schema and revocation strategy) ARE on the ledger.

2. Other than a trust anchor, what could be the reason (i.e., incentives)
> for one to run a validator node? In short, why should anyone run a indy
> validator node?
>

Most people and orgs shouldn't. It's like asking the question, "Why should
someone run an ATM?" Answer: most of us never even consider doing that,
because we can use an ATM to interact with our bank without ever running
one ourselves.

The network doesn't *want* lots of orgs to run nodes right now. 50 or 100,
maybe. 1000? Probably not. It would bog down consensus.

Organizations that want to do go for the world, want the reputation
benefit, or want faster-than-average access to the ledger could consider
running a node. If you are interested in running a node in an indy network
of your own making, you can do it without any help. If you are interested
in running a node on Sovrin (a governed instance of Indy), contact the
Sovrin Qualification Committee or support@sovrin.org.

3. Since RBFT is the chosen consensus mechanism, what happens when more
> than 1/3 of the nodes turn malicious? Highly unlikely of course but
> assuming these nodes start to collude, etc, will the network come to a
> screeching halt? i.e., one is unable to issue claims, verify claims, etc
>

The number of nodes on the network = 3F+1.

When F+1 nodes are malicious, then consensus can be blocked. This could
prevent new transactions from being written. Meanwhile, the other 2/3 of
the network would be screaming about the blockage in their logs, and the
whole world would know about the attack. The remediation would be to
disable the offending nodes.

When 2F+1 nodes are malicious, then the malicious nodes can force consensus
according to rules other than the ones the network chose. Meanwhile, the
other 1/3 of the network would be screaming about the misbehavior in their
logs, and the whole world would know about the attack. The remediation
would be to disable the offending nodes.

When 3F+1 nodes (100% of nodes) are malicious, then it becomes possible to
silently subvert the network, and to rewrite history, without anybody
noticing.

4. I like to explore a pan ASEAN decentralized identity solution where
> one's identity could be portable across the different ASEAN countries -- my
> driver license registered in Singapore can be used in Indonesia, for
> example. Can I assume that I need a Indy validator node in Indonesia as
> well? What are the technical setup required for a pan ASEAN/supra nation
> setup?
>

The short answer is: you don't need a node in a given country to be able to
create identities there. You just need to be able to reliably reach nodes
from that country using TCP connections.

The slightly longer answer is that it would be desirable to have a node
nearby any significant sources of network usage, for performance reasons.
However, even with a "local" node, the advantage is only mild. This is
because clients of the network always have to talk to multiple nodes, not
just the nearest one. This is required because if the local node is
malicious, clients need to not be subverted by it. They do this by talking
to multiple nodes at the same time.

If you are interested in running a node, I strongly recommend that you
contact Sovrin. It is the only production instance of Indy in the world,
and joining is free. They have a procedure, onboarding instructions,
support people, and so forth. Setting up a new and independent network of
your own, in production, is a substantial undertaking that may need legal
consultation and many other types of expertise besides just what you can
get from a short Q&A on a chat channel.


> 5. Understand that privacy risk is mitigated through the use of unique
> pairwise DIDs with different trust anchors. pseudonym, that is. This is
> achieved through ed25519 cryptographic primitive. Is this idea/concept
> similar to public key private key relationship? Sort of mathematical
> relationship? Lastly, Is ed25519 quantum resistance?
>

Ed25519 keypairs are technically called signing keys and verfiication keys.
Signing keys are private keys; verification keys are public keys. There is
a transformation of Ed25519 keys that we do seamlessly for certain
operations that makes them more similar to classic public/private key
pairs; this is a subtlety that crypto experts can comment on.

To my knowledge, no elliptic curves are inherently quantum resistant.
However, certain operations that involve elliptic curves might be. Indy
will have to be upgraded when QR becomes a requirement. The good news is
that Indy has been thinking about this for a while, There is some
experimentation happening on plugging in different crypto algorithms. The
algorithms being plugged in in these experiments are not quantum
resistant--but the abstractions that are being developed will allow a QR
algorithm to be plugged into the same fixtures.