Editor’s note: Bernhard Elsner is Digital Asset's Chief Product Officer.

Imagine proposing that a hedge fund expose all its trades and positions.

….or a central bank share all balances of all its citizens.

….or a patient permanently expose all her healthcare history.

That is the world of public blockchain as it exists today. Despite all the noise around public blockchain, a lack of privacy features is preventing adoption of the technology across traditional finance and other regulated industries.

This is not some secret. Vitalik Buterin knows it. Fred Wilson, a venture capitalist and co-founder of Union Square Ventures, and Katie Haun, of Haun Ventures and board member of Coinbase, co-wrote a blog acknowledging it.

In thinking about this problem and discussing with other industry experts, five key principles keep coming to the forefront. In a follow-on blog, we will look at some common misunderstandings that add to the confusion when customers choose blockchain solutions.

Why Privacy Matters

As Wilson and Haun wrote, “Blockchains as they were originally architected are public by default. This is not suitable for most applications. Imagine if your email, banking, and social data were public for everyone to see on a blockchain.” In fact, today’s public blockchains rely on seeing the full history of an asset for its integrity properties. That means any time you acquire an asset on those ledgers, you see the entire history of who owned it before you and often much more (in order to prove its validity).

Without privacy, use cases adopting blockchain are reduced to asset classes that are resilient to radical transparency (e.g., cryptocurrencies and NFTs) and on-chain exchanges for swapping cryptocurrency to stablecoins. The lack of privacy on blockchain makes it unsuitable for traditional assets.  

Privacy Principles

Let’s reduce requirements for blockchain privacy to a few core principles. Together, these principles allow you to support traditional asset classes on blockchain and to compose them to create innovative new products.

Principle #1: Only parties entitled to see a smart contract see its associated data

When data is written to most blockchains today, that data is available for all to see. Pseudonymity is not privacy. This is a feature, not a bug. Public blockchains that replicate data have high integrity protection, but no privacy. Segmented models, more common in enterprise blockchain, have more privacy features, but usually at the expense of a more difficult programming model and limited composability.

Business requires greater control over who can see what data. There must be a way to express permissions on a smart contract: To say who can view it and who can authorize changes. The underlying blockchain must assure access only to those authorized parties. 

Principle #2: Transferring an asset does not reveal its prior history

If you want to honor privacy privileges on a smart contract, transferring an asset cannot reveal data from that asset’s history.

That is exactly what happens when you transfer an asset on most blockchains: The asset’s entire history is revealed. That means that when you purchase an asset, you have access to the full transaction history of that asset, and anyone who receives the asset in the future sees the circumstances under which you acquired it. This privacy shortcoming is a necessary evil in all blockchain systems where an asset’s history is used to verify its authenticity. And that’s the case even for most of the permissioned enterprise blockchain systems that tout privacy. Tools provided to limit the damage in the form of re-issuance or pruning/snipping of the back-chain trade off security and integrity.

Compare this to cash: Cash transfers hands repeatedly without knowledge of previous owners or what it was used for. Are you ready to give up this privacy? Can you imagine a central bank digital currency (CDBC) saying that all your transactions are public?

Principle #3: Parties own their own data

At Digital Asset, we have a saying: Not your node, not your data.

Blockchains solve the reconciliation problem. That is, how we can be assured we have all recorded the same set of events (smart contracts) on our ledger, that we know exactly who owns any asset at any one time, and that that asset is not transferred to more than one party (the double-spend problem).

If you have to ask somebody else for your data, you can only trust the data to the extent you trust that counterparty. Let’s look at a simple example: Your checkbook. The reason we balance a checkbook is that we don’t completely trust a bank to track our balance and guard against fraud. When we find that our bank is reporting an amount we don’t expect, we call the bank to reconcile the two amounts. Maybe an unexpected payment was made. Maybe someone hacked your account. In any case, manual reconciliation is required.

Blockchain avoids reconciliation by having a shared ledger with signed smart contracts. All parties to a smart contract see the same smart contract, avoiding reconciliation. But unless you own your own data (in our parlance, unless your party’s data is on a node you operate), you have not solved the reconciliation problem. Why? Because you still must ask a third party via an API for your data, and you have no idea in what way that data has been tampered with. Another simple example: I loan you $100 via a smart contract. Five minutes later I ask you for my balance, and you say it's $200. What happened? Who knows.

On the other hand, if you own your data, you have the signed smart contracts of the loan and all subsequent actions. It's indisputable, on both sides, what the current balance is.

Principle #4: Composed smart contracts respect underlying smart contract privacy

In the real world, it is useful to build complex smart contract use cases from small building blocks of underlying smart contracts. Composability is the basis for innovation that connects previously siloed markets. For example, consider the killer app of blockchain, delivery vs. payment (DvP). In this case, we’ve started with two applications: A payment app (i.e., some kind of stable coin) and an asset issuance. On top of that, we would like to compose a DvP that swapped the stable coin for the asset. We have two main properties we want to maintain:

• The DvP must be atomic: We want to transfer the asset if and only if the stable coin was transferred.

• The details of the two sides of the transaction must remain private. The settlement system or repository is not entitled to know the cash balances of the buyer and seller, and the payment provider is not entitled to see the securities positions of the respective parties.

A DvP (delivery vs. payment) composed between two systems must be atomic and respect underlying privacy

The only way to compose such a system in a way that provides both atomic transactions and respects privacy constraints of underlying smart contracts is to offer sub-transction privacy, meaning privacy at a granularity finer than that of the entire DvP transaction. In this case, multiple smart contracts are being changed at once, without data being leaked between the payment and delivery smart contracts. This contrasts with systems that protect privacy only at the transaction level (i.e., all parties in the transaction see all data).

Systems that don’t offer sub-transaction privacy force you to make a consistency vs. privacy tradeoff. If the system cannot guarantee subtransaction privacy, the developer faces a choice:

• Perform one large transaction, leaking privacy to all parties of the larger transaction.

• Break the transaction into two parts, risking that one leg of the DvP happens, but not the other—resulting in complex error handling and/or expensive reconciliation. 

Principle #5: Privacy must be managed on a per use case consideration, not per chain

Many blockchains claim privacy via some form of in-built, chain-level mechanism (e.g., ZCash using ZK-snarks to protect data). Blockchains that rely on some form of ZKP for privacy provide single-use case, blockchain-level privacy. While useful for some specific, single-use blockchains, these techniques are not useful for general-purpose, smart contract use cases. ZKP techniques consume extreme amounts of computing power, which grows exponentially with complexity. And using ZKP in a general use case remains very difficult.

General-purpose smart contract use cases need privacy control that go beyond single use cases like ERC tokens or cash, and ZKP-style techniques will not meet these needs.

Conclusion

Lack of privacy features prevents broader blockchain adoption across a range of industries like traditional finance and healthcare. This blog proposed five principles you should consider when choosing a blockchain. In the next part of this blog series, we will take a look at some hard truths about the state of blockchain privacy.

Digital Asset’s Daml smart contract language and Canton blockchain are designed with these five principles in mind, and they have enabled key capital markets infrastructure providers to build on our platform.