ZK13: The Onchain Privacy Trilemma - Wei Dai

Transcript

[Music] So privacy let me first make a disclaimer. I think whenever we talk about privacy we need to uh mention what type of privacy we're talking about. So in this talk I'm not going to be talking about privacy of information of communication. I'm going to be talking about privacy of assets of financial privacy and in particular onchain privacy. So we're at a zero knowledge cryptography conference. So let me open up with a quote on cryptography by Phil Rogawway.

Cryptography rearranges power. It configures who can do what from what. Although cryptography is a technical field, it has deep and farreaching consequences in society. And in recent years, there is a growing tension at the intersection of privacy and blockchains. And I think there's a true ethical dilemma at the core. And the best way I found to distill this conflict is in the following technical trma between the following three properties. Maximum usefulness self sovereign privacy and assets and threat resistance. Any

onchain privacy system can only have two properties but never three. And for those of you familiar with some of the privacy protocols, this is roughly how the landscape look uh from a selection of them. There's many many more protocols out there. Roughly speaking, we'll have on the top left the idealized protocols which leverages ZK to build shielded pools for maximum amount of privacy possible. And on the bottom we'll have things that are similar to for example Zcash Monero but adds certain um velocity restrictions on asset movement therefore making it more threat resistant and I'll define what that mean in detail later

on. And then we have the top right category which sometimes you might not even associate them with onchain privacy solutions. In fact, a centralized exchange can be leveraged to get onchain privacy and there are also solutions leveraging for example multi-party computation FG and uh which is fully home encryption as well as trusted execution environments and I will expand on this dark one in more detail this talk and and here's the rough outline that um that we'll go through for the next 25 minutes. First, we'll go into detailed definitions of these these three properties and why we need them.

Then we'll look at a more technical treatment of the trlemma and get to the core of where this conflict is and I'll talk about the lens of solutions and how to expand the trade-off space and finally takeaways and uh call to action. So let's let us get started. First of all, why do we need self-s sovereign assets and privacy? Here's two articles from the Universal Declaration of Human Rights published by the United Nations 1948. There's article 12, which is often referred to as the right to privacy, and article 17, which is often referred to as the right to own property. In some

sense, privacy and asset ownership are fundamental human rights as defined by United Nations. So therefore, why shouldn't we have them in our onchain privacy protocol? And what do we mean exactly by self sovereign privacy? So in order to get a sense of this, let me uh read the following excerpt from the cypher punk manifesto by Eric Hughes which was published back in 1993. He says that we must ensure that each party to a transaction have knowledge only of that which is directly necessary for that transaction. An anonymous transaction system is not a secret transaction system. An anonymous transaction

system empowers individuals to reveal their identity when desired and only when desired. So by self-s sovereign privacy we mean that exact property which is your transactions should stay private on chain unless you or any other party involved in that transaction explicitly decide to reveal them. So let's go into a little bit more detail of how these onchain transactions uh what they actually encode. For a typical transaction on chain with a sender and receiver, we have the notion of anonymity which hides the identity of the sender and or the receiver as well as confidentiality which asks for the

privacy of the content of the transaction. And there's are transactions that interact with DeFi protocols which we also have the notion of anonymity which hides anity of the sender confidentiality which hides the content of the transaction and also function privacy which hides which application you might be interacting with. And by self- sovereign privacy we mean that the system should have the following property. When private transactions are posted on chain, the only way to reveal their content is if an involved party explicitly decides to reveal that transaction. And to wrap

up, soft sovereign assets and privacy means that empowered individual to own and to own their assets information and there should be no one else that can take that away from them. And um by show of hands, how many people think that we should have soft sovereign assets and privacy for alter protocols? Great. So this is not that u cypher punk off a notion, right? It's part of the declaration of human rights. I would say let's move on to the next property. This one is a lot easier and it's a notion of maximal usefulness. Onchain protocols today move an immense amount of value. So, here's a chart of the weekly stable coin um

