Next-Gen Blockchain: Empowering Scalability and User Experience with L2s

Transcript

[Music] Hello. Cool. Good morning everyone. My name is Matt. I work at Offchain Labs, the initial developers of Arbitum. Here today to talk a little bit about what we're doing to build blockchains and to make them faster. Going to grab my ticker. Apologies. Everyone having a good conference so far? Yeah, nice. We like that. All right, so I'm going to cover a lot of content today. I'll try to go quickly to make sure we have some time at the end for questions. Going to give a brief overview of scaling solutions in the Ethereum space. Going to talk about the core issues we're still facing um at the layer 2 level and building the solutions

that we're working on. Going to talk a little bit briefly about where I see the infrastructure space going terms of trends we're seeing on our side. And then I'm just going to leave you with a couple, you know, thought starters, things to think about over the next few weeks. So, let's get into it. So, going back and just taking a step back just, you know, so we're all on the same page. Um, rollups and layer 2 solutions in Ethereum have taken on a lot of influence recently. If you look at where we are today, I think I pulled these numbers last night, you have around $40 billion in total value secured or total value locked, depending on how you slice it across rollups. Um, you've got around, this is a bit harder to parse, but 25,000 monthly active developers contributing. I think we're seeing that

number balloon overnight as institutions with large teams start to come into the space. So, that's probably already out of date. You have large crypto assets that you're all familiar with like Bitcoin and Ether, tradable in most markets. Um, and stable coins as we're seeing massively evolving, lots of new issuances. It's becoming a very, you know, trend, a very big trend for um, retail investors and institutional investors to get their hands on these assets. We're seeing a lot of vertical integration in the space. So maturity of the industry uh in any industry is usually foreshadowed by consolidation and so we're seeing that in crypto as well. And there's other factors primarily if you look at resource scarcity and population growth around the world efficiency is important in all technology and blockchains were created for that purpose right to

disintermediate and to make it simpler to trade with another person. So we're seeing a lot of demand for the technology that we're building in scaling solutions and you know it's only going to get more challenging. So what are we seeing what's happening with roll-ups? You've heard about them for a long time but why are they you know becoming more important. I think we're seeing rollups as as you've you know kind of historically heard about them become common infrastructure. You're building an application. You want to do some trading. You want to build a D5 project. You want to build a social project. You're going to use either a rollup to launch your project on or you're going to launch your own chain. I think we're seeing chain stacks increasingly becoming, you know, viewed as the general backend infrastructure.

You want to build on the cloud. Okay, you're going to build on a rollup. It's just becoming a little more common in the developer space to make this decision. What once was kind of a set of individual chains are now becoming large ecosystems. So networks are branching out and forming their own little sporadic environments. If you see here in the arbitum space, what once started as arbitrum one, a single layer 2 on Ethereum L1 is now 50 60 and we've got 100 plus chains in development in the network. So a lot of growth both in terms of the types of applications that are being built, but where these chains are deployed, how they're configured, who's using them, who owns them. Um it's it's getting increasingly complex and that makes our

jobs harder. And I think you know with the exception of a few chains like arbitrum one a lot of the original chains that were deployed for those of you that have been in the space for a few years were you know are basically becoming proof of concepts right they were shown and deployed to see how far they could push the technology how hard it was to build an ecosystem and now we're starting to see real entrance come into the space and change the landscape quite dramatically I think however uh you know the value proposition of layer 2 has largely been delivered on if you look at where we were in terms of how much it cost to spend or to send money on Ethereum L1 a few years ago. Now you send money on arbitrum or base or any of the other L2s. It's it's very cheap. Um

not only have L2s because of their architecture reduce the cost, but Ethereum continues to work on scaling the underlying base layer and so costs generally have gone down overall. You see a few alternative DA solutions for those of you familiar with this which are basically other networks you can post data to. those may bring cost down further if you know things haven't commoditized already. Um, and in the happy case, just as an example, transactions that are free or almost free to send on L2s. And so if you're a project with a real business model collecting revenue because you're delivering something that people are willing to pay for that you you can just cover these costs. It's essentially free. So just as an example, if you look at how much it cost to send Ether on L1, this is based on the average uh prices

