Privacy as Infrastructure: What Institutions Actually Need on Ethereum

Transcript

All right. Hi everyone. My name is Oscar and I'm going to talk to you about privacy for institutions and privacy from institutions. So I'm from IPDF at the Ethereum Foundation, the Institutional Privacy Task Force. And basically what we try to do is we try to help institutions access Ethereum and make it sure that their privacy guarantees are met in a secure and usable way. All right. So just some questions to sort of set the scene a little bit, tickle your brains. So this is a Cypherpunk track and one question you might ask is do Cypherpunks and institutions want the same thing when we talk about privacy?

And what sort of the overlap and opposition in terms of what they care about when it comes to privacy guarantees? Can both these exist coexist on neutral rails like for example Ethereum? And what kind of privacy are we actually talking about here and under whose control? And when I talk about institutions I mean many things. I mean everything from like financial institutions to governments to NGOs as well as their end users. And there are also use cases where maybe an institution doesn't exist but should exist. So it makes sense to think about it in in a kind of institutional framework. And also what I want to point out like what we want to do right is we want to solve for institutions while sort of not getting rid of these kind of guarantees that sort of crypto

and and Cypherpunk movement that sort of made it interesting in the first place, right? At a very very high level you can think of it as like two privacy models. So one is kind of trusting people, kind of privacy by policy and this is something that we're very familiar with if it's from the traditional world or maybe sort of more permissioned blockchains and so on. Where basically the operator is promising not to look. And you might have various types of tools here like access control or you sort of have kind of a policy or legal agreements and that's how you kind of get privacy. Another one, obviously our favorite, is is privacy by math where the operator structurally cannot look. Whether it's one operator or multiple operators like in a decentralized network. But in that case you use various types of tools like

commitments or nullifiers and secret proofs and so on to get these type of guarantees. And it's kind of like a fundamental dichotomy if you will in terms of how you look at trust. And what we want to do is kind of continue in this great tradition of trust minimization and put more and more trust in math and moving away from trusting in people and policies. So basically I promise I deleted versus I never saw it. In this talk I'll talk about this and some other things. If you want to go deeper dive we have a write-up on ipdf.ethereum.org where we talk at public rails versus private ledgers. So why are we talking about this in this room, why now?

So when we look at public rails like Ethereum is aggregating a lot of things like users and tooling and liquidity. They're like massive network effects when it comes to developers or end users and just a whole developer ecosystem with tooling and so on. As well as in market dynamics the liquidity that exists with stablecoins and real world assets and so on. So it's acting kind of like as a selling point. And institutions right now are exploring privacy on public rails. This has been happening for the last year or so especially as regulation has sort of cleared up and there's more clarity. So this is like a massive thing that's happening whether we want it or not or whether we want to be part of be part of it or not.

And I would argue that if we don't shape this then what ends up happening is that you get worse defaults that harden elsewhere. And it's the kind of thing at least if you look for example at the financial infrastructure you will only like upgrade that like once in a generation or so. So we have a chance here to sort of like help push for better defaults and and move things in the direction we want to. So some things that we have built as part of IPDF the last few months but first a little bit of context. So when we talk about sort of privacy layers when it comes to accessing Ethereum Ethereum there's a few few ways you can look at it. One way is to split up in terms of privacy of reads, privacy of writes and then I guess the third one was like prove everywhere bucket.

Privacy of reads is basically like who can see what's on chain. So you need to read read the state of the chain in order to sort of do actions, right? And it can be anything from RPC privacy to how you kind of query in a private way with PR and so on. Metadata including network privacy. And basically how do you read the state privately without sort of other actors necessarily knowing. Now the big thing is privacy of rights. So who can see what you write if you do a transaction for example sending a some amount of money from A to B or or or doing some kind of smart contract interaction. And here you might want to hide if it's amounts or maybe you want to hide hide the counterparties or hide in the balance, right? And you hide it either from everyone or maybe from a

subset of people. And the third one is kind of like a overall bucket prove everywhere. And it's basically like taking things that are cryptographically distinct and using them on chain. Some examples here is for example CK for identity where you can have kind of selective disclosure and then using that as some kind of proof of humanity or civil resistance or whatnot on chain. It could also be things like compliance without revealing the underlying data or some kind of credentials. So basically anything where you do some kind of selective disclosure you create some cryptographic proof and then you put it on chain. The focus for IPDF the last few months has been on privacy of rights and there's a few reasons for that.

