All Core Devs - Testing #97

Transcript

Danceratopz: Good morning.

Jun Song: Morning.

Danceratopz: Good morning, good morning. Hey, Barnabas, I didn't expect to see you here today.

Barnabas Busa: I'm not here today.

Danceratopz: Oh, perfect, okay, good. Then, carry on. As he were. You're supposed to sneak in late if you don't want to be seen, Barnabas.

Barnabas Busa: I can still leave if you want me to.

Danceratopz: It's our pleasure. Please stay. Good morning, everyone. We'll just give it a couple more minutes to give time for people to join.

36 people. Can we make 40? 37… 38 that I'll have to do. Good morning, everyone. So, hello, good morning, and welcome to ACDT number 97. It's September 21st of 2026. I'll drop the agenda in the chat. And, basically we've got… a DevNet update, and then we've got, Two questions and decisions that we can think about. Regarding, Windows Serving, window, sorry. Block-serving windows, that are somehow related. But yeah, independent, and then we'll go for, a testnet. Quick check. Before going to the breakouts. So, first off, let's start with the DevNets.

PK, are you in the call? Would you like to give an update on the DevS?

pk910: Yep, I'm around. So yeah, there are basically not much updates from the DevNet side this week. We've continued to, stabilize devnet 8 again, so our clients are back to head. There are still two open scenarios that many affect Besu. One is the JUMP test, thingy, and the other is that attack that was launched on Tuesday, Thursday morning. Yeah, both are prepared, I think we can rerun them today, or tomorrow again, to see if, the network breaks again. Besides of that, happy testing again on the date. On devnet 11, we've pretty much… Finalized our testing there, optimism, and Lido replied that there are fines so far that we can tear down again, so I guess he also, shut it down today if no one complains about it.

Primary testing should still go to devnet 8. I think that's it from the definite SOD.

Danceratopz: Great, thanks a lot, PK. I just wondered if there's any update on relays, and whether they're activated on the DevNets, whether there needs to be any discussion around that today.

pk910: What kind of relays? Because builders are directly,

Danceratopz: Oh, sorry, yeah, sorry, talking about Titan and ultrasound.

pk910: Sorry, yeah. No update on that from my side.

Danceratopz: Okay. All right, are there any other questions from anyone else regarding the DevNet situation before we move on? Potuz comments that we're getting bids. It's good. Okay. So… All right, then. Then, Jihoon brought up, the CL serving window. And the background to that is that 8061 changed the churn assumptions, from the, That this value, the 33,024 epoch value, was derived from? But the, serving window itself, like, the week subjectivity period, sorry. So that the serving window itself didn't change, and the question is now, whether we should change it for Glamsterdam. So, we could, keep the same number. we could reduce it, to a number which turns out to be around 14K.

Under 8061. using the same derivation as what 33K came from, or we could choose to reduce it to around 8K, which comes from 8383. But that is PFI 4. Hegota. So, we're getting a bit ahead of ourselves there. So, Jihoon, would you like to… Sort of further introduce the subject.

Jihoon Song: Thank you, Dan. So, As just Dan described, currently the EL should be able to serve blocks for 30,000 sorry, 33,024 epochs. You can get this number by putting CFDK as 100 to week subjectivity period. A month ago, Kev brought this up and updated EIP force to align CL's and EL's block retention period. In Glas, we're gonna ship. 80-61, which reduces a week's subjectivity period, so we can reduce it… we could reduce it to 14K epochs. So I think there are two things to decide. One is whether we want to reduce the block retention period for CL, more precisely, is the return value of compute BN epochs for block requests? And… If we do so, we will need to decide whether we want to make the EL to reduce its history retention period matching to the CL1,

So if you reduce it from 33K to 40K-ish epochs, then the size saving from Balls would be around 144 gigabytes, assuming 200… Guest limit.

Toni Wahrstätter: Which number are you using there? Like, what is the average ball size you're assuming here?

Jihoon Song: It was actually based on your analysis on 60 mil, and I just assumed that it was gonna increase linearly.

Toni Wahrstätter: Yeah, I think that's a fair assumption.

Danceratopz: Okay, thanks a lot, Jihoon, for the, overview, POTUS.

