Marius van der Wijden - Sustainable Scaling

Transcript

Thank you everyone. Hello, my name is Marius. I think I know probably half of the audience already. So, it's uh it's great that you're here and you're supporting me. And today um I will be talking about sustainable scaling and uh how we at the Ethereum Foundation think about scaling um and how we think we can scale Ethereum uh without making it um impossible to run uh run nodes. So uh we recently had a bit of a restructuring of the Ethereum Foundation and we came up with these three tracks. Scale the L1, scale the blobs and improve user experience. Um I together with uh Tim and Anska we are leading the scale DL1

track. Um and we have several projects on this track um that we think are blockers for increasing the gas limit and scaling scaling the L1. Um I want to talk today about three of them uh and introduce uh introduce them to you. The first one is uh is history expiry. Um we have already shipped history expiry. If if if you don't know, we usually um we usually speak of the state as the current state of the network. So all of the accounts, all of the balances, everything. And we speak of the history as all of the blocks that happened

before that led up to this state. Um and we recently shipped in all of the clients we shipped a partially history expiry. uh which means that all of the premerge blocks and receipts can be forgotten by nodes. Um this will reduce your uh node requirement by 300 to 500 GB and uh it's already implemented by everyone. Um probably most of you have have heard of this before. Um and now you can still run a node under on a on a two terbyte uh SSD thanks to this. um it was a bit slow. So maybe you have already upgraded to the 4 terabytes. Um

but this will make sure that you don't need to upgrade to the 8 terabytes anytime soon. Um and then uh the next step of history expiry is full history expiry uh where we need a new era e format. Uh this is the format where we can store the history and we can also retrieve it from uh either decentralized or centralized stoages. Um, and this would also in full history expiry expiry, we also plan to expire everything after the merge up until one year ago. So nodes would only need to keep the last one year of uh blocks um uh on on disk and this would uh further reduce your node requirements by an

additional 300 to 500 gigabytes. And that would also mean that the node requirements uh are not uh increasing as much as they as they used to. Um so the requirement for disk space for a node should be increasing much slower than it uh than in the past. And one thing that we are also working on uh regarding history expiry is um history retrieval because even though most validators don't need the history anymore um some people do or some people still want to to look into the history um and they need a way of getting that history and we uh already have

centralized history providers um that have this history that provide this history for you. Um but we also uh and we also have some decentralized outofbend protocols like bit torrent um like uh some other uh some other solutions where you can uh get your history from in a decentralized way um but they are not part of the nodes yet. And uh we are also thinking about a purpose-built uh decentralized protocol where your node can uh ask for certain uh a certain range of blocks if you um if you're interested in them. Okay. So the main topic of this talk is uh is not

going to be about history expiry u but it's going to be about uh the 100 million mainet uh gas limit and the future of pricing. Um those are two topics uh two projects. So we we kind of when we started the track we kind of discussed which projects we would like to uh see being worked on and which which things we would uh like to see happening in the future. And um the future of pricing and 100 million uh the 100 million mainet gas limit was the first big project that we had in mind.

Um and in order to solve that, in order to get there, um we need uh we need significant changes. Um first of all, a little prime primer to why or or how uh some explanation of some of the things that we that we will be talking about in the next couple of minutes. Uh within the node, we have we have the EVM. The EVM executes all of the smart contracts. We have uh certain operations in the EVM uh like addition or multiplication. Uh these operations cost gas and they are priced roughly on how hard they are are

executed uh are to be executed. Um the problem is this pricing is uh not very dynamic. that was set once 10 years ago and for most of the operations it has stayed the same since then even though we have different hardware now we have different improvements um and then we have three different categories of um resources that we have in the nodes uh data compute and state and we usually when we think about these EVM operations we categorize them by one or two of these um these resources that they uh that they use. Uh so for example for the

data we have uh operations that impact the bandwidth like for example call data like log um like the transaction itself. um for compute or the the access list for example. For compute we have operations that use processing time like addition, multiplication, jump. And for state we have operations that either grow or read the state. So uh create s load, sore, create two, all of this. And um and then the gas limit limits how many of these operations can be done per block. And uh this limits uh this is for DOSS protection because otherwise you

could just send a transaction that would take 10 minutes on every node to execute and that would be kind of unfair to everyone else. So we have to limit the size of the blocks and the gas limit implicitly also limits the execution time and the size of the block. And um if we increase that as I already said it might uh might mean that some nodes are not able to execute the block in time anymore because we are producing a block every 12 seconds and there's like atestations uh after 4 seconds and then uh aggregation after another 4 seconds.

We have roughly three three and a half seconds to execute a block. And um this chart, one of the one of the good charts on on Etherscan, uh this uh shows us the uh average Ethereum gas limit. And as you can see, for a really long time since before, uh since 2021, mid 2021, uh it kind of stayed the same and we have recently started increasing the gas limit. So uh what you can see here on in the far left corner is an increase from 30 million gas to 45 million gas. And um what does that mean? Like it basically

means nothing but this might actually mean something to you. Um because this is the same the same time frame. And in this uh same time frame the average transaction fee over the last year has decreased to less than$1 uh dollar. And um so we we are at 45. Um but the question is can we go higher? Can we do more? And um how can we do more? And the problem is always we have a lot of operations like here here we we uh assigned them like in this star kind of format and we always have to identify

