Glamsterdam Ethereum Hardfork: Deep Dive

Transcript

Hello and welcome everyone. My name is Peter Robinson and today we've got Maria here who's going to tell us about the next um Ethereum hard fork Glampsterdam. So before you present your slides, Maria, please introduce yourself much better than I just have. >> Hi, hello everyone. Um I'm Maria and I'm a researcher at the Ethereum Foundation. Um I'm currently working uh closely in the next fork sodam which will be the topic of of this call and I've been involved in a set of um EIPs uh focus on repricing gas repricing. So this has been my my main focus um in the last uh

year let's say um but I'm also doing some research related to state. So understanding like how the state uh the E state not the the consensus state but the the the the execution state should involve under uh um higher throughput. So as Ethereum scales like what do we need to to to to do to make state still feasible. So um yeah that's also something I'm currently working on. But yeah for today the talk is all about Blsterdam. So yeah let's let's dive into it.

>> Yeah awesome. Can't wait. >> So, I will share my my slides now. >> Yes, please. >> Okay. >> Yeah, the slides look awesome. >> Is it okay? Perfect. Um, so, uh, as I was saying, I'm going to talk about Clamsterdam, which is the next fork that is scheduled to hit mainet in December. Um, we've been working on it for almost a year, a bit more than a year.

Um, and yeah, if throughout if you have any questions, just stop me and ask ask your questions. I I won't be following the chat too closely. So, please just just raise your voice and and ask. Um, that's that's completely fine for me. Um so what we'll cover um I will start by giving like an overview of what Clamsterdam is about what what we're trying to achieve with this fork. Um then I will deep dive into the key features. So this is what we call the headliners. They are like big things that the fork cannot go forward without these these two features. Um and then I'll start to deep dive into more of the EL or the execution layer um component

which was the part that I was more involved in and specifically on repricing. So how can we actually scale safely and then what what was the work actually involved in in repricings? Okay. So what is Glamsterdam about? Glamsterdam was really about scaling. So um Ethereum is great but we didn't had a lot of throughput um and so we wanted to raise the base throughput of of the L1 so the whole ecosystem could um could grow as well. Um and in Glamsterdam we are going from a block limit of 60 million um gas to two 200 million. So this means that we are

increasing around 3.3 um and all the key features and a lot of the um auxiliary EIPs are actually going in the direction of of these of making sure that we can safely hit this higher throughput using the same hardware so validators don't need to upgrade. We still have the same 12 second slot. we are just using the resources we have more um optimally. Um and so what is this fork about? So we do have those two headliners I was talking at the beginning. We have one on the consensus layer the CL and we have one on the execution layer the E and I

will discuss them in more detail next. Um then we have the gas repricings which is um what I was telling you about that um essentially I was very involved in and this is a set of of of EIPs that are changing the gas costs of of some operations. And besides this, we have some smaller changes like some qual quality of life EPS such as introduction of some new OP codes and uh deploy allowing now to deploy bigger contracts which was a feature that uh devs were asking for a long time and we are finally raising the the the max size uh contract that can be deployed and also some validators at hygene uh which are also some some smaller things. So I will

not talk about these any of these. So I will focus first on the headliners and then doing a deep dive on the gas repricings. So let's start with the CL level um headliner. So, EPBS um so EPBS stands for enshrine proposer builder separation and the key idea is to introduce an in protocol mechanism for the role that currently relays play essentially managing the me boost auction. Okay, so the key idea here is that we separate the beacon block from the execution payload. Um the execution payload is essentially the set of transactions that the validators need to execute. Um and

the beacon block has as the essentially the metadata about the block. So we are splitting these two things and they are shared and broadcast in the in the network at different times. And uh we also introduce a trustless payment feature that uh allows proposers and builders to exchange payments without having a trusted middleman. And we also have a quite a few changes to the slot which is actually one of the the the features that allows us to to scale.

So looking at the at the process of a block getting chosen and and and committed to. So today with me boost which accounts for almost 90% of all blocks built in Ethereum today um the builder essentially is an entity that is outside of the protocol and they create the payload and submit a beast to a relay. So a relay is another entity um outside of the protocol as well that is trusted. Um, so it's like both the proposers and the builders trust this this this entity and the builder essentially sends the bid to the relay.

So they say, "I have a block and I'm willing to pay X for this block." And then the relay uh essentially forwards this information to the next proposal. They say, "Okay, I have a a block. I'm not telling you what the block content is, but I'm telling you that you will be paid X by this block if you if you accept it." And so the the the proposers wait the beat. They see the beads coming in and then at a certain time they pick the the winning bid and they sign the header the block header that says this is the block I'm going to build. But at this point they still don't know the contents of of of the block. So the execution payload. At this point once the proposer signs the header then the

relay can observe this and then if this is the time where the relay um essentially releases the content of of of the payload and um and then the process normal process um continues and so as I was saying the relay here is a is a trusted party that intermediates the relationship between the builder and um and the proposer. Okay. And we with EPBS we are kind of like adding a mechanism that instead of having this trusted relay the middle in the middle the protocol is the one that kind of mediates this um in a trustless manner. So the way that this happens is that now builders are an entity that is

