All Core Devs - Testing #101

Transcript

Danceratopz: Good morning, good morning. Can you hear me alright?

Mario Vega: Yes, we can hear…

Danceratopz: Nice. Thanks, Mario.

Barnabas Busa: Northern.

Danceratopz: Good morning, Justin.

Justin Traglia: Good morning, guys. How's it going?

Danceratopz: Good, thanks. I just wanted to give you a quick heads up that I've moved the builder and Validator deposits up to the main section. I hope that's okay for you.

Justin Traglia: Yep, that's fine. I'll be ready.

Danceratopz: Awesome, thanks. I think it's just that Mario also mentioned it, I think it's important that it's discussed amongst everyone, or that everyone's aware of it, at least.

Justin Traglia: Yep, that makes sense.

Danceratopz: Awesome, thank you. Good morning, everyone. As usual, I thought it was going to be a really short agenda with not much in it. But it seems to have got quite busy quite quickly.

Good morning, everyone. We'll just give it one more minute. To let more people roll in. Okay. Thanks for the heads up on this, on this, yeah. I think it's mainly an EL topic, but we'll see. Okay. Good morning, everyone. We have more than 40 people. Let's make a stop. So, good morning, everyone, and welcome to ACDT number 101. It's… the 19th of October in 2026. I'm just dropping the agenda in the chat. We've got, quite a packed agenda today.

So, mainly… a Hoodi readiness check, and a devnet check, and then we've got a couple of decisions to make. for devnets for Hegota, let's get into it. So… First up, let's talk about the… Glamsterdam networks. So… Sepolia forked on October 6th, looking pretty healthy. Is there anything scheduled and upcoming the client team should know about at ShadowForks? Would someone from… EthPandaOps would like to give an update there.

Barnabas Busa: So, last week we have, run devnet-12. Devnet-12 was testing the builder deposits, excessive amount of builder deposits at the fork transition. We had, I think over 30,000 deposits, and 5,000 invalid, builder deposits in the middle of it, and all the clients were able to handle it, Pretty okay during the fork transition. I think that was the only one struggling a little bit, and everyone else, I was doing just fine. So, basically, the cache, the cache of the, Of the desert deposits were working for all the clients, so that's good. Glamsterdam devnet 8 is still going, We're doing some basic load on the network right now. We have a few validators of time, but nothing significant.

virtually.

Danceratopz: Awesome. Thanks, Barnabas. Any questions or concerns from client teams? Anything they want to raise here?

Barnabas Busa: So one thing that we're probably going to be doing is a Hoodi shadow fork as soon as all the clients have, have their releases out. We just want to make sure that it's gonna be a very short effort, which is gonna make sure that everything is working as expected. So… you know, push your… push your releases out, so we can get that tested ASAP.

Danceratopz: Awesome. Thank you, Barnabas. We'll, jump to Hoodi releases in a second. If anyone has anything… any questions, please jump in or raise them in the chat. Barnabas… raised… so I wanted to talk about some BPO stuff, and Barnabas raised that we should do it in the… In the general section altogether, it's more of a heads up, really, and a quick question, but just to raise awareness, I'll just drop it here, otherwise I'll forget. So this is mainly an EL concern. It's mainly about how we name and test BPO and forks on the EL layer from execution specs. So we have tests that, are transition tests, for example, that… Change the blob schedule, across a fork transition.

And currently, they're named, BPO3 and BPO4. And as these are test fork names, that's rather inconvenient, because when we do do a BPO3 at some point in the future, we'll have to rename them. And at the moment, these, schedules also transition from BPO to live on Mainnet. So we have to move these, test forks to… or we should move them to Amsterdam. And as we do that, we could rename them to give them more logical names. So, 4 EL clients don't need changes for this? You… we can name these, blobs how we want. But Besu, Geth, Gaff, and Nimbus will need some updates, so I just pushed some draft PRs. Please have a look. As when we make the change on our side, then it will change. It'll break your tests, it'll fail tests. So if you have any…

questions, please… or, like, if you have any ideas about letter names, for example, please just comment on the PR above in the comment. Otherwise… Are there any comments on that? It's more of a heads up. Barnabas?

Barnabas Busa: Yeah, so I also just want to make sure that we are all on the same page regarding the BPO values being set if we trigger shorter slots. So, the same way as we, you know, be doing the, gas limit, I think we should be automatically, scheduling the new BPO with the Heze fork. So, we have the constant throughput of number of blobs per second, instead of, Instead of keeping it to 15 and 21. The same way we're gonna be, scaling down the gas limit as well. To have a… Automatically set gas limit, basically, if we lower the slot time.

