All Core Devs - Testing #81

Transcript

Danceratopz: Good morning, Stefan.

Stefan Starflinger: One and…

Danceratopz: Good morning, everyone. I'll just give another minute for people to show up.

Alright, I think that seems like a pretty good turnout. So, let's go. Good morning, everyone, and welcome to all core devs testing number 81. It's June 1st, 2026. I think we've got a bit of DevNet discussion, to talk about maybe the fallout from DevNet 4, and, then we'll have a, A good look at some upcoming spec updates. And then we'll have a bit of discussion how we move forward with the next DevNets. how Glamsterdam DevNet 5 might look, for example. So let's get to it. First off, Glamsterdam. Just a quick heads up. The fortnightly Wednesday gas repricing breakout calls that Maria has been holding on Wednesdays. They've stopped now, as the specs have stabilized, and basically any discussion will now be moved to this call in ACDT.

I just dropped the agenda in the chat. And then we can jump straight to… I'll DevNet 7. So, the current state of bal-devnet 7 is… it's been pretty… it's stable, and… Apparently there's been 100 EVM fuzzing with 100% participation. Maybe Stefan would like to jump in and give an update there, or someone else from Eve Pandrops?

Stefan Starflinger: Yeah, sure. So it seems that, 8037 has mostly been successfully implemented in all clients. I… Can see that, from a consensus side, most guides are agreeing, most of the time, and there are just some small blips when some clients are updating, or creating a new commit, and the image is updating, with Watchtower most of the time, so it's working pretty well, and most clients are now working on, benchmarking and performance. So bal-devnet 7 branches will stay around, so clients can iterate on benchmarking mostly. So we can, get the final numbers, for that. But overall, it seems very stable at the moment.

Danceratopz: Great news. Thanks a lot, Stefan. On bal-devnet 7, EVE70 and EVE71 were mandatory, and I think you raised the question in a comment as to whether this works complete. Is there anyone in particular you wanted to hear from, or…

Stefan Starflinger: No, just if we could get a quick update on… from all clients, so I can just check it off, with confidence, because I think, we haven't… Put too much time in confirming it, from a testing perspective.

Danceratopz: Okay, perfect. Yeah.

Ben Adams: They're both implemented in Nethermind, in life.

Danceratopz: Perfect. Thanks, Ben. Any other clients would like to speak up? So here, another status of… So Tony says EV71 is done in all clients, as far as he knows. Has anyone got an update there? Besu, Daniel says both are done in Besu. Efrank's both done… Anyone from Erigon here?

Andrew Ashikhmin: Yes, we have them both implemented.

Danceratopz: Perfect. Thank you. I'm not sure if Ref could make the call today, but I think I saw Raimi in the… in the call. Does he know the status? Bye.

Stefan Starflinger: I think they have it.

Danceratopz: Okay, perfect.

Stefan Starflinger: I think the last one is Nimbus, then. Yo.

Dragan Rakita: What was the question? Sorry?

Stefan Starflinger: just if, Eth70 and Eth71 is done in the client, or if there's still some open… Work.

Dragan Rakita: Yeah, yeah, it's done from our side.

Danceratopz: Perfect. I presume it's done in Geth. If anyone from Geth is in the call, maybe they can speak up quickly.

Gary Rong: We also have the A771.

Danceratopz: Any update on EV70?

Gary Rong: We have… we also have that.

Danceratopz: Okay, perfect. All right, thank you. And I think we'll move on from that. You happy with that, Stefan? I think… That's pretty… Yeah, perfect.

Stefan Starflinger: I checked it off, already, just wanted to confirm.

Danceratopz: Nice, okay, thank you. Then… just while we're selling Val Definite 7, Steel is still in the process of merging AT37 into their default development branch, Fort Samsterdam. That's pretty close, if I understand correctly. And once that happens, we will, cut a final release for Battle DevNet 7 at 730, as a sanity check for everyone. It will ping you, obviously, in the Discord, once we get that far. Okay. So, maria, or any benchmarkers in the call? as benchmarking is happening on bal-devnet 7, I just wondered if you wanted to have, a quick round here, about the state of clients on bal-devnet 7 regarding optimizations? Or whether you'd like to defer to tomorrow's call and the gas… Benchmarking committee.

Maria Silva: maybe it's better to defer. I… as a general remark, I can say that, some clients are still working on optimization, so we don't yet have final numbers there. So when we do, maybe we can update here in this call, but I think for… for now, it's better to just… Defer to the… to the call tomorrow.

