Ethereum Stability Improvements: Censorship-Resistance

EthCC[8] · 30 Jun 2025 · 19:40

Viacheslav Shebanov examines censorship resistance as an Ethereum stability requirement. The presentation discusses current weaknesses and practical approaches to strengthening the network.

Speakers

Topics

From EthCC[8], hosted by Ethereum France.

Transcript

Okay. Hey everyone. Uh yeah, today I want to talk with you about Ethereum censorship resistance. And just to introduce myself, my name is Slava. I'm CTO gRPC.org and we're building robust RPC infrastructure for the multi-chain future. Anyway, when we talk about censorship in the you know Ethereum context, we typically man mean that censorship is some kind of transaction blocking like validators preventing transaction landing in the block or something like that. However, in my opinion, it's actually u too narrow. We should define censorship more broadly and we should talk about it as you know suppression of information flow and there are a lot of externalities that actually can influence Ethereum in this

way. Let's first uh look at the few examples uh that are about censorship sorry examples of censorship. Uh first I want to talk about bybe hack and probably a lot of you remember that recently there was a huge hack a lot of money was stolen. It's probably was where North Korean hackers and uh there were actually a lot of instances of censorship like their uh stable coins were frozen. some bridges and services try to prevent uh money laundering and the question is like is censorship good now? Uh because if you try to argue otherwise the the some of your opponents will say do you want uh North Korean hackers to stole money and launder them to build nuclear weapon and probably it

will be very hard to say you know yeah I support I I against censorship. So the other uh example I want to share is tornado. Obviously many of you also know this. uh at some point uh tornadicash was sanctioned but by US government and uh at that point a lot of different entities tried to censorship uh smart contracts and uh front end and uh the important thing here to understand is that not only tornadicash was censored itself it's also everyone who tried to use it and were like couldn't or at least they had some issues with that were censored as well and uh the last example actually is not from crypto. I

want to share with you the case from Russian internet. Uh in 2018, Roscom Nazor or RPN uh it's a Russian internet regulator decided to block Telegram. Probably a lot of you use Telegram right now. And the problem is that they didn't have a sophisticated enough tools to block Telegram right away. So they started bashing a lot of IP addresses, eventually banning 18 million IP addresses in Russian internet, disrupting Russian internet for several days. uh a lot of money were sto lost and a lot of businesses couldn't function and that was like the case when censorship actually is not just about censorship it's just about stability so in my uh presentation I I want to

distinguish two types of censorship first is targeted censorship which is when you try to censor individual or group of individuals but the key idea is that when it's individual sens like targeted censorship you kind of can't expand the censorship a list of censorship entities too quickly. It's very hard. For example, in bybit hack example that there should be some social broad social consensus to do it and it's hard to replicate. uh all other types of censorships are for me are blanket censorship and it's when you know you can expand censorship uh list very quickly like in matter of seconds or uh even or hours and uh my hot take would be that targeted censorship actually debatable whether we want it or

not and we should have this discussion because like if we won't uh blockchain industry will mature and there will be more and more question from states and different regulators to our industry like how do we how do we strike down the North Korean hackers? However, target censorship is un blanket censorship is unacceptable and not only not only because it's good or bad, it's because it's stability threat. It can bring down the thing that it basically censors. So, as I said, censorship is a broad thing and I want I would like to look at the Ethereum censorship resistance and at all of those layers. However, I only have 20 minutes. So I had to I I have to go down uh very quickly. So first of

course internet and there are actually a lot of interesting things about uh you can do on the internet level to for example censor Ethereum. However as I said I don't have time but the gist of it is just it's uh it's solable you can internet is a huge place you can hide you can blend in uh it's possible to resist uh internet censorship. then consensus layer and it's actually uh there are some problems many of you know I think there are some presentation about it right now or like this this this year at least but uh it's basically solvable uh the idea is that there is some algorithm or like trick like inclusion lists or some uh enshrined proposer builder separation that will help us solve censorship on those on

those levels um at least like most of it. However, then uh if you're uh looking from the perspective of the users, then after decentralized consensus, there's some kind of software as a service company that is called uh typically RPC provider and uh user uses front end deployed on AWS to and this front end asks data from this software as a service company u to basically interact with Ethereum. And uh the problem is that when uh something happens and FBI comes knocking for those centralized companies, they will censor.