Danceratopz: Okay, so I think one part of that is… More relevant for the… That heze-devnet discussion that we're gonna have in a minute. Whether we should try and align that right now, for Amsterdam testing, for, with how it could look in Heze, I'm not sure. I would tend to leave it as is. Until that's fixed. Again, this is just talking about Glamsterdam testing. A quick question to client developers. we could just simply move these tests to Amsterdam, but we could maintain tests from BPO2 to BPO3. And, as I mentioned. These… I think these pull, pull requests was handled all that, and the other clients don't need any changes. If you feel strongly that that's not necessary, then, please let me know.

You can, contact me async, or speak up now. Okay, so I definitely don't want to take up too much time with that. Let's move on to a point raised by Justin. For separating builder and validator deposits, and… how we could potentially change that for Glamsterdam.

Justin Traglia: Yeah, hi there. Yeah, I'd like to revisit a topic from ACDC last week. Lido and other distributed Validator systems notice that the builder onboarding logic complicates things for them. In the current logic, a bad actor could redirect validator deposits to a builder which the attacker controls. And their smart contracts wouldn't really be able to detect this. So, all of the distributed Validator systems would need to do one of the following, update their contracts to handle this situation, which is complex. Disable deposits during the, like, 20 days leading up to the upgrade, however long the pending deposit queue is then. Or monitor pending deposits and pause them if they detect an attack. My opinions on this matter has changed a bit, and I believe it would be easier for us, the consensus layer.

To, change this. I don't believe that this should delay the mainnet upgrade. It's fairly simple, and We'd make this after Hoodi upgrades. And we would test it with a short-lived devnet, like we did with devnet 12. like… Yeah, I'm curious to hear what other… still clients think, and I'm wondering if I could change your opinion on it. I was against it previously. Dustin, you're saying we should replay the Pectra disaster. What is that exactly? I forget.

Dustin Brody: I'm… I… what I'm saying is that these kind of late-breaking changes are precise… the specific method is different, because, sure, we're talking about some different protocol ones than a couple years ago. But, let's, let's, let's, you know, let's have our vanity system, contract process. Great. Oops. Like, no.

Justin Traglia: Okay.

Potuz: That went well. I am against this. I'm strongly against this. I think… I wouldn't personally mind if we do implement this. that we delay Hoodi, and we delay mainnet, and we spend time studying this fix. There's no simple fix, and no one will ever convince me that there is a simple Consensus-breaking fix. All of these changes that we're seeing, all of them, like, absolutely all of the bugs that we're seeing, that they keep appearing, very dangerous bugs on the spec, and we keep making consensus-breaking changes As we are already forged one of the chestnuts. they all are downstream from one of the changes that we said. It was an easy change and would come in the late stages of making ePBS. We removed the builders from the Validator set.

And everything else, everything that came, came from handling of deposits because of this. I just don't trust The fact that most people have not looked into this attack, and most people have not, have not, studied what are the possible implications for the changes in the fork. I would feel much, much better if either we don't implement this, and we let Lido or whomever is affected, handle this with their mitigation strategy, or if we do accept that we're gonna make this Consensus-breaking change, we cancel Hoodi right now, and we agree on delaying everything until we are sure that this is safe. I strongly believe this, and I believe that many are… agree with me and just are not voicing it.

Justin Traglia: Potuz, have you looked at the change? Like, it's fairly simple, and really, this came apart… sorry, this happened because of EIP8282. I mean, it was just the logic we had for 8282, and we didn't update it for 8282.

Potuz: I did look at the change, and I also have looked at many, many changes that came before, and we still are seeing double spending attacks, we're seeing, griefing attacks, we're seeing bad handling of slashings. And we're seeing lots of things that we thought were very simple changes. I just don't think that I can trust myself on quickly looking at something without spending days thinking about this.

Justin Traglia: I mean, are you against fixing bugs when we find them?

Potuz: No, I'm not. I'm just against fixing them and quickly shipping testnets and mainnets. Without really thinking about what are the fixes that we're changing. I don't mind fixing this. I do mind fixing this and keeping the deadlines that were set for Hoodi and mainnet. If we are going to keep the deadlines, then I'd say we don't fix this.

Justin Traglia: Yeah, I mean, I'm strongly against moving the deadlines, so… If clients don't feel comfortable doing this. without moving the deadlines, I guess they're just strongly against making this change.

Dima Gusakov: But by how much do we need to move the deadlines, though?

Matthew Keil: Like, we should probably do a devnet, and then before we do Hoodi… So, if it takes a couple weeks in order to do a devnet. That would push back Hoodi a few weeks. And then we get into Devcon for scheduling the mainnet, which means it probably pushes mainnet. Past the first of the year, which is not great.

Dima Gusakov: But would it require, like, several weeks of devnets? It's just one thing that we need to test on the transition. Because, like, I mean, I'm not… I'm not trying to pretend that…

Matthew Keil: There's no such thing.