Danceratopz: Perfect. Thanks. So that would be… the end of bal-devnet 7 updates. Then the next on the agenda would be, the Glamsterdam DevNet 4 situation. I believe, there was a split. Last week. Does anyone want to give a quick overview of what happened there, and what the next steps would be?

Barnabas Busa: Sure, can you guys hear me well?

Danceratopz: Yep.

Barnabas Busa: Yeah, so last week we had a transplant, and Since then, we have, updated the spec, and we are expecting to have offline spec release. By, hopefully, end of the day, based on the decisions that we make today, we're gonna be either expanding the scope or, keep it as is. And then we could target to have a new DevNet op, with off an ISPAC as early as maybe tomorrow.

Danceratopz: Justin asks… Changed in the spec.

Justin Traglia: Yeah, sorry, what was the problem and the fix?

Danceratopz: There's a PR posted above 5307.

Barnabas Busa: I think there was some clarification regarding some, was it KTC? Maybe.

Justin Traglia: Oh, that's right. I don't recall if that were… I don't recall if that was the issue, but yeah, great.

Nico Flaig: So maybe I can quickly clarify that, so for Lodestar, at least, we implemented, should build on full, as per the spec. And what basically happened there was we built a block that we didn't accept ourselves as head. We basically kept building on that branch. So that's just the… so we have a PR for that, but it doesn't really need a… a release, I guess?

Barnabas Busa: The reason I would like to have a release is, it's a bit nicer for us to keep track of, which specific version goes into which specific DevNet. So if someone that maybe wasn't included in the previous demo can still be onboarded, using the… Using the specific offline, if we do end up making a new release. Also, if we end up including 8045, then we also run into new release.

Nico Flaig: Yeah, but also this only clarifies what the load star issue was, so at least for us, but I still don't know why the network Broke like that. So we stopped also peering with Prysm, maybe, Other clients implemented the same bug? I'm not sure.

Danceratopz: I believe the other PR, 5307, is from 2EAFs. Is 2EFS in the call?

Nico Flaig: Oh, no, that one is the issue, basically, outlining it.

Danceratopz: Oh, that's the issue, okay. Oh yeah, sorry. Perfect. Thanks. suggesting that we merge these PRs before the next Alpha 9 release.

Justin Traglia: Yeah.

Danceratopz: I'm sorry.

Justin Traglia: Take a second to review them.

Danceratopz: So, previously, Barnabas, you suggested quite a fast timeline about, essentially, a new release today, and launching as early as tomorrow. would it be okay to consider the message from Justin and include those other PRs before creating a new release?

Justin Traglia: Just to clarify, I think we can't make the release today, or early tomorrow. These PRs are relatively simple.

Danceratopz: Okay.

Barnabas Busa: Yeah, I think the main question is AD45.

Danceratopz: Hmm. Is that relatively clear, how to proceed there? Okay.

Justin Traglia: From my perspective, yes.

Danceratopz: Okay, well, that's… that's the main thing. Thanks a lot for… Sharing that, and thanks for the explanation, Nico. I guess you'll follow up on that async?

Barnabas Busa: I think it would be good to make a decision on AD45 on today's call, whether we want to have it in, or we want to DFI it. I would not want to… keep going back and forth on the small EIPs.

Justin Traglia: Yeah, we just need to make a decision on AD45.

Danceratopz: Is that a decision that, you, Justin, and Barnabus want to drive right now? Since we're on the topic?

Justin Traglia: Yep, I'll let Barnes do it, though.

Barnabas Busa: Sorry, could you repeat that?

Danceratopz: So, if you'd like to get a decision on AT45 today? Would you want to reach out to client teams and see how they feel? Do client teams want to chime in?

Barnabas Busa: Yeah, I mean, I… I hope we have a client team from each team here. Could you guys chime in whether you would want to have 8045 in the next demo cycle? Maybe we can call out different client teams, like Lodestar?

Nico Flaig: Yeah, we already have it implemented, so we would be good with that. It's also pretty simple for us.

Barnabas Busa: I think Prysm also implemented it, already. We have Lighthouse.

Eitan Seri-Levi: yeah, I think we're… it's not a huge lift for us, so yeah, we're cool with it.

Barnabas Busa: Anyone from TECO? Pardon number seat? Hard drinking?

Justin Traglia: Dimitri from Tech… you said something for a split second, but I didn't hear it.

Dmitrii Shmatko: Yeah, we have not added to it, but we will let it.

Sam | Nimbus: Yeah, we have a PR from Nimbus and ready to merge soon. Once the dispatch updated.

Barnabas Busa: Yeah, it sounds like everybody would have an implementation ready, and I think we should include it then.

