Execution Layer Meeting 241[2026-07-16] | ACDE 241

Akash Kshirsagar: welcome everybody to All Core Devs execution number twenty two forty-one. So it's July 16th. we have a super short agenda today, I think that we can get through it pretty fast today. the first things first, Stefan, are you here? We'll start with Claire Amsterdam DevNet updates. yeah, sure. So we launched DevNet 7 on Tuesday and we had the gloss fork on Tuesday evening European time. And it was a little bit chaotic in the beginning. We created the network with half a million exited validators to increase the state so that we can better test the new SSC changes. and it showed, but clients were quick to Fix everything up. and then we ended up onboarding nearly all of the clients by now. so right now I'm in the process of adding Grandine and Aragon. I think will be ready tomorrow. we have 3,000 validators with 1k ETH, 1024 ETH each. And I should have increased kind of the deposit queue speed. Because depositing such large validators takes a long time. And so I had to reshuffle the validators a little bit, which took some time. But I think everyone should be weighted equally now on DevNet 7 with 100 validators each. and right now we're running normal spamming scenarios and fuzzing scenarios as well. there are quite a few bugs found on the network. I'm not gonna go over all of them. but I think most of them were pretty small and could be fixed quite quickly, which is very nice. And I think right now we have a very good participation rate of around eighty to ninety percent, which is great on DevNet seven. Great. is there gonna be a devnet 8? Yeah, pretty, pretty sure that that would make sense to have another DevNet since it was quite unstable still. I think one DevNet 8 would make sense, and after that, going for the testnets. I think we also still have the final repricing numbers that are open from the execution side. And there is some cleanup work in the process regarding the EIPs with minor changes to I guess wording and just overall polishing. Okay, great. And we are we are still work waiting on those repricing benchmarks from DevNet 7, correct? I think regarding the benchmarks, there has been some progress but not as fast as I guess the devnets have been have been progressing. So they're still a little bit behind. They're currently working towards or we're currently working towards DevNet six for benchmarking and I think it should be ready quite soon. Gotcha. Okay. do we have any other any other Amsterdam stuff? Anything that clients need to look at, pay attention to, work on? Okay. We're getting close. reminder that once we get test net updates or once we start moving on to test net, there will still be the thirty day security the audit review period and then two weeks before each test net and then thirty day thirty day notice period for the rest of the ecosystem to upgrade. So still a minimum of three months. one thing I'd think might be worth mentioning is that DevNet seven is for and app developers to try out and see the impact for them against the DevNet. So feel free to use the faucet, create contracts and reach out if there's anything you need help with. Is there a resource that they can go to to Figure out how to set that up. Yeah, I can share the Itfano ops network link. Nego, I don't know what you mean by the temporary public testnet. I thought last or like a week ago or something, we talked about something similar to Mekong that we had for Electra. yeah. Or maybe not even three months. It was shorter but it allowed like apps and so on to test. So is that the this version of the is that DevNet 7? As far as I know, I think I agreed with Maria also that DevNet 7 should be the one that developers should try out before we go to the testnets. Okay, but but what do you mean like testness like Cipolia or yeah, yeah. Yeah, because for example for Fusaka we kinda broke a lot of setups 'cause people were not aware of like Supernode changes and like layer twos, right? I was just just thinking if if it makes sense to have a more public network like Mekong. I mean, there's nothing that prevents them from using a death net for that. I'm just not sure that's the venue we wanna use. I don't have a super strong opinion. so far the talks were that we would use DevNet seven. I'm happy to use DevNet seven. I don't think it will be too unstable from my perspective. Nico, is there any other reason why a devnet isn't appropriate for that? I don't see a real reason, I guess. I mean is there like a for set and people can get the Eve and so on? Yeah, everything like that is set up. Yeah, and also what Dustin says, like people just ignore this. It's not really like we have zero actual builders on the Devnet right now. So I mean there's just a lot of surface with glowers and clamster, don't I mean? I I actually wanna add a little I mean to that as well, which is to say even if we can get people to not ignore it, I'm not sure that's a great outcome. so because Netnet pins a very specific spec version in place and and right now, like it has been useful to be able to sort of expeditiously remove older spec version running devnets, like devnet for previously DevNet say five, for example, we we didn't have to keep it running because it was just for for the core devs to test their own implementations. and if we now say, but technically anybody can actually connect to them, that also creates a bit of a social expectation that it will keep running and keep being maintained. And I I think that may be more costly than it's worth. I mean that's kind of the long running thing. That's what test nets are for. And if we create a test net that is short lived, then we have the same problem as well. Right. true. so what I would say is converge to a near at least very, very near final spec first. Like and then so that we don't have that divergence and kind of backporting and and not and worse than that, even so that's one way of framing it is like, well that's more work for core dev, who cares? But it also means you're not testing what's gonna be deployed, which is worse and it's worse for everybody. is there any reason that DevNet eight can't be that middle ground? I am worried that with DevNet 8 we're so close to the test nets already that it would make more sense to go to the test nets. So in my opinion, it wouldn't make sense to give clients or developers, I mean app developers, time now before we move them to the testnet. Okay. in that case, let's just try to publicize DevNet seven as a very short lived temporary place where app developers can test if they don't want to test on Cepolia or Hoodie and break break things on there. because I think that was the concern last time is that they have things running and that testing on there broke things. So if they want to avoid that, they can use DevNet seven. We'll just have to make a concerted effort to actually reach out to app developers and make sure that they're aware of this temporary test net. DevNet testnet thing. Okay. If that is everything else for Amsterdam, anything else? Then I will mention that the community has been having input on the mascot. there was a vote on ETH Magicians, it appeared that the Flamingo won, but there was some consternation about botting and some shared IP addresses. so there's a runoff vote between Flamingo and pandas or polar bears. please please go vote so that there's not drama about this because this just sounds like the yes, the most important topic. This sounds like the the just an absolute we should not spend a bunch of time fighting o over this. So please go vote the here I'll drop the I'll drop the link here. great. And if nothing else for Glamston, we'll move on to Hagoda. Carlos, do you wanna Carlos is gonna propose EIP eight two six eight storage routes in block access lists? Carl Carlos, are you here? yeah. Marius is also not here. I had put that at the end of the agenda, but I guess that makes sense to include. so I So the Marius had an option or an an an addition to the agenda, he would like to take five minutes to r to discuss REST SSE, in particular the missing non-engine methods that are exposed on the engine port. is there anybody who's not me because I don't because I can't speak to this, who could speak to this? If not, I will leave it at the end of the agenda. maybe Marius will show up in the next couple of minutes. Maybe not. He I think he's at an in person event. He basically flagged are other clients if other clients need the same four methods, are there any additional methods that are needed or useful and can we retire the ETH one deposit path? Yes, thank you for putting those there. So if clients could take a look at that, otherwise I will have Marius Ping who is necessary on that. Then in the meantime, I will go back to Hagoda. So just a reminder that the non-headliner closing date is August 6th. that is an ACDC week. So for execution layer proposals, just PR your EIP against the Hagoda meta EIP, that's 8081. by August 6th. And if you have proposed it, if you have PR'd it into the meta by August 6th, feel free to propose it on the next call, which is seven days later. And then that'll can be considered in time. And I just wanted to remind people that the status of the Hagoda headliners is that Fossil is the headliner. There was a question of frame transaction or native account abstraction. And I just wanted to remind people because people forget like what the outcome of things were. we CFID frame transaction as a placeholder for native account abstraction, assuming that the people who are working on those different implementations of native account abstraction would work on converging upon some some sort of consensus for native account abstraction. So native account abstraction is CFI'd for it. It is not necessarily a headliner, which means that we wouldn't wait for it. We left it open to possibly propose it as a headliner. After we close the non-headlining EIPs, we will have another conversation about that. about the status of getting consensus around native account abstraction. okay. I think Carlos still isn't here. he PFI'd eight two six eight storage roots in block access lists. I will ask if he wants to propose that at the next if he wants to present something in the next ACDE. Otherwise I will just consider this a notification that it is being PFI'd. And then the last item on the agenda is the some housekeeping from Pooja. Pooja, do you want a couple of minutes? Yes, I would love that. Thank you so much, Nexo. And hello everyone. I'm back with some of the housekeeping agenda item. I'm quickly going to share my screen so we can go through them. So, this is a list of Clamsterdam EIP, which should be promoted to review status, as per my understanding. We have shared this in the previous meeting as well. We have received approval from multiple authors, and those PRs have been closed. Thank you for approving it and moving the proposal to the review status. But the there are still seven EIPs which are still open. Some of them have already received approval, but it is dependent on other. EIPs and that's why it is not being merged. So if you see your name here, kindly go ahead and take a look at the PR and if find appropriate, please do approve it so we can promote the EIP. Next thing here is about DevNet 7 and the Glamsterdam SFI stage. So I made an assumption that if proposals are in the Glamsterdam DevNet 7, then it should be moved to SFI, my bad and Thanks Joacham, it has been corrected right now. But at this point, I would like to quickly check with the testing team and client team. Are they comfortable enough to move all these EIPs to SFI stage, assuming that these EIPs are more stable? To give some context for people to understand how this is being considered, we we have tried to, I mean, I have tried to put it together this list based on my understanding. So if we are in upgrade DevNet, almost close to public testnet. So when we move into public testnet, it will be in the last call. So if we are in upgrade devnet, I believe all the proposals should be in the review and SFI stage. so if you find this is the right time, can we have some confirmation from testing team on that? Or if there is a recommendation, we should still wait. I'm open to the idea. I think the process is now that there are four milestones to hit for EIPs to be moved to SFI and the ACDT will determine when those are met and then just ratify it on A C D E or A C D, A C D C or A C D E. so as long as those four milestones are hit for those EIPs, I think it's it's fine to move those. And those are all laid out in 7723. All right. but just for clarification purposes, do we need to wait for another ACDT call to get it ratified there or should we come back on the next ACDE call to like confirm that they are ready to move in SFI stage? I don't think we need to like ratify it on ACDT, but I think it's the testing team that should be initiating that. Initiating the stat stage change, you mean? Like creating the PR? yeah, as long as you flag with one of the testing teams that all of those four things have been hit, I think that it is fine to say FYI, the testing teams have have determined that these four things have been met and we're moving them to SFI. Sounds good to me. I will go back and take a look at it and maybe come back to the ACD channel to confirm that with the testing day. Apart from that, there are a couple of open PRs. I think one is open PR. If authors may get a chance, please take a look. I feel like the status and stage confusion should not be there. This PR is still open. Please take a look, add your feedback. If this is not appropriate and something missing, we can take a look at it. And the final one was there is one PR which was there to add BPO folder, but it was closed. I'm not sure if it is by mistake or is there a reasoning for that, but I'm happy to accept the feedback on the PR itself. And that's pretty much it from my end. Thank you so much for the opportunity. Yep. Thank you, Petra. anything else? If not, this could go down as the shortest A C D E. Possibly ever. anybody got anything else? Glamsterdam, Hagoda, anything else? Perfect. Let's go get Glamsterdam out. Thank you, everyone.