Dima Gusakov: Give me a second, Matthew. Like, we are talking about, like, function that will be called exactly one time. During the hard fork, meaning that testing it basically means that unless we want to run multiple devnets, which I'm not convinced we should. like, a single devnet would require us to have, like, I don't know, 3, 4 days for this devnet maximum, provided that we let it start, then we add, some pending deposits. Like, with all of the I don't know, safety intervals added. It's, like, one devnet, I don't know, 2, 3, 4 days maximum. And that is it, because we really need to change… to check one thing that will be used exactly once on the hard fork, so if hard fork passes, network finalizes.

And we ensure that before the hard fork, we had enough pending deposits with, like, different types, conditions, and stuff like that within the queue, then we see that the queue has been processed correctly by all of the clients, and that is it. That's the testing.

Potuz: No, no, no, that's not it. This is not about testing. This is about verifying that changing the spec does not come with downstream effects in the spec itself. This is not about, like, having 2 or 3 days on a devnet or not. This is really about, like, having people studying this, and not trusting that Claude has thought about this and told me that there's no other spec effects.

Dima Gusakov: Yeah, but Juu B.

Potuz: itself needs to be vouched, and that.

Dima Gusakov: I…

Potuz: I understand that. Actually thinking about this.

Dima Gusakov: I understand that Potuz, but, like, have you actually looked at the fix? Like, again, it's literally a change to a one-time call function. That's what I'm trying to understand. Like, I understand that in general, you are absolutely right, no questions asked. Like, this particular change is about a pretty unique thing, which is a one-time call function. And this is what concerns me, like, when you are saying that it requires a shit ton of work. I mean, I came from the QA background on testing, like, mission-critical databases on Russian banks. I'm sorry for sharing that. And I… like, if it's a one-time call function, then, well, you need to… Test this one-time call function.

Matthew Keil: You know, and I tend to… I don't even think the… what Potuz is saying, while I don't discount it, is really even the part that… I think I take an exception to, it's that Devcon, like, the Devcon schedule, the holiday schedule, and a lot of the other logistical pieces are the parts that I think are the biggest concern. And really, that's the part, like, if we cancel Hoodi. and do some kind of, you know, at least some kind of testing on it, even if it only takes 3 or 4 days. Just the fact that Devcon is in the mix there, it pushes the Hoodi schedule out. And then, because of the holidays, that pushes dev… like, the mainnet out, and it's literally just a… to me, it's just a scheduling issue that becomes very, very, very difficult to handle without pushing out mainnet because of the holidays.

Probably a couple of weeks or a month. And I… you know, even if we only delay a couple of days now, just because of its… you know, it's like a knee-jerk, like, turn, because we have our release out that already schedules Hoodi. Do you know what I'm saying? So, like, that is… like, we'd have to re-release unscheduling Hoodi, and I think there's risk there that, you know, that some clients might fork. I mean, it's just… it's nuanced. But I do appreciate the fact that it's… it is kind of a tough situation.

Danceratopz: Thanks, everyone, for chiming in. There does seem to be a unanimous pushback from client teams across, like, against the delay, and including this, because it seems like it's far too late to include this Hoodi. Before we… Before we, draw a conclusion to this, though, could… Justin, would you mind just sort of weighing in the gravity of this Bug that's existing and what we're trying to fix against a delay.

Justin Traglia: I mean, it's not worth… delaying anything, in my opinion. It is a hypothetical attack, and it does complicate things for systems like Lido. I mean, I would prefer we just fix it real quick, but this doesn't seem practical, I guess.

Danceratopz: Yeah, it's not worth it.

Justin Traglia: Delaying anything.

Danceratopz: Okay. Thank you, Justin. So, from what I can tell, Lodestar, Matt spoke up from Lodestar and pushed back, Potuz obviously against it. Dustin from Nimbus and Eitan from Lighthouse have all pushed back against delaying anything, which would be absolutely necessary if we include this. So, unless I'm missing something, I think it's… Clearly, rough consensus that, we should… should not include this fix.

Justin Traglia: Yep, that sounds fine. Let's move on.

Danceratopz: Okay. Thanks everyone for the discussion. Moving on to Hoodi in that case, since we're on topic. Hoodi is scheduled for next Monday. on October 26th, after ACDT. The gas limit will be 200 million at the fork. I think we need to do… a quick round on client releases. This is what I could find quickly. In the chat, I think a few releases are missing. Would the client's… Who are missing release mind chiming in and saying when they could expect a release landing? I think Erigon's missing one…

Andrew Ashikhmin: Yeah, we expect a release, either tonight or tomorrow morning.

Danceratopz: Okay, perfect. Thank you. Okay. Yeah, we'll… thank you, Dustin, for the comment in the chat. We'll, We'll make sure that blog is updated. Barnabas, did… can you update the blog for anything that's… I believe that ethrex also has a release with Hoodi config in now, is that right, ethrex?

Barnabas Busa: Yeah, we can… we can keep it updated, true.

Danceratopz: Thanks. Is someone from ethrex here? Could confirm that V30 has already come back in it.

Iván | ethrex: Thanks, Dan. Yeah, v30 is the one that replaces the… are seeing tools.

