Glamsterdam Repricings #6

Transcript

Parithosh Jayanthi: I'm assuming you guys couldn't join until I joined the call? Is that true?

Ben Adams: Maybe.

Maria Silva: Hello, everyone. Sorry for the bumpy start, I'm not sure what happened.

Parithosh Jayanthi: I meet you host now, so you should be good to go. But you should ask someone from DevOps to sort this out next time.

Ben Adams: We had to wait… we had to wait for Barry.

Parithosh Jayanthi: Yeah, no, I'm… I just abused some admin permissions to get the call to start, but it was a short-term fix, let's say.

Maria Silva: Okay, okay, I will reach out to them after. Thank you. It's actually funny, because for some reason, I was timed out out of the ETH Research channel, Discord, so I couldn't even talk there, so I'm not sure what happened. But yeah. So, without further delay, maybe we can start. So, the goal of this call, so I can post the agenda… Let me just get it, But the main topic is, finalizing the decision on, the spec for… EIP-8037 and, Pectra DevNet 4. So, spencer posted, posted the, 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

from, Pavel that, Spencer then implemented, very quickly in the specs, just to… just to have a, an idea. But yeah, I think, maybe the, the, the best way here would be just to get, like, a general… Feedback from, from, from each of you, saying, like, in general, How do you feel about the… the… the refund to the reservoir? And then the general idea of doing it at the end of the call. 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… 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.

Should we… if there are no, like, general comments, should we go maybe one by one and discuss? Okay. So, let me then try to get the lease out. Mmm… Okay, so I'll just share my screen, and we can go one by one. Okay, so… First on the… 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…

Consensus from the people that answered that things should be refunded to the reservoir. But yeah, happy to… happy to hear your thoughts there.

Ben Adams: So, one… one consideration is… Could somebody… If it was a full refund, could somebody use it to… Grief in some way, where they create state and revert. Could not pay any state cost. 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… I think the state gas component of operations should only account for the added costs of 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 Of impacts, both for the size. requirements of disks, but also syncing, and so on and so forth. Like, we are all aware, we are 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

accessing The states, so reading and writing. And then we have these, like, long-term cost of the fact that now state got larger. And… the way I'm thinking about is, like, the states… gas component should only cover the long-term costs, and so it's only actually affected if… 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 incentives for grifting to be there, because you'd always… Pay the cost of the execution. You just wouldn't pay the cost of the state growth, and that's fine, because actually no state is being grown. so I… I think this is where, for instance, on the… on the CREATE case,

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, 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… decide on, yeah, we will do the refund in this case.

Spencer Taylor-Brown: I think in the thread, we all kind of seemed aligned on the refund. That being, I guess, myself, Dragan, yourself, Maria. 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. 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… 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 refunded fully, it would go to the refund counter, which had a cap of 20%. And so, on this case, I'm still… Personally, I'm still a bit… tending towards giving the refund, because I think that's the more correct thing to say, but I also

can see the fact that implementation-wise gets… this may get a bit more tricky, because now we have these two 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. 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. If you don't do that, we will have, like, a little bit fake data on how much state gas is consumed. For me, it's more about how to implement it. Pavel proposed to delay That state gets refund to the end of the section. And second option is to do refund at the place when we do X to 0. 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. Then delaying it to the end. But I wouldn't mind, like, doing it differently.

Maria Silva: Okay, so maybe, 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… 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? 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. Daniel, do you… from Besu, do you have an opinion here?

Daniel Lehrner: Weekly, I would say, I would return it immediately. Not adding it to the refund. That's… that's a big position.

Maria Silva: Okay. Okay, so maybe, if no one complains, I'll say, to me, the takeaway here is we do want to do the refund. Maybe we still… still need to… 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 the end of the block, the refund should be there. And should go to the reservoir. I'll give one more bit for… People to complain about this one. Okay. Perfect. Then point number 3… I think this one is… 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…

should return, the state CAS. So, like, in my mind, if we are okay with 0.1 and 2, I think 3 is sort of, like… 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. Okay, so I give one more bit. So I guess here, if there are no complaints, we'll… Give the refunds. In this case, so this will change. how… Gas Create works,

Okay, then I'll take these as we provide the refund, and then for point number 4… 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 a state act… the state's gas back, and, yeah, in that case, I think it would also make sense to… To do it, yeah. Go, Ben.

Ben Adams: And just a side question, will this… completely affect refunds. So we're… we're giving immediate refunds for site creation. Would we want We also have the other refund. Oh no, maybe it doesn't matter.

Maria Silva: Right, so I think… 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, That will go through the refund counter. For all these new refunds we are giving, they will go directly to the reservoir. So they can be immediately used, and they don't have The 20% cap on it. And then, maybe in the next fork, we can decide if we want to fully get away with the… 0 to X refunds.

