Reconciling decentralization and network privacy

Thank you. So I'm going to give this talk going through sort of navigating decentralization and the network layer and talk through sort of like the common choice that you have to make in thinking about what is this like step towards a more peer-to-peer or permissionless or decentralized network. There's a bunch of privacy concerns that often come up in those conversations. And you've got a few different ways to navigate through that. And so to make this a little bit more concrete, I'm going to go through this using the example of the various wallets that you commonly encounter.

So whether it's Brave Wallet or MetaMask or so forth, one of the places that you find that starts to not look quite as decentralized is that you're putting in a single HTTP URL of the RPC that you're going to use to actually talk to the chain and back to this decentralized network. And you look at that and you're like, okay, well, at least I can choose it. And it gives you this path towards decentralization of some users can run their own full node or a light node, point to their own RPC gateway that they're now running, and they've reduced their reliance on having this service. But I think there's very few examples of gaps or wallets or things of that nature out there that are by default either expecting the user to be running a full node or that don't have something that looks very much like this. Right?

So you've got the baseline of a hard-coded RPC point. The next step where at least you allow some configuration. And then we've got where we really would like to go from the standpoint of a decentralized Dapp or wallet or so forth, which is that you'd like to make use of this whole decentralized network of all of these users and peers. So why don't we? Right?

Like, why is there this choke point that we've got behind our Dapps and our wallets and so forth right now? And generally there's two different sort of arguments that as you drill into this problem you'll come down to. One of them is somewhat economic and is a question of like, well, you know, by providing this end point of an RPC, now the RPC provider actually can do some of that MEV and can get some of the revenue through a kickback type thing. And we can actually like use that to our advantage to monetize our users. So there's some like, oh, could we have a product here and use this along with the activity on our Dapp as a way of both getting intelligence and on getting, you know, direct economic value extracted.

The second one though is a privacy argument, which is, well, if we make this a wild west of an actual decentralized thing of users sending their messages or getting data from other users, then that means that we've really like leaked all of this network layer stuff. That now users could tell who the other users are. Someone can just sort of sit there and get the list of all of our users. That feels bad. We haven't really thought through what the potential consequences are, but we're afraid of this IP leakage.

We're afraid of that meaning that users get attacked. And so these concerns that sort of like sum up to, well, there's privacy problems are probably one of the larger reasons along with like just, oh, it takes a lot of engineering work that we see reluctance to move past this level of the paradigm. So I think the claim is that if you aren't decentralizing for privacy, you already have the privacy problem. So if you're saying, well, we've got this privacy risk if we decentralize, the reality is you're already leaking that to your RPC provider. You're already leaking that to the network through the ISPs that your users are going through and so forth.

So the privacy leak has already happened. You just haven't properly modeled it into your protocol. And so you can think about this then as one of two reasons as you drive into it that you either need to model the rest of your protocol and be able to understand the incentives and what's keeping things safe from your perspective, or you need to make sure that you aren't actually leaking stuff that you don't want to. So let's sort of break this down a little bit into what this chain looks like, right? The user is using some DAP, which is going back to an RPC provider, which is getting them to the chain.

And we're concretely saying, can we take this choke point that is the RPC provider and turn it into sort of other users that route us back into the chain? And so what's the thing we're really scared about? It's that now these other users can link my network IP address back to my activity. And so we've got like sort of a range. This is an attempt at sort of taxonomizing this.

Like when you say like, well, what's the concrete risk here? It's that someone's watching, they see someone make a transfer that they decide is high value. And so now they say, okay, well, I'm going to call your ISP, pretend to be you, figure out your name. And now I can target you because I can just sort of be watching this ambient network. But you've got like a set of more nebulous risks that is where it gets much harder to model.

So maybe there's malicious users in this mesh that are like delaying or preventing some transactions in order to arbitrage them. Or people are just sort of collecting these passive databases of linking IPs at some time back to the wallets or the activity they see. And then later when some other database leaks or becomes public, you can cross-reference and you can re-identify users at scale. So you've got this set of like growing risk that's really hard to quantify. That's what you're really, I think, sort of like trying to encompass in terms of what is this risk.

And by trying to at least write these down as the specific risks or at least the class of risks, you're now able to figure out how you're going to mitigate them. Okay. So, my argument is you've got two things here. And I said that before, but I'm going to say it again, which is you're either going to take the externalities of how you're protecting it already in an RPC provider and you're going to be able to think about that in terms of a protocol. And then you can do a Web3 native version of it with the same structure.

Or you're going to actually have to think about the protocol level. What is this link that's getting exposed and are there ways to not expose it in the protocol? So the first one of how you're going to scope these externalities. The reality is that the reason you are okay with an RPC provider is that you've got a remedy if there's a problem, which is you can go and sue them, right? Like if your RPC provider is acting badly, you've got this real world soft gap of how you're going to remedy the harm, right?

