EIP-7904: How Ethereum is Fixing Compute Gas Costs for Scalability

Transcript

The big thing that uh these repricings allows us is to significantly increase the block limit. >> There were many factors like algorithm changing constantly and measurement methods changing constantly and so on. And hopefully this EIP fixes the problem that we created few years ago when we implemented point evaluation pre-o compile. The reason why this proposal is so important and this was like since the beginning a clear one that should be included is because these operations are now a bottleneck for us to achieve a certain gas limit goal. We created an EIP7904 which initially was very conservative

then revolutionary then conservative again and now it's turned into conservative well the fact we can do it and it's not that difficult. The fact that well researched EIP are actually important. I think Mia mentioned it briefly but hardcoded gas limit it's a big no no. That's uh something that every developer should keep in mind. >> Who will benefit the most out of this proposal? >> I think end users because they will experience lower. Welcome back to Peep and EIP. This is

episode 159 brought to you by ECH Institute. I'm your host Puja Ranjan and in this episode we are going to talk about a topic that most of the people in Ethereum community love. Yes, it's about gas repricing. We are going to talk about EIP 7904 compute gas costs increase. This is a proposal being considered for Glamsterdam upgrade documented in February 2025. The proposal is in draft status and is in CFI as per network inclusion stage. We are joined by co-authors of the proposal Yasik Glane and Maria. We would learn in next 40

minutes or so about this proposal. Welcome you both. >> Welcome. >> Thank you. Thank you. So I understand this proposal is built over EIP7883 that was deployed with the Pusaka upgrade and there are some interesting tradeoffs and changes that are being brought in with this proposal. We will learn more about it. But before we get into the weeds of technical details maybe we can kick off with a quick round of introduction. >> Hi hello everyone. I'm a researcher currently working at the Ethereum Foundation. I'm part of the robust incentives group. So my topics of interest tend to be a lot of data analysis related to incentives and

economics. And recently I've been leading the work on the gas repricing. So this is a major effort we have been doing in the past couple months to align the gas costs of the EVM with the actual resource consumption that the different clients experience. So that this has two key benefits. The first is that by doing this we can control much better our resource usage but also it allows us to scale. So by making sure that we don't have like specific operations or specific resources that are bottlenecking the others, this allows us to increase the gas limit and overall

have a more performant EVM and this EIP that we'll discuss is a a big part of this effort. >> My name is Yatsk. I'm a software developer at heart. I've been doing it for many many years now and I still enjoy building uh software. About four or five years ago, I discovered the wonderful world of blockchain Ethereum in in specifically and then I had um a pleasure of working for Ethereum Foundation different research uh projects. One of them was doing specifically this trying to answer the question like this gas cost like is it accurate at all? I mean how do we know

it and that's the whole history that we're going to go through it I'm give you some details on what people were thinking and how it was going and the outcome of this project which lasted for 3 years I think in in total not continuously but uh with some gaps but it's been quite a long uh journey we created an EIP7904 which initially was very conservative then revolutionary and conservative again and now it turned into conservative but on different scope. So gasing is always an interesting topic to discuss. Many people have many different opinions trying to juggle those opinions

and put them together in one coherent change proposal. It's almost impossible. There will always be someone who's uh dissatisfied with uh the stuff. But hopefully we'll get somewhere uh with this uh with the 7904 and because it's the in fact the first EIP that looks at guest replicing from that perspective like uh not a single thing but trying to take the whole one. So hopefully we will open the door for for many more replicing in the future.

Why? I think we can discuss it later why we need a more gasly pricing after the after that. Of course, not everyone agrees but just my opinion but uh we'll see. >> Yes. So, first of all, welcome you both. I'm so glad to have you here. I understand this is like really interesting that this proposal is coming so late in Ethereum road map, but I'm glad it is here. If I understand correctly, it's going to change your 13 op codes plus pre-ompiles gas costers and this is mostly based on benchmarking data. So I understand that there is also a presentation. Without further ado, let's get into it.

