All Core Devs - Consensus #159

Transcript

Ansgar Dietrichs: we can just get going. I think we have possibly a long agenda to go through. I'm not sure how long it will be, so let's let's go live.

Josh Davis: I knew when you are. You're alive.

Ansgar Dietrichs: Awesome. Yeah. Hi, everyone. To the to Acdc today I'm filling in for Alex, who will be back for next Acdc. yeah. we I am. I also guest hosted last week's acde. I'm a little bit less familiar with, intimately familiar with the Acdc topic. So if I kind of make any mistakes, something feel free to just jump in and correct me on anything. But yeah, let's let's get started. I'll put the link to the agenda in zoom chat M. So 1st up, we wanted to talk about Fusaka for most of today's call, and the 1st topic there is Devnet, 2 Barnabas, I think, wanted to give a status update of where we are at there with the launch.

Barnabas Busa: Yeah, sure. So this morning at 10 Am. Utc, we have launched 2. We scheduled to be hit tomorrow around the same time in epoch 256. And then we're going to do a Bpo every other day. Basically, we're gonna do every other epoch. 2, 56 is going to be a Bpo change. I have put in the interrupt channel the exact schedule. We're gonna go up. We're gonna go down and we're gonna go up again till we hit next blocks of 20. So far the network looks very stable this morning. I have raised some Cl questions regarding Nfd values and Cgc values and those fixes seem to have came in except for Nimbus, that is still, have a incorrect nft value. But I'm sure nimbus team is already looking into it also. On the nimbus side we seem to have some empty blocks produced by Nimbu.

and they are also looking into that that's about it, for now.

Ansgar Dietrichs: Sounds good. Any any other topics on Devnet 2 or any action items we need to get to on on that topic specifically.

Barnabas Busa: So hopefully, you're gonna be able to test everything, including checkpoint syncing and verifying the new status messages. And yeah, I'm looking forward to that.

Ansgar Dietrichs: Sounds good. Yeah. Then, onto the next topic. General Ps, updates, they are just the one thing I wanted to briefly get to is on acdt on Monday. We briefly had the announcement of a new Sunset Labs report, but people hadn't really had time yet to have a look, so there wasn't really much discussion. So I just wanted to give it some room again today in case there was any follow up anything people would want to briefly talk about yeah, I'm not sure. I think we have someone from from Sunnyside labs on the call as well. If you want to say a few words on just the headline, Findings.

J Sunnyside Labs: Yeah. Hi, so regarding the network bandwidth limits, network bandwidth. We retested with 8 validators. as Barnabas pointed out from the acd call, and we found much less bandwidth usage by prison, and we will retest all the other ceos with def net 2 spec. Once devnet 2 is stabilizes. So yeah, we will give you guys more updates on this. And also we've contacted at least one person from every Cl teams if they need something. So please let us know. Then we can run like or prepare something for individual teams upon request. Yep, thank you.

Ansgar Dietrichs: Thanks. Were there any comments at Barnabas? Yeah.

Barnabas Busa: Not regarding this, but regarding the net too.

Ansgar Dietrichs: Oh, sorry. Yeah. Then. Yeah. Let's proceed. Go back to that. Then.

Barnabas Busa: Yeah. So I've quickly enabled watchtower on the 2. So this means that if you push a new commit to your existing branch for like a 2 branch and we trigger an automatic image build, we will automatically pull the images every 2 min. We're gonna be checking. If there's a new docker image available. So in case you push now something to the branch that is untested, or something that's broken that might take your entire find offline.

Mark Mackey: Just wanna ask if cause Cp doesn't have that branch. But you're saying, if I if we make one, that we can continue to iterate on that. And it will be built automatically. Okay.

Barnabas Busa: Yes.

Ansgar Dietrichs: Sounds good. Then to come briefly back to the Sunnyside labs. point! Was there anyone who maybe also, or had a look or any any follow up questions or comments regarding the report for Monday. Anything more on this topic. otherwise. are there any general like? We have a few concrete updates to go through in a second open Prs and discussion of Bpo strategy and and spec freeze. But before that, any general kind of Ps testing updates. Okay? I mean, I assume, just like everyone was waiting for Devnet to. Okay, then let's go to the specifics. We have a few open Prs. We wanted to talk about. Justin had put them into a comment on the agenda. Let me briefly link that that was 5 open Prs. Although the last one is not specific to Fusaka, so we'll talk about that separately in the section afterwards. So it's only the 1st 4 here that we will want to briefly talk about here.

basically just to make a decision ideally today, on like whether to merge or close them. Yeah, I'll just go through through the 4 of them. So the 1st 1, 4, 3, 9, 3 by Anish from Nimbus, I think. If you're on the call to briefly talk about this.

Dustin Brody: I don't know if Agnesha's I'm I'm here. I'm on the call. It is Agnesia's Pr.

Ansgar Dietrichs: Since. Yeah, if you have the context on this then that would be great. Yeah.

Dustin Brody: Sure. So I believe this. This is the one where it removes the the pure, pure sampling, and like correct me if I'm wrong. Because that's why I'm gonna that's that's my back. And so the idea is, peer sampling was an earlier iteration of a broad design goal that that now is being fulfilled in a in a different way. I want to kind of avoid getting into too details here. I can talk about if people want but that validator custody? And and so it essentially got replaced a little bit by validator custody in its overall role. And and importantly, not a single team. We haven't been testing it. We haven't been deploying it at the most. Anybody is is really kind of saying about this as well. Maybe in some future time. This might be a useful technique again. But but the idea is like, for now we're practically not using it. Don't have this part of the spec. If somebody wants to be introduced, make make it sort of aligned to spec with what people are doing and what we're actually planning on in the near term.

If people want to reintroduce this in a future version of pure dos or full dos, or something else, and we can do that. But.

Ansgar Dietrichs: Thank you. I'm read through the context on this. Does anyone else have comments on? I mean, it sounds plausible. This is the general agreement to to match this, or is there disagreement? Or. yeah, I guess maybe the better question by numbers from chat is exactly like more, more concrete. Anyone opposed to merging this in. Okay, then I think the decision is to merge that awesome. Then the second pr is from Manu, I think. And I think I see I saw you on the call. Right. Could you briefly talk about that?

Emmanuel Nalepa: Please tell me if my connection is bad, actually,

Ansgar Dietrichs: We'll do, for now it's good for now it's good we can.

Emmanuel Nalepa: Okay, perfect society is right now. it is not possible to request a data colon by a root for finalized block. It is only possible to request by Roots Colon for unfinalized block. I guess this comes from the copy paste from Blobs, which itself was a copy paste from blocks, because some some clients does not store finalized and unfinalized blocks in the same way in the debit. But for the tech columns, I guess it would be very useful to be able to. Yes, to request. Finalize the tech columns by root. For the reason I describe a little bit more in the pr description, like, if you request a lot of data columns by range. But if for any reason there is few scars missing data columns in the response, then you have to generate a bunch of new by range data columns, requests which is not very convenient.

