DAPPCON 2024: RPC Centralization In Web3 - Viacheslav Shebanov

Transcript

today I want to talk with you about RPC centralization and what it means for our industry so just to introduce myself um my name is Slava I'm CTO drpc and we're building the centralized RPC infrastructure for the multi-chain future so you know what's RPC again maybe you haven't heard about it but if you haven't heard about it you probably heard about blockchains and if you know blockchains are PR probably like it's just you know a fancy way to synchronize State between different computers um in a decentralized and permissionless fashion but the most important stuff in blockchain is a state so if you're building any kind of uh dab or web fre application you need this access this state so typically uh each blockchain client have some kind of API that allows

you to Creer this state and why do we call this RPC because it's like API well historically ethereum and Bitcoin went with Json RPC protocol and the trim kind of stuck so originally of course everyone imagined that if you want to write your own Dap You would just run your own note and like this is a perfectly decentralized way to do stuff however uh we live in 2024 and this is a multi-chain future uh where like running uh if you're support like 30 protocols running all the blockchain noes is just not feasible it's too expensive and basically Nobody Does that so uh naturally a type of company appeared

that we call right now RPC providers that are basically typical software as a service company web to web software as service companies so we're building decentralized web on top of centralized software as a service company but temporarily right well let's try to think about it and first let's ask ourselves a question what do those RPC customers clients want well they of course want good user experience and developer experience high speed high reliability and low cost so what what things they don't want they don't they actually don't want decentralization and they don't want fancy technology with bad developer experience and it's understandable because you know uh we talking about web three companies they

have their own customers uh and they should care about them and you know they can't say you know last day we were down for 3 hours because of our PC provider but you know it's centralized uh their customers will probably go to their competitors that can probably use centralized providers so uh centralization on RPC layer is a status quo it's not because we are bad industry or bad people it's just because it's the most efficient and easiest way to achieve desired properties that customers want okay but why would we even want decentralized RPC uh and let's try to be honest about that well maybe user experience and developer experience

for so decentralized rpcs is are is better uh you probably know the answers uh that decentralized rpcs uh historically perform in terms of user experience uh very bad and centralized rpcs and in general centralized applications have better ux and DX okay so that's not it maybe they have better reliability well there is an argument that we I mean the centralized RPC providers are kind of running for a while right now uh that we decentralized RPC providers don't have a single point of failure so we're more reliable but unfortunately every decentralized RPC provider I know also runs centralized Gateway so it's kind of you know effic

effectively the same thing that was centralized ones uh again it's not because we want to lie to you it's just because uh everyone want wants good developer experience and it means they just want to copy paste the link uh from your website and that's why we need to centralize gateways okay so maybe decentralized RPC providers have better performance again uh you could argue maybe that in decentralized protocol you can have on board like uh a lot of projects from all around the globe have better latency but I would argue that centralized providers can do it too uh can have servers everywhere and in theory they can even reach better performance than decentralized because

they control everything they control Hardware networking and then uh can uh build a setup that is in theory more performant than the centralized one then there is verifiability uh it's a common argument in the discussion between uh centralized with decentralized RPC provider and uh the core thing is that when you use some kind of RPC provider you kind of trust them uh because you don't have any means to easily verify their response so nobody cares a lot about that until of course something bad can happen for example one day you go to some you know very important project very important

vote and uh in this in this moment RPC provider decides to temper with the data and for example change the vote typ uh voting title and you can end up voting for the thing you don't understand on don't agree with there are a number of ways how you can uh protect yourself uh first and obvious one is light clients so light client is a super efficient node that you can run on your phone run on your uh in your browser and you basically can use it as a you know RPC node your for your dab you connect to this light client and this light client connects to RPC provider but it do does some fancy stuff that allows uh it to verify each RPC provider response so you

kind of protect it from this tempering uh there are existing Solutions right now for ethereum both two of them are Kevlar and helus uh however there are a number of problems with them first uh as I said like when you send a request to light client it translates um your request probably into several requests uh and this will be more expensive for you it will take more time um and so it a lot of uh a lot of applications do not want that also of course uh not all requests can be verified this way and the last thing is not all the blockchain support like clients ethereum does but many more don't you can imagine some solution using ZK magic probably you can imagine

that our RPC provider can send uh the ZK proof uh with along with response and you can verify it however technology is not yet there it's computationally INF feasible and I struggle to imagine how it can be done universally across all blockchains and the last one Quorum check you kind of can send the same request to different RPC providers check if they agree with each other and if they do probably their response is correct so you can see all of those three um ways to battle this verifiability problem uh however it doesn't matter whether you work with decentralized or with centralized provider uh it works either way you can argue that in decentralized setup you kind of can punish the providers who can

who try to lie to you however you know it's not really important in my opinion so far things don't don't look good for decentralized RPC providers so what about cost efficiency and I would argue it's cost efficiency is really better for the centralized providers um there are several reasons to that first is that uh when you have this decentralized RPC provider there's a so there's basically a protocol and there's protocol participants node Runners who run their like noes for you and uh participate in the protocol and they can squeeze more juice from their setup because for example they can participate in several protocols uh simultaneously and use different resources for example