yesterday, around 5 cents on L1, which is historically low actually. um and fractions of a cent on an L2 like arbitum. And so this is just based on the the base fee prices across the chains. So okay, it's really cheap to send money to someone else on chain or to send ether. Uh what what's the challenge? Why is cost an issue? Um one of the main things is variable cost. So when a network becomes congested uh and there's a lot of traffic on it the price is not stable it's very hard as a project to predict how expensive things are going to be. You see this in most economies um you know resource scarcity means things go up in price. So when things are congested it becomes very challenging and the issue with this is depending on

what you're doing it doesn't matter the prices go up for everyone. So it's really really hard um when things are congested as a project to know how your uh business model will scale and the important thing is this is across network. So say you're on arbitrum and things get really congested the price can go up but if arbitum is doing fine kind of stable and Ethereum gets very congested the price on arbitum also goes up. So all of these networks, as I mentioned earlier, that are expanding, they are all interconnected in some way, usually relying on the same security layer. And when prices go up on that security layer, things can get more expensive for all users. So that that's a problem, right? If you're a project or you're a user, you want stable prices.

When you send money between bank accounts, the price is always the same. If we're trying to make this financial infrastructure that everyone uses, we need stable pricing. So imagine just for a second that you're building a normal like website on AWS or GCP and you're trying to you know scale the business to millions of users. If I told you as your sales rep at Amazon or Google that oh well sometimes the price might 5x and we won't know when it's going to happen. That might not work. You probably might not want to use that backend technology. So as this technology becomes increasingly viewed as that replacement or a parallel, we need to make sure that the cost experience is the same for developers. It's not scalable in the current state. So what are we doing

about it? Um one of the things we announced about a couple months ago, I could be off on that timing, is something called dynamic pricing. You might say all pricing is dynamic. um we're working on our naming plans, but really really simply what this means is we're going to make the pricing algorithm on arbitrum chains a little smarter. So first of all, right now the pricer that's used on arbitrum one and all arbitrum chains is mostly responsive to the cost on the parent chain with about a 15minute delay and it's optimizing for the price of gas generally. So, as I mentioned, when gas gets more expensive, all transactions for all users get gets more expensive.

But in reality, sometimes as a chain owner, you might want to optimize for smoothing the price over a longer time horizon. If the price goes up very very quickly in a small period of time, you might not want that change to be reflected to your users immediately. You might you might want to manage that over a long time horizon, right? Over the next 30 days, we're going to recoup those costs to make the price more stable. So giving that flexibility to change is really important as different business models start to permeate. So again the important thing here is just we're going to be introducing better ways to ensure price stability with resource thresholds over different cadences. You know thinking about storage ops per week or call data per second. You can configure this a little

more easily once we introduce this. The second thing is when you're submitting a transaction for developers in the audience you know there's lots of different op codes in the EVM. They're all priced differently, but there is a kind of universal gas cost. However, when you think about it, or for those of you not familiar with this, at the end of the day, gas is just a representation on chain of the cost of the cost of running a node. And running a node when you're running it on your say your computer at home or on a server in the cloud, there are different costs associated with different things.

Particularly, there's a large difference in cost between storage and execution. The more data that goes on chain makes it harder and harder for individual node operators to continue to run their nodes, particularly if they're running archive nodes. And that is a lot different in terms of compute costs versus just raw computation doing a bunch of cryptographic signatures all at once. So we're going to make this easier to price between different op codes. We're still working on this heavily in the research side. It's interesting in how kind of balanced the current network is um across all of Ethereum in terms of what resources people are using, but this is because again the gas is currently a universal price. So we're going to be updating the price here to charge based on the most tightly bound

