All Core Devs - Consensus #162

Transcript

Alex Stokes: Hello.

Hello, everyone! We'll wait another couple of minutes for people to join, and then we'll get started.

Matthew Keil: Hey? I just wanted to make sure that we're gonna talk about the the release timeline. And we're going to leave enough time to actually do a good discussion about that.

Alex Stokes: Yep, Yup, it's on the agenda. I will cover the Fussaka stuff 1st before the glance room. Stuff.

Matthew Keil: Sweet thanks.

Alex Stokes: Okay, let's give it one more minute and we will get started. Okay, Josh, if you're helping with the stream, I think we're ready to go.

Josh Davis: You are alive.

Alex Stokes: Okay. Great. Hi, everyone this is Acdc, number 1, 62. It's issue 1638 in the Pm repo. So today on the agenda. We have Fusaka and Amsterdam, and I think it might be quite packed today. So let's go ahead and get started. So 1st up with Fusaka, I wanted to check in. If there are any updates on Devnet 3 I think the Devnet itself was going pretty well. and then we started doing some testing, and so far I think the test have been pretty good. I think we're in the middle of one right now. Perhaps Carrie or Barnabas have an update in more detail. There.

Parithosh Jayanthi: Yeah, I can go so in 3, we've mostly seen also perfect participation. And I've listed a couple of non finality tests that we wanted to do. And we've been doing over the last. Let's say. 2 ish days. The 1st one was where we created non finality and took out about 40 ish percent of the network. And these were just full nodes. So the network still had a lot of super nodes and we put them back together, and the network healed in under an epoch which is great to see. Right now, we're doing a non finality test where most of the super nodes are taken offline, and we've submitted exits, and once the exits are through the network should sort of self heal, and then we'll bring the super nodes back online and

log. How long it takes for the network to be okay again. There's 2 more scenarios that I've listed on there some with a few malicious actions, and would be great if people can. Add more to the to the list of tests we have. This is all to do with Devnet 3 before we started earlier today, we had a hundred percent participation, which is great to see. Since the Devnet 3 testing's been going full stream. We also started Devnet 4, which will be going live tomorrow. And this is a really really large network. I think we're planning about 15 to 1,600 nodes. The notes are going online as we speak, and we should be set up for Genesis tomorrow morning. We're gonna do roughly one day worth of data for each step, and I think the last Vpo goes up until 48 72 blobs. And the idea is that we can collect one day's worth of data with 8 hops and with everything running as we

is, we expect it to run on roughly, 10% of maintenance, and this should give us a decent idea on how pure scales. and we should be able to present it in 2 weeks at Actc again. I think that's all the current status we've outlined, the plan for the Devnet and the spec. Everything's on the interrupt chat.

Alex Stokes: Alright great, awesome. You mentioned a list of different testing scenarios like we started with on Devnet 3. Is there a list actually written down somewhere, or or should we collect other ideas? Okay, you're on discord. I'll just grab this thing.

Parithosh Jayanthi: Yeah, I sent the message, and we can create a thread and discuss it. There.

Alex Stokes: Okay, cool. Thank you. Cool. So yeah, definitely, 3. Moving along. Devna 4 will be really interesting to see what happens as we really crank things up on a much bigger network. And yeah, I think from there, that takes us into the next thing I wanted to talk about which is the Bpo schedule. So you know, as we all know, we have this Vpo feature where we can kind of independently change the blog counts once we've deployed a given hard fork. And essentially, it's time now to think about what the schedule should be for Posaka I could give a little more context. But, Justin, you had a document. Maybe you just want to take it over from here.

Justin Traglia: Yeah, sure, can I share my screen?

Alex Stokes: Sure.

Justin Traglia: One second alright! Can everyone see that.

Alex Stokes: Yep.

Justin Traglia: Cool so Hi! Everyone I'd like to for us to start discussing possible blah blah schedules it'd be good to get a sense of what this looks like and what our priorities are. I've made this proposal. which I believe would work well. There's a single phase with 3 Bpo forks. There's approximately one month between each Bpo fork. and after 3 months we had target 21 blobs and with a limit of 32 blobs per block the epoch. The epoch values I've chosen which are below are not. I don't want them to be like exact times, so maybe not. Don't debate this too much, but I propose for the Fusaka upgrade to happen. End of October beginning of November.

yep, and then, like, I said before, like a month between. So the 1st Vp. Of work would be December 15th before Christmas, and after Thanksgiving in the Us. Bpo. 2 would be January 14, th 2026, another month later. and then Bpo, 3 would be February 10.th Approximately these times that I've chosen are best for like Asia and Australia. Because there are so many people working on Peer to ask there. Oh, yes. So I just kind of want to get a broad agreement on what we think this should look like, and what our priorities are. Thoughts.

Alex Stokes: Cool. Thank you. Yeah. So I guess one other thing here, just to ground the discussion. is. There's sort of this phase one here. But then the idea is that we'd have a you know. Second phase, we'd have another Vpo update sometime in 2026. That would assuming it all looks good to scale us up to this 8 x on top of Petra. That period should theoretically provide right. So getting to like target of 48 people seem to prefer having this like phase deployment, where we have a much more gradual rollout at the beginning. That seems wise. Soccer will be new on Mainnet Periodos will be new on Mainnet. So it seems. Yeah, seems appropriate to start out with a more gradual rollout. So then we have this schedule that would ship.

We'd have another phase early, 2026. That would add more Bpos to get us up to 8 x throughput again, assuming everything looks good, and there are no surprises as we start to scale from there in terms of this chunk of things. Yeah, I think the main thing is just the dates. at least for me. These are pretty spaced apart, and we could compress them a bit. and the question is, why? Well, we want to get to higher throughput sooner. But you know this is obviously something we have to trade off against like with respect to security, right? So we don't want to be too aggressive. But we also don't want to like leave any scaling that's possible on the table, because again, there are roll ups who are looking for more blobs. There are other

players in the ecosystem who would like to be roll up so basically aren't just because they see there's not enough da throughput for for their use cases so given all that. Anyone else have any other comments about this document and this general shape of the Bpos. I think one other thing here I think Pandops is planning to do testing to validate these numbers. I guess. Yeah, Perry, a quick question. There is this tied to the devnet for, or are you thinking a different set of experiments.

Parithosh Jayanthi: No, it's tied into tenant 4.

Alex Stokes: Okay? So yeah, so basically, we'd have scaling on Demo 4 again, with like, a much higher node count more realistic network parameters. And that would inform this data. Especially the actual target. And Max numbers that we'd want then, otherwise the question is more up to us as to like what kind of space we want. you know, if this is like much more compressed, and we have less time to observe Mainnet. But again, if we just delay it because we can. Then it'll just take much longer to get to say an 8 x amount of scaling. So with all that, said, anyone else have any other comments. I think one other comment here is that if we do, you know, say one Bpo a month, I think this gets us to something like