they can have their server can have GPU CPU and they run you know the node participate in graph indexing and maybe some you know GPU sharing stuff so the second one is if you have any kind of price auctioning inside a protocol uh you can have significantly more efficient price Discovery mechanism because like all all of those node Runners will compete with each other uh yeah the centralized providers also compete on price however the problem is that that's there are not a lot of them uh and uh the thing is that it's not always about price there's General stickness to the platform there's BD there's marketing PR all that stuff so the pride Discovery mechanisms will never be as efficient okay so what about multichain

does multichain better for uh de centralized RPC providers yes uh the thing is that when you are centralized RPC provider and you want to on board new blockchain you need to first run some servers uh or buy them buy them then you need to learn how to run this new blockchain stuff and then you need to add some code to maybe to your ux and your load balancer to support the new protocol however in the centralized RPC provider we just need to support this protocol on load balancer level and that's it and then we can find some people who are already running those noes and or you know at least know how to run them or at least have some spare time to learn it so that's why this is why we were able to support 63 I think

blockchain ch right now uh far more than any RPC provider on the market right now and the last and most important thing in my opinion censorship and you know censorship on RPC lar is not unheard of we've seen instances of that already but I'm I argue that it's getting worse so there is a paper from recent paper from legal a group of legal researchers uh that uh are you know they want to provide framework for battling illicit uh flows elicit activity in defi and they argue that you know in uh trefi uh battling elicit activity is all about intermediaries so you can Implement some measures on intermediaries and if control intermediaries you kind of

control uh illicit flows and they uh correctly identify that RPC node in D is the ultimate inter intermediary all read and write requests go through it go through it so you they Define CCT critical communication transmitter the basically every commercial RPC provider should should be CCT and then you can require them to implement risk management practices and procedural reasonably design to help mitigate elicit Finance activity in ways tailored to their operations which is basically Implement sensor censorship mechanism can it work well uh first I must say that uh battle and illicit activity in defi is a noble goal however imagine there's a hacker and they want you know they stole some money from the protocol and they need to send few

transactions would it be hard for them to run their own note or find uncensoring note I would argue no but if you're a big Dex or a big web fre uh application it could be hard for you to you know mitigate this regul this like censorship so you have kind of would have uh three options run your own notes uh use unre related providers or submit to censorship and we know like we previously talked that running your own notes if you support 30 blockchains is not viable it will probably kill like uh uh all most of the project that will try to do that so uh so then there's only two options running unregulated providers or submitting to censorship and uh it's hard to say how it will play

out however remember in RPC Market uh everything is about you know performance reliability uh stuff like that so Market leaders who excel at this they will probably you know comply immediately so you are left with those who are worse in many ways privacy security all that stuff will be worse worse for the unregulated Prov providers uh you can compare with uh this with for example free VPN situation where you know you can use free VPN but they will gather data about you and sell to someone sell it to someone uh so maybe the only one the only way will be just you know some buiness censorship and again for regulated uh for C centralized providers there's actually not a question to comply or not they will eventually

comply uh maybe like just comply or seiz operations in uh country of regulations however for decentralized providers it's a little bit more complicated remember there are node Runners and they can decide for themselves and you could argue yeah but you have centralized Gateway and if it uh it will Implement censorship like uh doesn't matter however if you have a community of nonr Runners uh unified by a protocol you can have multiple gateways some of them will be censoring some some of them will be not and you can compare this to situation in ethereum uh block you know transaction censorship you you kind of it's enough to have uh a small fraction of non- censoring mavet non- censoring

uh block producers uh to uh non-compliant transaction to pass through so it will if we will have at least 10 20% of node Runners and uh gateways uh to be non- censoring uh those this will make those regulations inefficient okay so let's look at everything we discussed so far so if we're building decentralized uh RPC provider we probably have better cost efficiency we have better multi-chain and of course we have censorship resistance uh verifiability goes both ways and uh for centralized providers you have better uxdx better performance and better reliability and if you remember what I was talking in the beginning uh centralized providers are actually winning hard so uh if we don't

do anything we have a future with extreme centralization and censorship mechanisms so what can we do about it well the real question is can we get everything can we get both best of the Both Worlds censorship resistance from the centralized world and good metrics from centralized world that's what we're exploring at drpc so our goal is to understand whether we can build a decentralized RPC provider that is on par or better than their our centralized counterparts that's why we for example uh focused more on the Gateway we saw some project that already built permissionless decentralized Pro U node Runner set and we know it's possible to do that however uh we invested so we

decided to invest more resources into centralized Gateway that will be able to offset individual provider problems uh optimize latency reliability stuff like that and I would say that we have a pro of the concept working and we were able to on board a lot of cool projects like sushi swap instad up Lio and many more and they all choose us not because like we're decentralized and we gain some points from it it's just because we're better or at least uh in some ways better than their previous RPC provider so uh so yeah uh now our goal to understand how we can push decentralization even further uh but we don't want to do it you know just for the sake of decentralization we want to

understand if it's possible to push decentralization further without compromising quality of service because in my opinion the only way um we can have a future with truly decentralized web running on truly decentralized data layer is this way so we're trying to build this feature uh at drpc and if you want to check it out go to drc.org if you want to follow our Twitter account you can scan the QR code and that's it for me if you have any questions I'm happy to answer