And if we can request data columns by root, we can just generate only one request for all missing data columns. which is more convenient. That's all.

Ansgar Dietrichs: Any comments on this Pr, I think I see lighthouse in favor of merging any. Basically, again, any anyone who would be opposed to this Pr. Then again, we can go forward and merge it perfect. Then onto the 3rd one, 4, 4, 0, 6. I think that was from Justin. In in a conversation with with people from lighthouse. If I'm not mistaken. does. Is anyone from from lighthouse with comment on and with context, on the call that could talk about this one.

Mark Mackey: I don't know that it was from us for the clarifications. It was kind of as a result of multiple like a discussion among multiple cl clients. But I don't see any issues with this. The clarifications are are definitely necessary. I don't think they really change like change. What was what was discussed at the Berliner Berlin torat, but they they make it explicit, and they make it visible. So.

Ansgar Dietrichs: Yeah.

Mark Mackey: 4, 4, 0, 6, right.

Ansgar Dietrichs: Yes, that's right.

Mark Mackey: Yeah.

Ansgar Dietrichs: Yeah, sorry again, again, context on these. But but yeah, okay, I mean, that sounds like it's it's not really changed. Just justification. then, yeah, if sounds like, like, is there is there anyone that that has context on the on this? That? The people? Yeah, Francisco.

Francesco D'Amato: No. Sorry. This is actually about the the 1st pr. Again. So 1st complete this discussion.

Ansgar Dietrichs: Okay, yeah, we'll get back to the 1st one in a second. But then first, st just to stay with 4, 4, 0, 6 anyone who has contacts on this would be opposed to merging 4, 4, 0 6. Okay, then sounds like we would also be good to go with merging the 3rd one, and then we have a 4th one. But before we get to that, then let's briefly revisit the 1st one. Francesco, you had some comments.

Francesco D'Amato: Yeah. Sorry I should have said you before, but I I thought Jimmy might be here, and but I think I see, is not an yet sent on this court like earlier this morning. basically like he had expressed that he he doesn't necessarily think that we should get rid of the pure sampling. Spec. I think it would be okay to still go ahead and do it. But I think this is a fairly like, I don't think removing this or not removing this is gonna affect anything like, as we kind of said, like, the point of removing is that no one's actually implementing this so I think you'll be okay to make this change whenever. So maybe we can just let this like sit open for a little bit more, and, you know, actually finish the conversation with the middle parties involved. Again. I don't think it's a big deal big deal either way, but.

Dustin Brody: I I personally, I mean, aside from everything else that I find a lot of value. And here I'm not trying to speak on behalf of magnesia or anything. A spec that clearly delineates what is and is not actually real. We have a couple of other corners in the specs here, where, especially in the more experimental ones where they're, they're not actually real. Nobody implemented them ever. And I think those are unfortunate, too. But as this moves into production. I think it's worth being very, very clear about what is real and what is not. And right now this is not real.

Francesco D'Amato: Yeah, I mean, I I agree. I think if it stays, it should be like somehow made clear that this is not a part of the spec that the the clients are implementing right now, or something like that. I think that the argument for not removing is something along the lines of this is something that you could implement after fully was live without necessarily coordinating with other clients, and and so on and so forth. Whereas I guess if we didn't have it in the spec, that sort of maybe would require yeah. Then re-adding into the spec later. but yeah, I don't know again. I don't have a strong opinion on this. I I am just saying, like Jimmy specifically

express an opinion against removing it. But but I think you just like this conversation. I think maybe was in a thread. I don't know this kind of thing, that it was a bit lost somewhere, and at least I personally don't find much urgency in changing this, because it doesn't affect at all what what's happening with the the things that people are actually implementing. So I would consider maybe holding off on this for a few more days. But I I don't know. I'm okay. Even if we decide to merge that. That's fine with me.

Ansgar Dietrichs: Yeah, I mean, given that there was quite a bit of support from merging it, I would be, is there basically anyone anyone else that would be would would be in favor of of waiting one more round of comments for a decision here. Sounds like we wouldn't necessarily need need this for for saka work to to move forward, so default, I would still go ahead and merge it. But if if there's anyone else would prefer to to hold off on this one sounds like, so if if no one is implementing it and in the chat, if if they also, it sounds like Jimmy would not be super opinionated about this. Just had some concerns. So then

I would say, unless someone disagrees. Now, I think we would stick with the decision and just merge it. Okay, then, that's stick with that. And if you feel strongly about this, then later point in this call like, speak up or otherwise. That's that's the decision merging the pr, okay, then we have one more Pr in this section, the last one. Let me have a look that one was, I think, also from just in in a conversation with Casey, I think, originally, but also maybe several people involved. I'm not sure if either Casey or someone else who has context on this Pr is on the call. I'll put the link in chat.

Kasey Kirkham: Is this about 4? 4? 0, 7.

Ansgar Dietrichs: 4, 4, 7. 0, yeah, sorry I should have. I should have mentioned that. Yeah. 4, 4, 7.

Kasey Kirkham: Yeah. So this is just kind of clarifying some of the language around the requirement to disconnect. If the Nfd doesn't match currently says that you must disconnect at the Fork boundary, and what will happen, and and the way things have been worded previously is, if you're not on any of the same topics, and you're not agreeing with fork digest for the purposes of Rpc. Encoding. You'll just downscore each other and not have any positive peer score activity, and you'll just disconnect and so like, we can kind of let that happen. And if people want to implement this, I think it's I think it's fine, totally, but optional, and it seems like Raoul agrees in the issue, and I think he introduced that word originally.

So the idea is to just clarify that you must not disconnect before. But you know you may. You may, after.

Ansgar Dietrichs: And Mac.

Mark Mackey: Yeah, I mean, I I don't know if you said that the existing language was that you must disconnect before, because if that was the existing language. I would. Yeah, I would say that this oh, at the fort boundary, but not sooner. Oh, okay, none of mine. So I do like the clarification. Yeah. I just thought I thought it was more needed. I thought, the the original language is wrong. It looks like it's just clarifying and and adding things sorry. But yeah, I do support.

Ansgar Dietrichs: Awesome. And would there be anyone opposed to imagining this? Then? Okay, then, I think, looks like we will go 4 to 4, 4 to 4 and 4 on merging. So we'll also merge. This 4th pr. perfect. So that's those are the prs, at least the the ones directly relevant to to Fusaka. And then next up. Next topic we wanted to talk about is the question of spec freeze for Fusaka. Basically like, are we ready for this? How much close to to it are we? I think, Barnabas, you wanted to say something to to get that conversation started.

Barnabas Busa: Oh, sorry I thought I was unmuted. Which conversation.

Ansgar Dietrichs: Oh, just the question of whether we are ready to do for spec freeze, for for for the Fussaka spec.

