Glamsterdam Repricings #5

Transcript

Maria Silva: Hello, everyone.

Ameziane Hamlat: What was it? No.

Maria Silva: Hey, hey. So, as always, I would suggest that we wait maybe one more minute to see if more people join, and then we can start. Okay, so… I don't see… more people joining, so maybe we can kick off. So I think the agenda today is a bit lighter, so we'll be focusing on the State Growth EIP, so AT37,

As the other EIPs, we are still working on the latest benchmark data collection, so there are no… no, no updates there. so on, 1837, maybe, Spencer, if you could, maybe you and Stefan, if you could give, a quick update on the current status of the Ball DevNet 3, and, any pending things we need to figure out and discuss.

Stefan Starflinger: So in general, we have, I think, in the channel, 8037, been discussing, kind of, how we should progress, and… I think we decided that Spencer is gonna make some small adjustments, and gonna release another spec change with these small adjustments. I think Erigon shared something, then I have some tests, that will be potentially added as well. And then there is the question. I think which will not be added, to the next spec release, with the parent, state gas refund. That's something we can discuss, but maybe Spencer, are you here? In the car?

Spencer Taylor-Brown: Yeah, I guess, Just to kind of relay what Stefan, mentioned. I think, I mean, ideally, we wouldn't update the spec. Just to get DevNet Free up and running, but I think… Because we have, We have, kind of, different… issues with the spec that different client teams have found, so Erigon found one. And rest, fund, found more, Nether, Nethermind, Has, has one. So I think it's, It makes sense to align at least these, like, kind of smaller changes, I feel like. for the next release, just so that there's minimal, like, back and forth between clients, like… Clients that are technically correct. Than having to… Like, make a change that makes them incorrect. To then revert it back in the future. So I think… Yeah, we'll…

Well, I'll get another test release out, By the end of today, with… these spec changes, I'll make it very clear what the changes are. And then hopefully that can be the final… DevNote-free set of spec… spec and tests, or at least the spec, I mean, we might add more tests, But yeah, and then I think… For DevNet4, we can… add, any other spec changes, so I think, in the… 8037 channel, Yeah, there has been some discussion going on about, Other spec changes, but those can be in… The next step now. Yep.

Stefan Starflinger: I'd also like to add, that now all clients work pretty well just with themselves in the network, so only Geth, only Nimbus EL, and so on. But if I add a guest to any of the networks with any of the other clients, there is quite the disagreement, so it… I think it makes sense to do the small changes now, like you said, Spencer. We don't necessarily want clients to do work to… Add code that's not gonna stay anyways, and if they're not, interrupt. If there's no interrupt yet anyways, I think we can still make that change. But I hope that we can still target Wednesday next week to launch, that would be the goal.

Maria Silva: Okay, and just so… so we are clear, so what issues would remain out of scope for, ball definet 3? So, which… which open questions or the bugs that were already reported would not be included in these small changes?

Stefan Starflinger: Like I said, from my side, the, thing, the change to the EIP, if the… parent, frame, if, the state gets from the parent frame, if that gets, returned or not. And I think this change is something we should discuss here, but I don't think it will make it into the DevNet. So, regarding the accounting, clients should… Return from child frames, to the parent frame if there is a failure, but the parent frame, that state guy should not be returned for the definite.

Maria Silva: Okay, but then that would be a situation where… So, clients would have to change… Indefinite for their… Their codebase to then have that fix.

Stefan Starflinger: Yes If we decide to do that, maybe we will find a reason why this is not a good idea.

Maria Silva: Godragon, do you want to comment on this?

Dragan Rakita: Yeah, I would like to say there's, like, two discussions. First one is if this is correct behavior. And I think, In general, we should… it makes sense to unify behaviors between the subcalls and the main topmost call. And second is, discussion is, should we include this inside the Devon tree? For dentistry, I think we should skip it, just like… things true, it's basically already have branch reside red, that basically make… reverts disk change. So, I would say that for the definite tree, we are fine to not include it. Just wanted to say there is, like, two discussions that we should have.

Maria Silva: Right, right, makes sense. So… So maybe we can just focus on now for the DevNet 3, and then we can open the discussion on the correctness. Okay, so… seems like we are all in agreement, so just doing some small changes that wouldn't have a big impact on clients, and I'm guessing Red would have to undo that logic for the… reservoir… Refill on the topmost frame.