>> Okay. So gasing let's start from this. This is the current gas schedule just a small part of it. The point of showing it here is that many years ago, 12 or 13 years ago, we as a community, we wrote the yellow paper for the Ethereum. Of course, uh not the whole community, some some certain individuals were behind it. Many thanks to them for starting the whole nice uh ecosystem. But in the yellow paper, they put this gas schedule. So each operation should cost some gas. and they made surprisingly a very good estimate of what each opcode should cost. It hasn't been backed by uh

a proper benchmarking at the time and that's why I'm saying it's surprisingly very accurate. So when we started of the journey that research project we immediately assumed that most of the op codes must be wrongly priced and it was our discovery that we were quite wrong. There are some nuances to this but uh this stuff is not as um inaccurate as you would think from just someone's estimate uh 12 or 13 years ago. But anyway, we think this gas schedule needs an update. Why do we need uh that update? The point of gas schedule is to show how each operation actually cost on

a node executing that uh operation. And there is a number of reasons why we want to make sure it's very accurate. We want to reward node operators for the effort of executing contacts. Of course, we want to make sure that the network is safe. The gas cost is very directly linked to network security without any cost of transactions. You could swamp the network with uh all the operations.

That's why we have to pay a small price every time we execute a contract. But if you have a number of operations and they are misplaced, you can prepare a vector of attack which targets a specific misplaced operations and therefore caused some of the issues on some of the nodes and if you hit enough of the nodes you can stall the network completely. Then there are some more practical let's call it effects of correct pricing. We know from the past that if you have some op codes which are underpriced for example you can abuse them. So you can use them for something else that they

shouldn't be used. Typical example from any low computing uh coding is that uh rather than setting something to zero you use excel operation. So many similar things both compilers and developers were using directly in smart contracts. And that's it. That was our starting point. We want to measure what it actually takes to execute a smart contract and each op code. By measuring it, I don't mean a one off. We from the beginning, our goal was to have the whole methodology and the tooling, but we can reproduce the efforts many times after our initial project has finished.

The reason is that all the EVM clients which executes those contacts, they evolve constantly. The ecosystem evolves constantly. We open a new vector of attacks or close some old ones and we have to measure it uh constantly. And uh here we go at the bottom of it. We want to measure single operation. It's an either an op code like an add more multiply or whatever or a pre-ompile from EVM point of view. A pre-ompile is a single operation. We need to measure it. But by saying we want to measure this, there's a number of things that we don't want to measure. We don't want to

measure typical things that happens on each machine executing uh smart contracts like caching, wall maps, processor architecture, any other other hardware things, uh IO, disk speed, what kind of language it was written uh in does it contain a garbage collection or not and so on. And is your note running under some load or not running under some load? All those things are important for anyone running a note in Ethereum network but they are not measurable and not important for the safety of the network. We just want to remove it. So what do we want to measure? We we want to check how each

EVM engine behaves in reproducible ideal conditions. So we can run the same benchmarks over and over again, get the same results and make some assumptions on back of uh those results. It means unfortunately that you EVM uh engine needs to run in some isolation. It has to have some predictable storage history that we control which allows us to produce those uh results. You need to reduce the network traffic to absolute minimum and the whole host to be uh a minimum and once you have it you can measure it. Now the problem here is that

the more isolated it is the less real life scenario it represents. So you need to find a a balance of how you want to represent it or you want to measure it on different levels like in isolation or in network which is unfortunately much more complicated than it sounds. Okay. In general the testing method says rather than testing a single operation like in the first low he have an impact of some warming up or phasing out. It doesn't matter whether you execute one block or one transaction and so on. You always have some kind of a warm up reading the contract data reading the account state and then closing saving some storage and so on at

the end. So you want to avoid running a single operation. You want to fill up your whole space with as many identical operations as you can. So it's either a transaction or now we test it on the whole blocks and then you know how many operations you executed. You know how long your block uh executed for and you can measure a single operation. Again does carry a lot of tradeoffs with its uh self but we can actually prove that this method accurately represents the the cost of running a single operation. So in this case we have an ad operation and we can see if we were to measure a single ad

which is on the left side here and it was something like two microsconds that would be completely inaccurate. But as we add uh more operations in the same space, we can see that each of them on average increase just by a small margin. And this margin by recalculating and applying some regression to it. This margin is the cost of a single operation operation in here. Okay, you could argue what about this initial setup here. It costs a lot to to run the first one and then doesn't cost uh so much to run multiple ads. In fact, it doesn't matter because the cost of the whole initial

