Deanonymizing Ethereum Validators The P2P Network Has a Privacy Issue Yann Vonlanthen

Transcript

[Music] so hello everyone um my name is Yan and I'm very excited to be here I'm a PhD student uh dth Zurich our building is just across the road from here um this is this work I'm going to present today is joint work with lioba who is also here in the room today uh Juan who was working this as part of his master fees uh Luciana and our adviser is Roger venofer first off a little uh disclaimer so everything I'm going to talk about today so we found this vulnerability right and we disclosed it to the etherum foundation and we have the um we're allowed to talk about it now and um we

also received a bug Bounty uh for it so let's uh jump in here I have a depiction of the etherum uh peer-to-peer Network which the whole blockchain is built up on and so here you see what I display here are nodes specifically uh consensus noes so these are the for example Lighthouse or prism clients that you all know uh they're connected to each other and they host validators validators um are the entities that run actually the consensus and as you see there's not always a validator on every client or on every node and some nodes have of course

multiple validators and the validat themselves right I said they have an ID they from time to time oh some slid is missing that's okay um they have to every um Epoch they have to send one attestation uh and where they attest the current head of the of the chain and then more rarely they have to propose blocks right so I think for a single validator maybe proposes a block every 3 to four uh months but every six minutes they have to send an attestation and so how does that look like right so if we have here validators actually in practice if you look at it you don't

know where the validators are situated and there's a good reason for this right so there's this anonymity property and why do we want this anonymity you might ask well let's consider this uh simple example um where there's these validators and they create a blockchain so now here there's a block created by validator 7 then there's a next block by validator one etc etc validator 4 creates a block now as you know there's very often me on chain and that means that certain blocks will have a much bigger reward than others right and so now valid 4 can see this MV opportunity and can if validator 4 is malicious if he knows where validator one is he can

launch an attack on the client on the node of valider one right and so he can prevent this block from ever being proposed and thus he can can swoop in the swoop to the rewards for himself right and uh that's obviously uh a pretty bad uh consequence if we don't have anonymity there's more though so you can keep doing this right so you could you could not only do it when there's a big reward you could also keep doing it so that there's no more liveness in the system and maybe even worse uh if the attacker is a bit even more powerful right right maybe you could even impact safety by tricking for example um light clients you might be

able to trick that there's two different states suddenly so to look into the attack a little bit more I have to dive a bit deeper into the eum network layer maybe I I can uh you know teach you something because I think it's it's it's very interesting design here and so how it works is if a validator wants to send an attestation uh you could do this by simply broadcasting to everyone right and then everyone broadcasts again to everyone this is called flooding the problem with this is that etherum has a million validators right and that means a million messages every six minutes that's a huge load and so instead what ethereum did now or like uh for the

merge is that they use gossip sub which introduces this idea of subnets so instead of everyone talks about everything every one only cares about two subnets and there's 64 so every uh node that you see here only cares about one or two subnets and so and then and that reduces the message complexity quite a bit I'll show you how it reduces complexity so assume now validator one uh wants to send um an attestation the attestation maybe You' notice the validators are grouped in committees right it doesn't really matter for this but the validator knows in which committee is and hence it can know in which subnet that committee

is assigned to so it knows this attestation needs to go to subnet 5 right and so what you can do he can check okay which of my peers are in subnet 5 send that to these peers and then only the peers inside the subnets will gossip that this attestation to everyone inside that subnet right and so everyone in the subnet gossips again similar to before but then what you can do is that there's only a few aggregators in that subnet that will take all these attestations and then they'll make a single one of them with multi signatures and then that's uh aggregated signature you can then broadcast globally to everyone so we were wondering oh this is

a you know interesting design that was introduced what's you know what could go wrong what what's what's this kind of the trade-off here right and specifically um what does it mean for anonymity and for privacy I see that my animations are not working s but all good so you you cannot in principle you don't know uh who is connected to who so what you see actually is just a bunch of clients except if you run your own clients then you can see your peers right and you see the IP addresses and you can connect to them now you can also see in which subnet they are in they advertise that to you right because you need to know to

whom to send what type of messages and so um you will also see the attestations that they sent to you right and that's the that's the other time piece of information that you have so now you might wonder you know which of the which of my peers is running what validator right and now uh I'm going a bit into what we did so we're thinking now to have more information even we can claim that we're in all subnets or we can actually be in all subnets right so we say hey I care about every subnet I'm I can forward you any message you want me to forward and so what in theory we should observe is that every Pier sends us essentially all their messages always right um in practice there's a little