staked and is recognized by the protocol and they broadcast their their bits to the network and so the proposer can observe the bits. Um and they are not revealing the payloads as with normal me auctions. Um and then the proposer watches for all the bits coming they can come again from um from the network. So as as the stake builders are sending but it can also come from MEF boost. So MEF boost is not necessarily going away. Um but with EPBS we allow like this trustless way of of doing this. Um and then once the proposer uh reaches a certain time they will pick the winning

bit and they build the beacon block. So this um metadata of of of the block and they share this beacon block to the network and so the validators attest that the just the beacon block is correct. So they still don't have the payload. They are not executing anything. They are not saying that the the actual transactions are valid. They are just saying the metadata is correct and looks good. Okay. Um and so once the builder sees that enough at stations have gone by and actually that will be the canonical block then this is the time where they can release the payload.

Okay. Now they they are sure that the the this is the this is the the block that the testers are attesting to and so I can so no one will steal my my my me let's say and then um uh a certain time after um the tester deadline actually the validators also attest to the fact that the payload was made available on time. Okay. And if either the the payload is not available or after execution see that the payload is not valid for some reason then the beacon block is still canonical. So the the

builder still has to pay the they said they would pay but essentially nothing gets executed. It's like an empty block. Okay. And so the the the builder needs to make sure that first the block gets there in time. So the block they are building is actually uh arrives in time and also that the block is valid because otherwise they'll have to pay without receiving their transaction fees and and me. So far so good. Maybe I'll pause here to see if there's any questions. >> Yeah, you answered the question I had about what happens if the um it doesn't arrive in time. So it it's just a blank block.

>> Uh how how does the builder how does the payment from the builder to the proposer how does that get forced to happen if the block doesn't actually get executed? >> So I think it comes from the fact that the builder is being staked and so the payment actually comes from the staking that the builder did before. So before you actually submit bids, you need to have enough money to actually >> be able to pay for it.

>> Okay. All right. That that's good to know. That makes sense. And what did PTC stand for? >> So PTC is um actually now that I don't know. It's the time. It's like I don't know what the P stands for, but I know the T stands for timely. Uh it's like I think it's maybe payload timely committee. >> It's a committee that attests for the timeliness of the payload. I think P is for payload.

>> I know. >> Yeah, we've been saying PTC for so long that we don't even [laughter] know what the what the acronym stands for, but yeah, it's like a a time timelin timeliness committee essentially. It's a committee of a testers that are testing that thing the thing arrived in time. >> Okay. All right. That makes sense. All right. Cool. And looking at the chat, I don't think there are any other questions. So please >> Okay, perfect. Um, so now I want to talk about the actual slot because this is the part that kind of shows you why this feature is a scaling feature. Um, so today the slot looks like this. We have 12 12 seconds, right? Um, but at the at station so the deadline for a validator

to say that the block is valid is at second four. Okay. And so during these 4 seconds essentially we have to propagate the block to the entire network and the validators need to execute the block to attest that the block is valid. Okay. So you have 4 seconds for both propagation and execution and then the other 8 seconds are sort of idle like you you you are still doing some things on the CL side but like you have like this essentially this burst of activity in the network at the first 4 seconds and then the rest of of the block is a bit idler let's say which is not very optimal.

After EPBS, what actually happens is that now the atstation deadline is at second three. But because the testers are only attesting to the beacon block at this point, you don't need either to execute or to propagate the payload. Right? So the only thing that needs to happen in these three seconds is actually for the beacon block to be propagated which is very light. Okay? So the beacon block gets gets um shared among the network. The testers attest at time uh 3 seconds and then after 3 seconds the the builder reveals the payload. So between um second three and the PTC which is the the deadline for

validators to say that the block was made available. Essentially this is all propagation time. So the builder has this time to essentially propagate the block and then after second three the validators need to execute and essentially they have until second 12 because at second 12 the propo the next proposer needs to have um the state route so that they can build the right beacon block for the next slot. So essentially you have 12 like you have this six seconds for the proposer for the next proposer to execute and for the attesters actually is a bit more because they only need to attest at second three of the next slot and this is the time

where they need to know the state route so that they can attest that the the the beacon block they are observing now is being built on top of the right state route of the previous block. So but essentially we assume six seconds because we need to make sure the proposal executes in time. Um and so um essentially now we move from 4 seconds for both propagation and execution to actually 3 seconds for propagation plus 6 seconds for execution. So this is like now actually the slot is being used for the most part and this is a a big boost.

Um okay now going to the uh block level access list which is the uh headliner for the e so the execution layer um what is the key idea here? So um block level access list um add um new condition or this new not the condition but this new thing that the the block needs to come with. So now every block needs to come with a list of all the state reads and writes. Um so this includes all addresses, storage slots and codes. So every time everything is read, you need to say that that thing is was read in the block. And then everything there's a state change.

So a slot that moves from one to two or an address nouns that gets increased by one that needs to be recorded in this list. This is a canonical list. So given a block um we have a canonical way to that to to derive what the block level access list looks like. And then this must be correct. So if if the block level access list is not correct then the block is invalid. Okay. So this is the same thing as like an execution u like a transaction being invalid and essentially um making the whole block invalid. uh block level access lists are built by the builder. So the builder will build the block. Then after the