setup cost is spread over all the operations that are included in your uh transaction or uh block. So by measuring a single operation, you still have the accurate uh uh gas cost because gas cost is not uh it's representive uh only measure to represent some kind of a cost. It's not a very linked to uh reality like it's not in nanconds or any other units. It's just a representative cost. Okay. So how it works? We created all those kinds of uh contracts running uh all blocks running all those operations as many as we can run it for all the EVM clients that we have and

came up with some measurements for each of the operation for each of the EVM clients. Now we normalize those operation measurements. We remove outliers. Try to put them on on a single picture really and we do actually have a picture like this which allows us to compare those uh clients with each other. You mentioned the picture this is the actual picture. So after all this measurements when I say all these measurements we have to acknowledge the fact we are talking about thousands of contracts blocks and billions of executions really because we iterates all over the the same uh executions over

EVM clients uh op codes and so on and then we use some uh statistical methods regression mostly to come up with a single cost of uh operation and we can compare clients the details the skill doesn't matter. What I want to present here that many of the op codes like we see at dup or swap op codes on the right they are surprisingly similar across the clients some of the op codes like uh let's see the m lost store x the variety between the clients is quite big and the question is now it's easy for the to propose some change when all the clients

match. What do you do in situation when you have a a split? So let's say most of the clients execute an operation in X units but one of the clients uh execute that operation in uh 20x. So it's 20 times more expensive on a single client and you want to propose a new cost. Do you remove that single client as an outlier or do you take them into account but your outcome new cost gas cost will not reflect the majority of the clients because you take this outlier into the account.

Many of these different decisions discussions how it should be. Do we remove the outliers? Do we look at the actual popularity of the clients? I mean is the GF more important than uh elegon because GE is at the moment what 30% and elegon is 2%. Uh does it matter if elegon is completely misspriced because in the worst case all the nodes running ele 2% of the network it doesn't really matter. So we had a lot of discussions like this what we should really take into the account but after making some

of uh the decisions that are all uh documented. We came up with a new proposal and as I mentioned the gas cost is relative. So you can actually rescale your gas cost as you really want as long as everyone agrees to it. So the first proposal was to leading to the average. So we wanted to keep most of the op codes at the one point and only adjust both op codes which were completely misplaced one way or or another. The second approach was to keep most of the op codes at the same level but we lowered the cost for those which are overpriced. Now we wanted to do that initially mostly because of the network

security again and back uh at the uh the time increasing a block gas limit was not an option because we couldn't get a consensus of doing it. So decreasing a gas cost was a way to put more transactions in a single block. So that was the quite radical proposal. I think most of the op codes were priced at one with some exceptions to keep uh the current and gas cost uh and that proposal would uh deduce a typical contract by about 30 or 40% cost of running executing a contract. But the things have moved on since then. So we increased a block gas limit quite

significantly since then. We viewed the network security and uh figured out that increasing a gas cost of asserting operations will not be so dangerous to the network. The reason why it was dangerous is because some of the old contacts were using a gas limit when uh calling it. So it was important to for backwards compatibility not to increase the gas cost because this gas limit uh could have been exceeded for the old contracts. But this wor wasn't as serious as we initially thought. So increasing the gas cost for some operations, it's not that dangerous.

This is the uh most recent proposal. We identified some of the op codes which needs increase in the cost. Some of the pre-ompiles which also need an increase. These are not very drastic uh changes. These are more like adjustment. It reflects what I said in the beginning. the current gas cost is surprisingly accurate. We just need to identify problematic uh operations and adjust them. I think the best point is the point evaluation pre-ompile here from the very beginning. We actually knew it's not uh priced correctly. I worked at the original pricing of this pre-ompile. Honestly, I don't know how we came up with uh the 50k uh gas cost

even for we did know it's not accurate. There were many factors like algorithm changing uh constantly and the measurement methods changing constantly and so on and hopefully this uh EIP fixes the problem that we created uh few years ago when we implemented point evaluation pre compile. Coming back to some uh measurements and how accurate they are and that the whole operation actually makes uh sense. We can see here different uh clients um giving very good uh results uh when we measured some uh individual operations. That's interesting. Uh our initial work looked at each of the clients specifically for