resource at any given time um as an example. So again goals at a super high level are to raise the gas targets on arbitum chains. All teams have gotten more aggressive about this without really, I think, being honest with the public about how much this is costing them and third parties and increasing the centralization risk on chains. We're trying to do this sustainably by making it easier to configure. Um, and we want to make chains a little more responsive to call data demand when or blob demand uh when things go up. Um, so another thing that we're working on and just to kind of like share some information are batching improvements. So for rollups, what the core, you know, architecture change that was introduced when they first launched was the idea of batching

transactions offchain using something called a sequencer and posting those to the underlying uh settlement layer in a batch. Um, right now if there's a lot of chains and there's volume discrepancies between a few of them, if I'm a chain with one transaction and I want that transaction to settle, but that's all that's happening on my chain, I need to buy uh part of or a whole blob on Ethereum to get access to that security and to have that that transaction be considered final. So if there's a bunch of these chains with not much volume, they can actually share that resource together by using what we call a shared batch poster. It's quite simple. It's just sharing resources together. Right now, this is not done in production

anywhere, but it's a pretty simple concept and we're looking to roll that out at some point. What this also does is, you know, and in addition to helping to secure finality, you can also amortize costs across a bunch of these chains by having them share that resource. The other thing is right now we're seeing slow growth and continual growth however in other data availability layers. Um Ethereum obviously historically has been used for settlement and DA but there have been a bunch of other networks that have launched to try and solve the problem of storage being expensive. We'll see how this plays out. My view is that most of these you know pieces of technology will essentially become the same price over time and we'll all hit the same scaling issues. But when there are different economies or different networks to

choose from with arguably the same security model as a chain, why shouldn't I be able to post to different ones as long as my validation mechanism or the challenge protocol knows where to pull data at at a different period of time depending on if there is a challenge. So again, getting a little bit too in the weeds here, but think about it this way. If Ethereum costs 5 cents and Celestia costs 4 cents, I might want to use the cheaper option at that point in time if I'm comfortable with that trade-off. So thinking about how we can enable chains to make that decision.

Okay. Um so I'm realizing that somehow a few of the slides that go over the uh agenda have just been removed from the presentation. So apologies for the lack of transition here, but I'll cover that myself. So, another thing that we're working on, I just went over cost. Um, right, it's important to make sure that costs are scalable for users. The other thing, and generally, I'm not going to go too much into here, but I just want to walk through an example of how complicated it is to send transactions across chain. So, who in the audience here has had money on one chain and you want to buy something on another, right? Okay, awesome. So, you're familiar with this. It's not the best experience. A lot of teams are working on this. We're pretty much near a position where this will largely what

I'm about to go through be not a problem. However, just to illustrate this, I want to, you know, buy something. Let's say I have money on arbitr. I want to buy an NFT on base. My friend just launched a collection. I'm really excited about it. So, I have to make that decision myself. Obviously, I navigate to their website. Then, I got to connect my wallet. Maybe that takes one or two steps. Then, I got to okay, I need to navigate to a bridge page. maybe the website or the application developer has created to let me withdraw my funds from arbitrum and to put them on base. Now I got to sign that transaction. I've got to go back to the project page. If if for example the project doesn't have a bridge, I need to go to another bridge like one we host. And then okay, well

what if I go to this other chain and the contract to buy the NFT only accepts a certain type of token or the network I'm buying the asset on has a different fee token than Ether. Now I have to get that fee token and swap it. I have to prove it and I have to sign it and then I finally receive the asset. And so if you bundle a few of these things together, I know there's only uh eight blocks, but nine plus steps to buy an asset on another chain is not a good experience, right? When I check out on Amazon or any website that has Shop Pay enabled, it's about one step and it texts me my confirmation code if I've used it once before. So the flow of buying things which is again trade what this technology was built to do is bad.

Um and as we see fragmentation this is only going to grow in complexity. Not to mention and there's a prettier version of this. Um not to mention when you're doing this there's no education given to the user about the security model of the chains they're moving between. You have no idea what the underlying bridge architecture. So how did my money go from one chain to another? As a new user, I'm not informed how that actually works or who I'm trusting, especially if I'm going quickly. And that's already stacked on top of the existing risk we've had the whole time since these smart contract technology chains came out. There's smart contract risk.