bit of details because of fan outs and peer scores and stuff like this but mostly we observe this as well mostly if we say we're n subnets then we do receive everything um so now let's have a concrete example so we're here we're connected to a pier here they advertise that to us that they're in subnet 13 and 14 and then if we look at what we receive you see yeah we receive a lot of attestations for subet 13 and 14 but wait a second we also receive some other things huh that's uh maybe not expected and then you can look a bit deeper and you can see that they're all from the same validator maybe right they're all from the same validator ID now there's no reason that this pier

knows about all these other messages because he's not subscribed to these other subnets right so how could he know about these attestation well the most likely explanation is that these stations were created here actually they're created by that Speer itself so that's the whole kind of intuition behind behind our attack by by observing this we can uh assign validators to clients so more precisely what do we do so now we run a nodes and we try to connect it to as many peers as possible we listen to all the attestations that they sent to us right we log all of that

tation here and um then we can analyze all this data and try to extract the anization and I'll show you some uh real data here so this is only one connection as the example before so you see here on the xais there's the different subnets the 64 subnets here there's this a couple hours of us listen listening to attestations and now let's look at from which validators have we received attestations here so you see all the red dots they come from a single validator then you can see there's a second one blue dots another and the fourth and they explain kind of almost all the points that are outside the the subscriptions the

subscription here was 13 and 14 right before so all of these are kind of expected they're what was subscribed but and all these that I colored are kind of the outliers that you you you would you wouldn't suspect right initially uh so you see that this is a very clear picture and even more so you see that all the validators they have uh IDs um that's just they're they're just one off right so this is very common if you run uh if you sign up to a few at the same time you get consecutive IDs uh and then there's maybe one more thing I should explain here um is these other kind of so in pink better very I should say these are all the other validators that we receive attestations

from and you might see that there's a couple pink uh here right that you might first not know what it's from but actually these uh patterns match pretty much exactly the aggregation duties that I just briefly talked about before so if you want to if you have to aggregate then for a brief moment of time you need to subscribe to that subnet and so this for example here so that that Pier subscribed to the subnets was also propagating uh attestations for a bit and then created the attestation the aggregation here which you see here created aggregation and then unsubscribed that's exactly the the pattern we also see in in the data right so here we would say okay we have de anonymized these four uh

validators on that Pier right now we're going to do this for much more and to do it more um kind of method more precisely right we introduce a methodology um I'll briefly run you through so we create a login client so we use prism and then we add all this what I talked about of capturing all the information we can we call it rainbow um then we run our rainbow client in four locations there's uh three of them are AWS and one of them is just in our office and our servers um and you see here there's we have a Frankfurt location a sale location Virginia and Zur and we see

here that how many peers they get so Virginia has been pretty popular and Zurich as well the others uh not so much we we can connect to a few less peers um I can talk about the details for for this later if you want to uh and then we kind of introduce heuristics to kind of extract the the denization um and for our connection you see here uh we are we see about 11,000 uh peers in total and for 4,000 we stay connected long enough so these are the ones that now we want to try to De anonymize so we want to figure out in these 4,000 IPS what validators are running there uh so these are our heuristics I

just put them there we can discuss them but it's it doesn't it doesn't really matter so much instead I want to jump right into the the results um maybe I should say just for the heuristics right we have run a study to kind of show which parameters uh make sense and which parameters are and in the end we chose the ones that are the most safe and the most conservative right so we don't want to have false positive at all we were like very conservative with with our parameters here and so yeah let's let's jump into the into the results uh and let starts with with Zurich so this is kind of what have we observed from our zoric machine

uh that was barebones uh service so we had uh in these three days we had 2,000 about uh 2,000 long connections and from these 2,000 connections for almost 60% we can with very high like certainty de anonymize them fully so we know exactly which validators run on these machines for 30% 34% we know that there's no validators on them uh then there's 1% in of the peers that are subscribed to all subnets and so at least not with this methodology we cannot de anonymize them for now and then you see there's a 7% um where our certainty is not high

enough to De anonymize um in numbers this means that we have theed 160,000 validators um this was in May so I think at the time it was about 1 million validators uh in total um so that was about 60% of all validators out there um and then we put a large focus on verifying these results right because so far maybe you don't trust me you saw some heuristics and you you might not trust these results uh this why we have three ways of of verifying these right and that's why I I'm also quite confident that that the denization is correct first uh we look at the

consistency what we call consistency of validator so here there's a bunch of uh data that you can look into for valat so for example you can see so let's say first of all I should say we look at one if we look at one uh client here uh we look at I mean by consistency I mean how consistent are the validators inside that one client right and so we look are these uh all the validators that assigned to this client are they all from the same staking pool do they all have the same deposit address right do they all use when they propose blocks do they use the same fee recipient add address and as we saw before do they have consecutive IDs right so if if one of these uh matches we say that they're