Danceratopz: Perfect. I think that's all for client releases. I believe there was some chatter about… builder configuration, potentially on Teku, that was not updated for Sepolia. Is everyone aware and ready to… do they have their configs updated? I guess this is a configuration issue for the network, right? Could anyone speak up to that?

Dmitrii Shmatko: I think I'm from Teku. I think we have updated it today.

Danceratopz: Amazing. Thank you. Is there anything else that we need to… are there any other T's that we need to cross or I's we need to dot before Hoodi to make sure that… everything is plain sailing, bearing in mind that ACD will be a bit late next week.

Barnabas Busa: What is the BAL retention question? I'm not sure… I'm just not sure if you want that for, for Hoodi as well.

Danceratopz: Okay, well, let's park that for a minute, we're gonna get to BAL retention in a minute. And then we can just decide. If that's good. gonna be changed for Hoodi. Anything else that needs to be done for Hoodi that the pandas can think of? Otherwise, if client teams have any concerns, please voice them now. Do we need circuit breakers in all CLs, for example? Okay, then… I presume that everything is clear, otherwise we can clarify things async or an ACDE on Thursday. So we can move on to the point from Toni about… BAL retention.

Toni, would you like to… Speak up to that, and…

Toni Wahrstätter: Yeah, I bet.

Danceratopz: by what the… I'm just going to drop the current status as I can determine in the chat, so we can go through the clients.

Toni Wahrstätter: Sounds good. Can you hear me, Dan?

Danceratopz: Yup, I can hear you.

Toni Wahrstätter: Perfect. Yeah, this is a PR from Nico. It's a few weeks old now, and by the time we discussed increasing the BAL retention window from 3,533 epochs. to the value provided by the CL, which was, 14K, I think 14… 1,299 or something? And… Nico's PR implements that, and I saw that most of the clients are already on that, some have already merged their PRs, others have, prepared PRs that are still open. And, yeah, I would… after the call, I would merge this in. And I would then ask clients to also comply. Yeah, it would be… actually, it would be helpful to… to, check with the clients if everyone, has

is ready for that, because Geth doesn't need anything. I think Besu, in the meantime, created a PR and merged it already. Is someone from Besu here that can double, confirm that?

Justin Florentine: We'll have to get back to you on that. Yes, I'm here, but I'm unfamiliar, I'll go check.

Toni Wahrstätter: Okay. What about the other clients? Nethermind, Reth, Erigon, Nimbus EL?

Dustin Brody: You have a PR, I guess you've seen that, right?

Toni Wahrstätter: Yeah.

Dustin Brody: I was personally not 100% sure on the status of… I mean, we're happy to merge this, obviously, if that's where the spec goes. I… I haven't, been 100% certain whether that's where the spec is going, but sure, we'll… Practice back either way.

Toni Wahrstätter: Perfect. Yeah, and if, I would love if Nethermind could, double-check if they have a PR ready for that, same for ethrex and Reth in this case. For Erigon, I think there was a PR, I'm not sure, if the other clients had a PR for that already.

Łukasz Rozmej: I think we do, and it's even merged, but I need to confirm with Mark, because it's his PR, I haven't even… I just… I haven't even seen it. Yeah, so I need to confirm, but if it's… if we don't, it should be extremely easy to… to change. I think it's just a configuration value.

Danceratopz: Yeah, thanks, Łukasz, it looks like it's merged. I just checked. So, in the chat… Maybe…

Toni Wahrstätter: Yeah, Nico is saying he opened an issue at all the clients in the chat, and I think this is then finally resolving the topic of blinding the BAL on the CL side, so CLs can proceed with blinding BALs, and will still be able to fulfill requests that are… ForK old plugs.

Nixo: Dan, we can no longer hear you.

Nico Flaig: Just to Toni's comment, so there was one left over, I guess, which is during non-finality. So right now, the period is long enough that it's really unreachable, but if we reduce the retention further. then it could become an issue if CL clients dedupe unfinaled data, because it could be that the EL prunes their side of the data, and the payloads become no longer servable over P2P. But I don't think it's a big concern right now, and for example, Lodestar doesn't dedupe non-finalized data, so for us, it's not a big deal. I'm not sure about other clients.

Danceratopz: Hello, everyone, sorry about that, I'm back. Yes, Potuz?

Potuz: Yeah, so what Nico's saying is true, it's just that I'm not really sure if it's easy for us. We… we… we blind everything as soon as we put on GP. It's not clear to me how easy it would be to To wait until we are finalizing. We do migrate to code on finalization, so in principle it's doable, but… but I don't think it's an easy change.

Toni Wahrstätter: Yeah, to me, it feels like, Potuz, it's almost like if what you guys are doing on the EL is already fine, and it would actually need a change on the EL to be aware of when we are going into a period of non-finality, and then the EL would actually need to keep more in order to allow the EL to directly blind. Without caring. Yeah, to me, this whole thing feels like something we could also at some point discuss in real life at some event, because the 14K number seems very high to me. I know where it comes from, but maybe, there is some optimizations that we can do around those, numbers.