There's legitimacy risk. Uh when I spend that money, when I get this asset, how do I know the project is not going to rug me? So there's a lot of risk in this system. Um and it's important that we think about this. So again, I can't cover all of this in one talk, but I wanted to illustrate that this is a large challenge. a lot of teams are working on including us. What are we doing about it as a developer of a core protocol? Well, a few things. One of the things we want to work on is making account abstraction infrastructure a bit easier to get. When you roll up a chain, uh, so roll out a chain, you have to choose a stack, but you have to go and find an additional service or a set of services to enable things like sponsoring fees for your users or

supporting alternate gas tokens or bundling transactions like approving and signing into one transaction for your user. That costs money, that takes time, that has you have to go whole new due diligence process on a service provider. That's difficult and sometimes thought about way too far down the line when you're trying to bootstrap a business. So you want to make this a little bit easier. It's also made much more complex with gas sponsorship for example because if you want to let users pay in say all you know various stable coins for the underlying ether costs someone has to manage a treasury right how am I going to make sure that I have enough inventory to pay for the users especially when as I was just talking about gas prices are volatile what if I'm using an asset or allowing users to

pay an asset that has a very weird price relationship with ether that's difficult and why we haven't seen this being rolled out at scale across a lot of apps So mostly just to say we're working with a lot of these partners by com by economy zerta of Alchemy Pimlo to think about how we can take some of these services and make it easier for chain owners to make that decision to spin that out as a default when they launch. And just as a last point on this delivering the best experience you know in concept it doesn't matter if it's too hard to enable for your users. So we're trying to make this easier.

And a quick thing just for devs in the audience. Um it's a very simple graphic on the side. Um but right now on arbitrum chains a lot of operations that are dealing with the inbox or the rollup transition um the state transition function are handled in smart contracts on layer 1. A lot of this is you know obviously for the reason that you want to have all the data associated with the chain stored on the most decentralized layer. But a lot of it is just inventory management, some you know data processing that doesn't need to happen onchain and is a lot simpler and cheaper and more accessible if the nodes just handle it themselves. The L2 nodes that you can run as an individual operator.

So what we're introducing is something called the message extraction layer which is just a series of read and write protocols between nodes that that that operate today on L2 which will make it easier for projects to you know access information like batch and block data for the chain that you're syncing with. So rather than having to pay a fee on L1 to get this information you can just call a RPC function directly to any of the nodes in the network and you'll get that data. This is cheaper for developers. It's cheaper for chainosers, chain owners. And right now, this is part of the cost that is, you know, amortized in the operation of the chain.

So, users actually indirectly pay this fee. This makes it cheaper for everyone. This is something that will come hopefully by the end of the year. Okay. So, I've gone over cost, I've gone over ease of use. Um, the last thing I want to talk about is speed. So, obviously chains are great if they move quickly. That's one of the value propositions that arbitum has done really well. There's a few dimensions of speed I'll cover. One is finality. So how quickly a block is final, including underlying settlement. There's a lot of, you know, variables there. Response time. So I'm making a call to an RPC. How quickly do I get that back? And block production. So how quickly do orders of transactions get turned into a block? And I have an, you know, a notion of ordering. So faster is always better, but it's always more expensive. And, you know, again,

cost is primarily the main thing we're trying to solve for in this industry. So let's talk about block production and response time. With block production, it's largely a function at this point of resource management optimization. Arbitum chains today support a 100 millisecond block times like in trading. Obviously, if you want to go down to 1 MS, if you can break the laws of physics across a globally distributed network, um that would be great. But that's really really difficult. And what we've seen today is that 250 milliseconds, which is what arbitum one operates on, is pretty good and if not the best that you can get. Some teams put this out lower, but if you want to optimize for this further, it just means spending more money on the hardware or making a more optimized setup across nodes. I think the other thing that people

