DAPPCON 2025: Deanonymazing Ethereum Validators: The P2P Network Has A Privacy Isuue - Yann

Transcript

All right. Hello everyone. Super happy to be here. Uh I'm presenting today a paper um that was done uh at TTH Zurich where I'm a PhD student. I also recently joined the FUM foundation. Uh and this work uh was done in collaboration with my amazing colleagues Leoba uh Juan who was worked on this as part of his master thesis uh Luciana and Roger who was our adviser. Uh so in this work we'll be looking at how we can deanmize Ethereum validators and just uh to just right away I just wanted to mention that we've disclosed uh these findings to the Ethe foundation and uh to this bigger staking entities and so I'm allowed to talk about this I

think safely. Um so yeah let's jump right in. I will uh start with the very basics. So here imagine this is a peer-to-peer network. uh let's say the the consensus peer-to-peer network actually. So these are uh the nodes um you can imagine them the the prism clients, lighthouse clients, etc. TU um and they're connected with each other and their job is essentially to host validators. Uh we see here a couple validators. You see some nodes have no validators. Some nodes might have just one or a few and some might have a lot of validators.

And uh the validators, they're essentially the entities in charge of consensus. They have a unique ID and um one of their main jobs is to uh continuously propose uh blocks. This happens very rarely, right? A single validator since there's more than a million of them. I think currently they propose only like three to four times a year. And what they do more often though is that they send votes to attest their view of the chain. So that's their and they have to do this once per epoch. and epox is like six and a half minutes. So that's kind of what they what they do all the time.

So here we have the the network with our validators and essentially what we want we might want is that this is uh anonymous that we cannot from the outside tell which validator is where and also by the way the links we should also not be able to tell of course. Um but you might ask you know why do we want this this property uh if it's a very good question. So let's uh look at a quick example of what could go wrong. So imagine here we have a a block that is produced by some validator. There's another validator here. Validator one proposes a block etc. Now it's the turn of validator 4. Now if validator 4 sees

that there's a huge uh reward in the previous block. What validator 4 might do is if it's if it was malicious uh then the validator could uh try to figure out the IP address of validator one first and given this IP address really launch a launch a DOSS attack on this on this validator essentially preventing this block from ever being you know sent into the network and thus being able to re uh reap all the benefits of that block.

Uh so that's uh I would argue would be a pretty bad thing to happen. Um so this is like a it's called a sniping attack. And of course you could do this also continuously if you really wanted to completely halt if you're even though at at a higher cost of course uh at so this is I think two uh things of course with uh theization you could also you know you could think of other things that could go wrong to understand a bit more how our attack works or how why anonymity is not is not given uh I'll give you a primer on on the HUM network layer and I think this is actually quite uh interesting and hopefully you can learn something here.

So the validators need to send uh at the stations and one way to do this and how this is often done is that you gossip this at the station to your peers and these peers then gossip it to their peers etc until the whole uh every node has this attestation. The problem is there's a million validators and if everyone does this every six minutes, right, this is a huge this is um multiple megabytes of data that have to be sent in a in a rather short amount of time which would be unfeasible.

And so when the merge happened they um used this other design instead or they used subnets um that are part of gossip sub. So gossip sub is the is the gossiping mechanism in general which gives you this ability to have subnets and how ethereum uses them is that validators they're assigned to a given subnet when they need to send a message and so now um this for example validator one if val one needs to send a message it can tell which subnet it was assigned to given if it's assigned to subnet 5 it can check its peers check who is in in subnet 5 and only send it to the to the

peer that is in that subnet. And so I should say the idea right is that on a higher level is that each node is not in every subnet. So each node here currently for Ethereum is by default only in two subnets. So if there are 64 subnets, every node is in two subnets, right? You scale down the communication complexity at least at this high level by by 32. So to keep the example going the message is now sent to a peer that is in subnet 5 and now the gossiping happens but only in that subnet 5. So here the same thing happened as before and the the trick here is that now in that subnet there can be a few aggregators and so they see

all these messages in the subnets but they can aggregate and then only that aggregate is sent to everyone right saving a lot of bandwidth. Um and this we we looked at this design and we thought this was uh you know very interesting but we wondered do we have to give private do we have to give up privacy as a trade-off for this lower network load and I will show you uh that yes we have to give up privacy and to look at this um let's see uh what appear from the perspective of a peer what is the information that appear has Okay, so if I'm this peer, I know the IP addresses

of everyone in my peer list. I know in which subnets they are, right? This is kind of what I need to know so that I can forward the message correctly. And of course, I continuously receive the messages that they send me. Okay, so this is kind of what we're working with here. uh what I shouldn't be able to tell as a as a peer is that I I shouldn't be able to assign validators to these nodes. So uh the trick here and this is the very the intuition of the whole thing is that you can tell your peers that you're in all subnets. Okay? So you tell them, hey, please send me all your messages

that you have. So they they will happily do that because you're useful to them, right? They want to propagate at the station. Um and now we can look at what types of attestations we get. So we have our uh a pier here that is subscribe to subnet 13 and 14. So their job is essentially to forward everything from 13 and 14, right? So of course you see here we see a lot of messages, the green ones and the pink ones from subnet 13 and 14. Wait a second. Why do we have um attestations from different subnets?