Danceratopz: Ivan is asking in the chat, whether the EL should just not prune non-finalized payloads. And Nico points out that Kev's EIP reduces it to 8K in Hegota. So can we, a question to Toni. Can we leave… leave it as it is now, at 14K and reduce it later in the future?

Toni Wahrstätter: I don't think we will add much security if we say we don't prune them. We are… with 14K, like, we… the network would be dead if we ever have, like, non-finality for 14K epochs. This is already the assumption with, I think we used the 100 factor there, so this is already very conservative, and I think 14K is conservative enough.

Danceratopz: Okay, thanks, Toni. What's this?

Potuz: For what it's worth, I think the right way of attacking this problem would be to compute… to actually have good numbers with the leak, with how far we can… we are forced to recover finality in case of a percentage of stake actually leaks out. So we have numbers for this, we can actually get a bound, and as long as the EL needs to retain longer than that bound, we're fine, because we cannot keep non-finality forever, because we're just going to eject validators.

Barnabas Busa: Doesn't take, like, 18 days to start detecting Validator still?

Potuz: Well, that… it depends on the number of validators, and it depends on a bunch of things, but yeah, so… but whatever that number is, that is the only assurance that we have on the EL side.

Nico Flaig: Yeah, but from a CL point of view, right, we discussed, during non-finality, we should never prune. So, this number we choose here is for the happy path syncing, not for the non-finality syncing.

Potuz: Right, but what I'm saying is that the non-finality has a bound. We are always talking as if there weren't a bound, and we're talking about, like, months of non-finality, but there is a bound. We cannot not finalize for long enough, because we… if we're not finalizing, then we're just ejecting everyone that doesn't have our view. So we should just take that bound, and we're forced not to prune that much, and that's it.

Danceratopz: Toni, do you have enough information to move us forward, or do we need to take this discussion async in order to potentially change this number?

Toni Wahrstätter: I think we're good. I think we're good. We have decided that we would merge the PR, so CL clients can proceed. And yeah, I think this discussion will then just continue for Heze, like, where we exactly land. I guess the 8,192 number is already, like, a good start.

Danceratopz: Awesome. Okay, thanks a lot, Toni. So, that wraps up the Glamsterdam part of the call, Next up, we've got… Hegota devnets and scheduling, but before we jump in there, Barnabas just wanted to bring up The proposed scoping process change, would you like to… speak up to that Barnabas and make everyone aware. I think we'll talk about this more on Thursday.

Barnabas Busa: Yeah, I think the process change should be I-Star-related, though. I don't think we should be changing the process. While we are doing the process. So I think we should circle back when we're talking about the I-Star update.

Danceratopz: Okay, fair enough. Then moving on to… Hegota devnets. The first thing we have… So the current state is we have, heze-devnet-1 FOCIL, and bogota-devnet-1 frames. And we have a frames breakout tomorrow. Does… Anyone from Panda Ops want to give an update on devnet states?

Barnabas Busa: Yeah, so heze-devnet-1 is, very stable. We haven't been really doing much there. It's basically just wholesale, and The two is in the planning. currently have, 3 different CL teams that have implemented it. Well, 4 if we… Conde shorter slots. Prysm, has all the merged EIPs in beta 4, and We have Lodestar, Lighthouse, and Teku that has implemented also the shorter slots on top of Beta-4. So… We could realistically be looking at launching, heze-devnet-2 with shorter slots already. today or tomorrow, but I would actually prefer to have the PR in discussion, merged in, and possibly make a new release as well.

Danceratopz: So, you're jumping up to heze-devnet-2 alignment, which felipe brought up in the comments about CL slot duration and the blob schedule.

Barnabas Busa: Yeah. Would you like to… on this as well. So…

Danceratopz: Oh, okay.

Barnabas Busa: So yeah, it's, it's a few changes here and there.

Danceratopz: Okay, would… Which one is 5743? Sorry? Just for context.

Barnabas Busa: So, 5743 is a PR that is built on of, jihoon's… PR, which was introducing the shorter slots into Heze, so… But there was a couple of bugs in Jihoon's PR, and he's out of office this week. So my flow of PR is basically fixing those bugs, which could be triggered at Heze genesis.

Danceratopz: Okay, so maybe Justin could speak up as to whether that could be… Fixed this week.

Justin Traglia: Potentially. I would like for Jihoon to review it, though, since he'll be leading it.

Danceratopz: Okay. Thank you, Potuz, if I hand up.