block is built, they can say which um which uh state was read and accessed and then they build this list and they add it to the payload. So this comes essentially with the execution payload. But why is this a scaling feature? So let's think about it. So today when validators are executing the block they need to do it sequentially because essentially the execution of one transaction can impact the execution of all later transactions right let let's think about it like one transaction changes uh balance on UTS on US sorry uh on like uh I don't know I'm missing

now the word but it's like or for or for instance let's think about it so transaction um changes the their own balance, the dress of their own balance. For instance, they now have two instead of one. And then a later transaction is actually um reading that balance to then decide if they want to do something. Um then the execution of the second transaction actually depends on the execution of the first transaction. And so you cannot really parallelize these two transactions. you need to first finish the first transaction, see the end state and then start the execution of the second transaction. Um, and today we do have some optimistic paralization that clients do and um, it works on the

average case, but the issue is that it doesn't work on the worst case. Like you can always build a block that kind of defeats all these optimizations and makes the execution take much longer. Um on the other hand with block level access lists we can actually execute things in parallel. So first because block level access lists include the read location say they don't have the value. So they don't say slots number x has value y it only says slot number x was read. Um but because you have all the things you need to read from you can actually prefetch. So you can while you are executing you can already start um going to your database and actually

reading the stuff you need to read. So you don't need to wait to the execution to say oh actually I need to read this thing so let me just go fetch it now. So you can actually prefetch stuff. Um and second because we know the end state of each transaction. So what every slot address and code that was changed. um we can actually execute things in parallel without having the previous transactions finish their execution um because we can say okay transaction two actually it depends on transaction one I'm seeing that on on a block level access list and the final state of transaction one is X so I can just assume that I will use

that value for the execution of transaction two um and also So another win is that now updating the state try and calculating state root actually now is independent of execution. Right? With the block level access list we have all the information we need to actually update the try and calculate the state route. And um we can even use this to speed up sync. For instance we have now a new sync protocol snap 2 that actually uses u block level access list to make the syncing faster because you don't need to execute everything. you already have your state div. So you can just apply that state div into your state try and recalculate things.

Uh so far so good. I will maybe stop again to see if there are any questions. >> Are there any questions? Here's a one for you. So are you saying so there's the block access list but is there also for each transaction a transaction access list of what each transaction touches?

>> Yeah that's that's a great question. So before block level access list we already had these transaction access list and actually the idea of the block level access list came from this optional access list. So what this transaction level access list is the way that they worked was that the the user that is submitting the transaction can optionally state which um which access they will make. So it's it doesn't have the state tiffs. It only has like I'm going to to read or I'm going to touch this slot and this address. Okay? And if you did that you would get a discount. So your your actually state access cost would be

lowered. Um and this would the idea is like this is optional so people could use it and get a discount and this would help with parallelization. But the issue is like this is really not doesn't really unlock everything because again we need to price things based on worst case and because this is an optional feature. It can help with the average case but it doesn't help with the worst case and also doesn't have the state tips. So because of the state tips then there's it's also limited what it can do because of this then now in this feature in this fork we are introducing the block level access list which is kind of like an aggregated list of all the transaction access lists

and it has also the information on the state tips and it's mandatory. So actually this covers the worst cases as well like all blocks need to come up with this and if the list is invalid then the block is also invalid and um yeah this is actually what allows us to scale and because of this we are kind of deprecating access lists because they are not needed anymore and the way we are deprecating them is that now like if you put it in the access list just cost the same. So there's no incentive for you to actually add stuff to the access list, the transaction access list.

>> Yeah. Uh Genyang, do you have a question? >> Uh yes, I guess. So um if what what happens? So if I understand correct, right, in the final block, we still have ordered transactions, right? So um what happens um if two like what to determine um the final order of the transactions if we are executing them in parallel because order sometimes matters a lot in terms of like the final transaction outcome. Uh if if you know >> of course yeah and >> yeah that's that's a good question. So

what happens here is that the order there's still a canonical order, right? So when the the the builder builds the block, they set what the order is and that's part of the execution payload. So everyone agrees to it. And if you change essentially if you change the order of transactions, the final state diff would be different, right? Like maybe some transaction would become invalid or or would revert or or whatever. And so while so we are executing in parallel yes but we are reaching the same result as if we were executing sequentially.

And the reason why we can do this is because the block level access lists tells us when I would have started it for for instance if I have two transactions what the block level access list says is if I when I finished transaction number one the end state would look like this. Okay. And so I can actually execute transaction two at the same time as transaction one because I know what the end state of transaction one would have been. So I just assume it and I execute transaction two as if I had executed it sequentially.

Does this make sense? >> Yeah, that that makes uh makes a lot of sense. So uh essentially um can I can I say that basically we've got you know when when we execute the list of transactions we know which transactions are like separately uh from from others like we we have already know that after we executing them so we provide the access list so others can like process it in in parallel to speed up things. Right.

Exactly. So essentially the builder still needs to execute things sequentially, right? Because it doesn't have the block level access list. The builder needs to build a block and then calculate the block level access list. And then >> the validators essentially they are reusing the work that the builder already did. >> Okay. Yeah. Yeah, that makes sense to me now. Yes. Well, thank you. >> Sure. which mean which means that I guess the worst case say there was I don't know some NFT sale or anyway something where everyone was using the one contract and even if it was an ERC20 everyone's using one ERC20 so we all use USDC and then the total supply is say updated in every single transaction or