a potential 8 x in April of next year. Does anyone have any input here? They think to subscribe? I did have a different salute or a suggestion. Let me go find the comments. Yeah, basically moving the dates a bit up. So you can imagine doing. Bpo, one on 24th November, Bpo. 2 on 15th of December and Bpo. 3 on 14th January. And that just kind of pulls everything forward a bit. Anyone have any comments either way. Yeah. One square.

Ansgar Dietrichs: Not a comment directly on the dates. More, maybe question. So obviously, we would have to have validated all the throughput levels up to basically the Bpo 3 numbers before the initial fork rollout, right? Because that would then be automatically bundled. And do we would we want to already in advance kind of have some sort of ballpark understanding of if, say, for example, 21 is the number, or like, I guess, 32, 32, because that's the worst case. Of course, 32 blobs is the number we had aim for right now. But then Pandops comes back, and actually we can only prove up to. We only have really reliable numbers up to 24, I assume. Then we would all agree. Okay, we actually do. I don't know. 1824, 1624, or something, and we don't delay the fork. We just basically cap out a little bit lower, and then we use the time until early next year to validate higher throughput and ship more Bpos. But if they come back, and maybe they can only validate up to 12

blobs that might actually be a reason to delay and halt the fog. So do we have some sort of like up to what level would we just cap the Bpo 3, basically. And still chip on time versus, where would we say, okay, this is a meaningful enough hit to the kind of throughput targets that we would want to roll out with Fusaka that we would. and delay and and put more more time into into validation.

Alex Stokes: Yeah, I mean, what would be the argument for delaying like, even if we had to like ship a Vpo, that's like much lower than we're expecting. We would still get Periodos live on main, that right.

Mark Mackey: That was my thought. And then also, you get mainnet data with pure dash. You get to know things like the distribution of super nodes and things that kind of factor into how far we can scale. So I would say that even if we didn't have those numbers up to higher amounts that we would still ship just because we only get more data about how far we can push scaling by by shipping to Amsterdam. That was actually one of the biggest motivations originally behind Bpo Forks. To begin with.

Ansgar Dietrichs: Interesting. So we would basically ship, no matter what. In a sense, I mean, obviously, like, at whatever level we feel that is definitely stable. But that could be basically as slow as no throughput increase. To begin with at all. It's just about getting it out there getting data. And there's just no given that. We basically are already confident at this point in time that we don't need any spec changes at all anymore. Kind of as a result of things we encounter in. Let's say, testing, I guess. Yeah, we can always just address it with Bpos. Okay, that was an update for me. So thank you. That's useful.

Alex Stokes: Yeah, I don't really see why we'd want to delay the fork. And yeah, it may just mean the Vpo schedule looks a little different than we're expecting. So in any case, we could bike shed this the rest of the call today, so we might go ahead and time box this. Let's see any other things to bring up. Yeah, I did want to open the conversation, because I think it will ground the next few discussion points. Some of these things that we're going to get to in a second, depend on how ambitious we're trying to be. And yeah, wanted to make the point that it seems like people are generally okay with something like this. Directionally, I think also, the experiments that Pet Ops are doing will help inform these numbers give us a little more confidence in them.

But ultimately, yeah, wanted to open that thread today. And yeah, I'm sure this is something we'll circle back to on future calls. So unless there are any other comments or questions on that Bpo schedule. let's move to some testing updates. So this is following a thread from acdt on Monday. where there was some discussion around, I think at least 2 different things. There's this notion of this like perfect, pure desk configuration. and having node being able to sync. I think there are also some questions around the custody backfill in the event that your custody assignments change, and you need to like again, back fill in these different columns you're supposed to have. So I was curious for an update here. I think we had said on Monday, we'd follow up with the idea, having a few more days for client teams to work on these features.

Are there any things? Yeah, any updates here or things we should discuss.

Matthew Keil: Is this the right time to talk about timeline.

Alex Stokes: Yeah, I mean, it ties into it, I think.

Matthew Keil: So I no, it's hard for us to stand up and to reach out about this. But there has been some internal discussions between a lot of the client teams. And we have, we have concerns with the timeline. And I know I'm the voice that you guys are hearing bring this up, but it is not just me nor is it just us so I'm speaking on behalf. And and I've been asked to to talk for for us, for for prism, and for Nimbus, and they're on the call as well in support. we have concerns that the rush in order to get to where we are. For September one cutting of of of images in order to do the release. On that timeline is aggressive. We also have concerns surrounding some of the

the testing that we think might also be beneficial. To give peace of mind and to move to to main it smoothly. the major concern is that we're not on master. So we are. We'll be done with that. Basically, this weekend, we're gonna be done. But I know that that prism and nimbus are gonna need more time in order to get everything fully reviewed and to be comfortable with the code that's actually gonna be running on mainnet there is, this is something that I think we were advocating for a devnet that has all of the code on the trunk branch. It's and it's a lot of code that needs to get merged as as manages brought up.

There's also been no devnets where there has been a quote unquote spec freeze, and then the ability to go from one devnet to the next. Devnet granted 4 is basically the same as 3 but our code isn't on master. And so now, being able to to test, to execute that code or to exercise those code bats on on trunk branches. We think is is critically important. the timeline that we've been talking about is basically 4 extra weeks. So end of September. And this is something that and I agree with you, Potus, that we, you know, I think being able to test this stuff on Holeski is so that that test net can get shut down, I think, is outside of the discussion, because that you know whether we're exercising those code paths on mate, on trunk, branch or not, for Holeski, I think, is less of a concern, but I think being able to have one solid devnet with no spec changes, and all of the code on

on trunk branch is is critically important for the success of this rollout. there's also been no private mempool testing up to this point, and there is a concern that the get blocks. V. 2 has been a crutch in order to make sure that syncing and and following head works well. And we think that needs to be exercised as well. So this is something that I I know again that I'm the voice that you're hearing speak on on behalf of this issue. But it is something that there is a lot of consensus among the consensus teams. We've been having a really deep heart to heart about this, because we know the importance and the critical nature of getting these timelines met.

so I I want to open the floor, though, in case I've missed anything to to the other people that also feel that that we need a little more discussion. Now, this is the the thing that we thought about Justin. Is that realistically, if we could get the rest? Yeah, sure, sure, if you want to. If they feel comfortable speaking up, please feel free. I was just on the call with Manu and and Dustin.