Danceratopz: Yeah, okay, yeah, I think that was also pretty clear to me. Everyone seems in favor. The… the only question is, basically, we're… we… this is a silly question, but we're abandoning, DevNet4, right? That's… We're not even gonna bring that back. So…

Barnabas Busa: Yeah, that's correct.

Danceratopz: If we're sort of breaking into the DevNet discussion, which we're going to enter in more detail below, but just quickly, as a temperature check while we're on the topic. it sounded like CL teams wanted to have, a DevNet at the same spec as Glamsterdam DevNet 4 in order to verify stability before Any big changes? what's the temperature on including 8045 in that updated spec, i.e. updating the spec?

Barnabas Busa: It's a very, very slow change. It's very…

Danceratopz: Okay, Nico also says, doesn't matter. Alright, okay. Then, Moving on to the spec changes, so that's the existing DevNets finished, and we move on to, spec changes discussion. So basically, the first, spec change that we've had is just a heads up. The spec change this morning that was merged, which basically, you have to have At least one storage change in order to have a slot change. I think… let me just find it… B. Harnett raised that in the Discord, and Rahul, made a PR against the spec, and added to us this morning. Yes, Ben?

Ben Adams: Yeah, I just want to confirm that the target gas limit In payload attributes. Which is required for the glamps to them, but that's not compatible with the Baldwinnet. Is that correct?

Barnabas Busa: We are doing 190 mil on grumpster term.nets.

Ben Adams: No, I don't mean that. Where are the consensus layer is passing in the target gas limit.

Barnabas Busa: Oh, yeah, that is forgotten ceremonic. Something football.

Danceratopz: Okay, so this is another, change that EL clients will have to make before they move to the Glamsterdam series of definets, is that right, Ben?

Ben Adams: No, it just means we need to keep it as slightly separate from… So we have to put that on top of… But not put it in the valid definite, if that makes sense. Everybody has the change.

Danceratopz: Yeah, makes sense. Okay, thanks. Back to the original agenda point, Rahul, did you want to briefly mention this, or did… is it very obvious to anyone? This is basically more of a heads up?

raxhvl: Yeah, I think this is not possible to be… to be generated by a client. This is basically a protection against having a malicious file with some bloated entries, so a valid client should not be able to generate it. Yeah, it's basically an initial check that we are ensuring to avoid, like, Boom. A problem with parsing bell.

Danceratopz: Okay, alright, thanks, Rahul. Any questions to that from any client teams? Okay, then, moving on to a point that Tony raised. As a comment on the agenda. Another point for BAL7928 for state access decoupling. Tony, would you like to drive a conversation on that one?

Toni Wahrstätter: Yes, happy to do so. I posted the PR in the chat. And essentially, we discussed that last week already, like, what is the ordering, when do we want to charge for certain things when it comes to a call? And this popped up during 7702 discussions, and we almost had agreements, but Dragon from REF proposed, like. In my opinion, almost a cleaner solution to everything. Like, it decouples a little bit about from the access list, tracking? And essentially, what we do here is, today we charge the $2,600 for cold access. And we do so even before we check the… the call stack steps, and also before we check the sender balance. This means, like, if those two checks fail, then we build, basically, 2,500 cold gas

For nothing, because eventually the address was never loaded. And the proposal here would then be to only charge 100 gas. Then, check the depth, check the balance. And afterwards, after we did those checks, we charge again for $2,500, such that we end up at the $2,600 again. And this is currently the PR, so I would love if clients could have a look. I know that all clients except RAF Already signals support for the current implementation, which wouldn't be doing that. But, yeah, maybe, Dragon, I saw earlier that you were on the call, maybe you can provide some context of why the current way of doing things would be more difficult for REF? And why… what is the initial, motivation? Why we should go for this?

Change here.

Dragan Rakita: Yeah, basically, the… Current solution is fine for us, but there is some proposal that was made to, like, split the warming from the bowl inclusion. And in RED, we have basically optimized those kind of things, where we have just one hash map access that does both the check for the warming and check for inclusion for the ball, and yeah, all those kind of things are done in one HashMap. So, when I saw that proposal, I thought to myself, what would be… basically, I could do implementation, but we could not be performant. I thought to myself, what would be if I design the checks now? what would be the order of those checks, and that's the solution that Tony is basically… the PR that Tony made.

Basically, do the gas, the basic gas that you need first, to do the checks that needs to be done, and then do the loading that basically proceeds after that. In the end, that make, basically the… first proposal, it was done even better, because now we optimize both on the AIP7702 access, and optimize both on the target access. Basically, we do those checks even before we access that. That means that if a caller doesn't have balance, or the… we are at the end of the call stack, those kind… those addresses are not going to be loaded inside the ball, and I think that's, like, the best outcome.