Potuz: Yeah, it's… It's tangential to this, but it's related to these things that were merging on the Heze fork. I am very unhappy with the double moderations that we're seeing on governance. it's… in this particular case of quick slots, it was already a call by Alex on ACD to decide that there was rough consensus that the EIP should be CFI'd. And then there's a second layer of moderation, also happens with the criteria. I mean, Justin or whoever has access to write in the CL spec, they also need to decide that there is rough consensus to actually merge in the actual fork. I think we should… this decision of merging something in the actual fork branch for the spec should be done at ACD and should not have another layer of moderation. We should agree

that… what goes into the fork at ACD, and only then we should be merging onto the main fork. The Consensus spec already has the capability to keep test vectors to keep everything we need to test on feature branches. We typically would keep major changes on feature branches until they are SFI, and only then merge. If we agree that we're going to be merging things into the main fork, only being CFI instead of being scheduled, which is already weird, because it puts the onus on really on moving out, an EIP from there, if it's not, SFI, then I think we should agree on this on ACD and not here, and not by… by a second layer of moderation.

Danceratopz: Okay, yeah, thanks, Potuz, appreciate the comments. I… I think that at the moment, there's quite a few, discussions about CFI and SFI, And let's… let's move this discussion to I-Star and continue with the scoping. I think, As it stands, basically, the problem is that we have a bit of a chicken and egg process, and… that, essentially, when we CFI during scoping, And then we SFI when… an EIP, gets… when we agree that an EIP should be added to a devnet. Which is a bit circular, in my opinion, I think, should be prioritized ahead. And not just jump into, Devs. But maybe we can take this part of the discussion to what Barnabas raised about process in the I-Star section.

And, essentially, I wanted to ask Felipe if he wants to speak up to his questions about the slot duration and the blob schedule, because felipe is the one that raised this comment in the… in the issue.

Felipe Selmo: Yeah, sure, I put my comment, yeah, can you hear me?

Danceratopz: Yeah, I can hear you.

Felipe Selmo: Yeah, yeah, I put my comment in the… in the chat here. I don't really have, like, a strong opinion on this, but it seemed like it was a bit up in the air what blob params the EL side would use. Ethrex was the only client that had implemented this, and they aligned with the spec. I, I think, Barnabas, you had a question about… Changing the blob params and such, so, Yeah, I just wanted to align and make sure everybody's using the same values, otherwise we'll need to move the tests a little bit and cut a new release, so if anyone has any strong opinions otherwise, we could just keep the current. The current values. Just want to make sure we have alignment on it.

Danceratopz: Thanks, Felipe. Perhaps everyone in the, every… all EL Devs can check on the, PR that… Billabe shared in the comment above, 3703, to check they're aligned with the blob parameters. about the slot duration. Is that clear? What value is going to be used there? Are we keeping a slot duration of 12 seconds, or has it defined 2?

Barnabas Busa: So we said, last week that if we have 3 clients that have implemented shorter slots, then we would just, shorten the slot time in the following devnet, and we have seemed to reach, 3 clients that have working already, so I would actually propose for the next, devnet 2 for the, To 10 seconds slot time, so we can begin testing everything else. With the shorter slots. Yeah, this is…

Danceratopz: Yes, exactly, yeah.

Barnabas Busa: But, no. I, I think, client teams would… prefer to merge in, 5743, For this, or… like… In previous cases, we almost always had a spec release Before we had the devnet Hub. And, now Potuz is saying that he wants to keep the PR open, and just do the devnet. I'm not sure how… We would be doing that.

Potuz: Well, if you've already merged part of it, then it's a… it's a mix. What I'm saying is that merging things into the main branch disrupts our normal work. And this should not be done unless we're forced to actually implement the test vectors that are being there on the main branch.

Barnabas Busa: I think the point of the consensus spec main branch is to make sure all the CFI EIPs are there. Yep.

Potuz: No, CFI does not mean that we're going to ship it on the fork. Agreed It's.

Lightclient (Matt Garnett): I agree.

Potuz: To consider this.

Lightclient (Matt Garnett): I feel like the main branch should be the SFI.

Matthew Keil: Yes.

Potuz: Exactly! This is the whole point, because the main branch is what we in production code are testing against.

Matthew Keil: Like, and I don't understand why we don't have an EIP branch for quick slots and some of these others, and why are they getting merged into the main Heze? Because essentially, that is an implicit SFI, and that, to me, is antithetical to how we do this process.

Lightclient (Matt Garnett): Yeah, I absolutely agree. I think this has been the problem with shipping the things to the devnets, kind of just implicitly, is that then we just implicitly accept them. And that's not the process that we should be following. We should have the discussion, do we want to SFI it or not, and then merge it to the main branch?

Matthew Keil: And particularly with short slots, this is one that was not an easy… like, this is… there is not broad consensus that this should be included. And that, to me, is also the part that I think rubs even harder about this particular one. Like, forget the fact that ETH1 data, or it's… we're not talking about closing the OXOOs, like, that's something that literally everybody agrees upon. It's much less contentious, but this is something that… It feels like it… you're sneaking it past the goalie, and it… it… it doesn't feel right.

