"This Boom Feels Organic; Traffic's Not Coming Out of The Blue Like With ICOs in 2017:" Infura's EG Galano

In this week’s episode I speak with E.G. Galano, cofounder of Infura, an infrastructure provider for Ethereum and other blockchains. Many Ethereum applications depend on Infura to run their nodes, and it became apparent why that’s problematic recently, when the service provider was having trouble connecting to the Ethereum blockchain, causing much of DeFi to break down.

Critics often point to the reliance on Infura to say that Ethereum is centralized. E.G. argues why that’s not the case, as they run only a small fraction of all of Ethereum’s nodes. The same might not be true though for applications built on Ethereum, which might be overly reliant on the infrastructure provider.

E.G. talks about the importance for companies and individuals to run their own nodes and says it’s relatively easy to do. While this may seem a bit arcane, being able to do so, even if you don’t, is a fundamental piece of building an actually independent and decentralized financial system.

E.G. dives into the recent outage; he goes into what went wrong and what Infrua is doing to make sure it doesn’t happen again. He also talks about DeFi from the backstage perspective of an infrastructure provider, and what he says might get you feeling even more bullish on this space.

🎙Listen to the interview in this week’s podcast episode here:

You’re a paid subscriber, which means you get the full transcript below. Subscribers also get exclusive access to The Defiant’s Discord chat for the community, here’s a new link to join.

🙌 Together with Zerion, a simple interface to access and use decentralized finance, and1inch.exchange v2, which aims to provide the best rates by discovering the most efficient swapping routes across all leading DEXes.

EG Galano: My name is Eg Galano, I'm one of the cofounders of Infura. I'm currently the head of engineering. My background is in distributed systems, systems engineering, scalable backend type of infrastructure.

Before getting into blockchain and Ethereum, I was at several startups here in California, one of them was doing video games streaming, not like Twitch but more platform streaming. It was a company called Gaikai, that's now a part of the PlayStation game streaming service.

After that, I was at a couple of other startups doing hotel backend software, but always on the side of the infrastructure behind it: how to keep these systems up and running, how to make sure that we're minimizing impact to users during updates and downtimes, and things like that. It was at that last company that I met one of my cofounders who, just as a water cooler topic, asked something that was like, how would you verify a piece of data that somebody gave you if you didn't actually trust this person? I joked around with him and said, are you interviewing somewhere? Is this like an interview question you want me to answer for you? He’s like, no, no, it's something that's really interesting going on in the Bitcoin space right now.

“How would you verify a piece of data that somebody gave you if you didn't actually trust this person?”

I was aware of Bitcoin, I was following up but not heavily involved. He was the one that convinced me that I should be paying more attention to the space. I was getting a little bit bored at my current role, and I wanted to be closer to the R&D side of the industry, and it really seemed like a lot of people were fascinated and interested in the technology behind Bitcoin and what was starting to be called blockchain. I wanted to be a part of that and figure out what it could be used for.

He was already acquainted with Joe Lubin, one of the cofounders of Ethereum, and he introduced me to Joe over a call. It was very informal. At the end of the call, Joe was saying like, do you want to join us, work at ConsenSys and find a product or project that you're interested in working on? Shortly after joining ConsenSys, I met a couple of other people who were equally interested in infrastructure and what infrastructure for blockchain could mean, and we started working on Infura almost immediately as initially an internal project for ConsenSys teams and then opening it up as a full-blown public offering.

Camila Russo: Can you describe more about what forming a team for a blockchain infrastructure actually means? What infrastructure is needed for blockchain technology?

Offloading the Node Burden

EG: The analogy I will use for people is to say, back in the day when you're using Kazaa and LimeWire, and these other peer-to-peer sharing networks and systems, and if you wanted access to this information, you had to run the software, you had to run a BitTorrent client to be able to connect to the BitTorrent network. It's exactly the same thing. If you want to participate in whether it's Bitcoin or Ethereum, you have to be connected to this network, because it's inherently different from what we traditionally see as the web. It's a decentralized network. It's a peer-to-peer network, and everybody has to run the software to be able to use the technology.