something like that so that would mean the worst case would be no parallelization because everything has to be executed serially Right. >> Exactly. >> Yeah. Which Yeah. Yeah. All right. Makes sense. Makes a lot of sense. Thank you. >> Sure. Okay. So, um now let's um deep dive into repricings and so and um and let's discuss like how do we actually scale in in a in a safe way. Um so the two headliners give us some rule some room to scale right. So with EPBS we have more time in the slot for both propagation and execution and then block level access lists give us a way to

schedule execution more optimally. So we can run things in parallel, we can prefetch. So this should also speed up um the execution itself. Um however this actually creates some mash between the various operations. Um so for instance pure compute operations get their bigger boost from parallelization than state operations because state operations are bottleneck by IO and execution also gets a bigger boost from EPBS than block propagation. So actually data in relative terms now becomes more expensive. Um so without changing gas prices actually we can only rate the gas limits by the worst op operation um or

the worst performing operation and so this is where repricings also come in. So um repricings you can think of them as like an enabler of making these features actually work um across the across the different operations. But why is this even a problem? So be besides the mismatches I've talked about that are introduced by the new padliners um actually there's already mismatches uh currently so the first time that gas costs were set um the network was very different so there was state was smaller so we were launching Ethereum right so there was very little state and hardware requirements were even like we didn't

even had like a um accepted hardware requirements um for uh testers and full notes which we do today. And also the prices were not based on actually measured performance because clients were still being built, right? And since then even the clients themselves has changed a lot. They like they optimized in a lot of ways. Um they new clients popped up. So actually the the the the whole shape of what Ethereum is today is very different from when gas costs were first set. And so this means that um operations are not harmonized. So the gas costs are sort of okay like they

work for the throughput we have today but they are widely mismatched and so oops um I can show you here a plot. So essentially um in this plot I'm showing you uh each bar. So this is a distribution. So this is the number of operations that are performing at a given million gas per second. And uh to interpret what this million gas per second means. Um so what imagine that you can interpret this way. So imagine that we are building a block where we are just using the same op code. So for instance we are using add add we are using it like many many many many many

many times in that block and we fill that block until the block takes 1 second to execute. Okay so we kind of fill that block until the actual time to execute it would be 1 second. Then we see how much gas does this block have and this is the million gas per second. So it's essentially for instance for an ad I can fit in a second a block of 200 million. Okay. And so you can like this is a good thing to kind of put in perspective because then you can imagine for instance if I had two seconds of execution and all my operations are performing at for instance 50 million um

this means that if I can fit 15 millions in 1 second I can fit 100 in 2 seconds. So this also has like a nice translation between um execution time and the actual block limit. Okay. And so and also to kind of um explain this a bit better. So this means that the higher the million gas per second performance it means the faster the op code is. Okay. So it if you are here in this uh right side of the plot then it means that actually that op code is too expensive right like we are paying too much for something that is really fast on the other hand if it's on the on the left side so the that it has a lower million gas per second

performance this means that now the op code is too cheap so we are actually taking a long time to execute um for the gas that is costing okay and also As you can see like this is the actual measured um performance of the pure compute op code. So ads will um all of these um pure compute and you can see like the variation is crazy like you go from like 20 to 600 which is [laughter] which is crazy right? Um and um actually the the the funny thing is that we don't need to change everything. Like ideally

we would change all the gas costs and everything would be harmonized and everything would be pretty but that would be a big change and a lot of work. But there's actually like a small hack we can do. So we what we can do is just fix the small the the small number of operations that are too cheap. So we can increase a bit the gas costs and by doing that we remove them as bottlenecks right. So now so when you think about it like we need to set the gas limit based on the worst operation right because if we set it at the higher level then someone could build a block with that operation that would actually take longer to execute and it would uh stall the network and so actually we need to

price it based on these all these performing operations. If we actually fix this and we move them to a higher million gas per second, then now we can increase the gas limit and this will just raise the throughput overall. Um so and this is actually the strategy we take we took with repricing. So we just said okay let's set an anchor so a goal for what we want to do in terms of throughput and let's just raise the gas costs of those operations that are too cheap.

Um yeah and this is essentially the whole the whole idea. So the whole idea is we armonize so but we armonize in a smart way. So we are harmonizing just to the operations that are too cheap so that we can raise um the gas limit and then we can also um take performance gains from block level access list take the longer execution time and propagation time from EPBS and we can um get to a higher um block limit. Uh cool. So far so good.

Yeah, I think so. I I think everyone's got them there just waiting to find out which op codes turned out to be underpriced >> um and whether it includes pre-ompiles and which pre-ompiles were underpriced. >> Yes. So yeah, let's let's dive into it then. Um so this is now the glamster repricing package. So what are the actual things we are repricing? So the first uh and I think the bigger change is related to states and this is what expected again as state grows the performance of state access did is worse and so we were already expecting these to be like the the biggest bottlenecks we we we have today and so we did a lot of work on state and for state is