Potuz: I have two independent comments here. One is that I find weird, this… push to try to reduce the retention of blocks on the CL side, where the CL database has never been a problem on users complaining about, like, our usage. So I find it already strange. But, the second one is… I think we should not even be discussing this on ACDT. This is some… this is something for ACD, not for ACDT. I mean, this… the change is technically trivial. It's just a governance decision of whether… of what the node should have on what it shouldn't. I don't see how this belongs here.

Danceratopz: Thanks, Potus. Yeah, appreciate the input. We definitely don't have to make a decision today, but it was raised in the comments, and I think it's good that we at least get everyone warmed up to the subject. And exactly as Kayman drops in the chat, we could make a recommendation, or at least come to some, rough consensus, basically. In the meantime.

Nico Flaig: adding… Oh, sorry. Okay.

Danceratopz: Sorry, no, go… Okay.

Toni Wahrstätter: Yeah, I just wanted to add, this also plays into this larger topic that we have been trying to tackle for a while now, where we try to, unify all the retention windows on the EL as well. For example, there's also different retention windows when it comes to state divs, so not every EL client could reorg that far back, and it feels like This is… this also plays into that decision, where we should just align all those numbers such that clients agree on them.

Danceratopz: Thanks, Toni. Nico?

Nico Flaig: Yeah, so my comment is related to what Potu said, which is the CL database size, but basically the EL today has to follow the retention period. That we need on the CL side, so you can dedupe the data. So basically, you bet… so while the CLDB is small in that case, we can also reduce the EL side retention. Which is where you get the big gains, in terms of storage.

Danceratopz: Yeah, so this is definitely a conversation for both layers. And it's… it also pulls into the… the decision on whether the, bowel retention period Should be increased to match, the serving period on the CL side. As I understand. Toni?

Toni Wahrstätter: Yeah, and I very much agree with Nico, like, the goal should be to enable deduplication of the BAL. Like, this should be possible, and we should get to something where CL clients can do that safely.

Danceratopz: Yes, Kev?

Kevaundray Wedderburn: Yeah, so I think there's 3 questions here. The first one is, should the bowel match the CL block retention window? The second one is that, given, I think it's 8061, has reduced, the max week subjectivity period. should we change their CL retention window to match that? And then the third one, which I think people want to defer, is should we just change the CL retention window to match 8383? So I think the battle one is… Probably the easiest one to solve. like… I don't know if Nico or Jihoon or Toni had a strong opinion on that, or if anyone else did. Like, should it match the CL retention window, or should it stay at… I don't know what it is right now, actually.

Toni Wahrstätter: So this was discussed… we had this definitely on 223 breakout calls, and also on ACDC and ACDE, like, what should the barrel retention window be? And by the time it was set to the week subjectivity period, of 3,533 epochs. And the reason was because if an EL client goes offline for a while, then they can stay offline for exactly that period for 3,533 epochs, and then, if they want, they can still catch up by doing re-execution. This is super slow, because, You have to catch up a lot of blocks, but at the same time, you at least have the ball, so you can parallelize, and if you wouldn't have the ball, then catching up would basically be impossible.

Kevaundray Wedderburn: Right, so yeah, I agree with that rationale. I think the other point was what Kayman said, which is, should it match the max safety decay Because I think the 3500 is for 10% safety decay, right? Or at least it sounds like it's around there in terms of epochs.

Toni Wahrstätter: This is… this is just weak subjectivity. This has nothing to do even with, inactivity leaks and safety decays, and restoring finality. This is purely weak subjectivity.

Nico Flaig: No, but it's the weak subjectivity with 10 safety decay, right? But also, it feels like this is missing the CL retention, right? So, the problem we have is that if the EL brunes it, we don't gain anything in terms of storage, because that forces the CL to store the balls in full. And I also realized that ELs behave vastly different. So, for example, Geth retains them for the full time. While others prune them at, like, 3,500-ish epochs. So it feels like we will duplicate data if we don't figure this out correctly. Because right now, you basically would have to check the connected execution layer client to determine what storage strategy you use on the CL side, which is not great.

Toni Wahrstätter: Maybe a naive question, but when… which… in which situation would you need to serve a 3000 epoch old ball on the CL? Is it if we don't finalize for that long?