When I first joined ConsenSys, and I was looking around at all of the cool things people were building, the common thread and theme was that these were really smart people engaged with all of the possibilities of what they were building.

But the connection to the network that they had to manage was kind of an afterthought, or sometimes an annoyance of, we're really interested in building and solving this problem with the smart contract layer, we're not interested as much as having to maintain this node. Because for you to be able to participate in the network, you have to run this node software that's always up to date. It's what keeps the database underneath it in sync and aware of what's going on in the network. Because if that starts lagging behind, you can't transact on the network, you're basically dealing with stale data.

CR: The main piece of infrastructure that you saw missing was this ability for people to be able to rely on someone running the node without them having to go through that hassle of doing it themselves?

EG: The thing was, people were spending more time than they expected maintaining this node, and it was getting to the point where they didn't want to put as much time and energy into it as they were having to. Because as people coming from a web development background with traditional systems, maybe you were building something integrated with SMS and you were using tools like Twilio, and other types of API's that are available to web developers, you don't have to run that infrastructure. There are ways that you can offload that burden from your development team so that your team can focus on solving the problems that are core to your product. That was the model that we have seen work well for the traditional web space and we felt like there was an opportunity to have a similar product for the blockchain space that also solved developer problems.

“There are ways that you can offload that burden from your development team so that your team can focus on solving the problems that are core to your product.”

CR: So this was 2016 when Infura was founded. Right now, almost five years later, how much of the Ethereum infrastructure is Infura running? As a percentage, how many of Ethereum nodes are under Infura’s control?

EG: We run dozens of nodes. That number fluctuates day to day, based on how many we need to run based on traffic. But the thing is, there's the site ethernodes.org that tracks on a given day how many nodes are currently running on the network. I think Etherscan also has a chart on this. I'm going to pull it up really quick because I haven't checked recently. I'm curious what the number is today. Last time I checked, it was something around maybe 7,000 or so. But it looks like currently on the network ethernodes.org, they're just under 10,000 nodes running for the Ethereum mainnet. We run dozens of those.

That's where that's one of the pieces of information that comes across and it's something that it's hard for us to disprove. People think, oh, Infura runs more than half the network. That's not true. It's not cost-effective for us to do so and it's also not necessary. What we see ourselves as more as a cloud-optimized Ethereum node. We don't just run Ethereum nodes on the backend, and it's like one node conserve 100 users or something. We use these nodes to pull data and push data from the peer-to-peer network, but we've built customized systems that we use to help scale access to this information so that maybe a single node can handle something like 10,000 requests per second for what's the latest block information.

“People think, oh, Infura runs more than half the network. That's not true. It's not cost-effective for us to do so and it's also not necessary.”

Now, we build systems kind of around that, that can cache and more efficiently serve that data so that we can serve at 100,000 requests per second. That started out as a cost optimization for us, but it turned into the evolution of how we viewed our infrastructure. Everybody should run their own node. But that doesn't necessarily mean everybody should run their own node on their own laptop.

What we saw is that more and more people will want to have control over this infrastructure and we're trying to create tooling to help them do that. But the cloud as a tool isn't going to go away even as decentralized protocols are adopted. The better option and opportunity is to allow people to run pieces of the Infura infrastructure with more direct control over it. We see ourselves as a cloud-optimized Ethereum more so than a collection of nodes.

“What we saw is that more and more people will want to have control over this infrastructure and we're trying to create tooling to help them do that.”

CR: I'm not sure I understand that what it means to be a cloud-optimized Ethereum node. Is it that you're providing direct access to each individual node? What exactly makes it different?

Cloud-Optimized Ethereum

