How Ethereum Can Scale to Billions of Users

Transcript

Good morning, everyone. I'm Ed from the Offchain Labs team, developers of Arbitrum, and I'm here to talk about what we can do to scale Ethereum to a billion users. We talk about that a lot. Many people talk about the billion user goal. But, what I hope I can offer this morning is some real talk about what we need to do to get there. What is it that we're building and how can we build it in a way that will attract the that billion users? And I want to start with Paul Graham's famous phrase in Advice to Startups, "Make something people want."

What this means is having some humility about what it is that we are building or should be building in order to focus on the needs of users and developers for our platforms rather than building for ourselves or building something that we think is cool. So, what is it that people want? What is it that we can provide that really has mass appeal and value to users all around the world? And I think at the end of the day, what it is is I would call the programmable economy.

And the idea is to take the economy that people are already engaged with and in and to make it programmable in the same way that the internet took communication and made it programmable. We want to take the economy and make it programmable. That ultimately is I think what people want, and it's the thing we can build that will be attractive and bring those users on board. It should feel like the familiar economy only faster, cheaper, and with less friction. So, I think the programmable economy has four main components that we need to provide. The first one is open and accountable code. That means not only

that people can see what is the code that is implementing this, what is the code that's implementing applications, but also that there's some sense of accountability there so that people know how this can change, where it came from, and if there are changes that people don't like, they have some recourse. The second one is permissionless innovation. We want it to be the case that anyone who has a good idea and some reasonable capability or excellent AI can build a new product, a new idea, and roll it out to at whatever scale the market will that matches the market interest.

The third one is scalable connectivity. If we as we build this, we can't build a single monolithic system that will be able to serve all of these people directly. We need to figure out how to scale up the system while still retaining connectivity so that people who are connected in different places or assets in different places are able to interact in a relatively smooth way. And then the last one is integration with the economy. That is not to build a separate economy alongside the legacy one, but to integrate into the legacy economy in a way that makes it better, faster, cheaper, and easier to use.

So, how are we doing so far against these goals? Well, in open and accountable code, we are killing it. Not only is the code that provides our platforms open and accountable, but also almost uniquely among technology platforms, the Ethereum stack and similar systems is able to provide and support open and accountable code for applications that run on top. People can inspect the code, they can know that the code that is running is the same code they inspected. And that is really a unique value that we can provide, and it's one reason why at least nerds are really attracted to this technology, but it can provide a lot of value

to end users if we can make it practical. Second, permissionless innovation, there I think we're also doing very well. As the tools grow, it becomes easier and easier for people to build systems and roll them out worldwide. Now, in the last two, I'd say are works in progress. Scalable connectivity, we have interop across the Ethereum ecosystem and and to some extent outside, but that interop is in many ways not ideal. And I'll talk more about this in a few minutes. But, it's still a work in progress to get to the level of trustlessness and the level of friction that of low friction that we need to reach. And finally, integration with the economy, again a work in

progress. I think the entry of of large TradFi firms into the space and the growing integration between blockchain-based DeFi and TradFi platforms is really exciting. It's one of the things that we have to do to get to that billion users, but it's very much a work in progress, and we need to continue to work on that. Okay. So, how can we get there? What What lessons can we take? It's important always to learn from other's success, and I think one of the others that we can best learn from is the internet, which went from this map in 1973, each oval being a computer, to this map about 25 years later. And now you wouldn't even try to put it on a

diagram. So, the internet is really the unique and and best example of an open and permissionless system that was able to grow beyond a billion users and to do it quite quickly. So, I think there's a lot we can learn from what the internet did. So, lessons from the internet. First, building layers. The internet famously was built in layers, and that's one of the reasons why it was able to outcompete its monolithic competitors. So, building in layers gives you a few advantages. First, each layer can focus on doing one thing and doing it very well.

And each layer can rely on the layers below doing their things well, so you don't have to replicate that functionality in the same way that in the Ethereum stack, L1 provides a very high security, very reliable base on which to build everything. And layer twos can provide can take advantage of that to provide additional features, higher throughput, and so on. Similarly, on the internet, you have the stack of layers, and as you go up the stack, what you find is each layer innovates more quickly and is willing to take a bit more risk in its innovation.