Barnabas Busa: I think we should be. I think we should be ready to freeze this back. Yeah, at at least on the side once. All these 4 Prs are merged in we should be able to have another offer release, possibly office 3, and then going forward, we should be able to do better receipts. That will be. Doesn't specific races. does it? Any of these cl, devs feel like there's still some open questions regarding pure desktop especially, or Bpo. Spec. I think there was one more open Bpo question regarding the Max transaction. But that's it's more of a question for next week. I think.

Ansgar Dietrichs: And then, just for my understanding, would that mean that because we will still have a devnet? 3? Obviously so, there would not be any expected changes anymore between Devnet 2 and definite. 3 from the Cl. Spec. Side.

Barnabas Busa: Yeah, from the sales back side. Only these 4 Prs, but none of these would be new. As far as I understand, all these clarifications are already included in that. Not too. And yeah. these Prs, once they are merged in, we should be basically spec complete for on the sales side. and then physically, could possibly launch in approximately 2 weeks with the adjusted 7, 9 0. 7, and possibly any other vip that needs repricing for Devnet 3, and then devnet 3 should be the frozen spec. and that should be the spec that is touching Mainnet.

Ansgar Dietrichs: Right and.

Barnabas Busa: Except for Bpo's, because at this point we still don't know the Bpo values.

Ansgar Dietrichs: Makes sense. Yeah, just for clarification for people listening. So we will still like this would only be freezing on the Cl. Side and then on the El side. Basically, we will have another next week where we would then freeze the fully. Freeze the El Specs. There's still a few very last things in flight there for for 3 and then basically that the hope would be that that would be the the specs that, as part of said that would not include the specifics of the Bpo fog values, even though they might at least some initial Bpo fogs will be rolled out together with the client releases for the main Fusaka fog. But that's still separate forks, basically. So those are specifically not what we're talking about here, freezing. But the Fusaka spec itself. Then

would be frozen from on the Cl side. of course, pending no issues during testing that that actually requires to to make changes further changes. Is there anyone that feels like we are not ready for that? Is there anyone that still has concerns that? This this would be premature, or are we generally feeling good about this? I mean, it sounds like, maybe no one has serious concerns. And so my understanding is that there's a chance. We would want to launch definite 3 before the next Acdc. Right? So if next Acdc is in exactly 2 weeks, it could be that we're launching Devnet 3 before then. So basically that there will be no further Acdc before that aspect is fully frozen. So so, indeed, that this is the last moment in time, basically awesome. But then with that, I guess.

unless something unexpected happens, then Fusaka Cl side specs are frozen perfect. That that was easier than thought, okay, then we can move on to the next topic, the last one for Fusaka, which specifically is exactly about the part that's not frozen, which is the Bpo strategy. So basically like these kind of tiny parameter. Only folks that we will have after Fusaka. I think there was a Sigma prime blog post, I think. But, Jimmy, but I think Jimmy's not on the call. If maybe someone from Sigma Prime would want to M. Talk a little about kind of the the Sigma pine. Thoughts on this to get us started.

Mark Mackey: The the post was mostly about about like wanting to freeze the specs. So I think we more or less just decided that and the Sigma Prime team was in favor of freezing the specs.

Ansgar Dietrichs: Yeah, sorry about that. I thought I thought reading it. There was also something about basically like good basing to what's basically shipping I don't know. I thought there was also some.

Mark Mackey: It wasn't suggested, like target for the blobs. that we would ship for up to to maybe 18 blobs at the at the fork boundary, and then maybe have a Bpo for it for 24. But yeah.

Ansgar Dietrichs: Okay, then. Yeah, thanks. So sorry about that. Then then kind of misplaced that article a little bit. Okay? Then I think Barnabas and Pawri. I'm not sure which of the 2 of you I think you both had some specific thoughts on the kind of the the which Bpos to to potentially bundle with the initial mainnet releases of Fusaka. And yeah, basically, the general strategy approach here.

Parithosh Jayanthi: Yeah, maybe I can start with some context, typically for the Neb as well as Electra. We had a bunch of analysis on mainnet that was done to try and arrive at a block. Count that we deem the network can handle however, with pierdas that changes, we can do all the analysis we want right now. It just won't really mean much for a post peer das world. Which is why our proposal would be to have a very conservative bump immediately. After Fusaka, so that could be Bpo one. So that would essentially mean we have Fusa. We get roughly, let's say, a week, 2 weeks, whatever worth of pristine data where we can comparedas and post periods.

And then we have Bpo, one that increases blob counts by a relatively small number to give us some scaling short term, and then we can actually do all the analyses that we want on with the main data, and then we can schedule the next 2 Bpo's, which can be a lot more aggressive if required, and in general, I think the plan should be that we can, we should ship at Max. 3 Bpos, because trying to do analyses beyond that, on how the network might predict might behave in the future is kind of hard. Yeah, we wanted to propose this as a general strategy for Bpos, and see if there was any initial reaction or opinions from clienteles.

Justin Florentine: When you say a small bump for Bpo. One. Is there a number that we have in mind already?

Parithosh Jayanthi: Yeah, I think we were imagining like 9 12. But again, it's an open question. I don't think we have a yeah. The Sigma Prime Post, for example, talks about 18 instead. I think one of the other side effects of this staggered ish approach is that we can also let demand catch up. Faster. Yeah, I want.

Pawan Dhananjay: Yeah, when you mentioned that like, post Bpo, one like we can have more aggressive targets if everything looks good like, what numbers did you have any numbers in mind for that as well.

Parithosh Jayanthi: I think that's the tricky bit, because until the data is there, I feel like it's hard to make a prediction. The good thing is Sunnyside labs networks, as well as all the hardening stuff we do over the next one might give us a nice upper limit. And then we can choose how close to the upper limit we're going on subsequent. Bpo's. But yeah, I don't wanna give a number right now and then have to backtrack it once the data is there? I guess the overall question is, then, are we okay with the blob numbers looking different on test nets versus mainnet. Do we wanna just have all the Bpo scheduled on testnets? What's our strategy? Because I would assume we don't want to go through the whole testnet. Bpo mainnet, Bpo. Cycle for the future.

I guess in general, are we okay with test nuts having a different? They they might end up at the same value, but they might have a different intermediate value.

Pawan Dhananjay: You're basically saying, test nets have a little more aggressive targets, that's all.

Parithosh Jayanthi: Yeah, exactly. So test nets could jump already to 20 blobs, for example, and on Mainnet we might just do 18.

Pawan Dhananjay: Make, sense.

Ansgar Dietrichs: Is that something that it would be good to have L 2, or like, basically, if input from people that would want to test blobs at that kind of higher throughput level but whether for them that would be a headache or something, if if those there would be different values between the test nets and Mainnet? Or is that something that if you come comfortable wouldn't be an issue.

Parithosh Jayanthi: Yeah, I'm I'm not sure at the moment. It would be nice if we have people testing the higher throughputs on test nets as well, but I I guess, at least on testnet, we can just induce the load, if required.