EG: It would be the way that we interact with the rest of the peer-to-peer network. But from the perspective of the rest of the network, we as Infura and the Infura traffic is just another point on the network from which information is pulled and from which transactions are pushed. We don't run 5,000 nodes on the network. When you run more nodes on the network, you're able to do things like eclipse attacks, and other things to potentially censor transactions or information on the network.

By just being a point on this network that helps scale read access to the data, we're allowing more people to interact with the Ethereum network without having to run the node, but we don't ultimately compromise the security of the peer-to-peer and decentralized network.

CR: Can you tell me a case where it would be more beneficial for a user to run their own node versus have it run by Infura? What are the different use cases?

EG: Our goal was not to make it so that people didn't run nodes. Our goal was to make it easier for people to quickly get started exploring Ethereum. So say, if you have a friend that wasn't very technical, and you wanted them to trade tokens on Uniswap, maybe they were really interested in the DeFi, fintech type applications of Ethereum as a technology, you're going to have a hard time convincing them that Ethereum is worth exploring if they need to be technical enough to run the node. Our goal was to make it so that people could quickly try if they're in the combination of Infura plus a wallet or browser like MetaMask, made it really easy for people to just get in and try it out.

“Our goal was not to make it so that people didn't run nodes. Our goal was to make it easier for people to quickly get started exploring Ethereum.”

The way that we see people typically going, is they might just stay on that, and that's perfectly acceptable for the amount of time that they spend interacting with applications on Ethereum. But there's nothing preventing them from also running their own node. We've actually done a few webinars and blog posts about how to run your own Ethereum node. The main thing is that if you're only going to be interacting with this node occasionally, you have to keep it always up to date to be able to transact on the network. When you have it on your laptop, if you shut down your laptop, and maybe you're traveling for like five days, and you come back, it's going to take a little while for it to sync back up so that you can transact on the network again.

There was a blog post we did a while back called the Hybrid Infrastructure Approach, which is you can run your own node and use Infura. Which would mean, say, you came back from vacation and as your node is syncing up, you still wanted to interact with these applications right now rather than in two hours from now or so, you can have it fall back to a connection with in Infura so that you can transact on the network. Then once you know its synced, you can switch back to using your own node, so that you know that there's a place where you always have up to date information. There are a few groups or companies out there that that is the way that they use us. They choose to run their own nodes, and use us as a fallback or safety.

CR: Do you think applications are overly reliant on Infura, and not running their own nodes as much as they maybe should?

Infura as a Safety Net

EG: That's hard, because there are some that are completely using Infura as the way that they get data from the network. It's almost impossible for them to allow an end user to run their own node if they wanted to. If I built an application that's using Infura, there's no way to swap that out to have it point to my own local Ethereum node if I wanted to. The reason for that is because they've built an API that sits in front of Infura that customizes that data for their application, or essentially optimizes it, and there's no way to kind of swap that out.

There are a few applications that have done that. For the most part, we've seen that people have been aware of that as they're building out their solution, and have made it so that their systems can fall back to something. With the outage that we had a couple of weeks ago, there were applications that heavily used us, but when the health of our service was impacted, their users were still able to interact with their applications.

CR: We touched on this common criticism that Ethereum is centralized, Infura is running most of Ethereum nodes, and you've basically, debunked that saying that you're running dozens of nodes versus 10,000 or so total Ethereum nodes.

But I wonder still, do you have data on, not the number of nodes, but on the number of Ethereum applications that are 100% relying on Infura?

EG: That we don't have, because we don't know. For instance, if there's an application out there that uses us like Maker, or Uniswap, we only know that they use us, we don't know necessarily what other ways they have of getting that data. I was saying there are a few companies that run their own nodes, and use us as a fallback or a check. There is an interesting pattern that you can implement where you can basically track both sets of information, the information coming from your own local Ethereum node and the information coming from Infura, and then you can have this like logic layer that chooses which one you're going to trust.

