speaker-0: The big thing that these repricings allows us is to significantly increase the block limit.

speaker-1: There were many factors like algorithms changing constantly and measurement methods changing constantly and so on. And hopefully this EIP fixes the problem that we created a few years ago when we implemented point evaluation pre-compiled.

speaker-0: The reason why this puzzle 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.

speaker-1: We created an EIP 7904, 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 EIPs are actually important. I think Maria mentioned it briefly, but hard-coded gas limit, it's a big no-no. That's something that every developer should keep in mind.

speaker-2: Who will benefit the most out of this proposal?

speaker-0: I think end users because they will experience lower...

speaker-2: Welcome back to PEEP and EIP. This is episode 159 brought to you by ECH Institute. I'm your host, Pooja 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 reprising. We are going to talk about EIP 7904 compute gas cost increase. This is a proposal being considered for Glamster Dam 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, Yasek Glane and Maria. We would learn in next 40 minutes or so about this proposal. Welcome you both. ⁓ Thank you. Thank you.

speaker-1: Welcome

speaker-2: So I understand this proposal is built over EIP 7883 that was deployed with the Fusaka upgrade and there are some interesting trade-offs 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.

speaker-0: Hi, hello everyone. I'm a researcher currently working at the Ethereum Foundation. I'm part of the repost 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 of months. to align the gas costs of the EVM with the 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 at that bottleneck in. 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 big part of this effort.

speaker-1: My name is Jacek, I'm a software developer at heart. I've been doing it for many, many years now and I still enjoy building software. About four or five years ago, I discovered the wonderful world of blockchain, Ethereum specifically. And then I had a pleasure of working for the Ethereum Foundation, different research 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 there's the whole history that we're gonna go through it. I'll give you some details on what people were thinking and how it was going. And the outcome of this project, which lasted for three years, I think, in total, not continuously, but with some gaps, but it's been quite a long journey. We created an EIP-7904. ⁓ which initially was very conservative, revolutionary, then conservative again, and now it turned into conservative but on different scopes. So, gas pricing 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. will always be someone who's... dissatisfied with the stuff. But hopefully we'll get somewhere with this 7904 and because it's the, in fact, the first EAP that looks at guest repricing from that perspective, like not a single thing, but trying to take the whole one. So hopefully we'll open the door for many more repricing in the future. Why? I think we can discuss it later why we need more gas replacing after that. Of course not everyone agrees but just my opinion but we'll see.

speaker-2: 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 roadmap, but I'm glad it is here. If I understand correctly, it's going to change your 13 opcodes plus precompiles, gascasters, 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.

