Anatomy of on-chain privacy

Hello. Where can I see the time? It will be here. Okay. Thank you.

Hello, everyone. It's a pleasure to be here. I'm a member of a team in Aztec. And if I were a good employee, I would probably give you a talk around that if you build something with privacy, you should build on Aztec because this is the best solution ever. But I'm not a good employee.

So I will tell you that if you build something with privacy or dream of doing something with privacy, I do not know which tech you should use. But I will give you some mental model that will help you to understand what tech will fit you. I believe that the ultimate goal of people at this conference and in general in our space and maybe builders in the world, worldwide, is building products that work. Not just things that look great in PowerPoint presentations or that look good at the or on Twitter, but things that really work. So when it comes to privacy, it's also a good question, like, what is privacy?

Because very often we hear like, oh, like this messenger, like our favorite messenger, where we talk all the time. And it is private, completely private. What it means? No one cares. It's private.

Definitions are annoying. But sometimes we need definitions. And when it comes to privacy and when it comes to building products with privacy, the first question is, what is privacy? Compare privacy to Caesar salad, chicken Caesar salad. If I tell you chicken salad, chicken Caesar salad, this is it.

Everyone in this room, maybe except for some outliers, will imagine that. If I tell you on-chain privacy, no unique definition. Or even general privacy in Web 2.0, no unique definition. And important point to highlight, that most companies, both in Web 2.

0 and Web 3.0, they benefit from you not thinking about what is privacy. What they want, they want you to feel that you have privacy, and to feel like secure and comfortable about that. Because if you feel that you have privacy, if we feel that we have privacy, then we use the product, and we are like a returning user, and they can put ours into a quota report that they show investors. And this is the ultimate goal.

So important thing to outline, what is privacy? That happens. But what should we do with that? Should we become like privacy maxi? Okay, just doing everything private.

Doesn't make sense to make everything private. What will we get? Costs, benefits. We will be maybe less surveilled. Not sure.

We will get some ego satisfaction because we are now superior over people who have some social approval because we can boast to people and give talks about that. What will we give? What are our costs? We will spend a lot of time, and probably money, and UX suffering, and some paranoia. What is the problem with fighting capital and surveillance?

It's very good for presentation. It's very painful in practice. Because what it credit cards. In case of blockchain, not using wallets. I don't think that many people in this room and in our industry will give up on it just to fight capital and surveillance, whatever it is.

So should we be privacy maxi? I don't know. It's everyone's personal choice. But should we be privacy aware? I would say probably yes.

Especially when we build products engaging privacy. And what I mean by privacy aware, we need to explicitly define what is privacy. Think of it this way. I tell you what is privacy. You tell me privacy is three.

And like three of what? Kilos? Meters? Kitchens? This is approximately the level of how privacy is defined in blockchain.

Like giving some more concrete example, like think of client-side proving. I can claim that client-side proving provides privacy if it is only my device that generates the proof, like smartphone or laptop browser. I would say this is the strict definition of privacy. But someone can argue with me that if this is the cluster of GPUs that I rented, this is also client-side because I rented them. And it doesn't matter that all I know is infrastructure that is maintained by third party.

And it's not about like, this is right, this is wrong, even though sometimes we argue on Twitter and say, oh, you are wrong, I'm right. It's just about explicitly defined privacy in terms of concrete products. So we say something is private. Private to what extent? Like is private Validium or private blockchain?

Yes. Is Hyperledger a private blockchain? Yes. Is T-based blockchain a private blockchain? Yes.

Is client-side proving blockchain a private blockchain? Yes. And whatever is blockchain and has some private component to any extent can be called private blockchain because there is no legal rule of how to call products. I don't know. Who is from this application?

Quote reports of the companies. Because the developer pops up and says, oh, I want to build something with privacy. The protocol says, cool, you can have privacy. Then they can put this developer as an ecosystem developer into the quota report this quarter. It doesn't matter for them that in half of the year nothing works.

He's building, he's building, he's our developer. If he will never build it, it's his problem. So who loses from this application builders? Because if the builder has his own understanding of her own understanding of privacy for his product or her product, and the protocol can provide another type of privacy, it just doesn't work. So how we think about like blockchain privacy?

