L1/L2 Scaling Roadmap

Transcript

All right, thank you very much. Uh my name is Marius. I'm with the Ethereum Foundation. Um I work in the guest team, but uh very recently we started this new track system. And within this this three new tracks, uh we have the scaling track and uh I'm co-leading the scaling track together with uh Ansgar and Rolle uh from the Ethereum Foundation. And today I'm going to talk to you a bit about um scaling. Um I I took the slides from an old talk, so the the title is wrong, but this is L1 L2 scaling.

If this is not the talk you want to see, then um stick around. It's going to be very interesting. Um yeah, so uh as I said, um the Ethereum Foundation last year started having three focus areas. Uh last year it was uh scale the L1, scale the L2, and uh improve user experience. Um and this year we have decided to put together the LD uh scale the L1 and scale the L2 track into a single track called scale.

And we have uh we have decided to introduce a new track called hardening. Uh where it's about making Ethereum more secure and uh better. Today we're going to talk about the scale track. Um the scale track uh consists of many different uh different projects and different topics. Uh I have um put some of these topics here. Uh and I will uh I will uh talk about some of them, like a subset of them. Um but [clears throat] um yeah, let me start with uh 100 million mainnet gas limit. This was the the name of the project last year.

It's changed a bit. Um we are not targeting 100 million, but we are targeting higher gas limit and uh the future of pricing. So why why is this important? Um as you can see, this is the average gas limit over the last um ever. Over the last uh Uh yeah, since 2015 when the chain was started. And you can see here uh in the last year from uh 2025 to 2026, we have uh doubled the gas limit from uh 30 million gas to uh 60 million gas per block uh at maximum.

Um and if you look if this is a it's a on a different time scale, um but this is the last um 2 years. And if you see over the last years, the ever the average transaction fee was less than $1. And that is because we in created increased the gas the gas limit. >> [snorts] >> Uh the problem with uh just increasing the gas limit is that it makes some of the worst cases worse. So we have operations that um that can very reasonably work in the 60 million uh timeline, and we have operations that would if if you would fill a block with

it, it would take about 3 seconds to execute that block. Um >> [clears throat] >> so what we need to do and what we're going to do for for Glimesis Dam is repricing. So you can see here um these are like this is the KZG operation. The KZG operation right now roughly runs at 20 mega gas per second. So if we would fill a block full of KZG operations, we would a 60 million gas block we would um yeah, we would need 3 seconds to execute that block. Um in the structure that we have in the slot structure, we have around 3 seconds to execute the block. So 60 million is

fine. But if we want to increase the gas limit beyond that, um to let's say 100 million, then executing the the block would take 5 seconds and that would be bigger than the time window that we have in the slot. Um so what we need to do is we need to make KZG more expensive, three times more expensive. Yes, the slide is a AI generated and it's wrong. Um but yeah, I'm sorry. I I did these slides this morning um because I was busy, so uh Yeah. Um if we increase the the price of KZG 3x, um then the slowest operation that we

have is at 60 mega gas per second. Um what we could then do if we still have the the budget of 3 seconds, we can fit 180 mega gas per block. Um and so this is what we're trying to do in Glimesis Dam. Um we we proposed a list of a lot of EIPs um that are that are trying to make sure that the resources are properly priced. Um and the problem with with KZG in this point in this case is it is not properly priced. All of the all of the other operations are better priced, but KZG is kind of uh

mispriced. So if we reprice KZG, um we have a more we have a we have a better picture and and we can increase the gas limit. Um All all of these EIPs that I that I wrote down here, um those are the EIPs that are considered for inclusion. I think some of them are already scheduled for inclusion in Glimesis Dam. All of these are being prototyped. Um and they basically try to make the resources that we that we use match or like the the the the cost for resource match the gas that we price them at.

And um EIP 3070 uh also unlocks the state creation uh from the state from the normal execution gas. Um so what we what we want is we want to make sure that if we increase the gas limit, the state growth does not increase. We want to we want to be able to price those two resources on a different dimension. We want to make sure that the state only grows at 100 gigabytes a year. Um but we want to make make sure we can increase the gas limit um to increase the amount of execution that can be done um uh in that time.

What we needed for that was a set of test cases. Um and we created this tool called benchmark core, uh which has around 4,000 tests for compute and around three two two and a half thousand tests for state uh operations. And um as you can see here in in this test, the roughly 1,100 tests uh that are executed, and you can see some of them are below the 60 mega gas threshold. And those are the operations that we would need to reprice in order to um in order to to make sure that uh we can uh securely run the chain at 60 mega gas per second.

Um so our goal was when we started this project last year to reach 100 million gas uh 100 mega gas per second. Oh, sorry, 100 mega gas per block. Um Uh by the end of this uh by the end of uh by the [snorts] end of last year. We're not there yet, but hopefully with the Glimesis Dam repricing, we can be um be there. So right now we have 3 seconds block time. As I as I said, like this is this is the time in the in the in the slot of the of of of the 12 seconds that we have for the slot time, we have around 3 seconds that we can use for executing the block.

We have a throughput of 20 mega gas per second. That means um overall we can actually execute six 60 mega gas worth per block. Um now with the repricing, we still have the 3 seconds. Uh we but in instead of the 20 mega gas per second throughput, um because we we reprice all of the operations that are slower than this, uh we end up at a 60 mega gas throughput. That means with the repricing alone, we would be safe to go to roughly 180 mega gas per block. And now with EPBS, uh which gives us more time in the slot to execute the block, we can roughly go from hopefully

