Glamsterdam Repricings #4

Transcript

Maria Silva: Hello, hello?

Ameziane Hamlat: Yep.

Maria Silva: So, I think we can try and wait a few minutes to see if more people join, and then we'll kick off. Hi everyone, for the new joiners, we are just waiting a couple more minutes to see if more people join, and then we'll start.

Okay, so… We are 2 minutes in, so I think we can probably start. I'll share the agenda… But these, this call, we don't have as many topics, so I wanted to go over, EIP 8037, the State Creation Gas Cost Increase. So we had this discussion on the last ACDE, about whether we could add any changes to this EIP to make it work better with the other EIPs in the fork, and also to make it a bit simpler. And in the meantime, we had this proposal from Tony. To clarify, I'll also share here. But essentially, this is, clarifying how the pre-state and post-state gas validation in block-level access lists maps to 8037 and the costs that are,

And how it impacts the state gas and regular gas. So, maybe to… to kick off, I think it would be good, Andrew, if you can, maybe give, so everyone in the call is aware, like, a summary of your comment on ACDE, and in your view, what things maybe could be changed to… to… to make 8037 better? And then we can do a discussion on what makes sense, what doesn't make sense, any ideas that people may have, or comments. Sounds good.

Andrew Ashikhmin: Yeah, sure. So, it just, you know, just as I said, I have this concern that in Glamsterdam. That, we are making a lot of changes to the gas, and now it's turning to be… quite hairy and messy, so… like, before Glamsterdam, we had… we first introduced blob gas, so there is that, blob versus regular. Now, with block access lists, we are, like, considering pre-state gas checks versus post-state gas checks. than in… 8037. It's quite clever, it has the, like, the reservoir Model, and so on. And I understand that some of it It's, like, driven…

By, by, by, by, by this design decision to not, like, to not, Do multi-gas in earnest, but the result is that It becomes quite complicated, and this is, like, this third flavor of state versus regular gas. And then, with, 77… 7778, it has to do with refunds, so essentially it introduces a fourth, flavor to the gas, user accounting versus block accounting, and I can understand the motivation behind all of those changes. In isolation, but it just, maybe we have to do it, but I think we have to admit that we are complicating

the gas in… in Glamsterdam quite a lot, and there are many nuances, and I don't have a solution, it just… just… I wanted to share my… my worry. That, yeah, that we are having this… a lot of complexity. So, unfortunately, I don't have a good solution. And initially, I thought that maybe we can… maybe… when we talk about state gas in 17928 block access lists, and then in 8037, it should be the same state gas, but no, they are addressing different things. In block access lists, we are talking, like. Pre-state checks versus post-state checks, while… In 8037, we are talking about, like, state modifications of state growth, versus everything else. Nevertheless, it just… my worry remains, yeah, it's just coming… I don't know.

Yeah, so that's… I just wanted to share this story.

Maria Silva: Goldwish?

Luis Pinto: Yeah, so I… I don't… I don't have much of an opinion on the pre- and post, gas on the, on the VALs, but… as I've suggested, some time ago, maybe it makes sense to merge the refunds and the state gas, because At the end of the day, both are, like, incentives for, incentives or disincentives for usage, for, storage usage. More so, so it's kind of different than the regular gas, which is kind of, computation, client efforts, that it has to do, to, to make to… process blocks. So, in my opinion, I think these two, parts of VIPs are, are related to reflect that, in the state metered, like.

Maria Silva: Sorry, I'm not sure if it was just me, but I think it broke the bit at the end, but my understanding is, like, you think that, essentially the refunds should go to state gas instead of regular gas. Is this the… the TLDR?

Luis Pinto: Yes, yes, yes, that's my… That's my take.

Maria Silva: Okay. My understanding is, like, I remember Marius saying something about that, making the implementation itself a bit more complicated, but I'm… I'm not too familiar about that. I don't know, Marius, do you have an opinion on that one?

Marius van der Wijden: Not really, like, I think the… I don't think it is that… that complicated. Like, yes, definitely the refund is the one part… Where if you are running out of normal gas in a subcore, the subcore reverts, and you don't get that gas back. But the… Problem is that with normal gas, you can specify that… how much gas you are giving to the subcall, in order to say, okay, like, I'm just giving a tiny amount, if the call reverts. then that's fine, I can continue on with my execution. With, with, state gas. We are passing the gas… the state gas reservoir into every subcall, so if we would… Just, like, if we would not give that gas back, the state gas back, then,

If you, yeah, if you fail a subcall, it would not just burn. A bit… the bit of regular gas that you gave to it, but it would burn all of the state gas that you… that you had. So… And, if you are… If you are… passing state gas, and the subcore reverts, no state changes will be made. So, the… The principal thing is to return back all of the state gas if a subcore reverts, right? Because there's not… there are no state changes, so you… be paying for any state. So, yeah, I… Yeah, I also came around to that viewpoint, that it's basically, this is…