Ben Adams: I mean, not… I would say that is consistent also with the regular So if you… if you start a… If you start with the zero state, set it to something, and then set it back to zero. In the same transaction, that's a different cost to the, 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, I mean, in the current costs, they… they… they don't… they have the same refund, let's say, but yeah, with these Issue number two would be changing how that works, so… Now the 0 to X to 0 will just go directly to the reservoir. Perfect. So, any, oh, go, Johann?

Jochem Brouwer: Yes, about 4. There's, like, a gotcha about self-destruct. If you… Invoke South District? Then the account flow actually gets removed at the end of the transaction, so not if you invoke it. 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 refund in place. In this specific case, we should just refund at the end of the transaction.

Jochem Brouwer: Yes, exactly, yeah. 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. That can theoretically be refunded, in the case that this storage is either reset, or cleared, or whatever. 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. then, that will not go into the stated SFR, but then into the Regular gas, sorry, not the regular gas in the refit count.

Maria Silva: Exactly. Yes, it will go into the refund counter. Bragan, do you… do you want to speak next?

Dragan Rakita: There is one more edge case around self-destruct. If we create a contract, then self-destruct it, basically, in the local the local, like… context. What if we do a store on all the self-destructed accounts? We will still charge the state gas… Because… We don't know… there is no, like… We'll still charge the gas for the account that will get self-destructed. So the question is, should we account the storage that got deleted? For the account that got self-destructed. 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? 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. Self-destruct, you can check that only after the end. 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. And then self-destruct. You… Return the 100 storage lots. In cost. Because he didn't grip.

Dragan Rakita: You… Created, then nothing is going to be stored on the state. Because all of that is going to be deleted. 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. Of the transaction, now is all my storage fee. So I can… I can store. 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? 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 actually access… accessing Like, the access costs for creating those accounts will be Much more expensive than just a final loop of just iterating over them and giving the refunds. But I would guess that this is something we can try 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. I mean, it's normally… I think, the most use of, self-destruct is, like, a Create 3, where you… You deploy an account, use that to deploy a… contract with the Create. So that you get a deterministic… Nonce endpoint across chain. I don't see why… what… Functionality you'd be gaining from, like. Raiding a thousand storage slots and then self-destructing it. But I don't. Other than, like, a briefing rate in that. Massively increasing the accounting.

Maria Silva: So I… I guess that's… that's also a point, but I… I think it's more of, like. 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. Except when… this specific thing happens.

Ben Adams: Yeah, but my… my issue is that the self-destructors are fixed. cost. It's not related to the number of things you're self-destructing. with her. So there's an inconsistency in self-destruct.

Maria Silva: Right.

Jochem Brouwer: Yeah, maybe to also mention here that, just as a reminder. that you can only do self-district in the same transaction as in with the contract it's created. 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. It makes sense to refund, the state… state guides that it's not going to be used to create state. That's the logic that I go by. So, if… even if somebody creates the 100 or 1,000 storages inside self-destruct account. That storage, because it's locally created, are not going to be stored on the… in the tree. So it makes sense to refund them and have… State gas only representing… to have state gas representing only the state that got created. 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. And so it's not like they can do this to then fit more things in the block. And, 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. So I would… 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.

Ben would be okay with this… with this plan.

Ben Adams: Yeah. Although I'm… I'd like to… look at the effects, right? Okay with how it is, but maybe… In some testing, yeah. 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. This case. Yeah, good, good point. Anything else on point 4, or are we all in agreement to issue the refund to the reservoir?

Spencer Taylor-Brown: 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… Or at least that's how this rule works in my mind. You refund the state cash once you actually change this state. So, from the 0x20 case, if you would set X20, then you would get this refund. 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. And possibly also these, storage slots, which were created. Then the only note there is that if we were to rethread this to the, state reservoir. 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. perfect. Anything else on point 4, or should we move to 0.5? Okay, so I think in point 5, since we are refunding the self-destructs. I think… Here… so, the question in this point is, what happens when you do a call with value? To an account that was previously self-destructed. So, my… Intuition here is that you should try to keep with the principle that we only charge for

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… 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 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. 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. So the account is already created, because if you are in account With, which is creating code. then it is already being created. Let me actually check if that's the case, even if it goes from inside. Mmm… 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? 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. I think… Yeah, yeah, no state gas is going… No state gas should be consumed there, so it's, we can skip 5 and just, like… It's not tissue.

Maria Silva: Okay. 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 Taylor-Brown: Yeah, no, sounds good.

Maria Silva: Okay, perfect. So moving on to 6, I think this one is… One that is a bit… slightly different from all the others, because this is connecting to intrinsic Cas. So maybe just, just going there. So I… 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 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. If the account actually exists, then I do a refund through the refund counter.

Okay, so this is how 7702 initially implemented this. So if we didn't want to change anything, we should just keep this behavior, but again, like. 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. We are sort of mutating I mean, we are not mutating the intrinsic gas, because that still is, 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… 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 772 account, which is being authorized, if that already exists, then we should directly refund this gas to the state reservoir. And if this does not exist, then we would, of course, charge it.