payment amounts relative to Visa and AC. We're currently we currently have exceeded the amount of money movements that Visa facilitates and more than half of that of AC payments or as a AC transfers and onchain protocols today are very easy to use and they uh and we want to preserve that property. So what do we mean? A maximal use useful protocol on chain should have at least the following properties. Anyone should be able to transact freely making arbitrary transfers making arbitrary DeFi uh transactions. They should be able to generate new addresses to to to get better anonymity and there

should be no limits on how fast transaction can happen or how fast money can move around. Okay, so that's roughly what we mean by maximum usefulness. By show of hands, how many of you think that we should build protocols that is maximally useful on chain? Okay, less hands. Interesting. Um, my argument is we we don't want to replicate and want to make onchain finan as accessible and useful as possible. So therefore, for this purpose of this talk, we're going to consider uh systems that wants to achieve maximum usefulness. Finally, let's move on to threat resistance. This is perhaps the one one property of the three that's more subjective or sometimes you could

maybe refer to this as interubjective, right? What is a hack? We have a common notion of what hack is today and here's a graph of all the onchain hacks that have happened over the past decade. um there's no signs of them slowing down and in fact there's simply more and more hacks that that are happening as more and more finance uh move move on chain and just recently about 3 months ago there was the largest hack ever um on a bad bit wallet totaling $1.4 4 billion and let's take a look at what happens during these hacks. So, so here's a stat statistic of

the buy bid hack after two months um of the hack. Roughly 69% of the assets are still traceable. Meaning we have a list of addresses across different chains that are possibly belonging to the original attacker. And roughly 28% of the funds have gone dark. Meaning we don't know where the address is holding these funds. It could be any address that have been that have received funds over the past right 3 months. And roughly 4% have been frozen.

Meaning they were probably retraceable and that counterparty that attacker used uh was actually collaborative in freezing the funds. And during this process, the attacker extensively leveraged for example crosschain swaps which are traceable exchanges which are also traceable but only if the exchanges cooperate and mixers on both Bitcoin and Ethereum. So this is what we mean by threat resistant where this is one example of how protocols can be threat resistant. We want these major hacks to be traceable. We want the number of uh the amount of traceable assets to be as

large as possible so that we we can have uh you know the third number there amount assets to be uh frozen to be also as large as possible. We don't want asset to go dark and and so that is what I mean by threat resistance. We want hacks to be traceable and note that this does not actually require us to build in protocol freezing uh methods. So the we simply need to reveal the content of transaction. We don't actually need to take the assets away from the attacker and this is actually how all the transparent onchain protocols work today, right? Um we simply need the ability to track and so it's not really asking for that much. It's really right reveing the

revealing the content but not uh explicitly taking away self sovereignty of assets. And best show of hands, how many of you think that we should build protocols that are threat resistant? Great. Okay, more hands than the usefulness one. Um, so great. So this means that we have a true uh problem here because I claim we cannot get all three at the same time. So the perfect onchain privacy protocol does not exist. And let us see why. The strategy will be as follows. We'll assume I promise this is the kind of the only technical part of the talk.

Uh we will assume that a system is both maximally useful and soft sovereign. And we're going to show that it will not be threat resistant. Meaning if there's a hack that happens, there will not be a way to trace the transaction graph. And we'll do so in three steps. First in order to set up the the proof uh we we'll first argue that we must have a system that deal through raw public keys and one one of the responses that uh you know to to this is what if we get an identity system. So the first step is to claim we cannot have a global identity system if we aim if we want maximum usefulness and the second step

we'll set up the uh we will model privacy preserving onchain transaction systems and the notion of threat resistance more formally then we'll do this um final implication which will be obvious once we set everything up. Okay. So the first first argument if you look at current blockchain protocols today there's only the notion of addresses which can be derived from public keys of signature schemes or code uh for example for smart contract wallets and addresses have no inherent notion of an owner and addresses can be created on any device on the fly anywhere in the world. On the other hand, an identity system, if we were to

actually enforce something like that, would need to effectively map every single possible address that's ever used or will be used to a real world identity. And that real identity could either be a human or could be a company or any entity. Um, and so you can see that it would be quite hard to achieve such identity system. And in fact, we simply do not have the identity system today. And so for the sake of maximal usefulness, I'm going to assume that systems will need to work with raw public keys or raw addresses. Okay, so that's step number one. Now let's actually set up the