Francis: I don't think there's any problem with testnet and many that have different configurations. It's just mainly like for the higher throughput. There might be situations where we cannot submit blobs fast enough, but like we can test that in testing as well.

Ansgar Dietrichs: Sounds good. Some principle, it seems like it might would be an option at least, to have testnets at at different numbers. Do do we have people like, do we have opinions? So 1st of all, maybe pari, a question in terms of like, what? What do you see as the timeline for decision making on on the Bpo rollout strategy here, like, how how much more time would we have to make these decisions.

Parithosh Jayanthi: I think, until we start talking about test networks, we can essentially change our mind. It's a config value that has to be changed and will likely be tied in with the releases that go out for test nets. So I guess the next month.

Ansgar Dietrichs: Sounds good. So then, I think maybe today is primarily about flagging this topic. Getting a 1st round of busy people's opinions and then, yeah. taking it from there for for next Acdc, is there anyone else that like has specific like opinions on on kind of like initial rollout, like what one Bpo, as I put a chat like I personally kind of like to be 2 2 bpo's that already come with with the Fussaka rollout. But, like. Is there anyone else that wants to briefly present their opinion here?

Francesco D'Amato: A more opinion, a question like, how if we did do this? Separate Bpo like not already scheduled in in Fusaka? How long after Fusaka. Do we think that that would need to be.

Parithosh Jayanthi: I think, at least on the data analysis side, we we try to have one week worth of useful data. And then it takes, let's say, 3 to 5 days to do a good high quality analysis on the data that we've collected. And there's, I guess, one more caveat. I forgot to mention earlier with Fusaka. There's also some repricing that are required for increasing the gas limit, so that might be another sort of parameter we're playing around with which leads to this which leads to me at least, feeling more like we should be conservative because we're playing around with a lot of parameters at the same time. But yeah, it it, I think in general, is about the release overhead and getting the community to upgrade. I would say, we're looking at like a 1. Ish 2 ish month time, 1, 1 and a half month. Timeline, I guess.

Ansgar Dietrichs: And and just to clarify there, basically because we would say we would decouple the throughput numbers on testnets from Mainnet, we would not have to 1st go through a full kind of update up upgrade cycle for all the test nets. Is that right?

Parithosh Jayanthi: I guess that's the question. Right now. We could, for example, bake in all 5 bpos and have the testnet sitting at 48 blobs, or whatever the upper limit we agree on is. And then we just have to do mainnet, because the test nets are already above the mainnet number. I guess that would save us a few weeks worth of doing test nets first, st and then Mainnet.

Barnabas Busa: I would actually recommend to bake in the and Bpo. One numbers in the minute releases. Once it comes to that.

Parithosh Jayanthi: Yeah, for sure. Yeah.

Barnabas Busa: So like we wouldn't need to make a different release for Bpo one, and then for Bpo, 2 we could actually reconsider and and see when it makes sense, and then give like 2 weeks notice, to know the printers to like, roll up the new version.

Parithosh Jayanthi: Exactly so. That is the proposal that when we have the Fusaka releases, it comes with Bpo, one values as well as a timeline baked in, but not for Bpo. 2, 3, and how many ever we decide after.

Lightclient (Matt Garnett): Is there a reason to not include 2 and 3? As, like our optimistic values, we're planning to choose, like, I think the upgrade cycle is quite long for this type of stuff.

Parithosh Jayanthi: Yeah, I think that's the alternate approach. Then, we just pre select everything, and we decide to, let's say, abort or make another release to change the Bpo values. The question is, which approach do we want right now? I personally feel like agreeing to a number and then trying to change. It is messier than just agreeing to the number later. But I can see both ways if we want to be really aggressive.

Ansgar Dietrichs: Yeah. And I think the good thing is, we don't have to decide that today. But I feel like, kind of it's already clear with the kinds of aspects that we have to weigh here against each other. Also the specific kind of turnaround time for a minute. I mean, put us on chat that it's maybe a bit too optimistic to think that between client releases and mainnet hard fork we could ever do. 2 weeks might need a bit more for Mainnet specifically. But still, if we can skip the test nets, that still means that the turnaround time, for between client release and and Mainnet Fork would be unusually short at least. Okay, any other comments on this topic for today. Otherwise, again, decisions we would make in 2 and or 4 weeks from now on, on the next one or 2 Acdcs.

Anything otherwise Bpo related that we would want to already have in mind for for now in between for for devnets or anything basically anything about Bpo related that that is kind of short term, urgent.

Kasey Kirkham: One thing I brought up before was the idea of having a rollback built into the schedule where we we increase, and then we decrease just to make sure that that's a scenario that the system handles gracefully. And I think people push back on the idea of doing that in Mainnet but I think we should consider doing that in at least like sepulia like a a test net where there are things that aren't only El and Cl. Running.

Barnabas Busa: I think we're gonna do that on hold team.

Parithosh Jayanthi: Yeah. So we have host key as an option for that as well as sepulia. Sepulia is also kind of a weird network, because basically, every validator is a super node purely because it's a very small network. And most people run all of their keys on one host. So yeah, it's gonna have different patterns, anyway. So.

Kasey Kirkham: Yeah, I don't know if there's any validity to this, but I was also thinking about things outside of El and Cl, that might bake in assumptions about the schedule and that if any of those pieces is fragile in a rollback scenario, it would be better to find that out when the network isn't already in trouble, was was my thinking. But not not gonna push too hard for that.

Dustin Brody: I would continue to push back against this idea of of Bpo rollbacks as an emergency measure. It is never going to happen. We know we don't have the logistics for this in terms of the deployment or or coordination. Now you can argue that there are certain failure modes where it's like. It's kind of whipping along. And it turns out that we just kind of disenfranchised a few more nodes, and that then eip 7,870 really anticipated, and you know that I can see that kind of scenario. But the idea is something going seriously wrong and like no. no, please don't plan on that. It's not gonna happen.

Dankrad Feist: I was running back a Bpo different from just making another hard fork. I think like it's it's an equivalent thing, right just to some new client releases.

Dustin Brody: Right. My point is not, of course, either is possible is that neither is an emergency measure. Neither is oops. We push too far too fast. you know. And now let's revert like this is my only point.

Dankrad Feist: I guess if it's not an emergency measure, then like it's also. then the Ppo is also just fine, like it works.

Dustin Brody: But they work as well as each other. But but the the basic premise of as Prac. Here's what I'm getting at the basic premise of Let's as practice, for when we might want to do an emergency rollback, etc, etc, etc. Then, like No, I would stop there and say, that's we already screwed up really, really badly like that, that is, and and in a way that I is not going to be recoverable in that specific way is would be my would be my claim. So it's it's not that Bpos as a mechanism are worse than sort of ordinary hard forks. It's that the question is irrelevant to me. It speaks to an approach that is misguided.

