New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

RPC Centralization in Web3: Balancing Efficiency and Decentralization | Viacheslav Shebanov - dRPC

Ethereum DenverWed, Oct 9, 2024, 12:00 AM

APPLICATIONS FOR ETHDenver 2024: #YearOfTheSpork ARE OPEN APPLY NOW https://ethdenver.com/apply

Transcript

Insurance yeah hey guys uh yeah let's talk a little bit about problems that we have in web3 and today I want to talk about like RPC centralization and what it means for web fre yeah so I'm Slava I'm CTO at drc.org and we're building uh decentralized RPC infrastructure for multi-chain future so let's start from the sorry let's start from the basics like what's an RPC uh you've probably heard of blockchains and if you know what's blockchain it's basically the you know fancy way of synchronizing State uh to multiple computers in a decentralized fashion but the important stuff is the state and if you're building web free applications uh web web three applications need onchain data though so they need to access this state and each typically each blockchain client will have some kind of API to do that so yeah uh and why it's called RPC well historically uh ethereum and Bitcoin they decided to go with a Json RPC protocol uh and we kind of Now call this you know all this blockchain IPI rpcs which maybe not the best name but yeah we still use it and uh historically uh the vision was that if you want a data on chain you you kind of run your own note however it's 2024 and we live in multi-chain world so if you're building some web three a you probably need a lot of blockchains and it mean it means you need a lot of noes H and it's very expensive and it's very hard so basically Nobody Does that uh so there appeared a number of companies that are call we call now RPC providers and yeah we kind of run web 3 decentralized uh web on top of web to centralized software as a service companies but temporarily right well let's think about it and the first step would be let's think about what clients want I mean RPC clients uh and those clients uh clients are web three companies that are basically businesses too so they have customers also and they want basically four things they want have good ux user experience and developer experience they have high they want to have high speed and good reliability and of course they want cost low cost cost efficiency what clients don't want well uh yeah actually I must say that this not like we invented it we talked to hundreds of customers and they all said that uh but what they don't want they don't want decentralization and they told us specifically that they don't care about it a lot of them uh and they don't care about fancy technology with bad ux and actually that's understandable as I said they are businesses they also they have their own customers then they can't you know say their to their customers sorry guys we were down like 3 hours but you know we use decentral decentralized providers uh because customers they just will go to their competitors and you know uh who use centralized providers maybe so that's like what we end up with centralization of RPC providers is St status quo and we arrived that not because like we're bad people or bad industry it's just you know econom economically ible to do that and it's reasonable so like let's think about what why would do we need decentralization on our PCL layer at all like and let's be honest about that because um I must say decentralized like providers not always honest with you I'll try to be so first uh is decentralized providers have B better ux or DX the you probably know the answer no uh decentral historically centralized providers like infu or Alchemy have significantly better ux than you know uh decentralized contrap parts so that's not it maybe decentralized providers have better reliability uh and you know we're running kind of this argument we I mean decentralized provider RPC providers for a number of years that uh yeah you know decentralized rpcs don't have a single point of failure but the problem is unfortunately every decentralized provider like I everyone I don't want to call names runs centralized gateways and the reason is specifically the previous point that you need a good Dex developers just want to copypaste uh URL and just work with it so they don't want you know your fancy stuff and you kind of end up with a centralized Gateway and yeah so you're not that different from centralized providers and now if we're like thinking about other things of course centr providers like Alchemy or infura they don't think about decentralization so they have time to think about their customers and historically of course the reliability of those providers are significantly better than on for their decentralized counterparts okay but maybe performance for decentralized providers is better uh yeah you could argue that you know the the there's like a lot of compute a lot over the world the G distribution for decentralized providers would be better however I can argue that everything that decentralized providers can do centralized can do too and actually as I said previously because they think about customers a lot a lot more times uh they historically have the best uh the better performance significantly and in theory they even can have the best performance possible because they control Hardware they control Network they can uh provide the best setup possible okay uh there is another argument that you can hear a lot with this all centralized versus decentralized uh like discussion it's verifiability the problem when you use RPC provider you kind of trust them you know uh you don't have when they resp respond with some data you don't have any way to check if it's valid uh yeah and of course nobody cares about that yeah and nothing bad happen you know and no of course like how here how it goes Nobody Cares until some something happens like you know some kind of Black Swan event and maybe one day you kind of go to some voting platform that uses this RPC and maybe this a vote for very important protocol and that's very important vote and that in that moment provider decides to temper with your data and you could could end up voting for something you don't understand or don't agree with how can you protect us ourselves well there is a solution it's called like clients so the light client is a kind of super lightweight efficient node that you can run on your phone and it actually talks to the centralized for example RPC provider and only syncs the state that it your web application needs so you could uh and it it can do that in a trustless way so it can check everything that RPC provider returns so if it provider will try to temper with the data um light client will detect that and you can kind of use this light client as your RPC node and you know if you have a wallet for example it's a reasonable way to do that uh to reasonable reasonable way to do verifiability for the RPC and for ethereum there are actually existing Solutions like Kevlar or Helios that can you can use right now however there are few problems with that uh first is that actually this stuff is very inefficient because for most of the time for each call to the light client light client makes several calls to centralize RPC provider for example and it will cost you more money and it's it it's slower just slower uh also unfortunately you can't verify all requests using this approach and uh moreover not every chain supports light clients ethereum does albate not like in full like there's still ways to improve it uh but a lot of chains do not support it at all yeah so of course we can IM imagine that there's be can be kind of ZK magic and wouldn't it cool if every RPC provider uh return uh ZK proof that the data they return is valid are val is valid so yeah you could probably imagine that technology is of course not there uh and I would argue that it would I it's hard to imagine how it can be done like you know universally multi-chain verifiability through the ZK for RPC responses however yeah theoretically it's also possible and the last one you can do you know basically Quorum you can send request to several providers and compare the responses if the responses are the same well you can consider this uh response valid uh it kind of doesn't matter if your if those RPC providers centralized de centralized uh you can do it boss ways you could argue that in the centralized setup you can punish providers that uh return invalid data but really doesn't matter uh so yeah so far looks not good for decentralized pro providers you know uh yeah maybe cost efficiency is better for decent decentralized providers and that's where I would argue that yes decentralized providers can achieve better cost efficiency there's two reasons to that first uh in decentralized RPC providers uh typically you have some kind of you know independent node Runners that uh this decentralized protocol uh roads requests to so uh there are a lot of of them and they of course are quite efficient in what they do and if you allow them for example to set their own price the disc the price Discovery mechanism would be sufficiently more efficient than for the centralized providers because centralized providers of course compete on the priz too however there is you know PR marketing stuff and also uh yeah it's not that it's not too much of them so the this price Discovery would be less efficient sign like forever basically and uh the second part of that is uh those node Runners they can actually use nodes in different ways and they can exploit like they're running the node this this node they run not only in for example drpc they can uh use it for graph index like par participate in some protocols and other stuff so there I I argue that decentralized providers if done correctly can be significantly more cost-efficient and that's actually what users do want yeah so what about multi-chain maybe multichain is better in decentralized setup yeah I also think that it is and the reason is very simple because when you're are centralized provider and you want to add new chain for example you know super roll up L3 or something like that uh you need to First add some code probably to your balancer Gateway you then need to buy new servers and then you need to you know acquire knowledge how to run those new blockchain clients for decentralized providers uh you just need to know write some code and find right people who already have this compute or they just know how to run those clients so it's easy for you so for example that's why we are supporting right now 60 blockchains I don't think there's RPC provider centralized or decentralized uh like we in that sense yeah and of course the most important thing uh and the ultimate boss is censorship and we understand that of course RPC censorship is not unheard of you know uh we've heard we've seen this with tornado cach that RPC providers censored transactions and read calls to the tornado cash contracts so it's like real but I think it's getting worse because recently there was a paper published by a group of legal researchers that actually uh suggest the protocol the framework for battling illicit actors for in Dy and what they do uh they argue that in treaty it's actually you know the like intermediaries is basically you know the ultimate uh way to battle illicit actors you kind of can Implement some measures on those intermediaries and everything kind of works so uh those legal researchers uh were smart enough to point out that RPC nodes is actually ultimate ultimate intermediary in defi world so if you implement some kind of censorship here you could probably censorship defi so they Define this CCT term critical communication transmitter basically they say that every commercial RPC note provider is CCT and then uh you can require them to implement risk management practices and procedures reasonably designed to help mitigate elicit Finance activity in wayte tail through their operations so basically Implement sensorship mechanism for RPC yeah can it work actually I was thinking a lot about that and I think battle incit activity in Def is very Noble goal however if you're a hacker like would it be hard for you to run your own note would it be hard to find some uncensoring note if you need to run only one transaction yeah I doubt that however for example say we can we would like to uh censor specific decks yeah for decks to BU the censorship would be quite more like complicated they would probably have some kind of these options you know they can run their own notes uh or they can use some unregular unregulated providers or submit to censorship basically and we know right now that running their own notes it's just not possible it's economically unviable and probably if they try if web free applications would try that most of the businesses will be killed by cost and complexity so in reality is if such uh regulation would occur unregulated there's an option between unregulated providers and censorship and it's hard to say how it will play out however uh remember in RPC Market there's everything about efficiency you know quality latency and uh reliability and I would argue that leader Market leaders would comply to those regulations immediately so the ones who are won't probably worse and in in many ways like not only this qualities but also security privacy you know the situation with free vpms basically can be can be the same thing so it would it's easy to imagine that uh in future like if uh this regulation occurs like basically both uh the only option would be to submit to censorship and that's it and as I said for centralized providers the choice is to comply or not is actually not a choice you know they have to comply however for decentralized protocols it's actually quite more complicated the reason is because there as I said there is node Runners and each node Runner can decide for themselves you could say but you run centralized Gateway yes but if you have a community of node Runners that is actually unified by some kind of protocol yeah you have centralized Gateway but you you can set up more centralized Gateway it's easy it's just code you can run it so each centralized Gateway also can choose like sensor or not sensor but the quality will still be good if we have like could be good problem so uh I would compare this to you know basically sensoring transaction on ethereum yeah you have you have a lot of compliant actors but you still need like a small amount of a small amount of number like of non-compliant like MAV relays or blog Builders validators and and non-compliant transaction will go through the same will go with RPC market so if if we have this decentralized protocols we Pro those regulations will probably be inefficient so let's look at everything we talked about uh if we build a decentralized protocol yeah we have cost efficiency we quite feel uh ourselves quite good in multi-chain world and the more most important we are censorship resistance probably and yeah the centralization is actually the only way to battle censorship we know of verify AB ility kind of irrelevant it can be done either way of and centr centralized solutions they have better uxdx performance and reliability so if you remember the first part of my talk you see that kind of centralized providers are winning the race you know and if we don't do anything the future is centralized rpcs with censorship mechanisms can we do something about it well the the question is can we get everything can we have both so Des properties of decentralized providers and centralized and that's the thing we're trying to explore our uh explore at drpc that's why we ran with permissioned pool of providers and we because of that we were able to uh invest a lot of our time because we didn't have to build uh have to build uh you know this blockchains permissionless join all that hard stuff staking we were able to invest a lot of energy if in in our load balancing uh load balancing technology that allows us to offset individual provider problems and optimize latency and reliability so because of that I would say that we were able to on board cool projects like curve instad up Sushi swap uh Lio and many more and we the next the next thing for us is to think whether we can push decentralization even F further but we don't want to we want a balanced approach we can't we don't want to do decentralization just for itself we want to find this balance where we can do decentralized stuff but also with good qu quality and I personally think that the only future where we can have a decent truly decentralized web built on top of decentralized decentralized data layer is looks basically like this like that uh yeah without censorship so if you want to check it out we're trying to build its future so if you want to check it out go to drpc if you want to participate also go there and if you want to follow our account uh that's a QR code so thank you for your time have a nice day I hope it was interesting yeah so that's it any questions yeah

Automatic transcript — names and jargon may be misspelled.