speaker-1: Okay, so, gas liptising. 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, not the whole community, some certain individuals were behind it. Many thanks to them for starting the whole nice 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 a proper benchmarking at the time and that's why I'm saying it's surprisingly very accurate. So when we started off the journey, the research project, We immediately assumed that most of the opcodes must be wrongly priced. And it was our discovery that we were quite wrong. There are some nuances to this, but this stuff is not as inaccurate as you would think from just someone's estimate 12 or 13 years ago. But anyway, we think this gas schedule needs an update. Why do we need that update? The point of gas... schedule is to show how each operation actually costs on a node executing that 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 contracts. 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 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 mispriced, you can prepare a vector of attack which targets a specific mispriced operations and therefore cause 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 opcodes 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 coding is that rather than setting something to zero, you use XOR operation. 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 opcode. 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 that we can reproduce the efforts many times after our initial project has finished. The reason is that All the EVM clients which execute those contracts, 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 constantly. And here we go. At the bottom of it, we want to measure single operation. It's either an opcode like an add, multiply or whatever, or a precompile from EVM point of view, APT compile 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 smart contracts, like caching, wall maps, processor architecture, any other hardware things, I.O., disk speed. what kind of language it was written in, does it contain a garbage collection or not, and so on. And is your running under some load or not running under some load? All those things are important for anyone running a note in a 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 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 the back of those results. It means, unfortunately, that your EVM engine needs to run in some isolation. It has to have some predictable storage, history that we control, which allows us to reproduce those results, you need to reduce the network traffic to absolute minimum and the whole host to be 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 ⁓ 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-heel, where you 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 executed for and you can measure a single operation. Again, does carry a lot of trade-offs with itself, but we can actually prove that this method accurately represents the cost of running a single operation. So in this case, we have an add operation and we can see if we were to measure a single add, which is on the left side here and it was something like two microseconds, that would be completely inaccurate. But as we add 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, add operation in here. Okay, you could argue what about this initial set up here. It costs a lot to run the first one and then doesn't cost 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 transaction or block. by measuring a single operation, you still have the accurate gas cost because gas cost is not, it's representative only. measure to represent some kind of a cost. It's not very linked to a reality like it's not in nanoseconds or any other units. It's just a representative cost. Okay, so how it works. We created all of those kinds of contracts running 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 operations, for each of the ⁓ EVM clients. Now, we normalize those operations, measurements, we remove outliers, try to put them on a single picture, really. And we do actually have a picture like this, which allows us to compare those clients with each other. I mentioned the picture, this is the actual picture. So after all this measurement, when I say all these measurements, we have to acknowledge the fact we are talking about thousands of contracts, blocks, billions of executions really because we iterate over the same executions over EVM clients, opcodes, and so on. And then we use some statistical methods, regression mostly, to come up with a single cost of operation, and we can compare clients. The detail skill doesn't matter. What I want to present here that many of the opcodes, like we see at Doop, or swap opcodes on the right, they are surprisingly similar across the clients. Some of the opcodes, like let's see the MLOT or MSTORE EXP, the variety between the clients is quite big. And the question is now, it's easy to propose some change when all the clients match. What do you do in a situation when you have a spread? let's say most of the clients execute an operation in X units, but one of the clients executes that operation in 20 X, 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, your new cost, cost, 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 GAF more important than Erigon? Because GAF is at the moment worth 30 % and Erigon is 2%. Does it matter if Erigon is completely mispriced? Because in the worst case, all the nodes running Erigon will break down in some sense or try to break the network down. And because they represent only 2 % of the network, it doesn't really matter. So we had a lot of discussions like this, what we should really take into account. But after making some of the decisions that are all documented, we came up with a new proposal. And as I mentioned, the 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 opcodes at the one point and only adjust both opcodes which were completely misplaced one way or another. The second approach was to keep most of the opcodes 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 at 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 opcodes were priced at one, with some exceptions to keep the current gas cost. And that proposal would reduce the typical contract by about 30 or 40 percent 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 reviewed the network security and figure out that increasing a gas cost of a certain operations will not be so dangerous to the network. The reason why it was dangerous is because some of the old contracts were using a gas limit when calling it. it was important for the backwards compatibility not to increase the gas cost because this gas limit could have been exceeded for the old contracts. But this worry wasn't as serious as we initially thought. So increasing the gas cost for some operations, it's not that dangerous. This is the most recent proposal. We identified some of the opcodes which needs to increase in the cost, some of the pre-compiles which also need to increase. These are not very drastic 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 operations and adjust them. I think the best point is the point evaluation precompile here. From the very beginning, we actually knew it's not priced correctly. I worked at the original pricing of this precompile. Honestly, I don't know how we came up with the 50k gas cost, even though we did know it's not accurate. There were many factors like algorithms changing constantly and measurement methods changing constantly and so on. and hopefully this EIP fixes the problem that we created a few years ago when we implemented point evaluation precompile. Coming back to some measurements and how accurate they are and that the whole operation actually makes sense, we can see here different clients giving very good results when we measure some individual operations. That's interesting. initial work looked at each of the clients specifically. For each of the clients, we created a report and gave it to corresponding implementation teams. Our report, our findings. And like here, for example, Erigon had a hidden bug that push operations get more expensive on Erigon depending on the argument size. Doesn't really make sense, but... It was very hidden back. 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 doesn't stop here because... The landscape changes, the EVM clients change constantly. We want to make sure that the same process is happening over and over again. And we already made a lot of progress on this side. So the Ethereum latest benchmark suite is very good in automated measurement of all of the stuff. One of the things that we removed from the original EIP was the memory replies. We removed it because there were some other proposals and also they will talk of the multi-dimensional gas prices. As far as I know, nothing of that has materialized. So maybe we should bring back the original memory gas replies EIP, which was very simple at the sum 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, was called Gas Cost Estimator, but more importantly, Ethereum benchmarking is the place to look at the moment. And of course, the EIP 7904. Hopefully that will make its way to Glamstodon.