Toni Wahrstätter: Awesome, thanks. Just to flag that for other clients. If we would decide to merge that PR, this would mean all clients, except REF would have to change their implementation to make sure that items are not put into the ball without the actual access on the disk happening. So this would be quite nice to align The bulw with actual state access. But it also means some clients will need to change. And I would love if clients would find time to look into this. It's a quite… for some clients, at least, it's a quite deep change, I think. And… it might not be a very difficult change, but it's quite deep in the codebases, so I would love if clients can take their time to look into this.

And, yeah, I mean, if someone is on the call who has already looked into this, I'm curious, like, what is the perceived complexity with such a change? If the complexity is higher, I would just propose we stay We keep the code as it is.

Dragan Rakita: Just to mention, I'm…

Danceratopz: Teams on the call that have looked into this change?

Dragan Rakita: I just mentioned, from Brad's side, we are both fine with, current change. and basically present logic, and, this PR determined. we had… I had problems with that, previous, previous, request.

Toni Wahrstätter: Okay, so you would either go with as is. or with the latest PR, right? Correctly. Okay, I see in the chat, he's saying rookie here. Okay. If there's no… I mean, we can keep discussing this, there is a threat in the Ball Discord, and if clients decide we should do that. We should decide on that soon, just to get it into a next definet, or the second next… Otherwise, I would just say, we keep it as is, and that's the default.

Danceratopz: Yeah, that definitely sounds like it'd be a change that'd be worth making sooner rather than later. would it be possible for client teams to have a look at that by ACDE, and we bring it up again then, on Thursday?

Gary Rong: Yeah, I will check it. So guess…

Danceratopz: Perfect. Thanks, Gary. Okay, thanks for that, Tony. But perhaps we need to follow up on Thursday for that one, if you want to drop it on the ACDE agenda. Otherwise, moving on. Now to AT37, I believe Maria wanted to give a heads up on an 8037 change?

Maria Silva: So, I just wanted to, highlight two things. So, we had a couple of open, small changes to 8037. That were meant to be included in Glamsterdam DevNet 5, which will now be likely Glamsterdam DevNet 6. And this is just a warning that the… that PR to the… to the EIP was merged, so if you guys want to… to take a look, it's a couple of clarifications and, one… one bigger… bigger change, And then there's also another PR open that Gary, added, that he's focused on. The reservoir mechanics for authorizations, and essentially expands a bit the refunds that we give in those, in those cases. So, for the first change, I think it was less… less controversial, let's say, so it was, I merged it already, but for the second change, yeah, it's just a question for…

For… for the clients to see if they like this change, and if If they wanted to be included in the EIP. I don't know if you guys had time to look into it, but I linked the PRs in the agenda.

Gary Rong: Yeah, I can quickly introduce the change. So, basically, The current spec is a bit unclear in certain scenarios, such as, what if the authorization itself is invalid? And, now we just pre-charge all the state gas, and, if this authorization is invalid and it doesn't really happen, then we will overcharge the state gas for it. And another scenario is, It is possible that we have multiple authorizations within a single transaction against the same account. And, We change the delegation for this account from the empty to a address, and then from this address to the empty again. In this scenario, the net state change is zero. But according to the current spec, we will also overcharge certain state guests for these authorizations. And,

the intention is, I really want to, align the goal that we only pay… the amount of stages we pay will actually match the… changes in the state. So I extend the current spec by adding a few… a few more rules. One rule is, if the authorization is invalid. And we need to refund the four stages, including the one for the account creation, and also the one for the delegation marker. We will still charge the regular, for the state access, for the computational costs. But we need to refund the state part. And, another rule, another important change is and… if we… like, in the scenario I have mentioned before, if we are clearing a delegation which was paid.

previously within a single transaction, and we not only refund the state gas for this clearing operation, we also need to refund the state gas for the previous delegation, because the net change should not become zero. And, the state guess for all the authorization should also be zero. So, by adding this… by adding these additional rules, I guess we need… I think now, we will only pay the actual state change, We only pay the state gas for the actual state change.

Danceratopz: Gary, I'm guessing… did any… did any of the client teams have a chance to look at this? I think this is a change that Maria's asking more input for from… of the AL teams for this one?

Maria Silva: So… so maybe just to add a bit more context, so I… I do like the change in general, but it will be, some… so the… it will change, the implementation, a bit, so I just wanted to make sure that everyone is aware and, is okay with… with… with adding it, before, merging the… The change and included in the definite.

