DAPPCON 2025: Reconciling decentralization and network privacy - Will Scott

Transcript

Thank you. Um so I'm gonna give this talk uh going through sort of navigating decentralization and the network layer uh and talk through sort of like the the common uh choice that you have to make in thinking about what what is this like step towards a more peer-to-peer or permissionless or decentralized network. um there's a bunch of privacy concerns that often come up in those conversations. Uh and you've got a few different ways to navigate through that.

And so to to make this a little bit more concrete, uh 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 um you find something 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 DAPs or wallets or or things of that nature out there that are by default either expecting a user to be running a full node or that don't have, you know, 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 DAP 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 why is there this choke point that we've got behind our DAPs and our wallets and so forth right now and and generally there's two different sort of arguments that as you drill into this problem you'll you'll come down to um one of them is somewhat economic um and is a question of like well you know by by providing this uh this endpoint of an RPC now the RPC uh provider actually can do some of that me and can get some of the uh revenue through a kickback type thing and we can actually like use that to our advantage to monetize our users. So there there's there's some like oh could we could we

have a product here and use this along with the activity on our DAP as a way of both getting intelligence and on um getting you know direct uh economic value uh 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 uh are probably one of the larger reasons along with like just oh it takes a lot of engineering work um that we see reluctance to move past this level of the paradigm. So I think the the claim is that if you aren't decentralizing for privacy you already have the privacy problem. So if you're 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 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 uh one of two reasons as you drive into it that that you've either need to model the rest of your protocol and be able to understand the 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 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 what's the what's the thing we're really scared about? It's that now these other users can link my my network IP address back to my activity.

Um, and so we've got like sort of a a range. This is an attempt at sort of taxonomizing this. Like you when you say like, well, what's the concrete risk here? It's that, you know, 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. Um, but you've got like a set of more nebulous risks. That is where it gets much harder to 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 you know leaks or becomes public you can cross reference and you can reidentify 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. Uh and by 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 two things here. Uh, and I 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 uh 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 if your RPC provider is acting badly, you've got this real world stop gap of how you're going to remedy the harm, right? that 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, you know, compensate the users andor the protocol that's using it to to make that not the rational action for these entities." But we can do that in a web 3 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 onchain 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 staked 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 uh you know how you're going to dellink 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 onchain or into something that is decentralized. Um, we see a bunch of pretty functional federations emerging as as a much more web 3 native thing. Um, once you've got to 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 that starts with doing this in a policy way. So 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. Um, 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 at the network layer to the stuff you're doing. And so, is there a way to still do the stuff that your DAP is doing without having that link getting coded and without people being able to see it? Um, this is sort of like a little taxonomy of how we approach this that, um, Vitalic has shown something pretty similar. Um but

the first thing you will uh often see when you're thinking about uh 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. Uh and often your reads you're doing a lot more. You want to like learn various parts of state. You want to see that change over time. Um 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 subp parts of the problem differently.

Um for reading um so when you're trying to learn you know what is my account balance or what is the DAP state or things of this nature. Um there's a couple different building blocks in here that can help you with unlinking that are already getting pretty close to just be drop in. One of these is using confidential computation. s you can um use hardware security to impose an additional economic cost to whoever is doing that read uh from being able to compromise it. And so you can build an economic argument uh around the cost of the person you're talking to being able to see what it is you're

actually reading. And that and that economic based thing works um as a as a thing that really doesn't require too much code change. you're you're doing uh some signature verification to make sure that you're actually talking to valid hardware on the other end of your network link. Um but then you have the same computation happen by the other user, but the other user um is now uh has a much more costly time of looking in to see what's actually being read. um 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 um located with private information retrieval or PI uh is a cryptographic technique that uh

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. Um and as a as a sense of scale here, um P like uh two years ago now, um 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 isn't 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?" Uh, and is in fact using homorphic encryption and this