uh more formal model of the system. And we'll have the notion of addresses. So these are arbitrary bit strings. And we have the notion of transactions which have sender, receiver, and an asset and amount. And with that in mind, it's really easy to define what a ledger is. A ledger is simply an ordered list of transactions. And here I'm going to block out the text to denote that that transaction is fully private.

And due to self-s sovereign privacy it means that if a party involved in the transaction want to reveal that transaction then they can decide to do so and we will denote on on on the diagram by unblocking the content and when transactions are added to the ledger we will assume that they're added onto ledger by default fully privately. Okay. And so these can be realized using um combination of geological cryptography and other tools. But this model is kind of the core of what's what's happening semantically on a private transaction system. So now let us move to setting up defining threat resistance more

formally. And formally we we're going to define a game between an adversary and an environment. And we're we're going to have the notion of a malicious set which initially will be empty. And this set will be keeping track of all the public accepted malicious addresses. The adversary um will can at some given time any chosen time tick an pick an address a to be malicious. So this uh if you connect to the previous example of onchain hacks.

So this effectively could be a is modeling like a real world hack where when a hack happens that fund is marked as malicious with the address mark as malicious. However there's a delay. In practice, when this happens, there's a social consensus that it should be reached on that that is an actual hack and and that often times could be hours, days. And so we're going to formally model that as the time delay D. So what happens is that at any at some point in this in this in this game, the adversary can pick an address, mark it as malicious, and after some time delay D, that address is is then added to the set. the public set M. Okay, so that's

uh point number one. And then any at any time the adversary can create new addresses and the adversary can submit arbitrary transactions to the ledger. And at the end we'll say that the adversary wins this game if a is not fully traceable. So the the address picked by the adversary it have spent um have done transfers that are not revealed on chain. Okay. So this is some something I guess more complicated to set something very simple. is simply saying um if the adversary picks an address and um that that models a hack can can the average get away with it and

we'll have this notion of a public set M that keeps track of all the accepted malicious addresses and so the first point um is if we want any form of traceability for the malicious address then the following must happen. We must modify our ledger protocol so that if a transaction is coming in that's fully private, we cannot fully we're not cannot commit a transaction unless the sender is not part of the malicious set. Right?

Because if we commit that transaction, what happens is that due to soft sovereign assets and privacy that can never be revealed. So we cannot let malicious addresses spend their funds or spend their funds fully privately. And so we must do the following at any given time. If um an if an address is in a malicious set then any transaction from that asset uh from that address must be done transparently. And so we can enforce this for example using $0 proofs. And we're going to to restrict ourselves to the set of protocols that do this. And now this kind of the final

step to to see the contradiction. Um recall the time delay d that we have. The claim is is the following. If the ledger commits any fully private transaction before the time delay then the system cannot be threat resistant and the and the reason is the following. Consider the following scenario. Suppose that the ledger have committed a transaction here is the the transaction A sends to A prime. If the transaction is committed in a fully private manner, what would happen is that the adversary can simply sample new new addresses, new public keys and send

from the original malicious address to the new addresses. And because of soft sovereign access and privacy property, any uh any transaction following um this transaction can be spent and the transaction a sends to a prime will safely private. And so that means that effectively the entire graph is not traceable. And this is if the system commits that transaction before the delay D. And on the other hand, if we actually wait for this delay D to commit transactions, then I claim that actually the entire thing can be fully traceable and threat resistant for this malicious

address. And it's easy to see that because if we wait for delay D then we we we we can simply keep track of of the original malicious address as well as all the all the transactions originating from it. Okay. So, so this concludes the proof of the contradiction, the proof of the trailemma. Um, because we have shown that if a system is maximally useful and self sovereign, then it cannot be threat resistant, meaning there's a hack that can go through the system without being uh traceable. Okay, so now let's actually explore this trade-off space a little bit.

Um the dilemma really signals that we cannot get all three properties perfectly and in the real world I think there's effectively three class of protocols that start with two properties and try to get the third property as much as possible even though we cannot really fully get there and on we have first idealized privacy protocols these protocols typically have the notion of full sovereign full self- sovereign privacy as well as maximal usefulness and however it's really hard to add threat resistance and the second category is what I call programmatic privacy

