Corda's privacy guarantees


Immad Naseer
 

Hi,

 

I had a question around privacy guarantees provided by Corda. I'll pose the question through a contrived, but hopefully representative example in order to validate my understanding.

 

Corda's privacy model allows participants to share states with other participants, packaged into transactions, on a need-to-know basis. The other participant will however have to fetch all the preceding transactions so they can be convinced of the validity of the state(s) they are being given. While each state evolves in a chain, all the preceding transactions actually constitute a tree. If we have to validate the entire tree, this seems a little troubling from a privacy perspective.

 

Consider a CorDapp which models some sort of digital token, issued by a known issuer. Let’s say two nodes, A and B, decide to perform an atomic swap between a token which A owns and some stock which B owns. The situation is depicted in the diagram below. As part of validation, B will validate the transaction tree from which the token came from, and A will validate the transaction tree from which the stock came from. As part of that validation, A will learn about a cryptokitty which was exchanged for that stock by B, and will then end validating the history of that cryptokitty, which might lead it to inspect the history of yet another set of assets which were exchanged for that cryptokitty, and so on. Node A will end up learning about a lot more than just the history of the piece of stock which was handed to it.

 

Do I understand the transaction validation process accurately? If this is how it works, the system will end up leaking up more and more information as the assets exchange hands and are swapped for other assets. It is still better than everything being on a public chain but privacy aspects require careful design in such a situation.

 

Thanks,

Immad

 


vjuge@...
 

Interesting question
Maybe I’m wrong, but IMO, knowing that the state represents something that is shared only by the parties inside a « shared fact » subgroup, by definition parties would have access to all the ledger ?

The derivative question would be what is the impact and how to secure adding a new party to a state ...?


Ryan Gledhill
 

Great question Immad. Have a read through Transaction Tear Offs
Matt Bradbury's talk on CorDapp design and CDL might also be useful as there are ways to design against this architecturally.
Conclave (Intel SGX) should also allow the tree to be traversed and subsequent validation in complete privacy, once development work is complete.

Let me know if I can help further!


Mike Hearn
 

Yep, that's right Ryan, thanks for the answer.

The design challenge is combining integrity with privacy. The privacy problem you describe Immad can be trivially fixed by moving tokens and updating other state in two separate transactions. However, then you risk bringing back the "breaks" and reconciliation problems that people wanted blockchain to fix. So the standard approach is to combine all changes that must be atomic from a business perspective together and then either mitigate or accept the resulting privacy leaks.

Clearly this is unsatisfying, hence our research into (primarily) SGX but we've also done some research into what it'd take to provide ZKPs in Corda too. In fact I've written a paper on what's involved with ZKPs which I'll get around to publishing on the Corda blog+docsite at some point. But suffice it to say it's a lot, at least for the general case.

With SGX you can do arbitrary full speed computation on encrypted data, so then you can get both privacy and integrity. That's where we're heading.