Nico Flaig: No, so the CL spec currently forces us to serve up to 5 months of blocks and payloads, so that's just a spec thing, and that uses the Phase 0 calculation with 100 safety decay, basically.

Potuz: Yeah, but the question here is not about what the spec says. I think what Toni is aiming is, like, why do we even have these numbers? And yes, we only need to process states both on the CL or the EL. If you need to regenerate a state. And on the CL side, that only makes sense either if you're an archive node, or if you are not finalizing. And I think that's the core of the question here. We need to keep data around for two different reasons. One is if we actually actively need to generate a state, and that's because we are not finalizing, or we need to serve that And the other one is just to make history available, for example, for archetype nodes that need to serve information. And I think these two things have different purposes, and we can probably have a discussion as to what needs to be available and what's not.

But, for the purpose of regenerating state, because we're not finalizing, we can relax things, but for the purposes of making history available, it's not really clear to me that we can relax these things.

Nico Flaig: Yeah, but for example, during non-finality, I think the CL site should not dedupe at all. That's at least what Lodestar does. We only do it for finalized data. So that shouldn't even be a consideration.

Danceratopz: Okay, so… How about,

Enrico Del Fante: Techo, I believe we… we… we blind everything also on… on, Non-finalized data.

Potuz: Same for Prysm. We don't store anything that we do not need to store.

Enrico Del Fante: We just have a little cache in memory for full things, but whenever we touch storage, we go blind.

Nico Flaig: Yeah, but for example, I noticed that Prysm also prunes based on the wall clock time, so if the finalized period goes above that window, they cannot serve. You guys cannot serve even the data, so that seems wrong, definitely. Like, we should only Brune if the data is older than the last finalized check.

Potuz: What data? If it's columns, those are based on… I mean, we have a retention period, which is what waste.

Nico Flaig: Blocks and payloads.

Potuz: No, that's… that I don't think is true. If that's true, that's a bug that was introduced in Prysm. We never prune… we used to never prune on World Clock. We only finalize and we migrate to cold. And essentially never prune, except if the user is forcing us to prune. But that's, that's definitely not the fault, that's a hidden flag also, it's not, not an issue.

Enrico Del Fante: I'm cool.

Nico Flaig: Yeah, my…

Enrico Del Fante: You said that, Prysm never, never write blob.

Potuz: Yeah, in that sense, we agree with you. We… we… as soon as we hit storage, we blind everything.

Enrico Del Fante: Right, so you mean you need… EL for serving even non-finalized payload, recent payload.

Potuz: Yes, unless we just have them in memory, let's just say.

Enrico Del Fante: Yeah, yeah, but for long, non-finality…

Potuz: We… we… everything is, is blinded.

Enrico Del Fante: Oh, yeah. Yeah, the same fortech.

Nico Flaig: Yeah, I just feel like it's easier to make a decision on this if, like, the EL doesn't prune anything below finalized, above finalized, I mean, and if we don't dedu, because then we are not that reliant on the EL side, which is not.

Potuz: And the decision was, and I stress this again, was not to serve payloads, nor valves, nor anything on the EL side.

Nico Flaig: Yeah, but we didn't go with that, right? So, we need a solution for the current spec. I'm guessing you mean the independent zync topic?

Enrico Del Fante: Yeah, I agree with you, Nico, but… Can-can-can we… rely on Yelts? What will be… It will be complicated to have ELs agree on serving those data. I mean, through the Engine API, obviously.

Nico Flaig: Yeah, I mean, in my mind, this deduplication is just the optimization, right, in the happy case, to reduce, like, storage for users.

Danceratopz: Okay, so… Clearly, some difficult topics that… we don't seem to have so much agreement on. as Kev mentioned, perhaps the easiest The thing to decide on would be the, bowel retention period. Which seems to be… More of an EL change? Do some EL clients want to speak to that? Does anyone from Nethermind or Geth, for example, have an opinion on that?

Toni Wahrstätter: Then, I would propose we just bring this to ACDE and ask the clients. Maybe it's not a big deal for EL clients, since Geth is already storing them all. Maybe all the other clients can just also not prune them. And then the topic would already be resolved, it feels like. I'm happy to bring it up in the next ACDE.