And um and innovation increasingly happens as you move up through the layers. The internet was very successful with this, Ethereum has been very successful so far with this, and I don't see a reason to go away from it. Second lesson from the internet, make it programmable. This one This one we already have. Next lesson from the internet is connect everything. Now, the internet does connect everything, but it connects everything in a particular way, and I think we can learn from how the internet connects everything and emulate that as we work to connect everything across the Ethereum stack.

So, I think interop that works interop internet style has a few characteristics that I want to point to here. It's fast. It's standards-based. We're doing okay on these things. But, I think the last three have important lessons for us. First, it's asynchronous. One component doesn't stop and wait for another component because at global scale, they can't really be synchronized and also run at maximum speed. So, don't stop and wait. Next, it's fault-tolerant, which means you don't assume that the other one will be available. You need an interop scheme which is able to deal with the other component being down, being non-responsive, being disconnected from the network somehow.

And it's security-conscious, meaning that one component doesn't automatically assume that the other component is secure. It's a It's a try to interact, but protect yourself against the other component being being compromised. And so, as we build out internet interop across the Ethereum stack, I think it's important to be asynchronous, fault-tolerant, and security-conscious. And that will be the key to being able to scale it up. And that means that the friction will not be zero, just as on the internet, the the friction from interop and operating across different sites and services is not zero. But, we can drive that down.

And in fact, in practice, you get the lowest friction by following this recipe. Lessons from the internet. Everyone chooses who to trust. We don't assume that there's a central body that decides what's trustworthy and what's not trustworthy. Each user can make that decision for themselves or delegate it to some entity that they trust. And finally, innovate to solve users' problems. That is, we should innovate not to solve our own problems as users, nor should we innovate to build something that because we think it's cool.

We should figure out what it is that users want and need, and then direct our innovation towards those problems. And I want to do a deep dive into an example of this, what I think is an excellent example from the recent history of Arbitrum. And that is a user problem of gas price variation. So, I have a graph here that shows the price of the base fee, the gas price on Arbitrum One on October 10th of 2025, which some of you may remember was probably the busiest, highest market turbulence day in the history of our stack.

And this is against UTC on the x-axis, the Arbitrum gas price. And you see that it peaks at around 41 gwei. What that is is about a 2,000 x increase in the price of doing a transaction. And of course, this happened at exactly the moment when users cared the most. And if you go to any consumer of any product and say, "This thing you rely on, someday unexpectedly it's going to cost 2,000 x more than it does today, and that will happen exactly on the day when you most want that thing?"

That is not That is not a user-friendly situation. So, we set out to attack this problem. Could we reduce gas price variation without putting in danger the things that the pricing algorithms are already protecting? And this is a hard problem. And it's a hard problem for a fundamental reason, that first of all, the demand for transactions, for block space, varies incredibly over time. And second, you have chain infrastructure, which has limited capacity.

Right? And so, the conventional wisdom is that you have to increase the price. Price increases are the only mechanism that the chain has, other than just dropping user traffic, but let's not go there. Price increases are the only practical mechanism we have to protect the infrastructure from being overrun in in busy times. And so, the standard response to that is in Ethereum's EIP 1559. And Ethereum, of course, uses that, and L2s, up until recently on Arbitrum, have used this. The 1559 price algorithm is what led to this graph that you saw on the previous slide.

So, this seems like a hard problem. How can we protect the infrastructure from from being overrun, while still having less price variation in practice? So, our solution was something called responsive pricing, and I'll talk in a minute about how it works. But I want to first show you what the effect of it could be. This is again a graph of October 10th. The red line here is the actual gas price curve that I showed you on the previous slide, two slides ago.

The blue line here is our simulation of what responsive pricing would have done on October 10th. While again, I emphasize, still protecting the infrastructure of the chain from getting overrun. And what you see is a peak gas price of about nine gwei, which is um much better. And by the way, this is not due to increasing the gas limit, because if you turn on responsive pricing and increase the gas limit, what you get is this green curve. So, the benefit here is coming from responsive pricing and not for gas from a gas limit increase.