They don't they will have options go to jail or censor and the choice is obvious. Uh so we we don't believe we don't believe them. And if you think that it's some kind of you know uh just targeted thing about uh some investigations targeted censorship uh actually it's not. For example, last year on HTC, there was a presentation about this paper uh that basically proposes some kind of very very well- definfined and very systematic uh way of censoring on RPC layer. Uh it's kind of a lightweight bank secret bank secrecy act that will force all RPC providers that need to comply to score your

wallets uh to uh to block suspicious activity, to log all the data, you know, all the good stuff. basically implementing uh mass censorship uh mechanisms and how can RPC providers censor you basically two two ways read uh right and of course if I don't know if you know but when you send a transaction you send it through the wallet but the wallet typically use some RPC provider and the thing is for example for meta mask you can change it but for most of them you actually can't change so if for example they use censoring RPC provider um RPC provider can deny your transactions And also there is a read uh before if you go to unis swap and unis swap and you want to make a transaction first you

need to read a lot of data from the blockchain to build the transaction itself and only then you can sign it and of course those requests can be denied as well and the question first question can censoring RPC stop by bit hacker and the obvious question is no it can't uh sufficiently sophisticated actors will run their own nodes no problem the long answer yeah there are some possibilities you can make actually it harder. You can maybe catch some guys uh and also if they run their own nodes it it uh creates additional digital footprint.

There are some attacks that allow you to deanimize Ethereum uh node that actually was origin from which uh transaction originated. However, as I said uh after a few times they will learn and uh it won't work. However, can it used can it be used for blanket censorship? Of course, it can. For example, imagine uh your favorite tax was sanctioned by US government and now all sensoring RPC providers do do not work with uh with it. So, uh maybe they will find some non-sensoring RPC provider and uh it the front end will work but it will work you know slowly, more errors, more latency, it's kind of bad user experience. And

also don't forget you need to find a a wallet that will support non-ensoring uh RPC to send the transactions. And of course it's the kind of the same story as with VPN. You know if you have some blocked website you yeah you can use VPN to access it but uh obviously it's easier to use just alternative. Uh and this way we can basically censorship out of existence any project we want. uh and even if there is for example a project that does something unique like tornado tornado cache and you will find a non-sensoring wallet and you will find uh the front end with non-ensoring RPC and you send the transaction after that

for example in few days you will go to your favorite decks to to buy more meme coins I don't know and uh nothing works nothing works because now your wallet is tainted uh because and now RPC sensoring RPC provider actually scores your wallet and said, "No, it's it's probably a hacker. I will deny the service." And uh you kind of shadowbanned, you know, this kind of dystopian future social rating RPC provider layer. So imagine uh you know this great instrument in the hands of this guy or any crazy regulator out there. It's actually I would I would say it can bring down web 3 completely.

So the obvious question uh decentralized RPC. Yes. uh and there are some projects that are at least claim to do it like pocket network or lava network and my hot take would be that decentralized RPCs are dead and DRPC maybe you've guessed that D stands for decentralized we've been trying to do this for 3 years uh in a way that is not kind of ideological project but commercial and uh at this point I I think this it's not possible there are two things why it's not possible first we need to understand who I users of RPC. It's commercial companies who run their own projects having their own goals, own clients, and they actually don't care about

decentralization. And for a good reason, they are not bad just because they have a lot of on their plate, a lot of problems they need to solve. They can't bo be bothered by supply chain decentralization. It's it's hard enough for them. So, they will evaluate your solution based on very simple metrics like reliability, cost, and latency. And if you if centralized alternatives will have it better they will go to them. The second uh the second problem is imagine you work with this decentralized RPC provider and some at some point there are some errors. So what who you going to call what what you do it's decentralized. You will go to some discord room to ask community for like can you help me please. At the at the at the same moment when your clients you

know uh write you angry messages uh asking you to you know revive your project like nobody wants to deal with it and most of them want just 24/7 support and they will go to this uh support line and fix the problem. So in my opinion, it's kind of those two reasons why decentralized RPCs I I don't know in my opinion are impossible. So the the answer may be run your own notes, but yeah, you probably know the answer. At this point, we see no signs of it being kind of widespread practice and I don't see any future where it it happens, especially with the L2 explosion as as of now. It's just

nonviable. So in my opinion there is actually no solution in a sense like inclusion list sol uh solve the you know build your censorship problem. However like we have the only thing we can do we need as much RPC provider as possible and uh you know we need a good uh d go diverse set of you know different RPC providers with in different jurisdictions. So in case this regulation applies there will be al always some RPC provider that that is in in another jurisdiction.