Danceratopz: Perfect. That'd be great, Toni. Thanks.

Potuz: Why do we need them? Again, so if… I understand the spec requires us to service if, especially if we're not finalizing. But, I mean, we can't… we know we are broken much earlier than that, so probably if the only reason to serve… to keep them is not for history, but it's just to recover in the case of non-finalizing, we're broken much… with much less than that.

Marius van der Wijden: We… we use them for SnapSync. Or we want to use them for SnapSync. And that means during the point where you are syncing, you have to be able to request that, them…

Potuz: But you need them to generate the snapshot? I mean, if I give you… will I ever give you a snapshot that is old enough So that you actually need them.

Marius van der Wijden: No. So, it only happens…

Potuz: We're not finalizing, right?

Marius van der Wijden: right? Mmm… yes. I think, I think, I think…

Toni Wahrstätter: Even then, it's not a problem.

Marius van der Wijden: That's not a problem. Even then, it's not a problem.

Toni Wahrstätter: Because…

Marius van der Wijden: Yeah. Whenever we move the pivot, like, we will just get the access list for every head block. And whenever we move the pivot, During the snap sync, we will just… Download all of the… all of the bells. And, at some point, we will have… an imperfect snapshot, and we will be able to heal it with the bells that we have stored locally.

Potuz: Perfect, so then this is just artificial, right? So we are making clients store things only because the spec says that we need to have them in case we need to regenerate something, but there's no way that we can actually survive such a long, non-finalizing period.

Nico Flaig: No budget.

Potuz: Many, many reasons.

Nico Flaig: It's also relevant for normal zinc, right? Let's say my node is offline for 2 months. How do I sync back to head to see EL needs that data right now?

Potuz: Well, but that's the thing, so the CL doesn't really need it at all, because it's not validated in any way.

Nico Flaig: But do we need…

Potuz: So the C requires us, because I don't care about bureaucratic statements. I can sync the CL without ever touching a BAL.

Nico Flaig: So is everyone implementing, BeaconBlock-only sync up to finalize then, or… No, no.

Potuz: We aren't because we're required because of the spec, and I don't want to get back into this whatever discussion about the CL situation, but the point is, if we are finalizing. then the CL doesn't need to re… doesn't need to sync for even 2 months, you can just back sync, and then forward sync only with… with BeaconBlocks. And… if you are not finalizing, then I don't really care if I have or not the BALs, because we're already dead after 3,000 ebooks.

Marius van der Wijden: But what Nico is saying is also, is also true, like, the BALs help us to catch up to the head faster. Yes.

Potuz: But why do you need to catch up to the head if you are finalizing?

Marius van der Wijden: finalizing.

Potuz: If you're finalized.

Marius van der Wijden: Oh, you could just…

Potuz: Snapshot from something much, much closer.

Marius van der Wijden: much closer. Yeah, but, like, I don't know if we shut off our node for a week. And then we have the state of head minus one week, and then… We get a bunch of blocks.

Potuz: That means that you haven't finalized for a long time, right? Because you shut down your node for a very long… every node for a long, very long time.

Marius van der Wijden: No, no, no, only one note. Only my node. And then I get… I get the next, week worth of blocks, and I can either apply them, or I can get them together with the BL, and I can apply the BL and be up to… Head much faster.

Potuz: Sure, and then two statements on that. One is, you can snapshot to a finalized state. And then… just verify that state however you want, or if you really want to execute everything, you can anyways get those blocks on the EL side. The whole point is that the EL doesn't need this at all. Especially for finalizing, because anyways, we're trusting the checkpoint.

Nico Flaig: Now, I feel like we are assuming here that you checkpoint zoom, right? Which is not the case. You don't need to checkpoint zync if your node is 2 months behind.

Potuz: I understand, you don't need to, but if we're finalizing, you just checkpoint sync and backfill, and you get exactly the same assurances that just restarting your node and waiting for, I don't know how long, probably a week to sync back? If you just checkpoint sync and back sync, you can verify everything, and you get the same assurances.

Nico Flaig: Yeah, but you are assuming you have a checkpoint to sync from.

Potuz: Yes, I am assuming that we're finalizing. If we are not finalizing for 2 months, we're…