Dragan Rakita: Yep. Just addition to mention, this is one of the three issues that I think are affecting dignitary. One… the second one is… When the init code limit is checked, the state… it's about static call, check. It is done after the state gas is consumed. So this is the second issue? And the third issue is… When there is… At the topmost call, if there is create that fails on the init code check. The state gas for the… for… State gas is still consumed for the… state gas is returned to the topmost frame.

And it… it shouldn't, because it failed. In the end, the gas limit… the gas used should be the gas limit, but it is lower than that. This is one of the two tests that… We are not passing. That's, like, the third issue.

Maria Silva: Sorry, do you think you can explain issues 2 and 3 again? Because I didn't fully follow it.

Dragan Rakita: Issue… Issue 2 is basically when you do create, there is static call check. And that statical check is done after the state gas is consumed. This means on the creator, create two opcodes. If it is called in the static call context. It will still consume the state gas, and it probably shouldn't.

Maria Silva: Okay, and this is the… so the current spec is like that, and it's something we would have to fix. Down the line.

Dragan Rakita: that's specified in spec at all. I think that's just a bug in the spec code. It's not specified in the IP. But I think the spec has a bug there.

Maria Silva: And I'm sorry, Spencer, you are saying this is one of the things that would be fixed in the release you are doing today, or not?

Spencer Taylor-Brown: Yeah, I was… I was going to add it, because it's a… I mean, it's a simple change. For us, it was just a spec change, the tests are there. And, the tests just need refilled with a small change. If, that works for everyone.

Dragan Rakita: Yep.

Maria Silva: And so… Okay, so this one, essentially, clients may have to do some updates on their code, but it would already be included in Abol DevNet 3. Okay, and the sec… and the third issue, Dragon, can you go over it again?

Dragan Rakita: I don't know full details, but what I noticed in the tests is There is one test with gas limit of 60 million. And that test inside calls create and create2UPCODE. Those create and create duop codes fail on init code track. So the init code is more than the maximum. And I would expect For full gas limit to be consumed. But on the test, it is consuming Something like 50 million and something. The difference is, like, 100… 100,000 gas.

Maria Silva: Hmm. Okay, Ben, do you have a comment here, or is it at a different point?

Ben Adams: Yeah, on the… Sorry, it's… it's not about… Situation 3. That fills Situation 1. Do we have a test to confirm the… Opposite If that makes sense. So that we have consensus. A test to ensure consensus.

Dragan Rakita: Oh yeah, when that change is made inside the code, a lot of tests is going to fail. Not a lot, but, like, 10 to 20.

Spencer Taylor-Brown: Yeah, I'm not… I'm not sure if we have a test. But I can… I can check. I think, just in general, I, The changes to the spec and the tests? I… I'm going to try and align… so… I'd say the issues are coming up because, within the eel spec, I've added… I've added things that have not been defined in the actual EIP is marked by. So it's kind of like a spec issue that shouldn't really be there. So I think the changes are mostly just aligning the spec with the existing EIP's repo markdown file. For this next release. And so I… I guess I'm proposing that any Any change that requires The changes to the EIPs repo should be… moved to… Devnet 4?

And… the changes on our end where our spec doesn't align with the EIP's markdown. And we'll be in this. release.

Dragan Rakita: To comment on that, I, I… did one implementation of AT37, and the things that I found, basically, is when I started running tests. And I saw that my implementation doesn't… it's, like, different than the test assumed. And when I started the debugging test, I found that there is, like, inconsistencies. So, I'm not sure… because the spec was kind… the AIP wording was kind of ambiguous. On some of those… on some of those, like, terms, so I, like, interpreted it in a different way than the spec code. So I don't see it as the spec being wrong here, but spec being… Sorry. I was confused back in AIP. AIP having wrong wording, but it… In a sense, they need clarification, too, so we are sure that Everything knows what exactly expected.

But yeah, I think for the sake of the… Moving forward, we can move all this clarification into DevNet form.

Maria Silva: Okay, and sorry, on the issue 3 again, so this is something you are saying that currently is… breaking indefinite 3. And so, we will have to essentially investigate what is happening there. Is this something that only happens in breadth, or is it happening on other clients as well?

Spencer Taylor-Brown: I…

Dragan Rakita: dispenser.

Spencer Taylor-Brown: I think… I think it might only be Russ. I think, Yeah, do you have the test? Andrew again.

Dragan Rakita: Let me find it, I'll be… I have turned somewhere.