usually forget is that the more blocks you're putting out, that means that's more, you know, compute and storage cost on everyone running a node. So, the more decentralized it is when you want to crank up the speed, uh, that cost for everyone. And that that's literally the problem that Ethereum is dealing with today. There's obviously more innovation here through things like eraser coding or uh data sampling like we're seeing with pure being rolled out soon on L1 but it still increases costs for everyone. So again I mentioned you know arbitrary right now has quite fast block times and there are you know things that we can do to optimize it which we're working on but actually in speaking with a lot of projects this is good enough um particularly when you're doing uh trading between parties or conducting arbitrage you need time and between

seeing the block and putting in your next transaction to calculate what you want to do what is the order you're going to put in how much time okay all right I'm going to go really quickly here So talking about speed. All right. Response times. You know, you want to get a faster response from the network. That's really just something that is is, you know, a distributed systems problem. The issue with this is if we make the network faster or or, you know, as a chain or I make my network faster, everyone running infrastructure needs to spend more money to sync the chain. It's not uh a great relationship to increase centralization on one party the faster you want to go.

All right. Uh really quickly, we're working with Aragon and Nethermine to bring new client types to arbitrum. I think one of the beauties of blockchains is that you can have different teams working on different parts of the stack. Aragon very fantastic archive database performance. Nethermine pushing the limits on throughput. Being able as a chain orderer to choose I want this node for archive. I want this node for chain tip sync speed is a great ability and something that's really uniquely possible in blockchains. So we're trying to target, as I mentioned, going down below 100 is harder, but we're trying to target 50 and allow users to choose um improvements without lockin. I'm going to go uh just through this because I'm being told that I need to wrap things up. But we're working on a few things for interoperability. Uh we're working

on hybrid CK proving. Uh the great thing about this is right now optimistic proving is free for users. If you want to go faster and you can prove with a zero knowledge proof, you as a party that wants that finality can pay for that. That's a great ability. And also right now when you want to send messages outside of a chain, which is really what we're trying to solve for in a huge network state, uh you're relying on an underlying settlement layer. But what if you can facilitate peer-to-peer agreement directly between two parties that are trying to trade though? Something to think about. So we want to speed up finality and reduce time to rebalancing for solvers for those of you familiar. All right, I'm going to keep going really quickly. Okay, so you can read this um few things. Where are L2s going? Where's infrastructure?

Sovereignty really important. Everyone wants to capture value. You need to ensure that chains have flexibility to make decisions to meet the business need, but also ensure that they have access to this most secure uh technology that they can use. Maybe they want to opt into other governance models. Maybe they want to run their own. Make it easier for them to do that. That's something we're working on. Um, I think value sharing is important. Networks that have the most flexible ordering policies will win. It's really important that you enable chains to be able to do that and capture value in their own way. Sharing rewards with validators is something that's not done on L2s today.

I think that will change. And I think also the notion of an L2 or chain will completely disappear from nomenclature except for at maybe developer conferences and apps and ecosystems will win. The chains and teams that embrace this will lead. All right, a few things uh just to leave you with and then I'll be done. I promise. One of the interesting things we're seeing, uh, Ethereum embraced free market capitalism and said, "Hey, all you teams can innovate and we'll benefit from all of your innovation." At the same time, saying, "We want to move away from the capitalist structures that created the financial markets that do not act in the interest of users." And now we're seeing the same exact problem that we saw in Trafy emerge in crypto, where you have a bunch of different parties all seeking

to capture the same value. Can we escape it? How do we move on? How do we move from once being partners to now trying to compete for the same value? This is going to be the problem of the next 5 to 10 years and we're going to see a lot of friction with it. Um, good luck. The the last point I'll make is that Okay. Okay. All right. I'll stop. Stable coins are going to be important as we know, but centralized parties control them. So, that's also going to be a problem. Thank you all very much. I'll talk to you again. Sorry. Just got to got to keep it.

[Music]