EIP-8007: A major update to EVM gas prices with Maria Inês Silva | Devconnect 2025

Transcript

[music] Hello. Uh so uh thank you for the warm introduction. So uh I will be talking about EIP8007 uh which we can jump right to it. Uh so this is a meta EIP. So this means that is a collection of a bunch of different EIPs and it's really aimed at uh being a directory for all the EIPs that are proposed for Glamsterdam. So the next fork after Fusaka um that are focusing on changes to the gas model or the gas prices of uh EVM operations.

And the goal of these EIP is to be poorly uh umformational. So there was so many different uh EIPs related to repricings that we thought it would be a good way to aggregate the information and help organize the work around these uh repricings and also um give more information uh to the community. And uh why are we seeing so many repricings in Glamsterdam? Why are we even doing this? Uh so there's two main main reasons. Uh the first one is that um a big focus for Glamsterdam is to scale the L1. So increasing throughput

and uh repricings uh on their own they do allow us to scale further um through uh what we call harmonization. So what we mean by these is that the current gas costs of the different EVM operations they are not harmonized. Uh so we know that some operations are overpriced so they are more expensive than they should. Um and this means that we are essentially limiting the throughput of that particular operation. So instead of being able to fit 10 operations, we are only able to fit five because they are too expensive.

And for other operations, they are underpriced. So they are too cheap. And these are even worse because that means that they alone become a bottleneck to all the other operations. So we cannot increase the gas limit uh because they uh essentially create a single bottleneck that could lead to um a worst case block that would take more time to execute or uh would would hit another limit on the overpriced operations. Uh I I'm showing here a plot where you can see the efficiency loss per OP code. So when I say efficiency loss, what I mean is

that how much throughput are we losing because of the pricing uh we have um considering the actual execution time that the operation would take. So in the ideal world with the execution time we could fit an X amount of that operation under two seconds. Um and uh we can also calculate with the current price how many operations we can fit within the gas limit and we take uh the ratio for this to get the efficiency loss. Um and so you can say this is focusing on the pure compute operations and for a big majority of them we actually have efficiency losses of five times until 15

times. So this means that for some operations, we could fit 15 times more of that operation in a single block if they are correctly priced. Um and then for the the next two box plots, you can see what it would look like with a more accurate pricing. Um the the middle one um is uh an accurate pricing that uh would not uh go fractional. So we would still have operations that should be for instance 0.1 but we need to round them up to one because the gas model uh is not fractional is is you it needs to be an integer.

And the final one is like we could solve all of that with with a fractional pricing. But it's just to give you a sense of the level of throughput gains on individual op codes that we get from um fixing their prices. Um and for the underpriced operations the way to look at this is so we have this benchmark that is been um work done by both the steel team and uh some other people at the EF and also the nethermind client team um where you are benchmarking different test cases for different operations and that will give you a performance of milligas per second. So how much milligas of that

operation per second can we execute and you can see like the performance varies widely right um essentially you should have all operations at very close milligas per second like we shouldn't have more uh some operations that are more expensive than others but it also tells tells you like if we want to target a specific block limit so let's say we want to target 100 millig gas for a two-cond block. Um then we should have all operations uh at least 100 milligas per per second. Um or sorry 50 milligas per second. Um and so everything that is performing worse so it's it's it's it's

less than that um they are creating these bottlenecks. So they need to be uh more expensive and this is the reason number one. So the reason number two is essentially by doing the repricing we are actually unlocking scaling from both headliners. So in glamsterdam we have right now two headliners. So the first one is EPBS uh which is uh changing the slot structure. So when certain things happen at certain times in the slot and essentially uh EPBS will give us more time in the slot for execution. So we'll have instead of having two seconds we

will have for instance four seconds and also will give us more time for data uh for the data um or bandwidth let's say like the propagation time for for for for all the data and um and also because of the PTC deadline the actual relationship between execution and data will change so we'll have now more time for execution in relation to data And then we have block level access. So these uh headliner essential introduces the possibility of doing execution in parallel.