Right? This is unexpected. This pier was only able is only subscribed to 13 and 14 should only be able to receive those. And if we look a bit in more detail into these uh other messages, we see that they're all signed by the same validator, right? So what's the most likely explanation here? Well, is that this validator is on this node, right? Signed these or just created these atestations there and that's why that node knows about them and that's why they sent them to us. So here we could probably with very high likelihood say okay val 93 is on this node and this is the the intuition behind uh what we're doing.

So what we can do is we can have this uh spy nodes that is connected to a lot of nodes and it will just continuously log all the attestations that we receive and keep track of them. And here uh so this is uh we did this uh study about a year ago and this is uh a real um snapshot of what we observed or what our node observed and so this is one connection to this is a connection to one pier. Uh you see here on the x-axis there's the different subnets subnet zero to subnet 64 and you see um this is a couple hours of data that we collected

and each dot is a single at a station. And so when now we can look at these single dots who signed them who signed this at the station which validator and we see that uh all the red dots this they are from a single validator ending in 16 all the blue dots another validator orange dots and turquoise dots. These are four validators and they if you look at it they kind of make up all the surprising uh dots in this picture right because actually that's pier was subscribed to subet 13 and 14 as in the example before right so this is these big this big line this big horizontal line right that's

the subscriptions which we expect to be there right and all the others they are essentially only coming from four validators Um so here we would say you know there's again a very high likelihood that these four validators are actually hosted on that node. Um a little bit of a maybe an interesting side note if you look at these uh the pink ones right so this is all the ones that are not from these uh not written signed by these four validators. You see that there's also um little blips that are not subnet 13 and 14. And so these little blips correspond to a aggregation duties where for a

short amount of time you need to uh subscribe to a sunnet so that you can do this aggregate and at the end of the blip you see actually the the attestation or the aggregate that was that was sent. Uh also pretty interesting right or like maybe a clue you see that the validator ids there sub subsequent um which uh is exactly what happens if you stake you know more than 32 if then you get like subsequent validator ids. All right so now for the more large scale study let me talk about you know what we did in more detail. We took a prison client uh we added a lot of logging to it and we call it rainbow. We run this client in four locations. One

of them is in our office in Zurich, three of them in in AWS locations around the world. And we run only for three days. So I want to emphasize this is very easy to do, right? Uh you very short amount of time, a very uh you know kind of lowcost uh setup. Uh and this is kind of so the these are for the four locations we have how many peers we connect to. So that's the kind of one of the changes we did is we just connect to a lot of peers so that we try to have more connections but other than that we behave like a honest participant. We don't do anything uh that harms the network.

Uh so we get about 4,000 connections that are rather long in total. You see we connect about 11,000 um nodes and 4,000 of them are are long. And then we run a heristic that is based on the insights I just told you about. Uh this is the exact heristic. Essentially what we did is we did a whole study on which on how these you know how to select these parameters so that we can be as safe as possible and as conservative as possible. So I'll not go too much into this but happy to discuss later.

So instead yeah just let's just jump right into the results. Um maybe start with starting with Zurich where we had our Bearborn server that was able to kind of keep 2,000 uh connections for these three days. And you see uh for 60% of these uh 2000s connections, we could fully with high confidence deonymize um which validators are in them. For uh about a third, we know for sure that there's no validators. And then there's uh a rest where we are just not uh confident enough.

Um in total over all the machines we are able to denomize 160,000 validators which makes up at the time at least we did this was about 16% of the validators. And I want to emphasize that uh so this was kind of an academic study and our goal was not to denomize everyone. It was just kind of to prove that it's possible. uh but still I think we can kind of draw some some interesting conclusions and I think you know if we did this with more machines and we did this over more days then we could denimize much much more uh but first maybe for now you don't really trust me uh and you don't trust kind of the validity of these results so we did three types of verification to

make sure that uh they're correct so let me briefly talk about them first we look at the consistency so if we look at the single node And we look at which validators were assigned there. Are are they kind of consistent? Do they come from the are they from the same staking pool or do they use the the same fee recipient address? Right? If they don't, then we say they're inconsistent. Uh and for peers, we see that many of them were consistent, but then wait a second, for validators, actually there's a lot of inconsistent peers. And now maybe you don't trust me anymore. Um but there's a a simple explanation for all these inconsistent uh peers I would say. Um we looked here

you can see uh which peers um have overlap in the validators that they host. So these are all the peers that have more than 200 validators of overlap. And you see this very interesting pattern that the first uh free peers so the ones that have the most the host the most validators they overlap a lot um with the with the top 14 peers. So in other words uh the validators present in these 14 peers they all kind of also appear in appear in the pier 0 one and two. So the the explanation here is that we believe that there's um service providers that you

