All Core Devs - Testing #83 (EL Breakout)

Transcript

With that, I think probably we've got everyone in here. Maria, if you like to start off. >> Sure. Um so, maybe we can just start by the order that we have it here. So, the first one is on 2780, which is the ETH transfers um EIP. So, it's starting to become a bit more clear from the current um optimizations uh benchmarks that will likely not be able to make ETH transfers cheaper. Um and so, these kind of changes a bit the flavor of the EIP. So, it's not um about making ETH transfers cheaper, but it's about making the price of ETH

transfers um align with their actual execution work and um and state uh growth uh charge costs in a way. Um and so, this is a major rewrite. I opened uh an EIP for I opened a PR to the EIP. And yeah, it would be great to get some some eyes on it and see if if people in general um agree with it. And yeah, this would be the proposal for the next Klömp Stadäm Devnet. So, that that would be the shape of the EIP and the and the and the numbers um that we shouldn't expect them

to change too much. And so, what this means now is that we still have some clients that are performing worse than this. So, that would also need um so, that work still needs to continue, but we have a sense of like this is the goal post for this EIP, and these should be the more stable numbers um that we see. Um So, yeah, I don't know if there's like any comments here already. Um um Go Guru. >> Uh yes, so uh remember the first form of this EIP had like code versus no code separate charges based on the final benchmark numbers. Is that I know the second draft that you had

kind of took that out? And based on the final numbers are we still sticking to having same charge across both types of accounts or >> So I I would say to me it seems like the difference between EOAs and contracts likely do not justify the added cost or the added complexity. I mean EOAs or E transfers to EOAs are still still so they are more performant, let's say, but I don't think that the the the change is like that significant and and

that would justify the added complexity of having that check for every E transfer. And for context, if you want to see uh what the current numbers are um um I have this dashboard and um you can take a look there. So I I I I would say is it okay to make a decision today or should we give more time for people to look into it and

review a and reviewing it? >> Uh I I I uh looked at the PR. It largely looks good to me. There was one very small edge case uh uh that I have uh added a comment. We don't have to discuss it now, but it largely looks good to me. >> Okay, for client teams and maybe especially Ben um that I know you were one of the initial authors of the IP. Do you need some time to look into it or should we just uh make a decision today?

>> I I didn't end up where I wanted it to. >> [laughter] >> Um I I've been in New York the last week, so uh but I would like a day to look through it. >> Sounds good. Um so maybe we can just go go starting discussions on the other topics and so the takeaway here is um please take a look um review it um and maybe in uh next few days we can discuss this async and then merge it. Ideally, we would have this merge sooner rather than later so that we can um have a finalized back for um Glandstone definite six, but that

that is essentially the let's say the goal. Like we don't need to make a decision today, but we need to kind of uh do it in the next couple of of days. cool. Then the next topic um is 8037. Uh so we have a couple of open things. >> Sorry to interrupt you, Maria. Uh Tony just asked in the chat if we could just announce the 779 changes real quick. I think it's a short a short um PSA. Tony, did you want to do that now?

>> Yeah, sorry for the interruption. Just wanted to quickly announce because I saw it on the agenda. Um, Francio changed EIP 7997. This was decided on ACD E last week. We switched from the system contract that would be deployed to 0x12 and it's now basically enshrining the Arachne contract. And that's the whole change. Just as a heads-up that we have it pro forma documented here. >> Awesome. Thanks a lot, Tony.

Um, I guess there's no questions on that. I think it's quite clear. Otherwise, chime in right now. If not, handing back to Maria. Thanks, Maria. >> Right, for then for 8037, again, we have a couple of open decisions for Gnosis and then 86 as well. Um, so the first one is uh error that um Pavel um discovered on the uh dimension per dimension inclusion check. Uh, so when we are um seeing if if if a block is valid and if the the next transaction can be executed.

Um, and essentially the the key thing is like the specs were not doing the check that the EIP was doing. Um, and I think the the EIP was the correct um behavior. Um, so this means that we would need to merge this into the specs. Um, I I'm I'm not sure. Is there anything to discuss here or is it people are mostly aligned on this isn't it's just a matter of of of merging? I I I haven't found any issue with with merging this. >> Yeah, I think we we just need to merge it in the OS, I think.

>> Okay, so there's no essentially no decision. It's just an action on on yield side. And and then maybe there's a warning that um things will be um yeah, client devs need to um update their their implementations if they are complying with a spec at at this point. Um the other one is an issue raised by Gary and a potential uh conflict with block level access list. Um he had this hack MD with um an analysis. Uh we still don't have any PR to update the EIP um or the specs.

Uh but essentially the the key change um that is being proposed now is in the create um cases. So, create transaction and create up code. Essentially, the idea is like to uh pre-charge always for account creation. And then at the end of uh at the end of the call frame, uh we do refill in case of um if the account was already existing, then we do the refill. Um so, that this should be the main change. Um again, I think this is fairly I haven't found any issues with this so far. Um Um Goloise?

>> Uh yeah, so um I have a quite a little bit of a strong opinion here. Um I would like to know what is it meant by pre-charging. Uh so, are we charging the parent or the child frame? Because I think that's what we need to get clear for for this matter. >> Yeah, we would charge on the parent. >> Yeah. Okay. Because then this creates um a changing behavior from what you currently have, what which we might OG the the parent and right now we don't we don't check if the account exists at least in Bezo in a parent frame we we do all these