Lightclient (Matt Garnett): I fully agree.

Justin Traglia: Yeah, I mean, that's really fair. I sort of agree as well.

Nixo: And we also did agree at Svalbard at 7723 to create a priority list that all of the client teams can agree on. Which… I'm… I am working on right now to get some consensus from Panda Ops and Steel before bringing to ACDE this week. And I think that that would create a little bit more consensus.

Danceratopz: Yeah, that'd be great. Thanks, Nixo. I agree with the sentiment shared. On the execution spec side, we try not to merge nothing to, our main development branch until it's been SFI. And I agree that just be… I think that basically just saying that an EIP is SFI once it hits a devnet is not really the right criteria. And I think Nixo's list includes… Basically, a checklist that… That says, Once the EIP has been deemed stable on a devnet for a couple of weeks, then we can specify. If people agree that we should move forward, but…

Lightclient (Matt Garnett): But I think that, like, once you put it on the fork branch. you know, even if it's not SFI, then you start to kind of, like, have your implementation depending on it. then, you know, you kind of have the sunk cost already, so why would you say, yeah, we implemented it, it's, you know, now dependent on, in our fork main fork branch, you know, let's just go ahead and just rip it out. Like, most of these EIPs are not necessarily bad ideas, or have, like, bad specs. But I think that… we shouldn't just kind of, like, default, yes, add everything that's CFI to the fork. I think that we need to have more… You know, be more thoughtful about what is actually changing about the protocol, rather than just saying, well, we implemented it, so we might as well just ship it.

Danceratopz: Agreed. I believe there'll be an agenda item for this for ACD on Thursday? Nixo, is that right?

Nixo: Yep.

Danceratopz: Okay, then we can follow up the discussion then.

Lightclient (Matt Garnett): Are we gonna do something about the… Hegota EIPs, though, that, like, we're already putting in devnets. That haven't been SFI, or is this something we just want to deal with in the future?

Potuz: I think we're already going to devnet, and this is already merged. I think it's more work to remove them. We should keep them. And this is the whole problem, that we are already without some code on the spec. I think we should keep them, and then we just target those devnets with the EIPs in. If we later decide to not include them, then we will have to pay the cost. But it's stupid to pay the cost before we just made that decision.

Lightclient (Matt Garnett): But do you also want to do it with the quick slots, which sound like it has more contention than maybe some of the other CFI deals?

Potuz: But it's already there, clients are already implementing it, and we are going to test it. Yeah, it is a cost of… yeah, it's the problem of paying the cost, but if we remove them now, then we're going to pay the cost of removing it, and then we might pay it again to include them again. It just doesn't make any sense.

Lightclient (Matt Garnett): Yeah.

Matthew Keil: Yeah, but then…

Lightclient (Matt Garnett): I'm just…

Matthew Keil: quick slots is that there are a lot of knock-on effects for what's coming in future forks, and it hasn't been coordinated with all of the future work when it comes to PQ. And, like, that is my issue with quick slots. Like, it's not just that it's in the spec, and it's easy to implement, it's that once you shorten the times, it makes it difficult in order to coordinate all the rest of the slot work that's gonna happen when we get to the next fork.

Ahmad Wilson: By the way, you guys, I'm, maybe assuming here, but, there is somewhere where it's formally documented, just for people who are not as familiar with the CFI versus SFI terminology, as well as just the process of going from CFI to SFI and, like, even getting to the point where something is CFI. I think the acronyms are probably more familiar, but the actual process around them may not be.

Danceratopz: Yeah, thanks. That's a good point. For, Thursday, everyone's homework is to have a look at, this EIP. On, network upgrade inclusion stages. And just so that we manage to get through the remaining items on the call, I think we have to park this now, and pick up the discussion then. Maria, sorry, Maria HardANDAO. Maria, would you like to add something for me?

Maria Silva: Yeah. Sorry, I just wanted to say, so for quick slots, it seems like this is a slightly different one in the context that if we added in the specs, and we didn't want to implement it. The only thing we needed to do is to set the slot time to 12 seconds, right? So, this seems one of those EIPs that is pretty easy to just undo. I mean, you already do some cleanups on the code side, but nothing in the protocol changes. But yeah, but I see, like. In principle for other changes, it's a bit harder to understand.

Danceratopz: Yeah, thanks, Maria. I think that's true. I think the argument is just that, you already put a lot of work into, not necessarily with Implementation, but with testing. But it's definitely possible to clean up afterwards. Okay, spencer, moving on to the Hegota devnet plan, Spencer wanted to quickly discuss Whether we still plan to have a hegota-devnet-0 before Mumbai? and what the hegota-devnet-1 scope should be.

Spencer Taylor-Brown: Hey, you know, this is… sounds like a bad time to… I guess talk about this, but yeah, I guess first question, Is that… is it still the plan to launch a hegota-devnet-0 before Mumbai? The assumption on my side is that we merge bogota-devnet-1 and heze to devnet 2.