each of the clients. We created a report and uh gave it to corresponding uh implementation teams. I will report our findings and like here for example elegon had a hidden bug that a push operations get more expensive on depending on the argument size doesn't really make sense but uh it was very hidden bug thanks to our working they have fixed it we did manage to spot a few things like this and it was all reported to the corresponding teams now I did mention that I hope it's not the only one not the only EIP but more importantly I hope the work that we've

done on measuring the actual cost it's doesn't stop here because uh landscape changes the EVM clients change constantly we want to make sure that the same process is uh happening over and over again and we already made a lot of uh bloggers on this uh site so the Atheium latest uh benchmark uh ute is very good in automated uh measurement of all of the stuff. One of the things that we removed from the original EIP was the memory replies. Uh we remove it because there were some other proposals and also there were talk of the multi-dimensional gas prices. As far as I know, nothing of

that has materialized. So maybe we should uh bring back the original memory gas deploy EIP which was very simple at the some of the issues and actually made it more pragmatic for the developers to use more memory and that's it. You can look at the original project which was called the gas cost estimator but more importantly Ethelium benchmarking is the place to look at the moment and of course the EIP 7904 that's um hopefully that will make its way to Glamsterdam.

>> Thank you so much. This was a great presentation and I was like mesmerized by looking at the charts and the deep work that is done behind the scene to come up with the numbers. I understand these are also added as a part of proposal maybe an asset. >> Yes, it is attached to 7904. I think this is rare in the history of EIP that we get this kind of collection and asset is so much rich that people can get all information and a lot of references of all the ongoing work in parallel. So thank you to the entire team.

>> Thank you. All right, with that maybe we can move on to the next section which is Q&A. This was a great explanation but just for some uh references and clarification we have a few questions for you. So my first question is why now? Like we all understand that uh this gas propricing was static for a very long time. Earlier you mentioned that there was a long history of research work ongoing in the background. So what uh pivoted this proposal right now? Was that some ask by the community? Do we think that this has been researched enough and the numbers will sustain for a longer time or was there any other reason?

>> Good question. One of the answer is now because we managed to push it now through all the usual buttons that you have to we managed to agree on uh what it is to go and be implemented now and it's a long way. We didn't have something like this before in Atheium because of two reasons mostly. We didn't have a tooling and we didn't feel we have a need to do it. Yeah, we have more needs now because a film is more mature now and we actually need to make sure that the cost represent the actual cost not some madeup cost. And we have

enormous tooling what the Ethereum Foundation and all people involved in it getting uh the benchmarking though it's really a lot of good work and I'm really happy to see how how it works but Mia you have uh more to say on this. >> Yeah I think I 100% agree with you. So I think it's both now we have more tooling and also more need but I think also the need comes mainly from this new push for scaling. So past year there's been like a a big focus on scaling Ethereum, making sure that we can process more transactions. There was a realization

that actually our gas pricing was a real bottleneck on this effort. And so that's also where the need came from. And I would also say I think as an ecosystem we are also more mature and also I think the apps themselves are more mature. And so the first time that there was any updates on the gas pricing, it was like a really big problem because a lot of contracts had like hard-coded gas cost and these sort of things. And now that I think the maturity of developers is higher and so we can more easily make these changes because people can adapt to them also more more easily. And I think in the future this will become

more and more common as Yas was saying like maybe we have like a more automated process that every fork like checks like with the new EIP being added is there any new bottleneck that is coming and do we need to make any adjustments to the gas cost and then we make those those adjustments. So I think as we move forward this process will be more and more streamlined and we'll start having more and more gas costs aligned with the actual execution and resources that are being used. >> I mean I would agree 100% here. The process seems to be way more streamlined now now that we see the meta EIP the EIP number is 8007 that helps us learn about all those proposals which are being

