All Core Devs - Testing #86 (EL Breakout)

Transcript

I my understanding is not is not that we are launching it is the specs should be landing >> okay >> for that date so we need to make a decision in this call essentially but I think if we make a decision then it should be to >> um I think the change is fine and we should go with it >> perfect yeah this aligns very much with the vibe I got on Thursday and last week. it seems like people are very much um agreeing that we should do this. Then I would just say okay let's merge um um my APR to the he's already merged and

let's also get um Puru's um PR against execution specs merged and we can then roll it out on def 7. Perfect. If there is nothing else, I will pass it over to you, Mia. >> Thank you. Thank you. Um, so I guess there's two open issues on one on 8037 and another one on 2780. So maybe to start with 2780. I think this is something we discussed. Um,

I don't even remember was it in ACD or ACD? I'm not sure, but we already brought this up. Um, so this is a proposal that Raan added about changing how we charge intrinsic cost to only be the charges that depend on state. So previously for some things we would overcharge during the intrinsic costs and then during runtime we would preund back and with this change we are only charging the things that don't depend on state and then during runtime we charge things that depend on state and so they essentially um function as the normal EVM runtime would. So you do the

separation between the state reservoir and cast left. We have the same refunds and same um same logic overall. Um so I think there was already a lot of comments on the on the EIP for the PR and I feel like we are um in a good um in a good enough spot. So I think it should be ready to merge. I know I don't know um Draan and Guru if you have like anything else that you want to read out here. Um or if you feel like um it's it's it's ready to to be merged.

>> Yeah, I I think it's sorry gone. >> Okay. I I um I think it's ready. I think it's there. Uh I did few modifications because yeah of the comments and discussion that we had simplified a little bit. So yeah the question is mostly about the second topic that we need talk about because if the topic is [snorts] um if we go with that path of how we calculate create then this affects interest at least runtime part of the intric but in general I think PR is in good

spot. >> Okay. Um Guru what what what were you going to say? >> Yeah, I agree. The only like very minor thing that I would want uh to explicitly agree on here is uh uh once the the point we were discussing this morning I think on discord where once the authorizations are set and there's enough cash to pay for them but the transaction ogs after that point do we like roll them back or not? Uh um so I yeah if we can um like kind of agree if all the clients can agree on that uh I think the rest of it seems seems fine to me.

Right. So the so the the key change is like before if you had enough gas essentially for the authorizations essentially you the the the authorizations would just um happen while here if now during runtime if um there's some halt then um then we are essentially rolling them back. Um, so I I I tend to agree with so Guru said that he would be leaning towards option number one. So rolling back um I tend to agree. Um I see that Luiz from Bezu is also agreeing. Do you

have anyone um that things differently or go Yam? >> Yeah, I just want to raise that if we change this I think the changes are fine. Um but what we are changing is that currently if um so you can think about it as uh regarding the EIP772 delegations that this is now not part of the same well how you want to call it like the the the execution level frame and the pre-execution level frame. So if the execution goes out of gas then your authorizations still go through. Uh and what we are now introducing is something

else. I think this is fine but we should definitely check if this doesn't change any assumptions on the user side or or or people will will use the the delegations that uh now everything is rolled back. So this this this will change and I'm just raising that we are at least aware of this change. So how how do you think users would be impacted or how could we um do that analysis?

>> So currently what um what you are guaranteed is that if you send a 772 transaction then you are guaranteed that all these authorizations are checked and if they are valid then your authorization will go through no matter what your execution uh will do. So if that execution goes out of guess then authorization still go through and what we are now introducing is that uh if the pre-execution check is not valid then your uh delegations do not go through. Um yeah I'm not really sure how we should check this uh because EIP72 is not super used a lot. Um but yeah we we should investigate. I'm also not sure like who should do this. I would not be

able to do this but yeah we should do it. But just to be clear like before the reasons so after this change the reasons why the authorizations would roll back is essentially for the same reasons that the transaction wouldn't be valid in right now. Right? So it's it's it's it's not like transactions that were valid before now the authorizations are not val are not executed if this makes sense.

>> Uh and what do you mean exactly by the validness of transactions? Because do you mean that um uh because we have two checks like the intrinsic check uh and the actual execution part um and you are now sure that you are currently sure that if your transaction is valid in the sense that it can be included in the block. So you pay the intrinsic gas cost then you are are ensured that your delegations are checked and they will go through and now it is possible uh we introduced the thing that your transaction is valid so it can be included in a book but uh now you are not guaranteed anymore that your delegations go through >> right but the reasons so if if now you submit a transaction that is valid but

that your authorizations are rolled back after this change. Previously, what would happen is that that transaction wouldn't even be valid, right? So, it's it's not like transactions that were valid now are not executed correctly. It's just transactions that wouldn't be valid before now go out of gas. >> Yes. Uh yeah, I think you touch in Yeah. Yeah. >> Okay. Got it. Got it. Okay. Just trying to kind of put like some intuition behind this. So, I in my mind seems fine. Um, but yeah, I don't know what what what other clients think.

>> Um, it it did seem a bit weird that you you essentially have a transaction that rolled back, but the delegations didn't roll back before. So, I'm okay with Yeah, I am also very curious about the original Russian reason for like have this particial uh to have the valid uh authorization even the transaction is invalid. Uh because people might send a lot of like continuous transaction in the man poolool with all the nons bumped

all the time because they assume the transaction no matter the transaction itself is like out of gas or some other uh failure. So the the nons of the authority will still be bumped. Uh if we have this changed then the sender must check out the nons like before they sending the transaction. Um I think uh previously the gas amount for the changing or inserting your storage was low is basically two times of the transaction cost. But