Barnabas Busa: I think it would be good to scope down, devnet2 first, and then we can discuss whether we could do hegota-devnet-0.

Spencer Taylor-Brown: So, potentially, on the assumption of scoping heze-devnet-2. And then, I guess on the hegota-devnet-1 side, it's mostly an EL scope. Question, so, maybe we can defer that to the EL breakout.

Danceratopz: Okay, thanks, Spencer. Yeah, maybe we can continue those scoping points also, I think. And… and move to the breakouts. So we have time for the other topics that people brought up, or at least tried to make time for them. Justin, have you got the link somewhere? Maybe I can find it quickly.

Justin Traglia: Yeah.

Danceratopz: Breakup.

Justin Traglia: I can share a link in a second.

Danceratopz: Okay. Thank you.

Justin Traglia: Yep, just posted it. I'm gonna join that call now. Bye, everyone.

Danceratopz: Thank you, Justin. Goodbye. Okay, so… Moving on to the EL breakout, So, it was raised… Whether we have… what the status is of, the discv5… endpoints, and this is what I could find. is, Csaba on? Nicole? Who raised this in the comment? Doesn't look like it. Let me just see if I can get the comment up real quick. One second.

some… I must think I may have hallucinated that, actually, because I can't find it. But it's nice that Ivan from ethrex is confirmed. In the chat, I'm not sure what the status is elsewhere. But I'm not seeing… Where the heck? I'm sorry. So… but I've got… I've got another topic for you, if no one wants to speak up to that.

Iván | ethrex: Sorry, what's the question if we have, our… if our defaults are discv4 and discv5 together?

Danceratopz: Yeah, exactly.

Iván | ethrex: Oh, yeah. Then, then, yeah. Don't end it.

Danceratopz: I think this was probably… sorry, this was probably raised in Discord, and I took it over, but it's not, mentioned on the agenda anywhere. But I can… I can dig out the, message and respond basic. So we don't take up any more time here. You can…

Csaba Kiraly: So, yeah, the other one… You've done with this myself. I think it was built up quite some time ago, and the question was really just whether All clients have now. the discv5. default on. And… who is already… Planning to… to switch off this week for… My understanding was that everyone has discv5 on. So no one is left behind. And then we can, we can discuss separately. sunsetting this before. But D.

Danceratopz: Perfect.

Csaba Kiraly: What I just want to make sure is that everyone has discv5 on. As far as I've seen, everyone has it.

Danceratopz: It looks pretty good. Okay. Otherwise, please speak up if it's an issue, but it looks like, from what I could tell, everyone had it. Okay. Did you want to raise anything else there, Csaba, or… Or is that clear not?

Csaba Kiraly: I'm checking the tests now, but I will come back if I see something wrong. I haven't checked it yet.

Danceratopz: Awesome. Okay, thank you. All right, then the last item that I have is really just more of a heads up for, EL developers, that are involved in testing and proofs. Spencer and I have been, implementing docker images for the execution-specs hive simulators. Which should really speed up things a lot before we move on. So, essentially, at the moment, when you… when you run a Hive simulator. If any target has changed, so if the fixtures have changed, or the branch you're targeting has changed, you're looking at, Almost 2 minutes of build time to… before you even start running your tests. And with this change, you should be able to start running different test releases in a matter of seconds.

This does impact some client CIs. Spencer pushed some PRs this morning. to update them. We were working on trying to make it backwards compatible. I'm not sure if it's worth the effort. We'll keep you posted and let you know, async during this week what the status is. It's not… It's not live yet, but it's basically on the cusp. But being merged. That's all. If there's any questions, just let us know, please. Spencer, did you want to add anything? All good?

Spencer Taylor-Brown: Not all good. I guess, yeah, like, when this merges, might break your CI if you're running Hive and CI, I guess that's the… the heads up.

Danceratopz: Awesome. Thanks a lot, Spencer. Oh. Is anyone from Reth in the… And Nicole, that moment, are you there? I can see. I think you'll have to ping, probably. Of all the famine notes. Okay. Otherwise, did anyone want to squeeze something in? Does anyone have anything important they wanted to add at the end of the call? Otherwise, thank you very much, everyone. Have a good week, and I'll see you on Thursday.

Spencer Taylor-Brown: Can I quickly, say something? So yeah, I think it would be beneficial for us to… I guess scope out the EL EIPs officially for hegota-devnet-1, and just… At some point, so I think I'll bring that up. Next Monday. We can lock in, hopefully. Yep.

Danceratopz: Awesome. All right, thanks a lot, Spencer. Thanks a lot, everyone. Have a good week, see you next time.

Jochem Brouwer: Thanks, all. Bye-bye.

Toni Wahrstätter: Thank you, bye bye.

Łukasz Rozmej: Bye.

Danceratopz: Bye-bye, everyone.

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