Danceratopz: Steelside had a chance to have a look at it, and the potential impact on tests. Do you have any feeling there, Maria, or anyone else?

Maria Silva: I think Spencer did a thumbs up, so… I'm not sure if he wants to add anything, and I think, Dragan, you're going to say something, right?

Dragan Rakita: Yeah, I didn't look at the detail, but in general, I think, change makes sense. Yeah, basically, we can be more accurate on the state gas that is spent on authorization lists. If authorization list gets duplicated. And it should be easy to check, at least, because we already loaded the previous account, and we need to compare it with the With the original version that you want to do. So… Yeah, from both the implementation side and the sense of the change, it makes sense.

Spencer Taylor-Brown: Yeah, happy, here as well.

Danceratopz: Thanks a lot for the input, Dragon, Spencer. That looks pretty good. If Erigon or Nethermind has an opinion already. on Nimbus EL. Otherwise, I'd ask you to have a look quickly at this proposal. To give a bit of feedback. Still got a bit to discuss, so moving on. I think this is the last actual spec change, that I found… this is, regarding 2780. You didn't flag this yourself, Maria, maybe this still needs a bit more time, I'm not sure. This is a change proposed by Ben, I believe? Or Dragon? Let's have a look. Does anyone want to…

Maria Silva: Maybe…

Danceratopz: the point.

Maria Silva: maybe I can… I can jump in on this one. So this is, from my understanding, is a proposal from… from Dragon to simplify, how we are doing some of the charging. So, essentially, in 2780, we do, like, a full separation of If it transfer goes… is a self-transfer, if it's calling a pre-compiled contract, and it gives, like, different… Values or different costs to these things. The reason why I haven't merged these is, I'm still in the process of refactoring that, EIP and waiting a little bit on also some benchmarking results, so that we can have, like, a more coherent version of that EIP, and then once we have it, we can maybe, Merge this, simplification.

And I think also it will depend on how the final costs look like. Not final-final, but, a bit more stable, costs look like, from… from the benchmark, so I would say If it's okay by everyone to kind of put a pause on this one and leave it as, as to-do, maybe we can, follow again next week.

Danceratopz: That's perfect. Thanks, Maria, for the overview and the update.

Dragan Rakita: If you could summarize it, there's, like…

Danceratopz: Eastern.

Dragan Rakita: tree, I think, changes there. One is to remove target to pre-compile. I think this is, like, agreed by everybody that should be removed. To remove the edge case where the caller and target are the same. I think Ben raised the issue about the lock. Basically, the gas for the lock should be even lower. I agree with that. To be honest, I didn't have time to update the PR. And the third thing is, Pricing, the access to the caller, and the delegate, if the caller has… no, sorry, target and delegate. Do not take into account if it is warm or cold, just assume it's cold-loaded. Because, it doesn't matter a lot, and… It would be, like, a bit more faster if you don't need to access the access lead, it's probably some vector, not Hash App.

to just, like, market always as the cold, cold access. I think those are, like, three, three topics.

Danceratopz: Thanks, Dragon. Ben?

Ben Adams: So my, my objections on this were, sweet. Yeah, you… you don't emit the… Log for self-transfer, so we shouldn't charge for it. Also, on the 2, I agree the access list. Ignore the access list. But… It's in the tooth, so it's like it's in the access list, so is it… already, Warm, as it were, because it's… Literally in the transaction. And also… Saying… that it's a hot transfer on the self when it's already warmed by being a from address is… Yeah, it doesn't fit with charging, And we're already special casing self-transfers in the logs.

Dragan Rakita: I'm fine with that. If you can skip the access to the access list and just assume the target and the caller are the same, yeah, yeah, I'm fine with it, because it's easy to track, and… Especially as interesting gas inside the section pool.

Ben Adams: But also… Also, it's like the to address is… is in an access list by being actually in the transaction. But I mean, the access list is irrelevant. I agree with that.

Dragan Rakita: Yep. Yeah, I agree with you.

Ben Adams: And, the pre-compile thing was because precompiles are warm addresses, but… I… I think it's an irrelevant use case, so I'm happy to… not special case people. Because why are you sending ETH to a precompile?

Danceratopz: Awesome. It sounds like we got some resolution on that. I guess you can take it to the PR now?

Ben Adams: I think… I think it still needs, benchmark results.

Danceratopz: Yeah, of course, yeah, finalization. Okay. Thanks, Ben. Beautiful.

Dragan Rakita: open new PR with those kind of changes, or if you like, I can make these changes to that PR. Find me, Tenny.

Danceratopz: Any preference on that, then? Make the changes to this PR, or create a new one?