Maybe some people say initially, I'm only going to trust the information coming from my node, unless Infura’s information is more up to date. Maybe it's a way of having like a health check failure and saying, oh, something's up with our nodes, let's use Infura as infrastructure for now until ours is healthy again. People can implement that, and it's completely okay to us as Infura the service. We're not sure if that's how most people implemented or not.

CR: Is there no way of gauging the percentage of applications that are relying 100% on Infura? Is there a range that you can speculate on or not even?

EG: Not even. I think, that would be hard to make a guess on. Actually, so I took a quick look, because I know a lot of our users use us for trading Uniswap, it's like the most popular option out there as far as DEXs go. I took a look at the daily volume of transactions on Uniswap the day that we had our incident, and you really can't see a huge difference between the previous day and the following day after that. But that yes, some users were impacted by not being able to use Uniswap when we had our incident, but unless I told you this is the day that this outage happened, you wouldn't be able to tell just by looking at the amount of transactions that they happen on Uniswap and, that's one of our heavy users.

It made me feel pretty uncomfortable with the amount of reliance that people have on us. It's something that, that we're sometimes concerned about, we don't want to be a point of failure in the network. We believe in ourselves and our ability to provide a robust service. But we are a centralized service, we don't pretend to be a decentralized protocol or anything. We're a centralized service that's able to provide value because we're a centralized service. So, it's good to see that even when we have an incident, that the impact on the overall Ethereum network is minimal.

“We're a centralized service that's able to provide value because we're a centralized service.”

CR: I think that's an interesting balance there that you might have internally as a company. Because as a for a profit company, you would want to gain the most market share and have as many people using your service as possible. In that case, it would mean to have everyone using Infura to run their Ethereum nodes and Ethereum infrastructure.

But in your case, that's a little bit conflicting values and goals there. Because for the Ethereum and whatever blockchain you're doing infrastructure for, for that ecosystem to be healthy, you don't want people to be relying on one centralized service like yourself. So how do you deal with those contrasting goals and values?

Internal Tension

EG: It's hard. Because like you said, we're a for-profit company. For the first couple of years, we were just a free public service, because we wanted Ethereum to grow. We believe that there was a business model here that could be successful. But if you charge and have a paid product too early, you're just going to kill adoption and growth of the ecosystem, and our primary goal was to ensure the growth of the ecosystem.

Now that we have paid products and the business model that's working, how do you balance that? As you said, the traditional thing is go after as much market share as you can. But imagine if it really was 100% market share that we had, and we were the only way that somebody can interact with Ethereum, then the vision of Ethereum really has failed at that point, because we're making it impossible for somebody else to participate in that.

We've believed that as the ecosystem grows, as the customer base grows, there's enough room in here for alternatives to Infura. For other ways for people to consume blockchain data besides the way that we provide, we feel like we provide a really good tool for people to build with and interact with Ethereum. That's our goal is provide the best tooling and infrastructure for these people. But we definitely don't think we should be the only one.

“But imagine if it really was 100% market share that we had, and we were the only way that somebody can interact with Ethereum, then the vision of Ethereum really has failed at that point (…) We've believed that as the ecosystem grows, as the customer base grows, there's enough room in here for alternatives to Infura.”

CR: Maybe the path forward do you think would be to simplify these options of having Infura as a fallback in case the users own node isn’t running or the other way around, maybe making it easier for people to using Infura and something else? Maybe it would be the option for a more decentralized ecosystem?

EG: I wondered when I joined this ecosystem, why services like ours didn't really exist yet. There were already API's available for Bitcoin, like blockchain.info at the time. But they were always proprietary APIs. They were always things that made it more optimized and easier to query that information. What we did that was different. We kept to the standardized, specification of the Ethereum API.