And in fact, the to get the same degree of improvement through gas limit change alone, you'd have to increase the gas limit by 5 x, which is not really practical. Okay. So, responsive pricing really does address this important user need. How does it work? Well, there is a post on our research blog, which has the equations and the model and all of that. But let me explain it by analogy to a marathon runner. So, this runner is going to run a marathon, and she can run at a particular average pace over the course of the marathon.

If she needs to, she can run faster for a short period, but not too much faster and not for too and not for too long. If she does speed up, then she's going to have to slow down and run run a bit slower than her average pace at some point later. But if she has some reason, whether it's a hill or I don't know, she's being chased by wolves, she can run fast for a while and then slow down later, so that the average pace over time is maintained. Well, if you look at the demand on chain infrastructure and why we have the gas limit that we do, what you find is that the situation is a lot like this marathon runner. You need to sustain a certain pace, no more than a certain pace, over a long period, but you can

sprint faster without overrunning the without overrunning the infrastructure. And so, what responsive pricing does is vary the pace in a way that is principled and has provable properties. So, let's show you what the effect of this is. It rolled out on Arbitrum One in mid-January. So, this is January 31st, which is probably the second biggest traffic day. And what you see here is there's faint gray lines, which are the which are the demand on the chain, which you see goes up to at or above 130 million gas per second.

The blue line here is the actual gas price on Arbitrum One. And the black line is our simulation of what 1559 would have done, even taking into account that users slow down when the price goes up. So, what you can see here is a huge improvement realized in practice through responsive pricing. So, you can look at some data from that day, and this is sort of a comparison across chains. What was the peak demand that arrived at the chain? What was the maximum price when you were at that demand? And then what was that in dollars? Okay. So, So, the key thing here is that Arbitrum was able to reach about over 900 million gas per second briefly in arrivals at

the system, while keeping the gas price max gas price at about 2.1 gwei, compared to base, which uses 1559 with a much higher gas limit, which was able to peak at about 370 with a slightly higher gas price. So, this is basically the payoff. You can serve more traffic at lower gas price, and again, without overrunning the infrastructure. Ethereum, of course, has a lower peak demand that it can serve at a higher price, and optimism just has less demand. Okay. So, just to show this wasn't a fluke, here's February 5th, another relatively busy day.

And you see again, the blue line is the price on Arbitrum One, the red line is 1559 simulated. So, this is consistently reduced the variance in price, which is a major pain point not only for users, but also for developers of certain applications, lending protocols and perp DEXs and so on. A major breakthrough, but working on a problem that is not as sexy as designing the next ZK protocol, but something that meets users' demand and needs better. So, this is an example of what I think we need more of, which is deep technical work that aims at actual user problems, instead of the things that we

would work on in a vacuum. It's important to do that, and and I think we're seeing teams in the space becoming more practical about this. Now, there's a lot of debates right now about the direction of Ethereum and the Ethereum stack. And those are often framed as a tradeoff between principles and pragmatism. Should we design a system that meets our highest ideals of what we should build, or should we make decisions that will attract usage? And of course, like many dichotomies, the best solution is to try to break it.

What can we do to achieve principles and pragmatism? This is what we need if we're going to get to a billion users. Because if we have only principles, we'll build a beautiful system, but it won't benefit people if they because they won't use it. On the other hand, if all we have is pragmatism, then why are we even here? Because we're just, at best, rebuilding what came before. So, we need to find a way forward, where we're able to leverage our principles, turn them into benefits for the product and and the stack, and actually deliver the value of those principles by making smart decisions about how to combine and, when necessary, how to balance principles and pragmatism. This

is the only way forward. And we're at a really unique point. We are at an inflection point in the development of this technology, in the development of the Ethereum stack. We have the opportunity to take on board the merger with TradFi. We have the opportunity to sustain our principles as we do this, as people stay in this community during a time when, you know, frankly, there's some turbulence. This is the time to focus on building the foundation that will serve that billion users.

I know we can do it. There's so many smart people, so many principled people in this community. So, my call to action for you is let's build this programmable economy, and let's build it together. Thank you.