now that's basically increased by the 10 time. So the overcharging thing that we had previous I think it made more sense than having it now there where you require basically 10 times more the gas even for the accounts that you know that exist. That's one of the points and I think second point is um I think including reverting back all the things makes a lot of sense if somebody wants to deploy transaction again it can be always done so it's not blocking factor for anybody but I think having the notion that transaction got included didn't block

but didn't execute I think with the future development blockchain this is going to be a lot more common with new protocols so I don't think that's something that we need to think about a lot to the point that I have so my understanding so far is that um in general people seem to be okay with this new change but we need to check with um 7702 others to see if they um what's their opinion on this? But could we so would it be okay for us to just say um let's merge this change um and for now

assume that this is the way forward and then um today we'll uh reach out to to um to light client and see um if he finds any big issues. Um, but could we I I just want to avoid like delaying this decision for another week because uh it would be nice to close the specs. Um, so would that be okay for everyone? >> Yeah, it sounds good to me. >> Okay, perfect. Um, okay. Then the last thing is on for repricings um is uh something that uh Pavvel raised on 8037.

Um I can try to see if I link the PR here. It's this one. Um but essentially so before the create um charges um were essentially unconditional. So we were always charged the state creation um independently of the account existing or not and then at the end we if the account was existing we would refund it back.

And um Pavl is essentially proposing for us to be a bit smarter about it and just do the checks um during so before entering the the the create frame and um yeah is essentially is specifies more um clearly like what things are checked and when the charge actually happens. Um, so I think I would open now the floor. Did you guys have time to look into it? Um, does this look okay? Um, and should we should we merge this? And I would say in regards just just to make it clear in regards to I think then like

because of these changes in parallel the EIPs are no longer fully accurate between them, right? then we'll have to then do some cleanups there. Uh but I would say let's just focus on these two changes independently and then after they are merged I can just do a final pass on the IP and make everything consistent both for 803837 and 2780. Um but for now let's just focus on the meaty decisions and then we can do the cleanups after. Yeah. So just to confirm the powers change will only affect the one specific

uh one case is that the destination of the deployment was preunded right and otherwise like we will always create the account for the contract deployment. >> Um sorry Gary can you say that again? I couldn't fully understand it. Uh what I'm saying is the EIP will only affect the one special case uh the destination of the deployment the contra deployment was pre-existing with some balance. It is like the only special case for this uh for this EIP.

Sorry. Are you are you meaning to say that the change that Pavvel is suggesting only change that case or or are you saying something different? I I think is this uh EIP change will only be make some difference for this special case? Uh the the destination of the contract deployment was pre-existing with some balance. So originally we will pre-charge the state gas and in this case we with this new EIP we will not and it's the only difference if if I understand correctly.

>> Yeah I think that's that's the case. >> I think we are currently overcharging everybody here on every call on every create top code basically we charge and only revert if the call or create reverts or holds. So yeah, I think yeah, it's it does two things like it doesn't charge something that we didn't do and it basically doesn't overcharge user for the something that's not going to happen.

But yeah, it is the create target is already existing has balance and you basically your create or create code is basically want to create contract there. >> Right. Right. Right. Uh so yeah I think it makes sense. So for the overall end gas used that is the only change but it does also change to like the accounting during the create frame right um >> yep >> and it's going to change if this is like applied it's going to change how the the main tx create basically does does that >> basically right inside yeah

>> yeah it should be consistent. Agreed. Um, okay. Um, yeah. Do you have any more comments here? Are people fine with this change? Should we merge it or or not? >> Uh, it looks fine. I think we should do it >> and it makes sense. >> It's also coherent with the other change that we just discussed previously because that other one also defers the charge of the create transaction. So, I think this also makes sense. Okay. So, I feel like this one seems more or less um everyone is in agreement. So, um we can just merge it. I think Pavvel had

some changes there that were like in relation to another EIP that he was trying to fix as well. So I think maybe better to remove those references and then just merge this specific part. Um yeah and then I will just clean up all all the IPs and make them consistent across the board. Um but yeah so I guess to do these um for dragon's PR I'll just approve it and merge it. um Pavvel's um just ask him to change that bit and then approve and merged and then I will um make the IPs consistent and then from the spec side um I I guess you guys also

need to to work on the specs but do you need anything else from from our side? I think we're I think we're good now. Um >> yeah, I think uh I guess we can uh we'll keep updating the tracker um async, but I think as the tracker is right now, I think it covers everything we've discussed minus the spec EIP mismatch that uh Gary mentioned before the breakout, but um yeah, we'll add that there if uh yeah, if it's appropriate.

Okay, perfect. Then I think for repricings that's all. I do see here something that Barnabas suggested to discuss on builder deposits, but I'm not so like I'm I don't have context here. Um I don't know if some someone wants to read this part. I mean, I'm seeing it's already merged, so I'm not sure if there's a discussion there. Um, Mario, do you know, Mario on Spencer and Guru, do you know if we need any actions here?

>> Which one are we talking about? I missed that bit. Sorry, I'm I'm just saying that Barnabas puts put this one um in the agenda. Um it's already merged. So I don't know what he wanted to discuss on this point. >> Yeah, I think before when he posted it wasn't merged, but we've uh we've got a PR up for for that now. It should 8282 I think just needs a review and merge on our side. >> Okay. Okay, perfect. Okay. Is there anything else we should discuss then?

Um, or can we wrap up earlier? Okay. Um, thank you all for for joining and yeah, see you around. Bye.

>> Thanks all. Bye. Bye. Bye everyone.