And also state root calculation can be done right at the beginning of execution. So you don't need to wait, you don't need to execute the transaction to then start doing the the state root calculation. So again it gives us more throughput for execution. Um but because some data is being added to the block which is the block level access list then again it's putting a higher burden on the data resource. So we are using more data now. So what this essentially means is that first we are adding more room for burst resources. So we are adding more room for execution for state IO for data. Um

but for state growth which is how much the storage layer let's say is growing um that doesn't change like the the available resources there don't change um so everything needs to become cheaper in relation to state growth or say in another way state growth needs to become more expensive otherwise that will be a single mock and at the same time data in relation to the other burst resources so compute and state IO needs to also become slightly more expensive uh because now the relationship between them is also changing and so in summaries like these headliners are great they are giving us

more throughput but we can really just squeeze we won't be able to squeeze all that throughput gain until we repric these things and so how are we actually doing this So, the meta EIP has 18 EIPs, which is a lot. Uh, core devs are currently going crazy with the [laughter] amount of EIPs they they they need to review. And so, I'll try just to give a quick overview of them. Uh, but essentially there's like three main types of EIPs here. So, the first one is a broad harmonization.

So this means is EIP that are changing broadly all um op codes on a single dimension like compute state IO state growth intrinsic cost and so so forth. They are doing essentially an armonization across the entire resource. Then we have pricing extensions which are specific changes to some component of the gas model um that are not an harmonization but are sort of unlocking some further scaling in a specific component.

And finally, we have some supporting EIPs, which are mostly things that are not really um impacting scaling per se, but are um or are sometimes not necessarily a gas repricing directly, but they are supporting u the other EIPs and how to think about all these EIP. So we are now in the process where we are discussing which IPS to to to select and um the way I'm thinking about it is we should prioritize the broad um repric uh EIPs. Uh so this means uh we know that we need to repric compute. We know we

need to repric state growth. We know we need to repric state access and data. So these are the core things like a core group of things that we should harmonize so we can remove the single bottlenecks and the uh enterprised uh op codes and then there's like these supporting ERPs are more a menu of choice right we can take okay this extension uh is nice and we should have it or this extension is not uh so needed now and we can leave it for for for later and so I think the the way that I try to group these things like the broad first level um repricings are a bundle or they need to be done together because

if we don't if we change something and we don't change the other resource for instance we'll be just introducing bottlenecks and doesn't make sense and then the pricing extensions uh we can add as we go and so what comes next what are the next uh steps Um so now we are in the process of uh deciding what which EIPs to select and we already um have some signals that repricings in general will be a core um focus. Um however there are a couple things missing. So first some of the IPs or a a big part of of of at least the broad uh pricing IPs they are still not fully

defined and the reason for that is that we are still working on the benchmark to actually collect the the how much time things take to execute um so that we can set the final numbers and we are currently starting to get the first numbers on this but it's still a work in progress and Then we need to decide on the scope. So which operations are we prioritizing? Uh when which price which of the addition should should be added and then another big uh thing is uh state growth. Um so all the other operations are sort of simpler because we can just benchmark them. Say okay

this operation with these parameters takes 100 milliseconds and so their price should be x. This is fairly simple. State growth is a bit more complex like we kind of have to take a guess on what state uh growth rate we should be targeting. And this is sort of is not something that we can benchmark directly. So it's a bit more nuanced and and then there's also different flavors of how we could repric uh state growth. Um, and so I think this one is sort of a very important thing and something we should definitely do, but the exact flavor of what will end up in the IP, it's still um unknown.

And um, thank you. So I think we still have some time for questions. Um, yes. [applause] By the way, quickly checking, did you guys get the idea of why we have this EIP in place for the first time? No, actually it is not for the first time. Maybe for gas repricing, this is for the first time, but we have seen such kind of EIPs in the past where we try to put all the related proposals in one place so people can learn it and say which one they would like to see in the next upgrade.