Emmanuel Nalepa: Yes, so yes, my one of my concern was yes, the fact that we should test We should test as clients without the help of the 2. I noticed that we had a lot of failing devnets pure. Designate 3, 4, 5, and I don't remember exactly when pure das B. 2 was introduced, but I do remember that as soon as Peerdas v. 2 was introduced, so Devnet started to be really stable. That's why, yes, I think we should have something really close to Mainnet regarding private Main pool. I'm talking about private, because when you have at least one blob, which is in a private name pool. The Getlob v. 2 does not help at all. and we should have something very close to to my net about about this private connection. When I look at now on door explorer.

it seems we don't have a lot of blocks with private private blobs. I mean parito. It was a chat that it's only now, but a few days ago it was the case.

Parithosh Jayanthi: Yeah, the thing is we're doing non finality testing. So the circuit breaker triggers, and then it disables the workflow for most clients other than North Star, so you won't see Private mempool testing working for all of today. But we were doing it in the week.

Barnabas Busa: Yeah, we've been doing it for like, 2 weeks. We've been posting blob data on it today. Really. So we have been doing maybe 90% of all blobs in 3 with private member. there's and.

Parithosh Jayanthi: I posted an example. I posted an example map block from like 5 ish hours ago. So this is before we started the Non finality test and this was all with private clubs.

Matthew Keil: You know, and I.

Barnabas Busa: In rest right now. Where the transactions don't get passed to the our builder. That bug is actually being worked on right now. So we saw some ups and downs in terms of a number of transactions.

Matthew Keil: You know. And I I don't want to. And I I apologize. I don't. Wanna you guys had devops do an amazing job like heaths. You guys are fantastic. And I know that we're we're exercising a lot of these these edge cases, the and again, yeah, exactly. And scar like I. I believe that like that is a that is a piece of things. But really the major concern is really the the the fact that we have code paths that are not fully merged yet, and a devnet that has stable specifications with that code well reviewed battle tested and hardened and ready like. Really, it's it's ready to rock and roll, and like. there has been a lot of effort that's gone into doing a lot of the testing and and some of this edge case design. But it's a complicated feature with a lot of code like we have a lot of code between between all of us. It's 20,000 some lines of code between our 3 clients that needs to move to to trunk branches. And that's really, I think the major concern. I I don't want to to sideline it with the with the the test. Net. Specifications it's

is is exactly is that you know, a large portion of of the code bases are, you know, we've exercised this codes on feature branches, but feature branch still needs to be merges. There's merge conflicts that happen. There's a lot of of effort that goes into doing that. And I know for a fact that we've all discussed that this is something that needs to be a focus for the next fork, so that we don't get in the situation. I think that, you know, after speaking with Paul, like, he basically instilled upon me the importance of making sure that that the feature branch stuff gets merged early and and aggressively. And I think that's something that because it's been complicated, and we've been doing it as feature branch testing. We're now kind of in the situation where we have this.

It's just a lot of work in order to get it there, and having that peace of mind that it's going to be a smooth rollout, considering how you know Petra like. And this is where it really, this is. What. What is the concern is that we did an amazing job testing Petra on the devnets. And we did an amazing job planning for it. We had 2 smooth releases, 2 smooth devnets that worked spectacularly, and then we got to the test nets. and it was a simple constant that caused it to go haywire. And then. because there was so much effort. And it's really it's a human issue, not a spec specification issue. It's not a testing issue. It's it's that we were all so focused on making the, you know, healing the test net that literally the same constant was wrong on the next test net. And it's not that it's a. It's a specifications break. It's not that it's a

we don't want to get into a situation with the forest for the trees, and miss something small that causes a bigger issue, because we're all scrambling and being able to to step back in a way and breathe, and then have the time to look for icebergs is really is really the primary concern.

Dustin Brody: What I would add to that, I think, is in terms of and and responding a bit to the idea of the the the Congo line but also in general. one of the challenges with achieving. That was that especially because it were definite one and definite. 2 things were changing quickly enough that it was sort of a unclear whether it was worth merging things along the way. So this isn't in Petra. There was more time to kind of be kind of do these gradual merges to our our trunk branch? For for Fusaka the things we made so unstable in in all respects I mean the specs. For quite a while. Validator custody was the the side of the last metaphorical moment, and etc, that.

and and by the time that, like the very moment again, metaphorically, that the dead net 3 is becoming kind of stable. for at least it's so. So it appears right now then, now, like is everybody's trunk branch ready? Well, no, we're not going to destabilize our production branch for this. Not so. And and Petra did not have this timing issue where it was immediate turnaround from sort of unstable specs, and everything else to is is trunk ready.

Matthew Keil: Now I know nobody wants to delay this, including us like no, we we don't want to to be to be bringing this up, but we feel it's important. And this is exactly why we wanted to at least bring up the bring it up. And I think that's probably the you know we we talked about some of this timing. that if we could, basically, if we do push back the 4 weeks it would we'd be able to do everything but Mainnet before dev connect. and that would leave dev connect post dev connect for Mainnet, and I don't know if doing it at dev connect as an interop. We've talked about that, but like to be fair. Paul brought up a great point is that no one wants to fly home from def connect, if God forbid! Something happens on Mainnet. But the idea that we could do an interop and actually do the rollout together and hold hands, and like, I know, we can all sing Kumbaya, which everybody loves.

But you know, there, there are options and opportunities for success that I think that you know, just because it's after dev connect at least mainnet you know I don't any thoughts about that.

Alex Stokes: What was the suggestion for defconnect.

Matthew Keil: So if we do push releases like final releases out 4 weeks, you know. So it's basically end of September, October one, you know somewhere in there. That would push Mainnet from where it stands today. To it would be just after devconnect, or possibly at Devconnect. I don't know if it's the right idea for us to all get together and do it while we're at dev connect. you know. I don't know if that's creates more.

Alex Stokes: If everyone's gonna be at Dove connect, it's kind of far for some people. But yeah, I mean, I guess. Yeah. So I hear all of that. Thank you for bringing it up. I mean, definitely, we should talk about this stuff. I guess my 1st question would be like, how confident are we in needing 4 more weeks.

Matthew Keil: This is something we've we, we basically all got into a A Tg in in order to assess this as the main people developing. And it's the number that we're and I speaking on behalf of us, Nimbus and prism. And again, guys please feel free to raise your hands, if you have any, or if I say anything that's out of what we've already talked about. But we all feel very confident that with the additional 4 weeks. So the end of September, because, like, we can possibly get onto And I'm speaking for the 3 of us as a team as a group we can possibly get onto trunk branches by the September one timeframe. But that doesn't leave any, you know, any time for double checking, for making sure that testings are hardened for doing a devnet, which really, I think, is the critical thing, is having a devnet with everything on trunk branch, and that would be the thing we would shoot for