One is that you see that tokenization is rising with like bonds or stablecoins or real world assets or any type of funds. Another is that institutions are writing sensitive financial data to a public ledger. So this is like a massive problem for them. And that is from a like a first principles point of view like if you're tokenizing some kind of asset you need to seal these rights and for many reasons like some are like legal regulatory reasons and others in terms of like competitive secrets and so on. So it's kind of like the the most fundamental thing that you need to start by guarding.

So one thing we've been working on is this privacy map if you will. You can see a little bit of a graph representation there on the left. This is open source we have a GitHub repo. And basically what we're trying to do is create like a public knowledge base for institutional privacy on Ethereum. And starting off we have like various types of patterns. So these are kind of like specifications or small building blocks like primitives that exist in the space that can be used for different things. So it can be anything from how you do shielding to stealth addresses to the zero knowledge proofs or FHE or TE or private shared state. Like all of these are kind of fundamental building blocks that exist and kind of documenting that them as part of a solution.

And then on the other extreme we have use cases. So these are like actual real world validated use cases coming from us talking to like hundreds of institutions and understanding like what they want to achieve and documenting that along with their their specific requirements. And it can be things like bonds, some kind of payments, maybe derivatives, stablecoins, identity, voting. Basically anything you can imagine an institution want to do on chain and understanding like what they want to do and what the specific requirements are. And the requirements can also be they can be technical but they can also having something to do with how their existing works systems work. But it can also be regulatory. So we also document jurisdictions and how regulatory frameworks impact the design because

that's usually like a fundamental blocker for a lot of institutions in terms of making sure that there's like a compliant solution. And and and then we have various types of approaches. So approaches are basically like end-to-end architectures. So it's how you combine these various patterns together to solve for a specific use case. And we try to like make it clear what the various tradeoffs are in terms of choosing a specific solution. And we also talk a bunch about vendors. So vendors are maybe companies or foundations or protocols that combine multiple of these patterns and and maybe have some approaches that could solve one or more of these use cases.

And the overarching goal here is basically to create like these feedback loop between institutions and their specific sort of requirements and and and use cases on one hand and then on the other hand sort of what the ecosystem ecosystem is able to provide in terms of primitives. And hopefully they meet in the middle and there's like a lot of constraints or things that are like a work in progress and tradeoff and so on. But by making it more explicit what those are it's useful both for institutions because they get an overview of what's actually possible in the Ethereum ecosystem. It's not just sort of on chain but all the products that are here in this space overall. And on the other side you have various vendors and protocol engineers and so on that can sort of see how their work relates to institutional use cases and

sort of do things that are actually useful. So you can check it out. It's open open source and you can contribute to it and do what you want. Another thing we've been doing especially the last few months has been doing like a lot of POCs. So this is basically us exercising various types of patterns or or approaches and trying to target specific use cases. These are not meant to be sort of any kind of production used in any kind of production environment but it's us like understanding this this space like at a deeper level and then being able to go to institution and show them here are some examples of how you can do it.

And it's all available on ipdf.ethereum.org. We have protocol specifications for the guarantees. We have code and write-ups as well. So you can dive into them and see more. I'm not going to go into super detail of any of these but just like a high level. So one thing we have is kind of a do-it-yourself Validium. So kind of how you how do you get private logic on on public rails? So how you can make that on your own. So imagine something like CK sync, Providium but like at a much easier kind of just the fundamental parts that's the Validium and not all the L2 and everything around it.

We've done a lot of POCs when it comes to private transfers. So things like shielded pools using plasma. We've done work when it comes to private bonds and how you issue those and and do transfers. So also sealer pools doing it with FEC, privacy L2s like Aztec. And we also looked at things like cross-chain settlement. So, how do you actually do settlement between completely different networks and using that with TE and creating this kind of atomic swap, which is a very fundamental building block in financial systems. Um And one thing that keeps coming up, there's like obviously a lot of different ways of do solving this and various types of patterns and approaches and so on, but there's one thing I want to mention that's kind of common common theme is shielding and you might have

seen this before, especially if you're on the more technical side. But it's basically like these four components that compose of create one pattern. So, you have some kind of commitment scheme where you sort of hiding what you own and then you have a nullifier mechanism to sort of prevent double spend without revealing what was spent. And then some kind of Merkle membership proof where you can prove that your note exists without showing which one. And then finally you have some kind of dual key architecture where basically you're able to separate the transfer authority as a spending key from audit process in in terms of viewing key. And this is like not a new pattern, right?

Like if you're familiar with the space, it's been done in Zcash and like a lot of other products protocols, but what what the ends up happening is that this is a very useful building block, so you can generalize it and have it for specific use cases, right? And it's arguably one of the more practical building blocks for privacy on Ethereum today. Works for things like transfers and bonds, derivatives and any kind of asset type. And you can implement it in lots of different ways. So, if it's with CK, like something like Noir from Aztec. Uh it can be like if it's so something like Salama or TEs or natively on Aztec. Uh and here in this case shielding is actual abstraction the pattern and then the actual cryptographic backend is a deployment choice and this depends a lot a lot on your specific constraints. So,

