Decentralized Infrastructure Network (DIN) Phases Towards a Sustainable Web3 Gateway | Iris Radoi

oh okay um good morning ladies and gentlemen and thank you for those who are attending virtually uh let me just start by saying that I've been working in the blockchain space for about three years and this is the first year where I'm attending East Denver and all I can say is wow I know we're just starting but I can already feel the energy building up so let's just start with the basics my name is Iris and I a product owner for consensus more specifically for the decentralized infrastructure Network project also known as Den uh I have with me e who is the co-founder of infura and uh in November last year we promised at the decentralized RPC Summit in Istanbul that the next big update on din is going to be at if Denver so nonetheless here we are uh today today me and E are going to give you an update on the progress that we have made on din in the past few months and oh believe me this is going to be exciting but uh before we begin I do like to start all my meetings with a d joke so unfortunately for all of you here today uh this is no exception so if if was a bodybuilder what would they drink whey protein all right so now that I've managed to make a full out of myself we can actually get started on the proper stuff so for the next 20 minutes uh our presentation will be structured at follow as follows so first I'm just going to provide a quick brief o of then uh I'm going to cover the what why and how of the project and this is going to be more tailored for newcomers as well as those of you who need a refresher on what then is and following this I'm going going to highlight some of our most significant Milestones that we have achieved so far and then I'm just going to hand over to EG who is going to dve into the current state of din and finally both of us are going to address the challenges ahead as well as the next steps that din is going to undergo all right so what is then um I would say think of it as decentralized uh RPC as a service in essence we've designed the network where providers can earn revenue and customers can enjoy endpoints that mimic their current experience so for example imagine having one always on endpoint that connects you to different blockchains behind the scenes though the traffic is served through uh network of providers instead of a single source and you might be asking yourself why do this well looking at the provider space through uh the lens of the web free EOS we have noticed that It suffers from from a lot of the common centralization issues so a lot of the providers tend to be single points of failure and a lot of them are susceptible to availability issues whether that's you know due to technical issues or regulations issues or provider limitations as a whole so and also there is an adversarial relationship between all providers and essentially we're all doing similar things to provide the service but there is wasted effort recreating our respective stacks and now that I've addressed the problem statement let's Envision the future of din's state of RPC as a service and why it's exciting as din realizes its full potential users can anticipate an elevated quality of service and an enhanced availability so this is made possible through the N Network's provision of geolocation and infrastructure diversity and essentially what we're saying is that we will be able able to find the best way to Route requests to you with minimal latency and with costs that fit your needs do you want something more specialized like a specific virtualized method we got it do you seek cost optimization over latency we can do that for you and the beauty of all of this is that this will be packaged in a Sim ux experience so as a user you shouldn't really feel much difference from just using like a regular RPC provider all right so I know a lot of us are Engineers here the next logical question is how are we actually going to build this so we are looking to uh we are working towards the decentralized model but the first step we're taking is for building a federation and the reason for doing this is because it's very hard to start an initiative like this on the right side of the spectrum and we're trying to build this in a way that it is sustainable and it's scalable long term and whilst I'm not going to dive too deeply into the diagram that we're looking at here EG is going to provide a more in-depth exploration in just a few minutes but what I do want to stress about this information is that there are a few critical roles played by various actors that are going to contribute to basically realizing Den's Vision so first first we've got the node operators so these are reliable and robust service providers who are capable of handling High trut requests at an agreed upon quality of service and we currently already have a handful of note providers on boarded Onin as we are preparing to launch failover for arbitrum optimism and Avalanche for infin next we've got the network Watchers and these are actors who will report degraded quality of service with evidence and periodically test the node providers that I was just talking about earlier in order to make sure that we maintain the quality of service of the network and currently the network Watchers are in a PC state so we're going to have more updates for them uh in the coming coming quarter next on the list we've got the onchain registry so this is also in a PFC state right now we're working very hard to get this up and running and this is also going to help towards building more of D's vision of reaching a decentralized state where providers should be able to declare their capabilities on chain and last but not least we've got the Ingress operators and uh one of those which is the din router which again EG is going to talk about more in a second but in a nutsh show these are the behind the scenes magic makers that I was talking about earlier so in terms of our journey so far in case you're not really familiar with what we've been doing we started off with an announcement in September 2022 at Eve Berlin where the idea kind of came to came to life and then we've had uh one hell of a year and a half since then and we've started obviously from The Logical things of drafting the white paper to putting up together the acceptance criteria for who we want to onboard on the network all the way down to September 2023 when we've managed to on board a first batch of Partners and we managed to meet up in person in New York where we together tackled a few of the challenges that you face when you're trying to build a decentralized network and we kept on boarding more and more Partners uh iterating on the acceptance criteria working out the economics side of things and towards the end of the year we ended strong with a din partner announcement at the decentralized RPC Summit that mentioned earlier as well as uh enabling the first live offering of din which was a polygon failover for infura and in the New Year we uh had further iterations on the router further iterations on the acceptance criteria which brings us to February last week we had the second in person meet up with our partners in Denver where we made tremendous progress again on all the different working group topics that we're trying to cover to make this a reality as soon as possible and to offer it to you and the we're here today uh and you know on to bigger and better so I'm GNA hand it over to e cool thanks Iris all right so so what have we been doing for the last four months or so since that last Workshop we did this workshop and where we were onboarding new participants getting them uh involved in participating in the network in various ways there were some people that wanted to contribute code some people that wanted to contribute infrastructure some people that wanted to actually help with the core development of what'll eventually be a d protocol and our first focus is building the D Gateway in the previous diagram that you had seen um showing the different actors on the network the D Gateway is one of those Ingress operators where traffic enters the network and the first thing that we have to build is essentially a reverse proxy or a d router that accepts that traffic authenticates that traffic and decides how that traffic gets routed out to the network so that's been the focus of our development the last um three to four months in parallel to that we've been on on boarding providers we went from initially having a handful of providers um in the spring of last last year now we have I I believe it's over 40 uh registered RPC and infrastructure providers that are willing to participate or are already working with us on the network um we've been working on expanding the network capabilities so the initial design of den was focused on ethereum or evm RPC and we quickly saw or found that people were interested in having Den serve capabilities Beyond just evm compatible Networks so we've been talking to people figuring out what the use cases are for um or what what the requirements are and making sure that we're adapting our current design in all of the different components whether it's the router itself the node kit that I'll get into in a little bit or um some of the other like payment mechanisms that we're designing lastly we started this bounty program uh which is intended to help bootstrap Demand on the decentralized infrastructure Network there are many talented providers out there that are capable of serving um RPC traffic API traffic other types of web 3 services but they are maybe too small to actually go out there and create these Partnerships that get them the deal flow that allows them to be profitable so we as infira consensus D are trying to do that leg work for people that are participating in the network so that they can focus on running the infrastructure and immediately get access access to um the demand side that that we're helping build uh this is a little zoomed in version of the D Gateway so this is the Federated phase of the network which means there it's not permissionless it's not like anybody can join it infira currently has a a business that we're running that's a traditional SAS and Den's journey is transitioning in F from a traditional SAS business to a more Crypton native web 3 business model and the first step in that for us is going through this Federated phase so in this Federated phase there's this D router that you see in this like purple color this is the proxy that we've been building and because we're building it into the existing infus service for now it solves some things for us um things like how we're going to um do user authentication and authorization for the network we're using the traditional um like API keys and typical web 2 permissions to start while we decide what we're going to do to actually implement this in an onchain verifiable way um that work is happening in parallel but this router is now live because we're able to start routing traffic to some of these providers that we've already connected Iris was mentioning that our first thing that we did was serve the polygon Network um ear late last year we're adding Avalanche arbitrum there's a few other announcements coming very soon of the networks that are going live on din the way that they're getting access to those networks is through this D router that um infura is kind of in front of right now so if you're already using infira you already have access to or you will have access to these networks as they go live the intent is that over time this Gateway is not something that only infira runs it's a permissionless thing where maybe an infrastructure provider decides they want to run a gate way in addition to their node infrastructure or maybe they only want to run a Gateway and they don't want to run the node infrastructure uh some of the challenges that we're trying to solve at that proxy level is network capacity that when you have a single point of entry into this network yes the uh the node capabilities behind that are horizontally scalable we can keep adding providers adding node operators but you have this single point that um will be that point of failure until we actually start to have horizontal scaling across the gateways because of that in the design we have to factor in how we're going to provide cross provider consistency which means if you're going to the infura Gateway or some other Gateway um say there's five gateways in the future you're not going to get consistency across them unless you design it into this the protocol right now and we were exploring some things with how we could potentially do that use maybe onchain signals to sync um session management across gateways uh our our current thinking on that is that Gateway uh consistent or consistency consistency is specific to gateways so when you're interacting with a Gateway directly you have a consistent experience when it comes to um the data that you're getting through those API queries but if you're starting to um interact across gateways that's that's outside of the scope of the network consistency implementation service compatibility is another one where different node operators and infrastructure providers might say I provide this service or that service but it's a slightly different flavor and a user doesn't really encounter that until they run into a bug that actually like breaks their application um so that's one of the things that we're building into the design of The Watcher system which is how it checks and verifies that a service is what it says it is it's as performant as it should be and it's um uh it's meeting uh the expectations of the user when it comes to the types of responses that it's getting back and then lastly extensibility making sure that in all of the things that we're building it's extensible not just by the uh D team we want it to be a community-led initiative to keep adding new functionality to this network and these are the steps to add um a new network or capability to d d while while we're initially talking about as decentralized RPC we really see it more as a decentralized Marketplace of apis and web 3 Services we're starting with um evm based RPC but anything that kind of fits this mold right here uh could potentially be solved on D you need to be able to create a service definition um which defines like what does your service look like for something like the RPC that means what network is it that it supports maybe what chain ID it's expecting um what uh RPC methods are specific to this network so if you if you use metamask and traditional like evm applications there's there's a very standard set of ethereum methods but maybe somebody creates a new evm fork and it has 12 new methods or it only has a subset of those somebody here can create a service definition specific to that Network then do the work to create a router plugin so that the that router or Gateway is aware of what these changes are and then lastly somebody needs to create a watch or test Suite or validation Suite which is those checks that I was referring to how somebody knows that the service that's running actually is adhering to the specification we have a version our first version of the onchain node registry in development right now um it this is a very simple like yaml uh representation of what what that work is so you can consider the onchain registry as a list of providers that are available a list of services and a mapping of which services are um hosted by various providers so you don't it's not uniform across this if you're running din infrastructure if there's like uh there's going to be this din node kit that I'll talk about in a in a second if you're running this did noit it's configurable because of that extensibility and plug-in model that I was talking about where you can pick what you're going to run and support so that's that extensibility and plugins here's an example of um a user interacting with the D router and that interacting or sending traffic to this node kit so the node kit is run by an RPC provider or infrastructure operator they would be picking and um either devel veloping new network plugins and storage plugins to meet the needs of the services that they are planning to offer um or if you're a Ingress operator or Gateway you're maybe um adding the integration of a new protocol some new authentication scheme maybe you came up with something to instead of traditional Json web token authentication you have something based on like ethereum private keys or pretty much anything you can think of any kind of like account abstraction based like authentication model can be supported by a new plugin in this din router so we are trying to design this as an open framework uh back in 2019 when we had first announced this uh we had said that this was going to be an open framework that people could extend running out of time I'm going to have to speed up uh the Federated architecture looks like this right now which is in fura as I said acting as the initial gateway to the network passing traffic to the din router which is where we're um tweaking the parameters of how traffic gets routed how much goes to this provider versus another provider and then we can also play around with um different methods of accepting payment for services I'm going to skip this uh little bit right here um but in this Federated phase not everybody is running the same infrastructure some someone might be running uh a highly indexed stack somebody might be running something with more persistent sessions going directly to nodes we're not trying to say what people run uh we're just saying that you need to uh pass certain validation and performance criteria to be um accepted into this network and capable of serving traffic uh the Bounty program as I said is live right now if there's people in here launching new protocols layer ones layer twos app chains this is something that we're able to um help get people RPC access or API access to to your new network uh and you can reach out to us if you have any questions going to have to speed up challenges I uh Iris do you want to take it uh yeah sure so uh I've got my slides here so excuse me if I'm looking down um so in terms of challenges we've got obviously there's there's a bunch of challenges that we need to solve on the D level but the ones that we're focusing on right now are uh moving beyond the Federated States so you know the potential for din found uh we've got the quality of service which you know we're always trying to figure out ways in which we're testing new partners and we're trying to be fair when we when we're doing that and uh also in building The Watcher specification and in terms of the economics is uh building the onchain registry yeah really quick on the R&D next steps that node kit is under active development we're adding um support for more like high storage High throughput networks new protocols like websockets and grpc and then and lastly um working on the first version of onchain settlement which is how how you move from traditional Fiat payments going out to these providers to something that's onchain and tokenized all right and just to close out the presentation if we could go to the next slide we want to leave you with one thought and that's not that we don't know how to make slides but rather that there's a lot of challenges that we need to solve on then and these are just some of the we're just scratching the surface with this presentation basically and last but not least I just want to save you a few headaches uh but what we're what I initially tried to do with this presentation is at the sprinkle of Eve Denver so I asked jbt how would you say thank you in Spork quale and this is what it came up with so thank you for all your time and attention and uh Tri undulation all right thank [Applause] you