Marius van der Wijden: Why? Because. like, if if we if we schedule something that is that is and we'll figure out, it's it's broken. and we need to unschedule it right.

Mark Mackey: I think I think, Dustin, you're essentially saying that we'd be more or less testing in prod like.

Dustin Brody: Yes.

Mark Mackey: Like we're we're raising it to a limit, we think is fine. We're not quite sure we're gonna let it be there for a little bit and then quickly switch back. And that's what you're objecting to.

Dankrad Feist: That's not what's being suggested. What's being suggested is using the previous race. The data from the previous race to like understand, if the next race is safe. I don't think the idea is to like 1st raise. Oh, it wasn't good. Now we're going back down that I don't think that is what's what we're suggesting.

Dustin Brody: No, but but but the argument for doing that was as practice, for indeed doing it as a as an in case measure as I understood it. Maybe I misunderstood this, the proposal, but it was like before the claim or the statement. The suggestion was well, we might have to, and so we should find out first, st if some of these other sort of non elcl ecosystem entities react particularly badly to it. And let's do that before the the network is in crisis. That's that's why I'm reacting to. I'm not against testing it per se. I see Mary is just posted. What I am against is viewing it as a.

Ansgar Dietrichs: A particularly useful escape patch for the network planning as a whole or Vpo planning as a whole. We have maybe to just jump in, because we have several people with raised hands, so maybe go by orders.

Potuz: Yeah. So I think you guys are having 2 separate discussions in parallel. So on the one hand, I think there, there was a suggestion of like shipping. 2 Bpos separated enough so that we can recognize that the 1st one wasn't working as well as we respected the second one might be dangerous, and then that gives us time to call off the second one. and my understanding of I mean, and Casey was suggesting to have an emergency release that would just roll back the previous the previous Vpo and I kind of empathize. I mean, I I agree with the 1st approach, like we have we? We can schedule several of them as long as they're separated. We have enough time to call off the second one without any special mechanics, and I empathize with Dustin's point of view on rolling back and the mechanism to roll back. Because

if a Bpo actually happens and it's an emergency situation, then any mechanism to roll back would be exactly the same as just like planning a new hard fork. It would require the same sort of release strategy, and it doesn't. I don't. I don't feel like it's we're gonna gain much by having an emergency mechanism to go back because it sounds to me like it's exactly the same as just a normal, hard fork.

Ansgar Dietrichs: Right Enrico.

Enrico Del Fante: Yeah, to me, it's just we have now this mechanism that allows us to change things easier. So on one way it's it's wrong that we can say, Okay, based on this, we can then go go on main unsafely. And just because we have this escape patch that can use it. But anyway, if we, we have to schedule Bpos in A in steps right? So there is even a possibility where the previous Bpo is fine when the next one activates, we see some network degradation which is not catastrophic, but still degradation. And we can still plan for the next Bpo that goes that put the the blobs a little bit down. So we go back to a better situation, and we buy time to analyze things and improve. So

I think, like there are. There is this possibility as well. It's not a full rollback. It's just scheduling something new and and lower down the numbers.

Ansgar Dietrichs: Makes sense any other comments on either this topic narrowly, or kind of Ppo strategy in general. Otherwise I would also bias towards trying to wrap that up, for now and then we should have that conversation actively Async, between now and Acdc. In 2 weeks, and then, maybe already in 2 weeks. We can finalize our general strategy, maybe with value still pending for the testing or something. But basically general rollout strategy, I think 2 weeks from now would be a good time for for decisions on this, but for today, maybe if there's any further comments, then now would be the time. Otherwise that would move on Shaba.

Csaba Kiraly: Yeah. So from my point of view, the the kind of baking in too many values is is very much belief based. And and we will have much more data later on. So I I don't see a reason to to bacon too many of these, because we can go faster. We can do so, but it's good to agree on on the timeline that we want to have. But but I think the baking in is is. I just don't see the technical value in in baking in many values, scaling because the many bottlenecks that can hit at every point of view. We will see and and we will learn from the mainnet. But we will learn also from tests in the meantime.

which we can scale up testing. So it's not just learning from the previous bump. It's also more testing on the higher levels and larger networks. Yeah, so I would. I would just bake in one to close it.

Ansgar Dietrichs: Sounds good. Yeah, I think. Then, yeah, on external code of sec, at least, we will talk about that. And I think the different proposals are basic categories, either one Bpo baked in 2 Bpos baked in or multiple. And I think we've heard the different arguments already. So now it's about discussing it and coming to an agreement in 2 weeks. Awesome. And then I don't see any further resistance. Shaba. If you could unraise yours. then, yeah, then, let's move on to the. I think that was the last point that I had for Fusaka. Is there any other remaining Fusaka points that we would want to discuss today. Okay, then we can move on to the Glam section. That one is a short section. We only have 2 items. The 1st one is just yet one more. Pr, that one is a very old one by Xiaoway that has been open for quite a while. The I think the

there was some questions around what? What basically are the main blockers there? My understanding is that it would be a requirement if we ever wanted to in the future change slot times. I'm not sure if that's the only motivation for the Pr. I'm not sure if someone that has context on this. Sorry? The number is 3, 5, 1 0. You can already see in the number that it's a bit of an earlier one. If there's someone here that has context on that, and could briefly say something about it. put us.

Potuz: No one's raising hands. The original motivation comes from an eip a pr made on the spec. I think it was Yasik who's proposed it first.st That was about like rearranging this slot like changing the attestation, deadline, increasing it a little bit, realizing that we're wasting time with an idle node during aggregation and aggregation could be made shorter. That raised the problem, that the spec is phrased in terms of intervals per slot. And if we have, like a non symmetric slot, like the different intervals, have different timings. Then it would be better just to like, specify each of the deadlines in milliseconds instead of us an interval of the slot. and that's the original motivation for the eip, and it turns out that if we change the total time of the slot anyways, we would need this, and since this is a No. OP. For most clients, except perhaps, like dealing with configuration and dealing with the spec tests. It's a simple eip to merge as long as we don't change the this form of the slot, because essentially, clients don't need to do anything. That's why I believe.

but I am in support of merging these assets.

Ansgar Dietrichs: Yeah, thank you. Is there? Basically, yeah, are there other clients have an opinion? Or to to ask the question, the way I did earlier, like, basically like, Is there any anyone who would be opposed to merging it as is? And then Barnabas also asked the question, chat, maybe, is there anyone who would be opposed to, even if they maybe are okay with this being merged? Is, would there any be anyone who would want to wait with merging this until we have full life on Mainnet. Is this silence? Because everyone is okay with merging it? Or is the silence? Because no one else's context, because then otherwise, like, I would just say, we merge it.

Enrico Del Fante: Yeah. The only concern, as as said, is some noise around configuration, and I don't know if there is possibility that we start breaking up a little bit. Some interrupt between clients like Mix, Vc. And Vn. Due to this configuration, changes floating around this the only risk that I see to waiting. Our troll fool. Is a reasonable argument. Even if I think that we, we have to go, we should go forward with this because it's a very basic thing that we have to do for everything else like slot and epbs. So we need to do that. So the the quick the better. But I see some noise.