When you run your own node, and you have this API offered by the node, that's exactly the API that we wanted to provide. We didn't want to make it proprietary, because then that becomes this vendor locking thing. That was really what made it palatable for developers, as they didn't see it as oh, well, we're going to make your life easy for you, but then you're going to be stuck with us. It was we're going to make your life easier, and we're going to prove it to you, otherwise, you can easily just switch back to your own node, because we're the exact same API.

CR: Can you talk more about your business model? You mentioned that you switch to being for-profit a couple of years back. How does it work?

Tiered Business Model

EG: The first thing was, we didn't want to overnight, just flip a switch and say, well, we used to be free and now we're a paid service, because, again, we didn't want to hurt the users that have been relying on us. We analyzed our usage, and we said, for, say, 90% of our users, how do they interact with Infura and how they use us?

We came up with a model of a tiered level of service where there would be this core tier that would just continue to be a free tier where people that are occasionally tinkering around with our API building proof of concepts, or even just our small teams that are just getting into production, have a way to connect to the Ethereum network without having to be worried about the cost of it. Then as they see their application is getting adoption, as they're getting more users that are interacting with their service, then the traffic levels grow. Then there's this team tier that we have above that, that can support more users behind it, and then a growth tier after that. Besides the tiers being based on traffic volume, there's also additional support with each tier, things that are more relevant to enterprise and business use cases than an individual developer or hackathon team type of thing.

CR: So each tier depends on the number of calls that each team is making to the Ethereum network. According to that, they would pay a different price?

EG: The two main things is based on the amount of traffic that comes through, and then also the level of support that they require from us.

CR: You mentioned the outage that happened recently. Can you describe for those who don't remember, or don't know what went on, what happened and the impact that it had in DeFi?

A Bad Block

EG: I'm based in California, it happened late evening, California time, just before midnight or so. What happened was these nodes that I mentioned earlier on in the call that we run dozens to sync our different systems with the latest data from the network, they stopped receiving new information. Our stream of information just stopped. At that point, we checked our monitoring to see exactly what's happening.

As our team started triaging, we found that the nodes were stuck on a specific block number. Having seen this before, the error that was showing up said that there was a bad block, which means there's a consensus bug or issue with the underlying Ethereum client. What that means is that the Ethereum client —because there are multiple implementations— agree on what rules are needed to transact and interact with the network. Is this a valid transaction that's trying to interact with this smart contract and modify this storage in this way? Is this the correct amount of gas that needs to be put into this transaction for it to be able to succeed? These are all rules that are hardcoded into these client implementations.

What happened was somewhere in the implementation of these rules, there was something that was different in the version of the client that we were using versus the version of the client that other people on the network were using. When that happened, it caused essentially a fork. Or this is the way that when people talk about hard forks on the network, and protocol upgrades, this is how they happen. Is rules are changed, new versions of the client are rolled out, and everybody has to update.

What happened here was that the version of the client that we were using had a rule set that was different from the rest of the network, and so our block processing was halted at that point until we could get our infrastructure on to a version of the client that now was back in consensus with the rest of the network.

CR: What transpired was that Geth, the client that had this issue, had found a bug in its code a while back, and they had fixed it. At that time, when this incident happened a couple of weeks ago, something triggered that bug in that version of the Geth client. There was already a new version of Geth that other nodes were running, which didn't have this bug and this kind of difference in code is what generated this fork of Ethereum.

What's the protocol in Infura for updating Ethereum clients and keeping the most updated version? Why wasn't that the case in this occasion?

EG: Historically, we would try to update to the latest version of Geth as soon as it was available and that's what we used to do. This ecosystem and the client software to run and connect to the Ethereum network is very unique in terms of, the impact that it has compared to say, a traditional database software or something else that you might run.

When we would update our client version before, we would occasionally run into significant performance changes. Maybe there was like a new RPC method, or API method that was added or some new client behavior that was added, and it would severely impact either the performance of our service or potentially, the availability of our service, early on, we have a few outages related to changes on how it handled peer-to-peer networking and things like that.