after releases are done. You know, in the month of September. and so that 4 weeks really buys the time in order to do that, to do the additional testing on on trunk branches.

Alex Stokes: Is there a chance? 4 weeks turns into longer than 4 weeks.

Matthew Keil: I know for us as far as Lodestar. No, I think we're probably in great shape at that point. but I I would like to, you know. Ask Manu and and Dustin, you know, because we talked about that, but I'd prefer to have them speak. I don't want to speak on their behalf. I guess.

Dustin Brody: No, I think that. Oh, sorry. Go go ahead.

Emmanuel Nalepa: Oh, okay, thank you. Yeah, for prism. I think it's do. I want to merge everything for September first, st but it will, you know at very later time. You need to be absolutely confident about the code we match. So definitely, I think for more weeks we'll helps a lot. And additional thing is, if we sorry. If we run as a new devnet so devnet. For before the code is merging in trunks, that means that we will have some code in our code base which goes through Fuzaka and Bpo. One Bpo. 2 and Bpo. M. Which are never on the trunk branch. So I think the last devnet should definitely be run on the trunk branch of every client. To be sure that you know the

the 4th epoch is running on the trunk branch. Yeah. And exception is maybe holistic, actually. for sure, for Sepoli and Hoodie should be the case.

Alex Stokes: Yeah, I mean, yeah. So there is the suggestion here to do Haulaski. So on September. what exactly does this buy us other than we can just see it live, I guess.

Matthew Keil: Yeah, and making sure that all the interrupts work correctly like that to us, we feel is is important.

Alex Stokes: Right? And so, okay. But then I guess the concern then is that we wouldn't have everything on a trunk release. Let's call it.

Emmanuel Nalepa: Just a random question, is it possible to run a devnet after holly? Or yeah, I think sure.

Alex Stokes: Yeah, we can run demos whenever, yeah.

Emmanuel Nalepa: Yeah.

Parithosh Jayanthi: Also, we're planning on continuing testing until being that we wouldn't be stopping. Once we have releases.

Emmanuel Nalepa: Oh, okay.

Barnabas Busa: We are talking about a 2 months lead time here. Just so everyone is aware of it. We don't plan to do Mainnet in October. still planning to do maintenance in November. So like we can, we can get Host Key, release it out on a feature branch. Someone is not ready, and if someone is ready, then we're gonna use their front branch like I. I don't see this as a absolute blocker. We can have a client releases for sepulia. If we need to, we can push that by 2 weeks and then, have the hoodie releases also pushed by 2 weeks.

Matthew Keil: Yeah, I I tend to agree that whether it's a trunk branch or a feature branch for Holeski like. But but Potus is right, is it? Really? It's a non finality testing for the code that we have. And really, that's that's the big concern, you know, considering that we're going to do non finality testing and backfill really isn't a thing yet for anybody. you know, and that's really where where it starts to become critical is when you get into these non finality situations where you know, you need to make sure that data is propagated pretty widely so that it's available when you have a very limited subset of peers and same thing for the perfect peer scenario. That is a challenge. And so is it critical that we're on trunk, branch. And all this stuff is ready for Holeski when we actually do a real non finality kind of a a situation

arguable. You know, we could probably do that on a devnet 3 style branch, but you know, because we will still see the code exercised but definitely for a separate devnet. After that, if we do, holusky before we do a separate devnet, I think it's important that we have that that last devnet say mid September, where everything is on trunk branch, and we're exercising the actual code paths that are going to go live.

Alex Stokes: Okay? I mean, can we at least then agree to target helushi in September, are we okay with that cause? Yeah, I think where this is heading is what Ongar has here in the chat. I think we just need to discuss this a little bit more in depth. And see what we can do. Like. yeah, maybe this is the case, and that's the case. It's possible we can cut weeks here and there, and maybe we can do better. I would say, to move forward. So okay, sounds like, people are okay with Flushky in September. So you know, we'll take it a step at a time. We'll focus on that. And in the meantime, yeah, it sounds like the blocker is just general confidence in the code, and a big thing there is that things aren't on everyone's trunk branches.

In the code trunk. So I would focus on that. Then from there. Yeah, I'm sure myself and others will keep talking with everyone, and we'll see what we can do. Yeah, I mean, yeah, thanks for bringing this up. It's good to know.

Matthew Keil: Yeah, no one wants to deliver the bad news. But we thought it was important enough.

Alex Stokes: It's not, it's not. I wouldn't really call bad news. I think it's more just we should be talking. And let's figure out. You know the best we can do.

Matthew Keil: Yep, thank you. Thank you for everybody's openness to to hearing it. We we do appreciate that. And I know everybody, all the people that. I'm speaking on behalf of do as well. So thank you.

Alex Stokes: Sure. Okay. So if it's helpful, we can circle back to the details here. Because again, this all kind of started from the point on Tuesday, on Monday. with perfect peer to us. And this question of backfill. So are there any things we want to discuss now. or are we okay. I think it was mainly just a question of implementation, so there might not be much to to touch on right now. Okay, then. Next up there was a Pr here or the beacon Api. So let me just get a link. And right this is about essentially how the beacon node exposes Bob's to consumers

is inflag on the call use on there is the point.

Nico Flaig: Yeah, I can quickly talk about it. So the main open questions, there are, basically what kind of filtering do consumers want? So there was a previous discussion of using version hashes instead of indices. And the other open question was, Do we just want to return the blob, which was the internal discussion with other teams. So Manu and also Francis from base was in favor of that and few others to just return the blob and not the commitments and version test and stuff. So it would be good to get more feedback, especially from layer twos, which will be the consumer of this. yeah, just take a look at the Pr, I think this can be done, Async, unless someone has

an opinion.

Alex Stokes: Yeah. The point was raised about roll call. Let's see. Yeah. I mean, sure, when the next one is.

Carl Beekhuizen: Would be next week. But we've been having them on pause, for now. as in we haven't been. We haven't been having them or try figure out a bit more the relationship to of l 1 to the L twos and that kind of thing. I mean, we could. I can also.

Alex Stokes: You can just reach out.

Carl Beekhuizen: But local chats. Yeah.

Alex Stokes: Get any input. But otherwise, yeah, I think. I took a look the other day. And essentially, yeah, the the main thing here is just taking away a lot of the like additional consensus data that the roll ups, for example, wouldn't really need. And return just the blob. That seems fine to me. yeah, unless anyone has any comments on this right now, we can just take further discussion to the Pr, there and then. Yeah, we'll reach out Async to different parties. See what works for them. Okay, let's see. So I think that was everything we had for Fusaka. We discussed timelines. And yeah, we're essentially halfway, which leaves the back half of the call for Glamsterdam.

