In almost every facet of life we prefer the presence of privacy to the absence of it, or at least the choice of being private. In many cases privacy appears to be a given but we’re increasingly confronted with technological and practical tradeoffs.

Everything is a tradeoff

Privacy is impossible without tradeoffs. For example in the public blockchain space where every participant needs to know all states of the network, privacy is not a given. In fact the presence of strong privacy may negatively impact other properties of the network such as the supply of tokens or any other fact about the state of the network. In these cases privacy is often foregone and replaced by weak assurances of pseudo-anonymity.

However if you’re not worried about making transactions in public (and receiving the benefits that come with them) you can do them in private among the small group of entities you choose. This is why when it comes to private ledgers, much like private SQL databases, or private agreements, we don’t broadcast them to the entire world.

Practically achieving privacy is hard. In the case of public blockchains we find more and more sacrifices of privacy for the sake of coordination. This has led to a significant number of people having substantial amounts of their wealth and whereabouts revealed to the world, permanently, forever. While this behavior is a particularly egregious outlier it shows the extent to which privacy can be unnecessarily forfeit.

Image courtesy of Richard Patterson. CC-BY-2.0 licensed

Ethereum Name Service

The Ethereum Name Service is a particularly large mechanism by which countless people have voluntarily sacrificed their privacy for the sake of convenience. In this case they’ve permanently attached their pseudonymous addresses (ex 0x0ab238…) to their real names and identities. By doing this they’ve made it easier to send transactions between each other as they can now use an address that looks like “anthony.eth”.

But such designs generally don’t need to exist, and in fact there are much more private ways to achieve the same things. One solution to this is privately (rather than publicly) storing public keys. Another, whenever you’re not doing payments on a public network, is to avoid public coordination entirely.

Private coordination is better

When you’re not communicating over a public network Daml makes the functionality of many private distributed ledgers easily accessible. Every ledger Daml runs on has a different approach to privacy, but they generally share the common thread of being permissioned networks, meaning that in the worst case scenario data stays within the network of operators granted permission to access it. In practice, however, there are different approaches.

Private networks use a variety of permissioned approaches including channels, transaction encryption (ex. zk-SNARKS), and hash commitments. Ultimately you need to decide what type of permission architecture works best for your application. If that need changes then you can migrate without changing your business logic.

Channels are perhaps the most common method of privacy on a distributed ledger and represent a form of communication that is out of band from the base ledger. In a channel participants choose to send their transactions between peers they’ve collectively agreed are part of their channel. Communication between participants is typically encrypted and some form of authentication is required in order to join a channel.

Transaction encryption is another way of allowing for communication between participants while protecting the data they’re sharing. In this case they look much like most channels except the data they are sharing is committed directly to the base ledger instead of between peers. Those with the correct key can read the encrypted messages, while those who do not have it cannot. While in practice this type of communication is relatively safe it is worth considering the value and nature of that data and what issues may arise based on transaction metadata, loss or theft of keys, and future breakage of the encryption algorithm used.

Hash commitments also look largely like channels with the one difference being that a hash of recent communications is submitted to the base ledger. This is largely a method to ensure synchronization between participants without revealing the data they are sharing.

In some of these constructs metadata may leak information on which parties are talking to each other, and as such may reveal too much information about the nature and extent of relationships between parties. Lost keys may make it impossible to retrieve information, while stolen ones may allow an attacker to gain access to a long history of information. Broken encryption algorithms may do the same but allow for a much wider pool of potential attackers to decrypt your private data with less risk of them being discovered (since they don’t need to steal keys from you).

Conclusion

These are some of the common approaches that the various ledgers Daml runs on top of take, and a full discussion and explanation of each is beyond the scope of this article. However these designs, ultimately, should be part of the architecture of your program rather than its business logic. Using Daml helps to abstract the business logic of your application away from the coordination of transactions by handling the backend ledger access and api layers for you. In doing so it makes it much easier to test and evaluate various platforms to see which meet the security needs of your particular use case.

Daml has also a new learn section where you can begin to code online:

Learn Daml online