speaker-2: Thank you so much. 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 in a set.

speaker-1: Yes, it is attached to 7904.

speaker-2: I think this is rare in the history of EIBs 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 for all the ongoing work in Pradhal. So thank you to the entire team. 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 references and clarification, we have a few questions for you.

speaker-1: Thank you.

speaker-2: So my first question is why now? Like we all understand that this gas pricing 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 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?

speaker-1: One of the answers is now, because we managed to push it now through all the usual buttons that you have to. We managed to agree on what it is to go and be implemented now. And it's a long way. We didn't have something like this before in Ethereum 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 Ethereum is more mature now and we actually need to make sure that the cost is not the actual cost, not some made up cost. And we have enormous tooling. What Ethereum Foundation and all people involved in it, getting the benchmarking though, it's really a lot of good work and I'm really happy to see how it works. But Maria, of course, you have a mother to say on this.

speaker-0: Yeah, I think I 100 % agree with you. 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 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, was like a really big problem because a lot of contracts had like hard coded gas costs 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 easily. And I think in the future, this will become more and more common as the asset was saying, like maybe we have like a more automated process that every fork like checks like with the new EIPs being added, is there any new bottleneck that is coming and do we need to make any adjustments to the gas costs and we make those adjustments. So I think as we move forward, this process will be more more streamlined and we'll start having more and more gas costs aligned with the actual execution resources that are being used.

speaker-2: I would agree 100 % here. The process seems to be way more streamlined 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 glancer down gas repricing proposals. What makes a 7904 more unique? Why do we think that it should be considered for Amsterdam?

speaker-0: As a way to kind of answer this, I'll also give some context on what changed since the proposal that Jasek 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. But this essentially during the discussions of what the IPs we showed introduced or not, there was this worry that we were changing too many opcos at the same time and this for testing would be very, very difficult given also the already big size of the fork that we have that is Glamster, which is 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 the same thing as Jacek 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 of 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 reprice less operations, which is easier for testing and backward compatibility analysis, and then increase the gas limits. And so now if you go to the EIP, we are only changing really 13 operations, like half of them are pre-compiles and the other are opcodes. And the reason why this puzzle is so important and this... was like a, 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 these 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. we don't have like in terms of implementation, these EIPs are pretty simple. You are just making a few changes in the constants, but the work behind getting to those numbers, it's really interesting. Like the approach that the asset takes is very smart. Like the regression doing like different blocks with different numbers of each opcode and then just computing the marginal increase. Like, so really, I don't know, like as a data scientist, find it is, it's really interesting and also from a developer perspective like building these blocks 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 make it more consistent and also improving the analysis itself.

speaker-2: Yes, I think Maria rightly mentioned the approach behind it was ⁓ unique. was like I was seeing it for the first time here in the EIP's documentation. 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, ModExP 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 a lot of contracts because it could break as... Some of them may be historically using the hard-coded value so that can disturb them. I'm curious to understand, do you guys think that this will improve the process of selection of EIPs 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?

speaker-0: So I would say this is one of the things that we've been working a lot in the last couple of months. We do have some benchmarking tooling, but it was pretty like scattered and 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 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 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, it's 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 are coming in this fork. And as an example, like one of the headliners 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 List and integrating it into the benchmarking process. And also, I think they're still working on integrating the different steps of the benchmarking and making it more automated. But for sure, I think in the future, it will become more and more automated where we can just plug the fork and run all the benchmarks and then collect the final cost prices.

speaker-1: Yeah, so when we started, we tried to juggle many different interests like increasing throughput or network security and so on. Now, from my perspective, least, the network security when it comes to 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 ways, either increasing block gas limit or running transactions in parallel and all other improvements that have been done in Ethereum. So probably at the moment we're mostly looking at identifying problematic operations and adjusting them, well, increasing costs mostly to the level that brings back the security to the network.

speaker-2: 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 devnet specifically for testing this?