we have things to discuss. Although I did see Oscar here proposed, basically waiting. I don't know if people want to get into Glamsterdam right now. I do think focusing on Fusaka is quite prudent. Yeah, Oscar.

Ansgar Dietrichs: Yeah, I think personally that we basically the reason we opened Glamsterdam discussion was because we said, Okay, Fusaka is out of the door now everything is kind of just running its course. But we can focus on Glam Saddam. I think this kind of discussion has changed that, at least for for me. And I do think there's a danger if we basically just normalize splitting attention. So I personally think it would be best practice if we if we were to basically say, Look right now, there seems to be kind of really some urgency around Fusaka. It's even up in the air. How much delay we might cause that it could be that, like any splitting of attention, could add another week or 2, or whatever for

for this delay. So so I personally would say that we basically try to work towards being kind of back on some sort of track by 2 weeks from now and and then we basically and make the decisions there.

Alex Stokes: Yeah, I'm curious what other people think. Because so I mean, yeah, maybe just to give a summary. There were a few things and people had some updates. And then, yeah, I mean, I think we're pretty much in a place to go ahead and make a call on the headliner today. But I think, given this, it does seem more prudent even to, you know. Delay this segment segment by another 2 weeks. So the next Acdc. Well, I think that we see if I had bal sort of conditional on what the Cl. Would do. Mark.

Mark Mackey: I mean, the last time we didn't make a decision on the headline. The reasoning given was that we wanted community feedback, and I I think we've gotten that. And I think I mean. not a lot has really changed other than getting community feedback. I think we've had all the information for quite a while now to make the decision to be honest. So I don't know. I I see the like. People are waiting to do things like rebate specs on top of each other, and, like it, has its costs, delaying that has its costs as well.

Alex Stokes: Yeah.

Mark Mackey: I I mean me personally, I would be against delaying this decision, because I think we almost could have made it last call.

Alex Stokes: Okay, let's get into it. Then. So okay, there's a bit of a bridge Pr to discuss here. This is looking at how we structure the slot and the spec and all the different sub intervals. So, oh, yeah, thanks. Justin. Yeah, this was your Pr, so if you want to give any context that'd be great.

Justin Traglia: Yeah, I can talk about it. Hi, again. So there's a consensus. Specs. Pr, that I would like to merge. It deprecates the intervals per slot variable, and defines explicit durations for deadlines like the attestation deadline. This Pr is an alternative to 3, 5, sorry at 3, 5, 10, which we discussed about a month ago. But instead of using milliseconds this Pr defines durations as a percentage of the total slot duration and uses configuration variables instead of preset variables, which heath, Panda Ops requested. There are several groups that want to merge this pr soon like this week so that we can make so that we can start to really work on Glamsterdam specs. Eip 7, 7, 8, 2, which is like the shorter slot times.

eip and epbs sort of depend on this. so yeah, I don't know. I just don't. I would prefer I would want for us to merge it soon, instead of waiting until after husaka, like we originally said. and that's pretty much it.

Alex Stokes: Yeah, that makes sense. Are there any open questions we should touch on now. there's a number of comments here.

Justin Traglia: I do want to say one more thing so this shouldn't actually change the current behavior. It just defines new configuration variables and client teams can essentially ignore these until we start to implement Amsterdam.

Alex Stokes: Right? Okay? So I mean, I, unless there's a concrete, ask on exactly when to merge this end. I think all we're saying is sooner than after Fusaka, or, you know, soon with Fusaka. So yeah, I wanted to call it up. Because then, yeah, definitely touches, I think on 7, 7, 3, 2 and I might get the number wrong. I think fossil is 7, 8 0, 6. But there are a number of other eips, and the consists repo that this would use. So I know we're busy with Osaka, but if you have a moment, please take a look and provide feedback on the Pr. okay? So then next up right? We mentioned stakeholder feedback Nick. So I think wanted to give a summary of different input that she has found

from 8th magicians. Nexo.

Nixo: Hi, so I'm gonna put this link in the chat. Sorry for those who hate ocean. But so basically, I focused on the the top eips that were talked about in the stakeholder feedback, and I just wanted to call out some of the feedback so that we're not having them speak into the void here. But basically the stakeholders that responded were staking protocol dows, validator sidecar software based roll-up standards, block builders, relays, encrypted, encrypted encrypted mempool software, Rpc. And Node. Infra providers, protocol research bridges, L. 2 S. Dexs. L. 2 analytics, financial tooling apps and users independent stakers. So it was a pretty wide breadth, and it was pretty high quality feedback. Some concern callouts that I want to. Highlight is any slight slot. Pipelining in-flight changes. Apps are concerned about too much happening up to the end of the fork, and want to make sure that there's enough heads up for them to undertake the large engineering costs that that would require from them.

There were, there was a lot of support for 7, 8 0. 5 fossil but many people expressed concern about the lack of coverage of blobs. There was also notable feedback about the 8 GB, Max inclusion, list, size and inclusion list building logic being up to the consensus client implementation. 7, 8, 8, 2 had a lot of support, but most people felt like it was under researched in various aspects, and some call outs. There were issuance, validator centralization and consensus overhead, and I guess we won't talk about El. It wasn't super contentious. Anyway, most people supported block access lists for the consensus layer. Again, most people can. 14 of these stakeholders expressed support for fossil, 7,805 in conjunction with other options, only 5 cited it as a primary option. The most support that we saw was for Epbs. 7,732, 9 listed as their 1st option, 3. As their second option. There were direct impacts cited on the stakeholder communities.

such as trustless exchange between builders and proposers, reducing peak bandwidth and the ability to scale blobs. There was also support for 7, 7, 8, 2, 6, second slots, 5 as their 1st options. I will say that the only people who supported direct impacts to their community was Snowbridge as a bridge But most of the other supporters cited sort of ideological or indirect indirect impacts. And again, a lot of people felt like that was under researched. So that's sort of just the the synthesis of it. I encourage people to go read it. A lot of people gave very high quality feedback.

Alex Stokes: Cool. Thank you. I think this is at least the 1st time I've seen something like this. It looks like it actually is getting community, input which is really nice. yeah, okay, maybe that's all safe right now on that. Yeah. Any other questions or comments for Nixo, or about any of these points. Okay? If not, then we had a request for an update on fossil from Jihoon is Jihoon on the call.

Jihoon Song: Yes, I'm here.

Alex Stokes: Okay.

Jihoon Song: Mind if I share, screen.

Alex Stokes: Sure. Yeah. Please.

Jihoon Song: Alright. Can you guys see this? Okay?

Alex Stokes: We can. But just a comment before we get into it. Timeline wise we have, I think, other things to discuss. So yeah, I guess. Just try to move through the slides quickly. Yeah, I can. Don't delay, Dolly.