the worst case operation. um because we if if someone just sends a block with all of the worst case operations, um that block will take very long to execute. And so we need to make sure to limit our gas limit um to the worst case. And uh we so what we do during the during the 100 million gas uh project and the the repricing project is we try to identify the worst cases and once we identify the worst cases we try to optimize the worst cases. We try to go into the clients and see okay like I don't know addition takes too long there's something wrong addition on this one client takes too long it takes like

three times the the this the the time that it takes on other clients so we are going to optimize addition in this one client and um what we can then do is we can raise the gas limit and uh we will see the next slowest operation. Um the problem is we cannot always just go into the client and and fix things. Some things are just uh the way they are. It is uh very hard to make an addition much faster. Um it's just not possible.

There's only one way to do it. Um but what we can do is we can repric some of the operations. As I mentioned before, every operation is denominated in gas. So if we change the amount of gas that that an operation take uh we can kind of homogenize uh these operations and with that we can again increase the gas limit. Um what we also are thinking about is homogenizing the operations across the different resources. As I said we have uh data, we have compute and we have state.

And um right now we are limiting them with the same gas limit. But that means if there's an edge case in compute, it means also that um there might be uh an increase in data that we could do that we in theory that we cannot do right now because we are limited by this one uh by this one edge case. So hopefully in the future with repricing and multi-dimensional metering we can get uh all of the resources to kind of match each other other and um how are we doing this? Uh we have a we have built a comprehensive benchmarking suit or we are building a comprehensive

benchmarking suit. Um and the idea of it is it will be available for all Ethereum clients and it will also be available for all L2s because they face similar problems. It's a bit easier for them because they can just scale up the nodes. They can just scale up the uh uh the sequencer. Um but uh in theory the same the same problem uh happens to them as well that there are some operations that might be really really hard that they cannot get rid of or that they cannot repric. So if we repric, we also repric for all of the L2s. And uh this benchmarking suit is part of the uh EST, the east um testing efforts. And

oh well, I I thought there was there was supposed to be a picture here. Uh anyway and um yeah we are proposing a bunch of repricing EIPs um for Amsterdam uh for the next hard which are trying to change different values where we think we can then increase the scale. Um, for example, so uh 87 is uh is a meta EIP that contains all of the different EIPs that we that we think. Um, and most likely we will not be able to ship all of them. Um, but if we ship the most important ones, we have

like kind of a an internal ranking what we would uh focus on first. um it uh it would already greatly improve um the scale of Ethereum. So uh how can you think about this? How how can you think about what what we're doing? So this is um this is a screenshot from our benchmarking platform. Uh here you can see the here you can see the test names but we have so many test names that you cannot read them right now. But um you can see the test names and you can see how much um meagas per second um they are uh they can run it and if we like draw a line we can kind of draw the line

here. So this is this is roughly what we can do per second. Um what we want to do is kind of repric and and what this also shows that there are a lot of operations that could theoretically run at 3 gig gas um but we cannot run them at 3 gigas because we are always limited by these uh by these operations here. What we would like to do in the next half a year is we would like to take that line from I think it's about 40 megs per second that we can do right now. Um we we would like to take that line to roughly here where it's about 120 or 140 meg uh per

second. And that means all of the operations that are where you can see that are like lower than the line we would need either need to optimize them quite heavily or we would need to repric them. And that that is what we are trying to achieve in glm. Um okay so where should the where will the journey take us? Um as you've seen on the on the first uh on on previous slide I I showed the gas limit and we were at uh 40 million g 45 million gas. Um we have uh already done a bunch of uh repricings in Fusaka and we will be able to hit uh six 60 million gas um by Fusaka. So all of

the clients have already introduced this G gas limit increase in their releases for Fusarka and we hope that in the next year we will be able to hit somewhere around 140 or 150 mega gas. Um because of the repricings gas might not mean the same thing anymore. uh we might change the way um a lot of operations are priced and so it could be that we are that this number might change that it's not 150 but it's 300 or 500 um but what it what I'm trying to convey here is this

is roughly in today's gas with today's schedule this this is roughly what we expect uh happening over the next year. All right. Um, if you're interested in this and you would like to contribute and you think this is really cool, um, join us. Uh, we are always looking for great people for the Ethereum protocol fellowship. Um, there's a there's a study group where you can permissionlessly join and there's a program um that runs I think twice a year. um once a year. No, sorry. Um where uh where you will be able to get some resources and you will be able to get mentorship and you will be able to work on some of these hard problems and

uh yeah, thank you very much. Uh that was it. Excellent. We do have about two minutes for maybe one question I see right here with Thorston. Hey Marius. >> Yes, >> this is Torston. Um, I I hope I didn't I paid I hope I paid attention. You didn't already answer this. Do you have a rough timeline for era e and more expiry? >> Um, the e is currently being prototyped. Um, the uh it's going a bit slower as we would have liked because people just have been

stuck with fusaka work. Um but uh yeah I hope within the next two or three months we will have um at least one or two working implementations and uh then we will push the other clients to also implement the the new format and also implement this um this like trailing uh window expiry. >> Excellent. Well, thank you very much uh for it. I think we're uh at time here for questions, but Mary Seal will be available just outside.

>> I will just stand outside if you have more questions we can discuss for the rest of the day. Thank you very much. >> Perfect.