That you're going to file some sort of lawsuit and you're going to say, hey, you leaked the user data and then we should compensate the users and or the protocol that's using it to make that not the rational action for these entities. But we can do that in a Web3 native world as well. We know how to do this. We stake some money and we'll have some governance body that is able to decide if that stake gets slashed. And so you could have something that looks very similar to the RPC provider, but with an on-chain governance and you've now internalized it and you've now got a governance process for how you're going to change that RPC structure.

Or you can say that now you're on a path to a federation where that governance body can say, great, entities that have faked this much that we're going to make sure aren't leaking can join in. And now you've gone from like a single thing to a path of multiple providers and you've actually got something that looks a lot more decentralized rather than there being a single hard-coded URL that is the choke point. So I think the point here is even without looking into cryptography or how you're going to delink this in your protocol or making development protocol changes, there's absolutely a path towards decentralizing this choke point that's done purely at your sort of policy legal governance level. And it's about taking the stuff that you've got encoded in your contracts and how you're paying some RPC provider and bringing that on-chain or into something that is decentralized. We see a bunch of pretty functional federations emerging as a much more Web3 native thing.

Once you've got the federations, you can do things like multi-party computation and other forms of cryptographic things to further reduce your risk from this structure. But there's a path here that starts with doing this in a policy way. That's the first arm and I think this is an arm that is like very powerful that we don't talk about enough when we talk about navigating this path. Okay. So the other thing we can do is we can go and nerd out about how to make our protocol better.

And in general, this is, well, okay, we saw that there was this link that we were unhappy with, which was I can now attach your IP address as a network layer to the stuff you're doing. And so is there a way to still do the stuff that your dApp is doing without having that link getting coded and without people being able to see it? This is sort of like a little taxonomy of how we approach this that Vitalik has shown something pretty similar. But the first thing you will often see when you're thinking about chain-based applications is that you've got two types of activity. You're trying to read and then you're going to make transactions.

And often your reads, you're doing a lot more. You want to learn various parts of state. You want to see that change over time. Whereas transactions that you're making on chain already cost money, already typically are going to take a little bit more time. And so you may approach these two sub-parts of the problem differently.

For reading, so when you're trying to learn, you know, what is my account balance or what is the dApp state or things of this nature, there's a couple different building blocks in here that can help you with unlinking that are already getting pretty close to just be dropped in. One of these is using confidential computation, so Ts. You can use hardware security to impose an additional economic cost to whoever is doing that read from being able to compromise it. And so you can build an economic argument around the cost of the person you're talking to being able to see what it is you're actually reading. And that economic-based thing works as a thing that really doesn't require too much code change.

You're doing some signature verification to make sure that you're actually talking to valid hardware on the other end of your network link. But then you have the same computation happen by the other user, but the other user is now has a much more costly time of looking in to see what's actually being read. If that's sort of not satisfying because you don't want to trust Intel or the other hardware vendors where this trust route and the cost is located with, private information retrieval or PIR is a cryptographic technique that allows you to do something similar where you can do computation over encrypted data without being able to see what specific data you're looking at. And as a sense of scale here, PIR like two years ago now got deployed by Apple in probably the largest deployment for all caller ID lookups. So whenever you get a phone call on an iPhone and it shows the name and it's not in your contacts, that name is getting fetched from Apple's server, but Apple isn't able to know who called you, right?

Apple doesn't have a log that associates the contents with the people saying, hey, I got a phone call, what's their name and picture? And is in fact using homomorphic encryption and this private information retrieval method to be able to retrieve items out of its central server database, but with a cryptographic protection that keeps it from having to know those links. So they're doing that for every phone call that's happening. That is higher volume than what we're doing for, I probably guarantee any of the dApps that are considering this. So certainly for account balances, probably for most state, PIR is able to work performantly and really cheaply enough that you could go out and deploy it.

The main problems are purely sort of an engineering one at this point, that performant and scalable implementations of it are probably not language integrated in ways that mean that you don't have to do any development work yet. So there's this additional development work along with it being sort of like in this systems layer means that you have to pay someone who knows what they're doing, and that's been a barrier where we've only started to see some experimentation. There have been, there's web demonstrations of being able to fetch any Ethereum or Bitcoin wallet address without the server that's providing that knowing what you're doing. So this is like close and hopefully comes more. On the right side, there's two different pieces.

You've got a mixnet like NIM that's going to be able to separate and unlink who is making the transaction from the contents of the transaction, right, so it protects that network layer from the contents. And then you've got privacy chains where balances are shielded, and that's protecting what is happening or how many coins are moving around in an ongoing way. And so these are generally complementary that working with shielded transactions in Zcash or Monero or so forth is something that you would do in tandem with network privacy to both unlink when you're doing them and being able to keep sort of that series or the conversation or the iteration of transactions, which is what the network level mixnet type things are protecting from how much volume or things of that nature, which you would want shielding on the chain from doing. When you're saying, okay, I'm unlinking, the thing to then zoom out, which I think is going back to sort of a meta discussion, is what is it you're trying to hide as? And this is a concept in this space that gets referred to as the anonymity set.