Nico Flaig: But where you get the checkpoint, I mean, checkpoint zoom is trusted, right? We don't have that assumption since space theorem.

Potuz: I understand. I do trust that if we are finalizing, I'm going to get a finalized checkpoint from somewhere.

Kevaundray Wedderburn: I propose that we continue this async. I have some other questions, but The agenda looks pretty packed, so I don't want to take up too much time. I can create a thread for… Toni Marius… protests, and whoever wants to join in on that discussion, maybe we'll reach a conclusion before ACDE.

Danceratopz: Perfect. Thanks, Kev. Yeah, I think it would be helpful to start a discussion async, And one reason why we brought it up today was also the next topic, which is our… moving to testnets, to glamsterdam, so… Moving on to that topic, basically, as discussed on ACDC last week, Sepolia is now confirmed for October the 6th. And, let me, let me just drop a link in the chat. Alex created a PR in the EF client, Sepolia Repo… I think most clients have already reviewed it, but if you haven't, please do. It's already merged into the EIP. And based on that, basically, so, assuming that timeline.

It's hopefully okay for everyone, then the next thing would be, Hoodi is tentatively scheduled for the 27th of October. With a go, no-go on October 8th. And… just jumping back to Sepolia, I wanted to ask… If there was a Sepolia Shadow fork date scheduled, for testing. Maybe a question for the past.

pk910: I think we didn't schedule a date yet. Last week, we were waiting for Lighthouse, we wanted to harden stuff. But, I think we can schedule it for this week. We've at least planned so internally.

Danceratopz: Okay. And… Just, a naive question, how… How critical is it that we resolve, these network parameters for the retention period? Or periods. Before we do something like a shadow fork for Sepolia. I would have kind of expected that to be resolved. Before we move to a testnet face.

Parithosh Jayanthi: It shouldn't be overly important, right? Especially if it's… Yeah, okay, maybe it's something we can't really change later, but it is something in the happy case that doesn't matter too much. Like, it's an optimization.

Danceratopz: Okay. Okay. Good to know. Okay, Toni also says, that… he wouldn't consider it worth blocking testnet, so… Thanks for that. Then, does anyone have… or does anyone have any topics on the testnet schedule? So, just wrapping up that subject, like, if you can see the link in the chat to the EF clients Sepolia repo, if you haven't approved or checked out that pull request yet from Alex, please do. Otherwise we can move on. Does anyone have any topics for Glamsterdam at all, before we leave the shared Glamsterdam section? So actually, I can just add one thing for EL clients, which is we'll…

We aim to release, on Wednesday, a new stable, test fixture release for Amsterdam, which will… following our new release, versioning scheme that'll bump the major version of our stable release, so it will not be a DevNet release anymore. we will start releasing tests for Amsterdam, and the aim of this is to hopefully match With, the branches of clients, so that basically they're… As you move your Amsterdam stuff to Maine, our test fixtures also match that. Just a heads up. We'll… obviously, you'll get a ping. Okay, so assuming nothing else for Glamsterdam? Please shout otherwise. We could move to Hegota, and… Spencer? has been pushing to start a discussion on how to go to a DevNet schedule, or respectively, how we organize the FOCIL and frame DevNets.

In order to move forward, as… Efficiently as possible. with our EIP schedule. Obviously, it was a bit preliminary as we haven't CFI'd everything or DFI'd everything yet, but I think it's worth bringing this up. Spencer, did you want to add some color to that topic?

Spencer Taylor-Brown: Hey, yeah, I guess, we can be brief on this call, but, just to give… Everyone a high-level overview. basically looking back on Glamsterdam. I thought I had of how we can try and speed up the DevNet process, development cycle is… trying to align on a DevNet plan, and I don't think this is anything we should do now, but it's mostly a… Let's keep this in the back of our minds, and… Once all the EIPs for Hegota are CFI'd, maybe that's in a few weeks. We come back to this topic on ACDT, and we try and align on A loose plan, not a concrete plan on… How many dev nets we should have on the EL, how many dev nets we should have on the CL, what EIPs we add to each dev net first.