private information retrieval method um to be able to retrieve items out of its central server database um 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 DAPs that are considering this. So certainly for account balances probably for most state PI uh 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 uh 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 this additional development work along with it being sort of like in this systems layer means that you have to like pay someone who knows what they're doing. Uh and that's been a barrier where we've only started to see some experimentation. There have been um there's web demonstrations of being able to fetch any Ethereum or Bitcoin uh wallet address without the server that's providing that uh knowing what you're doing. So, this is like close uh and hopefully comes more on the on the right side. There's two two different pieces. you've got a mixet like NIM uh 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 uh in an ongoing way. And so these are generally complimentary that you know working with uh shielded transactions in in Zcash or Monero or so forth is is something that you would do in tandem with network privacy um to both unlink the when you're doing them and being able to keep sort of that uh series or the conversation or the

iteration of transactions which is what the the network level mixnet type things are protecting from you know how much volume or things of that nature which you would want shielding on the chain from doing when when you're when you're saying okay I'm unlinking the thing to then zoom out which I think is uh 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 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 as a fear. So, if you 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 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 the our our user base and 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 tour users it's not going to work because you already vastly outnumber the tour users and so now it just means that someone looks at all the tour users tour is not trying to hide the fact that someone is using tour just what they're doing within tour and you'd say okay great I'll just watch for tour users and now I'll know that 75% of them are you know wallet users and I've I've recalculated that database with some error 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 Ethereum user bases already that we're going to be able to hide among uh and say oh I'm not a blockchain user I'm just what a VPN

user maybe um but then I think that's going to take like a set of uh negotiations with the big VPN providers and beyond that like when when you look at sort of the scale of VPN 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 set uh or a tough thing so uh figuring out what it is you're blending in with is probably the biggest challenge or challenge for uh a lot of large scale privacy migrations. The flip is if you're a DAP that is not MetaMask uh or you know one of these large wallets

and 10 million users looks like a lot of users, you can hide in these things. Um, and that's probably realistically a very valid anonymity set to make use of uh as you grow for for most existing apps today. So, um, 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 uh for most applications. I'll end with a couple minutes just sort of deep in sort of the nerdy uh tech uh stuff. Beyond this, there's two other classes of privacy anonymity um edges that people are looking at how to

hide. One is uh length of messages. So, can you learn something from how long messages are uh 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 uh is this a normal transaction versus a smart contract versus a multi-IG? Those don't like look at different lengths. Um the other one is timing. Uh 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, you know, a European ISP, but VPNs and so forth mean that

alone is not as as useful as when the activity happens. Um, for the first one, um, there's a bunch of work that happened in the last decade. Um I think the one of the more useful uh summarized repos is this thing called WF pad tools that um has a bunch of torque contributors uh helping uh think about what good quantizations are for general message patterns. Uh and then for timing um again about a decade ago pond uh came out as one of these privacy messengers. And the cool thing there is it used um an exponential sampled interval. Um and what that means is uh 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 uh the fact that message sending is always a statistical thing uh makes it much harder to uh confidently tell uh if a user is online or offline. So uh I think that's uh where I'll leave it. Um I don't know if we've got a minute or two for questions, but thank you.

Uh questions questions questions. Um super simple. uh in that sense like uh why we are where we are in sense of there also for example uh Cassandra has been talking about like okay we need to redesign wallets UX from the ground up but I'm interesting like what were the design choices architectural choices like dev choices that led us to where we are what we can learn from them h maybe those people who were kind of like jumping into crypto as holy grail of let's say privacy as people many people thought of bitcoin um they were just naive in terms of a specific uh I don't

know pronimity uh academic knowledge or they lack a spe certain skills what we can learn from this let's say uh mistakes of the past I don't know if that's I' I' I'd characterize it in that way I think um daps and this use of the web platform form as an interface definitely came as a sort of a second iteration where first you got a set of systems builders who were playing with this you know demon app that that is the node and then transactions happen through that and then people 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 had existed through that first round of the RPC of Bitcoin and Ethereum where it was like great 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 item potent or gotten through um you know the set of best practices for DAPs to and 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