In general, when someone develops an application, what happens? Write a contract, deploy a contract, execute a contract on some inputs, get some outputs, update the state, some other maybe steps, but like those are the main. And then in each of these steps, there are many components that potentially can be private. Should they be private? This is not the case, but let's say this is liquid definition.

So let's think about how to think about it. It's hard, because in blockchain very often, the ecosystem wants the developer to come and to build something that will be feasible for this ecosystem. The ecosystem doesn't want the developer to come to build something that can't be built in this ecosystem. But I think we should go another way around. First, we think about what do we want to build?

And then we think about on which chain it should be built. Because even if the chain has an angry devil, and no memes on Twitter, and non-charismatic SEO, but its stack can meet the requirements, maybe this is the way to go. And vice versa, if the chain has an amazing Twitter, and very friendly devil, and very charismatic SEO, but its technical capabilities doesn't meet the requirements, maybe it's not worth it. So when we think about what to build, the next question is like, what do we want to make private? And thinking about what can be made private in the application, it can be private identities, it can be in the smart contract, private variables and private functions.

The smart contract can have private execution, the bytecode can have private deployment, and there also can be private state. And the question is like, what of that is really required? And very often we will want to have some blend, meaning not making everything monolithically private. Because if everything is monolithically private, it kind of loses composability. And in blockchain, the whole idea of blockchain to a large extent relies on composability.

So we will often want some identities to be private, some public, some functions private, some public, different states, different smart contract execution environments, and so on and so forth. For example, think of building a blockchain so everyone can verify it. So you need a blended private and public components. But what else? If, for example, assume we know what we want to build, we understand what privacy do we need just for like product features.

The next step is a compliance requirements. If you're not talking about like some total anarchy in the development, and very often like the jurisdiction we plan to operate in has its own like requirements of what can be done, what can be public, what can't be public. Maybe by design, we would love to have application that publishes all password data on chain. But by legal requirements, we are not allowed to do it. And then another question is, what privacy guarantees do we want to promise the user?

And this overlaps with the next point of very unpopular thing called morality. Is it important to do right things, or is it enough to market right things? Think about like swap. We talk about like mass market very often. Think about that someone has built something called private swap.

And this is for like user who doesn't really know too much about how blockchain works. And they treat it as like privacy currency exchange. When you're at the airport, you come to the some human in the window and say, okay, this is dollar, give me euros. They say swap, they see that the only component that is private is identity. It means that all swap activity is public, but the identities are private.

So is it fair to say the user who won't check that this is private swap? It depends on the moral boundaries of individuals. I don't know. But it's just something to think about. There is no right answer here.

Another question to consider is, do we really need all this fancy tech? I mean, fancy tech is cool. It's just, it feels great to work with your knowledge first. Like you feel like you are on the forefront of the humanity evolution. But it comes with like a lot of costs.

If you compare like TEE and your knowledge first, trusted education environment and your knowledge first, even though we publicly say that they do not compete, they complement each other. The truth is, according to my opinion, they do compete. Because both of them gives you probability. The difference is that TEE gives you trusted probability. And your knowledge first gives you trustless probability, but at the cost of a lot of overhead.

And maybe for the product that someone is building, they do not need trustlessness. They will be happy enough with TEE. That is almost free and almost with no overhead compared to your knowledge first. So this is just another point to think about. But all in all, when it comes to building privacy products, abstraction is not our friend.

Even though like products like to tell you, oh, it's so easy. It's so easy to use. It's so like smooth experience. Very bad advice. Do not trust people.

Check on your own, even if people are very nice. Even if you want to build something in a particular stack and you seriously consider investing part of your life into this, check the code, how it really works compared to what is promised on the website and what privacy guarantees it will give you. Because what we want, we want to build products that work. We do not want to build products that do not work. Because imagine like you want to build company, you quit your job, you spend your savings on building this company, and then you realize that it doesn't work because it doesn't work.

And another point of work, it can be the case that something works by like definition, for example, for one bit. But it's not feasible at like scale that you want to do. So if you want, if you know what you want to build, and if you have a hypothesis, what stack to use, think about how feasible it will be. How much resources will the user flow require, and if the user will be fine with this react. So the conclusions of this talk.

