All Core Devs - Testing #82 (EL Breakout)

Transcript

Mhm. >> on an existing chain that sounds off to me. So. >> So the 16 million is not even the problem. The problem is that the contract used mix method, which means you mine the signature of a transaction without having the private key that generated that signature. So using mix method you set a gas limit into your transaction, which was in this case years ago chosen to be 100k. And since then you always submit the same already signed transactions to generate this um create2 factory. And since the original transaction was signed with um 100k gas and now because of 8037 um the state

creation gas costs um increased, which means the transaction will just um run out of gas and it would need two to 300k gas, which it was not created for. This is what I mean. >> Okay, so we would end up on different chain with different address. >> Yes, so if you if you would now deploy a new Ethereum chain and you would just keep do the same gas scheduling that we do on mainnet, then you couldn't deploy this factory. But everyone who has it deployed already is fine.

>> Mhm. Mhm. But if someone wants to deploy it on a new chain that is already existing chain, so he cannot like do irregular state transition uh easily, he can deploy it on different address. That's that's That's the case? >> Yeah. Yes, exactly. But then there that would also land on a different address. So the goal here is that if you write a dapp, then you want to have it on the same address on each chain. So what dapp developers do at the beginning, they have to decide which create2 factory they want to use and usually they pick createX or Arkened and based on that um it's already predetermined which chains will support them having the exact same address.

>> Okay. Then I would be for option three. To to deploy >> The only different difference between option three and option two is that on option three we have like the what is I would say the state of the art factory which also returns like the revert data and that kind of stuff and also um the second point was the addresses returned in 32 bytes and not 20 bytes. That's That's literally the only um I think the only difference based on what Frankie was putting into the Discord.

And yeah, comparing those two I would I would go for option two just because it's less work and gives us exactly the same and everyone is already using our Arachnid anyway. >> Yeah, this uh option three would be has a big downside that you have to bootstrap it again from scratch across the whole all of EVM chains, right? Um and this is a feature deterministic deployments across chains for which this network effect is very important. And so I think option two is significantly better um in in that regard.

>> Okay, Marius is asking which doctor we talking about. I posted ah okay. I was Frankie already. Thanks a lot for posting um the link already. So the those are the three options when we talk about options. Yeah, are there any other opinions on that one? >> Yeah, may maybe just just to reinstate because um I just got convinced that we should not even consider three because two is already like the standard great two factory and Vangel already said we can actually use two to deploy three.

So, what we what this means is we should really communicate if you start a new chain, then you should deploy this great two factory in the genesis. Um but all the other chains which already have this great two factory, uh they can just deploy this upgraded version. So, so three is like an an an well, let's say version two of this this factory. >> Is there any any other client team with an opinion on that one?

I mean, yeah, what Lucas is saying um that answer is you forget about it and then you use chain is screwed. This is true, but it's it's really about uh sorry Marius, go ahead. >> Yeah, you can you can just do a do a irregular state transition and put it there. It's not really a problem, right? >> I I think the L2s are doing these irregular state transitions quite frequently to add like system contracts. So. >> Maybe maybe also to to to mention here that this might also be more a part for the the the development side.

Uh because like in the client teams, we don't actually have to change anything. It's just a communication that this is the great two factory and as soon as it's deployed, and then in all tools what we make like genesis bells, it should just be included. >> Yeah, so it feels like we have quite some consensus, this draft consensus on going with option two. So, is there anyone who would oppose that, would have a strong opinion for staying, keeping 797 as is, or doing something different?

Karim, you're unmuted. >> Uh no, no, I didn't want you to talk. Sorry. >> Okay, all good. Cool. I can ask again, anyone strongly opposed, otherwise I would just um sync with Frontier Way sync and we either swap out the EIP or we create a new one and swap it out in the Amsterdam meta EIP. Um but yeah. The whole thing is in the end a simplification for clients.

>> Okay, so >> Sorry, Maria. >> move [clears throat] to the 8037. Oh, sorry, Maria. Go. >> Just very quickly, um if we are retaining any EIP or 797, right? Because I think it's important that we retain the EIP just um to to make sure that everyone understands that everyone who is forking into Glambulance them, other chains I mean, know that this contract has to be deployed before 8037 uh lands in their chain. Right. That's why it's important that the number is important, I mean. Yeah. >> Yeah, definitely.

Awesome. Sounds good, and then I would say we move on with the next topic, and the stage is yours, Maria. >> Thank you. Thank you. Um so, we have two topics, mostly. Um the first one um goes So, it was already discussed in the previous ACDT, but there was still not a lot of, um, engagement with it. And I think it's important that we close it now, so we can, um, start working or start finalizing the specs for bold up net seven.

So, it is question of, um, doing a more, um, accurate gas accounting, uh, for 7702 authorizations. Um, so, this was a proposal by Gary. Um, and, yeah, I I, um, I think at the time we had some, like, no one opposed to it. Um, but this is a uh a a slight change to how we are doing gas accounting there. So, I, before merging, I just wanted to get a thumbs up from from from from everyone. Um, so, I'll give here, um, some time, like, are there any issues here, um, that anyone, um,

