On Valitraitors and Relayviors: Censorship On Ethereum
ETHCC 6 · July 2023 · 15:16
Jannik Luhn examines censorship in Ethereum through the roles of validators and relays.
Speakers
Topics
From ETHCC 6, hosted by Ethereum France.
Transcript
name is Yannick thank you all for coming I am working at brainbot on a project called shutter network but today I want to talk about something different I want to talk about censorship on ethereum and that's because we at brainbot we care about ethereum and especially if your own fundamentals and last year this topic of censorship became very hotly debated and we have some thoughts about this that I want to share but to start with I want to take a step back and look at ethereum as a whole and in particular on its incentives and block rewards so every single day ethereum pays its value data set three and a half
million euros in eth which is a lot of money and the reason why it does that is because it wants to encourage a large and decentralized and diverse Valley data set and of course this in its own is not really a goal on it in itself it's not an end goal and the actual goal behind it is credible neutrality that's what ethereum wants to achieve the idea is that the more decentralized and the more diverse you're validated as it is the more difficult it is for a single entity to um yeah to or for groups of in in that set to band together and to yeah to imprint their own values on the protocol
and the way this credible neutrality manifests itself is of course intensive resistance for example um so let's look at censorship poker sensorship work um to do that we have to look at a transaction and how it goes through the system it originates at a user then it goes through a front-end application and then usually through a wallet which actually signs it then through an ISP or network connection and then to some sort of block production mechanism and in addition to that the front end and the wallet they might be talking also to other third-party services that are vital to um to that transaction and if and all of these steps there can be censorship and I think it's very
important to look at all of these steps but for the purpose of this talk I want to focus on only the block production mechanism because the like the solutions and the problems are of course very different on these layers yes so how does it work and traditionally it's very simple the value data was assigned by the protocol to produce a block they pick a transaction or a set of transactions from the public mempool which is kind of a peer-to-peer Network they produce a block and send it again to a network of where the block is broadcasted um very simply the only entity that could censor here is the validator but since the valid data set as we said earlier is very decentralized and diverse I would say this setup is very safe
now recently a new way of producing block has emerged again we have a validator at the very end that produces or at least the science of the block but the block is actually produced by another entity called the Builder the Builder picks transactions from the public member as well but they might also have access to um to other sources or transactions what we call a private mempool and then this block is passed through a relay and then to the validator so here we have two additional entities the Builder and the relay hook and sensor and this model is much more important to look at if we if we want to talk about censorship because 95 of all blocks are produced using this way today this mechanism by the way like this PBS
proposal Builder separation um now we said earlier value data set very decentralized but so that might be safe but let's look at the Builder and the the relay how decentralized are they it turns out they are not very decentralized at all for the Builder for example we have only two entities which make up 50 of all blocks and four entities produce more than 80 of all blocks and very similar picture even a little bit worse on the relay side um so now the question is do the sensor and we can look at the mempool and see if they if these entities include transactions that they should and it turns out
um that most of them or many of them do not so 65 of our oil Builders sends some transactions and 35 of our relays um which is yeah an arguable problem um how many transactions are affected um it's about 220 transactions a week and they as a as a result they get delayed by 23.6 seconds roughly um censorship we could can call the censorship weak censorship because the transactions will get eventually included but only later when a block producer is selected that does not do this sort of censorship
um so why is it a big deal 220 transactions a week is not a lot if we look at the like the whole throughput of the network and 23.6 seconds additional wait time is also probably bearable for most users so why are we talking about this at all and some might argue it's not a big deal at all but um I think it is because um it's in um I think the first time in ethereum's history that etheros neutrality is like systematically uh compromised and also permanently compromised so it's not not something that went only on for a day but it's been going on for months and months by now it also shows that ethereum is vulnerable
um that may be the properties that we we claim ethereum has uh maybe not as safe as we we say and this might encourage attackers to look for uh um at more things yeah what they could do also I would argue that the victims of the censorship are actually the the primary users the most important uses of ethereum because those are actually the parties that are affected by um by yeah government um yep um like if you if you're not a victim of censorship then you might just use a bank for example and lastly one could say that um this sort of stuff like this local validator policies
are a slippery slope towards like more harmful activities for example if validators would not only look at their own blocks that they produce but also look at blocks that they attest to like if they would stop attesting to blocks that contrain these transactions that they don't like and then we would have like a much much bigger problem right now and at the very least I think it's an important and interesting case study to uh to look at I think it's also an interesting question of who's responsible some might argue that no one's responsible it's like um the protocol does not punish these sorts of um activities so it doesn't really matter the um the validators of
like if like they can do whatever they want basically um but I think that's not the right way to look at it because if we like take this a little bit further and take it to the extreme that if you would imagine that the value data set would stop including transactions at all then the protocol of course would not function anymore um um so I think it's like also these implicit rules that how blocks have produced should be considered part of the actual protocol um even if there's no enforcement of these rules at least not on the technical layer um so who is responsible I would say it's very simple like the people who have the power or the entities that have
the power which is like all the parties participating in this process the sensory Builders the sensor relays and the validators that pick the sensoring relays um but I think for the most part ultimately um I think it's most important to look at the valet data here because they have the ultimate power they can just um choose to they in the end put their signature in the under the block and also the validators are closest to the protocol which means that uh um like easier to address by the ethereum community as a social norms for example that we we basically that we can use to enforce these
non-protocol defined rules um and like the validates are mostly affected by by these rules maybe the bill doesn't do realize uh um because we're far away they don't um yeah they're difficult more difficult to address so what can we do about this um as I did earlier like the social norms I think are very important and we as a community should try to strengthen them let's try to discuss what we actually want them to do and then also um exert some sort of pressure and I think it's already we saw some very good signs um like there's already some like in the very beginning it was very bad but now we have some relays who are not
censoring and they improve the the situation quite a bit so I think that's already working to some extent but maybe still do a little bit better also I think um there's still technical ways we can improve the situation one is to add inclusion in this to the protocol these inclusion lists are basically a way for the validators to enforce transactions to be included even if the Builder does not necessarily want to do that um and that would basically again put the whole weight of the value data set behind um the transaction selection mechanism and lastly something we are working on a shutter network is using encrypted mempools so um
if the [Music] um yeah if the if transactions are encrypted then the validator cannot or the Builder cannot distinguish between transactions they like and transactions they don't like so um the problem would be solved this is a very big step for a protocol it's a very large change to the system so it's probably not very likely that ethereum will take this step but um we implement this for Roll-Ups for example and for uh also we are working a little bit with the nurses chain um inside this where this takes a little bit lower
um just to show that this is also an option yeah this is basically all I have about um sensitive um but now I have to apologize because I want to talk about something completely different as well so I'm going to rock pull your attention in some way um I want to talk about a friend of mine who is new to crypto they it's their first crypto conference and they they need your help so they came from very far away from the the South Pole and it's a penguin um
they want to get to know all of you so they want to basically be embraced by the crypto Community they want to travel across the whole world like one circle around the world and visit like all the crypto events we have many events here in Paris but we also have many events like in the coming months and and weeks that this penguin wants to visit so um yeah I'm going to today I'm going to to show it to some of you people and at some point I hope I will give it to um one of you and maybe they can bring it to uh to another event maybe um I don't know where it's going next there's a website
um [Music] travelingpenguin.xyz it has an Instagram account if you make photos they like it very much and also to to help set this up I'm going to deploy a token and to have a publishes a photo of the penguin in front of some famous site maybe I will send some tokens to and whoever sends gets it an invite to an event get some tokens and whoever carries it for some distance will also get some so I hope we can maybe get like a community started to help this little penguin achieve their goal to see the world thank you very much
[Applause] I think we have time for some questions if you have I wanted to ask if you are if you're familiar with the implementation of censorship on the validators on the builders that do they do sensor and specifically how do they how do they evade the denial of service where you would send them transaction that does something that they would sense or but only after spending a lot of gas on execution uh yeah that's a very good question
um I don't think they have any protections against this sort of stuff um so in theory they are liable or like susceptible to these censorship attacks um but they in some way they already are so some of the builders for example they um have like this mechanism where you can send a transaction that fails and they still don't include in a block so that can also be used for denial of service attacks so I think it just works because it's a very centralized system so they can have a lot of Hardware behind it yeah the ones that are the ones that provide a service for a non-revealed like flashback protect usually do it only for specific accounts but here they have to do it for every they have to do it for every sender so basically if we flood the mempool with
the if we flood them probably the high gas transactions that do this I don't think sensorship will be very scalable and they could scan they could sensor EOS but nothing beyond that I think that's very interesting yeah that could actually work also because I think they detect um like they go very deep they only not only look at the receiver they look at basically the whole call stack um so that is very costly to analyze might be interesting to to try it of course it would cost some gas though there's a way to make it cheaper but we can talk later yes I would love to I think we all have time uh but yeah thanks for your attention and see you later
[Applause]