Maria Silva: Okay, so maybe we can… Follow, this one async. Okay, maybe, so for DevNet 3, anything else we should discuss? I think, Ben, you raised the concern there, I don't know if you… Give a bit more thought on that.

Ben Adams: Yeah, so if there's changes we're delaying to DevNet 4, then the inverse test should be in DevNet 3, otherwise we'll have… the consensus will be a bit sloppy, and we'll have, People with different implementations. Potentially.

Stefan Starflinger: I don't quite follow that, because if we make a change to the EIP, for example, and then that is added to the tests. Then we don't need to test the inverse, because we're changing the existing test, right? Or is it just the discrepancy between the EIP and the tests that currently exist, which you're referencing?

Ben Adams: Yeah, so if… if we're changing the EIP in DevNet 4, And we should be testing for the… the not-changed version in DevNet 3. Otherwise… You know, we'll have two clients that'll decide two different things. If it… if there was no test. Enforcing a behavior.

Maria Silva: Yeah, I would say I'm not sure if I fully agree, so I think this would be a case where we are just saying that we will not be testing that component. So, for instance, we are not doing any tests on the dynamic cost per byte in DevNet 3, right? So, at this point, like, we are not targeting the DevNet to cover all edge cases of this EIP. And so I think it… should be fine to have, like, meeting spots, then we address on DevNet 4. But I may be missing something, I don't know. Trakhan, do you have a comment there?

Dragan Rakita: And the spec code… get changed. The tests generated by that new spec code are going to be changed. So, tests are already covering these cases. But the problem was that no… No client basically notices that this is not correct. I… I assume that we are a lot… a lot… that's one of discussions that I… basically, we started in the, in the Discord, and… on the Monday of code dev testing call. A lot of clients, I'm assuming, is basically using AI bots, and… Like, let's pass all the tests, and not checking should they pass that test or not. So there is, like, the tests are there, tests are covering those use cases. But because the spec code has bugs, They are basically…

Outcome of those tests, basically, is wrong. So when we fix the… spec code, the test outcome is going to change, and we are testing… we are going to test the cases. I think all the tests that got failed on REVM is the way how I found those, like, changes that… And how I basically… Like, try to address them.

Maria Silva: Okay, sounds good. So, is there anything else for Ball Definite 3 that we need to discuss?

Stefan Starflinger: Yeah, I would like just to agree with what Dragon said, that… I think it's good that clients really look at and challenge the IP itself, because I also found many points where the IP is, like, really not clear, and it's just as difficult for a client as for the EALS implementation to really get that right, and anything that's unclear. should be really fed back into the IEP to make it as clear as possible. And there are just many discrepancies because it's just so unclear.

Maria Silva: Yeah, I think… I think that's… that's, that's a great point. So I… I would say maybe before we launch DevNet 4, we could maybe try to do, like, a full review on all the tests and the IP wording, and, make sure that, Everything is… is… is aligned and clarified. Cool. Anything else on DevNet 3?

Spencer Taylor-Brown: Yeah, this, this sounds good to me. I think just… just want to say that I'll, I'll make it very clear what the spec changes are gonna be in the next release, and… Yeah, I mean, maybe, if there's anything I'm missing in that release, just please, like, flag up quickly, or anything I've added that you think I shouldn't, also flag it up. Yeah.

Maria Silva: Perfect, thank you, Spencer. Anything else? Okay, so should we then move to the discussion of, state gas refill on failure cases? Maybe I'll just add, like, from, from a general, like, philosophy perspective, I think the… What to me makes the most sense is… State gas should… so, state gas covers the costs of growing states, and These specifically should be… The… the cost of… Actually, like, renting the space in the state database. And not the execution or I.O. costs of in-the-moment creating that… That state.

So… whenever we are splitting up the costs of each operation in state gas and regular gas, the general principle is always the burst resources, so the in-the-moment execution costs and I.O. costs go to regular gas. And state gas is only… the cost of state growth, so, like, paying the rent for using space in Ethereum's state DB. And, in that sense, I think a guiding principle should always be that you only pay for it if you are actually using that space, right? If you are not using that space, then you shouldn't pay for it. And I think this kind of, like, touches a lot of the edge cases where we kind of discuss, like, should the state gas be refunded or not?