This uh still quite unclear with the way the EPBS EPB EPBS spec is evolving, but hopefully we could go from a 3-second block time to a 5-second block time, which would mean we can roughly go to 300 mega gas per block. Um which would be a 5x increase from the from the state we are in today. Um and a 10x increase from the state we are in last year. Okay.

>> [clears throat] >> So um we have an we have a few other things um that that I wanted to talk about, especially for stakers. Um the the thing with the with the pricing is you don't need more hardware. We are going to utilize the hardware better, the existing hardware better. And um this is this is our our main idea with the with a short-term scaling stuff is that we want to make sure that the hardware that we all have for staking is going to be utilized better. Because if you look at the if you look at any graph of your of your node, you see every time there's a block, there's a spike in CPU, and then there's basically nothing, and then there's a spike in

CPU, and then there's nothing. And now we want to make sure that the the hardware is consistently used. Um history expiry. I think most of you already know that uh we shipped history expiry uh the the the pre-merge history expiry by uh I think middle of last year, end of last year. Um and since then we have also created a new specification called RIE. Um and the RIE spec also drop allows dropping the post-merge block blocks. Previously, we could only drop the the blocks until the merge,

um but now we can drop basically everything until basically the head. And this would reduce uh node sites sizes by over 600 GB together with the pre-merge blocks. And from the state we are in right now, if you have already pruned away the pre-merge blocks, you would gain another roughly 300 GB because of RIE. Um and this has been implemented in Nimbus and Geth already, and other clients are looking at the at at implementing it as well. And if you want to find these files, uh we are also um uh seeding them uh over at the EthPandaOps team.

>> [clears throat] >> Another topic that um is important for Glimmer Shadow, and also maybe important for node runners is block access lists. Um basically um this is roughly how we are how we are executing a a block right now. We take a transaction, the transaction has uh state access, state reads, and execution interleaved. And then at the end, we have some state writes. Um the state writes are are cached, and uh and they will be written to the disk at some point. Um uh the problem with this sequential execution is that um well,

it's sequential. Takes a long time. Uh what we are doing with block access lists is uh we front-load all of the state reads. Um and they can actually happen in parallel again. AI created uh picture. It's not really not really the right thing, but uh the um the the reads can happen in parallel, um and the execution can happen in parallel. So, all of the execution can all of the transactions can be executed in parallel, and at some point there's a state writes.

Um >> [clears throat] >> And uh we The problem uh well, like what what what we get through block access lists is multi-thread verification. Um what we are still sacrificing is a miner still needs to do the sequential um block creation, and he needs to create the block access lists. So, there's a bit more load on the miners, but it's kind of neg- negligible, but there's a lot of load taken away from the from the verifiers. Now that uh around 90% of I think more than 90% of blocks actually come from from from MEV, um most of the time that a local node is uh

is spending is spent in verification, not in block creation. Um And uh roughly the bandwidth for the bell is in line with the block size, means um we are roughly doubling the size of data that needs to go through the network. Um uh for the block, um but that's it's it's not that much. And uh what we've seen is we observed a roughly 3x uh speedup on a four-core machine. Um so, it doesn't completely scale with the number of cores, um but uh very closely. So, um that's pretty cool.

The last topic that I wanted to talk to you about is uh EthP2P uh networking specification. Um This is where we're at when it when when when it comes to um to uh blob increases, so for L2s, um we need to increase the amount of blobs per block. Uh we are currently at a at a target of 14 and a max of 21. Uh there's again a 1559 mechanism. Um and we would like to increase uh that slowly over the coming years. Uh don't take a picture of the dates. They are again AI.

Um but uh if we are seeing that the that um that the utilization of blobs um >> [clears throat] >> uh is uh blobs are fully utilized, then we can increase the the the >> [clears throat] >> the amount of blobs per block, um which increases the bandwidth uh consumption of your node. Um and what we are trying to do again- against that is uh EthP2P and data layer improvements. EthP2P is a networking stack specially built for Ethereum. Um it builds on top of the libp2p uh spec.

Um and part of it is the erasure-coded broadcast um that can reduce the amount of data that you have to send around. Uh and it's based on quick. Um and the early experiments are significantly faster than what we have right now, especially for bigger network bigger packages. And uh hopefully this will allow for more data availability or data traffic um both in the amount of uh call data that we can uh allow in in the networking layer and the amount of blobs that we can allow.

And um yeah, this will be rolled out. Uh if you look on the straw mech map, there's a like a whole track on that. And um yeah, if you are interested in this, you can go to EthP2P /ethp2p to learn more. That's it. Thank you very much. >> [applause] >> I think we have like one or two quick questions. I had one. Just to follow up that kind of tie into the earlier conversation, you mentioned that um you had a goal of increasing the amount of blob space. Um do you see a need for that? Uh or could we wait on

that before increasing the throughput? Um the amount of blob space or the amount of block space? Blob. Um yeah, right now uh we are not seeing the the blobs the blobs being fully fully utilized, and I think uh until then there's not um not such a big need. Um but uh we always have to be forward-facing, and uh I think um even though the roll-up-centric roadmap is dead, L2s are still a very important part of Ethereum, and they will be uh even more important in the future. And um hope- hopefully adoption on L2s will rise, and that will um necessitate us increasing the the

the blob throughput uh as well. And additionally, in the future, there will be um there's a project called uh block in blobs, and the idea is to uh use the same mechanism that we currently use for blob dissemination around the network to also use for block dissemination around the network. And um that would allow us for significantly bigger block block sizes, and to um to to also get the gains from EthP2P for the block dis- distribution.

Another quick one? All right. Thank you very much. >> Thank you.