important that we separate two types of resources let's say so one of them is state growth so this is essentially how much we are growing our state. So this is kind of like the rent you are paying for actually using uh Ethereum storage. Okay. And then we have state access. So state access is more the in the moment execution cost of actually reading and writing from state. Okay. So every time you read from state this takes execution time or every time you write to state even if it's not a new slot it takes execution time. So this is the state access cost. Um but also then the state creation is mostly like the

rent you are paying for actually storing stuff on Ethereum. Um and the first E so 8037 is all about fixing state growth. Okay. So giving like a specific cost for state creation and fixing some issues we had um with that while uh 8038 is about state access. So fixing the execution cost of state access operations. Okay. And this covers mostly like stor s loads uh create calls um all these all these hop codes. Um and then 278 is essentially changing the intrinsic costs of

transactions to be aligned with the previous two. Okay. So this is the state package. Then we have data. So for data this was mostly as I was explaining because we get a bigger boost in execution. Uh we actually have to make data a bit more expensive in relation to execution. So we had to increase the cost of some components of call data. Um and this is where these two um beeps come in. But these ones actually have very low impact because they mostly impact um like 1% or 2% of of transactions while um these ones like almost all

transactions use some sort of um state access operation. So they they get um they have a bigger impact. Um then we have compute. So this one was like just a pure compute. So as Peter was saying like the pre-ompiles and sum and whatever like which um pop codes you would have to repric here. Um and um I don't want to to to spoil it, but essentially the the kind of the key conclusion here was that we actually didn't need to repric anything on compute because once we took into consideration the performance from block level access lists actually all operations all pure compute operations

were already performing above our goal um to get to the the 200 million. So this became anformational EIP. So there's actually no repric on compute. So no pre-mpiles or pure compute operations need to be repriced. Um and then we have like a small accounting thing that um actually this idea is like we know that you can use funds as a way to kind of make um add more execution because you get refunds that those refunds are um taken from the block limit and so it means that you can

add more execution on top, right? And so essentially removing the refunds from the block limit accounting kind of like solves though that that worst case. So this is also another um small thing an accounting thing. So as you can see like most of the work is actually around state. We did had a lot of work on compute but it ended up being that yeah there's not a lot that needs to be done here. uh but we did the analysis anyway and then they has all the information on the process but most of the changes actually come from state um okay any questions so far so next I'm going to um deep dive a bit into the actual process that we use to set up the

gas costs um but before going into that any questions around the package itself I've got a question. Um, but I'm just seeing if anyone else is going to dive in. But um, so at one point people were getting very interested in the cost of doing things in L2 and especially say in ZK. Um, and I know some of the say EC pairing stuff in in um doing that as part of a ZK circuit was massively

expensive. So, um, in all of the Glamsterdam efforts, has it just worried about L1 and said, "Look, L2 people, they can sort it out for themselves, or has there been like a a consideration for how much it costs, say, to do it in ZK for L2s or, you know, what's the been there?" >> Yeah. So, that's that's a good question. So I I I think the ZK cost themselves is not only relevant to the L2s but also to the L1 to the sense that we we are planning to do ZKVM and then like the the the the ZK proving cost will will matter. Um but I think for L2S is

especially hard. So and I think the main reason is because these all is very particular to first your slot time and how much time you have for execution but also the your hardware requirements for in this case the Altusa sequencer right >> and I I I I think it's it's almost impossible for us to to have a gas cost that is uniform for all these scenarios. Right. And so the only way is really like we focus on the L1 and what the constraints are for the L1 and then usually what happens is that the L2s they are usually okay. So they they

usually have like buffier machines so they can still process things um on their time and usually like their slot times is also very different. Um their requirements is also very different. So I don't know it would be impossible to kind of harmonize like harmonizing the L1 and the different clients is already hard trying to put the L2s into the mix would be impossible but I think something we are trying to do is we are so I I think this was the first fork where we actually built like reliable tools for doing this like if an L2 really wants to dig in and adjust the gas cost for their own environment they could use our tools. Um and I think this is this is a cool thing on the ZK more

broadly. So we we we very much uh like in our in the back of our minds it was the question of like we are not pricing things for ZKVM yet because it's too early but we also don't want to make things that then will have to be and do and did no have we will have to turn back on in ZKVM. So for instance, things like making OP codes cheaper that we know would be ZK killers like this already we decided not to do but also our strategy at the beginning was like we are not making stuff cheaper. We are just raising the cost of the few couple operations that are the bottleneck. So that will not will never be an issue for

for ZKVMs. Then when ZKVMs comes, there might be new bottlenecks that pop up that we need to repric, but then we'll we'll cross that uh path when when we get there. >> Okay, that that makes a lot of sense. Yeah, I can fully understand the complexity of you trying to factor in everything. Okay. >> Yeah. >> Um are there any other questions? I >> think you're good to go. >> Okay. So now how do we actually do this? So here and um for now I'm really focusing on the process that we did to derive gas costs based on the execution time. So like I'm not talking about the

data repricings and I'm also not talking about the state growth repricing because that one is is is a different one and I will talk about it after. So this is really just focusing on h how do you convert execution time performance into gas costs. Okay. And what we did essentially was we first started with uh building tests or benchmarks that essentially can create these synthetic blocks that have only one op code or pre-ompile many times. So as I was explaining at the at the beginning like imagine building a block with only ads or you build a block with only catch. Um and this is not perfect like you do have

