# Decentralizing Infura | Devcon Bogotá

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-09
- Duration: 28:20
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-Wo6CVsHiniI
- YouTube: https://www.youtube.com/watch?v=Wo6CVsHiniI

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/decentralizing-infura/

Infura has provided a centralized API service to help grow the Ethereum and Web3 ecosystem since we launched in 2016. In 2023 we will be launching Decentralized Infura. This talk will go over the details of the decentralized protocol and the transition to it. We will also discuss why this is necessary at this point in the growth of the ecosystem and the emergence of a multi-chain future.

Speaker(s): E.G. Galano, Tim Myers
Skill level: Beginner
Track: Developer Infrastructure
Keywords: api,infura,infrastructure

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

foreign [Music] o I'm one of the co-founders in the general manager for infuri and I'm joined today with my colleague Tim Myers one of our lead engineers at inferior so you've seen the title of the talk you might have caught our announcement at East Berlin a month ago we're here to talk about decentralizing inferior it's something that's been on the Twitter waves and crypto Twitter for years something that people ask us about all the time like is inferior centralized how are you going to decentralize are you going to decentralize this is this is the talk where we answer quite a few of those questions for you we gave you a preview at eath Berlin if you're able to see the recording from that talk this is going to go more into the details of the why behind it the why now what now and especially the technical details that go into decentralizing inferior so inferior was launched in 2016 with the sole purpose of providing utility for ethereum and ipfs Developers it's something I say in all of my talks because I I want to make it very clear that inferior was always about the developers and making sure that developers that are building on web3 which for us was initially ethereum and ipfs could quickly get started and we did that at Devcon 2. it was four of us from the inferior team we flew to Devcon at the time we were a small team within the larger consensus organization focused on trying to build something that would be useful and so we all went to this conference and we were saying that we were going to get up on that stage and say there's a lot of innovation that's happening in this space we've created this new service called inferior and it's a traditional SAS service that you can use to connect to blockchains and we had a lot of apprehension about that like what would the reception to that be because at the time we were all running our own infrastructure we were all running our own nodes there was very much a lot of interest in like clients verifiability of data and we were saying don't run your own infrastructure trust us to run your infrastructure and so the the reception at Devcon was a little mixed some people were like okay great I'm going to use that other people said but why would I want to do that I can just run my own node and it's going to sink in an hour and then I don't need you anymore and uh so we said well that might be the case but we're going to try it like we're just here to try to provide something useful and maybe that will be useful and maybe it won't be and uh so we went up on stage and we we announced that we were going to be doing this and then during Defcon 2 the ethereum network was uh subjected to the denial of service attacks that almost brought down the network and some of the many of the heroes that helped save the network from that are either in this room or definitely at this conference the people that helped mitigate the attacks on the network and inferior's role in that at the time was trying to keep our endpoint up that was already being used to sort of metamask mother mask had launched uh two three months beforehand and uh thousands of users were already using metamask every day to send ether do some basic interactions with some of like the early maker contracts that were out there some of the early other experiments that were out there around that 2016 time and we said well we can't do anything actively to fix that client we're not the protocol core developers the core developers are solving that problem but there was already this issue where we were in Shanghai the Wi-Fi there was awful even worse than at most conferences and nobody was able to like get access to their infrastructure to update their clients once the actual client development teams had put out these updates and so our inferior team was sitting there in the lobby of the hotel updating our endpoints so that the thousands of users that were using metamask that might have been pointing metamask at their own infrastructure could use inferior until their infrastructure came back online and so that started to highlight one of the value props that we saw which was by having this centralized point we could simplify um or try to eliminate a lot of the pain for these users by um yes we'll take on this like aspect of centralization but for the most part it'll be beneficial and so we're going to keep doing that until it gets to the point where we feel like it's crossed a Tipping Point and we need to try to do things differently and when you look around the space there's other points of centralization that have paths to decentralization things like Fiat on-ramps and centralized exchanges and how there's a transition from those to Alternatives or decentralized truly decentralized ways of doing the same operation my favorite example is when you talk about Roll-Ups and how initially Roll-Ups start as having a single entity that's creating the Roll-Ups and the roll-up teams have a road map of how they will eventually get to being more decentralized so that's how we thought of ourselves as inferior started to centralize and we'll see when we get more decentralized and we're going to have a a solution for how we do that and the reason is because we had to create quite a bit of uh proprietary infrastructure to serve the traffic that we've done over the last six seven years what we run today as inferior is far more complex than what we ran with in 2016. if uh if you had tried to replicate what we had in 2016 um maybe a month or two after we launched you could do it within a week or two now it would take you probably years to try to replicate the systems that we've had to build because between 2016 and now we went through the 2017-2018 Ico bubble the 2019 crypto winter 2020 D5 summer all of the explosion of nft growth and with every single one of those things you might have run into an inferior production incident something uh that showed Oh this didn't scale exactly right and every time it didn't scale exactly right we improved our system right and so it forced us to innovate every single time take data like back in the day we used to send requests directly to ethereum nodes and there was really no virtualization as we call it custom services that would handle the traffic because we didn't ever want to be in a position of providing the wrong data to you because that would be really bad that'd be the end of our service if we ever provided you the wrong day that like that and especially in 2021 we ran into this issue where we tried to be very uh conservative with how often we updated our clients because uh early on the clients were a little bit uh bleeding edge and a little bit unstable the closer you tracked to the latest release and because of that users were complaining like maybe give us a little more stability less of the absolutely latest client that ended up biting Us in 2021 when we were running a client that was about six months old and a bug was triggered by by a team that I won't mention because there was an accident and they apologized to us but um it took down inferior for six hours and that was our first multi-hour outage that we have ever had and it's still our worst outage that we've ever had and so that really made us think maybe that was the Tipping Point maybe that's the point where we need to start considering Now's the Time to do things differently because for us decentralization was always the plan we said we're going to get there it's just not the first step in that plan we said that we are going to set out to prove that web 3 could be served by SAS we're going to say that we're going to run a SAS service and that's going to be beneficial for uh the ecosystem and it's going to bring more developers in it's going to bring in more investor interest a lot of activity is going to come into this space because people will see oh I can actually make a living and support myself running a business in web 3 when at the time it wasn't very clear Which models would work and so now inferior is not the only game in town There's dozens like they can't even fit on this screen anymore and we feel like we've accomplished that goal we've proved that SAS Works in web 3 and so now we want to prove that web 3 models can be used to serve SAS and that's what we took as our approach to decentralizing inferior and that's where we are today and the first step to that is open collaboration and transparency we don't have the entire solution in a white paper form that we're going to upload to ipfs and you're all going to read it right now like we're still in that design phase but we've already started collaborating with other people in the ecosystem on that design we've been working on it for a year and a half this is where we want to start showing you more of the technical details of what goes into that what does decentralizing inferior look like it could people have said oh are you just going to create a dow so that we can like have some governance over what inferior does is that good enough or is it some sort of uh utility function that we're going to try to have as part of this network what are the incentives of participating how do we incentivize the right behaviors and what people were especially asking was does participating in this decentralized infrastructure Network mean like inferior still owns and controls everything and that's the biggest question that we got in the last month since we announced it East Berlin and the answer to that no it that's that defeats the purpose of what we're seeing with a decentralized infrastructure Network that's supposed to be a permissionless network so inferior is going to just be a partner in a decentralized permissionless network one of an equal amount of or one of equals in operators so now I'm going to pass it over to my colleague Tim and we're going to start sharing some of the technical details with you thanks oh sorry uh yeah so as EG mentioned we don't have all of the details of this figured out yet we're still pretty deep in the design phase uh but the next 10 minutes I'm gonna try and walk you through as much as we have figured out right now as I can and then hopefully save about five minutes for any questions you all might have uh so first I want to start with just a really high level overview of what we see as the network participants in this decentralized inferior Network so first of course you have your end user who wants to connect to a web3 network maybe they just need to send a transaction to a blockchain maybe they need to read a bunch of data from it either way they need some way to access the API that a blockchain node typically exposes and so the first participant to support that are the infrastructure providers of course and they're the ones that are going to actually be writing the blockchain nodes off the supporting infrastructure that makes that possible to allow for high throughput of requests to send all the transactions to read historical data all of those things that you typically do with the centralized provider and they'll provide this service in return for a reward um which is what's going to motivate them to want to do this uh the next participant we're calling the network status Watchers uh this party will provide performance and capability reports of the infrastructure providers uh so they'll be there to kind of check and keep them honest you know they'll they'll see that they're keeping up with the head of the chain they'll check that they're you know responding quickly that their uh answers are accurate all the things that you would hope that an API does and finally we have this concept of an Ingress node they kind of act as an intermediary they will sell the actual network resources to users after purchasing them from the infrastructure providers and later I'll also show how they're not entirely necessary but they can provide a ux option that I think is useful so more detail on the infrastructure providers the first thing of course to note is that instead of now with just a single centralized provider we'll have many of them and they won't be run by a single party so here we just have a little simple diagram we have inferior we'll probably run one of course uh you'll also see other named providers that you're used to seeing that we hope will collaborate with us and you might also have Anonymous providers so you never really know who they are but through the mechanisms of the network you can come to trust that they are going to provide a good service so these infrastructure providers they commit to providing capacity on the network they'll specify the protocols and capabilities that they support so we envision this network working for ethereum but we also Envision Envision it supporting all of the sort of new networks that inferior has added over the last couple of years the layer twos new layer ones but not every infrastructure provider is going to want to serve all of those so they can pick and choose and specify what they want to support they'll also say the capabilities so you might be used to having you know archive nodes for ethereum and then sometimes you need that sometimes you don't and running archive traffic is a lot harder so some providers might do that some might not they'll also give an idea of the amount of throughput that they're capable of specifying and this may take a couple different shapes but you know you could think of it as like a thousand requests per minute when someone registers as a provider they're saying I can support this much and so that people can then buy that back and of course they'll be compensated for for doing this I want to talk a little bit about what it actually looks to be a node provider um and so this is a diagram of what inferior does and what other big centralized providers do it's complicated as EG said it's become much more complicated since 2016. to start of course you have your blockchain nodes these are the the ones that are produced by the client teams that interact with the peer-to-peer Network that sync blocks that verify it but um there's a lot of supporting infrastructure around that so first we have a snapshot system uh if you've ever tried to sync a node you'll know that it takes a very long time so we typically take the disk of a blockchain node save it to our own private Secure Storage and then when we need a horizontally scale out those nodes we use that as a seed for new blockchain nodes so it's downloaded onto a server and then sync from there which makes it much faster you also have various indexers and accelerators so if you've ever tried to do like a big wide get logs query for events from a blockchain node you'll know it's really slow so we have special indexers to speed that up also for things like nfts in front of that you have a load balancer that makes the decision of what accelerators to send your request to maybe for just sending a transaction it goes directly to the nodes and in front of all of that we often have a consistency system that helps make sure that users see a canonical view of the chain so this helps with reorgs to make those a little less painful for the user and also make sure that if they like query a block it doesn't change in between requests and this is something that is altogether quite complicated there's been several uh projects out in open source land that have attempted to help with this I think most of them are you know more on just running the blockchain nodes running several of those but to really provide good service you need a lot more than that and we will be releasing our own open source infrastructure kit that node providers can use to help them participate in this network of course there's also going to be parties that already know what they're doing and we'll probably just run their own flavor of infrastructure to provide the same service in the end uh next we have the network status Watchers again there's multiple of these run by different parties these will periodically test the infrastructure providers by sending them a small volume of requests they'll measure the performance and check for correctness of those responses they'll report all this to a Federated status page so if you're thinking about using this network you'll be able to go there look through the different providers see how they perform what their you know capabilities are of those things and also in cases of provably incorrect responses so there are certain requests on the ethereum Json RPC API that you could prove with Merkle proofs rather easily so in those cases those might also be used to inform penalties to the node providers and we hope over time as stateless clients start to improve that there will be more and more of that API surface that is verifiable a picture of kind of what it looks like to run a network status Watcher they will have to run some small amount of blockchain infrastructure themselves not nearly on the scale that an infrastructure provider would because they're not serving a high volume of requests but they need sort of a baseline to compare to they want to check that the infrastructure providers are near what they think is the head of the chain um and then of course they'll have all these periodic tests that they're running to see if the providers are operating well so they'll interact with the infrastructure providers they'll potentially send things to a Smart contract on chain for those provably incorrect responses and then they will also send their results to a Federated status page where you can view more detailed information and then last we have the Ingress node so as I mentioned this kind of serves as an intermediary between the end user and the infrastructure providers so an end user will send their Json RPC request to an Ingress node and then that Ingress node May then forward that to multiple different infrastructure providers maybe they generally send it to one and if that goes down they have a fallback maybe they round robin in maybe they choose to actually send it to all of them and do a quorum of that and return it to the user this will be something that the Ingress node can actually choose how they want to do it and one reason for having this Ingress node is that you can use it to give the same web to ux of the centralized providers today so I think there's a reason that inferior and centralized providers have been so successful it's provided a an easy entry point for people to come and swipe their credit card and get access to the network and that doesn't necessarily align with a decentralized ethos but it's also brought a lot more people to our our world and so an Ingress node might allow users to actually pay them in Fiat and then give them API access but this will still have better results than the current model because they can then be sending the traffic to multiple infrastructure providers and get some of those benefits uh in addition to that though an Ingress node might purchase resources from several node providers and then register themselves as a node provider uh with the sort of the you know the sum of all of that capacity and then an end user can go and pay for that provider in crypto um and then you have a fully crypto native experience so there's options here the node provider lets you do a lot of interesting things with uh combining other providers so the on chain registry is what we're typically calling our smart contract that kind of coordinates all of this and the main way to think about it is it's basically the data structure of your node providers so we have a very simple example of what that kind of looks like this is uh just one detail but you have your name providers and the protocols that they're supporting so uh as inferior maybe we're supporting the five that are listed here but maybe operator a is only supporting Ethan polygon this is where you would also be able to see things like maybe what region they exist in um whether they support archive nodes things like that uh gonna look sort of of the timeline of how this all operates so first of course the smart contract is deployed uh some amount of time later your infrastructure providers come in and they register they specify the protocols the capabilities and the throughput that they'll support uh some amount of time later you'll have Network watches that will register they may only want to participate watching for certain protocols maybe they're only capable of checking certain capabilities maybe you have a watcher that can't check that a node or that an infrastructure provider can support archive access but they want to help with you know the the near head requests and see that those are good for providers and then finally you have your consumers who come in and purchase throughput so that might be an end user who wants to go directly to a node provider or it could be an Ingress node that wants to combine them and once you put all of that together you get sort of what we view as our decentralized architecture uh so in the center you have the on-chain registry you have your network Watchers your infrastructure providers your blockchain API consumers and your Ingress nodes that all will register with that on chain registry and then once that's all set up your blockchain API consumers can send their requests to the various infrastructure providers that they've chosen or to an Ingress node which is sort of helping them do that and yeah uh we hope once we have that all figured out that it'll give us a self-sustaining reliable and robust network of infrastructure providers uh that's built to really serve the high throughput that inferior can today or other centralized providers can today uh for all of the blockchain API requests that you you need um but instead of what we have now it'll remove a single point of failure uh we help to hope to do this out in the open as much as possible and really follow that collaborative web3 Spirit uh this is we hope really going to improve reliability for these for the users and get a lot closer to that kind of 100 uptime dream um but also which I think is important still provide the ability to have that really easy web to ux if you want it uh we could also have the crypto native uh and yeah that's it uh we're seeking strong web 3 infrastructure providers to work together with us if you're interested in joining and participating in this network I encourage you to snap this QR code it takes you to a form that you can fill out provide a little information on your experience and your interest and we'd love to work with you um that's it I've got about four and a half minutes for questions if anyone has any thank you so much um please raise your hand if you have questions so our volunteers can lend you the microphone one two yeah so do you plan this whole decentralization to be more creative or censorship resistant sorry what was the first you said censorship yes so either you have for example a list of creative providers for quality or you have a censorship persistently so providers that will treat any request from anyone regardless of definitely improved censorship censorship resistance because it's permissionless anybody can participate in the network by meeting the criteria to join the network which is technical um technical criteria of meeting a level of performance right if you can meet a level of performance you can participate in the network we're not going to be selecting who can participate and then as a consequence what if a provider constantly perform badly uh they would be penalized by the network right there's there would be a financial incentive to provide the minimum level of performance and uh they would get penalized by the network if they're not meeting that level of performance additionally that Network Watcher that or in status monitor that we're talking about is continuously checking and Reporting on both the capabilities of the network as well as the performance so you can see here's a new provider that just joined they've only been part of the network for seven days they support seven networks of those seven networks this is the performance criteria of that right and all of that's going to be published in a stream of information that people can consume from to make routing decisions so a user can like a very technical user that wants to be in control of that can say this provider is coming from this region or this providers coming from that region and this is their performance and make selection criteria of how their traffic gets routed or they can pick their level of decentralization and ease of of years by going through an Ingress operator that can make those routing decisions on their behalf can you um give an example of what the centralized infrastructure currently looks like in terms of like number of servers and bandwidth and so on and what you expect will be when it's decentralized will there be overhead will it will it need more servers to do the same performance that kind of thing by number of servers are you talking about inference current current yeah um dozens of subsystems hundreds of different instances or servers providing different types of functionality so like we have a separate subsystem subsystem that all it does is index event logs and when you query events from uh like erc20 token events and things like that it's pulling from that subsystem and then we have this consistency system that tries to keep all of that in sync when you're querying one subsystem versus another um so that's the challenge that we've had is we built that as quickly as possible to solve problems and it's very proprietary Cloud specific and we've been working on how do we retool that so that it's something that can be not just open source and something that somebody else can run but can run with like not a team of dozens of operations people and so it's not what we're going to release in the node kit is what we think is an minimum level of functionality of performance where this is better than running a bunch of nodes behind a load balancer because it now has some of these indexing and performance optimizing systems but it's something that can be taken on by hopefully an individual but um at the very least a small team much smaller team than the current inferior team do you think it's uh likely that this unchain registrations of the providers will be a new yet to be launched dedicated chain or is it more likely that it will be on an existing chain like this you remain at uh that's one of the things that we've been considering as we're going through the design we're leaning towards don't don't start a new chain for that like try to use something that exists and that goes back to the why are we doing it now rather than in 2016 when people are talking about like micro payments between providers and like you use State channels for that and all these other things like we would have had to develop a significant amount of our research just on that problem whereas now a lot of these Primitives are out there and we can try to use some of the things that already exist to build the network uh yeah can you tell me who is the entity or people who decide what the requirements are to become an operator and who decides which operators or providers would meet those requirements and then how they would change in the future okay so multi-part so who decides who can be an operator so this form to sign up is to participate in like a permission beta um similarly to like how uh when other people are uh developing new networks we're going to have to start with a small group to try to test and iterate iterate with and for that we're looking for people that already have experience with the infrastructure and that we can reach out to and get feedback from um pretty quickly on the technical front but once we actually launch this network it's fully permissionless the criteria of that is what we're defining as a protocol in the design of this would be you know the amount of resources that you would have to provide or this would be the minimum level of performance so you have to at least support one network you have to at least support this level of performance and then as long as you can meet that it's um anybody hey Lefteris here I'm from Rocky right in front of you I just wanted to ask about the Ingress nodes will there be a requirement or will they be optional you should say like the indexing notes no no Ingrid at the end grass yeah it'll definitely be optional um so I can't quite get to the slides it'll take too long uh but you can still have a consumer who will go directly to the contract to purchase resources and go directly to one or multiple node providers that they choose the Ingress node is kind of an option where if you don't want to go to the trouble of doing that maybe you want to use one that allows you to pay in Fiat that you can but it's an option this this was our last question but if you have more questions please reach out to our speakers that we're going are going to be here thank you so much