checks in in the child frame and also update the nonce and the balance and so on. So currently create return zero [snorts] if it OG's and if we do this check in the parent we would be introducing OG's in the parent possibly. >> No actually like currently we also pre-charge the account creation in the parent. For the for example like for the create up code so the gas price is 32K it includes the account creation and at that point we are run out of the gas the parent will be invalid and it will be reverted so the behavior is aligned.

>> Okay I'll need to double check that then I just to be sure >> So maybe a clarification is it is aligned with the current so it it's not aligned with the current implementation of 8037 so this is not how the current specs are doing it but it is allow aligned with how creates would be charged before clubs are done. >> Exactly. >> If that makes sense. >> Yeah I just post the link to my write up and I have explained like why it is not good to charge it inside of the child frame or after the child frame and

what is the current behavior we having we are having like right now for account creation. So please check out the write up and hopefully we can make a quick decision. >> Thank you, Gary. So, I I I would say maybe um the next steps here would be for client devs to take a look at the proposal and the hackMD from Gary, see if you can find any issues, and um let's do a decision, I think. Um in the meantime, I'll also draft the PR on the AIP um with this change, and then we can I

will also post it on on on Discord. Does that sound okay? >> Yeah, uh sounds good to me. >> Okay, perfect. Um then the next thing on 8037 is um these um so, this is a discussion we had during interop uh actually, which was um when we are doing the refilling, do we refill back to the reservoir always, or do we refill to the counter we took it from? So, in sometimes we would refill back to the reservoir, and other times we'll we'll fill back to the to the gas left. Um

This is relevant because So, I I I think this would kind of if we So, at the moment we do always refilling back to the reservoir. If we move to the source-based refilling, so refilling back to where it was taken from, um it would solve two things at once. So, the first one is we would um Uh so, there was this issue that um the way we were dealing with reverts um was not complying with the initial discussion we had in interop where we decided to just refill

So, when we do a revert, we would only give back the reservoir that was available in the parent. So, this would avoid having different So, in asset calls, if you reverted in different levels, this avoids having different gas accountings. The second issue it would raise is something that uh Gulwish from from from Azure raised, which is the next point, saying that for authorizations, we are actually doing this overcharge and then refilling back to the reservoir, and we should be refilling back to the gas left. So, if we just decide to do source-based refilling, then these two

issues get solved automatically. I feel like the initial discussion was around the reservoir refill was a bit easier from an implementation side and also from a testing side, but now that we've all started to implement these things, and since we have to have this exception for reverts anyways, it feels like now implementation is not that much easier. And also for testing, I guess folks seem to be more comfortable with with this change. So, so it seems like from my perspective, it seems like we should go with it. But yeah, happy to also hear your thoughts.

Is there like any questions, concerns with just doing the source-based thing? I'm Gulwish. >> Yeah, sorry. I I would just like to split the both cases because I think they are a bit different. So, the one I raised is um more because I believe it is an overcharge that is later corrected after processing the authorization list.

And I think it's different than refunding back the to the source the the to the source of the gas during run time. Because at this stage you are overcharging and then you are kind of correcting in your overcharging rightfully because you you to prevent DOS attacks, but then you are um correcting these charges even before execution kicks off. Uh and then yeah, just to charge the exact amount to the user.

Uh in this case. So, I think it's a bit different in my view. >> But you agree that we if we go with source-based refilling, your issue would be automatically resolved, right? >> Uh yes. Yes, if you go like source wide, but I mean they they if it's just I just want to prevent because there could be some contentious on the second one and I want to split them uh a little bit concept because they're not similar conceptually. That's what I I'm going for.

>> I see. I see. I see. Got it. Yeah. >> Um yeah, I think that's good to split it. I would even say the 7702 the basic authorization list how we give back the gas. I think we could even simplify it even more because it is at the beginning of like execution. We could directly return the gas, not return it like later. And just like continue execution. So, we could do something. I think I think uh I think Luis you already proposed this.

Basically, take it return gas for authorization that doesn't create anything. return gas back, and then just calculate reservoir from that uh gas amount that you have. I think this could be even simpler solution. Those are like small like details how you're going to do that. But, yeah, on the first point, yeah, about the like written that it's like I don't have strong opinion. I think both works.

>> But, we still need the source-based refunding mechanism to solve the issues if we halt in the different place, the estimated gas used will be different. >> Yes, yes, that that will solve that that issue. True. Okay, so I think conscious of time and we are all already over. So, very quickly, I guess we'll move this async, but it would be nice again to take a decision in the next couple of days so that we can move on with the implementation of the specs.

Um so, I I I guess for all of these changes essentially will be the same thing. I'll draft the EIP PR and then I'll share um and then we can just continue on. Uh two very quick things. So, first is um 7904. So, it is clear now that the compute re-pricing won't be needed after client implementations. sorry, client optimizations. And so, I've converted the EIP 20 informational EIP. Uh it's already merged uh and you have the PR link if you want to take a look. Um and then for 8038, I'm I also opened the PR, but it's still in draft with some early numbers. So, the idea

for these numbers is not that all clients are already matching them. It's a bit similar to 7 um 2780, which is more like a goal and then we need to make sure the clients opt in finish their optimizations to meet this goal, but it give us an initial set of numbers we can use for the for the top nets. So yeah, just the PR is also in the agenda. Please take a look and yeah, any comments are welcome. And on that note, I guess we can wrap up.

>> Awesome. Thank you so much, Marian. >> Thank you all. Bye-bye. >> Thanks, everyone. Bye-bye. >> Bye-bye. >> Thank you. Bye-bye. >> Thank you.