considered or at least being discussed. So my next question is about the uniqueness of this proposal. I understand there are around 18 proposals which are listed as Glamsterdown gas repricing proposals. What makes 7904 more unique? Why do we think that it should be considered for Glamsterdam? As a way to kind of answer this, I'll also give some context on what changed since the proposal that Yas did initially and what we are seeing right now. So initially the proposal was mostly reducing the cost of transactions that were overpriced and so this is a good way for us to scale because without changing the gas limit we can now fit

more transactions. Um but this essentially during the discussions of what the IPs we should introduce or not, there was this worry that we were changing too many op codes at the same time and this for testing would be very very difficult given also the already big size of the fort that we have that is Glamster which is a a beast and so there was this concern and at the same time the idea was okay so instead of keeping the gas limits fixed and making things cheaper. We can achieve the same overall increase in throughput by doing the other way around. So by increasing the gas limit more and just making some

operations that would be blocking it more expensive. Okay. So if you make like 10 operations more expensive now you can increase much more the gas limit and so the other operations get cheaper in comparison. Right? So it's it's the same thing as Yas was saying like the gas costs are just relative things. You can change them and change the gas limit and nothing changes like your throughput remains the same. And so you kind of can get the same effect of throughput by either making things cheaper and keeping the gas limit or increasing the gas limit and making it a couple things more expensive. And so this was kind of the trade-off and like the big change in

this EIP was this thing of let's repric less operations which is easier for testing and backward compatibility analysis and then increase the gas limit. And so now if you go to the EIP we are only changing really 13 operations like half of them are pre-ompiles and the other are op codes. And the reason why this proposal is so important and this was like a since the beginning a clear one that should be included is because these operations are now a bottleneck for us to achieve a certain gas limit goal. If we don't make these operations more expensive, it means that we cannot increase the gas limit and so we don't have any gains in

throughput. And so that's what makes this EIP so needed. in terms of also what makes it special. I do think the way that we are arriving at the numbers is very interesting from a technical perspective. So we don't have like in terms of implementation these EIPs are pretty simple. you are just making a few changes in the constant but the work behind getting to those numbers it's really interesting like the approach that the ASC takes is very smart like the regression doing like different blocks with different numbers of each op code and then just computing the marginal increase like it's a really I don't know for like as a data scientist I find it is it's really interesting and

also from a developer perspective like building these blogs and making them as lean as possible is also like a challenging task. And so I think at the end of the day like there's a lot of tooling behind it that makes it very interesting work and there's still a lot of developments happening to improve this tooling and make it more consistent also improving the analysis itself. >> Yes, I think Maria rightly mentioned the approach behind it was unique. It was like I was seeing it for the first time here in in the EIP's documentation. And of course it was done in research work but never have seen it in that extensive maybe from the prior upgrade in Fusaka as well XP had some kind of benchmarking

done there and the approach as you mentioned was like marginal so it was like very very careful do not disturb lot of contracts because it could break as some of them maybe historically using the hardcoded uh value so that can disturb there I'm curious to understand do you guys think that this will improve the process of selection of EIP of such value like we should go for this kind of intense benchmarking or research work done. Do you think we can standardize this as a process? >> So I I would say this is one of the things that we've been working a lot in the last couple of months. We do had some benchmarking tooling but it was pretty like scattered and uh we are now trying to kind of like standardize it

and make it more usable and I think there's been a lot of progress on on this. So we are still working on it at this moment. I'm not sure if we discussed this before but actually the numbers on the EIP are not still final numbers and one of the reasons is like we are still working towards running all the benchmarks with all the glamsterdam changes because this is another thing is like you are working in a fork doing changes in the gas prices but you also need to take into consideration the new EIPs that coming in this fork and as an example like a one of the headliners ers of Glamsterdam which is the block level access lists. They do allow for clients

to be more optimized by running transactions in parallel. And so this actually has a huge impact in the final gas prices, right? Because now you can execute all operations much faster because you are able to run it in parallel. And so we are still in the process of merging the changes that are already being worked on for block level access and integrating it into the benchmarking process. And also I think there's still work on integrating the different steps of the benchmarking and making it more automated.

But for sure like I think in the future it will become more and more automated where we can just like plug the fork and run all the benchmarks and then collect the final gas prices. >> Yeah. Also and when we started we we tried to juggle many different uh interests like increasing throughput or network security and so on. Now from my perspective at least the network security when it comes to uh repricing the network security is the key factor at the moment because all other considerations that we have in the past have been addressed in different way by the increasing uh block gas limit or uh running transactions in parallel and all