to do some setup. Um so you never can build a block that is only one op code but we try to make it as clean as possible. And so we we we have this test that essentially you you you give the test a block limit. you say build me a block of 60 million and it will fill that block with as many of one single op code as possible and then there's some caveats for state access. So for instance for state access you need to consider like are you doing a cold access a warm access is the access creating a slot or not creating a slot.

Then there's like these different um variants to the test but we try to like cover all the possible variants and then um we have one block test for each variant and then we measure essentially these uh tests they essentially you generate these payloads um that are blocks the synthetic blocks that are just filled with a single block and then we have this tool benchmark core that essentially can run these these blocks many times uh on the different clients and we try to like isolate the client like we don't have any CL we only have like these uh the only the the EL and then then we kind of fake the CL to make

it as fast and light as possible um and then we also have a lot of measurements like uh time like IO dis usage and and and everything like we can measure everything but the key thing we are taking here is like how much time did this block take to execute. Okay. And this is a screenshot of the benchmark tool. So you can see like you have here the different clients and then each of these squares is uh one run. So one run of the entire set of blocks that has the all the op codes. And then here you are seeing the million gas per second performance. Um which is the that metric that I showed

before. And then you can also see like the duration how much the suite took to run and then also the million average million gas performance. So essentially like this is running on on on the background. We have like a couple of machines per client and they are just chugging through these these um these blocks and we are like measuring their performance over and over again. And here you can see like just one suite like this is one group of tests. Um and um you you can see that each test has slightly different performances as I was showing you right like if you do an ad versus if you do a mole the performance will be slightly different and you can

see here the same million gas per second distribution as I was um showing you before. But here you have the million gas second sorry million gas per second uh performance and the test itself. So each line here is a single test. Okay. So you can see like this is a big a big big suite that we are running and it takes like I don't know an hour to to do a single run. Um but yeah then we run this multiple times and then once we gather all these data we actually do a regression per client. So what this looks like so I just to to explain like imagine that we are just measuring the the the gas cost for an S load. Okay. Um

and this is a specific variant where um the the S load so it's cold. So it's the we are reading from a slot for the first time and the slot exists. So we are not creating like it's not a non-existing slot. The slot exists. Okay. And so what we did is as I was telling you, we have this thing where we have the test, we give it the block limit and we will build the block that is full with S loads. And in this plot here in the um on the right um I I can show you like we ran 10 sized blocks. So we have uh 10 blocks of different sizes and in the

x-axis you can see the number of s loads that were in each block and then on the y-axis you have how much time the block took to execute right and so we are fitting here a regression on this data that essentially tells us like the the slope of this line essentially tells us how much time in milliseconds a single sloth takes to run. So essentially we run this across different sizes. We see how much time in total it took and then we just extract the the time that the single sold takes on average. Okay. And this the way we do

this is because it cleans up a lot of noise like all the the like setup of goals that are there in the middle they get like uh isolated um into the constant of this of this regression. And then the the the slope is really just the cost of each additional S load um to to the block. And also by running bigger blocks because this is also an issue like you could say okay let's just run a block with a single S loss and this would actually not be realistic because if you think about it we are running big blocks we are doing we are executing things in parallel and we want to take that into consideration so we really need big blocks to actually be able to

assess what the actual performance is taking into consideration the the pre-fetching and the parallel execution. And so this is kind of like our way um to to to estimate these things. Um and so at this point we had the tests we measure the total time for the block. Then using that data and using uh um some statistical magic we kind of estimate for each op code and for each variant of that op code what the costs in milliseconds. So how much time it takes to execute a single op code and then we need to convert and uh to convert then

uh we essentially use this concept of an anchor in million gas per second. Okay. So we say we want operations to be performing at least at for instance 100 million gas per second. And so this gives us like a relationship between runtime and gas. And so we can use this to then convert what the gas cost of that op code should be based on its runtime. Okay. And then we just choose the worst case. So all clients they don't perform the same like different clients are optimized for different things. Like some clients are better on reads and worse on rightes. Um some clients are really optimized on compute and then not

so much on on state. So they vary a lot and so what we are saying is like we we just price by the worst client. Um there's a caveat here which is sometimes or in some cases we saw that the single client was kind of like an outlier was performing much worse than all the others. And then we al also did like some work on optimizations, right? Like we kind of like these were the tests where we kind of pointing them or you guys are really performing weirdly below what what you should be based on the performance of other clients. Can you look into it? And we actually sometimes found some bugs or some things that clients actually fixed um that allowed them to

like we didn't need to repric it anymore because now they were performing on par to to the other clients. So there was also like some back and forth where we actually did a lot of the analysis and we did the analysis many times where we say okay now these are the new bottlenecks and these are the outliers and the clients would observe and see oh I okay I will investigate and see if there's something I can to improve and they would sometimes two weeks after would come oh I can I improved it now can you measure it again we would measure again and say okay now this is what it looks like and so there was a lot of back and forth this is the the the the the the general idea and if you want to know more about this so I have here the links for all the

