dRPC | The future of web3 data layer is centralized? - Viacheslav Shebanov | ETHDam 2024

[Music] okay hello uh in my today's presentation I will try to pose a question if the future of web 3 data layer is centralized and first let me introduce myself my name is Slava I'm CTO drc.org and we're building uh decentralized RPC for the multi-chain future so maybe you don't know what's this mystical uh web 3 data layer but maybe you've heard about RPC or even if you don't haven't heard about rpcs you probably heard about blockchains so yeah if you heard about blockchains you probably know that uh blockchains are basically a fancy way to synchronize state state in decentralized fashion between different computers so the real like core value of every blockchain is its state and if you're building web free application you have to you know access it somehow so typically every blockchain client have some kind of API uh that you can query so why is it why is it called then rpcs in our industry well historically ethereum and Bitcoin decided to go with Json RPC protocol which you example of the query you can see on the slide and you know the term sticks it may be not the best word to describe uh blockchain apis but you know uh we kind of using it right now so I'll I'll use it in my presentation as well so uh historically of course everyone thought is for example You're Building ethereum wallet and how could you access this state you would just run your own note and everything would be in this perfect cool decentralized fashion no censorship no no nothing everything is perfect however uh it's 2024 and we kind of live in multi-chain World it means if you're building a serious web three application you probably need several chains maybe dozen of chains so you have to run dozen of noes and it's just too complicated too expensive and basically Nobody Does that so of course naturally uh the type of company appeared that we called now RPC providers uh that run your nose for you and you just pay them money so this compan is a typical web to software as a service companies so we kind of building decentralized web 3 on top of centralized web two companies but temporarily right uh well let's think about it uh and first let's ask ourselves question what do clients want and we talked with hundreds uh web fre projects and ask them what would what do they want from RPC or web blockchain API API companies so first of course they want user experience and developer experience to be good uh they want a high speed high reliability and of course low cost but what they don't want first they really don't care about decentralization and they don't want to fancy technology with bad developer experience and it's understandable because uh remember these are we web free project they are businesses too so they have clients they have businesses to run they now have time to think about you you know yeah you know we were down yesterday for 3 hours but we use de centralized RPC provider uh because you know they their clients won't understand them they will just go to the their competitors who Pro maybe use centralized provider so centralization is a state of state of squad it's not because we're B bad industry of bad people it's just because you know uh it's the most most efficient and the easiest way to achieve uh the client's desires you know to provide this service with good reliability good performance yeah y so let's talk about why we why would we even want a centralized de centralized rpcs and let's try to be honest um this time first maybe the centralized uh RPC providers or decentralized projects have better uxdx you probably know the answer the answer is no historically of course uh centralized RPC providers and in general centralized Services have better ux and DX uh well maybe then reliability is decentralized RPC providers is better well there is an argument that we decentralized RPC providers been running for some years uh uh for you like that decentralized RPC providers don't have a single point of failure you know they're distributed but unfortunately every single one of the central RPC provider on the market right now running running centralized gateways so effect uh effectively there is no difference in terms there's always a single point of failure uh and again decentralized RPC providers do that not because we want to you know lie to you it's just because of the previous Point uh we want to have good DX and developers like uh they want to just copy paste a HTTP link and just you know uh be done with it uh so we have to have those centralized uh gateways uh otherwise of course because uh centralized RPC providers they tend to think more about their clients because they don't have to think about about all this you know fancy decentralized stuff they kind of historically perform better in terms of reliability uh what about performance you could maybe argue that because you know if you're building decentralized RPC providers probably you com uh connect to your protocol some ex external companies like that are distributed all over the globe and then your latency for example is better I I would argue that actually centralized providers can do everything that decentralized providers can do and because because they also have you know everything is controlled environment for them like they control networking hardware for nodes hardware for gateways they can do the best setup and best performance in theory so it all depends basically on engineering efforts of each team and but but in theory centralized providers even faser uh the common argument in this you know decentralized V centralized uh RPC is verifiability and I'll just you know talk about it a bit so you have a problem we have have a problem when um you build your web3 application you talk to the RPC provider uh you basically trust everything you get from them you don't have an easy way to verify the you know the response uh and you know nobody cares most of the time uh as every time you know nobody cares until something bad happens and for example you go some someday you will go to some you know voting platform for very important project very important vote and this time RC provider decides to temper with your data and you probably end up voting for some you know thing you don't understand or don't agree with and it can be a disastrous it can have a disastrous outcome however like we we haven't seen such cases yet uh but can how can we defend ourselves in theory so there is the obvious thing is like lines maybe you some of you heard about them but uh in essentially it's a very lightweight note that you can run on your phone uh it basically connect connects to some RPC provider nothing matter centralized de centralized and uh it verifies each call like each response so you then connect your dap node to this uh light client and use it as RPC like local RPC node um and yeah this this way RPC provider won't be able to you know fool you uh it's totally verifiable everything is like cryptographically correct yada yada uh and there are existing solutions for ethum for example Kev and Kevlar and helos are doing that right now however there are a number of problems first it's very inefficient uh every call to this cide client will probably translate to several calls to RPC providers so we will probably pay more and also it will be slower then not all calls can calls can be verified in that way and the last latest thing is that no not every chain supports like clients for example ethereum does but many many more don't do that okay then next we can imagine some solution with ZK Magic imagine RPC provider will return some ZK proof of validity of the data they respond with however um technology is not yet there of course uh it's uh it's first comput computationally infeasible it's too computationally intensive to do that and I actually struggle to uh imagine how it can how can we do it universally for multiple chains however yeah you you can imagine in future maybe we build something like that and the latest way is Quorum check you basically can ask different RPC providers you can compare the result and if majority agrees you you can trust this data uh so in this case yeah of course not it doesn't matter like decentralized centralized uh you can do that either way and uh you can argue that in decentralized setup you can punish providers that lie um economically however yeah it's it's it doesn't make M like it it really doesn't matter so it goes B way so so far um you know just it doesn't look good for decentralized providers uh and uh centralized providers are clearly win so what about cost efficiency and that's the first thing I would argue that decentralized providers can do significant significantly better than centralized so uh first reason is because uh like those node Runners that participate in decentralized RPC providers they can actually squeeze more juice from their Hardware because for example they can participate in different protocols simultaneously um uh and uh those protocols for example they can run drpc Noe ethereum node for drpc then they can use this Noe to uh for graph indexer uh and then for example if they have some spare compute that is not really uh utilized by those protocols for example they have GPU installed they can can participate in something like i.net or something like that uh so they can squeeze more juice as I said from this Hardware uh and the second reason is that uh because those node Runners they have there there's a lot of them uh if you implement uh some kind of of uh price auction or you know uh price discover mechanism uh it will be the price Discovery will be significantly more efficient for them so price will be probably lower or at least more fair than for centralized ones and uh centralized providers of course compete on price too but there is like not too much of them so this price discover is not so efficient and also there's a lot of stuff uh besides price for example like marketing PR BD all that stuff so what about multichain maybe decentralized providers are are better at multi-chain yes I think it's also true uh because if for example you're a building a centralized RPC provider and you want to support new chain so what do you what so what do you need to do first you need to add some code uh like for a Gateway or something uh then you need to buy new hardware or rent servers and then you need to learn how to run the noes and that's very everything is very hard so uh it's like adding new chains is hard for centralized providers for decentralized providers you just need to add some some code for your gateway and then you need to find uh some people who already have spare comput spare Hardware have maybe already running those nodes or know how to run those nodes and uh it basically uh using crowd wisdom and because of that for example drpc is able to support 60 blockchains I think the biggest number of the market uh is just because it's far more easier for us and the last thing is most important thing of course is censorship um so what about censorship uh censorship censorship on uh on the end of the RPC providers is not unheard of we've seen this already multiple times uh however I are I will say that it's getting worse for example this paper was released recently by a group of legal researchers who actually um they want to propose a framework for battling illicit activity in D and uh they say that okay in trfi that like battling elicit flows is all about intermed medies if you can control intermediaries Implement some measures on those intermediaries you basically can you know stop police detectors from transferring the funds and they correctly identify that RPC providers are actually the you know ultimate intermediary in D5 everything goes through RPC like new transaction read request everything so okay they say well let's then Define CCT this term critical communication transmitter and basically say that every commercial RPC provider is CCT and then we have them require them to implement risk management practices and procedures reasonably designed to help mitigate elicit Finance activity in waste allert to their operations which is basically means Implement censorship mechanisms can it work well um first I want to say battling elicit activity in Define is very Noble goal however like imagine there's some ha hacker who stole some funds and they need to run a transaction would it be hard for them to run their own note or for example to find un sensory note to run several transaction I I think I would say no it's it's pretty easy however for example say we want to censor some big project like Dex or other any other big project well for them it would be significantly more harder to bypass those regulations they basically would have uh three options that first they could run their own notes they can R use some unregulated providers and they can submit a sensorship uh as we previously discussed running uh running own notes running their own notes probably will will kill any web web fre project because of complexity and cost so it's not really an option so the choice is really between using unregulated providers and censorship and it's really hard to say how it will play out however uh remember uh in the beginning I was talking like this uh in RBC Market it's everything about reliability performance and cost efficiency so Market leaders who are best in these things they they will immediately comply uh it's it's it doesn't it's it's not a question so the unregulated providers we are left we we would be left with are worse than that and in many ways for example privacy security you can compare this with for example free VPN situation uh where if you use some shady VPN and can sell gather sell your data uh it's a little bit frightening or those unregulated providers could be very prone to hack and like uh tampering with data so maybe in the end the only if we have this you know status quo right now as right now uh the only way to do is would be to submit censor to censorship for those projects and the as I said for centralized providers it's not a question to comply or not they will eventually all comply or close or seize operations in the in the country of Regulation uh but for decentralized providers it's more complicated because as we I previously mentioned there is there is a community of node Runners you know and they all can each and one of them can decide for themselves whether to comply or not and you You could argue okay but you're running centralized Gateway yes that's true and Central for example this centralized Gateway right now could be could be censoring however if we have a community of node Runners who are all unified in some protocol well you can run multiple gateways and uh some of them will be censoring some will be not you you can compare with with the situation in ethereum right now uh on censoring on the protocol level for example you only need a fraction of you know non- censoring MAV relays non- censoring block build ERS and validators to for non-compliant transaction transactions to go through so if we still like if there's at least like 10 20% of node Runners and gateways will be uncensoring it will be enough and it will probably make those kind of regulations inefficient so let's oh let's let's talk about let's think about what we talked uh since so far so if you're building the centralized provider uh you have probably best uh you have probably you have better cost efficiency multi and of course censorship resistance uh decentralization is the only way to battle censorship we know of uh verifiability kind of goes both ways doesn't matter and centralization uh centralized providers have better uxdx performance and reliability so if you remember what I talked uh in the beginning uh centralized providers are winning hard so uh if nothing changed everything like our future is actually extremely centralized with with censorship mechanisms on uh with we data layer can we do something about it well actually the real question can we get everything because uh uh can we get everything can we get uh every trait of decentralized and centralized providers basically in one project and uh yeah that would probably solve a pro that would probably solve the problem so that's what we exploring in drpc right now uh we kind of try to understand is it possible to buil a decentralized RPC provider that is on fire better uh in terms of reliability or speed uh so far I would say uh we are we we proved like have a proof of concept because we were able to on board uh very cool projects like Lio Sushi swap instadb curve and many more and they selected us not because of our you know decentralization or uh narrative they uh selected us because they uh CH choose us because we actually better or on par with our competitors uh and it's because we we decided that you know we already saw a pro we've already seen the projects who for example have you know a decentralized set of node run permissionless set of node Runners we know how to do that but uh we haven't seen the project who can you know be uh have a the same quality of service as on centralized providers so like we focused more on uh Pro on our Gateway that uh allows us to offset individual problems of individual provider problems and optimize for latency and reliability and we go went with a permission set of providers because we know like that in future we can you know decentralize it more and add permission list uh made it make it permissionless so now we uh think our our next step is how to push the decentralization F further but we don't want to do it like just you know for sake of decentralization we want to understand is it if it's possible to uh add more decentralization without sacrificing quality of service because in my opinion it's the only way uh that we can have a future where uh there is a web three truly uh decentralized web 3 with truly decentralized data layer without censorship and we're trying so we're trying to build this future and if you want to check it out uh go to drc.org and if you want to follow our Twitter account there's a QR code um and thank you for your time that's it uh awesome that was a very action-packed information full talk thank you and we do have a couple questions for you so if you want to follow the Twitter scan it real quick because we're about to switch to the slido uh the first question that we have for you is uh do end users care about censorship and how can we make them care million dollar question um I would say I would say that uh it's kind of you know uh end users shouldn't care about it because uh you know they it's it's not like it's not they only care when their FA favorite project is online because of censorship but it's already you know too late so the industry the web 3 uh uh application and we as a whole as a industry as a whole should care about that the end user you know we shouldn't uh think about them too much in terms of like should they care or not uh they some of them probably will do they they care more about you know priv privacy security stuff like that but you know for example censoring tornado cach uh do they care well those who use tornado cash of course care others don't uh and that's that's natural and you can't force people to think about you know theoretical threat like when we when we talk about you know huge mass of people is hard so you can you know convince individual individuals or individual businesses about that but you can't you know say the narrative is very hard like to to push this narrative and say you know you should every every everyone should care uh we can we've seen successful n narratives uh right now and in the past but you kind of it's hard to control and hard to pred it's hard to you know manufacture so I would say we just need um the awareness should be built uh throughout the web 3 businesses who actually are threatened by censorship yeah and I think that's what a lot of us are here trying to do right and talk about it um the this last question we have is uh so transactions would never be would never make it to the blockchains because of this censorship and why isn't this spoken about more it's a good question I'm trying I'm doing my my part you know uh but the it's like I think there's two two parts first is as we talked a little bit about you know end users or you know Common folks uh they don't care because like uh they have a lot of a lot of information it's hard you know to care about everything um if we're talking about you know I it's I'm liking the better word of elite or something like um opinion makers why don't do they why don't they care more well uh maybe it's because it's a little bit boring I mean it's uh it's not so exciting like I don't know Shing charting or I don't know data blobs uh failing Salon transactions uh there are there are probably more you know more interesting more exciting uh things that you can apply your mind and intelligence to than uh sensor censoring censorship problem on RPC layers because it kind I think most of the opinion makers they think that it's not a very probable future that that eventually you know there will be some way to to pass your transaction uh still because like for example all of them probably would are capable of running their own note uh and you know submitting transaction directly to this note and if protocol is not censoring so who cares but uh I think they failed to a lot of them fail to understand that for Big Pro like if you're indiv an individual you can bypass this this problem but if only if you have a special set of skills but for end users for example and web three businesses it would be actually very hard absolutely well thank you so much I think we all care right yeah cool cool awesome thank you so much [Music]