This is the best version of the EIP that I can see right now. The… the things that are, and I think it is pretty… It's pretty clean within the EVM. I think the only… the only questions, the only, like, The ugly parts are… when it's kind of outside of the EVM itself, so the gas accounting between transactions, and with that also the… The receipts. And, I don't really agree that we have now 4 types of gas, or something, like Andrew said, but I do agree that we, that gas is being significantly reworked. And, many AIPs are touching the same stuff. And, I'm making it… Much more… or much harder to reason about, about, gas, especially…

like, in the outer layer of the EVM. So, basically, everything that is not inside of the EVM, but the user… the stuff that we use to, to… to fill the receipts, and the stuff that we use to make sure that the block is not running out of gas, and so on. So, yeah, that logic… It's a bit… it gets a bit murky with 8037, and… Block access lists, and… The… I think it prints for one? Or, like, this other one that also changes the receipts, but, I also don't really see a better way than what we have right now.

Maria Silva: Luis, you still have your hand up, do you have any additional comments, or was it from the previous one?

Luis Pinto: No, it's still from the previous one, sorry.

Maria Silva: Okay, Tony, do you want to speak now?

Toni Wahrstätter: Yeah, maybe just to provide some additional context, When it comes to block access lists, so one thing we changed there… was also what Andrew was talking about, is when do we actually charge for certain gas? For example, for block lab access lists, it matters a lot if… when do we run out of gas? For example, there is things like checks if an account exists already, and then that can be done after accessing the account, but then there are things like memory expansion that is done before we even go to state. And this suddenly became, like, important, because clients could, up to block their access lists, implement that as they wanted. And, for example, we realized that GAF and the specs were aligned, but other clients did it in a more optimal way.

That was already fine for block lab access lists, but this also meant we had to change the specs, and GAF had to also change some of their code. So, this is… this is what we mean when we talk about the gas changes coming from block web access lists, that suddenly it mattered in which order we charge certain things. And… The good thing is, we are now very sure that clients do it Similarly, and we have tests for that, so shout out to Philippe and Rahul. I think Block Live Access List is right now the most tested EAP we ever had. And all those edge cases are… So we have test cases for all of them, and I would just stress that

Also, for 8037 and all the other smaller EFPs that interact, we just need to make sure that we understand the edge cases very well, and prepare tests for each of them to make sure that If we ship them, and they interact with each other, that at least we have, 100% certainty that nothing breaks.

Maria Silva: So I think… so there's two things that I wanted to take from this call. So first is just trying to understand if there's any improvements we could make, and it seems from what I'm hearing is, like, there's still some concerns, but there doesn't seem to be, like, a concrete proposal of Improvements we could make. maybe I can give a bit more time for us to discuss this, but if not, I guess the other point is also Increasing our confidence on the testing… coverage of all these… of all these EIPs, And so, on that note, I think, it's a matter of, like. making sure that, as you guys keep implementing the EIPs, you raise, like, new issues that you find, so we can continue to improve on the tests.

But also to say that we will be doing a more in-depth security review once the… all the full repricing package is finalized. So that's, that's also, in the plans to, to, to make sure that things look, look good. But yeah, I don't know, are there any more comments or suggestions to… to… to improve.

Toni Wahrstätter: Maybe one thing, I posted the PR I had, again, in the chat. It would be great if we can just also specify that a little bit clearer in 8037. So, would love if clients could have a look and give some feedback there. Basically, what part of the gas do we have to check, pre-state access versus post-state access, such that we have alignment between Block level access lists and 8037 there, so please have a look.

Maria Silva: Yeah, thank you, Tony. I think, yeah, agreed, if you could, guys, could take a look and comment, it would be great. Dragon, do you want to add anything?

Dragan Rakita: Yeah, in general, the… the… the way how I think about it, the regular should be spent first. And when everything is, like, finished, checked, that means every account is loaded, storage is loaded, whatever needs to be done, then the state guess is spent. Why does this matter? We have refilling of reservoir, spilled reservoir, at the revert and on hold. If we have different, order of deducting regular gas. Against the reservoir gas, we can get consensus issues here. Because the… if we first deduct the state gas, then we fail on reservoir gas. That means that state gas will get refilled, or basically spilled over. The regular… the reservoir from the parent.

So I think I talked with, yeah, Spencer, and yeah, I think we need to clarify slightly the AIP to say the state gas Needs to be, like, deducted at the end of the… all… after all the regular gas deductions.