other improvements that have been done in Ethereum. So probably at the moment we mostly looking at uh identifying problematic uh operations and adjusting them well increasing cost mostly to the level that uh brings back the security to the network. >> Very interesting. So these numbers are not finalized I understand it now and it's good that you have highlighted that as well. This is currently being tested. Is the testing going on along with BLS or how will there be devet specifically for testing this uh proposal?

>> Yeah, that's a great question. So at the moment are in devet. So DevNet 2 of block level access lists is being mostly finished and we are moving on to DevNet 3. And DevNet 3 includes block level access lists plus a few other EIPs and one of them is a repricing EIP but is mostly around state uh growth. So state creation. So we are not yet integrating everything like we are not integrating the the 7904 yet into a definite and uh the reason for that is that we first want to finalize the numbers and then we will integrate it and so what we are

doing is like now we have a stable devet with the block level access list optimizations that clients are implementing and so we can run on our benchmarks on these dev nets essentially these releases of of or the stages of the clients and then we derive the final numbers and once we have that then we integrate it into the next available devet and then that's when we start testing and so this is in general the process at the same time we are doing so this testing for this is also a bit because we do have to do backward compatibility analysis which is essentially analyzing historical transactions and seeing what breaks and then warning people about it and so we

are starting also to do this work and Buha from from the protocol coordination team at Ethereum Foundation he's been doing an amazing work there so we are starting to contact big like big contracts that we see are are starting to to break for some reason and warning them so that they can adapt and so this is also like an important part of of testing that is not necessarily integrated into a devet so is mostly about like rerunning historical transactions and and and seeing seeing what what breaks.

>> I mean it's good that big contracts are being approached. I wanted to learn more about it like you know there are some toolings and different projects who would want to get it tested when do you think uh there would be the right time when uh these people can maybe check their applications that they are working as expected and it is not being damaging to to their projects. Right. I think that's a great question. So, we do have a website that brings together all the information on on repricing. It's essentially gas repricing.netifi.app.

And there you have all the information on repricings. We also have a simulator that was worked on by the ETH panda ops team at the Ethereum Foundation. And essentially in this simulator, you can essentially change the gas prices and replay blocks. So essentially you you can like pick a block where you know your app was being used and then you can do the changes. Um it already has a default for the current um Glamsterdam repricings. Of course a big caveat. This is not still final final numbers and so it's the with the preliminary numbers we have but you can already see what breaks and how different the gas costs in those

transactions are. Um so this is step one like I would urge you for you to explore it in terms of timeline. So we do want by end of April to have all the repricings with final numbers and integrating into a devet and so after that once we have like a a a stable devet we can start a more like public test net and then people would be able to go and and test. But I would say at least until end of April uh we would expect to have final numbers and DevNet um integration.

>> Awesome. So that is good to know. But just on a high level if we have to like spread this word out, would you let us know what kind of a smart contract will most likely feel the impact of 7904? Yeah, this is very hard to say because there's like a bunch of different things. I would say the first one is like any contract that has hardcoded gas costs be affected if the hardcode gas costs are being changed. This is this is number one. I think another type of contracts that will be likely impacted is if you have very complicated logic and you are very close to the transaction limit of the 600 million gas units, ice increases will likely make

you hit this. And so for instance, an example is uh gas proofs of optimistic uh rollups. Like there there are some cases where this could be like right over the edge. And so this is also another case where definitely need to check it and make sure that your transaction cost is not going above the max limit of a transaction. But yeah, I think mostly like it's very hard to say like in general what things are breaking. It's like there's tons of different things that get impacted. But I would say these are maybe the more two general cases that that we are seeing.

>> Yeah. >> Yeah. That is good to know. So I understand that there could be some D5 protocols or some AMM projects they may have like hardcoded gas value there. So if they are expecting to be adjusting their parameters what kind of work they are looking for like would there be work that might require reuditing of their projects or just testing on the public test net would be sufficient? Yeah, for sure is like first is you'll have to test on the public test set to see what is breaking. For most of the things you are in an upgradeable contract and you can just make changes but essentially you'll have to likely make changes to

