All Core Devs - Testing #84 (EL Breakout)

Transcript

Well, um So, I think we have here four topics on the agenda. So, the first one was actually raised by myself, so I can just um start on that. Um so, um there was one update on the EIP 8038. So, this is the state access EIP, so the EIP that is changing the cost of state access operations. Like sstore and sload calls and stuff like that. And there was a a a um a bug in the way that we were doing the uh sstore refunds. So, when when someone clears a slot from X to zero,

and essentially, um we were missing to undo the refund when um the slots that ha- was cleared then was rewritten to again. Um And uh from my understanding then, uh looked into it, it was a bug in the EIP, but the specs were correct. And so, I think if you are using London Devnets um six on the latest release, it should be okay. So, it's just uh now it's mostly just a warning that the EIP was incorrect, and now it is correct. Um So, that's it on my point. Then, I think we have here two more points that Stefan

raised. Um Do you want to >> Um >> talk about it? >> Yeah, sure. Um I just wanted to ask if anyone is still using uh Berlin Devnet 3, uh since it's already quite old, and we I think now successfully migrated to Berlin Devnet 7 for benchmarking. And if I could retire it, and if no one uh has any objection, I think I will retire it uh pretty soon. >> Yeah, I would say for benchmarking we are not using it anymore. Um, yeah, everyone is using bold definite seven as you said.

>> Sounds good. Uh, and then the second point I just wanted to um, kind of make it a little bit more official than uh, in the discussion. I think we decided uh, on option one. Um, unless there's anyone else that uh, wants to add some more context that hasn't been mentioned yet. >> So, is option one not changing anything?

Sorry. >> Yeah, exactly. >> Okay. >> Sounds like we're agreeing on option one then. Then I'll also update the spec sheet. I think that's it for me. We have one fourth point. >> Yeah, I think it's Louise um, raised this um, so this was um, an issue that Louise raised um, a couple weeks ago. But my understanding is now that we are uh, so this is related to 8037 so the state growth EIP.

Um, my understanding was that once we moved 8037 to use the source base uh, refill so um, doing a a a refill first on gas left if there was any spills to gas left and then only then start refunding back to the reservoir. So, my understanding is like with these now his issue or the issue he raised sort of um, not doesn't happen anymore so maybe we can close it. Um, but if I'm missing anything, Luigi, please let me know.

I I think it just wanted to get a thumbs up from from client. >> Yeah, um, the test still reads like uh refilled the state gas reservoir. Um, uh, so, uh, yeah, I think that still needs changing, uh, at least. Uh, if we don't go to we don't want to go to the through the intrinsic gas route. Um, so at least need to change that, I think. >> Okay, so what would be the next steps there? I'm not sure is uh Spencer, are you in the call?

I'm not seeing you. >> He's out of the office today. >> I feel I feel that, um, uh, it it that this this is my opinion, uh, just working it out in the intrinsic gas, uh, might be, uh, the best place because you don't need to track things over, uh, into gas left. Um, but because this feels like very localized to the 7702 uh processing authorization list processing.

But, um, yeah, if people are want to go with gas left, I think we could, um, change the the text uh, to show that it's going to be, uh, going to impact, uh, whatever the source, uh, was taken from. >> Yeah, so so something that I think we we should avoid is and and the reason why it is doing it as it is today is that we would ideally like to keep intrinsic gas independent of state. And what I mean by this is like you cannot change intrinsic gas depending on the current state tree.

Um because if you start introducing dependencies between intrinsic cost in and the state, then this creates a bunch of complications for transaction validation and also looking forward when we move to like a partial stateless or Um like pops world, then it will be even harder. So I think it's the design at the moment was done taking that into consideration. So we wanted to avoid intrinsic gas having dependencies with the state and that's why it's also we are charging the worst case and then refunding after.

So yeah, I don't know if there's any Yeah. I >> Don't you have like two intrinsic gas now? Like the regular and the state one? How does that play with the stateless side of things? >> So at the moment essentially the only charge we do for a state gas in intrinsic cost is first when you do create transaction and this you already know by just looking at the by just looking at the at the transaction envelope.