Maria Silva: I think that… I think that makes a lot of sense, and I think we should… should… should make that. I can open a PR for the… for the EIP to… to update it. Are there any comments on why this doesn't make sense, or… Do people generally feel like this makes sense? Okay, thank you, Turagan. Anything else, or any more comments on… on these? And maybe I could ask, like, how… how are you guys on the implementation side? Like, is it, how… how has it been going so far?

Marius van der Wijden: Our implementation is passing the tests? I already implemented the basic part of 8037, like, a couple of months ago, and I recently updated it to the newest spec version. And now to the newest test version. So I had a bit of a, like, earlier start than other implementations, but for us, it's okay.

Maria Silva: Do you want to… Danielle, do you want to go next?

Daniel Lehrner: Yeah. So, from Besu side also, I mean. Our biggest challenge is just that, execution spec tests have been changing in the recent weeks. Several times, I think we had version 3. In general, I think we had all the tests passing at some point, but then we need to change the implementation again, so that's what's costing us time at the moment. So I… I don't know if maybe at some point you want to say, okay, we just use the current version of the tests as the one for Bar Defnet 3, and maybe other changes we want to do to 8037, we… we do it in the next DevNet, because for the gas repricings, we need another one anyways. So this… this… this would help us, finish it, because right now, it's like…

trying to hit a moving target. And we are close. I think we have, like, two failing tests with the latest version. So if we keep this one and don't change the specs again, I think we would be ready soon for… For, definite.

Maria Silva: Cool. Spencer, do you want to… to… to talk on this point?

Spencer Taylor-Brown: Yeah, sure, I totally agree, it's… it's… Being, like, a moving target and a… I'd say it's, primarily been because of, others finding Issues with the spec. So, after each spec issue and spec clarification, we've, updated the tests. That might have not been communicated very, very clearly. and… I do plan to create another release, so it might change again, so apologies, but I feel like that… that should hopefully be, like, the final cutoff, And people are happy with that, Yeah, I just wanted to comment next. But yeah, I do feel like we're… Starting to get in a good place, because it feels like most exciting. Gave good feedback, and found edge cases, so… yeah.

Maria Silva: Okay, and before going to Drogan, because I think you'll… maybe Stefan also has a comment on this topic, or is it a different topic, Stefan?

Stefan Starflinger: No, I just wanted to say that we should differentiate between changes to the spec when we have a test release, and just adding more edge case testing as well, because if I… We're on a kurtosis network right now with EVM fuzz. It's pretty easy that most clients run into some issue at the moment. And at the moment, this EIP is also pretty difficult to test, because you have to trace every single transaction to find where is the gas discrepancy, and then you have to figure out, okay, which client is implementing it correctly. And so far, I have the most confidence in the Geth implementation, but still, like, I'm still not sure which client has the right implementation to really

compare and see that it's working together, and it doesn't make sense to start a DevNet. Even if all the tests are passing, there is some edge case where then all of the clients will fork into different directions.

Maria Silva: Okay. Makes sense. Dragan, do you want to speak next?

Dragan Rakita: Yeah, physically… I would say similar to something that Stefan said. Spencer, yeah, it was only target because… I did implementation on REVM, and I started running tests, and I found that tests are not okay. So there was a few iterations, like fixing all of that, and, like. Figuring out what's the correct thing to do or not. And I do agree with Spencer that the last iteration, the next test version that we are basically releasing. should be okay, because I think we passed all from, like, the… the execution loop to the… out of that, so I think we covered a lot of things there.

Maria Silva: Perfect, thank you. Andrew, do you have a comment?

Andrew Ashikhmin: Yeah, I wanted to tell about implementation in Erigon. So, we have a draft implementation. Unfortunately, the team member, Milan, who is working on 8037, I fell ill, so… but I see in his draft implementation that we now pass all the tests except for 4, and those four, I think they are not even 8037. So, yeah, hopefully, when he recovers in a few days, we'll have, an acceptable implementation.

Maria Silva: Sounds good. Perfect. And Nethermind, Ben, do you have any updates on 8037? I'm not sure if you are the one working on it.

Ben Adams: I think we're good, we're just, following… Things as it's coming out, and… And the test was there, right? We have done Marius's change. Yeah, I have said before it was quite complicated, but… Yeah, I don't have any suggestions on how to… How to improve it. It's like a necessary… we need to do something about… State gas, and… I can't… I can't tell you a better method today.

Maria Silva: Okay, perfect, thank you. Any more comments or things that people want to discuss on 8037? Spencer, do you want to…

Spencer Taylor-Brown: Sorry, yeah, I guess… I guess I'd just ask, are… are people happy with… our final test release, in the next, day or two, and then we just use that as the base, and I feel like, yeah. As we haven't mentioned, it should… Everything kind of should be aligned… aligned well and cover most, important edge cases. And then we use that as the spec for DevNet Free, and if there are any other non-critical edge cases, we can make that for the release in DevNet4.

