All Core Devs - Testing #74
All Core Devs - Testing · 16 Mar 2026 · 26:47
Client teams, testers and devnet operators meet on the All Core Devs Testing call to check test coverage and devnet progress for upcoming Ethereum upgrades. Decisions about scheduling EIPs for inclusion remain with the All Core Devs call, not the testing call, and EIPs for bal-devnet-3 become eligible one week after stability is demonstrated.
Speakers
Topics
From All Core Devs - Testing, hosted by Ethereum Foundation.
Transcript
Spencer Taylor-Brown: Nope.
Parithosh Jayanthi: Hello, everyone. Let's give people another minute to join, and then we can start off.
Okay, let's get started. First on the agenda item is, how we're gonna structure the call today. So we're gonna do our usual updates, as well as going through any immediate blockers, as long as they're shared blockers. Once that's done, we're gonna experiment with breakout rooms today, so we're going to split the call into two breakout rooms, block-level access lists and ePBS. I'm choosing the option to self-select, so each person can choose which breakout room they're gonna go to. This might be exclusionary for some people who do want to be in both breakout rooms. The rooms themselves won't be recorded, so for now, we're going to have to just experiment with this approach, and in the future, we can still see how to merge it better. The breakout room approach is also
Temporary, as in we're not fixing these as the two breakout rooms, but instead, on a week-by-week basis, we can decide what are the most valuable breakout rooms to choose, and who's going to lead them. That being said, let's, start off with the usual bits. Devnet updates for block-level access lists, do we have… sorry, for blob-devnet-0, do we have Barnabas?
Barnabas Busa: Yeah, blob-devnet-0 has been seen some issues in the past week. I'm not sure if we have anyone from Prysm here that could, speak up regarding the Prysm bugs that, For the… regarding the partial cell stuff. Other than that, the spec is finally… Pretty much firms, so everyone should be able to implement, Everything that they need for partial size stuff. If you have updated your partial self, self, logic, then please let me know, and I can, add you to develop the list on blob-devnet-0.
Parithosh Jayanthi: Is there a rollout plan for this one? I know that there was some talk about deploying it on testnets.
Barnabas Busa: Yeah, so ideally, we can start deploying it on testnets once, the clients feel very optimistic about it. Right now, we… the alternative would be to launch a very big network, but, realistically, we're not gonna be able to see, The network effect of… Of this change, unless we do, like, another 1,000-node network or something like that. So, I think, what, we were thinking is a few validators will, have it enabled on, on Sepolia, and on Hudi, and then on Hudi, we can investigate further if… in case we do see some kind of clustering. And, once we are confident, then, Clients can decide to, have it, default enabled in their, in their logic.
Parithosh Jayanthi: Okay, sounds good. Next on the list is block-level access list, devnet 2, as well as, any blockers for benchmarking. Either Stefan or Tuni, whoever wants to go?
Stefan Starflinger: Yeah, I can start quickly on just a general update. So, we finally have reached pretty much 100% participation on devnet 2. Erigon has implemented and fixed the issue today regarding proposals, so not… a few blocks get proposed, but most blocks now get proposed by all the clients. There are still some small improvements that can be made in general. For example, I reported one issue to Besu, where sometimes when it falls behind syncing, for some reason, it has a little bit of trouble catching up. But otherwise, I think we are at a good place with devnet 2 at the moment, which is great. But just, the next thing would be the benchmarking, and it would be great to get an update on how far clients are that haven't added the benchmarking flags.
And if any clients have maybe also iterated on any of the benchmarking code that they have, maybe we could get an update from the clients that don't have the flags yet, Nethermind. Or Erigon, or Reth. That would be great. Maybe start with Nethermind.
Marc Harvey-Hill: Yeah, there's good progress on the parallel execution. It seems to be running, like, pretty stable in the devnet, like, it worked for about 12 hours, but then it broke, so… I'm just gonna, investigate that a bit more, and then hopefully we can get that merged soon. And I think Alexi's still investigating on the, parallel, state, ex… Sorry, a parallel, state loading. Yeah.
Stefan Starflinger: Yeah, I mean, we can also do that in the breakout call, would also make sense. And what Barnabas said. But I think that's then pretty much it, unless someone else has something regarding devnet 2.
Parithosh Jayanthi: Yeah, I think we'd structure it such that general updates can happen in the main call, but if there's anything specific to dive deep into, then that can happen in the breakout rooms. So yeah, it would still be interesting to get an update from, from the other ELs as to where they are.
Stefan Starflinger: Then can we continue with Reth quickly?
emma: Hey, I just joined… late. What are we discussing? Sorry.
Stefan Starflinger: Just the flags on the benchmarking, so the flag to toggle the prefetching, the flag to enable all the optimizations, and the flag to disable all the optimization regarding parallel processing and prefetching state and state root calculation.
emma: I think we have all three flags on our devnet 2 and devnet 3. Brunch.
Stefan Starflinger: Okay, could you, could you share all of the configuration? Because so far, I think I only have one of them.
emma: Yeah, I'll ping it through in the chat. No worries.
Stefan Starflinger: Thank you, and Erigon would be great, if you have any update on that.
Andrew Ashikhmin: Right, so, yeah, we are working on, We are finishing parallel execution, I'll check about the flags, So… I see that, where are they spec'd? On the bal-devnet-3 page. I see some flags for Basil…
Stefan Starflinger: Yeah, both. bal-devnet-2 and bal-devnet-3, but bal-devnet-3 is not ready yet, so it's good to have it on 2 right now, so that we can continue the progress on the gas repricing.
Andrew Ashikhmin: Alright, okay, yeah, I'll check the implementation status, and if they are not implemented, I'll try to add them. soonish.
Stefan Starflinger: Okay, super. I think that's it for devnet 2, otherwise we can move to devnet 3, if there's nothing.
Parithosh Jayanthi: Let's move to that 3, then. What's the blocker or timeline there? I know that Tony shared an agenda, so maybe besides those discussion points, if there's any blockers?
Stefan Starflinger: Yeah, maybe I can give a quick overview. I've been doing some testing, regarding devnet 3 and, In a single testnet, most of the clients are doing pretty well with just normal transactions, but as soon as I start with EVM fuzzing scenario, it breaks apart pretty quickly, maybe… Some updates from the client teams and testing would be great.
Parithosh Jayanthi: Have you already shared all the issues with the client teams? Are there anything in specific you want to dig into?
Stefan Starflinger: It's quite general still, so… There's nothing in particular right now, that I would want to share at the moment. Okay, so…
Parithosh Jayanthi: So it sounds like we're still going to continue fuzzing locally. We'll probably have some minor spec change before we do a devnet launch, right?
Stefan Starflinger: Yeah, we will… I think, talk about it more in the breakout call. I think it's… yeah, I think we should… Not go into too much detail here now.
Parithosh Jayanthi: Okay, yeah, drawback?
Dragan Rakita: I just mentioned that Friday I found some existing inspectors that needs to be fixed. And I think the test feature was just created a few times previous week, so I don't think that anybody's passing them. So there is still, like, work that needs to be done.
Parithosh Jayanthi: Okay, cool, thank you. Anything else for bal-devnet-3? Okay, I did want to announce that, Justin's made a release on the consensus specs for V170Alpha 3. And to continue that point, do we want to get some updates on epbs-devnet-0, as well as where Alpha 3 will be used?
Barnabas Busa: Yeah, I can give a quick update. So, we currently have Prysm, Lighthouse, and also working, correctly on the devnet. We have Nimbus proposing blocks here and there. It's not completely working yet. And, Teku has not been able to sync or propose at all yet. local groups that also weren't able to work with Teku. we added Checkpoint Sync… we added Lodestar to the Checkpoint Sync instance last week, and that seemed to have broken some stuff, so we now reverted back into only using Prysm. And, Yeah, I tested exits last week, and deposits, deposits worked, exits do not work yet. I can run another round, Later today, to see if there has been any changes that, Would make sure that we can do the exits as well.
Parithosh Jayanthi: Sounds good. To carry on there, I also posted a message about disabling block production and then re-enabling it, and that's also leading to some Some issues with the network, healing afterwards, but yeah, I guess there's still a lot of fixes for epbs-devnet-0 before we go to devnet 1, right? And I guess Alpha 3 will be what we use for devnet 1?
Barnabas Busa: Yes, most likely.
Potuz: Don't we want the PTC… I mean, we've discussed this in the breakout, but I think we want the PTC loop behind, or look ahead, one way of it, for the next advent.
Parithosh Jayanthi: Okay, so there's probably going to be another release, before that. Okay. Cool. The next point on the agenda was, update from the gas repricing, effort. Do we have any more insight into numbers, where we are in terms of getting them, and when we want to sequence these into devnets? Okay, I think the relevant people might just not be here today. Okay, we can do that on async. There was maybe one other agenda item before we switch to breakout rooms. The item was from Spencer talking about, SFI and EIPs. Spencer, do you want to first bring up the point, and then I think Tony and I had some follow-up points over there?
Spencer Taylor-Brown: Yeah, sure. I guess, just some context, so… And personally, I would, like. us to SFI EIPs a bit faster, Kind of aligning more with the network upgrades. Including EIP, so EIP7723. And selfishly, on the steel side on eels, we only include EIPs, or we only merge EIPs into our main… Our main branch, Forks Amsterdam, wants to recified. it's a process that we like to keep, but we can also change that. But, I guess right now. For Amsterdam, we've been having, like, a lot of, a lot of issues with, consistently having to have all these, conflicts between EIPs when creating the devnet branches, because we don't… yet have these EIPs specified, so we can't merge them in earlier into our works Amsterdam.
branch. So that's the kind of the selfish side. From steel. I guess the other benefit of SFI earlier is the downstream effects it would have. For the community. And… but yeah, I guess, the main reason I brought this up is because… In the network upgrade EIP, 7723, we staked When client teams agree to implement a core EIP in the next upgrade devnet, the EIP should move to The SFI stage and the upgrade EIP should be updated to reflect this. We also state, SFI signals that implementation and testing work are underway. the EIP should be included in the network upgrades if no issues arise. Now, I know, like, the key word here is should, doesn't say must.
But my gut feeling is that should apply to the majority of EIPs, and then the must should, I guess, negate that. So, my feeling is that maybe, like, 70-80% of the EIPs should She'd follow this, And I, yeah, I do… I do… I don't think it's the best idea to just say the EIP has been added to a devnet, therefore we must SFI it. I think we could maybe change the terminology a bit to state that, EIPs can be SFI'd once it's successful in a devnet. So, for example, all the EIPs that have been successful on devnet 2, I feel like she'd be SFI'd by now, But yeah, I guess I just wanted to bring this up as a general process question.
Parithosh Jayanthi: Yeah, maybe, sharing… I already posted my thoughts on the, on the topic in the issue as well, but, thanks for the context, I think that helps a ton. Probably… The biggest fear for me is that we SFI something. It has a relation with another EIP that we only haven't included in a devnet. Because of differing complexity, and then… we have to kind of backtrack the SFI-ing, if we SFI too early. There's probably a middle path over there where if an EIP doesn't have any interactions with other EIPs, or any foreseeable interactions with other EIPs, as well as is deemed well implemented and testing coverage is good, then we can SSI it. But at least from my perspective, I think this makes more sense to do one ACD rather than ACDT until ACD explicitly says ACDT can take a call on this.
Yeah, that was, I guess, high-level thoughts, but… yeah, open to other opinions or decisions. Do we want to SFI stuff on this call, or do we want to defer that to ACD? Yeah, Tony?
Toni Wahrstätter: Yeah, I agree with you. I think we should do that on ACD. And… Yeah, so far, there haven't been many definites, so not many EAPs were already on devnets, but maybe this week on ACD, we can already take a decision on a few of them that were already on a devnet. Two, and that don't interact with, many other EIPs, and we can already SFI them. Especially, like Spencer said, to give the community, like, more certainty about what is going to… Ship, or whatnot.
Parithosh Jayanthi: Yeah, that makes sense. I think the list that Spencer shared already makes sense. I think he also has a PR to update them, right? Yes, he does. So, in general, is anyone opposed to Spencer presenting this list on Thursday, and then getting ACD's approval for SFI?
Spencer Taylor-Brown: And note, this list contains all the EIPs in devnet 3, so… I think we might need to filter it down.
Parithosh Jayanthi: Sorry, okay. I guess you can post a list on ETH R&D and then solicit feedback there?
Spencer Taylor-Brown: Sure, sure, sounds good.
Toni Wahrstätter: And we could also… we could start with only the EIPs from devnet 2, Because we don't even know if they work yet, we haven't launched devnet 3 yet, so maybe it would make sense to do that, like… One after another. But I have no strong opinion on that.
Spencer Taylor-Brown: I guess, like, the main reason I brought this up was not necessarily to SFI the EIPs, but, like, should we change what we state in the network upgrade inclusion EIP to, kind of. Align more with, a slightly different process of, like, okay, the… the EIPs in the previous devnet were stable, we should SFI them Assuming that, yeah, there's no future conflicts with other EIPs that we may see in the future. I guess, like, that's… That was kind of the main question. I don't want to take up too much more time here.
Parithosh Jayanthi: Yeah, maybe vulnerables for last points, and then we can move on.
Barnabas Busa: Yeah, just one point that, for example, EIP-7637, the state creation gas cost increase, the IP, is not really finalized yet, so I would actually make sure that We're not gonna SFI a half-complete EIP, because, yeah, right now it's just using some hard-coded version for devnet 3. So, I would not feel comfortable specifying that EIP in that… its current form. So, unless we're actually gonna be doing the seed creation gas cost increase properly, I would keep that away from the list, even if we do end up including it in the mystery.
Parithosh Jayanthi: Yeah, for sure. I think the same should apply for us putting in a change that requires a repricing later on. I think we should SSI EIPs That we just see having very few interactions, and has already been tested adequately, and has implementation that's already in the final stage. Okay, cool. That's, I think, everything on the agenda. Are there any other topics people wanted to bring up before we head to breakout rooms? Okay, if that's the case, I will… Create the rooms now. Please note that the rooms won't be recorded, at least not right now. There also won't be a transcript, so if you're participating in one of the two rooms and make, make notes, please do post them on EthR&D so that we can, collect them later on.
And yes. You should be able to choose a breakout room now.
Toni Wahrstätter: Is it only me, or is this… button I should click, like, outside my window, I can't click it.
Stefan Starflinger: I can't even see one.
Toni Wahrstätter: It's amazing.
Karim Taam: students.
Parithosh Jayanthi: Is no one able to see the results?
Milos: And it should give a pop-up.
Parithosh Jayanthi: Yeah. There's people joining the rooms.
Stefan Starflinger: Where should we see them?
Pooja Ranjan: Click on More, and then you will see breakout room in progress.
Parithosh Jayanthi: Thanks. Okay, let me just manually assign you, if I can, Rakan.
Dragan Rakita: Appreciate it. Shit, no.
Transcript adapted from ethereum/pm, CC BY-SA 3.0.