Jihoon Song: Thank you. I guess I could use like 7 next 8 min. So Hello! I'm Jill. I'm working on fossil. I'd like to talk about the complexity of fossil for both Cl and el. It aims to lay out technical aspects of fossil, to provide solid ground for core devs, to make a better technical decision to make sure everyone is on the same page. I'd like to quickly go over the fossil mechanism, see how it can be implemented referring to the spec, and then demonstrates how fossil can be replaced on top of apbs. So from Beacon Committee members with borrowed 16 validators to constitute Inclusionist Committee Inclusion List committee members construct dials and broadcast it over the Prp network.

But testers and builders collect the Ils and builders update their payload to include Il transactions when the proposer submits the block. But testers validate if it contains the ir transactions, if it's yes, they vote for it, and the block would become canonical. Now let's take a look into how it can be implemented. The 1st validators can figure out if they have inclusion, inclusion, committee assignment by running this function. Validators need to call it at the start of an epoch, and is stable within the epoch and the next epoch. So it has one epoch. Look ahead. When an Il committee member performs its duty, the Cl. Will call, get in colossion list engine Api and the El will collect Il transactions from the public sample, and then return it to the Cl.

And then a validator receives the Ils. They check if it's not equivocated, and then catch it. So if any Il equivocation is detected, all Ils from that equivocator should be ignored. But we don't have any selection mechanism. We just ignore it for that slot. So technically, the quivocator can just normally produce Ils. Next time when a builder updates their payload, they can call pokechoice updated engine Api, the El can rebuild the payload or just append the I transactions at the end of the payload one by one, depending on the implementation. When our testers receive a block and run new, payload the el validates the Il constraints and return the result. So if the block is not il compliant, the Cl. Will record the block. As il unsatisfied.

we want to block the reorg, so the block would get the proposer boost, and if it's not, I am satisfied, then our testers will not for vote for the block, and proposals will not extend it. So this is how valuable fossil can be implemented. If you have any question, please feel free to interrupt me. Otherwise we can just move on to how fossil can be replaced onto a Pbs any Pbs, when a proposal receives bits from builders. They want to know if their payload will satisfy the inclusion list. In that regard we add the Il bit list to builders, bits. A proposer can safely ignore bits that don't have a superset. Il bit list compared to their subjective il view.

Then they can select the bid. However, they want the bit. Il bit list, construction and comparison can be implemented like this, for example. but it's quite straightforward. So I think we can just move on. The other major change is how our testers enforce inclusion rates. So let's say that we are testers for slot n, and we receive transaction XY. And Z. As ir transactions. When the execution payload for slot n. Minus one arrives, we validate, if it contains ir transactions in this example, let's say that it fails to satisfy the ir constraints because it doesn't have transaction. Y. For whatever reason we will mark this payload as not ir compliant. When the beacon block for slot N arrives we will validate if the beacon block is ir compliant. The only case that we report that become block is when the parent node was full.

but the payload was not ir compliant. Whether the payload was timely, timely or not doesn't matter. If the parent block was empty, we're good. If it was full and ir compliant. We're also good. So if the payload is not ir compliant, the become block can reorget while making progress. and this can be implemented in 2 steps 2 steps because of the separation of become block and execution payload. When the execution payload arrives. It works the same with vanilla fossil. The Cl. Relies on the el for the il validation. If it's not il compliant, we mark the payload as il unsatisfied, and then when the Pcom block arrives we check if the parent node was full and the payload was not il compliant. If yes, the Pcom block should reopen the payload, otherwise our testers were not vote for it, so that the Pcom block will reorder.

Other cases. Follow the Pbs back same as vanilla fossil for any become block. That is not il compliant or testers and proposers won't accept it as hat. And this is it so? If you have any question or comment, please feel free to share it, and I wrote 2 articles about this one for the El, the other for the Cl. Please take a look into them. If you are interested in details. Let me share the links in the chat, and thank you for your listening.

Alex Stokes: Yeah, justin.

Justin Florentine: Yeah, just a real quick question from an Eldev's perspective. So when we say it would not have fit, are we implying that the missing transaction would have to be executed against the block that it was missing from. I'm just wondering about the dynamism of the actual gas cost and some kind of gray area around the notion of whether or not it would have fit or not.

Jihoon Song: So I can share the execution spec later. But the idea is for for the ir transactions that are not included in a block we check if they can, they can be appended at the end of a payload. So how it works is we? Firstly. validate, if it's intrinsically valid, and if it's yes, we're gonna check. If there was enough gas left to include the gas, and if the transaction sender it was affordable. I mean, if the transaction can afford the transaction. If yes, it means that the transaction, I mean the missing Ir transaction could have been appended at the end of a payload, and then we mark the payload as ir in not satisfied.

Justin Florentine: Okay. Thank you.

Alex Stokes: Okay, there are some comments in the chat about the agenda. and people had made requests to get some last minute things in around the headliners. So that's kind of what we're doing now. There's 1 more request to hash. Give a short update on 6 second slots. The way I'm viewing this is, we take all of these inputs along with the community input that we got from Nixo. And then we can make the decision today. So that's where this is heading. I mean, we haven't decided the headliner yet. So these are all you know. I feel like people are getting ahead of ourselves by one step. So anyway, I think Maria wanted to share a quick update. Let's do that.

Then we will go to the headliner selection.

Maria Silva: Right? Thank you. So I just quickly share my screen. This should be fairly quick. So I just wanted to have an update on some of the numbers that I shared last time. So, going back to the to the metrics we were that I showed last time. So the 1st update is on the block arrivals minus the relay publishing time. So this is trying to estimate block propagation, excluding timing games. and the the update here is that we were actually using data from a different table that had a few issues. And so Sam, from depend Ops. He realized this and and and told me the right table we should be using and actually looking at the community notes. Now.

the 95 the 95 percentile is actually much closer to what we were seeing on the internal notes from the Ops. So it's around the 865 ms. So this is looking much better now. so it seems like we can do the block propagation in under one second. The second update is around just the at station arrival for Miss Slots. So because they are Miss Slots, we are not considering the propagation and execution and validation. So we are just looking at this blue part of your attestation propagation time. Okay? And for for these. I also want to to to share something that Sam from from the Ops team did so. He was looking at the different percentiles of arrivals for me slots, and he was seeing the different contributions of the different entities. That we got from each year.