speaker-0: Yeah, that's a great question. So at the moment are in DevNet. 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 it's mostly around state growth, so state creation. So we are not yet integrating everything like we are not integrating the 7904 yet into a DevNet. And the reason for that is that we first want to finalize the numbers and then we'll integrate it. And so what we are doing is like now we have a stable DevNet with the block level access list optimizations that clients are implementing. And so we can run on our benchmarks on these DevNets, essentially these releases of our stages of the clients. And then we derive the final numbers. And once we have that, then we integrate it into the next available devnet. And then that's when we start testing. And so this is in general the process. At the same time, 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 Puta from the protocol coordination team at Ethereum Foundation, he's been doing an amazing work there. So we are starting to contact big contracts that we see are starting to break for some reason and warning them so that they can adapt. So this is also like an important part of testing that is not necessarily integrated into a DevNet. So it's mostly about like rerunning historical transactions and seeing what breaks.

speaker-2: 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 there would be the right time when these people can maybe check their applications that they are working as expected and it is not being damaging to their projects?

speaker-0: Right, I think that's a great question. So we do have a website that brings together all the information on repricing. It's essentially gasrepricing.netlify.app and there you have all the information on repricings. We also have a simulator that was worked on by the ETHpandaOps team at the Ethereum Foundation. And essentially in this simulator, you can essentially change the gas prices and replay blocks. So essentially you can like pick a block where you know your app was being used and then you can do the changes. It already has a default for the current ⁓ Amsterdam repricings. Of course, a big caveat, this is not still final numbers. And so it's the preliminary numbers we have, but you can already see what breaks and how different the gas costs in those transactions are. So this is step one, like I would urge you for you to explore it in terms of timelines. So we do want by end of April to have all the repricings with final numbers and integrate into a dev net. And so after that, once we have like a ⁓ stable dev net, we can start a more like public test net and then people will be able to go and test. But I would say. At least until end of April, we would expect to have final numbers and DevNet integration.

speaker-2: 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 smart contract will most likely feel the impact of 7904?

speaker-0: 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 hard-coded gas costs affected. If the hard-coded gas costs are being changed, 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, increases will likely make you hit this. And so for instance, an example is gas proofs of optimistic roll-ups. Like there are some cases where this could be like right over the edge. And so this is also another case where you definitely need to check it and make sure that your transaction cost is not going above the max limit of a transaction. But yeah, 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 too general cases that we are seeing.

speaker-2: Yeah, that is good to know. So I understand that there could be some DeFi protocols or some AMM projects. may have like hard-coded guess 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 re-auditing of their projects or just testing when the public testnet would be sufficient?

speaker-0: Yeah, for sure is like first is you'll have to test on the public test net to see what is breaking. For most of the things you are in an upgradable contract and you can trust make changes, but essentially you'll have to likely make changes to your contract and what the changes are. It depends on what depends on the contract, but I'd say like the first step would be testing on a test net and then yeah, understanding what needs to

speaker-2: Very well. So let's move on to the roadmap of Ethereum. I understand that we are now having multi-dimensional gas values and we have roadmap Elvin 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 Elvin centric roadmap in mind could more accurate compute pricing make certain types of on-chain computation more viable on layer one directly? What are your thoughts on that?

speaker-0: So that's an interesting question. 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 get like creating state, reading from state and writing to state will become more expensive and pure computation things will become cheaper. so with this, think, and this is independent of the multi-dimensional fees and so on and so forth. With this, will likely, so as pure computation things becomes cheaper, there could be like new applications that come and make use of this. It's hard to predict what will come because 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.

speaker-2: 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 Glamster Dam 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?

speaker-0: So I think like the majority of the repricing for GlamsterDAM is all about solving the single bottlenecks. So making sure that the few operations that are impeding us to increase the block as 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 nuanced, 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 CAS that is measured separately from all the other regular CAS. 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 marks that control how full a block is. And maybe this would be a good topic for another podcast because this CIP is quite complex, but this also it's introducing these 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 four hours 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 AIP is kind of like the first steps in that direction.

speaker-2: So do you see all proposals which are listed in 807 would be part of Glamster Dam or do we see that some of them may be dropped at some point and the list will be short?

