Maria Silva:maybe we can start. So, the goal of this call, so I can post the agenda…
Transcript
Maria Silva:Let me just get it,
Maria Silva:But the main topic is, finalizing the decision on, the spec for…
Maria Silva:EIP-8037 and, Pectra DevNet 4.
Maria Silva:So, spencer posted, posted the,
Maria Silva:open questions, in the Discord, and I saw that some of you, went there and gave your opinion. I think you also had a more recent proposal
Maria Silva:from, Pavel that, Spencer then implemented, very quickly in the specs, just to… just to have a, an idea.
Maria Silva:But yeah, I think, maybe the, the, the best way here would be just to get, like,
Maria Silva:a general… Feedback from, from, from each of you, saying, like, in general,
Maria Silva:How do you feel about the… the… the refund to the reservoir?
Maria Silva:And then the general idea of doing it at the end of the call.
Maria Silva:And… and also if there's any, if there's any, like, questions on the, on the open, topics and the potential solutions, also happy to…
Maria Silva:to… to go through it. But yeah, if there's our… if there are any, like, specific opinions right off the bat, I would like to… to hear them.
Maria Silva:Should we… if there are no, like, general comments, should we go maybe one by one and discuss?
Maria Silva:Okay.
Maria Silva:So, let me then try to get the lease out.
Maria Silva:Mmm…
Maria Silva:Okay, so I'll just share my screen, and we can go one by one.
Maria Silva:Okay, so… First on the…
Maria Silva:top-level reservoir, so this idea is essentially, if there is a revert and no, state is created, should we still charge for it or not? I think on this one, there was some…
Maria Silva:Consensus from the people that answered that things should be refunded to the reservoir.
Maria Silva:But yeah, happy to… happy to hear your thoughts there.
Ben Adams:So, one… one consideration is… Could somebody…
Ben Adams:If it was a full refund, could somebody use it to…
Ben Adams:Grief in some way, where they create state and revert.
Ben Adams:Could not pay any state cost.
Ben Adams:If you know what I mean. So there's no cost for the river, but they have done extra work.
Maria Silva:Right, so the way, I'm thinking about it is…
Maria Silva:I think the state gas component of operations should only account for the added costs of
Maria Silva:adding states. So, by this, I mean every time a new account and a new slot is created, this creates an overhead on the entire network. Not the in-the-moment processing, but just the fact that now we have to live with that state going forward, and that has a bunch of
Maria Silva:Of impacts, both for the size.
Maria Silva:requirements of disks, but also syncing, and so on and so forth. Like, we are all aware, we are
Maria Silva:we all know what these, like, long-term costs of state are. But so, essentially, like, we have these two costs, right? We have, like, the in-the-moment execution of actually
Maria Silva:accessing The states, so reading and writing.
Maria Silva:And then we have these, like, long-term cost of the fact that now state got larger.
Maria Silva:And… the way I'm thinking about is, like, the states…
Maria Silva:gas component should only cover the long-term costs, and so it's only actually affected if…
Maria Silva:state is created. For the part of the in-the-moment execution cost, that should be covered by the state access cost, which we updated with EIP 8038. And so, I would expect no
Maria Silva:incentives for grifting to be there, because you'd always…
Maria Silva:Pay the cost of the execution.
Maria Silva:You just wouldn't pay the cost of the state growth, and that's fine, because actually no state is being grown.
Maria Silva:so I… I think this is where, for instance, on the… on the CREATE case,
Maria Silva:the reason why there was grifting, or the possibility of grifting before, is because we didn't have these two separated costs, right? Like, the $32K cost of a create combines both the in-the-moment execution cost and the state growth cost, so, you couldn't separate. But now we are separating it, and so,
Maria Silva:we can… we can make this, this decision, I guess.
Ben Adams:Yeah, okay.
Maria Silva:Okay, are there any more issues here? Does anyone want to give more opinions on these, or should we just…
Maria Silva:decide on, yeah, we will do the refund in this case.
spencer:I think in the thread, we all kind of seemed aligned on the refund. That being, I guess, myself, Dragan, yourself, Maria.
spencer:And then Avail as well. So if… if there are no objections from anyone, I'd say we… we do that.
Maria Silva:Okay, so let's go with that. I'll give just one more bit for anyone to complain.
Maria Silva:And if not… okay, let's… let's move to the other one. Okay, so the other one is similar in a way, like, we are still…
Maria Silva:doing this thing where we know that no state will be created, so we should likely just refund it. But again, we are changing the way that the VM works in this case, because previously, actually, this would not be
Maria Silva:refunded fully, it would go to the refund counter, which had a cap of 20%.
Maria Silva:And so, on this case, I'm still… Personally, I'm still a bit…
Maria Silva:tending towards giving the refund, because I think that's the more correct thing to say, but I also
Maria Silva:can see the fact that implementation-wise gets… this may get a bit more tricky, because now we have these two
Maria Silva:separate cases of going from X to 0. We have the just X to 0, and we have the 0 to X to 0. And these two will have different behaviors.
Maria Silva:So yeah, I'm open here for the discussion. How do you guys feel about this one?
Dragan Rakita:I think… In general, this makes sense.
Dragan Rakita:If you don't do that, we will have, like, a little bit fake data on how much state gas is consumed.
Dragan Rakita:For me, it's more about how to implement it.
Dragan Rakita:Pavel proposed to delay That state gets refund to the end of the section.
Dragan Rakita:And second option is to do refund at the place when we do X to 0.
Dragan Rakita:So, I'm not exactly sure what's better implementation-wise, but internally, I think we should choose one of those options, and this is… it looks like a good change to do.
Maria Silva:Thank you, Dragan. How about the other people? How do you feel about this one?
Andrew Ashikhmin:Yeah, I think we should do the proper fix, because we want to decommission the old refund model anyway.
Dragan Rakita:I'm more leaning to, like, doing refund at the place when we do weeks to zero.
Dragan Rakita:Then delaying it to the end.
Dragan Rakita:But I wouldn't mind, like, doing it differently.
Maria Silva:Okay, so maybe,
Maria Silva:if we all agree that, in general, we want to refund, so maybe then we can sort of work on, figuring out the details of the two implementations and see, what would work, better. But, yeah, so I… I take from Andrew that you, you would like to do the…
Maria Silva:the refund in this case. Lucas, do you have, an opinion on this? Oh, sorry, Andrew, do you want to speak?
Andrew Ashikhmin:Yeah, so basically I want to do whichever option is more correct.
Maria Silva:I wish… Lucas, do you have an opinion on this one?
Maria Silva:I know you always tend to… to lean more towards the making it simpler approach.
Łukasz Rozmej:I don't have an opinion.
Maria Silva:Okay.
Maria Silva:Daniel, do you… from Besu, do you have an opinion here?
Daniel Lehrner (Besu):Weekly, I would say, I would return it immediately.
Daniel Lehrner (Besu):Not adding it to the refund.
Daniel Lehrner (Besu):That's… that's a big position.
Maria Silva:Okay.
Maria Silva:Okay, so maybe, if no one complains, I'll say, to me, the takeaway here is we do want to do the refund.
Maria Silva:Maybe we still… still need to…
Maria Silva:think a bit if we want to do it, at the end of the call, or right, when the refund happens, so I'm… I think maybe we could do some exploration on… on those two options, but at least we have a decision, like, in general, for
Maria Silva:the end of the block, the refund should be there.
Maria Silva:And should go to the reservoir.
Maria Silva:I'll give one more bit for…
Maria Silva:People to complain about this one.
Maria Silva:Okay.
Maria Silva:Perfect.
Maria Silva:Then point number 3… I think this one is…
Maria Silva:very much connected with point number one. So, to me, it's… it's very similar. So it's like, if no state is created, we still…
Maria Silva:should return, the state CAS.
Maria Silva:So, like, in my mind, if we are okay with 0.1 and 2, I think 3 is sort of,
Maria Silva:like…
Maria Silva:coming from those two as well, it makes sense to do the refund. But yeah, also, happy to hear your thoughts, if there are any complaints on giving the refund in this case.
Maria Silva:Okay, so I give one more bit. So I guess here, if there are no complaints, we'll…
Maria Silva:Give the refunds.
Maria Silva:In this case, so this will change.
Maria Silva:how… Gas Create works,
Maria Silva:Okay, then I'll take these as we provide the refund, and then for point number 4…
Maria Silva:I would say, again, maybe we should be consistent with 3, so again, this is the question of, we are self-destructing an account that was created in that transaction, and so should we give the
Maria Silva:a state act… the state's gas back, and, yeah, in that case, I think it would also make sense to…
Maria Silva:To do it, yeah.
Maria Silva:Go, Ben.
Ben Adams:And just a side question, will this… completely affect refunds. So we're…
Ben Adams:we're giving immediate refunds for site creation. Would we want
Ben Adams:We also have the other refund.
Ben Adams:Oh no, maybe it doesn't matter.
Maria Silva:Right, so I think…
Maria Silva:Yeah, so I guess the way I see it is, like, you still maintain the old refunds for the case of storing X to 0,
Maria Silva:That will go through the refund counter.
Maria Silva:For all these new refunds we are giving, they will go directly to the reservoir.
Maria Silva:So they can be immediately used, and they don't have The 20% cap on it.
Maria Silva:And then, maybe in the next fork, we can decide if we want to fully get away with the…
Maria Silva:0 to X refunds.
Ben Adams:I mean, not… I would say that is consistent also with the regular
Ben Adams:So if you… if you start a…
Ben Adams:If you start with the zero state, set it to something, and then set it back to zero.
Ben Adams:In the same transaction, that's a different cost to the,
Ben Adams:You know, starting with something that's not zero, and then setting it to zero.
Maria Silva:Exactly, exactly. So I think those are two separate cases,
Maria Silva:I mean, in the current costs, they… they… they don't… they have the same refund, let's say, but yeah, with these
Maria Silva:Issue number two would be changing how that works, so…
Maria Silva:Now the 0 to X to 0 will just go directly to the reservoir.
Maria Silva:Perfect. So, any, oh, go, Johann?
jochem-brouwer:Yes, about 4. There's, like, a gotcha about self-destruct. If you… Invoke South District?
jochem-brouwer:Then the account flow actually gets removed at the end of the transaction, so not if you invoke it.
jochem-brouwer:So if we'll do the immediate, state gas refund, then the right time to do this is then at the end of the transaction.
Maria Silva:Okay, so that's… that's a good point. So, in issue 4, instead of… as we were doing with all the others, where we just
Maria Silva:refund in place. In this specific case, we should just refund at the end of the transaction.
jochem-brouwer:Yes, exactly, yeah.
jochem-brouwer:So…
Maria Silva:Okay.
jochem-brouwer:maybe also to note, because I think that the general pattern, what we are now pursuing, is that, any state gas, which… or state-specified gas, which we spend in the current transaction.
jochem-brouwer:That can theoretically be refunded, in the case that this storage is either reset, or cleared, or whatever.
jochem-brouwer:And I think that that would then directly catch rule 2 and 3. And then the main gotcha here is that if you would have, like, a refund which is not state-created in this transaction, so you would clear, for instance, a storage slot.
jochem-brouwer:then, that will not go into the stated SFR, but then into the
jochem-brouwer:Regular gas, sorry, not the regular gas in the refit count.
Maria Silva:Exactly. Yes, it will go into the refund counter.
Maria Silva:Bragan, do you… do you want to speak next?
Dragan Rakita:There is one more edge case around self-destruct.
Dragan Rakita:If we create a contract, then self-destruct it, basically, in the local the local, like… context.
Dragan Rakita:What if we do a store on all the self-destructed accounts?
Dragan Rakita:We will still charge the state gas… Because…
Dragan Rakita:We don't know… there is no, like…
Dragan Rakita:We'll still charge the gas for the account that will get self-destructed.
Dragan Rakita:So the question is, should we account the storage that got deleted?
Dragan Rakita:For the account that got self-destructed.
Dragan Rakita:And refund that after the section finished.
Maria Silva:Right, so I think, like, my intuition is that this would be a sort of 0 to X to 0 case, right?
Maria Silva:Because there was no slot before, because the accounts… Self-destructed in the same transaction.
Dragan Rakita:But it's implemented a little bit differently because of self-destruct.
Maria Silva:Right.
Dragan Rakita:the… when you do STOR and you do X to 0, you are at that place in that instruction, and you know, you can check that.
Dragan Rakita:Self-destruct, you can check that only after the end.
Dragan Rakita:So…
Maria Silva:Right.
Dragan Rakita:Yeah, Satistract is very… Not great.
Maria Silva:Okay, but I think, yeah, even though maybe implementation-wise it's a bit tricky, I think we should keep with the principle and make things consistent, so I do think we should give the refund in that case at the end of the transaction.
Dragan Rakita:Yeah, I do agree.
Maria Silva:Perfect. Are there any more comments on these?
Ben Adams:Yeah, if you, if you create, like, 100 storage slots.
Ben Adams:And then self-destruct. You… Return the 100 storage lots.
Ben Adams:In cost.
Ben Adams:Because he didn't grip.
Dragan Rakita:You… Created, then nothing is going to be stored on the state.
Dragan Rakita:Because all of that is going to be deleted.
Dragan Rakita:So it makes sense to, like, not spend state gas, because nothing's going to be stored.
Ben Adams:So could you then… then the weird approach would be, I call self-destruct. It doesn't permanent to the end.
Ben Adams:Of the transaction, now is all my storage fee.
Ben Adams:So I can… I can store.
Ben Adams:Because if it doesn't count, it's gonna be deleted. I mean, obviously, you have the execution cost, but… .
Dragan Rakita:But… isn't that fine?
Ben Adams:Maybe.
Maria Silva:Right, so I think…
Ben Adams:I'm also a bit worried about, like, you'll have a loop of, like, well, how many storage slots have you created that we should be refunding?
Ben Adams:Oh my god, that word.
Maria Silva:Right, I guess, like, the only cost that we may not be considering is that end-of-transaction loop where we are accounting the refunds. Like, if that is significant, I would assume no, because I would assume the cost of
Maria Silva:actually access… accessing Like, the access costs for creating those accounts will be
Maria Silva:Much more expensive than just a final loop of just iterating over them and giving the refunds.
Maria Silva:But I would guess that this is something we can try
Maria Silva:to benchmark once EIP8037 is fully done, so we can even, like, run the gas benchmarks on that and see if there's any… any problems there, and in that case, we can simply just increase the access cost until things look… look safe.
Ben Adams:Or.
Maria Silva:Make… make sense?
Ben Adams:Or return the account gas, but not the storage slot gas.
Maria Silva:Right, I think that would be too… too harsh, I feel.
Ben Adams:Yeah, but it would be… it'd be a weird behavior, that you create an account, add a thousand storage slots, and then self-destruct the account.
Ben Adams:I mean, it's normally… I think, the most use of,
Ben Adams:self-destruct is, like, a Create 3, where you…
Ben Adams:You deploy an account, use that to deploy a… contract with the Create.
Ben Adams:So that you get a deterministic… Nonce endpoint across chain.
Ben Adams:I don't see why… what…
Ben Adams:Functionality you'd be gaining from, like.
Ben Adams:Raiding a thousand storage slots and then self-destructing it.
Ben Adams:But I don't.
Ben Adams:Other than, like, a briefing rate in that.
Ben Adams:Massively increasing the accounting.
Maria Silva:So I… I guess that's… that's also a point, but I…
Maria Silva:I think it's more of, like.
Maria Silva:keeping consistency in the principle itself, and so I think things start to become much more complicated when you have edge cases. Like, you always keep the refund.
Maria Silva:Except when… this specific thing happens.
Ben Adams:Yeah, but my… my issue is that the self-destructors are fixed.
Ben Adams:cost. It's not related to the number of things you're self-destructing.
Ben Adams:with her.
Ben Adams:So there's an inconsistency in self-destruct.
Maria Silva:Right.
jochem-brouwer:Yeah, maybe to also mention here that, just as a reminder.
jochem-brouwer:that you can only do self-district in the same transaction as in with the contract it's created.
jochem-brouwer:Yeah, just a reminder about it.
Maria Silva:Yeah, so this is really, like, an edge case of an edge case, but I think it's still important for us to have a decision on this, so…
Dragan Rakita:You don't mind, I think.
Dragan Rakita:It makes sense to refund,
Dragan Rakita:the state… state guides that it's not going to be used to create state.
Dragan Rakita:That's the logic that I go by. So, if…
Dragan Rakita:even if somebody creates the 100 or 1,000 storages inside self-destruct account.
Dragan Rakita:That storage, because it's locally created, are not going to be stored on the… in the tree.
Dragan Rakita:So it makes sense to refund them and have…
Dragan Rakita:State gas only representing… to have state gas representing only the state that got created.
Dragan Rakita:Yeah.
Maria Silva:I agree, and I think, like, the user won't be able to use these reservoir refunded things for anything else, right? It just gets added to their account.
Maria Silva:And so it's not like they can do this to then fit more things in the block.
Maria Silva:And,
Maria Silva:And then I think we can really target and make sure that, with gas benchmarks, that this additional loop at the end is not introducing any new attack vectors, and make sure that the access cost of these operations cover for that… for that case, which will be an edge case.
Maria Silva:So I would…
Maria Silva:And then maybe we can consider in another fork to fully kill Top Distract. I'll be up for that as well. But I think in this case, it makes sense for us to just keep the consistency and say that we refund everything.
Maria Silva:Ben would be okay with this… with this plan.
Ben Adams:Yeah.
Ben Adams:Although I'm… I'd like to… look at the effects, right? Okay with how it is, but maybe…
Ben Adams:In some testing, yeah.
Ben Adams:Go into it. See if there's any, like, terrible deniers for…
Maria Silva:Yeah, for sure, and I think this is likely, like, a takeaway for the benchmarking people, so Johan and Luis, like, I don't think this is a priority right now, but we eventually will need some benchmark to test this.
Maria Silva:This case.
Maria Silva:Yeah, good, good point. Anything else on point 4, or are we all in agreement to issue the refund to the reservoir?
spencer:If we're wanting to refund at the end of the transaction for 4, should we do the same for 2?
jochem-brouwer:I would say no, because I think that the…
jochem-brouwer:Or at least that's how this rule works in my mind.
jochem-brouwer:You refund the state cash once you actually change this state.
jochem-brouwer:So, from the 0x20 case, if you would set X20, then you would get this refund.
jochem-brouwer:And for the self-destruct case, then you would get the refund when this state is actually being restored to the original value. This is at the end of the transaction, and you will then refund the account creation gas.
jochem-brouwer:And possibly also these, storage slots, which were created.
jochem-brouwer:Then the only note there is that if we were to rethread this to the, state reservoir.
jochem-brouwer:Well, of course, it's at the end of the transaction, so we can't execute anything anymore, so that's… it's just like an, well, it will directly get added back into the account.
Maria Silva:Right, so I would agree with Johann. I still think the question of, for all other points, if we give them at the end of the call, is still something we can discuss, is independent from point four, I think.
Maria Silva:perfect. Anything else on point 4, or should we move to 0.5?
Maria Silva:Okay, so I think in point 5, since we are refunding the self-destructs.
Maria Silva:I think…
Maria Silva:Here… so, the question in this point is, what happens when you do a call with value?
Maria Silva:To an account that was previously self-destructed.
Maria Silva:So, my…
Maria Silva:Intuition here is that you should try to keep with the principle that we only charge for
Maria Silva:state that is created, and in this case, what would happen is, like, the self-destruct would occur at the end of the transaction, but then there was a call after. So how would this work, Johan? Because the first time I was…
Maria Silva:thinking about this, I… I forgot that the self-district would only happen at the end of the transaction.
jochem-brouwer:Yeah, I'm actually slightly confused about 0.5, because, about what state cost is this actually
jochem-brouwer:having an issue, because if you will do call with value to an already existing account, would you then charge state cash in this ERP account?
Maria Silva:No.
Maria Silva:No, you wouldn't.
jochem-brouwer:Right, so then I think that 5 is not an issue, right? Because the self-destruct happens at the end of the transaction.
jochem-brouwer:So the account is already created, because if you are in account
jochem-brouwer:With, which is creating code.
jochem-brouwer:then it is already being created. Let me actually check if that's the case, even if it goes from inside.
jochem-brouwer:Mmm…
jochem-brouwer:Yeah, I think this is not an issue, because you would go to value to this specific account, but it is already created, so you would not extra charge a new create gas for this account.
Maria Silva:Okay, so, so you did something where… You self-destructed?
Maria Silva:And then you still do a call after. So in that case, the account would still exist, because you haven't destructed it yet.
jochem-brouwer:Yes, so indeed, if you would… if you would, in the same transaction, if you would create a contract, if you would self-destruct it, but also in the same transaction, recall this contract, then the account would just sit there with the code, with the storage, with whatever. Only at the end of the transaction, the code gets removed, and the storage gets cleared.
Maria Silva:Okay. Dragon, do you want to add something to this?
Dragan Rakita:Just wanted to confirm. Yeah, I missed that, but yeah, Johim is correct. At least notes will stay, incremented, so no new account is going to be created.
Dragan Rakita:I think… Yeah, yeah, no state gas is going…
Dragan Rakita:No state gas should be consumed there, so it's, we can skip 5 and just, like…
Dragan Rakita:It's not tissue.
Maria Silva:Okay.
Maria Silva:Perfect. So, maybe a takeaway there, Spencer, is would it make sense for us to try to have a test on these to check the behavior?
spencer:Yeah, no, sounds good.
Maria Silva:Okay, perfect.
Maria Silva:So moving on to 6, I think this one is… One that is a bit…
Maria Silva:slightly different from all the others, because this is connecting to intrinsic Cas. So maybe just, just going there. So I…
Maria Silva:make sure that I'm not seeing anything incorrect. So, yeah, so this is about the 7702 cauterization, mechanism, and in this case, the way that the initial EIP
Maria Silva:defined this was, we will assume that the intrinsic cost of this transaction includes the cost of creating the account, right? Like, when I'm setting the delegation, I would assume that the account doesn't exist, and then during the execution.
Maria Silva:If the account actually exists, then I do a refund through the refund counter.
Maria Silva:Okay, so this is how 7702 initially implemented this.
Maria Silva:So if we didn't want to change anything, we should just keep this behavior, but again, like.
Maria Silva:we are doing a lot of refunds through the reservoir, so would it make sense for us to also do this here? I think the only point is, like.
Maria Silva:We are sort of mutating I mean, we are not mutating the intrinsic gas, because that still is,
Maria Silva:doesn't change, but we are giving a refund from Intrinsica, so this is sort of slightly different. So, yeah, I don't know how you guys, think of this.
jochem-brouwer:Yeah, so also with these authorizations, we have to…
jochem-brouwer:the computer gas here, and also the state gas. If we will treat the state gas in the same, the same behavior as we did with the storage and the accounts, then at the start of the transaction, if the
jochem-brouwer:772 account, which is being authorized, if that already exists, then we should directly refund this gas to the state reservoir.
jochem-brouwer:And if this does not exist, then we would, of course, charge it.
Maria Silva:Okay.
Maria Silva:Yeah, I think I'm also tending towards refunding it again through the reservoir, because I think it's the more… the most correct, like, you are not capped with those 20%.
Maria Silva:And it's consistent with everything else we've decided, but I just wanted to…
Maria Silva:Here maybe some, some more opinions,
Maria Silva:Okay, so I'm assuming no complaint means that it's okay to give the refund through the reservoir?
Maria Silva:So, should we go with that one?
Maria Silva:Okay, then I guess we'll… we'll go… With that one,
Maria Silva:I think then the final one is this transaction inclusion validity. So, at the moment, we are only… so when we are, checking, doing this check transaction pre-execution, we are essentially just making sure that the transaction has enough
Maria Silva:Gas available to cover for the regular gas.
Maria Silva:But I think we should also…
Maria Silva:consider, the state gas. So we should, have enough available gas…
Maria Silva:Sorry, enough state gas available to cover for the
Maria Silva:transaction gas, which is the most that the user can use on state.
Maria Silva:So I think this is a bit more limiting, right? Like, now you… you will feed less transactions, but I think it's the correct… the correct thing to do.
Maria Silva:are there any, opinions against this, or complaints?
Maria Silva:Okay, so, in this case, we'll do the streak to the bottleneck here.
Maria Silva:Ultra again.
Dragan Rakita:I think there is, like, two cases here. One is tracking the regular gas, and one is tracking if you have a maximum state gas to fill inside the block.
Dragan Rakita:Currently for DevNet 3, we need…
Dragan Rakita:I think we are doing that check after the transaction, and that's slightly… Strange.
Dragan Rakita:So, we can move that before execution, before the section starts, and we have two checks. One is, do we have maximum regular gas to fit inside the block? And second is, do we have maximum state gas to fit inside the block?
Dragan Rakita:That will cover that, in any case, anything that's get, as a kid, we'll…
Dragan Rakita:be inside that block. That recycling will be inside the book.
Maria Silva:Right, I think that's also a good point that actually will simplify things a bit, so instead of doing these two checks, we just do one at the start, and that's it.
Dragan Rakita:We need those two checks. One is for regular gas, one is for the state gas.
Maria Silva:Right, but they happen at the same point in time.
Dragan Rakita:Yeah, yeah, yeah, yeah, yeah, exactly, yeah, true.
Maria Silva:Perfect. Any more comment here?
Maria Silva:Okay, so I guess, like, the final thing is we've gone through all the points, and I think we've mostly tended towards always giving the refund, so maybe in the last, 10 minutes, we could probably just have a quick discussion on
Maria Silva:the idea from Pavel, and,
Maria Silva:This option of giving the refund just at the end of… The call frame versus
Maria Silva:Right at the point where the…
Maria Silva:The… the… the storage is being not… or destroyed, or whatever, is not being used.
Maria Silva:So, are there any comments on this? I think, Drogan, you already gave a little bit your opinion, where you think you like more doing it at the point of…
Maria Silva:At the point of,
Maria Silva:Of when the state is being destroyed, rather than at the end of the call. But it seems like doing it at the end of the call would make things a bit simpler.
Maria Silva:So yeah, I don't know if there are any other opinions on these.
jochem-brouwer:Yeah, I think I may have to reread this thread, but what is, like, the…
jochem-brouwer:Benefit of doing… doing this? Or, like…
Maria Silva:Of doing it at the end of the call.
jochem-brouwer:Yes, yes, yes.
Maria Silva:My understanding is that, it simplifies, the accounting, because you can rely on this journal.
Maria Silva:And so… Yeah, you, you… Like, yeah, I'm…
Maria Silva:this was, like, my broad understanding, but also it's not very deep.
Maria Silva:But I think also from what Spencer was seeing at the spec side, I think the spec also got a bit simpler, like, you remove some edge cases and things
Maria Silva:Become a bit more simpler.
spencer:Yeah, I guess I'd add, so…
spencer:Yeah, on the… on the spec side, basically, all of the… all of the logic we do before the call is now…
spencer:At the end of the call.
spencer:So basically, We just removed that logic, which…
spencer:to me, makes… makes… makes things more simple, and I guess kind of more safe in that sense, because it's just, like…
spencer:It's happening at one point instead of,
spencer:multiple areas, but just because it's simpler in eels.
spencer:Doesn't necessarily… it's gonna be simpler for the clients when they… Use the… use their journaling.
spencer:oh, yeah.
Maria Silva:Go. Rogan, do you want to say something?
Dragan Rakita:Yeah, I looked at the ELS code, and it's not something that any clients can use. It is mostly iterating over the state after every call.
Dragan Rakita:So, this is not a solution that we can…
Dragan Rakita:Anybody can use because of performance.
Dragan Rakita:we will still need to have… I don't see it as a simpler solution, it's a different solution.
Dragan Rakita:We'll still need to have a counter that counts the state gas that needs to be…
Dragan Rakita:Accounted at the end of that transaction.
Dragan Rakita:in comparison, First solution is basically adding it directly to the refund.
Dragan Rakita:So, I don't see it as simpler, I think to get teams set, they're simpler for them.
Dragan Rakita:And… Yeah.
Dragan Rakita:That's my… Yeah, input on that.
Maria Silva:Okay, perfect, thank you.
Maria Silva:So did you guys have any time to look into these? Maybe people from Nethermind, Besu.
Maria Silva:Or nuts.
Ben Adams:Not really.
Maria Silva:Okay, so,
Maria Silva:Yeah, I don't want to rush to a decision here, because I do think this is, like, a major design
Maria Silva:choice, so…
Maria Silva:Maybe, Spencer, would it be okay for us to just, take the decisions we have right now?
Maria Silva:And then… Give a few more days for people to look into this option, and then, report back.
Maria Silva:Like, what would be the best, or what would be, like.
Maria Silva:A good deadline for us to, like, fully settle on this decision.
spencer:I mean, just to keep the ball moving, and the fact that we're all happy with, I guess, the previous decisions, I would be inclined to…
spencer:go with what we have decided here for… Definite 4?
spencer:And then if anyone has any strong opinions on… The alternative approach?
spencer:Then we, in the next few days, just as we chat async, then…
spencer:we can maybe revisit that at ACDT, but if not, I'd say we just go with
spencer:Go with these decisions for… For DevNet 4.
spencer:Stefan, maybe, maybe you wanna… wanna say something as well?
Stefan Starflinger:Just that I, agree. I think we've made a lot of decisions, I think we have enough to go on, and this is pretty fresh. I think we should let that idea…
Stefan Starflinger:Grow it a little bit and think about it a bit.
Maria Silva:Okay, sounds good. So let's take these decisions into DevNet 4, so we'll just assume that we do the refunds at the time where they
Maria Silva:Happened, with the exception of the self-destruct, of course, that it happens at the end of the transaction, but for all the others, things happened during, the execution.
Maria Silva:And, and then in parallel, we'll continue to chat async and try to figure out if the
Maria Silva:option of doing at the end of the call, or even doing at the end of transaction, how, how people are discussing now in the chat would be a better approach.
Maria Silva:Sounds good.
spencer:Just a quick, question. So, the… the threads?
spencer:To me, it felt like I was kind of spamming the channel, but,
spencer:I feel like overall the feedback has been positive. Is this something that…
spencer:You guys think we should consider doing…
spencer:In the future for… for EIPs, if there are any spec… Related, changes or decisions.
spencer:And we just opened these threads.
spencer:And then kind of what we've done here, agree on the call. I mean, in an ideal world, we'd,
spencer:Have the spec.
spencer:I guess, finalized a lot earlier before… for implementing, but I think with EIPs like this.
spencer:But there are a lot of edge cases to, kind of.
spencer:figure out. The Fred solution, to me, feels…
spencer:Feels like it's been good, sort of, people…
spencer:I agree with that, then we can maybe make that,
spencer:As part… as part of our process, I guess.
Maria Silva:Yes, I think, at least for me, it was super helpful,
Maria Silva:Yeah, I don't know if someone disagrees, but yeah, I think it was good.
Maria Silva:well organized.
Maria Silva:Perfect. Anything else on AT37?
Maria Silva:So I'll just stop sharing my screen then.
Maria Silva:And maybe in the last 4 minutes, I'll just like to give a quick upload, so…
Maria Silva:Good news on, benchmarking side, so after, a huge lift from Louise and Jocham, I think we finally have the state access benchmarks, working.
Maria Silva:We've collected initial results. I haven't yet shared any numbers yet, because I think we are still
Maria Silva:We still only collected a few runs, so I think we need to wait a bit more to get more runs in. But we should be able to then, by interop.
Maria Silva:have the numbers for… final numbers for both 7904 and AT38, so the compute reprice and the state access reprice, so I think we'll be in a good position to then try to include them into a definite re-interrupt, so…
Maria Silva:Yeah, just to give that, that quick update. And,
Maria Silva:On that note, also, I think the next, call would fall in the interrupt, so they… it would likely be
Maria Silva:canceled.
Maria Silva:And yeah, and then we'll see if it still makes sense to continue the breakout, after that, depending on… on the progress we do.
Maria Silva:But yeah, thank you so much for attending. Are there… sorry, is there any other questions or comments there? Yes, Johan?
jochem-brouwer:Yes, about the compute cache and the state cache, I see that we have not yet
jochem-brouwer:proposed this for DevNet 4. I think we should only do this when we think these are ready, but maybe we should start to signal that, this
jochem-brouwer:well, the EP with at least the initial numbers is coming soon, but we would really want this on DevNet 4.
jochem-brouwer:Is that correct?
Maria Silva:So I wouldn't say it goes to DevNet 4, so my understanding is, like, DevNet 4 is something that is already launched.
Maria Silva:or interrupt?
Maria Silva:And then maybe during interop, we'd be working on integrating those EIPs into
Maria Silva:a DevNet 5, maybe? Or is this not correct? Spencer, am I incorrect?
Stefan Starflinger:I think we would… we would go in the direction of, getting a Glamsterdam DevNet running, so with both EPBS and, BAL.
Stefan Starflinger:And the repricing changes, but there, I think we would create a Glamstagram DevNet Zero with just the already existing EIPs, not adding new ones, depending on how EPBS progresses also. So right now, there's been a lot of spec changes on the EPBS side.
Stefan Starflinger:And that will probably delay things a little bit, so we really have to see it interop what the best, course of action is.
Maria Silva:Right, but I would say that initial, Glamsterdam DevNet would only have DevNet for EIPs, right? So it wouldn't have the repricing for compute and state access.
Stefan Starflinger:Yeah, that's right, yeah.
Maria Silva:Right. And then we could try to work during the week to get those EIPs in.
Stefan Starflinger:yeah, I mean… We can try, for sure.
Stefan Starflinger:Depends on how quickly we progress.
Stefan Starflinger:Really. I think it's, quite optimistic.
Stefan Starflinger:To get, everything done.
Dragan Rakita:From implementation side, I'm very optimistic that we could do it, but we'll see. AP8037 is very… yeah, there is a lot of new mechanism and all things, but changing costs should be… should be easier, but we'll see.
Stefan Starflinger:Yeah, I'm happy to be proven wrong.
Maria Silva:Yes, and I think there's been also a lot of work done on the testing side, right, Spencer?
Maria Silva:For… for those EIPs.
spencer:Yeah, I think… I think those EIPs should be… should be okay.
Maria Silva:Cool.
Maria Silva:So… yeah, I think we are…
Maria Silva:At the end of the call. Thank you all for joining, and yeah, speak soon.
jochem-brouwer:Alright, thank you.
Stefan Starflinger:Thank you.
spencer:Cheers.
Maria Silva:Bye.
Chat Logs
00:02:17
Maria Silva:https://github.com/ethereum/pm/issues/2016
00:02:24
Parithosh Jayanthi:Giphy [ID:XCrNuIxkoVqQbG55MP]
[Full message cannot be displayed on this version]
00:02:59
Dragan Rakita:Awesome list spencer!
00:03:54
spencer:Replying to "Awesome list spenc..."
Maria's finds just relaying!
00:05:59
FLCL:exec cost will be spent
00:08:07
Dragan Rakita:This one makes sense to add, it aligns how subcall logic is currently done
00:09:23
Stefan Starflinger:1. Top-Level Reservior Refund -> Option 2 refund parent frame same as child frame
00:13:44
Dragan Rakita:It is state refund, not present refund
00:15:50
spencer:If we do 2, we should do 3/4 I think
00:18:34 Ben Adams: self destruct was a mistake 😅
So many issues
00:18:44
Dragan Rakita:Replying to "self destruct was a ..."
Worst thing ever!
00:19:45
jochem-brouwer:deprecate selfdestruct eip when
00:20:46
Ben Adams:self distruct refund loop?
00:20:54
jochem-brouwer:only happens at end of tx :)
00:22:46
Stefan Starflinger:when RAM gas?
00:23:44
Dragan Rakita:True, there is access cost
00:27:26
jochem-brouwer:I also think to be consistent return all the state cost paid for the selfdestructed contract (so refund this at the end of the transaction)
00:28:08
Dragan Rakita:How to fully kill selfdestruct?
00:28:50
jochem-brouwer:This CREATE3 pattern is this used much in practice? Are there any use cases of SELFDESTRUCT currently besides reusing CREATE?
00:29:52
Ben Adams:Replying to "This CREATE3 pattern..."
CREATE3 is quite cool as gives you an CREATE2 like address (nonce free) that isn't dependent on initcode
00:30:22
Ben Adams:As the creator is always same address and always has nonce 0
00:31:08
jochem-brouwer:Antwoord verzenden naar "This CREATE3 patte..."
oh right good point, address independent of initcode
00:31:30
Ben Adams:Replying to "This CREATE3 pattern..."
but not sure why you'd use self-destruct beyond contract creates
00:34:12
Ben Adams:Replying to "This CREATE3 pattern..."
is a wacky opcode
00:39:09
Stefan Starflinger:sgtm
00:41:50
FLCL:sounds cool
00:42:27
Dragan Rakita:I would do sstore at moment of call, and do selfdestruct at the end
00:43:27
FLCL:it sounds stricter against dos and simpler/safer
00:43:59
FLCL:maybe at the end of tx?
00:45:16
FLCL:don't you track it with bals?
00:46:20
Dragan Rakita:Replying to "don't you track it w..."
This is at the end of tx, not at the end of the call that eels code did.
00:46:51
FLCL:Replying to "don't you track it w..."
and can't we refund at the end of tx?
00:46:55
Stefan Starflinger:agree, this still needs time
00:47:55
jochem-brouwer:This EIP sounds like a nightmare to test lol. I am mainly thinking about cases where there is just enough, gas -1 and gas+1 available and then doing proper journaling e.g. OOG, not OOG, and the refund tracker 🥲
00:48:58
FLCL:incerement only state gas, real charge at the very end. so gas limit should be bigger, but gas spent is just for state changes
00:49:22
jochem-brouwer:Yes agreed
00:50:45
Dragan Rakita:Replying to "don't you track it w..."
Ok got confused, there are two things here, one is proposal to use gas state at the end of call, and second is when to use refund. Second one to use refund makes sense, it would be done as inner counter state_refund and just do it after tx ends.
00:52:55
spencer:so bal-devnet 4 pre interop -> glamsterdam-devnet-0 at interop -> glamsterdam-devnet-1 (maybe)
00:53:42
spencer:we just need to work 15hrs a day and we'll get there
00:54:05
Stefan Starflinger:happy to support as many devnets as we can manage :)
Summary
10 highlights
· 3 action itemsExperimental
Summary
10 highlights · 3 action itemsExperimentaleip 8037 design decisions
- Refund state gas to reservoir when reverts prevent state creation00:06:01
- Refund 0→X→0 storage transitions to reservoir, not refund counter00:09:23
- CREATE gas refunded when no state created; new VM behavior00:15:03
- Self-destruct refunds processed end-of-transaction, includes storage slots created00:19:45
- EIP-7702 authorization refunds go to reservoir when account exists00:36:02
- Transaction validity check now requires sufficient state gas coverage00:38:19
testing progress
Decisions
- State gas refunded to reservoir when no state created (top-level reverts)00:09:41
- 0→X→0 storage refunds go to reservoir; old refund counter deprecated for state gas00:13:27
- CREATE operations refund state gas when account creation fails00:15:50
- Self-destruct refunds all state gas at transaction end, including storage slots00:27:26
- EIP-7702 authorization refunds to reservoir when account pre-exists00:37:07
- Transaction inclusion requires sufficient state gas for maximum consumption00:41:50
- DevNet 4 uses in-place refunds; end-of-call alternative deferred pending review00:47:42
Action Items
- Benchmarking team (Johan, Luis): Benchmark self-destruct loop refund overhead with gas benchmarks post-803700:28:46
- All client teams: Async discussion: evaluate end-of-call vs in-place refund timing00:42:27
- Maria Silva, benchmarking team: Finalize EIP-7904/8038 benchmarks for interop presentation00:50:07
Targets
- Interop week - Present final EIP-7904/8038 benchmarks; launch glamsterdam-devnet-000:52:55