that they're consistent um and then you might see we look at the data of like you know what what is the consistency results uh you see that our Piers they're actually quite consistent uh if we look in terms of numbers of validators there's a percentage that is not uh you know fully consistent with 40% of inconsistent but uh so we look at this and in at first glance you might uh be worried now you might not trust me anymore but I will make you trust me again um so if you look at this uh Matrix here so this is all the almost all the the peers that have inconsistent validators uh or the the largest ones um

and really the inconsistence were um mostly here and you see a pretty interesting pattern that there's especially these first um two peers they are have a high overlap with the other 14 peers so essentially in in other words what it means is that these three peers um pretend or like they they propagate the same messages as these 14 so in essence or how to explain this right is that there are certain service providers that you can subscribe to as a validator and you can send them your attestations and these service providers

will propagate that attestation better in the network right um so so you have like more resilience and maybe also High L uh lower latency for your me for your attestations hence why you won't want to subscribe to these service providers so we have this evidence that there's these service providers and thus we can kind of figure out who's a service provider and we can remove them from the D anization so this 160,000 actually does not include all the inconsistent or the all the the validators that were using service providers um so if we do this uh we go from 250,000 to 160,000 the number I showed you before um and now we can use the second

uh verification method namely we can make you can see whether a certain validator was mapped to multiple IPS and this also we here we see quite many unique validators and little overlap and the ones where there's overlap it could also just be I mean they're often in the same location and so it's it could be like rotation of IP addresses for example or there's multiple explanations for that and finally we since we have four locations right we can make sure that our all four location de anonymize in the same way and here we also we get something like 95% uh of the same d anization at 99% of the valat is

matching um yeah that's for that's it for verification now I think having de anonymized this portion of the network right gives us a quite a unique perspective into ethereum uh decentralization as a whole right because so far people could only look at which clients are are used where are the clients situated but no one could kind of look at where are the actual validators situated where are the actual where is the actual power located right so here this gives us kind of a window although you know it's I a window because only 16% but I think it there's already you can already see quite a few interesting things for example we can check how many validators are run on the peers right so

um on a single Pier how many validators um entities run and I think there's a few surprising things so first of all if you look at here these are CDF plots I'll just quickly go through them so if you look at what this tells you is that for about 50% of the peers they run four validators or less so it's a quite a large uh portion of kind of what we would call solo stakers right that don't uh have money validators on their on their client um also quite interesting you can see that at the at the round numbers like uh there's a 300 400 500 there's a little bump always that's kind of people

like to run a round number of validators uh on their on their clients you see this also here for the five largest staking pools uh you see here the CDF is much uh flatter it means there's much more validators that are run per perer if you run a staking pool that's as expected and you see here for a thousand validators uh there's a a prominent bump that uh staking pools like to run a th000 validators per Pier apparently and you see the same kind of bump at 500 and 300 here um a little interesting information as well the most valat we saw on one Pier was 19,000 that was very surprising to

us that from a single Pier you could run this many validators um and also maybe thought-provoking is that you could that we saw on the same clients validators from multiple staking pools which if you want decentralization right you would want staking pools to be independent and not be run on the same machines uh so that's also uh yeah a little bit um yeah suboptimal uh in terms of locations uh you see here at the top the where we find our peers that we connect to right there's not that many surprises here uh there's a lot of peers in the United States and then in Germany in Europe in general uh you see

that there are four nodes here and you can see that our node in the US is better at connecting to nodes in the US as you'd expect uh Etc um and then in terms of deanonymization though so in terms of where are the validators situated you see there's a huge skew towards kind of Europe and the United States somehow is not the the top location anymore um so this was also kind of surprising to us and I think one explanation is that our Zurich node was just so much better uh at uh connecting or at at De anonymizing uh peers in general and one reason for this is that I think the hardware was better and so we had and we had lower

latency because it was like a bareb server as opposed to the AWS servers so you see here uh only in the US the US node was good atomizing validators in the US but everywhere else kind of our node was very good was better at the anonymizing uh and then in Asia though you see the the the Korean node is is also kind of okaying in in Korea and in the US but still still not great um so that's one thing the other thing we can look at is the or the organizations that run validators um you also here see The Usual Suspects in terms of the peers that we connect to so we connect to many Comcast hetner Amazon on Etc

appears um there's also here a bias and namely we see Amazon is AWS is not so prominent here but if we look atomization we have deize a lot of valid on Amazon and hetner here was very popular but it's it's very unpopular in terms of validators uh you know there I think you know you could yeah we have some explanations for this but maybe you have your own or you can you have your own idea why this could be the case um yeah but I think interesting biases there um now I also want to spend a little bit of time talking of you know what should we do now uh given this this