tools. So benchmark core is that um tool that kind of picks up the tests and just measures uh how much time each client takes to execute the block. Um then you have the EEL's benchmark which is essentially a Python um they are Python test that generates the the payloads like they they generate these synthetic blocks and then EVM gas feed is the the statistical modeling machinery to go from the results from benchmark core to the final gas costs. Um so yeah if you are curious um you can check the the repos and so what were the results so I as I I

was saying before we essentially the compute IP becameformational uh we figured out that actually we didn't need to repric anything there so everything was was performing above the our goal uh state access had to become more expensive so uh s load sore create calls uh all everything that has an state access component became more expensive and then e transfers were right at the edge. So we are not really changing um the 21k costs of the intrinsic uh e transfer but we did make some things cheaper like if for instance a self transfer now is a bit cheaper and we

also made some e transfers more expensive. So if an ET transfer is creating a new account then that is more expensive. Okay. So this was the the only more expensive change in the ETH transfers um E and what about state creation? So at this point um so before maybe I can just pause here and see if there are questions and then I will talk about the state creation. a possibly spicy question and so I I co-founded protocol engineering at

consensus so you know I was there at the start when we were creating hyperledger and I remember saying I don't think Java is a good idea you know we shouldn't use Java we should use rust so it you know like and looking at the slide there was like a red line sort of for Bessu that you know it was significantly slower um compared to like you know others that were more green. Would there be a case at some point for saying look hyperled I mean Bessu is just too slow. We want to you know go at one gigabit one gigas per second and Bessu is just going to be too slow and we've got to drop it. Would or would

that be something that would just be I don't know removing one of the one of the Ethereum clients because of the language. Would that be something that would never happen? >> So I I would say I think I don't know I I feel like we are still very far from there. So I think even on Bezul I mean I took this screenshot like a couple of weeks ago. Um and they are still working on a bunch of optimizations on their side. Um so I I I think there's still a lot of room to actually scale even beyond the 200 million without repricings because what what we did this time was kind of we

were very conservative. >> Mh. Um, and also there's still some optimization work that the clients can do. >> Right. And so I I I think there's still a lot that we can do without just saying, "Yeah, let's just >> throw a client out." Um and I think but I I think something we have been discussing is that for instance this thing of one client is better in one thing and worse in another thing is actually a result of the client diversity right and this is good like having like different implementations is like it was one of the key goals of of

of the whole thing but there are some parts that we maybe we could say maybe we could take more the learnings from one client and kind of like optimize the the other clients in that way and I think in some things related to states we are already walking in that direction um and so I I I I think this will be like a slow process like as we measure things clients try to optimize they'll try to improve maybe they will share more things between them because now like we even have like a weekly benchmarking call with all clients where we just chat about these things Um and so it's I think it's a work that will naturally progress and I think we still have a lot of room

>> um so so yeah this is how I see it. >> Okay. Uh got a small question I guess. Um if data access becomes more expensive, does that mean that most transactions gets more expensive? Right? Because most transactions require access to some level of state. Um so um what would be the best practice in the future like we limit the num number of state access or so this is this is the interesting thing is that transactions become more expensive in gas terms but then in ETH in ETH terms they can become cheaper

because what happens is that you increase a little bit the cost. So you so for instance you increase the cost of a certain op code that op code is increased by like 2x for instance but your overall transaction gas cost is only like 2.5x more for instance um and then because you are raising the gas limits your base fee will go down. So now the ETH the amount of ETH you pay for each gas unit usually goes down more than the actual increase you got from the repricing. So I I I did some some uh simulations uh

with this like assuming different demand for transactions and price elasticities and whatever and in general the end that people pay will go down. >> Even though in gas terms is higher your but the money you actually pay is lower. >> Okay. Wow. That's interesting. Yeah, sounds great. And that make I mean it makes sense as well that as you have more gas available the price is going to go down. I mean in the box. Yeah.

>> Thank you. >> Cool. Um, so I just now wanted to quickly go through state creation because I think this is a bit different, right? Like as I was telling you about state creation is not about like the execution time cost is not like the in the- moment cost is more about like this rent you are paying for actually Ethereum to store your data forever. Um, and so the way that we price these things is actually very different. And so first one thing we noticed was u state creation or the cost that you pay for each bite of states is not consistent across the different ways

that you can use to create state. So for instance if you create state through a new storage slot this is much more expensive by bite than if you deploy a contract for instance. And so one of the things we did with AT37 was um un make this a uniform thing. So we have one variable which is this um CPS. This stands for cost per state bite. So this essentially encodes um how much gas each bite costs. Okay. And then we have a mapping of how much byte each operation adds to state and then we just multiply two

Okay. So we say now for for the code deployment one bite is um 1,530 and new storage slot is 64 bytes. Um so it's like 97k gas more or less. So this is actually the the one that got the biggest increase um in cost. Um and the and and also um the way that we did this was um so and this also comes from where this um value comes from. So what we did was we want to target a certain um growth rate.

So we don't want like we essentially like if we increase the gas limit and didn't change anything the state growth would grow linearly right like if now we are creating 100 GB per year if we raise it by 3x then we would create 3x more um and we don't want to do that because um state has like a long living weight in the network like the you pay once and all valid datators need to store it forever.