And we were seeing that initially, a a big part of the late arrivals were due to a few entities. and we actually reached out to kill, which was the one that was showing the the biggest change, and they noticed a misconfiguration on their validator that they then later fixed. and this was the result. So now kill me! Is the light blue. So he here he was the dark blue, because it was the 1st one, and he's now he's in the second place. And so it's these light blue. So it got much, much better on the higher percentiles. And this actually led to an overall decrease of the 95th percentile from 2.5 seconds to 1.8 5 seconds. So I think this shows that maybe a way to go about these, or it's something that we are also doing at the moment is targeting these these larger entities that are showing here as a

big contributors on the later arrivals, and trying to understand what could be causing these and and trying to understand if it's something that that we can fix. Yeah. So I I just want to say that we are continuing to work on the empirical analysis and trying to find more optimizations. There's been also some good progress on the specifications and also early prototyping in clients. So I think we are working towards a good. a good place here. Yeah. So this is the. This is the updates. I don't know if if anyone else wants to wants to to say anything or ask questions. If not, I will just stop sharing.

Alex Stokes: Great thanks. Yeah. There were some comments in the chat around this data, looking a lot better than last time. Which is really good to see. So yeah, thanks for that. Okay. let me just double check. But I think that was everything we had. So okay, now we come to selecting the headliner for Amsterdam, which everyone seems very keen to do. And yeah, I think all things taken together. I think where we had left the last time is that essentially, Epbs was leading candidate. You know one thing, there was community inputs which we did get. Now, thanks. Thank you, Nixo. and it seems like there. That was also the selection as well, essentially. Pps. So I think you know, what I propose is, we go ahead and Sfi. 7, 7, 3, 2 for Amsterdam.

I thought we were essentially waiting for this decision to like simultaneously, Sfi es on the El. But either way we can figure that out. But yeah, basically have those 2 as our Cl and Eo headliner. and that unlocks the 1st step of glens RAM scoping. So. I suppose we can discuss the decision, but it seems like this is a crowd consensus mark.

Mark Mackey: So we know that. That there are synergies between fossil and epbs. So if we and and given the community feedback, there does seem to be a surprising amount of support for fossil, or at least it surprised me how how highly the community does seem to value fossils. I think. like, I think last call the consensus was towards Epbs for the Devs. We just don't have very good visibility on how easy it is to also include fossil yet, and as far as I'm aware, we're waiting for things like the Epbs spec to be rebased on top of the fossil or on top of Fusaka, and then for fossil to be rebate, based on top of epbs and obviously a bit of look into the implementation. But

I would also Cfi fossil. That would be my vote for now and and like inclusion of Cfi involved.

Alex Stokes: Okay, I just think process wise. So that was also why I wanted to have the fossil segment earlier. I think process wise. We wanted to do the headliners first, st and then that would kind of put fossil in this bucket of being a not headliner. The decisions for non headliners, I think will come in the future. I don't think we should try to scope everything today, if anything, I think going step by step, is going to be best. So, you know, if we move ahead with the headliners today, which sounds like we are. we should work on those. And yeah, over the coming weeks we can have a conversation about other eips to put in there.

That gives us more time to validate these questions around, yeah, how does fossil exactly fit other Pps like, is it a good idea? And all of those types of concerns? Okay, Marcus, here. First, st was your hand there from earlier. Okay, yeah. Source book.

soispoke: Yeah, yeah, I mentioned this in the chat. But I think like fossil is like right now, a bit in a weird place. And I think it might be in a weird place already, just because of the headliner structure. I sort of like, said this already, but like the fact that it's cross layer, and it's also like, not too huge of a change, but also like not super small like. But it's in a weird position. The fact is like fossil, was considered as a headliner, and there was super broad community support for it. So I also don't think it's like super normal or like process wise to just like bump it, and just like treat it as like a normal eip without additional consideration. I think

I think, yeah, what I wanted to propose is like, yes, like process wise. Maybe, like we can't have 2 headliners. So just like bump it to the status of a vanilla eip And also, you know, consider, it's a vanilla aip. So if it actually ends up being the part that slows down the fork, which, from the feedback of like devs that have worked on epbs and fossil shouldn't be the case. But like we, you obviously never know. I mean, it is a vanilla head, high eap now, so you could just like move on with the fork without like including fossil if it turns out to be the actual issue. But I just think like just bumping it as a like, oh, yeah, it's actually not a headliner anymore. After, like, the community has signaled like a very broad support, for it is is very fair, either. So yeah, just pointing out, it's in a well position.

Alex Stokes: Yeah, I mean, I don't think it has to necessarily be weird. So I think we'll have another round of non headliner Ips in the future, and you know, I think possible at the end is, has a lot of support, and it could easily go in there. You know what I would suggest then, is taking the time between now and when we make that decision on not have minor eips to de-risk all these questions around, yeah, interactions with us and any other complexities that could come up there. Potus and the Barnabas.

Potuz: So if epbs is specified and every single client voiced to have fossil in it and the community, most of the community asked to have fossil with it. and there is already work on it. There's already work in rebasing it on top of epbs. These people are going to continue working on it. Anyways, it doesn't matter if it's Cfi or not. I don't see any reason not to cfi it, because Cfi does not mean that we're not that we're going to include it. Nor doesn't mean that we're going to delay the forward until it's ready. I don't see any negative connotation into Cfi in it today because I don't see anyone against it.

Mark Mackey: Agreed.

Alex Stokes: Okay, Barnabas, I think this is going to be your counter comment, Otis.

Barnabas Busa: No, I agree with. I'm actually quite surprised that Foxville got demoted as a non headliner. It was proposed as a headliner. It's a massive change on its own. I don't see a reason of not having both of them in, but we shouldn't call it fossil as a non headliner the whole point is that maybe Glamsterdam will have to have 2 year headliners and one year headliner.

Alex Stokes: Yeah, I mean, I wouldn't get too hung up on the exact semantics of headliner.

Mark Mackey: I think it was just about how much like a headliner is somewhat by definition, a very large change, and maybe due to synergies. You might consider fossil, not as large as it would otherwise be. I think that's really the the difference in terminology here. It's not anything more than that, as far as I can tell.

Alex Stokes: Right, like whatever goes in, we'll go in, and we just still need to decide what is the right scope. Yeah, onskar. And then I have a follow up comment myself.

Ansgar Dietrichs: Well, yeah. So in my mind, there's a pretty big question, at least a potential for difference in what the headliner means versus a non headliner, and that is the whole delaying the fog for. Talked a little bit about it in chat. I do think so. One thing, for example, historically, we've been very, very bad at like saying, trying to sequence work on different features, like we've been in the past saying, Oh, yeah. Ps. Is not in a fog, but we still need to prioritize the work on it, and then it just left sitting there until we actually prioritize it in a fog. And these things. So like, I think if we just say, Oh, we will 1st finish all the work on epbs, and then do the work on fossil, so that basically fossil is the stretch goal that we could just drop. That will not happen, I think what will happen in practice is that work on both of them will be integrated and will basically just basically, there won't be a