Ben Adams: This pair would be different.

Maria Silva: I also say I already have one for the parameter changes, so I would prefer to maybe finish that one first, and then we can try to align that one with the ER from Dragon, if that's possible.

Danceratopz: Okay, sounds good. So, Maria will finalize her changes, and then you can PR on top of that. Okay. Thanks, Maria. Alright, moving on, in the agenda. I did mention, Pavel's 8246 to remove the self-destruct burn. I don't think we need to discuss the specs here. I think it was just more of a question, when do we include that? And that's exactly… our main… Big topic that we still need to get in today. So I would… Basically, quickly just go through the to-dos we have for Glamsterdam, our next spec to-dos we need to do. So, you can find it in the agenda if you want. You might want to refresh, because it did change, during the call. So basically, we need to finalize the gas repricing numbers, but this is ongoing, that's no problem.

The CL stability, we just talked about that. the issues that we had on Glamsterdam DevNet 4. Then, on the AL side, we need to include new EL AIPs, so what I just talked about, the self-destruct Burn 8246, then… Once the final numbers have landed from 1, we need to include EIP2780 and EIP8038. Which update the gas costs. We could add these to a devnet with placeholder numbers in the interim. Then, we still have not… had an updated 7954, which is the increase map contract size. My DevNet, so that needs to land at some point. And then the other EIP spec changes that we had above. And then potentially any other CL changes that we still want to get in.

we discussed previously that 8045 will be in the next, Glamsterdam DevNet. And… ATAM flags somewhere about adding 7688. I think it's… if ATAN is in the call… ETAN, sorry, if he wants in the call, does he want to just quickly… Say something to that.

Etan Kissling: No, makes sense.

Danceratopz: I think I sensed from Barnabas, eagerness to finalize the… CL specs as well, and not keep adding small…

Barnabas Busa: Very nice. I think, we need to make a decision also on the SSDs. Stuff, whether we're gonna be doing it or not.

Etan Kissling: Yeah, I mean, so Ingos and Lodestar have the 7688 implemented, right?

Danceratopz: Yeah, Tony's… So… In order to get through what we need to talk about right now, I think we… We leave 7688, and we know that 8045 is going to land at some point, First of all, Tony's also mentioning 7997, the factory precompile. We can take that on the list as well. Is… has it been… sorry, Tony, is it agreed that that's going? Is it CFI'd, SFI'd?

Toni Wahrstätter: I just remember it was… I think it was CFI. Maybe it's even already on the definite, I… I wasn't following too close yet, I just remembered recently, I thumbed over it, and was wondering. It's on it?

Barnabas Busa: No, it's not.

Toni Wahrstätter: It's not okay. Yeah, we should at some point take a decision if we wanna, ship it. Or if we want to delay to Hegota or something.

Danceratopz: Is there a quick consensus on that one? Anyone with questions? I'll take you through. Barnabas is for shipping it.

Ben Adams: Oh, this CEO, yeah. Because I think… Yeah. I think it'd be good.

Danceratopz: Mark, to see if I… Stefan chimes in right now. I think we need to move on a little bit to the form of the DevNets quickly, because I think that's quite… sorry, Tony, yes, please? Before we do that.

Toni Wahrstätter: Okay, yeah, no, just to add to that point, maybe just for clients to look into the, deterministic factory precompile, if it would make sense. I know that there are other ways these days how devs deploy contracts to the same addresses on different chains. For example, there was a new 7702 method used by SAFE. Which, yeah. We might not even need to pre-compile, in my opinion.

Ben Adams: Yeah, there's things like, so, frames transactions. And some of the, like, if you want a deterministic, privacy pool, kind of thing. It helps if there's… It's using an enshrined… Back to it. I'm not…

Toni Wahrstätter: Yeah, but you get most of it, which is basically the transaction itself, like, deploying, you get most of it with the other methods. For example, this new 7702 method also allows you to deploy to the same address on every chain that has 7702, of course.

Ben Adams: Yeah, but it doesn't make it as easy to embed in the spec.

Danceratopz: I'm just looking at the complexity assignment for 7997. That's a 5. It seems that people are in consensus about shipping. I think now we're going to have to move to the shape of the next DevNets, because it's a very important discussion to have. So I laid out some options in the agenda. So, essentially. Going into the call, I was kind of assuming that Glamsterdam DevNet 4 would, get a relaunch as Glamsterdam DevNet 5 without any spec changes. That does not seem to be the case. It seems that Glamsterdam 7114 will get AT45 on top of it. And then we'll be relaunched. Is my understanding correctly for that? So this would be, at the moment, initially,