And then there's also the issue of the larger the state, the worse the state access performance will also be. So there's both the hardware requirement issue but also the performance issue. So we wanted to really control the states of growth that we have today. And so we just said let's target one one um 120 gabytes per year. Um then we set the reference limit and here we set it 150 because at the time we were kind of like we knew that Glamsterdam would be something around 100 million and 300 million like we didn't yet had like the

final um number and we wanted to kind of get like a value that was in the middle but also allow ma made the uh state creation operations not too high. Um so there was some simulation also that I I did here with uh with assuming different demand elasticities and and and so on so forth and we kind of settled that this was a good reference. Um and then we just assume so for state creation the worst case is really sustained load right it's not like one attack block that fills the block and then throws the network out.

what state like the worst case here is that you continuously create states in a in like normal loads. And so here the the more realistic worst case is actually you assume that a block is full to 50% um of state creation because then your base fee doesn't go up. Like if you just assume full blocks your base fee will go up and this stack will become exponentially unfeasible. And so the actual like steady state worst case is just a block is filled to target with And so we assume that 50% of the block is used for state creation. We say how many blocks per year we get. Um and then

we just derive um essentially we have how much state gas available per year and then we divide by the bytes that we are willing to add and then we kind of derive this um this cost. Um and this is just an illustration of what it would look like. So at today's prices and 200 million we would get 387 um gigabytes per year on these um uh half% uh 50% utilization. And this is what it would look like with this current um um um cost per state bite across different block limits.

So with 200 we are going a little bit above the 120 but that's still okay. still a uh growth okay growth rate. Um okay, another thing we did was um so we are increasing the gas cost of state creation significantly and this has an issue because um we have um so we we kind of have like this um uh EIP7825 uh cap that says that one transaction can only spend um 60 million gas. And actually if we wanted to deploy a contract

we would need more than this in state creation and so this created like an issue like if we wanted to make large deployments um we will need to increase this cap but the whole idea of this cap is that we want to make parallelization work like we don't want very large transactions because then you would defeat the gains from block level access list, right? Like you wouldn't be able to parallelize a transaction anymore. Um but if you think about it, like state creation is not really about the execution. So it doesn't matter if a transaction is creating a lot of state.

Um we are still measuring the the the state access um cost separately. Um and so the the idea here was that okay, let's meter these two resources independently. So we we meter state creation as its own independent gas and we also meter the remaining execution gas as its own counter and then um essentially the block limits only cares about the max of the two and also not only this but we can also exclude the state creation gas from this cap.

Okay. So now we can deploy bigger contracts. There's no uh like transaction level limit to um to how much state creation a transaction can can use. Um and so and this was actually one of this mechanism let's say was um the most complicated component of repricings because um it actually changes how we do GA accounting and it has a lot of edge cases. So this was a lot of work for a long time.

Uh but it has two big things or two big benefits. So the first one is that um we get these large deployments still fit within the cap and uh you don't need to like slack on the execution perilization that this cap gives you. Uh and then you also get more throughput. And why do you get more throughput? Um, essentially what is happening is that before you needed to fit the sum of execution and states in the block limit, right? And now you only need to to fit the max. So you even if you use like 50% or 100% of execution, you can still fit some state creation there. So right now

these two resources are not competing for the gas limit. So we also get a bit more more throughput there. Um right so this is 8037 and this is the end of my presentation. So um I can take more questions now about what we talked or even for the entire presentation. I think we still have some time I believe. >> Yeah I think uh we can do a question or two and look thank you for your talk by the way it's been awesome. very educational.

Very very educational. So the when we think of say say the gas limit is say 100 million gas is it just the execution um gas then that we're talking about or is it the state and the execution gas? >> Right. So when we are talking about the block okay so what the block is doing is actually taking the max of the two. So this concept of how full a block is now is changing. Like before 1837 it was the sum of of the two. So you only have a single gas um dimension and both state creation and execution were summed right

but now with 837 what what we are saying like this concept of how full a block is is only what is the bottleneck resource. So we are it's like we assume that execution and state creation are orthogonal right like we can fit 120 gigabytes of state creation and we can fit six seconds of execution and then you can use the maxes of both independently like if you use a lot of state creation and you haven't used a lot of execution you can still fit more execution in that's fine >> and so now so for instance as an example if you have a block that uses like 50 million of execution and 40 million on state creation. The lock ga the block

gas used would be the max of the two. So it would be feed. >> Okay, that makes sense. >> But the but the transactions still pay the sum. >> So this is an important thing like the transactions still pay for all the things they use. It's just the concept of if a block is full uh uses like these two orthogonal resources. >> Okay, go all the people who are writing block explorers are going to have to update their software. [laughter] >> Um I don't know, Betina. Anyway, the all the people who are on the call um do you have any other questions?

I think you're good. So that that I mean we've asked like must be a dozen questions during the talk. So um look, thank you. That was absolutely awesome. That was fantastic. So thank you very much. Um have a great day and um yeah, thank you. It's um I've I think we've all learned a lot. >> Yeah, >> thank you. Uh thank you so much for for inviting me. It was really fun. >> Yeah. All right. Well, um, have a great day and, um, talk to you all later. Bye-bye.

>> Thank you. Bye. >> Bye. Bye.