thinks or is it okay to just, uh, merge it? So, this is, um, for context, um, let me see if I can share the PR. It's, uh, this one. Okay, thank you, thank you, Luis, for for for your comments. Um, yeah, I think

we'll likely have to do some, another review just to make sure that the wording makes sense. Um, but but, yeah, if people are in general in agreement with the direction, we can just um start working on it and and merge it. If there are no more points raised. Okay. Um so I'll take this as a decision. So we'll move on. We'll move forward with this one. Um so I'll work with with Gary um and and and have it merged. Um the second point is also something that uh was raised by Gary on Discord and he shared these analysis.

Let me just try to get it. Um so essentially the and this is something I also wanted to to get your opinion on because so the current wording of the EIP um is essentially saying for uh create and create two. Um and uh calls, we do the state's uh gas accounting uh before the respective call frame.

and um the the question here was that how it connects with um balls and this idea that we only um charge for state creation as we do the access itself. Um so I I I guess it's like I I recognize that the EIP is not super clear around the point where the charge happens. It just says before entering the call frame. Um my understanding is that it should be charged as we are doing the access. So we do the access, we figure out that the uh account is missing and then we do the access charging.

Um is this how it is implemented in clients or um and in the specs as well? So, would just updating the IP be a no-op or is this actually changing behavior in clients? For for us, this would actually change behavior. And and we could throw away a lot of code because of this. That's that's why that's why we really proposed it.

Because it Yeah. We we can charge at a different point. Um, and uh that makes uh the gas calculation much easier for us. >> Okay, how about um other clients? Um Maybe can we have someone from Besu?

How how do you guys do this? >> Uh I I only had a brief look. I think it would simplify our code a bit, but it's definitely a code change. So, I I I I I think from the effort it's fine for us. In general, I think it should make the code a bit easier. >> Okay, how how about you, Andrew? Um do you know how Aragon is implementing this? >> No, sorry. I haven't looked into it. I need to to to check.

>> Okay. Uh I guess I'm not seeing more client representatives here. Um in terms of of specs, um would this be a spec change as well? Um, does anyone know? I know Mario, if you if you know. >> I think so. I think it should be a spec change. But I if it's going to go up to that devnet 7, we it shouldn't be like it might be a like one line change and update like both tests, but not not that big of a deal.

>> Okay. Um, so from the clients that did look into it, it seems like it would simplify code. Um, also I agree it should be more explicit in the EIP. And in general, I do think it makes sense as a change. So, um is there like any concerns or should we just uh do the decision here and just say that we'll take this um change um and add it to the EIP. Um, okay then we'll we'll do that. So, I

will uh do the update um on the authorizations and then also um this uh clarification. I'll open the PR for the EIP and then share on on on Discord before merging it so everyone is informed. Um, but yeah, I'll I'll move on with this. and I think these were the topics for the EL. I'm not seeing anything else. Um, is there anything else that we should discuss in the last 3 minutes? >> There is like a PR um

to about [clears throat] 20 that you're um for including thinking of basically delegation and access list. I'm not sure if you're still doing it. >> Uh yeah, this was the restructuring. Um so, we said um if there is no decision taken, we just keep it as is. So, right now the EIP is still open, but it seems like most client teams uh haven't really chimed in >> [clears throat] >> or haven't voiced a strong opinion except for I would count that as an opinion for the default where we are today.

And if that's the case, I would just move on with that and close my PR. >> I think Karim commented friend. >> Sorry, go ahead. >> Yeah, I think Karim commented like few minutes ago that they're looking into it. >> [snorts] >> So, Karim, if you're here. >> Yeah, yeah, just as I said, I'm just trying to implement it on Besu to see if it's something clean or not to to add it on Besu side.

So, I want to have maybe one more week like that I will be able to to finish the implementation, test it, and see if it makes sense or not. So, yeah. But yeah, for the moment, I don't have any conclusion. >> Okay, thanks. Yeah, then let's discuss it next week again. Would also be great if from other client teams get um Nethermind, Aragon, if they could also look into it.

Um Prysm has already been advocating for that change. yeah, same for Nimbus, CL, Lighthouse, Rex. Um it would be great if we um if you guys can chime in into the Discord thread. I can post it again into the Discord because it might have been moving up fast, but I can post it again and then we can see and take a final decision next week on ACDT. >> Um can I can I just ask so um sorry, can you give a bit more context so and that is is this for balls or also for 8037?

Sorry, I I I I missed this one. >> Yes, I just posted it into the into the chat. This is the the whole discussion. There is right now a PR open. Let me also see if I find this one. Um yes, I found it. One second. This is the specs PR if you want to look into it. And it's basically um changing when we charge certain things.

So, this might also play into what Gary was um analyzing there. Um I would have to double-check the exact things we do now because I don't remember them by heart. But this might play into the topic that Gary analyzed. >> Right. Um yeah, I think it would make sense to have two things um together or maybe like at least align them. yeah, okay. We can do that, I think.

>> Sounds good, yeah. Are we done with the agenda? I guess so. We are at time anyway. And I would just say we end the call at this point. Awesome. Perfect. Thank you everyone. see you on ACD C on Thursday. >> Thank you. Bye-bye.

>> Bye-bye.