Maria Silva: Okay. 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%. And it's consistent with everything else we've decided, but I just wanted to… Here maybe some, some more opinions, Okay, so I'm assuming no complaint means that it's okay to give the refund through the reservoir? So, should we go with that one? Okay, then I guess we'll… we'll go… With that one,

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 Gas available to cover for the regular gas. But I think we should also… consider, the state gas. So we should, have enough available gas… Sorry, enough state gas available to cover for the transaction gas, which is the most that the user can use on state. 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. are there any, opinions against this, or complaints?

Okay, so, in this case, we'll do the streak to the bottleneck here. 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. Currently for DevNet 3, we need… I think we are doing that check after the transaction, and that's slightly… Strange. 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? That will cover that, in any case, anything that's get, as a kid, we'll… 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? 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 the idea from Pavel, and, This option of giving the refund just at the end of… The call frame versus Right at the point where the… The… the… the storage is being not… or destroyed, or whatever, is not being used. 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…

At the point of, 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. 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… 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. And so… Yeah, you, you… Like, yeah, I'm… this was, like, my broad understanding, but also it's not very deep. 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 Become a bit more simpler.

Spencer Taylor-Brown: Yeah, I guess I'd add, so… Yeah, on the… on the spec side, basically, all of the… all of the logic we do before the call is now… At the end of the call. So basically, We just removed that logic, which… to me, makes… makes… makes things more simple, and I guess kind of more safe in that sense, because it's just, like… It's happening at one point instead of, multiple areas, but just because it's simpler in eels. Doesn't necessarily… it's gonna be simpler for the clients when they… Use the… use their journaling. 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. So, this is not a solution that we can… Anybody can use because of performance. we will still need to have… I don't see it as a simpler solution, it's a different solution. We'll still need to have a counter that counts the state gas that needs to be… Accounted at the end of that transaction. in comparison, First solution is basically adding it directly to the refund. So, I don't see it as simpler, I think to get teams set, they're simpler for them. And… Yeah. That's my… Yeah, input on that.

Maria Silva: Okay, perfect, thank you. So did you guys have any time to look into these? Maybe people from Nethermind, Besu. Or nuts.

Ben Adams: Not really.

Maria Silva: Okay, so, Yeah, I don't want to rush to a decision here, because I do think this is, like, a major design choice, so… Maybe, Spencer, would it be okay for us to just, take the decisions we have right now? And then… Give a few more days for people to look into this option, and then, report back. Like, what would be the best, or what would be, like. A good deadline for us to, like, fully settle on this decision.

Spencer Taylor-Brown: 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… go with what we have decided here for… Definite 4? And then if anyone has any strong opinions on… The alternative approach? Then we, in the next few days, just as we chat async, then… we can maybe revisit that at ACDT, but if not, I'd say we just go with Go with these decisions for… For DevNet 4. 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… 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 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. And, and then in parallel, we'll continue to chat async and try to figure out if the 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. Sounds good.

Spencer Taylor-Brown: Just a quick, question. So, the… the threads? To me, it felt like I was kind of spamming the channel, but, I feel like overall the feedback has been positive. Is this something that… You guys think we should consider doing… In the future for… for EIPs, if there are any spec… Related, changes or decisions. And we just opened these threads. And then kind of what we've done here, agree on the call. I mean, in an ideal world, we'd, Have the spec. I guess, finalized a lot earlier before… for implementing, but I think with EIPs like this. But there are a lot of edge cases to, kind of. figure out. The Fred solution, to me, feels… Feels like it's been good, sort of, people…

I agree with that, then we can maybe make that, As part… as part of our process, I guess.

Maria Silva: Yes, I think, at least for me, it was super helpful, Yeah, I don't know if someone disagrees, but yeah, I think it was good. well organized. Perfect. Anything else on AT37? So I'll just stop sharing my screen then. And maybe in the last 4 minutes, I'll just like to give a quick upload, so… Good news on, benchmarking side, so after, a huge lift from Louise and Jocham, I think we finally have the state access benchmarks, working. We've collected initial results. I haven't yet shared any numbers yet, because I think we are still

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. 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… Yeah, just to give that, that quick update. And, On that note, also, I think the next, call would fall in the interrupt, so they… it would likely be canceled. 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.

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 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 well, the EP with at least the initial numbers is coming soon, but we would really want this on DevNet 4. 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. or interrupt? And then maybe during interop, we'd be working on integrating those EIPs into 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. 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. 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. Depends on how quickly we progress. Really. I think it's, quite optimistic. 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? For… for those EIPs.

Spencer Taylor-Brown: Yeah, I think… I think those EIPs should be… should be okay.

Maria Silva: Cool. So… yeah, I think we are… 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 Taylor-Brown: Cheers.

Maria Silva: Bye.

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