CL only changes, and then with an aim of achieving… a glimpse of DevNet 5 with a stable CL, is that correct?

Barnabas Busa: It is, Cora.

Danceratopz: main… main priority. Okay.

Barnabas Busa: I think that that would make more sense, without adding any more ER changes, but if there's any small ER change. The clients are comfortable including as well. I'm not sure if the factory 7997 is a small one or not. If it's a very small one, then it should be included, otherwise, yeah.

Danceratopz: I think it would be maybe more the question about, including some of the already SFI spec changes into that DevNet. But before we go down that path, I would just point to the last option, which is laid out in the agenda. Which Spencer also commented on in… in the call, is essentially we could, Potentially consider launching two DevNets simultaneously? With, Glamsterdam DevNet 5 targeting mainly CL changes for stability and adding AT45, and then having another BAL DevNet, so a BAL DevNet 8, which would update the AL specs. With the changes we discussed above. Assuming they get… all get in. And, include… 8246… The self-destruct burn, removal 7954, which is the increased max contract size, but with the larger contract numbers.

And basically get BAL DevNet 8 in a form which is close to the final EL spec. And then once we have those two DevNets. We could consider a Glamsterdam DevNet6, which then merged those two specs. Would anyone like to chime in? with… Support for that, or… or… say that it's a bad idea, I would be happy to hear you there.

Maria Silva: And I just…

Danceratopz: Yeah, go for it.

Maria Silva: Sorry, I just wanted to point out, so, I… I would be in favor of, having more EL EIPs in… in a DevNet sooner rather than later, but I don't think that would… should come at the cost of optimizations being delayed, because realistically, this is now the one blocker for the entire EL, I feel, because we need optimizations to be merged. So that we can get the final numbers, so that we can update the EIPs and give time for the community to adapt to these new gas costs, and do the backward compatibility analysis, and so on and so forth. So. If you tell me that including more stuff on the Yale side won't delay optimizations, then I'm…

all go for it. If there's a possibility of it delaying optimizations, then I would rather we don't, because I feel strongly that optimizations are now, like, really a blocker for… for us to have, like, enough time for the community to adapt to the new gas costs. So yeah, just, just wanted to… To raise this point.

Danceratopz: Thanks a lot, Maria. So there is the option that, we launch Glamsterdam DevNet 5 with a main focus on the CL stability, and in the meantime, finalize the DevNet benchmarking. Done?

Ben Adams: Yeah, I'd say, it depends on how quickly you want to launch DevNet5, which I assume is… As soon as possible, because it seems a small change, for the CL. Whereas if you want to do it on a newer, Well, EL, doesn't it? That'll delay. Doing the CR one. Doing Glamsterdam. So I'd recommend you do it on the current… version of the AIL. But, yeah, it depends when you want to launch it.

Danceratopz: Yeah, okay. Dragon?

Dragan Rakita: My impression is that there is not a lot of IP that are left. There are basically a few smaller ones, maybe changes to interesting gas was… is the biggest one. I would like them… be included, all of them to be included in the next DevNet. Be that the Glamsterdam DevNet 6, where we merge CL and EL changes, What the ball damnate. I don't think there is a lot of work there to be done, and… Yeah, when that's finished, it's like, Yale's side, at least, is going to have everything in one place.

Danceratopz: Makes sense. Thanks, Dorian, for Stefan.

Stefan Starflinger: Yeah, I think we have, like, multiple work streams, and the question is, like, how many resources do we want to, put on each? So I think from the EL side, the work for Glamsterdam devnet 5 is pretty minimal. So, there's the question, how much work do we want or have to put into benchmarking, and how much work do we want to put into, the other EIPs? And I think, since we have some important EIPs that are dependent on the benchmarking, I think that should be a focus, and I think the benchmarking efforts should still be done on BALDevNet 7. And I think, other EIPs, we can target, bal-devnet 8. And have Glamsterdam DevNet 5 launch date this week, and then BAL DevNet 8 launch date, maybe next week, or the week after. That would be my suggestion.

Barnabas Busa: Can we stop doing both FNETs, and just do the 6 with the ER changes?

Danceratopz: That seems like the other obvious option, what Barnabas just suggested, that we don't try and squeeze in a bal-devnet 8. But we could create about a Glamsterdam DevNet6 spec with all the… finalized EL specs. for when Glamsterdam DevNet 5 is ready with CL stability, I think there was talk… about wanting 2 weeks of a stable DevNet 5. for the CLs, before moving on. So that would mean that… We would have a two-week window to finalize the Glamsterdam DevNet SIG spec, roughly. for the ELs. And the CL will be stabilized, and we don't need to squeeze in an additional bal-devnet 8 in between. How does that sound to you, for example, Stefan?