protocols so these are similar to category A but they add movement controls so sometimes uh for example by disabling payments from within a protocol and adding deposit delays we're going to effectively become threaded the distant and there's more recent works showing that if you can actually encode the transaction graph with every single transaction then we can potentially also uh we can actually allow payments and faster movements without sacrificing threat resistance meaning we can make the protocol as useful as possible while retaining self-s sovereign privacy and um threat resistance and finally there's this category which I

privacy with information custodian using a trusted custodian is um is somewhat of easy solution and there's ways to make this less trusted meaning we can use multi-party computation protocols we can use trusted execution environments to custody the information that then need to be decrypted so in that way we could actually offer better privacy for individuals even though it's it cannot be fully self-s sovereign And let me um end uh the talk with some more forward-looking points. And really the the landscape is is just a landscape of trade-offs. We

cannot get the best of of all three properties. And the field is still wide open in terms of pushing the trade-off space outwards. And it specifically in pragmatic privacy protocols, how do we get more usefulness out of these things? How do we lower the restrictions while still getting threat resistance? and in um privacy protocols with programmable disclosure. How do we leverage multi-party computation, trust execution environments to to be able to make protocols uh threat resistant but offer max amount of self-s sovereign privacy? And for those of you that

really think we need full self-sign privacy, here's another way to think about it. Um it turns out because onchain privacy protocols work with the notion of anonymity sets, the inability to disassociate oneself from an attacker is actually can be seen as a problem. And so so instead of thinking about self-s server privacy, we can also think of think think of offering freedom of dissociation to people right? And let me end the talk with the following quote um by by Helen Nissen. Privacy in a sense of contextual

integrity demands that information gathering and dissemination be appropriate to specific contexts. Privacy as a technical pursuit is something that we as cryptographers as uh protocol designers think about all the time. We should enlarge the space of trade-offs of privacy protocols. However, doing that is not enough. The larger challenge is to have social consensus on what type of privacy we actually need for onchain transactions. And that I think is the largest challenge that we have today.

Technically I think um we have very very good construction of privac privacy protocols but we have very little social consensus um relative to how much these onchain protocols are used and I truly believe we can build protocols that maximally achieve the three properties despite we cannot really reach it 100%. So that is the end of my talk. Thanks for your attention. [Applause] Thank you very much. Wade, do we have any questions?

I'll just give you the mic. For the first property, I forget what you call it. Uh the privacy one. Um why is it that you define it in such a way that either of the parties can reveal the entire transaction? Yeah. So that's a it is defined that way. It is defined that either the sender or receiver. Yes. But why? Yeah. So it's a simplification. So for sure. Yeah. There's going to be there could be two two notions, right? Maybe maybe this receiver cannot uh can only reveal itself but not the sender.

But really it's not um uh the same the same trouble will hold. So I I just you know use the the the simpler definition of that to um you know for the talk. But like it it doesn't really matter kind of like uh who could provide more privacy and and the the property will still hold. Do we have any other questions? So in the assessment of the threat uh resistance at one point there's going to be a a determination to make on whether

the threat is in the onchain or offchain and whether an actor is malicious deemed malicious onchain or offchain. So onchain I think that determination is a little bit more intuitive but in your vision how do you see uh dealing with a mixed reality where the threat can come from you know the real world and how do you uh bake that in? Yeah. So this um is kind of baked into how how the model is defined. So um sometimes these onchain can just looks like a normal transfer but still there's a social consensus that hey there's a key loss on a on an address right and this is in fact what happens with a bad day hack and um I think really there's actually not one

globally accepted list which is malicious right chain anal chain analysis maintains a list and you know there's a list if you were maybe to survey uh different crypto companies um and that can you know be larger or smaller. So some protocols do maintain se different lists right like you can have like this parallel list of different malicious addresses and in fact that's what privacy pools does right you have this notion of anonymity set um provider so I think fundamentally there is in some sense a minimal uh list that we can all agree on because there's certain things that we call hacks and certain things that we don't call hacks right and so um yeah it's definitely open question thank you very much we'll thank our

speaker once again. [Applause]