Maria Silva: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,
Transcript
Maria Silva:As the other EIPs, we are still working on the latest benchmark data collection, so there are no… no, no updates there.
Maria Silva:so on, 1837, maybe, Spencer, if you could, maybe you and Stefan, if you could give,
Maria Silva:a quick update on the current status of the Ball DevNet 3, and, any
Maria Silva: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…
Stefan Starflinger: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.
Stefan Starflinger:And then there is the question.
Stefan Starflinger: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?
Stefan Starflinger:In the car?
spencer:Yeah, I guess, Just to kind of relay what Stefan,
spencer:mentioned. I think, I mean, ideally, we wouldn't update the spec.
spencer:Just to get DevNet Free up and running, but I think… Because we have,
spencer:We have, kind of, different…
spencer:issues with the spec that different client teams have found, so Erigon found one.
spencer:And rest, fund, found more, Nether, Nethermind, Has, has one. So I think it's,
spencer:It makes sense to align at least these, like, kind of smaller changes, I feel like.
spencer:for the next release, just so that there's minimal, like, back and forth between clients, like…
spencer:Clients that are technically correct.
spencer:Than having to… Like, make a change that makes them incorrect.
spencer:To then revert it back in the future. So I think… Yeah, we'll…
spencer:Well, I'll get another test release out,
spencer:By the end of today, with…
spencer:these spec changes, I'll make it very clear what the changes are.
spencer:And then hopefully that can be the final…
spencer:DevNote-free set of spec… spec and tests, or at least the spec, I mean, we might add more tests,
spencer:But yeah, and then I think… For DevNet4, we can…
spencer:add, any other spec changes, so I think, in the… 8037 channel,
spencer:Yeah, there has been some discussion going on about,
spencer:Other spec changes, but those can be in… The next step now.
spencer: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.
Stefan Starflinger: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…
Stefan Starflinger:Add code that's not gonna stay anyways, and if they're not, interrupt.
Stefan Starflinger:If there's no interrupt yet anyways, I think we can still make that change.
Stefan Starflinger: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…
Stefan Starflinger:parent, frame, if, the state gets from the parent frame, if that gets, returned or not.
Stefan Starflinger:And I think this change is something we should discuss here, but I don't think it will make it into the DevNet.
Stefan Starflinger:So, regarding the accounting, clients should…
Stefan Starflinger: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…
Maria Silva:So, clients would have to change… Indefinite for their…
Maria Silva:Their codebase to then have that fix.
Stefan Starflinger:Yes
Stefan Starflinger: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.
Dragan Rakita:And I think,
Dragan Rakita:In general, we should… it makes sense to unify behaviors between the subcalls and the main topmost call.
Dragan Rakita:And second is, discussion is, should we include this inside the Devon tree?
Dragan Rakita:For dentistry, I think we should skip it, just like…
Dragan Rakita:things true, it's basically already have branch reside red, that basically make… reverts disk change.
Dragan Rakita:So, I would say that for the definite tree, we are fine to not include it.
Dragan Rakita:Just wanted to say there is, like, two discussions that we should have.
Maria Silva:Right, right, makes sense. So…
Maria Silva:So maybe we can just focus on now for the DevNet 3, and then we can open the discussion on the correctness. Okay, so…
Maria Silva: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…
Maria Silva:reservoir… Refill on the topmost frame.
Dragan Rakita:Yep.
Dragan Rakita:Just addition to mention, this is one of the three issues that I think
Dragan Rakita:are affecting dignitary. One… the second one is…
Dragan Rakita:When the init code limit is checked, the state… it's about static call, check.
Dragan Rakita:It is done after the state gas is consumed.
Dragan Rakita:So this is the second issue?
Dragan Rakita:And the third issue is… When there is…
Dragan Rakita:At the topmost call, if there is create that fails on the init code check.
Dragan Rakita:The state gas for the… for…
Dragan Rakita:State gas is still consumed for the… state gas is returned to the topmost frame.
Dragan Rakita:And it… it shouldn't, because it failed.
Dragan Rakita:In the end, the gas limit… the gas used should be the gas limit, but it is lower than that.
Dragan Rakita:This is one of the two tests that…
Dragan Rakita: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.
Dragan Rakita:And that statical check is done after the state gas is consumed.
Dragan Rakita:This means on the creator, create two opcodes.
Dragan Rakita:If it is called in the static call context.
Dragan Rakita: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.
Maria Silva:Down the line.
Dragan Rakita:that's specified in spec at all. I think that's just a bug in the spec code.
Dragan Rakita:It's not specified in the IP.
Dragan Rakita: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:Yeah, I was… I was going to add it, because it's a… I mean, it's a simple change.
spencer:For us, it was just a spec change, the tests are there.
spencer:And, the tests just need refilled with a small change.
spencer:If, that works for everyone.
Dragan Rakita:Yep.
Maria Silva:And so…
Maria Silva: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
Dragan Rakita:There is one test with gas limit of 60 million.
Dragan Rakita:And that test inside calls create and create2UPCODE.
Dragan Rakita:Those create and create duop codes fail on init code track.
Dragan Rakita:So the init code is more than the maximum.
Dragan Rakita:And I would expect For full gas limit to be consumed.
Dragan Rakita:But on the test, it is consuming
Dragan Rakita:Something like 50 million and something.
Dragan Rakita:The difference is, like, 100… 100,000 gas.
Maria Silva:Hmm.
Maria Silva: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…
Ben Adams:Situation 3. That fills Situation 1.
Ben Adams:Do we have a test to confirm the… Opposite
Ben Adams:If that makes sense. So that we have consensus.
Ben Adams: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.
Dragan Rakita:Not a lot, but, like, 10 to 20.
spencer:Yeah, I'm not… I'm not sure if we have a test.
spencer:But I can… I can check. I think, just in general, I,
spencer:The changes to the spec and the tests?
spencer:I… I'm going to try and align… so…
spencer:I'd say the issues are coming up because,
spencer:within the eel spec, I've added… I've added things that have not been defined in the actual
spencer:EIP is marked by.
spencer:So it's kind of like a spec issue that shouldn't really be there.
spencer:So I think the changes are mostly just aligning the spec with the existing EIP's repo markdown file.
spencer:For this next release.
spencer:And so I… I guess I'm proposing that any Any change that requires
spencer:The changes to the EIPs repo should be… moved to… Devnet 4?
spencer:And… the changes on our end where our spec doesn't align with the EIP's markdown.
spencer:And we'll be in this.
spencer:release.
Dragan Rakita:To comment on that, I, I…
Dragan Rakita:did one implementation of AT37, and the things that I found, basically, is when I started running tests.
Dragan Rakita: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.
Dragan Rakita:So, I'm not sure… because the spec was kind… the AIP wording was kind of ambiguous.
Dragan Rakita:On some of those… on some of those, like, terms, so I, like, interpreted it in a different way than the spec code.
Dragan Rakita:So I don't see it as the spec being wrong here, but spec being… Sorry.
Dragan Rakita:I was confused back in AIP. AIP having wrong wording, but it…
Dragan Rakita:In a sense, they need clarification, too, so we are sure that Everything knows what exactly expected.
Dragan Rakita:But yeah, I think for the sake of the…
Dragan Rakita: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…
Maria Silva:breaking indefinite 3.
Maria Silva:And so, we will have to essentially investigate what is happening there.
Maria Silva:Is this something that only happens in breadth, or is it happening on other clients as well?
spencer:I…
Dragan Rakita:dispenser.
spencer:I think… I think it might only be Russ. I think,
spencer:Yeah, do you have the test?
spencer: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.
Maria Silva:Okay,
Maria Silva:maybe, so for DevNet 3, anything else we should discuss? I think, Ben, you raised the concern there, I don't know if you…
Maria Silva:Give a bit more thought on that.
Ben Adams:Yeah, so if there's changes we're delaying to DevNet 4,
Ben Adams:then the inverse test should be in DevNet 3, otherwise we'll have… the consensus will be a bit sloppy, and we'll have,
Ben Adams:People with different implementations.
Ben Adams: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.
Stefan Starflinger:Then we don't need to test the inverse, because we're changing the existing test, right?
Stefan Starflinger: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,
Ben Adams:And we should be testing for the…
Ben Adams:the not-changed version in DevNet 3.
Ben Adams:Otherwise… You know, we'll have two clients that'll decide two different things.
Ben Adams:If it… if there was no test.
Ben Adams: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
Maria Silva:cost per byte in DevNet 3, right? So, at this point, like, we are not targeting the DevNet to cover
Maria Silva:all edge cases of this EIP.
Maria Silva:And so I think it…
Maria Silva:should be fine to have, like, meeting spots, then we address on DevNet 4.
Maria Silva:But I may be missing something, I don't know.
Maria Silva:Trakhan, do you have a comment there?
Dragan Rakita:And the spec code…
Dragan Rakita:get changed. The tests generated by that new spec code are going to be changed.
Dragan Rakita:So, tests are already covering these cases.
Dragan Rakita:But the problem was that no…
Dragan Rakita:No client basically notices that this is not correct.
Dragan Rakita:I… I assume that we are a lot… a lot… that's one of discussions that I…
Dragan Rakita:basically, we started in the, in the Discord, and…
Dragan Rakita:on the Monday of code dev testing call. A lot of clients, I'm assuming, is basically using AI bots, and…
Dragan Rakita:Like, let's pass all the tests, and not checking should they pass that test or not.
Dragan Rakita:So there is, like, the tests are there, tests are covering those use cases.
Dragan Rakita:But because the spec code has bugs, They are basically…
Dragan Rakita:Outcome of those tests, basically, is wrong.
Dragan Rakita:So when we fix the…
Dragan Rakita:spec code, the test outcome is going to change, and we are testing… we are going to test the cases.
Dragan Rakita:I think all the tests that got failed on REVM is the way how I found those, like, changes that…
Dragan Rakita: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…
Stefan Starflinger: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
Stefan Starflinger:the EALS implementation to really get that right, and anything that's unclear.
Stefan Starflinger:should be really fed back into the IEP to make it as clear as possible.
Stefan Starflinger: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,
Maria Silva:Everything is… is… is aligned and clarified.
Maria Silva:Cool. Anything else on DevNet 3?
spencer: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…
spencer: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.
spencer:Yeah.
Maria Silva:Perfect, thank you, Spencer.
Maria Silva:Anything else?
Maria Silva:Okay, so should we then move to the discussion of, state gas refill on failure cases?
Maria Silva:Maybe I'll just add, like, from,
Maria Silva:from a general, like, philosophy perspective, I think the…
Maria Silva:What to me makes the most sense is…
Maria Silva:State gas should… so, state gas covers the costs of growing states, and These specifically should be…
Maria Silva:The… the cost of… Actually, like, renting the space in the state database.
Maria Silva:And not the execution or I.O. costs of in-the-moment creating that… That state.
Maria Silva:So…
Maria Silva: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.
Maria Silva:And state gas is only…
Maria Silva:the cost of state growth, so, like, paying the rent for using space in Ethereum's state DB.
Maria Silva: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
Maria Silva: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?
Maria Silva:My… my view is that, from a general point of view, it should always be refunded.
Maria Silva:But I think this then enters into conflict with some behavior that we currently have in the EVM. So, for instance, the… the…
Maria Silva:Gaz's new account, where… it kind of…
Maria Silva:only tries to cover the state growth cost, because the in-the-moment I.O. cost is covered by a other parameter.
Maria Silva:But it's still not being refunded when… when there's a failure, so we would actually be changing
Maria Silva: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…
Maria Silva: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.
jochem-brouwer: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.
jochem-brouwer:Yeah, I think… I think… I think…
jochem-brouwer:If we would apply this all in a,
jochem-brouwer:how do you say this? Like, in the same way for both accounts and stores, I think that makes sense.
jochem-brouwer:And…
jochem-brouwer: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.
Maria Silva: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.
Maria Silva: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,
Maria Silva:And then something happens, and something fails. Or you go from 0 to X, and then to 0 again.
Maria Silva:So in these cases,
Maria Silva:Before the transaction, the slot didn't exist there.
Maria Silva:And so…
Maria Silva: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,
Maria Silva: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.
Maria Silva: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.
Maria Silva:And it should apply, like, on… I think on the top post level, and also the call level.
Maria Silva:But again, I think the… the big point here is we are changing how the guys…
Maria Silva: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
Maria Silva:We want to make… The change now, and can we think of any other issues?
Maria Silva: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.
Dragan Rakita:Yeah, it can be, like… the same behavior can be, like, applied to the storage, so it makes sense.
Dragan Rakita:I like that we have a reservoir when we don't, like, reimburse the ordinary gas, we are putting it in reservoir, so the…
Dragan Rakita:The main path of how the gas is used and how it's consumed still just stays the same.
Dragan Rakita:So, because of that, I'm slightly confident there are not going to be edge cases that we don't know about.
Dragan Rakita:But yeah, I agree with Maria that we need… we should think about it.
Dragan Rakita:At least.
Dragan Rakita:It doesn't make sense to add these, but, thinking about education is always time-consuming, and we need… yeah.
Dragan Rakita:To be sure that everything is okay.
Maria Silva:Cool, are there more… more comments on these?
Maria Silva:Okay, so it seems like we…
Maria Silva:will likely not, have a decision on this call. I think this maybe would need more eyes.
Maria Silva:So maybe a next step here is, like, maybe…
Maria Silva: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…
Maria Silva:maybe start the discussion on the ethmos…
Maria Silva:on the, magician's, thread,
Maria Silva: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.
Maria Silva:Does that sound good?
Maria Silva:Okay, perfect.
Maria Silva:Okay, so, on that note, is there anything else we should… we should discuss?
Maria Silva: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.
Maria Silva:Thank you, bye-bye.
jochem-brouwer:Thank you, bye-bye.
spencer:Thanks, guys.
Dragan Rakita:Bye-bye.
Chat Logs
00:08:04
Maria Silva:https://github.com/ethereum/pm/issues/2000
00:15:17
Ben Adams:Do we have test to confirm the opposite?
00:16:27
spencer:For 2 I have a PR now: https://github.com/ethereum/execution-specs/pull/2608
00:20:42
FLCL:The simplest for an EL would be to have spec tests that if we make em all green will mean all 3 cases are covered for devnet-3 and everything is correct
00:22:43
Ben Adams:My concern is if the tests aren't convering the inverse of the changes for devnet-4 then consensus will be a bit sloppy?
00:23:10
Dragan Rakita:Here it is: https://discord.com/channels/1359927674746835211/1487027709803761796/1487090434713976873
00:24:58
FLCL:Just to be sure not-testing will not lead to devnet forking
00:26:46
jochem-brouwer:Which client fills tests now? Is it EELS by default?
00:26:59
spencer:Replying to "Which client fills..."
Yeah!
00:27:33
Dragan Rakita:It is nasty EIP with a lot of edge cases
00:29:11
jochem-brouwer:Yup =) And also not being 100% spec ready yet means we are in the uncomfortable position where we cannot write a spec-compliant implementation, and this also means we cannot write a test suite which has 100% coverage. Because everything which is not yet specced is a grey area. So it is a collective effort for us all to polish the tests and the EIP spec 😄👍
00:29:12
Dragan Rakita:Is someone want to look, this is diff for devnet-3 for first two issue that revm has: https://github.com/bluealloy/revm/pull/3519 (Still missing third issue)
00:32:14
Stefan Starflinger:refund: https://github.com/ethereum/EIPs/pull/11476
don’t refund: https://github.com/ethereum/EIPs/pull/11468
00:36:29
spencer:EELS spec is aligned with "dont refund"^^ currently
00:36:42
Dragan Rakita:Replying to "EELS spec is aligned..."
Yeah, this is new mechanism
Summary
10 highlights
· 3 action itemsExperimental
Summary
10 highlights · 3 action itemsExperimentaltesting progress
repricing updates
- EIP-8037 spec has discrepancies between execution-specs and EIPs repo markdown00:09:14
- Static call check bug: state gas consumed before check, should fail earlier00:14:35
- Init code limit failure incorrectly returns state gas to topmost frame00:17:40
- State gas refill on failure postponed to DevNet 4 for thorough review00:28:37