Barnabas Busa: Could you maybe target Amsterdam branches with this spec so like any kind of Amsterdam that we're gonna be launching, it would be built on top of this. Would that make sense? Because very, very shortly, we're gonna need to start doing the Instagram specific donuts also. even probably before we hit follow, so I would most likely not wait till we hit. Follow to merge this line.

Enrico Del Fante: So this is not going back to to phase 0 is something that enables on on a specific fork. Correct.

Barnabas Busa: I think the config would go back to phase 0. Yes. so like you would need to maintain a different branch that is able to read in a different config. That would be your Amsterdam branch, or possibly an epbs specific branch.

Ansgar Dietrichs: Yeah, I'm a little out of the loop on this. This sounded reasonable. What Barnabas was saying just now is that a reasonable strategy, basically merging it for the glam saddam branches. I mean, if we even have porters and bannabas agreeing, then I think we can't really waste that opportunity. Yeah. Then, I think. basically, if unless anyone wants to disagree, then I think that that's what we would want to, we we want to do here. So merge it. But for for Amsterdam. Okay, perfect. And maybe last, just to double check is that, do you think that that's generally clear what that exactly implies for for people.

Barnabas Busa: I think so. I guess it's very clear for me, and we're gonna be the ones doing the glimpse and testing as well. So it should be very. very obvious for everyone. In my opinion. it's just the question of what we want in Amsterdam. That's going to be the next question. I think.

Ansgar Dietrichs: Sounds good. Then let's.

Danceratopz: Which is.

Ansgar Dietrichs: Basically for for the Glampson branches and move forward. We only have one remaining agenda item, which is also for Glamsterdam, and it is a headliner proposal. I think it's the last headline of proposal, because my understanding is that the deadline for proposing basically was, is over now, and this was the last one that basically made it in. So starting next Acdc, assuming that we basically do no longer too busy with Fusaka, we can then also open the discussion. For for picking headliners for today. It was between primarily just the presentation. But yeah, Barnaby, I think you're on the call to talk about shorter slot times.

Barnabe Monnot: Yes. Can you hear me? Well.

Ansgar Dietrichs: I can hear you. Well.

Barnabe Monnot: Okay. Yeah, we've been playing with our proposal. We sent it in pretty late. So thank you all for letting me present.

Ansgar Dietrichs: And we can see your screen.

Barnabe Monnot: Okay, Zuko. okay, this is a short presentation to drive home the point that shorter things are better. We're essentially trying to make the case for moving to shorter slots for Glamsterdam in particular, moving from 12 second slots to 6 second slots, following an eap that was originally written by Ben Adams and Dunkrat, feist, and Julian and I joined more recently. So why do we think 2 X shorter slots are very meaningful. The main message is that this makes ethereum l. 1 a better confirmation engine, which is essentially the main business of ethereum and its main value proposition to give some examples, it reduces transaction inclusion from 6 seconds on average to 3 seconds. It gives you 2 X censorship resistance from having 2 X block producers per unit of time.

It gives you lower dex fees for users from having less value picked up by arbitrages, and so more liquidity providers and so tighter spreads it accelerates finality. Time. If we don't change anything from the consensus, from what it is today, like 13 to 19 min to something that's under 10 min. There's many downstream interrupt ux and cost benefits. And there's even more good things that are detailed in the in the proposal. So why make this proposal for Glamsterdam? I genuinely think that shorter slot would be a great option to to consider slotting it in at the time that Amsterdam is expected to to be released, meaning, after we have ramped up to 48 blobs and to

hopefully a hundred 1 million gas limit. I also think it's a good idea to make this proposal to accelerate conversations about it. I don't think shorter slot time is contentious. I think we all agree that generally we want to move in that direction, so I also don't think it's like distracting too much. And I also think it's meaningful to have shorter slot in mind when thinking about the values restructuring proposal. So what I'm suggesting is to pipeline our thinking between the 2, the 2 proposals. How could we achieve it? So I've been. These are like very high, level straw men on the path to to implementation. Let's say, if we did decide to go with the route to include it in Amsterdam, I think we 1st need like a very serious study of attestation and aggregation propagation time in the Eip. The suggestion is 3 seconds for block propagation, 1.5 for attestation, 1.5 from aggregation.

There's a lot of anecdotal evidence out there that kind of make us reasonably confident that yeah, this is possibly workable. But I think we need to be. Yeah, just much more precise than this. Then the second part is, there is a fairly large effort of just retrofitting the client and making the slot time conditional mainly because the chain has been running at some different slot slot time until now. So yeah, I understand that it's not like launching a new chain that just has 2 X slot times, like there's there's overhead that comes from this. And then, of course, testing to to make sure that everything works out if we did not decide to do slot times in Glamsterdam, but instead to do that in Htar, and assuming that slot restructuring is what goes in Glamsterdam. So I think the path, then, is a little different. We obviously have a work of doing the slot restructuring, which involves

figuring out the right one, testing, etc. We may not need to be so precise about the attestation and aggregation propagation, time study just because some of the proposals. They pipeline this like they remove some of this stuff out of the hot path. And so, yeah, we may have an easier time figuring out like the right partitioning of the slot. There is still, I believe, the work of retrofitting the client with this, with this conditional logic, and then still, the testing that needs to happen for the for the slot time. Hard work. One thing I want to point out is that over the last week, like we've been looking at the restructuring slots with the length of the shorter slot times, and it brought up some challenges and opportunities which some of them may be relevant. So maybe not. But I just want to point the high level points, because I think they're nice to have in mind. The 1st one is that whenever there are fixed overheads like one of them is, for instance, the attestation and aggregation round

that happens at the end of the slot. These fixed overheads. They get worse, obviously with shorter slots, because if their time is incompressible, then when you have shorter slots, you spend a higher relative share of the slot incurring these these costs there may be more ways that are interesting to to get out of some of these fixed overheads like something we discussed a bit was the idea of essentially unbundling or pipelining the head vote from the source and target votes, so that the aggregation can be moved out of the hot path. This is also something that we get in epbs with the Ptc. And the attestations being earlier. And then another thing that I think came up quite a bit when we were discussing. This is this kind of trade-off that exists between the propagation time and the execution time and where we want to be on that frontier.

Yeah, that's it for me. Thank you for your consideration. I'm seeing a very active chat. So sorry I did not see the messages. I think so.

Ansgar Dietrichs: Very primary clarification that people wanted was just that, basically by default. You would also argue for having the throughput per slot right to keep the throughput per time. Constant.