And I guess, looking back on Glamsterdam. And one of the mistakes we made on our side on the EL was underestimating the complexity of 8037, so… M… With, this kind of… loose to have in that plan, the idea would be to include the more complex EIPs a lot earlier in the cycle. And yeah, try and potentially reduce the number of demets, but I guess that's, like, the loose overview, so maybe we can be more concrete about that in a follow-up ACDT, but I guess for today. I think one thing that I would be interested in us aligning on would be… I guess specifically, the FOCIL and Frames, DevNets, whether we should… and have a single CL thread.

Where it's just the FOCIL, FOCIL, and then the CL EIPs. And Frames, and then the… EL EIPs, and then merging the two at the end, kind of like what we did for Glamsterdam. Or do we merge Frames and FOCIL? Earlier, given that there might be some complex interactions there. Yeah, I guess I just wanted to open that discussion there. I'm sure the Pandas have, a lot of comments on this. Yeah.

Danceratopz: Awesome. Thanks, Spencer. Did anyone, from EthEthPandaOps want to speak to that now? Stefan?

Stefan Starflinger: Yeah, I would like to say that, for me, I think it was nice to separate EL and EL into two different definets, so that we would have a Frames DevNets and a FOCIL definites running, and we would try to separate whatever is CL and EL as much as possible. And then, once things mature more, we can combine it into a Hegota DevNets network, and that also makes it a little bit easier To really go from a very rough stage to a little bit more stable stage, and we can focus on the issues there that arise without any other issues or any interactions that might confuse, kind of, where the root cause is. And then later, to have the more complex relationships together in one Hegota DevNets, where we can then be sure that the basics are running well, and we can try to tackle the more complicated edge cases and interactions.

That would be my take.

Danceratopz: Awesome. Thanks, Stefan. Yeah, Tony raises the point that, while ePBS and blobs didn't have much interaction, it's very different from a FOCIL and Frame setup.

Potuz: But that's only on the EL, right? So, from the EL side. the interaction of FOCIL with AA, it's just trivial. There's zero. On the EL side, there are some interactions, so you… anyways, you're gonna want to have that… those testing on EL branches, not on CL branches.

Toni Wahrstätter: Right, yeah. It's only EL, and the interesting point here is the mempool, such that EL clients will have to build inclusion lists. Including frame transactions, and frame transactions are the most complicated transaction type we have when it comes to inclusion. So, in that regard, it would be great to have them combined as early as possible.

Potuz: Yeah, but…

Toni Wahrstätter: SEO clients.

Potuz: You can test on the CL side of the implementation as soon as you just have FOCIL. That'll make the testing much easier, because you could just, like. have it working correctly on the CL side, and then it becomes only an EL testing when you want to combine them.

Toni Wahrstätter: Yeah, this is correct. I agree.

Danceratopz: Yeah, thanks, Potus.

Toni Wahrstätter: I just see more complexity on the EL side than on the SL side, so it's fine if we get the SL side done. I think the EL size will be more complex when it comes to FOCIL plus Frames.

Danceratopz: Thanks, Toni. Yeah, like Clan.

Lightclient (Matt Garnett): I tried to post a comment, but for some reason I had a lot of autocorrects, so just to say it loud, my mental model for the plan here was to have, EthPandaOps DevNet Zero for Frames, as, like, a first step, and if that generally goes well. spend October working towards the FOCIL and Frames DevNet. So, we would do want to move towards FOCIL and Frames early. if things don't go well on DevNet0, then maybe we can, like, revisit and look at doing DevNet1. There's a couple spec items for Frames that are sort of, like. pending a bit to consider for the next devnets. But if that sounds good to people, I think that's, like, the right plan, and try to target a working Frames FOCIL DevNet before DevCon. That would be ideal to me.

Danceratopz: Awesome. Thanks, Matt. Yeah, obviously a FOCIL definite… oh, sorry, a frame dead note zero would be a good first step, and I think, Parry Anson in the chat, but… Oh, we'll push for that. this next week. Spencer, you've got your hand up.