Stefan Starflinger: I mean, for me, it's, if we don't have a stable, CL site, then I don't think ELs can make progress. That's the thing I'm concerned about. And I think it will slow us down, at the moment, but… yeah. I mean, sounds reasonable still.

Danceratopz: So, with… I think my… my main concern, hearing everyone's opinion, is that if we rush into a bal-devnet 8, then… and start putting focus on that, then we derail a little bit the benchmarking optimizations. Then we start having too many parallel flows, potentially, when essentially there's no huge rush from the CL side. So… my… I'm kind of… it's not my place to decide, but I'm kind of just wondering if it makes sense to… Postpone the decision on bal-devnet 8 until next week at least. Continue the bal-devnet 7 benchmarking. let Glamsterdam DevNet 5, roll out later this week. And then, basically come to a decision in… in ACDT next week. as to whether we target for the EL side, the next DevNet would be either Glamsterdam DevNet 6,

Or… bal-devnet. 8, if there's a holdup on the CL side, for example. I think we still have that freedom. Yep, Tony… Tony states that benchmarking optimizations is better for more AAPs, I think that's in agreement with what Maria said at the beginning of this discussion. I think Shitafan… Finds the idea good. Spencer… says, yeah, optimizations about MS7, of course. And then target the 6 for new EIPs, and… EIP changes. Okay. So I think… I think we can carry on with, Glamsterdam DevNet 5 being a CL-only update.

Stefan Starflinger: So we don't have 7997 in it? Is there a decision there?

Danceratopz: That's a good question. the other option would be 8… I mean, if we open… if we open up that question, then we could also talk about 8246, or even, That'll be…

Barnabas Busa: Should any of the CL devs speak up about 7997? How big of a lift it is. And how many days extra work does it take to do?

Dragan Rakita: This is irregular state transition, basically. It should be few lines. If some… We had it similar with Dow. It shouldn't be that big of a change. It just inserts the bytecode at some specific. address. account.

Ben Adams: Does it add anything? To glance down of that? Versus putting it in with all the other EL changes?

Barnabas Busa: No, that's it.

Stefan Starflinger: I mean, yeah, we can leave it out as well.

Danceratopz: We are coming to the end of the call. I think we can take… Yep. So Mario just brings up the point that instead of 7997, if you put in 8246, It would simplify 7708.

Ben Adams: Are we… are we still talking about the glam stamped up?

Danceratopz: This would be… do we sneak in an EL change onto Glamsterdam DevNet 5, which is primarily for CL stability?

Ben Adams: I'd say no. I don't see what it…

Barnabas Busa: Sometimes the switch.

Danceratopz: And… In terms of attention, I would… lean to perhaps keeping DevNet 5 simple, and then moving the EL changes to the… Next up, but I think we're gonna have to continue this conversation async. Carson?

Carson: Hey, so, Steel Team does have an implementation, and tests for it, that I'm in the middle of reviewing. I should have that done today. So, I do think it's important to get that on a DevNet soon, but I agree, it's a little… a little too undercooked for this one, but I want to target the next one for getting that in, because it will… it will simplify, edge cases for 7708.

Danceratopz: Next question. Stefan is saying let's postpone it. Mario, would you like to speak up?

Mario Vega: Yeah, I just wanted to clarify, I meant, I prioritized self-destruct burn removal over 7997. That's everything I meant. It's not like… if we are not discussing that, I mean, it's fine too, yeah.

Danceratopz: Thanks, Brian. Thanks, everyone. After the call, I will open up, a thread in ETH R&D. And, basically outline what we discussed, for Glamsterdam DevNet 5, and just make sure that we're all on the same page. And if anyone has extremely strong feelings. About including A246, for example. Then they can race up there. So… I think we've got consensus that Tony is also saying that Optimizations take priority, self-destruct takes priority over 7997, and just to be clear, there is an EIP interaction in self-destruct burn, which Carson outlined before, which is why. Mario Antonio making that statement. Okay, I will open up a thread afterwards, and please chime in if you have strong feelings. Otherwise, I think we'd keep Glamsterdam devnet 5

CL only. But we have a couple of days to make a decision. So, let's take it async. Alright, that's it, more or less. I think there are a few other items at the end, but we are over time, so I will leave them. Thank you very much, everyone. And see you next time.

Stefan Starflinger: Thank you.

Dmitrii Shmatko: Thank you, bye.

Toni Wahrstätter: Thank you, bye-bye.

Louis Tsai: Thank you.

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