your contract and what the changes are it depends a lot depends on the contract but I would say like the first step would be testing on a test net and then yeah understanding what what needs to be >> very well so let's move on to the road map of Ethereum I understand that we are now having multi-dimensional gas values And we have road map L1 centric and things like that we are changing here and there and that brings us for the changes that we generally deploy with the network upgrades. So with this L1cententric road map in mind, could more accurate compute pricing make certain types of onchain computation more viable on layer 1 directly? What are your thoughts on that?

>> So that's an interesting question. I think so in general if we look at how gas costs are so at the moment is state related operations tend to be underpriced. So they should be more expensive while pure compute are definitely overpriced. So they should be much cheaper and so I think the long term would be you you get like creating state reading from state and writing to state will become more expensive and pure computation things will become cheaper and so with this I think and this is independent of the multi-dimensional fees and and and so on so forth with this you will likely so as pure computation things becomes cheaper

there could be like new applications that come and and make use of this. It's hard to predict what will come because it's it's very hard to say, but I think this is mostly like it's not as much the multi-dimensional fees that I think will allow new use cases, but more like these mispricing that now compute will become much more cheaper than state related operations. >> So, we are seeing quite a few changes those are upcoming on Ethereum. Maria, great that we have you here for this conversation. My next question specifically is about the set of proposals that we are seeing with the Glamsterdam Meta E. So if the full set

of repricing proposal lands coherently, what does Ethereum's execution layer look like in two to three years? >> So I think like the majority of the repricing for Glamsterdam is all about solving these single bottlenecks. So making sure that the few operations that are impeding us to increase the block as gas limit are not there. So they are correctly priced. And so on this note, what the big thing that these repricings allows us is to significantly increase the block limit. I think there's another proposal that is a bit more nuance which is the state creation EIP. So 8037

and this one actually is introducing now we are starting to measure state creation in its own separate resource. So we start introducing this state cast that is measured separately from all the other regular casts. And so this changes because now the way that we define how full a block is changes. So now it's not the sum of everything. It's just each dimension separately has its own limit and it's the max that control how full um block is. And maybe this would be a good topic for another podcast because this CIP it's it's quite complex. But

this also it's introducing this multi-dimension to the concept of gas that I think will change a lot how it will look like. And I think in the next forks we'll continue to build upon it. So I think the way that we control the different resources, how we define limits for it and how we price them I think will be very different and these IP is kind of like the first steps in that direction. So do you see all proposals which are listed in 807 would be part of Glamsterdam or do we see that some of them may be dropped at some point and the list will be short? So I would say all the EIPs that are now considered for inclusion so not the ones that were already declined I do think

they will go through of course like process is very um there's a lot of unknowns so things may change but from the work we are doing now and on the information we have right now I think all the IPS are in a good position to to be included for the ones that were declined there could be some that go in in the next fork But I I think we are still early stages to see exactly what will go and what will will end up never being implemented. I think also a lot is changing in in Glamsterdam in terms of EVM execution. So with the block level access and EPBS like things are like the slot is changing the fact that clients can now run transactions in parallel

like this changes a lot how the different resources and how like execution looks like. And so it's also hard to say like what will be needed in the next fork before like fully implementing these features and then doing like the proper benchmarks and understanding what things are now looking very mispriced. And so I think the plan is like we know that the yips we we are considered fork Amsterdam. they are important and I think they they will mostly go through and then for the next fork we'll need to rethink and re rebenchmark and see like what are the next things that that we need to address. So for this proposal 7904 currently is in CFI. I understand the

reason it is not SFI because we do not have the exact parameters. We do not have the exact numbers. would that be defining point to move it to SFI? >> So I think there's two defining points. So first is yes having the final numbers and for that we need to and again the reason why we don't have the final numbers is because we are still we had to give time for clients to implement all the optimizations from block level accessly. So then we can benchmark them and get the final numbers. And so now we are in a position where we are starting to do the these benchmarks the optimizations. And so this is uh milestone number one is having final numbers and then the final milestone is

