Corda is a permissioned distributed ledger system; thus, Corda identities have well-known legal identities as opposed to public blockchains where identities are anonymous. It means parties involving in a Corda transaction would be known to each other.

New to Corda? A great way to start with Corda is to take a look at one of our online bootcamp webinars. The recording for one of them is available here: https://www.youtube.com/watch?v=tVE1rKbFA3g

You may also consider joining us for one of our in-person or live virtual bootcamps. Keep an eye on the link below to know what events are coming up: https://corda.net/blockchain-bootcamp/

It is great when you compare that to the traditional blockchain where all you know about your counterparty is just a pseudo-anonymous public key. However, we will come across situations when businesses might want to perform a transaction anonymously. There could be multiple reasons behind it, like say a party does not want to reveal its identity when an asset held by them is transacted between random parties in the future.

Take the example of Cash, while it’s essential to know the issuer of the Cash, a party may not want to reveal its identity about the ownership of the Cash in a future transaction where he is not involved anymore.

How do we handle those cases in Corda? To understand this further, we need to have a look at Corda Identities first.

Corda Identity

Identities in Corda are represented by the AbstractParty class. It is the base class to represent any identity in Corda. It has two concrete implementations: Party and AnomymousParty.

Party is used to represent a normal Corda identity which is identified by thePublicKey and the CordaX500Name. The CordaX500Name represents the well-known name of the identity

AnonymousParty is identified by a PublicKey It is used in cases when the well-known identity of a party is not supposed to be revealed while traversing through the transaction chain.

Implementing Anonymity in CorDapp

It’s pretty obvious that anonymity won’t be achieved without some changes to a CorDapp. Let’s take an example of the token CorDappand implemented here, and try to update it to allow anonymous parties. It’s a very simple CorDapp that implements Token Issuance and Token Transfer functionality.

Let’s try to update the CorDapp so that the owner (holder) of the token remains anonymous. We will just concentrate on the Issuance-part in this article.

TokenState

We need to update the TokenState to make sure we are not storing the well-known identity of the owner (holder of the token). So we need to update the datatype of the owner from Party to AnonymousParty as shown below:

Is that enough? Do we need to change anything in the flows? One might think changing the Party to AnonymousParty should be enough, as we are not anymore sharing the well-known name, but no, it won’t work. The public key of a party is also known to other participants in the network. Hence they can easily map the public key to the legal name. So we need to create a new key-pair to sign the transaction.

Let’s take a look at the flow to understand how it’s done.

TokenIssue Flow

We will use a Corda library called confidential-identities, which does much of the heavy lifting for us. We don’t have to deal with the details of generating the public and sharing it with counterparties etc. Confidential Identities (CI) library will provide easy abstraction by means of certain sub-flows which we can use in our flows.

We would use the RequestKeyFlow of the CI library to request a new public key from the counterparty. The flow will take care of storing the new public key returned from the counterparty as well as storing a mapping of the public key with the counterparty’s well-known identity.

Note that the counterparties needs to know the new public-key mapping with its well-known identity because it needs to validate who the public key belongs to in order to transact.

The changes needed are to call the RequestKeyFlow and use the newly generated public-key for signing the transaction.

One last thing is needed to be taken care of on the responder side. The responder flow needs to generate a new key-pair and return the public-key to the initiator wrapped in an object of AnonymousParty. All this can be done using the ProvideKeyFlow as shown below:

Now if we try to peek into the vault to see what we have stored in the owner field, below is what we see:

We see that the owner is anonymous, any party not having a mapping of the public key to the well-known party would not be able to infer the owner party.

So that’s how we achieve anonymity in Corda.

Thank you so much for reading.

Want to learn more about building awesome blockchain applications on Corda? Be sure to visit https://corda.net, check out our community page to learn how to connect with other Corda developers, and sign up for one of our newsletters for the latest updates.

— Ashutosh Meher is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.

Follow Ashutosh on Twitter here.