can subscribe to. So if you're a validator and you want to have better network connections, you can go to a service provider who then uh sends these attestations out from different endpoints across the network so that you can you can have better latency guarantees for example and you make sure that your attestations is seen. So of course these uh service providers uh they would falsify our results. So we removed them and actually so we had first 200,000 validators and after removing them uh we're with the then we have the 160,000 left that I just told you about.

So now we have uh consistent validators. So let's uh double check again with another metric namely by checking the uniqueness uh of the validator IP mapping. So do we map the same validators to multiple IP IPs sometimes and there's about 10% which we map to you know non-unique IPs but which again might be a bit concerning you you might think but actually uh almost all 90% of these uh of these cases the IP come from like the same city uh which might either you know be due to uh validators or like peers rotating ing their IPs or you just using more hardware more than just one

um node. Um so that's that. And then finally since we have four locations right we could cross reference the donimizations from the four locations and make sure that that they match and here we get about 99% uh accuracy. Uh so now we can talk a little bit about the the takeaways uh that we can observe from these denomizations and I think there's a a few interesting things that we can learn. Uh here we have uh two CDF plots of uh how many validators there are on a given pier and first on the left you see uh that the CDF kind of ra rises very sharply. So I

think it's about at um about four validators per pier. So half of the peers have only four validators or less. So it's kind of a I would say a large proportion of solo stakers at least if you look at it from a a peer perspective. Uh then you see these uh vertical lines which mark exactly the peers that have exactly 100 validators uh 300 400 500 and a,000. And you see that people like to run an even number of validators. You see little little bumps there.

Um and then as for the staking pools, you see that the this the CDF is more flat. So there's in general there's just staking pools run many more validators per pier, which makes total sense. And again, you see that uh for uh one I think one especially one big uh staking entity, they always like to run a thousand validators. um per pier. Um we saw uh one pier that had uh almost 20,000 validators. That was quite surprising to us that you can run a pier with that many validators.

And maybe more worryingly uh we saw that actually uh some uh peers were running validators from different staking pools which would which is kind of alarming because you'd want staking pools to be like independent uh entities and not use the same machines. Uh we can also look uh a little bit into uh the geographic distribution. So first at on at the top you see um where the peers are located that we connect to uh and you see that uh by the way these the the colors correspond to the four machines that we're running. So you see that the the node in um Virginia uh this turquoise node is connects a lot to the

peers in the new United States as as you would expect. Uh and then at the bottom you see the validators and this is was quite surprising to us. Uh even though we connect a lot of peers in the United States, we found a many more validators in in Europe. Um and one explanations for this is that our uh our peer in Zurich was just much better at the anonymizing. So it was a beefier machine than the ones on Amazon. And so it was better at keeping connections uh with with its peers. And so you see that the the blue bars are quite high except for the United States where the United States machine actually was was better at the anonymizing.

Um and then as for the um cloud providers first of all we see that there's a a lot of uh val running on on cloud providers and you see the again where the peers are run. So here you see Comcast Hetner and surprisingly they there's not many validators on HNER for example even though there's a lot of peers we find most validators on Amazon and AW and I think maybe this might be you since there's some policies right that you're not allowed to run um clients on HNER so maybe for you know a full node it's okay but if you have a validator you wouldn't want to go to Hzner that's that's maybe one explanation for

Uh also quite surprising is that even though we run many nodes on Amazon itself on AWS, the Zurich machine was best at generalizing also Amazon um validators. And yeah, now I have a little bit of time left to talk about mitigations. Uh one simple idea, right? If we talk simply about the symptoms uh of having the anonymized validators to prevent a sniping attack each validator could run an additional node right that is independent connected to the network and only used to gossip the block. Uh, of course the big uh providers already or the big staking

pools already do this today and I think also there's clients that natively offer this option to do this. Um, but I would say for solar stakers it's maybe not the the best option. Another thing that exists today is that you can do private peering agreements. So if you trust some other nodes or some other valid layers you can uh enter private uh you can connect directly and then sorry and then it looks uh here the slide doesn't show but it then it looks that once they're connected from the randomizer perspective it looks like both of them run both all the validators right so you get some notion of k anonymity um you could have secret leader election

um maybe more interestingly you could have uh some form of anonymous broadcasts which I think is explored not for uh me for attestations because for attestations that would add a lot of overhead right which anyway we're we um we wouldn't want for latency reasons for example um but for other things that are maybe even more um critical we could think about doing using anonymous broadcast and finally I want to kind of open up the the discussion a little bit uh And uh because one I one thing that is done in a lot of other blockchains right is that to completely forget about uh anonymity post the IP address even

onchain in some cases. And what this allows you to do right if you have no no anonymity anonymity at all is that you can run firewalls for example that can block traffic from all but the validators for example right. uh and also this would allow you to do a lot more um you know performance uh networking uh algorithms. So I I would argue at the moment Ethema is in this kind of in between space where it's it's kind of looks like it's anonymous but it's it's not really right but but also we cannot take advantage of the fact that it's not uh anonymous.

So yeah, I'd be I'd be happy to hear uh what you think about that and where Ethereum should be headed in that direction. Yeah, thanks a lot. That was it. Thank you. Do we have time for questions? No,