being integrated into a devet. So once we have final numbers integrating into the devet will be easy because we already have the testing framework ready. we have the specs mostly ready. It's it's still with placeholder numbers, but the PR is is ready. Um, and so it's just a matter of then just selecting it for the next available DevNet and integrating everything. And so I think this is the the two important milestones. Awesome. Thank you. That was great. like that was good to know all about not just this particular EIP but about other gas repricing EIPs that we would be bringing up for our audiences in upcoming episodes because Glam Dan is bringing them all. Well, now we can

perhaps quickly move on to our next section which is rapid fire round. So Jess here what we are going to do is have the questions answered in one word, one sentence or one minute. So if you're ready maybe we can get there. All right. In one sentence, what is Glamsterdam optimizing for? Scalability. >> It's even one W. Even better. >> Even better. Yeah. Whatever works here. >> Does this make Ethereum more L1 centric? >> I would say no. And the reason is like I think like bigger throughputs overall helps the entire Ethereum ecosystem both the layer 1 and the layer twos. So I see it as an enabler of the whole ecosystem.

>> Good. Actually that was my second question. Who will benefit the most out of this proposal? >> I think end users because they will experience lower gas fees. So the base fee will go down because the block limit goes up and so overall transactions should be cheaper. So yeah hoping the end users. biggest understanding about gas repricing >> complexity because it's actually very very simple. >> Yeah, we all the time hear people complaining about gas prices. They do not understand the complexities behind this.

>> Yeah, maybe it's like how actually like how intricate the benchmarking is. It's it's actually much more complicated than it it seems in the first look. >> Very well. What metrics will you personally watch post upgrade if these proposals are included in Glamsterdam? >> So metrics. So one of them is I think looking at the gas used and base fee. So we would expect again base fee to go down and the gas used to be at the 50% of the block limit. So this would mean that we'd start to have much more throughput and transactions would be would be cheaper. I think another important metric is we do have these

like slow blocks dashboard that looks into like and these are essentially like the attack blocks. So looking into these and making sure that no new bottleneck are popping up is also important. Yeah, I think this would be the important metrics >> really a piece of mind for a very large group of people who were worried about first of all security then how it's going to impact any kind of changes and so once we'll do it it will be fine I hope >> so if we have to say like what is the long-term impact on Ethereum with these changes >> well the fact we can do it and it's not that difficult the fact that well researched EIPs are actually important

and it it makes sense to put a lot of effort into well researching something and trying to showing to other people that this actually makes uh sense not just you know some madeup uh proposals. I know people have the best intentions but those intentions have to be based on some concrete uh data. Is there anything specific that builders should keep in mind in order to prepare for this CIP or for Glamsterdam in particular? >> I think Malia mentioned it briefly but hardcoded gas limit it's a big no no that's uh something that every developer should keep in mind.

>> If anyone is building the project new then they should definitely consider this. Well, one word for Ethereum future >> bright. >> Your thoughts Maria? I think I'm in general bullish on new users coming in and and us having a much more performant VM. >> Awesome. That was great. Now I would like one of you to maybe summarize 7904 in 1 minute. >> 7904 is changing the gas costs of a couple of compute focus operations including some op codes and pre-ompiles and they are making them more expensive.

And so by making them more expensive, this allows us to increase the gas block limit to allow a higher throughput overall. And so these are the operations that are the most underpriced based on current benchmarks. And so this change allows us to make those operations well priced and increase the overall throughput of of them. >> Thank you. Yes, Maria, for taking our time and talking about EIP7904. It was great listening and learning about the gas changes which are expected with the Glamsterdam upgrade. I wish all the best uh to all the co-authors of the proposal and hopefully we'll be seeing this proposal in the upcoming upgrade.

>> Thank you very much. Bye. >> Dear listeners, if you are one of those developers whose application may be affected, please reach out to authors with the website listed in the show notes. Do not wait till it is already deployed on the Ethereum mainet. There is an opportunity to test your application before there. So please be on lookout for the public test net and you should be able to test your application. For anyone who wants to get deeper into the proposal, please check out 7904 and also participate in discussion at ET Magician forum. We would love to bring more EIPs. Those are listed for Amsterdam. Until next time, keep building, keep sharing, and we will

see you with the next proposal. Cheers everyone.