 Okay, here we go. Hi, everybody. My name is Eiji Galano. I'm one of the co-founders and the general manager for Infira and I'm joined today with my colleague Tim Meyers, one of our lead engineers at Infira. So you've seen the title of the talk. You might have caught our announcement at ETH Berlin a month ago. We're here to talk about decentralizing Infira. 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 Infira is centralized? How are you going to decentralize? Are you going to decentralize? This is the talk where we answer quite a few of those questions for you. We gave you a preview at ETH Berlin if you were 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 Infira. So Infira 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 want to make it very clear that Infira was always about the developers and making sure that developers that are building on Web 3, 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 Infira 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 is a lot of innovation that's happening in this space. We've created this new service called Infira. And it's a traditional SaaS 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 light clients, verifiability of data. And we were saying, don't run your own infrastructure. Trust us to run your infrastructure. And so 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 so we said, well, that might be the case. But we're going to try it. We're just here to try to provide something useful and maybe it will be useful and maybe it won't be. And so we went up on stage and we announced that we were going to be doing this. And then during DevCon 2, the Ethereum network was 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 in fear's role in that at the time was trying to keep our endpoint up that was already being used to serve MetaMask. MetaMask had launched two, three months beforehand. And thousands of users were already using MetaMask every day to send Ether, do some basic interactions with some of 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 get access to their infrastructure to update their clients once the actual client development teams had put out these updates. And so our infira 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 infira 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 or try to eliminate a lot of the pain for these users by, yes, we'll take on this aspect of centralization, but for the most part, it'll be beneficial. And we said, 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 truly decentralized ways of doing the same operation. My favorite example is when you talk about rollups and how initially rollups start as having a single entity that's creating the rollups and the rollup teams have a roadmap of how they will eventually get to being more decentralized. So that's how we thought of ourselves as Infera. Start the centralized and we'll see when we get more decentralized and we're going to have a solution for how we do that. And the reason is because we had to create quite a bit of proprietary infrastructure to serve the traffic that we've done over the last six, seven years. What we run today as Infera is far more complex than what we ran within 2016. If you had tried to replicate what we had in 2016, 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 DeFi summer, all of the explosion of NFT growth. And with every single one of those things, you might have run into an Infera production incident, something that showed, oh, this didn't scale exactly right. And every time it didn't scale exactly right, we improved our system. And so it forced us to innovate every single time. 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 data like that. And especially in 2021, we ran into this issue where we tried to be very conservative with how often we updated our clients. Because early on, the clients were a little bit 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 a team that I won't mention because it was an accident and they apologized to us. But it took down in fear for six hours. And that was our first multi-hour outage that we had ever had and 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, 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 the ecosystem. And it's going to bring more developers in. It's going to bring in more investor interests. A lot of activity is going to come into the 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, in fear is not the only game in town. There's dozens. They can't even fit on the 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 in fear. 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. 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 in fear look like? People have said, oh, are you just going to create a DAO so that we can have some governments over what in fear it does? Is that good enough? Or is it some sort of 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 in fear still owns and controls everything? And that's the biggest question that we got in the last month since we announced it at ETH Berlin. And the answer to that's no. That defeats the purpose of what we're saying with a decentralized infrastructure network. That's supposed to be a permissionless network. So in fear is going to just be a partner in a decentralized permissionless network, one of an equal amount 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. Sorry. 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. But the next 10 minutes, I'm going to 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. So first, I want to start with just a really high level overview of what we see as the network participants in this decentralized and fear 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 running the blockchain nodes, all of the supporting infrastructure that makes that possible to allow for a 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, which is what's going to motivate them to want to do this. The next participant, we're calling the network status watchers. This party will provide performance and capability reports of the infrastructure providers. So they'll be there to kind of check and keep them honest. They'll see that they're keeping up with the head of the chain. They'll check that they're responding quickly, that their answers are accurate, all of 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 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 Infira. We'll probably run one, of course. 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 it supporting all of the sort of new networks that Infira has added over the last couple years, the Layer 2s, New Layer 1s. 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 can 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 doing this. I want to talk a little bit about what it actually looks to be a node provider. And so this is a diagram of what Infira 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 ones that are produced by the client teams that interact with the peer-to-peer network that sync blocks to verify it. But there's a lot of supporting infrastructure around that. So first we have a snapshot system. 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 synced from there, which makes it much faster. You also have various indexes 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 that 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 have been several 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 will probably just run their own flavor of infrastructure to provide the same service in the end. 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 of 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 capabilities are, all 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 with the node providers. And we hope over time as stateless clients start to improve that there will be more and more of that API service 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. And then of course they'll have all of 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 provider. 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. 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 2 UX of the centralized providers today. So I think there's a reason that Infera and centralized providers have been so successful. It's provided 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 the decentralized ethos but it's also brought a lot more people to 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. In addition to that though an ingress node might purchase resources from several node providers and then register themselves as a node provider with the sum of all of that capacity. And then an end user can go and pay for that provider in crypto. 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 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 just one detail. But you have your name providers and the protocols that they're supporting. So as in FIRA 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, whether they support archive nodes, things like that. Again, it looks sort of of the timeline of how this all operates. So first of course the smart contract is deployed. 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. Some amount of time later you'll have network watchers 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 the near-head request 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. 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 we hope once we have that all figured out that it'll give us a self-sustaining reliable and robust network of infrastructure providers that's built to really serve the high throughput that Infira can today or other centralized providers can today for all of the blockchain API requests that you need. But instead of what we have now they'll remove a single point of failure. We hope to hope to do this out in the open as much as possible and really follow that collaborative Web3 spirit. 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. But also which I think is important still provide the ability to have that really easy Web2UX if you want it. We could also have the crypto native. And yeah that's it. We're seeking strong Web3 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. That's it. I've got about four and a half minutes for questions if anyone has any. Thank you so much. 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 created or censorship resistant? Sorry, what was the first you said censorship yes so either you have for example a list of created providers for quality or you have a censorship persistent list of providers that will treat any request from anyone regardless of definitely improve censorship resistance because it's permissionless anybody can participate in the network by meeting the criteria to join the network which is technical technical criteria of meeting a level of performance. 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? They would be penalized by the network. There would be a financial incentive to provide the minimum level of performance and they would get penalized by the network if they're not meeting that level of performance. Additionally, that network watcher that or 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 a very technical user that wants to be in control of that can say this provider's coming from this region or this provider's 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 use by going through an ingress operator that can make those routing decisions on their behalf. Can you 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 to do the same performance that kind of thing. By number of servers are you talking about in fears current current turnout? Yeah. 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 like ERC 20 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. 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 a 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 at the very least a small team much smaller team than the current Inferite team Do you think it's likely that this on-chain 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 it That's one of the things that we've been considering as we're going through the design we're leaning towards 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 to use state channels for that and all these other things like we would have had to devote 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 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 similarly to like how when other people are developing new networks we're going to have to start with a small group to try to test and 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 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 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 anybody hey Lefteris here out from Rotky right in front of you I just wanted to ask about the ingress nodes will there be a requirement or will there be optional you should say like the indexing nodes no ingress of the ingress yeah it'll definitely be optional so I can't quite get to the slides it'll take too long 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 was our last question but if you have more questions please reach out to our speakers we're going are going to be here thank you so much