speaker-0: 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 this process is very, ⁓ 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 EIPs are in a good position to be included. For the ones that were declined, there could be some that go in in the next four. But I think we are still early stages to see exactly what will go and what will end up never being implemented. I think also a lot is changing in GlamsterDAM in terms of EPM execution. So with the block level access list 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 EIPs we are considered for Amsterdam, they are important and I think they will mostly go through. And then for the next fork we'll need to rethink and pre-benchmark and see what are the next things that we need to address.

speaker-2: 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?

speaker-0: So I think there's two defining points. So first is yes, having the final numbers. 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 access list. 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 these benchmarks, the optimizations. And so this is milestone number one is having final numbers and then the final milestone is being integrated into a DevNet. So once we have final numbers, integrating into the DevNet will be easy because we already have the testing framework ready. We have the specs mostly ready. It's still with placeholder numbers, but the PR is ready. And so it's just a matter of then. just selecting it for the next available DevNet and integrating everything. So I think this is the two important milestones.

speaker-2: Awesome, thank you. That was great. Like that was good to know all about not just this particular EIPs but about other gas repricing EIPs that we would be bringing up for our audiences in upcoming episodes because Glanster Dan is bringing them all. Well, now we can perhaps quickly move on to our next section which is rapid fire round. So, Yesik, here what we are going to do is ⁓ have the questions answered in one word, one sentence or one minute. So, if you are ready, maybe we can get there. Alright. In one sentence, what is Glamster Dam optimizing for?

speaker-0: yellow bullet.

speaker-1: That's even one vault. Even better.

speaker-2: Even better, yeah whatever works here. Does this make Ethereum more element centric?

speaker-0: I would say no. And the reason is I think bigger throughputs overall helps the entire Ethereum ecosystem, both the layer one and the layer two. So I see it as an enabler of the whole ecosystem.

speaker-2: good actually that was my second question who will benefit the most out of this proposal

speaker-0: I think end users because they will experience lower gas fees. So the base fee will go down because the block limit goes up. so overall transactions should be cheaper. yeah, hoping they use the end users.

speaker-2: biggest understanding about gas repricing.

speaker-1: complexity because it's actually very very simple

speaker-2: Yeah, we all the time hear people complaining about gas prices. They do not understand the complexities behind this.

speaker-0: Yeah, maybe it's like how actually like how intricate the benchmarking is. It's actually much more complicated than it seems in the first look.

speaker-2: Very well. What metrics will you personally watch post upgrade if these proposals are included in GlamsterDAM?

speaker-0: So metrics, so one of them is, 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 50 % of the block limits. So this would mean that we'd start to have much more throughput and transactions 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. I think this would be the important metrics.

speaker-1: Really a peace of mind for a very large group of people who were worried about first of all security and how it's going to impact any kind of challenges and so on. Once we'll do it, it will be fine. I hope.

speaker-2: So if we have to say like what is the long term impact on Ethereum with these changes?

speaker-1: Well, the fact we can do it and it's not that difficult. The fact that well-researched EIPs are actually important and it makes sense to put a lot of effort into well-researching something and trying to show to other people that this actually makes sense. Not just, you know, some made-up proposals. I know people have the best intentions, but those intentions have to be based on some concrete data.

speaker-2: Is there anything specific that a builder should keep in mind in order to prepare for this CIP or for Glamster Dam in particular?

speaker-1: I think Maria mentioned it briefly, but the hard-coded gas limit is a big no-no. That's something that every developer should keep in mind.

speaker-2: If anyone is building the project new, then they should definitely consider this. Well, one word for Ethereum future. Your thoughts Maria?

speaker-1: light.

speaker-0: I think I'm general bullish on new users coming in and us having a much more performant EVM.

speaker-2: Awesome! That was great! Now I would like one of you to maybe summarize 7904 in one minute.

speaker-0: 7904 is changing the gas costs of a couple of compute focus operations, including some opcodes and pre-compiles, 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 them.

speaker-2: Thank you Yasek and Maria for taking out time and talking about EIP 7904. It was great listening and learning about the gas changes which are expected with the Glamster dam upgrade. I wish all the best to all the co-authors of the proposal and hopefully we'll be seeing this proposal in the upcoming upgrade.

speaker-1: Thank you very much. Bye.

speaker-2: 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 mainnet. There is an opportunity to test your application before there. So please be on lookout for the public testnet 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 ETH 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.