fossil like epbs is ready. But fossil is not so like, basically just it will just like delay both of them, by the same amount, in a sense. So that's why, to me, initially, the headliner status was at least kind of implied some sort of yeah, this is the feature the folk would wait for. And otherwise you would not wait for the fork. In a sense, basically, like I'm open to. If if really, the Cl. Devs are confident that these 2 are easily integratable, I just like we given that we kicked out eof we have not had any meaningful features on the El side, for basically, since spectra, I really really really would not want us to delay Glam Saddam at all from from the El side, because the L side is very exciting. It's it's bringing a lot of scaling features across bulk lab access lists and repricings. I think, then the understanding must be that

whether we call fossil a co-headliner of the Cl. Or a non-headliner does not really matter for me, but the understanding must be that then Cl. Headliners cannot hold the fork under any circumstances like if the Cl. Headliners are not ready and the yellow headliners are, of course it's by a few weeks we wait. But if it's actually like, still, like 2, 3 months of work left, we would just go ahead and ship Amsterdam with only the El headliners. If that's the understanding, then I, personally am perfectly fine with combining these erps, then it's really up for the Cls to basically pick their own scope here.

Alex Stokes: Parents Terrence.

Terence Tsao: Yeah. So I'm probably the only person in this world that implemented both epbs and fossil. So I kind of know how it works. So I, personally don't think like it's that bad of an idea to do etbs and fossil together in the beginning, and then push it, and then. if fossil end up delaying etbs significantly we strap off fossil. I think the interaction, the most of the interaction between Pbs and fossil, is in the fortunate side, because in the Epbs you get this notion of building on full or empty, and then fossil, you kind of have this like decision you have to make on whether to reorg the block or not. That's probably the biggest interplay other than that. It's pretty like

Orthogonal. They're very different because of Epds doesn't have el changes and fossil has el changes, and then the and then and then and then, and then the engine. Api also don't intercept as well, so that part is very nice. So yeah, so I think, like. I think Etbs by itself, like I speak on, maybe just from prison. On my personal opinion. We can ship like early next year by early, I mean, like maybe, like March or April, but then, like with fossil, you probably add, like a month or 2 delay. I think that's probably the I probably the best, probably the best way I can quantify. I guess the question at the end of the day you have to ask is like, are we scoping based on timeline? Or are we would like, basically, what are we scoping based on?

That's just my 2 cents.

Alex Stokes: Mark.

Mark Mackey: I guess. And then a further question, like, if we Cfi something like, okay? So we've specified epbs, which means that the Glamsterdam spec is going to have epbs in it. Does Cfi, and something mean that the spec is going to be modified to include those things, or just that the Pr. Is going to be ready for the spec to include those things, because if it just means that if it doesn't mean that it's like in the spec. Yet. Then again, I would reiterate Potus's point, that there's no reason to not cfi

Justin Traglia: I believe it would be the latter. It would just be a Pr. That's ready to merge into to Amsterdam.

Mark Mackey: Okay? So at that point, we're not actually making the decision today to Cfi doesn't introduce any delay.

Alex Stokes: That's correct. I think we do it in a way that in yeah minimizes the risk. So I'll echo Tim's comments here. Essentially, we'd Sfi Epvs bals today. Then sure, we can see if I fossil seems to be how people want to play this. I think that is reasonable. But the idea would be that we move ahead with spec and devnets for just the Sfi things, and then only once those are stable, then do we think about elevating from Cfi to Sfi

Justin Traglia: I wanna make one little note. So if we sfi epbs, we would essentially rename 7, 7, 3, 2 feature spec to gloss how we say it, and then we would rebase 7, 8 0, 5 off of that. So just the feature spec for fossil would be rebased pretty much.

Alex Stokes: That makes sense to me. And yeah, I mean, it sounds like there are synergies between the 2 features. So then maybe it reduces the complexity of the fossil feature. But that'd be the hope. Yeah, okay, I mean, I think on square will get as strong a commitment as as possible. But yeah, maybe. Then, to make it explicit like, do we feel okay with this plan? Which again, this is following patterns we've laid out in the past, but essentially we would commit to focusing on the Sfid Ips before the Cfid Ips. Nobody wants to commit there. There's some chatter over here in the chat.

But any case, we are coming up on time. and I think we have enough to move forward, so we'll ssify 7, 7, 3, 2, we will see if I fossil. and that will be it for Glamsterdam today on Square.

Ansgar Dietrichs: Yeah, I want to make one last push against sfying epbs. I just saw on chat that the Epbs champion said that there's no chance that epbs could be ready by March. I understand that we are not specifically taking talking about timelines for glums lab in general, but like that makes me feel like the earlier statements that epbs is basically already well implemented, tested, and very light. that were somewhat misleading. And given that, I think there's a good chance that the El side will be ready on that timeline like block level access list and summary pricings. I would personally think that then we might want to revisit, only having a single headliner in the fog, which was originally planned, and only having buckle blacks. As this headliner.

Mark Mackey: I I mean I, when you said earlier, that if the distance between the forks is several months between the El and the Cl. Side. If the distance is several months, then we. you know, cut the El sooner. I think that's largely correct. Like the the main difference. The main reason not to split the forks up is doubling the testing overhead. But there's obviously a trade off there between basically, how many months there are between. So I I mean, as of right now. Yeah, we don't know how long it's gonna take the El to implement block level access lists. And when they're gonna be ready, but I I would think generally, if there was a large gap between the 2 sides, that we we could in principle at a later time decouple them.

Ansgar Dietrichs: Okay. Yeah. Then, sorry. I also, I know that this was not realistic to actually, you know, be revisited. So then I'm I'm happy to to have that be the compromise kind of point of view, that we at least very open to the option of these ending up not being delivered together. Of course, but for now track towards a unified glam set up that works for me.

Alex Stokes: Yeah, and to circle back. I think we should be focusing primarily on for soccer right now again. It sounds like, it'll be very tight to get that wrapped up this year. So we should be focusing on that. And yeah, I think this lets us make some progress on classroom, which is good. I also think it's quite early to have a super clear sense of okay, these exact timelines and what that will look like. So again, Cfi, sorry. Sfi, 7, 7, 3, 2 cfi fossil that settles the discussion today, and that gives us more to move on with. Otherwise, yeah, we will be talking about slash working on for Saka. Any closing comments otherwise. I'll see many of you on a call Monday.

Potuz: Bye.

Alex Stokes: Thanks. Everyone.

Pooja Ranjan: Do.

Alex Stokes: Bye.

Mark Mackey: Hey, guys.

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