Spencer Taylor-Brown: Yeah, I guess it asks really quick, so I think obviously we want to do a Frames cabinet independently, and then a FOCIL debinnet independently, but maybe it makes sense… I don't know if this is fair or not, but would the CLs be open to having A FOCIL-only branch, so then the… Basically, ELs could have a Frames plus FOCIL only. For, like, the EL independent track. I don't know if that makes sense here. Because then you kind of have the CL only and the EL only, but, They can be merged at the end still, and then we can also test the interactions earlier.

Danceratopz: But that was a question for CL clients, right, Spencer?

Spencer Taylor-Brown: Yeah, well.

Danceratopz: Exactly. I think we won't do the round right now, as we're… we're kind of pushing on for time, but Jihoon, you have your hand up.

Jihoon Song: Yeah, for the idea of having a leaf branch, a FOCIL olee branch for testing. Frames and FOCIL on the EL side, there's a little bit of a change that we need to make on the EL to enable Frames and FOCIL interaction, which is not huge compared to what we need to do in the EL. So… but I also agree that… It's better to have Frames only and fast only in the beginning, and then… Let them mature. But… FOCIL-lay DevNet also require a little bit of a change on the EL side, because we need EL that can produce inclination, and for Frames. and FOCIL DevNet. On the EL side, we also need to change our SL a little bit so that we can

I mean, there's a little bit of change that ELs require so… My two cents is… we can probably start with FOCIL-Oly and Frames only, and then once FOCIL-Oly DevNet is stabilized, we can modify CL clients a little bit so that ELs can test FOCIL and Frames in their DevNet. And at a later stage, once the DevNets are stabilized, then we can try. Hey, go to Definite Zero.

Danceratopz: Thanks, Jihoon. So I think we can all agree that basically at the start, we'll go FOCIL and Frame separately, before we go to Combine.net. And… I guess this will be a topic of discussions further down the line in other ACDTs. But as we're already at 4… well, 43 past EF o'clock, I think, we should move to the breakouts. I've dropped the CL breakout link in the chat. And just as a heads up, mainly for EL clients that, 8142 was withdrawn by its champion, and… Instead, he's proposed 8411, faster execution broadcast, and so… Marc from Forkcast wanted to just make everyone aware that CL teams should add ratings ahead of next day CDC. Just so that doesn't get forgotten.

And with that, unless anyone has anything else for the shared… Segment of today, we could move on to the breakouts.

Justin Traglia: Alright, bye, bye to yellow people.

Danceratopz: You're by Consensus people.

Potuz: Wait, where are the breakouts? Oh, I think I. I just saw it.

Danceratopz: Yeah, no worries. The link's in the chat for anyone who's looking for the CL breakout. Or it's in the agenda. Okay, alright. I think most people have found their way across. So we can move to the… EL breakout, and we don't really have much on our agenda. They had a bit more on the CL breakout, so I wanted to give them time for that. And… First of all, I just have one topic that I just wanted to ask EL client developers about, and that's currently that, Our test releases have, test fixtures. which test BPO transitions, which are Osaka-based, or more precisely, BPO2-based. So we have tests that transition from Osaka to, BPO… sorry, from BPO2 to BPO3 or BPO4, and BPO3 is a…

a blob increase, and BPO4 is a blob decrease, so that both Pops are tested. And I just wanted to give a heads up that… We should add such test transactions that are based on Amsterdam and not Osaka. So it's more the… a public service announcement, but, like, basically I was thinking that when we add these new test schedules, perhaps instead of using named, sort of, fork BPO slots. we could, call them BPO Increase and BPO decrease, and I just wanted to get a temperature check. Whether any EL clients have anything. To say about that. Spencer.

Spencer Taylor-Brown: Yeah, I guess I'd add to it, so… We want to make sure that, weekend tasks. any potential future BPO increase or BPO decrease, just on the fly, So I guess this is hence, having these… New fork names? yeah, and I guess, Dan, the reasoning for keeping BPO3 and 4 is, Because they'll likely be used. is that right?

Danceratopz: I mean… So, I mean, these are… these are test forks, right, that, only configured for testing? And initially, I thought we could just, move BP03 and BP04 to be Amsterdam-based, but it seems sort of, like, sensibly cautious. Just to keep them based in Osaka. Until after the Amsterdam Fork. And then, for now, just add, like, new schedules. And then the question is. what do we call the new schedules? We call them… BPO5 and 6, or 6 and 7, or something like that? Or do we… we go with more descriptive fork names? Because the primary purpose of these forks are just for testing. I don't know if an EL client wants to speak up to this. Does anyone have any…