First, think of what to build, not on which chain or which stack. Then define the required type of privacy for this particular product in this particular jurisdiction for the privacy guarantees that you want to give the user. Then check the accessibility. And then do not trust people, especially dev rels. I don't think that many people misinform builders on purpose.

Very often it's just very nuanced. It might be by accident, it might be that something has changed and someone didn't notice, and so on and so forth. And this is it. If you have any questions, you're welcome. Thank you very much, Lisa.

We do have a couple of questions, I can see. Let me just sort it here. All right. So privacy is available to some extent already now, like think Tenedo Cache or privacy pools, but they require users to be quite knowledgeable to actually use them correctly. So is it fair to say privacy UX is lacking or is pretty bad, and how do we potentially fix that?

Wow, this is a great question. I think it circles back a bit to a moral aspect, if we can call it this way, because one can build an application and say, okay, all responsibility is on the user. The user should be knowledgeable. If he fucks up, it's his problem. There can be another approach when an application wants to ensure that the users act as correctly as possible.

Another thing, but looking from the experience of Web2, when it comes to, let's call it real privacy with stronger privacy guarantees, UX usually goes down. Because you can't do like one-click, one-button, smooth, one-second experience. It is some trade-offs. The question is, should it be fixed or not? It depends on what people want to build and what people think is the right to build and with what approach.

All right. Next one is a little bit in the same direction. DevX of privacy is pretty bad. Do you think it's realistic to improve this drastically, like assume to reach the same level, I guess, as like regular solidity development or something like that? Good question.

I think it is possible, but it won't be. Let's think, for example, about roll-up. Let's think about centralized-decentralized sequencer. The cost of decentralized sequencer is that you have many nodes that need to propagate transactions in a P2P manner. Will it ever work as fast as centralized sequencer?

Of course not, by like common sense. Can it work in a way that user making a transaction feels fine with UX they get? Yes, it can. I think so. All right.

Next one, great talk regarding abstraction is not our friend. Is it the case that we need more time to discover and mass market the right abstraction? I don't think there is right abstraction. It's like every company that abstracts something acts probably in like in a good space. They assume that this is the best way to abstract something.

Then you have companies doing it in different ways because they have different views. I think there are some ways when abstraction starts working, like when you have the technology, maybe like solidity today, that is more obfuscated and you know that what you have done, many people have already done it. For many people, it has worked out. So you do not really have strong reasons to recheck it on your own, but if you work with some like cutting edge tech that you are almost among the first who touches it, my own view is that abstraction doesn't help here, but other people can have other views on that. All right.

Are there any examples of applications do you think approach incorporating privacy well or in a good way? Like if you have some concrete examples, I think of applications that are approaching or doing very well in using privacy, I think. Good question. I think it's not about like, so like approaching privacy, it's about like being transparent about it. I think privacy pools is quite good in terms of how they explain users what are the privacy guarantees that they get there and what they do not get there.

But yeah, I don't have any like particular example. All right. What are some examples of how privacy tech can be leveraged to unlock new features or like new ways of use? Yeah, I guess that's, yeah, new features. Yeah, that's also a great question.

I think there are several approaches here. First, we can think in like pure blockchain paradigm and think, OK, we have built a lot of applications on transparent blockchain. In what points the applications can drastically win or benefit from introducing privacy. Then there can be another approach where we can look into Web2 world and think what of existing applications there can drastically win or benefit from having on-chain privacy incorporated into their products. And then the third approach, maybe the most complicated, when one thinks from scratch, thinking that I have blockchain privacy, meaning that I have both blockchain property and privacy property, what existing world's problems can be resolved with this.

I think this is the most complicated. The third one is the most complicated approach and the most interesting approach, because what blockchain is good in, in my opinion, is the coordination layer, especially when you have privacy. Without privacy, it's quite tricky. So you want to, like just thinking outside, you want someone, probably computers, to coordinate on something in a private and provable manner. The first thing that comes to my mind, assume you have a crowd of surgery robots performing different operations and talking to each other.

Do you want their communication to be verifiable? Probably you won't. Can blockchain be a good environment for that? In my opinion, yes. A lot of space for discovery in the real world problems.

That works only when you have privacy. If you have just blockchain, the space of discovery, in my opinion, is very small. Thank you. I think that's the last question we have time for. Thank you so much.

Lisa, thank you very much.