After having been bitten by some bugs, or changes in behavior by tracking the absolute latest version of the client, we said, if there wasn't a really significant reason for us to update, then we would stay on the stable version until we scheduled like a regular update to the next version. What determined when we would update is basically based off of if there was a critical consensus bug reported, if there was a network upgrade, or if there was new functionality in the client that we wanted to use.

“What determined when we would update is basically based off of if there was a critical consensus bug reported, if there was a network upgrade, or if there was new functionality in the client that we wanted to use.”

This bug was affecting versions of the client all the way up to, I think, August of this year was the time when the bug was fixed. Whether you were running a client from a year ago all the way up until August of this year, you would have gotten hit by this bug.

The Geth team released a great postmortem explaining why they didn't sort of shout loudly that there was a consensus security issue in these versions. Their reasoning was, we don't want to announce this in a way where an attacker can exploit this bug before enough of the network has a chance to update. They said maybe we can approach that differently or better, but at the time, that's the decision that we made. I understand that.

The reason that we were not tracking the latest version is, again, because we had seen stability and performance issues historically and so we wait for these releases to marinate and test it a little bit more before we roll over to them. Also, that there were breaking API changes in terms of how the nodes handle specific API behavior, and that would hurt our users because then it requires them to change their code.

We were actually in the process of getting ready to update to one of the newer versions that had these API changes and we announced it. We said we were going to schedule it for, I think, it was November 4th, at the time. We ultimately decided to postpone that update, because several users reached out to us and said, hold on, if you roll out this update, it's potentially going to break my application. I need more time to be able to update my code to use the new API or respond better to these API changes.

We postponed the update in the interest of stability for our existing users. That's what started by unfortunate is trying to provide that stability for those users ultimately ended up hurting us, because then we got hit by this bug, which was triggered not by an attack, but by curious researchers that were wondering if this bug but they found was exploitable, and it turned out that it was.

CR: I didn't realize that's what triggered it. Going forward, did you decide to change the way that you upgrade your client versions? Also, did you talk with Geth into maybe them being more clear in announcing when they change different versions of their clients? What was the fallout from all this?

EG: Our action items in that postmortem, where that one, while we do have great lines of communication with the Geth team, we're able to reach them if we have any issues or concerns and they're able to reach us. We said, going back to that centralization concern, we don't want to be treated differently than any other person that has access to that software and is running that software. They shouldn't feel like if there's a security issue, they should reach out to Infura and Etherscan, and the people that are running a lot of infrastructure. The methodology for how they do these responsible disclosures needs to be something that the Ethereum community agrees on and is aware of.

It's something that we raise that's going to be discussed, and I think is already being discussed amongst the client development teams, is how do they responsibly disclose any issues like this? The Geth team said that they're going to make it clear in the future when there is something like this that requires that people update quickly, rather than quietly mentioned it. So that's one thing.

On our side, we are going to make sure that we have more testing in place to quickly vet new versions and have the ability to quickly roll them out within our infrastructure so that we're always prepared and ready to roll them out if and when we need to. That's one of the areas where it might have still impacted us, we might have still had a service interruption, but it would have been a way to improve the time to recovery in this particular instance.

“We are going to make sure that we have more testing in place to quickly vet new versions and have the ability to quickly roll them out within our infrastructure so that we're always prepared and ready to roll them out if and when we need to.”

CR: I wanted to talk about how difficult it is to run an Ethereum node. There's a running theme on Twitter and elsewhere critics of Ethereum say that it's virtually impossible to set up a node, that it requires too much space and time and money and that it's unfeasible for an individual to do that. So I wanted to get your thoughts on this. How would a non-dev person go about running their own nodes and the benefits of doing that?

Running an Ethereum Node

EG: Well, step one for a non-developer is I would say, try running a light client. For the most part, a light client is more than enough for what people need. It's a way to quickly send transactions on the network. It doesn't require days of time to sync and that doesn't require gigabytes or terabytes of disk space to be able to store the full chain. If all you're doing is transacting on the network, and you're not doing analysis of blocks and tracing blocks, and all this kind of fancier stuff that some of our customers do, it should be sufficient.