Um and then we charge worst case for authorization. So we always assume that creates state and we charge for for the worst case. So these are the only two and so they are independent of the state tree. Right. Um Dragondil, you want to to go next? >> some clarification on that. If the if we basically are going with source base refund, with source base refund, basically we don't have like split between initial state gas, initial state gas initial regular gas, because if they are refunding to

to to basically remaining gas, that that the difference doesn't doesn't like matter. So, in the end you could just do like just interest do interest the gas everything like summary of everything, reduce the the gas limit of the section with that, and then do split between regular gas and reservoir. Um additional difference that I see, yeah, yeah, this should be equal.

Uh So, that's like nice property. Uh additional like difference that I see from from like ordinary uh usage of the gas how we do it in the sub calls is when the main call or create fails, you don't erase that 80 uh AP 7072 like uh refund that you already did. So, that's like nice that's like edge case that we need to to to be aware of nothing more.

But yeah, that's like my my my how I see this this change. Nothing more. >> Right. So, if I follow you correctly, so essentially it's like the way we are doing it now and the way that Louis is proposing us to do it at the end would be giving us the exact same gas accounting and intrinsic gas costs. It's just um if you do it before you do the split between gas lit and reservoir or after.

This is correct. >> Yeah, that's true. I think they are same and that's nice property. Um, Mhm, So, how do clients feel about this? Should we make a decision on these and then move it to the next step in that maybe? Um, because I think maybe move like introducing this already on devnet six maybe a bit too short. >> How is it currently done?

Uh, do we have anybody from testing team that knows about it? >> I don't know, Dan. Do you Do you have an opinion there? >> Yeah, sorry. I was a bit out of the loop on Friday. I was wondering maybe if Mario could chime in. >> No, I have to see the tests to be honest. Yeah. But just my recommendation would be to not touch the release and just leave the clients consume the test assets and then we make a decision for the next step.

It would be too rushed in my opinion to change anything at this point. >> Yeah, I I I agree. So, maybe what we can do is um, Louisa, I Sorry, I haven't looked into this AP in in this PR in a long time. Is it um, agreeing with the latest um, change in 8037 or do we would we need to make any updates on this one? >> Um, so can you repeat that?

>> Excuse me. >> I I was I was asking if your your PR is already taking so this one if it's already taking into consideration the latest changes on 8037. So, the um the changes with the authorizations that Gary introduced and also the source-based refills. >> Um yeah. >> I >> Yeah, so I've based on top of the latest 7702 changes on that VIP and I don't think the source-based had any conflicts with this one. So, I think it should be good to go.

>> Okay, sounds good. So, I I guess like at best we are targeting the next step net for for this last thing. Um so, maybe what we can do is let's maybe we can post this again on on on this card and I will I'll ask all the clients to take a look and see if they like this change and if yes, we can we will make a decision on the next ACDT. That'd be fine for everyone. Perfect. Um and I'm sorry. I I I I thought that this thing would be would not be needed after we merged the

latest changes, but I think I I kind of misunderstood what this was trying to do. So, apologies for that. Um And yeah, so I think for 8037 this was the last topic. Um I don't know if there are any other topics that people want to discuss or should we wrap up earlier? >> Would be good to get all the glumps down, definite six branches up. If we can.

>> Yeah, we are all starting to see the the end of the tunnel, right? >> [laughter] >> Cool. Anything else or should we wrap up? >> Um, I would just add that yeah, I think everyone knows that um the first release for .NET 6 is out on execution specs and there should be like another release out tomorrow with some additional coverage.

So, we'll post when that's ready. And otherwise, if someone from Bazoo could just take a quick look at this diff and make sure that the name corresponds to what's found in the Glamster .NET 6 branch, that'd be awesome. >> Cool. So, should we wrap up or are there any other topics?

Okay. so I guess we can all leave the the breakout. Um, thank you all. See you in a couple of days. >> Thank you. Thank you. >> Thank you.