there's usually always these various trade-offs in terms of privacy versus scalability and various type of trust assumptions and so on. Uh With all of these various types of patterns and and approaches and POCs we talked about, you might ask like how should you think about this how should you evaluate it? And one framework that you can use is this like crops framework uh where you have sensor resistance and here you want to think about like can anyone exclude valid users? Like who's controlling an exit? Like if you're in a L2, are people actually able to exit from it and get their funds if the operator stops cooperating?

Uh can a user always withdraw, right? Another kind of key component is openness. So, are the specifications are they public? Can anyone actually read it and understand what guarantees do you get? Uh is the code auditable? Has it been audited? Uh can these users take something, fork it and deploy it in a different environment? A big one is obviously privacy. Like what is what is hidden from who and at what cost, right? Is the privacy just from a single operator or is it only from the public, right? And how does that work? And finally also security. So, does it actually do what it what it claims to do? So, does it actually fulfill the threat model? Uh is the threat model explicit? What are the trust assumptions? Has it been audited and so on?

So, this is not necessarily like a pass or fail, it's more like a lens. It's one way of evaluating these these solutions in terms of it being more um kind of Ethereum aligned and more in the sort of Cypherpunk uh tradition. Um and and you can sort of go through various protocols that exist and solutions and see if they actually match this or not. I also want to talk about two classes of problems. So, this is like a distinction that we've started making more explicit uh lately. Um And it's alluded to in the beginning of my talk and it's kind of basically this distinction between institution to institution versus institution to end user.

And they're kind of different, right? Because as end users, you usually think of things maybe in in like a retail setting. Like if you hear about stable coins, you think oh well that means like I as an individual will go and buy a coffee with a stable coin. But in reality, like 80% of all institutional use cases are actually institution to institution. That's like where most things are, but they're kind of not necessarily visible unless you're actually working in that specific domain right? So, one example of institution to institution use case is two banks maybe trading bonds, right? And in this that case you have more of like a symmetric type of power, right? Like both have access to lawyers, they can negotiate and walk away and they are fairly sophisticated. And the privacy goal here is usually in terms of like hiding

strategies from competitors, right? Um for example, when we talk about institutions to end users, one example here is like banks offering some kind of payments to individuals. And this is more asymmetric because the user usually doesn't have a lot of leverage. Uh the institution the user doesn't have a lot of leverage because the institution is controlling like the keys and infra and exit paths and so on. So, it's a bit it's more of a fragile relationship, right? And the privacy goal here is to protect the user's private life. And this is kind of leads to these questions of of incentives because sometimes the institution is is aligned and they actually do want something that's good for the end users, but it's not always the case and and this is something you have to think a little bit more carefully about.

And we talk about privacy from institutions versus privacy from institutions, these are different design constraints and it's different for specific use cases and you should think about them separately. Uh what should end users get? Well, a few questions you can ask as a kind of a litmus test. Like can the user exit without the operator's permission? So, for example, if you have an L2 or whatnot and the operator goes rogue or maybe they just disappear, can the user withdraw their funds and and have access to them? Like not your not your keys, not your crypto, right? Is it privacy from operator or just from the general public? And like who do you actually get privacy from? And this there's like a lot of details here in terms of how viewing keys work, under what conditions various type of authorities gets access to them and so

on. Uh this also relates to like what can admin keys do and like what type of access do you have with that? What if the operator disappears, what happens then? Um and one example here is like Validium, right? Where normally you might cooperate with the operator and then everything is fine and you can move funds around. But sometimes maybe the operator doesn't want you to withdraw and then it's question of what do you do then? Can actually exit. Um and sometimes the operator just disappears for some reason. Do you actually have access to your funds? Is it your data?

Can you get it back? So, those are some questions to consider and you can look at it a little bit as like a spectrum, right? So, on the one end you have permission chains where the operator can see everything and they control the exit. And then you have things like Validiums where the operator can see everything, but the exits are guaranteed on chain. And then sort of more in this of crops side of spectrum, you have things like sealer pools where the operator can't see things, you can exit on chain. Your privacy L2s like Aztec have some kind of protocol level security privacy. And you have various types of trade-offs here, right? And what we want to do is we want to be explicit about users what they get at each level.