But even if you don't want to run a light client, which only downloads a small portion of the chain, basically the minimal amount of the chain that you can to have some verifiability on the data that you're using, and you wanted to run a full Ethereum node, it's definitely possible. It's definitely possible for a non-developer to still do, as long as they understand the resources that it requires. The more resources that you're able to give to an Ethereum node, the easier it'll be to sink. Because this is a blockchain node, whether it's Bitcoin or Ethereum, is essentially a database that grows unbounded, it's just going to keep growing over time. That's a hard problem to solve. In computers, how do you allow this database to grow, grow and grow and grow infinitely and not have it get harder over time?

“What determined when we would update is basically based off of if there was a critical consensus bug reported, if there was a network upgrade, or if there was new functionality in the client that we wanted to use.”

That's why our researchers are doing a great job with all of these advancements that they're making in the ways that you sync a node, how you can just sync the portions of the data that are most relevant to you, how you can still have a way to verify pieces of this information without having to just store everything all at once. If you wanted to configure your Ethereum node to be able to store everything, what would be considered the full archive node, I think it's around six terabytes, right now, five, or six. But if you don't need the data in that format, and you can kind of get rid of the earlier data once you verified it, and just keep the portion that's most relevant to you, that's still under a terabyte, hundreds of gigs is probably what it would take.

As long as you can set up a node with that amount of disk space and give it a decent amount of CPU and memory, you should still be able to run the node, it'll just take some days to sync it the first time.

CR: Is a regular laptop enough for a light client? Or do you need some any special hardware for that?

EG: No, you can definitely run a light client and even that standard full node that I was talking about on a laptop.

CR: What about for archival note? What kind of hardware do you need for something like that?

EG: You can also run that on a laptop if you have enough disk space. I have a MacBook and so I don't have six terabytes on here. So if I were going to run an archive node with this, I would probably need to have an attached SSD that has that. Most of my friends and people that I know that run archive nodes on their own hardware will use a dedicated desktop for that, or just like a dedicated box that they can use and give it enough disk space for.

CR: That makes sense. So it's not impossible as some people would want you to believe?

EG: But not as fast as you'd like it to be. Once you get past the painful first sync operation, then it's going to be much easier to just keep it online and up to date. I really do think there's going to be improvements over time to keep that experience manageable so that more people are able to do it and potentially even improve on the same time.

CR: The benefits of this is not relying on any third parties, fully living out decentralized finance to its fullest. You're controlling your money, you're controlling your node, you're not relying on any servers. So I guess that would be the benefit of running your own node, right? I still kind of see it as a very ideological stance to take. Maybe the reason why it's important is because you want to know that it's possible to do it if you want to do it, even if it's not practical for every single person or every application to actually do it. But in the ideological sense of a decentralized future, you want to be able to have that option, right?

EG: I think ideologically, having the ability to do it is important. I'm pretty, maybe pragmatic, I like to be pragmatic with how I choose to approach idealism when it comes to this decentralization aspect of Ethereum and blockchain. In that, I feel like the most important thing that needed to be decentralized and tackled is not the access to the data, because there are ways around that if, you can use an alternative to Infura, you can run your own node, you can use Infura, but check that data against your own node, still there are things that you could do there.

For me, being able to remove proof-of-work and move to proof-of stake-systems and allow more people to participate in that with this upcoming ETH phase 2.0 launch is a great step forward in terms of really tackling decentralization as ideology, I think goes much further than optimizations and allowing more people to run nodes.

“For me, being able to remove proof-of-work and move to proof-of stake-systems and allow more people to participate in that with this upcoming ETH phase 2.0 launch is a great step forward in terms of really tackling decentralization as ideology, I think goes much further than optimizations and allowing more people to run nodes.”