However we need to understand like if we want to understand can it be is it possible that RPC is commodity. It's like electricity everything sells the same stuff. So JSON RPC is standardized u there is no different uh the product is the same for alchemy for DRPC and for any other provider. And the second thing that it's hard to enter this market. Uh it means that you know you need to invest a lot of resources. You need to build a lot of stuff, hire a lot of people sales marketing developers devopses, infrastructure. You need to buy a lot of servers and you need to buy them cheap because nodes are not cheap.

So for typical uh typical commodity market it basically looks like that. There are three stages. Uh first is called race to zero. As I said uh you all sell the same thing. So the only thing uh to distinguish yourself from competitors is to just drop price and everyone does it for a while until there are some big players emerge and for them uh economy of scale starts working. So basically it means that uh they for each the more requests they have the each individual request will be cheaper and they will have more money and they start buying smaller players and this consolidation phases continues for a while and after that oligopoly emerge uh some oligarchs emerge they control the

market control the prices control the quality they control everything and good examples would be for example US airlines I think it's now more expensive to uh fly in America than it was in 70s because there are only four US domestic airlines right now. The same kind uh similar example would be CDN cloud uh cloud provider markets and there are a lot of a lot more examples. So and if we look at the RPC uh market right now uh there is like uh 70% of uh market is controlled by four uh entities and uh you know it's not working. So what can we do about it? So we can

basically do two thing. We have we can have more ideas how to um you know decrease the barriers to enter the market and we can h like do it easier to swap the provider. So first is of course uh how to the idea how to enter the market easily more easier it's the our DRPC idea it's basically modularized. You have two types of companies. You have node providers and you have front ends. And uh front ends doing all the stuff that decentralized RPC provider can't do. Support, sales, marketing, all that stuff. Uh node providers are actually kind of uh those native web3 blockchain companies that uh are

responsible for infrastructure and it's already happening. As I said, DR DRPC is um basically doing it right now and we we're doing it from the start and I could tell you that right now we are top five RPC provider. uh we do 50% of volume of uh alchemy or quicknote and we have less than 20 people uh technical team and less than 30 people sales team uh with sales and everyone else and uh yeah so there are we are not alone growth another project that uh are is built on top of uh pocket network uh node runner set and of course maybe you've heard about infurine uh they I think they quietly moved to the same

direction as previous two and there are a lot of of course um listed some of the projects that are you know those actually very interesting breed of web blockchain companies uh which are focused on infrastructure they work with us they work with laido for example with the graph protocol and uh you should piggy back on them it will uh cut the costs and the second easy to easy swap first we should uh we should have all the libraries is supporting uh fallback logic. So you wouldn't be able you you would be able not to use one uh one provider but several. For example, kudos to VM.js team that already I think one of the first who did it. But if yours if

your library doesn't support it uh there are some smart RPC proxies. For example, we maintain the shekele for several years. There's ERPC uh on the market you can use. So if your library doesn't support it, just use them. And there is a lot of nice things that you can you can actually save money. You can incre uh improve latency uh and uh say sometimes like do some other stuff that will help you. Uh and the last thing to to be able to easily switch is pay as you go. When we started pay as you go for RPC providers uh was non-existent. I think we were one of the first who did it. And right now Alchemy recently changed their pricing to reflect the same as we do. They are now they are now

having uh pays go tariff which is great because it doesn't lock you for first it doesn't lock you for a long time uh on a contract and the second it uh even if you have several RPC providers it allows you not to burn money for having a fallback which is also very important and we also build a product building a product uh smart RPC proxy right now uh if you want to you know have look more at it you can go to this uh URL. But if we do both of those two things, we can have this future. There's basically polyarchy. A race to zero happens uh still. But because there is um easy swap those companies won't be

able to uh like the big players won't be able to burn the market basically for example going below profitability level until the you know oligarchy emerge after that after which they potentially can increase the prices and also if it's sufficiently easy to enter the market uh they also don't do not have incentive to burn the market with the prices. Um that's that's that's our goal I think and also you can help uh if you're building any kind of decentralized uh application or web3 application that uses RPC please just use several RPC providers uh it will help you because it will make your uh application more stable and uh less prone to RPC problems

but you will also support competition and I think we should all do that because otherwise we have a quite dystopian future with RPC regulations. So my small takeaways is that first blank blanket censorship is unacceptable and we we should you know not take it lightly. Um and RPC layer right now is highly v vulnerable and very centralized. So please keep the good fight, keep this keep help us keep the the decentralization and you know be safe. Uh if you want to check out DRPC gopc.org work. If you want to follow me on Twitter, you can scan this QR code.

And that's it for me. [Applause] [Music] [Music]