Barnabe Monnot: Correct. Yes, yes, so there are many that would need to be preserved. One of them is the throughput. Another one is the reward rate for stakers like, it doesn't mean you get 2 x, the issuance like you should still keep that constant. So yeah, yeah, keeping everything equal unless there's a strong reason that by the time we move to this shorter slot Fork, maybe we have scaling opportunities from for for different reasons, but all else equal. We would only want to change the slot time, and not like use that as a Trojan horse for making other changes. Yeah.

Ansgar Dietrichs: Mark, do you have a comment or question.

Mark Mackey: Yeah, I'm I would just like to make some a general statement that I think is useful for everyone that's going to be participating in this debate. I've been participating in it since. since Bill and the bill interrupt, and it's been ongoing, and I just wanted say where I think the debate is from my perspective, and give people a chance to disagree on some just, very general statements, which is that, as far as I can tell, just based on where I I think there appears to be consensus that we want 2 things, and one of those is shorter slots. and the other one is some sort of slot, restructuring and pipelining. people are in various camps on that, but I think everybody wants both of those, and there is also consensus that we can't do both of those things in Glamsterdam itself. And so the debate

is more or less about which form of pipelining, and which order to do these things in. so does anyone disagree with those general statements.

Barnabe Monnot: I agree with them? Yeah, yeah, I think I've heard, indeed, that doing both in the same work is not feasible unless I see, like strong evidence to the contrary. I think I would make that assumption, and then I do think it's a matter of 1st selection of a restructuring proposal. That's where I think, actually having the shorter slot. Timelines can be helpful, even if I also feel that the discussion has progressed quite a bit. And and we have like much higher confidence. So yeah, selection of a restructuring proposal and then ordering between shorter slot time 1st or restructuring. First, st I think that's indeed the question. Yeah.

Mark Mackey: I? Okay, I'm glad there's agreement, because I I see the things the same way. And from where I stand I want to get both of these things into ethereum as fast as possible. So I I think there's also one more point of agreement on a limited statement that you know, people may disagree about whether or not this restructuring, the the favored pre restructuring proposal is 7, 7, 3, 2. But I think at this point there is agreement that 7, 7, 3, 2, regardless of what other trade offs you might believe, offers maximal pipelining, meaning that for the same slot time you have more blobs and more blocks than competing proposals. And I think there's also agreement that you

can have shorter slots from 7, 7, 3, 2 than you could for competing pipeline proposals. So I I those are all the statements. I believe that there is agreement upon. There may be others, but I'd like to give anyone a chance to to disagree with that if if that's not true, or if if yeah, you don't feel that.

Ansgar Dietrichs: Yeah. Enrico.

Enrico Del Fante: I just want to make the argument. Why, I think the restructuring in the form of 7, 7, 3, 2 should go 1st is because the 7, 7, 3, 2 form is allowing us to decouple the consensus block from the payload and no matter, you see, so reducing the slot time, anyway, in some form reduce the network resiliency. So in my mental model going in that in buff first, st is wrong, because if you do the decoupling. First, st at least, you the argument is having is will be. We will have a much more resilience on the consensus layer, because the block will be much smaller, and the

the instability might go only on the execution side of it, and we will have a much better consensus. Blocks flow, my dear.

Ansgar Dietrichs: Makes sense. Then, just a comment for me as a researcher, not not as host. Basically. Yeah, I, I, personally am not super opinionated in terms of the ordering of of these 2, I do think maybe just as a general comment, I think. while yes, 772 epbs, like we've been talking about for a long time. I think we shouldn't just be too quick in being like. Okay, then, obviously, it should go first.st I think that's probably where we'll end up with, anyway. But I think at least, at least, it's good to like to take the moment of being like, okay, which of the 2 should go first.st And the the one thing that I would say is, even if we end up doing slot, restructuring slash epbs, or something like that. First, st it's still a good exercise to already do that while discussing what that would look like in terms of implications for shorter slot times.

And so in particular, Mark's comment, I think that basically, even for shorter slot epbs is optimal or close to optimal for actually making use of the window, and so actually is, in a way especially well positioned to then be shrunk later on. I think that's exactly the kinds of arguments we should look into M, yeah. And and and the one question I would maybe have for people is just to double check. We always say there's no world where we would ever combine these 2? Are we certain? I mean sounds reasonable, and we should not do monster fox anymore. But is this something? We are 100% locked in on? Or is there like still a world in which these 2 could be in the same fork?

Mark Mackey: I would love to combine them, but I've heard that Harry's head would explode so.

Ansgar Dietrichs: Yeah, we definitely don't want that. Yeah, then let's continue with the comments, Ben.

Ben Adams: I would I would argue, if we can shorten the slot times. If that's a possibility, then that should go first, st because that has an immediate user experience impact. If we if we do delayed execution, that doesn't really change anything or epbs that doesn't actually change anything in the user experience. So I would argue for a shorter slot and then bring in epbs or delayed execution, or whatever to afterwards. To then allow us to start increasing gas again.

Ansgar Dietrichs: Mark.

Mark Mackey: Yeah, I mean, I think the counterpoint to that. Is that like number one, we can't have as short slots as we can after epbs is before so like we may be able to get 6 seconds or sometime today, but we would certainly be able to do shorter after Eps so we could be like putting ourselves into a position where the slots are longer than they need to be if we do it. The other direction and I think.

Ben Adams: But you, but you've had. You've had that additional lag that you have to wait an additional hard fork before any any.

Mark Mackey: You too.

Ben Adams: Very interesting.

Mark Mackey: Data doing it, doing 2 2 forks where you change the slot. Time is like a lot of extra work. Now, we may not necessarily do 2 forks where we change the slot time, we may just say 6 seconds is fine, but even on top of that there's a lot of work around timing of various things that happen in the slot that, like handoffs is gonna need to do. And you know, if we did it the other way around. They're gonna need to do it twice. So even if we don't change the slot time twice, they would have to do those timings twice. So that's the main like, I think, basically, the main argument is to sum up something like

we get to a world with both of these things slower, doing it the other way around, and maybe, and and getting to an optimal world where of even lower latencies is even slower.

Ansgar Dietrichs: Makes sense. Then, yeah, maybe one more quick one for me. I just wanted to agree to some extent with what Ben just said specifically from the scaling point of view. I understand Epbs has several benefits. Scaling is a big one, but not the only one, but in terms of scaling. Given that we just never really made scaling changes in ethereum in the past, or just for a long time. There is a bit of an overhang right now. So I think. even without epbs in Glamsadam we would still, out of Glam Saddam, have quite a bit of extra headroom for scaling with access list. If we choose to do that, or and or with just general repricing that, give us more, remove some of the worst cases. So in terms of scaling. Given that we like, if we scale immediately by a factor of 5, there's no usage, anyway, to take immediate advantage of that. So I think, in terms of immediate impact, actually like