Ben Adams: Can… can the, Is that going to be in the new format of tests, or in the prior format?

Spencer Taylor-Brown: So, would be the same, the same format as the previous, previous release. I think, I'd say the main… the main, the main change in addition would be just making sure that.

Ben Adams: I mean, there's… there's, like, a new JSON layout for them. For the East test. That's coming.

Spencer Taylor-Brown: I think… I think that's already in the… the most recent… recent releases.

Ben Adams: Okay, so we'll need to update that. Thank you.

Maria Silva: Seems like there was a lot of thumbs up on one last release in the next couple of days, Does anyone… does anyone want to raise anything against it, or… Okay, so seems like people agree, Spencer. Cool. Anything else on 8037 people want to bring up? Okay, so… If not, I just wanted… so this will be a short update, so I just wanted to give you a quick update on the benchmarking effort, which is relevant for the compute reprice, so $7904, and also the state access reprice, so 8038, and the ETH transfers, reprice.

So on that, We are now doing two things in parallel, essentially. So, one of them is starting to run repricing benchmarks on, BOLT-optimized, clients. So we did have to make some updates on the testing infrastructure and the tooling and the tests themselves. And we should be able to start collecting data on these, this week. So this is important, This will be a big step for the compute reprice, where so far we've only had the preliminary numbers, and once we have the runs with the optimizations, we can start getting more, like, finalized numbers that take those optimizations into account. On the compute, benchmarks, we also had an update on some precompiled tests that were… essentially, they were being too fast because they were being, like, there were…

There… there was this issue where you could essentially not recompute everything and just read from the cache, Because the precompiles always had the same inputs, and so now we are… we have much more robust tests that change the inputs every time, and so we should be able to see We should be able to see, like, more realistic numbers for those precompiles. So I would expect that, in the next couple of weeks to, to, to start having the final numbers for 7904. For the state access, so this is the other thing in parallel, which is, benchmarking state access operations has been much harder, and much more complex than we initially thought, in the beginning of the year, so we had to do a lot of

Updates to our tooling and to our tests, and we are still… In the back-and-forth stage, where we are doing some fixes on the test, rerunning everything, checking the numbers, and some numbers sometimes don't look… don't make sense, and so we need to go back to the… to the test and… and… and the process and make sure that things look good. So, at the moment, we are in the third iteration of, of these, and collecting, early results, and so I don't have yet numbers on these so I can show you, but just to let you know that We are, in this iterative phase, and, we are starting to see some numbers, but I don't think they are ready yet to share, because we still need to collect a few more… few more runs.

But yeah, I would expect by the next, breakout call to maybe have a more… To be able to give you an update with these numbers. Yeah, so this is the status, so we are a bit delayed on getting numbers for the state access EIP, but yeah, we are working, tirelessly to get those numbers as soon as possible. Any more comments on any repricing EIPs, or… Questions people want to raise? Cool. Cold dragon?

Dragan Rakita: What would be rough plan when this is going to land? Easy.

Maria Silva: Do you mean the state access EIP?

Dragan Rakita: More about gas repricing. Should we expect it something like DevNet 4 or DevNet 5? I'm not, I'm just asking, I don't want to put pressure.

Maria Silva: Right, right. So it's hard for me to say a specific definite, so my initial plan was to have final numbers by end of March. And then have everything ready by interop. I think now, final numbers by end of March, I don't think it will very likely happen. And so I think maybe we are looking into, during April. adding it into a DevNet. I'm not sure if that would be DevNet 4 or DevNet 5. But I think this should be, like… I do, I do think that by interrupt, we should have… final numbers and a good progress into having everything into a DevNet, so then we have time We give time for the community to adjust, because there will be a lot of, like, contracts and dApps and tooling that needs to be updated, and it's nice that they have, like, a stable

DevNet with enough time for them to… To… to update.

Dragan Rakita: Yeah, after we have that in our EVM, we can propagate that to… Foundry to everybody, so the tooling is… Could support all that.

Maria Silva: Yep. Yeah, in parallel, we are also doing a lot, like, Carl from the EF is also working on a backward compatibility analysis, and we are starting to contact specific top developers that are affected. But again, like, they will only know exactly what changes they need to make to their contracts until they have, like, a stable set of numbers and a stable definite that they can test against. So that's why I think we… it's important that we give them We integrate these early on so that we give them enough time. Perfect. Any more comments, questions, feedback?

Okay, so if not, I think we can wrap up early and give you some time back. Thank you all for… For coming and, And yeah, I'll see you, see you around.

Jochem Brouwer: I think so.

Maria Silva: Bye, everyone.

Ameziane Hamlat: I'm gonna fix.

Toni Wahrstätter: Thank you, bye-bye. Thank you.

Maria Silva: Bye.

Andrew Ashikhmin: Goodbye.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.