And there's no real answer here in terms of what actually ends up winning and gets adopted. And one question that's useful to think about is like should we start from the what institutions are right now or should we start from what we want for end users? And what's the best path towards adoption in terms of actually getting to where we want to be? And this is kind of you can figure it out like incrementalist versus nativist approach. So, are you trying to sort of push really hard for these like very sort of hard requirements or do you want to sort of meet them where they are and and work step by step? And if you do step by step, how do you make sure it doesn't sort of entrench kind of centralized control and so on? And is there a path to even better upgrades and so on?

So, these are kind of useful things to think about and I don't think anyone knows because this is something that's playing out over the next few years and decades right? Um one thing we have started doing is we have started looking more at adversarial use cases. So, these are use cases that are even more extreme than this where what happens if an institution uh is adversarial, right? So, how do you have a notion of identity or how do you do payments or how do you do things like coordination or voting in a scenario where you can't even trust the institution, right? So, that's like even more extreme where you wouldn't work with institution, but more like against it.

Uh just some things that we are looking into and so on. Uh things like state bloat, uh commitments and nullifiers they're growing linearly, so you need some kind of notion of pruning. Uh things like post-quantum resistance, which you might have heard about. Um like a lot of CK tech right now relies on elliptic curves. You have things like Stark, but they are sort of safer, but costlier in terms of cost in terms of space and so relayers they can censor. There's things like in Ethereum with account abstraction and fossil that can help with this. Network privacy. So, this is something we have not looked at that much in our POCs so far. We'll do so over the next few months, but these are things like timing correlation and metadata leakage.

Uh and then finally what I mentioned, right? Like adversarial environment. So, how do you get things like identity and payments and coordination when the institution itself is the threat? Um so, if you're representing an institution, you can definitely come talk to us and see we can see how we can help out. If you're a builder, you can contribute. It's all open source, public domain. And if you're a Cypherpunk, like help us keep these guarantees explicit and making sure that the protocols we have they actually have the the guarantees that we want them to have. Uh That's it for me. Everything is public open source. Here are some links uh Twitter websites to our map and the POCs. And you can also scan the QR code to get access to the links.

Thank you. Any questions? Anyone have a question? All right. If you Yeah, you can also come up to me after if you have anything you want to talk about. Hello. Um you've been talking to institutions, so just maybe may if you can share some like interesting findings. Like what are

the top things they are kind of are looking for it right now, but maybe it doesn't exist by the current protocols. Maybe some interesting Sure. findings. Thank you. So, there's like a lot of things. I would say in general, stablecoins is still like something that's sought after a lot. There's also various types of identity. Um Like I think the thing is that different institutions they think about things differently in different jurisdictions um because regulation is is is is at different stages, right? So, it looks different in Singapore compared to US and Europe and Japan.

Um so, there's still some that like are are trying to figure out how things should work in their specific uh jurisdiction. That's something they're considering. Uh I think for like stablecoins, it's not always like retail. Like a lot of it is just internal. Like they want to do something with settlement. They want to instead of um correspondent banking, they want to have something a better system that sells on Ethereum. So, that's like a pretty common thing. Various types of tokenization as well. Um And I guess it's it's like they are trying to understand uh I think there's like a disconnect between all the technical capabilities we have in the space and sort of the business and legal reality they're in.

So, a lot of work is in terms of translating and and trying to understand what does it actually look like uh because CKNS stuff like that is very new to them. So, it's can be hard for them to evaluate. So, a lot of it is also in terms of education and that goes also for policy makers. Um So, I'm not sure if that answered your question, but those are like some concerns that that people are thinking about. Uh and then just like it a lot of it is like it takes a long time, right? And and maybe depending on the timeline, some of them might go for something they can employ deploy right now and others they want to have their own R&D department and they are fine working on this for like two two to five years. So, it's very different depending on what

specific jurisdiction you institution you're talking to. Um It's very interesting. I noticed that the research that you are doing um it's sort of broader than perhaps some people think about privacy. For example, you go into exit rights. So, that's more like self-sovereignty. Like how how do you get this connection? What brought you you know, what what makes you brought to broaden that research basically? That's a good question. Uh I think the reason we focused on privacy initially is uh because that we saw sort of the biggest gap and that was kind of also part of how EF was also currently thinking about it in terms of we have all these institutions they want

to do things on chain. The biggest blocker is privacy, right? Uh what we started seeing partially from demand, but also partially in terms of how we should think about offering them these better systems, it's been okay, we should consider all security properties. So, it's not the case that we didn't do it before, but we're trying to be more explicit about that. So, I think it was always like in the back of our heads, but we have now focusing more on making that explicit and and uh giving like a wholesale analysis to them and not just like privacy specifically. Yeah. We're out of time. Thank you, everyone.