My… my view is that, from a general point of view, it should always be refunded. But I think this then enters into conflict with some behavior that we currently have in the EVM. So, for instance, the… the… Gaz's new account, where… it kind of… only tries to cover the state growth cost, because the in-the-moment I.O. cost is covered by a other parameter. But it's still not being refunded when… when there's a failure, so we would actually be changing a behavior in the EVM. Although, I would argue it seems like the correct behavior, but we need to be really careful and make sure that we are not missing anything here. But so, but this is, like, my general…

frame when I'm thinking about this, but yeah, happy to also hear your thoughts. Johan, do you want to go next?

Jochem Brouwer: Yes, one question on this, because I agree that from, like, a, like, how we would view these gas costs, it would make a lot of sense to refund this state cash in case that you are not creating a new account. But then we also have this similar situation for the storage keys. If you create a new storage slot, then we have the same situation, right?

Maria Silva: Right, I'd say, yes.

Jochem Brouwer: Okay, okay, interesting. Yeah, I think… I think… I think… If we would apply this all in a, how do you say this? Like, in the same way for both accounts and stores, I think that makes sense. And… Then the refunds, these are, like, the normal refunds which get, applied after the transaction, right? Then you get back your gas.

Ben Adams: But… They're not normal refunds, are they? They're just… you didn't use.

Maria Silva: No. No, so I think, like, on accounts, the KZs, the account doesn't exist, and you are creating a new account, and then things fail. on S-Tor, is a bit simpler. I think Dragon made a comment on this in the channel as well, so it's… it's only the case where you go from 0 to X, And then something happens, and something fails. Or you go from 0 to X, and then to 0 again. So in these cases, Before the transaction, the slot didn't exist there. And so… it never occupied space in the DB, and so you shouldn't be charged for state CAS. But in the case where, at the beginning of the transaction, there was something there, so there was X,

and you are clearing the slot, then this… nothing changes here. So you just do the normal refunds, as we are doing right now, and it has the 20%, cap.

Jochem Brouwer: Yes. But in the.

Maria Silva: In this case, this transaction would never have paid for state gas anyways.

Jochem Brouwer: Yes, so the situation I was thinking about is, like, creating a storage slot, so not deleting a storage slot, but creating one, and then applying the same logic as creating an account to creating this storage slot, because that would… that makes sense, I think.

Maria Silva: Yeah. Yeah, so I think… I think if we… if we end up doing it for the accounts, it would also make sense to do it for the… for the storage slots to make everything consistent. And it should apply, like, on… I think on the top post level, and also the call level. But again, I think the… the big point here is we are changing how the guys… costs, work. So this is not just going from one dimension to two dimensions, we are actually changing the behavior, and so we need to make sure that we are not opening ourselves up for any new, weird actors there. So in… yeah, again, like, in general, it makes sense, but then there's the question of

We want to make… The change now, and can we think of any other issues? so yeah, I don't know if there are more, thoughts on these.

Dragan Rakita: I have you basically started with self-destruct, and it was, like, we already have, like… we already know that account is locally created, so self-destruct locally created account, we could, like, refund part of the gas that we know that's not going to be spent on creating an account. Yeah, it can be, like… the same behavior can be, like, applied to the storage, so it makes sense. I like that we have a reservoir when we don't, like, reimburse the ordinary gas, we are putting it in reservoir, so the… The main path of how the gas is used and how it's consumed still just stays the same. So, because of that, I'm slightly confident there are not going to be edge cases that we don't know about.

But yeah, I agree with Maria that we need… we should think about it. At least. It doesn't make sense to add these, but, thinking about education is always time-consuming, and we need… yeah. To be sure that everything is okay.

Maria Silva: Cool, are there more… more comments on these? Okay, so it seems like we… will likely not, have a decision on this call. I think this maybe would need more eyes. So maybe a next step here is, like, maybe… we can all agree that this will be up for DevNet 4, so we won't, won't, change, or test this in the, in the current, DevNet. And in the meantime, we should probably have a better view on this. So on this point, I can… maybe start the discussion on the ethmos… on the, magician's, thread,

And maybe list all the options, and try to be as thorough as possible. And then I'll also ask you all to take a look and chime in. Does that sound good? Okay, perfect. Okay, so, on that note, is there anything else we should… we should discuss? Okay, so if not, we can wrap up early. Yeah, as I said at the beginning, it was likely, like, a shorter… a shorter call. Thank you all for joining, and yeah, anything else, we can chat to sync in the… in the channel.

Thank you, bye-bye.

Jochem Brouwer: Thank you, bye-bye.

Spencer Taylor-Brown: Thanks, guys.

Dragan Rakita: Bye-bye.

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