delaying and delaying the scaling aspect here until H. Star would probably not really be noticeable for users, because we already still have, like a smooth kind of scaling gradient, where shortest sometimes basically is the thing that otherwise you just don't have. So I do agree with Ben that just from a scaling point of view, basically like versus the benefits that shorter sometimes give, it might actually be that there's a more immediate benefit for users doing it this way around. But again, that's just a very partial argument. Okay, that was last time for me making comments. Any other comments that obviously there's also quite a bit in chat if anyone would want to highlight anything out of chat for on the call.

Saulius Grigaitis: So 1 1 thing I'm just wondering. Maybe there was already some study there done what impact would be on the on the end users, because likely a lot of of these systems has a hard coded like a 2012 second slots there, and it could be a quite a big hassle for for these systems to to move to the new slot time.

Barnabe Monnot: Yeah, maybe quickly on this. That's 2 things I've identified that might be important to look into is 1st systems like explorers. Them I feel like. because there are chains that look like ours like gnosis chain that run at different slot times. There might already be like some infrastructure that is built that is flexible enough to change their assumptions. There's probably still some that is not ready, and I think we should identify those. And the second thing is something that was also called out by Terence, and that's included in the headliner proposal. The possibility that some smart contracts may have hard coded 12 seconds in in their behavior. That seems also it's likely that there are some the changes to work

with proof of work which was viable slot time. So yeah, you would maybe limit the amount of the ones. But now I'm seeing that photo says, actually, arbitrum contract itself has this hard-coded assumption. So yeah, okay, maybe there is something to be done. There.

Ansgar Dietrichs: Welcome!

Mark Mackey: Yeah. So, wading more into, like my personal views on on the debate, I do think that in terms of the ordering of things like that. 7, 7, 3, 2 is just much more mature than shorter slot times for these kinds of considerations. And but I mean me personally, I would also, like my ideal world, is that we do? 7, 7, 3, 2, and we for sure do shorter slot times. The very next fork which would give of the stakeholders like the time to prepare for that. and and could potentially be like developed in parallel the way that Electra and Fushaka were. if we know what the headliner is, we can do it in parallel.

Ansgar Dietrichs: Yeah, just because I've heard this concern about, I mean, obviously, like 7, 7, 3, 2 already has the benefit of actually like not just being specs, but but but having having been implemented and and so on in terms of just the general implementation, complexity, testing, complexity of shorter slot times, this has been brought up in the past as a concern for even general Glam. Stamp viability? Are there people that that have opinions and views on, independent of the ordering, and whether we want to do it in Glamsterdam. But like how realistic it would be for shorter slot times to be in Glamsterdam. as he put us in chat, saying a lot of work, but doable.

yeah, put us.

Potuz: So I don't know. I gave enough time to Preston to express his opinion on this. He's the one that's been working on this. It's been working for a few weeks and has a branch that is already passing tests and compiling at least a lot of things that need still to be changed from the point of view of the code base is not something. I mean, people think we just have this constant that you need to change, and that's it. But the second order effects are huge. We have a lot of timing places where you need to deal with like, are we going to reorg this block or not. Is this block actually late? Are we counting attestations for the next slot early or not, because we made a bet that we will reorg this block. And then we decided that this block is not weak. We need to reorg it back.

We have cache that those cache has timing expirations. So when are we pruning those cash? We have optimistic syncing that is affected by this. That is one of the largest, most complicated pieces of code. On the Cl side, we have 4 choice that actually should take tracks of timing to decide whether or not the head is is weak or not. So this, besides the blockchain part of it. There's so many places that the slop time changes affect that. It's going to be quite, quite hard to test. However, having said so, I believe if the choices is, I mean I'm I'm of course I'm against having this in Glamsterdam, but I believe that it can be done in a single fork if it's chosen to be one one pr. It's just that. I think that the the number of things that need to be tested, the number of teams that need to be called that. It's it's just daunting to even start thinking about it.

Ansgar Dietrichs: Annabe.

Barnabe Monnot: Yes, yeah, yeah. I agree with Potus. My question is, how much of that is just fixed work that we have to do, no matter what like, even if we were to restructure first.st

Potuz: All of it. So we are already working on it because we believe that we are going to ship this. And that's why, we started working on this

Barnabe Monnot: Okay.

Potuz: We will have to do this, anyways.

Barnabe Monnot: Yes, right? Right? Yeah. Yeah. So then, it's really a matter of something is more ready now. So we might as well ship that 1st and have this big bundle of work like pipelined with the thing that is more ready. I I think that's reasonable. I still to me like, yeah, from my viewpoint. the sequence of operation that makes sense from a feature. Perspective is really shorter, slot time 1st and then restructuring. So there's a difference in opinion. Kill, of course. But yeah, yeah, I do think highlighting the extra overhead of doing, shortening 1st and then restructuring would be helpful to the, to the discussion as well. What Barnabas asked in the chat essentially.

Ansgar Dietrichs: Right? yeah, is there anyone with a specific opinion on on that specific question that Bannabas just put in chat, what's the implementation time basically of the 2 different orderings here, if we do. Ep, based 1st and then lower slot times or the other way around, basically, is there anyone that thinks that just in terms of implementation time, the ordering here matters for those.

Potuz: Yeah, that was the argument that Mark was making. That we seem to disagree. But I don't understand why, because to me this is a no brainer testing the timings on this. Within the slot is going to have to be done and benchmarking. This is going to have to be done twice instead of once. So certainly there's an obvious testing overhead by shipping slot times earlier. So shipping epbs earlier has less impact on the testing team.

Mark Mackey: Yeah. So to clarify it, we we are of the opinion that in getting both of these things into ethereum it's long to do, it will take more time doing it the other way around. When you wanna look at I don't. I don't know that.

Danceratopz: Do anything.

Mark Mackey: Okay, unfortunately, it has any impact.

Danceratopz: But.

Ansgar Dietrichs: Can we have someone mute then? That? Oh, that that this account that's unmuted perfect. And okay. Then sorry I didn't want to drop you then, in terms of so because again, like, the idea is not to for today to make decisions. We also kind of only wanted to mostly highlight. This proposal have some light initial discussion just to highlight the questions or areas of disagreement. I think that probably we did quite well now and then the idea would be again in 2 weeks if if we are still very busy with kind of with Fusaka, that depends a little bit. But in principle. If we have the room, then we will really kind of go into into the discussion of what what we should prioritize for Glam Saddam in 2 weeks, and so ideally kind of people that have

had disagreements on on this topic that were highlighted just now should take the next 2 weeks to basically iterate on that. And so that we we have the most information possible for for starting that discussion in earnest in 2 weeks. Perfect. Then, I think, unless there's any remaining comments, anything that was is urgent that we need to discuss right now. We have only a few minutes left, anyway, but I think we otherwise finished with the agenda any remaining of topic? If not, then. Yeah. thank you very much. It was great to host these 2 O'confs, and also happy to have the professionals take back over next week. See you all next week. Bye.

Potuz: Bye-bye.

Justin Florentine: See you did great Anskara.

Ansgar Dietrichs: Thanks.

Barnabe Monnot: Great job on scale.

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