attack and how can we prevent uh this attack from happening um there's a very uh simple way but that comes with some cost is if you want to only treat the symptoms so the symptom being or for me the biggest problem right right away short term is if you want to propose a block and then you get uh there's this denial service attack that prevents you from proposing a block right um if you want to just prevent this what you could do is to run a client a second client separately that does nothing but proposing blocks right uh so this is kind of what what already the bigger staking entities I think do that they have not just one client but they can run from out of multiple

clients so adding a a little bit more Hardware um might work in a short term but I would argue in the long term is not really uh where we should go a different option is to create private peering agreements so maybe you know this client and this client they trust each other um and so what they can do is that they can send each other attestations first uh so they just share attestations among themselves first and then they both broadcast it and so what it means is that from the outside it would look like there's multiple validators here multiple validators here um and so from the outside you get something like a notion of K anonymity right you you it's harder now if you want to do a DI service on valat S you'd

have to both attack this node and this node so that's potentially one option um another option uh also again um targeting kind of the symptoms is if we did secret leader election because with secret leader election you don't actually know in advance who is going to propose the next block so this that would also prevent uh attackers launching it in Al service um and more fundamentally there are techniques to do Anonymous broadcasting right typically though they come at a large cost in terms of of latency um and finally and this is kind of also where I want to um yeah maybe open up to just not just ethereum and

and gossip up but other blockchain how are other blockchain handling this and um we've seen quite a few blockchains now that go the exact opposite way of ethereum right ethereum has you has a goal of remain everything has to remain anonymous and uh prevents attacks like this other blockchains they go the opposite way where the IP addresses are actually put on chain right so it's the every validator everyone knows exactly where every validator is the advantage of doing this though is that you can block traffic or you can have like firewalls or like dos prevention mechanism by blocking traffic from everyone that you don't you know is not a validator for example right so that way you can also kind of prevent the

null of service and certain blockchain blockchains are doing this yeah that's it for me thank you very much for your attention it's our paper thank you very much Jan and now I think we have some time for questions so is there any question yeah it's coming the mic Cube sorry so you managed to then minimize 16% of the validators on the network but what happened with the rest % or so yeah so um we just didn't so we could run it for longer right and run out of more locations and um and have better servers that are better atomizing

right and that way we could deize more this was more like a proof of concept of hey this is possible and even with 50 by the way even with 15% right uh if you propose many blocks this allows you still to do this uh this uh this sniping attack right where you can prevent Snoop in some M um but yeah for now it's this is a proof of concept and we were not interesting in di we're not interested in deionizing everyone I was wondering if those other validators had like some protection mechanism in place that prevented that duck that's a good question yeah I think definitely um so there's one staking pool that we have never that we haven't anonymized at all like no validator from that staking pool

so for maybe that sing pools for example uh run is subscribed to all 64 subnets which means that with this methodology we cannot deize them uh and there might be cases like this yes uh and all all the ones that use this uh service providers that I mentioned we also cannot gize right yeah I think there is a another there uh if people use uh me commit and all the proposable Builder separation stuff I think what happens is the validator will send their signature to the to the me people and the M people will broadcast the block how does that affect the the methodology here so sorry can you repeat miss the beginning if you

send your if you sign a block that uh that flash BS builds for you how how does that affect the de anonymization attacks if you sign a block that flash block so you're saying um as a the proposing duties if that if that kind of adds more information to the DI anization or well I guess I guess the question is set backwards because the one of the attack goals is to find the proposer before they propose but what happens if they do uh if they do if they Outsource block building and they give the signature to uh to right yeah but then I guess if you do that you you have trust assumptions to the person you give away

your information right so yes and I think we might see a talk later on that talks about this I think there was one last question yes oh this is a microphone um are there any other peer-to-peer protocol changes that you recommend that might mitigate this um well even gossip sub right so even the so this is Li peerto peer right and this is only if you use gossip Sub in this way of having multiple subnets right so we exploit the fact that the way these submits are used right so if you had a validator on a a node with only a single validator then

this wouldn't work right if you have only a single validator yeah no that then it works even better yeah yeah yeah um but if you have only a single uh Gossip topic or if you have only a global gossip which which most blocking also only have right only a single everyone talks about everything then we cannot do this yeah thank you very much uh there is one question I think we have one minute for one last last question um would it be possible to implement or adjust the protocol on a protocol level for example if the peers would change the subnet every EPO or something like that would that make this kind of attack uh basically update the

protocol such that this type of anonymization the anonymization is not possible anymore would something like that work um yeah good question I think it's uh the inherently the information would still be there and maybe it would take a bit longer to the animize right um but I don't see apart from thinking really about anonymity and uh yeah maybe this canity notion right so adding more message complexity back this maybe but just changing uh subnets more often I would for example I don't think that would help um there's no to me there's no obvious simple answer to how to solve this

yeah but maybe there is uh okay if there is no other question I don't see any we can thank again the speaker thanks Yan thank you very much