CR: Makes sense. To wrap up, you've been such a key part of the Ethereum network’s history so would love your take from the backbone infrastructure piece of Ethereum on what this past year with this DeFi explosion has been like relative to other key times in Ethereum history, say, the 2017 ICO bubble, the bear market.

Organic Boom

EG: The main way I've been describing it to people who have asked is that it feels organic. It doesn't feel like a boom as much as 2017 and early 2018 did, where during that time, we would just get hammered by an ICO out of the blue, and it was one after the other. You can look at some of our traffic graphs, we've presented these at some previous conferences where it was just month over month, our traffic was just growing and growing. Before it was just one second that traffic wasn't there, and we were just seeing like a slow trickle of new registrations, and then all of a sudden, everybody was interested and wanting to build something quickly, and essentially, cash in on the popularity of ICOs at the time.

We're not seeing that same type of engagement this time, where most of the projects and the people that are using Infura are either people who have already been using Infura and have been building this product for a long time and it's now getting to the point where it's launched, and it's getting traction, or there are people that are coming to us signing up and showing us what they're building. The attitude is not I'm building this quickly because it seems like there's an opportunity here. It’s, I noticed that there was this problem that needed to be solved, and this is what I'm building and Infura is helping us build that. Which is great.

“The attitude is not I'm building this quickly because it seems like there's an opportunity here. It’s, I noticed that there was this problem that needed to be solved.”

The growth in traffic is still there, but it's more linear growth. It's been over time, say over the summer things grew and then there are certain events here and there like when SushiSwap was trending on Twitter and when Uniswap was doing their token drop and things. There are things here and there that activity for Infura tends to have some spikes here and there based on what's going on in terms of the overall ecosystem. But it doesn't feel like it's been rapid; you can see that the trend was building over time.

CR: That's great to hear. That sounds a lot healthier than the explosion, the boom and bust of 2017 and 2018. Given this more organic growing trend of growth for Ethereum, going forward, what are your plans, what do you hope to see for the next year for Infura to continue growing in number of nodes or what are your goals?

Not Ethereum-Only

EG: One thing is, we've always seen ourselves as a blockchain infrastructure company, not an Ethereum-only infrastructure company. We recently added support for the Filecoin network, we feel like that pairing of Filecoin for storage plus Ethereum for compute and transactions is great as a pattern for people to build applications. We want to see more people doing that. That's why we added support for the Filecoin network shortly after their launch. We now offer an API for Ethereum 2.0 so that the Ethereum 2.0 testnet currently and we're prepared to support the ETH phase 2.0 launch when the time comes.

We are starting to branch off from just this Ethereum 1 service. There's an opportunity for us to maybe get involved in other parts of infrastructure that are interesting, maybe something in Layer 2. There's a lot of people interested in pending transaction pool data right now, whether it's for trying to build like front running arbitrage bots or something or just gather more interesting insights into what the current traffic patterns and behaviors are on the network. We're working on offering that up as an API for people as well.

The developers within this ecosystem are further along and more sophisticated now than they were when we first launched. Meaning that when we started out, people were still not sure what they were going to be building and what their needs were. They were more exploring what could be done. Now people are coming to us with more specific asks of this is a problem that we have as smart contract developer, application developers, this is the type of data we need access to, can you help us with that? I can't say too much as yet, but we're going to be announcing relatively soon, some new products that should help with some of the pain points that developers are having right now.

The Defiant is a daily newsletter focusing on decentralized finance, a new financial system that’s being built on top of open blockchains. The space is evolving at breakneck speed and revolutionizing tech and money.

About the founder and editor: Camila Russo is the author of The Infinite Machine, the first book on the history of Ethereum, and was previously a Bloomberg News markets reporter based in New York, Madrid and Buenos Aires. She has extensively covered crypto and finance, and now is diving into DeFi, the intersection of the two.