And it's saying, okay, so they can't say it's you, but what is it that you're hiding amongst? Who else could it be? So are you just trying to be another blockchain user? Or is that still too specific because, oh, you still are using crypto, you still probably have a crypto wallet, you're still a potential target. And I think we have this as a fear.

So if you go to a wallet and you're like, well, you know, do a peer-to-peer thing as long as you sort of encrypt your transactions and people don't know how much someone has, you know, is that really a problem? And you'll often get people saying, well, but if someone can enumerate and get the whole set of our users, that's pretty scary because, you know, they can know that and target our user base. And the reality is that for a bunch of these, like you look at Ethereum users or MetaMask users, you're already bigger than any of the privacy-focused anonymity sets, right? So if you're trying to hide amongst Tor users, it's not going to work because you already vastly outnumber the Tor users. And so now it just means that someone looks at all the Tor users, Tor is not trying to hide the fact that someone is using Tor, just what they're doing within Tor.

And you say, okay, great. I'll just watch for Tor users. And now I'll know that 75% of them are, you know, wallet users and I've recalculated that database with somewhere. So if you're trying to go into a larger set, you need to figure out what that larger set is. And I don't think we have very many credible things at scales above current Bitcoin slash Ethereum user bases already that we're going to be able to hide among and say, oh, I'm not a blockchain user, I'm just, what, a VPN user, maybe.

But then I think that's going to take like a set of negotiations with the big VPN providers. And beyond that, like when you look at sort of the scale of VPNs, a lot of that's corporate VPNs. And so really actually hiding within the broad set of VPNs is going to be a pretty tough thing. So figuring out what it is you're blending in with is probably the biggest challenge or challenge for a lot of large scale privacy migrations. The flip is, if you're a dApp that is not MetaMask or, you know, one of these large wallets and 10 million users looks like a lot of users, you can hide in these things.

And that's probably realistically a very valid anonymity set to make use of as you grow for most existing apps today. So I think there's two different conversations and you shouldn't get scared of the conversation of like how do you hide being a blockchain user for most applications. I'll end with a couple minutes just sort of deep in sort of the nerdy tech stuff. Beyond this, there's two other classes of privacy anonymity edges that people are looking at how to hide. One is length of messages.

So can you learn something from how long messages are and how much should you pad them so that most messages are the same length? So do you add some extra zeros before you encrypt them so that seeing the encrypted message you can't tell is this a normal transaction versus a smart contract versus a multi-sig. Those don't like look at different lengths. The other one is timing. So can I tell, oh, this IP is sending messages during daylight hours of Europe and so this user is probably in Europe.

You may already learn some of that from the fact that the IP address is associated with a European ISP. But VPNs and so forth mean that alone is not as useful as when the activity happens. For the first one, there's a bunch of work that happened in the last decade. I think one of the more useful summarized repos is this thing called WFPadTools that has a bunch of Tor contributors helping think about what good quantizations are for general message patterns. And then for timing, again, about a decade ago, Pond came out as one of these privacy messengers.

And the cool thing there is it used an exponential sampled interval. And what that means is each time the next message, it samples on an exponential distribution. So most of the time it's pretty soon. But if you don't see a next message, you can't tell for sure if the user went offline or if they just rolled a long time for their next message. And so that, the fact that message sending is always a statistical thing makes it much harder to confidently tell if a user is online or offline.

So I think that's where I'll leave it. I don't know if we've got a minute or two for questions, but thank you. Thanks. Questions? Questions, questions, questions.

Super simple in that sense, like why we are where we are in the sense of, for example, Cassandra has been talking about, OK, we need to redesign Wallet UX from the ground up. But I'm interested in what were the design choices, architectural choices, dev choices that led us to where we are? What we can learn from them? Maybe those people who are kind of like jumping into crypto as Holy Grail of, let's say, privacy as people, many people thought of Bitcoin. They were just naive in terms of a specific, I don't know, anonymity, academic knowledge or they lacked certain skills.

What we can learn from these, let's say, mistakes of the past? I don't know if I'd characterize it in that way. I think dApps and this use of the web platform as an interface definitely came as a sort of a second iteration, where first you got a set of system builders who were playing with this, you know, daemon app that is the node. And then transactions happen through that and then people are like, oh, we need a UX for it. And the system was not built for how do you make a decentralized network that decentralized web apps can communicate with.

And so the thing that has existed through that first round of the RPCs of Bitcoin and Ethereum, where it was like, right, you can submit transactions from the desktop client that then emerges or then evolves into, okay, well, we can do that over JSON and have a web front end, meant that there wasn't thought from the underlying distributed system that is these blockchains into, okay, is there a way for clients that may be sort of either idempotent or gotten through, you know, the set of best practices for dApps to then not end up either having a local node that they're talking back to or some hard-coded one. And so I think we built the underlying system without having an answer for what this front end that has emerged as sort of like the compelling user interface was going to do with it. And so now we're figuring that out.