Strong thoughts on this? Or otherwise, I can just… Create a PR and propose something for you. And Toni in the chat is asking whether we're considering increasing blob counts. Is there a panda in the house that can speak to that?

Stefan Starflinger: I haven't seen the latest data, but so far, I don't think we're hitting limits at all for blobs, so I don't see this as being too urgent.

Danceratopz: Okay. Thanks, Stefan. Yeah, it's not an urgent topic either way. but just something that we should take on. Moving towards Amster. Alright, so… no other EL topics on the agenda, officially. I would generally ask if anyone had anything from the benchmarking side that they wanted to bring up ahead of call tomorrow's dedicated. Gaslighting committee call? Or whether it can just wait for that call. Is there any… News or announcements anyone wanted to… Give for benchmarking.

Ben Adams: Yeah, I was gonna bring it up in the… I was gonna bring it up in the call tomorrow, but, the… what we're testing on Benchmarker is essentially a… Weekend Validator node… sorry, full node. on EIP7870. And I'm just wondering if we should be testing, a tester node, which is, like, has double the hardware. Because for a full node, they can… They can essentially work at the average. Of the chain, because if a block is too heavy, they can catch it up when blocks are light, and… Whereas the attester node has a shorter deadline, it doesn't have the full slot. And it also has to meet a deadline, so it's… It's a much stricter… That's where the worst cases are really important.

But it's also stronger hardware, so at the moment, we're testing on weaker hardware. Yeah, I'll add it there.

Danceratopz: Thanks, Ben. Good question. everyone can contemplate on it for tomorrow, maybe, unless Toni has his hand up?

Toni Wahrstätter: Yeah, with ePBS, we… Testers don't have to execute the payload anymore, right? Before they attests, so they only have to finish payload execution until the next slot.

Danceratopz: Thanks, Toni. Maria?

Maria Silva: Yes, can you hear me alright?

Danceratopz: Yep, loud and clear.

Maria Silva: Okay, thank you. So, I would say, although I do understand, the idea of, like. We should only care about worst cases for our testers. In reality. we are using this not just for worst-case testing, right? Like, we are using this to also decide how much an opcode should cost. And in that case, I think we need to consider the loads it adds to the network for the low-powered. Nodes, not just… the EF era testers. And so I think in that case, that's… I think there's… Where the rationale comes that we should price by The more pessimistic case, and not the more optimistic one.

Ben Adams: Yeah, but the… the… the pessimistic ones have a longer time to… to process, and they also… they don't have to meet the deadline, and… They will be operating at the average Of, of the, of the chain. Whereas the attesters have to meet the deadline the worst case of the chain. So I think they have different… Constraints, also.

Łukasz Rozmej: If I can weigh in something, yeah, it's probably… depends what you want to measure. If you want to measure… DOS scenarios, so worst… worst case, then definitely you… you want to… Use… A tester spec. Because that's what you're measuring against. While average case, as we observe it today, I'm not sure how it will be after repricing. Average case is probably 10 times lighter than the… or even more, right, currently, than the worst case, so… We don't really have to focus on that, and average case is what will be actually processed on full nodes, so we don't have to do We don't have to… make them…

Be compliant with those protection cases.

Danceratopz: Thanks, Lukasz. I'm not sure if you entirely got your answer question, Ben. But I think that can be a topic for tomorrow, in a more dedicated round.

Ben Adams: I'll bring it up tomorrow. It's more to… Raise awareness. That was all.

Danceratopz: Perfect. Thanks, Ben. Alright, Yeah, Mark's reminding in the chat that the next frame breakout is tomorrow, so please add topics to the agenda. On the issue, there's a link in the chat for that. And otherwise, I would ask if anyone else has any other topics for today. We do even have 5 minutes left. But if not, thank you very much, everyone, and I'll see you all on Thursday. Thanks a lot, if not before.

Kevaundray Wedderburn: Alright, thanks, Dan. See you guys.

Stefan Starflinger: Thanks.

Danceratopz: Thanks, everyone! Bye.

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